From nobody Thu Dec 2 18:51:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BB67618ABB2E for ; Thu, 2 Dec 2021 18:51:50 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J4lRn73w4z3t42; Thu, 2 Dec 2021 18:51:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B2Ipg7Y008549 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Dec 2021 10:51:42 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B2IpfYa008548; Thu, 2 Dec 2021 10:51:41 -0800 (PST) (envelope-from sgk) Date: Thu, 2 Dec 2021 10:51:41 -0800 From: Steve Kargl To: John Baldwin Cc: "Bjoern A. Zeeb" , Ed Maste , FreeBSD Hackers Subject: Re: Retiring WITHOUT_CXX Message-ID: <20211202185141.GA8371@troutmask.apl.washington.edu> References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J4lRn73w4z3t42 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 02, 2021 at 09:02:17AM -0800, John Baldwin wrote: > > Also, have you looked at what WITHOUT_CXX actually removes? c++ is just > a hard link to clang. That's the big space eater, not libc++.so.1 or > libcxxrt.so.1. For reference, on my 13.x desktop, libc.so.7 is about 3 > times the size of libc++.so.1: > > -r--r--r-- 1 root wheel 1986208 Aug 19 15:28 /lib/libc.so.7 > -r--r--r-- 1 root wheel 112200 Aug 19 15:29 /lib/libcxxrt.so.1 > -r--r--r-- 1 root wheel 846200 Aug 19 15:29 /usr/lib/libc++.so.1 > How well do libc++.so and libcxxrt.so work if you remove libc.so? Yes, removing libc++.so and libcxxrt.so only remove 95 kBi, but your size comparison to libc is misleading. -- Steve From nobody Sat Dec 4 06:59:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ACE1C18C00B6 for ; Sat, 4 Dec 2021 06:59:29 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5gXw5fpXz4hVT for ; Sat, 4 Dec 2021 06:59:28 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x929.google.com with SMTP id n6so9732601uak.1 for ; Fri, 03 Dec 2021 22:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Yhky9qnndDCv0kgcHgX1OyLFWjhEuld5605sP4H9SQA=; b=qfX+8Nlyxfo04AoPVVlBKBg32T8mKN1941Km7ShS80rSdpkgFhxKeAFwaRUo3Tazq2 +VBpgFfZGrz1QA4njNnsqqn72vkQQ8OYJEXP9aUOXz6PnzI6bBuXQoiu5TQcqKdTMGVt 6bS1cRPpXI7RtO/XUnbO/28LJJWEghuvCgR+am35FV5t26pDftW30tf7mNX5PtxTta2P 2IWj9w8ag+TCj2wUHx6cgg9gsMhcVnI2/uw1GrJelYidXWiJBs+acBMJjyh8qkkWmPo8 B9GV0e5D7EfHLQrgTtb0c5KtagFsPYS39unK0a3jmAVeqicOUSSljBuNhyT5TXHZlwnr 2YzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Yhky9qnndDCv0kgcHgX1OyLFWjhEuld5605sP4H9SQA=; b=E3i6iaz6IETZeJxhGcTQqfIy54++eOhMOCaHLYjKXO5QZgfJbNhW8MHtXhzahhn0fS OpQivUWk1wjCZwz5IveoHNu+Nt6/HJJiMuVJhctGgtk3pJowqDA862K4p6RtrYnrNZgH HY52YnRImYwlHw59i9korMVHzlRmJeVkZ+yDo2h7NdFbn0I3FnpjQQEiZ3Q92jz7qqYb pawM1ONqWIerxYPQ/9Okkp26Lwh6GQCIY8btBHBuXrq3IuGirG39jTmZWSMrNjEpEboE AYQFNKjAOKKJ8H+zbRGTzhE4PE/3foaYNngo4T0Um7UlYKg9IzpQL2dtmD87CPsBNtOu enZQ== X-Gm-Message-State: AOAM5327Zb5EsrEMYVgeJVpd+OI+50ulJSo7Alky5B2dsWcjwiCL6Wvx MO1R4Y6vW8qRWMAaxTU3AcuM1/KMIF6F34Mkt+5yjRGg0IA= X-Google-Smtp-Source: ABdhPJwakRRc+tt/oiDYePmebWvZlCroRC7PoTJoT/oCVOtyVU0liRZw19z66HjhIxFtXW1LCuznsRRla1lL2W9qzcI= X-Received: by 2002:a05:6102:2922:: with SMTP id cz34mr24966385vsb.56.1638601161613; Fri, 03 Dec 2021 22:59:21 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Sat, 4 Dec 2021 09:59:10 +0300 Message-ID: Subject: zoneinfo problem To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J5gXw5fpXz4hVT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qfX+8Nly; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::929 as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [0.61 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; R_MIXED_CHARSET(1.25)[subject]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.36)[0.363]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I don't know if here is the right mail list. I'm using stable/12. But there is a strangeness about zoneinfo files. # ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/localtime # date Sat Dec 4 03:48:50 -03 2021 Above, I want to set the timezone to GMT+3 but date command shows as GMT-3 # rm /etc/localtime # ln -s /usr/share/zoneinfo/Etc/GMT-3 /etc/localtime # date Sat Dec 4 09:49:07 +03 2021 When I set to GMT-3 then date command shows as GMT+3 I think there is a problem with zoneinfo files. Best regards From nobody Sat Dec 4 08:58:24 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E5F2118CDC2E for ; Sat, 4 Dec 2021 08:58:26 +0000 (UTC) (envelope-from dereks@lifeofadishwasher.com) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5kBB5vsfz3nHJ for ; Sat, 4 Dec 2021 08:58:26 +0000 (UTC) (envelope-from dereks@lifeofadishwasher.com) Received: by mail-qv1-xf2f.google.com with SMTP id i13so5190623qvm.1 for ; Sat, 04 Dec 2021 00:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifeofadishwasher.com; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=q850p3wayQ97gUdEjyPK32L308qoQeMpkw6PBZY19UY=; b=TAZHopBHQqe9EkUL8fiG8j2ozXI20XNulW/Nk/Qg65lhwq1qO1A2DIctkLPJVUKUvs TsirmeHmvfvUjLi3F5pWxH9cX9zcWWbopvnwiLsTKxxKKGN2IHrZ80r23+TU/y9NgW/C cAvRVp8VbXQ3+EkL5yUiERKvfPTUlOfTx5bC0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=q850p3wayQ97gUdEjyPK32L308qoQeMpkw6PBZY19UY=; b=L46Zq/aKkipi7N5l8YjRY+QJKjp25+menZT23EEiY65/mcT/4wUTLq+1ZKoTtOZEtj HDcW6DLYuvw/C1LufN7S+xK7XfkIRaaCOn1Zcj+fqyctSEQt+7N77A6jnHP+Lf4f4nJw 8rLtv4K8FAMDG9AG3e6YeY8kaxm2Xij74T6UdwYz0lDlMCId2b+iMdjdnfdLdf/uSdpE pCotD6WXda4GbHK/hQXKZG486m/A991jT64tCtjAZp5Hq0quDHZikrj2XqGe/QuTOQd6 LskLZzRYNyBzy7AZ/sYClVg+DoFfRTfTCSmAmBMQ96AgrHrg/j+cQ7ebH6DGL6wNFS8I wH0w== X-Gm-Message-State: AOAM5326D+0clC4ojrVgDfpGUg4bExMzgu9vxmbh44w0Amm3JCPOfaIb 1NMomXPBW9ElDfw/MeOvC+NBhfBbRLSa9Q== X-Google-Smtp-Source: ABdhPJz7prTFkQWPd3rKbgDJ8X32EzAyj5pI6wt8MmAkYAz/OkL6bK/BiHKx+57idPphmrHqo5hduQ== X-Received: by 2002:a05:6214:400e:: with SMTP id kd14mr23914946qvb.70.1638608306224; Sat, 04 Dec 2021 00:58:26 -0800 (PST) Received: from lifeofadishwasher.com ([2601:547:900:2410:54ab:d385:f777:b2eb]) by smtp.gmail.com with ESMTPSA id w14sm3761882qkp.54.2021.12.04.00.58.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Dec 2021 00:58:25 -0800 (PST) Received: by lifeofadishwasher.com (sSMTP sendmail emulation); Sat, 04 Dec 2021 03:58:24 -0500 Date: Sat, 4 Dec 2021 03:58:24 -0500 From: Derek Schrock To: =?iso-8859-1?Q?=D6zkan?= KIRIK Cc: freebsd-hackers@freebsd.org Subject: Re: zoneinfo problem Message-ID: Mail-Followup-To: =?iso-8859-1?Q?=D6zkan?= KIRIK , freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4J5kBB5vsfz3nHJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 01:59:10AM EST, Özkan KIRIK wrote: > Hi, > > I don't know if here is the right mail list. > I'm using stable/12. But there is a strangeness about zoneinfo files. > > # ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/localtime > # date > Sat Dec 4 03:48:50 -03 2021 > > Above, I want to set the timezone to GMT+3 but date command shows as GMT-3 > > # rm /etc/localtime > # ln -s /usr/share/zoneinfo/Etc/GMT-3 /etc/localtime > # date > Sat Dec 4 09:49:07 +03 2021 > > When I set to GMT-3 then date command shows as GMT+3 > > I think there is a problem with zoneinfo files. > > Best regards > This is expected. https://github.com/eggert/tz/blob/2018g/etcetera#L38-L44 From nobody Sat Dec 4 09:58:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E95018CAA68 for ; Sat, 4 Dec 2021 09:59:00 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5lX32F5Mz4Zb2 for ; Sat, 4 Dec 2021 09:58:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id az37so10081027uab.13 for ; Sat, 04 Dec 2021 01:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dpK/X0uyV1YPmwN8AK6dUwmtq3j0T7ldHe9dDWHpxrA=; b=GrkYjv/dVmupX38buOaWlTQ2xnqeT8/SGHxsSySFanqG1rU2nDL8pEmTeG/SUWerw9 jfAZAE0vva/20gS9JTNZ3pJlZFMww7orHf6xHa4+d+qjFZ/cQNgw39hlJQOaqQsXwRYw d7NMFdYbXqT5+1A24QcWfSu/5nNr7hKvyfn41NjOLbYm3qanMuyZUPFAlRSzhMXkaALF vN6wgOUl8bmjiStPQI0lPlKOLSU4yjmomdZTcZBU2FurzmW4/BY01YHn+jNysUy9HtKR h/LxXWb8A8si7783qhNQYjrK9c2te1rAaeWSnC4OqCDwjKjWdQuPs46W9jxHMdcywR8t 7New== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dpK/X0uyV1YPmwN8AK6dUwmtq3j0T7ldHe9dDWHpxrA=; b=b6ucW5QAZ/v5jrmmRkWgaNIzsW/NzAtPeyPMPnZrM6e1o8I5Wm1EFb0k6KSiE4fOKV MVQ+ACB54sTL8cZyRAtn5fzkg9u4APoRgFbCQ4Rb4Anz/B7buldonRP8hPj8EajckABe aj/hWohBeiEMzM06zBNnQkCyo5v9bBYigEMLYEJwBs/UxfQ4u8ClMl7YQPGB8jLu1yZa Fdg4x7smGxGAiTzMGptsVfgnqsP9wObrBy4Uhc/JgAHDDn32St1rhXKS0RkxByjOyzci mSJa/yVSv6+JqKux7bMgwrH1hHAA83aRNcJRvS925MGtD7dzN2TN5DGj+d7uvdc0TxFT bD0Q== X-Gm-Message-State: AOAM532qFzzJJx6/4P5I25mhDVhCKVja1tv9BSBV52uwNRYSTOvH6Zj7 Pd7MD8QZDWzqtbZqMD1ImDbbI46b5W9fUUR4d5o= X-Google-Smtp-Source: ABdhPJwJ3LYRMNCzGPdMG9HmV0n7rfApy5ugvgEcQIr0COPZfYgBFDwzaiKU2X/onVca8ix9FXT50wqF5Aj5sQTkSPc= X-Received: by 2002:a67:d508:: with SMTP id l8mr25046093vsj.42.1638611933241; Sat, 04 Dec 2021 01:58:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Sat, 4 Dec 2021 12:58:42 +0300 Message-ID: Subject: Re: zoneinfo problem To: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J5lX32F5Mz4Zb2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="GrkYjv/d"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::934 as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-2.83 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; R_MIXED_CHARSET(1.00)[subject]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.83)[-0.830]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Thank you On Sat, Dec 4, 2021 at 11:58 AM Derek Schrock wrote: > > On Sat, Dec 04, 2021 at 01:59:10AM EST, =C3=96zkan KIRIK wrote: > > Hi, > > > > I don't know if here is the right mail list. > > I'm using stable/12. But there is a strangeness about zoneinfo files. > > > > # ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/localtime > > # date > > Sat Dec 4 03:48:50 -03 2021 > > > > Above, I want to set the timezone to GMT+3 but date command shows as GM= T-3 > > > > # rm /etc/localtime > > # ln -s /usr/share/zoneinfo/Etc/GMT-3 /etc/localtime > > # date > > Sat Dec 4 09:49:07 +03 2021 > > > > When I set to GMT-3 then date command shows as GMT+3 > > > > I think there is a problem with zoneinfo files. > > > > Best regards > > > > This is expected. > > https://github.com/eggert/tz/blob/2018g/etcetera#L38-L44 From nobody Sat Dec 4 18:53:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BF79F18D1BF1; Sat, 4 Dec 2021 18:54:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J5zPN6tq1z565j; Sat, 4 Dec 2021 18:54:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B4Irq6M020460 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 10:53:53 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B4IrqGQ020459; Sat, 4 Dec 2021 10:53:52 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 10:53:52 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: What to do about tgammal? Message-ID: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4J5zPN6tq1z565j X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [1.04 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(0.04)[0.042]; NEURAL_SPAM_SHORT(0.99)[0.990]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N What to do about tgammal? A long time ago (2013-09-06), theraven@ committed a kludge that mapped several missing long double math functions to double math functions (e.g., tanhl(x) was mapped to tanh(x)). Over the next few years, I (along with bde and das reviews) provided Intel 80-bit (ld80) and IEEE 128-bit (ld128) implementations for some of these functions; namely, coshl(x), sinhl(x), tanhl(x), erfl(x), erfcl(x), and lgamma(x). The last remaining function is tgammal(x). If one links a program that uses tgammal(x) with libm, one sees /usr/local/bin/ld: fcn_list.o: in function `build_fcn_list': fcn_list.c:(.text+0x7c4): warning: tgammal has lower than advertised precision The warning is actually misleading. Not only does tgammal(x) have a *MUCH* lower precision, it has a reduced domain. That is, tgammal(x) produces +inf for x > 172 whereas tgammal(x) should produce a finite result for values of x up to 1755 (or so). On amd64-*-freebsd, testing 1000000 in the below intervals demonstrates pathetic accuracy. Current implmentation via imprecise.c Interval | Max ULP -------------------+------------ [6,171] | 1340542.2 [1.0662,6] | 14293.3 [1.01e-17,1.0661] | 3116.1 [-1.9999,-1.0001] | 15330369.3 -------------------+------------ Well, I finally have gotten around to removing theraven@'s last kludge for FreeBSD on systems that support ld80. This is done with a straight forward modification of the msun/bsdsrc code. The limitation on domain is removed and the accuracy substantially improved. Interval | Max ULP -------------------+---------- [6,1755] | 8.457 [1.0662,6] | 11.710 [1.01e-17,1.0661] | 11.689 [-1.9999,-1.0001] | 11.871 -------------------+---------- My modifications leverage the fact that tgamma(x) (ie., double function) uses extend arithmetic to do the computations (approximately 85 bits of precision). To get the Max ULP below 1 (the desired upper limit), a few minimax polynomials need to be determined and the mystery around a few magic numbers need to be unraveled. Extending what I have done to an ld128 implementation requires much more effort than I have time and energy to pursue. Someone with interest in floating point math on ld128 system can provide an implementation. So, is anyone interested in seeing a massive patch? -- Steve From nobody Sat Dec 4 21:20:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23D851837833; Sat, 4 Dec 2021 21:20:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J62fK6xnNz3jdQ; Sat, 4 Dec 2021 21:20:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B4LKOEl020812 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 13:20:24 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B4LKNAk020811; Sat, 4 Dec 2021 13:20:23 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 13:20:23 -0800 From: Steve Kargl To: Hans Petter Selasky Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211204212023.GA20729@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <46162af1-b63f-be10-ebdf-cd328dcfb6e2@selasky.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46162af1-b63f-be10-ebdf-cd328dcfb6e2@selasky.org> X-Rspamd-Queue-Id: 4J62fK6xnNz3jdQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 08:40:56PM +0100, Hans Petter Selasky wrote: > On 12/4/21 19:53, Steve Kargl wrote: > > What to do about tgammal? (trim some history) > > > > Interval | Max ULP > > -------------------+------------ > > [6,171] | 1340542.2 > > [1.0662,6] | 14293.3 > > [1.01e-17,1.0661] | 3116.1 > > [-1.9999,-1.0001] | 15330369.3 > > -------------------+------------ > > > > Well, I finally have gotten around to removing theraven@'s last kludge > > for FreeBSD on systems that support ld80. This is done with a straight > > forward modification of the msun/bsdsrc code. The limitation on > > domain is removed and the accuracy substantially improved. > > > > Interval | Max ULP > > -------------------+---------- > > [6,1755] | 8.457 > > [1.0662,6] | 11.710 > > [1.01e-17,1.0661] | 11.689 > > [-1.9999,-1.0001] | 11.871 > > -------------------+---------- > > > > My modifications leverage the fact that tgamma(x) (ie., double function) > > uses extend arithmetic to do the computations (approximately 85 bits of > > precision). To get the Max ULP below 1 (the desired upper limit), a few > > minimax polynomials need to be determined and the mystery around a few > > magic numbers need to be unraveled. > > > > Extending what I have done to an ld128 implementation requires much > > more effort than I have time and energy to pursue. Someone with > > interest in floating point math on ld128 system can provide an > > implementation. > > > > So, is anyone interested in seeing a massive patch? > > > > Hi, > > Do you need a implementation of tgamma() which is 100% correct, or a > so-called speed-hack version of tgamma() which is almost correct? > > I've looked a bit into libm in FreeBSD and I see some functions are > implemented so that they execute quickly, instead of producing exact > results. Is this true? > I'm afraid that I don't fully understand your questions. The ULP, listed above, were computed by comparing the libm tgammal(x) against a tgammal(x) computed with MPFR. The MPFR result was configured to have 256 bits of precision. In other words, MPFR is assumed to be exact for the comparison between a 64-bit tgammal(x) and a 256-bit mpfr_gamma() function. There is no speed hack with mpfr_gamma(). % time ./tlibm_lmath -l -s 0 -x 6 -X 1755 -n 100000 tgamma Interval tested for tgammal: [6,1755] 100000 calls, 0.042575 secs, 0.42575 usecs/call count: 100000 xmu = LD80C(0xae3587b6f275c42c, 4, 2.17761377613776137760e+01L), libmu = LD80C(0xb296591784078768, 64, 2.57371418855839536160e+19L), mpfru = LD80C(0xb296591784078760, 64, 2.57371418855839536000e+19L), ULP = 8.28349 6.04 real 6.02 user 0.01 sys My test program shows 100000 libm tgammal(x) calls took about 0.04 seconds while the program takes 6 seconds to finish. Most of that time is dominated by MPFR. In general, floating point arithmetic, where a finite number is the result, is inexact. The basic binary operators, +x-/*, are specified by IEEE 754 to have an error no larger that 0.5 ULP. The mantra that I follow (and know bde followed) is to try to optimize libm functions to give the most accurate result as fast as possible. -- Steve From nobody Sat Dec 4 22:03:27 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 06A731899D53 for ; Sat, 4 Dec 2021 22:03:35 +0000 (UTC) (envelope-from grog@lemis.com) Received: from lax.lemis.com (www.lemis.com [45.32.70.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4J63c669Xsz3rbQ for ; Sat, 4 Dec 2021 22:03:34 +0000 (UTC) (envelope-from grog@lemis.com) Received: from eureka.lemis.com (121-200-11-253.79c80b.mel.nbn.aussiebb.net [121.200.11.253]) by lax.lemis.com (Postfix) with ESMTP id 578EE28034; Sat, 4 Dec 2021 22:03:28 +0000 (UTC) Received: by eureka.lemis.com (Postfix, from userid 1004) id AEAAE2635BF; Sun, 5 Dec 2021 09:03:27 +1100 (AEDT) Date: Sun, 5 Dec 2021 01:03:27 +0300 From: Greg 'groggy' Lehey To: Derek Schrock Cc: =?iso-8859-1?Q?=D6zkan?= KIRIK , freebsd-hackers@freebsd.org Subject: Re: zoneinfo problem Message-ID: <20211204220327.GA50507@eureka.lemis.com> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: Organization: The FreeBSD Project Phone: +61-3-5309-0418 Mobile: +61-490-494-038. Use only as instructed. WWW-Home-Page: https://www.FreeBSD X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 User-Agent: Mutt/1.6.1 (2016-04-27) X-Rspamd-Queue-Id: 4J63c669Xsz3rbQ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Saturday, 4 December 2021 at 3:58:24 -0500, Derek Schrock wrote: > On Sat, Dec 04, 2021 at 01:59:10AM EST, =D6zkan KIRIK wrote: >> # ln -s /usr/share/zoneinfo/Etc/GMT+3 /etc/localtime >> # date >> Sat Dec 4 03:48:50 -03 2021 >> >> Above, I want to set the timezone to GMT+3 but date command shows as GMT= -3 > > This is expected. > > https://github.com/eggert/tz/blob/2018g/etcetera#L38-L44 To quote that page, which is also in the sources as /usr/src/contrib/tzdata/etcetera: # Be consistent with POSIX TZ settings in the Zone names, # even though this is the opposite of what many people expect. # POSIX has positive signs west of Greenwich, but many people expect # positive signs east of Greenwich. For example, TZ=3D'Etc/GMT+4' uses # the abbreviation "-04" and corresponds to 4 hours behind UT # (i.e. west of Greenwich) even though many people would expect it to # mean 4 hours ahead of UT (i.e. east of Greenwich). I'd be more inclined to say "this is intentional" rather than "this is expected". I certainly didn't expect it. It's clearly a carry-over =66rom the old System V nonsense that made its way into POSIX. All the more reason to avoid the "GMT" offsets (GMT is no longer used in time zone calculations). Thanks for pointing this out. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmGr5a8ACgkQIubykFB6QiNdHwCeP8TGTQV2nz5wpp26pnpj8x86 9FAAmwfeedez8TrTbIj0zXivhj8dQSUK =6XYZ -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From nobody Sat Dec 4 23:48:13 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F8F018376BB; Sat, 4 Dec 2021 23:48:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J65ww1s86z4bpG; Sat, 4 Dec 2021 23:48:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:71c3:4809:ece6:78d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 99C4429C51; Sat, 4 Dec 2021 23:48:15 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211204185352.GA20452@troutmask.apl.washington.edu> Date: Sat, 4 Dec 2021 23:48:13 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1638661696; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EOJnd4kaEMSBsY6MMdVcF6V6+pboRU59PQWAeaASS1E=; b=lkk3tSkrLy9SApY8HZMoYDzx+RS0RVw23KZkfsaEG/FazxdJu02OPgOiIDU01LCiBQaq0f ErYPc6F2bBT8echHKa3/xe+9ibs1sJN3Jj9VaBcy17POW1lf1huBM3jW3cxW+ftZVz7j4d R0Q9QfrMoGaPKVtXv3eay+60/QJwy78wuL1CJZGr9ZIkTymJRJ/Rb6Cc2F96TMPm3KzXyG zrFeCEtJF2KVx+9eIfu0BfFTVrBTJBNHsEJF8csUznhEO/uQx5q0tqcTfrGmEEwuop37pO LGvwKe63aJd8Auwliu6ohaTe359bDboiN1Sx3AdGTLM5/DFJNMgY5SFX6rkhUw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1638661696; a=rsa-sha256; cv=none; b=Xx4u81CQpiGFfFiRoPomk3sEqgig8UHKtLTURK/+APVZpksy4//DzVUkjSUmuaP7PgXrP6 XJ5WCLwWfF/qXbz/mUdTIGlGXMWUg0NEwQB+YMjHluyjQuJ0E5TFEBWxAOs9KOdwuH+xzg lU/P3B6BK+94FAHUMJDfAuZ+8zo7hrVtljPrqP4i4x+au8YuqR24YNr1ivtIIgxxLCcc+f PkZ2lO1tRQ7SfIJKF+n6mLjavqm4U835svTt2PkPRQTP2dN0VSmDulqxSRzgNO3rkYuJ3E Wv/dJtd6tE26oWsXTPWyfMZYcX/hcbMmW/y7kGofMWyoU8JTM8eUEPuRw+3Cqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4 Dec 2021, at 18:53, Steve Kargl = wrote: >=20 >=20 > So, is anyone interested in seeing a massive patch? Me, please! M -- Mark R V Murray --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmGr/j0ACgkQQlsJDh9C UqCCbwf+K6NfE5MfnaD8qPJFdF+w8jIYs+/CqPn0R+2np8KE7uEYAx09MJJ7K6/G iWtVqKw0XfspMF7uBXjpkR1xdSSHzqggqVvhjnkgFEaoynOMkpsIExFCJMFwQpyZ GMKYrBBnz0NwWRuCnWfZ/Xxn2iLsfkA04ut1J4E2qenNzVmDsbTpiHhvpgQ8ztWZ pvlXq1n+ndCEZh5lrhZj320RpCGYBKXuHqYDfb3UNNBGQYElnVGjpGkUR+Slbryk XJfyfU7vb33Ppg5FlnnxuB0XTzi8uWj611Ve3SrYxeZBYHnvmzdx+A8cAdEZ+mJo +t+HC/+mGDxC4itEZ4lMlgP0Ph9gCg== =j6yb -----END PGP SIGNATURE----- --Apple-Mail=_3C2A57F7-D97B-4F72-96C1-F0679D5B40A2-- From nobody Sun Dec 5 00:25:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A8E8C1897537; Sun, 5 Dec 2021 00:26:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J66mT3Rr8z4hRv; Sun, 5 Dec 2021 00:26:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1B50PxLL021884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 16:25:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1B50Px8x021883; Sat, 4 Dec 2021 16:25:59 -0800 (PST) (envelope-from sgk) Date: Sat, 4 Dec 2021 16:25:59 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211205002559.GA21850@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4J66mT3Rr8z4hRv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > It is ld80 only. ld128 is still broken. I'll clean things up and create a diff over the next few days. The patch will disconnect imprecise.c from the build. So, if you like what you see and pursue committing the patch(es), one pre-requisite will be to copy src/imprecise.c to ld128/b_tgammal.c. In the good old day, one would use % svn copy src/imprecise.c ld128/b_tgammal.c % svn delete src/imprecise.c or % svn move src/imprecise.c ld128/b_tgammal.c Don't know (or care) how to do this in a git world. -- Steve From nobody Sun Dec 5 17:53:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD53E18B2C0F for ; Sun, 5 Dec 2021 17:53:32 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4J6Z175j0kz4Zq3 for ; Sun, 5 Dec 2021 17:53:31 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from [192.168.5.3] (c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 1B5HrO8v010887 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 5 Dec 2021 09:53:25 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-73-189-35-76.hsd1.ca.comcast.net [73.189.35.76] claimed to be [192.168.5.3] Message-ID: <656bf089-bcc9-748a-6db2-52f3707e863c@rawbw.com> Date: Sun, 5 Dec 2021 09:53:23 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Is it possible to determine the open file path based on the file descriptor? Content-Language: en-US To: Konstantin Belousov , Mateusz Guzik Cc: Freebsd hackers list References: <21b0280d-c290-f27f-98a9-0c2242380718@rawbw.com> <5a00f93e-21a1-47ab-6e8e-15d24840c525@rawbw.com> <20200708175300.GA2866@kib.kiev.ua> From: Yuri In-Reply-To: <20200708175300.GA2866@kib.kiev.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J6Z175j0kz4Zq3 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=rawbw.com; spf=pass (mx1.freebsd.org: domain of yuri@rawbw.com designates 198.144.192.42 as permitted sender) smtp.mailfrom=yuri@rawbw.com X-Spamd-Result: default: False [1.95 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:198.144.192.0/24]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.343]; DMARC_POLICY_ALLOW(-0.50)[rawbw.com,none]; NEURAL_SPAM_LONG(0.99)[0.991]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[73.189.35.76:received] X-ThisMailContainsUnwantedMimeParts: N On 7/8/20 10:53, Konstantin Belousov wrote: > I think an immediately useful addition would be a sysctl or fcntl that > return struct kinfo_file for single file descriptor. There is another project that resolves file descriptors to file names: https://github.com/PixarAnimationStudios/USD/blob/release/pxr/base/arch/fileSystem.cpp#L470 Maybe it makes sense to provide a sysctl or fcntl that would return a list of paths for a given file descriptor? I opened the PR for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260241 Yuri From nobody Sun Dec 5 18:54:36 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 308DF18C034E for ; Sun, 5 Dec 2021 18:54:46 +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 4J6bMn5mSHz4lQ7 for ; Sun, 5 Dec 2021 18:54:45 +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 1B5IsbkX018356 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 5 Dec 2021 20:54:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1B5IsbkX018356 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1B5IsaIv018354; Sun, 5 Dec 2021 20:54:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Dec 2021 20:54:36 +0200 From: Konstantin Belousov To: Yuri Cc: Mateusz Guzik , Freebsd hackers list Subject: Re: Is it possible to determine the open file path based on the file descriptor? Message-ID: References: <21b0280d-c290-f27f-98a9-0c2242380718@rawbw.com> <5a00f93e-21a1-47ab-6e8e-15d24840c525@rawbw.com> <20200708175300.GA2866@kib.kiev.ua> <656bf089-bcc9-748a-6db2-52f3707e863c@rawbw.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <656bf089-bcc9-748a-6db2-52f3707e863c@rawbw.com> 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: 4J6bMn5mSHz4lQ7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Dec 05, 2021 at 09:53:23AM -0800, Yuri wrote: > On 7/8/20 10:53, Konstantin Belousov wrote: > > I think an immediately useful addition would be a sysctl or fcntl that > > return struct kinfo_file for single file descriptor. > > > There is another project that resolves file descriptors to file names: > > https://github.com/PixarAnimationStudios/USD/blob/release/pxr/base/arch/fileSystem.cpp#L470 > > > Maybe it makes sense to provide a sysctl or fcntl that would return a list > of paths for a given file descriptor? > > I opened the PR for this: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260241 > https://reviews.freebsd.org/D33277 From nobody Mon Dec 6 07:13:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2CAD618BDE81 for ; Mon, 6 Dec 2021 07:14:34 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J6vnP37n4z3sb7 for ; Mon, 6 Dec 2021 07:14:33 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f175.google.com with SMTP id v15so19234702ljc.0 for ; Sun, 05 Dec 2021 23:14:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kc/KK+n6V5CCguIyLLGQ9XYKE0x8TAe60XGl15oPjkM=; b=nNCpcC5u+wN4gjPiRmtpPkH2eNOclx1RqGU+l9pWsdWwYETvdhVSUKar8zJw4aRrCv MSf/LlowNy/jH+qDWbr51AC3FF7ygDLJfxpTFDYm+azzcTXjqp9H4Jsiu4zdymc5OVzx BcVuxtvEe1/z02rMtmZ6ButceO45gd83LZD+nAQHt2KbcCU/Dwb2Vuyn50UY3T+7/Yv8 +SmqwxgKuuoyp8mkxv4xie3S7fYNnXkouXLGpQPA5BRUBKKgwXSDiW0pcB0ISWkOJFQE 2EoTZsJOkfvGtlGQzkZdyhURuNozPapxGy1ZHvusSxW4KPCvP90AC/rP3LqQs5vp/hOg fkPg== X-Gm-Message-State: AOAM530TI1CCuu+uOUr0xW7IvPzhX5asrOaX0Heq5e+oNRNxh4EVY1vB 4+GSOt3nuJX/2VRIPYCzXnH7XP6t2ERp3A== X-Google-Smtp-Source: ABdhPJwiiDLzKOV+Ht87y/0gjGNwN0CkP3Tk93gEz8qWSiXhMWkpYsmIKXrZAVkT4QAQ2Js5ukK9YQ== X-Received: by 2002:a2e:b5d2:: with SMTP id g18mr34185595ljn.354.1638774865484; Sun, 05 Dec 2021 23:14:25 -0800 (PST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com. [209.85.208.179]) by smtp.gmail.com with ESMTPSA id a7sm1273438lfi.149.2021.12.05.23.14.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Dec 2021 23:14:25 -0800 (PST) Received: by mail-lj1-f179.google.com with SMTP id m12so19114220ljj.6 for ; Sun, 05 Dec 2021 23:14:25 -0800 (PST) X-Received: by 2002:a2e:bc1c:: with SMTP id b28mr35080816ljf.500.1638774865088; Sun, 05 Dec 2021 23:14:25 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Gleb Popov Date: Mon, 6 Dec 2021 10:13:59 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: nmount(2) returns undocumented EDEADLK To: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000b355c005d2750105" X-Rspamd-Queue-Id: 4J6vnP37n4z3sb7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.985]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.175:from,209.85.208.179:received]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.175:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000b355c005d2750105 Content-Type: text/plain; charset="UTF-8" Hey hackers. I have a little program that calls the nmount(2) function in the following way: - First it mounts nullfs with fstype="nullfs", from="/src" and fspath="/dst". This works fine. - Next it tries to remount it as readonly by adding MNT_UPDATE and MNT_RDONLY to the nmount(2) call. This call fails with errno=11 (EDEADLK) for some reason. The relevant part of kdump: 19909 coolmount CALL nmount(0x801610380,0x6,0<>0) 19909 coolmount NAMI "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" 19909 coolmount NAMI "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" 19909 coolmount NAMI "/var/db/collaboraonline/systemplate" 19909 coolmount RET nmount -1 errno 11 Resource deadlock avoided Does anyone have an idea what's wrong with this? I can try coming up with minimal repro if needed. Thanks in advance. --000000000000b355c005d2750105-- From nobody Mon Dec 6 08:23:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5292B18C98CC for ; Mon, 6 Dec 2021 08:23:34 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J6xK15k0tz4VTb for ; Mon, 6 Dec 2021 08:23:33 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32f.google.com with SMTP id p3-20020a05600c1d8300b003334fab53afso9768119wms.3 for ; Mon, 06 Dec 2021 00:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=Ij4PRJnUNygQ5VcJKBigCfMgGMqJibcLVb7B8GzePJI=; b=Dmc8d8TKXnrcLBL1bfRTmlWpdjzanHuOECD8gHodCxLGHOUAa+p2+lpL+Cl/1XCG1C DJTAXKQkwoZN1CClusHoJjzf0ZmTGABqWTY99PRSSv5LpqhM2HK2fyt95zMChlZDeoX3 +4hU8BwRGghJNB/mhabWw+UB4WCUxDIBCBxUBOweVRD27Hjstgr0BrIT+LJkDYkZz7Td DZpXjR/hh1HxZRVQOwPrzukx6cPCk6U7hSVjyLIZYnWk3hxv46iK9NA7hVbwTpOS5/2u 92FOOM1Jqe4VLzZUiunvKa5m8KEYKd9a8JWJBenKnCUm9rdGkSve5nHRuYgE5F5eyxTE xX/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=Ij4PRJnUNygQ5VcJKBigCfMgGMqJibcLVb7B8GzePJI=; b=Ox118PSpyZX0KDjA9NqCMcJeJdwzQqlnczqzze/DF9CCke/0UyWaEbF3rX0mEA6j68 YZR8vToUd9M+0ZpsLzitW4OsuvEmLjaWYcKCbUO0CNNyxCJ59buXZxCJMoZKcqYfQRrw sRy+Fv8c3djMKnY+V4fEHFPdxCFCPhVfLILOuG9mIufZM1VDOdoStwDYE7ccCiISvFHA 7bXh7uJ7HhLXR4YB/Gy+KCASDcSplrHZTdIEKsGtwyC2s6gTFLzmMIG1NENzTX/Pv/Qz lL6i+52yVHZabF+U69K5dEcok2mmbCT4nYReCvCE1oCXAq5k39ENwpWblErWSfOpelnk X+hQ== X-Gm-Message-State: AOAM5308I89opDt2xy7/eShNIpMXxwYhwXOfhPi8uptouypvK5grMetn 9nlBWDt9EVFErcnd+8zoJATCwgwFaIQQRGdO X-Google-Smtp-Source: ABdhPJwZ+tpOXMPsQgBhiI62CNNXxdUmLMyYopAtAiBobNwzRR+jcLD299g46hE+nxQAHGsAIRY/9A== X-Received: by 2002:a1c:a7c3:: with SMTP id q186mr38240024wme.20.1638779012852; Mon, 06 Dec 2021 00:23:32 -0800 (PST) Received: from [137.202.253.121] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id e18sm10538239wrs.48.2021.12.06.00.23.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Dec 2021 00:23:32 -0800 (PST) Message-ID: Date: Mon, 6 Dec 2021 09:23:31 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Is it possible to determine the open file path based on the file descriptor? To: freebsd-hackers@freebsd.org References: <21b0280d-c290-f27f-98a9-0c2242380718@rawbw.com> <5a00f93e-21a1-47ab-6e8e-15d24840c525@rawbw.com> <20200708175300.GA2866@kib.kiev.ua> <656bf089-bcc9-748a-6db2-52f3707e863c@rawbw.com> From: "Floyd, Paul" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4J6xK15k0tz4VTb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Dmc8d8TK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2021-12-05 19:54, Konstantin Belousov wrote: > On Sun, Dec 05, 2021 at 09:53:23AM -0800, Yuri wrote: >> On 7/8/20 10:53, Konstantin Belousov wrote: >>> I think an immediately useful addition would be a sysctl or fcntl that >>> return struct kinfo_file for single file descriptor. [snip] >>> https://reviews.freebsd.org/D33277 That looks really nice. It's possible to do this with sysctl CTL_KERN / VKI_KERN_PROC / KERN_PROC_FILEDESC but that gets info for all file descriptors, meaning that you then have to search for the one that you want. https://github.com/paulfloyd/freebsd_valgrind/blob/freebsd/coregrind/m_libcfile.c#L121 (I'm not the author of that bit of code). A+ Paul From nobody Mon Dec 6 09:53:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 318B418D61E8 for ; Mon, 6 Dec 2021 09:54:00 +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 4J6zKM6T0pz4fH8; Mon, 6 Dec 2021 09:53:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1B69rqVE041383 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 6 Dec 2021 11:53:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1B69rqVE041383 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1B69rque041382; Mon, 6 Dec 2021 11:53:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Dec 2021 11:53:52 +0200 From: Konstantin Belousov To: Gleb Popov Cc: freebsd-hackers Subject: Re: nmount(2) returns undocumented EDEADLK Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4J6zKM6T0pz4fH8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 06, 2021 at 10:13:59AM +0300, Gleb Popov wrote: > Hey hackers. > > I have a little program that calls the nmount(2) function in the following > way: > > - First it mounts nullfs with fstype="nullfs", from="/src" and > fspath="/dst". This works fine. > - Next it tries to remount it as readonly by adding MNT_UPDATE and > MNT_RDONLY to the nmount(2) call. This call fails with errno=11 (EDEADLK) > for some reason. > > The relevant part of kdump: > > 19909 coolmount CALL nmount(0x801610380,0x6,0<>0) > 19909 coolmount NAMI > "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" > 19909 coolmount NAMI > "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" > 19909 coolmount NAMI "/var/db/collaboraonline/systemplate" > 19909 coolmount RET nmount -1 errno 11 Resource deadlock avoided > > Does anyone have an idea what's wrong with this? I can try coming up with > minimal repro if needed. First, nullfs does not support remounting to ro/rw. But this is not likely an issue with your code, because you do get EDEADLK. EDEADLK means that you are trying to mount nullfs on itself, see the check at line 150 of the file sys/fs/nullfs/null_vfsops.c. Most likely you did not properly pass MNT_UPDATE, but then even if you did, it would not help because, as noted, nullfs does not support remount to ro. From nobody Mon Dec 6 14:38:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 93FE018B27DA for ; Mon, 6 Dec 2021 14:39:33 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J75fs3Xqwz3rGs for ; Mon, 6 Dec 2021 14:39:33 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf1-f45.google.com with SMTP id z21so3752398lfu.8 for ; Mon, 06 Dec 2021 06:39:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bfVDd/iLIq1s0DcmTLBKLwrQRw6t1A2YyOzUlTMfPvQ=; b=P84ogxfXvT/sKHKKl/HSenqK/GFXXiq1tOHZ3/+flaE9brIeMYcnX0aPoBHPBoHfvP hYO8duZ1LOKRsnBqN1X6kavjGZWi9SBJ0jqH6LctRwTjqpgj+2753pzSoqFrXlGzz+uU mg26CvpF63/AXkP5zDRTtB1Q0CcpcTFgQBMKetZltXuf2p2F4kxsArXC5GdkRN8Ggyif gdT5gp4flOCt7a2TnQwQ1/cJAanCq5gcSAhAkn5GKoIu4vQsmNg1YK0DSsDY9Av8z+hk U+jnXruGCM9QFJ4xo4ugGWLCuyU7nBlpuF5lyeCagWNtwaND4XTjFtHuBfYXfL2ADPiH lSjw== X-Gm-Message-State: AOAM533YM3fIWWPriEicYDhzPEF/dJxq8F3InUISlGtxbpNeNtnNtKNb IBwQDDReBEMjPKDUr7JLS+rx7LybeDkt+A== X-Google-Smtp-Source: ABdhPJxxrGQvJ7pfWd83cIXML7peFcWSxKyp0kEEguePFKgisMeVqDzTosaZPcHJ/9gEd9AnbKZG7g== X-Received: by 2002:a05:6512:344d:: with SMTP id j13mr37697534lfr.347.1638801566072; Mon, 06 Dec 2021 06:39:26 -0800 (PST) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com. [209.85.208.171]) by smtp.gmail.com with ESMTPSA id z19sm1368790lfd.68.2021.12.06.06.39.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Dec 2021 06:39:25 -0800 (PST) Received: by mail-lj1-f171.google.com with SMTP id k2so21417423lji.4 for ; Mon, 06 Dec 2021 06:39:25 -0800 (PST) X-Received: by 2002:a2e:a365:: with SMTP id i5mr35876522ljn.335.1638801565583; Mon, 06 Dec 2021 06:39:25 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Mon, 6 Dec 2021 17:38:59 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: nmount(2) returns undocumented EDEADLK To: Konstantin Belousov Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000002c8f4405d27b39f1" X-Rspamd-Queue-Id: 4J75fs3Xqwz3rGs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000002c8f4405d27b39f1 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 6, 2021 at 12:54 PM Konstantin Belousov wrote: > On Mon, Dec 06, 2021 at 10:13:59AM +0300, Gleb Popov wrote: > > Hey hackers. > > > > I have a little program that calls the nmount(2) function in the > following > > way: > > > > - First it mounts nullfs with fstype="nullfs", from="/src" and > > fspath="/dst". This works fine. > > - Next it tries to remount it as readonly by adding MNT_UPDATE and > > MNT_RDONLY to the nmount(2) call. This call fails with errno=11 (EDEADLK) > > for some reason. > > > > The relevant part of kdump: > > > > 19909 coolmount CALL nmount(0x801610380,0x6,0<>0) > > 19909 coolmount NAMI > > "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" > > 19909 coolmount NAMI > > "/var/db/collaboraonline/child-roots/hQN4KQVIpWNA7Pic" > > 19909 coolmount NAMI "/var/db/collaboraonline/systemplate" > > 19909 coolmount RET nmount -1 errno 11 Resource deadlock avoided > > > > Does anyone have an idea what's wrong with this? I can try coming up with > > minimal repro if needed. > > First, nullfs does not support remounting to ro/rw. But this is not likely > an issue with your code, because you do get EDEADLK. EDEADLK means that > you are trying to mount nullfs on itself, see the check at line 150 of the > file sys/fs/nullfs/null_vfsops.c. > > Most likely you did not properly pass MNT_UPDATE, but then even if you did, > it would not help because, as noted, nullfs does not support remount to ro. > Indeed, I made a mistake in the code so the flags parameter was always 0. After fixing it I'm now getting EOPNOTSUPP. If remounting as ro is not supported, what are my options? Is there any semantic difference between remounting with ro and unmounting/mounting again? --0000000000002c8f4405d27b39f1-- From eugen@grosbein.net Mon Dec 6 15:01:09 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D7AFE18B8817 for ; Mon, 6 Dec 2021 15:01:26 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J76855r01z4RKW for ; Mon, 6 Dec 2021 15:01:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1B6F1HOP008398 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 6 Dec 2021 15:01:18 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1B6F1G3f085158 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 6 Dec 2021 22:01:16 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: nmount(2) returns undocumented EDEADLK To: freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Mon, 6 Dec 2021 22:01:09 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J76855r01z4RKW X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.73 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.84)[0.839]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.99)[0.987]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.12.2021 21:38, Gleb Popov wrote: > > Indeed, I made a mistake in the code so the flags parameter was always 0. > After fixing it I'm now getting EOPNOTSUPP. > If remounting as ro is not supported, what are my options? Improve nullfs to implement such remounting :-) > Is there any > semantic difference between remounting with ro and unmounting/mounting > again? You will not be able to perform not-forced unmount in case of open files and maybe even current directory of a process pointing there. From nobody Wed Dec 8 06:43:41 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4776018C634F for ; Wed, 8 Dec 2021 06:44:17 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J871X2w19z3rXx for ; Wed, 8 Dec 2021 06:44:16 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf1-f49.google.com with SMTP id z7so3511850lfi.11 for ; Tue, 07 Dec 2021 22:44:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tD5+BFkNnjfXCeeMYk4TXX/K7d0pHeeGqCbx9YcTTrw=; b=x4l5xsEzsIbsm0HBzWfgYx74vZbXYnTdZwrLDmXn/o1AU6ExYpsp3AeeYb1Wafpkno R+jYeGchbUM+kvDywgAjbYHFvBKfdsC9OF7wi7fu1x7v4HRdQEZCL2rfRNdw3snpK5dC aE53CrPJnXnNRjGdCXzx7tMv+nYJ2LsFlSo3iHflKR2DA3QO+Ujb8JJzdiS1nKJ+NTLH QEjKEL/LmLC9/mJA9BtBY1gRfcSscU+4ZyDbBUohxeFIjYOg6QBxBPUTh9ewT2TL7VRZ r4cLtVXQmJVyyeBmnlgH3bHxUzG8G3nJhyT0ZlnhOxC4zZSYRwJzR6gq1MtX3WVY2Hx/ +WFw== X-Gm-Message-State: AOAM530er8Re1GA+J+2vmGLIeA2eBs9dAZZ15nN/ezqWoM8whvZnf7a8 CW3qZ6l9n+UkNQM2U+yqgQIJHO1aN4ff9A== X-Google-Smtp-Source: ABdhPJz7JzvrWzIBjQiDAQFC8eTl2my/s/RKH4pV+qVOk8N2d9XsDQ2IWFyWk983Xj+OJfK9gHKuCA== X-Received: by 2002:a05:6512:aca:: with SMTP id n10mr46834365lfu.265.1638945848940; Tue, 07 Dec 2021 22:44:08 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com. [209.85.167.54]) by smtp.gmail.com with ESMTPSA id f39sm160587lfv.221.2021.12.07.22.44.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Dec 2021 22:44:08 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id bi37so3586273lfb.5 for ; Tue, 07 Dec 2021 22:44:08 -0800 (PST) X-Received: by 2002:a05:6512:308b:: with SMTP id z11mr44605166lfd.177.1638945847849; Tue, 07 Dec 2021 22:44:07 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Gleb Popov Date: Wed, 8 Dec 2021 09:43:41 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: What to use in place of abstract unix sockets? To: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000001139f805d29cd169" X-Rspamd-Queue-Id: 4J871X2w19z3rXx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-0.05 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.946]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.49:from,209.85.167.54:received]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.49:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000001139f805d29cd169 Content-Type: text/plain; charset="UTF-8" Hello hackers. I'm porting a software that does the following things on Linux: 1. Binds an abstract UDS (the socket name starts with '\0') 2. Launches a "client" process. 3. "Client" uses chroot() to constrain itself in a sort of jail. 4. "Client" connects to the abstract UDS. >From what I can tell, this works because abstract UDS's do not use the filesystem namespace, which is why "client" can connect out of the chroot'ed environment. What can I do to make this software work for FreeBSD? Simply using regular UDS instead of abstract ones doesn't work for obvious reasons - the "client" can't find the socket file. Thanks in advance. --0000000000001139f805d29cd169-- From eugen@grosbein.net Wed Dec 8 07:50:08 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1851D18D3277 for ; Wed, 8 Dec 2021 07:50:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J88Tv62Zwz4TXB; Wed, 8 Dec 2021 07:50:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1B87oIER025603 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Dec 2021 07:50:19 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: arrowd@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1B87oGRO002344 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 8 Dec 2021 14:50:16 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: What to use in place of abstract unix sockets? To: Gleb Popov , freebsd-hackers References: From: Eugene Grosbein Message-ID: <9ca80eac-e24a-802d-fae0-6a2146c4a825@grosbein.net> Date: Wed, 8 Dec 2021 14:50:08 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4J88Tv62Zwz4TXB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 08.12.2021 13:43, Gleb Popov wrote: > Hello hackers. > > I'm porting a software that does the following things on Linux: > > 1. Binds an abstract UDS (the socket name starts with '\0') > 2. Launches a "client" process. > 3. "Client" uses chroot() to constrain itself in a sort of jail. > 4. "Client" connects to the abstract UDS. > >>>From what I can tell, this works because abstract UDS's do not use the > filesystem namespace, which is why "client" can connect out of the > chroot'ed environment. > > What can I do to make this software work for FreeBSD? Simply using regular > UDS instead of abstract ones doesn't work for obvious reasons - the > "client" can't find the socket file. > > Thanks in advance. If they are parent/child, you could try using socketpair(). From nobody Thu Dec 9 00:08:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CA5818DD7A9 for ; Thu, 9 Dec 2021 00:08:49 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J8ZBm4tpbz4mLq for ; Thu, 9 Dec 2021 00:08:48 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1B908PsX019621 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 9 Dec 2021 10:38:25 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1639008513; bh=grhfshK6apj99dBWNLtEUn05NXK13TyZeovO+HQRbP8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CWSEhEvqplvOXxpz8Cu4SC93GoXVmhFqURcpKeCI6+cwA4aFizLTVz9PshEOdtCWt FnC63U3Cma47BjXy9pEnD0JuSFhoN76gwtnBZqyGZu+wkyLr0RmzPNJ/ftzhXXtOML 3JncU8/EZdMJalukpLNobciqErHM7VGcYuaqbcUQ= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1B908KO2019615 for ; Thu, 9 Dec 2021 10:38:20 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2001:44b8:1d2:8900:ecbb:36a4:68ae:4a5f Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:ecbb:36a4:68ae:4a5f] [2001:44b8:1d2:8900:ecbb:36a4:68ae:4a5f]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1B908JH9019610; Thu, 09 Dec 2021 10:38:20 +1030 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What to use in place of abstract unix sockets? In-Reply-To: Date: Thu, 9 Dec 2021 10:38:19 +1030 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gleb Popov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J8ZBm4tpbz4mLq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via freebsd-hackers X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 8 Dec 2021, at 17:13, Gleb Popov wrote: > I'm porting a software that does the following things on Linux: >=20 > 1. Binds an abstract UDS (the socket name starts with '\0') > 2. Launches a "client" process. > 3. "Client" uses chroot() to constrain itself in a sort of jail. > 4. "Client" connects to the abstract UDS. >=20 > =46rom what I can tell, this works because abstract UDS's do not use = the > filesystem namespace, which is why "client" can connect out of the > chroot'ed environment. >=20 > What can I do to make this software work for FreeBSD? Simply using = regular > UDS instead of abstract ones doesn't work for obvious reasons - the > "client" can't find the socket file. If the parent knows where the child will chroot it could create a unix = domain socket under that directory somewhere. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Dec 9 16:46:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 31D9318D5561 for ; Thu, 9 Dec 2021 16:47:00 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J90LW2BVSz58nq for ; Thu, 9 Dec 2021 16:46:59 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: by mail-qv1-f47.google.com with SMTP id p3so5591446qvj.9 for ; Thu, 09 Dec 2021 08:46:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=bIa7HmazBJ4bvCv10HZSP1oo9zba0nvtMNAP4Lxo4uI=; b=X75LPRu9GzIscr9IMlaS5fRPdUcEFKt7q8NjvWISLdoHDBz+Azv6pTWCsUQlFg7iE6 nqJBN/4Yd8TOcOOBjmmRpLlitTLNQQ8CTZEzryezrmzkMuEFf48K/Os5YRZFktxDMXG6 4IyboaugnEmPGNu7Y+C5ydKuAJyHBcr4WPSsEPi7SEUijqWIFOJ2PVPNP7V8KsiliiwC eod5jR5/nxliqSr3HyeF/5lnSqXio+m9f8qIdaX2pK7rL9hont12cGdB1k+MH/j/l2+j MUv9piqxD4F/FAxO6XO1HzNLSsctbEOJiDp31bOO4r2zakiLx2Mh1gDIABzS+aR7GbAr h/nQ== X-Gm-Message-State: AOAM533/sBhkdgDE5nK+5l518O8i2Q2D2KsQzyyh4ThB3srYAfQ7rbpA wFMHEXroSigccJ+Z1zdIG4ywAAiOPGNcLA== X-Google-Smtp-Source: ABdhPJzWdUdWFS9NF2Qx82QgFXfSt4YZ1OmzhCcCYeRNYIf7PJcouH24FgH+cmfQLrb2RGTT5xU3zw== X-Received: by 2002:a05:6214:cc9:: with SMTP id 9mr19079785qvx.86.1639068413234; Thu, 09 Dec 2021 08:46:53 -0800 (PST) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-249-199.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.249.199]) by smtp.gmail.com with ESMTPSA id h13sm254533qtk.25.2021.12.09.08.46.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 09 Dec 2021 08:46:52 -0800 (PST) From: Joseph Mingrone To: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> Date: Thu, 09 Dec 2021 12:46:52 -0400 In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> (Joseph Mingrone's message of "Tue, 23 Nov 2021 18:41:01 -0400") Message-ID: <861r2l914z.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4J90LW2BVSz58nq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jrm@ftfl.ca designates 209.85.219.47 as permitted sender) smtp.mailfrom=jrm@ftfl.ca X-Spamd-Result: default: False [-0.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[jrm]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.99)[0.993]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.47:from]; RECEIVED_SPAMHAUS_PBL(0.00)[156.34.249.199:received]; FORGED_SENDER(0.30)[jrm@FreeBSD.org,jrm@ftfl.ca]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.219.47:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[jrm@FreeBSD.org,jrm@ftfl.ca]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Thank you to everyone who took the time to contribute project ideas. Here is a summary of what was submitted. If your idea was missed or misrepresented, feel free to add or edit it. https://wiki.freebsd.org/2021FoundationCFI Joe From nobody Thu Dec 9 18:25:53 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE80B18EB5F7 for ; Thu, 9 Dec 2021 18:26:10 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J92Xy5CT0z3nhR; Thu, 9 Dec 2021 18:26:10 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id n6so12475265uak.1; Thu, 09 Dec 2021 10:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/gwLu2p8tHJobmTgmpL6ezXF/2G85Sb7iwMqhrzEngw=; b=V3DvPM0tMRpAVsXYTmR3LVvkqqLO/KDsqQzWxQyx2urMFeprXd8QN24sKTau9MmA8c tSChvsC//EdqJVkrf5OGFta71+/HGbL4TA/DLOEmfL0zD34Co6dQG3PorG1TMx6ZTUw2 GF22yTCvLK5H1i9WwKDcFwUPnIxPtOTnJ/mzWjiJltaLn3Wo0P/8oQRejBNMvcLeNYBG b0r6MWPH9EdwWqGdhUddrMBDGVXfJ3NmXhrkxMUzhbHVdNfKuAcC7WZi55fVV4waPpBv XxJjGKtKiTV4gZYpf/ypYGTclPBpvgydHpTyMGvyxdo9q+VK2MzysXm6xX2wn3ju3XQx nRNQ== 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=/gwLu2p8tHJobmTgmpL6ezXF/2G85Sb7iwMqhrzEngw=; b=TKuZe/ohX1T8+re/jqsE+RGIqXAdhWvudyGUDXJOS+b3AEwgZW1WWS6Q1vJxrlHfUF PplitFqWYep0ztdx0N5C9MMvU2BVGJgIeBG1leZ7XGRCXLdIttzW9DXrug9E0qn0gr7L ASyb6cPyCIN3cMdZQeOMO1Jz6Rr8aCce+7G93Xn8/hUQf9PMJSDD0HigMWK4e48WnUbS EAx0hNIknzl6W6YSEPxnFVrl8cfAgemubimYs6EAQHmCBLXvVbYhex5Ws6QF6VU2pdOM TGcYIClIroLeDErYmg23EWVLIniOe11NIxHOaKQ4gmpB5fBXHGk9IdtyHyPAPnX/sE5f XYNA== X-Gm-Message-State: AOAM530LBV1eRQnstNIgVR+3OJgXSAy8l27Ld6kBhk+k6Rif6sJgo87S 7xqQY+TJqsV2J4FH38wQdIHPVu5el5kw48SCZuQ8N8u+ X-Google-Smtp-Source: ABdhPJxDWmz4xlO75qr/n9qRqpwTimWtE2Nw5VdX8cGrbLd1/XFsi/HcQd9J37k1O8Dc5O8q3oMPZBvVBvuqCs06GBE= X-Received: by 2002:ab0:3d0d:: with SMTP id f13mr21678874uax.48.1639074364131; Thu, 09 Dec 2021 10:26:04 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> In-Reply-To: <861r2l914z.fsf@phe.ftfl.ca> From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 9 Dec 2021 21:25:53 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4J92Xy5CT0z3nhR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N bsnmpd: monitoring jails (event with different vnet) resources like interfaces, cpu usage etc. I don't have an account to modify wiki. thanks On Thu, Dec 9, 2021 at 7:47 PM Joseph Mingrone wrote: > > Thank you to everyone who took the time to contribute project ideas. > Here is a summary of what was submitted. If your idea was missed or > misrepresented, feel free to add or edit it. > > https://wiki.freebsd.org/2021FoundationCFI > > Joe > From nobody Thu Dec 9 18:45:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C56F18C1CA6 for ; Thu, 9 Dec 2021 18:45:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J92zW3MpRz3v9m; Thu, 9 Dec 2021 18:45:43 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4353B8D4A215; Thu, 9 Dec 2021 18:45:36 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1D9A9E70846; Thu, 9 Dec 2021 18:45:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ZzsIiSwdiLdm; Thu, 9 Dec 2021 18:45:34 +0000 (UTC) Received: from [169.254.1.48] (unknown [IPv6:fde9:577b:c1a9:4902:116b:449:5763:67c1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E3E88E7082B; Thu, 9 Dec 2021 18:45:33 +0000 (UTC) From: "Bjoern A. Zeeb" To: "=?utf-8?q?=C3=96zkan?= KIRIK" Cc: "Joseph Mingrone" , "FreeBSD Hackers" Subject: Re: Call for Foundation-supported Project Ideas Date: Thu, 09 Dec 2021 18:45:32 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J92zW3MpRz3v9m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 9 Dec 2021, at 18:25, Özkan KIRIK wrote: > bsnmpd: monitoring jails (event with different vnet) resources like > interfaces, cpu usage etc. And I assume that means “from the outside” (host view) and not within a jail just for the jail (“customer view”) — or maybe both? > I don't have an account to modify wiki. thanks > > On Thu, Dec 9, 2021 at 7:47 PM Joseph Mingrone > wrote: >> >> Thank you to everyone who took the time to contribute project ideas. >> Here is a summary of what was submitted. If your idea was missed or >> misrepresented, feel free to add or edit it. >> >> https://wiki.freebsd.org/2021FoundationCFI >> >> Joe >> From nobody Thu Dec 9 18:49:22 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E0FC18C2AE4 for ; Thu, 9 Dec 2021 18:49:34 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J933x6lMDz4QrX; Thu, 9 Dec 2021 18:49:33 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id l24so12596269uak.2; Thu, 09 Dec 2021 10:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tzEK2STWgUXW120hJb6cnbak7dHO3D/W8CZ3rSXNuvM=; b=fhPeU/1hWzqiTMkbOU+R3MUVp6w1IX4Ky7WMYN7oeILm+wK7x45wYJmkb+ZsVlWgfh 1CeqmrtjRrRi3QMZun1nLn4EfgoMr6xMMEcJei1kHcVCCKqccv35WoQxW1Q6BeYvEySn rEoqIo0FmMzuFvKT8t2IaG5eb2YYxvkmemjoyTHQnLaWw2y/DZTtaApQCHBLyq+PeBsP AOUwKWAdg0GUhymAXs2ssPTikMA6/xN7oV6kB9qPGmdhLwWgEQw1Tt9a5PS4PHGLM+Fa BGQf+xeAq7om0YhNdgd4Q8BBa0bEtBTxNyYlRjzNhpctLfDtI/HRW8o0HIq3BkZf4ejJ WDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tzEK2STWgUXW120hJb6cnbak7dHO3D/W8CZ3rSXNuvM=; b=C68Hty7z24CsBdwBc3hXSSYwn7QbToLkzTuoVZxpr1ZU4ELjqKevlSVQ+P07yxlvG6 x+sF0eA0cVpd8NMtGH+fEYgoB8u9R0ljgpUsNdzNK7/kBalocY4mrAIkpDwEOmdtIQ93 LW8gk7z3GToatJStDXZxh9u37MdUN01yHQ1K7L2nuGBLZ59TRc7NeFXFaDvTcEwfZGQO 7VnzMMBUYfsDOrD1/VLziC0gcgmG2Aeetn/R0DTOTZmPsQqVSJ7GKghySvv/tEwNgu4N 5ydnO64AJ5rBw+23HqZI5avHBLIhqHhFCa4CYAkssuoHpbQwXaOmM0cOQvZuHsWz0wQu /70A== X-Gm-Message-State: AOAM530PTlW6VmHd2D42IcWK8cZa+oXwQVqahbg/y0Mm7T7Q08Due8UF hYDjNVAB6s98psNtt+XZuGKyJdYsictCnVZGWoqnvz9D X-Google-Smtp-Source: ABdhPJxxP4hEP2mNPoGL3HYggQGnJRNYoIPj6baSrF3TQejQIqmxOuwuPWOYK1Y3Q8EYRk2VJrbBAxfQPKQoQ0Po4tA= X-Received: by 2002:a67:d508:: with SMTP id l8mr9452164vsj.42.1639075773467; Thu, 09 Dec 2021 10:49:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 9 Dec 2021 21:49:22 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: "Bjoern A. Zeeb" Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J933x6lMDz4QrX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N That's true, I mean "from outside" host view. Now, sysctl ioctl cannot access different vnet's interface list and stats from host. thanks On Thu, Dec 9, 2021 at 9:45 PM Bjoern A. Zeeb wrote: > > On 9 Dec 2021, at 18:25, =C3=96zkan KIRIK wrote: > > > bsnmpd: monitoring jails (event with different vnet) resources like > > interfaces, cpu usage etc. > > And I assume that means =E2=80=9Cfrom the outside=E2=80=9D (host view) an= d not > within a jail just for the jail (=E2=80=9Ccustomer view=E2=80=9D) =E2=80= =94 or maybe both? > > > > I don't have an account to modify wiki. thanks > > > > On Thu, Dec 9, 2021 at 7:47 PM Joseph Mingrone > > wrote: > >> > >> Thank you to everyone who took the time to contribute project ideas. > >> Here is a summary of what was submitted. If your idea was missed or > >> misrepresented, feel free to add or edit it. > >> > >> https://wiki.freebsd.org/2021FoundationCFI > >> > >> Joe > >> From nobody Thu Dec 9 18:57:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D20EE18C5B67 for ; Thu, 9 Dec 2021 18:57:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J93Dv0ytbz4T12; Thu, 9 Dec 2021 18:57:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id E1E548D4A215; Thu, 9 Dec 2021 18:57:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 27045E70846; Thu, 9 Dec 2021 18:57:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Qp0aTIW3_TfM; Thu, 9 Dec 2021 18:57:15 +0000 (UTC) Received: from [169.254.1.48] (unknown [IPv6:fde9:577b:c1a9:4902:116b:449:5763:67c1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AF59AE7082B; Thu, 9 Dec 2021 18:57:15 +0000 (UTC) From: "Bjoern A. Zeeb" To: "=?utf-8?q?=C3=96zkan?= KIRIK" Cc: "Joseph Mingrone" , "FreeBSD Hackers" Subject: Re: Call for Foundation-supported Project Ideas Date: Thu, 09 Dec 2021 18:57:14 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J93Dv0ytbz4T12 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 9 Dec 2021, at 18:49, Özkan KIRIK wrote: > That's true, I mean "from outside" host view. > > Now, sysctl ioctl cannot access different vnet's interface list and > stats from host. If we’ll do that and possibly need new syscalls we should make that interface extendable as that was one of the things virtual process space in the end got stuck on needing host based management of virtualised resources (and not doing the jexec things and do stuff from the inside). > On Thu, Dec 9, 2021 at 9:45 PM Bjoern A. Zeeb > wrote: >> >> On 9 Dec 2021, at 18:25, Özkan KIRIK wrote: >> >>> bsnmpd: monitoring jails (event with different vnet) resources like >>> interfaces, cpu usage etc. >> >> And I assume that means “from the outside” (host view) and not >> within a jail just for the jail (“customer view”) — or maybe >> both? >> >> >>> I don't have an account to modify wiki. thanks >>> >>> On Thu, Dec 9, 2021 at 7:47 PM Joseph Mingrone >>> wrote: >>>> >>>> Thank you to everyone who took the time to contribute project >>>> ideas. >>>> Here is a summary of what was submitted. If your idea was missed >>>> or >>>> misrepresented, feel free to add or edit it. >>>> >>>> https://wiki.freebsd.org/2021FoundationCFI >>>> >>>> Joe >>>> From nobody Thu Dec 9 19:02:59 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD81C18CBA59 for ; Thu, 9 Dec 2021 19:03:10 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J93Mf3kz7z4WdZ; Thu, 9 Dec 2021 19:03:10 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92b.google.com with SMTP id p2so12563309uad.11; Thu, 09 Dec 2021 11:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZKQ7nO/l1L38RH/DCt3iDOFCmpVmagpHHudiS++S34k=; b=TDwgI+j1x8z96To67+04cgoc3WuO6sgQlK9eqgdNcyVmLJ20HAfxg4Kb/yOPxGtBCx UjNhw1b4IeRjgA2upawxU+SFJwnu2oPJo55qFRDoa+QNmTsKn+Y2phqkgHN8n8TnK9dE LTpzZVlPM/YKwZPj7Xs8sqXJLPPdF7id3DLkDGB/TrPb7GbDvQj0JO9I6LKt4bIit2gq iHmxgIxfV42kA3Q/8oS2Yq7s7qJ2yZ4FcHlX++qCjW3gSdAZuScRXBmGmEVg2K/2hXek k0M0m78twwh3fP/ScrrMRuX9VI8nRitWjAiYtVvo9Rt4dTyEElDkIfRsjJqwktCX3Rat U5qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZKQ7nO/l1L38RH/DCt3iDOFCmpVmagpHHudiS++S34k=; b=2VBkV0izLV6f0j1S2IJXTYlawTYBLXpcQaU2D5Ba5L1e2+BQWPgwtl7x+4y7Byoo9t hn6ETFbhKXyHzRCPAtfdN9opa4yeb6AXoc6/XC6ux+z0bheVrJQc6IAy3oOHG4rfjP/V 2ZHqXvkI8FbzY6BocHnOGeQBcMUjfBtJXRObfOAowWPHPpscwytrX8xMDALuadl96434 AHTbyM0yFGUTYB6S0AvCLnXl3u3bC1QRQBudXWyiH4aLfQnJir8OmbBLFhZ/CmewgwZu /fm6OaS+j+XR080xxg0B6LoWVIphgjCqetBwLY513UtHh6gkYBMmTp5Dvpfb4qO2X+cr DhRw== X-Gm-Message-State: AOAM533A/Hna4qXIGNSZohmlnFeQHRR4reomtumRXdpq0swCXNBZukaP rRtMkDqpaSQliNwIbFTGMNOR3W1mNTXK2s/CnPR7zLT6 X-Google-Smtp-Source: ABdhPJzVrLA1Ej731mK2bJrqo6UcnWKIGF35JEB6M4i/9so5NI7WckphdPQ2MoPVYaCF0UrfwgOZXHTGJiQK/0iNCG8= X-Received: by 2002:a05:6102:2922:: with SMTP id cz34mr9886676vsb.56.1639076589775; Thu, 09 Dec 2021 11:03:09 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 9 Dec 2021 22:02:59 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: "Bjoern A. Zeeb" Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J93Mf3kz7z4WdZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N +1 On Thu, Dec 9, 2021 at 9:57 PM Bjoern A. Zeeb wrote: > > On 9 Dec 2021, at 18:49, =C3=96zkan KIRIK wrote: > > > That's true, I mean "from outside" host view. > > > > Now, sysctl ioctl cannot access different vnet's interface list and > > stats from host. > > If we=E2=80=99ll do that and possibly need new syscalls we should make th= at > interface extendable as that was one of the things virtual process space > in the end got stuck on needing host based management of virtualised > resources (and not doing the jexec things and do stuff from the inside). > > > > On Thu, Dec 9, 2021 at 9:45 PM Bjoern A. Zeeb > > wrote: > >> > >> On 9 Dec 2021, at 18:25, =C3=96zkan KIRIK wrote: > >> > >>> bsnmpd: monitoring jails (event with different vnet) resources like > >>> interfaces, cpu usage etc. > >> > >> And I assume that means =E2=80=9Cfrom the outside=E2=80=9D (host view)= and not > >> within a jail just for the jail (=E2=80=9Ccustomer view=E2=80=9D) =E2= =80=94 or maybe > >> both? > >> > >> > >>> I don't have an account to modify wiki. thanks > >>> > >>> On Thu, Dec 9, 2021 at 7:47 PM Joseph Mingrone > >>> wrote: > >>>> > >>>> Thank you to everyone who took the time to contribute project > >>>> ideas. > >>>> Here is a summary of what was submitted. If your idea was missed > >>>> or > >>>> misrepresented, feel free to add or edit it. > >>>> > >>>> https://wiki.freebsd.org/2021FoundationCFI > >>>> > >>>> Joe > >>>> From nobody Thu Dec 9 23:00:31 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E160918E6352 for ; Thu, 9 Dec 2021 23:00:50 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J98ds6FPLz3tFB; Thu, 9 Dec 2021 23:00:49 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 1B9N0gcP001213; Thu, 9 Dec 2021 17:00:42 -0600 (CST) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.30] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 1890819D3E5; Thu, 9 Dec 2021 17:00:37 -0600 (CST) Message-ID: <4eee16fa-d160-2b1a-2d46-42b7a607fb04@shrew.net> Date: Thu, 9 Dec 2021 17:00:31 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Fwd: Call for Foundation-supported Project Ideas Content-Language: en-US To: freebsd-hackers@freebsd.org References: <2BC55859-CA32-4DDC-B5E8-C17ED4934E0C@pretty.Easy.privacy> <949CAEC9-25C4-4448-9C60-30687D17410B@pretty.Easy.privacy> Cc: Mihai Carabas , mike@reifenberger.com, mr@freebsd.org From: Matthew Grooms In-Reply-To: <949CAEC9-25C4-4448-9C60-30687D17410B@pretty.Easy.privacy> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Thu, 09 Dec 2021 17:00:42 -0600 (CST) X-Rspamd-Queue-Id: 4J98ds6FPLz3tFB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [0.19 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; DMARC_NA(0.00)[shrew.net]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; FREEMAIL_CC(0.00)[gmail.com,reifenberger.com,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; RECEIVED_SPAMHAUS_PBL(0.00)[136.49.68.36:received] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N Support for USB Device pass through is being worked on by a student at the Bucharest Polytechnic University. This effort is essentially a port of the feature from Intel's Acorn hypervisor which is based on bhyve ... https://github.com/FreeBSD-UPB/freebsd-src/tree/projects/bhyve_usb_passthrough The UPB team has quite a few projects that would benefit from more support from the FreeBSD Foundation. They've asked for feedback and review of many bhyve related features that have been developed over the past few years. Unfortunately most of that work has been gathering dust in their github repository. This includes work on features such as warm migration, live migration, improved checkpoint file support, improved multiple checkpoint of devices, more sophisticated disk file formats such as qcow2 and vmdk via libvdsk that could help checkpoint disk images, etc. It would be incredibly helpful if the Foundation could offer some help getting some of this code reviewed and provide feedback so that it has a chance of being committed at some point in the future. -Matthew On 11/30/2021 1:30 PM, Michael wrote: > > > -------- Original Message -------- > From: Michael > Sent: November 30, 2021 11:03:13 AM GMT+01:00 > To: freebsd-hackers@freebsd.org > Subject: Call for Foundation-supported Project Ideas > > Hi, > one missing feature is USB device pass through for bhyve. > That would be quite handy for passing unsupported USB devices > to Linux/Windows on Laptops where a controller pass through isnt > possible. > > > -------- Original Message -------- > From: tux2bsd via freebsd-hackers > Sent: November 30, 2021 8:35:36 AM GMT+01:00 > To: "freebsd-hackers@freebsd.org" > Subject: Call for Foundation-supported Project Ideas > > Hi Joe > > Call for Foundation-supported Project Idea, well not a project but an item of importance in my opinion (the hostile forums disagree with me). > > Some help to fix freebsd-update , a very longstanding poor performance problem I took the time to investigate and provide an attempt to fix, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258863 > > I've been working with Colin Percival towards providing/fine-tuning a workaround but the program itself is monolithic and very intertwined which means a seemingly trivial fix is actually a nightmare - the goal posts keep changing with each step forward. Quite frustrating actually so I'd appreciate some help if mini-projects are acceptable. > > Thanks > tux2bsd > (apologies for the thread busting email) > -- > -- From nobody Fri Dec 10 07:53:12 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E094E18DDD49 for ; Fri, 10 Dec 2021 07:53:41 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9NSj1RSPz4TSF for ; Fri, 10 Dec 2021 07:53:41 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f176.google.com with SMTP id b19so10744592ljr.12 for ; Thu, 09 Dec 2021 23:53:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QhjE3fPcxg+5t2kWvrOps79t8XG9TfOhO/kVKUcicLs=; b=olPhDmF4CxPQdxLuh2CNxwfKCQ5Y3VoRS+RtW+KMch556SQqkvAIKXuGuK19mCYimc azyeTWoF9pg0sHizZ7NFmAf0YewKT8SIbbjCmlDoMY+XrCsBeNBkjlGf1S2YDvVvUdzu wgDFK8W5YXt06XsFb8tH0nQQ7U/f8aaL9qVEPa/uPgduykhb1sSJBpLgVl8sk1OAQLEe tOoELvFWIY3EjB/aROdRYMRYSwJykmrFzxlyxctiYnf9Yd4xAhwH5HiYujlRl91N5qB0 h7nnvkXx2ExsZee+TFvOXu6pz6rGhsmuxEVzURhpcpJFbbspii7lfwN6KZsLguQs1RsL SgKg== X-Gm-Message-State: AOAM5333lX0yNaPgPZiRboHmlQs3Q9sOtT9YR01oYFIjTv2y1r5tGtYs 2TApVQvJpVzdF0fY8Q8ifmdIL3Z6p26VqQ== X-Google-Smtp-Source: ABdhPJxNi8iarBdD+7wB1+n8vCdTWrSQY8y6yF48wtJ/gF+9F4zLdGnF/ogshfm5V4r+kBtHklW48Q== X-Received: by 2002:a2e:9206:: with SMTP id k6mr11348424ljg.117.1639122819837; Thu, 09 Dec 2021 23:53:39 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id s5sm237418ljg.3.2021.12.09.23.53.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Dec 2021 23:53:39 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id bi37so16543978lfb.5 for ; Thu, 09 Dec 2021 23:53:39 -0800 (PST) X-Received: by 2002:a05:6512:3050:: with SMTP id b16mr11205514lfb.89.1639122818923; Thu, 09 Dec 2021 23:53:38 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Fri, 10 Dec 2021 10:53:12 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: What to use in place of abstract unix sockets? To: "Daniel O'Connor" , Eugene Grosbein Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000005d84b505d2c60558" X-Rspamd-Queue-Id: 4J9NSj1RSPz4TSF X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [2.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.88)[-0.881]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.97)[0.969]; RCVD_COUNT_THREE(0.00)[4]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.50:received,209.85.208.176:from]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.176:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-ThisMailContainsUnwantedMimeParts: Y --0000000000005d84b505d2c60558 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 8, 2021 at 10:50 AM Eugene Grosbein wrote: > 08.12.2021 13:43, Gleb Popov wrote: > > > Hello hackers. > > > > I'm porting a software that does the following things on Linux: > > > > 1. Binds an abstract UDS (the socket name starts with '\0') > > 2. Launches a "client" process. > > 3. "Client" uses chroot() to constrain itself in a sort of jail. > > 4. "Client" connects to the abstract UDS. > > > >>From what I can tell, this works because abstract UDS's do not use the > > filesystem namespace, which is why "client" can connect out of the > > chroot'ed environment. > > > > What can I do to make this software work for FreeBSD? Simply using > regular > > UDS instead of abstract ones doesn't work for obvious reasons - the > > "client" can't find the socket file. > > > > Thanks in advance. > > If they are parent/child, you could try using socketpair(). > There are actually multiple children. If I understand it right, using socketpair() would lead to N sockets on the server side for the N connected clients. Right now there is a single UDS that handles all connections, so rewriting it with socketpair() would be problematic, I think. On Thu, Dec 9, 2021 at 3:08 AM Daniel O'Connor wrote: > > > > On 8 Dec 2021, at 17:13, Gleb Popov wrote: > > I'm porting a software that does the following things on Linux: > > > > 1. Binds an abstract UDS (the socket name starts with '\0') > > 2. Launches a "client" process. > > 3. "Client" uses chroot() to constrain itself in a sort of jail. > > 4. "Client" connects to the abstract UDS. > > > > From what I can tell, this works because abstract UDS's do not use the > > filesystem namespace, which is why "client" can connect out of the > > chroot'ed environment. > > > > What can I do to make this software work for FreeBSD? Simply using > regular > > UDS instead of abstract ones doesn't work for obvious reasons - the > > "client" can't find the socket file. > > If the parent knows where the child will chroot it could create a unix > domain socket under that directory somewhere. > Same problem as above - there should be a single socket on the server side. --0000000000005d84b505d2c60558-- From nobody Fri Dec 10 08:29:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 40E7718E37E8; Fri, 10 Dec 2021 08:29:57 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9PGX3b2zz4XdR; Fri, 10 Dec 2021 08:29:56 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x22f.google.com with SMTP id i63so12680912lji.3; Fri, 10 Dec 2021 00:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:mime-version; bh=ELm2y6dbPZGlarzo9PgVfq5ub4AS3vQ4PdnjPoV7hjk=; b=KiUMwissu+BAl0VtHc+FEvD3Exi32DA3UdcLtoUFbKoHRXelwjEpaIMDd8L/kzPwWC +GodOJfXsdMME6usdNypUq3+Mz8/kcwzHcE+BGp1Xj+LIdFrwLw++PNpBsbUxxJwsVJO n3jTvCZGMMRIO2uFe3AU+MrFO31iMOx9/uwr53NR+YYJVcFZ98qjGCiTLjSweelG4pTS t2IllvcQDfjA4sey+YM5tU8lgF1/aRipAu5p2VilevkJvKCC2Xfcqnld6i9gDf/CDny5 drG7Jx3GPW4dse7xijYUb35BKvfYYl1X1+jcuxAhrbjyKnYkMtpT/asD46YYz30wzvC+ N9zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version; bh=ELm2y6dbPZGlarzo9PgVfq5ub4AS3vQ4PdnjPoV7hjk=; b=V+A2P/ReHSsvJhALSXoLuS5FMCjh4N55V3pI0Z+6CtHr3cCTGYNHJkBUPcJn3qprlI SP7AfXy+aBYb9+7IjVs1xgrdQxvxcF3G4F3Lhhu+O4GlptQ9Iwlrk9L+vvTkBwW2qiSc WuMtNaQYnlv03GtViC3pxbAEnOSKJrqmyin1Hj1Qvh0yfIuA3cr6gJO89wmsjDmZj4E/ Jy5gln6q18HTG8N7ld/+uRvAmB4dg+Ql8hxRYEcOLS9OT0g00ZRTm/+AP1l+JigmLNr2 JCpNWvltrVIKNz9aCGPBsrlOO8H7mvLk5hJohbruEhCohCXC7anVo6wPFNAnjVqTHiO3 3JPg== X-Gm-Message-State: AOAM532I1rG+9Ng241isHorSnoFQ6HMCh2Mf6oH00X+3Xd/gWKJ920Wy BhdS0xY1/6pKW+e2eX8WdKxSeYQnptc= X-Google-Smtp-Source: ABdhPJyWs/V/OtZLNL1OaQlOoJLOheZz4pYEO8Dvk/eJWjjWRWpz8TMlyDLmFvL19UHe2nNJr2xAzg== X-Received: by 2002:a2e:1644:: with SMTP id 4mr10940548ljw.312.1639124995277; Fri, 10 Dec 2021 00:29:55 -0800 (PST) Received: from rimwks.local ([176.99.182.246]) by smtp.gmail.com with ESMTPSA id m29sm240049lfj.187.2021.12.10.00.29.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Dec 2021 00:29:54 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Fri, 10 Dec 2021 11:29:38 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Cc: Rozhuk Ivan Subject: Too many warnings for world and kernel for 13 stable Message-ID: <20211210112938.21747d4d@rimwks.local> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/wQ+F2DVnjFSjsXA5CnSTh.G" X-Rspamd-Queue-Id: 4J9PGX3b2zz4XdR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KiUMwiss; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::22f as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[176.99.182.246:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.95)[0.950]; NEURAL_HAM_LONG(-0.97)[-0.968]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-patch]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22f:from]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --MP_/wQ+F2DVnjFSjsXA5CnSTh.G Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! There was a lot warning during build wold and kernel in past with clang 13, but with clang 14 to many warnings. Probably commiters will find some time to fix it? I spent some time to fix/supress warnings for world, exept contrib and stand parts. This patch is not to merge, it is to show that something goes wrong. --MP_/wQ+F2DVnjFSjsXA5CnSTh.G Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=616ca2b8b6.patch >From 616ca2b8b63b225be0305d34f36dd3d0050a6a4f Mon Sep 17 00:00:00 2001 From: Rozhuk Ivan Date: Fri, 10 Sep 2021 18:50:20 +0300 Subject: [PATCH] Fix build warnings --- lib/geom/eli/geom_eli.c | 4 +- lib/libc/stdlib/rand.c | 4 +- lib/libfetch/http.c | 7 +--- lib/libkvm/kvm_minidump_powerpc64_hpt.c | 3 -- lib/libmd/rmd160c.c | 1 + lib/libmd/sha1c.c | 2 + lib/libpfctl/libpfctl.c | 16 +++---- lib/libpjdlog/pjdlog.c | 5 ++- lib/libprocstat/libprocstat.c | 1 + lib/libvgl/mouse.c | 5 +-- lib/libvmmapi/vmmapi.c | 3 +- lib/ncurses/ncurses/termcap.c | 2 - sbin/bsdlabel/bsdlabel.c | 8 +--- sbin/camcontrol/zone.c | 7 +--- sbin/ggate/ggated/ggated.c | 42 +++++++------------ sbin/growfs/growfs.c | 5 +-- sbin/ipfw/ipfw2.c | 5 +-- sbin/ipfw/nat.c | 3 +- sbin/ipfw/nat64clat.c | 3 +- sbin/ipfw/nat64lsn.c | 3 +- sbin/ipfw/nat64stl.c | 3 +- sbin/ipfw/nptv6.c | 3 +- sbin/ipfw/tables.c | 6 +-- sbin/nvmecontrol/modules/wdc/wdc.c | 3 +- sbin/pfctl/pfctl_optimize.c | 3 -- sbin/recoverdisk/recoverdisk.c | 14 +------ sys/amd64/vmm/vmm_instruction_emul.c | 18 ++------ sys/netinet/libalias/alias.c | 11 +++-- usr.bin/backlight/backlight.c | 3 -- usr.bin/ipcs/ipc.c | 3 +- usr.bin/mkuzip/mkuzip.c | 8 ++-- usr.bin/mt/mt.c | 5 +-- usr.bin/procstat/procstat.c | 3 +- usr.bin/truss/syscalls.c | 7 +--- usr.bin/unifdef/unifdef.c | 5 +-- usr.bin/units/units.c | 5 --- usr.bin/vmstat/vmstat.c | 4 +- usr.bin/vtfontcvt/vtfontcvt.c | 8 ---- usr.sbin/acpi/acpidump/acpi.c | 5 --- usr.sbin/bhyve/atkbdc.c | 12 ++---- usr.sbin/bhyve/bhyverun.c | 12 ++---- usr.sbin/bhyve/gdb.c | 14 ++----- usr.sbin/bhyve/hda_codec.c | 22 +++------- usr.sbin/bhyve/mem.c | 26 ++++-------- usr.sbin/bhyve/mevent.c | 4 +- usr.sbin/bhyve/pci_ahci.c | 20 ++++----- usr.sbin/bhyve/pci_e82545.c | 8 +--- usr.sbin/bhyve/pci_emul.c | 26 ++++-------- usr.sbin/bhyve/pci_hda.c | 31 ++++---------- usr.sbin/bhyve/pci_virtio_block.c | 10 ++--- usr.sbin/bhyve/pci_virtio_console.c | 8 +--- usr.sbin/bhyve/pci_virtio_net.c | 7 +--- usr.sbin/bhyve/pci_virtio_rnd.c | 5 +-- usr.sbin/bhyve/pci_virtio_scsi.c | 4 +- usr.sbin/bhyve/pm.c | 10 +---- usr.sbin/bhyve/rtc.c | 21 ++++------ usr.sbin/bhyve/spinup_ap.c | 22 ++++------ usr.sbin/bhyve/task_switch.c | 22 +++------- usr.sbin/bhyve/uart_emul.c | 13 ++---- usr.sbin/bhyve/vga.c | 8 ++-- usr.sbin/bsdinstall/partedit/scripted.c | 7 ++-- usr.sbin/camdd/camdd.c | 19 +-------- usr.sbin/efibootmgr/efibootmgr.c | 3 +- usr.sbin/efidp/efidp.c | 3 +- .../fifolog/fifolog_reader/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_int.c | 2 +- usr.sbin/fifolog/lib/fifolog_reader.c | 4 +- usr.sbin/fifolog/lib/fifolog_write_poll.c | 2 +- usr.sbin/fifolog/lib/getdate.y | 13 +----- usr.sbin/fwcontrol/fwdv.c | 4 +- usr.sbin/makefs/msdos.c | 2 - usr.sbin/makefs/msdos/msdosfs_vfsops.c | 2 - usr.sbin/mpsutil/mps_debug.c | 2 - usr.sbin/mptable/mptable.c | 3 -- usr.sbin/pmc/cmd_pmc_filter.cc | 3 +- usr.sbin/pw/pw_user.c | 4 +- usr.sbin/rpc.lockd/kern.c | 5 --- usr.sbin/rpc.tlsservd/rpc.tlsservd.c | 3 +- usr.sbin/rrenumd/parser.y | 2 - 79 files changed, 179 insertions(+), 459 deletions(-) diff --git a/lib/geom/eli/geom_eli.c b/lib/geom/eli/geom_eli.c index 4c04a9256b5..5d3cf504e17 100644 --- a/lib/geom/eli/geom_eli.c +++ b/lib/geom/eli/geom_eli.c @@ -1285,7 +1285,6 @@ eli_setkey_attached(struct gctl_req *req, struct g_eli_metadata *md) { unsigned char key[G_ELI_USERKEYLEN]; intmax_t val, old = 0; - int error; val = gctl_get_intmax(req, "iterations"); /* Check if iterations number should be changed. */ @@ -1304,9 +1303,8 @@ eli_setkey_attached(struct gctl_req *req, struct g_eli_metadata *md) * command-line argument, update the request. */ if (val == -1 && md->md_iterations != old) { - error = gctl_change_param(req, "iterations", sizeof(intmax_t), + gctl_change_param(req, "iterations", sizeof(intmax_t), &md->md_iterations); - assert(error == 0); } gctl_ro_param(req, "key", sizeof(key), key); diff --git a/lib/libc/stdlib/rand.c b/lib/libc/stdlib/rand.c index e448d1b1fd1..45ae924dd7a 100644 --- a/lib/libc/stdlib/rand.c +++ b/lib/libc/stdlib/rand.c @@ -71,11 +71,9 @@ static pthread_once_t rand3_state_once = PTHREAD_ONCE_INIT; static void initialize_rand3(void) { - int error; rand3_state = allocatestate(TYPE_3); - error = initstate_r(rand3_state, 1, rand3_state->rst_randtbl, BREAK_3); - assert(error == 0); + initstate_r(rand3_state, 1, rand3_state->rst_randtbl, BREAK_3); } int diff --git a/lib/libfetch/http.c b/lib/libfetch/http.c index bcb089dc0fc..c1d92d08b31 100644 --- a/lib/libfetch/http.c +++ b/lib/libfetch/http.c @@ -976,13 +976,12 @@ http_base64(const char *src) "0123456789+/"; char *str, *dst; size_t l; - int t, r; + int t; l = strlen(src); if ((str = malloc(((l + 2) / 3) * 4 + 1)) == NULL) return (NULL); dst = str; - r = 0; while (l >= 3) { t = (src[0] << 16) | (src[1] << 8) | src[2]; @@ -991,7 +990,7 @@ http_base64(const char *src) dst[2] = base64[(t >> 6) & 0x3f]; dst[3] = base64[(t >> 0) & 0x3f]; src += 3; l -= 3; - dst += 4; r += 4; + dst += 4; } switch (l) { @@ -1002,7 +1001,6 @@ http_base64(const char *src) dst[2] = base64[(t >> 6) & 0x3f]; dst[3] = '='; dst += 4; - r += 4; break; case 1: t = src[0] << 16; @@ -1010,7 +1008,6 @@ http_base64(const char *src) dst[1] = base64[(t >> 12) & 0x3f]; dst[2] = dst[3] = '='; dst += 4; - r += 4; break; case 0: break; diff --git a/lib/libkvm/kvm_minidump_powerpc64_hpt.c b/lib/libkvm/kvm_minidump_powerpc64_hpt.c index baa2fd1ebc0..d13f8021a73 100644 --- a/lib/libkvm/kvm_minidump_powerpc64_hpt.c +++ b/lib/libkvm/kvm_minidump_powerpc64_hpt.c @@ -253,9 +253,6 @@ static int ppc64mmu_hpt_init(kvm_t *kd) { struct hpt_data *data; - struct minidumphdr *hdr; - - hdr = &kd->vmst->hdr; /* Alloc MMU data */ data = _kvm_malloc(kd, sizeof(*data)); diff --git a/lib/libmd/rmd160c.c b/lib/libmd/rmd160c.c index a8a4ced70b0..95f56dc6b9a 100644 --- a/lib/libmd/rmd160c.c +++ b/lib/libmd/rmd160c.c @@ -83,6 +83,7 @@ char *RMD160_version="RIPEMD160 part of SSLeay 0.9.0b 11-Oct-1998"; #ifdef RMD160_ASM void ripemd160_block_x86(RIPEMD160_CTX *c, const u_int32_t *p,int num); +#undef ripemd160_block #define ripemd160_block ripemd160_block_x86 #else void ripemd160_block(RIPEMD160_CTX *c, const u_int32_t *p,int num); diff --git a/lib/libmd/sha1c.c b/lib/libmd/sha1c.c index d0bcc35f93d..05223204518 100644 --- a/lib/libmd/sha1c.c +++ b/lib/libmd/sha1c.c @@ -101,6 +101,7 @@ char *SHA1_version="SHA1 part of SSLeay 0.9.0b 11-Oct-1998"; #ifndef NOPROTO # ifdef SHA1_ASM void sha1_block_x86(SHA_CTX *c, const u_int32_t *p, int num); +# undef sha1_block # define sha1_block sha1_block_x86 # else void sha1_block(SHA_CTX *c, const u_int32_t *p, int num); @@ -108,6 +109,7 @@ char *SHA1_version="SHA1 part of SSLeay 0.9.0b 11-Oct-1998"; #else # ifdef SHA1_ASM void sha1_block_x86(); +# undef sha1_block # define sha1_block sha1_block_x86 # else void sha1_block(); diff --git a/lib/libpfctl/libpfctl.c b/lib/libpfctl/libpfctl.c index 9252f64969b..09c4aba9c94 100644 --- a/lib/libpfctl/libpfctl.c +++ b/lib/libpfctl/libpfctl.c @@ -60,8 +60,8 @@ static int _pfctl_clear_states(int , const struct pfctl_kill *, unsigned int *, uint64_t); static void -pf_nvuint_8_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint8_t *numbers, size_t *nelems) +pf_nvuint_8_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint8_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -77,8 +77,8 @@ pf_nvuint_8_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_16_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint16_t *numbers, size_t *nelems) +pf_nvuint_16_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint16_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -94,8 +94,8 @@ pf_nvuint_16_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_32_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint32_t *numbers, size_t *nelems) +pf_nvuint_32_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint32_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; @@ -111,8 +111,8 @@ pf_nvuint_32_array(const nvlist_t *nvl, const char *name, size_t maxelems, } static void -pf_nvuint_64_array(const nvlist_t *nvl, const char *name, size_t maxelems, - uint64_t *numbers, size_t *nelems) +pf_nvuint_64_array(const nvlist_t *nvl, const char *name, + size_t maxelems __unused, uint64_t *numbers, size_t *nelems) { const uint64_t *tmp; size_t elems; diff --git a/lib/libpjdlog/pjdlog.c b/lib/libpjdlog/pjdlog.c index eb7ddb2b7a8..46d31761f41 100644 --- a/lib/libpjdlog/pjdlog.c +++ b/lib/libpjdlog/pjdlog.c @@ -78,7 +78,7 @@ static char pjdlog_prefix[PJDLOG_PREFIX_STACK][PJDLOG_PREFIX_MAXSIZE]; static int pjdlog_printf_arginfo_humanized_number(const struct printf_info *pi __unused, - size_t n, int *argt) + size_t n __unused, int *argt) { assert(n >= 1); @@ -104,7 +104,7 @@ pjdlog_printf_render_humanized_number(struct __printf_io *io, static int pjdlog_printf_arginfo_sockaddr(const struct printf_info *pi __unused, - size_t n, int *argt) + size_t n __unused, int *argt) { assert(n >= 1); @@ -570,6 +570,7 @@ pjdlogv_common_single_line(const char *func, const char *file, int line, break; default: assert(!"Invalid mode."); + return; } *logp = '\0'; diff --git a/lib/libprocstat/libprocstat.c b/lib/libprocstat/libprocstat.c index 89896a81388..3c2e5222a4c 100644 --- a/lib/libprocstat/libprocstat.c +++ b/lib/libprocstat/libprocstat.c @@ -877,6 +877,7 @@ procstat_getfiles_sysctl(struct procstat *procstat, struct kinfo_proc *kp, break; default: assert(!"invalid type"); + return (NULL); } if (files == NULL && errno != EPERM) { warn("kinfo_getfile()"); diff --git a/lib/libvgl/mouse.c b/lib/libvgl/mouse.c index 010a1b7b9c5..fc7ba239938 100644 --- a/lib/libvgl/mouse.c +++ b/lib/libvgl/mouse.c @@ -284,22 +284,19 @@ VGLMouseInit(int mode) { struct mouse_info mouseinfo; VGLBitmap *ormask; - int andmask, border, error, i, interior; + int border, error, i, interior; switch (VGLModeInfo.vi_mem_model) { case V_INFO_MM_PACKED: case V_INFO_MM_PLANAR: - andmask = 0x0f; border = 0x0f; interior = 0x04; break; case V_INFO_MM_VGAX: - andmask = 0x3f; border = 0x3f; interior = 0x24; break; default: - andmask = 0xff; border = BORDER; interior = INTERIOR; break; diff --git a/lib/libvmmapi/vmmapi.c b/lib/libvmmapi/vmmapi.c index 0543c92f430..0d3444a24f9 100644 --- a/lib/libvmmapi/vmmapi.c +++ b/lib/libvmmapi/vmmapi.c @@ -391,7 +391,8 @@ setup_memory_segment(struct vmctx *ctx, vm_paddr_t gpa, size_t len, char *base) } int -vm_setup_memory(struct vmctx *ctx, size_t memsize, enum vm_mmap_style vms) +vm_setup_memory(struct vmctx *ctx, size_t memsize, + enum vm_mmap_style vms __unused) { size_t objsize, len; vm_paddr_t gpa; diff --git a/lib/ncurses/ncurses/termcap.c b/lib/ncurses/ncurses/termcap.c index 535301a1b47..9a609537d80 100644 --- a/lib/ncurses/ncurses/termcap.c +++ b/lib/ncurses/ncurses/termcap.c @@ -111,13 +111,11 @@ _nc_read_termcap_entry(const char *const name, TERMTYPE2 *const tp) int i; char pathbuf[PBUFSIZ]; /* holds raw path of filenames */ char *pathvec[PVECSIZ]; /* to point to names in pathbuf */ - char **pvec; /* holds usable tail of path vector */ char *termpath; _nc_termcap[0] = '\0'; /* in case */ dummy = NULL; fname = pathvec; - pvec = pathvec; p = pathbuf; cp = getenv("TERMCAP"); /* diff --git a/sbin/bsdlabel/bsdlabel.c b/sbin/bsdlabel/bsdlabel.c index 943f37207fc..efe7eebf23c 100644 --- a/sbin/bsdlabel/bsdlabel.c +++ b/sbin/bsdlabel/bsdlabel.c @@ -1094,7 +1094,7 @@ checklabel(struct disklabel *lp) struct partition *pp; int i, errors = 0; char part; - u_long base_offset, needed, total_size, total_percent, current_offset; + u_long base_offset, needed, total_percent, current_offset; long free_space; int seen_default_offset; int hog_part; @@ -1173,7 +1173,6 @@ checklabel(struct disklabel *lp) /* first allocate space to the partitions, then offsets */ - total_size = 0; /* in sectors */ total_percent = 0; /* in percent */ hog_part = -1; /* find all fixed partitions */ @@ -1234,9 +1233,6 @@ checklabel(struct disklabel *lp) size /= lp->d_secsize; pp->p_size = size; } - /* else already in sectors */ - if (i != RAW_PART) - total_size += size; } } } @@ -1272,7 +1268,6 @@ checklabel(struct disklabel *lp) if (part_set[i] && part_size_type[i] == '%') { /* careful of overflows! and integer roundoff */ pp->p_size = ((double)pp->p_size/100) * free_space; - total_size += pp->p_size; /* FIX we can lose a sector or so due to roundoff per partition. A more complex algorithm could avoid that */ @@ -1328,7 +1323,6 @@ checklabel(struct disklabel *lp) } else { lp->d_partitions[hog_part].p_size = current_offset - base_offset - needed; - total_size += lp->d_partitions[hog_part].p_size; } } diff --git a/sbin/camcontrol/zone.c b/sbin/camcontrol/zone.c index 130f53226f5..e6ca6295450 100644 --- a/sbin/camcontrol/zone.c +++ b/sbin/camcontrol/zone.c @@ -138,7 +138,6 @@ zone_rz_print(uint8_t *data_ptr, uint32_t valid_len, int ata_format, struct scsi_report_zones_desc *desc = NULL; uint32_t hdr_len, len; uint64_t max_lba, next_lba = 0; - int more_data = 0; zone_print_status status = ZONE_PRINT_OK; char tmpstr[80]; int field_widths[ZONE_NUM_FIELDS]; @@ -168,7 +167,6 @@ zone_rz_print(uint8_t *data_ptr, uint32_t valid_len, int ata_format, } if (hdr_len > (valid_len + sizeof(*hdr))) { - more_data = 1; status = ZONE_PRINT_MORE_DATA; } @@ -560,7 +558,6 @@ restart_report: case CC_DT_ATA: case CC_DT_SATL: { uint8_t command = 0; - uint8_t protocol = 0; uint16_t features = 0, sector_count = 0; uint32_t auxiliary = 0; @@ -571,7 +568,6 @@ restart_report: */ if (use_ncq == 0) { - protocol = AP_PROTO_NON_DATA; command = ATA_ZAC_MANAGEMENT_OUT; features = action & 0xf; if (all_zones != 0) @@ -581,7 +577,6 @@ restart_report: if (cdb_storage == NULL) err(1, "couldn't allocate memory"); - protocol = AP_PROTO_FPDMA; command = ATA_NCQ_NON_DATA; features = ATA_NCQ_ZAC_MGMT_OUT; auxiliary = action & 0xf; @@ -594,7 +589,7 @@ restart_report: /*retry_count*/ retry_count, /*flags*/ CAM_DIR_NONE | CAM_DEV_QFRZDIS, /*tag_action*/ task_attr, - /*protocol*/ AP_PROTO_NON_DATA, + /*protocol???? AP_PROTO_FPDMA*/ AP_PROTO_NON_DATA, /*ata_flags*/ AP_FLAG_BYT_BLOK_BYTES | AP_FLAG_TLEN_NO_DATA, /*features*/ features, diff --git a/sbin/ggate/ggated/ggated.c b/sbin/ggate/ggated/ggated.c index 226ba1ce72d..03aabd271da 100644 --- a/sbin/ggate/ggated/ggated.c +++ b/sbin/ggate/ggated/ggated.c @@ -639,7 +639,7 @@ recv_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -688,13 +688,10 @@ recv_thread(void *arg) /* * Put the request onto the incoming queue. */ - error = pthread_mutex_lock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&inqueue_mtx); TAILQ_INSERT_TAIL(&inqueue, req, r_next); - error = pthread_cond_signal(&inqueue_cond); - assert(error == 0); - error = pthread_mutex_unlock(&inqueue_mtx); - assert(error == 0); + pthread_cond_signal(&inqueue_cond); + pthread_mutex_unlock(&inqueue_mtx); } } @@ -704,7 +701,7 @@ disk_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -713,15 +710,12 @@ disk_thread(void *arg) /* * Get a request from the incoming queue. */ - error = pthread_mutex_lock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&inqueue_mtx); while ((req = TAILQ_FIRST(&inqueue)) == NULL) { - error = pthread_cond_wait(&inqueue_cond, &inqueue_mtx); - assert(error == 0); + pthread_cond_wait(&inqueue_cond, &inqueue_mtx); } TAILQ_REMOVE(&inqueue, req, r_next); - error = pthread_mutex_unlock(&inqueue_mtx); - assert(error == 0); + pthread_mutex_unlock(&inqueue_mtx); /* * Check the request. @@ -766,13 +760,10 @@ disk_thread(void *arg) /* * Put the request onto the outgoing queue. */ - error = pthread_mutex_lock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&outqueue_mtx); TAILQ_INSERT_TAIL(&outqueue, req, r_next); - error = pthread_cond_signal(&outqueue_cond); - assert(error == 0); - error = pthread_mutex_unlock(&outqueue_mtx); - assert(error == 0); + pthread_cond_signal(&outqueue_cond); + pthread_mutex_unlock(&outqueue_mtx); } /* NOTREACHED */ @@ -785,7 +776,7 @@ send_thread(void *arg) struct ggd_connection *conn; struct ggd_request *req; ssize_t data; - int error, fd; + int fd; conn = arg; g_gate_log(LOG_NOTICE, "%s: started [%s]!", __func__, conn->c_path); @@ -794,16 +785,13 @@ send_thread(void *arg) /* * Get a request from the outgoing queue. */ - error = pthread_mutex_lock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_lock(&outqueue_mtx); while ((req = TAILQ_FIRST(&outqueue)) == NULL) { - error = pthread_cond_wait(&outqueue_cond, + pthread_cond_wait(&outqueue_cond, &outqueue_mtx); - assert(error == 0); } TAILQ_REMOVE(&outqueue, req, r_next); - error = pthread_mutex_unlock(&outqueue_mtx); - assert(error == 0); + pthread_mutex_unlock(&outqueue_mtx); g_gate_log(LOG_DEBUG, "%s: offset=%" PRIu64 " length=%" PRIu32, __func__, req->r_offset, req->r_length); diff --git a/sbin/growfs/growfs.c b/sbin/growfs/growfs.c index 1f1bcf82c96..6a57924fb7b 100644 --- a/sbin/growfs/growfs.c +++ b/sbin/growfs/growfs.c @@ -560,7 +560,7 @@ static void updjcg(int cylno, time_t modtime, int fsi, int fso, unsigned int Nflag) { DBG_FUNC("updjcg") - ufs2_daddr_t cbase, dmax, dupper; + ufs2_daddr_t cbase, dmax; struct csum *cs; int i, k; int j = 0; @@ -607,9 +607,6 @@ updjcg(int cylno, time_t modtime, int fsi, int fso, unsigned int Nflag) dmax = cbase + sblock.fs_fpg; if (dmax > sblock.fs_size) dmax = sblock.fs_size; - dupper = cgdmin(&sblock, cylno) - cbase; - if (cylno == 0) /* XXX fscs may be relocated */ - dupper += howmany(sblock.fs_cssize, sblock.fs_fsize); /* * Set pointer to the cylinder summary for our cylinder group. diff --git a/sbin/ipfw/ipfw2.c b/sbin/ipfw/ipfw2.c index e210cbfd02e..35f7ef2e4c4 100644 --- a/sbin/ipfw/ipfw2.c +++ b/sbin/ipfw/ipfw2.c @@ -2650,7 +2650,6 @@ list_static_range(struct cmdline_opts *co, struct format_opts *fo, int n, seen; struct ip_fw_rule *r; struct ip_fw_bcounter *cntr; - int c = 0; for (n = seen = 0; n < rcnt; n++, rtlv = (ipfw_obj_tlv *)((caddr_t)rtlv + rtlv->length)) { @@ -2669,7 +2668,6 @@ list_static_range(struct cmdline_opts *co, struct format_opts *fo, if (r->rulenum >= fo->first && r->rulenum <= fo->last) { show_static_rule(co, fo, bp, r, cntr); printf("%s", bp->buf); - c += rtlv->length; bp_flush(bp); seen++; } @@ -2788,13 +2786,12 @@ ipfw_show_config(struct cmdline_opts *co, struct format_opts *fo, char *endptr; size_t readsz; struct buf_pr bp; - ipfw_obj_ctlv *ctlv, *tstate; + ipfw_obj_ctlv *ctlv; ipfw_obj_tlv *rbase; /* * Handle tablenames TLV first, if any */ - tstate = NULL; rbase = NULL; dynbase = NULL; dynsz = 0; diff --git a/sbin/ipfw/nat.c b/sbin/ipfw/nat.c index 1076e1038b8..bb2a63e21e9 100644 --- a/sbin/ipfw/nat.c +++ b/sbin/ipfw/nat.c @@ -1074,7 +1074,6 @@ nat_foreach(nat_cb_t *f, void *arg, int sort) struct nat44_cfg_nat *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(struct nat44_cfg_nat); @@ -1097,7 +1096,7 @@ nat_foreach(nat_cb_t *f, void *arg, int sort) cfg = (struct nat44_cfg_nat*)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, arg); /* Ignore errors for now */ + f(cfg, arg); /* Ignore errors for now */ cfg = (struct nat44_cfg_nat *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64clat.c b/sbin/ipfw/nat64clat.c index 962fe7064f8..25d0689ca5f 100644 --- a/sbin/ipfw/nat64clat.c +++ b/sbin/ipfw/nat64clat.c @@ -505,7 +505,6 @@ nat64clat_foreach(nat64clat_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64clat_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -528,7 +527,7 @@ nat64clat_foreach(nat64clat_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64clat_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64clat_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64lsn.c b/sbin/ipfw/nat64lsn.c index ff36181815d..b9b58042e94 100644 --- a/sbin/ipfw/nat64lsn.c +++ b/sbin/ipfw/nat64lsn.c @@ -853,7 +853,6 @@ nat64lsn_foreach(nat64lsn_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64lsn_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(ipfw_nat64lsn_cfg); @@ -877,7 +876,7 @@ nat64lsn_foreach(nat64lsn_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64lsn_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64lsn_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nat64stl.c b/sbin/ipfw/nat64stl.c index e82ec202b5c..ec1d11aaad4 100644 --- a/sbin/ipfw/nat64stl.c +++ b/sbin/ipfw/nat64stl.c @@ -521,7 +521,6 @@ nat64stl_foreach(nat64stl_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nat64stl_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -544,7 +543,7 @@ nat64stl_foreach(nat64stl_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nat64stl_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); /* Ignore errors for now */ + f(cfg, name, set); /* Ignore errors for now */ cfg = (ipfw_nat64stl_cfg *)((caddr_t)cfg + olh->objsize); } diff --git a/sbin/ipfw/nptv6.c b/sbin/ipfw/nptv6.c index f2ebbdb6518..a158299eb37 100644 --- a/sbin/ipfw/nptv6.c +++ b/sbin/ipfw/nptv6.c @@ -420,7 +420,6 @@ nptv6_foreach(nptv6_cb_t *f, const char *name, uint8_t set, int sort) ipfw_nptv6_cfg *cfg; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(*cfg); @@ -442,7 +441,7 @@ nptv6_foreach(nptv6_cb_t *f, const char *name, uint8_t set, int sort) cfg = (ipfw_nptv6_cfg *)(olh + 1); for (i = 0; i < olh->count; i++) { - error = f(cfg, name, set); + f(cfg, name, set); cfg = (ipfw_nptv6_cfg *)((caddr_t)cfg + olh->objsize); } free(olh); diff --git a/sbin/ipfw/tables.c b/sbin/ipfw/tables.c index 81cf7e39258..c3c2173f48e 100644 --- a/sbin/ipfw/tables.c +++ b/sbin/ipfw/tables.c @@ -1386,7 +1386,6 @@ guess_key_type(char *key, uint8_t *ptype) { char *p; struct in6_addr addr; - uint32_t kv; if (ishexnumber(*key) != 0 || *key == ':') { /* Remove / if exists */ @@ -1402,7 +1401,7 @@ guess_key_type(char *key, uint8_t *ptype) } else { /* Port or any other key */ /* Skip non-base 10 entries like 'fa1' */ - kv = strtol(key, &p, 10); + strtol(key, &p, 10); if (*p == '\0') { *ptype = IPFW_TABLE_NUMBER; return (0); @@ -1685,7 +1684,6 @@ tables_foreach(table_cb_t *f, void *arg, int sort) ipfw_xtable_info *info; size_t sz; uint32_t i; - int error; /* Start with reasonable default */ sz = sizeof(*olh) + 16 * sizeof(ipfw_xtable_info); @@ -1710,7 +1708,7 @@ tables_foreach(table_cb_t *f, void *arg, int sort) info = (ipfw_xtable_info *)(olh + 1); for (i = 0; i < olh->count; i++) { if (g_co.use_set == 0 || info->set == g_co.use_set - 1) - error = f(info, arg); + f(info, arg); info = (ipfw_xtable_info *)((caddr_t)info + olh->objsize); } diff --git a/sbin/nvmecontrol/modules/wdc/wdc.c b/sbin/nvmecontrol/modules/wdc/wdc.c index 050458a8812..cfef69d8b69 100644 --- a/sbin/nvmecontrol/modules/wdc/wdc.c +++ b/sbin/nvmecontrol/modules/wdc/wdc.c @@ -783,7 +783,6 @@ static void print_hgst_info_log(const struct nvme_controller_data *cdata __unused, void *buf, uint32_t size __unused) { uint8_t *walker, *end, *subpage; - int pages; uint16_t len; uint8_t subtype, res; @@ -791,7 +790,7 @@ print_hgst_info_log(const struct nvme_controller_data *cdata __unused, void *buf printf("===================\n"); walker = buf; - pages = *walker++; + walker++; /* Pages */ walker++; len = le16dec(walker); walker += 2; diff --git a/sbin/pfctl/pfctl_optimize.c b/sbin/pfctl/pfctl_optimize.c index cb557884067..d999734a906 100644 --- a/sbin/pfctl/pfctl_optimize.c +++ b/sbin/pfctl/pfctl_optimize.c @@ -817,7 +817,6 @@ block_feedback(struct pfctl *pf, struct superblock *block) { TAILQ_HEAD( , pf_opt_rule) queue; struct pf_opt_rule *por1, *por2; - u_int64_t total_count = 0; struct pfctl_rule a, b; @@ -827,8 +826,6 @@ block_feedback(struct pfctl *pf, struct superblock *block) */ TAILQ_FOREACH(por1, &block->sb_profiled_block->sb_rules, por_entry) { comparable_rule(&a, &por1->por_rule, DC); - total_count += por1->por_rule.packets[0] + - por1->por_rule.packets[1]; TAILQ_FOREACH(por2, &block->sb_rules, por_entry) { if (por2->por_profile_count) continue; diff --git a/sbin/recoverdisk/recoverdisk.c b/sbin/recoverdisk/recoverdisk.c index 8c4aabebc76..0f3388f9933 100644 --- a/sbin/recoverdisk/recoverdisk.c +++ b/sbin/recoverdisk/recoverdisk.c @@ -32,9 +32,7 @@ /* Safe printf into a fixed-size buffer */ #define bprintf(buf, fmt, ...) \ do { \ - int ibprintf; \ - ibprintf = snprintf(buf, sizeof buf, fmt, __VA_ARGS__); \ - assert(ibprintf >= 0 && ibprintf < (int)sizeof buf); \ + snprintf(buf, sizeof buf, fmt, __VA_ARGS__); \ } while (0) struct lump { @@ -79,8 +77,7 @@ static void report_good_read2(time_t now, size_t bytes, struct period_head *ph, time_t dt) { struct period *pp; - const char *fmt; - struct tm tm1; + struct tm tm1 __unused; pp = TAILQ_FIRST(ph); if (pp == NULL || pp->t1 < now) { @@ -89,11 +86,6 @@ report_good_read2(time_t now, size_t bytes, struct period_head *ph, time_t dt) pp->t0 = (now / dt) * dt; pp->t1 = (now / dt + 1) * dt; assert(localtime_r(&pp->t0, &tm1) != NULL); - if (dt < 86400) - fmt = "%H:%M"; - else - fmt = "%d%b"; - assert(strftime(pp->str, sizeof pp->str, fmt, &tm1) != 0); TAILQ_INSERT_HEAD(ph, pp, list); } pp->bytes_read += bytes; @@ -149,12 +141,10 @@ static void set_verbose(void) { struct winsize wsz; - time_t t0; if (!isatty(STDIN_FILENO) || ioctl(STDIN_FILENO, TIOCGWINSZ, &wsz)) return; verbose = 1; - t0 = time(NULL); } static void diff --git a/sys/amd64/vmm/vmm_instruction_emul.c b/sys/amd64/vmm/vmm_instruction_emul.c index ae022210893..a2ee81761c7 100644 --- a/sys/amd64/vmm/vmm_instruction_emul.c +++ b/sys/amd64/vmm/vmm_instruction_emul.c @@ -717,21 +717,11 @@ get_gla(void *vm, int vcpuid, struct vie *vie, struct vm_guest_paging *paging, { struct seg_desc desc; uint64_t cr0, val, rflags; - int error; - - error = vie_read_register(vm, vcpuid, VM_REG_GUEST_CR0, &cr0); - KASSERT(error == 0, ("%s: error %d getting cr0", __func__, error)); - - error = vie_read_register(vm, vcpuid, VM_REG_GUEST_RFLAGS, &rflags); - KASSERT(error == 0, ("%s: error %d getting rflags", __func__, error)); - - error = vm_get_seg_desc(vm, vcpuid, seg, &desc); - KASSERT(error == 0, ("%s: error %d getting segment descriptor %d", - __func__, error, seg)); - error = vie_read_register(vm, vcpuid, gpr, &val); - KASSERT(error == 0, ("%s: error %d getting register %d", __func__, - error, gpr)); + vie_read_register(vm, vcpuid, VM_REG_GUEST_CR0, &cr0); + vie_read_register(vm, vcpuid, VM_REG_GUEST_RFLAGS, &rflags); + vm_get_seg_desc(vm, vcpuid, seg, &desc); + vie_read_register(vm, vcpuid, gpr, &val); if (vie_calculate_gla(paging->cpu_mode, seg, &desc, val, opsize, addrsize, prot, gla)) { diff --git a/sys/netinet/libalias/alias.c b/sys/netinet/libalias/alias.c index 39e9b060623..b70c6458c80 100644 --- a/sys/netinet/libalias/alias.c +++ b/sys/netinet/libalias/alias.c @@ -827,7 +827,6 @@ UdpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) u_short dest_port; u_short proxy_server_port; int proxy_type; - int error; size_t dlen; LIBALIAS_LOCK_ASSERT(la); @@ -899,7 +898,7 @@ UdpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) alias_port = GetAliasPort(lnk); /* Walk out chain. */ - error = find_handler(OUT, UDP, la, pip, &ad); + find_handler(OUT, UDP, la, pip, &ad); /* If UDP checksum is not zero, adjust since source port is */ /* being aliased and source address is being altered */ @@ -949,7 +948,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) struct in_addr proxy_address; u_short alias_port; u_short proxy_port; - int accumulate, error; + int accumulate; /* * The init of MANY vars is a bit below, but aliashandlepptpin @@ -968,7 +967,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) }; /* Walk out chain. */ - error = find_handler(IN, TCP, la, pip, &ad); + find_handler(IN, TCP, la, pip, &ad); alias_address = GetAliasAddress(lnk); original_address = GetOriginalAddress(lnk); @@ -1055,7 +1054,7 @@ TcpAliasIn(struct libalias *la, struct ip *pip) static int TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) { - int proxy_type, error; + int proxy_type; u_short dest_port; u_short proxy_server_port; size_t dlen; @@ -1137,7 +1136,7 @@ TcpAliasOut(struct libalias *la, struct ip *pip, int maxpacketsize, int create) TcpMonitorOut(tc->th_flags, lnk); /* Walk out chain. */ - error = find_handler(OUT, TCP, la, pip, &ad); + find_handler(OUT, TCP, la, pip, &ad); /* Adjust TCP checksum since source port is being aliased * and source address is being altered */ diff --git a/usr.bin/backlight/backlight.c b/usr.bin/backlight/backlight.c index 9cf7a0912e9..7c3f295223f 100644 --- a/usr.bin/backlight/backlight.c +++ b/usr.bin/backlight/backlight.c @@ -101,11 +101,9 @@ main(int argc, char *argv[]) long percent = -1; const char *percent_error; uint32_t i; - bool setname; bool quiet = false; action = BACKLIGHT_QUERY; - setname = false; fd = -1; while ((ch = getopt(argc, argv, "f:qhi")) != -1) { @@ -114,7 +112,6 @@ main(int argc, char *argv[]) quiet = true; break; case 'f': - setname = true; set_device_name(optarg); break; case 'i': diff --git a/usr.bin/ipcs/ipc.c b/usr.bin/ipcs/ipc.c index d48389dd54b..6a128ba58b1 100644 --- a/usr.bin/ipcs/ipc.c +++ b/usr.bin/ipcs/ipc.c @@ -106,7 +106,8 @@ static struct scgs_vector msginfo_scgsv[] = { MSGINFO_XVEC { .sysctl=NULL } }; kvm_t *kd; void -sysctlgatherstruct(void *addr, size_t size, struct scgs_vector *vecarr) +sysctlgatherstruct(void *addr, size_t size __unused, + struct scgs_vector *vecarr) { struct scgs_vector *xp; size_t tsiz; diff --git a/usr.bin/mkuzip/mkuzip.c b/usr.bin/mkuzip/mkuzip.c index a2763e06440..43fb4f49d73 100644 --- a/usr.bin/mkuzip/mkuzip.c +++ b/usr.bin/mkuzip/mkuzip.c @@ -128,9 +128,8 @@ int main(int argc, char **argv) uint64_t offset, last_offset; struct cloop_header hdr; struct mkuz_conveyor *cvp; - void *c_ctx; struct mkuz_blk_info *chit; - size_t ncpusz, ncpu, magiclen; + size_t ncpusz, ncpu; double st, et; enum UZ_ALGORITHM comp_alg; int comp_level; @@ -233,8 +232,7 @@ int main(int argc, char **argv) cfs.handler = &uzip_fmts[comp_alg]; - magiclen = strlcpy(hdr.magic, cfs.handler->magic, sizeof(hdr.magic)); - assert(magiclen < sizeof(hdr.magic)); + strlcpy(hdr.magic, cfs.handler->magic, sizeof(hdr.magic)); if (cfs.en_dedup != 0) { /* @@ -255,7 +253,7 @@ int main(int argc, char **argv) errx(1, "maximal compressed cluster size %zu greater than MAXPHYS %zu", cfs.cbound_blksz, (size_t)MAXPHYS); - c_ctx = cfs.handler->f_init(&comp_level); + cfs.handler->f_init(&comp_level); cfs.comp_level = comp_level; cfs.iname = argv[0]; diff --git a/usr.bin/mt/mt.c b/usr.bin/mt/mt.c index a053cdd9213..73b54e24217 100644 --- a/usr.bin/mt/mt.c +++ b/usr.bin/mt/mt.c @@ -1555,15 +1555,12 @@ mt_getdensity(int argc, char **argv, char *xml_str, struct mt_status_data *status_data) { int retval = 0; - int verbose = 0, xml_dump = 0; + int xml_dump = 0; struct mt_status_entry *density_root = NULL; int c; while ((c = getopt(argc, argv, "vx")) != -1) { switch (c) { - case 'v': - verbose = 1; - break; case 'x': xml_dump = 1; break; diff --git a/usr.bin/procstat/procstat.c b/usr.bin/procstat/procstat.c index a1cd082ecb5..bb3b9e9de5a 100644 --- a/usr.bin/procstat/procstat.c +++ b/usr.bin/procstat/procstat.c @@ -236,11 +236,10 @@ static const struct procstat_cmd * getcmdbyprogname(const char *pprogname) { const char *ca; - size_t i, len; + size_t i; if (pprogname == NULL) return (NULL); - len = strlen(pprogname); for (i = 0; i < nitems(pacmd_table); i++) { ca = pacmd_table[i].command; diff --git a/usr.bin/truss/syscalls.c b/usr.bin/truss/syscalls.c index 6740ab21ff2..bdad78e66a2 100644 --- a/usr.bin/truss/syscalls.c +++ b/usr.bin/truss/syscalls.c @@ -977,18 +977,15 @@ print_mask_arg32(bool (*decoder)(FILE *, uint32_t, uint32_t *), FILE *fp, static void quad_fixup(struct syscall_decode *sc) { - int offset, prev; + int offset; u_int i; offset = 0; - prev = -1; for (i = 0; i < sc->nargs; i++) { /* This arg type is a dummy that doesn't use offset. */ if ((sc->args[i].type & ARG_MASK) == PipeFds) continue; - assert(prev < sc->args[i].offset); - prev = sc->args[i].offset; sc->args[i].offset += offset; switch (sc->args[i].type & ARG_MASK) { case Quad: @@ -2128,11 +2125,9 @@ print_arg(struct syscall_arg *sc, unsigned long *args, register_t *retval, fputs(strsig2(args[sc->offset]), fp); break; case Sigset: { - long sig; sigset_t ss; int i, first; - sig = args[sc->offset]; if (get_struct(pid, args[sc->offset], (void *)&ss, sizeof(ss)) == -1) { print_pointer(fp, args[sc->offset]); diff --git a/usr.bin/unifdef/unifdef.c b/usr.bin/unifdef/unifdef.c index 50331d5ad9b..b7381a0b46b 100644 --- a/usr.bin/unifdef/unifdef.c +++ b/usr.bin/unifdef/unifdef.c @@ -1556,7 +1556,7 @@ static void addsym2(bool ignorethis, const char *symname, const char *val) { const char *cp = symname; - struct macro *sym, *r; + struct macro *sym; sym = findsym(&cp); if (sym == NULL) { @@ -1564,8 +1564,7 @@ addsym2(bool ignorethis, const char *symname, const char *val) sym->ignore = ignorethis; sym->name = symname; sym->value = val; - r = RB_INSERT(MACROMAP, ¯o_tree, sym); - assert(r == NULL); + RB_INSERT(MACROMAP, ¯o_tree, sym); } debugsym("addsym", sym); } diff --git a/usr.bin/units/units.c b/usr.bin/units/units.c index 02aeb60606f..f547ab66acc 100644 --- a/usr.bin/units/units.c +++ b/usr.bin/units/units.c @@ -763,11 +763,9 @@ main(int argc, char **argv) EditLine *el; HistEvent ev; int inputsz; - char const * history_file; quiet = false; readfile = false; - history_file = NULL; outputformat = numfmt; quit = false; while ((optchar = getopt_long(argc, argv, "+ehf:o:qtvH:UV", longopts, NULL)) != -1) { @@ -782,9 +780,6 @@ main(int argc, char **argv) else readunits(optarg); break; - case 'H': - history_file = optarg; - break; case 'q': quiet = true; break; diff --git a/usr.bin/vmstat/vmstat.c b/usr.bin/vmstat/vmstat.c index 403dc6e2a05..7318d0ed6f1 100644 --- a/usr.bin/vmstat/vmstat.c +++ b/usr.bin/vmstat/vmstat.c @@ -670,12 +670,11 @@ dovmstat(unsigned int interval, int reps) u_long cpumask; size_t size; time_t uptime, halfuptime; - int ncpus, maxid, rate_adj, retval; + int maxid, rate_adj, retval; uptime = getuptime() / 1000000000LL; halfuptime = uptime / 2; rate_adj = 1; - ncpus = 1; maxid = 0; cpumask = 0; @@ -714,7 +713,6 @@ dovmstat(unsigned int interval, int reps) } if (Pflag) { - ncpus = getcpuinfo(&cpumask, &maxid); size_cp_times = sizeof(long) * (maxid + 1) * CPUSTATES; cur_cp_times = calloc(1, size_cp_times); last_cp_times = calloc(1, size_cp_times); diff --git a/usr.bin/vtfontcvt/vtfontcvt.c b/usr.bin/vtfontcvt/vtfontcvt.c index fbfc0539b4d..86b06a9a6f2 100644 --- a/usr.bin/vtfontcvt/vtfontcvt.c +++ b/usr.bin/vtfontcvt/vtfontcvt.c @@ -721,12 +721,9 @@ write_mappings(FILE *fp, unsigned int map_idx) struct mapping_list *ml = &maps[map_idx]; struct mapping *mp; vfnt_map_t fm; - unsigned int i = 0, j = 0; TAILQ_FOREACH(mp, ml, m_list) { - j++; if (mp->m_length > 0) { - i += mp->m_length; fm.vfm_src = htobe32(mp->m_char); fm.vfm_dst = htobe16(mp->m_glyph->g_index); fm.vfm_len = htobe16(mp->m_length - 1); @@ -734,7 +731,6 @@ write_mappings(FILE *fp, unsigned int map_idx) return (1); } } - assert(i == j); return (0); } @@ -743,19 +739,15 @@ write_source_mappings(FILE *fp, unsigned int map_idx) { struct mapping_list *ml = &maps[map_idx]; struct mapping *mp; - unsigned int i = 0, j = 0; TAILQ_FOREACH(mp, ml, m_list) { - j++; if (mp->m_length > 0) { - i += mp->m_length; if (fprintf(fp, "\t{ 0x%08x, 0x%04x, 0x%04x },\n", mp->m_char, mp->m_glyph->g_index, mp->m_length - 1) < 0) return (1); } } - assert(i == j); return (0); } diff --git a/usr.sbin/acpi/acpidump/acpi.c b/usr.sbin/acpi/acpidump/acpi.c index adb5b968f44..25a0f577b20 100644 --- a/usr.sbin/acpi/acpidump/acpi.c +++ b/usr.sbin/acpi/acpidump/acpi.c @@ -1576,7 +1576,6 @@ acpi_print_nfit(ACPI_NFIT_HEADER *nfit) ACPI_NFIT_SYSTEM_ADDRESS *sysaddr; ACPI_NFIT_MEMORY_MAP *mmap; ACPI_NFIT_INTERLEAVE *ileave; - ACPI_NFIT_SMBIOS *smbios; ACPI_NFIT_CONTROL_REGION *ctlreg; ACPI_NFIT_DATA_REGION *datareg; ACPI_NFIT_FLUSH_ADDRESS *fladdr; @@ -1650,10 +1649,6 @@ acpi_print_nfit(ACPI_NFIT_HEADER *nfit) printf("\tLineSize=%u\n", (u_int)ileave->LineSize); /* XXX ileave->LineOffset[i] output is not supported */ break; - case ACPI_NFIT_TYPE_SMBIOS: - smbios = (ACPI_NFIT_SMBIOS *)nfit; - /* XXX smbios->Data[x] output is not supported */ - break; case ACPI_NFIT_TYPE_CONTROL_REGION: ctlreg = (ACPI_NFIT_CONTROL_REGION *)nfit; printf("\tRegionIndex=%u\n", (u_int)ctlreg->RegionIndex); diff --git a/usr.sbin/bhyve/atkbdc.c b/usr.sbin/bhyve/atkbdc.c index a08f58f84b2..df0f2661c8a 100644 --- a/usr.sbin/bhyve/atkbdc.c +++ b/usr.sbin/bhyve/atkbdc.c @@ -397,7 +397,7 @@ atkbdc_sts_ctl_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { struct atkbdc_softc *sc; - int error, retval; + int retval; if (bytes != 1) return (-1); @@ -467,8 +467,7 @@ atkbdc_sts_ctl_handler(struct vmctx *ctx, int vcpu, int in, int port, sc->status |= KBDS_AUX_BUFFER_FULL | KBDS_KBD_BUFFER_FULL; break; case KBDC_RESET: /* Pulse "reset" line */ - error = vm_suspend(ctx, VM_SUSPEND_RESET); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_RESET); break; default: if (*eax >= 0x21 && *eax <= 0x3f) { @@ -516,7 +515,6 @@ atkbdc_init(struct vmctx *ctx) { struct inout_port iop; struct atkbdc_softc *sc; - int error; sc = calloc(1, sizeof(struct atkbdc_softc)); sc->ctx = ctx; @@ -531,8 +529,7 @@ atkbdc_init(struct vmctx *ctx) iop.handler = atkbdc_sts_ctl_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); bzero(&iop, sizeof(struct inout_port)); iop.name = "atkdbc"; @@ -542,8 +539,7 @@ atkbdc_init(struct vmctx *ctx) iop.handler = atkbdc_data_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); pci_irq_reserve(KBD_DEV_IRQ); sc->kbd.irq = KBD_DEV_IRQ; diff --git a/usr.sbin/bhyve/bhyverun.c b/usr.sbin/bhyve/bhyverun.c index e4d96d2293f..d5bfc00f35d 100644 --- a/usr.sbin/bhyve/bhyverun.c +++ b/usr.sbin/bhyve/bhyverun.c @@ -488,14 +488,13 @@ vm_inject_fault(void *arg, int vcpu, int vector, int errcode_valid, int errcode) { struct vmctx *ctx; - int error, restart_instruction; + int restart_instruction; ctx = arg; restart_instruction = 1; - error = vm_inject_exception(ctx, vcpu, vector, errcode_valid, errcode, + vm_inject_exception(ctx, vcpu, vector, errcode_valid, errcode, restart_instruction); - assert(error == 0); } void * @@ -1136,15 +1135,12 @@ do_open(const char *vmname) void spinup_vcpu(struct vmctx *ctx, int vcpu) { - int error; uint64_t rip; - error = vm_get_register(ctx, vcpu, VM_REG_GUEST_RIP, &rip); - assert(error == 0); + vm_get_register(ctx, vcpu, VM_REG_GUEST_RIP, &rip); fbsdrun_set_capabilities(ctx, vcpu); - error = vm_set_capability(ctx, vcpu, VM_CAP_UNRESTRICTED_GUEST, 1); - assert(error == 0); + vm_set_capability(ctx, vcpu, VM_CAP_UNRESTRICTED_GUEST, 1); fbsdrun_addcpu(ctx, BSP, vcpu, rip); } diff --git a/usr.sbin/bhyve/gdb.c b/usr.sbin/bhyve/gdb.c index 219d192b7c9..0ff15bdef5b 100644 --- a/usr.sbin/bhyve/gdb.c +++ b/usr.sbin/bhyve/gdb.c @@ -780,7 +780,6 @@ static void gdb_cpu_resume(int vcpu) { struct vcpu_state *vs; - int error; vs = &vcpu_state[vcpu]; @@ -791,8 +790,7 @@ gdb_cpu_resume(int vcpu) assert(vs->hit_swbreak == false); assert(vs->stepped == false); if (vs->stepping) { - error = vm_set_capability(ctx, vcpu, VM_CAP_MTRAP_EXIT, 1); - assert(error == 0); + vm_set_capability(ctx, vcpu, VM_CAP_MTRAP_EXIT, 1); } } @@ -874,15 +872,13 @@ gdb_cpu_breakpoint(int vcpu, struct vm_exit *vmexit) struct breakpoint *bp; struct vcpu_state *vs; uint64_t gpa; - int error; if (!gdb_active) { fprintf(stderr, "vm_loop: unexpected VMEXIT_DEBUG\n"); exit(4); } pthread_mutex_lock(&gdb_lock); - error = guest_vaddr2paddr(vcpu, vmexit->rip, &gpa); - assert(error == 1); + guest_vaddr2paddr(vcpu, vmexit->rip, &gpa); bp = find_breakpoint(gpa); if (bp != NULL) { vs = &vcpu_state[vcpu]; @@ -914,11 +910,9 @@ gdb_cpu_breakpoint(int vcpu, struct vm_exit *vmexit) } else { debug("$vCPU %d injecting breakpoint at rip %#lx\n", vcpu, vmexit->rip); - error = vm_set_register(ctx, vcpu, + vm_set_register(ctx, vcpu, VM_REG_GUEST_ENTRY_INST_LENGTH, vmexit->u.bpt.inst_length); - assert(error == 0); - error = vm_inject_exception(ctx, vcpu, IDT_BP, 0, 0, 0); - assert(error == 0); + vm_inject_exception(ctx, vcpu, IDT_BP, 0, 0, 0); } pthread_mutex_unlock(&gdb_lock); } diff --git a/usr.sbin/bhyve/hda_codec.c b/usr.sbin/bhyve/hda_codec.c index 7a6ba345d8e..45dfdc898e7 100644 --- a/usr.sbin/bhyve/hda_codec.c +++ b/usr.sbin/bhyve/hda_codec.c @@ -395,7 +395,6 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, { struct hda_codec_softc *sc = NULL; struct hda_codec_stream *st = NULL; - int err; if (!(play || rec)) return (-1); @@ -426,10 +425,9 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, if (play) { st = &sc->streams[HDA_CODEC_STREAM_OUTPUT]; - err = hda_audio_ctxt_init(&st->actx, "hda-audio-output", + hda_audio_ctxt_init(&st->actx, "hda-audio-output", hda_codec_audio_output_do_transfer, hda_codec_audio_output_do_setup, sc); - assert(!err); st->aud = audio_init(play, 1); if (!st->aud) { @@ -444,10 +442,9 @@ hda_codec_init(struct hda_codec_inst *hci, const char *play, if (rec) { st = &sc->streams[HDA_CODEC_STREAM_INPUT]; - err = hda_audio_ctxt_init(&st->actx, "hda-audio-input", + hda_audio_ctxt_init(&st->actx, "hda-audio-input", hda_codec_audio_input_do_transfer, hda_codec_audio_input_do_setup, sc); - assert(!err); st->aud = audio_init(rec, 0); if (!st->aud) { @@ -743,7 +740,6 @@ hda_codec_audio_input_do_transfer(void *arg) struct hda_ops *hops = NULL; struct hda_codec_stream *st = NULL; struct audio *aud = NULL; - int err; hci = sc->hci; assert(hci); @@ -754,8 +750,7 @@ hda_codec_audio_input_do_transfer(void *arg) st = &sc->streams[HDA_CODEC_STREAM_INPUT]; aud = st->aud; - err = audio_record(aud, st->buf, sizeof(st->buf)); - assert(!err); + audio_record(aud, st->buf, sizeof(st->buf)); hops->transfer(hci, st->stream, 0, st->buf, sizeof(st->buf)); } @@ -884,8 +879,6 @@ static int hda_audio_ctxt_init(struct hda_audio_ctxt *actx, const char *tname, transfer_func_t do_transfer, setup_func_t do_setup, void *priv) { - int err; - assert(actx); assert(tname); assert(do_transfer); @@ -903,14 +896,11 @@ hda_audio_ctxt_init(struct hda_audio_ctxt *actx, const char *tname, else strcpy(actx->name, "unknown"); - err = pthread_mutex_init(&actx->mtx, NULL); - assert(!err); + pthread_mutex_init(&actx->mtx, NULL); - err = pthread_cond_init(&actx->cond, NULL); - assert(!err); + pthread_cond_init(&actx->cond, NULL); - err = pthread_create(&actx->tid, NULL, hda_audio_ctxt_thr, actx); - assert(!err); + pthread_create(&actx->tid, NULL, hda_audio_ctxt_thr, actx); pthread_set_name_np(actx->tid, tname); diff --git a/usr.sbin/bhyve/mem.c b/usr.sbin/bhyve/mem.c index 90aefe45c85..588e116c3b1 100644 --- a/usr.sbin/bhyve/mem.c +++ b/usr.sbin/bhyve/mem.c @@ -169,7 +169,7 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, void *arg) { struct mmio_rb_range *entry; - int err, perror, immutable; + int err, immutable; pthread_rwlock_rdlock(&mmio_rwlock); /* @@ -187,8 +187,7 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, /* Update the per-vCPU cache */ mmio_hint[vcpu] = entry; } else if (mmio_rb_lookup(&mmio_rb_fallback, paddr, &entry)) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); return (ESRCH); } } @@ -208,15 +207,13 @@ access_memory(struct vmctx *ctx, int vcpu, uint64_t paddr, mem_cb_t *cb, */ immutable = (entry->mr_param.flags & MEM_F_IMMUTABLE); if (immutable) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); } err = cb(ctx, vcpu, paddr, &entry->mr_param, arg); if (!immutable) { - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); } @@ -294,7 +291,7 @@ static int register_mem_int(struct mmio_rb_tree *rbt, struct mem_range *memp) { struct mmio_rb_range *entry, *mrp; - int err, perror; + int err; err = 0; @@ -310,8 +307,7 @@ register_mem_int(struct mmio_rb_tree *rbt, struct mem_range *memp) pthread_rwlock_wrlock(&mmio_rwlock); if (mmio_rb_lookup(rbt, memp->base, &entry) != 0) err = mmio_rb_add(rbt, mrp); - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); if (err) free(mrp); } @@ -336,17 +332,12 @@ register_mem_fallback(struct mem_range *memp) int unregister_mem(struct mem_range *memp) { - struct mem_range *mr; struct mmio_rb_range *entry = NULL; - int err, perror, i; + int err, i; pthread_rwlock_wrlock(&mmio_rwlock); err = mmio_rb_lookup(&mmio_rb_root, memp->base, &entry); if (err == 0) { - mr = &entry->mr_param; - assert(mr->name == memp->name); - assert(mr->base == memp->base && mr->size == memp->size); - assert((mr->flags & MEM_F_IMMUTABLE) == 0); RB_REMOVE(mmio_rb_tree, &mmio_rb_root, entry); /* flush Per-vCPU cache */ @@ -355,8 +346,7 @@ unregister_mem(struct mem_range *memp) mmio_hint[i] = NULL; } } - perror = pthread_rwlock_unlock(&mmio_rwlock); - assert(perror == 0); + pthread_rwlock_unlock(&mmio_rwlock); if (entry) free(entry); diff --git a/usr.sbin/bhyve/mevent.c b/usr.sbin/bhyve/mevent.c index 0c5351cd31a..2ce2f655ba6 100644 --- a/usr.sbin/bhyve/mevent.c +++ b/usr.sbin/bhyve/mevent.c @@ -475,7 +475,6 @@ mevent_dispatch(void) { struct kevent changelist[MEVENT_MAX]; struct kevent eventlist[MEVENT_MAX]; - struct mevent *pipev; int numev; int ret; #ifndef WITHOUT_CAPSICUM @@ -509,8 +508,7 @@ mevent_dispatch(void) /* * Add internal event handler for the pipe write fd */ - pipev = mevent_add(mevent_pipefd[0], EVF_READ, mevent_pipe_read, NULL); - assert(pipev != NULL); + mevent_add(mevent_pipefd[0], EVF_READ, mevent_pipe_read, NULL); for (;;) { /* diff --git a/usr.sbin/bhyve/pci_ahci.c b/usr.sbin/bhyve/pci_ahci.c index 38ec87c34ee..d6c301492d4 100644 --- a/usr.sbin/bhyve/pci_ahci.c +++ b/usr.sbin/bhyve/pci_ahci.c @@ -672,7 +672,7 @@ ahci_handle_rw(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) struct ahci_cmd_hdr *hdr; uint64_t lba; uint32_t len; - int err, first, ncq, readop; + int first, ncq, readop; prdt = (struct ahci_prdt_entry *)(cfis + 0x80); hdr = (struct ahci_cmd_hdr *)(p->cmd_lst + slot * AHCI_CL_SIZE); @@ -744,10 +744,9 @@ ahci_handle_rw(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) ahci_write_fis_d2h_ncq(p, slot); if (readop) - err = blockif_read(p->bctx, breq); + blockif_read(p->bctx, breq); else - err = blockif_write(p->bctx, breq); - assert(err == 0); + blockif_write(p->bctx, breq); } static void @@ -755,7 +754,6 @@ ahci_handle_flush(struct ahci_port *p, int slot, uint8_t *cfis) { struct ahci_ioreq *aior; struct blockif_req *breq; - int err; /* * Pull request off free list @@ -780,8 +778,7 @@ ahci_handle_flush(struct ahci_port *p, int slot, uint8_t *cfis) */ TAILQ_INSERT_HEAD(&p->iobhd, aior, io_blist); - err = blockif_flush(p->bctx, breq); - assert(err == 0); + blockif_flush(p->bctx, breq); } static inline void @@ -820,7 +817,7 @@ ahci_handle_dsm_trim(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done uint8_t *entry; uint64_t elba; uint32_t len, elen; - int err, first, ncq; + int first, ncq; uint8_t buf[512]; first = (done == 0); @@ -894,8 +891,7 @@ next: if (ncq && first) ahci_write_fis_d2h_ncq(p, slot); - err = blockif_delete(p->bctx, breq); - assert(err == 0); + blockif_delete(p->bctx, breq); } static inline void @@ -1402,7 +1398,6 @@ atapi_read(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) uint8_t *acmd; uint64_t lba; uint32_t len; - int err; acmd = cfis + 0x40; hdr = (struct ahci_cmd_hdr *)(p->cmd_lst + slot * AHCI_CL_SIZE); @@ -1441,8 +1436,7 @@ atapi_read(struct ahci_port *p, int slot, uint8_t *cfis, uint32_t done) /* Stuff request onto busy list. */ TAILQ_INSERT_HEAD(&p->iobhd, aior, io_blist); - err = blockif_read(p->bctx, breq); - assert(err == 0); + blockif_read(p->bctx, breq); } static void diff --git a/usr.sbin/bhyve/pci_e82545.c b/usr.sbin/bhyve/pci_e82545.c index d0b4fb9e466..7688cbc205b 100644 --- a/usr.sbin/bhyve/pci_e82545.c +++ b/usr.sbin/bhyve/pci_e82545.c @@ -1084,7 +1084,7 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, struct ck_info ckinfo[2]; struct iovec *iov; union e1000_tx_udesc *dsc; - int desc, dtype, len, ntype, iovcnt, tlen, tcp, tso; + int desc, dtype, len, iovcnt, tcp, tso; int mss, paylen, seg, tiovcnt, left, now, nleft, nnow, pv, pvoff; unsigned hdrlen, vlen; uint32_t tcpsum, tcpseq; @@ -1092,8 +1092,6 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, ckinfo[0].ck_valid = ckinfo[1].ck_valid = 0; iovcnt = 0; - tlen = 0; - ntype = 0; tso = 0; ohead = head; @@ -1124,20 +1122,17 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, /* * legacy cksum start valid in first descriptor */ - ntype = dtype; ckinfo[0].ck_start = dsc->td.upper.fields.css; break; case E1000_TXD_TYP_D: DPRINTF("tx data desc idx %d: %08x%08x", head, dsc->td.upper.data, dsc->td.lower.data); - ntype = dtype; break; default: break; } } else { /* Descriptor type must be consistent */ - assert(dtype == ntype); DPRINTF("tx next desc idx %d: %08x%08x", head, dsc->td.upper.data, dsc->td.lower.data); } @@ -1150,7 +1145,6 @@ e82545_transmit(struct e82545_softc *sc, uint16_t head, uint16_t tail, if ((dsc->td.lower.data & E1000_TXD_CMD_EOP) != 0 && (dsc->td.lower.data & E1000_TXD_CMD_IFCS) == 0) len -= 2; - tlen += len; if (iovcnt < I82545_MAX_TXSEGS) { iov[iovcnt].iov_base = paddr_guest2host( sc->esc_ctx, dsc->td.buffer_addr, len); diff --git a/usr.sbin/bhyve/pci_emul.c b/usr.sbin/bhyve/pci_emul.c index d155029d269..aca69cbf88f 100644 --- a/usr.sbin/bhyve/pci_emul.c +++ b/usr.sbin/bhyve/pci_emul.c @@ -507,7 +507,6 @@ static void modify_bar_registration(struct pci_devinst *pi, int idx, int registration) { struct pci_devemu *pe; - int error; struct inout_port iop; struct mem_range mr; @@ -522,9 +521,9 @@ modify_bar_registration(struct pci_devinst *pi, int idx, int registration) iop.flags = IOPORT_F_INOUT; iop.handler = pci_emul_io_handler; iop.arg = pi; - error = register_inout(&iop); + register_inout(&iop); } else - error = unregister_inout(&iop); + unregister_inout(&iop); if (pe->pe_baraddr != NULL) (*pe->pe_baraddr)(pi->pi_vmctx, pi, idx, registration, pi->pi_bar[idx].addr); @@ -540,18 +539,14 @@ modify_bar_registration(struct pci_devinst *pi, int idx, int registration) mr.handler = pci_emul_mem_handler; mr.arg1 = pi; mr.arg2 = idx; - error = register_mem(&mr); + register_mem(&mr); } else - error = unregister_mem(&mr); + unregister_mem(&mr); if (pe->pe_baraddr != NULL) (*pe->pe_baraddr)(pi->pi_vmctx, pi, idx, registration, pi->pi_bar[idx].addr); break; - default: - error = EINVAL; - break; } - assert(error == 0); } static void @@ -2253,7 +2248,6 @@ struct pci_emul_dsoftc { static int pci_emul_dinit(struct vmctx *ctx, struct pci_devinst *pi, nvlist_t *nvl) { - int error; struct pci_emul_dsoftc *sc; sc = calloc(1, sizeof(struct pci_emul_dsoftc)); @@ -2264,17 +2258,13 @@ pci_emul_dinit(struct vmctx *ctx, struct pci_devinst *pi, nvlist_t *nvl) pci_set_cfgdata16(pi, PCIR_VENDOR, 0x10DD); pci_set_cfgdata8(pi, PCIR_CLASS, 0x02); - error = pci_emul_add_msicap(pi, PCI_EMUL_MSI_MSGS); - assert(error == 0); + pci_emul_add_msicap(pi, PCI_EMUL_MSI_MSGS); - error = pci_emul_alloc_bar(pi, 0, PCIBAR_IO, DIOSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 0, PCIBAR_IO, DIOSZ); - error = pci_emul_alloc_bar(pi, 1, PCIBAR_MEM32, DMEMSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 1, PCIBAR_MEM32, DMEMSZ); - error = pci_emul_alloc_bar(pi, 2, PCIBAR_MEM32, DMEMSZ); - assert(error == 0); + pci_emul_alloc_bar(pi, 2, PCIBAR_MEM32, DMEMSZ); return (0); } diff --git a/usr.sbin/bhyve/pci_hda.c b/usr.sbin/bhyve/pci_hda.c index 7491944fedd..d8677088301 100644 --- a/usr.sbin/bhyve/pci_hda.c +++ b/usr.sbin/bhyve/pci_hda.c @@ -325,7 +325,6 @@ hda_init(nvlist_t *nvl) const char *value; char *play; char *rec; - int err; #if DEBUG_HDA == 1 dbg = fopen("/tmp/bhyve_hda.log", "w+"); @@ -355,8 +354,7 @@ hda_init(nvlist_t *nvl) rec = strdup(value); DPRINTF("play: %s rec: %s", play, rec); if (play != NULL || rec != NULL) { - err = hda_codec_constructor(sc, codec, play, rec); - assert(!err); + hda_codec_constructor(sc, codec, play, rec); } free(play); free(rec); @@ -786,7 +784,6 @@ hda_corb_run(struct hda_softc *sc) { struct hda_codec_cmd_ctl *corb = &sc->corb; uint32_t verb = 0; - int err; corb->wp = hda_get_reg_by_offset(sc, HDAC_CORBWP); @@ -797,8 +794,7 @@ hda_corb_run(struct hda_softc *sc) verb = hda_dma_ld_dword(corb->dma_vaddr + \ HDA_CORB_ENTRY_LEN * corb->rp); - err = hda_send_command(sc, verb); - assert(!err); + hda_send_command(sc, verb); } hda_set_reg_by_offset(sc, HDAC_CORBRP, corb->rp); @@ -923,13 +919,11 @@ static void hda_set_corbctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; struct hda_codec_cmd_ctl *corb = NULL; if (value & HDAC_CORBCTL_CORBRUN) { if (!(old & HDAC_CORBCTL_CORBRUN)) { - err = hda_corb_start(sc); - assert(!err); + hda_corb_start(sc); } } else { corb = &sc->corb; @@ -943,12 +937,10 @@ static void hda_set_rirbctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; struct hda_codec_cmd_ctl *rirb = NULL; if (value & HDAC_RIRBCTL_RIRBDMAEN) { - err = hda_rirb_start(sc); - assert(!err); + hda_rirb_start(sc); } else { rirb = &sc->rirb; memset(rirb, 0, sizeof(*rirb)); @@ -1005,7 +997,6 @@ hda_set_sdctl(struct hda_softc *sc, uint32_t offset, uint32_t old) { uint8_t stream_ind = hda_get_stream_by_offsets(offset, HDAC_SDCTL0); uint32_t value = hda_get_reg_by_offset(sc, offset); - int err; DPRINTF("stream_ind: 0x%x old: 0x%x value: 0x%x", stream_ind, old, value); @@ -1016,11 +1007,9 @@ hda_set_sdctl(struct hda_softc *sc, uint32_t offset, uint32_t old) if ((value & HDAC_SDCTL_RUN) != (old & HDAC_SDCTL_RUN)) { if (value & HDAC_SDCTL_RUN) { - err = hda_stream_start(sc, stream_ind); - assert(!err); + hda_stream_start(sc, stream_ind); } else { - err = hda_stream_stop(sc, stream_ind); - assert(!err); + hda_stream_stop(sc, stream_ind); } } } @@ -1212,10 +1201,8 @@ hda_set_pib(struct hda_softc *sc, uint8_t stream_ind, uint32_t pib) static uint64_t hda_get_clock_ns(void) { struct timespec ts; - int err; - err = clock_gettime(CLOCK_MONOTONIC, &ts); - assert(!err); + clock_gettime(CLOCK_MONOTONIC, &ts); return (ts.tv_sec * 1000000000LL + ts.tv_nsec); } @@ -1261,7 +1248,6 @@ pci_hda_write(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, int baridx, uint64_t offset, int size, uint64_t value) { struct hda_softc *sc = pi->pi_arg; - int err; assert(sc); assert(baridx == 0); @@ -1269,8 +1255,7 @@ pci_hda_write(struct vmctx *ctx, int vcpu, struct pci_devinst *pi, DPRINTF("offset: 0x%lx value: 0x%lx", offset, value); - err = hda_write(sc, offset, size, value); - assert(!err); + hda_write(sc, offset, size, value); } static uint64_t diff --git a/usr.sbin/bhyve/pci_virtio_block.c b/usr.sbin/bhyve/pci_virtio_block.c index 385b812be84..946fa4d3a67 100644 --- a/usr.sbin/bhyve/pci_virtio_block.c +++ b/usr.sbin/bhyve/pci_virtio_block.c @@ -305,7 +305,6 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) struct virtio_blk_hdr *vbh; struct pci_vtblk_ioreq *io; int i, n; - int err; ssize_t iolen; int writeop, type; struct vi_req req; @@ -363,10 +362,10 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) switch (type) { case VBH_OP_READ: - err = blockif_read(sc->bc, &io->io_req); + blockif_read(sc->bc, &io->io_req); break; case VBH_OP_WRITE: - err = blockif_write(sc->bc, &io->io_req); + blockif_write(sc->bc, &io->io_req); break; case VBH_OP_DISCARD: /* @@ -406,11 +405,11 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) io->io_req.br_offset = discard->sector * VTBLK_BSIZE; io->io_req.br_resid = discard->num_sectors * VTBLK_BSIZE; - err = blockif_delete(sc->bc, &io->io_req); + blockif_delete(sc->bc, &io->io_req); break; case VBH_OP_FLUSH: case VBH_OP_FLUSH_OUT: - err = blockif_flush(sc->bc, &io->io_req); + blockif_flush(sc->bc, &io->io_req); break; case VBH_OP_IDENT: /* Assume a single buffer */ @@ -424,7 +423,6 @@ pci_vtblk_proc(struct pci_vtblk_softc *sc, struct vqueue_info *vq) pci_vtblk_done_locked(io, EOPNOTSUPP); return; } - assert(err == 0); } static void diff --git a/usr.sbin/bhyve/pci_virtio_console.c b/usr.sbin/bhyve/pci_virtio_console.c index 71c3375a57a..e22da0357cf 100644 --- a/usr.sbin/bhyve/pci_virtio_console.c +++ b/usr.sbin/bhyve/pci_virtio_console.c @@ -575,15 +575,13 @@ pci_vtcon_control_send(struct pci_vtcon_softc *sc, struct vqueue_info *vq; struct vi_req req; struct iovec iov; - int n; vq = pci_vtcon_port_to_vq(&sc->vsc_control_port, true); if (!vq_has_descs(vq)) return; - n = vq_getchain(vq, &iov, 1, &req); - assert(n == 1); + vq_getchain(vq, &iov, 1, &req); memcpy(iov.iov_base, ctrl, sizeof(struct pci_vtcon_control)); if (payload != NULL && len > 0) @@ -602,14 +600,12 @@ pci_vtcon_notify_tx(void *vsc, struct vqueue_info *vq) struct pci_vtcon_port *port; struct iovec iov[1]; struct vi_req req; - int n; sc = vsc; port = pci_vtcon_vq_to_port(sc, vq); while (vq_has_descs(vq)) { - n = vq_getchain(vq, iov, 1, &req); - assert(n == 1); + vq_getchain(vq, iov, 1, &req); if (port != NULL) port->vsp_cb(port, port->vsp_arg, iov, 1); diff --git a/usr.sbin/bhyve/pci_virtio_net.c b/usr.sbin/bhyve/pci_virtio_net.c index d253b081d13..aad2e133b03 100644 --- a/usr.sbin/bhyve/pci_virtio_net.c +++ b/usr.sbin/bhyve/pci_virtio_net.c @@ -506,7 +506,6 @@ pci_vtnet_tx_thread(void *param) { struct pci_vtnet_softc *sc = param; struct vqueue_info *vq; - int error; vq = &sc->vsc_queues[VTNET_TXQ]; @@ -515,8 +514,7 @@ pci_vtnet_tx_thread(void *param) * first tx signaled */ pthread_mutex_lock(&sc->tx_mtx); - error = pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); - assert(error == 0); + pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); for (;;) { /* note - tx mutex is locked here */ @@ -526,8 +524,7 @@ pci_vtnet_tx_thread(void *param) break; sc->tx_in_progress = 0; - error = pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); - assert(error == 0); + pthread_cond_wait(&sc->tx_cond, &sc->tx_mtx); } vq_kick_disable(vq); sc->tx_in_progress = 1; diff --git a/usr.sbin/bhyve/pci_virtio_rnd.c b/usr.sbin/bhyve/pci_virtio_rnd.c index 7274d0b0591..1d2d6144f94 100644 --- a/usr.sbin/bhyve/pci_virtio_rnd.c +++ b/usr.sbin/bhyve/pci_virtio_rnd.c @@ -114,7 +114,7 @@ pci_vtrnd_notify(void *vsc, struct vqueue_info *vq) struct iovec iov; struct pci_vtrnd_softc *sc; struct vi_req req; - int len, n; + int len; sc = vsc; @@ -124,8 +124,7 @@ pci_vtrnd_notify(void *vsc, struct vqueue_info *vq) } while (vq_has_descs(vq)) { - n = vq_getchain(vq, &iov, 1, &req); - assert(n == 1); + vq_getchain(vq, &iov, 1, &req); len = read(sc->vrsc_fd, iov.iov_base, iov.iov_len); diff --git a/usr.sbin/bhyve/pci_virtio_scsi.c b/usr.sbin/bhyve/pci_virtio_scsi.c index f4a701c0e25..0554fcecb81 100644 --- a/usr.sbin/bhyve/pci_virtio_scsi.c +++ b/usr.sbin/bhyve/pci_virtio_scsi.c @@ -598,14 +598,12 @@ pci_vtscsi_requestq_notify(void *vsc, struct vqueue_info *vq) struct pci_vtscsi_request *req; struct iovec iov[VTSCSI_MAXSEG]; struct vi_req vireq; - int n; sc = vsc; q = &sc->vss_queues[vq->vq_num - 2]; while (vq_has_descs(vq)) { - n = vq_getchain(vq, iov, VTSCSI_MAXSEG, &vireq); - assert(n >= 1 && n <= VTSCSI_MAXSEG); + vq_getchain(vq, iov, VTSCSI_MAXSEG, &vireq); req = calloc(1, sizeof(struct pci_vtscsi_request)); req->vsr_idx = vireq.idx; diff --git a/usr.sbin/bhyve/pm.c b/usr.sbin/bhyve/pm.c index 9f467cb591e..30357679ffd 100644 --- a/usr.sbin/bhyve/pm.c +++ b/usr.sbin/bhyve/pm.c @@ -63,8 +63,6 @@ static int reset_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { - int error; - static uint8_t reset_control; if (bytes != 1) @@ -76,8 +74,7 @@ reset_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, /* Treat hard and soft resets the same. */ if (reset_control & 0x4) { - error = vm_suspend(ctx, VM_SUSPEND_RESET); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_RESET); } } return (0); @@ -238,8 +235,6 @@ static int pm1_control_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, uint32_t *eax, void *arg) { - int error; - if (bytes != 2) return (-1); if (in) @@ -259,8 +254,7 @@ pm1_control_handler(struct vmctx *ctx, int vcpu, int in, int port, int bytes, */ if (*eax & PM1_SLP_EN) { if ((pm1_control & PM1_SLP_TYP) >> 10 == 5) { - error = vm_suspend(ctx, VM_SUSPEND_POWEROFF); - assert(error == 0 || errno == EALREADY); + vm_suspend(ctx, VM_SUSPEND_POWEROFF); } } } diff --git a/usr.sbin/bhyve/rtc.c b/usr.sbin/bhyve/rtc.c index 0f63156adb9..777c8316492 100644 --- a/usr.sbin/bhyve/rtc.c +++ b/usr.sbin/bhyve/rtc.c @@ -78,7 +78,6 @@ rtc_init(struct vmctx *ctx) { size_t himem; size_t lomem; - int err; /* XXX init diag/reset code/equipment/checksum ? */ @@ -89,21 +88,15 @@ rtc_init(struct vmctx *ctx) * 0x5b/0x5c/0x5d - 64KB chunks above 4GB */ lomem = (vm_get_lowmem_size(ctx) - m_16MB) / m_64KB; - err = vm_rtc_write(ctx, RTC_LMEM_LSB, lomem); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_LMEM_MSB, lomem >> 8); - assert(err == 0); + vm_rtc_write(ctx, RTC_LMEM_LSB, lomem); + vm_rtc_write(ctx, RTC_LMEM_MSB, lomem >> 8); himem = vm_get_highmem_size(ctx) / m_64KB; - err = vm_rtc_write(ctx, RTC_HMEM_LSB, himem); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_HMEM_SB, himem >> 8); - assert(err == 0); - err = vm_rtc_write(ctx, RTC_HMEM_MSB, himem >> 16); - assert(err == 0); - - err = vm_rtc_settime(ctx, rtc_time(ctx)); - assert(err == 0); + vm_rtc_write(ctx, RTC_HMEM_LSB, himem); + vm_rtc_write(ctx, RTC_HMEM_SB, himem >> 8); + vm_rtc_write(ctx, RTC_HMEM_MSB, himem >> 16); + + vm_rtc_settime(ctx, rtc_time(ctx)); } static void diff --git a/usr.sbin/bhyve/spinup_ap.c b/usr.sbin/bhyve/spinup_ap.c index 7c4186f5ed1..7f254f79c53 100644 --- a/usr.sbin/bhyve/spinup_ap.c +++ b/usr.sbin/bhyve/spinup_ap.c @@ -47,7 +47,7 @@ __FBSDID("$FreeBSD$"); static void spinup_ap_realmode(struct vmctx *ctx, int newcpu, uint64_t *rip) { - int vector, error; + int vector; uint16_t cs; uint64_t desc_base; uint32_t desc_limit, desc_access; @@ -59,33 +59,26 @@ spinup_ap_realmode(struct vmctx *ctx, int newcpu, uint64_t *rip) * Update the %cs and %rip of the guest so that it starts * executing real mode code at at 'vector << 12'. */ - error = vm_set_register(ctx, newcpu, VM_REG_GUEST_RIP, *rip); - assert(error == 0); + vm_set_register(ctx, newcpu, VM_REG_GUEST_RIP, *rip); - error = vm_get_desc(ctx, newcpu, VM_REG_GUEST_CS, &desc_base, + vm_get_desc(ctx, newcpu, VM_REG_GUEST_CS, &desc_base, &desc_limit, &desc_access); - assert(error == 0); desc_base = vector << PAGE_SHIFT; - error = vm_set_desc(ctx, newcpu, VM_REG_GUEST_CS, + vm_set_desc(ctx, newcpu, VM_REG_GUEST_CS, desc_base, desc_limit, desc_access); - assert(error == 0); cs = (vector << PAGE_SHIFT) >> 4; - error = vm_set_register(ctx, newcpu, VM_REG_GUEST_CS, cs); - assert(error == 0); + vm_set_register(ctx, newcpu, VM_REG_GUEST_CS, cs); } int spinup_ap(struct vmctx *ctx, int vcpu, int newcpu, uint64_t rip) { - int error; - assert(newcpu != 0); assert(newcpu < guest_ncpus); - error = vcpu_reset(ctx, newcpu); - assert(error == 0); + vcpu_reset(ctx, newcpu); fbsdrun_set_capabilities(ctx, newcpu); @@ -95,8 +88,7 @@ spinup_ap(struct vmctx *ctx, int vcpu, int newcpu, uint64_t rip) * Set up the processor state in power-on 16-bit mode, with the CS:IP * init'd to the specified low-mem 4K page. */ - error = vm_set_capability(ctx, newcpu, VM_CAP_UNRESTRICTED_GUEST, 1); - assert(error == 0); + vm_set_capability(ctx, newcpu, VM_CAP_UNRESTRICTED_GUEST, 1); spinup_ap_realmode(ctx, newcpu, &rip); diff --git a/usr.sbin/bhyve/task_switch.c b/usr.sbin/bhyve/task_switch.c index f1b564d560c..94ade46a18e 100644 --- a/usr.sbin/bhyve/task_switch.c +++ b/usr.sbin/bhyve/task_switch.c @@ -104,20 +104,16 @@ static uint64_t GETREG(struct vmctx *ctx, int vcpu, int reg) { uint64_t val; - int error; - error = vm_get_register(ctx, vcpu, reg, &val); - assert(error == 0); + vm_get_register(ctx, vcpu, reg, &val); return (val); } static void SETREG(struct vmctx *ctx, int vcpu, int reg, uint64_t val) { - int error; - error = vm_set_register(ctx, vcpu, reg, val); - assert(error == 0); + vm_set_register(ctx, vcpu, reg, val); } static struct seg_desc @@ -178,11 +174,10 @@ desc_table_limit_check(struct vmctx *ctx, int vcpu, uint16_t sel) { uint64_t base; uint32_t limit, access; - int error, reg; + int reg; reg = ISLDT(sel) ? VM_REG_GUEST_LDTR : VM_REG_GUEST_GDTR; - error = vm_get_desc(ctx, vcpu, reg, &base, &limit, &access); - assert(error == 0); + vm_get_desc(ctx, vcpu, reg, &base, &limit, &access); if (reg == VM_REG_GUEST_LDTR) { if (SEG_DESC_UNUSABLE(access) || !SEG_DESC_PRESENT(access)) @@ -470,10 +465,7 @@ tss32_save(struct vmctx *ctx, int vcpu, struct vm_task_switch *task_switch, static void update_seg_desc(struct vmctx *ctx, int vcpu, int reg, struct seg_desc *sd) { - int error; - - error = vm_set_desc(ctx, vcpu, reg, sd->base, sd->limit, sd->access); - assert(error == 0); + vm_set_desc(ctx, vcpu, reg, sd->base, sd->limit, sd->access); } /* @@ -714,7 +706,7 @@ vmexit_task_switch(struct vmctx *ctx, struct vm_exit *vmexit, int *pvcpu) struct iovec nt_iov[2], ot_iov[2]; uint64_t cr0, ot_base; uint32_t eip, ot_lim, access; - int error, ext, fault, minlimit, nt_type, ot_type, vcpu; + int error, ext, fault, minlimit, nt_type, vcpu; enum task_switch_reason reason; uint16_t nt_sel, ot_sel; @@ -818,8 +810,6 @@ vmexit_task_switch(struct vmctx *ctx, struct vm_exit *vmexit, int *pvcpu) &access); assert(error == 0); assert(!SEG_DESC_UNUSABLE(access) && SEG_DESC_PRESENT(access)); - ot_type = SEG_DESC_TYPE(access); - assert(ot_type == SDT_SYS386BSY || ot_type == SDT_SYS286BSY); /* Fetch the old TSS descriptor */ error = read_tss_descriptor(ctx, vcpu, task_switch, ot_sel, &ot_desc, diff --git a/usr.sbin/bhyve/uart_emul.c b/usr.sbin/bhyve/uart_emul.c index fd0ad2c846f..3e2f87a16a9 100644 --- a/usr.sbin/bhyve/uart_emul.c +++ b/usr.sbin/bhyve/uart_emul.c @@ -188,7 +188,6 @@ rxfifo_reset(struct uart_softc *sc, int size) char flushbuf[32]; struct fifo *fifo; ssize_t nread; - int error; fifo = &sc->rxfifo; bzero(fifo, sizeof(struct fifo)); @@ -208,8 +207,7 @@ rxfifo_reset(struct uart_softc *sc, int size) * Enable mevent to trigger when new characters are available * on the tty fd. */ - error = mevent_enable(sc->mev); - assert(error == 0); + mevent_enable(sc->mev); } } @@ -226,7 +224,6 @@ static int rxfifo_putchar(struct uart_softc *sc, uint8_t ch) { struct fifo *fifo; - int error; fifo = &sc->rxfifo; @@ -239,8 +236,7 @@ rxfifo_putchar(struct uart_softc *sc, uint8_t ch) /* * Disable mevent callback if the FIFO is full. */ - error = mevent_disable(sc->mev); - assert(error == 0); + mevent_disable(sc->mev); } } return (0); @@ -252,7 +248,7 @@ static int rxfifo_getchar(struct uart_softc *sc) { struct fifo *fifo; - int c, error, wasfull; + int c, wasfull; wasfull = 0; fifo = &sc->rxfifo; @@ -264,8 +260,7 @@ rxfifo_getchar(struct uart_softc *sc) fifo->num--; if (wasfull) { if (sc->tty.opened) { - error = mevent_enable(sc->mev); - assert(error == 0); + mevent_enable(sc->mev); } } return (c); diff --git a/usr.sbin/bhyve/vga.c b/usr.sbin/bhyve/vga.c index 24864f32e8b..1dde97422f9 100644 --- a/usr.sbin/bhyve/vga.c +++ b/usr.sbin/bhyve/vga.c @@ -1270,7 +1270,7 @@ vga_init(int io_only) { struct inout_port iop; struct vga_softc *sc; - int port, error; + int port; sc = calloc(1, sizeof(struct vga_softc)); @@ -1283,8 +1283,7 @@ vga_init(int io_only) iop.handler = vga_port_handler; iop.arg = sc; - error = register_inout(&iop); - assert(error == 0); + register_inout(&iop); } sc->gc_image = console_get_image(); @@ -1299,8 +1298,7 @@ vga_init(int io_only) sc->mr.size = 128 * KB; sc->mr.handler = vga_mem_handler; sc->mr.arg1 = sc; - error = register_mem_fallback(&sc->mr); - assert(error == 0); + register_mem_fallback(&sc->mr); sc->vga_ram = malloc(256 * KB); memset(sc->vga_ram, 0, 256 * KB); diff --git a/usr.sbin/bsdinstall/partedit/scripted.c b/usr.sbin/bsdinstall/partedit/scripted.c index 37ac6de131b..ae275663917 100644 --- a/usr.sbin/bsdinstall/partedit/scripted.c +++ b/usr.sbin/bsdinstall/partedit/scripted.c @@ -71,12 +71,11 @@ part_config(char *disk, const char *scheme, char *config) struct gclass *classp; struct gmesh mesh; struct ggeom *gpart = NULL; - int error; if (scheme == NULL) scheme = default_scheme(); - error = geom_gettree(&mesh); + geom_gettree(&mesh); if (provider_for_name(&mesh, disk) == NULL) { fprintf(stderr, "GEOM provider %s not found\n", disk); geom_deletetree(&mesh); @@ -107,7 +106,7 @@ part_config(char *disk, const char *scheme, char *config) } geom_deletetree(&mesh); - error = geom_gettree(&mesh); + geom_gettree(&mesh); /* Create partitions */ if (config == NULL) { @@ -133,7 +132,7 @@ part_config(char *disk, const char *scheme, char *config) gpart_create(provider_for_name(&mesh, disk), type, size, mount, NULL, 0); geom_deletetree(&mesh); - error = geom_gettree(&mesh); + geom_gettree(&mesh); size = type = mount = NULL; } diff --git a/usr.sbin/camdd/camdd.c b/usr.sbin/camdd/camdd.c index caf06ba9a59..337c48db6f2 100644 --- a/usr.sbin/camdd/camdd.c +++ b/usr.sbin/camdd/camdd.c @@ -2748,12 +2748,9 @@ bailout: int camdd_get_next_lba_len(struct camdd_dev *dev, uint64_t *lba, ssize_t *len) { - struct camdd_dev_pass *pass_dev; uint32_t num_blocks; int retval = 0; - pass_dev = &dev->dev_spec.pass; - *lba = dev->next_io_pos_bytes / dev->sector_size; *len = dev->blocksize; num_blocks = *len / dev->sector_size; @@ -2810,15 +2807,11 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) { struct camdd_buf *buf = NULL; struct camdd_buf_data *data; - struct camdd_dev_pass *pass_dev; size_t new_len; struct camdd_buf_data *rb_data; int is_write = dev->write_dev; int eof_flush_needed = 0; int retval = 0; - int error; - - pass_dev = &dev->dev_spec.pass; /* * If we've gotten EOF or our partner has, we should not continue @@ -2838,8 +2831,7 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) */ if (is_write) { read_buf->status = CAMDD_STATUS_EOF; - - error = camdd_complete_peer_buf(dev, read_buf); + camdd_complete_peer_buf(dev, read_buf); } goto bailout; } @@ -2908,7 +2900,7 @@ camdd_queue(struct camdd_dev *dev, struct camdd_buf *read_buf) if (len == 0) { dev->flags |= CAMDD_DEV_FLAG_EOF; - error = camdd_complete_peer_buf(dev, read_buf); + camdd_complete_peer_buf(dev, read_buf); goto bailout; } } @@ -3560,7 +3552,6 @@ int main(int argc, char **argv) { int c; - camdd_argmask arglist = CAMDD_ARG_NONE; int timeout = 0, retry_count = 1; int error = 0; uint64_t max_io = 0; @@ -3585,10 +3576,8 @@ main(int argc, char **argv) if (retry_count < 0) errx(1, "retry count %d is < 0", retry_count); - arglist |= CAMDD_ARG_RETRIES; break; case 'E': - arglist |= CAMDD_ARG_ERR_RECOVER; break; case 'i': case 'o': @@ -3618,10 +3607,6 @@ main(int argc, char **argv) errx(1, "invalid timeout %d", timeout); /* Convert the timeout from seconds to ms */ timeout *= 1000; - arglist |= CAMDD_ARG_TIMEOUT; - break; - case 'v': - arglist |= CAMDD_ARG_VERBOSE; break; case 'h': default: diff --git a/usr.sbin/efibootmgr/efibootmgr.c b/usr.sbin/efibootmgr/efibootmgr.c index 53bc417c4e0..75c8592eb07 100644 --- a/usr.sbin/efibootmgr/efibootmgr.c +++ b/usr.sbin/efibootmgr/efibootmgr.c @@ -996,7 +996,7 @@ report_esp_device(bool do_dp, bool do_unix) char *name, *dev, *relpath, *abspath; uint8_t *walker, *ep; efi_char *descr; - efidp dp, edp; + efidp dp; char buf[PATH_MAX]; if (do_dp && do_unix) @@ -1026,7 +1026,6 @@ report_esp_device(bool do_dp, bool do_unix) // Now we have fplen bytes worth of file path stuff dp = (efidp)walker; walker += fplen; - edp = (efidp)walker; if (walker > ep) errx(1, "malformed boot variable %s", name); if (do_dp) { diff --git a/usr.sbin/efidp/efidp.c b/usr.sbin/efidp/efidp.c index aef154112d6..96769402438 100644 --- a/usr.sbin/efidp/efidp.c +++ b/usr.sbin/efidp/efidp.c @@ -169,14 +169,13 @@ efi_to_unix(void) char buffer[MAXSIZE]; char dpbuf[MAXSIZE]; efidp dp; - size_t dplen; char *walker, *dev, *relpath, *abspath; int rv; dp = (efidp)dpbuf; while (fgets(buffer, sizeof(buffer), stdin)) { walker= trim(buffer); - dplen = efidp_parse_device_path(walker, dp, sizeof(dpbuf)); + efidp_parse_device_path(walker, dp, sizeof(dpbuf)); rv = efivar_device_path_to_unix_path(dp, &dev, &relpath, &abspath); if (rv == 0) printf("%s:%s %s\n", dev, relpath, abspath); diff --git a/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c b/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c index 7d6fdbff214..c7485ee23d8 100644 --- a/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c +++ b/usr.sbin/fifolog/fifolog_reader/fifolog_reader.c @@ -54,7 +54,6 @@ Render(void *priv __unused, time_t now, unsigned flag __unused, const unsigned c { static struct tm utc; char buf[128]; - int i; if (now < opt_B || now > opt_E) return; @@ -66,8 +65,7 @@ Render(void *priv __unused, time_t now, unsigned flag __unused, const unsigned c fprintf(fo, "%s\n", p); } else if (opt_T != NULL) { (void)gmtime_r(&now, &utc); - i = strftime(buf, sizeof buf, opt_T, &utc); - assert(i > 0); + strftime(buf, sizeof buf, opt_T, &utc); fprintf(fo, "%s %s\n", buf, p); } else { fprintf(fo, "%12ld %s\n", (long)now, p); diff --git a/usr.sbin/fifolog/lib/fifolog_int.c b/usr.sbin/fifolog/lib/fifolog_int.c index d22bd4745e4..19d61c8b7c5 100644 --- a/usr.sbin/fifolog/lib/fifolog_int.c +++ b/usr.sbin/fifolog/lib/fifolog_int.c @@ -178,7 +178,7 @@ fifolog_int_close(struct fifolog_file **ff) } static void -fifolog_int_file_assert(const struct fifolog_file *ff) +fifolog_int_file_assert(const struct fifolog_file *ff __unused) { CHECK_OBJ_NOTNULL(ff, FIFOLOG_FILE_MAGIC); diff --git a/usr.sbin/fifolog/lib/fifolog_reader.c b/usr.sbin/fifolog/lib/fifolog_reader.c index 1ef6a4e2048..7627dad117d 100644 --- a/usr.sbin/fifolog/lib/fifolog_reader.c +++ b/usr.sbin/fifolog/lib/fifolog_reader.c @@ -59,7 +59,6 @@ fifolog_reader_open(const char *fname) { const char *retval; struct fifolog_reader *fr; - int i; fr = calloc(1, sizeof(*fr)); if (fr == NULL) @@ -74,8 +73,7 @@ fifolog_reader_open(const char *fname) err(1, "Cannot malloc"); fr->olen = fr->ff->recsize * 16; - i = inflateInit(fr->ff->zs); - assert(i == Z_OK); + inflateInit(fr->ff->zs); fr->magic = FIFOLOG_READER_MAGIC; return (fr); diff --git a/usr.sbin/fifolog/lib/fifolog_write_poll.c b/usr.sbin/fifolog/lib/fifolog_write_poll.c index cffe095d4d7..a581df6fbc6 100644 --- a/usr.sbin/fifolog/lib/fifolog_write_poll.c +++ b/usr.sbin/fifolog/lib/fifolog_write_poll.c @@ -65,7 +65,7 @@ const char *fifolog_write_statnames[] = { * Check that everything is all right */ static void -fifolog_write_assert(const struct fifolog_writer *f) +fifolog_write_assert(const struct fifolog_writer *f __unused) { CHECK_OBJ_NOTNULL(f, FIFOLOG_WRITER_MAGIC); diff --git a/usr.sbin/fifolog/lib/getdate.y b/usr.sbin/fifolog/lib/getdate.y index 53a515c4d17..02357b24c56 100644 --- a/usr.sbin/fifolog/lib/getdate.y +++ b/usr.sbin/fifolog/lib/getdate.y @@ -816,26 +816,15 @@ yylex(void) time_t get_date(char *p) { - struct tm *tm, gmt; + struct tm *tm; time_t Start; time_t tod; time_t nowtime; - struct tm *gmt_ptr; yyInput = p; (void)time (&nowtime); - gmt_ptr = gmtime (&nowtime); - if (gmt_ptr != NULL) - { - /* Make a copy, in case localtime modifies *tm (I think - that comment now applies to *gmt_ptr, but I am too - lazy to dig into how gmtime and locatime allocate the - structures they return pointers to). */ - gmt = *gmt_ptr; - } - if (! (tm = localtime (&nowtime))) return -1; diff --git a/usr.sbin/fwcontrol/fwdv.c b/usr.sbin/fwcontrol/fwdv.c index 2baf1c43c80..cb821891821 100644 --- a/usr.sbin/fwcontrol/fwdv.c +++ b/usr.sbin/fwcontrol/fwdv.c @@ -262,7 +262,7 @@ dvsend(int d, const char *filename, char ich, int count) struct dvdbc *dv; struct fw_pkt *pkt; int len, tlen, header, fd, frames, packets, vec, offset, nhdr, i; - int system=-1, pad_acc, cycle_acc, cycle, f_cycle, f_frac; + int system=-1, pad_acc, cycle_acc, cycle, f_frac; struct iovec wbuf[TNBUF*2 + NEMPTY]; char *pbuf; u_int32_t iso_data, iso_empty, hdr[TNBUF + NEMPTY][3]; @@ -363,10 +363,10 @@ next: if (frames % frame_rate[system] == 0) fprintf(stderr, "\n"); fflush(stderr); - f_cycle = (cycle_acc / frame_cycle[system].d) & 0xf; f_frac = (cycle_acc % frame_cycle[system].d * CYCLE_FRAC) / frame_cycle[system].d; #if 0 + int f_cycle = (cycle_acc / frame_cycle[system].d) & 0xf; ciph->fdf.dv.cyc = htons(f_cycle << 12 | f_frac); #else ciph->fdf.dv.cyc = htons(cycle << 12 | f_frac); diff --git a/usr.sbin/makefs/msdos.c b/usr.sbin/makefs/msdos.c index a0e0f7174f2..23fa200d3e5 100644 --- a/usr.sbin/makefs/msdos.c +++ b/usr.sbin/makefs/msdos.c @@ -149,7 +149,6 @@ msdos_makefs(const char *image, const char *dir, fsnode *root, fsinfo_t *fsopts) struct vnode vp, rootvp; struct timeval start; struct msdosfsmount *pmp; - uint32_t flags; assert(image != NULL); assert(dir != NULL); @@ -183,7 +182,6 @@ msdos_makefs(const char *image, const char *dir, fsnode *root, fsinfo_t *fsopts) fsopts->fd = open(image, O_RDWR); vp.fs = fsopts; - flags = 0; if ((pmp = msdosfs_mount(&vp)) == NULL) err(1, "msdosfs_mount"); diff --git a/usr.sbin/makefs/msdos/msdosfs_vfsops.c b/usr.sbin/makefs/msdos/msdosfs_vfsops.c index 4a5c658b794..fa4855597d7 100644 --- a/usr.sbin/makefs/msdos/msdosfs_vfsops.c +++ b/usr.sbin/makefs/msdos/msdosfs_vfsops.c @@ -87,7 +87,6 @@ msdosfs_mount(struct vnode *devvp) struct byte_bpb710 *b710; uint8_t SecPerClust; int ronly = 0, error; - int bsize; unsigned secsize = 512; MSDOSFS_DPRINTF(("%s(bread 0)\n", __func__)); @@ -107,7 +106,6 @@ msdosfs_mount(struct vnode *devvp) error = EINVAL; goto error_exit; } - bsize = 0; pmp = ecalloc(1, sizeof(*pmp)); /* diff --git a/usr.sbin/mpsutil/mps_debug.c b/usr.sbin/mpsutil/mps_debug.c index 4c462ef65f6..83315090d73 100644 --- a/usr.sbin/mpsutil/mps_debug.c +++ b/usr.sbin/mpsutil/mps_debug.c @@ -136,11 +136,9 @@ print_sgl(char *buf, int offset, int numframes) { MPI2_SGE_SIMPLE64 *sge; MPI2_SGE_CHAIN_UNION *sgc; - MPI2_REQUEST_HEADER *req; u_int i = 0, flags; char *frame, tmpbuf[128]; - req = (MPI2_REQUEST_HEADER *)buf; frame = (char *)buf; sge = (MPI2_SGE_SIMPLE64 *)&frame[offset * 4]; printf("SGL for command\n"); diff --git a/usr.sbin/mptable/mptable.c b/usr.sbin/mptable/mptable.c index 6c5efee766b..e8be110dfb1 100644 --- a/usr.sbin/mptable/mptable.c +++ b/usr.sbin/mptable/mptable.c @@ -530,7 +530,6 @@ MPConfigTableHeader( u_int32_t pap ) { mpcth_t cth; int x; - int totalSize; int c; int oldtype, entrytype; u_int8_t *entry; @@ -574,8 +573,6 @@ MPConfigTableHeader( u_int32_t pap ) printf( " extended table length:\t%d\n", cth->extended_table_length ); printf( " extended table checksum:\t%d\n", cth->extended_table_checksum ); - totalSize = cth->base_table_length - sizeof( struct MPCTH ); - puts( SEP_LINE ); printf( "MP Config Base Table Entries:\n\n" ); diff --git a/usr.sbin/pmc/cmd_pmc_filter.cc b/usr.sbin/pmc/cmd_pmc_filter.cc index 07027cb272f..7f2fae6d208 100644 --- a/usr.sbin/pmc/cmd_pmc_filter.cc +++ b/usr.sbin/pmc/cmd_pmc_filter.cc @@ -208,7 +208,7 @@ pmc_filter_handler(uint32_t *lwplist, int lwpcount, uint32_t *pidlist, int pidco char cpuid[PMC_CPUID_LEN]; char *proclist[LIST_MAX]; char *threadlist[LIST_MAX]; - int i, pmccount, copies, eventcount; + int i, pmccount, eventcount; int proccount, threadcount; uint32_t idx; idmap pidmap, tidmap; @@ -247,7 +247,6 @@ pmc_filter_handler(uint32_t *lwplist, int lwpcount, uint32_t *pidlist, int pidco pmclog_close(ps); if ((ps = static_cast < struct pmclog_parse_state *>(pmclog_open(infd)))== NULL) errx(EX_OSERR, "ERROR: Cannot allocate pmclog parse state: %s\n", strerror(errno)); - copies = 0; while (pmclog_read(ps, &ev) == 0) { if (ev.pl_type == PMCLOG_TYPE_THR_CREATE) tidmap[ev.pl_u.pl_tc.pl_tid] = ev.pl_u.pl_tc.pl_tdname; diff --git a/usr.sbin/pw/pw_user.c b/usr.sbin/pw/pw_user.c index 2eec317b5e5..5041dd74b5c 100644 --- a/usr.sbin/pw/pw_user.c +++ b/usr.sbin/pw/pw_user.c @@ -493,7 +493,6 @@ pw_pwcrypt(char *password) char salt[SALTSIZE + 1]; char *cryptpw; static char buf[256]; - size_t pwlen; /* * Calculate a salt value @@ -505,8 +504,7 @@ pw_pwcrypt(char *password) cryptpw = crypt(password, salt); if (cryptpw == NULL) errx(EX_CONFIG, "crypt(3) failure"); - pwlen = strlcpy(buf, cryptpw, sizeof(buf)); - assert(pwlen < sizeof(buf)); + strlcpy(buf, cryptpw, sizeof(buf)); return (buf); } diff --git a/usr.sbin/rpc.lockd/kern.c b/usr.sbin/rpc.lockd/kern.c index 08566a5b465..b25ca828fa2 100644 --- a/usr.sbin/rpc.lockd/kern.c +++ b/usr.sbin/rpc.lockd/kern.c @@ -572,16 +572,11 @@ void show(LOCKD_MSG *mp) { static char hex[] = "0123456789abcdef"; - struct fid *fidp; - fsid_t *fsidp; size_t len; u_int8_t *p, *t, buf[NFS_SMALLFH*3+1]; syslog(LOG_DEBUG, "process ID: %lu\n", (long)mp->lm_msg_ident.pid); - fsidp = (fsid_t *)&mp->lm_fh; - fidp = (struct fid *)((u_int8_t *)&mp->lm_fh + sizeof(fsid_t)); - for (t = buf, p = (u_int8_t *)mp->lm_fh, len = mp->lm_fh_len; len > 0; ++p, --len) { diff --git a/usr.sbin/rpc.tlsservd/rpc.tlsservd.c b/usr.sbin/rpc.tlsservd/rpc.tlsservd.c index 71787b162ac..db829be6833 100644 --- a/usr.sbin/rpc.tlsservd/rpc.tlsservd.c +++ b/usr.sbin/rpc.tlsservd/rpc.tlsservd.c @@ -142,7 +142,7 @@ main(int argc, char **argv) * TLS handshake. */ struct sockaddr_un sun; - int ch, debug, fd, oldmask; + int ch, fd, oldmask; SVCXPRT *xprt; struct timeval tm; struct timezone tz; @@ -177,7 +177,6 @@ main(int argc, char **argv) rpctls_dnsname = hostname; } - debug = 0; rpctls_verbose = false; while ((ch = getopt_long(argc, argv, "D:dhl:n:mp:r:uvWw", longopts, NULL)) != -1) { diff --git a/usr.sbin/rrenumd/parser.y b/usr.sbin/rrenumd/parser.y index 43d08634d43..c75dde23df3 100644 --- a/usr.sbin/rrenumd/parser.y +++ b/usr.sbin/rrenumd/parser.y @@ -335,10 +335,8 @@ rrenum_statement: match_prefix_definition: rrenum_cmd MATCH_PREFIX_CMD prefixval maxlen minlen { - struct icmp6_router_renum *irr; struct rr_pco_match *rpm; - irr = &ple_cur.pl_irr; rpm = &ple_cur.pl_rpm; memset(rpm, 0, sizeof(*rpm)); --MP_/wQ+F2DVnjFSjsXA5CnSTh.G-- From nobody Fri Dec 10 09:08:53 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DAB7418EAF42 for ; Fri, 10 Dec 2021 09:09:23 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9Q832Lf5z4fPC for ; Fri, 10 Dec 2021 09:09:22 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.16.1/8.16.1) with ESMTPS id 1BA98xa6066765 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 10 Dec 2021 19:39:05 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1639127349; bh=zrKKIEkwirooxdvcyjv8QJV29MQBY9d3emLWWqMBcJk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=CbQ48ZcxT2mxAG7zgbBW+KowRb8m1l6JHQQgurG4G8KT/iEmucL3dGZB3q0GmbKNN Cir5dtFCng1a+bZVGlErOWCq2SfLdrNOCOLIWen63OpufVyRnBfyxe7HiLi2AWGaYA V7+8nodQVZBfpYAH+Y20bBGfVga8ELD9ImjAyJqA= Received: (from mailnull@localhost) by midget.dons.net.au (8.16.1/8.16.1/Submit) id 1BA98rps066756 for ; Fri, 10 Dec 2021 19:38:53 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-f0f0b4ff001831caa5b8ac39868c4c7e9b4d12fc: 2403:5800:5200:4700:792f:b02:6699:af48 Received: from smtpclient.apple (2403-5800-5200-4700-792f-b02-6699-af48.ip6.aussiebb.net [2403:5800:5200:4700:792f:b02:6699:af48]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 1BA98rlw066749; Fri, 10 Dec 2021 19:38:53 +1030 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What to use in place of abstract unix sockets? In-Reply-To: Date: Fri, 10 Dec 2021 19:38:53 +1030 Cc: Eugene Grosbein , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> References: To: Gleb Popov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spam-Score: 0.8 () No, score=0.8 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4J9Q832Lf5z4fPC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: darius@dons.net.au From: Daniel O'Connor via freebsd-hackers X-Original-From: Daniel O'Connor X-ThisMailContainsUnwantedMimeParts: N > On 10 Dec 2021, at 18:23, Gleb Popov wrote: > > What can I do to make this software work for FreeBSD? Simply using = regular > > UDS instead of abstract ones doesn't work for obvious reasons - the > > "client" can't find the socket file. >=20 > If the parent knows where the child will chroot it could create a unix = domain socket under that directory somewhere. >=20 > Same problem as above - there should be a single socket on the erver = side.=20 I just did a quick test with nc and you can hard link unix domain = sockets so you could bind it in the parent then hard link it for each = child. Seems pretty kludgy though :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Dec 10 10:15:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 630B818D0024 for ; Fri, 10 Dec 2021 10:15:50 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from mail.0x20.net (mail.0x20.net [46.251.251.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9Rck1tGgz4q5K for ; Fri, 10 Dec 2021 10:15:50 +0000 (UTC) (envelope-from lme@FreeBSD.org) Received: from 0x20.net (webs.0x20.net [46.251.251.54]) (Authenticated sender: lala) by mail.0x20.net (Postfix) with ESMTPA id 42EF53D888 for ; Fri, 10 Dec 2021 11:15:42 +0100 (CET) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 10 Dec 2021 11:15:42 +0100 From: Lars Engels To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> Message-ID: <50ce89e135767d11adc2f90a602b28ce@FreeBSD.org> X-Sender: lme@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4J9Rck1tGgz4q5K X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 2021-12-09 19:25, schrieb Özkan KIRIK: > bsnmpd: monitoring jails (event with different vnet) resources like > interfaces, cpu usage etc. > > I don't have an account to modify wiki. thanks I added this to the wiki page. From nobody Fri Dec 10 10:55:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 93FB318DC7C8 for ; Fri, 10 Dec 2021 10:56:05 +0000 (UTC) (envelope-from elenamihailescu22@gmail.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9SW93Y6yz3L7g; Fri, 10 Dec 2021 10:56:05 +0000 (UTC) (envelope-from elenamihailescu22@gmail.com) Received: by mail-ed1-x52b.google.com with SMTP id v1so28973405edx.2; Fri, 10 Dec 2021 02:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6ZtbgqYFUxaV4r5hBKkt6cc93DZw1Bwa/AnXF4FlYQk=; b=MoulTyw8jllccvY0eiN8dod+sh81J0XPbhMQFNqO0ey5wHC3smHYugHriyao2hEJid AKQlTwknIlJJisADg7qXZ6spAKFOOuA6dpWm2faDl1ycEkhxZseNRI4nr0DaIGrJLFgv 0Yrh6FCYggVpw8wWuT6DJOqZFKpk6m1kz2BawS2do/LstzNSfuAAsZAc4NJZI55Eb9Ql RlMAH0xZ9HCtyiUBy94uBQK/OAfNo+ajKnzTBu30HdQx5oXUV+ANxS7hrBkBGkZ9Fa82 v5xGtROLot+AWP6o/rhsrc1lrJ0ZVr/7rMbGsWZjBKaCkX80WgMJWbzDPHmkPITFqx61 KnXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6ZtbgqYFUxaV4r5hBKkt6cc93DZw1Bwa/AnXF4FlYQk=; b=TNEVJ836B12zJ0kJwkT67GlQdOFhG4eg4AA6I49nF108BBY3qdtpovvt2ThAzlmojr HD0kwyxLZUQ0f2b/Ii+5frATYUDqCenMEqeo2Ns3WiNWXRixrbt74x8tJZxxyJ7SUtxJ rm2s3B+AkY8wsN/JPpDEGBOgDnlnuWRg/W+iBPWFLi1AsU4gz4k3WPRPWQtAhS/SJ7gD SAd2oZfgpcnUNZkjfxegdQzzXR/T3XM+dhL5YHEQwCdHBLqIyR9sdCENKHHT0tlRrZqo hfi4axfAaTfRRrpjlr2KnnewPv0pd89WZ7MxWbhKGrsPSTRXWBo5y6uvXymCjTPIDS0R U5cw== X-Gm-Message-State: AOAM531iKTaDLonlT/oLnmw4jhsWkqMKrO7JumAFn5VkvZgWIn2Xhii6 khMVa1AvCjbPDrRbO2kOsHtN+AFTZsSfTHcy41g= X-Google-Smtp-Source: ABdhPJw53fwVUDQnqCedCWnD465fLtrzHGGxS8hF1r8zeNejTrmv1R0qCH4zNQP38XA8gOzQltK8p3HXlO9kYSnTC+Q= X-Received: by 2002:a17:907:3e25:: with SMTP id hp37mr23208218ejc.43.1639133764207; Fri, 10 Dec 2021 02:56:04 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2BC55859-CA32-4DDC-B5E8-C17ED4934E0C@pretty.Easy.privacy> <949CAEC9-25C4-4448-9C60-30687D17410B@pretty.Easy.privacy> <4eee16fa-d160-2b1a-2d46-42b7a607fb04@shrew.net> In-Reply-To: <4eee16fa-d160-2b1a-2d46-42b7a607fb04@shrew.net> From: Elena Mihailescu Date: Fri, 10 Dec 2021 12:55:38 +0200 Message-ID: Subject: Re: Fwd: Call for Foundation-supported Project Ideas To: Matthew Grooms Cc: freebsd-hackers@freebsd.org, Mihai Carabas , mike@reifenberger.com, mr@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J9SW93Y6yz3L7g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, all, Thank you, Matthew, for your description. As Matthew said, any feedback or any help in bringing these things upstream is highly appreciated. I want to add links to repo, wiki and reviews for a better view of our projects. In UPB (University Politehnica of Bucharest), we work on various bhyve related projects (some of them are research projects, other are faculty projects). For better awareness, here is our wiki page [1] where we present the ongoing projects, reviews, tutorials or other resources for them. We have a GitHub [2] organisation where you can find our main tracks: - improvements to FreeBSD (mainly bhyve) - a forked repository from FreeBSD/freebsd-src. Usually, each project has a branch where we develop things and the main branch is used only for synchronisation with the FreeBSD/freebsd-src main repository. - improvements to libvdsk - a standalone library that brings support for different types of file formats that may be used for bhyve (raw, qcow2, vmdk). We have pending reviews on Phabricator for which we need feedback: - bhyve - ARMv8 implementation - https://reviews.freebsd.org/D26976 - bhyve - Snapshot Save and Restore - multiple devices https://reviews.freebsd.org/D26387 - Warm Migration feature for bhyve - https://reviews.freebsd.org/D28270 - bhyve - JSON format snapshot - https://reviews.freebsd.org/D29262 - bhyve - Capsicum integration - https://reviews.freebsd.org/D30471 - Live migration for bhyve - https://reviews.freebsd.org/D30954 Beside the opened reviews, we are working on various projects (are described in the wiki as well) that are still not ready for a review on Phabricator yet: - checkpoint option for bhyve either using ZFS or libvdsk - we have a PoC for ZFS [2][3] and are working for adding QCOW2 checkpoint functionality to libvdsk and then link it to the bhyve checkpoint functionality. - USB-passthrough - we managed to pass-through a keyboard to a bhyve Linux VM, we are working on reattaching the USB device to the host when exiting the VM and then we plan to check the functionality with an USB stick (storage transfer). - AMD CPU support for the save restore - we are running the final tests before opening a ticket on Phabricator. - use FreeBSD as a compute node in OpenStack If you have any questions, please let us know. [1] https://github.com/FreeBSD-UPB/freebsd-src/wiki [2] https://github.com/FreeBSD-UPB [3] https://www.youtube.com/watch?v=3DFWyk1y460Dg [4] https://github.com/FreeBSD-UPB/freebsd-src/wiki/Checkpoint-for-bhyve-us= ing-zfs-snapshots-and-clones Thank you, Elena Mihailescu On Fri, 10 Dec 2021 at 01:01, Matthew Grooms wrote: > > Support for USB Device pass through is being worked on by a student at > the Bucharest Polytechnic University. This effort is essentially a port > of the feature from Intel's Acorn hypervisor which is based on bhyve ... > > https://github.com/FreeBSD-UPB/freebsd-src/tree/projects/bhyve_usb_passth= rough > > The UPB team has quite a few projects that would benefit from more > support from the FreeBSD Foundation. They've asked for feedback and > review of many bhyve related features that have been developed over the > past few years. Unfortunately most of that work has been gathering dust > in their github repository. This includes work on features such as warm > migration, live migration, improved checkpoint file support, improved > multiple checkpoint of devices, more sophisticated disk file formats > such as qcow2 and vmdk via libvdsk that could help checkpoint disk > images, etc. > > It would be incredibly helpful if the Foundation could offer some help > getting some of this code reviewed and provide feedback so that it has a > chance of being committed at some point in the future. > > -Matthew > > On 11/30/2021 1:30 PM, Michael wrote: > > > > > > -------- Original Message -------- > > From: Michael > > Sent: November 30, 2021 11:03:13 AM GMT+01:00 > > To: freebsd-hackers@freebsd.org > > Subject: Call for Foundation-supported Project Ideas > > > > Hi, > > one missing feature is USB device pass through for bhyve. > > That would be quite handy for passing unsupported USB devices > > to Linux/Windows on Laptops where a controller pass through isnt > > possible. > > > > > > -------- Original Message -------- > > From: tux2bsd via freebsd-hackers > > Sent: November 30, 2021 8:35:36 AM GMT+01:00 > > To: "freebsd-hackers@freebsd.org" > > Subject: Call for Foundation-supported Project Ideas > > > > Hi Joe > > > > Call for Foundation-supported Project Idea, well not a project but an i= tem of importance in my opinion (the hostile forums disagree with me). > > > > Some help to fix freebsd-update , a very longstanding poor performance = problem I took the time to investigate and provide an attempt to fix, > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258863 > > > > I've been working with Colin Percival towards providing/fine-tuning a w= orkaround but the program itself is monolithic and very intertwined which m= eans a seemingly trivial fix is actually a nightmare - the goal posts keep = changing with each step forward. Quite frustrating actually so I'd apprecia= te some help if mini-projects are acceptable. > > > > Thanks > > tux2bsd > > (apologies for the thread busting email) > > -- > > -- > From nobody Fri Dec 10 21:40:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C1BE018D69CF; Fri, 10 Dec 2021 21:40:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9kpm2WHZz4qbr; Fri, 10 Dec 2021 21:40:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 31A7D2787C; Fri, 10 Dec 2021 21:40:32 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f170.google.com with SMTP id t34so9718468qtc.7; Fri, 10 Dec 2021 13:40:32 -0800 (PST) X-Gm-Message-State: AOAM532AOsakstNQF6iAEWA0LJUEwQHtiOo8cn0EWsp+VdKIgWbfbEZ3 oUmXWoxXuTYX9a3G5tYz7cjcrGx81/dXBlwvG9I= X-Google-Smtp-Source: ABdhPJy8zvPV9WwF1yp+H6c7BRh3PrDY0DjyWpLTbWDYYYNqo9IlZNVf4QoSPXy+niE80AJoIx52bnYWsIBnfQCIJ2A= X-Received: by 2002:ac8:58ca:: with SMTP id u10mr29657394qta.44.1639172431649; Fri, 10 Dec 2021 13:40:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Fri, 10 Dec 2021 15:40:19 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: configng To: freebsd-arch@freebsd.org, FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000839de905d2d19259" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639172432; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=lmfbxcQqkI8m0v4FpItYbn2gjjSqm1Zc+RfMjjYf5P4=; b=NAe+8yVDfelQg9uBNvsOXjmw3GQse7Edlm2QlEV8yJgkouW46r7ytZ0LHByP13OJXVx5iH i9Qfn+Okppp2/yEFC0Au/UORRsVnjjSw5yNlQcw4NBAmctYGkb5jAaJ8h6vN5E8+1EMT5S +YWK4lLLo/en6WnaAHwfZTwT4170rJqfyg79BWCv4IP8kaXBk7ponnqpftyAoL2xnBxvuV 9XVWfpOk+F9SdOqjcZDS2wxTc5tZfvJHLxTOJ3g31WlsAFd5Q8J00VDtaloIMh9GzR+031 k+6r4rZ8FwKmdPktG8g0YB46RgLNMz2I8jJ4eSLMUYG44HCA6cZzg+ABurtVpQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639172432; a=rsa-sha256; cv=none; b=qRfzkea6VsaBCnrabEFDHazAtK5gmEyoe2e+uRJdQE0/8ds8ucqWN949W0pD8U7RkyD4Wp b/6f32pQDwUnP+qy5ayV8TQ3ghK0Y4x/4BArlUTRYOzxcTu2YNdYYfaD1bEzPCNDpDUHHt tLx7PSxrp4iSDkEcUiYetTme9i7dCUs+mo5galRym1Yb/O2hJzB/iB1sQcSh0AbxvJBjXp nXqjRTCkIzk/oOAaZkai131firyPUTWSMzFr/MQYq+IjvJ2Fs7y17ZRp9EtP/7ulVSY10G Ra7kKxJFkUS2IW9FIYqKEWDItWqzYNEqSuqahk2LXnBhES5MKLyTTSB70JSeYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --000000000000839de905d2d19259 Content-Type: text/plain; charset="UTF-8" Hi, FYI- we're forming a group to look at what the next generation of config(8) should look like, with the goal of addressing some long-standing issues with the existing kernel configuration system. If you're interested in participating in the ongoing design discussion, please shoot an e-mail to kevans@FreeBSD.org or imp@FreeBSD.org. The current high-level requirement outline can be found here: https://hackmd.io/w1Tf8mmVQVuZok7-LNEhgw The current expectation is that configng will use an entirely different configuration language, rather than extending what we currently have, and come with some tooling to aide migration. This will be discussed more in-depth in later stages; for now, we want to focus on what we want to get out of the next generation. Thanks, Kyle Evans --000000000000839de905d2d19259-- From nobody Fri Dec 10 22:05:01 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BF57918DBE8F for ; Fri, 10 Dec 2021 22:05:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9lMG4q5Dz4vgB for ; Fri, 10 Dec 2021 22:05:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639173907; bh=7UH4bynHEijqj22fi4vaAhU3fvfQNI4L1SHXMH++3SU=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=G1mYk4D/hGMpu+FDLt0P9ckYtCDNh7eJwUNkByCVipUgH0SExxC11HV6HvHqCHlbUm2QtM0nQw/DC/zn7P9+TdlWFSiJT6qIbmdQ08YdV12X7v7fJSA58qEuZPpXlZADQCqKYHhlxkZR4knIL8k2Ijka0p2cBfrCtXWLqh2XoW8i9Hj5QefdlyAB4LY8fGqJ3ie17kMge0Ujeat9E9J/ymYTC+dEucUVm2LrplVGdC8qbX93bNi0RPSU/X2S6PYeWXOQ3TnNZRT/niOcIOwnmgoEOaR/PWfE+Pkzn4pSj92pWNjMxANbFbvIwgWV2xDv+nrqckTUTJZWMn6eLLd+fw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1639173907; bh=n2/K/88vykyppmOQlgQTM8NBUfayic8YcSVmUWUqLcW=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Bd6DodKx6ReuCDGHbupcwg3ccPdAgR9lATcq1cVVe2moQMoQ+JdkA8A2vu3yoatuclnPi3T6WMuShW5w/QRPidMxiMHzjOfHnTm7Z40JqAOVGvir54WE0qv9Fgg1uGNN3uN9cugJ6jS1yVz0SL30qPbmT+/PMuQpxZAjNTpRRhgLyeZre/kwd2XZfpWmqcDAuhdmVp6r978T8kvE8kQwiEPX79swkEIQS2OxjfGq0l931nANDzozAkhvXAXxJA/T2dZ3jCx8oQtcJ05Hhlgz/v2rLU0MagWwexHdWiIN/Eq1NZU2dwPdMBs73+T57ude4z5yl4NLxTTMKIytEd5s8Q== X-YMail-OSG: FbnMSZsVM1kiUjBDmSr.ZGC7SQXDIKS1L4dVkDekLCO6Xhj1uqQCQ7hOreQaWbl JL2c9X0YiTka_2KKezC_JXcevcnrSCj.IUVVvd2MGw.OjpG_To7gA644aokWaQiNKMryzsjtWRRe PrAB_Iv63NNwfyq86xgkJU.5OI4UZdXpj__k4O7_CnHfppwcvNrBZCGq1SICMXRYcMvwOszCM3no LRLsf8amdfEwBbC2xe6DLCpP_Llrr5oZMIX3oFNIiZgoNGCSr3SswUUKqV9fmcjglLYmyIRAIRj5 7AsgtK3PG9uLsDAXZFPp7zVBZT5ABOorVQGLoPGGgjIEp9LzB8.5I0c8.aL.FvaU3xv5As5krhHH 1hDRc_KR637hKCTqGKiqE2zOPA601i_sduuX4ZVpuT6imJmmCmpApqI.HEdWvvVGy1NpKXoxNHk8 hpr28lHqtgh_2c_hqjruVF4Z9Ckf3PAuBFtSb1.qJ0KvFBazq4oAN6F9VazIAo9CWiP7lK0oK0T_ grycivPux7JL3lR3rsaiRxmnnfklKz9bm6qZnmJSgsXiUVQ8QP_R1mM1CDG4hzckh2oVEatvicF2 VAFw7ttcW1JLySQGPX71IvlDEsGzBbi8s6m_SgME7ejsDw.epYyV1r0HscFOCIilCiNexOVaPNl. li5xwFY8DaAvCvor8kc9MbPdyZWTMCTMKamP.sH89k1qbehMhgpgBu7CHipP56y15qIVdntWsC8B V1b_tQUxx7K60.2LkZwUoY5nlsYWTWeDIiBxjTHHQrbZ.Mwns2I9BhPWj3jzrcyLnd7IxLp4.wTG DHHIh8gqlJiCN4MXSEksQnI0XWQw7PkTcfJZRRtt2mat8ACQyoFWx_5D6UFaykVoqMHKkwvVpukp n9cfqIV_6yPXdFmFimy_4i42U9uZCzqakqnItFJ74z4f.M.dZLJWciUcEndqGPQw.OdsKhx2kUlR aVkr7_AYNtn6Vay97QIluYM0A2KCmKUVYMTBDAKwKI6gsJhKjldGCxnIr_d1MTc4gik.Vdkli64X LMNUNZ1a7aQfqJj4OY7d3ByANEvmqA9nvZXmW.5RYChLNNKtlkLvswcjnjQdRXYnJQUwxQeppuEq 02StB9eVtg8GtoAFWZGvqvsggAeRSOEAG_C79LpChrKKwVfEJwPApilrYD_u_O3Vg6Ip8cyQMyUY g57k4hYiDgzJ0qlFZHxOccbuX5FuodW3SzwUzPmRxK0hp95z.g6Ae928BcIrqidi2Sh15dnBS0MP nbPW4mOyrGsbbJlLEcxSJYu28UHbWx9VuvvinciUArKph5J8.oKGBkpu2FWZxfoiKbBqcfkZeiJR N3m.uOc8.nq34hnHtmf6UhqppnX41fI6d7xhik_Ht1EEsMDP80zsw3uZdOAfzDqggDegKr_Mpx.C E8e7_Si.gmFe0lUA48.8zXDMaiEMafTs.eCxS_i8ZLjS7ehlkGE5jW1IcOVEEM2A7_VToE9SiEHi tIeU5Dgie2iFneDfmrWL2eOwS_NTqOE_tC4fv0nWfUZWo4ZLRiPfqJGnMhP9r1UjzLlv3fKPrUDy Lg.jcqWkZLG5ir4VXXUjhDXtSW.KaJLmCyGb.M7RZRQDhq9vrcRPKSdLVbgihP8kTqMJf2Ni.aPo CwQU1C_satk5Hc8oXHdG8uD8dnu4Ap4HSz.y5GrZCyu2WmDTwHNkiRhFK.GvZTvtiAgbkAyorymg mROYh6kx7LPJXFh7d5387gVuzLS9I4aefoV59WGHZcsCtXdN9GM3_K5CJyRfZsywpHIjA2gsAVmc RQwhipLPlwzwWFrklqFo_F72pDxpw.ZYimbGCsQvATossEMpqW3x.BNODzVgrpTU8QZqQqiqjyrV G.TIhfqzTAEL4McQm7D1Rp_IJ.uPln8xnxj5CO6zdlE7utpCCiyckBSh9uMpvSOJJumu2ExniI5A mrd3EgyOWl.puI_jsB7RHtjWHuIeJ4VOvPpmfBN1FB4vOF7YXMuAPc_7hkcqAmg8EEEBbqcZhhCK RHHG9YSqkK3o_1kjb96dJvS8FwwE2zHpCZqKl5QySZAKIKsxM5fSpncR9h3y42iAA_4MPLI4ZmVG .QO9kVLy5h1sM5HZdeNyqKGpwUAxdzaDT9AsTvHD2BsN0E4C4bMiJoiQBpZhd1FatxfOkM50VDoC FgDCbEO.MFsUAe5NkryLVTqmFbKULC890X0XlRyUKigalJKQAZLmRUkKxCeeFX5PfVnjobKeIDCf z1bXX88OO0BghVYT6An.V1Ds5EZw4ju3d0J45cUEmhO_yfC3elxBnPVXe6Qa1sjsCDyRL_ReS0G0 w2Q8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 10 Dec 2021 22:05:07 +0000 Received: by kubenode533.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 16731730d86b240b17333165f07d997b; Fri, 10 Dec 2021 22:05:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: e.MMC HS400 mode and FreeBSD's retune_ticks for its MMC_SEND_TUNING_BLOCK_HS200 activity when Enhanced Strobe is disabled Message-Id: Date: Fri, 10 Dec 2021 14:05:01 -0800 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4J9lMG4q5Dz4vgB X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="G1mYk4D/"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [2.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_SPAM_MEDIUM(0.85)[0.849]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_SPAM_LONG(0.95)[0.954]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N In reading to learn some about why recent changes broke booting the Rock64 via the e.MMC that I have involved, I ran into the following (that is not the cause of the boot issue but my reading overlapped with the area before figuring that out): . . . int sdhci_generic_tune(device_t brdev __unused, device_t reqdev, bool hs400) { . . . case bus_timing_mmc_hs200: /* * In HS400 mode, controllers use the data strobe line to * latch data from the devices so periodic re-tuning isn't * expected to be required. */ if (hs400) slot->retune_ticks = 0; opcode = MMC_SEND_TUNING_BLOCK_HS200; break; . . . I expect that the above comment is wrong about the reason for needing MMC_SEND_TUNING_BLOCK_HS200 use for HS400 support. So I also expect that the conclusion is wrong when Enhanced Strobe is disabled. Quoting something I wrote elsewhere: QUOTE HS400 needs CMD21 use for synchronizing the command responses on the CMD line to the CLK (a temporary use of HS200 mode to do the tuning). END QUOTE But there is more context that I should have referenced: For HS400, when Enhanced Strobe is disabled, the CMD-out line (from device to host) has no matching strobe to go with it in any fixed signal-timing relationship from what I've read. So I expect that the comment is also wrong about needing the CMD-out line to be periodically retuned vs. not --when Enhanced Strobe is disabled. (Data Out and CRC Response always are synced to the Strobe.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Fri Dec 10 22:39:37 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 87AA218E243A; Fri, 10 Dec 2021 22:40:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9m7g3CWmz3Gs8; Fri, 10 Dec 2021 22:40:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id 77-20020a1c0450000000b0033123de3425so10126621wme.0; Fri, 10 Dec 2021 14:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4EILn3eJFqusQL6CnbT2GOklNsW1NwwTKUSrNYVyxqo=; b=HyiKSLiHMPqS5/jmc0LLi72wYXMDN27paek9grVO0auNpjQdjY+x/Wa7uH3AsR67Fc DSnIuKLCkUpiEWB0tvpDUNZZjOOQRj+tIYTIBiKCS2IqJAMlhNEypVyIbtOoIlmj6hnx mjqoES7FD1m224gccnjhRXYtOXnRnRAThSGRNIXKQQkhr51zqEa6dLz40CAgDMnHkejq IGud3ccE00fKaebqo/MFUdPWO0/hiU6/9hWNCSwn8JR1EUOeW6G5kkKrzBgXoXjSAKbi ohtj2i1HtnrC7UsZDUfqrjDtNo0FLhXtGmOsG+XaanFVcZkTQzujWblR7dI4m/DY2uSW lCSw== 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=4EILn3eJFqusQL6CnbT2GOklNsW1NwwTKUSrNYVyxqo=; b=L09DvGNt3B5DikLuGfev8JAF5bQWgU3Mv5C/PU2+3HVzcFpeV4pPBa+sqkM+Rb5n1m 5wSuNb5TgswIF7WtHJ29T0rlqZFSOPkUhiwTz7NTFLpBs2SXir6W8SD8gt9f8xk3lAdb 7nQVj62pbPsP3BMC/gt4r6f+2ENSpufYVqYPazWzvpVIOp0wAQDiYcsEGkTpddE0qicG Vdpp4ONYgVNW3ZuNaXE9kypy8OmG2fM6W7lAhAXj6YuRTru8yYmQ+kKUew4LEWKRPxF2 ER+kuCIySNDVWEGfdRXpOofzGbKez4BdcDSNcqk4n5Cxhp9GiQYu9iURfL8sRoqYcMgq ykpw== X-Gm-Message-State: AOAM530aXgEMsqvUZYnZWi18V4CT9rZBn48RpKU0uaOWolQ1edv6VIJ1 HKxB/z+5qW66KfgeILWX6gsLecIk3Sg0HC91Hb6t1YD/Vnk= X-Google-Smtp-Source: ABdhPJxNDpt13xhxHCtxAaMl3nCtMaFjxkh/oM/3fMvsal9N52sTel8aZ5EzIUecSKBANHx6xenPNgCZVWcCGX9BcRk= X-Received: by 2002:a05:600c:4f55:: with SMTP id m21mr20602202wmq.68.1639176013983; Fri, 10 Dec 2021 14:40:13 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Sat, 11 Dec 2021 01:39:37 +0300 Message-ID: Subject: Re: configng To: Kyle Evans Cc: FreeBSD Arch , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000009b29505d2d2685d" X-Rspamd-Queue-Id: 4J9m7g3CWmz3Gs8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000009b29505d2d2685d Content-Type: text/plain; charset="UTF-8" On Sat, Dec 11, 2021 at 12:41 AM Kyle Evans wrote: > Hi, > > FYI- we're forming a group to look at what the next generation of config(8) > should look like, with the goal of addressing some long-standing issues > with the existing kernel configuration system. > > If you're interested in participating in the ongoing design discussion, > please shoot an e-mail to kevans@FreeBSD.org or imp@FreeBSD.org. The > current high-level requirement outline can be found here: > https://hackmd.io/w1Tf8mmVQVuZok7-LNEhgw > > The current expectation is that configng will use an entirely different > configuration language, rather than extending what we currently have, and > come with some tooling to aide migration. This will be discussed more > in-depth in later stages; for now, we want to focus on what we want to get > out of the next generation. > > Thanks, > > Kyle Evans > My suggestion may be to use an "expert system" with its "rule" structure . Over time , by adding rules only , you may improve its ability to make decisions for a proper configuration . In that way you will be able to use an expert system to manage your rule base . You may study as a beginning point the CLIPS among many other systems : https://en.wikipedia.org/wiki/CLIPS CLIPS You may design all of expert system as a single XML file or other included XML file names as elements of main XML file ( let's say ) entries . You may need to cooperate with a person being "expert" on "expert systems" . With my best wishes for all , Mehmet Erol Sanliturk --00000000000009b29505d2d2685d-- From nobody Sat Dec 11 05:38:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6DA1A18E467C for ; Sat, 11 Dec 2021 05:38:16 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J9xQ01l8zz4sBq; Sat, 11 Dec 2021 05:38:16 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x934.google.com with SMTP id w23so20392240uao.5; Fri, 10 Dec 2021 21:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kfGxB3z2nnMpcYionZ0bwkjLEPF1wMh2OXV47xW+JpM=; b=X0awBjLMQZAIUn5N+Sk9ZWjQUJCVSTpcKpFnY3tsKtMocW5dKS9n4YE2y5V6qksDuF Yy+HgltYbtBKpFNWb1IZkiuylufztkcLRWlR7SKOoL4xGpSUGHzZ8JVDlW6yBkVbAE6t h3sQm8a8RdwBMA4jxPy9StPMYR/BCPNcib3EsEmFLWf3cXu3qdvILOEdGmTb0/vtqXYt ncwMaIaTY5lwCJ5HwVndVI3lD+5BLfsIdqP4+xj8Fee2Mbr9yIXMyqj//sS1mrwfHA5/ /pBn2MYVSn2y4QJtFQYF11dpw7RWE/SAkaSPnxbEqRM9bgZos7Ysk6eE7lOhyubcEg8/ 52tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kfGxB3z2nnMpcYionZ0bwkjLEPF1wMh2OXV47xW+JpM=; b=VfkPTezIiMJ722yR27aX0QCXOEECFkEdm8JzGiIv+A24qthyTx8FcP/tpJe0iNXPtF LLa4Dw8mgJs9Hqmjpb4lJK3iCMSfkb09difAEW/1dng/Q74nIivQds4PMs4nML/377ZX Hm/cEPZmHBlizP+CDn1fJncl4tOipQv9a2ITUyGS/iRNMVJbWQ3/Jg61CcRtMPJjEh30 2xHAWzUxK46ACoVILpJYXvivd1x1suXfP04JK0YmiBVvQydInBNDdWqU9e5qfxtFsN/A +dI0Ki3HkeiGNIYs/pXi3uDZfsoH0EohmLP5sKLNbN2ddQyftvMONL8bH/cpT0d6o/CE 9Qdg== X-Gm-Message-State: AOAM533UvWZGUCwqCn+d3mahgrL4Q1rceeJEmeggqHQ5JQqRwwatGNic HiEb1zhSk/QrBvZMtgNexXmzTJr0nXuRe/RzoVA0b5Zg7xw= X-Google-Smtp-Source: ABdhPJyEIrgTUPhZgUoknHcDjN1lGN+z3wDvypySD0+ngN0/i23PM0GK3h2o462M2XEjA+SVW11QaqmqfaV4S3j+buk= X-Received: by 2002:a05:6102:548f:: with SMTP id bk15mr19663483vsb.31.1639201095461; Fri, 10 Dec 2021 21:38:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> <50ce89e135767d11adc2f90a602b28ce@FreeBSD.org> In-Reply-To: <50ce89e135767d11adc2f90a602b28ce@FreeBSD.org> From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Sat, 11 Dec 2021 08:38:04 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Lars Engels Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4J9xQ01l8zz4sBq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N freebsd-pf: matching and logging receive interface and xmit interface in single rule (ipfw has support) I'm looking for a solution to match a traffic received on igb0 and xmit on = igb1. According to man page, ipfw(8) supports this syntax: ipfw add deny ip from any to any out recv ed0 xmit ed1 The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in is invalid) whenever xmit is used. Is it possible to add support to pf for this feature like ipfw? Have a nice day On Fri, Dec 10, 2021 at 1:16 PM Lars Engels wrote: > > Am 2021-12-09 19:25, schrieb =C3=96zkan KIRIK: > > bsnmpd: monitoring jails (event with different vnet) resources like > > interfaces, cpu usage etc. > > > > I don't have an account to modify wiki. thanks > > > I added this to the wiki page. > From nobody Sat Dec 11 09:59:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 32DA718CE881 for ; Sat, 11 Dec 2021 09:59:51 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB3Cn6GK4z4T4g for ; Sat, 11 Dec 2021 09:59:49 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f180.google.com with SMTP id k23so17057920lje.1 for ; Sat, 11 Dec 2021 01:59:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qPOtUlHxUb4O85bfqD1YotGDA5db4r7/Y295E2LfcbU=; b=wit+ErGJpMgiHyHf5dmSFROpI2Eb6ACB4g6XDelZPj4fQ/l+8FjETq0UtXHyOUKpfa FcEMa99lzBNQF6i6kfgYqUoaJ6QgHe2ZXtWi8imqIDAaUc4cxZ3CQlgiNkZ52toXadJF J9W9fB0dX68Em/9Op+Eukn08vQGGWp1qB4rIDh++cNJt2+xmS+f3GaAl5VzJpgYOhbja rZj8olFIcI113PtOJnZ+XH/tb5fFAz04N9wPFodRl2YAlxJG6ir2qbxH1Me/kWBO18GZ ZEKl4XOaK0ijzAX4kOhl9tLhdpuplg1wD+TGX1yBTwHnkOMMZdSgSzSWqeDVrv5iLf/h ctbw== X-Gm-Message-State: AOAM531IuSZt8pYJ5yJNUOpNeobEV43oEds6qKMzea6Ulw4zkODkazO/ 5z9i4upYc8sQ8BiRkfuxNgBcPrLLGE4QXA== X-Google-Smtp-Source: ABdhPJx2kfzBTIRBLwVqlpKvKiSxWyL/a1aTiFzvzq7lwwtfBF+ZnrSNjCGiJ5pMIhLnzPYlplEgEQ== X-Received: by 2002:a2e:5c04:: with SMTP id q4mr18108391ljb.334.1639216781837; Sat, 11 Dec 2021 01:59:41 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id c25sm560412lja.38.2021.12.11.01.59.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Dec 2021 01:59:41 -0800 (PST) Received: by mail-lf1-f51.google.com with SMTP id bu18so22406697lfb.0 for ; Sat, 11 Dec 2021 01:59:41 -0800 (PST) X-Received: by 2002:a05:6512:ba8:: with SMTP id b40mr17737514lfv.114.1639216781341; Sat, 11 Dec 2021 01:59:41 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> In-Reply-To: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> From: Gleb Popov Date: Sat, 11 Dec 2021 12:59:15 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: What to use in place of abstract unix sockets? To: "Daniel O'Connor" Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000f637db05d2dbe5c0" X-Rspamd-Queue-Id: 4JB3Cn6GK4z4T4g X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-1.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-0.79)[-0.789]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.180:from,209.85.167.51:received]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.180:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f637db05d2dbe5c0 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 10, 2021 at 12:09 PM Daniel O'Connor wrote: > > > > On 10 Dec 2021, at 18:23, Gleb Popov wrote: > > > What can I do to make this software work for FreeBSD? Simply using > regular > > > UDS instead of abstract ones doesn't work for obvious reasons - the > > > "client" can't find the socket file. > > > > If the parent knows where the child will chroot it could create a unix > domain socket under that directory somewhere. > > > > Same problem as above - there should be a single socket on the erver > side. > > I just did a quick test with nc and you can hard link unix domain sockets > so you could bind it in the parent then hard link it for each child. > > Seems pretty kludgy though :) > This is actually a nice suggestion, as it is simple to try out. However, it doesn't work, the link() call fails with EXDEV: Cross-device link This might be because the chroot's target directory is an nullfs mount. Am I right that it isn't possible to create hard links that span nullfs mount points? --000000000000f637db05d2dbe5c0-- From nobody Sat Dec 11 11:22:44 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0978D18E3321 for ; Sat, 11 Dec 2021 11:22:50 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB53Y5zH4z4ndn for ; Sat, 11 Dec 2021 11:22:49 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 1BBBMin5020112 for ; Sat, 11 Dec 2021 03:22:50 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 11 Dec 2021 03:22:44 -0800 From: Chris To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> <50ce89e135767d11adc2f90a602b28ce@FreeBSD.org> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_b2a48954112c92ee83d5989fb4216748" X-Rspamd-Queue-Id: 4JB53Y5zH4z4ndn X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_b2a48954112c92ee83d5989fb4216748 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Sorry for the top-post. Phoronix recently created a comparison: Linux vs BSD[1] Given they know little about the BSD's. The competition was pretty biased towards the Linux's. It would be great if the Foundation could produce a similar completion that was more correctly/fairly weighted. It would be great for (BSD) Promotion/Advertising/Evangelism. If done well. It would give better credence to the sponsored tests making it the "defacto" test/comparison. Which should also show FreeBSD in a better light. As opposed to all the other tests performed by Linux users with little-to-no-knowledge of the BSD's. -- Chris 1. https://www.phoronix.com/scan.php?page=article&item=bsd-linux-eo2021&num=1 On 2021-12-10 21:38, Özkan KIRIK wrote: > freebsd-pf: matching and logging receive interface and xmit interface > in single rule (ipfw has support) > > I'm looking for a solution to match a traffic received on igb0 and xmit on > igb1. > According to man page, ipfw(8) supports this syntax: > > ipfw add deny ip from any to any out recv ed0 xmit ed1 > > The recv interface can be tested on either incoming or outgoing > packets, while the xmit interface can only be tested on outgoing > packets. So out is required (and in is invalid) whenever xmit is > used. > > Is it possible to add support to pf for this feature like ipfw? > > Have a nice day > > On Fri, Dec 10, 2021 at 1:16 PM Lars Engels wrote: >> >> Am 2021-12-09 19:25, schrieb Özkan KIRIK: >> > bsnmpd: monitoring jails (event with different vnet) resources like >> > interfaces, cpu usage etc. >> > >> > I don't have an account to modify wiki. thanks >> >> >> I added this to the wiki page. >> --=_b2a48954112c92ee83d5989fb4216748 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_b2a48954112c92ee83d5989fb4216748-- From nobody Sat Dec 11 13:08:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09BB118CE289 for ; Sat, 11 Dec 2021 13:08:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JB7P71M8Fz3J0W; Sat, 11 Dec 2021 13:08:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 1BBD84QY070280 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 11 Dec 2021 08:08:04 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4::29] ([IPv6:2607:f3e0:0:4:0:0:0:29]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 1BBD84N5079683 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 11 Dec 2021 08:08:04 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <07e181c5-fb4c-8ac2-2948-2986062bed5c@sentex.net> Date: Sat, 11 Dec 2021 08:08:04 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Call for Foundation-supported Project Ideas Content-Language: en-US To: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> From: mike tancsa In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4JB7P71M8Fz3J0W X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [0.33 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.43)[-0.427]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_SPAM_SHORT(0.22)[0.220]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.84)[0.837]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi,     A somewhat late add, but perhaps some resources behind the MPLS efforts https://lists.freebsd.org/archives/freebsd-net/2021-November/000977.html     ---Mike On 11/23/2021 5:41 PM, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? > > You can read about past Foundation-supported projects at > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > four main areas of focus in the 'Technology Roadmap' article at > https://freebsdfoundation.org/blog/technology-roadmap/. > > Right now we are gathering ideas. We will send out a call for project > grant proposals soon. If you prefer to send your project ideas directly > to the Foundation, we will be monitoring responses at > techteam@freebsdfoundation.org. > > -- > Joe (with Foundation hat on) > From eugen@grosbein.net Sat Dec 11 16:20:33 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3ECC718D33E6 for ; Sat, 11 Dec 2021 16:21:12 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBCgr04dWz4RW6; Sat, 11 Dec 2021 16:21:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1BBGKkml067079 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Dec 2021 16:20:47 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: arrowd@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1BBGKjDZ040335 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 11 Dec 2021 23:20:45 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: What to use in place of abstract unix sockets? To: Gleb Popov , "Daniel O'Connor" References: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> Cc: freebsd-hackers From: Eugene Grosbein Message-ID: Date: Sat, 11 Dec 2021 23:20:33 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4JBCgr04dWz4RW6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 11.12.2021 16:59, Gleb Popov wrote: > EXDEV: Cross-device link > > This might be because the chroot's target directory is an nullfs mount. Am > I right that it isn't possible to create hard links that span nullfs mount > points? It is not possible to create hard links for source and destination directories with different st_dev values as per stat(2), this includes nullfs, each of which has its own st_dev id. From nobody Sat Dec 11 16:55:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 053BE18DAD4D for ; Sat, 11 Dec 2021 16:56:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBDSK4ydDz4XNX; Sat, 11 Dec 2021 16:56:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1BBGtnn2045131 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 Dec 2021 18:55:52 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BBGtnn2045131 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BBGtn4r045130; Sat, 11 Dec 2021 18:55:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 11 Dec 2021 18:55:49 +0200 From: Konstantin Belousov To: Eugene Grosbein Cc: Gleb Popov , "Daniel O'Connor" , freebsd-hackers Subject: Re: What to use in place of abstract unix sockets? Message-ID: References: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4JBDSK4ydDz4XNX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 11, 2021 at 11:20:33PM +0700, Eugene Grosbein wrote: > 11.12.2021 16:59, Gleb Popov wrote: > > > EXDEV: Cross-device link > > > > This might be because the chroot's target directory is an nullfs mount. Am > > I right that it isn't possible to create hard links that span nullfs mount > > points? > > It is not possible to create hard links for source and destination directories > with different st_dev values as per stat(2), this includes nullfs, > each of which has its own st_dev id. The VOP_UNP_BIND() and VOP_UNP_CONNECT() vops are bypassed to the lower fs. It means that if you bind(2) or connect(2) on unix domain socket that is visible through nullfs mount, effectively you are doing the bind or connect operation on the lower filesystem. That said, implementing 'abstract' unix socket addresses would be nice. From nobody Sat Dec 11 17:02:36 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8BB6518DC4BF for ; Sat, 11 Dec 2021 17:02:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBDbx5p7Gz4Yq8; Sat, 11 Dec 2021 17:02:53 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f45.google.com with SMTP id 47-20020a9d0332000000b005798ac20d72so12822164otv.9; Sat, 11 Dec 2021 09:02:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9pJsVgvIvmnOR5/yZ/QYtmknOuWrq/u7/U+xyMwNvvk=; b=XvDhjG2dAvN9Eh/ZAZ2pOntPYiVf/pyqDU4daA2MkEqpfZE+fPVVsv7UtRU39ysWMW wiDlBATDcEQ1J88a3nGBgrgYBjS4lqeP0pkfuwG51e52BW9Qs3elPlwpdsr2mdXTm247 AtA2RN6TJZtjS6Ka8GvP9mvCysX76G9/WTkr7o1S7fOj0mQGGBtKIWnTKFq3Ouvbr/GP bB/h87mxI/fYtg6I1ayUuWjkHWVK/7R27ybuNDky09KPz6/yrhggMO7CyW+P1KmFQxak ihifKR7Fvxkj1/+yNFiettVCIJr2BHBDsud+9ptosSn68unS3Yi5HsXvbVYNq2132CET R6fA== X-Gm-Message-State: AOAM532bNZ79J1qCVP1OHWxY410sBKP/g29Z/LoxQxAquZEOqYQidBHY b/2qyq+D1X5Rz48Ek3iQGYRWjwStpsr7gX2JSLF6+bRi X-Google-Smtp-Source: ABdhPJyO2AwFQpdp60AWFXTe7s9srovXDb6+iqI21LwZU5DeB9Q+DSf05Q+Guuz8wpiHOayGq/AikeZN2G5HzCkf+7M= X-Received: by 2002:a9d:6d98:: with SMTP id x24mr16014641otp.371.1639242167241; Sat, 11 Dec 2021 09:02:47 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 11 Dec 2021 10:02:36 -0700 Message-ID: Subject: Re: What to use in place of abstract unix sockets? To: Gleb Popov Cc: "Daniel O'Connor" , Eugene Grosbein , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JBDbx5p7Gz4Yq8 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.45 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [0.75 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; 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(-0.25)[-0.250]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.45:from]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.45:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 10, 2021 at 12:54 AM Gleb Popov wrote: > > On Wed, Dec 8, 2021 at 10:50 AM Eugene Grosbein wrote: > > > 08.12.2021 13:43, Gleb Popov wrote: > > > > > Hello hackers. > > > > > > I'm porting a software that does the following things on Linux: > > > > > > 1. Binds an abstract UDS (the socket name starts with '\0') > > > 2. Launches a "client" process. > > > 3. "Client" uses chroot() to constrain itself in a sort of jail. > > > 4. "Client" connects to the abstract UDS. > > > > > >>From what I can tell, this works because abstract UDS's do not use the > > > filesystem namespace, which is why "client" can connect out of the > > > chroot'ed environment. > > > > > > What can I do to make this software work for FreeBSD? Simply using > > regular > > > UDS instead of abstract ones doesn't work for obvious reasons - the > > > "client" can't find the socket file. > > > > > > Thanks in advance. > > > > If they are parent/child, you could try using socketpair(). > > > > There are actually multiple children. If I understand it right, using > socketpair() would lead to N sockets on the server side for the N connected > clients. Right now there is a single UDS that handles all connections, so > rewriting it with socketpair() would be problematic, I think. > > > > > On Thu, Dec 9, 2021 at 3:08 AM Daniel O'Connor wrote: > > > > > > > > On 8 Dec 2021, at 17:13, Gleb Popov wrote: > > > I'm porting a software that does the following things on Linux: > > > > > > 1. Binds an abstract UDS (the socket name starts with '\0') > > > 2. Launches a "client" process. > > > 3. "Client" uses chroot() to constrain itself in a sort of jail. > > > 4. "Client" connects to the abstract UDS. > > > > > > From what I can tell, this works because abstract UDS's do not use the > > > filesystem namespace, which is why "client" can connect out of the > > > chroot'ed environment. > > > > > > What can I do to make this software work for FreeBSD? Simply using > > regular > > > UDS instead of abstract ones doesn't work for obvious reasons - the > > > "client" can't find the socket file. > > > > If the parent knows where the child will chroot it could create a unix > > domain socket under that directory somewhere. > > > > Same problem as above - there should be a single socket on the server side. Since socketpair() doesn't work in this case, why not just use a UDP socket bound to 127.0.0.1 ? From nobody Sat Dec 11 17:48:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DC2F518E48F5 for ; Sat, 11 Dec 2021 17:48:34 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBFcd6WZ8z4gFv for ; Sat, 11 Dec 2021 17:48:33 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qv1-xf2c.google.com with SMTP id u16so10823149qvk.4 for ; Sat, 11 Dec 2021 09:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=WT/5GpyUlNxbSTn2TEA1iVRteQk5hVnXeVGZShrmKww=; b=HzNYzn0hvW815PcrcfmONjen+jRPu77iGkx1DeiEAu58ZgOEWb/EkX6XeCTZCOzg+n rNTPJIYgLitA6nNu0lI8lf8EFyTev4b0gXNqIARsuHqN1D4pT9snHN2PNBvqMAsjaaRP StLUGwVJfVNpIOqtHCPCeL5AF8u9mnw6LryGxiSxvddVwt6BiCNaa9nTvZRZOY1WlHs4 uEougXZf8BVSJAizisTY40HwxDWj9IH5rRHeTRasgkACEosTfb9gm1hkfnjyGASv7eNo ZBP67avIqTgy49EI9IJz40enJ84+/QKLMJJNoeDMnjSL/q6m2rbD571s3B7JvV536MX2 dDXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=WT/5GpyUlNxbSTn2TEA1iVRteQk5hVnXeVGZShrmKww=; b=iNZzqgv5OkDdu47ieafZr76xi1P+98PbC8AZ/4jja7SUuuLOeQwP21SZr5A1MfyQqY 99b6fz9sLkLZ/JOp9U6PTmILY61E+qC4KLmj0O5uJymkkXCfg5fIjIieqi+Beaw4JFIH ac1o22Qf0hcqFnVOmsctommOe5GEnnJ60ebspMuU7pJ4SZECxcB7x0mujsF6ZPXlHBRA DPuXnG4xfNn12+dQgsBaTR7KGEDzBRXOUkFo3S94NKB/PTl1cS0fqTiW0YDUFu+6ZYuL 5F/3qLZ32kBq5aswmcDDcavX/R89wK2YBQng57eJJFvTUbfYUii3TgbNUk7J08yXvnlP rkag== X-Gm-Message-State: AOAM532Aco83k6avr6T94zbhfZTwoNsD4DdJrAye+rQFfCWt+RHLnFmR fd95zDIbz7QeoZ/AHkZ0pMOJQw== X-Google-Smtp-Source: ABdhPJyukTGxrG5ApJyf9V4Efr7S8LRe3MmhCSh4g47+MPqYAoiiksnxPFz4EgFokIvTjZ50Hy4sXw== X-Received: by 2002:a05:6214:2021:: with SMTP id 1mr32234456qvf.75.1639244907393; Sat, 11 Dec 2021 09:48:27 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id x25sm3232835qkf.91.2021.12.11.09.48.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Dec 2021 09:48:26 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Bakul Shah List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: What to use in place of abstract unix sockets? Date: Sat, 11 Dec 2021 09:48:23 -0800 Message-Id: <44CC9776-D2C1-4B37-8758-3D94C35AE97A@iitbombay.org> References: Cc: freebsd-hackers In-Reply-To: To: Gleb Popov X-Mailer: iPad Mail (19B74) X-Rspamd-Queue-Id: 4JBFcd6WZ8z4gFv X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=HzNYzn0h; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::f2c as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [1.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[iitbombay.org]; NEURAL_SPAM_MEDIUM(0.98)[0.981]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_SPAM_LONG(0.41)[0.413]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Dec 7, 2021, at 10:44 PM, Gleb Popov wrote: >=20 > =EF=BB=BFHello hackers. >=20 > I'm porting a software that does the following things on Linux: >=20 > 1. Binds an abstract UDS (the socket name starts with '\0') > 2. Launches a "client" process. > 3. "Client" uses chroot() to constrain itself in a sort of jail. > 4. "Client" connects to the abstract UDS. >=20 > =46rom what I can tell, this works because abstract UDS's do not use the > filesystem namespace, which is why "client" can connect out of the > chroot'ed environment. >=20 > What can I do to make this software work for FreeBSD? Simply using regular= > UDS instead of abstract ones doesn't work for obvious reasons - the > "client" can't find the socket file. >=20 > Thanks in advance. Can you not pass one end of unix domain socketpair via sendmsg/recvmsg?= From nobody Sat Dec 11 17:57:28 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9ECF818E6EE6 for ; Sat, 11 Dec 2021 17:57:47 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org (gritton.org [162.220.209.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gritton.org", Issuer "gritton.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBFqH3KW8z4hlp; Sat, 11 Dec 2021 17:57:47 +0000 (UTC) (envelope-from jamie@freebsd.org) Received: from gritton.org ([127.0.0.3]) (authenticated bits=0) by gritton.org (8.16.1/8.16.1) with ESMTPA id 1BBHvSBH058010; Sat, 11 Dec 2021 09:57:28 -0800 (PST) (envelope-from jamie@freebsd.org) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 11 Dec 2021 09:57:28 -0800 From: James Gritton To: freebsd-hackers Cc: Eugene Grosbein , Gleb Popov , "Daniel O'Connor" , Konstantin Belousov Subject: Re: What to use in place of abstract unix sockets? In-Reply-To: References: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <2c4d62457377d7bde6a0fbad1050ef8e@freebsd.org> X-Sender: jamie@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JBFqH3KW8z4hlp X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 2021-12-11 08:55, Konstantin Belousov wrote: > That said, implementing 'abstract' unix socket addresses would be nice. Though if that were to happen, I would want to separate the namespaces of the abstract sockets. This seems an analog to the POSIX shm pseudo-file namespace, which has similar names that aren't really files (though they still follow a file-like naming scheme). And then we'd be back where we are now, with a way to add a socket to a jail's namespace, but requiring per-jail sockets (because there is no abstract namespace hard-link). - Jamie From eugen@grosbein.net Sat Dec 11 18:57:10 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2C17B18CBDE3 for ; Sat, 11 Dec 2021 18:57:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JBH8V6Xngz4spc; Sat, 11 Dec 2021 18:57:46 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1BBIvMwG068166 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 11 Dec 2021 18:57:23 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: jamie@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1BBIvMk8041339 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 12 Dec 2021 01:57:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: What to use in place of abstract unix sockets? To: James Gritton , freebsd-hackers References: <58874E76-8541-46BF-A197-C984D6A869DF@dons.net.au> <2c4d62457377d7bde6a0fbad1050ef8e@freebsd.org> Cc: Gleb Popov , "Daniel O'Connor" , Konstantin Belousov From: Eugene Grosbein Message-ID: Date: Sun, 12 Dec 2021 01:57:10 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <2c4d62457377d7bde6a0fbad1050ef8e@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4JBH8V6Xngz4spc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 12.12.2021 0:57, James Gritton wrote: > On 2021-12-11 08:55, Konstantin Belousov wrote: >> That said, implementing 'abstract' unix socket addresses would be nice. > > Though if that were to happen, I would want to separate the namespaces > of the abstract sockets. This seems an analog to the POSIX shm > pseudo-file namespace, which has similar names that aren't really > files (though they still follow a file-like naming scheme). > > And then we'd be back where we are now, with a way to add a socket to > a jail's namespace, but requiring per-jail sockets (because there is > no abstract namespace hard-link). It would still be usable for chrooted application as opposed to jailed. As for jails, we could introduce new jail attribute that makes it abstract socket namespace isolated or shared with global one. From nobody Mon Dec 13 02:22:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 93A2018E49BE; Mon, 13 Dec 2021 02:22:31 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JC4zB3Yk6z4Vst; Mon, 13 Dec 2021 02:22:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BD2MN81041496 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Dec 2021 18:22:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BD2MN7g041495; Sun, 12 Dec 2021 18:22:23 -0800 (PST) (envelope-from sgk) Date: Sun, 12 Dec 2021 18:22:23 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211213022223.GA41440@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JC4zB3Yk6z4Vst X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: > > > > On 4 Dec 2021, at 18:53, Steve Kargl wrote: > > > > > > So, is anyone interested in seeing a massive patch? > > Me, please! > So, I have the ld80 case working. I'll open a PR if on does not exist. The pr will contain 1) Diff for nonfunctional changes to code for tgamma(x). This is a re-organization of the code so I could reverse it. Some cleanup of comments and documentations. A move towards style(9) 2) Advice on what to do about tgammal(x) on ld128 hardware. Essentially, need to do the git equivalent of 'svn mv imprecise.c ld128/b_tgammal.c. 3) Diff with the new code for ld80 tgamma. Interval tested for tgammal: [6,1755.1] 5000000 calls, 2.056068 secs, 0.41121 usecs/call ulp <= 0.5: 90.233% 4511666 | 90.233% 4511666 0.5 < ulp < 0.6: 7.061% 353033 | 97.294% 4864699 0.6 < ulp < 0.7: 2.393% 119644 | 99.687% 4984343 0.7 < ulp < 0.8: 0.300% 14981 | 99.986% 4999324 0.8 < ulp < 0.9: 0.014% 676 | 100.000% 5000000 Max ulp: 0.873414 at 1.480588145237629047468e+03 Interval tested for tgammal: [1.0662,6] 5000000 calls, 0.748966 secs, 0.14979 usecs/call ulp <= 0.5: 96.355% 4817737 | 96.355% 4817737 0.5 < ulp < 0.6: 3.291% 164534 | 99.645% 4982271 0.6 < ulp < 0.7: 0.328% 16403 | 99.973% 4998674 0.7 < ulp < 0.8: 0.026% 1297 | 99.999% 4999971 0.8 < ulp < 0.9: 0.001% 29 | 100.000% 5000000 Max ulp: 0.861508 at 1.999467927053585410537e+00 Interval tested for tgammal: [1.01e-17,1.0661] 5000000 calls, 0.904246 secs, 0.18085 usecs/call ulp <= 0.5: 96.201% 4810043 | 96.201% 4810043 0.5 < ulp < 0.6: 3.297% 164875 | 99.498% 4974918 0.6 < ulp < 0.7: 0.412% 20581 | 99.910% 4995499 0.7 < ulp < 0.8: 0.082% 4108 | 99.992% 4999607 0.8 < ulp < 0.9: 0.008% 389 | 100.000% 4999996 0.9 < ulp < 1.0: 0.000% 4 | 100.000% 5000000 Max ulp: 0.938041 at 1.023286481537296307856e+00 Interval tested for tgammal: [-1.9999,-1.0001] 5000000 calls, 1.740820 secs, 0.34816 usecs/call ulp <= 0.5: 56.596% 2829776 | 56.596% 2829776 0.5 < ulp < 0.6: 8.616% 430793 | 65.211% 3260569 0.6 < ulp < 0.7: 7.452% 372621 | 72.664% 3633190 0.7 < ulp < 0.8: 6.250% 312511 | 78.914% 3945701 0.8 < ulp < 0.9: 5.147% 257372 | 84.061% 4203073 0.9 < ulp < 1.0: 4.100% 205010 | 88.162% 4408083 1.0 < ulp < 1.5: 9.846% 492324 | 98.008% 4900407 1.5 < ulp < 2.0: 1.790% 89514 | 99.798% 4989921 2.0 < ulp < 3.0: 0.201% 10074 | 100.000% 4999995 3.0 < ulp < 0.0: 0.000% 5 | 100.000% 5000000 -- Steve From nobody Mon Dec 13 13:26:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BE51218F39E8 for ; Mon, 13 Dec 2021 13:27:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCMjv68T0z4r3H for ; Mon, 13 Dec 2021 13:26:59 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x830.google.com with SMTP id n15so15168822qta.0 for ; Mon, 13 Dec 2021 05:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=EhDaxUh//6B4RDy2KNuu2Dmx3GK/vKMh0GnMao81moA=; b=QezUskpYrikTAu57Omg+1OwypNO5AQ+TuFRqdrVdVibcv1Z+adYAU3zr63tnDqaGbj oxWec4Mlkee8qA5oupoIgm/+wjyZQkZlPM+jyaQjTnxpRK6Xe250jc3grK/Uxp8WkkoG +czexyFtzLPAoUk/PN/R2FV0tKc7HG43lYStbtkOydoROHQD1/ZpapW7D12Odlmfh7Em 8bXFDrhySitQIzK717xXZTIMGz784ptH2VUZVv9rhMI0f6qD03WCpC4xOAnYjYnsXsoq hm8Zz+hUcrllXsfRM1Is4UmVXjs0YHTvuhsuxHng5j2aMVfGBr2TR8kvaADq0UyrPvcP dIyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EhDaxUh//6B4RDy2KNuu2Dmx3GK/vKMh0GnMao81moA=; b=bOe+x7J3NjarX+dWO1YwjbyA/KIyXuoIYmAf7EoAGSxFxLO9QH6mShcdpKz2PHAYXM JdQfvEozNWoYW91+waMsY+xDQMswuXcNoFXLwv5KmlIMdfL+41Md3V8gJLZpijSrefhE LcSVGn2HRVJT2z0aEUOkLwjOg9atvfzz3nFkz37CSHmt3VGfgg7yiLWxSCez3pgeZpUy 51kq1xfIrsqB57zolBRUz4M4CG+WGfb4FbBokhSX9UNNNhGX0+rB/Y2EvpyrfencLJ+x gGZx+8GSDza3jp/JBl9qku6byOeMmvC7pKBAW5PRDuLnl42/xhbSeXGdaZeLeGHIIsop HNiA== X-Gm-Message-State: AOAM530T6KsgPO9VRFEUP6NyOUxPSKtgBG4TDu07nKNXE+MpOnQaNHKb Hr6XXs98KLyjOk0VsBTrhFH5LOcxSDoHI07Q X-Google-Smtp-Source: ABdhPJySZuztjnWudfsUBmWVfjbfOIglpPY3urCgZgD+6/WJsQb2x1RuPU/a1CthNWZjYLtq02Gn+A== X-Received: by 2002:ac8:5a0b:: with SMTP id n11mr45392212qta.372.1639402019420; Mon, 13 Dec 2021 05:26:59 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id v12sm9461501qtx.80.2021.12.13.05.26.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Dec 2021 05:26:58 -0800 (PST) Date: Mon, 13 Dec 2021 08:26:58 -0500 From: Shawn Webb To: Joseph Mingrone Cc: FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-ID: <20211213132658.x5sfzqntltrkp25x@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <861r36xzpe.fsf@phe.ftfl.ca> <20211123232814.6vx3sqnsdvc52oc3@mutt-hbsd> <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qw2nclyin4tnonzo" Content-Disposition: inline In-Reply-To: <20211124213150.6lsyaqgwbkgfcgzi@mutt-hbsd> X-Rspamd-Queue-Id: 4JCMjv68T0z4r3H X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=QezUskpY; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-3.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-0.91)[-0.907]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received] X-ThisMailContainsUnwantedMimeParts: N --qw2nclyin4tnonzo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 24, 2021 at 04:31:50PM -0500, Shawn Webb wrote: > On Tue, Nov 23, 2021 at 06:28:14PM -0500, Shawn Webb wrote: > > On Tue, Nov 23, 2021 at 06:41:01PM -0400, Joseph Mingrone wrote: > > > Hello FreeBSD community, > > >=20 > > > The Foundation is seeking suggestions for new projects to support. W= hat > > > gaps in the Project are not being addressed by the broader community? > > >=20 > > > You can read about past Foundation-supported projects at > > > https://freebsdfoundation.org/our-work/projects/ and the Foundation's > > > four main areas of focus in the 'Technology Roadmap' article at > > > https://freebsdfoundation.org/blog/technology-roadmap/. > > >=20 > > > Right now we are gathering ideas. We will send out a call for project > > > grant proposals soon. If you prefer to send your project ideas direc= tly > > > to the Foundation, we will be monitoring responses at > > > techteam@freebsdfoundation.org. > >=20 > > Hey Joseph, > >=20 > > Thanks for sending this out! > >=20 > > Here's just a few things I'd love to see: > >=20 > > 1. wireless mesh support. this would go _a long_ ways for supporting > > human rights efforts. > > 2. 100% llvm toolchain for base and ports. freebsd seems to already be > > going in this direction. > > 3. jail orchestration in base. it's great that we have all these > > disparate jail management ports, but we lack a fully > > coherent/integreated solution. I'd love to see jail orchestration > > get the same love as zfs in base. > > 4. tor browser bundle (port from openbsd?) > >=20 > > That's at least what I can think of off the top of my head. >=20 > Another idea: >=20 > 5. Distributed Poudriere. I have a few systems that would benefit from > such a feature. For example, two ThunderX1 systems. And once I > resurrect our partially-dead ThunderX2 system, we'll have three > arm64 appliances in which we can build packages. Another idea: Make unionfs stable and usable. unionfs is plagued by quite a few issues. I'm currently running into a unionfs-related kernel panic at ${DAYJOB} when building our appliance firmware. And I have a major release happening in four days. ;-) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --qw2nclyin4tnonzo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmG3Sh8ACgkQ/y5nonf4 4fqV8w/7B6FvtptBbtp6Z8ofqPQNH1+VndD7V63blmW96dHbErjlMAvg927yagTk 5nV0NIvC8llLnDn5vh+ElmHFxoF5ZkYgdvjuDc5wbNplMzCMlt8K/EQFt1mVSYDO o92EpQcADVBalR4f/iwSlZdJhawRcejRlu+gLPbGhARrzEuvpHzumqtw4AdLtjmb Enj87UxCfm5p08+abKWLTUjcj6z+lFDHxrwxj+83bVik8SSli/Jm4KrbQGocb1FX GVweBwjQJxei7er0QCYBuWY2w1khllWqRpzeAMenkrNCkc8M5kJ4WZH7QLje0Qk2 fyyhzGAQww8/G5erE2q3quf5veK/cYjbp4uQptfib6WHWtWJ/YLDFOi9sm9uElbm 2aJnkhlLBT7fDiaZcn6sooQh3gNCGRcOqm+Xrhv+Iw/ZoMhWKt6yCygMrXoe1R2T k9tqyiKZKrrANGI1XisYdAOCmv8Om0/9H2mG6Ar0AwmuHfx0bCpbqGdLRz6Kk6sc ujJ0UvnoIMQagugxDUuUYMFo2tPdKWaUB9EgMgeykUl7t9WGbUTCrPPLOMqaESpI ogyjIZqIt/k+ksvT4VKJSbym5S1H6Rxf3JGrcx5ya0UKMbytGOpPdoFlhs9xAHnu JrNL6UeYkdhPiKhiwya578idKhGSacQF/Hrj7O3u8OI23G1Ntqs= =AH9o -----END PGP SIGNATURE----- --qw2nclyin4tnonzo-- From nobody Mon Dec 13 14:24:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0ECE518D9BA1 for ; Mon, 13 Dec 2021 14:25:24 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCP1H1fWqz3L6Y; Mon, 13 Dec 2021 14:25:23 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lj1-f171.google.com with SMTP id k23so23970394lje.1; Mon, 13 Dec 2021 06:25:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Kg0xCGAxQmATkd/NIu0M0pKXUjIwIzdfkSnGUIrHhA=; b=AzrBk1LBlhnaQAMWrVNreahG2u2QvF+pSI+1I6SlZWx7/NnKvE7SdVDIDGrQSOhTcQ 39BiqD516kUuAEzdqhBB58AsIZ9N8NeFSX+jsvoqAvxEfrMl201wALgyV1AqlJCchEXX VO68jPMlWbP/LAK0mBA7iOr7MGHpuz8qC9NCvPuEM77LuMe/EXahrgdwIzdWz7hmhENy wIDZLwwAaMiKWO3nr2wPYc7+KHlUYMb/O5TYd5f7RbUE7j8yuTSSunpDs/Bs4j+9Y74K N3SOC8ulrnfrZ+pUqZMauPp8J+ehhlOs73VKp8lqD4t8pbaOZXqslTeKOqst4uUXMco2 lpZA== X-Gm-Message-State: AOAM533VinPFfuoPBGcAZY8XF7mDK7FwlY/9yhc99GV7W38n/aKeHde0 tUrQ6oiUQIXzuq2PIr3aA7walOA51tus6w== X-Google-Smtp-Source: ABdhPJyFQ+PXwntpPt0Yf6EH2lGdouW0MHVOoiRtI4T1LLtqbwSpFaxO/Oapw0Abq4TFZM+y+sVohQ== X-Received: by 2002:a05:651c:4ca:: with SMTP id e10mr29318786lji.101.1639405516371; Mon, 13 Dec 2021 06:25:16 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id o15sm1456114lfd.164.2021.12.13.06.25.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Dec 2021 06:25:15 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id e24so5442232lfc.0; Mon, 13 Dec 2021 06:25:15 -0800 (PST) X-Received: by 2002:a05:6512:3405:: with SMTP id i5mr28810704lfr.471.1639405515542; Mon, 13 Dec 2021 06:25:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Mon, 13 Dec 2021 17:24:49 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: What to use in place of abstract unix sockets? To: Alan Somers Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="00000000000065945e05d307d7fc" X-Rspamd-Queue-Id: 4JCP1H1fWqz3L6Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.208.171 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.171:from,209.85.167.50:received]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.171:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000065945e05d307d7fc Content-Type: text/plain; charset="UTF-8" On Sat, Dec 11, 2021 at 8:02 PM Alan Somers wrote: > Since socketpair() doesn't work in this case, why not just use a UDP > socket bound to 127.0.0.1 ? > This would introduce a bit of overhead as the packet would pass through the IP stack. Another problem is that the current code uses SOCK_STREAM socket type, which isn't supported by the UDP protocol. Maybe this would work with SCTP? Anyways, I'm going to try this only as a last resort. OK, so far my options are: 1. Mount the directory containing UDS into chroot with nullfs. 2. Use PF_INET. 3. Do kernel-hacking and implement abstract sockets (as well as remount-to-readonly support for nullfs). I'd go straight to #3 but with my skills/free time this would take a lot of time, so I'm going to try hacking it around with #1 and #2. Thanks everyone for all the suggestions. --00000000000065945e05d307d7fc-- From eugen@grosbein.net Mon Dec 13 16:53:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5370318D9432 for ; Mon, 13 Dec 2021 16:54:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCSJw0QQYz4WWv; Mon, 13 Dec 2021 16:54:07 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 1BDGrxv4082093 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Dec 2021 16:53:59 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: arrowd@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 1BDGrwL1062737 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 13 Dec 2021 23:53:58 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: What to use in place of abstract unix sockets? To: Gleb Popov , Alan Somers References: Cc: freebsd-hackers From: Eugene Grosbein Message-ID: <91be3e0c-6c87-ef71-c54d-9049ab1ead84@grosbein.net> Date: Mon, 13 Dec 2021 23:53:51 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4JCSJw0QQYz4WWv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N 13.12.2021 21:24, Gleb Popov wrote: > On Sat, Dec 11, 2021 at 8:02 PM Alan Somers wrote: > >> Since socketpair() doesn't work in this case, why not just use a UDP >> socket bound to 127.0.0.1 ? >> > > This would introduce a bit of overhead as the packet would pass through the > IP stack. Another problem is that the current code uses SOCK_STREAM socket > type, which isn't supported by the UDP protocol. Maybe this would work with > SCTP? > Anyways, I'm going to try this only as a last resort. > > OK, so far my options are: > 1. Mount the directory containing UDS into chroot with nullfs. > 2. Use PF_INET. > 3. Do kernel-hacking and implement abstract sockets (as well as > remount-to-readonly support for nullfs). > > I'd go straight to #3 but with my skills/free time this would take a lot of > time, so I'm going to try hacking it around with #1 and #2. > > Thanks everyone for all the suggestions. Is'nt hacking "the client" to open AF_UNIX socket before chroot() an option? From nobody Tue Dec 14 00:07:09 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2326B18E91AF for ; Tue, 14 Dec 2021 00:07:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4JCdwq0G69z4gPS for ; Tue, 14 Dec 2021 00:07:22 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fc4c12a.dip0.t-ipconnect.de [79.196.193.42]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id 1BE07Fk5035874 for ; Tue, 14 Dec 2021 00:07:15 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 1BE079qt062803 for ; Tue, 14 Dec 2021 01:07:09 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.16.1/8.16.1) with ESMTP id 1BE079G8030464 for ; Tue, 14 Dec 2021 01:07:09 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202112140007.1BE079G8030464@fire.js.berklix.net> To: hackers@freebsd.org Subject: /boot/loader.conf debuging traces come out jumbled From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30462.1639440429.1@fire.js.berklix.net> Date: Tue, 14 Dec 2021 01:07:09 +0100 X-Rspamd-Queue-Id: 4JCdwq0G69z4gPS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-1.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; 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)[berklix.com]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.63)[-0.629]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[79.196.193.42:received] X-ThisMailContainsUnwantedMimeParts: N Debugging my /boot/loader.conf on 12.2-STABLE (with a 12.2-RELEASE kernel, (as 12.2-STABLE & 12.3-RELEASE & 13.0-RELEASE GENERIC kernels crash during boot on one machine here (To be subject of later analysis & posting)... I got distracted onto debugging boot options, after output from booting screen rolled off the top), So I concentrated first on identifying & hashing out noisey boot options , before next searching how to capture boot text (maybe to a serial port ?) ) I tried adding markers to loader.conf create deliberate visible error texts to mark around lines I wanted to study the effect of, eg fuse_load="YES" etc ... I added this in the middle of /boot/loader.conf : ZZZZZZZZZ00000000_load="YES" ZZZZZZZZZ00001111_load="YES" ZZZZZZZZZ00002222_load="YES" ZZZZZZZZZ44440000_load="YES" ZZZZZZZZZ44441111_load="YES" ZZZZZZZZZ44442222_load="YES" & next boot showed a weirdly disordered: Loading configured modules... can't find 'ZZZZZZZZZ00000000_load' can't find 'ZZZZZZZZZ00002222_load' can't find 'ZZZZZZZZZ44442222_load' can't find 'ZZZZZZZZZ44440000_load' can't find 'ZZZZZZZZZ44441111_load' can't find 'ZZZZZZZZZ00001111_load' /etc/hostid size=0x25 its not even just a reverse order that one might have expected from a forth unstacker or some such. Makes it harder to trace what output lines come from which loader.conf lines. -- Julian Stacey http://berklix.com/jhs/ http://stolenvotes.uk Minimise contact, vax insufficient. Prime liar a liability to cons & UK. From nobody Tue Dec 14 00:17:52 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00B2018EB2B3 for ; Tue, 14 Dec 2021 00:18:04 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCf975QlJz4hls for ; Tue, 14 Dec 2021 00:18:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 953542C060 for ; Tue, 14 Dec 2021 00:18:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f182.google.com with SMTP id 193so15452935qkh.10 for ; Mon, 13 Dec 2021 16:18:03 -0800 (PST) X-Gm-Message-State: AOAM533SBUto6VHYUl9qJ+Rm0Jx5rSvL90kfKREPaRCHIlTVA08cNFFf Lw+rgg3rRJ596VdytK+J7uYwxdSkNmP0getQTec= X-Google-Smtp-Source: ABdhPJxolq85SpJJ1MdsFxYybDnRw650vWVn0fRJ6bjKhfd+dKOOzekdDlnKy61ypqlsT2Zf0sjPVZpj4dTbTaPdAdc= X-Received: by 2002:a05:620a:1a92:: with SMTP id bl18mr1435645qkb.488.1639441083160; Mon, 13 Dec 2021 16:18:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202112140007.1BE079G8030464@fire.js.berklix.net> In-Reply-To: <202112140007.1BE079G8030464@fire.js.berklix.net> From: Kyle Evans Date: Mon, 13 Dec 2021 18:17:52 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: /boot/loader.conf debuging traces come out jumbled To: "Julian H. Stacey" Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639441083; h=from:from:reply-to:subject:subject:date:date: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=5O2BMoeEiZNtzKN6c/nwMd+tq720847qKfiPcTl03FI=; b=c8XqDub5s1sjufbBj7zi70efoSZoBYY87EeXQne3wvz30YObHSyKdNAjg/F6E5mulaKiAB ETR4AM4StbP4xbTYr5L3IY7Z5ogUP0CjoG/Sua65x0ZsjKrHmZXS9wU/mKXfgYW1HDd1aG W6byBYFVPVLVuhy4D5IO/qUNrul29ksYtIulEyhblBAsrK8TJwVTIIywgoxSBrCARI7ovE dAIMsZfLq5jsN0jdyDCs6M2vHrcQVsq5SP9JCFhNqaAuYcFMdW5+5CbcbjbRa4re+zh3/M b4DsnJ8VDKYN5HX4WLEOxQBLqwi36k56d3r4Mv8JVk9B4fpHX7YEC2H7AFm9rg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639441083; a=rsa-sha256; cv=none; b=niCw4eMtET68jFWXxgXM1RARK8sE9IH65CRE6yy8GkZY/GIJyGji+rS0siTwwiztRvCNcN UHJu6Z8NL4C1wi6p+tcTDdKs+tgn/VlOVsUkMsVOIvT2oGxTpDM4J+1+9OnXCtCKd7bM77 4QnSbfs4KBzWbK8vNh5qs3ylQ2VfIH3+zzVPdITJWR6WTSQJFqSvnLK+Q7j1zpAQ5vg4V1 r6y+O7hy1Roin3DEBtN3QTej6XE9I+sTo3y9VTxzyAs68yOzGK7tQUNnZEGh1NvDZ0Tyf7 VVOzgC9MuCa8wP4ny+fhZ6H4kpGDvyOLhbon57g/OAu6+qp8fMMvC60ucNMUMA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 13, 2021 at 6:07 PM Julian H. Stacey wrote: > > Debugging my /boot/loader.conf on 12.2-STABLE (with a 12.2-RELEASE kernel, > > (as 12.2-STABLE & 12.3-RELEASE & 13.0-RELEASE GENERIC kernels crash during > boot on one machine here (To be subject of later analysis & > posting)... I got distracted onto debugging boot options, after > output from booting screen rolled off the top), So I concentrated > first on identifying & hashing out noisey boot options , before > next searching how to capture boot text (maybe to a serial port ?) ) > > I tried adding markers to loader.conf create deliberate visible error texts to > mark around lines I wanted to study the effect of, eg > fuse_load="YES" etc ... > > I added this in the middle of /boot/loader.conf : > ZZZZZZZZZ00000000_load="YES" > ZZZZZZZZZ00001111_load="YES" > ZZZZZZZZZ00002222_load="YES" > ZZZZZZZZZ44440000_load="YES" > ZZZZZZZZZ44441111_load="YES" > ZZZZZZZZZ44442222_load="YES" > > & next boot showed a weirdly disordered: > > Loading configured modules... > can't find 'ZZZZZZZZZ00000000_load' > can't find 'ZZZZZZZZZ00002222_load' > can't find 'ZZZZZZZZZ44442222_load' > can't find 'ZZZZZZZZZ44440000_load' > can't find 'ZZZZZZZZZ44441111_load' > can't find 'ZZZZZZZZZ00001111_load' > /etc/hostid size=0x25 > > its not even just a reverse order that one might have expected from > a forth unstacker or some such. Makes it harder to trace what output > lines come from which loader.conf lines. > To my knowledge, we've never guaranteed module load order beyond kernel-first then everything else. You'll have a much better time with _before/_after though; something like this should work: hostid_before="echo before hostid" hostid_after="echo after hostid" From nobody Tue Dec 14 03:06:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC68A18EE9EB for ; Tue, 14 Dec 2021 03:06:53 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCjvw3ZJNz3j40; Tue, 14 Dec 2021 03:06:52 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lj1-x22c.google.com with SMTP id p8so26449546ljo.5; Mon, 13 Dec 2021 19:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=CzzL3QljhounuQzPrOZs8zYHOj1IBBAWh7WM/OIsupU=; b=AgPeLK/BhKkwi+w/NBd/WJnQnDzuEyjiHKu4gvleXMcBI/sukOWrK5urCbIN45EVUP c8+WWDD3aUjDe1vTeE6rAEPjXhgCVF1aTAtlts3Wy3ubeXkSy6Ti54py+8o0hzwZ2U+d P1Ch5gwBsGfLvIiWvrDYH7KXMDfv1f9GcQUzPAlw0LFZ+mLTB6KSR6Yi9VNlbzycwMA0 H6fEntufq0sM63jlW0fjF+0MLQ5CHvg1rXY85VA0ef64WbeD4baThngaz5WfsV0XhbnQ 5Ai3lBYw50apKqHjvp8fgjBVQDYC65PW7Vt2S62+ddcpDm4yALSiUtcjZnhhun7wX6fZ MvTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=CzzL3QljhounuQzPrOZs8zYHOj1IBBAWh7WM/OIsupU=; b=jKwbc+Q88lW3qxuk6gCbByR0LChY4wGEufCj2hSM4BhkICuWrstpJacJWJF55P0IRM JEUhiZJqgWKHXwNitnmozTxwZRleKLOqz+eJDmsTt5TL4h1a0Z2nrAg2Edyk0VhaWeEI 7YMFECCkPQzIiyXvNJlAvuMUFEDIKCB/wVj1dx8nZ2dB8KN1+r4VJCeuBGBq6UxtjaK5 NOxiiqXRVr6O2y9QRJVOZAMbtwaD6Ef/H/SrG3kIpvkHZNFRKxcn5CXkSyuFi06xzEfg eGrosjp79nzhOwjri3JEI6zEDxcq1Tcfti00P1xSqaz/0LTY0pslUtARcjXIuGj+04i0 Ucvg== X-Gm-Message-State: AOAM530stmy6ViNcdSD2lYiEOyIU/TwV/b+Q86JgK/kB9Sv5xuRfZ2tq DAR8bMPuRtrYFid2RKHnGsgAdUPlGld4Q5w6GGbBxqKX X-Google-Smtp-Source: ABdhPJw7QcxTVz6hYkN4xKPeTXI4ucxiUolyEyD5AQgHx1I+LnPxac3lRmp6oHmJqp3156QG1gC8vMT8Z/m0rAR9nlY= X-Received: by 2002:a05:651c:b12:: with SMTP id b18mr2466855ljr.306.1639451211007; Mon, 13 Dec 2021 19:06:51 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Mon, 13 Dec 2021 19:06:50 -0800 (PST) From: Stefan Blachmann Date: Tue, 14 Dec 2021 04:06:50 +0100 Message-ID: Subject: Weak disk I/O performance on daX compared to adaX, was: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Alan Somers Cc: Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JCjvw3ZJNz3j40 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="AgPeLK/B"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::22c as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I am wondering what could be the cause for the weak disk I/O performance on FreeBSD when using daX drivers instead of adaX drivers. Explanation: The HP Z420 has 6 SATA ports. SATA drives that get connected to port #1 to #4 are being shown as daX drives on FreeBSD. Drives connected to ports 5 and 6 appear as adaX drives. > On 12/2/21, Alan Somers wrote: >> That is your problem then. The default value for dd if 512B. If it >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 >> IOPs. Frankly, I'm impressed that the SATA bus could handle that This shows that on the ada driver, the disk I/O performance is acceptable. However, after 14 days dd is still working on the same type drive on connector 4 (da3). So my questions: - Why does FreeBSD use the da driver instead of the ada driver for drives on SATA ports 1-4? - And, why is the da driver so slow? (For example, on HP Z800 when used with FreeBSD, 15k SAS drives seem as slow as normal consumer drives, while on Linux disk I/O is just snappy.) - Is there a way to configure FreeBSD to use the ada driver instead of the da driver, so using FreeBSD is still an alternative to Linux if disk speed matters? - Or is it impossible to use the ada drivers on SATA connectors 1-4 for maybe some HP Z420 hardware related reasons? Cheers, Stefan On 12/2/21, Stefan Blachmann wrote: > Ah, the buffer cache! Didn't think of that. > Top shows the weighted cpu load is about 4%, so your guess that it was > the SATA scheduler might be correct. > Will try this on Linux the next days using conv=direct with a pair of > identical HDDs. > Already curious for the results. > > > > On 12/2/21, Alan Somers wrote: >> That is your problem then. The default value for dd if 512B. If it >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 >> IOPs. Frankly, I'm impressed that the SATA bus could handle that >> many. By using such a small block size, you were doing an excellent >> job of exercising the SATA bus and the HDD's host interface, but its >> servo and write head were mostly just idle. >> >> The reason why Linux is different is because unlike FreeBSD it has a >> buffer cache. Even though dd was writing with 512B blocks, those >> writes probably got combined by the buffer cache before going to SATA. >> However, if you use the conv=direct option with dd, then they probably >> won't be combined. I haven't tested this; it's just a guess. You can >> probably verify using iostat. >> >> When you were trying to erase two HDDs concurrently but only one was >> getting all of the IOPs and CPU time, was your CPU saturated? I'm >> guessing not. On my machine, with a similar HDD, dd only consumes 10% >> of the CPU when I write zeros with a 512B block size. I need to use a >> 16k block size or larger to get the IOPs under 10,000. So I'm >> guessing that in your case the CPU scheduler was working just fine, >> but the SATA bus was saturated, and the SATA scheduler was the source >> of the unfairness. >> -Alan >> >> On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann >> wrote: >>> >>> I intentionally used dd without the bs parameter, as I do care less >>> about "maximum speed" than clearing the drives completely and also do >>> a lot of I/O transactions. >>> The latter because drives that are becoming unreliable tend to >>> occasionally throw errors, and the more I/O transactions one does the >>> better the chance is to spot this kind of drives. >>> >>> The system is a HP Z420, the mainboard/chipset/controller specs can be >>> found in the web. >>> The drives in question here (quite old) 2TB WD Black enterprise grade >>> 3.5" SATA drives. Their SMART data is good, not hinting at any >>> problems. >>> >>> On Linux, erasing them both concurrently finished at almost the same >>> time. >>> Thus I do not really understand why on FreeBSD this is so much >>> different. >>> >>> On 12/2/21, Alan Somers wrote: >>> > This is very surprising to me. I never see dd take significant CPU >>> > consumption until the speed gets up into the GB/s range. What are you >>> > using for the bs= option? If you set that too low, or use the >>> > default, it will needlessly consume extra CPU and IOPs. I usually set >>> > it to 1m for this kind of usage. And what kind of HDDs are these, >>> > connected to what kind of controller? >>> > >>> > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann >>> > wrote: >>> >> >>> >> Regarding the suggestions to either improve or replace the ULE >>> >> scheduler, I would like to share another observation. >>> >> >>> >> Usually when I need to zero out HDDs using dd, I use a live Linux. >>> >> This time I did that on FreeBSD (13). >>> >> My observations: >>> >> - On the same hardware, the data transfer rate is a small fraction >>> >> (about 1/4th) of which is achieved by Linux. >>> >> - The first dd process, which erases the first HDD, gets almost all >>> >> CPU and I/O time. The second process which does the second HDD is >>> >> getting starved. It actually really starts only after the first one >>> >> finished. >>> >> >>> >> To me it was *very* surprising to find out that, while erasing two >>> >> similar HDDs concurrently takes about one day on Linux, on FreeBSD, >>> >> the first HDD was finished after three days, and only after that the >>> >> remaining second dd process got the same CPU time, making it proceed >>> >> fast instead of creepingly slowly. >>> >> >>> >> So I guess this might be a scheduler issue. >>> >> I certainly will do some tests using the old scheduler when I got >>> >> time. >>> >> And, I ask myself: >>> >> Could it be a good idea to sponsor porting the Dragonfly scheduler to >>> >> FreeBSD? >>> >> >>> >> On 12/2/21, Johannes Totz wrote: >>> >> > On 29/11/2021 03:17, Ed Maste wrote: >>> >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >>> >> >> wrote: >>> >> >>> >>> >> >>> It's certainly not the latest and greatest, >>> >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz >>> >> >>> K8-class CPU) >>> >> >> >>> >> >> If you're content to use a compiler from a package you can save a >>> >> >> lot >>> >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >>> >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps >>> >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. >>> >> > >>> >> > (re-send to list, sorry) >>> >> > Can we disconnect the compiler optimisation flag for base and >>> >> > clang? >>> >> > I >>> >> > don't need the compiler to be build with -O2 but I want the >>> >> > resulting >>> >> > base system to have optimisations enabled. >>> >> > Right now, looks like both get -O2 and a lot of time is spent on >>> >> > optimising the compiler (for no good reason). >>> >> > >>> >> > >>> >> >>> > >> > From nobody Tue Dec 14 03:31:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 181CA18F328B for ; Tue, 14 Dec 2021 03:32:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCkT274lKz3lmP for ; Tue, 14 Dec 2021 03:32:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92b.google.com with SMTP id n9so13730927uaq.10 for ; Mon, 13 Dec 2021 19:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MU+K0fCB4ggg1XArDu5UfZX0F5tBnOWV73C7Gxs/XrY=; b=uyVZDA9IkchkB86bfMIKrzZK2zkKV9I9dL64SNt/FCB+2VI9DZZPy+lEZ6e3ex3rVQ Ih921hipihDB6qy+gatR6wKczGNrSXVOmTNCOdpiA58x/3vXjzpwPIDHAJDScGGIqCHk 3UqPIQtUOFojFKVUsqdN1vmWvV45x4PBxs2FVr6sJUyZwUEijJCC4zj63+K9KhDhqjp7 dK3ubiRSr09hzA7lzCJpb0TNuu9PPT4nz/+cJNeFAnkwAAgH8bVzjmCET9yCRJlAG6Nh 5zCv58q7ghTnHqyuUiWHAf40Lyst6wvXTdU20kUzbM30doQt6oxjVKjMlX5gvdPhZFQk YBoQ== 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=MU+K0fCB4ggg1XArDu5UfZX0F5tBnOWV73C7Gxs/XrY=; b=CTzXBI9QR2L7Ti5OSm/0J6hPMMMMXjQchwzCo7Z5wN9pqkEHQIxVKxspIRSEBcI1zq 6Y89AdbJt6A6g6ho1m5KCAEHlo0SkPdhcxI2MUR7qRmo6PnWkf0AswsNU4DVfrQVJked tr9/vlS8GK3W828gw5P/wWuWhivjCToGJnyCXXB9eHkk0I/clDshgvUrG4W47uBqr+KY lxc2pTdE5NUnJYPHN0+kPXsuO8FxUVy6l3Hz5+IX66eODkW5S46v5ha95cuAU9Ge06WF n/qt4ajV735CvwUDRizEvUssUHMmhvCXtSOBl+BnE5ooaLCTVRV8xkexO31+x/DaU5mp wBQQ== X-Gm-Message-State: AOAM530h9XBIsv+nDKZDW78R+rhn4CD1pHckcGEZodi70XRJ07dqa2W0 FhYsNfeF7En4ylVvnNLovC3AAjXbsBHXNNIux/jIyKRINaLSlw== X-Google-Smtp-Source: ABdhPJyT9LaELsaEhDQznt163pmrbk3D/Hq7qzbmOli30tEPfWFaU0ce2bhcI9nLY78/MO60x9e1w9ekSOjV7cyShy4= X-Received: by 2002:a67:f912:: with SMTP id t18mr3388885vsq.6.1639452726329; Mon, 13 Dec 2021 19:32:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 13 Dec 2021 20:31:55 -0700 Message-ID: Subject: Re: Weak disk I/O performance on daX compared to adaX, was: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Stefan Blachmann Cc: Alan Somers , Johannes Totz , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000611a5705d312d5c8" X-Rspamd-Queue-Id: 4JCkT274lKz3lmP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000611a5705d312d5c8 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 13, 2021 at 8:08 PM Stefan Blachmann wrote: > I am wondering what could be the cause for the weak disk I/O > performance on FreeBSD when using daX drivers instead of adaX drivers. > > Explanation: > The HP Z420 has 6 SATA ports. > SATA drives that get connected to port #1 to #4 are being shown as daX > drives on FreeBSD. > Drives connected to ports 5 and 6 appear as adaX drives. > > > On 12/2/21, Alan Somers wrote: > >> That is your problem then. The default value for dd if 512B. If it > >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 > >> IOPs. Frankly, I'm impressed that the SATA bus could handle that > > This shows that on the ada driver, the disk I/O performance is acceptable. > However, after 14 days dd is still working on the same type drive on > connector 4 (da3). > > So my questions: > - Why does FreeBSD use the da driver instead of the ada driver for > drives on SATA ports 1-4? > Because it isn't an ahci controller, but something else. dmesg will tell you, or camcontrol devlist. It might be crappy hardware, poorly configured or maybe you've discovered a driver bug that's easy to fix. > - And, why is the da driver so slow? (For example, on HP Z800 when > used with FreeBSD, 15k SAS drives seem as slow as normal consumer > drives, while on Linux disk I/O is just snappy.) > It isn't. It's more likely the controller they are attached to that's slow. At work we get line rate out of daX and adaX all the time. They are just protocol translators and hands it off to the host adapter (what's called the SIM). > - Is there a way to configure FreeBSD to use the ada driver instead of > the da driver, so using FreeBSD is still an alternative to Linux if > disk speed matters? > Unlikely. > - Or is it impossible to use the ada drivers on SATA connectors 1-4 > for maybe some HP Z420 hardware related reasons? > What does camcontrol devlist tell you? Chances are it's the SIM that's to blame for the poor performance (we run all kinds of crazy I/O through ada and da and if anything da is a smidge faster). The key question is why things are so seemingly slow. Warner > Cheers, > Stefan > > > On 12/2/21, Stefan Blachmann wrote: > > Ah, the buffer cache! Didn't think of that. > > Top shows the weighted cpu load is about 4%, so your guess that it was > > the SATA scheduler might be correct. > > Will try this on Linux the next days using conv=direct with a pair of > > identical HDDs. > > Already curious for the results. > > > > > > > > On 12/2/21, Alan Somers wrote: > >> That is your problem then. The default value for dd if 512B. If it > >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 > >> IOPs. Frankly, I'm impressed that the SATA bus could handle that > >> many. By using such a small block size, you were doing an excellent > >> job of exercising the SATA bus and the HDD's host interface, but its > >> servo and write head were mostly just idle. > >> > >> The reason why Linux is different is because unlike FreeBSD it has a > >> buffer cache. Even though dd was writing with 512B blocks, those > >> writes probably got combined by the buffer cache before going to SATA. > >> However, if you use the conv=direct option with dd, then they probably > >> won't be combined. I haven't tested this; it's just a guess. You can > >> probably verify using iostat. > >> > >> When you were trying to erase two HDDs concurrently but only one was > >> getting all of the IOPs and CPU time, was your CPU saturated? I'm > >> guessing not. On my machine, with a similar HDD, dd only consumes 10% > >> of the CPU when I write zeros with a 512B block size. I need to use a > >> 16k block size or larger to get the IOPs under 10,000. So I'm > >> guessing that in your case the CPU scheduler was working just fine, > >> but the SATA bus was saturated, and the SATA scheduler was the source > >> of the unfairness. > >> -Alan > >> > >> On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann > >> wrote: > >>> > >>> I intentionally used dd without the bs parameter, as I do care less > >>> about "maximum speed" than clearing the drives completely and also do > >>> a lot of I/O transactions. > >>> The latter because drives that are becoming unreliable tend to > >>> occasionally throw errors, and the more I/O transactions one does the > >>> better the chance is to spot this kind of drives. > >>> > >>> The system is a HP Z420, the mainboard/chipset/controller specs can be > >>> found in the web. > >>> The drives in question here (quite old) 2TB WD Black enterprise grade > >>> 3.5" SATA drives. Their SMART data is good, not hinting at any > >>> problems. > >>> > >>> On Linux, erasing them both concurrently finished at almost the same > >>> time. > >>> Thus I do not really understand why on FreeBSD this is so much > >>> different. > >>> > >>> On 12/2/21, Alan Somers wrote: > >>> > This is very surprising to me. I never see dd take significant CPU > >>> > consumption until the speed gets up into the GB/s range. What are > you > >>> > using for the bs= option? If you set that too low, or use the > >>> > default, it will needlessly consume extra CPU and IOPs. I usually > set > >>> > it to 1m for this kind of usage. And what kind of HDDs are these, > >>> > connected to what kind of controller? > >>> > > >>> > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann < > sblachmann@gmail.com> > >>> > wrote: > >>> >> > >>> >> Regarding the suggestions to either improve or replace the ULE > >>> >> scheduler, I would like to share another observation. > >>> >> > >>> >> Usually when I need to zero out HDDs using dd, I use a live Linux. > >>> >> This time I did that on FreeBSD (13). > >>> >> My observations: > >>> >> - On the same hardware, the data transfer rate is a small fraction > >>> >> (about 1/4th) of which is achieved by Linux. > >>> >> - The first dd process, which erases the first HDD, gets almost all > >>> >> CPU and I/O time. The second process which does the second HDD is > >>> >> getting starved. It actually really starts only after the first one > >>> >> finished. > >>> >> > >>> >> To me it was *very* surprising to find out that, while erasing two > >>> >> similar HDDs concurrently takes about one day on Linux, on FreeBSD, > >>> >> the first HDD was finished after three days, and only after that the > >>> >> remaining second dd process got the same CPU time, making it proceed > >>> >> fast instead of creepingly slowly. > >>> >> > >>> >> So I guess this might be a scheduler issue. > >>> >> I certainly will do some tests using the old scheduler when I got > >>> >> time. > >>> >> And, I ask myself: > >>> >> Could it be a good idea to sponsor porting the Dragonfly scheduler > to > >>> >> FreeBSD? > >>> >> > >>> >> On 12/2/21, Johannes Totz wrote: > >>> >> > On 29/11/2021 03:17, Ed Maste wrote: > >>> >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> It's certainly not the latest and greatest, > >>> >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz > (1995.04-MHz > >>> >> >>> K8-class CPU) > >>> >> >> > >>> >> >> If you're content to use a compiler from a package you can save a > >>> >> >> lot > >>> >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and > >>> >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN perhaps > >>> >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > >>> >> > > >>> >> > (re-send to list, sorry) > >>> >> > Can we disconnect the compiler optimisation flag for base and > >>> >> > clang? > >>> >> > I > >>> >> > don't need the compiler to be build with -O2 but I want the > >>> >> > resulting > >>> >> > base system to have optimisations enabled. > >>> >> > Right now, looks like both get -O2 and a lot of time is spent on > >>> >> > optimising the compiler (for no good reason). > >>> >> > > >>> >> > > >>> >> > >>> > > >> > > > > --000000000000611a5705d312d5c8-- From nobody Tue Dec 14 04:42:08 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 700FB18D6BEB for ; Tue, 14 Dec 2021 04:42:11 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCm1v2VKLz3smM; Tue, 14 Dec 2021 04:42:11 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x131.google.com with SMTP id m27so34683753lfj.12; Mon, 13 Dec 2021 20:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=chMqm45m6qJ7f24JuuQYh39wn6STlWndviL1XADDdzE=; b=DltKYxDB5RGQkCxKo8oo3aWxspJte2/ihmwY+kgzwIp28Hc4oJ9iNdh5A7w1z0uJ7t BCOiaqhTfU9Ii86CSstcMQ8Ls6PsCMYbNCxi95CGcRYHxDlDyGs/EZokx4KcExYgBBMp 7JY6rklzzWkjuWHvoRy1ud2cu9W4VMgB2378KJ2r3u8VCX8nt8ErTpZZMlJeO3k9e08i AXrIODivJbLa5AzwSlNkFIJ0I4ACKV651WVz6mMGOeggdVhHYtbvmENIiLtEMAe7+UHU 8xmLKpVXAhzx+SlkjXv/ZA0TJyOapGckkaGidRW6Ov/oN1RnNfGojEDmO1dfFudonf96 5ESg== 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=chMqm45m6qJ7f24JuuQYh39wn6STlWndviL1XADDdzE=; b=fbUSbD+tlnmUmOT+YYTZW4j48b5j1WFGmWGG7rUymdisV3HyO9UTk4ZkEI6BKHFKot ymwnWpVukwrkFuzQYFce2iLYl3s7wgLkDByMUzBW//GRtITKyyh+a5wDcyx0L8vG7NWq 9nrBpadjrCc6q3Vlm9x7MTfMuLcrgxsYSt578RLUbZsVSv+ps/BJH7ig3kLWm0lLHPDc Nz2zFPGtfYcGKXN5kPnQvlQ0EcMp26pbH4a0w/rt8z30bh7CV9zF0Ibuc/QzrKIu12LW DMO0UoS6qUCBgi/40q2h77LnXFrSYd42FIjrLajBp6RAe2LCkhLnsG7hnSTo3TUFtEyW 00MQ== X-Gm-Message-State: AOAM532VDOK1QD8Cz1mgwKGh0D5YXXH3S7VX6gkLWzazWJwg1VFgO0IH Z0GuCcC5a/V7haEsHvNF3ZpDZ4sp7KJqvnlp2Zc= X-Google-Smtp-Source: ABdhPJyJmeh5tp//+sTVQSFC7JvqaKVWKzwycvo9rhf+cDFcQL8PCiYBAWfGJ7Fi4KeDkVoPntk3X7F6Entep6LrJB8= X-Received: by 2002:a05:6512:3718:: with SMTP id z24mr2654753lfr.563.1639456929006; Mon, 13 Dec 2021 20:42:09 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:651c:1242:0:0:0:0 with HTTP; Mon, 13 Dec 2021 20:42:08 -0800 (PST) In-Reply-To: References: From: Stefan Blachmann Date: Tue, 14 Dec 2021 05:42:08 +0100 Message-ID: Subject: Re: Weak disk I/O performance on daX compared to adaX, was: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Warner Losh Cc: Alan Somers , Johannes Totz , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JCm1v2VKLz3smM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Warner, thank you for the reply! > Because it isn't an ahci controller, but something else. dmesg will tell > you, or camcontrol devlist. It might be crappy hardware, poorly configured > or maybe you've discovered a driver bug that's easy to fix. There is a RAID BIOS on the HP Z420 that apparently cannot be deactivated. According to what the RAID BIOS screen displays, there is no RAID configured, and the drives connected to the system seem to be "passed through" to the OS. The camcontrol devlist output (see the two WD 2003FYYS): at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3,da3) at scbus1 target 0 lun 0 (cd0,pass4) at scbus2 target 0 lun 0 (pass5,ada0) at scbus3 target 0 lun 0 (pass6,ses0) at scbus4 target 0 lun 0 (da4,pass7) The dmesg (not obviously disk-related stuff snipped) tells about a SATA controller and a SAS controller in SATA mode: isci0: port 0xd000-0xd 0ff mem 0xe2800000-0xe2803fff,0xe2400000-0xe27fffff irq 16 at device 0.0 on pci4 ahci0: port 0xe0d0-0xe0d7,0xe0c0-0xe0c3,0x e0b0-0xe0b7,0xe0a0-0xe0a3,0xe020-0xe03f mem 0xef72c000-0xef72c7ff irq 19 at devi ce 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahciem0: on ahci0 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich1 bus 0 scbus2 target 0 lun 0 ada0: ATA8-ACS SATA 2.x device ada0: Serial Number WD-WMAY04325670 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors) ses0: (none) in 'Slot 00', SATA Slot: scbus1 target 0 ses0: ada0 in 'Slot 01', SATA Slot: scbus2 target 0 da0 at isci0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-3 SCSI device da0: Serial Number 14260C786E76 da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 244198MB (500118192 512 byte sectors) da1 at isci0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SPC-3 SCSI device da1: Serial Number Z7747X6AS da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 2861588MB (5860533168 512 byte sectors) da2 at isci0 bus 0 scbus0 target 2 lun 0 da2: Fixed Direct Access SPC-3 SCSI device da2: Serial Number Z7747SSAS da2: 300.000MB/s transfers da2: Command Queueing enabled da2: 2861588MB (5860533168 512 byte sectors) cd0 at ahcich0 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c losed da3 at isci0 bus 0 scbus0 target 3 lun 0 da3: Fixed Direct Access SPC-3 SCSI device da3: Serial Number WD-WMAY04325722 da3: 300.000MB/s transfers da3: Command Queueing enabled da3: 1907729MB (3907029168 512 byte sectors) GEOM_ELI: Device da0p2.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: accelerated software System is only running dd, except for a few sc consoles idling at command prompt nothing else. top -m io varies 99.8 to 100% for dd top without options dd shows a time of >800:x for dd and a WCPU varying between 3.5-4.2%. For the drive on ada0 dd total time was ~150:x with a WCPU of ~1%. On 12/14/21, Warner Losh wrote: > On Mon, Dec 13, 2021 at 8:08 PM Stefan Blachmann > wrote: > >> I am wondering what could be the cause for the weak disk I/O >> performance on FreeBSD when using daX drivers instead of adaX drivers. >> >> Explanation: >> The HP Z420 has 6 SATA ports. >> SATA drives that get connected to port #1 to #4 are being shown as daX >> drives on FreeBSD. >> Drives connected to ports 5 and 6 appear as adaX drives. >> >> > On 12/2/21, Alan Somers wrote: >> >> That is your problem then. The default value for dd if 512B. If it >> >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 >> >> IOPs. Frankly, I'm impressed that the SATA bus could handle that >> >> This shows that on the ada driver, the disk I/O performance is >> acceptable. >> However, after 14 days dd is still working on the same type drive on >> connector 4 (da3). >> >> So my questions: >> - Why does FreeBSD use the da driver instead of the ada driver for >> drives on SATA ports 1-4? >> > > Because it isn't an ahci controller, but something else. dmesg will tell > you, or camcontrol devlist. It might be crappy hardware, poorly configured > or maybe you've discovered a driver bug that's easy to fix. > > >> - And, why is the da driver so slow? (For example, on HP Z800 when >> used with FreeBSD, 15k SAS drives seem as slow as normal consumer >> drives, while on Linux disk I/O is just snappy.) >> > > It isn't. It's more likely the controller they are attached to that's slow. > At work > we get line rate out of daX and adaX all the time. They are just protocol > translators and hands it off to the host adapter (what's called the SIM). > > >> - Is there a way to configure FreeBSD to use the ada driver instead of >> the da driver, so using FreeBSD is still an alternative to Linux if >> disk speed matters? >> > > Unlikely. > > >> - Or is it impossible to use the ada drivers on SATA connectors 1-4 >> for maybe some HP Z420 hardware related reasons? >> > > What does camcontrol devlist tell you? Chances are it's the SIM that's to > blame for the poor performance (we run all kinds of crazy I/O through ada > and da and if anything da is a smidge faster). The key question is why > things are so seemingly slow. > > Warner > > >> Cheers, >> Stefan >> >> >> On 12/2/21, Stefan Blachmann wrote: >> > Ah, the buffer cache! Didn't think of that. >> > Top shows the weighted cpu load is about 4%, so your guess that it was >> > the SATA scheduler might be correct. >> > Will try this on Linux the next days using conv=direct with a pair of >> > identical HDDs. >> > Already curious for the results. >> > >> > >> > >> > On 12/2/21, Alan Somers wrote: >> >> That is your problem then. The default value for dd if 512B. If it >> >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 >> >> IOPs. Frankly, I'm impressed that the SATA bus could handle that >> >> many. By using such a small block size, you were doing an excellent >> >> job of exercising the SATA bus and the HDD's host interface, but its >> >> servo and write head were mostly just idle. >> >> >> >> The reason why Linux is different is because unlike FreeBSD it has a >> >> buffer cache. Even though dd was writing with 512B blocks, those >> >> writes probably got combined by the buffer cache before going to SATA. >> >> However, if you use the conv=direct option with dd, then they probably >> >> won't be combined. I haven't tested this; it's just a guess. You can >> >> probably verify using iostat. >> >> >> >> When you were trying to erase two HDDs concurrently but only one was >> >> getting all of the IOPs and CPU time, was your CPU saturated? I'm >> >> guessing not. On my machine, with a similar HDD, dd only consumes 10% >> >> of the CPU when I write zeros with a 512B block size. I need to use a >> >> 16k block size or larger to get the IOPs under 10,000. So I'm >> >> guessing that in your case the CPU scheduler was working just fine, >> >> but the SATA bus was saturated, and the SATA scheduler was the source >> >> of the unfairness. >> >> -Alan >> >> >> >> On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann >> >> >> >> wrote: >> >>> >> >>> I intentionally used dd without the bs parameter, as I do care less >> >>> about "maximum speed" than clearing the drives completely and also do >> >>> a lot of I/O transactions. >> >>> The latter because drives that are becoming unreliable tend to >> >>> occasionally throw errors, and the more I/O transactions one does the >> >>> better the chance is to spot this kind of drives. >> >>> >> >>> The system is a HP Z420, the mainboard/chipset/controller specs can >> >>> be >> >>> found in the web. >> >>> The drives in question here (quite old) 2TB WD Black enterprise grade >> >>> 3.5" SATA drives. Their SMART data is good, not hinting at any >> >>> problems. >> >>> >> >>> On Linux, erasing them both concurrently finished at almost the same >> >>> time. >> >>> Thus I do not really understand why on FreeBSD this is so much >> >>> different. >> >>> >> >>> On 12/2/21, Alan Somers wrote: >> >>> > This is very surprising to me. I never see dd take significant CPU >> >>> > consumption until the speed gets up into the GB/s range. What are >> you >> >>> > using for the bs= option? If you set that too low, or use the >> >>> > default, it will needlessly consume extra CPU and IOPs. I usually >> set >> >>> > it to 1m for this kind of usage. And what kind of HDDs are these, >> >>> > connected to what kind of controller? >> >>> > >> >>> > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann < >> sblachmann@gmail.com> >> >>> > wrote: >> >>> >> >> >>> >> Regarding the suggestions to either improve or replace the ULE >> >>> >> scheduler, I would like to share another observation. >> >>> >> >> >>> >> Usually when I need to zero out HDDs using dd, I use a live Linux. >> >>> >> This time I did that on FreeBSD (13). >> >>> >> My observations: >> >>> >> - On the same hardware, the data transfer rate is a small fraction >> >>> >> (about 1/4th) of which is achieved by Linux. >> >>> >> - The first dd process, which erases the first HDD, gets almost >> >>> >> all >> >>> >> CPU and I/O time. The second process which does the second HDD is >> >>> >> getting starved. It actually really starts only after the first >> >>> >> one >> >>> >> finished. >> >>> >> >> >>> >> To me it was *very* surprising to find out that, while erasing two >> >>> >> similar HDDs concurrently takes about one day on Linux, on >> >>> >> FreeBSD, >> >>> >> the first HDD was finished after three days, and only after that >> >>> >> the >> >>> >> remaining second dd process got the same CPU time, making it >> >>> >> proceed >> >>> >> fast instead of creepingly slowly. >> >>> >> >> >>> >> So I guess this might be a scheduler issue. >> >>> >> I certainly will do some tests using the old scheduler when I got >> >>> >> time. >> >>> >> And, I ask myself: >> >>> >> Could it be a good idea to sponsor porting the Dragonfly scheduler >> to >> >>> >> FreeBSD? >> >>> >> >> >>> >> On 12/2/21, Johannes Totz wrote: >> >>> >> > On 29/11/2021 03:17, Ed Maste wrote: >> >>> >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl >> >>> >> >> wrote: >> >>> >> >>> >> >>> >> >>> It's certainly not the latest and greatest, >> >>> >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz >> (1995.04-MHz >> >>> >> >>> K8-class CPU) >> >>> >> >> >> >>> >> >> If you're content to use a compiler from a package you can save >> >>> >> >> a >> >>> >> >> lot >> >>> >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and >> >>> >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN >> >>> >> >> perhaps >> >>> >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. >> >>> >> > >> >>> >> > (re-send to list, sorry) >> >>> >> > Can we disconnect the compiler optimisation flag for base and >> >>> >> > clang? >> >>> >> > I >> >>> >> > don't need the compiler to be build with -O2 but I want the >> >>> >> > resulting >> >>> >> > base system to have optimisations enabled. >> >>> >> > Right now, looks like both get -O2 and a lot of time is spent on >> >>> >> > optimising the compiler (for no good reason). >> >>> >> > >> >>> >> > >> >>> >> >> >>> > >> >> >> > >> >> > From nobody Tue Dec 14 05:36:12 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F2E818E2BBC for ; Tue, 14 Dec 2021 05:45:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCnQg2Tydz4VJL for ; Tue, 14 Dec 2021 05:45:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id y12so58416476eda.12 for ; Mon, 13 Dec 2021 21:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GCFZx+L0X6kks+WdhABQLC/pDpWCXJy5IGkTjMg1MsY=; b=p+++a92oBGSKlVdJnxVg/pVePq9PPq2XdBC0ord9otI0/xVR/7Czla/RFdxnRlaoeo srz1Nq5UboDpkTEzSSoLMyfKKT6K+uk0IvwR9PM/4Fmn2Ob8CEK9rB3Ynxi3oc/dfbRa iKAj2pa//EMQRZXs6EucRD+whv8KNqCoCCHo4kUbAv+b8V1gcqQyC8PskxGxUudhQXtP wTd5rtM59OZNvMO4SR8CVeFRb1HNyzB1Xf85k8+GtbIK41FQod5XES9F6uFJTdtTh34p V7JNnlvOjYwvvz2Anq2eCvLz2EoL3wXLLGCMrysYFDOa5kMc6dq/GXe2ntdB5Bzlfm63 Lt2Q== 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=GCFZx+L0X6kks+WdhABQLC/pDpWCXJy5IGkTjMg1MsY=; b=Csc0EsLe0M5O9InHPWg2shrgKSjSvt+dLNLTHbWuPmBf8w/kSGON6UGXYU5D/jJrsQ +l1Eq4P92sGJWTYcIDoyagAULhVodw2N56p3nUpuFcH0gsPcJKGlSmiekrMgZ31+sAwF 8ZHL3VhK7oaeEdICufsVLmknlUI+Vv9fTycE3C8E/asdC2Z88XnheEhRyXSGXEUcEzPx WWVbDFsQe/ZzuaJHo/Nm2KNX4DtVT1KetPFVRkIenCt7U+Fg7V++AnUbUG/BxE3OXnjv pwNhVidN/Xsc9uVcpFHA/vi1RVVEWuuqNopK7qLMmDZo7OxiKa/Cqq+RUoqKn7HIALjR 4oRw== X-Gm-Message-State: AOAM533GJHW0Tp5YKC8WzOtvep2aaxl+H2j7GyuCldQI91NEBmuMTmJi w1ppDa+0Kl8IZWgGwrOfp+DoSfuUZ1SInRSpuxMHcQTdmLnOgA== X-Google-Smtp-Source: ABdhPJwBe2//33LClmiwVMFZPwGjzkGXaYvHS0F8qpAB+OKSDU9kgazEEh66vFUPFecgmT95LpnCFw6MnuykizrmgMI= X-Received: by 2002:a5d:6dab:: with SMTP id u11mr3367812wrs.46.1639460208187; Mon, 13 Dec 2021 21:36:48 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202112140007.1BE079G8030464@fire.js.berklix.net> In-Reply-To: <202112140007.1BE079G8030464@fire.js.berklix.net> From: Mehmet Erol Sanliturk Date: Tue, 14 Dec 2021 08:36:12 +0300 Message-ID: Subject: Re: /boot/loader.conf debuging traces come out jumbled To: "Julian H. Stacey" Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000551d2005d3149341" X-Rspamd-Queue-Id: 4JCnQg2Tydz4VJL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000551d2005d3149341 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 14, 2021 at 3:08 AM Julian H. Stacey wrote: > Debugging my /boot/loader.conf on 12.2-STABLE (with a 12.2-RELEASE kernel, > > (as 12.2-STABLE & 12.3-RELEASE & 13.0-RELEASE GENERIC kernels crash > during > boot on one machine here (To be subject of later analysis & > posting)... I got distracted onto debugging boot options, after > output from booting screen rolled off the top), So I concentrated > first on identifying & hashing out noisey boot options , before > next searching how to capture boot text (maybe to a serial port ?) ) > > I tried adding markers to loader.conf create deliberate visible error > texts to > mark around lines I wanted to study the effect of, eg > fuse_load="YES" etc ... > > I added this in the middle of /boot/loader.conf : > ZZZZZZZZZ00000000_load="YES" > ZZZZZZZZZ00001111_load="YES" > ZZZZZZZZZ00002222_load="YES" > ZZZZZZZZZ44440000_load="YES" > ZZZZZZZZZ44441111_load="YES" > ZZZZZZZZZ44442222_load="YES" > > & next boot showed a weirdly disordered: > > Loading configured modules... > can't find 'ZZZZZZZZZ00000000_load' > can't find 'ZZZZZZZZZ00002222_load' > can't find 'ZZZZZZZZZ44442222_load' > can't find 'ZZZZZZZZZ44440000_load' > can't find 'ZZZZZZZZZ44441111_load' > can't find 'ZZZZZZZZZ00001111_load' > /etc/hostid size=0x25 > > its not even just a reverse order that one might have expected from > a forth unstacker or some such. Makes it harder to trace what output > lines come from which loader.conf lines. > > -- > Julian Stacey http://berklix.com/jhs/ http://stolenvotes.uk > Minimise contact, vax insufficient. Prime liar a liability to cons & > UK. > The above message has triggered remembering one of experiences with FreeBSD before 9.2(?) : I am testing a C program with "clang" : print ( ... 'A : ' ... ) a ; print ( ... 'B : ' ... ) b ; print ( ... 'C : ' ... ) c ; Output ( like similar to the following but disordered with respect to its liking ) : B : ... A : ... C : ... means "Unbelievable" ... Mehmet Erol Sanliturk --000000000000551d2005d3149341-- From nobody Tue Dec 14 05:58:35 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C92518E5CD2 for ; Tue, 14 Dec 2021 05:58:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCnkH1BbGz4Y9g for ; Tue, 14 Dec 2021 05:58:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa34.google.com with SMTP id h1so11868967vkh.0 for ; Mon, 13 Dec 2021 21:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=90MqaEUVsiG0llvFYd8yBXTi5BSr3QXz/R62omYzg14=; b=6dLQdb7InHLTMhTE97AsmipoMEuQshcCASDGAVEn2uxqgvtHVTFUmAvvBOv1HQmoJp jHHXERVOI8lDXYHSAv6ricgr2tCC4xWBUx7WLfsZxYsixF1Wh2QsE74ZQbSyTXEhcFur vm3Jz9JxXhYT5k9qzbSIN5GyUkmyqTGIhPlFmrB/XzP1jXvk0kaZzt1T7rw3TdiYSeah XF7W75wbMWhVj7Bz0MGmKu3oqzigsR+9kfYmH+w55/5JRT4jFQ6Yo2QhWuVltxmdTlkj azMTH9hbATjp/sBLSPowFAyndIXq3w1sCdR5SaKimRj9TecnZWGq1PU8+Q3dv/W5CO5H lbog== 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=90MqaEUVsiG0llvFYd8yBXTi5BSr3QXz/R62omYzg14=; b=uTsKwFHy3gRDf/n6+InzJnZrxSU3eYC4N8+yjeXRDzzPfRNYfG58quEIrkn+iypxgV 0sFZy0eHpn4qy17du/hxTzFUM+PO1gaqyGxJXBb/uLErqB/O6AlLZLHEfRy+0HEOdczh EXQlBUcbqF5YS+4qCDiNxGMH9OViMsSZfNE+PlzDWW+h5mUPANRGtRhXXZAZ29a2eF7e Qe12L8AbjG9qgMM85CsSY4naaObNg0QjL+opjiom5i9mCnnAN9xru7nJ4B3dpFBeITsM gQr3kSoS1xlL5O8BYVpxgr8SMvsyWzYv3IGoq0QTdi++FBLbTdS+ezz6NxV0S5DkFV29 DzYw== X-Gm-Message-State: AOAM530zXDCqW7gbQQBkaFODGgdiG+sX5A3djZ7V+pObN5q8ctYge8jW RaLS8wMTKloupZv/u4yeoadWeOmH/yjXK4fz0Ki3TL1yfSRSLA== X-Google-Smtp-Source: ABdhPJyzPSr2yYrpvhlmv8Y5/uvUws8CINg+XIBvmaH5OZkiKHVA95A1I0swipJyrc7TJTnwjvVawhRfwY/Zc2fcHc0= X-Received: by 2002:a05:6122:988:: with SMTP id g8mr4327226vkd.2.1639461526409; Mon, 13 Dec 2021 21:58:46 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 13 Dec 2021 22:58:35 -0700 Message-ID: Subject: Re: Weak disk I/O performance on daX compared to adaX, was: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] To: Stefan Blachmann Cc: Alan Somers , Johannes Totz , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e7abd205d314e168" X-Rspamd-Queue-Id: 4JCnkH1BbGz4Y9g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000e7abd205d314e168 Content-Type: text/plain; charset="UTF-8" Oh. isci. This silicon has known limitations. First, the reported speed is 3Gbps, which is 1/2 the speed of most SATA drives. This is a big problem for SSDs. Second, there's a limit for all the channels that's less than 4*3Gbps. However, this limit isn't documented: you have to measure it. Third, there may be a bug in isci that's likely causing excess CPU. I've had issues in the past with this driver. I don't use it much any more since the machines that had it in it have aged out. And I've never done much work with the isci driver, so I'm not sure how much more help I can be.... Finally, If you have a free PCIe slot, you might be happier with an old LSI mps or mrsas card. The card will be about $30-40 and another $15-20 for the cable. I know this is an unsatisfying answer... Warner On Mon, Dec 13, 2021 at 9:42 PM Stefan Blachmann wrote: > Hi Warner, thank you for the reply! > > > Because it isn't an ahci controller, but something else. dmesg will tell > > you, or camcontrol devlist. It might be crappy hardware, poorly > configured > > or maybe you've discovered a driver bug that's easy to fix. > > There is a RAID BIOS on the HP Z420 that apparently cannot be deactivated. > According to what the RAID BIOS screen displays, there is no RAID > configured, and the drives connected to the system seem to be "passed > through" to the OS. > > The camcontrol devlist output (see the two WD 2003FYYS): > > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 2 lun 0 (pass2,da2) > at scbus0 target 3 lun 0 (pass3,da3) > at scbus1 target 0 lun 0 (cd0,pass4) > at scbus2 target 0 lun 0 (pass5,ada0) > at scbus3 target 0 lun 0 (pass6,ses0) > at scbus4 target 0 lun 0 (da4,pass7) > > The dmesg (not obviously disk-related stuff snipped) tells about a > SATA controller and a SAS controller in SATA mode: > > > isci0: port > 0xd000-0xd > 0ff mem 0xe2800000-0xe2803fff,0xe2400000-0xe27fffff irq 16 at device 0.0 > on pci4 > > ahci0: port > 0xe0d0-0xe0d7,0xe0c0-0xe0c3,0x > e0b0-0xe0b7,0xe0a0-0xe0a3,0xe020-0xe03f mem 0xef72c000-0xef72c7ff irq 19 > at devi > ce 31.2 on pci0 > ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahciem0: on ahci0 > > ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 > ses0: SEMB S-E-S 2.00 device > ses0: SEMB SES Device > ada0 at ahcich1 bus 0 scbus2 target 0 lun 0 > ada0: ATA8-ACS SATA 2.x device > ada0: Serial Number WD-WMAY04325670 > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 1907729MB (3907029168 512 byte sectors) > ses0: (none) in 'Slot 00', SATA Slot: scbus1 target 0 > ses0: ada0 in 'Slot 01', SATA Slot: scbus2 target 0 > da0 at isci0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SPC-3 SCSI device > da0: Serial Number 14260C786E76 > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 244198MB (500118192 512 byte sectors) > da1 at isci0 bus 0 scbus0 target 1 lun 0 > da1: Fixed Direct Access SPC-3 SCSI device > da1: Serial Number Z7747X6AS > da1: 300.000MB/s transfers > da1: Command Queueing enabled > da1: 2861588MB (5860533168 512 byte sectors) > da2 at isci0 bus 0 scbus0 target 2 lun 0 > da2: Fixed Direct Access SPC-3 SCSI device > da2: Serial Number Z7747SSAS > da2: 300.000MB/s transfers > da2: Command Queueing enabled > da2: 2861588MB (5860533168 512 byte sectors) > cd0 at ahcich0 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI device > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not present - > tray c > losed > da3 at isci0 bus 0 scbus0 target 3 lun 0 > da3: Fixed Direct Access SPC-3 SCSI device > da3: Serial Number WD-WMAY04325722 > da3: 300.000MB/s transfers > da3: Command Queueing enabled > da3: 1907729MB (3907029168 512 byte sectors) > > GEOM_ELI: Device da0p2.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Crypto: accelerated software > > > System is only running dd, except for a few sc consoles idling at > command prompt nothing else. > > top -m io varies 99.8 to 100% for dd > top without options dd shows a time of >800:x for dd and a WCPU > varying between 3.5-4.2%. > For the drive on ada0 dd total time was ~150:x with a WCPU of ~1%. > > > > > > On 12/14/21, Warner Losh wrote: > > On Mon, Dec 13, 2021 at 8:08 PM Stefan Blachmann > > wrote: > > > >> I am wondering what could be the cause for the weak disk I/O > >> performance on FreeBSD when using daX drivers instead of adaX drivers. > >> > >> Explanation: > >> The HP Z420 has 6 SATA ports. > >> SATA drives that get connected to port #1 to #4 are being shown as daX > >> drives on FreeBSD. > >> Drives connected to ports 5 and 6 appear as adaX drives. > >> > >> > On 12/2/21, Alan Somers wrote: > >> >> That is your problem then. The default value for dd if 512B. If it > >> >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 > >> >> IOPs. Frankly, I'm impressed that the SATA bus could handle that > >> > >> This shows that on the ada driver, the disk I/O performance is > >> acceptable. > >> However, after 14 days dd is still working on the same type drive on > >> connector 4 (da3). > >> > >> So my questions: > >> - Why does FreeBSD use the da driver instead of the ada driver for > >> drives on SATA ports 1-4? > >> > > > > Because it isn't an ahci controller, but something else. dmesg will tell > > you, or camcontrol devlist. It might be crappy hardware, poorly > configured > > or maybe you've discovered a driver bug that's easy to fix. > > > > > >> - And, why is the da driver so slow? (For example, on HP Z800 when > >> used with FreeBSD, 15k SAS drives seem as slow as normal consumer > >> drives, while on Linux disk I/O is just snappy.) > >> > > > > It isn't. It's more likely the controller they are attached to that's > slow. > > At work > > we get line rate out of daX and adaX all the time. They are just protocol > > translators and hands it off to the host adapter (what's called the SIM). > > > > > >> - Is there a way to configure FreeBSD to use the ada driver instead of > >> the da driver, so using FreeBSD is still an alternative to Linux if > >> disk speed matters? > >> > > > > Unlikely. > > > > > >> - Or is it impossible to use the ada drivers on SATA connectors 1-4 > >> for maybe some HP Z420 hardware related reasons? > >> > > > > What does camcontrol devlist tell you? Chances are it's the SIM that's to > > blame for the poor performance (we run all kinds of crazy I/O through ada > > and da and if anything da is a smidge faster). The key question is why > > things are so seemingly slow. > > > > Warner > > > > > >> Cheers, > >> Stefan > >> > >> > >> On 12/2/21, Stefan Blachmann wrote: > >> > Ah, the buffer cache! Didn't think of that. > >> > Top shows the weighted cpu load is about 4%, so your guess that it was > >> > the SATA scheduler might be correct. > >> > Will try this on Linux the next days using conv=direct with a pair of > >> > identical HDDs. > >> > Already curious for the results. > >> > > >> > > >> > > >> > On 12/2/21, Alan Somers wrote: > >> >> That is your problem then. The default value for dd if 512B. If it > >> >> took 3 days to erase a 2 TB HDD, that means you were writing 15,000 > >> >> IOPs. Frankly, I'm impressed that the SATA bus could handle that > >> >> many. By using such a small block size, you were doing an excellent > >> >> job of exercising the SATA bus and the HDD's host interface, but its > >> >> servo and write head were mostly just idle. > >> >> > >> >> The reason why Linux is different is because unlike FreeBSD it has a > >> >> buffer cache. Even though dd was writing with 512B blocks, those > >> >> writes probably got combined by the buffer cache before going to > SATA. > >> >> However, if you use the conv=direct option with dd, then they > probably > >> >> won't be combined. I haven't tested this; it's just a guess. You > can > >> >> probably verify using iostat. > >> >> > >> >> When you were trying to erase two HDDs concurrently but only one was > >> >> getting all of the IOPs and CPU time, was your CPU saturated? I'm > >> >> guessing not. On my machine, with a similar HDD, dd only consumes > 10% > >> >> of the CPU when I write zeros with a 512B block size. I need to use > a > >> >> 16k block size or larger to get the IOPs under 10,000. So I'm > >> >> guessing that in your case the CPU scheduler was working just fine, > >> >> but the SATA bus was saturated, and the SATA scheduler was the source > >> >> of the unfairness. > >> >> -Alan > >> >> > >> >> On Thu, Dec 2, 2021 at 10:37 AM Stefan Blachmann > >> >> > >> >> wrote: > >> >>> > >> >>> I intentionally used dd without the bs parameter, as I do care less > >> >>> about "maximum speed" than clearing the drives completely and also > do > >> >>> a lot of I/O transactions. > >> >>> The latter because drives that are becoming unreliable tend to > >> >>> occasionally throw errors, and the more I/O transactions one does > the > >> >>> better the chance is to spot this kind of drives. > >> >>> > >> >>> The system is a HP Z420, the mainboard/chipset/controller specs can > >> >>> be > >> >>> found in the web. > >> >>> The drives in question here (quite old) 2TB WD Black enterprise > grade > >> >>> 3.5" SATA drives. Their SMART data is good, not hinting at any > >> >>> problems. > >> >>> > >> >>> On Linux, erasing them both concurrently finished at almost the same > >> >>> time. > >> >>> Thus I do not really understand why on FreeBSD this is so much > >> >>> different. > >> >>> > >> >>> On 12/2/21, Alan Somers wrote: > >> >>> > This is very surprising to me. I never see dd take significant > CPU > >> >>> > consumption until the speed gets up into the GB/s range. What are > >> you > >> >>> > using for the bs= option? If you set that too low, or use the > >> >>> > default, it will needlessly consume extra CPU and IOPs. I usually > >> set > >> >>> > it to 1m for this kind of usage. And what kind of HDDs are these, > >> >>> > connected to what kind of controller? > >> >>> > > >> >>> > On Thu, Dec 2, 2021 at 9:54 AM Stefan Blachmann < > >> sblachmann@gmail.com> > >> >>> > wrote: > >> >>> >> > >> >>> >> Regarding the suggestions to either improve or replace the ULE > >> >>> >> scheduler, I would like to share another observation. > >> >>> >> > >> >>> >> Usually when I need to zero out HDDs using dd, I use a live > Linux. > >> >>> >> This time I did that on FreeBSD (13). > >> >>> >> My observations: > >> >>> >> - On the same hardware, the data transfer rate is a small > fraction > >> >>> >> (about 1/4th) of which is achieved by Linux. > >> >>> >> - The first dd process, which erases the first HDD, gets almost > >> >>> >> all > >> >>> >> CPU and I/O time. The second process which does the second HDD is > >> >>> >> getting starved. It actually really starts only after the first > >> >>> >> one > >> >>> >> finished. > >> >>> >> > >> >>> >> To me it was *very* surprising to find out that, while erasing > two > >> >>> >> similar HDDs concurrently takes about one day on Linux, on > >> >>> >> FreeBSD, > >> >>> >> the first HDD was finished after three days, and only after that > >> >>> >> the > >> >>> >> remaining second dd process got the same CPU time, making it > >> >>> >> proceed > >> >>> >> fast instead of creepingly slowly. > >> >>> >> > >> >>> >> So I guess this might be a scheduler issue. > >> >>> >> I certainly will do some tests using the old scheduler when I got > >> >>> >> time. > >> >>> >> And, I ask myself: > >> >>> >> Could it be a good idea to sponsor porting the Dragonfly > scheduler > >> to > >> >>> >> FreeBSD? > >> >>> >> > >> >>> >> On 12/2/21, Johannes Totz wrote: > >> >>> >> > On 29/11/2021 03:17, Ed Maste wrote: > >> >>> >> >> On Sun, 28 Nov 2021 at 19:37, Steve Kargl > >> >>> >> >> wrote: > >> >>> >> >>> > >> >>> >> >>> It's certainly not the latest and greatest, > >> >>> >> >>> CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz > >> (1995.04-MHz > >> >>> >> >>> K8-class CPU) > >> >>> >> >> > >> >>> >> >> If you're content to use a compiler from a package you can > save > >> >>> >> >> a > >> >>> >> >> lot > >> >>> >> >> of time by building with `CROSS_TOOLCHAIN=llvm13` and > >> >>> >> >> `WITHOUT_TOOLCHAIN=yes`. Or, instead of WITHOUT_TOOLCHAIN > >> >>> >> >> perhaps > >> >>> >> >> `WITHOUT_CLANG=yes`, `WITHOUT_LLD=yes` and `WITHOUT_LLDB=yes`. > >> >>> >> > > >> >>> >> > (re-send to list, sorry) > >> >>> >> > Can we disconnect the compiler optimisation flag for base and > >> >>> >> > clang? > >> >>> >> > I > >> >>> >> > don't need the compiler to be build with -O2 but I want the > >> >>> >> > resulting > >> >>> >> > base system to have optimisations enabled. > >> >>> >> > Right now, looks like both get -O2 and a lot of time is spent > on > >> >>> >> > optimising the compiler (for no good reason). > >> >>> >> > > >> >>> >> > > >> >>> >> > >> >>> > > >> >> > >> > > >> > >> > > > --000000000000e7abd205d314e168-- From nobody Tue Dec 14 05:57:12 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B395718E833A for ; Tue, 14 Dec 2021 06:09:07 +0000 (UTC) (envelope-from elrond@phoe.frmug.org) Received: from frmug.org (enterprise.frmug.org [IPv6:2a01:e0d:1:3:58bf:fa61:0: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 4JCnyC49SJz4Zl3 for ; Tue, 14 Dec 2021 06:09:07 +0000 (UTC) (envelope-from elrond@phoe.frmug.org) Received: by frmug.org (Postfix, from userid 66) id 705CE12B641; Tue, 14 Dec 2021 07:09:06 +0100 (CET) Received: by memo2.memo.frmug.org (Postfix, from userid 1001) id 1F48517A7C; Tue, 14 Dec 2021 07:05:46 +0100 (CET) Resent-From: Bertrand Petit Resent-Date: Tue, 14 Dec 2021 07:05:45 +0100 Resent-Message-ID: <20211214060545.GA30665@memo2.memo.frmug.org> Resent-To: freebsd-hackers@freebsd.org Date: Tue, 14 Dec 2021 06:57:12 +0100 From: Bertrand Petit To: Stefan Blachmann Cc: Alan Somers , Johannes Totz , FreeBSD Hackers Subject: Re: Weak disk I/O performance on daX compared to adaX, was: Re: dd performance [was Re: Call for Foundation-supported Project Ideas] Message-ID: <20211214055711.GT33211@memo2.memo.frmug.org> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 4JCnyC49SJz4Zl3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 04:06:50AM +0100, Stefan Blachmann wrote: > > So my questions: > - Why does FreeBSD use the da driver instead of the ada driver for > drives on SATA ports 1-4? A look at the Z240 block diagram in the maintenance and service guide (document number 669531-005) reveals the presence of two different HBAs. First there is one raid controller (Intel or LSI depending on the bought options) and, secondly, a plain AHCI adapter. One can only boot from the first controller. It is usual for HP/HPe machines to provide a firmware setting permitting the disablement of the raid controller. When used, this setting morphs the controller to a plain AHCI HBA. Doing this on my Proliants did improve I/O performances up to the satisfying point of the disks themselves becoming the bottleneck. I recommend using the AHCI mode, especially if you are storing zpools. You should also be aware that not all SATA ports are made equal on this motherboard. In the manual some are marked as 6 Gb/s while other are 3 Gb/s. (SATA 3 vs. SATA 2?) Some ports can also be configured for eSATA operation, this should be checked. -- %!PS -- Bertrand Petit /D{def}def/E{exch}D/G{get}D/I{2 div}D/U{dup}D/L{roll}D/Y{setgray}D/N{newpath}D /O{N 0 0 moveto}D/P{pop}D/T{translate}D currentpagedevice/PageSize G U 0 G/w E D 1 G /h E D w I h I T 0 Y 1 setlinewidth 0 1 2 { P 120 rotate 2 4 w U mul h U mul add sqrt I 50 add {N 50 0 3 2 L 0 360 arc stroke}for}for/s{O true charpath pathbbox exch 4 -1 L E sub I 3 1 L sub I} D /l(bp)D 0.94 Y /Helvetica findfont 22 scalefont setfont l s P(x)s exch P T O l show showpage From nobody Tue Dec 14 11:15:06 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2476618E1AD0 for ; Tue, 14 Dec 2021 11:15:17 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JCwlR73DMz3kYy for ; Tue, 14 Dec 2021 11:15:15 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Tue, 14 Dec 2021 12:15:07 +0100 id 00DADC7E.61B87CBB.0000603A Date: Tue, 14 Dec 2021 12:15:06 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Two devices created for one block in device tree? Message-ID: <20211214121506.34c7f96b@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git299 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JCwlR73DMz3kYy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-0.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[1.50.218.176:email,0.0.0.0:email,0.0.0.1:email,1.50.226.128:email]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.988]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi, is it possible to attach two different devices for one device description in device tree, with some order being guaranted, maybe one device in a pass? To be clear, I am trying to solve problem with PHY being attached to MAC being initialized later. I have a board with two MACs and two PHYs. There is a data connection from MAC to PHY - SGMII, one to one, and there is another connection, MDIO, with a bus controller via second MAC. In a device tree, it looks like this: ethernet@20110000 { status = "okay"; phy-handle = <0x00000010>; }; ethernet@20112000 { status = "okay"; phy-handle = <0x00000011>; ethernet-phy@0 { phandle = <0x00000010>; }; ethernet-phy@1 { phandle = <0x00000011>; }; }; (only some properties written here, just to illustrate the case) So it is basically the same as Routerstation or Routerstation Pro using if_arge interface. I understand the concept of mdio/miiproxy used here, but those boards' configs uses hints, different mechanism, not FDT/DTS. However, the problem is the same - on first pass through device tree, MDIO device is being created and initialized, then PHYs attached are being probed, attached and initialized, and then, in second pass, ethernet inteface is being created, initialized and configured to use PHY already found as prescribed. I searched in recent source tree for inspiration, but there are only three devices with something similar - if_arge.c in sys/mips/atheros, if_are.c in sys/mips/atheros/ar531x, and if_rt.c in sys/dev/rt. The last one, if_rt.c, uses two compatible strings to differentiate MAC and MDIO controllers, maybe they are implemented independently, I don't know, I did not found DTS using it. The rest uses hints, as already mentioned. For now, I see no working method for this scenario. The device in my case is Cadence GEM, MII readreg/writereg function are already there. All I need is just create a proxy for first ethernet, which should use those function accessing MDIO controller for second ethernet. In single pass scenario, this could not work because MDIO controller is not yet working when first ethernet is being initialized. Trying to use multi pass scenario, if I attach MDIO controller on first pass, MAC controller is not attached on second pass, because there is already driver attached. Could anybody provide any hint to me? It could be something obvious I just don't see, also one more complication is the code should be compiled conditionally, maybe using 'options CGEM_MDIO' in config file (just as if_arge and if_are do), because there are other boards with no need for mdio/miiproxy, I'd prefer to use simpler code for this case. Regards, Milan From nobody Tue Dec 14 15:28:36 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7973718D401B for ; Tue, 14 Dec 2021 15:28:49 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD2N04F3wz3HZM for ; Tue, 14 Dec 2021 15:28:48 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [217.246.54.215] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mx9jT-0003Sq-KB for freebsd-hackers@freebsd.org; Tue, 14 Dec 2021 16:28:47 +0100 Date: Tue, 14 Dec 2021 16:28:36 +0100 From: Fabian Keil To: freebsd-hackers@freebsd.org Subject: High mbuf count leading to processes getting killed for "lack of swap space" Message-ID: <20211214162836.3d3b9b87@fabiankeil.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/vN9fdp0HlM4NS1AijD3T1st"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4JD2N04F3wz3HZM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.13) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[80.67.18.13:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.13:from]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[217.246.54.215:received] X-ThisMailContainsUnwantedMimeParts: N --Sig_/vN9fdp0HlM4NS1AijD3T1st Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A while ago one of my physical systems running ElectroBSD based on FreeBSD stable/11 became occasionally unresponsive to network input and had to be power-cycled to get into a usable state again. It's conceivable that console access still would have worked but I didn't have console access for the system (and still don't). The problem was always preceded by "[zone: mbuf_cluster] kern.ipc.nmbclusters limit reached" messages and only occurred when the system was busy reproducing ElectroBSD or building ports with poudriere while additionally running the normal work load which includes serving web pages with nginx and relaying tor traffic. Some additional log messages and munin graphs from March are available at: As a first step to diagnose the problem I added munin plugins for the mbuf state but unfortunately munin needs the network to work and thus is unreliable when mbufs are scarce ... While I'm generally not a big fan of cargo-cult administration I later on set kern.ipc.nmbclusters=3D1000000 while the auto-tuned value was "only" 247178 which is more than enough for the normal operation. This prevented the system which is now running ElectroBSD amd64 based on FreeBSD 12/stable from completely becoming unresponsive under load but unfortunately it also results in important processes getting killed with messages like: 2021-12-14T06:24:40.267263+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 63731 (tor), jid 33, uid 256, was killed: out of swap space = =20 2021-12-14T06:24:41.000777+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 91800 (tor), jid 37, uid 256, was killed: out of swap space = =20 2021-12-14T06:24:41.000862+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 81324 (c++), jid 56, uid 1001, was killed: out of swap space = =20 2021-12-14T06:24:41.000903+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 17233 to 200 packets/sec = =20 2021-12-14T06:24:41.000917+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 19764 (c++), jid 56, uid 1001, was killed: out of swap space = =20 2021-12-14T06:24:41.000954+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 1635 to 200 packets/sec = =20 2021-12-14T06:24:41.000967+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 1192 to 200 packets/sec = =20 2021-12-14T06:24:41.000980+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 974 (xz), jid 0, uid 0, was killed: out of swap space = =20 2021-12-14T06:24:41.001016+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 441 to 200 packets/sec = =20 2021-12-14T06:24:41.001029+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 10872 (perl), jid 0, uid 842, was killed: out of swap space = =20 2021-12-14T06:24:41.001065+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 1052 to 200 packets/sec = =20 2021-12-14T06:24:41.001078+01:00 elektrobier.fabiankeil.de kernel <3>1 - - = - pid 62569 (tor), jid 35, uid 256, was killed: out of swap space = =20 2021-12-14T06:24:41.001114+01:00 elektrobier.fabiankeil.de kernel <5>1 - - = - Limiting closed port RST response from 269 to 200 packets/sec = =20 My impression is that the system isn't actually out of swap space. The system has 4 GB of RAM and I temporarily increased the swap space from 8 GB to 16 GB which didn't make a difference. As far as munin is concerned the swap space isn't full in the time when munin is working: As munin isn't reliable under load, I additionally let the system dump sysctls periodically and it looks like mbuf usage goes up to over 800000: [fk@elektrobier /var/log/sysctl-dumps]$ grep "mbufs in use" sysctl-dump-202= 1-12-14_0[56]\:* [...] sysctl-dump-2021-12-14_06:11:53.txt:829476/729/830205 mbufs in use (current= /cache/total)=20 sysctl-dump-2021-12-14_06:12:57.txt:831954/831/832785 mbufs in use (current= /cache/total)=20 sysctl-dump-2021-12-14_06:14:02.txt:834506/4/834510 mbufs in use (current/c= ache/total) =20 sysctl-dump-2021-12-14_06:15:11.txt:837446/814/838260 mbufs in use (current= /cache/total) =20 sysctl-dump-2021-12-14_06:16:19.txt:840177/948/841125 mbufs in use (current= /cache/total) =20 sysctl-dump-2021-12-14_06:17:26.txt:842652/603/843255 mbufs in use (current= /cache/total) =20 sysctl-dump-2021-12-14_06:22:31.txt:657/1293/1950 mbufs in use (current/cac= he/total) =20 sysctl-dump-2021-12-14_06:25:40.txt:528/1422/1950 mbufs in use (current/cac= he/total) =20 sysctl-dump-2021-12-14_06:26:40.txt:518/1432/1950 mbufs in use (current/cac= he/total) =20 sysctl-dump-2021-12-14_06:27:40.txt:517/1433/1950 mbufs in use (current/cac= he/total) =20 The sysctls were supposed to be dumped once per minute but apparently the system can't be trusted to do this under pressure either ... It's interesting to me that in the case above the mbuf usage went up but the mbuf cluster usage didn't go up as well. In the past both went up together (as shown in the munin graphs for the week). I'm wondering if killing processes is the best way to deal with the problem. I would prefer it, if the kernel would simply stop allocating new mbufs and mbuf clusters before memory becomes too scarce for the system to function. I'm aware that this would affect applications as well and would probably result in dropped connections, but my expectation would be that it would be less annoying than the whole system becoming unresponsive or important application getting killed and becoming unavailable until I can restart them. Has anyone already looked into this? Is there maybe a reason why stopping to allocate more mbufs and mbuf clusters than the system can handle isn't expected to work for reasons that aren't obvious to me? Fabian --Sig_/vN9fdp0HlM4NS1AijD3T1st Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYbi4JQAKCRAFiohV/3dU ne8AAKDBqUxeqWgNygfcaO/QmWCC7D+bGwCdEqEXp1+KDG3hk5pGdlhPUF+GgjE= =wkEh -----END PGP SIGNATURE----- --Sig_/vN9fdp0HlM4NS1AijD3T1st-- From nobody Tue Dec 14 18:26:13 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CB6C318D5C45; Tue, 14 Dec 2021 18:26:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD6Jm3vvVz4dMt; Tue, 14 Dec 2021 18:26:16 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id E05DF528E; Tue, 14 Dec 2021 18:26:15 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211213022223.GA41440@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 18:26:13 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Message-Id: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639506376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZJpJSHPkrIi/bzjmiXVfk0CQDpi0DTk3/PtMptbcZxk=; b=OsR/C39SEKiTPaqLy+UnSGs1P/rKfQZq6qHABJW0n74orTV/YZpJySrH4Tz4LZQ7//rXYf IxAIybsIQbAAV6H/Y1GjaSiL2ObqwSR8bfAk+AWbm3rJuLv6RJCawDF5++uJnlb8Q4dCva o6BtJz6wHtxkaydnUjT/xQW1aTdjGpCT+DHjugZccSDCb2uByJ9ZbQnOEeUp2VwujhXaQl 7mm/VKbJVRdUp08MEKsck24OWqd11oNVY5e1PkepFxbFK3jOkFD4swkZb8DQny8Z7hZPS9 JU2zyTAvNPxkUug+XUWoEmAZaXP4p/jXoYl5vaIwJmlhD5uWiZFltAse6+TkTQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639506376; a=rsa-sha256; cv=none; b=Hd1GOj+qzjbOnRt1zHPxR6pwKVt158ZZBUJQ3F09SZY1w7ioowHATPteBQPjVHooAAICXM tbsSJKeh44BVr45JmuRwdo5P78VLCgHjYHnQN7q+r9dwc2mKy71IvvOFYwK80JYL+Z+j9w HcJ3LgQbfw2PxXdZtCVSpm/LR1BgnZAsJAV0LrnxUqf+zSEadldH6UYKPJdJKXRzq8qPk/ c9ap0gLriD4t8Wk6Q//vFjnXMfQiEdJZiDO+MYp5mxQLK2YKgrPHNitF9arAE/w6ubnheM oKpHl2qR+JjF4DWHpFiwnVFi/BW+U4Ia5pyie4zqQCeMGYP1XJ6Z5GF2t/zMOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E" --Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Dec 2021, at 02:22, Steve Kargl = wrote: >=20 > On Sat, Dec 04, 2021 at 11:48:13PM +0000, Mark Murray wrote: >>=20 >>=20 >>> On 4 Dec 2021, at 18:53, Steve Kargl = wrote: >>>=20 >>>=20 >>> So, is anyone interested in seeing a massive patch? >>=20 >> Me, please! >>=20 >=20 > So, I have the ld80 case working. I'll open a PR if > on does not exist. The pr will contain This is now visible for review at https://reviews.freebsd.org/D33444 Thanks! M -- Mark R V Murray --Apple-Mail=_7DF879A0-F428-4C26-BF70-B4BA90ABBD6E-- --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG44cUACgkQQlsJDh9C UqD1sQf9FgYaKDAcglmiZRzEfpKQ+nWzxG9SChr7V8o2lykhdu7j19XyTR6B8vt/ wFcZZt2AcmaryjNijeDDLlBX5NfLG0EmdkaL4k92+QqBI15MY2PdIH0dw5zVJ/NG 8k42f4P199vo33tquvq9wy4QyPnxwN0xjGvzgLZJZC8Zf9F/92rEaKjepvl2S0Hk DOBUHLYerxfmvUOqdSaotlPEPINdkBLw62tiAUX7UJ5j9l+HVFUWTLKl4EPzaj7b HyKCnflw1aanjnyeHBVgw77izyPwXycn4+kXuIAsyUXnOFvt1YvWqanWmpFQiEmD wu5Z+QXuR/3seIlVhl6KolQnaiiiuQ== =XXUp -----END PGP SIGNATURE----- --Apple-Mail=_8B49C783-B298-40B7-95EB-EFD0CBF8D0D3-- From nobody Tue Dec 14 20:07:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A04A518EE851; Tue, 14 Dec 2021 20:07:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD8Yn342vz3DwT; Tue, 14 Dec 2021 20:07:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BEK7emU049984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 12:07:40 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BEK7eCJ049983; Tue, 14 Dec 2021 12:07:40 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 12:07:40 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214200740.GB49922@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JD8Yn342vz3DwT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Thanks! I looks okay to me (but, of course, I wrote the patch ;-) BTW, I'll probably take a shot at ld128 tgammal(x) this weekend as I still have my account on your aarch64 system for testing. -- Steve From nobody Tue Dec 14 20:41:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F6E618D72F5; Tue, 14 Dec 2021 20:41:34 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JD9Js6yRZz3Lhl; Tue, 14 Dec 2021 20:41:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BEKfW49050142 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 12:41:32 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BEKfWXm050141; Tue, 14 Dec 2021 12:41:32 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 12:41:32 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214204132.GA50132@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JD9Js6yRZz3Lhl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > Just looked at this again. I cannot tell from the diff whether you've 'git mv' src/imprecise.c to ld128/b_tgammal.c. This is need to still get the mapping of tgammal -> tgamma. -- Steve From nobody Tue Dec 14 21:51:06 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 053DC18E9BB1; Tue, 14 Dec 2021 21:51:09 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDBs847rqz3s5w; Tue, 14 Dec 2021 21:51:08 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BELp6iq050409 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 13:51:06 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BELp69M050408; Tue, 14 Dec 2021 13:51:06 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 13:51:06 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211214215106.GA50381@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> X-Rspamd-Queue-Id: 4JDBs847rqz3s5w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: > > This is now visible for review at > https://reviews.freebsd.org/D33444 > I see imp lamented that that fact that he is not sufficiently versed in the numerical methods used (neither am I!). bde use to be my go-to reviewer, but he's no longer with us. To allay fears, I've tested 5 million values distributed in the intervals of the various approximations. Here's the result Interval max ULP x at Max ULP [6,1755.1] 0.873414 at 1.480588145237629047468e+03 [1.0662,6] 0.861508 at 1.999467927053585410537e+00 [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or 1.01e-20. -- Steve From nobody Tue Dec 14 22:20:58 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1717118F1E60; Tue, 14 Dec 2021 22:21:01 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDCWc6T2Hz4WXb; Tue, 14 Dec 2021 22:21:00 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 476F56561; Tue, 14 Dec 2021 22:21:00 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211214204132.GA50132@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 22:20:58 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214204132.GA50132@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639520460; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FcQIZpp5Ddv5iJPgA4aqyaO6rJlojnO+LH+H3WhJzGU=; b=wShUTfPPyECILqY6oJu0gadB6ZWruTmAVrOiK09sYQTm0CnOxG9ZVU1X0YAIqlKBSNhPOI f49UTw61zp/JIX6lYpWEbuVilLqT3nWDjw7syP+lKR4SXy36jknvXzKmtLDZfZK2B+0ZZM vLIqguXJZUuzfSdCMF2NopyjtC6WJc/VzanYP1pEZfrTm14D1CiqzvcR+9ixaSEE12gJac NbqxkHMI18I0LMg5CN2A0EgDTOV7uvaItShaw9rnGI3NI9McI0Mw6pd0ApyGm7DQG0M421 Vgc2K/U98twuqAteQqpgS8jnQVG9bhW7y7i1osz5DaNF2kNsZOnIlwe1QJCSsA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639520460; a=rsa-sha256; cv=none; b=l6OfhfO1Jqdc3Nwf2cg1hOKVWlbGt9ct44x0KiV7To1MQR9l/WPaBsII2cFfNoKlKBqyHD itbSGa+B1I5WBNOKdk9pNcnSQaaYJfr9GJfiU4AWIorO5uoop2QZ63ufABnjMN3WasKe0/ KRyIlo5VrlDIWtzjXHQymIX0AZQzrvZ5tUJ2t1Y4Q5qqvDIlHNQBAbO3Ei+UPe9LsX5xL2 eZiMPRRZa1Nrk5Xuadm9qS0701VMdNnzCDG/+UnBZj2WUtN/nV3B/32SWNk8cR105dxHvV gU98OJ5k961Fz2q64a/9hhlwdDiFmZ9grSRrbFzwU/KwMq/TQrz3J6CtDO4/Ag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 14 Dec 2021, at 20:41, Steve Kargl = wrote: >=20 > On Tue, Dec 14, 2021 at 06:26:13PM +0000, Mark Murray wrote: >>=20 >> This is now visible for review at >> https://reviews.freebsd.org/D33444 = >>=20 >=20 > Just looked at this again. I cannot tell from the > diff whether you've 'git mv' src/imprecise.c to > ld128/b_tgammal.c. This is need to still get the > mapping of tgammal -> tgamma. Fixed, thanks! Thats what I get from checking only on an ld80 machine! M -- Mark R V Murray --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG5GMoACgkQQlsJDh9C UqBQFQf+JYuW46dzet7+VlsSzBkBR+THl+2mHKiZ4WTFjQ73tl5aWCMX/lf6gXxS Jc8gl9SwV1UAP+PxrPkPOd2vnqx/7ZJP74/KKMedbRmGe/msyjMAXU2c1WbboM9f JI3SPiC+Gw6M9RF6+yXv2OjYxeNdFDqNKkE/4ATbPu8CsiAh4Dg0t1ZDMMGkq2/R F5n5bDOZ+3py9uygp8eKC1G/X34Vdc9Wg5wVYeR/V29tTQBKg9mNI+P7QTJxVesM TfNyIACoySxJ60WOKpri77qMkfi74eytr/d1fZA2i438gt8bWT2+KHaitDUAVD+W 647cc2JR3kmGvPwRg/SHXBU9nOdL6g== =gI/g -----END PGP SIGNATURE----- --Apple-Mail=_05A1EFD2-5DBC-4A0E-8510-39E1615D462B-- From nobody Tue Dec 14 22:21:55 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8F5F918F2678; Tue, 14 Dec 2021 22:21:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDCXh2RsYz4X90; Tue, 14 Dec 2021 22:21:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:7dfe:d4bd:52c0:bafb]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 783145FD6; Tue, 14 Dec 2021 22:21:55 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211214215106.GA50381@troutmask.apl.washington.edu> Date: Tue, 14 Dec 2021 22:21:55 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639520516; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Oeh+rWYxRSnAVL01tiMUmYsav5/TCgFWljJZk9MeA4=; b=M6UwZme6z2uQ38lDSnJkPkMz0w6HTEmAghtsisbWGEpse32auM/gELPQsELdrXpbo4zxJk 5ts/Yqf6ONzfDZgDxpmwZ6F4197pnn2syRajBK+eLj2SS4mVoc9NPSxLVsMVcumRaQKlmv Ni2YfoIobLS/fNNjq59FyajtU28stkHZAX8V+sWk8k1AZd/c26w7fu7gZ8CwjPKh6qYLx5 8g8ldsWxs9dMzKNSerG3lUqfDNznNtefx5jdL1eDWmB7oRCRaJFihX3XQmQW4vLafVtTqk y5GlYxvYNL3ZqzZ0wfjfGoK1RUvMVV7sRYOGjfnonz+tQNyVGeGk+t7O5W/CIQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639520516; a=rsa-sha256; cv=none; b=AAbbb0CgPwB+nsmi+OqcMKamDCf+IX5O9X/7555ZUg+T0SCQVzs64EfkU0c9JwIqPBIEJC bZq3L1ijrzUJS4r+X4OPcLsTMVIXSM6VlszCZaJss/bTapMiQ9SdaqYELf6OX4WYrIooOU B9fPM+GyB1onpmbzgh8LWiTmtL5r60R0bBK7Q3MBoFYL2kTlUZZAstQqplja5n9lqXFoL5 NGyWASLBOXBxLE8k+hOAOY8RKf7s1OSFELNq7mSZVjjkxCUQjlRg8ALEWlYAwtDH3NWanv bnmPsjMn/k1GYd50LRLmghxxYi0ycynkQrhJ7r61Cy3gMEKf5ifhmbxlXWl/TA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Dec 2021, at 21:51, Steve Kargl = wrote: > Interval max ULP x at Max ULP > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 >=20 > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or Extra diffs most welcome! M -- Mark R V Murray --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG5GQMACgkQQlsJDh9C UqBoBAf+NsbD7j2sJiYzE0Y+SWknyDuVSKV8LoNb0TT4DzFcSNtaGbEhnMzcnOCf vd/OYnwr+EaII3Hv/W8VwGKcQK6tvUrjSPh4fxiGWJcZFv2MyETRel776NUdFUqF nEcAn/dXDIjQIlTtwALbyIMmY22ThF/IhmHNrutI9PLWfQf6HB98hZ5dOa2V7sQX OEJTSjrPA20gZM+/0hxzjbvXSWxL/jJtIRXseIb3L1WqkMFbuf3u0jLVsMvS2gER xzADf9ArAVdNF0KaideNP1ysb8KShLts6wvHGaboCbd7mQ6E/BxHfBRw8p9bOPyv 1Yoe5ez4fioJHe69Ihm8Vxgi/iEUyg== =t+Ia -----END PGP SIGNATURE----- --Apple-Mail=_7789ED85-99E3-47A4-AD1C-A919E6E23F8D-- From nobody Tue Dec 14 22:47:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9851B18D3631 for ; Tue, 14 Dec 2021 22:47:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDD683hBXz4jnH for ; Tue, 14 Dec 2021 22:47:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2e.google.com with SMTP id m19so13445223vko.12 for ; Tue, 14 Dec 2021 14:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5+JwcqFe5Y2gLCcWupXXwrdKoIxzVAyW60rDxPMYyzg=; b=aRs2CkykXaio/4tcRr8Apqx68tQb23navWsj3vmJ6RqlhwEKZ+9gn2LFmHiioPhre4 6OcNpbC3EGnp3r7bNqYnNy4AIT0tHl8V070FVVkZzgxH8R1XKcwfaHq80a0mEenrQIU5 NMo233nUe6X5XxuyiPjba9WK/Wk80hjkjy0y7Xu4uFRU/HuRVxI4qAkr5gNCcmkIJRgi lsT097HiGnijWbRI9l7Tby0wau/L8Er4DNTob+T7+pAthvxOQdQ2RdgCZbeOpPio96P9 dwgeNwrOXXieMSqjIIY74SRP6yLylTbdVuRH0NKpEs+qcv4TMIFaKDWr88Ag2tCDsJ7f tNLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5+JwcqFe5Y2gLCcWupXXwrdKoIxzVAyW60rDxPMYyzg=; b=idyyH6gkcXDCiMeKNpB1y9G+I4bQzraDsQrunKOVfP4SfZ++OqkUU0DxNSYA0TDmhj GwAA6flS/NbS0b9ecPJMDdsLVynYUcxsSFUijsFb8jav5OcTHbzMVmCbPqsDZxQrjlVl qsIvxTXHoWq/5jNYP+OTm7avJAxT04YV1PJEloqpUIiSztioIzSPIZhs6htpG/lQZDHJ q32XR5gUgEiwaQ+mYhf3Nsbrsm6GUUBaSyMuO4vq0uoA80508prMe/MlgEl4P1oLWBxi 531fU1BJVm+sOU2oe4PekSk6c/kI/opvuINgr0GX+wWGunXhyOQz8uiKBGBqiUVgd5/j 8QIA== X-Gm-Message-State: AOAM5308EV7yLVzEhFmwse8MXZDU0oH7LQ/KoyUIzdCLLOGg6mYp6Zw8 raO2QTB+365hPfmCiFTz02curPRgJbovOLAA6pZgiQ== X-Google-Smtp-Source: ABdhPJyz/m+YQMvxQO1J+P6J9FXlcxFdaeFCsri5qp76Hj01rOovls6TkWruKz/Kw32B/rdOwG2DuRs1PHGvOaA7r4M= X-Received: by 2002:a1f:c193:: with SMTP id r141mr2052619vkf.27.1639522047610; Tue, 14 Dec 2021 14:47:27 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> In-Reply-To: From: Warner Losh Date: Tue, 14 Dec 2021 15:47:17 -0700 Message-ID: Subject: Re: What to do about tgammal? To: Mark Murray Cc: Steve Kargl , FreeBSD Hackers , FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000003fe9cd05d322f945" X-Rspamd-Queue-Id: 4JDD683hBXz4jnH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000003fe9cd05d322f945 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl > wrote: > > Interval max ULP x at Max ULP > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > Extra diffs most welcome! > Those results have allayed my fears. Is 1e-17 sufficient to commit these changes, or do we need to work to get it down to 1e-19 for it to be acceptable? Warner --0000000000003fe9cd05d322f945-- From nobody Tue Dec 14 23:14:22 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4FE5718D9BC6; Tue, 14 Dec 2021 23:14:25 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JDDjF0n6Wz4p6B; Tue, 14 Dec 2021 23:14:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BENEMOB051104 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 14 Dec 2021 15:14:23 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BENEMow051103; Tue, 14 Dec 2021 15:14:22 -0800 (PST) (envelope-from sgk) Date: Tue, 14 Dec 2021 15:14:22 -0800 From: Steve Kargl To: Warner Losh Cc: Mark Murray , FreeBSD Hackers , FreeBSD Current Subject: Re: What to do about tgammal? Message-ID: <20211214231422.GA51064@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JDDjF0n6Wz4p6B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 03:47:17PM -0700, Warner Losh wrote: > On Tue, Dec 14, 2021 at 3:23 PM Mark Murray wrote: > > > On 14 Dec 2021, at 21:51, Steve Kargl > > wrote: > > > Interval max ULP x at Max ULP > > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > > > Extra diffs most welcome! > > > > Those results have allayed my fears. Is 1e-17 sufficient to commit these > changes, or do > we need to work to get it down to 1e-19 for it to be acceptable? > Well, egg-on-the-face. I updated the sloppy limit to isolate x = 0 from 0x1p-56 to use 0x1p-116 and forgot to update my test scripts. The code in tgammal in the interval [-iota:iota] is if (x > iota) RETURNI(smaller_gam(x)); if (x > -iota) { if (x != 0) u.a = 1 - tiny; /* raise inexact */ RETURNI(1 / x); } so tgammal(x) -> 1/x as x -> 0. -- Steve From nobody Fri Dec 17 14:46:23 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DDC0D18E9236; Fri, 17 Dec 2021 14:45:06 +0000 (UTC) (envelope-from bdysonsmith@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JFsGB27f7z3kqm; Fri, 17 Dec 2021 14:45:06 +0000 (UTC) (envelope-from bdysonsmith@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id p65so3282962iof.3; Fri, 17 Dec 2021 06:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=aqr8x3OZKsuOwfGkEqMQhvKmDuinisg62uUSg+Y8wDA=; b=dij77ZyCpVbFqim93VV3dv+vPn1s2zAFN9NbF0nrwdkXGEiDkwtSlTWWYC0QC3Ym3l mgOeQIuoF6OwLmhTN8viWcvTRZvl+7GwC0Hi2hBshqwsjKWXQBPadq/xXOWpxmkqiuHM 1J+96YRmPatHzWS/QR9/h1xVieeGXmeahaGWxSOZrfp2miMboXrK1CSjcIldiC1IQb8x z7eD1t3aBtWrt0Ru34Zqz0CJIWyNZ1Bayxe5leR9aDsY1NiXZ+VNt73Cd8M1r8IeVjZ/ Sg9XcQQldSRRQgK/B9VwjgIqQNjHIZukBslv8gGTDBbC6nV43KQAKo3nOknxpRhuX6Ow kVkQ== 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=aqr8x3OZKsuOwfGkEqMQhvKmDuinisg62uUSg+Y8wDA=; b=X0Jh4QsD4mpjN/c7qYnHJdk18TU+6SyCJ7bToRw22GGxn1skj6hfHI5dypSkVJY4gw LqzKt3XpwFbRDKHO4NH8ceaMKT0zy+TRKdfwb/Je/LHbrFzRYueNob0Ns9udStTlo9Mi AHLUcahd0nisdEDE1gK7RR150fRNlmoAMVYIuVzComDL4AUu0C09OtEEXnlYExUSxihW mnaQnhy0jZOSbOfa04SgxRD7Xws3sWXv2V+Qcxo994FRBH/6gQDpUSSabn7+f+oMi9FQ kOF0yQBDIcARg1+XKpOz7IiwDlN8JWJMHZrZ7QaVj3ZjFKTLe4F5jWJbVrI8DfbHud7D paeg== X-Gm-Message-State: AOAM533sD1bS9F6Acm90NndX7KDIfvPe2Fl9Z5ZCXZkk9y2ZSKP1KDUq o57/IhkgXNNQ1FVRnKaJlJV1Beo2A3YJ1xs0tBM/uR3B8k0= X-Google-Smtp-Source: ABdhPJyEg+uzjmx6MXI7ySfV2ILTHOD2Oi1sQ/EoffZzid80D+F66gOyvVUNS0hqDUJwFcGrYky+WnGBNweuyiJGYhc= X-Received: by 2002:a05:6638:14ca:: with SMTP id l10mr2038134jak.107.1639752305614; Fri, 17 Dec 2021 06:45:05 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Bridger Dyson-Smith Date: Fri, 17 Dec 2021 09:46:23 -0500 Message-ID: Subject: Re: Evolution mail: Deleted Items folder behavior To: freebsd-gnome@freebsd.org, freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b222d205d35895d0" X-Rspamd-Queue-Id: 4JFsGB27f7z3kqm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dij77ZyC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bdysonsmith@gmail.com designates 2607:f8b0:4864:20::d2d as permitted sender) smtp.mailfrom=bdysonsmith@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2d: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]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000b222d205d35895d0 Content-Type: text/plain; charset="UTF-8" Replying/forwarding to a second list - To the freebsd-gnome list: sorry for the additional noise -- I'm realizing now that maybe the list is more geared towards generated reports. To freebsd-hackers: Hi all, I'm wondering if anyone can help differentiate some Evolution mail folder behavior. On Mon, Dec 13, 2021 at 1:31 PM Bridger Dyson-Smith wrote: > Hi all - > > Thanks for your time and trouble making Evolution available. I'm having > two issues that may be related: > 1. I can't seem to expunge items in the Deleted Items folder (e.g. right > clicking on the folder doesn't show an 'Expunge' option) > 2. Expunge (Folder > Expunge) doesn't seem to work in any case. > > I'm using Evolution to interact with an Office 365 account, so I'm using > the evolution-ews package as well. > > ) pkg info -q | grep evolution > evolution-3.42.1 > evolution-data-server-3.42.1 > evolution-ews-3.42.1 > > I'm wondering if I'm just missing an additional library (or configuration > step), as I also use Evolution on a Void Linux install. It's running a > slightly older version (same packages but v3.40.2) but doesn't exhibit the > same problem. > > Does anyone have any advice for what can I do to try fixing this? Thanks > in advance for your help. > The Void Linux machine runs XFCE, while my FreeBSD machine uses an OpenBox WM. I keep thinking that perhaps I'm missing some library associated with the fuller DE, but haven't been able to make any determinations. Best, > Bridger > Thanks in advance for any suggestions you're willing to share! Best, Bridger --000000000000b222d205d35895d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying/forwarding to a second list -

To the freebsd-gnome list: sorry for the additional noise -= - I'm realizing now that maybe the list is more geared towards generate= d reports.

To freebsd-hackers: Hi all,

I'm wondering if anyone can help differentiate = some Evolution mail folder behavior.

On Mon, Dec 13, 2021 at 1:31 PM Br= idger Dyson-Smith <bdysonsmith@= gmail.com> wrote:
Hi all -

Tha= nks for your time and trouble making Evolution available. I'm having tw= o issues that may be related:
1. I can't seem to expunge= items in the Deleted Items folder (e.g. right clicking on the folder doesn= 't show an 'Expunge' option)
2. Expunge (Folder &= gt; Expunge) doesn't seem to work in any case.

I'm using Evolution to interact with an Office 365 account, so I'm= using the evolution-ews package as well.=C2=A0

) pkg i= nfo -q | grep evolution
evolution-3.42.1
evolution-data-server-3= .42.1
evolution-ews-3.42.1

I'm wondering if= I'm just missing an additional library (or configuration step), as I a= lso use Evolution on a Void Linux install. It's running a slightly olde= r version (same packages but v3.40.2) but doesn't exhibit the same prob= lem.

Does anyone have any advice for what can = I do to try fixing this? Thanks in advance for your help.
The Void Linux machine runs=C2=A0 XFCE, while my FreeBSD machin= e uses an OpenBox WM. I keep thinking that perhaps I'm missing some lib= rary associated with the fuller DE, but haven't been able to make any d= eterminations.

Best,
Bridger

Thanks in advance for any suggestions you'= ;re willing to share!
Best,
Bridger
= --000000000000b222d205d35895d0-- From nobody Sat Dec 18 03:52:22 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E5FE418EA5DA; Sat, 18 Dec 2021 03:52:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGBkj3879z3L0c; Sat, 18 Dec 2021 03:52:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BI3qMI9068936 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 19:52:22 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BI3qMNs068935; Fri, 17 Dec 2021 19:52:22 -0800 (PST) (envelope-from sgk) Date: Fri, 17 Dec 2021 19:52:22 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211218035222.GA68916@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JGBkj3879z3L0c X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 14, 2021 at 10:21:55PM +0000, Mark Murray wrote: > On 14 Dec 2021, at 21:51, Steve Kargl wrote: > > Interval max ULP x at Max ULP > > [6,1755.1] 0.873414 at 1.480588145237629047468e+03 > > [1.0662,6] 0.861508 at 1.999467927053585410537e+00 > > [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 > > [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 > > [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 > > > > Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or > > Extra diffs most welcome! > Hi Mark, Don't know if you noticed, but I borroewed a few cpu cycles from grimoire. My WIP is already better than the imprecise.c kludge from theraven@. I need to work out the details of computing logl(x) in extra precision or see if I can leverage what Bruce did a few years ago. Anywho, current results: Interval tested for tgammal: [128,1755] count: 1000000 xm = 1.71195767195767195767195767195767183e+03L libm = 7.79438030237108165017007606176403036e+4790L mpfr = 7.79438030237108165017007606175285456e+4790L ULP = 14869.19517 Interval tested for tgammal: [16,128] count: 1000000 xm = 1.27687183687183687183687183687183690e+02L libm = 6.61421998891483212224382625339007663e+212L mpfr = 6.61421998891483212224382625338960267e+212L ULP = 731.00958 Interval tested for tgammal: [10,16] count: 1000000 xm = 1.54261654261654261654261654261654251e+01L libm = 2.74203137295418912508367515208072654e+11L mpfr = 2.74203137295418912508367515208073861e+11L ULP = 45.61161 Interval tested for tgammal: [1.2446e-60,10] count: 1000000 xm = 6.26200626138006138006138006138006065e-02L libm = 1.54507103764516989381203274093299079e+01L mpfr = 1.54507103764516989381203274093299091e+01L ULP = 0.76751 -- Steve From nobody Sat Dec 18 10:41:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C65218E327C; Sat, 18 Dec 2021 10:41:18 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGMpQ26Hnz4kBs; Sat, 18 Dec 2021 10:41:18 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:6dfc:850d:c1cd:d820]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id A3CC220844; Sat, 18 Dec 2021 10:41:17 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211218035222.GA68916@troutmask.apl.washington.edu> Date: Sat, 18 Dec 2021 10:41:14 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639824078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Ad3Lky0eNnvICrh1CZUgIH6Hu4GiGCutuqmFdwq1ow=; b=szq2Z/cwOKBb/3GIcFVjdmlT3Tt6dvTWNRiU/KYR8hRFbWMJ70MMBuGVdTb9bP6ekiozGg sQfmk/47PpDFd7y2TljtnfBW9SlKTemCfsGgcA4c8NDcsbvXpRYMgIkQN1IO+5A6UNo4Wd IporNE203CF2bdihJQmKcVtoXPiEaZlRci8/uT1bhZC0aWkvpJhZyGGt+cGkAvcF6vQ/2V JLcgK2tiIlk5AA09/S1hz1XQsy3gXnP/Qx3kDxc825mM4J7nsUBWNpov1yjenooNutd3vw z89JUbgnRKQnsuza1RPe7w6TJHC3dzECd8RHOaLpWS4oAFYuQoRGha/RhcfgcQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639824078; a=rsa-sha256; cv=none; b=BVUsGMuoDwGcMRGoQL7wZ9UXzFE5uxTN2DzHwscP2uxA22GazGjk6wml3v4gPGBwDxuG92 Vbzmlwo0Pv2ZrcQIBtu1ahHLsPq9LqCdeBNlG1k/gjjNGwhxw7jqYdBRrizIQUcKbVJ+Pd 0ZPn3N7vcDb+BQkmFgOnalPPILIsX/2g+qM63C+4SWv1M3eHXiJoWCSuBL6hAXCk4IyNjh HSodVlseGiHJZC1HJNVjm1hVD1fxDT6cwkn5AIEx/JiBjhRBqmwxEt2Lysp5OUwPv9T2sZ aXiaHCZclcWbzxWvP4TM0rrp2k/SR31hiO23Gv+AHdQ9Mdu7DV6rgST8tJokpw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Dec 2021, at 03:52, Steve Kargl = wrote: >=20 > On Tue, Dec 14, 2021 at 10:21:55PM +0000, Mark Murray wrote: >> On 14 Dec 2021, at 21:51, Steve Kargl = wrote: >>> Interval max ULP x at Max ULP >>> [6,1755.1] 0.873414 at 1.480588145237629047468e+03 >>> [1.0662,6] 0.861508 at 1.999467927053585410537e+00 >>> [1.01e-17,1.0661] 0.938041 at 1.023286481537296307856e+00 >>> [-1.9999,-1.0001] 3.157770 at -1.246957268051453610329e+00 >>> [-2.9999,-2.0001] 2.987659 at -2.220949465449893090070e+00 >>>=20 >>> Note, 1.01e-17 can be reduced to soemthing like 1.01e-19 or >>=20 >> Extra diffs most welcome! >>=20 >=20 > Hi Mark, >=20 > Don't know if you noticed, but I borroewed a few cpu cycles > from grimoire. Didn't notice a thing! :-) > My WIP is already better than the imprecise.c > kludge from theraven@. I need to work out the details of > computing logl(x) in extra precision or see if I can leverage > what Bruce did a few years ago. Anywho, current results: >=20 > Interval tested for tgammal: [128,1755] > count: 1000000 > xm =3D 1.71195767195767195767195767195767183e+03L > libm =3D 7.79438030237108165017007606176403036e+4790L > mpfr =3D 7.79438030237108165017007606175285456e+4790L > ULP =3D 14869.19517 >=20 > Interval tested for tgammal: [16,128] > count: 1000000 > xm =3D 1.27687183687183687183687183687183690e+02L > libm =3D 6.61421998891483212224382625339007663e+212L > mpfr =3D 6.61421998891483212224382625338960267e+212L > ULP =3D 731.00958 >=20 > Interval tested for tgammal: [10,16] > count: 1000000 > xm =3D 1.54261654261654261654261654261654251e+01L > libm =3D 2.74203137295418912508367515208072654e+11L > mpfr =3D 2.74203137295418912508367515208073861e+11L > ULP =3D 45.61161 >=20 > Interval tested for tgammal: [1.2446e-60,10] > count: 1000000 > xm =3D 6.26200626138006138006138006138006065e-02L > libm =3D 1.54507103764516989381203274093299079e+01L > mpfr =3D 1.54507103764516989381203274093299091e+01L > ULP =3D 0.76751 Hmm. I think my understanding of ULP is missing something? I thought that ULP could not be greater than the mantissa size in bits? I.e., I thought it represents average rounding error (compared with "perfect rounding"), not truncation error, as the above very large ULPs suggest. M -- Mark R V Murray --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG9usoACgkQQlsJDh9C UqA2bwf/aSpM0ZVX02od/89cMjwD+Hy5U4QemDhs+qHx0hPQn/Ry5SyEEeqjAJrA lde6OSxRhX3wBc5i/eN7vXdTz1WVj8C/QboXx0pkOBvVMOrb/9CpD5und8EIdekf f5QixS6vqXURjgLqRCdmOViCfG58KF+BcLJHZAtwl1EwoVTo28H/o+gx+2iA84oT qknObY4tKpMFqi5I5l7mmv7T/1Kiiwbe56KGAHvAMBY3u2048mOZpTGxJ/4qfSJI D/ZZLu51KAVx6mp8gRqUObxVoUpaUpYY8v1C/1Qbegmc7GGPnzcQPV28SWtB6kSw D3jkwnsxc1+GcIvHkFG2WE9Spaq5+w== =gzh1 -----END PGP SIGNATURE----- --Apple-Mail=_D858C349-81E9-4783-9A72-6F9F7568A1F2-- From nobody Sat Dec 18 17:51:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2796418E7825; Sat, 18 Dec 2021 17:51:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGYMF03RXz4cfv; Sat, 18 Dec 2021 17:51:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BIHppYb071383 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Dec 2021 09:51:51 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BIHpp8v071382; Sat, 18 Dec 2021 09:51:51 -0800 (PST) (envelope-from sgk) Date: Sat, 18 Dec 2021 09:51:51 -0800 From: Steve Kargl To: Mark Murray Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211218175151.GA71197@troutmask.apl.washington.edu> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> X-Rspamd-Queue-Id: 4JGYMF03RXz4cfv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: > > Hmm. I think my understanding of ULP is missing something? > > I thought that ULP could not be greater than the mantissa size > in bits? > > I.e., I thought it represents average rounding error (compared with > "perfect rounding"), not truncation error, as the above very large > ULPs suggest. > The definition of ULP differs according which expert you choose to follow. :-) For me (a non-expert), ULP is measured in the system of the "accurate answer", which is assumed to have many more bits of precision than the "approximate answer". >From a very old das@ email and for long double I have /* From a das email: * * ulps = err * (2**(LDBL_MANT_DIG - e)), where e = ilogb(accurate). * * I use: * * mpfr_sub(err, accurate, approximate, RNDN); * mpfr_abs(err, err, RNDN); * mpfr_mul_2si(ulpx, err, -mpfr_get_exp(accurate) + LDBL_MANT_DIG, RNDN); * ulp = mpfr_get_d(ulpx, RNDN); * if (ulp 0.506 && mpfr_cmpabs(err, ldbl_minx) 0) { * print warning...; * } */ Here, "err = |accurate - approximate|" is done in the precision of the "accurate answer", and RNDN is round-to-nearest. The line 'mpfr_mul_2si(...)' is doing the scaling to manipulate the exponent of the radix 2. This is agreement with Goldberg. IIRC, Jean-Michel Muller et al have much more detailed discussion about error and ULPs in their book "Handbook of Floating-Point Arithmetic". https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html So, on ld80 and tgamma, I have % tlibm -l -x 8 -X 1755 -n 100000 -P tgamma Interval tested for tgammal: [8,1755] ulp <= 0.5: 90.207% 90207 | 90.207% 90207 0.5 < ulp < 0.6: 7.085% 7085 | 97.292% 97292 0.6 < ulp < 0.7: 2.383% 2383 | 99.675% 99675 0.7 < ulp < 0.8: 0.314% 314 | 99.989% 99989 0.8 < ulp < 0.9: 0.011% 11 | 100.000% 100000 Max ulp: 0.853190 at 9.236118561185611856579e+02 The "ulp <= 0.5" line indicates the number of correctly rounded case. If the value of ULP exceeds 1, then you are starting to lose more than 1 bit in the significant. Consider individual points. Here's a correctly rounded case: % tlibm -l -a 9.236118561185000000 tgamma xu = LD80C(0x93c72441a44a57a9, 3, 9.23611856118499999994e+00L), libmu = LD80C(0x82f85b3fe4b36f9b, 16, 6.70567128873706962722e+04L), mpfru = LD80C(0x82f85b3fe4b36f9b, 16, 6.70567128873706962722e+04L), ULP = 0.42318 Notice, ULP < 0.5 and the bits in libm and mpfr answer rounded to long double are all the same as is the decimal representation. Now consider the max ULP case: % tlibm -l -a 9.236118561185611856579e+02 tgamma xu = LD80C(0xe6e728a690c4fa87, 9, 9.23611856118561185658e+02L), libmu = LD80C(0xba6bea661a7eda3c, 7762, 5.72944398777756327202e+2336L), mpfru = LD80C(0xba6bea661a7eda3d, 7762, 5.72944398777756327245e+2336L), ULP = 0.85319 ULP is < 1, which is desireable. The bits agree except for the last place where we're off by 1, ie, 0xc vs 0xd. The decimal representation is of course off. So, now on grimoirei without my patch, I have % ./tlibm_libm -l -a 1.59255925592559255925592559255925594e+01 tgamma x = 1.59255925592559255925592559255925594e+01L libm = 1.06660136733166064453125000000000000e+12L mpfr = 1.06660136733166211967839038834033459e+12L, ULP = 13932370826141802496.00000 You have 16 correct decimal digits out of 36, which is the best you can expect from mapping tgammal to tgamma. ULP is significant larger than 1. The ulp is almost guaranteed to be larger than 2**(113-53). Now with my patch and worse case for 10000 x in [10:16] % ./tlibm_lmath -l -a 1.59255925592559255925592559255925594e+01 tgamma x = 1.59255925592559255925592559255925594e+01L libm = 1.06660136733166211967839038834033897e+12 mpfr = 1.06660136733166211967839038834033459e+12L, ULP = 41.40877 I don't print out the hex representation in ld128, but you see the number of correct decimal digits is 33 digits compared to 36. -- Steve From nobody Sat Dec 18 17:59:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4A21B18EB982; Sat, 18 Dec 2021 17:59:46 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JGYXL0NZxz4jDd; Sat, 18 Dec 2021 17:59:46 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:6dfc:850d:c1cd:d820]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id 628F823DCE; Sat, 18 Dec 2021 17:59:45 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Subject: Re: What to do about tgammal? From: Mark Murray In-Reply-To: <20211218175151.GA71197@troutmask.apl.washington.edu> Date: Sat, 18 Dec 2021 17:59:42 +0000 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3693.20.0.1.32) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1639850386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8awRWXdBdNSaG0H+w7qzgxKu0/o7+nYCAv4yo0dDwpo=; b=ksG/miBvnt0mQJJhLKubSCG4v+AWL+29ZZNXjvF2fOvMoCX9UdMYimfV5/6+QItp1whzvp LFHHvOB7YEVLpUxeS5UydZihTRD6r7EzRdZ9kGgZpICMArHCNOe3/2L+qgbdyIy9CjvV8F i+h9TzNR2X7+uils8YHbcdL0PxlFX4wVa6VoOucCqXmtZ9uzE8zmqc6SuY24SgcVIh/5W4 ztVs1gXxrAQHxgNHr6IiWqiFoCOt7dzbZOaSDgN0RKKi9BFglK/tUjs4DeQv4gLC57Nl4C 61QBXzD8G/4wPNBHp2k3KfrdpXqhnxY36XgwT/ZR04qOJ4ZnkiSXcNza9L/EPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1639850386; a=rsa-sha256; cv=none; b=lTHFPtsYdVc9073Talb0h0m5QMcmRXxllHxJWcUEZv7zv7TT/Zup3erbcCRdq+yXSBHAW1 6Hgk34FNFFwR6Ny9IGbpytEYRpvXUySSLoMQ75sFqipSbmUBX16mzdEec/sUqZBOfGmX39 XnnNFmsyAqpQz7nQ+08qKqcgF8wGRC8mb4S4bNvnJYF4Tqw+hHz89cy18l5aY/QQSA6ifZ iUTVe+LNwwQL/hedabTPbB3rcc+4Z+l2UHO/YWMInbO7RmDy8Qpa1zMM1yjSB5hSnm+oaH B1CuARUbZkUibxkepo7nrKqzc+VXa9Y2OC+3+6GqJtf/+WAVxLvMQ/h5iIp6Pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Dec 2021, at 17:51, Steve Kargl = wrote: >=20 > On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: >>=20 >> Hmm. I think my understanding of ULP is missing something? >>=20 >> I thought that ULP could not be greater than the mantissa size >> in bits? >>=20 >> I.e., I thought it represents average rounding error (compared with >> "perfect rounding"), not truncation error, as the above very large >> ULPs suggest. >>=20 >=20 > The definition of ULP differs according which expert you > choose to follow. :-) For me (a non-expert), ULP is measured > in the system of the "accurate answer", which is assumed to > have many more bits of precision than the "approximate answer". > =46rom a very old das@ email and for long double I have Thank you! I checked the definition that I was used to, and it is roughly "how many bits of the mantissa are inaccurate (because of rounding error)". I can see how both work. For utterly massive numbers like from Gamma(), I can see how accounting for a much larger range works. It still feels slightly tricky, as e.g. how many digits after the floating point do you account for? > I don't print out the hex representation in ld128, but you see > the number of correct decimal digits is 33 digits compared to > 36. Looking good! M -- Mark R V Murray --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmG+IY4ACgkQQlsJDh9C UqDfZggAnbSAQEULcHYiEtSHmmFl3QopLwmRz2Ut6beEHD8olyv/PuqY/zh1aq99 sBqzlnEuVlPIE0jc5LXinK7h4JEolvdmeHHWAKvVQMfoUBxKBQyKa0muErAi+DoH Oimuf27Ga+xSuoDyb34+Nhh2GySchEflyYMwp9VVy+vkApIGkRYJymba458oyQP3 LhkWSSUdP9d1I+AlJHq1zeukmryrGi39rumBvCQ2XPhn0y/Vt48TXAgoVA/M7q3S LY+oEvwnLrNWZkRQEr80lDDpaemmVAmPigj+viTBwhSR3z/cDmFWD1o7uga4Igv7 cMNxBkU0KfPByRz+c3TUnicJ4ZKBwQ== =8ZW9 -----END PGP SIGNATURE----- --Apple-Mail=_39AA88BD-0EEE-4E7D-9F37-3FC17D2DD0EA-- From nobody Sun Dec 19 16:50:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9BA2E190F844 for ; Sun, 19 Dec 2021 16:52:34 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JH80K5S9qz3mRt for ; Sun, 19 Dec 2021 16:52:33 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [217.246.54.215] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1myzPW-00084I-Fi for freebsd-hackers@freebsd.org; Sun, 19 Dec 2021 17:51:46 +0100 Date: Sun, 19 Dec 2021 17:50:11 +0100 From: Fabian Keil To: FreeBSD hackers Subject: Patches for GPT and geli recovery Message-ID: <20211219175011.3023a232@fabiankeil.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/N3ow18usOrcj9SyeyzSv.yO"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4JH80K5S9qz3mRt X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.16) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[80.67.18.16:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.16:from]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[217.246.54.215:received] X-ThisMailContainsUnwantedMimeParts: N --Sig_/N3ow18usOrcj9SyeyzSv.yO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recently one of my disks "experienced a data corruption event of unknown origin". Additional details are available at: TLDR: I created two patches to recover nearly all the data. The first patch implements a "search" subcommand for geli to look for valid meta data (but unfortunately the meta data on my disk was corrupted or gone): The second patch lets the kernel ignore more issues if kern.geom.part.check_integrity is set to 0: I'm wondering if those patches should be upstreamed. The first patch is probably safe but for the second one I only tested the code paths that were relevant for my issue. BTW, I would also be interested to know if others have experienced similar data corruption and could figure out how it happened. Fabian --Sig_/N3ow18usOrcj9SyeyzSv.yO Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYb9iwwAKCRAFiohV/3dU ndppAJ9ZKp5Rh9LBAgzhwBHmZi7+FPmtlgCfb0wmjgfImPhcPWoY95sR32yK9mc= =EPrJ -----END PGP SIGNATURE----- --Sig_/N3ow18usOrcj9SyeyzSv.yO-- From nobody Sun Dec 19 19:40:43 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A65AC18FE175 for ; Sun, 19 Dec 2021 19:41:01 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHCkj4B4pz4bbK for ; Sun, 19 Dec 2021 19:41:01 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-ot1-x330.google.com with SMTP id x43-20020a056830246b00b00570d09d34ebso10092824otr.2 for ; Sun, 19 Dec 2021 11:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O5lfAbs9eOtFctuEUILp6bkCKPcOaxCRnKLSDVuMBCE=; b=ZqRg94P29IKhPlpw0XtxQA3n3qUvL4m1DXyOIFwTWwPVhlfZqtRZ4AVoOv4MAUD6YW /1tY2V4Qh37Lzfgv1cQnuHt5UGeWhd4f1cVU7D+Vq+KkzHOrS9+Oj1CT/HnsnQ6dOWQk teIKNTyHa9flcTnF3SdkBl9T9h/CeKM/St9uKmiQNyXYnYYP9BcEVL1SOKYxlIBNqtVY TWk0PT0jQrqlErDO6lpWMue/grRlYHu+EIZGsdf8HEWKlABXHNzcMOgdfoeBiqR6mU13 vCClFq2l57uYcFk7incD1TPbej/yIuLVrQlx4WPa3/3XhbyZYN08HGoNQQqTaW4hO9+M jqLg== 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=O5lfAbs9eOtFctuEUILp6bkCKPcOaxCRnKLSDVuMBCE=; b=i6M5GGJE+D4xGhuEgf/jyqcFeIb7gNt3EihKH/IYxgmw9a4t+QYgMG4ocMe4gbohfV PqT249OL9DC2hPp2UMIMEK2K1BBGvRbOagyaC+5qLiMXteErkk2+/akGkc700gyjmMOo cGTbFS5NjG6MZeOuKuA+s0XJGGTQ3+grr9buiEF0AjRlPVMJ9zGApEHJRO8Rf4OcTEEa GVKJpMGAQTfQUo9cRCdV4im9a/7Y8X9hlKl834vVBHfj3HKTXzbgSp0Q6Rf6hy/QxHC1 nj3yo2lCG8xaRxsrIgFzhfAqrPcBs8fW5Ii3OTibPVXWRmeJ/HQWMwP1RfZm8drMGcqa 4RcA== X-Gm-Message-State: AOAM533Tv+aF6XrBISab5TS++nphVfIruq0tPGNrNMacA+ZjzuHjwVHz Cx4D7COT7HTIWp6HARMO8qBmQU2bvivPzpX4OeCDHcEs6r5bpg== X-Google-Smtp-Source: ABdhPJyW1PnLwOYWqgbhRg/xUsfcdxSQnHWpm/qWc/aNdAh+rZBhWdWBWrB+HUg3bEu/0mYqJbZF767A5U7EeB0CLEs= X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr9068805otq.105.1639942855109; Sun, 19 Dec 2021 11:40:55 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211219175011.3023a232@fabiankeil.de> In-Reply-To: <20211219175011.3023a232@fabiankeil.de> From: Lee Brown Date: Sun, 19 Dec 2021 11:40:43 -0800 Message-ID: Subject: Re: Patches for GPT and geli recovery To: Fabian Keil Cc: FreeBSD hackers Content-Type: multipart/alternative; boundary="00000000000054c47505d384f311" X-Rspamd-Queue-Id: 4JHCkj4B4pz4bbK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000054c47505d384f311 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 19, 2021 at 8:52 AM Fabian Keil wrote: > [cut] > BTW, I would also be interested to know if others have > experienced similar data corruption and could figure > out how it happened. > Sounds like bitrot. Bits flip on disks all the time, it doesn't matter if they are spinning rust or SSD, it happens. Sometimes they are detected and corrected, in which case you won't know. Sometimes they are detected and uncorrectable, you'll see that error propagated into the driver. And sometimes they are not detected at all and cause no errors that the OS can surmise. The higher the density of bits, the higher the probability of corruption. SMART is not reliably predictive. How does it happen? Cosmic rays and entropy. I've had lighty written SSD's fail after a few months. I don't use ZFS, but have GELI-Authentication under a GMIRROR, so whenever a bad checksum is read, it breaks the mirror, which gets attention (Iast I looked, there wasn't a simple userland hook for bad GELI reads, but there was for GMIRROR add/remove events). HTH - lee --00000000000054c47505d384f311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 19, 2021 at 8:52 AM Fabia= n Keil <freebsd-listen@f= abiankeil.de> wrote:
[cut]
BTW, I would also be interested to know if others have
experienced similar data corruption and could figure
out how it happened.
Sounds like bitrot.=C2=A0 Bits f= lip on disks all the time, it doesn't matter if they are spinning rust = or SSD, it happens.=C2=A0 Sometimes they are detected and corrected, in whi= ch case you won't know.=C2=A0 Sometimes they are detected and uncorrect= able, you'll see that error propagated into the driver.=C2=A0 And somet= imes they are not detected at all and cause no errors that the OS can surmi= se.=C2=A0 The higher the density of bits, the higher the probability of cor= ruption.=C2=A0 SMART is not reliably predictive.=C2=A0 How does it happen?= =C2=A0 Cosmic rays and entropy.=C2=A0 I've had lighty written SSD's= fail after a few months.

I don't use ZFS, but have GELI-Authentication u= nder a GMIRROR, so whenever a bad checksum is read, it breaks the mirror, w= hich gets attention (Iast I looked, there wasn't a simple userland hook= for bad GELI reads, but there was for GMIRROR add/remove events).

HTH - lee<= br>
--00000000000054c47505d384f311-- From nobody Sun Dec 19 22:21:39 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6FB8C19068D1 for ; Sun, 19 Dec 2021 22:21:48 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHHJC2Dzyz3Jpp for ; Sun, 19 Dec 2021 22:21:47 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qv1-xf30.google.com with SMTP id m6so7767371qvh.10 for ; Sun, 19 Dec 2021 14:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=wXD4beA3CbYqi2g+JKJTYDqw2OOHh6nOlZnS6cXg3Sc=; b=VJb6gCfcoS5ppRPJmHU7iX28wJkRbAk2Ttjezvdg2GQ86Vgjy8mgri5/NVAfOhLSWM RUla6NhPsQ5PLwguYCrzg3d5ZMGfdPO6S//pN0W6stirGuDRSeM4EYru2ziQ1JuAK5n0 yrcrFisLvJTfMW2gTwfuJHt2NXV82+u0n828HOBBAyrhZIR6C3tVDdQdTtLzRQB0R2mA sHI1GlorOfb9zprU4PRSbpBLBpfqRF5kG/BmI/5ISNopCskdx+MDUK47bEntZbu/TEvE JmPIpLx7pun9oDfi3wgs9ElMgR2/y4AjpmuQKb5+NpIQdQkKSSoBLn3U0bpOlU4hK5GG PKqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=wXD4beA3CbYqi2g+JKJTYDqw2OOHh6nOlZnS6cXg3Sc=; b=ATCL7qPuKKelOmtOitruoAADpCa9TjTrZsTCKxNA43v9HbQAU5hJa1qnvT/5COrgX4 dq0d03ex8wdje3xUFNbzmki2avn/vsSJfhnzcGcGZ5JM1T7DmLwShI3eA+OjerI6fJd6 oHWqHXrxdvtjlwJWBHCdNZr4qQGA3pO6i/whrJzh4tLF/Oox5PRXBpSINbqunehGpw8T 8Szvqomwj1vdP4uWNyvWALSG2y/tQbxBUsAOuAUgnd6N6vS2scn7tfoqy7jvSIQwF3Io OJANcKy4Q7ENojn37mc7BNRRXl53Z1Tkf80xNT9lMCkktylqeGE88WwBSNS67rZ4IdPr V3SA== X-Gm-Message-State: AOAM532nqyHlI4ZL4ugPUNKb4BK/k1Kf6pQCjwWiPHw4Milkx3CsYAdR 2h0YPzC8O1ZHOf1Bw7pK7VuSL4wmZLU= X-Google-Smtp-Source: ABdhPJxGuodMDXaOaI4XxRYm4kXjMFMxIZeVSJgx3tBs3O8j317/lumz0q+wDRmMzKlIuzFkEURThw== X-Received: by 2002:a05:6214:f04:: with SMTP id gw4mr2214168qvb.42.1639952500555; Sun, 19 Dec 2021 14:21:40 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id w8sm13274061qtc.36.2021.12.19.14.21.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Dec 2021 14:21:40 -0800 (PST) Message-ID: <67419422-5633-4e4b-870d-aec8762ec6a1@gmail.com> Date: Sun, 19 Dec 2021 16:21:39 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Patches for GPT and geli recovery Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20211219175011.3023a232@fabiankeil.de> From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4JHHJC2Dzyz3Jpp X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VJb6gCfc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [2.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0: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:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N T24gMTIvMTkvMjEgMTM6NDAsIExlZSBCcm93biB3cm90ZToNCj4gDQo+IA0KPiBPbiBTdW4s IERlYyAxOSwgMjAyMSBhdCA4OjUyIEFNIEZhYmlhbiBLZWlsIA0KPiA8ZnJlZWJzZC1saXN0 ZW5AZmFiaWFua2VpbC5kZSA8bWFpbHRvOmZyZWVic2QtbGlzdGVuQGZhYmlhbmtlaWwuZGU+ PiB3cm90ZToNCj4gDQo+ICAgICBbY3V0XQ0KPiAgICAgQlRXLCBJIHdvdWxkIGFsc28gYmUg aW50ZXJlc3RlZCB0byBrbm93IGlmIG90aGVycyBoYXZlDQo+ICAgICBleHBlcmllbmNlZCBz aW1pbGFyIGRhdGEgY29ycnVwdGlvbiBhbmQgY291bGQgZmlndXJlDQo+ICAgICBvdXQgaG93 IGl0IGhhcHBlbmVkLg0KPiANCj4gU291bmRzIGxpa2UgYml0cm90LsKgIEJpdHMgZmxpcCBv biBkaXNrcyBhbGwgdGhlIHRpbWUsIGl0IGRvZXNuJ3QgbWF0dGVyIA0KPiBpZiB0aGV5IGFy ZSBzcGlubmluZyBydXN0IG9yIFNTRCwgaXQgaGFwcGVucy7CoCBTb21ldGltZXMgdGhleSBh cmUgDQo+IGRldGVjdGVkIGFuZCBjb3JyZWN0ZWQsIGluIHdoaWNoIGNhc2UgeW91IHdvbid0 IGtub3cuwqAgU29tZXRpbWVzIHRoZXkgDQo+IGFyZSBkZXRlY3RlZCBhbmQgdW5jb3JyZWN0 YWJsZSwgeW91J2xsIHNlZSB0aGF0IGVycm9yIHByb3BhZ2F0ZWQgaW50byANCj4gdGhlIGRy aXZlci7CoCBBbmQgc29tZXRpbWVzIHRoZXkgYXJlIG5vdCBkZXRlY3RlZCBhdCBhbGwgYW5k IGNhdXNlIG5vIA0KPiBlcnJvcnMgdGhhdCB0aGUgT1MgY2FuIHN1cm1pc2UuwqAgVGhlIGhp Z2hlciB0aGUgZGVuc2l0eSBvZiBiaXRzLCB0aGUgDQo+IGhpZ2hlciB0aGUgcHJvYmFiaWxp dHkgb2YgY29ycnVwdGlvbi7CoCBTTUFSVCBpcyBub3QgcmVsaWFibHkgDQo+IHByZWRpY3Rp dmUuwqAgSG93IGRvZXMgaXQgaGFwcGVuP8KgIENvc21pYyByYXlzIGFuZCBlbnRyb3B5LsKg IEkndmUgaGFkIA0KPiBsaWdodHkgd3JpdHRlbiBTU0QncyBmYWlsIGFmdGVyIGEgZmV3IG1v bnRocy4NCj4gDQo+IEkgZG9uJ3QgdXNlIFpGUywgYnV0IGhhdmUgR0VMSS1BdXRoZW50aWNh dGlvbiB1bmRlciBhIEdNSVJST1IsIHNvIA0KPiB3aGVuZXZlciBhIGJhZCBjaGVja3N1bSBp cyByZWFkLCBpdCBicmVha3MgdGhlIG1pcnJvciwgd2hpY2ggZ2V0cyANCj4gYXR0ZW50aW9u IChJYXN0IEkgbG9va2VkLCB0aGVyZSB3YXNuJ3QgYSBzaW1wbGUgdXNlcmxhbmQgaG9vayBm b3IgYmFkIA0KPiBHRUxJIHJlYWRzLCBidXQgdGhlcmUgd2FzIGZvciBHTUlSUk9SIGFkZC9y ZW1vdmUgZXZlbnRzKS4NCj4gDQo+IEhUSCAtIGxlZQ0KDQpIb3cgb2xkIHdhcyB0aGUgY29y cnVwdGVkIGZpbGVzeXN0ZW0/ICBJIGhhYml0dWFsbHkgd2lwZSBteSBkaXNrcyBhbmQgZG8g DQphIGZyZXNoIGluc3RhbGwgYXQgbGVhc3Qgb25jZSBldmVyeSAyIHllYXJzIHRvIGF2b2lk IGlzc3VlcyBsaWtlIHRoaXMuIA0KSSBoYXZlIGV4cGVyaWVuY2VkIHVuZXhwbGFpbmVkLCB1 bnJlY292ZXJhYmxlIGVycm9ycyBvbiBvbGQgZmlsZXN5c3RlbXMsIA0KYnV0IGZvcnR1bmF0 ZWx5IG5vdGhpbmcgY3JpdGljYWwuDQoNClRoaXMgdG8gbWUgc2VydmVzIGFzIGFub3RoZXIg cmVtaW5kZXIgdG8gbWFpbnRhaW4gcmVndWxhciBiYWNrdXBzIG9mIA0KaW1wb3J0YW50IGZp bGVzIGFuZCBjb25zaWRlciBldmVyeXRoaW5nIGVsc2UgZXhwZW5kYWJsZS4NCg0KLS0gDQpB bGwgd2FycyBhcmUgY2l2aWwgd2FycywgYmVjYXVzZSBhbGwgbWVuIGFyZSBicm90aGVycyAu Li4gRWFjaCBvbmUgb3dlcw0KaW5maW5pdGVseSBtb3JlIHRvIHRoZSBodW1hbiByYWNlIHRo YW4gdG8gdGhlIHBhcnRpY3VsYXIgY291bnRyeSBpbg0Kd2hpY2ggaGUgd2FzIGJvcm4uDQog ICAgICAgICAgICAgICAgIC0tIEZyYW5jb2lzIEZlbmVsb24NCg== From nobody Mon Dec 20 10:15:53 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 108F918F0990; Mon, 20 Dec 2021 10:16:04 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHb8L4rw7z3tqH; Mon, 20 Dec 2021 10:16:02 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 33472B0057F; Mon, 20 Dec 2021 11:15:54 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BKAFsBY001311 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Dec 2021 11:15:54 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BKAFr4l001310; Mon, 20 Dec 2021 11:15:53 +0100 (CET) (envelope-from marc) Date: Mon, 20 Dec 2021 11:15:53 +0100 From: Marc Fonvieille To: Mark Murray Cc: Steve Kargl , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Mark Murray , Steve Kargl , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211204185352.GA20452@troutmask.apl.washington.edu> <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xCByWbMwccz7wm2s" Content-Disposition: inline In-Reply-To: <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> X-Rspamd-Queue-Id: 4JHb8L4rw7z3tqH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of marc@blackend.org has no SPF policy when checking 2a01:e0c:1:1599::10) smtp.mailfrom=marc@blackend.org X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[marc]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[blackend@freebsd.org,marc@blackend.org]; R_SPF_NA(0.00)[no SPF record]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[blackend@freebsd.org,marc@blackend.org]; RECEIVED_SPAMHAUS_PBL(0.00)[82.64.86.146:received] X-ThisMailContainsUnwantedMimeParts: N --xCByWbMwccz7wm2s Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Le 18.12.2021 17:59, Mark Murray a =E9crit : >=20 >=20 > > On 18 Dec 2021, at 17:51, Steve Kargl wrote: > >=20 > > On Sat, Dec 18, 2021 at 10:41:14AM +0000, Mark Murray wrote: > >>=20 > >> Hmm. I think my understanding of ULP is missing something? > >>=20 > >> I thought that ULP could not be greater than the mantissa size > >> in bits? > >>=20 > >> I.e., I thought it represents average rounding error (compared with > >> "perfect rounding"), not truncation error, as the above very large > >> ULPs suggest. > >>=20 > >=20 > > The definition of ULP differs according which expert you > > choose to follow. :-) For me (a non-expert), ULP is measured > > in the system of the "accurate answer", which is assumed to > > have many more bits of precision than the "approximate answer". > > From a very old das@ email and for long double I have >=20 > >=20 > Thank you! >=20 > I checked the definition that I was used to, and it is roughly > "how many bits of the mantissa are inaccurate (because of > rounding error)". > Hi, ULP (Unit in the last place) is at first the weight of the least significant bit of the mantissa. E.g., in IEEE 754 single precision =3D 2^-23. It can also be seen as the distance between 2 consecutive significands (which is not the distance between 2 consecutive floating numbers). Some people, use ULP (or number of ULP) as Units (plural) in the Last Place to show the number of bits in error in the least significant bits of the significand. I assume what Steve is talking about is the corresponding value in decimal of the number of ULP. This thread is really interesting (even if I'm loosely following it). > I can see how both work. For utterly massive numbers like > from Gamma(), I can see how accounting for a much larger > range works. >=20 > It still feels slightly tricky, as e.g. how many digits after the > floating point do you account for? >=20 > > I don't print out the hex representation in ld128, but you see > > the number of correct decimal digits is 33 digits compared to > > 36. >=20 > Looking good! >=20 > M > -- > Mark R V Murray >=20 --=20 Marc --xCByWbMwccz7wm2s Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRV00iDSgSCiqE5pc/ND1HAT4506AUCYcBX0wAKCRDND1HAT450 6MesAJ9hTi3dMFzFfLKQC7S8/sAwqKeudwCdEKjMYEmLttjWsFBx4mM0/L2y3JE= =Rz1J -----END PGP SIGNATURE----- --xCByWbMwccz7wm2s-- From nobody Mon Dec 20 14:15:00 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AE7171900B03 for ; Mon, 20 Dec 2021 14:16:32 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHhTr0VLCz3KNF for ; Mon, 20 Dec 2021 14:16:31 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [217.246.54.215] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mzJSu-0003t3-Gp for freebsd-hackers@freebsd.org; Mon, 20 Dec 2021 15:16:36 +0100 Date: Mon, 20 Dec 2021 15:15:00 +0100 From: Fabian Keil To: freebsd-hackers@freebsd.org Subject: Re: Patches for GPT and geli recovery Message-ID: <20211220151500.5e57c1a6@fabiankeil.de> In-Reply-To: <67419422-5633-4e4b-870d-aec8762ec6a1@gmail.com> References: <20211219175011.3023a232@fabiankeil.de> <67419422-5633-4e4b-870d-aec8762ec6a1@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/XQGc+8skOnRuNnHdVPt8VzF"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4JHhTr0VLCz3KNF X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.13) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [1.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[80.67.18.13:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.77)[0.770]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.97)[0.971]; NEURAL_SPAM_LONG(0.95)[0.946]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.13:from]; SIGNED_PGP(-2.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[217.246.54.215:received] X-ThisMailContainsUnwantedMimeParts: N --Sig_/XQGc+8skOnRuNnHdVPt8VzF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jason Bacon wrote on 2021-12-19 at 16:21:39: > On 12/19/21 13:40, Lee Brown wrote: > >=20 > >=20 > > On Sun, Dec 19, 2021 at 8:52 AM Fabian Keil=20 > > > wr= ote: > >=20 > > [cut] > > BTW, I would also be interested to know if others have > > experienced similar data corruption and could figure > > out how it happened. > >=20 > > Sounds like bitrot.=C2=A0 Bits flip on disks all the time, it doesn't m= atter=20 > > if they are spinning rust or SSD, it happens.=C2=A0 Sometimes they are= =20 > > detected and corrected, in which case you won't know.=C2=A0 Sometimes t= hey=20 > > are detected and uncorrectable, you'll see that error propagated into=20 > > the driver.=C2=A0 And sometimes they are not detected at all and cause = no=20 > > errors that the OS can surmise.=C2=A0 The higher the density of bits, t= he=20 > > higher the probability of corruption.=C2=A0 SMART is not reliably=20 > > predictive.=C2=A0 How does it happen?=C2=A0 Cosmic rays and entropy.=C2= =A0 I've had=20 > > lighty written SSD's fail after a few months. > >=20 > > I don't use ZFS, but have GELI-Authentication under a GMIRROR, so=20 > > whenever a bad checksum is read, it breaks the mirror, which gets=20 > > attention (Iast I looked, there wasn't a simple userland hook for bad=20 > > GELI reads, but there was for GMIRROR add/remove events). =20 > How old was the corrupted filesystem? I just checked: fk@t520 /var/log/fk/2021-12-20 $grep "zpool create" *zpool-history* ssh-steffen-sudo-zpool-history--l-bpool-20211220T102957:2017-08-10.21:52:07= zpool create -f -o version=3D28 -O compression=3Dlzjb bpool /dev/ada0p2 [u= ser 0 (root) on kendra] ssh-steffen-sudo-zpool-history--l-dpool-20211220T103420:2015-03-17.18:46:42= zpool create dpool /dev/gpt/dpool-ada0.eli [user 0 (root) on kendra] ssh-steffen-sudo-zpool-history--l-rpool-ada1-20211220T103234:2017-04-11.12:= 33:47 zpool create -o version=3D28 -o failmode=3Dcontinue -O compression=3D= lzjb -O checksum=3Dsha256 rpool mirror /dev/ada0p3.eli /dev/da1p3.eli [user= 0 (root) on ElectroBSD-11.0-STABLE-amd64] sudo-zpool-history--l-cloudia2-20211220T103856:2017-04-12.14:45:07 zpool cr= eate -O recordsize=3D1m -O checksum=3Dsha512 cloudia2 /dev/label/cloudia2.e= li [user 0 (root) on t520.local] So it looks like the partially corrupted pool "dpool" on partition five was created on 2015-03-17 while the (former) root pool "rpool-ada1" which didn't show any signs of corruption was created on 2017-04-11 which indicates that I installed a new operating system with cloudiatr and kept the data pool unmodified. The boot pool "bpool" was created on 2017-08-10 but it gets recreated with each ElectroBSD kernel update anyway. > I habitually wipe my disks and do= =20 > a fresh install at least once every 2 years to avoid issues like this.=20 Do you read back the complete data after fresh installs to confirm that the rewritten data arrived on disk as expected? I prefer ZFS scrubs to confirm that the data is still reachable. It's not obvious to me that recreating the data is safer than keeping the old data but verifying checksums. > I have experienced unexplained, unrecoverable errors on old filesystems,= =20 > but fortunately nothing critical. I too have experienced various unrecoverable errors on disks but I never lost GPT partition data and geli meta data at the same time while most of the data on disk remained valid and without the disk reporting any problems. While the pools "dpool" and "cloudia2" contained a couple of corrupt blocks this could be completely unrelated to the corruption of the partition table and the geli meta data. > This to me serves as another reminder to maintain regular backups of=20 > important files and consider everything else expendable. Agreed. The problem disk mostly contained DVD rips and while some of them weren't available on other disks as well, they could be recreated by simply ripping the DVDs again. Of course it's conceivable that some of the source DVDs now contain corruption as well (I own many older DVDs that contain corrupt blocks), but I could probably buy them new or rent them if needed. I use zogftw for backups and my important data is backed up to multiple external pools and some of them are stored off-site. Fabian --Sig_/XQGc+8skOnRuNnHdVPt8VzF Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYcCP5QAKCRAFiohV/3dU nSZWAKCVKS3A32rTmr/6Ymq7QoQBiobNywCfUWgNungBQYNYqLdTGI77WTHKEw0= =JFP0 -----END PGP SIGNATURE----- --Sig_/XQGc+8skOnRuNnHdVPt8VzF-- From nobody Tue Dec 21 00:48:19 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 96885190098F; Tue, 21 Dec 2021 00:48:27 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JHyVy2zTrz3vcJ; Tue, 21 Dec 2021 00:48:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BL0mJhT079172 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Dec 2021 16:48:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BL0mJKb079171; Mon, 20 Dec 2021 16:48:19 -0800 (PST) (envelope-from sgk) Date: Mon, 20 Dec 2021 16:48:19 -0800 From: Steve Kargl To: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211221004819.GA79153@troutmask.apl.washington.edu> References: <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JHyVy2zTrz3vcJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.14 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.77)[-0.767]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.82)[0.824]; NEURAL_HAM_LONG(-0.92)[-0.915]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > I assume what Steve is talking about is the corresponding value in > decimal of the number of ULP. > Bad assumption. Please read Goldberg's paper. I am talking about ULP in the underlying floating point format. -- Steve From nobody Tue Dec 21 14:46:40 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09C6A19061A6; Tue, 21 Dec 2021 14:46:51 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJK6L64Yfz3hxs; Tue, 21 Dec 2021 14:46:50 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id CDA1EB0051E; Tue, 21 Dec 2021 15:46:41 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BLEkejD002250 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 15:46:40 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BLEke99002249; Tue, 21 Dec 2021 15:46:40 +0100 (CET) (envelope-from marc) Date: Tue, 21 Dec 2021 15:46:40 +0100 From: Marc Fonvieille To: Steve Kargl Cc: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Steve Kargl , Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211213022223.GA41440@troutmask.apl.washington.edu> <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211221004819.GA79153@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4JJK6L64Yfz3hxs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Le 20.12.2021 16:48, Steve Kargl a écrit : > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > I assume what Steve is talking about is the corresponding value in > > decimal of the number of ULP. > > > > Bad assumption. Please read Goldberg's paper. I am talking > about ULP in the underlying floating point format. > Thanks, it's more clear now: it's the ULP value. Is your tlibm_libm program available for testing ? If I find time I'd like to do some tests. -- Marc From nobody Tue Dec 21 16:47:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 656C518F5A0F; Tue, 21 Dec 2021 16:47:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJMnz1xjsz4TR3; Tue, 21 Dec 2021 16:47:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1BLGlnbV081717 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Dec 2021 08:47:49 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1BLGlniI081716; Tue, 21 Dec 2021 08:47:49 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Dec 2021 08:47:49 -0800 From: Steve Kargl To: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: <20211221164749.GA81666@troutmask.apl.washington.edu> References: <813F29E3-8478-4282-9518-5943DE7B5492@FreeBSD.org> <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4JJMnz1xjsz4TR3 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [0.68 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.18)[-0.184]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.86)[0.863]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote: > Le 20.12.2021 16:48, Steve Kargl a écrit : > > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote: > > > > > > I assume what Steve is talking about is the corresponding value in > > > decimal of the number of ULP. > > > > > > > Bad assumption. Please read Goldberg's paper. I am talking > > about ULP in the underlying floating point format. > > > > Thanks, it's more clear now: it's the ULP value. > Is your tlibm_libm program available for testing ? If I find time I'd like to > do some tests. > Not at the moment. tlibm only handles math functions with a single real agrument [1]. I've been thinking about adding the 2 argument functions such as atan2 and complex argument function, but lack the time. I also need to improve the man page to decoment the default domain for each function and its complete domain. [1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf, erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p, log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1. -- Steve From nobody Tue Dec 21 17:55:38 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 34C2E1903CED for ; Tue, 21 Dec 2021 17:55:57 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JJPJX5HBzz4hSn for ; Tue, 21 Dec 2021 17:55:56 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id b13so26622737edd.8 for ; Tue, 21 Dec 2021 09:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=IMHE87UFn6DeaTO05/abLowDUhW1zwj5E0+4MbaC0L0=; b=fvtMqwFPXfPzn1Wld7fpx7AJeFEkktAQrXzxNpvtY3BuCaFB8et1cie1F1L+qfARsb wyOzLsHtZmhJnVEXcuhynRov2P1rMUl3f7iZL2b5zr8TVh1575dYF/QycdUmSp4kzOYk arUieIDdVzY1ZqOMxjZl2dClvzaPG6rPpYIgS/dK3indmQRue6DXLJH3RqX/K65hAcfV kzV8eGfog0CZukeowsDrk1aLsU+mXw/2BEZK138JpZwQ++9dJwgtl8/UwkFrG26UVdLv Vn01zpexiTEe1DgxQY9vevY7VIzV4Ew+rVjrbQfAOPuTz4+ptpci0NsaCRP/J2Wg+47E YRsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=IMHE87UFn6DeaTO05/abLowDUhW1zwj5E0+4MbaC0L0=; b=Bb8htG8nJp8oUjLk6t5OPiXNFEFfs/h4WMvHvlKMmjcN2AxoSXOb2WxqV7UqOjn7BC Bs7CsqcM2r7cXIi87Jye2knLUOqBGcC7Fsc09P4pUEXbLL4StFsfOuw7BDyl5DCK2FGC Qh0bumSOuxi7shSgh46EfzLkVwC27MNPjl7j6jhgO/mpuwXk1bBkmwEPka8AHQKaF3lq WKhDg1Rxsk0S0l+ThVp6rVxM6V/galnOJrTZihdsaWTjeBBfpadCOEdJIZ4RNkmENbZ3 eSK24UPFj5aJpnn6P+wqq01nq0WfDkPpvX0WjD3aGdqUcn4kn8fsT3Kg+OZwsf6sWZQJ tXPQ== X-Gm-Message-State: AOAM531wAKUPsTgmOUfMtwIQbmqCX9hx/DEYF6x/TcSIeVyYuNV8O3so p+E84ceKcyNmUKuo19srChr22YAhrTA= X-Google-Smtp-Source: ABdhPJysZY6C5G0Cmvdg8rwEULPwRGFkacoo8EWLPt0QczrYnY36480QHhw2pAyk4/ckFqh2It7ldw== X-Received: by 2002:a05:6402:26c5:: with SMTP id x5mr1146344edd.223.1640109350628; Tue, 21 Dec 2021 09:55:50 -0800 (PST) Received: from fbsd.home (host-95-237-18-203.retail.telecomitalia.it. [95.237.18.203]) by smtp.gmail.com with ESMTPSA id sg39sm6730045ejc.66.2021.12.21.09.55.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Dec 2021 09:55:50 -0800 (PST) Date: Tue, 21 Dec 2021 18:55:38 +0100 From: Alfonso Siciliano To: hackers@freebsd.org Subject: Call for testing libbsddialog Message-Id: <20211221185538.2fe5c33659f450f308fabf68@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JJPJX5HBzz4hSn X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fvtMqwFP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alfix86@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=alfix86@gmail.com X-Spamd-Result: default: False [0.51 / 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)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.987]; RECEIVED_SPAMHAUS_PBL(0.00)[95.237.18.203:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[0.999]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, Currently an effort to replace LGPL libdialog with a permissive alternative is in progress. So far we are using (testing) in CURRENT some feature via tzsetup, kbdmap, devel/bsddialog (utility) and port-mgmt/portconfig; thanks to bapt@ for ports, reviews and commits. This is a call for testing, isolation test with debug symbols: % git clone https://gitlab.com/alfix/bsddialog.git % cd bsddialog/ % git clone https://gitlab.com/alfix/freebsd-lab.git % cd freebsd-lab/bsdinstall/partedit/ % make -DDEBUG % ./sade To check: - Forms: and - ZFS Thank you in advance. Best regards, Alfonso --- Alfonso S. Siciliano http://alfonsosiciliano.gitlab.io From nobody Fri Dec 24 13:08:08 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A08FC1913195; Fri, 24 Dec 2021 13:08:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JL6n73d0Mz3kjN; Fri, 24 Dec 2021 13:08:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0285F27152; Fri, 24 Dec 2021 13:08:10 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> Date: Fri, 24 Dec 2021 15:08:08 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Content-Language: en-US To: FreeBSD Current , FreeBSD Hackers From: Andriy Gapon Subject: schedgraph.d experience, per-CPU buffers, pipes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640351291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ukPiNy1UwYaPjiemcRS5XSKrwtDEydPuax1eH3ax+E4=; b=n5bKNtGfvCOCPNBZDkntZURk9X9pwCpjTtocm/t9x/2YGoqjTIFTqcIAj6FKflM6X8xwWt gD6pN+66wGCVPW/SM/LeuhB7W6VrK/jYLv0Sv/NkzQGN3FgjYskMxMvtDpfWIdXol1KARt vBAm9FjimV9PgBysNqeHONGY6FcKQRe+jSMcavU3Y90QRxZCfI/1ofc4fKZUZLrko1U6/H 5hQBX09Zyoy3yGz8Ys+86o982rLguA4/lkTaJ0PLZo3Ga/lz47FFvYfXfMJ2wgyXlRssjH PTbX4NoelMiIYw5qfXld0Y7GphMxfxSL7MnSEkhFR2k62mjor7KRVB6GFuDtTA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640351291; a=rsa-sha256; cv=none; b=hk7rDkwr3MrN3Oe59bi4t0eJMuNAQtHj2Eqb97+Lca2OWTqN8jzMkQdXKaZLOLAlcNIqJq TrVhU+pbwzSeNirZ1ygaRaYfB59EpNhc5CRQQ43BazyXZ3Z9iaHVwAoXusEkUr3I8VVXFz 882YEezSdA5Rf2vkiqWSYrBME3uLIHqhuBFaDSbYmkJfoFPL1W2/aQGVokQdYYY4LF1bju uz9ZzgIhoKypPencyHYzu/b4C5rAD1IOkrft+/zHXCHsfJHU41P0kXycwzmIbvE6hEO3Bu F6RTzcBX5r0/3mJKL7l6XbibYdAleHG0djocV/QeLXPob3mbxpvxhSQPCGMMJA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N I would like to share some experience or maybe rather a warning about using DTrace for tracing scheduling events. Unlike KTR which has a global circular buffer, DTrace with bufpolicy=ring uses per-CPU circular buffers. So, if there is an asymmetry in processor load, the buffers will fill and wrap-around at different speeds. In the end, they might have approximately equal numbers of events but those may cover very different time intervals. So, some additional post-processing is required to find the latest event among first ones of each per-CPU buffer. Any traces from before that would have information gaps ("missing" processors) and would be very confusing. Also, I noticed that processes passing a lot of data through pipes produce a lot of scheduling events as they seem to get blocked and unlocked every few microseconds (on a modern performant system with the default pipe sizing configuration). That contributes to a quick wrap-around of circular buffers. -- Andriy Gapon From nobody Fri Dec 24 14:40:52 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A9BDF1905152; Fri, 24 Dec 2021 14:41:02 +0000 (UTC) (envelope-from marc@blackend.org) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JL8rF6H27z4SR4; Fri, 24 Dec 2021 14:41:01 +0000 (UTC) (envelope-from marc@blackend.org) Received: from emphyrio.blackend.org (unknown [82.64.86.146]) by smtp1-g21.free.fr (Postfix) with ESMTPS id B1D6CB004FF; Fri, 24 Dec 2021 15:40:53 +0100 (CET) Received: from emphyrio.blackend.org (localhost [127.0.0.1]) by emphyrio.blackend.org (8.16.1/8.16.1) with ESMTPS id 1BOEeruS001203 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 24 Dec 2021 15:40:53 +0100 (CET) (envelope-from marc@emphyrio.blackend.org) Received: (from marc@localhost) by emphyrio.blackend.org (8.16.1/8.16.1/Submit) id 1BOEeqfY001202; Fri, 24 Dec 2021 15:40:52 +0100 (CET) (envelope-from marc) Date: Fri, 24 Dec 2021 15:40:52 +0100 From: Marc Fonvieille To: Steve Kargl Cc: Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: What to do about tgammal? Message-ID: Mail-Followup-To: Steve Kargl , Mark Murray , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org References: <20211214215106.GA50381@troutmask.apl.washington.edu> <20211218035222.GA68916@troutmask.apl.washington.edu> <6C888EBF-1734-4EDC-8DBF-D2BA2454C37D@FreeBSD.org> <20211218175151.GA71197@troutmask.apl.washington.edu> <8011E549-1DEE-4B1B-BCC9-4604E155F4DC@FreeBSD.org> <20211221004819.GA79153@troutmask.apl.washington.edu> <20211221164749.GA81666@troutmask.apl.washington.edu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211221164749.GA81666@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4JL8rF6H27z4SR4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of marc@blackend.org has no SPF policy when checking 2a01:e0c:1:1599::10) smtp.mailfrom=marc@blackend.org X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[marc]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[blackend@freebsd.org,marc@blackend.org]; RECEIVED_SPAMHAUS_PBL(0.00)[82.64.86.146:received]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[blackend@freebsd.org,marc@blackend.org] X-ThisMailContainsUnwantedMimeParts: N Le 21.12.2021 08:47, Steve Kargl a écrit : > Not at the moment. tlibm only handles math functions with > a single real agrument [1]. I've been thinking about adding > the 2 argument functions such as atan2 and complex argument > function, but lack the time. I also need to improve the man > page to decoment the default domain for each function and its > complete domain. > > [1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf, > erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p, > log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1. > No problem. It's a great project. Keep up posting about your progress. -- Marc From nobody Fri Dec 24 15:31:29 2021 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D4DBE191000B for ; Fri, 24 Dec 2021 15:31:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) by mx1.freebsd.org (Postfix) with ESMTP id 4JL9yc6BSnz4cdw; Fri, 24 Dec 2021 15:31:36 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p4fc4c12a.dip0.t-ipconnect.de [79.196.193.42]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id 1BOFVTu6037020; Fri, 24 Dec 2021 15:31:30 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 1BOFVOnr049062; Fri, 24 Dec 2021 16:31:24 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.16.1/8.16.1) with ESMTP id 1BOFVTKv003800; Fri, 24 Dec 2021 16:31:30 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <202112241531.1BOFVTKv003800@fire.js.berklix.net> To: Kyle Evans cc: "freebsd-hackers@freebsd.org" Subject: Re: /boot/loader.conf debuging traces come out jumbled From: "Julian H. Stacey" Organization: http://berklix.com/jhs/ User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Mon, 13 Dec 2021 18:17:52 -0600." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3798.1640359889.1@fire.js.berklix.net> Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Dec 2021 16:31:29 +0100 X-Rspamd-Queue-Id: 4JL9yc6BSnz4cdw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 144.76.10.75) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jhs]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:144.76.0.0/16, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[79.196.193.42:received] X-ThisMailContainsUnwantedMimeParts: N Hi, Reference: > From: Kyle Evans > Date: Mon, 13 Dec 2021 18:17:52 -0600 Kyle Evans wrote: > On Mon, Dec 13, 2021 at 6:07 PM Julian H. Stacey wrote= : > > > > Debugging my /boot/loader.conf on 12.2-STABLE (with a 12.2-RELEASE ker= nel, > > > > (as 12.2-STABLE & 12.3-RELEASE & 13.0-RELEASE GENERIC kernels crash = during > > boot on one machine here (To be subject of later analysis & > > posting)... I got distracted onto debugging boot options, after > > output from booting screen rolled off the top), So I concentrated > > first on identifying & hashing out noisey boot options , before > > next searching how to capture boot text (maybe to a serial port ?) = ) > > > > I tried adding markers to loader.conf create deliberate visible error = texts to > > mark around lines I wanted to study the effect of, eg > > fuse_load=3D"YES" etc ... > > > > I added this in the middle of /boot/loader.conf : > > ZZZZZZZZZ00000000_load=3D"YES" > > ZZZZZZZZZ00001111_load=3D"YES" > > ZZZZZZZZZ00002222_load=3D"YES" > > ZZZZZZZZZ44440000_load=3D"YES" > > ZZZZZZZZZ44441111_load=3D"YES" > > ZZZZZZZZZ44442222_load=3D"YES" > > > > & next boot showed a weirdly disordered: > > > > Loading configured modules... > > can't find 'ZZZZZZZZZ00000000_load' > > can't find 'ZZZZZZZZZ00002222_load' > > can't find 'ZZZZZZZZZ44442222_load' > > can't find 'ZZZZZZZZZ44440000_load' > > can't find 'ZZZZZZZZZ44441111_load' > > can't find 'ZZZZZZZZZ00001111_load' > > /etc/hostid size=3D0x25 > > > > its not even just a reverse order that one might have expected from > > a forth unstacker or some such. Makes it harder to trace what output > > lines come from which loader.conf lines. > > > > To my knowledge, we've never guaranteed module load order beyond > kernel-first then everything else. You'll have a much better time with > _before/_after though; something like this should work: > > hostid_before=3D"echo before hostid" > hostid_after=3D"echo after hostid" Thanks Kyle for your _before & _after, it set me on course, though there's no hostid_load=3D in 12.2 src/, these worked: usb_quirk_load=3D"YES" usb_quirk_before=3D"echo Before usb_quirk" usb_quirk_after=3D"echo After usb_quirk" & I found lots of useful debugging stuff in /boot/defaults/loader.conf & man loader.conf loader boot. My next use will be boot -p or boot_pause=3D"" # -p: Pause after each line during device probing & then maybe some of: #boot_ddb=3D"" # -d: Instructs the kernel to start in the DDB debug= ger #boot_gdb=3D"" # -g: Selects gdb-remote mode for the kernel debugge= r #boot_multicons=3D"" # -D: Use multiple consoles #boot_serial=3D"" # -h: Use serial console #boot_verbose=3D"" # -v: Causes extra debugging information to be print= ed #debug.kdb.break_to_debugger=3D"0" # Allow console to break into debugger. Looking forward to debugging now screen doesnt roll off :-) Cheers, -- = Julian Stacey http://berklix.com/jhs/ http://stolenvotes.uk Reduce contacts, vax & pass insufficient. Dump UK's prime liar. From nobody Fri Dec 24 18:38:26 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 127C219005BC for ; Fri, 24 Dec 2021 18:38:38 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JLG6P3Hlcz3Dng for ; Fri, 24 Dec 2021 18:38:37 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-vk1-xa2c.google.com with SMTP id j4so2555371vkr.12 for ; Fri, 24 Dec 2021 10:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=5XX5S4mTrOaDgwGBNd8OaA8iZIuAxfZzlQKwTPFyEt4=; b=NjnsxkmtyQp7W2g4YUyPC/rxlEj9RLdmY8nI3vQmShZv8r+ofiGL7PTO1A/OycYiYz sRklo+4DyRC9RpwlrAzzL1uMVKjwmxWRAPRqXXDf4oWjaGyKIPI2ssnLNFfsERvbWqe7 cveprE4h7POdiRWYQ+yejmQS1OH364x95ueraPGt7m3cf/ZXxmNTRKayZEIDMXABsTEX OUXi8k/KfEvsE3PGaAcBV+otRvy+/yfGJjTDgn7w9YBzUWzByGAP7SnQYWKFskMcgSMr zv3w1F0lRzUVMQoDF72i6LJWyv4Tt3vCBRXDpwb/iM/1uAv/gBpqn8vWbmfTxRFmD32j Mo+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=5XX5S4mTrOaDgwGBNd8OaA8iZIuAxfZzlQKwTPFyEt4=; b=IrBPCDiubiVCjIR/IjZBQmdwro9p9jd+OjZtADZcIh/Di5Bsuv3za5mb9yWEBUY45W 0LNU2saWEnsVUuEWWTONUh8PyEd+VOeO3WzSyuiEyAxggB0xUvIGih6caT7UDBIHB8VJ gFm1oyTRz7G2/xWwfSGsScx6782davTdiXISYILe3M4s4qdzVF6iHof+vaarmZLp5YA5 8W3sCLHEAyEA5u7ikVUCSQobt+KslCHmVNiXPgiUmLim+M4rR7A35ybUg3jKlNolBGnk nes3iIWc31QgleneSvwBG1N58DIAkd85u16ZSqSmnhhPFBcvg2N83XTgkoyHwTtHi8Tp fVaA== X-Gm-Message-State: AOAM530GRFgPe9tmKzdBCfZdORFkTVEZNE92aBxCxzOVvuGWhnaCOaMU 7sHjAr5uu6l327NXKASFSgzeEmZvHqUhCZicoJLkWM1mF1A= X-Google-Smtp-Source: ABdhPJxtRk0WsVkOUmMKBa7C+n5E0wgWkDekk/ca6kslJkauuFchVeJh0jrERRRqkRYtYfZ7zjMABzOdiTlbeolNAT8= X-Received: by 2002:a1f:bf8d:: with SMTP id p135mr2465050vkf.16.1640371116824; Fri, 24 Dec 2021 10:38:36 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Fri, 24 Dec 2021 21:38:26 +0300 Message-ID: Subject: how to gett iflib queue - nic queue assignment list To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JLG6P3Hlcz3Dng X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Njnsxkmt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::a2c as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-1.77 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.995]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from]; NEURAL_HAM_SHORT(-0.78)[-0.778]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hello, I've sent this email also freebsd-net mail list 6 days ago. Sorry for asking again. I'm using freebsd stable/12. top shows the iflib queues as below: 0 root -92 - 0B 3872K CPU18 18 199.1H 100.00% [kernel{if_io_tqg_18}] 0 root -92 - 0B 3872K CPU22 22 228.4H 97.95% [kernel{if_io_tqg_22}] 0 root -92 - 0B 3872K CPU16 16 226.7H 55.63% [kernel{if_io_tqg_16}] 0 root -92 - 0B 3872K CPU20 20 208.4H 53.25% [kernel{if_io_tqg_20}] 0 root -92 - 0B 3872K CPU12 12 764.7H 14.24% [kernel{if_io_tqg_12}] Is there a way to lookup if_io_tqg_XX belongs to which nic's which queue (such as ix0, queue2) ? Before the iflib, top shows the driver's name. Regards =C3=96zkan From nobody Mon Dec 27 12:39:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 997D11921C08 for ; Mon, 27 Dec 2021 12:39:31 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JMy0d0CYzz3q1l for ; Mon, 27 Dec 2021 12:39:28 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 26361 invoked by uid 907); 27 Dec 2021 12:39:18 -0000 Received: from i5E86400D.versanet.de (HELO smtpclient.apple) (94.134.64.13) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Mon, 27 Dec 2021 23:39:18 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: closefrom blocking, wchan urdlck Message-Id: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> Date: Mon, 27 Dec 2021 13:39:11 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JMy0d0CYzz3q1l X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of janm@transactionware.com has no SPF policy when checking 203.14.245.7) smtp.mailfrom=janm@transactionware.com X-Spamd-Result: default: False [-0.86 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.37)[-0.365]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, (On 11.2) I am occasionally seeing closefrom() block in a child process created by = a call to pdfork(). When this does happen, it is very early after the process has started, = while other threads are being created elsewhere in the process. I cannot = reproduce it after the thread creation is complete. According to the = sigaction man page, this should be async signal safe. Stack trace from the call to closefrom(): * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at = _umtx_op_err.S:37 frame #1: 0x00000008008f6121 = libthr.so.3`__thr_rwlock_rdlock(rwlock=3D, = flags=3D, tsp=3D) at thr_umtx.c:307:10 frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire = [inlined] _thr_rwlock_rdlock(rwlock=3D0x0000000800911600, flags=3D0, = tsp=3D0x0000000000000000) at thr_umtx.h:232:10 frame #3: 0x00000008008ff19b = libthr.so.3`_thr_rtld_rlock_acquire(lock=3D0x0000000800911600) at = thr_rtld.c:125 frame #4: 0x000000080075332b = ld-elf.so.1`rlock_acquire(lock=3D0x0000000800765270, = lockstate=3D0x00007fffdfbfb8d0) at rtld_lock.c:208:2 frame #5: 0x000000080074ba20 = ld-elf.so.1`_rtld_bind(obj=3D0x0000000800769000, reloff=3D6072) at = rtld.c:861:5 frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at = rtld_start.S:121 frame #7: 0x00000000006562d3 = prog`Twio::ProcHandle::spawn(this=3D, command=3D"/bin/echo", = args=3D0x0000000800d7e000, descriptor_mapping=3D, = descriptor_end=3D3) at prochandle_pdfork.cpp:308:2 Any suggestions on how to approach this? Regards, Jan M. From nobody Mon Dec 27 13:52:13 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D65A1905D79 for ; Mon, 27 Dec 2021 13:52:25 +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 4JMzcm5fjpz4Sd3 for ; Mon, 27 Dec 2021 13:52:24 +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 1BRDqGfq015459 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 15:52:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BRDqGfq015459 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BRDqDqe015458; Mon, 27 Dec 2021 15:52:13 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Dec 2021 15:52:13 +0200 From: Konstantin Belousov To: Jan Mikkelsen Cc: freebsd-hackers@freebsd.org Subject: Re: closefrom blocking, wchan urdlck Message-ID: References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> 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: 4JMzcm5fjpz4Sd3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: > Hi, > > (On 11.2) > > I am occasionally seeing closefrom() block in a child process created by a call to pdfork(). > > When this does happen, it is very early after the process has started, while other threads are being created elsewhere in the process. I cannot reproduce it after the thread creation is complete. According to the sigaction man page, this should be async signal safe. > > Stack trace from the call to closefrom(): > > * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at _umtx_op_err.S:37 > frame #1: 0x00000008008f6121 libthr.so.3`__thr_rwlock_rdlock(rwlock=, flags=, tsp=) at thr_umtx.c:307:10 > frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire [inlined] _thr_rwlock_rdlock(rwlock=0x0000000800911600, flags=0, tsp=0x0000000000000000) at thr_umtx.h:232:10 > frame #3: 0x00000008008ff19b libthr.so.3`_thr_rtld_rlock_acquire(lock=0x0000000800911600) at thr_rtld.c:125 > frame #4: 0x000000080075332b ld-elf.so.1`rlock_acquire(lock=0x0000000800765270, lockstate=0x00007fffdfbfb8d0) at rtld_lock.c:208:2 > frame #5: 0x000000080074ba20 ld-elf.so.1`_rtld_bind(obj=0x0000000800769000, reloff=6072) at rtld.c:861:5 > frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at rtld_start.S:121 > frame #7: 0x00000000006562d3 prog`Twio::ProcHandle::spawn(this=, command="/bin/echo", args=0x0000000800d7e000, descriptor_mapping=, descriptor_end=3) at prochandle_pdfork.cpp:308:2 And where is the closefrom() call in the demonstrated trace? What version of the system do you use? You need at least cbdec8db18b533f6d7be (on HEAD) or a5659943e37a74c96e (stable/13) for pdfork() to behave sanely. But you still not allowed to call non-async signal safe functions in the child before exec. From nobody Mon Dec 27 14:54:57 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C66711911D31 for ; Mon, 27 Dec 2021 14:55:06 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JN1160vPxz4d0m for ; Mon, 27 Dec 2021 14:55:05 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 38636 invoked by uid 907); 27 Dec 2021 14:55:03 -0000 Received: from i5E86400D.versanet.de (HELO smtpclient.apple) (94.134.64.13) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Tue, 28 Dec 2021 01:55:03 +1100 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: closefrom blocking, wchan urdlck From: Jan Mikkelsen In-Reply-To: Date: Mon, 27 Dec 2021 15:54:57 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JN1160vPxz4d0m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 27 Dec 2021, at 14:52, Konstantin Belousov = wrote: >=20 > On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: >> Hi, >>=20 >> (On 11.2) >>=20 >> I am occasionally seeing closefrom() block in a child process created = by a call to pdfork(). >>=20 >> When this does happen, it is very early after the process has = started, while other threads are being created elsewhere in the process. = I cannot reproduce it after the thread creation is complete. According = to the sigaction man page, this should be async signal safe. >>=20 >> Stack trace from the call to closefrom(): >>=20 >> * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at = _umtx_op_err.S:37 >> frame #1: 0x00000008008f6121 = libthr.so.3`__thr_rwlock_rdlock(rwlock=3D, = flags=3D, tsp=3D) at thr_umtx.c:307:10 >> frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire = [inlined] _thr_rwlock_rdlock(rwlock=3D0x0000000800911600, flags=3D0, = tsp=3D0x0000000000000000) at thr_umtx.h:232:10 >> frame #3: 0x00000008008ff19b = libthr.so.3`_thr_rtld_rlock_acquire(lock=3D0x0000000800911600) at = thr_rtld.c:125 >> frame #4: 0x000000080075332b = ld-elf.so.1`rlock_acquire(lock=3D0x0000000800765270, = lockstate=3D0x00007fffdfbfb8d0) at rtld_lock.c:208:2 >> frame #5: 0x000000080074ba20 = ld-elf.so.1`_rtld_bind(obj=3D0x0000000800769000, reloff=3D6072) at = rtld.c:861:5 >> frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at = rtld_start.S:121 >> frame #7: 0x00000000006562d3 = prog`Twio::ProcHandle::spawn(this=3D, command=3D"/bin/echo", = args=3D0x0000000800d7e000, descriptor_mapping=3D, = descriptor_end=3D3) at prochandle_pdfork.cpp:308:2 > And where is the closefrom() call in the demonstrated trace? >=20 > What version of the system do you use? > You need at least cbdec8db18b533f6d7be (on HEAD) or a5659943e37a74c96e > (stable/13) for pdfork() to behave sanely. But you still not allowed = to > call non-async signal safe functions in the child before exec. This is 12.2-p11. I just noticed that I wrote 11.2 above, that is = incorrect. Frame 7 is a call to closefrom(). The child process calls dup2(), = closefrom(), signal() and then execv(). No other calls are made, and I = believe closefrom() is meant to be async signal safe. The commit you can apply cleanly to 12.2, I=E2=80=99m running a build = now. Are there other issues with pdfork in 12.2? Regards, Jan M. From nobody Mon Dec 27 15:03:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D7D3D1913FA3 for ; Mon, 27 Dec 2021 15:03:36 +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 4JN1Bw4DWgz4fFK for ; Mon, 27 Dec 2021 15:03:36 +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 1BRF3Tw9032757 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 17:03:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BRF3Tw9032757 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BRF3TSg032756; Mon, 27 Dec 2021 17:03:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Dec 2021 17:03:29 +0200 From: Konstantin Belousov To: Jan Mikkelsen Cc: freebsd-hackers@freebsd.org Subject: Re: closefrom blocking, wchan urdlck Message-ID: References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JN1Bw4DWgz4fFK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 03:54:57PM +0100, Jan Mikkelsen wrote: > > > On 27 Dec 2021, at 14:52, Konstantin Belousov wrote: > > > > On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: > >> Hi, > >> > >> (On 11.2) > >> > >> I am occasionally seeing closefrom() block in a child process created by a call to pdfork(). > >> > >> When this does happen, it is very early after the process has started, while other threads are being created elsewhere in the process. I cannot reproduce it after the thread creation is complete. According to the sigaction man page, this should be async signal safe. > >> > >> Stack trace from the call to closefrom(): > >> > >> * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at _umtx_op_err.S:37 > >> frame #1: 0x00000008008f6121 libthr.so.3`__thr_rwlock_rdlock(rwlock=, flags=, tsp=) at thr_umtx.c:307:10 > >> frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire [inlined] _thr_rwlock_rdlock(rwlock=0x0000000800911600, flags=0, tsp=0x0000000000000000) at thr_umtx.h:232:10 > >> frame #3: 0x00000008008ff19b libthr.so.3`_thr_rtld_rlock_acquire(lock=0x0000000800911600) at thr_rtld.c:125 > >> frame #4: 0x000000080075332b ld-elf.so.1`rlock_acquire(lock=0x0000000800765270, lockstate=0x00007fffdfbfb8d0) at rtld_lock.c:208:2 > >> frame #5: 0x000000080074ba20 ld-elf.so.1`_rtld_bind(obj=0x0000000800769000, reloff=6072) at rtld.c:861:5 > >> frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at rtld_start.S:121 > >> frame #7: 0x00000000006562d3 prog`Twio::ProcHandle::spawn(this=, command="/bin/echo", args=0x0000000800d7e000, descriptor_mapping=, descriptor_end=3) at prochandle_pdfork.cpp:308:2 > > And where is the closefrom() call in the demonstrated trace? > > > > What version of the system do you use? > > You need at least cbdec8db18b533f6d7be (on HEAD) or a5659943e37a74c96e > > (stable/13) for pdfork() to behave sanely. But you still not allowed to > > call non-async signal safe functions in the child before exec. > > > This is 12.2-p11. I just noticed that I wrote 11.2 above, that is incorrect. > > Frame 7 is a call to closefrom(). The child process calls dup2(), closefrom(), signal() and then execv(). No other calls are made, and I believe closefrom() is meant to be async signal safe. > Frame 7 cannot be a call to closefrom(), it would be resolved to closefrom() symbol would it be. > The commit you can apply cleanly to 12.2, I’m running a build now. Are there other issues with pdfork in 12.2? pdfork() with threading processes requires 21f749da82e755aafab1276 and the followup cbdec8db18b533f6d7be. I do not believe any of this is in 12.3, and definitely not in 12.2. From nobody Mon Dec 27 15:13:50 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D9A7419162A8 for ; Mon, 27 Dec 2021 15:13:58 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JN1Qt1LFnz4gkd for ; Mon, 27 Dec 2021 15:13:57 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 39809 invoked by uid 907); 27 Dec 2021 15:13:56 -0000 Received: from i5E86400D.versanet.de (HELO smtpclient.apple) (94.134.64.13) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Tue, 28 Dec 2021 02:13:56 +1100 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: closefrom blocking, wchan urdlck From: Jan Mikkelsen In-Reply-To: Date: Mon, 27 Dec 2021 16:13:50 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9CB0803A-E15B-47F9-97A9-03597D41C01E@transactionware.com> References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JN1Qt1LFnz4gkd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 27 Dec 2021, at 16:03, Konstantin Belousov = wrote: >=20 > On Mon, Dec 27, 2021 at 03:54:57PM +0100, Jan Mikkelsen wrote: >>=20 >>> On 27 Dec 2021, at 14:52, Konstantin Belousov = wrote: >>>=20 >>> On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: >>>> Hi, >>>>=20 >>>> (On 11.2) >>>>=20 >>>> I am occasionally seeing closefrom() block in a child process = created by a call to pdfork(). >>>>=20 >>>> When this does happen, it is very early after the process has = started, while other threads are being created elsewhere in the process. = I cannot reproduce it after the thread creation is complete. According = to the sigaction man page, this should be async signal safe. >>>>=20 >>>> Stack trace from the call to closefrom(): >>>>=20 >>>> * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at = _umtx_op_err.S:37 >>>> frame #1: 0x00000008008f6121 = libthr.so.3`__thr_rwlock_rdlock(rwlock=3D, = flags=3D, tsp=3D) at thr_umtx.c:307:10 >>>> frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire = [inlined] _thr_rwlock_rdlock(rwlock=3D0x0000000800911600, flags=3D0, = tsp=3D0x0000000000000000) at thr_umtx.h:232:10 >>>> frame #3: 0x00000008008ff19b = libthr.so.3`_thr_rtld_rlock_acquire(lock=3D0x0000000800911600) at = thr_rtld.c:125 >>>> frame #4: 0x000000080075332b = ld-elf.so.1`rlock_acquire(lock=3D0x0000000800765270, = lockstate=3D0x00007fffdfbfb8d0) at rtld_lock.c:208:2 >>>> frame #5: 0x000000080074ba20 = ld-elf.so.1`_rtld_bind(obj=3D0x0000000800769000, reloff=3D6072) at = rtld.c:861:5 >>>> frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at = rtld_start.S:121 >>>> frame #7: 0x00000000006562d3 = prog`Twio::ProcHandle::spawn(this=3D, command=3D"/bin/echo", = args=3D0x0000000800d7e000, descriptor_mapping=3D, = descriptor_end=3D3) at prochandle_pdfork.cpp:308:2 >>> And where is the closefrom() call in the demonstrated trace? >>>=20 >>> What version of the system do you use? >>> You need at least cbdec8db18b533f6d7be (on HEAD) or = a5659943e37a74c96e >>> (stable/13) for pdfork() to behave sanely. But you still not = allowed to >>> call non-async signal safe functions in the child before exec. >>=20 >>=20 >> This is 12.2-p11. I just noticed that I wrote 11.2 above, that is = incorrect. >>=20 >> Frame 7 is a call to closefrom(). The child process calls dup2(), = closefrom(), signal() and then execv(). No other calls are made, and I = believe closefrom() is meant to be async signal safe. >>=20 > Frame 7 cannot be a call to closefrom(), it would be resolved to = closefrom() > symbol would it be. =46rom lldb, attached to the hung process: (lldb)=20 frame #6: 0x0000000800748c7d ld-elf.so.1`_rtld_bind_start at = rtld_start.S:121 118 leaq (%rsi,%rsi,2),%rsi # multiply by 3 119 leaq (,%rsi,8),%rsi # now 8, for 24 (sizeof = Elf_Rela) 120 =09 -> 121 call _rtld_bind # Transfer control to = the binder 122 /* Now %rax contains the entry point of the function = being called. */ 123 =09 124 movq %rax,0x60(%rsp) # Store target over = reloff argument (lldb)=20 frame #7: 0x0000000000656813 = amt5-chefd`Twio::ProcHandle::spawn(this=3D, = command=3D"/bin/date", args=3D0x0000000800d5f010, = descriptor_mapping=3D, descriptor_end=3D3) at = prochandle_pdfork.cpp:304:2 301 _exit(127); 302 } 303 =09 -> 304 closefrom(descriptor_end); 305 =09 306 signal(SIGPIPE, SIG_DFL); 307 signal(SIGALRM, SIG_DFL); (lldb)=20 >> The commit you can apply cleanly to 12.2, I=E2=80=99m running a build = now. Are there other issues with pdfork in 12.2? >=20 > pdfork() with threading processes requires 21f749da82e755aafab1276 and = the > followup cbdec8db18b533f6d7be. I do not believe any of this is in = 12.3, > and definitely not in 12.2. Thanks, will check and apply. Regards, Jan M. From nobody Mon Dec 27 15:19:16 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 977721917B1F for ; Mon, 27 Dec 2021 15:19:23 +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 4JN1Y72Llpz4j50 for ; Mon, 27 Dec 2021 15:19:23 +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 1BRFJGg7036509 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 17:19:19 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BRFJGg7036509 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BRFJGxp036508; Mon, 27 Dec 2021 17:19:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 27 Dec 2021 17:19:16 +0200 From: Konstantin Belousov To: Jan Mikkelsen Cc: freebsd-hackers@freebsd.org Subject: Re: closefrom blocking, wchan urdlck Message-ID: References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> <9CB0803A-E15B-47F9-97A9-03597D41C01E@transactionware.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9CB0803A-E15B-47F9-97A9-03597D41C01E@transactionware.com> 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: 4JN1Y72Llpz4j50 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 27, 2021 at 04:13:50PM +0100, Jan Mikkelsen wrote: > > > > On 27 Dec 2021, at 16:03, Konstantin Belousov wrote: > > > > On Mon, Dec 27, 2021 at 03:54:57PM +0100, Jan Mikkelsen wrote: > >> > >>> On 27 Dec 2021, at 14:52, Konstantin Belousov wrote: > >>> > >>> On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: > >>>> Hi, > >>>> > >>>> (On 11.2) > >>>> > >>>> I am occasionally seeing closefrom() block in a child process created by a call to pdfork(). > >>>> > >>>> When this does happen, it is very early after the process has started, while other threads are being created elsewhere in the process. I cannot reproduce it after the thread creation is complete. According to the sigaction man page, this should be async signal safe. > >>>> > >>>> Stack trace from the call to closefrom(): > >>>> > >>>> * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at _umtx_op_err.S:37 > >>>> frame #1: 0x00000008008f6121 libthr.so.3`__thr_rwlock_rdlock(rwlock=, flags=, tsp=) at thr_umtx.c:307:10 > >>>> frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire [inlined] _thr_rwlock_rdlock(rwlock=0x0000000800911600, flags=0, tsp=0x0000000000000000) at thr_umtx.h:232:10 > >>>> frame #3: 0x00000008008ff19b libthr.so.3`_thr_rtld_rlock_acquire(lock=0x0000000800911600) at thr_rtld.c:125 > >>>> frame #4: 0x000000080075332b ld-elf.so.1`rlock_acquire(lock=0x0000000800765270, lockstate=0x00007fffdfbfb8d0) at rtld_lock.c:208:2 > >>>> frame #5: 0x000000080074ba20 ld-elf.so.1`_rtld_bind(obj=0x0000000800769000, reloff=6072) at rtld.c:861:5 > >>>> frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at rtld_start.S:121 > >>>> frame #7: 0x00000000006562d3 prog`Twio::ProcHandle::spawn(this=, command="/bin/echo", args=0x0000000800d7e000, descriptor_mapping=, descriptor_end=3) at prochandle_pdfork.cpp:308:2 > >>> And where is the closefrom() call in the demonstrated trace? > >>> > >>> What version of the system do you use? > >>> You need at least cbdec8db18b533f6d7be (on HEAD) or a5659943e37a74c96e > >>> (stable/13) for pdfork() to behave sanely. But you still not allowed to > >>> call non-async signal safe functions in the child before exec. > >> > >> > >> This is 12.2-p11. I just noticed that I wrote 11.2 above, that is incorrect. > >> > >> Frame 7 is a call to closefrom(). The child process calls dup2(), closefrom(), signal() and then execv(). No other calls are made, and I believe closefrom() is meant to be async signal safe. > >> > > Frame 7 cannot be a call to closefrom(), it would be resolved to closefrom() > > symbol would it be. > > >From lldb, attached to the hung process: > > (lldb) > frame #6: 0x0000000800748c7d ld-elf.so.1`_rtld_bind_start at rtld_start.S:121 > 118 leaq (%rsi,%rsi,2),%rsi # multiply by 3 > 119 leaq (,%rsi,8),%rsi # now 8, for 24 (sizeof Elf_Rela) > 120 > -> 121 call _rtld_bind # Transfer control to the binder > 122 /* Now %rax contains the entry point of the function being called. */ > 123 > 124 movq %rax,0x60(%rsp) # Store target over reloff argument > (lldb) > frame #7: 0x0000000000656813 amt5-chefd`Twio::ProcHandle::spawn(this=, command="/bin/date", args=0x0000000800d5f010, descriptor_mapping=, descriptor_end=3) at prochandle_pdfork.cpp:304:2 > 301 _exit(127); > 302 } > 303 > -> 304 closefrom(descriptor_end); > 305 > 306 signal(SIGPIPE, SIG_DFL); > 307 signal(SIGALRM, SIG_DFL); > (lldb) Ah, yes, it is rtld trying to resolve the symbol. So yes, the fix is to have the revisions I listed below. I am not sure about prerequisites. > > > >> The commit you can apply cleanly to 12.2, I’m running a build now. Are there other issues with pdfork in 12.2? > > > > pdfork() with threading processes requires 21f749da82e755aafab1276 and the > > followup cbdec8db18b533f6d7be. I do not believe any of this is in 12.3, > > and definitely not in 12.2. > > Thanks, will check and apply. > > Regards, > > Jan M. > From nobody Tue Dec 28 09:49:11 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4380E1903DD7 for ; Tue, 28 Dec 2021 09:49:22 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JNV9s45Crz3JYd for ; Tue, 28 Dec 2021 09:49:21 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 5852 invoked by uid 907); 28 Dec 2021 09:49:17 -0000 Received: from i5E86407B.versanet.de (HELO smtpclient.apple) (94.134.64.123) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Tue, 28 Dec 2021 20:49:17 +1100 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: closefrom blocking, wchan urdlck From: Jan Mikkelsen In-Reply-To: Date: Tue, 28 Dec 2021 10:49:11 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B3BA665-D42A-4B5F-AD2F-ED10E64A7276@transactionware.com> <9CB0803A-E15B-47F9-97A9-03597D41C01E@transactionware.com> To: Konstantin Belousov X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JNV9s45Crz3JYd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 27 Dec 2021, at 16:19, Konstantin Belousov = wrote: >=20 > On Mon, Dec 27, 2021 at 04:13:50PM +0100, Jan Mikkelsen wrote: >>=20 >>=20 >>> On 27 Dec 2021, at 16:03, Konstantin Belousov = wrote: >>>=20 >>> On Mon, Dec 27, 2021 at 03:54:57PM +0100, Jan Mikkelsen wrote: >>>>=20 >>>>> On 27 Dec 2021, at 14:52, Konstantin Belousov = wrote: >>>>>=20 >>>>> On Mon, Dec 27, 2021 at 01:39:11PM +0100, Jan Mikkelsen wrote: >>>>>> Hi, >>>>>>=20 >>>>>> (On 11.2) >>>>>>=20 >>>>>> I am occasionally seeing closefrom() block in a child process = created by a call to pdfork(). >>>>>>=20 >>>>>> When this does happen, it is very early after the process has = started, while other threads are being created elsewhere in the process. = I cannot reproduce it after the thread creation is complete. According = to the sigaction man page, this should be async signal safe. >>>>>>=20 >>>>>> Stack trace from the call to closefrom(): >>>>>>=20 >>>>>> * frame #0: 0x000000080090276c libthr.so.3`_umtx_op_err at = _umtx_op_err.S:37 >>>>>> frame #1: 0x00000008008f6121 = libthr.so.3`__thr_rwlock_rdlock(rwlock=3D, = flags=3D, tsp=3D) at thr_umtx.c:307:10 >>>>>> frame #2: 0x00000008008ff1ac libthr.so.3`_thr_rtld_rlock_acquire = [inlined] _thr_rwlock_rdlock(rwlock=3D0x0000000800911600, flags=3D0, = tsp=3D0x0000000000000000) at thr_umtx.h:232:10 >>>>>> frame #3: 0x00000008008ff19b = libthr.so.3`_thr_rtld_rlock_acquire(lock=3D0x0000000800911600) at = thr_rtld.c:125 >>>>>> frame #4: 0x000000080075332b = ld-elf.so.1`rlock_acquire(lock=3D0x0000000800765270, = lockstate=3D0x00007fffdfbfb8d0) at rtld_lock.c:208:2 >>>>>> frame #5: 0x000000080074ba20 = ld-elf.so.1`_rtld_bind(obj=3D0x0000000800769000, reloff=3D6072) at = rtld.c:861:5 >>>>>> frame #6: 0x0000000800747c7d ld-elf.so.1`_rtld_bind_start at = rtld_start.S:121 >>>>>> frame #7: 0x00000000006562d3 = prog`Twio::ProcHandle::spawn(this=3D, command=3D"/bin/echo", = args=3D0x0000000800d7e000, descriptor_mapping=3D, = descriptor_end=3D3) at prochandle_pdfork.cpp:308:2 >>>>> And where is the closefrom() call in the demonstrated trace? >>>>>=20 >>>>> What version of the system do you use? >>>>> You need at least cbdec8db18b533f6d7be (on HEAD) or = a5659943e37a74c96e >>>>> (stable/13) for pdfork() to behave sanely. But you still not = allowed to >>>>> call non-async signal safe functions in the child before exec. >>>>=20 >>>>=20 >>>> This is 12.2-p11. I just noticed that I wrote 11.2 above, that is = incorrect. >>=20 =E2=80=A6. >>>> The commit you can apply cleanly to 12.2, I=E2=80=99m running a = build now. Are there other issues with pdfork in 12.2? >>>=20 >>> pdfork() with threading processes requires 21f749da82e755aafab1276 = and the >>> followup cbdec8db18b533f6d7be. I do not believe any of this is in = 12.3, >>> and definitely not in 12.2. >>=20 >> Thanks, will check and apply. I can no longer reproduce the problem with these two changes added to a = 12.2 source tree. Thanks! Regards, Jan M. From nobody Wed Dec 29 18:30:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 51BE2190B748 for ; Wed, 29 Dec 2021 18:30:59 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPKjF6dpNz4pjc; Wed, 29 Dec 2021 18:30:57 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wm1-x333.google.com with SMTP id j140-20020a1c2392000000b003399ae48f58so14878462wmj.5; Wed, 29 Dec 2021 10:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UneGw2DE3/sZ+T9iejpQ3FyZp8FRfnwXPMybjjRWIoc=; b=HotTfUljOROqtFjq33CCYe44tNTR+Srp0Blm99TK1nwL1mU5cZgw/ciWeZhG1eobr/ jARHYe9OLuBIYPWBn2kIVVecwFM5szRoggmoLz180I37gCrckELWt5cbNprHrVl6fYFA d4o/fNuJnQb/ATdjuwqoX1HtYAACm4tgIUN/v3iIKQJxJefeF5vVwASmge67CNqF8kib U2lpzqI3j+KgI5OSivTw3t1eMND+vGkYKjhpYEhzvZWIFwCsudwS5qnnpwaoNQRZFUQh iujyJODJUSXf7ICT4CtUM7TgJrD4FpUrEhUcJeKaUFYmvxFLp9ckmXtn1oISughG8hgo 1JqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UneGw2DE3/sZ+T9iejpQ3FyZp8FRfnwXPMybjjRWIoc=; b=PSiE0diDbo0krMkqEcDd4AwIEAx661ePczk7UzHyMjWh84hGYaZTMtyV0iiVe2ED88 llKyQ9yOje+QzzrOJvkieeX39bKhgSPTgbQbvZy18IpIULRkG7AllN4X5zw3yUVAKX5P pmg3IjjFc/gpw/BOhvgrxjNq/NNMADjWiQ/5SVqzGJdrkHeQHbe4VUgtunTDf56uZB4G UuIkVhHD+V+hpc7FxWurVy/O3TAt3U0rQ8Oh9gcCVtfJAbzwn/CLTt2jtsfjIaVbcWWX AfqcZiMXOmenf2/NwIPnkwEc9nEmBjLHN7bwPzvSjuAd+FSsx6bAst0dIA5B3RNWIzdn c7nQ== X-Gm-Message-State: AOAM5306UCHSk7Die9L6OyCI8+JNAmp7GJw1mvZfL/Jys3hxnvonrCgT 0b6vViA0Cu+MDeqMIYu04eoMx5K/a+A= X-Google-Smtp-Source: ABdhPJz29lGMtm1T0ASFRtxFPOtupWtFhO+t9zfQhVX40HnouonQWt0YZEt3n3fKRAzq/0bEP1FURg== X-Received: by 2002:a05:600c:3d10:: with SMTP id bh16mr22902534wmb.111.1640802650990; Wed, 29 Dec 2021 10:30:50 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id 1sm13889664wrb.13.2021.12.29.10.30.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Dec 2021 10:30:50 -0800 (PST) Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> From: Karel Gardas Message-ID: <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> Date: Wed, 29 Dec 2021 19:30:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <861r36xzpe.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JPKjF6dpNz4pjc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=HotTfUlj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gardask@gmail.com designates 2a00:1450:4864:20::333 as permitted sender) smtp.mailfrom=gardask@gmail.com X-Spamd-Result: default: False [-0.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::333:from]; NEURAL_SPAM_LONG(0.99)[0.992]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 11/23/21 11:41 PM, Joseph Mingrone wrote: > Hello FreeBSD community, > > The Foundation is seeking suggestions for new projects to support. What > gaps in the Project are not being addressed by the broader community? sorry for being late with those: 1) implement/port beadm equivalent from Solaris/IlumosOS? Make freebsd-update process more reversible by using proper boot environments and using ZFS snapshots. May be good to also kind of hook freebsd-update and pkg update/upgrade together when required by user to make whole system updates more transactional. 2) not sure, but OpenBSD's pf got some as I would guess Oracle sponsored SMP work and enhancements. Isn't it a time to sync with it? 3) FreeBSD/KDE user hurting: baloo file indexer service is killing FreeBSD 13 when user directory have more than just few thousands of files (think few git clones of few repos). The service (baloo) crashes a lot on FreeBSD 14 so it's not that hurting experience as it is on FreeBSD 13 where it completely freeze system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230726 Thanks, Karel From nobody Wed Dec 29 19:12:29 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3AD051912EBE for ; Wed, 29 Dec 2021 19:12:42 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPLdQ0zM9z4v4J; Wed, 29 Dec 2021 19:12:42 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x12d.google.com with SMTP id g5so17255484ilj.12; Wed, 29 Dec 2021 11:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mcBKPgvE33iIk7UH14BXGvS2ykJScAZ9up9ceRJie34=; b=hFml/OaRlTj4ikOJEHhywd0DNtRgPUPZHLsivoV6yzi5WCvhOdsDBuCbqjRldd4IvO IBMaNRodO4xvhqAiLbBzXjZtC/ZeF+dM5R2YC+wpYdD/ky8hLFq9e0WpyRrv0KEhF6Dm k9cU4+fTpHtXqsmgF19iU4yJlfIhrGD3TPpcbbf5SxyFOCLvvePCyobHebmgAUMXwyov 0cwHKVBZyHQUsZ4uZwu15+wHYpaiH1kW9LHe7+Pz6ntsCM+VLeVdt/vjA/yX0hEdfAoP uDLe6SHFUfHNHHcQ8Gfej7lLKjcx5QhMZHsP5o1maUU1rIbCvq4pmPGf8zZ0XcAUprPT szzQ== 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=mcBKPgvE33iIk7UH14BXGvS2ykJScAZ9up9ceRJie34=; b=5UQVHX66iDjg1pcnZqfuPBcChZiSeUUm1RcxzVeKFtX/XV7ogKioc8xpzHLsiRxnTE wNY5/6knrdeHzt6vAnxeALtDFlGwYMFPK3MulmpBBbNbCwIiG5yKbGJ96vFEwfPvMhj9 ffWCNNyIAfNdiDxRCQD7oCO7G0/28yDv1j2hN7jxbtpdidCBh7mPZ5Hp3ylJoF9mzSIy ArwJ1B2Sg/4C68GFaqmHurWTjtS0XxEiSVWQaLAMhYDjS/ikMcXN69KBUxP74f5Tw/gI W3m/iCWGvuHtluXsSaCQTkAIY57eBV+GDuxbQCL7x0hOHUDGI6VuabgMNIXoUT1VCXMI +GnQ== X-Gm-Message-State: AOAM533QO4p9+M/6UTRfc2WvM2yIZDfvNpwMLWjh7BnoX8+67pXpSY4K YGWC+j/nP7Uu+Gf/Vf3AQNKpBLfkZCVni7LNZKEWUOVhGbc= X-Google-Smtp-Source: ABdhPJwtLwoZRaZumRK1ZU8uHkaIf2g9etrKoblzRExWvfszwCmbxUx+RhO4MFPviDRpDuFt30Oxq8FtIDfFM7O40+0= X-Received: by 2002:a05:6e02:545:: with SMTP id i5mr11731790ils.128.1640805161375; Wed, 29 Dec 2021 11:12:41 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> In-Reply-To: <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> From: Michael Schuster Date: Wed, 29 Dec 2021 20:12:29 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Karel Gardas Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000ca1cd405d44db858" X-Rspamd-Queue-Id: 4JPLdQ0zM9z4v4J X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000ca1cd405d44db858 Content-Type: text/plain; charset="UTF-8" Hi Karel, On Wed, Dec 29, 2021, 19:32 Karel Gardas wrote: > > > On 11/23/21 11:41 PM, Joseph Mingrone wrote: > > Hello FreeBSD community, > > > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > > sorry for being late with those: > > 1) implement/port beadm equivalent from Solaris/IlumosOS? Make > freebsd-update process more reversible by using proper boot environments > and using ZFS snapshots. All of these have been in FreeBSD for quite a while - can't give you dates or specifics (port vs "builtin"), but I've been using them since at least 13. Regards Michael --000000000000ca1cd405d44db858 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Karel,=C2=A0

On Wed, Dec 29, 2021, 19:32 Karel Garda= s <gardask@gmail.com> wrote:=


On 11/23/21 11:41 PM, Joseph Mingrone wrote:
> Hello FreeBSD community,
>
> The Foundation is seeking suggestions for new projects to support.=C2= =A0 What
> gaps in the Project are not being addressed by the broader community?<= br>
sorry for being late with those:

1) implement/port beadm equivalent from Solaris/IlumosOS? Make
freebsd-update process more reversible by using proper boot environments and using ZFS snapshots.

All of these have been in FreeBSD for quite a while - = can't give you dates or specifics (port vs "builtin"), but I&= #39;ve been using them since at least 13.

=
Regards=C2=A0
Michael=C2=A0
<= /div> --000000000000ca1cd405d44db858-- From nobody Wed Dec 29 19:15:38 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5052C1913B02 for ; Wed, 29 Dec 2021 19:15:51 +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 4JPLj30RwYz4vbF; Wed, 29 Dec 2021 19:15:51 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id DF7CF266D9; Wed, 29 Dec 2021 19:15:50 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f179.google.com with SMTP id q14so19735574qtx.10; Wed, 29 Dec 2021 11:15:50 -0800 (PST) X-Gm-Message-State: AOAM530dcNUeB3Um3IY/ldyPMlFDESxgzmkcovM6clEzsSTW0v9HaHXH uWMAAeUmUyVtdE7Z8Od+O1P8GNQMf6tS5vq2OuE= X-Google-Smtp-Source: ABdhPJxZtW3yT4L2kyCSTXisOc8Elg3Zcfo0LgvmXw7g5Ly6/iD3//2eYChONoOcy3qSADcj3eHcZzZ3NEtWdoZMEQ8= X-Received: by 2002:a05:622a:4c:: with SMTP id y12mr24399678qtw.21.1640805350484; Wed, 29 Dec 2021 11:15:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> In-Reply-To: From: Kyle Evans Date: Wed, 29 Dec 2021 13:15:38 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Karel Gardas Cc: Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640805351; h=from:from:reply-to:subject:subject:date:date: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=3y2k2BZNSiCn34fI0q9alodZ/DELIOWNe7F6opjw4dw=; b=EeqoYUgz+5GdPlVGihlC2B7wzEVbhGhH4nKNsfEYw8ceOEwW/869BFqTKvlb1ugxm7zZXV Dp+xLnx9Nwn8R4Hon0oZGd3WZQOvmpcE9N46q09ye/SJjJITkREEUku8boZVoA3prLlxQG w8w1C5nst8rB4qkqAdHVB89Pjwbfd6uGFzydeeTAXf0hN8V/Tx0V5e3iG1Z9G0+B+93986 QfDKsTNXuUDxHfAwUxXtTHwFMmROTqGdUbOK0kGzqK9xC9p7Amc76cS+a1ez0xS8WMNvWL tGDH3fpEDKgTpOLDK8oS/y93SzKN5yXeImZHbPOW0Tcf9D5WKxmGMBLZjZqFjg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640805351; a=rsa-sha256; cv=none; b=fN+rdOPa5LBEuJ7SJEb2KBcw1mmdyc1EZmnj5SeUURfVofCSYDyjV1Ew4pYI2pqCEF8vFn cL5B3TnkVR+VlEFqfEbdXTYPOT48Hc4tgj3QAUfeFg4OdSXt0+mJP0rKcBfekFj6NghWG+ bblf6NnjmQrsOPWk2vQaPJHe3aSdkohALOlTtq1Iq7luGSaawm+kCXbYE9+D6v0Fho0+6r sQLpCG090YlT0qpplUMt1cRqDOKwTRHaGxkVTvfaiBLkp0AhwQt7CIR4HVDUUedU4S2lNp wDeneDwRE5FZ0/rQLSG4YIWA31OGyRbMEP4FVjt3bz/N3jz9TerlVX9SfZS/Zg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 29, 2021 at 1:13 PM Michael Schuster wrote: > > Hi Karel, > > On Wed, Dec 29, 2021, 19:32 Karel Gardas wrote: >> >> >> >> On 11/23/21 11:41 PM, Joseph Mingrone wrote: >> > Hello FreeBSD community, >> > >> > The Foundation is seeking suggestions for new projects to support. What >> > gaps in the Project are not being addressed by the broader community? >> >> sorry for being late with those: >> >> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make >> freebsd-update process more reversible by using proper boot environments >> and using ZFS snapshots. > > > All of these have been in FreeBSD for quite a while - can't give you dates or specifics (port vs "builtin"), but I've been using them since at least 13. > Specifically, bectl(8)[0] has been in and mostly usable since 12.0, and more recently freebsd-update will use it to create a boot environment if the system can cope with that (i.e.: `bectl check` is happy/convinced that it's currently booted into a BE layout that it recognizes). [0] https://www.freebsd.org/cgi/man.cgi?query=bectl&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html From nobody Wed Dec 29 19:23:04 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD2EB191601C for ; Wed, 29 Dec 2021 19:23:16 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPLsc5l0nz4xCK; Wed, 29 Dec 2021 19:23:16 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x130.google.com with SMTP id b1so17335140ilj.2; Wed, 29 Dec 2021 11:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rQdBXxXXD8CTcVfsbzk3KhJiA96/a0IqfZzf+Nyi+d4=; b=cIXysxBs7HcUQlxP2d1d6QCsMnx+3UUkRWmnn+h4BZxPvJ1ZymSAqo3llMGb0WZz0r 6C0enrN3H9hQbOU3Eri4gOCFqHxTYPLtAIe++qeUj+D6y4VYlt/btFcEf3gKPwGE/Dse q2XArywvM5SI9NOeDI3iIIPifAT1g8R0oD+KAfLTpx9gQbfu/XW4wQBgOpRzPQN0qINs foJj1tiz5nsvp/MNXHdZjWntWdk7NYmsw5EjXMF2epzjDZz1uL3f8L5OZCm+42Zkm6f6 6m5YY+3Iv4u6o/px+RgeleT5YiteeA+CyQjKk3THwMTmK6S+bGVpUdtnXX7+iOuSCVlg utkA== 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=rQdBXxXXD8CTcVfsbzk3KhJiA96/a0IqfZzf+Nyi+d4=; b=vqWn+AxRcoME6golfBAlSIKbxpBbZlHYSn1/z+SQrvlvob7tStWz4arIIVBWKLi5A3 yScymFnr673JVlcCJMZ82IBu1I3Xq8LZSMEIYbFXVEDxkrJlPaJhMmJbmYFYZfX0GGfS B/l53J6gUuUIp/3/KgSPByBx1NePZb8RgfTpyQIsd3jKq72RGb9rLG+NSXjPBKCeSuQz bpeAge0SDjiLeUSsXGwDXkkufFuqoL+Sn7elZNEr3Th2gRdoeb+PeLTy8vtlBa9ueapY p/PYgnmmRdWiuC72ZCLz7Eq7GOY1ChhRNepbZ0kOhlzNbvsHsb/0jWSnWIhm/jfw1PjP cl+w== X-Gm-Message-State: AOAM531n/u1RnI7mysmz5olpWHCE+UcJU9DaU4wBzEAE1WtW3rsXmbyU fKNYP1r03xSfz5jAzdmo2PuomQN6WiO7fE6gc45NGgMXRLg= X-Google-Smtp-Source: ABdhPJwAS/VWtewcf1O6W4sEdn6mMWJPb5yXdywaYLzw5XMM9rvKpevQjSuWTsAqRR/L/Jxl32o2LKual8hh/LcGCrQ= X-Received: by 2002:a05:6e02:1949:: with SMTP id x9mr13015026ilu.63.1640805795852; Wed, 29 Dec 2021 11:23:15 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> In-Reply-To: From: Michael Schuster Date: Wed, 29 Dec 2021 20:23:04 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Kyle Evans Cc: Karel Gardas , Joseph Mingrone , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000009b757c05d44dde40" X-Rspamd-Queue-Id: 4JPLsc5l0nz4xCK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000009b757c05d44dde40 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 29, 2021, 20:16 Kyle Evans wrote: > On Wed, Dec 29, 2021 at 1:13 PM Michael Schuster > wrote: > > > > Hi Karel, > > > > On Wed, Dec 29, 2021, 19:32 Karel Gardas wrote: > >> > >> > >> > >> On 11/23/21 11:41 PM, Joseph Mingrone wrote: > >> > Hello FreeBSD community, > >> > > >> > The Foundation is seeking suggestions for new projects to support. > What > >> > gaps in the Project are not being addressed by the broader community? > >> > >> sorry for being late with those: > >> > >> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make > >> freebsd-update process more reversible by using proper boot environments > >> and using ZFS snapshots. > > > > > > All of these have been in FreeBSD for quite a while - can't give you > dates or specifics (port vs "builtin"), but I've been using them since at > least 13. > > > > Specifically, bectl(8)[0] has been in and mostly usable since 12.0, > bectl behaves slightly differently from beadm, which can be confusing when you're used to beadm. I don't have the specifics handy (although I was part of an email thread about this), but decided to stick with beadm as it suits my needs better. and more recently freebsd-update will use it to create a boot > environment if the system can cope with that (i.e.: `bectl check` is > happy/convinced that it's currently booted into a BE layout that it > recognizes). > > [0] > https://www.freebsd.org/cgi/man.cgi?query=bectl&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html > > --0000000000009b757c05d44dde40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Dec 29, 2021, 20:16 Kyle Evans <kevans@freebsd.org> wrote:
On Wed, Dec 29, 2021 at 1:13 PM Michael Schuster
<michaelsprivate@gmail.com> wrote:
>
> Hi Karel,
>
> On Wed, Dec 29, 2021, 19:32 Karel Gardas <gardask@gmail.com> = wrote:
>>
>>
>>
>> On 11/23/21 11:41 PM, Joseph Mingrone wrote:
>> > Hello FreeBSD community,
>> >
>> > The Foundation is seeking suggestions for new projects to sup= port.=C2=A0 What
>> > gaps in the Project are not being addressed by the broader co= mmunity?
>>
>> sorry for being late with those:
>>
>> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make
>> freebsd-update process more reversible by using proper boot enviro= nments
>> and using ZFS snapshots.
>
>
> All of these have been in FreeBSD for quite a while - can't give y= ou dates or specifics (port vs "builtin"), but I've been usin= g them since at least 13.
>

Specifically, bectl(8)[0] has been in and mostly usable since 12.0,

bectl be= haves slightly differently from beadm, which can be confusing when you'= re used to beadm.=C2=A0
I don't have the specifi= cs handy (although I was part of an email thread about this), but decided t= o stick with beadm as it suits my needs better.=C2=A0


and more recently freebsd-update will use it to create a boot
environment if the system can cope with that (i.e.: `bectl check` is
happy/convinced that it's currently booted into a BE layout that it
recognizes).

[0] https://www.freebsd.org/cgi/man.cgi?query=3Dbectl&apropos=3D0&se= ktion=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Ports&arch=3Ddefault&a= mp;format=3Dhtml

--0000000000009b757c05d44dde40-- From nobody Thu Dec 30 01:42:51 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 49AFF191880F for ; Thu, 30 Dec 2021 01:43:01 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPWHl6Z1Sz4hBC for ; Thu, 30 Dec 2021 01:42:59 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id d9so47622910wrb.0 for ; Wed, 29 Dec 2021 17:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=N4jj/H3jWVRIsgt5CnSA1n9BfCVN5YeptAISUrg5yv0=; b=D6HeYJ2Qb3RRkKlUs6I9A14v7WaNmRm0Fkvnhh45NiavDEgTplDQH72M9eMX5NZf+I AhkzFuqug115EoFYQzfWHxqG04M8NY6N48sqvZzqFHNdZKO3+L2C3imZGrJgz7/3PLfC puq3BDp6eu+98Rs0YxlD9OH5LIrZVjvbzgj6FfZCnEZ/AoSAYuVoysh3bahDM+hS8SCj 2BLSe+l/KnKqPkEL+KwbtT+rfYQvH1f7PNe2HBpL7El/H4vaKjUrNiPjBME3GremsR7Z VA7rU7wFfLTj7/f+Rr56NfeH+BfGcBdRixrIbcqvqyas0hBvFzbvlfMee4XAJynronUb HA6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=N4jj/H3jWVRIsgt5CnSA1n9BfCVN5YeptAISUrg5yv0=; b=lvZ+AbHkLZX+whhSZqwJNeVxmnJlVkYn0cSXsEzh6thWraAuEtuUEYWcafEa6v5zl7 isvNygR3CICV77iGGQyzVaZ4k7/ShkdMtjLqADp066XtwHGk2PziDjN7fJlJbI7mphGV r0uJJ/xYk5jJ36d62R39VgxzVfHG48rGtF1+U6TqEMyCN+R8cT/bTUvVKpbDgHyy7KNC D9lDFtz7gDqAPv3NgwxLc8uiXSlUhmYU3mPLxMLM5SjoFOMFIoGVYmYTqfZQqaj5I88J LK81U63zpvowXKNnnMk7/NPzBy+1+nPA66wE6JkXzPwJr36XoNh1+2rrdxyOQpoW4D9h 1M1A== X-Gm-Message-State: AOAM53024uhGmnUPd84jUPFwA8lHl67+0m/I3L3JYvViVPqmvWgYvykp WjPIzBvSjFUX6KIyoa28JZ7d6OR7xRE= X-Google-Smtp-Source: ABdhPJyUB9xek5bNPaj0Q7z59JJVRBgBmmvNJCpPrxY82xfjPA0XYC0g95xluHvEZXsQcL2mm34s1Q== X-Received: by 2002:a05:6000:15c5:: with SMTP id y5mr22256662wry.473.1640828572573; Wed, 29 Dec 2021 17:42:52 -0800 (PST) Received: from [192.168.1.10] (host-92-22-91-188.as13285.net. [92.22.91.188]) by smtp.gmail.com with ESMTPSA id d62sm25361196wmd.3.2021.12.29.17.42.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Dec 2021 17:42:52 -0800 (PST) Message-ID: Date: Thu, 30 Dec 2021 01:42:51 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: freebsd-update: create a ZFS boot environment on install (was: Call for Foundation-supported Project Ideas) Content-Language: en-GB To: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> X-Priority: 5 (Lowest) From: Graham Perrin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JPWHl6Z1Sz4hBC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=D6HeYJ2Q; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[92.22.91.188:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.80)[-0.802]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 29/12/2021 19:15, Kyle Evans wrote: > …𠉧 bectl(8) … recently freebsd-update will use it to create a boot > environment if the system can cope … Excellent! Thanks. I was previously unaware of this enhancement. From nobody Thu Dec 30 01:51:49 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 50987191C21A for ; Thu, 30 Dec 2021 01:51:52 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPWTz30rjz4m2M for ; Thu, 30 Dec 2021 01:51:51 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x336.google.com with SMTP id b186-20020a1c1bc3000000b00345734afe78so12594578wmb.0 for ; Wed, 29 Dec 2021 17:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=xEh2gw0adykqO0lgwNjKHZ+oQeChGbsX0vLHD3Tf/xE=; b=kR+PgUbMl5ytEOhQvOhcy+yfJ2lCVgKfz6mtIZ27cs1gukMkxVbFuMMx4dv4d5Vwdi YzRPTJe0NMCOkeWTcI7zAefm3tKjkYxJXr1SROwXvJEiRzhqpTzCXL7R5llOTCxqr+Eb bNnNr9TpsADpCNwqQYTyxe7d/aE5aFe3z6h51HAW4+bvof2eRxcdX8MtjBl+WLs6Npg5 /23DAom32nDVaQI+njIRrV4tQPv0ziU+blwc2zNCR8pp+PtldA6UnVD25dB2T2ge6gYZ rG75NRRYFazImU/xSllrss/UHkA9y33FMV6GGfKWlUsrgJ3qWccODmLr+hZJYpbZfd6U RrlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=xEh2gw0adykqO0lgwNjKHZ+oQeChGbsX0vLHD3Tf/xE=; b=udp28OzwgeeVLRLhWGN+9b96v1/n+s0P7UmFAtaiRZQF3GzIn1JMJTNLEwl8nDrziJ Y/Vy/fgouca0uLNH00PIbCmgjtEmN5aePVN3oqVc5UEQed0gFfLYS3+LVq6wlF0PiF1k cu91Bb5ZfUB8Ys5pH/tcqYV9ZAXbNnto6HHK3M61ltHgzf33mdR3vaZM6C1GWQt9Axej ODuWnZr2LwkycpYqpZ3s0WVSL6tKGYmsEiIgtj7Bu59a3WUcr6mi6wNndp6Q7TEEANwP 6U0II6yZjuUESkOMitryST7j6cQTOhQESZ0DfJOKFAZu8dwtrQSjLtO6jdWOfRvEjNqp rt8Q== X-Gm-Message-State: AOAM531cC4Jlvrt6rFkJaSHiOw+1pQT6ex1DVfLVi2SIga1XWZFxdQWR JeKEV3vucWW6TCdw3VCOilb2miaJtRU= X-Google-Smtp-Source: ABdhPJwC3JotmeJQyEIy056qJSRatAtr/lhgNE3i+tg7RVSWHoAybpTTd74ECt0BxSZTkSrdbz+OSA== X-Received: by 2002:a05:600c:3d88:: with SMTP id bi8mr23536469wmb.19.1640829110177; Wed, 29 Dec 2021 17:51:50 -0800 (PST) Received: from [192.168.1.10] (host-92-22-91-188.as13285.net. [92.22.91.188]) by smtp.gmail.com with ESMTPSA id c2sm24902789wri.50.2021.12.29.17.51.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Dec 2021 17:51:49 -0800 (PST) Message-ID: <40f91e35-b88e-10aa-221b-3439a9b88997@gmail.com> Date: Thu, 30 Dec 2021 01:51:49 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: =?UTF-8?Q?Recoll_=e2=80=93_an_alternative_to_Baloo_=28was=3a_Call_f?= =?UTF-8?Q?or_Foundation-supported_Project_Ideas=29?= Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> X-Priority: 5 (Lowest) From: Graham Perrin In-Reply-To: <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JPWTz30rjz4m2M X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kR+PgUbM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::336 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.82)[-0.822]; RECEIVED_SPAMHAUS_PBL(0.00)[92.22.91.188:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.87)[0.872]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 29/12/2021 18:30, Karel Gardas wrote: > 3) FreeBSD/KDE user hurting: baloo file indexer … Users who find problems with Baloo may look forward to version 1.31.4 of Recoll, which will allow real-time indexing to begin when the user signs in to the desktop environment. I have been using this feature, patched into 1.31.2, for a few weeks. This is not to detract from the wish for Baloo to be fixed on FreeBSD. Just FYI. From nobody Thu Dec 30 02:15:32 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8EA9319204D0 for ; Thu, 30 Dec 2021 02:15:41 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPX1S5wK9z4prM for ; Thu, 30 Dec 2021 02:15:40 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id w20so38639093wra.9 for ; Wed, 29 Dec 2021 18:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=ANXrfDWm2BjXxpuRjf8vFBrqDEJ7iY5CHLwGaOkUBZQ=; b=BMTRh52DBLa/lozDuyn9ZNkCVEYGO7hFmEjUiQQGj+5HOFq6TPum5Ev71g0jHx27Wm UTs1RwSBDPrZiLzbqh5v0xycXxmprgQouhU/JlBaChNqs4DjiN5NyDByWrYW35hM0eUT cvfJHAG5nEf8RkBmGTyl90xbMIXudK+OnJBbNSLUWa9gHinGMlIUsUVNH5b3lC411BI5 LnHvurcloJvM+IIU/gqc4qRcl6RbbJkwRNOfmB1S4XdQR0eaCCxTFghmrlVmrFYI6x0O D61zjERM21xxpTewmggIIys3XwNSk1jVc315a8FJN92HpdUWYEdgk2rkphsnBLySwT+G +Elw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=ANXrfDWm2BjXxpuRjf8vFBrqDEJ7iY5CHLwGaOkUBZQ=; b=TGdKCaks5eser00kwLFM0jCtXZriMu2l+LzfVbKH7n2Bel79aEzYe4iOp/hihztorF 0nmD1SzxKAVTnNHDyuAlWpa8f9ejKrffzdkcJ8VYQVg3gBz3hnZEgU7XnbMuZvvYAsUk pOBidav7Jd8b1hsFC0m0jNRHShuawU/eYxZlib92KCKhfEdzmT1TrO+oY2GIP8VpMi73 tECMYos/nqGNdENvpFsTqi2stwRG/tcPFy2tdYm+6JB4Pa3sNxWeMw3cNt0pcoxOwzXd 4rOOf4Ppazj9rJrcHVAoakKLASq0EHf8BPgLjSD+IUyK8v8511GzO+WXLgX855J689GQ mSvA== X-Gm-Message-State: AOAM533PQhKPjXaSyibvKRGs9xq7JiPh6vHSjbH9neO8ceaNDIlYG9Vd EgSMxMHe7z9reESulXI+Mjr3hPLppYI= X-Google-Smtp-Source: ABdhPJy0FtXBQ0+bfFbBGaLIkqNsM8IecYJse13/fP3JEzjLb6ZyzITlN8ICCIvtl2ZCkjY6SqIN/w== X-Received: by 2002:a5d:6842:: with SMTP id o2mr19412628wrw.615.1640830533207; Wed, 29 Dec 2021 18:15:33 -0800 (PST) Received: from [192.168.1.10] (host-92-22-91-188.as13285.net. [92.22.91.188]) by smtp.gmail.com with ESMTPSA id m12sm24364347wrp.49.2021.12.29.18.15.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Dec 2021 18:15:32 -0800 (PST) Message-ID: Date: Thu, 30 Dec 2021 02:15:32 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: bectl(8) with pkg-upgrade(8) and PkgBase (was: Call for Foundation-supported Project Ideas) Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> From: Graham Perrin X-Priority: 5 (Lowest) In-Reply-To: <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JPX1S5wK9z4prM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BMTRh52D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::435 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.64)[-0.644]; RECEIVED_SPAMHAUS_PBL(0.00)[92.22.91.188:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 29/12/2021 18:30, Karel Gardas wrote: > 1) … boot environments … May be good to also kind of hook > freebsd-update and pkg update/upgrade together when required by user > to make whole system updates more transactional. Maybe take inspiration from GhostBSD, where there's a GUI for the PkgBase-like approach that coherently updates the base system packages and non-base packages. > Better use of boot environments with Update Station is somewhat outdated, as a page. Also/alternatively, inspiration from: * the GUIs through which boot environment-friendly updates were managed in PC-BSD and TrueOS – (not the original location) lacks original screenshots, still it's a useful point of reference * the developer preview of Update in helloSystem, . From nobody Thu Dec 30 05:05:03 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4700D1913325 for ; Thu, 30 Dec 2021 05:05:21 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPbnF1MKVz3N4N; Thu, 30 Dec 2021 05:05:21 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x931.google.com with SMTP id i5so25688229uaq.10; Wed, 29 Dec 2021 21:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JlMRkxoTzb/blji/Q+Yd0Ugp69SHHdq/AU5QwiDFJh8=; b=F9BEzNlqJzRzF4MPu5jN2xKXq5c0Nbm1rzL/EwaLo6RGHVso+i4WwvFHSsgZsdTEwe YValx9dKwlYp2Mz0GaZ8hGZG6i5s7LC1iVhKgEgFIBK74OAV7DqbkV6LYKUno+JPGU/q 2AjIcGgbF1x0XkHDxPms46uSTSItBMAyfgBs6VRHjfzo9X9m/yGKy4W86LVuHLAYk/8E NF88j57Sca39b7lwbOWx1TvUuYlwF0Kj+QaYzeoJkbdp8wDhoDi/QbZsbhTJ/uCB4rJw lD0SyvUNgsqphExivg5GCl5PLO3qsZDSb/S+tMz68lx8RgB+3aIv0YSWBx1Rxb8C/Jlv PQ4g== 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=JlMRkxoTzb/blji/Q+Yd0Ugp69SHHdq/AU5QwiDFJh8=; b=PoMQVwvUHdjlmrgLRzm5LimT1kMiXw7FdZsNHNUIrBaqbCf+sU2FaGJ6bc9CA+ulR5 9Sjj7xy+0dBGCR01oI9GUrmP2TP1PzbrgHAGAqrBn1WnKJ/QoQ/7gdeDBxhWdQVgi9x9 VNdyUzx6UDjQ4EmL+Qenem0/6c5XYsBnKgesL2zNJg4Yi/pvOD1RtR5Ymq1y+y11GKtP Y2+ScRGpmDkfuALuQYXJwMXif51Kq/P2BvwflZrVvaCSvzABEQGtt/sQekoc8FRLSLMt g2MyBYsozt7V/0XbkwqMED+mIbIlNdqIn/J7zGXK8dPmnOf+tFs3ozZ6KCQbKo/9UkIZ hWEg== X-Gm-Message-State: AOAM53306lZNc04Wkx3YltaxzflFtWLNaYY75K+FAg+6oPWKm35AYtYz UjzOMV5wKQxOkHOA8QveOQcfXzlkTfJgeS/XEFonE0L1 X-Google-Smtp-Source: ABdhPJwtmtgoCebO7ytfPaaT6YSUL6iEDKGuI6RZIMzi2gk4KK8ouMYePyJP0zGXlMh5a/aWlaI6lm6ctr6EJgawoPA= X-Received: by 2002:a67:bd02:: with SMTP id y2mr9277192vsq.56.1640840713845; Wed, 29 Dec 2021 21:05:13 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 30 Dec 2021 08:05:03 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Michael Schuster Cc: Kyle Evans , Karel Gardas , Joseph Mingrone , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JPbnF1MKVz3N4N X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I've ideas about enhancing the routing architecture. Is it possible to add to wiki? - Source address selection option for destination route. (like: ip route add 10.2.2.0/24 via 172.16.1.1 src 192.168.1.2). It's a very useful feature for multihomed systems. - Metric support for routing. Thanks Ozkan On Wed, Dec 29, 2021 at 10:23 PM Michael Schuster wrote: > > > On Wed, Dec 29, 2021, 20:16 Kyle Evans wrote: >> >> On Wed, Dec 29, 2021 at 1:13 PM Michael Schuster >> wrote: >> > >> > Hi Karel, >> > >> > On Wed, Dec 29, 2021, 19:32 Karel Gardas wrote: >> >> >> >> >> >> >> >> On 11/23/21 11:41 PM, Joseph Mingrone wrote: >> >> > Hello FreeBSD community, >> >> > >> >> > The Foundation is seeking suggestions for new projects to support. What >> >> > gaps in the Project are not being addressed by the broader community? >> >> >> >> sorry for being late with those: >> >> >> >> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make >> >> freebsd-update process more reversible by using proper boot environments >> >> and using ZFS snapshots. >> > >> > >> > All of these have been in FreeBSD for quite a while - can't give you dates or specifics (port vs "builtin"), but I've been using them since at least 13. >> > >> >> Specifically, bectl(8)[0] has been in and mostly usable since 12.0, > > > bectl behaves slightly differently from beadm, which can be confusing when you're used to beadm. > I don't have the specifics handy (although I was part of an email thread about this), but decided to stick with beadm as it suits my needs better. > > >> and more recently freebsd-update will use it to create a boot >> environment if the system can cope with that (i.e.: `bectl check` is >> happy/convinced that it's currently booted into a BE layout that it >> recognizes). >> >> [0] https://www.freebsd.org/cgi/man.cgi?query=bectl&apropos=0&sektion=0&manpath=FreeBSD+13.0-RELEASE+and+Ports&arch=default&format=html >> From nobody Thu Dec 30 15:24:18 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E2EDB191B281 for ; Thu, 30 Dec 2021 15:24:20 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPsWS5fRhz3q3D; Thu, 30 Dec 2021 15:24:20 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id i22so51012154wrb.13; Thu, 30 Dec 2021 07:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kVIGV/3xLyqzlmLodXQWB2J03VE1DDqQ/Z0xNI8zrlc=; b=hkAIjoqoaCHjg8Avbn3O/uuq2fs/uBLYfEU6kTn1E96gQtAP4ndcTcchGuAppTaYYW cPbJjznoOKGB0VDAblF6zD/gQMaZepd8ItlMwu8MWyHf8u990dz4CeAwnlS/k306NcsY YqalTTEyHo8KG4wjUrMvxqYbD5o9B8T+Ev03vxNdz0UVVDDyO8Ocgje+icfyOD5BNAbz miuLxYwi30sf/tuWQ2jucx2JFlb8lY9AIr556VfFXHza0pMLWZ1+TJrKikhrD+Xr9qXm ZQ/oVKp3UiPDk0kMOoxoHCCvG+b5zIU+EkXvvpr0Pjsy5avzQMvD0xVhXfpuD4wziZEn XqnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kVIGV/3xLyqzlmLodXQWB2J03VE1DDqQ/Z0xNI8zrlc=; b=hFGBDF+Q/a563DWLBZDTK+l+xIMzOBwuF01R9ToiSoGr6zPPSU6HEqqZ0eOH6bcnU/ p/hZJUI4Hl/t0ljMyUuiERnYFW9pUgDvjlf7wBCmdS5i3eSLP/aRWq+C+doqiO8v4igU hN9fgf0shinTXbVfxcUKzc9DIME4QmWyjB00CDspxuosXjYATfuazQhLdlS3/j/gecuZ +3kRiTR69OGt7Nu7q+93GNT3fYJEt0hr+TalttJ0EEYTn3ydn1kR88Nxq4+Wc13KyjRn 9dLChpoiQAtsuUnxPgu/QmN8Qga277xJ0Oj9LBUgYSaN4TbcPXSBbKqlL3LgkMRZQeIP YkyA== X-Gm-Message-State: AOAM532oX1ocaWgGVvwy8Skx91LgCgQ4k8Vpk285av06UbadC7A3MZGd ZeUY1Lh0PmVU/J/msxBTFiCVnHWIqFw= X-Google-Smtp-Source: ABdhPJyjbixP3urFjdx9UfIoHulDTvZ+pTV4M5LzfzE3rGOgLzgUL7eye+6nQjI/EGi/ldexu0KK7w== X-Received: by 2002:adf:ba8b:: with SMTP id p11mr25059205wrg.390.1640877859535; Thu, 30 Dec 2021 07:24:19 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id f6sm29094327wmq.6.2021.12.30.07.24.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Dec 2021 07:24:19 -0800 (PST) Subject: Re: Call for Foundation-supported Project Ideas To: Michael Schuster , Kyle Evans Cc: Joseph Mingrone , FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> From: Karel Gardas Message-ID: <097e751f-468f-00e6-07ff-4a8286d3a275@gmail.com> Date: Thu, 30 Dec 2021 16:24:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JPsWS5fRhz3q3D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/29/21 8:23 PM, Michael Schuster wrote: > >> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make > >> freebsd-update process more reversible by using proper boot > environments > >> and using ZFS snapshots. > > > > > > All of these have been in FreeBSD for quite a while - can't give > you dates or specifics (port vs "builtin"), but I've been using them > since at least 13. > > > > Specifically, bectl(8)[0] has been in and mostly usable since 12.0, > > > bectl behaves slightly differently from beadm, which can be confusing > when you're used to beadm. > I don't have the specifics handy (although I was part of an email thread > about this), but decided to stick with beadm as it suits my needs better. Guys, I'm sorry about my oversight of this excellent feature. Obviously this is my mistake[1] and thank you both for the remark. I'll do my homework and look into bectl. No, I don't need it to be beadm compatible, but just beadm idea compatible. E.g. be able to roll-back after update. That's enough to make me happy about it. Thanks! Karel [1]: caused by a fact of having FreeBSD 13 with freebsd-update working but installed on shared drive with Linux and hence using UFS2 hence no ZFS snapshots. Also have FreeBSD 14 on zfs root on separate drive, but this obviously is not updated by -update but by git/make. Shame on me! From nobody Thu Dec 30 17:00:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F5DA192DC35 for ; Thu, 30 Dec 2021 17:00:45 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPvfh5j97z4bcf; Thu, 30 Dec 2021 17:00:44 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165022.dip0.t-ipconnect.de [91.22.80.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 9DB922437A; Thu, 30 Dec 2021 18:00:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1640883635; h=from:from:reply-to:subject:subject:date:date: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=PIQk7zt8H8FtftR4pdJJeqg6x11a3Px95DYfpn1zqcw=; b=ecb7w/SbXiHqCib0ysr3IQKebJgqIkUsp6MRjetWpWsd15QHFmVlbIxhCY0qLBPDWsVPzB fsjQWOwHHu8a3U2Bm/irIzCHX+DKKInOz9gjHc4qw/Dle4DWZ959T8KcGQYJGRNKyBZ7LR p/2S3waIkbW8LTVfuoIu17JFfoDrVVhswO/8j5LhshDIYhc/RLNTZG3LSjt+bRCTsvr4Bt hR4iDp0hpcD7D13JRCkwwdpUEW6AWgF5x9brMs+azZPMIPgen0ulYMlzbF1LAfMWO9VHBn H8ev0WJMkIY1lcfVm5TjUWwH0MO1TrFLzElKXPtFYztjissyCkVxbmlBc80T9A== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 2FA8A6DFA; Thu, 30 Dec 2021 18:00:17 +0100 (CET) Date: Thu, 30 Dec 2021 18:00:15 +0100 Message-ID: <20211230180015.Horde.J1DvEtdzVDFXjaUK5bFN0Iq@webmail.leidinger.net> To: Karel Gardas Cc: Michael Schuster , Kyle Evans , Joseph Mingrone , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <097e751f-468f-00e6-07ff-4a8286d3a275@gmail.com> In-Reply-To: <097e751f-468f-00e6-07ff-4a8286d3a275@gmail.com> Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4JPvfh5j97z4bcf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: Alexander@leidinger.net From: Alexander Leidinger via freebsd-hackers X-Original-From: Alexander Leidinger X-ThisMailContainsUnwantedMimeParts: N Quoting Karel Gardas (from Thu, 30 Dec 2021 16:24:18 +0100): > On 12/29/21 8:23 PM, Michael Schuster wrote: >> >> 1) implement/port beadm equivalent from Solaris/IlumosOS? Make >> >> freebsd-update process more reversible by using proper boot >> environments >> >> and using ZFS snapshots. >> > >> > >> > All of these have been in FreeBSD for quite a while - can't give >> you dates or specifics (port vs "builtin"), but I've been using them >> since at least 13. >> > >> >> Specifically, bectl(8)[0] has been in and mostly usable since 12.0, >> >> >> bectl behaves slightly differently from beadm, which can be >> confusing when you're used to beadm. >> I don't have the specifics handy (although I was part of an email >> thread about this), but decided to stick with beadm as it suits my >> needs better. > > Guys, I'm sorry about my oversight of this excellent feature. > Obviously this is my mistake[1] and thank you both for the remark. > I'll do my homework and look into bectl. > No, I don't need it to be beadm compatible, but just beadm idea > compatible. E.g. be able to roll-back after update. That's enough to > make me happy about it. You may want to check zfsbootcfg too. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Thu Dec 30 18:15:17 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1EDDD1911496 for ; Thu, 30 Dec 2021 18:15:20 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPxJl6fw9z4kfJ; Thu, 30 Dec 2021 18:15:19 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-249-199.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.249.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 87D87122D; Thu, 30 Dec 2021 18:15:19 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: =?utf-8?Q?=C3=96zkan?= KIRIK Cc: Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> Date: Thu, 30 Dec 2021 14:15:17 -0400 In-Reply-To: (=?utf-8?Q?=22=C3=96zkan?= KIRIK"'s message of "Thu, 30 Dec 2021 08:05:03 +0300") Message-ID: <864k6qj6x6.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640888119; h=from:from:reply-to:subject:subject:date:date: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=8mlD41nhSALNSeR9vooHQj6hWxQLrGU6HEZj2w04tV4=; b=iTIUAqGytJ5DhEtiNtIZdRnquw2ZKkA9f80AqPFJoee9gqBGXSOiRsVeeWkIN2C68mN81v qebmNJwppAjHx6CSxE6T5SMa9roCeDFb/dx9W5i4Reh6OBWdzwJS87mZeQ96dOVOya106I i3GQeuqzuIn5pmyL5E9sp7Jebqm1YGReJPStH+rERTFJT7d1m5SfOG2T6ybI8yWgEwTBUC SMKXgYIpKd2e3wyTWB6Ez4iCk8JQ39ZCw1gFRVnz3WJCVrLWUJOid5L9RdyDVRmC1vchvp ndOfOukcWRyGN84bFJVQXg07teW9/wRiGGm5QdtLG32wyFtqq9LjnvIOsieDNA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640888119; a=rsa-sha256; cv=none; b=B6YsONB9zTyo1rMWmSCKhyyiPrsJRTqArHpbEXzZj4LzdzjWQ7gDmfNKlt5F6jXBdeGsMp 7Js93CzcyCkKYje38m/yJwaTqpDVVAGkHzOFB3R5t/6Un1gEzNhZvo61yPBO/cukN4bDNU d/isV7BjVNk11JYKwVWAlfd+qrUhQAat7UkiRRKAcCja6ydSnqKD5fEMZD5IiGzcZJhOva pEzP5LYYd6rivGXmN6J3A+JbR9O3tNh19nYBZl00ARaan2FrDD6Wf9Orl4/ds3ut/Jki6o nzDEDnTbEU068Jkkl/RGcO1UCqBhEPHZVcZUQx6nG2mwAbS/dBiWb97NNbKRbg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK wrote: > I've ideas about enhancing the routing architecture. Is it possible to > add to wiki? Certainly. Please do. Thanks, Joe --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmHN9zZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnrjyEAClG1XRBu/esv4IKWS/vRAlHnCn/4yq/Io7 UHDrzxW5BNcZ/HMctYELDfcHLFcnRil0G0hlRO1/14IFLesN+iAFP1sloX9F0RJF vbEGw6spiIuqlTycaAkjapZtTOXG4E9ZacUVz+3zdZ+vU8fLJmrLB9ylVlXKLXvz Gl8zc7V5aXF963bR/JQCbYw1REIsCnXroEZ4I0NGlIasW9289IJUl9o6kFGwD698 Ax1mwkA3A3SDl9FphX189PLPVaLALwsHov5t938a5mL/A7CEPIugmJJQ21pVR98K 94fNfXwlgrD7V5YwnTioTXmutUVPbBXrCkXZL+ZO2UYI8vlbQSshOS6m6FbOe7iF bR97DEc5t5Wxt1YIOvP7sTwWf4mKqcsATppMzGaezoTyqzRKD0nP4pJ8Xbw1fMt3 w2c81iMXWoOSiu1tLKcDDsbGA+9O/9xYfED4+2LJi+VgVrEDg179r7TFfCaf0vGc ve3J7vWGainyS5dNSKDRMWB9RMIHGCB8vut6njqCaBmKCmwpEP4NQDIIkwL0Ue92 3lKQ8divLLbVbYPaYQvn2vyOWWaeBuc/meKe+zlIm+8uQtxVed0fHn7awyXxSiKS 6WAWf0/Kru2rQLUkkW73avLXrH6aEeup6ECcAltFqGFKBeCnkf0sLm2UkpD8VfDP LKdngmFwpw== =eRtZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 30 18:19:15 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AE131912DFA for ; Thu, 30 Dec 2021 18:19:17 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPxPJ5xfKz4mDD; Thu, 30 Dec 2021 18:19:16 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-249-199.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.249.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5582E1A13; Thu, 30 Dec 2021 18:19:16 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: =?utf-8?Q?=C3=96zkan?= KIRIK Cc: Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> Date: Thu, 30 Dec 2021 14:19:15 -0400 In-Reply-To: <864k6qj6x6.fsf@phe.ftfl.ca> (Joseph Mingrone's message of "Thu, 30 Dec 2021 14:15:17 -0400") Message-ID: <86zgoihs64.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640888356; h=from:from:reply-to:subject:subject:date:date: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=D+RpOzjyGysmC5IrOHuiC43ZcTTFJRSxXQ/Xoqie4Qg=; b=bmV8HDDp4moLMrWA2N63D1pL30tzXubyImnhukx1XFE4NPjgxx0UPtg8F0zGh0Ijbj36Bu hTXh7/lpVJwCvkhO/a3s2h29prTGboF0Ipu5RGLaV7BUSqmjIEijuAcKHuAkv9zxw8AUK9 mrueBrJbyEijCi7JzDksom0lrNxBD+mKdi02uNs1KEhMDAd/uPohI4palgiDdZK8q3yDrd DFz/S4tycPTnQMozxJwFJnCvGMD4DkYyAZtvKJ7cUpBnWNwMqnJictJ3w70MuASK5XG5Xs kZzcED5E/lvZ/uxXhCzqy++xvfNdHxQM5H6y7mNfTBQ/g9bzwb/TzlNT8/fVAA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640888356; a=rsa-sha256; cv=none; b=e4Q7fVQs3jsaPix0XGoiuQNZ93y9bo3hYTM7aCFLmRDs3iS6Wr4rXS7c3E4vksNXJvkiuJ HpVE6b0+iUb6z6r/M55Pq8dSnsGKxWbNh1bmwtfEFThj1Clb9Ze3X7zCztQ6qDl21H6pbO 2QiqRTZMb78VEN7US93u4IxEyOX4VxNld2/f/aVLZcHmlvQgjtdhKZVQtY4MQckkIZTM4C AmlLIUmdL5100yzqUNItlp1+yn6MUSqeGaLBX3Bx3tiSyo1uVDxutQP+soJK3peDmlOEAk eqNo40W5AzU/8K53To8rxEA0S+ZaEl0rGEjk73+PCmDTdHQVFmNFcRwTWimJTA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote: > On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK wro= te: >> I've ideas about enhancing the routing architecture. Is it possible to >> add to wiki? > Certainly. Please do. The link again is https://wiki.freebsd.org/2021FoundationCFI --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmHN+CNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnnZbEACJt86LtJvyQt5lSLQRnF1bzK413o2Fpo87 WaYIuNu+PUn+E5CgNOt88VLudXQWhUPHvejVpexcfv8terFMIITNsWeoMlHJCM7J 1IJUFmxffV5Mjmsyxd9G4aAAR/gfyZRzqvzhkMGV58LBweBC7W5h3bPE84+rM8jk +1St6qfveeBD41yzanvsL4cpQPnv5JjnueZGJkxioolo9bvL7MSTECJ4iP1NjShf JStuG4Pt3BxssDXyuckGt9mqrdxTR4P5K0kZGnBepyUXmeiE/qDhEYX7W+wT94vp g5x7ACtccBEvoif1H1KW9qo+gY7kJuSjtZVB8uvESvuxnDHc+RJHnuKhW/dgOfss tOp4pMBL2jToTSw9DjiRl74JgOJPH6YRQQb7IQT2zi+doGx8QdDEmoTpRUaigNlI Ncp33Hxu6/IGZ1aprV5iZIMGcuye9g54CT4LySZVUK+p7LnasUf3XJ5z78FMfyXk DxyfpyzfNYxOnJ6LyCm5ds9uYWMbjTFvIXqZvlsDxbG+RjXctT0ea5e9XKsgYnM7 MnGLekg164MYp1t8God8xgTXV+gRrNPy3q+4rU2pUYnSCqlrl6LtYukeZ+SLR9t/ E0RHdSv4RuERP8k7JkYJoUFVIvDlMuYHX4troiMgEguJIq03YCFjByWm+LpjIZif 6XCuqrXG/A== =tCJe -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 30 19:55:18 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B78ED192B27E for ; Thu, 30 Dec 2021 19:55:18 +0000 (UTC) (envelope-from luoqi@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPzX64vSVz3j25 for ; Thu, 30 Dec 2021 19:55:18 +0000 (UTC) (envelope-from luoqi@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640894118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=4yFq3fW2p8qzKow6WdrZofWyiiByH/Uff9SNUbKNq/U=; b=sM02hr5B+1acxgoCPl+ScBX2iwc+LzC4Lt+ouOUSWhWCnhyYDLmxcNvSbY5QF8YJxUOFJz GTxYNIBavcC/t+7EOG+lreVBd2ddMJSpwlSqAZVbVxWIBNgS1pEobgfUOE5e2A/eZHYeCE Q9c3wXcoBohKgICDvgDgAWDgtWsmkJdhkjGJ8sSsSuzUYHDAoJQpcmgmvN4ztuH9LiqZrn x+Q6L1LmpkKK5or5qvvKtUe4bFcBiuhDyr3bC6PvhIqUPrTLpugXCJUyOiJnPS79WekFyH MZwWdurlgdx+h1YskMkxpmGqselIdnYKok7plZ8Er8lOYukQP9uUIGPH3ABS0g== Received: by freefall.freebsd.org (Postfix, from userid 735) id 8F89676A9; Thu, 30 Dec 2021 19:55:18 +0000 (UTC) To: freebsd-hackers@freebsd.org Subject: leak sanitizer support Message-Id: <20211230195518.8F89676A9@freefall.freebsd.org> Date: Thu, 30 Dec 2021 19:55:18 +0000 (UTC) From: Luoqi Chen ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1640894118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc; bh=4yFq3fW2p8qzKow6WdrZofWyiiByH/Uff9SNUbKNq/U=; b=i1OqmGOGaiy/DQ1xKBIHwO7OAyVt2KHuP35v1hu2lqtuubCfEeMfcndbNUgq4n5+h6Dt39 wrqK34Qn1EvL/CU6ChWo9sAg34dTqyv/QxwE9etP5jssVZTJjx9GY5MKPSC3KQ99vxz20u Xyup05N9rTvhChZj9Hb4hK+D2RbxtpFyjPNO4Z4HezhMPJW1j3AFHKDqv05o0cCGuTsOXM Eev/jqhGmVNzBlD3Nq+RwsukgGJ9geYlolJfZhAegiV+efm40NEGmVFRzz9QvHVa2ewvum 79jf0541fcF9rKaUIfwSYWqk4hJuuqgglzVqc9OGZL7fA+uWuF8pCnPgv/Afeg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1640894118; a=rsa-sha256; cv=none; b=PRXMl6VVu87rXRFzzf4HX6H1pwlL+rkaYpiXpJzE/FHGvyCDav+kJQ2ZdOG5T/L/Iy3aYN B/v48J2VpjsOZQmN5ctM4VAjHjF5xI29rMKgiHgte46YVPuQuyg7Y8RZv7btKq+MVLeszo DKTxCrZ+2aeYaJcaqJwGzskcYQbdwWxQYYrKCgT9uQDhOhVrfM+B/0JaNRVQ/ZGVqQHAUc eHklvFcO0YnFUNHzDOOHtqUAU45yEca1AvrvQ7xwUll0yhzbRxnu9IZvsYGQTlHjJKVfwf PGm/Rq4FNf6pigl1irujkKInSEUWtuW4QcgQ8BRynF56WqzL28eJcoWQl6GLNQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Hello hackers, It's almost new year and I'm cleaning out the clutters on my hard drives, I came across some local mods that I feel someone else might also find useful. One of them is the leak sanitizer support, would anyone be interested? I've uploaded the diff to https://people.freebsd.org/~luoqi/lsan/. It's against -stable/13, but most likely would apply cleanly to -current. Happy new year! -luoqi From nobody Thu Dec 30 20:16:14 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 972B0192F759 for ; Thu, 30 Dec 2021 20:16:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQ00P3XcGz3mZL for ; Thu, 30 Dec 2021 20:16:21 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf35.google.com with SMTP id r6so22961006qvr.13 for ; Thu, 30 Dec 2021 12:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Z2zZJwE3Ev+QWG5GFt70c8ypl4+LArbx5BVOgqgmEm8=; b=PDcDerJUb7nL5yBkM2k4vWiDX9If5X+Z1Iou4cYtySwlQm22cznxEe/TJs/Qm2wDk7 BOY3U1U1SgXaQ+m08r1u88NQIJkU1jnwUo2lTdpT0i/YkbOCg7UY9ARxrjkFi/EOGgbx PpJuXlKECEcu8OCNkIQ4MttMYa/vVpuylY/1+3QgIHT4CUR6LHJhB8Nk2jGgPv1oSU7a 7Qw6XvFfXEfab8v4TudTt6p0VTtT7pG6YLLEVBO8SPd2pqkkGPzPN8JQBTETKkLs5vTe c6HROX2MZiPaX4OJoXOA+yGfOBpXmMIY00iYCMGwSzJUj5bn0596fHKJ9zVhvfvgROXs krjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Z2zZJwE3Ev+QWG5GFt70c8ypl4+LArbx5BVOgqgmEm8=; b=dw39nkuISPADrWsu+OGaoVQkvjY2CFVYMHmLnbEOgtV9d3KkLa+OqsZ4uFOuqC0cQP JL1vJ8jXYctbntGXAsy1yHCY160euufw1YaI2FKeyBBKlDL2pNIUypNrZ0wG1sfYWGb0 6eJ9fc4Vhfx7HjP2Uzz9yEEhlDCsXzUblFoyoejkRp/zBuAKx4xwFP2l9XgWMAqjUGNd 4AeQ5497JfvS959wZSHSDS+LeA8TCj2IxSr/NLg4fbEoKOEU2Y1du+jA1tH+SQMihAjC arXoioXXdWhsvVkgXY+3fuTWPQcWE2qQysFn6W+Ixekzb7N4umghq2yYBJ2agWfbFMeA fNgg== X-Gm-Message-State: AOAM531UUJo4msjskz2rJyQvQGm6VZNmhu8uoQQ2mGUs6I/k1QGOdy4j 0xKYRhxCBmWCEYgdZ3fe7t0RNQ== X-Google-Smtp-Source: ABdhPJzZyI6tPImFyKp5gMZiq0A4ziG2m3BQkk2oo0pyUxQjbmfleXvk9GcTGb+08cKTO91lDFOTwg== X-Received: by 2002:ad4:574f:: with SMTP id q15mr28811327qvx.97.1640895375334; Thu, 30 Dec 2021 12:16:15 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id q30sm19113339qkj.3.2021.12.30.12.16.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Dec 2021 12:16:14 -0800 (PST) Date: Thu, 30 Dec 2021 15:16:14 -0500 From: Shawn Webb To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: leak sanitizer support Message-ID: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20211230195518.8F89676A9@freefall.freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yany4lrjthotfjwx" Content-Disposition: inline In-Reply-To: <20211230195518.8F89676A9@freefall.freebsd.org> X-Rspamd-Queue-Id: 4JQ00P3XcGz3mZL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --yany4lrjthotfjwx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 30, 2021 at 07:55:18PM +0000, Luoqi Chen wrote: > Hello hackers, >=20 > It's almost new year and I'm cleaning out the clutters on my hard drives, > I came across some local mods that I feel someone else might also find us= eful. > One of them is the leak sanitizer support, would anyone be interested? > I've uploaded the diff to https://people.freebsd.org/~luoqi/lsan/. It's a= gainst > -stable/13, but most likely would apply cleanly to -current. Hey Luoqi, Thanks a lot for uploading the patch! I'm definitely interested in lsan, especially for ${DAYJOB}. I don't know when I'll have time to review/test the patch, but I thought I'd at least show my interest. If I do get some spare cycles at ${DAYJOB} for testing the patch, I'll let you know. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --yany4lrjthotfjwx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmHOE4wACgkQ/y5nonf4 4frh+A/8DR1BjGAKAxaF5HJICQo5kqh/fgySiXq+cSnz7caffMWRSPDoKW/6RVn0 EMz8FKhDxABRqPHKphW8rbkWrqxnzaea82GDEkujQpZpW1erNWilTAx4GNx3ypdY Oo4+OSDiLI3j97OJmukOM5KVEbsrJIJbZg305Y4exKnK/3q2F+WN+uzUPC+paAzf Ign6YUnT8ItFOLNL2JZfvCQu/yMAym0+pxsIO3PPuqr2YtELZqTIu0bOrU+4LwAH 0dwoQzCg1+Jfa12T/tHlQ+NraHKoYtyRHWsIZM+2i17MgiXOnUjrQqQPz+I5471j 36RU9KoFuarBO4YSK9IeWImonNKtXdPEfWF0nAtbDh8i+ZI4Dv+1F+2t6/8EiQQD mPCroZuaS7DzdN06+aDbFdR06mCEqCjpCStOVRD2NE6CvuEEE5rin7ewk7AvmmuG YiliQX78qchdF0wYAjFPJyW4cOPNQHDAgxMRE7+GFXxY46my68M0MvyuYVhTo214 txTu+8zj5c1Nq2Vj62Fx7cSRmu4ahScGTUQZfRW+3fVlo/ug5M7eyyCAqBdRt1Bo tAcoviGM/cHVJdHS7WGc6IPSrWxDw/atmRfi3WlCf7RPAMHeD5EknqAwXHWjIj+E 6/HB4xDwg39VY7wqQhkGqXILO5yV5srppx9e82dI85601dibRFE= =pYrB -----END PGP SIGNATURE----- --yany4lrjthotfjwx-- From nobody Sat Jan 1 18:44:04 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F2A7191BE7B; Sat, 1 Jan 2022 18:44:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JR9sM05Twz4X1r; Sat, 1 Jan 2022 18:44:23 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-pf1-x433.google.com with SMTP id u20so26017641pfi.12; Sat, 01 Jan 2022 10:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jr2PDLGqCk4ULqMmc0+XMQFSOsaE48vQGp3vxVsgSzs=; b=mykzB9epAA6hOcCbOZ86gsZ1r/EzN81uYugsyJNTnomT4cveW/9MdtYKqXOn2DqBOu wKpoMTr5fxITww0YWKXvedPdMQtFpvSnc+V6sWEU1bd5T8+zUh4vp36H3Bj8+NINkKUN hv1BxUjz6w6mWVt6Iw6wUkpGaiQ6HLL+RDBNfYywfpvc7JRWBQ9HWs72aUEXfkRfH7qv Ec8l2TROXK01ow39ZJRufRCNrWrSzyO8A6BtoQnM1FcwB6yvEKuAizXOWAmudVqTuqS5 UJTm5dJ/uBvBY0X7Eu0JFRYzg56BB5op7nkQhpLpoRR+M0+ygoMpUe/PGWXCFGXIJNbJ /AQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jr2PDLGqCk4ULqMmc0+XMQFSOsaE48vQGp3vxVsgSzs=; b=ZIfgnpuVO/fTJraaFio+zaG5f0ltcfnTTtJ75ndtjJGhHb6HAXreryWoWY5G4hYp7P CzBPUOQG/8lqI1EliqL2VeVbmld/mfYETGu6k6Mlu8bBHC28a7IDzRSjxDPcnv60qsE0 BUy+Smv1DIyMPMZqxqPSTNyasLm6SGsSb3Tn9qjWp+C8I6tF3pyxVNH+pSTQxiE9HzOL Avlen6QXvxp0qEbaM7obYcKSJ2eaQ4goVEvRC5x6oxcWQcx3Hljq0e4VDr8mvxMR3DYg wK09HV++ZT/QI6I/6YVli2BP+O9zs4ZpeJOyAoBoLi7n9EEx8QId79kH3CF3lH6/25MQ VeJg== X-Gm-Message-State: AOAM531M7HLdhghCe5Q4EZWQxQCkMARTdL+W44efTErbGqssFEd+bId/ XeHrCD7z/rxmuphm2eqFA7Qu0S3ySychOGvL8i/I4hZZ X-Google-Smtp-Source: ABdhPJz28XRsjRMdRBSgzCXnBu6j2tTQnAPrZ7sjcjyJvoBfuPvTUYFwTJ+fNfNW08gJ89mHmudJoG9wwkjvt/q0wbc= X-Received: by 2002:aa7:88ce:0:b0:4ba:efec:39e0 with SMTP id k14-20020aa788ce000000b004baefec39e0mr40355891pff.80.1641062656263; Sat, 01 Jan 2022 10:44:16 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> In-Reply-To: <02d9ca2a-2fd7-942b-f411-be007ef88327@FreeBSD.org> From: Ryan Stone Date: Sat, 1 Jan 2022 13:44:04 -0500 Message-ID: Subject: Re: schedgraph.d experience, per-CPU buffers, pipes To: Andriy Gapon Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JR9sM05Twz4X1r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mykzB9ep; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-2.08 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.92)[0.924]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::433:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I've definitely experienced the issue about different buffers rolling over faster than others and producing confusing schedgraph data. I'm away from home this week, but I believe that I have a script that tries to chop off the schedgraph data at the point where the most recent CPU to roll over has no more data. If I think of it I'll try to pass it along. Another issue that I remember encountering is that there is a limitation on the total amount of space that you can allocate to dtrace buffers and it does not scale to the number of CPUs in the system, so the more CPUs that you have, the less buffer you can allocate per CPU. I seem to recall that the limit being very small compared to the amount of memory on a modern large core count system. On Fri, Dec 24, 2021 at 8:08 AM Andriy Gapon wrote: > > > I would like to share some experience or maybe rather a warning about using > DTrace for tracing scheduling events. Unlike KTR which has a global circular > buffer, DTrace with bufpolicy=ring uses per-CPU circular buffers. So, if there > is an asymmetry in processor load, the buffers will fill and wrap-around at > different speeds. In the end, they might have approximately equal numbers of > events but those may cover very different time intervals. So, some additional > post-processing is required to find the latest event among first ones of each > per-CPU buffer. Any traces from before that would have information gaps > ("missing" processors) and would be very confusing. > > Also, I noticed that processes passing a lot of data through pipes produce a lot > of scheduling events as they seem to get blocked and unlocked every few > microseconds (on a modern performant system with the default pipe sizing > configuration). That contributes to a quick wrap-around of circular buffers. > > -- > Andriy Gapon > From nobody Sun Jan 2 00:28:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 711BA191779A for ; Sun, 2 Jan 2022 00:28:53 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: from mail.rickysquid.org (mail.rickysquid.org [104.168.201.163]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRKVr328Nz3nND; Sun, 2 Jan 2022 00:28:52 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: by mail.rickysquid.org (Postfix, from userid 1000) id 8878A40A14; Sun, 2 Jan 2022 00:28:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rickysquid.org; s=default; t=1641083331; bh=y9HWEL7LUtgL7KqvmwM9WwzRrKH+uhMWI6NN2g0rnQs=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=TT2Bb8jhHe0ux1WwJ6GMsG6B0/CIG9qz+XwxKTsm7QRZtzwS5S1L0dItCzHemgKKy KZND0w8WGkcVj8tyVIBSaBfT3WNlyNVaBaO8srXrP+QxLtlbWj31UjWv23+eP8q602 pj9L8ZQrXS6EsRXVnP8umMzR/91XLYLIVm4ifz+eXboxzeQqKbBNoB12t/o9sjFyxu TKMePO4ux8s/tMiVPIwcylq0LB/daDpjybTnXCe5YRmFqia9H9yUyuaaTksCD5j2BH 6F+dSHTcAorB9ZqMz81qxC1QQXiQxGtnRJ8v4knYk2i7ssTau7LB7UP3H8BeMIVP7E hpS+HeGN7staA== Date: Sun, 2 Jan 2022 00:28:51 +0000 From: rickygee To: freebsd-hackers@freebsd.org Cc: Shawn Webb , Luoqi Chen Subject: Re: leak sanitizer support Message-ID: <20220102002851.GA32472@rickysquid.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JRKVr328Nz3nND X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rickysquid.org header.s=default header.b=TT2Bb8jh; dmarc=pass (policy=none) header.from=rickysquid.org; spf=pass (mx1.freebsd.org: domain of ricky@rickysquid.org designates 104.168.201.163 as permitted sender) smtp.mailfrom=ricky@rickysquid.org X-Spamd-Result: default: False [-3.91 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; R_DKIM_ALLOW(-0.20)[rickysquid.org:s=default]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rickysquid.org:+]; DMARC_POLICY_ALLOW(-0.50)[rickysquid.org,none]; NEURAL_HAM_SHORT(-0.97)[-0.974]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:54290, ipnet:104.168.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hey Luoqi & Shawn, This is really cool - I have been testing on -CURRENT, and just needed to change one or two teeny little things and lsan is working in my hokey trivial examples anyway. Only changes so far were matching the method signatures in the derived SuspendedThreadsListFreeBSD class, to match its parent (actually the only sig so far needed amending was GetRegistersAndSP, where second param is now more complex type than before). Anyway here is a remote with the patch applied and my tiny little amendments: https://github.com/emgullufsen/freebsd.git example from testing follows - create leaky code, compile, and run) //CREATE LEAKY CODE - HOKEY EXAMPLE FROM clang ASAN webpage root@dougBSD14-vm:~/mem-leaky # cat leaky.c #include void *p; int main() { p = malloc(7); p = 0; return 0; } //COMPILE root@dougBSD14-vm:~/mem-leaky # clang -fsanitize=address -o leaky leaky.c //RUN root@dougBSD14-vm:~/mem-leaky # ASAN_OPTIONS=detect_leaks=1:verbosity=3 ./leaky [cut output] ================================================================= ==3753==ERROR: LeakSanitizer: detected memory leaks Direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x28fcdd in malloc /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 #1 0x2be638 in main (/root/mem-leaky/leaky+0x2be638) #2 0x2373df in _start /usr/src/lib/csu/amd64/crt1_c.c:73:7 #3 0x8002e4007 () SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s). //END OF TESTING EXAMPLE So I have only barely tested this and will continue with more involved tests, but anyway wanted to shoot this out - thanks! -Eric (or ricky, whichevs) From nobody Sun Jan 2 02:22:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 10869192E462 for ; Sun, 2 Jan 2022 02:23:05 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JRN2c0T7jz4WkV for ; Sun, 2 Jan 2022 02:23:03 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 2022Mv6m009040 for ; Sun, 2 Jan 2022 02:22:57 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 2022MuOl009039 for freebsd-hackers@freebsd.org; Sun, 2 Jan 2022 02:22:56 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202201020222.2022MuOl009039@donotpassgo.dyslexicfish.net> Date: Sun, 02 Jan 2022 02:22:56 +0000 Organization: Dyslexic Fish To: freebsd-hackers@freebsd.org Subject: [patch] touch(1) enhancement User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sun, 02 Jan 2022 02:22:57 +0000 (GMT) X-Rspamd-Queue-Id: 4JRN2c0T7jz4WkV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I've added an option to touch(1) - details here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260871 It adds "-R", which is like "-r", but in the case of a link, refers to the link itself. I'm not sure what the protocol is regarding adding "non-standard" options to standard commands, so please don't flame me if you think it's useless! Cheers, Jamie From nobody Sun Jan 2 06:16:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 812E4193FA39 for ; Sun, 2 Jan 2022 06:16:40 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2050.outbound.protection.outlook.com [52.100.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRTD749cQz3CSv for ; Sun, 2 Jan 2022 06:16:39 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=icsRjwvuPH6fM+b9LP5p9beQMMhOWHbJL6jf/BI1E01O8pVkHXzxYA3WJbDisZLrsQgOTwKd/R1A419vABzYjaHn1YOga89Kgrfyj7i1ndv4q9d5h7tJVeAm0zk9VDnq9s5oXLcv3Q2i3tg1q4xZEV6nqj1Tt6DZFBzvziuyCU0Z0NHplJdvoabw6Ag7H6zl4rEm1L+ThRNnLQxdNb7LQPTiKejZ9MA5FQQx8Evom46+iM4Vl2b5TqNYJK0a+Dg4dcONWcVzlW3xNLIm+Be+lohUSm/40f346a6SA/a0/C6rJl5DuB7AEI5tVeFxioInk4SveD49XFNT+OsGNKm9hA== 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=NxPSzeomp4/9UpSByv+TKNxdSUqTZro3f93QLWJJQ+I=; b=NRTQwHEhoad/0UIjSPuIhmSSklY3QJxy2sS0r4wo0RdWXmceckU3KDOr3pmv4yWOOsFIN38ZpPve39uP09f61h0p7i3pZJSvhNnjgBkYbIbZAp5O3P0hOnv84Z4JVzoraAVu3Fqlox1OXntX4wnSOEL8NSPaNPKx7aZ5DdYlzGWa0DKmsvDj+sHy3Muj7ifG3IrIffWx+gZEA/7id+zccU40c+Ntq8j1zEBmZ+8HaGppTjQTLY/nRby4yFsF+dLEgGLYzZUxTgRnY/r19CmQP9tgoMdtbnT2CNk0tkmPHxEd5tpBaBoGQlrIA6iA92q0fna2KQFDROVyvS3cfxyWAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NxPSzeomp4/9UpSByv+TKNxdSUqTZro3f93QLWJJQ+I=; b=ZDHWtAMiyxrHcGI6QcCRNPTTIwV2altOQPnk1DzeeCnuC9ve1V7rj2I0lP+AuTMtMmFeHDBwFzaEP0Kf746eDl4MXxAk1d1LjXf4xufRwgl6ABg9B9jgAd3KyPZhJ1p1SNOCg0EJd1YWYu79lRWvg68GqvE1gwZJkG1M4DpNO5pEpblPbAJq2OUafPFTfJn4LyIBwpKgxc3FbuAbC3oeiBuVsiQ9YTTvZG1P4w6+Pq91u6FxCCjNGif31utwPTlH09rNtT6c2ASdg5IdJtTExNVBpvAzaNNA1xR9+cmzAiklfQqNF7m2r5T6OzzsHtUy1orgoxy8cJ4p9dTDit77dg== Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:11a::9) by TYCP286MB2003.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:15b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.14; Sun, 2 Jan 2022 06:16:31 +0000 Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::4d39:4ab4:e041:c6f5]) by TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::4d39:4ab4:e041:c6f5%6]) with mapi id 15.20.4844.015; Sun, 2 Jan 2022 06:16:31 +0000 From: Daniel Cervus To: "freebsd-hackers@freebsd.org" Subject: AR9462 still not working properly Thread-Topic: AR9462 still not working properly Thread-Index: AQHX/51q64ieRyYR40Ob8xn4ikKeHQ== Date: Sun, 2 Jan 2022 06:16:30 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [AvXKTSqh52hX9e05161iAyl7y1fCCJN5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e3cbd6ab-873f-4aec-4fc5-08d9cdb76b3f x-ms-traffictypediagnostic: TYCP286MB2003:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: abJkYyD9zHmtJt5+leWh+ui1TK+anDHQQVGXQd5SwDp1MgeANhDd3osv7soeN4AuNtdrZpK8OoXBHFF1TEugZ1XYRB+8tQUZexGQ9qqLlyoXUexkzLusWiQIHgPFETJ7EyUGQiOsGXke8fEQxEA7376/blErwXbvOvmaMS7na87aa++LQlYvVWb9OZzx8yUioDNNY9QW8l3rqpTcZV6vfYIgMyLRK3eeQc6X3kiWSxT8rdri765vt7KxnlCyJFFOv2zDYuzZqitx9HJuwlc5MZToLqAmh7NEXzH6at+nr/J9zjuKRMA/pvQbdFfQDDS2ZStIp3GuWFyOCoTUj1MCUAXChRrTLxg8j68JQBJNnH/th7rGLxxr3UGOZBBH9MvACCK2vxBHEJgGKRWvxvQebZmmBN7/QQP3hyuLt88dwFnIwtBU+CCsNw8/ZRLoUh6DeZASrvt+Uq1ElQR181g63EtpJmrCg8A4TKzb2D/9FMR8GgD6p8t1ukBC6QSdbd+jDmCLgGk7PmKZ0L9WfZqDw+gqakrOlEuIfsZvy1Z3Y71Lek9DNmg4Q72CTq4FQ8XXumMjNzeY4ULXfH+VxhDaxw== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?S2QqdsWf1jR48MAdnmYZmgHkidp+YMU/Eh5l/ZnssCAHn+9otE8suD+V?= =?Windows-1252?Q?oE1a8KZkvBDbWj89JfAjtVot4hfOdaLCy1bJSHmftj4guzPYIc12LtZc?= =?Windows-1252?Q?GhHZCWeqzCJ+NkMpoV5p+LtKSNWS8bCTi/OJSASvCTET8ATR09ZEuIgg?= =?Windows-1252?Q?mGiKvN6GM2JLBm3pfvAXGoNfrqlkCwnQSelgBUVVhMJZ6qXEf08JdWKU?= =?Windows-1252?Q?pd8t3DfNTap/L0Prx7tMm8qIvPX07r/Am+JDMpAkr/dPSN3WhFF+aXRp?= =?Windows-1252?Q?sOCk/mDDbM85IqZd/uuf73KbDAcVzngZoSRoSYb79v7QoZj9YRW8bua7?= =?Windows-1252?Q?0wr5vZ22hmWEkpq95vwQocE348b2mCvbJshY7uuOB1HuvdLK5HtYOjTU?= =?Windows-1252?Q?mrInZT49EjCgDz1OrkrZOvnLK1pRIgsl6tIdHm3FzvB8e/k+AwxyowPx?= =?Windows-1252?Q?Yic/D9ym6SmdE9u4mP4hNUGFqTHf0Q+ocKPQASqO5/siyIU71a8ri2XK?= =?Windows-1252?Q?NYO4cOzGYjPlD//j0/gNjh7Ashlt6i3y43oJh5Tnk3W7XmeR4J4vzsKf?= =?Windows-1252?Q?D7Oj+XiYfXdVI0CJ4WxWVp2f5BnTDl2Wo7rnH5XpV3XrHfCQXlX4ELWw?= =?Windows-1252?Q?z/laqDRBCkJvAXEN5EE+yS8SGcYhoo88IFK+RnrEart0Fo8SZMHMumbH?= =?Windows-1252?Q?yEcFYotjuTWwF6+Zqk9rTrO+a7GZYSKWAO3DRZ3tfwJeAops0EjCIwxL?= =?Windows-1252?Q?ejQov3XuFkS3/j8sYMeMzq5qvKivv7218jw/pSU9x/0l3TC9nej8SMw+?= =?Windows-1252?Q?3KGn4LTNiqu6EKB5Sl1qF2RKvwHuj2JhchtEDGNEt/Bz3AKFw2Rcm3Ra?= =?Windows-1252?Q?OOt99kmEgD5jjb1xVAzc2Pzr527R+nPhkxTMTHHIkM7BQElOwGQEtKrE?= =?Windows-1252?Q?p6w+k9FxNrs/7JWctDcOGqiAI32uPdc3hatiLh5G5hp2ZbuerGVVKW7S?= =?Windows-1252?Q?bh73gL6fOYW20odpAhrZFoa1h7vKaMnvJNXRli2qQ0QBoDH150w=3D?= Content-Type: multipart/alternative; boundary="_000_TYYP286MB154633FFD6D26EB8ADB3F24FB8489TYYP286MB1546JPNP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: e3cbd6ab-873f-4aec-4fc5-08d9cdb76b3f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2022 06:16:30.9300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCP286MB2003 X-Rspamd-Queue-Id: 4JRTD749cQz3CSv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=ZDHWtAMi; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 52.100.215.50 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.49 / 15.00]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[outlook.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; NEURAL_HAM_SHORT(-0.49)[-0.489]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[outlook.com]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[52.100.215.50:from] X-ThisMailContainsUnwantedMimeParts: N --_000_TYYP286MB154633FFD6D26EB8ADB3F24FB8489TYYP286MB1546JPNP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, everyone. I have been using Dell 1901 (AR9462) wireless card since r= elease 12.2, but minor problems keep occuring. For example, it cannot be re= cognized in bsdconfig, when not connected to networks, error message =93Fai= led to add operating class IE=94 repeates. I remembered someone has told me= that he would deal with that. Now, I have done a brand-new installation of 12.3. But bsdinstall still had= diffculty in scanning Wi-Fis, and after I had tried a few times, no Wi-Fi = could be found at all. How to deal with this? I have put up a PR about that= . I=92m sorry for that I may have described the problem unclearly there. --_000_TYYP286MB154633FFD6D26EB8ADB3F24FB8489TYYP286MB1546JPNP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hell= o, everyone. I have been using De= ll 1901 (AR9462) wireless card since release 12.2, but minor problems keep = occuring. For example, it cannot be recognized in bsdconfig, when not conne= cted to networks, error message =93Failed to a= dd operating class IE=94 repeates. I remembered someone has told me that he= would deal with that.

 

Now,= I have done a brand-new installation of 12.3. But bsdinstall still had dif= fculty in scanning Wi-Fis, and after I had tried a few times, no Wi-Fi coul= d be found at all. How to deal with this? I have put up a PR about that. I=92m sorry for that I may have described t= he problem unclearly there.

--_000_TYYP286MB154633FFD6D26EB8ADB3F24FB8489TYYP286MB1546JPNP_-- From nobody Sun Jan 2 08:10:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 46968191EBBF for ; Sun, 2 Jan 2022 08:10:05 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: from mail.rickysquid.org (hwsrv-751118.hostwindsdns.com [IPv6:2607:5501:3000:207d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRWl03t2Pz3PwJ for ; Sun, 2 Jan 2022 08:10:04 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: by mail.rickysquid.org (Postfix, from userid 1000) id 53F3B4196E; Sun, 2 Jan 2022 08:10:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rickysquid.org; s=default; t=1641111002; bh=mON5YbRojmpHuD0zegQpcrlM54b6+WIxUe0CDljUUs8=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gPuoywwtcip8H87FrRY6iolCO1TJmZ1ko86+bw3aHgcADu2CkmEtKm7Lruzn6lKmr gBpGtE/ybiShn9cQspUXrp2xujPHhZnFtqqEniK/tcEMl9oL9T14CGTapaSrRVV+EL H96xCrdu2a+p0Jw8gQYbCUsNibTICCCzUTOR3JKJ2gDQt6W3qZGqxNJL+xjt1xw0sr SAn+rhnorW5lzwA/lwkt4TMd+u0dJwMeXfDaXbIKUG/eVBtWzoX8QboYbfsH2QCgsE JdO1uOb4xoE7uw1MOLKu/UtqohAgo6g1BQevaQNruJZ/NIUJ+Zqdg0uMG5MY2p16Nm A20GnnUOciG6w== Date: Sun, 2 Jan 2022 08:10:02 +0000 From: Eric Gullufsen To: freebsd-hackers@freebsd.org Subject: Re: leak sanitizer support Message-ID: <20220102081002.GA5827@rickysquid.org> References: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> <20220102002851.GA32472@rickysquid.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220102002851.GA32472@rickysquid.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JRWl03t2Pz3PwJ X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rickysquid.org header.s=default header.b=gPuoywwt; dmarc=pass (policy=none) header.from=rickysquid.org; spf=softfail (mx1.freebsd.org: 2607:5501:3000:207d::2 is neither permitted nor denied by domain of ricky@rickysquid.org) smtp.mailfrom=ricky@rickysquid.org X-Spamd-Result: default: False [2.92 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[rickysquid.org:s=default]; FROM_HAS_DN(0.00)[]; HFILTER_HOSTNAME_2(1.00)[hwsrv-751118.hostwindsdns.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.73)[0.729]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[0.995]; DKIM_TRACE(0.00)[rickysquid.org:+]; DMARC_POLICY_ALLOW(0.00)[rickysquid.org,none]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:54290, ipnet:2607:5501::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Here is patch for the tiny changes for after add Luoqi Chen's implementation of clang lsan for freebsd: https://raw.githubusercontent.com/emgullufsen/freebsd/lsan/lsan-params.diff ^just changed *buffer to InternalMmapVector *buffer, to match declaration Thanks! -Eric Gullufsen From nobody Sun Jan 2 17:53:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 56327192F349 for ; Sun, 2 Jan 2022 17:53:19 +0000 (UTC) (envelope-from luoqi.chen@gmail.com) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRmgz1jzwz3sGy for ; Sun, 2 Jan 2022 17:53:19 +0000 (UTC) (envelope-from luoqi.chen@gmail.com) Received: by mail-lf1-x130.google.com with SMTP id g26so70735917lfv.11 for ; Sun, 02 Jan 2022 09:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAhvvgvXASmsq+qKv/YDkt6AWu0NPocIEezbkA3DID0=; b=SnYLPI0MnOFo+hgAn6tOm7K8VfkQ17W76+7/ohC/mBk0bqey6l2ewFVeB4cGfGbKug E91sezebW3vhYxNaZsU1grzDyON1rUgh1YxdjC3OGPKP+NNErNL5L9hL/NS3ys+JCvw1 1ZfU3HzUUqtavMOqhYOv7Y3uEAs7Ae1xhKcRanDmTa0nsb/uk6fyiokVBpzXIm2c0QtY 0vuXt/z1ID/DxhxH9SokfULDNMM+7PuEvRi9vvB41/KiDBKGFIwH18wjjJbT3rAU3Alo FqqY9EPzd0XLOVykESGV4VhyCGmh15srCHMUla/z+IIW3gsuWidBq+gkVVJT3kCcDAeT r7lw== 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=VAhvvgvXASmsq+qKv/YDkt6AWu0NPocIEezbkA3DID0=; b=uGX/jzdS+8oYlqOn9eVgoe4EOtmWgmf7gdma2/vLcWk9iRK87939x6qdGY98ftexiW 2UCpjnuworleLBsAuf9XtnY4+UCVQ1/INQKC4RL3JURWiwNm9syqG+pV9PLJYjRWUuT/ m+JzCKCjP5mr1e0lLlJmePWSIueD+GQT60rfpeDNOAmcjsaj6mlfLPIPtBjjmAcwCFS+ f64A4bCmV6xik3yi/i3szuJMA8Kx+pHi4MRQbZ5wr5QE5W9bTEzHljm0AwYqtktIfE7B QztXTYpKUEyoV27Pocf5CjHnz3k6dPbcwBUshLQ1YqZ3+UKW2ML+YqOodSV/brD9JN1R HXIQ== X-Gm-Message-State: AOAM532YoLrTsqHfzLHN36oyDXqmLkbzAPbOiTv4H7L8GXOovBYlwmOS i+LftGz1E2yoMII0UE8oC+BV+n9lLzgDwK+p6/aoJG8/BV8= X-Google-Smtp-Source: ABdhPJwHlEnr6LNcsVM3SWlL/Ij9m8b1k2oVaUmU91z0TZScwQbAPZECwMILE2DBqif+J67j+WmFyl8Cq9vX7/dhlxg= X-Received: by 2002:ac2:5547:: with SMTP id l7mr37856299lfk.324.1641145997945; Sun, 02 Jan 2022 09:53:17 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> <20220102002851.GA32472@rickysquid.org> In-Reply-To: <20220102002851.GA32472@rickysquid.org> From: Luoqi Chen Date: Sun, 2 Jan 2022 09:53:06 -0800 Message-ID: Subject: Re: leak sanitizer support To: rickygee Cc: freebsd-hackers@freebsd.org, Shawn Webb Content-Type: multipart/alternative; boundary="0000000000003b6fcb05d49d1472" X-Rspamd-Queue-Id: 4JRmgz1jzwz3sGy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000003b6fcb05d49d1472 Content-Type: text/plain; charset="UTF-8" Hi, Eric, Thanks for trying out the patch and adapting it to -current. To be honest, I wasn't very careful about details such as locking, it was meant for internal use only (and the fact that these details don't usually matter for a normally terminating process). For a wider audience, it's better to tie up the loose ends. I've spent a little bit of time to fix the potential locking issue and also to cleanup some unused code, would you mind trying out the new version? I've updated the diff files. -luoqi --0000000000003b6fcb05d49d1472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Eric,
Thanks for trying out the patch and adapting it to -current. To be honest,= I wasn't very careful about details such as locking, it was meant for = internal use only (and the fact that these details don't usually matter= for a normally terminating process). For a wider audience, it's better= to tie up the loose ends. I've spent a little bit of time to fix the p= otential locking issue and also to cleanup=C2=A0some unused code, would you= mind trying out the new version? I've updated the diff files.

= -luoqi

--0000000000003b6fcb05d49d1472-- From nobody Sun Jan 2 19:35:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B7221927CB4 for ; Sun, 2 Jan 2022 19:35:08 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: from mail.rickysquid.org (mail.rickysquid.org [104.168.201.163]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRpxS1G5Jz4h92 for ; Sun, 2 Jan 2022 19:35:08 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: by mail.rickysquid.org (Postfix, from userid 1000) id E0EBF41997; Sun, 2 Jan 2022 19:35:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rickysquid.org; s=default; t=1641152106; bh=scmP0hJ3qiYn1CPl2rFQmU4HIEMoIX83FNw4YXT5EyM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cvjcUGi63PqnDpSnut3QcVxg4ZL2BiTHw0OGI2dWI58Ur2nTKqfQUlXOjHsGkyNiM Bl1O6XbeVqkZXWZVYE6SU5mcMjEgI3AHqOZWBbkSbh1rn/H+z+5rPS3aO1dmv3A0rg /1pN+iE0nuET6foEz453rE4TbyWYSeniKBYGP5VDYt9gsZw7q78IRbmX/MVmFAEfdw uytW67QHIRQcFbtcGwco1+JnsJG2+PIXMgs4X4mdiUH1SrIT/0YoPsgHXisWPm7Ts6 xDvNxzxIV2td08lJrCA5TWoTUT4KyEl2fRnFiw0zw1LIdpW/CoL8oHwRYUQhbxjed3 tg+6mM6Ijrnvw== Date: Sun, 2 Jan 2022 19:35:06 +0000 From: Eric Gullufsen To: Luoqi Chen Cc: freebsd-hackers@freebsd.org, Shawn Webb Subject: Re: leak sanitizer support Message-ID: <20220102193506.GA6478@rickysquid.org> References: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> <20220102002851.GA32472@rickysquid.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JRpxS1G5Jz4h92 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hey Luoqi, Awesome sounds great - will test with your new diff & module files posted & report back here in a few - thanks! -Eric On Sun, Jan 02, 2022 at 09:53:06AM -0800, Luoqi Chen wrote: > Hi, Eric, > > Thanks for trying out the patch and adapting it to -current. To be honest, > I wasn't very careful about details such as locking, it was meant for > internal use only (and the fact that these details don't usually matter for > a normally terminating process). For a wider audience, it's better to tie > up the loose ends. I've spent a little bit of time to fix the potential > locking issue and also to cleanup some unused code, would you mind trying > out the new version? I've updated the diff files. > > -luoqi From nobody Sun Jan 2 21:01:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5AF7C191CDE2 for ; Sun, 2 Jan 2022 21:01:59 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: from mail.rickysquid.org (mail.rickysquid.org [104.168.201.163]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JRrsd4wBxz3FMH for ; Sun, 2 Jan 2022 21:01:57 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: by mail.rickysquid.org (Postfix, from userid 1000) id C670545643; Sun, 2 Jan 2022 21:01:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rickysquid.org; s=default; t=1641157316; bh=JMpZeqQ5dfkRJHHfb/mHqA4R+W3oQkjbd6g6v49xzkE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NYtcd4cUgbGFYUnO/t/L2CKOeZcmC8ib3eqP5eNJ/eEg40B0MCg3f4EYRankZGlZ7 2jLwecdPULCAYnfftUQ5SEt/63KxougauXIeXbWzm6IFKIm6PlqLlI2e3nj+qmZLwb cogcZdAl4zJlXytmy3J9/7mXWRggscSUjcUDbU3PH6tgPYbJxX/+3VFMK//eCzfgnx T2cHf8xNVk6Xs2izXvaRVbCF5i1KEmYuj2stxyqDZlmFd+qA8r7Yj7Od4AM1hJfWkg 5sSdZ4cD8xbUe6e8w8toJGMI4nEPZ0Uu/n2Xbu0ynVnp9mfle/x60qbiIZaypjoLuw Vx/L1egKZJBBA== Date: Sun, 2 Jan 2022 21:01:56 +0000 From: rickygee To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: leak sanitizer support Message-ID: <20220102210156.GA16266@rickysquid.org> References: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> <20220102002851.GA32472@rickysquid.org> <20220102193506.GA6478@rickysquid.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220102193506.GA6478@rickysquid.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JRrsd4wBxz3FMH X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rickysquid.org header.s=default header.b=NYtcd4cU; dmarc=pass (policy=none) header.from=rickysquid.org; spf=pass (mx1.freebsd.org: domain of ricky@rickysquid.org designates 104.168.201.163 as permitted sender) smtp.mailfrom=ricky@rickysquid.org X-Spamd-Result: default: False [-0.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[rickysquid.org:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rickysquid.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[rickysquid.org,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:54290, ipnet:104.168.128.0/17, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jan 02, 2022 at 07:35:06PM +0000, Eric Gullufsen wrote: > Awesome sounds great - will test with your new diff & module files posted & > report back here in a few - thanks! > > On Sun, Jan 02, 2022 at 09:53:06AM -0800, Luoqi Chen wrote: > > locking issue and also to cleanup some unused code, would you mind trying > > out the new version? I've updated the diff files. > > > > -luoqi > Hey Luoqi, Dang you rock - I applied your updated patch against -current (commit 642f77be1d), and everything went swimmingly in initial testing: //GRABBED PATCH & APPLIED & BUILT/INSTALLED libclang_rt libs https://people.freebsd.org/~luoqi/lsan/ //TWIST SYSCTL KNOBS (PIE & ASLR) # sysctl kern.elf64.aslr.pie_enable=0 # sysctl kern.elf64.aslr.enable=0 //COMPILE # clang -fsanitize=address -g -o leaky3 leaky.c /* leaky.c */ #include void *p; int main() { p = malloc(7); p = 0; return 0; } //RUN # ASAN_OPTIONS=detect_leaks=1:verbosity=3 ./leaky3 [output cut] ================================================================= ==785==ERROR: LeakSanitizer: detected memory leaks Direct leak of 7 byte(s) in 1 object(s) allocated from: #0 0x28fcdd in malloc /usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:129:3 #1 0x2be638 in main /root/mem-leaky/leaky.c:6:6 #2 0x2373df in _start /usr/src/lib/csu/amd64/crt1_c.c:73:7 #3 0x8002e4007 () SUMMARY: AddressSanitizer: 7 byte(s) leaked in 1 allocation(s). //END TESTING Sweet! I'm not much of a c++ person but I am stoked to read up a bit more and see how you made this work - it is super cool from what I can glean so far - learning times for me - thanks! -Eric From nobody Mon Jan 3 23:40:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9987C193DD91; Mon, 3 Jan 2022 23:41:05 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSXLm0wzzz4hlm; Mon, 3 Jan 2022 23:41:01 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-qv1-xf36.google.com with SMTP id kk22so32776367qvb.0; Mon, 03 Jan 2022 15:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=vVt6x/YFsbXPbfsyz1LmXL1sWIw2Ox/oed2XBV8Vqh4=; b=glgej2U0Iogh1QSw623fquZxI7TP8D7R+aq8TyyIqCz4ujCnaMRKd2hfa6a/MEkv12 3eBxqo+oV/gOr0kq4ECVmuPZucNDG7qal3ckQoiw55fBH9RJHtNVcSilOWxwKic88/7M fnsOvR7JhdpZ677W3MvUm/pKz6+hGDuXZV/Laf5DioBx7IELS3RbDLk2yo/7/CzIJ7SQ 7Es5R5crKkHFr3u6YnDaicDiDfG5+TzhlyDtiXsnngRcLlx7A+rIT7+ChmzgaH+q4+3R ZvztzH7pahFpf7YKyy5RQMHX3s4bvWHRPQW9zXEp5Xyt0a8k4NsSRTzF2LyBTZF4BgYc v0oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vVt6x/YFsbXPbfsyz1LmXL1sWIw2Ox/oed2XBV8Vqh4=; b=KDs5DYlEZWzq12UY4eqMT+GMIfRIupG3lEbgj8JF+yjcBXNnjCbjmT2nD0lNY4Mb3I DbVo4M5pzj5mFfV/dVXNnuFZQgECLW7/rG73GnVzccBsGWFvcYTDyy0cqXWM+KSA46DH IQej3cRjHbQ+dmITQ+X95x5Kw1+GTtk8ygzhlawnOguVNuxJIQ3710vtAziyPpK7N5ts II1930g5cEr5bkT7tdaTkAWGpidGFwKaEBo9u8n3szA7UrNZMVYCC6z0vNRtr+clq2lH PVOMTLUTQUyILrDseG1J68RZsH3PS3nxQ7eiaLWjDenCIgvuphV4MKGiIIe6mzEiVlLl LUkw== X-Gm-Message-State: AOAM531ZZjjOIhl3HQf4UR1F4lBO4MgLeaNsIvc5Hf1b/J5vbLnhVLNI yS4GWjKHl2FqlsyDKMA15qdV+bMEhYSmpVsfJXPeXJdTypA= X-Google-Smtp-Source: ABdhPJx75ThKxo6pgJ1vrcBqS83hfiq9fFPjT4nNYxEOjqNFHIAeiDpMx+PQzJrdi0c/bfLruirEs9N7OEwiytSRxtE= X-Received: by 2002:a05:6214:2583:: with SMTP id fq3mr43759668qvb.94.1641253260579; Mon, 03 Jan 2022 15:41:00 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Luna Jernberg Date: Tue, 4 Jan 2022 00:40:48 +0100 Message-ID: Subject: Introduction Luna To: kde-freebsd@kde.org, freebsd-women@freebsd.org, test@freebsd.org, freebsd-chat@freebsd.org, freebsd-translators@freebsd.org, freebsd-i18n@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org, freebsd-testing@freebsd.org, freebsd-amd64@freebsd.org Content-Type: multipart/alternative; boundary="00000000000095581805d4b60de9" X-Rspamd-Queue-Id: 4JSXLm0wzzz4hlm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=glgej2U0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=droidbittin@gmail.com X-Spamd-Result: default: False [-3.16 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.17)[-0.175]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[10]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f36:from]; NEURAL_HAM_SHORT(-0.98)[-0.983]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000095581805d4b60de9 Content-Type: text/plain; charset="UTF-8" Hello! Just wanted to send an email to introduce myself i am Luna 31th year old non binary GhostBSD/FreeBSD user and see if posting to the lists works i have been involved a bit in the FreeBSD community in the past (PC-BSD/TrueOS Desktop/FreeNAS days) and now running GhostBSD on that old HP laptop with Core 2 duo been helping out at EuroBSDCon 2015 in Stockholm too and visited the one 2016 in Serbia and the one online last year, and the BSD Meetups in Stockholm so some people might recognize me already, but never thinked about joining or posting to the mailing lists until now --00000000000095581805d4b60de9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!


Just wanted to se= nd an email to introduce myself i am Luna 31th year old non binary GhostBSD= /FreeBSD user and see if posting to the lists works
i have been i= nvolved a bit in the FreeBSD community in the=C2=A0past (PC-BSD/TrueOS Desk= top/FreeNAS days)=C2=A0
and now running GhostBSD on that old HP l= aptop with Core 2 duo=C2=A0

been helping out at Eu= roBSDCon 2015 in Stockholm too and visited the one 2016 in Serbia and the o= ne online last year, and the BSD Meetups in Stockholm so some people might = recognize=C2=A0me already, but never thinked about joining or posting to th= e mailing lists until now=C2=A0=C2=A0
--00000000000095581805d4b60de9-- From nobody Tue Jan 4 05:11:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F0BC119214DB for ; Tue, 4 Jan 2022 05:11:44 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSghJ0p5Wz4XCt for ; Tue, 4 Jan 2022 05:11:44 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id h2so68609642lfv.9 for ; Mon, 03 Jan 2022 21:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=IPwsl9AF0w8c3NlH3nReJzOA91X/6BwcQXz0/aOhweA=; b=PAREQivmXNsJiuN7SySROt4WhcgMImrt/72B9IySS9hYgkXnYiTDJaznjnh/eeqxef uzKUoYokW0P6pcPGk6XhcjgUFLIZMi/LnjPsE0yL8aK1NHQv8Y2TT147SCotYp75udiQ cJfQlvIRrnOfhZLOGKoYZ9V6yRvMEv5R0VxZ165ocN89D1vIVLyo20qz9wg9oFWd3p2k NBnaTHA4eH5802G19zMutQtEvypHDfxHB6IY9x1UQuPP1Ql6MlTlYp407qHbg22oY7/2 5yGolrYhvOHFE8GlQ8Wh9QASV5Tz/qSYuNLF8oDmQSsbhElhDIsDS0hIVKlLMMuF2gM2 /ttg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IPwsl9AF0w8c3NlH3nReJzOA91X/6BwcQXz0/aOhweA=; b=fp/Z9oxxxUMYJ4fdOrT63kOZ+ya20YGGbEtwQf7pi6IO//xdvDLUfBisoICTIKGx0f EffhSE1y/ebOmrbQzA3EgMEKXlEVWe5UrituYIBHU9t/w2G24inTwZL8wYE4pIXEg21D N/tH5obpXtanWXgu+dHiSYfyY/YjgA2r0yUduCgCxENX93s7TY/VisMZOWz1w7iX53m/ +GrKCR0/ILdWfM9U8ksy3JeWI7K4Fk1osfmmHWUotZOlnj86V5UwNPcBzMhkso8jhBlR zv4UkjM7iYqQz3axNUWvvUAfaEfQIQHLXquO2/V6LbJd2M/VwlY80/hEBf8hefe9zj6B 1yAg== X-Gm-Message-State: AOAM532IExAM+uDWoVc29Em1OlENRHeeww6nLgLst9mSUeUzCFb0G/u3 bC4TC3X5mSzzm9JH3aUYBd0zfUnkzzSJ4x2mDZ0q8Si6 X-Google-Smtp-Source: ABdhPJxee663SoB7mIMYZVprs3McB6En95VyKpiESX3TEngnv5ndBaDt9VO74fXNsfGF9aNWdnYY0qAkgf6CmaqFBDc= X-Received: by 2002:a05:6512:324f:: with SMTP id c15mr42471692lfr.465.1641273095751; Mon, 03 Jan 2022 21:11:35 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Mon, 3 Jan 2022 21:11:35 -0800 (PST) From: Stefan Blachmann Date: Tue, 4 Jan 2022 06:11:35 +0100 Message-ID: Subject: pkg 1.17 and later: What's the recommended way to fix problems due to removed keywords? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JSghJ0p5Wz4XCt X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PAREQivm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [1.54 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-0.21)[-0.207]; NEURAL_SPAM_MEDIUM(0.75)[0.746]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hello, Using FreeBSD 13.0-RELEASE-p4, I am stuck trying to get apache24 from ports built and installed. There are two problems: 1. complaints about the correct setting of DISABLE_VULNERABILITIES option: the first build stopped, telling me I'd have to set 'DISABLE_VULNERABILITIES=yes'. The next build complained that the variable would have to be set to a "boolean" value. What would be a "correct" value if 'yes' isn't accepted? Anyway, the build proceeded. 2. Using the command line "make -DBATCH -DDISABLE_VULNERABILITIES install" the build part seems to work. But, after the build pkg-static complained that it does not know keywords "preunexec" and "postexec" and aborted. Searching the web led me to the porters handbook: https://docs.freebsd.org/en/books/porters-handbook/plist/#plist-keywords (see section 8.6.13.2.) Searching further, I read that a lot of keywords have been removed with pkg 1.17. (See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257384#c1 ) However, the porters' handbook doesn't mention the keywords as being deprecated. My questions: a) what could be the reason why pkg does not install Apache24, instead putting out these complaints? Have more keywords been removed than the porters' handbook states as "deprecated"? b) what would be the correct way to get installed apache24, and maybe other ports that fail the same way? Thank you all for your help! Stefan From nobody Tue Jan 4 06:01:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C1FD192D1DB for ; Tue, 4 Jan 2022 06:01:38 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JShnt0ZzKz4dyk; Tue, 4 Jan 2022 06:01:38 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12c.google.com with SMTP id u13so79261633lff.12; Mon, 03 Jan 2022 22:01:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/84TgZFFLBuRk0yzYgm75xUdNEiZPLTeyaCV6eNV3Xk=; b=Tm7i2Bjm36wvOoavHaNNcZVSG192ZEceOEAoq5Ni6TUXQy3zsHAyd5XH4trKsk63md sGDwl8hk9sIoOqJlabI/9nVodKmpxDsASR6KNe7ox2h6+YE/um0s1k6vStbm7a7TDXF5 N9sCK3ZD/FPvE3Ia9BjyHZAhUmUmpM7YtzJn0aUzKRdli1JyTZ3+ZyM+yHsUFV5Viya9 cfZ9DFHbjWrd2nGWiGAQ7Hb9qNSGMDPPHB/MM2gDvpxCHW0ICYnvwN9DWZz+PcYvUNe3 ioaMPcBsfYWs1vs3OLykY7/FAzTZQwuoSROn52zPIiMA0J2wFCmwYydYdixgxL008WMK Uq2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/84TgZFFLBuRk0yzYgm75xUdNEiZPLTeyaCV6eNV3Xk=; b=YnxBgkr9a4mceBDxdigoPTUzYqCGgU/IXngbcOsOKp6/JjhPeCG8kWY7VTEoZum2xB wz+gmQGPfDtWgxDo6AG5+e+lUa35116TSIebce8TO7Nrae1RFq8hbpI5M+kxqTwh8w// PQE+8xXQ0a+xQDWVDbly0p5QAdA0xxciuoeDGee58R2pjOjpy2Hab5TjzNSdUO3q3A6L jP46aWU60A2BpViNcPDrF55UX5lk0g48QFi2ydsMw8BE9pySkdZjJrtyBUsWGgryNZn1 5b1OhdkrNXps2DXmajp859hChmTHUSQphUWc0AFCPfm0TirfGul+BrlTrZnoVT8fQvv8 benw== X-Gm-Message-State: AOAM532k9Bb0MTAkaWuQmZQmqKX1mEADy7s0Aw3U7KaPIqA2YqG7HdNA kCJcheeqEaU0hfnsc/QKei8cjo/gc4Fy04dAf4P7A9ZZ X-Google-Smtp-Source: ABdhPJybn+Bpcj1rZOqPwYEYWNfwc0b7T1r6kaJy26FmbdirdHbSZf7r9eia+czxfbZsK/9wuxNGWq4c7/OQ9QEgiHk= X-Received: by 2002:a05:6512:2304:: with SMTP id o4mr41098424lfu.563.1641276096895; Mon, 03 Jan 2022 22:01:36 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Mon, 3 Jan 2022 22:01:35 -0800 (PST) In-Reply-To: <86zgoihs64.fsf@phe.ftfl.ca> References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Tue, 4 Jan 2022 07:01:35 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Joseph Mingrone Cc: =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JShnt0ZzKz4dyk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Tm7i2Bjm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::12c as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-1.80 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.30)[-0.297]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.87)[-0.866]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12c:from]; NEURAL_SPAM_SHORT(0.36)[0.364]; 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]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Implementing S3 suspend/resume was a sponsored project itself. However, it still does only work when at xorg graphics mode, which already was topic in this thread. When using it from console, no matter sc or vt, it still hangs with dark screen and unresponsive keyboard. Could finishing the suspend/resume work be sponsored, so that it also works on console-only computers? On 12/30/21, Joseph Mingrone wrote: > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote: > >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK wr= ote: >>> I've ideas about enhancing the routing architecture. Is it possible to >>> add to wiki? > >> Certainly. Please do. > > The link again is https://wiki.freebsd.org/2021FoundationCFI > From nobody Tue Jan 4 06:15:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 10A8B1930A04 for ; Tue, 4 Jan 2022 06:15:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSj5v6TRxz4hTW for ; Tue, 4 Jan 2022 06:15:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92f.google.com with SMTP id u6so54078010uaq.0 for ; Mon, 03 Jan 2022 22:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bw31H09+56D89EhOyrxq3SL+j2RrlP5qjGCZ/wZ5VVM=; b=DofHgNrSbtcf7PSAsbxVsWOvIo84s0NH7IEA1Q67vLDgfkjFegM4V8Woqa7HneOM7a TetZU++rZ2rO9gNuWDeEDXDma8fJPQkbw/wZpb4iISHS7zpOKjSYuk5AyTsTGZMaTSeC DJS4V3ygzCipIXZiL+JFEoB1IBKoySPFdCIo3gqcsWIWZq9dEKfy3MJekfF2XEgDdySN OFN6RGAxwIWVCaj3teCQU8I0ncIzs+v/HIPxSnC8SP79j3oe+9EYXvQyo+5PILB3hnBS 8avpr/UritBcP6BUUGoJ5w6IHN6ZXO9Lr70deAAMXzfGXpvSfKtIz1B4MhbISaGOffZ0 ++iQ== 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=Bw31H09+56D89EhOyrxq3SL+j2RrlP5qjGCZ/wZ5VVM=; b=IZR/3pNbBNDgrXFMGZxfWbho+X643O3tZhkJi8/kdolWh/mGjHFd07TOYR4vkP51+n pm9Jh2s5l5IpzZnjTGrSpkmymB4nDK4xSXwJ9wLxGDkVUREypynOm1Cn5SxD3nNcq7tq 8N0iP9VKhwMMLUbKgAgIiHz+O09pmtNCIAT9z2z9zKvvl7m7h10GW48UgnAcNUehtvpr YBcJ3Yn+jpBsckH1J7gEn3++umsz3WJbTLi9ZvWGgaL8blY3DomG9oNG7QyjAQEF74b8 mV8edzaevNKmELRg/9CBC4at01WXucEqrjsGWRPlAw0TiKGZAtg+gl/8Tx1w9aRuNlc5 euwA== X-Gm-Message-State: AOAM533grWH68VeX2FfndIDRggulmuibzBI451Q7a9bUp29PcCt4K3Ce ahckbXP8unq6WJTRMQjoWACs+8jzXTfu5TrgqLx9wHKjqEE= X-Google-Smtp-Source: ABdhPJwC6owFpbwyrA0U1eatSpgmArQdqWLEwUcYqck1nyGP5IHCFSVHVlRs1Ajvoz8ndTVcLP3Ow7yvnZ6dL+nKkYw= X-Received: by 2002:ab0:4405:: with SMTP id m5mr15986779uam.11.1641276931270; Mon, 03 Jan 2022 22:15:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Mon, 3 Jan 2022 23:15:19 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000777c9d05d4bb903a" X-Rspamd-Queue-Id: 4JSj5v6TRxz4hTW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000777c9d05d4bb903a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann wrote= : > Implementing S3 suspend/resume was a sponsored project itself. > However, it still does only work when at xorg graphics mode, which > already was topic in this thread. > When using it from console, no matter sc or vt, it still hangs with > dark screen and unresponsive keyboard. > Could finishing the suspend/resume work be sponsored, so that it also > works on console-only computers? > Not without loading the xorg graphics stuff... graphics chips from the last 15 or 20 years have lots of chip specific state that only the graphics stuff knows about... IIRC, it only knows about it because it put the graphics into a known state... it's the main reason laptops stopped suspending in the early 2000s... it looks to be a lot of work for a relatively rare use case... Warner > On 12/30/21, Joseph Mingrone wrote: > > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote: > > > >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK = wrote: > >>> I've ideas about enhancing the routing architecture. Is it possible t= o > >>> add to wiki? > > > >> Certainly. Please do. > > > > The link again is https://wiki.freebsd.org/2021FoundationCFI > > > > --000000000000777c9d05d4bb903a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <s= blachmann@gmail.com> wrote:
= Implementing S3 suspend/resume was a sponsored project itself.
However, it still does only work when at xorg graphics mode, which
already was topic in this thread.
When using it from console, no matter sc or vt, it still hangs with
dark screen and unresponsive keyboard.
Could finishing the suspend/resume work be sponsored, so that it also
works on console-only computers?

Not without loading the xorg graphics stuff= ... graphics chips from the last 15 or 20 years have lots of chip specific = state that only the graphics stuff knows about... IIRC, it only knows about= it because it put the graphics into a known state... it's the main rea= son laptops stopped suspending in the early 2000s... it looks to be a lot o= f work for a relatively rare use case...

<= div dir=3D"auto">Warner

=

On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
> On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.org> w= rote:
>
>> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK <oz= kan.kirik@gmail.com> wrote:
>>> I've ideas about enhancing the routing architecture. Is it= possible to
>>> add to wiki?
>
>> Certainly.=C2=A0 Please do.
>
> The link again is https://wiki.= freebsd.org/2021FoundationCFI
>

--000000000000777c9d05d4bb903a-- From nobody Tue Jan 4 07:14:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0319F1920D18 for ; Tue, 4 Jan 2022 07:14:32 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSkPz6Bj4z4rv0; Tue, 4 Jan 2022 07:14:31 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lj1-x22e.google.com with SMTP id v15so59448780ljc.0; Mon, 03 Jan 2022 23:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n45u3enJrEVm7ud8X8ifQhBRt2G/h1ZVTwr0adLFwbo=; b=Xd71i/5LOHJcFQ8Ox4ySTSEKNVMwR1Jj0UeWpWoIhxDALNNmFGqkvGCy7FIQhtruxU sgBt/QuC2VJs42SFsKN7gOxZ+xByc3NImiP+/g1aDXV2uFqtTzJvOKFChN2zpk06EbCZ a/oP4QnutdhF8e7MeoFHZ/5IfewYBJDYJ94q76LXj4hLajW1B3x3aHL8wo1NDC/8bHpj PTyBZy4cAKcQcg9BXAMoXpca9TOw8U/cH2xZ9+pBr0St0dcJkqD5j3dL4sMiepbsyTA0 6CexBhbETLuuXdWPpZ1XAPJmuUc8f9SNT+7LvwW4ymqgxab8D/Yu9KzWlEAz6o/TRM+t M3Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n45u3enJrEVm7ud8X8ifQhBRt2G/h1ZVTwr0adLFwbo=; b=lio920kgUfoTAKMST6PljwgL6wDkzVyDCybqULTNVhrzt4Ju4mkbEPCK478R8dyrrY uNuO5PbkoRLXxi2QqP0ulWM+q4wUiAgOTNe1yNz2Z2bSRAEu0e508TK0nXUziPOTX0b9 8gVLNwrLLjPxEBXxB1nh4CS6aEXovbxj+Fu4avI5wYzp0FzQt6VyQte31WEI+PjECnpB efUwMZJyuGN3BrskFEJQJW7f1/FIPCuSPh/kyK8ryX2Nd4vhHIccRke66yp/75vBf25y ylM7VLiDGk2AnY5V8dFvFhXf2CJU/fO/xWccz4g6lI+lmL4a4lpWvymYuR348w4sv3NH A7EQ== X-Gm-Message-State: AOAM5307CRkgQYf0v/CW5xZs0R3JSBaC/9SBKRh0l7Aoewv/E3+axXU6 jsnK/ZGtqopeqqCcXpFjDDu8aubAtGJNORRb/H4= X-Google-Smtp-Source: ABdhPJxd4KPNsQ7+FqFEEagp5/F7PSGJq6JB2CK510erwDcSLkmWlUrjmUPYTEwnsrWOmRKPIqSb/4IX7lIgaYVBBYc= X-Received: by 2002:a2e:94cc:: with SMTP id r12mr40506697ljh.208.1641280464024; Mon, 03 Jan 2022 23:14:24 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Mon, 3 Jan 2022 23:14:23 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Tue, 4 Jan 2022 08:14:23 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Warner Losh Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JSkPz6Bj4z4rv0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Warner Losh wrote: > Not without loading the xorg graphics stuff... graphics chips from the la= st > 15 or 20 years have lots of chip specific state that only the graphics > stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stopped > suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case... UEFI GOP seems to have the necessary functionalities (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work required would be limited (restore mode and redraw screen from buffer). With non-UEFI or old UGA UEFI implementations possibly one could use the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU and the int 10h interface, and then set previously used mode+redraw. BTW, doing that also could both enable vt(4) to change modes/resolutions and using sc on UEFI computers. But I think you are right, there are probably not too many users who would make use of that. On 1/4/22, Warner Losh wrote: > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > wrote: > >> Implementing S3 suspend/resume was a sponsored project itself. >> However, it still does only work when at xorg graphics mode, which >> already was topic in this thread. >> When using it from console, no matter sc or vt, it still hangs with >> dark screen and unresponsive keyboard. >> Could finishing the suspend/resume work be sponsored, so that it also >> works on console-only computers? >> > > Not without loading the xorg graphics stuff... graphics chips from the la= st > 15 or 20 years have lots of chip specific state that only the graphics > stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stopped > suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case... > > Warner > > >> On 12/30/21, Joseph Mingrone wrote: >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote: >> > >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> wrote: >> >>> I've ideas about enhancing the routing architecture. Is it possible >> >>> to >> >>> add to wiki? >> > >> >> Certainly. Please do. >> > >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> > >> >> > From nobody Tue Jan 4 13:19:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D2BA193B7DC for ; Tue, 4 Jan 2022 13:19:26 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JStW208Ldz4sQG for ; Tue, 4 Jan 2022 13:19:25 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id u25so27080024edf.1 for ; Tue, 04 Jan 2022 05:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y70cAgcyxdORAdAnK+XNev/pMB75mXwYrzcTgD+JQIE=; b=OwLZWALXS22x0av+SQM8WEaTAtz3IR6TzzPU/2vUaYYdg+SkPQ1rSn3RFnEOTHh1wx IFcxpKDc2US6w56zkcERwOGoVqL1pvSBqHzBPO91uWK5T3A9EuJcWLam+hj4b32e77ba qmhaiS2GN+dgmrgDHfKDuvqzTk0WMcAVF04A5nW2O47uOWOxIOEjO5EIsgFilFZvyVIx 90eGe0ievRazKG+d6uRHCb4rNgYEfcfX7nJrDKG+mBnXN+StlqRyP4I9SP0W7/t/mJkR VemOqEUSGAqb2GyS43ZBA3bOrDl+LdlqLMLLpSU7ay4o9wDoaqM1prB+cDBO2dAjq1ux NA8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y70cAgcyxdORAdAnK+XNev/pMB75mXwYrzcTgD+JQIE=; b=ikasDqSt6NjZIQYMJrSqRRUAettlhMiHKQFZCdRlsPZl3oWYw/+ozox0xi5G3MGdg5 YCWy+vpTfVHIBfm6LLQFwUf6Js+l3CPe5F+YUC81hdiK2Ku9/54Y+K/C/QZG7ikbABEJ PxhduZtU4WNNVy5VLc7S5qADWV3MGaMbo6DlAAOg9fyiOfX3cZeWMLuHmSwP8a7sqLPi gdw9CUXuc81RnUAhubjSUCy5yjNEMz4pXxeqO41zgov+aYpz0UfoyuOtHefpB/cvD3ss 4bKrOEDZDrk2W2hyrLpFEa/mKiNQPiqrmA+hPnQw7h70c+33CPUYy303hZm0oVkP3GKk vzJA== X-Gm-Message-State: AOAM532tD0XV8N0trp2S+OxtIEBBNvlxQi1xjtEaaR0a9T23KbcM4+O3 BaOIAXHq7VUOx55bQ67bmRZFdCmubCM= X-Google-Smtp-Source: ABdhPJyoh+ZEAvxinpHEjUXtDEVB5UNIbwZXSUyKi22lO7lccTDEsR/pmoPZW9paq8V8kbaXckCx3g== X-Received: by 2002:a17:907:7da5:: with SMTP id oz37mr41583882ejc.586.1641302358509; Tue, 04 Jan 2022 05:19:18 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id cb3sm14699215edb.35.2022.01.04.05.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 05:19:18 -0800 (PST) Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann , Warner Losh Cc: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Karel Gardas Message-ID: <13b4121f-0e3f-1650-f362-4d4a8209ac8f@gmail.com> Date: Tue, 4 Jan 2022 14:19:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JStW208Ldz4sQG 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 1/4/22 8:14 AM, Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: >> Not without loading the xorg graphics stuff... graphics chips from the last >> 15 or 20 years have lots of chip specific state that only the graphics >> stuff knows about... IIRC, it only knows about it because it put the >> graphics into a known state... it's the main reason laptops stopped >> suspending in the early 2000s... it looks to be a lot of work for a >> relatively rare use case... > > UEFI GOP seems to have the necessary functionalities > (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > required would be limited (restore mode and redraw screen from > buffer). Wouldn't that stumble over drm based driver code? Assuming majority of users are using drm based X server and not efifb based one... From nobody Tue Jan 4 13:32:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E4ADE193F3A4 for ; Tue, 4 Jan 2022 13:32:43 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JStpL6GSRz3Bq8; Tue, 4 Jan 2022 13:32:42 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1641303155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5K6BW21olOIKb3+6A9pDEiZg5H917/BoEQ8L82D6VMw=; b=YOaBj/cSL8RCn3N/mXqqggYuWEIy9k3v8e+NUEam1VwO7a5V7DK45HusH0zsQOvcP3wbzm JeQysvS1/WZW+ThhmNoaEEsOr69ZoyBiZXW4y4nRBbYs+ZP1Bqw/azWetDFLjc/YmvIjJd PYnMxFjd9z/PM9vgv7XQRNVg1g/IgJM= Received: from amy (lfbn-idf2-1-1163-183.w90-92.abo.wanadoo.fr [90.92.222.183]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 2f1b6e58 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 4 Jan 2022 13:32:35 +0000 (UTC) Date: Tue, 4 Jan 2022 14:32:34 +0100 From: Emmanuel Vadot To: Stefan Blachmann Cc: Warner Losh , Joseph Mingrone , =?ISO-8859-1?Q?=D6zkan?= KIRIK , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20220104143234.d9af3a4aa841c80219cdcf75@bidouilliste.com> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JStpL6GSRz3Bq8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Tue, 4 Jan 2022 08:14:23 +0100 Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > Not without loading the xorg graphics stuff... graphics chips from the = last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... >=20 > UEFI GOP seems to have the necessary functionalities > (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > required would be limited (restore mode and redraw screen from > buffer). ? You can't get or set the mode after ExitBootService in UEFI, you only have the framebuffer setup by the firmware. > With non-UEFI or old UGA UEFI implementations possibly one could use > the dual BIOS=B4 CSM part. Just call the CSM BIOS init to set up GPU and > the int 10h interface, and then set previously used mode+redraw. > BTW, doing that also could both enable vt(4) to change > modes/resolutions and using sc on UEFI computers. UGA have nothing to do with having CSM. Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't think that the firmware will setup the handler in non-CSM mode. > But I think you are right, there are probably not too many users who > would make use of that. >=20 >=20 > On 1/4/22, Warner Losh wrote: > > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > > wrote: > > > >> Implementing S3 suspend/resume was a sponsored project itself. > >> However, it still does only work when at xorg graphics mode, which > >> already was topic in this thread. > >> When using it from console, no matter sc or vt, it still hangs with > >> dark screen and unresponsive keyboard. > >> Could finishing the suspend/resume work be sponsored, so that it also > >> works on console-only computers? > >> > > > > Not without loading the xorg graphics stuff... graphics chips from the = last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... > > > > Warner > > > > > >> On 12/30/21, Joseph Mingrone wrote: > >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote: > >> > > >> >> On Thu, 2021-12-30 at 08:05, =D6zkan KIRIK > >> >> wrote: > >> >>> I've ideas about enhancing the routing architecture. Is it possible > >> >>> to > >> >>> add to wiki? > >> > > >> >> Certainly. Please do. > >> > > >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> > > >> > >> > > >=20 --=20 Emmanuel Vadot From nobody Tue Jan 4 13:19:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C71E3191C2A8 for ; Tue, 4 Jan 2022 13:50:54 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from delivery.e-purifier.com (delivery.e-purifier.com [41.168.2.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSvCL1SP6z3F71 for ; Tue, 4 Jan 2022 13:50:54 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from [192.168.202.38] (helo=SEC-NGP-AG08) by delivery.e-purifier.com with smtp (Exim 4.94) (envelope-from ) id 1n4kDC-0002zK-Tm for freebsd-hackers@freebsd.org; Tue, 04 Jan 2022 15:50:50 +0200 Received: from mail pickup service by SEC-NGP-AG08.neotel.e-purifier.co.za with Microsoft SMTPSVC; Tue, 4 Jan 2022 15:50:48 +0200 Received: from sec-ngp-spt04.e-purifier.com ([192.168.201.1]) by SEC-NGP-AG08.neotel.e-purifier.co.za with Microsoft SMTPSVC(7.5.7601.17514); Tue, 4 Jan 2022 15:21:06 +0200 Received: from localhost (localhost [127.0.0.1]) by sec-ngp-spt04.e-purifier.com (Postfix) with ESMTP id DAEBA114C38D for ; Tue, 4 Jan 2022 15:21:06 +0200 (SAST) X-Virus-Scanned: by SpamTitan at e-purifier.com X-Spam-Flag: NO X-Spam-Score: 2.377 X-Spam-Level: ** X-Spam-Status: No, score=2.377 tagged_above=-999 required=3.8 tests=[BAYES_00=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1.699, FREEMAIL_FROM=0.001, FROM_FMBLA_NDBLOCKED=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, IGNORE_BAYES_00=0.25, MAILING_LIST_MULTI=-0.001, NICE_REPLY_A=-3.28, RAZOR2_CF_RANGE_51_100=2.886, RAZOR2_CHECK=0.922, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, ST_FREEMAIL_EXTRA=1, ST_P0F_Unix=-1, ST_RCVD_IN_HOSTKARMA_W=-0.001] autolearn=no autolearn_force=no Received: from sec-ngp-spt04.e-purifier.com (localhost [127.0.0.1]) by sec-ngp-spt04.e-purifier.com (Postfix) with ESMTP id 87B20114C32C for ; Tue, 4 Jan 2022 15:21:00 +0200 (SAST) Received-SPF: pass (freebsd.org ... _spf.freebsd.org: 96.47.72.81 is authorized to use 'freebsd-hackers+bounces-712-ftk=nanoteq.com@FreeBSD.org' in 'mfrom' identity (mechanism 'ip4:96.47.72.81' matched)) receiver=sec-ngp-spt04.e-purifier.com; identity=mailfrom; envelope-from="freebsd-hackers+bounces-712-ftk=nanoteq.com@FreeBSD.org"; helo=mx2.freebsd.org; client-ip=96.47.72.81 Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) (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 sec-ngp-spt04.e-purifier.com (Postfix) with ESMTPS id AD19D114C353 for ; Tue, 4 Jan 2022 15:20:56 +0200 (SAST) Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 30DC1833E5 for ; Tue, 4 Jan 2022 13:20:52 +0000 (UTC) (envelope-from freebsd-hackers+bounces-712-ftk=nanoteq.com@FreeBSD.org) Received: from mlmmj.nyi.freebsd.org (mlmmj.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:24]) by mx1.freebsd.org (Postfix) with ESMTP id 4JStXg4tLhz4syn for ; Tue, 4 Jan 2022 13:20:51 +0000 (UTC) (envelope-from freebsd-hackers+bounces-712-ftk=nanoteq.com@FreeBSD.org) Received: from mlmmj.nyi.freebsd.org (unknown [127.0.1.24]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D58B7193B851 for ; Tue, 4 Jan 2022 13:19:39 +0000 (UTC) (envelope-from freebsd-hackers+bounces-712-ftk=nanoteq.com@FreeBSD.org) X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D2BA193B7DC for ; Tue, 4 Jan 2022 13:19:26 +0000 (UTC) (envelope-from gardask@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JStW208Ldz4sQG for ; Tue, 4 Jan 2022 13:19:25 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id u25so27080024edf.1 for ; Tue, 04 Jan 2022 05:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y70cAgcyxdORAdAnK+XNev/pMB75mXwYrzcTgD+JQIE=; b=OwLZWALXS22x0av+SQM8WEaTAtz3IR6TzzPU/2vUaYYdg+SkPQ1rSn3RFnEOTHh1wx IFcxpKDc2US6w56zkcERwOGoVqL1pvSBqHzBPO91uWK5T3A9EuJcWLam+hj4b32e77ba qmhaiS2GN+dgmrgDHfKDuvqzTk0WMcAVF04A5nW2O47uOWOxIOEjO5EIsgFilFZvyVIx 90eGe0ievRazKG+d6uRHCb4rNgYEfcfX7nJrDKG+mBnXN+StlqRyP4I9SP0W7/t/mJkR VemOqEUSGAqb2GyS43ZBA3bOrDl+LdlqLMLLpSU7ay4o9wDoaqM1prB+cDBO2dAjq1ux NA8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y70cAgcyxdORAdAnK+XNev/pMB75mXwYrzcTgD+JQIE=; b=ikasDqSt6NjZIQYMJrSqRRUAettlhMiHKQFZCdRlsPZl3oWYw/+ozox0xi5G3MGdg5 YCWy+vpTfVHIBfm6LLQFwUf6Js+l3CPe5F+YUC81hdiK2Ku9/54Y+K/C/QZG7ikbABEJ PxhduZtU4WNNVy5VLc7S5qADWV3MGaMbo6DlAAOg9fyiOfX3cZeWMLuHmSwP8a7sqLPi gdw9CUXuc81RnUAhubjSUCy5yjNEMz4pXxeqO41zgov+aYpz0UfoyuOtHefpB/cvD3ss 4bKrOEDZDrk2W2hyrLpFEa/mKiNQPiqrmA+hPnQw7h70c+33CPUYy303hZm0oVkP3GKk vzJA== X-Gm-Message-State: AOAM532tD0XV8N0trp2S+OxtIEBBNvlxQi1xjtEaaR0a9T23KbcM4+O3 BaOIAXHq7VUOx55bQ67bmRZFdCmubCM= X-Google-Smtp-Source: ABdhPJyoh+ZEAvxinpHEjUXtDEVB5UNIbwZXSUyKi22lO7lccTDEsR/pmoPZW9paq8V8kbaXckCx3g== X-Received: by 2002:a17:907:7da5:: with SMTP id oz37mr41583882ejc.586.1641302358509; Tue, 04 Jan 2022 05:19:18 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id cb3sm14699215edb.35.2022.01.04.05.19.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jan 2022 05:19:18 -0800 (PST) Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann , Warner Losh Cc: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Karel Gardas Message-ID: <13b4121f-0e3f-1650-f362-4d4a8209ac8f@gmail.com> Date: Tue, 4 Jan 2022 14:19:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641302451; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Y70cAgcyxdORAdAnK+XNev/pMB75mXwYrzcTgD+JQIE=; b=TYlkCHroo8qAqDH4gb6eYCtE8VoevtCSbm5eY1TinOrsDwGBAhNKfhNlvSqisZLsTwlbGL tBBsPi2Q74njuDcHCKkd4qjwD9It48UaNQg/2zaKhYIfDVAJDRomC2K3UsLaVwlwp1RW1k s45JPvIV+Mx2aa3qX6Pk3yi1/7hOtErQUEO0cSF0Ji7f0WkbTZt7wLeNIgFuCdKxfAFOjN 3gbphzdIM+YCIIk9EtM32PO6tjrUVH+J/Yu1OAxwW5mPWq1s3hhzCpdybPQvQYf/AQw5hD rqgLi331Q70kUMWcGX2zpS0BtEoQP0nmoDrvaEWE6ccYuNe29PfcH5jTbyOZdw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641302451; a=rsa-sha256; cv=none; b=EiTa19ux42k/K1UqevBeFe1OC86M+xaYvM1w8Vltj5rS2tTnhK60hOXKPLQCB5V0rJ3A3W Hoq4/ngHkhkmYfax6DctV5tepf5IJ2+Kwbddv+aklGRM4lqmOJj132bG4MROwe3ilLcHsI di8u8bH06SNwqj33dLx+TlDi5UJTGM5zEqETRdtj1ACkfjaVfNfDWaKQV2suz0lfO3Yfg3 DT2NNqPzeKufcbZudf6AdXx9CCwXGJMA+afmWiTjJpgveouq2QsX+i/5CFuHSQi5SNpb8m qXjVwweR848mGE/A8LBaSHjxFPAI9gTAXvf/ZnT6q7wXJMoMnG2UaPlN1SO5Pg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-OriginalArrivalTime: 04 Jan 2022 13:21:06.0550 (UTC) FILETIME=[EE1EF960:01D8016D] x-archived: yes x-dbused: RGF0YSBTb3VyY2U9MTkyLjE2OC4yMDEuMjY= X-Rspamd-Queue-Id: 4JSvCL1SP6z3F71 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 1/4/22 8:14 AM, Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: >> Not without loading the xorg graphics stuff... graphics chips from the last >> 15 or 20 years have lots of chip specific state that only the graphics >> stuff knows about... IIRC, it only knows about it because it put the >> graphics into a known state... it's the main reason laptops stopped >> suspending in the early 2000s... it looks to be a lot of work for a >> relatively rare use case... > > UEFI GOP seems to have the necessary functionalities > (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > required would be limited (restore mode and redraw screen from > buffer). Wouldn't that stumble over drm based driver code? Assuming majority of users are using drm based X server and not efifb based one... From nobody Tue Jan 4 14:20:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 54D941924BED for ; Tue, 4 Jan 2022 14:20:10 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSvs61YQkz3Lfv; Tue, 4 Jan 2022 14:20:10 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12a.google.com with SMTP id k21so82118544lfu.0; Tue, 04 Jan 2022 06:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LdyfuPvVrOH64PtpdAt5/IODcX2srwEEZH0b8qofOxM=; b=UZnlWDp3d1YMR3Iybsfo7CmnvBDFnse7nACFANgghby7clBtxY6Nj/+ay9HlYrMmAs G/khDQUMPpFoNwiPGDq/3ttteOQjcwx9D3wBLmP/mnusitdp6mH2Etr8GSaMIfsYngq0 kOjdwka0KI/qFZEX6D/ZsVzFbtuQZ5c3ftXAoUMpaQ68TF613Y5egTNqRenXeNnO5Il/ +95hYkn8zKoSeXHcS7R7meQnBO+ISFJwDdbqyPZH+SiZZua+y9p5rJpGwxRd7nPkd46Y 0r9FMUBoCiz0SPv7NMXbHHeMpBfh80T9SdLI/3lkO7TZ0RQc7AawkxVIE68jr7yxu8iV mDrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LdyfuPvVrOH64PtpdAt5/IODcX2srwEEZH0b8qofOxM=; b=4dC64WXWDovIVf2bP0WKzc+0KSzOXdvOD7/5xYJzYZkCe3Rzz0ydOPrdzHYRU44lST hDUKDgkshrMxh79JyzzepjdQmrUexNTrxohabF0EZF4BFvuiilzizitkaR2SuOKQE0Bn DHSYoAxuU04QlEoByYqFMDgA1LZSEfiiEsQM7dKcmaleJwzfWH4GfSc87cfCTRJcnewv 2Tm4WghUf2oojctO/lNVC8k7ZcCM3o7aacvfq2xwAHIgXJOS6YCcR7+4W4xRgr0gbn7V 47SxkVe/KOm2FZgU7hMJe0ge8KSKo1iHRuxE/HpIuli2DHgcXcm2meVmaGyZdZXB0yoa op/Q== X-Gm-Message-State: AOAM532ujuEz5egOiiFVwsjTI0Yti6r0SHm4qDBGM6AlvjxkzafgVn8k IPw+FKo071zapPPlhQ+E2NUDdnqxWAxN12swTJJCq6uwbrs= X-Google-Smtp-Source: ABdhPJyIz7GX5wmWgZhOX2C2Dy7KRS6m/dJOMAMzU+NsGOPL3jwm+7Iq0uyRDrS74631NaopA/odWpy1Hekk8ptYvjU= X-Received: by 2002:a05:6512:324f:: with SMTP id c15mr43827595lfr.465.1641306008854; Tue, 04 Jan 2022 06:20:08 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Tue, 4 Jan 2022 06:20:08 -0800 (PST) In-Reply-To: <20220104143234.d9af3a4aa841c80219cdcf75@bidouilliste.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> <20220104143234.d9af3a4aa841c80219cdcf75@bidouilliste.com> From: Stefan Blachmann Date: Tue, 4 Jan 2022 15:20:08 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Emmanuel Vadot Cc: Warner Losh , Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JSvs61YQkz3Lfv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Emmanuel Vadot wrote: > You can't get or set the mode after ExitBootService in UEFI, you only > have the framebuffer setup by the firmware. > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. > > UGA have nothing to do with having CSM. > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > think that the firmware will setup the handler in non-CSM mode. After the UEFI boot service is no longer needed, one can check the VGA BIOS UEFI signature for presence of a dual BIOS with normal VGA BIOS (which is being used in CSM mode) in addition to UEFI BIOS. Afaik, there are few if any UEFI compatible graphics cards without dual BIOS, as those would not work in computers without UEFI. If VGA BIOS presence is detected on the graphics card, calling the VGA BIOS init sets up the int 10h handler. After doing this, the UEFI crap limitations are gone. On 1/4/22, Emmanuel Vadot wrote: > On Tue, 4 Jan 2022 08:14:23 +0100 > Stefan Blachmann wrote: > >> On 1/4/22, Warner Losh wrote: >> > Not without loading the xorg graphics stuff... graphics chips from the >> > last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> >> UEFI GOP seems to have the necessary functionalities >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> required would be limited (restore mode and redraw screen from >> buffer). > > ? > You can't get or set the mode after ExitBootService in UEFI, you only > have the framebuffer setup by the firmware. > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. > > UGA have nothing to do with having CSM. > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > think that the firmware will setup the handler in non-CSM mode. > >> But I think you are right, there are probably not too many users who >> would make use of that. >> >> >> On 1/4/22, Warner Losh wrote: >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> > wrote: >> > >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> However, it still does only work when at xorg graphics mode, which >> >> already was topic in this thread. >> >> When using it from console, no matter sc or vt, it still hangs with >> >> dark screen and unresponsive keyboard. >> >> Could finishing the suspend/resume work be sponsored, so that it also >> >> works on console-only computers? >> >> >> > >> > Not without loading the xorg graphics stuff... graphics chips from the >> > last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> > >> > Warner >> > >> > >> >> On 12/30/21, Joseph Mingrone wrote: >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> > wrote: >> >> > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> wrote: >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >>> possible >> >> >>> to >> >> >>> add to wiki? >> >> > >> >> >> Certainly. Please do. >> >> > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> > >> >> >> >> >> > >> > > > -- > Emmanuel Vadot > From nobody Tue Jan 4 15:53:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 140AD193EDDC for ; Tue, 4 Jan 2022 15:53:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSxwy3P30z4Qmf; Tue, 4 Jan 2022 15:53:38 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 204FrSZM099991; Wed, 5 Jan 2022 00:53:28 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 5 Jan 2022 00:53:28 +0900 From: Tomoaki AOKI To: FreeBSD Hackers Cc: Stefan Blachmann , Emmanuel Vadot , Warner Losh , Joseph Mingrone , =?ISO-2022-JP?B?GyRCIi4bKEJ6a2Fu?= KIRIK , Michael Schuster , Kyle Evans , Karel Gardas Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20220105005328.e75c6948ec6d14adf29dee33@dec.sakura.ne.jp> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> <20220104143234.d9af3a4aa841c80219cdcf75@bidouilliste.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JSxwy3P30z4Qmf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 4 Jan 2022 15:20:08 +0100 Stefan Blachmann wrote: > On 1/4/22, Emmanuel Vadot wrote: > > You can't get or set the mode after ExitBootService in UEFI, you only > > have the framebuffer setup by the firmware. > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS$B!-(B CSM part. Just call the CSM BIOS init to set up GPU and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > > > > UGA have nothing to do with having CSM. > > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > > think that the firmware will setup the handler in non-CSM mode. > > After the UEFI boot service is no longer needed, one can check the VGA > BIOS UEFI signature for presence of a dual BIOS with normal VGA BIOS > (which is being used in CSM mode) in addition to UEFI BIOS. > Afaik, there are few if any UEFI compatible graphics cards without > dual BIOS, as those would not work in computers without UEFI. > If VGA BIOS presence is detected on the graphics card, calling the VGA > BIOS init sets up the int 10h handler. > After doing this, the UEFI crap limitations are gone. Possibly notebooks without discrete GPU (forced to use internal GPU on CPU) don't have CSM. IIRC, I heard M$ Surface doesn't have CSM (UEFI only). Just a thought, but adding something like hw.kms.in_use, initially 0 and incremented when a KMS driver is sanely attached, can help? It should be needed to be decremented when a KMS driver is detached. And something like hw.kms.intel.0.mode having needed data to manage suspend/resume would also be needed (set by KMS drivers). # Not sure if multiple KMS drivers can coexist or not, though. > On 1/4/22, Emmanuel Vadot wrote: > > On Tue, 4 Jan 2022 08:14:23 +0100 > > Stefan Blachmann wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> > last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > > > > ? > > You can't get or set the mode after ExitBootService in UEFI, you only > > have the framebuffer setup by the firmware. > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS$B!-(B CSM part. Just call the CSM BIOS init to set up GPU and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > > > > UGA have nothing to do with having CSM. > > Also I'm unsure if INT 10 would work when booted in UEFI, i.e. I don't > > think that the firmware will setup the handler in non-CSM mode. > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it also > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> > last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, $B".(Bzkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > > > -- > > Emmanuel Vadot > > > > -- Tomoaki AOKI From nobody Tue Jan 4 17:23:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66AB7193796F for ; Tue, 4 Jan 2022 17:23:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JSzwp27rJz4jxl for ; Tue, 4 Jan 2022 17:23:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa36.google.com with SMTP id 78so2301644vkz.7 for ; Tue, 04 Jan 2022 09:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OAq/yllwcxK+EqpAmGhPVJvb4ATaQfNjn9RGR6MadXg=; b=UYA1AwHXxSzJAcV+ZnPh+anfFgZaEgdvy25OT5BDd0fTCPa9wPU8SZOfun+Ro6udgU VAvc3NMgdG33WAuVipTgU+3oHKY7mP3ck/J4pdKjV+G9E2sIwEWAMkZPHQ8Ue+tHx1X+ 2YFYRWahHV7KYBrGeL8w1unysO+BA9JKaVhHve+v/FfTOnNvtUv18rQdu5yixZiuIpY+ g/7vfi2xZXo+GyA8etAT7c5bhkr68lOy5X90VRBBBx99ox6a6aePzSAjTlV4Lpf5Q5wl JQ0Q+ItEOUkU8fCh2v5cmx/esS0MVyIzozF8hgLMaur9h9YBkMFc8dkEI8EPCShWcaby r/uQ== 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=OAq/yllwcxK+EqpAmGhPVJvb4ATaQfNjn9RGR6MadXg=; b=GjpPghBLbcTPEgLCRxXw4lkDJ8MfoxrSevVUjpITocnFtngRAqg7Tr/1K7HukODXDs 8gQppNeN00q5D2pdPAmRKUqU9jzNkepGTmuiaq6W45JBvHWH0otue/+xZFHYNQ+HQOvD MYCFGJixicvfi5pMX9WQh6j0J+waHPh0cGeBV7k8DctxMadyatd7xKGHxB3aUTvhA5UH 8pq0aaBHZHPKYIy1z0kmsj5hswSBnzFMXqyORKadR9tt8aTXd6MIKfcrC6G6efWeZbBq dHqi+Y3Q0uTjjszfKv6RcVGDAyH+XJ99NiFN0yFIZMmFTkMSjaerynC5JzPX/T78Aent Zlfg== X-Gm-Message-State: AOAM531C29XYpsSWG6A+KD7bX/5Db4S5AiBGHM1z8gJdCzOI4pq/88m0 97DA4OecL4tn+RL3x+1wSjOErdCXEP4kM3lituAhwQ== X-Google-Smtp-Source: ABdhPJy286+1mjCWYIQG/rGtvnSHz7or6rlvAQeU52W+nR9upAxVZkqFCSHIcnIp5iozVvcyzia1SunkgRE751HeA18= X-Received: by 2002:a05:6122:e12:: with SMTP id bk18mr18047033vkb.40.1641317017691; Tue, 04 Jan 2022 09:23:37 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Tue, 4 Jan 2022 10:23:26 -0700 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000cdb91c05d4c4e5c2" X-Rspamd-Queue-Id: 4JSzwp27rJz4jxl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000cdb91c05d4c4e5c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > Not without loading the xorg graphics stuff... graphics chips from the > last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... > > UEFI GOP seems to have the necessary functionalities > (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > required would be limited (restore mode and redraw screen from > buffer). > UEFI GOP isn't available after we start the kernel, so this is a non-starter. It works great in the boot loader, but not so good after we boot. It could work for S3 sleep to disk where we actually reboot to restore the machine state, but we don't have sleep to disk today :( > With non-UEFI or old UGA UEFI implementations possibly one could use > the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU a= nd > the int 10h interface, and then set previously used mode+redraw. > BTW, doing that also could both enable vt(4) to change > modes/resolutions and using sc on UEFI computers. > Ah, if only things were really that simple... I tried variations on that hack years ago when suspending broke due to video. And it works for some machines, but not others, was the quick assessment I made. And the INT xx interface is unavailable on amd64 after we enter long mode (I tried this out on my then-current FreeBSD laptop which was 32 bit only, so 15 years ago?). Warner > But I think you are right, there are probably not too many users who > would make use of that. > > > On 1/4/22, Warner Losh wrote: > > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > > wrote: > > > >> Implementing S3 suspend/resume was a sponsored project itself. > >> However, it still does only work when at xorg graphics mode, which > >> already was topic in this thread. > >> When using it from console, no matter sc or vt, it still hangs with > >> dark screen and unresponsive keyboard. > >> Could finishing the suspend/resume work be sponsored, so that it also > >> works on console-only computers? > >> > > > > Not without loading the xorg graphics stuff... graphics chips from the > last > > 15 or 20 years have lots of chip specific state that only the graphics > > stuff knows about... IIRC, it only knows about it because it put the > > graphics into a known state... it's the main reason laptops stopped > > suspending in the early 2000s... it looks to be a lot of work for a > > relatively rare use case... > > > > Warner > > > > > >> On 12/30/21, Joseph Mingrone wrote: > >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone wrote= : > >> > > >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> wrote: > >> >>> I've ideas about enhancing the routing architecture. Is it possibl= e > >> >>> to > >> >>> add to wiki? > >> > > >> >> Certainly. Please do. > >> > > >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> > > >> > >> > > > --000000000000cdb91c05d4c4e5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 4, 2022 at 12:14 AM Stefa= n Blachmann <sblachmann@gmail.co= m> wrote:
On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> Not without loading the xorg graphics stuff... graphics chips from the= last
> 15 or 20 years have lots of chip specific state that only the graphics=
> stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stoppe= d
> suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case...

UEFI GOP seems to have the necessary functionalities
(https://wiki.osdev.org/GOP#Get_the_Current_Mode)= so I guess the work
required would be limited (restore mode and redraw screen from
buffer).

UEFI GOP isn't available a= fter we start the kernel, so this is a non-starter.
It works = great in the boot loader, but not so good after we boot. It could work
for S3 sleep to disk where we actually reboot to restore the machine = state,
but we don't have sleep to disk today :(
=C2= =A0
With non-UEFI or old UGA UEFI implementations possibly one could use
the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU and=
the int 10h interface, and then set previously used mode+redraw.
BTW, doing that also could both enable vt(4) to change
modes/resolutions and using sc on UEFI computers.

=
Ah, if only things were really that simple...=C2=A0 I tried vari= ations on that
hack years ago when suspending broke due to video.= And it
works for some machines, but not others, was the quick as= sessment
I made. And the INT xx interface is unavailable on amd64= after we
enter long mode (I tried this out on my then-current Fr= eeBSD laptop
which was 32 bit only, so 15 years ago?).
=
Warner
=C2=A0
But I think you are right, there are probably not too many users who
would make use of that.


On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>
>> Implementing S3 suspend/resume was a sponsored project itself.
>> However, it still does only work when at xorg graphics mode, which=
>> already was topic in this thread.
>> When using it from console, no matter sc or vt, it still hangs wit= h
>> dark screen and unresponsive keyboard.
>> Could finishing the suspend/resume work be sponsored, so that it a= lso
>> works on console-only computers?
>>
>
> Not without loading the xorg graphics stuff... graphics chips from the= last
> 15 or 20 years have lots of chip specific state that only the graphics=
> stuff knows about... IIRC, it only knows about it because it put the > graphics into a known state... it's the main reason laptops stoppe= d
> suspending in the early 2000s... it looks to be a lot of work for a > relatively rare use case...
>
> Warner
>
>
>> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
>> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.= org> wrote:
>> >
>> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK <ozkan.kirik@gmail.com>
>> >> wrote:
>> >>> I've ideas about enhancing the routing architectu= re. Is it possible
>> >>> to
>> >>> add to wiki?
>> >
>> >> Certainly.=C2=A0 Please do.
>> >
>> > The link again is https://wiki.freebsd.org/2= 021FoundationCFI
>> >
>>
>>
>
--000000000000cdb91c05d4c4e5c2-- From nobody Tue Jan 4 19:00:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECA78193433E for ; Tue, 4 Jan 2022 19:00:26 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT24V09F9z3NFn for ; Tue, 4 Jan 2022 19:00:26 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id A1454320209C for ; Tue, 4 Jan 2022 14:00:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 04 Jan 2022 14:00:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=dPOr2hoXCGIjrIk3q2umyI0Smw6 jzmaxHTGRp4iPE8c=; b=nDFOa7DsG5EF1wM0qyC7+rzRm9Q0422U8//i1nJhRTP 7GGtY+WRPsYIduT42wz1gVWa01GBrSjTcJIdWKTnl74rklr6OnhedlOCGTyHMzha L5wMYKEkQHsiqHFzHA+rBM9Ug5nqMoRY98yGrvwViF/wxMb8Sy4gcD0ZSj1NBzvZ b+JCuN/BhSXLFSsDuk/o3TZhTvrUvw2P0L9Va/UFjx3/Y7O5qq2bp4MCtQC7gq2F 4ADJIfPDlg9dAkBkxbQEgFQapOfeGtyHfSwKMU4wEOcffmyFSqOhr+v2O/mR3lPA qQvoHDNGWpxbhE63QKCS4I1hZlGNQnjDGQ14jYaEPCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dPOr2h oXCGIjrIk3q2umyI0Smw6jzmaxHTGRp4iPE8c=; b=me6CStaRTmOHCDPY14XSDj ERda+T+RuyUxw+Qc0ccqv2NLHY/VzapltMCJIToVhfhgzCCWyoiao+BBCh0dvBgm 2+kmdSxOvUDvOeRA5BsbjqwdQZetyCA9QaJ2m+nOvgp5V9WLwM6tOEJ/VhiBUFWY G8B2+ZnxipQMhxNEHtF4biZO1VTryedZ5BJ8/1C8XV/NjUo7VXoIgQojlznMnpx2 WvsFpg4fWeQWxLQZ7qjyauLXUUvnu7P05Zf7ryFuVOuNCHHaNsdMaKzUBAzVehUC tWUvIJITItHrLDeKOWhKq3bIBgRO1mttTN/IM1JPAeej36/Nlq4tAQG0OfFMXdqQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeffedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpehtvggthhdqlhhishhtshcuoehtvggthhdqlhhishhtshes iiihgihsthdrnhgvtheqnecuggftrfgrthhtvghrnheptedttdduuefggeeghfekkeetke ejleefffelheejfffgffdtfeeftdejgeeuieffnecuffhomhgrihhnpehfrhgvvggsshgu rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epthgvtghhqdhlihhsthhsseiihiigshhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 14:00:22 -0500 (EST) Date: Tue, 4 Jan 2022 19:00:20 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: Call for Foundation-supported Project Ideas Message-ID: References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="t8M9YdKMmMeh8hjh" Content-Disposition: inline In-Reply-To: <861r2l914z.fsf@phe.ftfl.ca> X-Rspamd-Queue-Id: 4JT24V09F9z3NFn X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=nDFOa7Ds; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=me6CStaR; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from] X-ThisMailContainsUnwantedMimeParts: N --t8M9YdKMmMeh8hjh Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 09, 2021 at 12:46:52PM -0400, Joseph Mingrone wrote: >Thank you to everyone who took the time to contribute project ideas. >Here is a summary of what was submitted. If your idea was missed or >misrepresented, feel free to add or edit it. > >https://wiki.freebsd.org/2021FoundationCFI Not sure where this would go, because it's such a general thing.. but=20 I'd like to see a hard commitment[0] to ensure the date-of-creation=20 and the date-last-modified of every page/article within the handbook[2]=20 is somewhere clear at the start/top[1] of each page. Missing manpages or instructions are bad. Inaccurate and out-of-date ones= =20 are actually *worse*. [0] meaning that if this information is not present, then the page gets rem= oved. [1] meaning that it's not in javascript, or in a sidebar. In the main page = so=20 that it can be read by AnyBrowser/Viewer. It could be justified to the= left or the right. But at the *start* so that one doesn't have to read the who= le thing only to discover that the instructions pertained to the previous decad= e. [2] not just the handbook thanks, --=20 J. --t8M9YdKMmMeh8hjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHUmTsACgkQs8o7QhFz NAUbjw/9H28sxnIUK7HjrsAvG4NnnaB2yTa/CYk3IQHVjAksu5yG/me7pZn7n94d 4nPy63pXd9B5b9SLPJrfy8S1NYzAX2tH80FoNW6HO3z+xKF4h2P1b9jyzaqXyxPz sRPtnOEasF4btXKiqhpqc+mdaKQQ4uLz71GMFtgzyrFAmDW954xTsOXUmkwaB49V ty4v4zcIdfCb/0qomizZv0nwSrVyWzJAx/CTPxgpU5kTESRafrqhfGxxG+aqB4f2 oJcuugOqFAIZQchduQGCEvx4DEo5ulPgTrgWf/XteaniaA+3B8A5TX6a4wJaBbMs QEO1+OP9w9qhjEieHkn2SFCCxkvnI/DRldp4j1WkMzPMQCTwZ1nmvSUb3WXo6AHZ BXuBD4pdExb11LQCfXex30OdcuaLTnl8ubOlzzh4dVX43vVmQAPaUIKcIytc+EMG hGq+17m9mmtmbiv6NAaaghOx/Jym50ahIx5GbM85vaQ/YibhMjFdFebtIIaoGS6L RJNmSzrynXiXJ3B8GhWN5zG0GtlL7G+5ufcwkPHblSxaY4PC1qv7hCNU13uJXsRn 5flP0woJq/kIME4pzIpHEto78plJcZreIp1feuFOghMsA33WMAJidl6uvL6Ddedg mQgTatF0vpD3rsBll/Oza98RlP7iivCckaSnSKVSGWWyQJb0VVU= =qn3B -----END PGP SIGNATURE----- --t8M9YdKMmMeh8hjh-- From nobody Tue Jan 4 19:14:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 31AA319396B4 for ; Tue, 4 Jan 2022 19:14:45 +0000 (UTC) (envelope-from carlavilla@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 4JT2P06Z8lz3j6F for ; Tue, 4 Jan 2022 19:14:44 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: carlavilla) by smtp.freebsd.org (Postfix) with ESMTPSA id C11672D211 for ; Tue, 4 Jan 2022 19:14:44 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: by mail-ua1-f43.google.com with SMTP id az37so44071723uab.12 for ; Tue, 04 Jan 2022 11:14:44 -0800 (PST) X-Gm-Message-State: AOAM533KFu6ahGUKj6/6Gkgj3E7TSftJc5r4cB/973JL6/kDJoMJDC29 MXN7PkJgLf05Z9UjxbJUAEJgKfQCQeSRqOXorQE= X-Google-Smtp-Source: ABdhPJycuwiBvtEyJROjJVNhjK9uBHI+qnetIU8BK/ODLrwf2p9OfE5BxSe2uaKUfLGaYYnHET3kxrODpZcPrpQKhdQ= X-Received: by 2002:a67:3085:: with SMTP id w127mr16099476vsw.72.1641323684397; Tue, 04 Jan 2022 11:14:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <861r2l914z.fsf@phe.ftfl.ca> In-Reply-To: From: Sergio Carlavilla Date: Tue, 4 Jan 2022 20:14:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: tech-lists Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641323684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l/FaNnaeB7b79ZcCNMV27w7ITduhc7g0eJf+HoG0qJs=; b=m0ll+F43Fx0xOfUDQ8D1Y1bDLd64SghjtTfuHcZtThlJU5ia6NLYawVl6Z/o2tDDm1kr2x CwFFwm9uUW/8ZF/7mV/uocSPOt9phFR1iIl4obUCLNkAJZr/KYj5R7BCoX8yWka3s3N2Am kpXorye0VEIzVh/lKNlOo7zLApgP7VORZDlrV3KGDdUhNPW/0L+SvjXAQK5P5VOmmgGkDK NqYjgMMEN9gj/qOVpNYgP5aDcTAs3Yqemekvt+MViDo87aHUa8VgrqLoxB+J6gkscJu5rX Fgr+5XJ69B69gjaWCfTt+5kPyy/OR0COvoH7AETBiSotxCS4OKuAwosX5B0tBQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641323684; a=rsa-sha256; cv=none; b=aOFif9JE3Jc5pvdJYUj0CHKPDnjDHbJGnka36o+HgMyqz59BYnokz7ioXGBPBqXeT4bqzA NEpjzh/YmQ6F21YAeqez2F6+9Th+J8WyN2vp37VV9zAg7o4qs1dAyRpSCE8FzVuhZhQEPG TOELadaGqtWyJtRWW1Fwmb5c5HIUZ7fXmgiwWEFhcTBnu5jb/ZBvy6YC+kEO7DWiwYfn55 vz4ccN8ZqzovyduIMXvrKoPB1ifCPFSSixk5JrvzEnAjNavL64lPtyFX/OJ0WAuBfzvQBi 8k/zuFWQvROx4Hc5fDCuoXyi49mRjt0y0DTwZzZtq+oLoCm+FNbeEW32B44K9A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, 4 Jan 2022 at 20:02, tech-lists wrote: > > Hi, > > On Thu, Dec 09, 2021 at 12:46:52PM -0400, Joseph Mingrone wrote: > > >Thank you to everyone who took the time to contribute project ideas. > >Here is a summary of what was submitted. If your idea was missed or > >misrepresented, feel free to add or edit it. > > > >https://wiki.freebsd.org/2021FoundationCFI > > Not sure where this would go, because it's such a general thing.. but > I'd like to see a hard commitment[0] to ensure the date-of-creation > and the date-last-modified of every page/article within the handbook[2] > is somewhere clear at the start/top[1] of each page. > > Missing manpages or instructions are bad. Inaccurate and out-of-date ones > are actually *worse*. > > [0] meaning that if this information is not present, then the page gets removed. > > [1] meaning that it's not in javascript, or in a sidebar. In the main page so > that it can be read by AnyBrowser/Viewer. It could be justified to the left or > the right. But at the *start* so that one doesn't have to read the whole thing > only to discover that the instructions pertained to the previous decade. > > [2] not just the handbook > > thanks, > -- > J. Hi, I'll take this task :) Bye! From nobody Tue Jan 4 20:28:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A5C4919227A2; Tue, 4 Jan 2022 20:28:45 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT42P2dtWz3tXD; Tue, 4 Jan 2022 20:28:45 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-249-199.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.249.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 16D292D962; Tue, 4 Jan 2022 20:28:45 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: freebsd-announce@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: FreeBSD Foundation Soliciting Project Proposals Date: Tue, 04 Jan 2022 16:28:43 -0400 Message-ID: <86y23vckjo.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641328125; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=cXeekCzKxZXfMmpHILV+3PfLJqwW0LIwI9wugQy6HXo=; b=k/O6MM8IyhOSGw2BnGWOUtVKHTOCErtSVL7axKxR014MpcrV6B+b8JBEG3pT4KVeeEDPPy ZlxRhs260Ok8lJ6R3sEHq/xyGhQfKYtPWVYMkxDaWoiizYHV/F/8MR6g6xS0jQFCbTBRd0 6HLRuY72d/xPRlg1MV6KqplVeOBhPeQ01K9ZmL+5abSxM3CjPPeoZVPkrL/7DkGdGtAvRX /yRYqlFikwg2PhA4Aj0oAeXl7Kc06aGv6N0146nWo2IyJqe4jOJN16InPLaubTk0N/TBYV XZM88uUvC5Qv9upg1RYDS7YFzLBHaj73ZKdwopV7MthNmBp241+nz9hCB4l5xw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641328125; a=rsa-sha256; cv=none; b=CXXXdxqRGL9q05wsgulny0QYWP7uwC4vByXyTGjbz9Ux/WXspQy8Y0J5tbQyZgGHwRlkvc GEUwsFyG/OPjbWc5KDUwVuCVIOkL+jNVtVP7fkWu9SArDZz1BeFa20j+sVd7Z9quHXILPa yWL8ac0FTzc/Rwshd4SYyC5fVY3oTaPUZgaAHVk+/n8NVWYrNAf6d2Jxe01Q+cAA2eUG1e m22oTmdp7Ukjx63ArTXk7nUnZ+vqtdlDx97qbk7C4TllRblHPGBGUudGkrh80ltrGAkuB7 anOoSxSJsUYxKAqQNboHpevTxMJkc08dsZVyLqfp2IahrLMVy/PzKAriZ5crHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain The FreeBSD Foundation is soliciting the submission of project proposals for funded development. Refer to the following documents for information about submitting a proposal and for project ideas. Proposal Overview ----------------- https://freebsdfoundation.org/get-involved/project-proposal-overview/ Submission Guidelines --------------------- https://freebsdfoundation.org/wp-content/uploads/2017/06/FreeBSDProposalSubmission.pdf http://issue.freebsdfoundation.org/publication/?m=33057&i=263272&p=50&ver=html5 FreeBSD Foundation Technology Roadmap ------------------------------------- https://freebsdfoundation.org/blog/technology-roadmap/ Contributed Project Ideas ------------------------- https://wiki.freebsd.org/2021FoundationCFI Successful completion of many of the contributed ideas such as Raspberry Pi hardware improvements, support for the exFat filesystem, and adding Capsicum use in more applications would be beneficial for the Project and have clear deliverables. However, please do not feel limited to these topics. We welcome proposals with other ideas for improving the base system, the ports tree, documentation, or other areas. If you think your proposal will benefit the Project, we will consider it. Please send any questions about submitting a proposal to proposals@freebsdfoundation.org. Key Dates --------- Call for proposals: 04 January 2022 Deadline for submissions: 15 February 2022 Notification of accepted proposals: 01 March 2022 Regards, Joseph (with Foundation hat on) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmHUrftfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnsNdEACFDLPk8V5X2JM/MiD3EnI4Rip9AjZ7rp8t 7XsF8S7m1xDEJz6PinIv06F7EJo6lGyO2RAUt70yU8Zspk4qqYCV60gsOYLKr8jn 5kHlm3lozSz5+uQHzgNvo24lBhO/IaIFZQhaTw/0SeBN4ts27hGsm6dRhJtX65nE 4yFF5ZYmvlqoWp5ECY9f6BEt/a++wV6K05U80y00WIwSWsm2oU5h290uhcHdkPAi 2KvBf1Mv6rmo4xg+4VTZBRDWkyQ54KBys5mGxBAnIiPQ/SDRtllMA72uBPOwvP6I J3udwLrI60R3HmlvQ/euJTQsG45j7DkXk6JTuGHB6XoB+q2kHJqqDFFF0hQ9ZZSZ D1MQxQ93nqNA2vwjFIjtV6/MIXhAHznbTJjvTF761WTvQ4YTmse1V6D2ttbUNy9F ro2su6ROf3XK0cs+5dRfgKBda1sWW/jwxlFz59ihLnav2fI944rZkK+Pq7XWDSOw sqtbvYpxBKmGkNIOlakqpkh8gnpvD+2tN0zBQKhnIOtk5ZDaxj3DvjZSriIJXVQ/ JcAe42pe86fY1t0x5uNfmUn5r0lNMa44AJ3I0wNDTv9RfcB41S02o9DE6gRkd4nM Pb9zg2erNYD9PiqOxms+feUs/XEvKqfVzdH/GnYMHnuAQ1Jyz0/Y6E+ZypKvJJs8 UFtH1f/zWw== =55i+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 5 00:09:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1436A193E66A for ; Wed, 5 Jan 2022 00:09:24 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JT8wz1hxkz3Pm7 for ; Wed, 5 Jan 2022 00:09:23 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id CBE9A5C01AC for ; Tue, 4 Jan 2022 19:09:17 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 04 Jan 2022 19:09:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm1; bh=/Cj0QtOodJlnmzRO/kAadOzhjDN+lmTsLpUWErz8x58=; b=rvjIKNnX 7uwja5dA1gv0XRrKyCZLlwqZ6iLZoSlm+/lcvUESQ8laB/brAdIZ1FxbZIOXS3t3 V/ugJAOMwBM60zYa/2QxFaqRi3UN5wnElj2pjLkGDpz3M8De13frFAwQK2w+SZMb HFMZzwdu5YLLAq/WJsb11x/C25ueZywYVygCNaE5ki0jWDTyc1bkV1U1fi7wDVuj aXp9ljG8xpGKeFoOdOXM1vzOI72MVnGI99pTgqI1QoUDvBnzqIuGFX8TjuvyIczn wkNZ1waBzKXs4aMhcA6ToSeHT5n6ivIkHw1x4vb+cFnPnzF+O8NZUgtsFQc0A2HI OOZ/lcFx8IqRGw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=/Cj0QtOodJlnmzRO/kAadOzhjDN+l mTsLpUWErz8x58=; b=GL5SqwSZXgQ+WHm9sKowLAu++ULZbnoEY4rCPa3P1eUI6 2KRIMQ4r5mnRdkTkB3rEFTWTVjV/1pA/FP6QP2VPIInCZQWi+OKXZWj6Hu+PvvbY cydIFiQ+P1kVzfS6CxyYn8GvRoXcok5Mq3qKKraGwU41KYo73B/ZNdLgEa/6LQKm R1Gbsa5W+UPrH67zO5zEkNMufcuEJDleN8m1aRTlnuIwTWaJsgdD6QwCbv0AySwQ tw1JijM2YOVR+yS0htPHFWmH6PGc15Z0ac0Wu6DDU50LkGhPAlUBxYcFIMhxZvkS 5XQ9s41rmRoMBup5rDoChDflOa85ZxfnombL3Fbew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefgedgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeeigfehtddttdevueetudetjedtjefhle eiuedvledvvddvieffgfehtdevkeeutdenucffohhmrghinhepsghsugdqhhgrrhgufigr rhgvrdhinhhfohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 4 Jan 2022 19:09:17 -0500 (EST) Date: Wed, 5 Jan 2022 00:09:14 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="swMl0K/E9y0JlD5w" Content-Disposition: inline X-Rspamd-Queue-Id: 4JT8wz1hxkz3Pm7 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=rvjIKNnX; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=GL5SqwSZ; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.26 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from] X-ThisMailContainsUnwantedMimeParts: N --swMl0K/E9y0JlD5w Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Are there known issues with Ryzen 5600G and freebsd-current? In particular with building *some* ports. perl5.32 and llvm13 fail to build, nothing on bugzilla and they aren't failing to build on any other freebsd-current system. This is a vanilla freebsd-current system. It has git installed (via pkg) but=20 little else. It built and installed world without error. I'm wondering if there's something like a sysctl I need to=20 tweak for this cpu. Not sure where to start looking. It's not clocked and it's not overheating. hwinfo: https://bsd-hardware.info/?probe=3De67007df20 --=20 J. --swMl0K/E9y0JlD5w Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHU4Z4ACgkQs8o7QhFz NAXmcw//WHrD1qqk/9N4vHtjGECEP4aDbcoEEnCb6O+o/L9ya3B4AWySqzAUs55Z WwLLkp3kbcstz7swypwjTCcxgsehpjuovAVrZyHZ0DsBcfyHzinEFghnANolHBHX xqYDihnEL9GGNRQmx7MWMbgdtjfyJFFXvnWx76ArSzif4yjy1lmd2P/ziEYsxbsK LO3mcKpYPmibCwbByfD67nIyG/gyS2/W9pZpo6v1r0hU8AlHzdrkMWqD8hdg7SqI RFJpDPkv4yHTlW8lOgplxPZqKZmFXUPZ30Yptl+iNEXdm3LjaKITEPaZ0x2cTEbC wcQ6Zr4g7d8qvjrGESC/V31kh3Oi7/7nR0S0CSr0AcAkya4GuBFkdZlXdAdwOvLY WyOeEzhOvpdxOpXDhAeOLm679aP8FJ1/yO2CNnWgQxVX3rzAKXVuut8eI1RgUSIt Eyo69XDk1++QZVY1QTmGaduEjCnfuNynIboRSPMUkhwWKuv3AVe1wPS0pBkQ3O8q wUO/V5MigV/lLSomKdGTBG+u7qTWNiBKrPvAtnC0gC87dAwzBEzXMjZMwu9+aTg1 TkPy13Jjl43tum/PEX98CPe5EJGnFwT733Se2XAhkXOpEXB/62QEyzTDeqMCquMm JXXYo3dpREfnFMK3f4EWS2GEp4xZA4/vlnAWKL0D6C+Rv5/UKIo= =xnFc -----END PGP SIGNATURE----- --swMl0K/E9y0JlD5w-- From nobody Wed Jan 5 05:18:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AC40E193B296 for ; Wed, 5 Jan 2022 05:19:07 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: from mail.rickysquid.org (hwsrv-751118.hostwindsdns.com [IPv6:2607:5501:3000:207d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTHpL669Dz3F3V for ; Wed, 5 Jan 2022 05:19:06 +0000 (UTC) (envelope-from ricky@rickysquid.org) Received: by mail.rickysquid.org (Postfix, from userid 1000) id 75EEB45695; Wed, 5 Jan 2022 05:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rickysquid.org; s=default; t=1641359939; bh=RS0706j1px0XHnQTpE6/JcV1P7uLYXXprmXnlRjTBco=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=axePmV3hi3gI6Kso/OxgVPiqy27k6/1wZbAoYNljyhkmefzDOSI764lWqlaE4znxh bZGvXYV7CBva7WyHrFVoEz6P+VgssoRJqSfKmuuBlSOIMeXXuTOIFsGupT3IQzWzoF K1sDvXR76FbxTdpvaHCNYXuCJSuhi9gUnTCt6kiTz1OH4omeyODAQpIzevEmlYbu4W pJq4gTxZl+wUbZZRRVt5liEw6slNDnWFScV0hLetVXaoNf6kSKqlhvP37zgzSBCIWq o1D3MElg9CooAXGpWetMTqVECvwUYKsze1K7uIXTgei2zw+sTAcpq6SfV11WEe9Jdi W+M9BUDeJMeKA== Date: Wed, 5 Jan 2022 05:18:59 +0000 From: Eric Gullufsen To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: leak sanitizer support Message-ID: <20220105051859.GA28486@rickysquid.org> References: <20211230201614.z4bsknfgdde7ufwu@mutt-hbsd> <20220102002851.GA32472@rickysquid.org> <20220102193506.GA6478@rickysquid.org> <20220102210156.GA16266@rickysquid.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220102210156.GA16266@rickysquid.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4JTHpL669Dz3F3V X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=rickysquid.org header.s=default header.b=axePmV3h; dmarc=pass (policy=none) header.from=rickysquid.org; spf=softfail (mx1.freebsd.org: 2607:5501:3000:207d::2 is neither permitted nor denied by domain of ricky@rickysquid.org) smtp.mailfrom=ricky@rickysquid.org X-Spamd-Result: default: False [1.22 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[rickysquid.org:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; HFILTER_HOSTNAME_2(1.00)[hwsrv-751118.hostwindsdns.com]; NEURAL_HAM_LONG(-0.98)[-0.979]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.994]; DKIM_TRACE(0.00)[rickysquid.org:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[rickysquid.org,none]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:54290, ipnet:2607:5501::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jan 02, 2022 at 09:01:56PM +0000, rickygee wrote: > On Sun, Jan 02, 2022 at 07:35:06PM +0000, Eric Gullufsen wrote: > > Awesome sounds great - will test with your new diff & module files posted & > > report back here in a few - thanks! > > > > On Sun, Jan 02, 2022 at 09:53:06AM -0800, Luoqi Chen wrote: > > > locking issue and also to cleanup some unused code, would you mind trying > > > out the new version? I've updated the diff files. > > > > > > -luoqi > > > > Hey Luoqi, > > Dang you rock - I applied your updated patch against -current (commit > 642f77be1d), and everything went swimmingly in initial testing: > > -Eric Hey Luoqi, Shoot so sorry for my confusion, but it looks like the updated diff/.cpp do not actually run quite right on -current. I think this is due to the signature of SuspendedThreadsList::GetRegistersAndSP changing in June 2021 A commit in June 2021 (e8d8bef9) changed this signature on you in sanitizer_stoptheworld.h Here is `git show` for that commit/file, where you can see the sig change: [e@bsd /usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common]$ git show e8d8bef96 -- sanitizer_stoptheworld.h [cut] - virtual PtraceRegistersStatus GetRegistersAndSP(uptr index, uptr *buffer, - uptr *sp) const { ++ virtual PtraceRegistersStatus GetRegistersAndSP( ++ uptr index, InternalMmapVector *buffer, uptr *sp) const { + UNIMPLEMENTED(); + } + [cut] I think this explains my run-time errors when using lsan on -current (see output) [begin error output] AddressSanitizer: CHECK failed: sanitizer_stoptheworld.h:37 "((0 && "unimplemented")) != (0)" (0x0, 0x0) (tid=169384) AddressSanitizer:DEADLYSIGNAL [end error output] Anyway - just a heads up - you probably would have been right on it when you moved up to the new header, instead of squinting at lldb like me for *awhile*. Oh here is a patch it might be easier to see it that way: https://raw.githubusercontent.com/emgullufsen/freebsd/lsan/lsan-params.diff Thanks and sorry for my confusion earlier! -Eric From nobody Wed Jan 5 06:59:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1EA511935CD5 for ; Wed, 5 Jan 2022 07:00:40 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTL3W0Tz1z3mJb for ; Wed, 5 Jan 2022 07:00:39 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: by mail-pj1-x102c.google.com with SMTP id m13so835037pji.3 for ; Tue, 04 Jan 2022 23:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to; bh=Oe4xNJ/YVGY3ze72l1WNM9YAX6vP/ilvKMkU9LbWx8c=; b=UjDwIsVcForl7Fd38mVOjwKYlk4nSzALgg7qC9ZF4rtTpQXYdgkKjUNqIjdVIXvpV3 vp98zJYsJ4J9cC8piMZg0bP1Yzl6qsBa73zMZu6wveo8MnkmEvFHjtlUxTM3scSXMt1j NFtindv2V7lbC8dLMrfNol1OQ8JL+n7oovgsiK0ZgRAJe+IR1Rn6hwqGBXXSzNaLP66d NNnUHe1dQXYmuCBzqbY/9/ewev66Z+3IeSQV8kfUuR3IayN4mA25kAd8/0AFuq7BFr5d oqPiL6AHokqmyVT6raS+TarnrC4Dwb2dDGDyFl7wQH/DsfS5droztN2TbikpHAdYSruv lq8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to; bh=Oe4xNJ/YVGY3ze72l1WNM9YAX6vP/ilvKMkU9LbWx8c=; b=nH6IcjZA1aoSuZsZ12A/UeuDzCbu1KBZ+2SWsGCXu6rbw+q+i2fYf/A3PCuLfLkONI vf1ERkBJBYT21/DgbL/OBmdzMNiZ6wgHpWcOJXERVf/jkxmYkQxppzWcsp/BLmIQqUlr rxVRJHh/whUZ0ep2/q4Tt/l/EDIvmDSgrSJ3LV+rUMScASPBmTy01v2CzKg0e5c+oIp7 tVrHj1qOUD9IGm2UgiN76UCwnyBpdUXbjHhqrjpI/WZhFOTx8Ds6vtd6aAV5FTtBiwru e22+3X+Tgn7pm4oZLsmhewHdC8QPKJo9vWiv8NRsYVdHLIl5CM2lPMpaZhj9xrOsAZ56 uLkw== X-Gm-Message-State: AOAM530pOADACJR3Yp46PlJtgosGaY/WA45ChzhPbKIQvB/q5FX33X6F c+JJUaJWL5Nh36jHRnvdBL2byGkQS7k= X-Google-Smtp-Source: ABdhPJwr5DqItD45sEr1sydeBeJ9SMXla52nKRqmmw52JhqYVNU2Q7tR42giMQBhb6iuIQdO5DP+VA== X-Received: by 2002:a17:902:8b8b:b0:149:6d32:4b4c with SMTP id ay11-20020a1709028b8b00b001496d324b4cmr46118235plb.8.1641366032604; Tue, 04 Jan 2022 23:00:32 -0800 (PST) Received: from DouglasBSD (236-53-74-65.gci.net. [65.74.53.236]) by smtp.gmail.com with ESMTPSA id f22sm40766388pfc.183.2022.01.04.23.00.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 23:00:32 -0800 (PST) Date: Tue, 4 Jan 2022 21:59:34 -0900 From: Eric Gullufsen To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: leak sanitizer support Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220105051859.GA28486@rickysquid.org> X-Rspamd-Queue-Id: 4JTL3W0Tz1z3mJb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=UjDwIsVc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ericgullufsen@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=ericgullufsen@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hey Luoqi, Geez sorry for the hassle - I am just changing my email addr for this list - was having trouble sending to gmail from my own domain. Anyway just getting that updated and squeaking a bit since these were probably getting buried in the list on you - thanks! -Eric From nobody Wed Jan 5 07:38:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8469E193FC70 for ; Wed, 5 Jan 2022 07:39:33 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTLwN5t31z3tZ6 for ; Wed, 5 Jan 2022 07:39:32 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: by mail-pg1-x52d.google.com with SMTP id t32so3257753pgm.7 for ; Tue, 04 Jan 2022 23:39:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=uXWNGzgAJ1u/KgdjGORkbNZ7V9G5Rt//uzfvnFo1NqQ=; b=fqfJXJ1GsmLRiAw7wtOc+XVOk5h64lWH0eBZJLLsHtu0HQMb3A5lPdEpYri0e0Sl+U mT1H3/4w2nV9QsZ9ucQq70iGfy9Xvb16yATE296QhU1T3lwSuUXQD7817E6DYgIubU5V DtX9lo1WyII1WvX/+gTbHTxUyV6UXiiAKzLDChp6f/LRZdo1bP3NkLy2QUc9rV96fiFX Ml3CqnzjnwhL4qcz+qfiydup1RNAgukMNsy4rQDcG+sSQBMIrG3lPMxrdIhF++DSzWTw XBPeS3s3szpSzHJiUByFWfq+xlvVXlUHZXuLERwZ8UEo94gPaf8aVvkd0i3ha02kYf/1 cXDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=uXWNGzgAJ1u/KgdjGORkbNZ7V9G5Rt//uzfvnFo1NqQ=; b=oGxpqKTRnNrQF/ZwQRnmMYb2kpz/2ECOp8KYADbxJF2FS4eBQKy6ReMsy1++kjwowW 0GVDTEPHLH+zQ8sHl4w5ENlH+5xzxVHJAwnmD3F5X9hq3z/E9bfVf0/w4w3GyqBHBguM D0HGU/wcmamx+o0ziRWGpfNQdxnqvPFpLbjYJDqOHMEO3zzOnJFHUGOad7dMvqphz50s Uz9aTG2uJiD0sqDuoshpAvc0Jvuc5nV/y663DiJB7cuRoF4wH0GW1FmgHOzfXOmCq4SK wBlLDGCgZTUkaI8w9Vu3pAec2DUh714JB1DRyJoeUfsL1OaW706gtfEimM6hMnEazzCM wjJw== X-Gm-Message-State: AOAM5318FSXjI+2lcJkyjZZqBxM4wPqq1x91T4Lv+LidYH6SiYI+DG2V Ua/d/wgDnwXbFJTYWsuROLg= X-Google-Smtp-Source: ABdhPJzCMfkvHu9unjTT9y7dretauxNUJax+kpeqPQk7eL6serEsuS87u3DsOaA+AgI8xcUWe2VmlA== X-Received: by 2002:a63:33cd:: with SMTP id z196mr25066200pgz.78.1641368371925; Tue, 04 Jan 2022 23:39:31 -0800 (PST) Received: from DouglasBSD (236-53-74-65.gci.net. [65.74.53.236]) by smtp.gmail.com with ESMTPSA id t80sm12993621pgb.23.2022.01.04.23.39.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 23:39:31 -0800 (PST) Date: Tue, 4 Jan 2022 22:38:34 -0900 From: Eric Gullufsen To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: Leak sanitizer support Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4JTLwN5t31z3tZ6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fqfJXJ1G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ericgullufsen@gmail.com designates 2607:f8b0:4864:20::52d as permitted sender) smtp.mailfrom=ericgullufsen@gmail.com X-Spamd-Result: default: False [-2.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.91)[-0.908]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52d:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Your implementation seems to work splendid with the little adaptation to -current: https://raw.githubusercontent.com/emgullufsen/freebsd/lsan/lsan-params.diff Super cool - Thanks! -Eric From nobody Wed Jan 5 07:46:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2DFB7192226E for ; Wed, 5 Jan 2022 07:47:15 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTM5G0TnLz3wPQ for ; Wed, 5 Jan 2022 07:47:14 +0000 (UTC) (envelope-from ericgullufsen@gmail.com) Received: by mail-pf1-x434.google.com with SMTP id b22so34475614pfb.5 for ; Tue, 04 Jan 2022 23:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :in-reply-to; bh=6Ur/5IRO9NisaV3xr+AcPJwbRP6J6/TbPULejS3GiVo=; b=BF6DyYqDzR1PeXplRtH3oqt1LrcQm4YSfDnLOnu1ap4312QnRGk+i6hpNnbByhvVQH l5GSeX1DX+ct1KoGI0eJpTa4lEM2sl287pIHgEVtL8+PqGNSCd0KXYGHK81uJts+e5R5 z/4DWojs8ysyn0XR0PXMFaby5T4VAGCIvThafA2cJoh/KezdnuIqIJQ1J09itOE/QmRP nlBpiXxGZ5Cj7YSJ0sjaBzCL1loSVCZldFtYVxKB8HrBTSa8hSXJtx7DM6hmTyKkxb66 zI293ecKRQgFWCUh6Dmxrb7lkpwAM6g7t77FhwFYZeAzZOIwy4udCJZbAdrf0HUBeo9N cnuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:in-reply-to; bh=6Ur/5IRO9NisaV3xr+AcPJwbRP6J6/TbPULejS3GiVo=; b=u5xhFkKRNbCQkVTl8LmXk3RgI3gUcGgJkyqj/7hdFtbebqpegUKj3eWtr5ut+w0Lv4 3IWGY9w2XkqPupUE7vJ87wmT0CMd90Y+s4WHY7Gtg3AZs2PJ05lSSg0+2vDYdzUwBis0 43bqzmK5y4maaE1mfB0POv1bJtXWBXzdXj2fWUnkWqe572EMUz31lLLswZt9e2tL6KG2 +L2iC4eKwLJ08Orb1bEztAtWkkAiQSLeKDPXs3+vXRPrMiXXTWptCQlUJMzBbaly0Dsv ol5v9+ikGC0KSHz+u733k/g5XJKxlg0zF61/GR2Ws8egfcTYev7hU0T8qEWQJeh7wOA6 5ong== X-Gm-Message-State: AOAM531jOdy2xX7Xp0FzxY5NsprSWxPdiFZ71m7hteHnCf/mEjQKo0Wu 8LymitWKp4PS8UB9TU2chOMEnn5UlNc= X-Google-Smtp-Source: ABdhPJx4JKurmC6azvZj95aDT+4emoqcFviN+vPI/dISGz6b2v7ZcSFsRfll3G7yUM+X+T/Hw7EJMg== X-Received: by 2002:a63:3f82:: with SMTP id m124mr31566904pga.85.1641368833299; Tue, 04 Jan 2022 23:47:13 -0800 (PST) Received: from DouglasBSD (236-53-74-65.gci.net. [65.74.53.236]) by smtp.gmail.com with ESMTPSA id b27sm2057248pfp.51.2022.01.04.23.47.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jan 2022 23:47:12 -0800 (PST) Date: Tue, 4 Jan 2022 22:46:15 -0900 From: Eric Gullufsen To: Luoqi Chen Cc: freebsd-hackers@freebsd.org Subject: Re: Leak sanitizer support Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JTM5G0TnLz3wPQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BF6DyYqD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ericgullufsen@gmail.com designates 2607:f8b0:4864:20::434 as permitted sender) smtp.mailfrom=ericgullufsen@gmail.com X-Spamd-Result: default: False [-3.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.89)[-0.893]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::434:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Your implementation seems to work splendid with the little adaptation to -current: https://raw.githubusercontent.com/emgullufsen/freebsd/lsan/lsan-params.diff Super cool - Thanks! -Eric From nobody Wed Jan 5 07:55:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE0C619258E0 for ; Wed, 5 Jan 2022 07:55:45 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTMH54GH0z4Skv; Wed, 5 Jan 2022 07:55:45 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 8D59A32D7D; Wed, 5 Jan 2022 07:55:44 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Wed, 5 Jan 2022 18:55:38 +1100 From: Peter Jeremy To: tech-lists Cc: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EP+CAZNlvax0vweo" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641369345; h=from:from:reply-to:subject:subject:date:date: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=0LHSPIZwf6lMoxugYMnVCSb+k8MY5j39kHUSnyaHiNM=; b=Dq9vHHa2Lt7ue4eAz5NRoctp+4XAKzLQOzgPSUnJJzT8C+P4TDmWddnLuIUxqcVbh3qena leW7LQaPJgXk26WU5MQCucb8FSjJ2ar8QGMySNyIxksz1Kagq1y5APt1Z6jLm/uZbFw7fE HdFRtGHvlXhZIABQG8i2+I8p/EZf2ARHw+wN1mZzTC1vjSLzVsfjq9DdEd07BUi5A0xvHo s0rnpiLYvfYiB9eJWaxGinKbnNOSquPGjN5cBhboffHbyQYybinpSTuHwmbkJVkXhjLmyK yeyckOcDJpoO+TR4ZEEz9GX/ARjwRTQE5xusrseEl/DiIqzxcrqr1FwT1RWKqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641369345; a=rsa-sha256; cv=none; b=eTJD6B37lkZKq1Uj+J4OJA6nvYm63lYKu0NeB/ZQVaPSJQhMvEQ9GtDN9hSrpyzdnO8Ied 5hndgIA0uXxBgDZWQIjiCHntf3naN/012HHPx2JJkAk0CYtxCiFS14ev5vgqNIqqVoiEVA Yzl8SclQLfLgQ0cGowVct8of3z0tsZR/SmbqxJoOaZ1Z2gD4OHhX5euEsAfAA6mlkYPr2+ qbggng+cedFIWriXjVxWw63sYD7QN+SshFqg+IRkKoS6e/n6LgpmEd7gVMTF23r/VuYVyH vqcdOg4rdsdppTaXCHb1qllYF7N+R+J/+N4360KyiElbFKktL4ydk6ZGu6wa6w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --EP+CAZNlvax0vweo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Jan-05 00:09:14 +0000, tech-lists wrote: >Are there known issues with Ryzen 5600G and freebsd-current? This might be better off on freebsd-current, rather than hackers. >In particular with building *some* ports. perl5.32 and llvm13 >fail to build, I can't answer your question but I have a number of questions for you: 0) What is the exact version of -current that you're running? 1) Can you share more details on "fails to build". Are you in a position to share a build log. 2) Are you using ECC RAM? Have you run memtest86 or similar? 3) Have you tried (eg) FreeBSD-13 instead of -current? >little else. It built and installed world without error. I presume that means a previous kernel/world could build/install world. 4) Have you tried a buildworld with your problematic install? >I'm wondering if there's something like a sysctl I need to=20 >tweak for this cpu. Any CPU-specific tweaks would be in the kernel. (FTR, I have an AMD 5600X that's happily/stably running 13-stable). --=20 Peter Jeremy --EP+CAZNlvax0vweo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmHVTvRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSgTxAAhLW7uREyqNYChPTgbdHG5PIS1GruCg0waZGbTxYVbgE5HZkru113YN1R YgZ7/mWDfht4mbggyCgWhv+tUXaozzMLVh5z3f/hNUrYaVVp0PUSSAMO16qb1kH6 ry8NlY84mXT9h4Scga8NabKALZcs6WDCWrv6ZZxuYaQkW3DcLrCK2L67nMUb8C40 SrdMzg45O1vNG/r418jeVIJUighye9d1gghN7/frINQd+5vCNU2GcI4QUCHXv3EI qCdVpYuP+6ms3zVZ16yM8AMgHx0Y5MRNKJpb28uQKQFMArp3wDeBtPghXpR0F0Iw SV8/czN6Y/STUDlLK41lEFrc/doLWcFQLYfHoqyo+JhN0edO3CaS9aV/TMjd3rTv T8mQR2jIh4EO8mEyCWeThTGV8/slb4tl6HConCcPq2TFpTb8HyddA9mcThMw/Dfo mC82BJ4lU/qbwb05WgG4vtiF5qulcHZtNqm5O+zjGqLBpF+AF0P2pBYFHaw3eEPT l/IX4bUKsCEacf+ZpAVxPQzS0H5c84rmIzDy6QJ49H1wjp7P/VG7YgM2jwibn6YQ Z4+rBCblA+VIx2RAdAzo7RLf2PyHTbIXMBJOwupPmuoduGTYm0Ju0pJk4lVX2mCP 7cyPs5igq1Cdo5HMqq+DrdqRgt1587jgQCYS/Q9BM43P9E6eYD0= =TA+c -----END PGP SIGNATURE----- --EP+CAZNlvax0vweo-- From nobody Wed Jan 5 12:16:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 938B51938C38 for ; Wed, 5 Jan 2022 12:16:12 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTT3c3Nj5z3JMs; Wed, 5 Jan 2022 12:16:12 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x129.google.com with SMTP id u13so88532438lff.12; Wed, 05 Jan 2022 04:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=YePaATXKMp6r8zlUKu3N7G9tqfJl0VC0IQXgHghtCUPQ9xuW7B7m/FBBXLUwhsohV+ ClLXd0h0KqynpeYvdrB+P8mpdIr/sVTyK0EiUH/A6Hx6dFBrp9pofC/iG1T9JKSZ/oea 373+HcQWrWF2/DKUD1qlU14K4BoH63X0icftZ8CGUSNI6rG9QRN3fyDDfdjjzHeCPzIP 1FP/w2kJqytLMUJXkJBNFSgQfw9p6ObRrrRucBY7ERsNWRRC/r5/tdNGm5ezLx+X4LcX +NHEDTMwA5dEctZUDXO773FJP6PMP5EQV4M7+34iZC1+AFnjlwxG00p1H5Fybt+iJn1W /sQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=PYpbposQgfjPbsfpVLNpv1s5Z6VSx/aaQlr7Y+lBOiiKLvo1Vcd4wgqs5yHLk9mETU 1fCv57FjG6aY6kw0ZDkkj4jgHU0cgqdEI72jp47ZpCtfsUHAfSNYaX7H9F4rAVkwpV3h kEA5R1z395Mk0UPsBtMVfNbN6lf5gedEr2DCO6sp4BRBWM7Y5Xzq1HBXqPs59udx01bO bbwT2eYI+nGfZCSvAWkycLAa2zZzXkpFZzEfNY6MrgXjUG/hdyVTxhqaCU97T+ptEVxp lgM/P3Vzm2l4BYRNruHc6fOwF2kaqQ7DUrcw2LKo0wjgWxSwtGDVo38vAtZgS/xeCQWW hb7A== X-Gm-Message-State: AOAM533B7ndrGPJJVV9P3D0Lt8AF+EltizinGGqdT649JGYXG9B4rg0b Me4Nw4AOxgWVat259sKsIHoFWNaUZ36MHYyJj1U= X-Google-Smtp-Source: ABdhPJzEsj2+AQUdqVdZxUNiwVfcJAMnNszTff+6N/uzEUFMNBprrGSeg8aj4NI4uHHDQbY3E99Ae3pX1mb5LsGDkDs= X-Received: by 2002:a05:6512:234d:: with SMTP id p13mr41676761lfu.157.1641384963777; Wed, 05 Jan 2022 04:16:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Wed, 5 Jan 2022 04:16:02 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 13:16:02 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Warner Losh Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JTT3c3Nj5z3JMs X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Warner Losh wrote: > 15 or 20 years [...] > main reason laptops stopped suspending in the early 2000s... [...] > And the INT xx interface is unavailable on amd64 after we > enter long mode First, you mentioned a hacking session in the "early 2000s". This makes me wonder whether you might mistake some other thing from the distance of time, as UEFI was no real thing until ~2010, and was never a thing on platforms other than amd64 also. Suspend/resume on FreeBSD only appeared much later, too. Second, there is kernel functionality to call real mode interrupt handlers from long mode, which manage switching to real mode and back. Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des. So I do not see why this real mode access infrastructure could not also be used to make a call to C000:(PCI PROM Programming interface code offset), or the respective segment address where the actual VGA BIOS is, to have it initialize the int 10h interface handler, if a hybrid/dual graphics card BIOS is present. I think a single function "InitializeVGABIOSifpresent" to enable access to VGA/VESA BIOS functionality might actually be fairly easy to implement. Furthermore, there is no need at all to access hardware specific stuff like you mentioned, as the necessary functionality is completely covered by the int 10h interface. Imho it could be worth to allocate a small part of the sponsoring budget to put a bounty to motivate people (including possibly me) to implement these improvements regarding suspend/resume and enhanced sc and vt usability. On 1/4/22, Warner Losh wrote: > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > wrote: > >> On 1/4/22, Warner Losh wrote: >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> >> UEFI GOP seems to have the necessary functionalities >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> required would be limited (restore mode and redraw screen from >> buffer). >> > > UEFI GOP isn't available after we start the kernel, so this is a > non-starter. > It works great in the boot loader, but not so good after we boot. It coul= d > work > for S3 sleep to disk where we actually reboot to restore the machine stat= e, > but we don't have sleep to disk today :( > > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. >> > > Ah, if only things were really that simple... I tried variations on that > hack years ago when suspending broke due to video. And it > works for some machines, but not others, was the quick assessment > I made. And the INT xx interface is unavailable on amd64 after we > enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?). > > Warner > > >> But I think you are right, there are probably not too many users who >> would make use of that. >> >> >> On 1/4/22, Warner Losh wrote: >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> > wrote: >> > >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> However, it still does only work when at xorg graphics mode, which >> >> already was topic in this thread. >> >> When using it from console, no matter sc or vt, it still hangs with >> >> dark screen and unresponsive keyboard. >> >> Could finishing the suspend/resume work be sponsored, so that it also >> >> works on console-only computers? >> >> >> > >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> > >> > Warner >> > >> > >> >> On 12/30/21, Joseph Mingrone wrote: >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> > wrote: >> >> > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> wrote: >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >>> possible >> >> >>> to >> >> >>> add to wiki? >> >> > >> >> >> Certainly. Please do. >> >> > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> > >> >> >> >> >> > >> > From nobody Wed Jan 5 14:47:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 104A4193C9EF for ; Wed, 5 Jan 2022 14:47:28 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTXQ66r71z3vpc for ; Wed, 5 Jan 2022 14:47:26 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 247F83200D30 for ; Wed, 5 Jan 2022 09:47:19 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 05 Jan 2022 09:47:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=vBF6p7y4/uQ3fUjFtjUKoSiwFON w4qQvm8DDXpiReqM=; b=fqOrq9vLNllFVcDcjGWWdVuwFvKSED5GtzV6yZIH4Vv yFSZWVtI7vg2CrYLFHDM9J5jW3bAhFCqbku0IRyYKcMAFygO8STZKTzUwWerRgRC 7IbA1eSXoCVpfqGNCbgGhO7p/Na+BScMh9J9AIOI9nrDI5WU708qthOecnop7Pxd q6fSIkEieGLwmvWd2acanby2jvRR9fqSH7qO/jJY47r+7K3IRWTVrafzsaPxzEV0 vS6Z0pzpGLRTK6LSHDHy+3VVOilopJoHXSzbqNyUuS2FOxEd2DcwU5PDgcVGKvZ6 xKa9ULu8zG1QHJ9CQpd8cLs6NVOLZkcLg3WkddJ5ttg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=vBF6p7 y4/uQ3fUjFtjUKoSiwFONw4qQvm8DDXpiReqM=; b=oHhADrQNdimfTfNQNdy5Li Q4zstudDb299CA3nVifsNhwRRZYlqvv2GnV+KeRJujM+wk8N45O8suPmHnx2Ks+S +FWD/Dj0UkfFoyNQJN0IbzSn2sHv4ewyyFTTKquk0WF5uXQJYN4Xd8eRU+jPbqIe /A2JK8vl2kbQiRUuVDNVltIGVT/CzqjaF7ZwNcO+AQ9mr7yEKCb3xV749EyPFujJ 719BK/OSG6BtdaxTlRoF+VLh9PCIvpcx/aciIl3pL2lmaivmSM/F4Pl2f9GoOFJI 4cj8y/BpPyKJIGjL1qBYfCnmFSbVwmIX7obrBH/8CTG1gr01HnmmntItPBSp+KbQ == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefiedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeettddtudeugfeggefhkeekteekje elfeffleehjeffgffftdeffedtjeegueeiffenucffohhmrghinhepfhhrvggvsghsugdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe htvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 5 Jan 2022 09:47:18 -0500 (EST) Date: Wed, 5 Jan 2022 14:47:16 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="C35ve0XOQSXWkWrO" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JTXQ66r71z3vpc X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=fqOrq9vL; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=oHhADrQN; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.24 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.24:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --C35ve0XOQSXWkWrO Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >On 2022-Jan-05 00:09:14 +0000, tech-lists wrote: >>Are there known issues with Ryzen 5600G and freebsd-current? > >This might be better off on freebsd-current, rather than hackers. Yeah I was confused about that. Is it a cpu/compiler problem?=20 (hackers@) or is it a -current problem? I raised a thread earlier in -current: https://lists.freebsd.org/archives/freebsd-current/2022-January/001358.html Context has changed a bit since then. >>In particular with building *some* ports. perl5.32 and llvm13 >>fail to build, perl5.32 failed to build because DTRACE was enabled in its config and for whatever reason the system didn't like it. It builds and=20 installs without it. As DTRACE is enabled by default, I've raised=20 a PR at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260947 llvm13 is still failing with a ninja error. I'll try again when the system is rebuilt. >I can't answer your question but I have a number of questions for you: >0) What is the exact version of -current that you're running? It *was* 14.0-CURRENT #0 main-n252210-3a9688f8bc4: Tue Jan 4 19:50:00 GMT = 2022=20 it's in the middle of a buildworld rn generic *everything*. Although the ab= ove build was vanilla it still had a src.conf and a make.conf for ccache. This = new=20 build has neither. >1) Can you share more details on "fails to build". Are you in a position > to share a build log. yes I'll do so as soon as it's done this completely generic build. >2) Are you using ECC RAM? Have you run memtest86 or similar? I don't know. The machine is remote. Need to see if memtest is in ports. This is the output from dmidecode: Memory Device Array Handle: 0x0010 Error Information Handle: 0x0018 Total Width: 64 bits Data Width: 64 bits Size: 16 GB Form Factor: DIMM Set: None Locator: DIMM 1 Bank Locator: P0 CHANNEL A Type: DDR4 Type Detail: Synchronous Unbuffered (Unregistered) Speed: 3200 MT/s Manufacturer: Unknown Serial Number: 00000000 Asset Tag: Not Specified Part Number: CMK32GX4M2D3200C16 =20 Rank: 2 Configured Memory Speed: 3200 MT/s Minimum Voltage: 1.2 V Maximum Voltage: 1.2 V Configured Voltage: 1.2 V Memory Technology: DRAM Memory Operating Mode Capability: Volatile memory Firmware Version: Unknown Module Manufacturer ID: Bank 3, Hex 0x9E Module Product ID: Unknown Memory Subsystem Controller Manufacturer ID: Unknown Memory Subsystem Controller Product ID: Unknown Non-Volatile Size: None Volatile Size: 16 GB Cache Size: None Logical Size: None >3) Have you tried (eg) FreeBSD-13 instead of -current? No not yet, that would be my next step after this build and if possible, memtest >I presume that means a previous kernel/world could build/install world. >4) Have you tried a buildworld with your problematic install? this is running right now >>I'm wondering if there's something like a sysctl I need to >>tweak for this cpu. > >Any CPU-specific tweaks would be in the kernel. it's been suggested in various places in other contexts but with=20 ryzen to add kern.sched.steal_thresh=3D0 in /etc/sysctl.conf and=20 machdep.idle=3Dspin machdep.hyperthreading_allowed=3D0 to /boot/loader.conf >(FTR, I have an AMD 5600X that's happily/stably running 13-stable). Have you clocked it in the bios? Which motherboard do you use? Does it have any special settings in sysctl or loader.conf? This system: Base Board Information Manufacturer: ASRock Product Name: B450 Steel Legend --=20 J. --C35ve0XOQSXWkWrO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHVr2kACgkQs8o7QhFz NAU3Ew//QiA+OmDZPnr1rC4Eat8GE0iLlJM1l/ntnUZNs7k44c1fw13yfoiesThK up5nhOZxkpSnt+mBG5PIxfzfh/1KlolHjr9gS1JbVNh2UmGeLFSxeqI3TVUMi6tF qu6T83h9FmHb8O1b0R9SoTh54eUeagvVdcPRAvn2NQkhmO0GKlSIOBUIdO+QMBEB fHx+JWQyoNxxv87wjlqa/j8GgWGkhGnFM28hxNztAhXvq6zWq+yJQrszs8ZzubmT JIhvPtq5GnB461t+2yFMQwJCznk0y/bMxWHEukwLuApC+T3zOrn8gKJNskcH81d/ xja+POHML5V75XM2PtXakKGIkPP8iV69p8vyd3yIipq/kNaXLOdtAflOtUbMikwr 9CvviJQ/EIdEM+Tf1RiSqUWJkX1zbMqZ5Qh796ERrs9GDeRkPO+iswArvIegyD7T 4F/xmJuV/JWJLtYwBR84fD3ql3MdxKCM7N5hBfy+TuqDdWOjEwyrtZkJtKJDkL4G bhFDTwLwONotN5nrQZ67CsVmPb3yITWLbXT1Bx1phB286NgERoELGQfi7hrDpMLP BF5QwfQ+rSVH4kJMIJjWa4D5qXynRVeXAU6CLJUA9oGhAfYDGTwsT7kihVibnnbd PgMSovwj/KBpd0eOMqmjvTMlQqE3sC4g+b0oCFzExDVToGfyBUc= =N8f9 -----END PGP SIGNATURE----- --C35ve0XOQSXWkWrO-- From nobody Wed Jan 5 14:50:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 82B63193DAD4 for ; Wed, 5 Jan 2022 14:50:55 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTXV66Sgbz4RF0 for ; Wed, 5 Jan 2022 14:50:54 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 15BC73201F88 for ; Wed, 5 Jan 2022 09:50:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 05 Jan 2022 09:50:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=nGfpj3ZR6k+Rz9tEZ7V4TLxgZKP FqunWvXDgB3z8OxQ=; b=VSpXvk1M7TlpuaTTcXVUcSBeqTg/P4dhXMuNyehtPEn PGUCByqIGKlmN9SCuUPVsiDZYhqjQ7+CgH6J9yahuCZEcdxoxWgVfSOCMapq6ViV g/POT9vGZjMcJMPxt1oAH8DYmUNAVfYY4D5C2VZJtZnPUqgVUO7I2osHdpufWcRf MKd8r/NeWB7mTNcm1gEaqlmWUmKflGcyVK2IzET0aaPd/eSTs9NW/yTYnsc1s/5R rFab48ViJOuXZPeiZ7E/0x5WtaCEE05dFF9JDhvGwoczyPHhzf7s/KnBqS/FhF2f TzeT14przix2oOQV3/MsQ9y8FIGidYQlBRz6/TsSn1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=nGfpj3 ZR6k+Rz9tEZ7V4TLxgZKPFqunWvXDgB3z8OxQ=; b=TmyVndS/6ybpJCZT3B/fiW s0pDmmd8CoNDRusA2SNZ+YisBED0a9j3g77bCYdFxorR4b9RBTJ1413kgE5Bw6Hk sX3WaL04W7vLsAZwWyOMh87OXDgz5MQbbbsvNCcmBTKTGKZihRf1zZjTiCJfAGen XALPWNLHTfiLc1kG+KOhzQlrvWqCKhKhLl6t57TU1ftfctKuGsM7PhxAnPbi6juk nZQghO7lKaN75Rq1jdr74cZvzLvVQtpc6MHPu2m3dAGIj22xf0c7Rkjt8tWhJqBS 0QfGGCpBbepZ00r0vhkcRpe5ibWpd6HwIu9HFN8HfSoAt2T7rbC4qEua6YDyQQEg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefiedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtheeigfdvudefkeekvddtfedvte dttdekuddvgeevlefftdekffdujedvhfduteenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 5 Jan 2022 09:50:52 -0500 (EST) Date: Wed, 5 Jan 2022 14:50:51 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RbyApAA0dcDWk5cc" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JTXV66Sgbz4RF0 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=VSpXvk1M; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="TmyVndS/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 64.147.123.24 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[64.147.123.24:from]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N --RbyApAA0dcDWk5cc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >0) What is the exact version of -current that you're running? FreeBSD 14.0-CURRENT (GENERIC) #0 main-n252226-ce1e5d0d5e6: Wed Jan 5 14:1= 8:58 GMT 2022 --=20 J. --RbyApAA0dcDWk5cc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHVsEsACgkQs8o7QhFz NAUxVxAAlCVvG9m/uA9pVzVU5idFiY5cZfadpkTUG099p1gfiDMpBWRWb9jDRUbW 9uzvBStrazHY1J6ZJtysxDJksinRqYEFClTuQtPrrqBsUtzwWpgDoG6QOo7J0sP9 wVpwmRh8Of8g3UAeJOICYRj9W1TgOuU5RVlzDWsj6aHs8beEIWHfZDI4vEJ2vwv+ 9rlHWiA42UVB025QgHZGyr4h4I5CAJEyDfbteFv2AvEis96vYc393cLKFLjbuJNv 71Rd80VJKWbw/s7PA4lR3XrYuR9qOa6yUhQ0g4qiYgjo4UGh76g8p/quaSMsZ3JH jxUp3WQ5A8uL6OqG4Dg2ucOMlwOwT7CaK6ZgFIcFbXYfGCO0gOLHckWjVHBO0eiv THH/XdOPYEuueldUUy0xaI+GlHwLWzaP14e0vXbbd1GJIj9YrYhC4S9TeXNRC58K odzuCOQGdz0+BGfg/0TN2TRul3W6t0JMuQ4m8ROoXmBlxQu06RkVvXd2PmseWi5S OYGI2DRYBoiFzlHAJ+dsLG4d9YdR/l3Z3oiUR7fUgQdgT4ywJyhMnol+X7R6YLao 3KFk6f6bSEpqZzweZ+O8BKvuY3YEpzY+OGBfdjMEV55e8QEKwIn+CuiS+uJbolAn V+zkPIDqmZCv9AdDR+QBUiI8n2/D3+H6XA9GyYRgh6EKrx6D/aU= =zxZC -----END PGP SIGNATURE----- --RbyApAA0dcDWk5cc-- From nobody Wed Jan 5 15:17:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E268E19283C3 for ; Wed, 5 Jan 2022 15:17:18 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTY4Z3WzWz4bb9; Wed, 5 Jan 2022 15:17:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 205FH5wl064242; Thu, 6 Jan 2022 00:17:06 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Thu, 6 Jan 2022 00:17:04 +0900 From: Tomoaki AOKI To: FreeBSD Hackers Cc: Stefan Blachmann , Warner Losh , Joseph Mingrone , =?ISO-2022-JP?B?GyRCIi4bKEJ6a2Fu?= KIRIK , Michael Schuster , Kyle Evans , Karel Gardas Subject: Re: Call for Foundation-supported Project Ideas Message-Id: <20220106001704.ca84c28e388a55046de2dccb@dec.sakura.ne.jp> In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JTY4Z3WzWz4bb9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 5 Jan 2022 13:16:02 +0100 Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > 15 or 20 years [...] > > main reason laptops stopped suspending in the early 2000s... [...] > > And the INT xx interface is unavailable on amd64 after we > > enter long mode > > First, you mentioned a hacking session in the "early 2000s". > This makes me wonder whether you might mistake some other thing from > the distance of time, as UEFI was no real thing until ~2010, and was > never a thing on platforms other than amd64 also. Suspend/resume on > FreeBSD only appeared much later, too. UEFI is based on EFI, developed initially for IA-64 (Itanium), and IIRC, FreeBSD EFI boot was first developed for (already dropped) IA-64 support. > Second, there is kernel functionality to call real mode interrupt > handlers from long mode, which manage switching to real mode and back. > Just an example, these are being used by vt (via vesa.ko) to switch vesa modes. IIUC about [1] and related ones, vesa.ko is for sc, not vt. And unfortunately, UEFI forces grphical frame buffer, making text-only sc driver prohibited. Of course, sc can work on legacy boot. [1] https://lists.freebsd.org/archives/freebsd-current/2021-November/001083.html > So I do not see why this real mode access infrastructure could not > also be used to make a call to C000:(PCI PROM Programming interface > code offset), or the respective segment address where the actual VGA > BIOS is, to have it initialize the int 10h interface handler, if a > hybrid/dual graphics card BIOS is present. Do you mean creating handler running on virtual 8086 mode? If so, once x86 CPUs switches to long mode (aka amd64 mode), it can no longer workable, as virtual 8086 mode is only on 32bit mode or less. > I think a single function "InitializeVGABIOSifpresent" to enable > access to VGA/VESA BIOS functionality might actually be fairly easy to > implement. > Furthermore, there is no need at all to access hardware specific stuff > like you mentioned, as the necessary functionality is completely > covered by the int 10h interface. > > Imho it could be worth to allocate a small part of the sponsoring > budget to put a bounty to motivate people (including possibly me) to > implement these improvements regarding suspend/resume and enhanced sc > and vt usability. > > > > On 1/4/22, Warner Losh wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > >> > > > > UEFI GOP isn't available after we start the kernel, so this is a > > non-starter. > > It works great in the boot loader, but not so good after we boot. It could > > work > > for S3 sleep to disk where we actually reboot to restore the machine state, > > but we don't have sleep to disk today :( > > > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS$B!-(B CSM part. Just call the CSM BIOS init to set up GPU and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > >> > > > > Ah, if only things were really that simple... I tried variations on that > > hack years ago when suspending broke due to video. And it > > works for some machines, but not others, was the quick assessment > > I made. And the INT xx interface is unavailable on amd64 after we > > enter long mode (I tried this out on my then-current FreeBSD laptop > > which was 32 bit only, so 15 years ago?). > > > > Warner > > > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it also > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from the > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphics > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, $B".(Bzkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > -- Tomoaki AOKI From nobody Wed Jan 5 16:04:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA2421934709 for ; Wed, 5 Jan 2022 16:04:54 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTZ7V5F5Rz4lLW; Wed, 5 Jan 2022 16:04:54 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id h23so1091401wrc.1; Wed, 05 Jan 2022 08:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vwZv3RSBBE1JEMfutqFrjnFMKT2dGo00S8IZ2qPgv70=; b=eVXxKPJjgDFJVATEYa7GqkFFpuFAoAvAbsrhAy5KeBNWdzWma2khydWBK9VS61ZMD1 I4wrc07zBCbG2lGCkFRmGvbLRrhLYVzXt3NT6nWebfk3tPoLsk92tbY+WfWsKzTz5+Uk 3bgVFfF8r3ZxuJCDrUvlSi+FSHXPWNSNtx5wrDHMn9/UNMso6MComBFcUo/TrxviS4sQ UdHMvZgo8TKGzOBzYoXXiKJAOe0c7Djb/YNrk0rBt/Wkk0q/I9JKuyz1Aduan1R9BFDT ahVJI+WC5J6iiFlRl0M5K0h+qWxxhLo65a5hq89cMfW8nE6NyF2JdJZh6qdop3muj4Fy 12xQ== 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=vwZv3RSBBE1JEMfutqFrjnFMKT2dGo00S8IZ2qPgv70=; b=Vg777HzfawZvRy0OGUuOMhIVCCPj6LcjUsjVfaCkHPzTWGBtiTUWmDIcc2TaQwPzgG gA47Fwi8hTa6BP1esfIsXhPPLvJflVdpDiIi3j4H8u/SjOodKgg7GxIl6bIu8dV3Jxhx v1JQJK587dWsakLAk81OZQiSYkYVkHBk/Dz1xx07/dpmtDnSbvLbgQRX8c0giWksFQRd MYaYFlRyo79Dza2AZbyyzsyjfw/yLcMDGrOQ2Kk2oXUz1aObn+J48mTpN8cCnE+S/0eo ZYM78q8GTIcNYsuVfuzDTPLffWWMnl8ZNLwEXEJqQmhwRqqDbZhs+IgJiU0MGAazXd0I mhtQ== X-Gm-Message-State: AOAM532NkkjZUYO1jx47xWZf8PXHKncffmjOfg4Lw7Bq4Z/3ElHe2yxC XdmuBCC4EZkOY8ZsQW15lz6rZRncbhYprrylQ2sj5UGTyCYd2w== X-Google-Smtp-Source: ABdhPJx43ETQfWiwfxwitT8ireK8bOcv9Bas/Zgm7CTCBtSy3hhiq7KAtJ/yv/QJaRhv03oKvzPuA7Jzy12gAhWL3rM= X-Received: by 2002:a5d:6d05:: with SMTP id e5mr46884422wrq.46.1641398692951; Wed, 05 Jan 2022 08:04:52 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Mehmet Erol Sanliturk Date: Wed, 5 Jan 2022 19:04:16 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Warner Losh , Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000738b405d4d7ea97" X-Rspamd-Queue-Id: 4JTZ7V5F5Rz4lLW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000000738b405d4d7ea97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not a part of this discussion , and the problem is not affecting me . But ... Such situations really are causing significant pain in my soul . Why ? ( I am a graduate of Mathematics , In our work every claim requires a PROOF , not words of a BIG one , whether she/he is me or any other one . ) I graduated in 1974 and started as a "System Analyst and Designer" job in Hacettepe University ( Ankara , Turkey ) . In our school , the computer was IBM System 360 with 64 KILO bytes . In Hacettepe Data Processing Center , the computer was a Burroughs B3500 with 128 KILO bytes ( called in that system as 256 KILO digits ) . https://en.wikipedia.org/wiki/Burroughs_Medium_Systems Burroughs Medium Systems https://en.wikipedia.org/wiki/Burroughs_MCP Burroughs MCP I front of its console ( Commands may be differently written ) : --- stop n <---- Number of multi-tasked job --- . --- . --- . --- start n <---- Number of multi-tasked job --- . --- . --- . --- set priority n as m ... A company of Hacettepe University was using the computer during nights . When they were starting around 18:00 : --- load / into tape in { cluster unit of } n ( 1 , 2 , 3 ,or 4 ) --- remove / <----- All of the contents ( written as / ) of the 100 MEGA bytes Hard disk larger than a caravan type automobile . --- load tape from { cluster unit of } n ( 1 , 2 , 3 ,or 4 ) A short time later , ALL of the MCP ( Master Control Program ) and data was loaded into the hard disk and ALL of the possible work began . Around 1979 , a new mainframe arrived to Beytepe campus of Hacettepe : Burroughs B6700 with 2 ( TWO ) MEGA bytes memory . https://en.wikipedia.org/wiki/Category:Burroughs_mainframe_computers Category:Burroughs mainframe computers https://en.wikipedia.org/wiki/Category:High-level_language_computer_archite= cture Category:High-level language computer architecture https://en.wikipedia.org/wiki/Burroughs_large_systems Burroughs large systems Around 1980 years , one engineer working for a large USA company made a remark , approximately , : "... Optimization of a very large Fortran program such as 2000 lines is a very difficult task . ... " Some of my mathematical analysis programs much larger than 2000 lines were developed and executed on this computer . It is not easy to develop such a large program without possible run time error(s) . Burroughs B6700 computer ( multi-tasked ) was using "print spooling" . In output of program , after banner about user name and some other information about the job , was listing a stack trace ( approximately in the following structure , the listing is not the exact reproduction ) : Run time error : n has occurred in line : m in routine : name called by routine : name from line : k called by routine : name from line : k . . . called by main : name from line : k Now the year is 2022 . You know what is the level of maturity or usability or other features of existing systems . The cpu speed is around 3 GIGA Herz . The memory sizes are { 4 or 8 or 16 or 32 or 64 or 128 or 256 ... ) GIGA Bytes ... The job done is ... : I do not know anything except fancy or fantastic screen paints or other useless things excluding facilities like the examples given above ... Please NEVER think that I am blaming our very valuable contributors . Contrary to such a disgusting behavior I am very indebted to them for their efforts ( means using their a part of very holy life time for the benefit of humanity ) . I know the difficulty of working in such a time : When it is understood that a pandemic has started , my official medical doctor called me to say : "Never go outside ! It is very dangerous for you ... " . Since at the beginning of 2020 February I am in isolation . The other people are not better than me with respect to their jobs , dangers for their families and themselves . At that , we need ways to maximize productivity of our contributors and users of FreeBSD by minimizing waste of their time ( ... ) and resources . How ? This is a different story outside of this thread . I am very sorry to waste your time . With my best wishes for your future and your work . Mehmet Erol Sanliturk On Wed, Jan 5, 2022 at 3:17 PM Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > 15 or 20 years [...] > > main reason laptops stopped suspending in the early 2000s... [...] > > And the INT xx interface is unavailable on amd64 after we > > enter long mode > > First, you mentioned a hacking session in the "early 2000s". > This makes me wonder whether you might mistake some other thing from > the distance of time, as UEFI was no real thing until ~2010, and was > never a thing on platforms other than amd64 also. Suspend/resume on > FreeBSD only appeared much later, too. > > Second, there is kernel functionality to call real mode interrupt > handlers from long mode, which manage switching to real mode and back. > Just an example, these are being used by vt (via vesa.ko) to switch vesa > modes. > > So I do not see why this real mode access infrastructure could not > also be used to make a call to C000:(PCI PROM Programming interface > code offset), or the respective segment address where the actual VGA > BIOS is, to have it initialize the int 10h interface handler, if a > hybrid/dual graphics card BIOS is present. > I think a single function "InitializeVGABIOSifpresent" to enable > access to VGA/VESA BIOS functionality might actually be fairly easy to > implement. > Furthermore, there is no need at all to access hardware specific stuff > like you mentioned, as the necessary functionality is completely > covered by the int 10h interface. > > Imho it could be worth to allocate a small part of the sponsoring > budget to put a bounty to motivate people (including possibly me) to > implement these improvements regarding suspend/resume and enhanced sc > and vt usability. > > > > On 1/4/22, Warner Losh wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > >> > > > > UEFI GOP isn't available after we start the kernel, so this is a > > non-starter. > > It works great in the boot loader, but not so good after we boot. It > could > > work > > for S3 sleep to disk where we actually reboot to restore the machine > state, > > but we don't have sleep to disk today :( > > > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GP= U and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > >> > > > > Ah, if only things were really that simple... I tried variations on th= at > > hack years ago when suspending broke due to video. And it > > works for some machines, but not others, was the quick assessment > > I made. And the INT xx interface is unavailable on amd64 after we > > enter long mode (I tried this out on my then-current FreeBSD laptop > > which was 32 bit only, so 15 years ago?). > > > > Warner > > > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it al= so > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > --0000000000000738b405d4d7ea97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not a part of this disc= ussion , and the problem is not affecting me .
But ... Such = situations really are causing significant=C2=A0 pain in my soul .

Why ?

( I am a= graduate of Mathematics , In our work every claim requires a PROOF , not
words of a BIG one , whether she/he is me or any other one . = )


I graduated in 197= 4 and started as a "System Analyst and Designer" job in
Hacettepe University ( Ankara , Turkey ) . In our school , the c= omputer was
IBM System 360 with 64 KILO bytes . In Hace= ttepe Data Processing Center , the computer
was a Burroughs = B3500 with=C2=A0 128 KILO bytes ( called in that system as 256 KILO digits = ) .




https://en.wikipedia.org/wiki/Burroughs_Medium_Systems<= /div>
Burroughs Medium Systems

Burroughs MCP




I front of its console ( Commands may be differently written ) :

--- stop=C2=A0 n=C2=A0 <---- Number of m= ulti-tasked job
--- .
--- .
--- .
--- start=C2=A0 n=C2=A0 = <---- Number of multi-tasked job
--- .
--- .
--- .
--- = set priority n as=C2=A0 m
=C2=A0...

<= /div>
A company of Hacettepe University was using the computer dur= ing nights .
When they were starting around=C2=A0 18:00 :


--- load=C2=A0 /=C2=A0= into tape in { cluster unit of }=C2=A0 n=C2=A0=C2=A0 ( 1 , 2 , 3 ,or 4 )


--- remove=C2=A0 = /=C2=A0=C2=A0=C2=A0 <----- All of the contents ( written as=C2=A0 /=C2= =A0 ) of the=C2=A0 100 MEGA bytes
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Hard disk larger than a caravan type automobile .
=

--- load tape from { cluster unit of }=C2=A0 = n=C2=A0=C2=A0 ( 1 , 2 , 3 ,or 4 )

=C2= =A0=C2=A0=C2=A0 A short time later , ALL of the MCP ( Master Control Progra= m ) and data
=C2=A0=C2=A0=C2=A0 was loaded into the hard dis= k and ALL of the possible work began .

= Around=C2=A0 1979 , a new mainframe arrived to Beytepe campus of Hacettepe = :

Burroughs B6700=C2=A0 with 2 ( TWO )= =C2=A0 MEGA bytes memory .




https://en.wikipedia.o= rg/wiki/Category:Burroughs_mainframe_computers
Category:Burroughs = mainframe computers


https://en.wikipedia= .org/wiki/Category:High-level_language_computer_architecture
Categor= y:High-level language computer architecture

<= /div>

https://en.wikipedia.org/wiki/Burroughs_large_sys= tems
Burroughs large systems



Around=C2=A0 1980 years= , one engineer working for a large USA company made a
= remark , approximately , :=C2=A0 "... Optimization of a very large For= tran program such as
2000 lines is a very difficult task . .= .. "

Some of my mathematical = analysis programs much larger than 2000 lines were developed
and executed on this computer .

It is n= ot easy to develop such a large program=C2=A0 without possible run time err= or(s) .

Burroughs B6700 computer ( multi= -tasked ) was using "print spooling" .
In output o= f program , after banner about user name and some other information
about the job , was listing a stack trace ( approximately in t= he following structure ,
the listing is not the exact reprod= uction ) :

Run time error : n
has occurred in line : m=C2=A0 in routine :=C2=A0 name

called by routine :=C2=A0=C2=A0 name =C2=A0 =C2=A0= from line :=C2=A0=C2=A0 k
called by routine :=C2= =A0=C2=A0 name =C2=A0 =C2=A0 from line :=C2=A0=C2=A0 k

= =C2=A0 .
=C2=A0 .
=C2=A0 .
called by main :=C2=A0=C2=A0 name =C2=A0 from li= ne :=C2=A0=C2=A0 k


Now t= he year is 2022 . You know what is the level of maturity or usability or
other features of existing systems . The cpu speed is aro= und 3 GIGA Herz .
The memory sizes are {=C2=A0 4 or 8 or 16 = or 32 or 64 or 128 or 256 ... ) GIGA Bytes ...
The job d= one is ... : I do not know anything except=C2=A0 fancy or fantastic screen = paints or other useless things excluding facilities like the examples given= above ...



=
Please=C2=A0 NEVER think that I am blaming our very valuabl= e contributors . Contrary to
such a disgusting behavior=C2= =A0 I=C2=A0 am very indebted to them for their efforts ( means
using their a part of very holy life time for the benefit of humani= ty ) .

I know the difficulty of working = in such a time : When it is understood that a pandemic
has s= tarted , my official medical doctor called me to say :

<= /div>
"Never go outside !=C2=A0=C2=A0 It is very dangerous fo= r you ... " .

Since at the beg= inning of 2020 February I am in isolation .
The other p= eople are not better than me with respect to their jobs ,
dangers for their families and themselves .



At that , we need ways= =C2=A0 to maximize=C2=A0 productivity of our contributors and users
of FreeBSD=C2=A0 by minimizing=C2=A0 waste of their time ( ... ) an= d resources .

How ?
This is a different story outside of this thread .


I am very sorry to wast= e your time .

With my best wishes for = your future and your work .




Mehmet Erol Sanliturk



=

On Wed, Jan 5, 2022 at 3:17 PM Stefan Blachmann <sblachmann@gmail.com> wrote:
On 1/4/22, Warner Losh <<= a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com> w= rote:
> 15 or 20 years [...]
> main reason laptops stopped suspending in the early 2000s... [...]
> And the INT xx interface is unavailable on amd64 after we
> enter long mode

First, you mentioned a hacking session in the "early 2000s".
This makes me wonder whether you might mistake some other thing from
the distance of time, as UEFI was no real thing until ~2010, and was
never a thing on platforms other than amd64 also. Suspend/resume on
FreeBSD only appeared much later, too.

Second, there is kernel functionality to call real mode interrupt
handlers from long mode, which manage switching to real mode and back.
Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des.

So I do not see why this real mode access infrastructure could not
also be used to make a call to C000:(PCI PROM Programming interface
code offset), or the respective segment address where the actual VGA
BIOS is, to have it initialize the int 10h interface handler, if a
hybrid/dual graphics card BIOS is present.
I think a single function "InitializeVGABIOSifpresent" to enable<= br> access to VGA/VESA BIOS functionality might actually be fairly easy to
implement.
Furthermore, there is no need at all to access hardware specific stuff
like you mentioned, as the necessary functionality is completely
covered by the int 10h interface.

Imho it could be worth to allocate a small part of the sponsoring
budget to put a bounty to motivate people (including possibly me) to
implement these improvements regarding suspend/resume and enhanced sc
and vt usability.



On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>>
>> UEFI GOP seems to have the necessary functionalities
>> (https://wiki.osdev.org/GOP#Get_the_Curren= t_Mode) so I guess the work
>> required would be limited (restore mode and redraw screen from
>> buffer).
>>
>
> UEFI GOP isn't available after we start the kernel, so this is a > non-starter.
> It works great in the boot loader, but not so good after we boot. It c= ould
> work
> for S3 sleep to disk where we actually reboot to restore the machine s= tate,
> but we don't have sleep to disk today :(
>
>
>> With non-UEFI or old UGA UEFI implementations possibly one could u= se
>> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set u= p GPU and
>> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change
>> modes/resolutions and using sc on UEFI computers.
>>
>
> Ah, if only things were really that simple...=C2=A0 I tried variations= on that
> hack years ago when suspending broke due to video. And it
> works for some machines, but not others, was the quick assessment
> I made. And the INT xx interface is unavailable on amd64 after we
> enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?).
>
> Warner
>
>
>> But I think you are right, there are probably not too many users w= ho
>> would make use of that.
>>
>>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com>= ;
>> > wrote:
>> >
>> >> Implementing S3 suspend/resume was a sponsored project it= self.
>> >> However, it still does only work when at xorg graphics mo= de, which
>> >> already was topic in this thread.
>> >> When using it from console, no matter sc or vt, it still = hangs with
>> >> dark screen and unresponsive keyboard.
>> >> Could finishing the suspend/resume work be sponsored, so = that it also
>> >> works on console-only computers?
>> >>
>> >
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>> >
>> > Warner
>> >
>> >
>> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
>> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm= @FreeBSD.org>
>> >> > wrote:
>> >> >
>> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK &l= t;ozkan.kirik@gm= ail.com>
>> >> >> wrote:
>> >> >>> I've ideas about enhancing the routing a= rchitecture. Is it
>> >> >>> possible
>> >> >>> to
>> >> >>> add to wiki?
>> >> >
>> >> >> Certainly.=C2=A0 Please do.
>> >> >
>> >> > The link again is https://wiki.free= bsd.org/2021FoundationCFI
>> >> >
>> >>
>> >>
>> >
>>
>

--0000000000000738b405d4d7ea97-- From nobody Wed Jan 5 12:16:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2C5701943816 for ; Wed, 5 Jan 2022 17:08:18 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from mail4.nevz.com (mail4.nevz.com [91.240.220.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail4.nevz.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTbXd4Wh1z3Bwf; Wed, 5 Jan 2022 17:08:17 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from Pickup by Srv032.nevz.com with Microsoft SMTP Server id 14.3.498.0; Wed, 5 Jan 2022 17:08:12 +0000 x-sender: freebsd-hackers+bounces-727-kozarenkoas=nevz.com@FreeBSD.org x-receiver: spam@vSrv021.nevz.com X-Virus-Scanned: amavisd-new at nevz.com X-Authentication-Warning: mailgate.nevz.com: Host [172.16.200.14] claimed to be tmh-chpt003 X-MTA-CheckPoint: {61D58C26-0-CC810AC-15F} X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=YePaATXKMp6r8zlUKu3N7G9tqfJl0VC0IQXgHghtCUPQ9xuW7B7m/FBBXLUwhsohV+ ClLXd0h0KqynpeYvdrB+P8mpdIr/sVTyK0EiUH/A6Hx6dFBrp9pofC/iG1T9JKSZ/oea 373+HcQWrWF2/DKUD1qlU14K4BoH63X0icftZ8CGUSNI6rG9QRN3fyDDfdjjzHeCPzIP 1FP/w2kJqytLMUJXkJBNFSgQfw9p6ObRrrRucBY7ERsNWRRC/r5/tdNGm5ezLx+X4LcX +NHEDTMwA5dEctZUDXO773FJP6PMP5EQV4M7+34iZC1+AFnjlwxG00p1H5Fybt+iJn1W /sQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=PYpbposQgfjPbsfpVLNpv1s5Z6VSx/aaQlr7Y+lBOiiKLvo1Vcd4wgqs5yHLk9mETU 1fCv57FjG6aY6kw0ZDkkj4jgHU0cgqdEI72jp47ZpCtfsUHAfSNYaX7H9F4rAVkwpV3h kEA5R1z395Mk0UPsBtMVfNbN6lf5gedEr2DCO6sp4BRBWM7Y5Xzq1HBXqPs59udx01bO bbwT2eYI+nGfZCSvAWkycLAa2zZzXkpFZzEfNY6MrgXjUG/hdyVTxhqaCU97T+ptEVxp lgM/P3Vzm2l4BYRNruHc6fOwF2kaqQ7DUrcw2LKo0wjgWxSwtGDVo38vAtZgS/xeCQWW hb7A== X-Gm-Message-State: AOAM533B7ndrGPJJVV9P3D0Lt8AF+EltizinGGqdT649JGYXG9B4rg0b Me4Nw4AOxgWVat259sKsIHoFWNaUZ36MHYyJj1U= X-Google-Smtp-Source: ABdhPJzEsj2+AQUdqVdZxUNiwVfcJAMnNszTff+6N/uzEUFMNBprrGSeg8aj4NI4uHHDQbY3E99Ae3pX1mb5LsGDkDs= X-Received: by 2002:a05:6512:234d:: with SMTP id p13mr41676761lfu.157.1641384963777; Wed, 05 Jan 2022 04:16:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 13:16:02 +0100 Message-ID: Subject: 5.1 points Re: Call for Foundation-supported Project Ideas To: Warner Losh CC: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , "Kyle Evans" , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641384995; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=Sl1C019Hw9DxOqRhdaIcoObyNARSJfTkn3NgvORoOk+BSuY340ZMhSkwCRv2iRc/AFWTl0 nMWXxf6BWbY+apWm7xXQQkmAYUHlAPOGlJO023NpSOdOjJgMcDsNz77I44K9TThYyl6q/h Ru3JNqwD03Is8q8x1Y4/GbIkjNAHsVEyA4oRpnPA7Av013v6SsnQwbeyl9LCGkAVf1+g7o 2Sa2MvCZoadlJHs/k47undmdZMSRywkIax7arXBW2HaPWYQHNcLKgESF2YC8T5RkB60pBz XQ743Xyvc3wwP9DS6WmfB55KEtUGP0LImX6B9JkKpa4/PAfKdcKrcfUuR0Vf9g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641384995; a=rsa-sha256; cv=none; b=BhalMCyYAKb9QxE2DbOt5+n9UXgTQvcf/YU+Ts6aPS15bXWoNYyRjFZ5azrtIVBkTa/gHC r9YcN1PtB+3XJixJdAUKSMmLWS0JN3LAQAZP5uU0QQVHyk5MVCjUPqs3n7nZ5lfEk9qefW ml5JkLcfOBN/WSZKAQ42ziwYcNFw+Gv6N/l6QQ/EEu5RYIln29xC6uOiCE4QN5iuFqOJXR indGv3sQg0JSjQixrU7CHpD88Oo3z3ztlAGdDr5Dv9Kq0OlfjJiv1hV2HmN7c+DQzsCheh aykAjNCgKUIP9Fpjq9UBxyoxjCacw8xugwZPy06IpTaqXdQnVKGGoKBh2SXMkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-FEAS-DKIM: Valid X-FE-Last-Public-Client-IP: 96.47.72.81 X-FE-Envelope-From: freebsd-hackers+bounces-727-kozarenkoas=nevz.com@freebsd.org X-FE-Policy-ID: 1:1:1:nevz.com X-Greylist: internal networks OS Linux 3.11 and newer X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (mailgate.nevz.com [172.17.206.231]); Wed, 05 Jan 2022 15:16:49 +0300 (MSK) X-Spam-Flag: YES X-Spam-Status: Yes, score=5.1 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,FREEMAIL_FORGED_FROMDOMAIN=0.25,FREEMAIL_FROM=0.001,FSL_HELO_NON_FQDN_1=0.001,HEADER_FROM_DIFFERENT_DOMAINS=5,MAILING_LIST_MULTI=-1,RAZOR2_CF_RANGE_51_100=1.886,RAZOR2_CHECK=0.922 mailgate.nevz.com; whitelist Reported 0 times. [10 mx1.freebsd.org., 30 mx66.freebsd.org.] [96.47.72.84] autolearn=no autolearn_force=no version=3.4.5 X-Spam-Orig-To: ORCPT=rfc822;kozarenkoas@nevz.com X-Spam-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FSL_HELO_NON_FQDN_1 No description available. * 5.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level * mail domains are different * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail * provider * [sblachmann[at]gmail.com] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 1.9 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and * EnvelopeFrom freemail headers are different * -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list * manager X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mailgate.nevz.com X-OriginalArrivalTime: 05 Jan 2022 12:16:53.0569 (UTC) FILETIME=[1FFA7B10:01D8022E] X-Rspamd-Queue-Id: 4JTbXd4Wh1z3Bwf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Warner Losh wrote: > 15 or 20 years [...] > main reason laptops stopped suspending in the early 2000s... [...] > And the INT xx interface is unavailable on amd64 after we > enter long mode First, you mentioned a hacking session in the "early 2000s". This makes me wonder whether you might mistake some other thing from the distance of time, as UEFI was no real thing until ~2010, and was never a thing on platforms other than amd64 also. Suspend/resume on FreeBSD only appeared much later, too. Second, there is kernel functionality to call real mode interrupt handlers from long mode, which manage switching to real mode and back. Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des. So I do not see why this real mode access infrastructure could not also be used to make a call to C000:(PCI PROM Programming interface code offset), or the respective segment address where the actual VGA BIOS is, to have it initialize the int 10h interface handler, if a hybrid/dual graphics card BIOS is present. I think a single function "InitializeVGABIOSifpresent" to enable access to VGA/VESA BIOS functionality might actually be fairly easy to implement. Furthermore, there is no need at all to access hardware specific stuff like you mentioned, as the necessary functionality is completely covered by the int 10h interface. Imho it could be worth to allocate a small part of the sponsoring budget to put a bounty to motivate people (including possibly me) to implement these improvements regarding suspend/resume and enhanced sc and vt usability. On 1/4/22, Warner Losh wrote: > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > wrote: > >> On 1/4/22, Warner Losh wrote: >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> >> UEFI GOP seems to have the necessary functionalities >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> required would be limited (restore mode and redraw screen from >> buffer). >> > > UEFI GOP isn't available after we start the kernel, so this is a > non-starter. > It works great in the boot loader, but not so good after we boot. It coul= d > work > for S3 sleep to disk where we actually reboot to restore the machine stat= e, > but we don't have sleep to disk today :( > > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. >> > > Ah, if only things were really that simple... I tried variations on that > hack years ago when suspending broke due to video. And it > works for some machines, but not others, was the quick assessment > I made. And the INT xx interface is unavailable on amd64 after we > enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?). > > Warner > > >> But I think you are right, there are probably not too many users who >> would make use of that. >> >> >> On 1/4/22, Warner Losh wrote: >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> > wrote: >> > >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> However, it still does only work when at xorg graphics mode, which >> >> already was topic in this thread. >> >> When using it from console, no matter sc or vt, it still hangs with >> >> dark screen and unresponsive keyboard. >> >> Could finishing the suspend/resume work be sponsored, so that it also >> >> works on console-only computers? >> >> >> > >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> > >> > Warner >> > >> > >> >> On 12/30/21, Joseph Mingrone wrote: >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> > wrote: >> >> > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> wrote: >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >>> possible >> >> >>> to >> >> >>> add to wiki? >> >> > >> >> >> Certainly. Please do. >> >> > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> > >> >> >> >> >> > >> > From nobody Wed Jan 5 12:16:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5B0C7194462B for ; Wed, 5 Jan 2022 17:09:30 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from mail4.nevz.com (mail4.nevz.com [91.240.220.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail4.nevz.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTbZ12wp3z3CJ6; Wed, 5 Jan 2022 17:09:29 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from Pickup by Srv032.nevz.com with Microsoft SMTP Server id 14.3.498.0; Wed, 5 Jan 2022 17:09:25 +0000 x-sender: freebsd-hackers+bounces-732-kozarenkoas=nevz.com@FreeBSD.org x-receiver: spam@vSrv021.nevz.com X-Virus-Scanned: amavisd-new at nevz.com X-Authentication-Warning: mailgate.nevz.com: Host [172.16.200.14] claimed to be tmh-chpt003 X-MTA-CheckPoint: {61D5D09D-0-CC810AC-15F} X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org x-sender: freebsd-hackers+bounces-727-kozarenkoas=nevz.com@FreeBSD.org x-receiver: spam@vSrv021.nevz.com X-Virus-Scanned: amavisd-new at nevz.com X-Authentication-Warning: mailgate.nevz.com: Host [172.16.200.14] claimed to be tmh-chpt003 X-MTA-CheckPoint: {61D58C26-0-CC810AC-15F} X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=YePaATXKMp6r8zlUKu3N7G9tqfJl0VC0IQXgHghtCUPQ9xuW7B7m/FBBXLUwhsohV+ ClLXd0h0KqynpeYvdrB+P8mpdIr/sVTyK0EiUH/A6Hx6dFBrp9pofC/iG1T9JKSZ/oea 373+HcQWrWF2/DKUD1qlU14K4BoH63X0icftZ8CGUSNI6rG9QRN3fyDDfdjjzHeCPzIP 1FP/w2kJqytLMUJXkJBNFSgQfw9p6ObRrrRucBY7ERsNWRRC/r5/tdNGm5ezLx+X4LcX +NHEDTMwA5dEctZUDXO773FJP6PMP5EQV4M7+34iZC1+AFnjlwxG00p1H5Fybt+iJn1W /sQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=PYpbposQgfjPbsfpVLNpv1s5Z6VSx/aaQlr7Y+lBOiiKLvo1Vcd4wgqs5yHLk9mETU 1fCv57FjG6aY6kw0ZDkkj4jgHU0cgqdEI72jp47ZpCtfsUHAfSNYaX7H9F4rAVkwpV3h kEA5R1z395Mk0UPsBtMVfNbN6lf5gedEr2DCO6sp4BRBWM7Y5Xzq1HBXqPs59udx01bO bbwT2eYI+nGfZCSvAWkycLAa2zZzXkpFZzEfNY6MrgXjUG/hdyVTxhqaCU97T+ptEVxp lgM/P3Vzm2l4BYRNruHc6fOwF2kaqQ7DUrcw2LKo0wjgWxSwtGDVo38vAtZgS/xeCQWW hb7A== X-Gm-Message-State: AOAM533B7ndrGPJJVV9P3D0Lt8AF+EltizinGGqdT649JGYXG9B4rg0b Me4Nw4AOxgWVat259sKsIHoFWNaUZ36MHYyJj1U= X-Google-Smtp-Source: ABdhPJzEsj2+AQUdqVdZxUNiwVfcJAMnNszTff+6N/uzEUFMNBprrGSeg8aj4NI4uHHDQbY3E99Ae3pX1mb5LsGDkDs= X-Received: by 2002:a05:6512:234d:: with SMTP id p13mr41676761lfu.157.1641384963777; Wed, 05 Jan 2022 04:16:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Post: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 13:16:02 +0100 Message-ID: Subject: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Warner Losh CC: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , "Kyle Evans" , Karel Gardas , "FreeBSD Hackers" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641384995; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=6sOO156XX54eIDDpQBIKWmR3aCLKtmo1pZGJ5xyXxYI=; b=Sl1C019Hw9DxOqRhdaIcoObyNARSJfTkn3NgvORoOk+BSuY340ZMhSkwCRv2iRc/AFWTl0 nMWXxf6BWbY+apWm7xXQQkmAYUHlAPOGlJO023NpSOdOjJgMcDsNz77I44K9TThYyl6q/h Ru3JNqwD03Is8q8x1Y4/GbIkjNAHsVEyA4oRpnPA7Av013v6SsnQwbeyl9LCGkAVf1+g7o 2Sa2MvCZoadlJHs/k47undmdZMSRywkIax7arXBW2HaPWYQHNcLKgESF2YC8T5RkB60pBz XQ743Xyvc3wwP9DS6WmfB55KEtUGP0LImX6B9JkKpa4/PAfKdcKrcfUuR0Vf9g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641384995; a=rsa-sha256; cv=none; b=BhalMCyYAKb9QxE2DbOt5+n9UXgTQvcf/YU+Ts6aPS15bXWoNYyRjFZ5azrtIVBkTa/gHC r9YcN1PtB+3XJixJdAUKSMmLWS0JN3LAQAZP5uU0QQVHyk5MVCjUPqs3n7nZ5lfEk9qefW ml5JkLcfOBN/WSZKAQ42ziwYcNFw+Gv6N/l6QQ/EEu5RYIln29xC6uOiCE4QN5iuFqOJXR indGv3sQg0JSjQixrU7CHpD88Oo3z3ztlAGdDr5Dv9Kq0OlfjJiv1hV2HmN7c+DQzsCheh aykAjNCgKUIP9Fpjq9UBxyoxjCacw8xugwZPy06IpTaqXdQnVKGGoKBh2SXMkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-FEAS-DKIM: Invalid Signature X-FEAS-DKIM: Valid X-FE-Last-Public-Client-IP: 96.47.72.81 X-FE-Envelope-From: freebsd-hackers+bounces-732-kozarenkoas=nevz.com@freebsd.org X-FE-Policy-ID: 1:1:1:nevz.com X-Greylist: internal networks OS Linux 3.11 and newer X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (mailgate.nevz.com [172.17.206.231]); Wed, 05 Jan 2022 20:08:56 +0300 (MSK) X-Greylist: internal networks OS Linux 3.11 and newer X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (mailgate.nevz.com [172.17.206.231]); Wed, 05 Jan 2022 15:16:49 +0300 (MSK) X-Spam-Flag: YES X-Spam-Status: Yes, score=7.0 required=5.0 tests=BAYES_00=-1.9,DATE_IN_PAST_03_06=1.592,DKIM_ADSP_CUSTOM_MED=0.001,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,FREEMAIL_FORGED_FROMDOMAIN=0.25,FREEMAIL_FROM=0.001,FSL_HELO_NON_FQDN_1=0.001,HEADER_FROM_DIFFERENT_DOMAINS=5,MAILING_LIST_MULTI=-1,RAZOR2_CF_RANGE_51_100=1.886,RAZOR2_CHECK=0.922,SPOOFED_FREEMAIL_NO_RDNS=0.001 mailgate.nevz.com; whitelist Reported 0 times. [96.47.72.84] [30 mx66.freebsd.org., 10 mx1.freebsd.org.] autolearn=no autolearn_force=no version=3.4.5 X-Spam-Orig-To: ORCPT=rfc822;kozarenkoas@nevz.com X-Spam-Orig-To: ORCPT=rfc822;kozarenkoas@nevz.com X-Spam-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FSL_HELO_NON_FQDN_1 No description available. * 5.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level * mail domains are different * 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override * is CUSTOM_MED * 1.6 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail * provider * [sblachmann[at]gmail.com] * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * 1.9 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * 0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid * 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and * EnvelopeFrom freemail headers are different * -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list * manager * 0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mailgate.nevz.com X-OriginalArrivalTime: 05 Jan 2022 12:16:53.0569 (UTC) FILETIME=[1FFA7B10:01D8022E] X-ThisMailContainsUnwantedMimeParts: N X-FE-Policy-ID: 1:1:1:nevz.com X-Rspamd-Queue-Id: 4JTbZ12wp3z3CJ6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 1/4/22, Warner Losh wrote: > 15 or 20 years [...] > main reason laptops stopped suspending in the early 2000s... [...] > And the INT xx interface is unavailable on amd64 after we > enter long mode First, you mentioned a hacking session in the "early 2000s". This makes me wonder whether you might mistake some other thing from the distance of time, as UEFI was no real thing until ~2010, and was never a thing on platforms other than amd64 also. Suspend/resume on FreeBSD only appeared much later, too. Second, there is kernel functionality to call real mode interrupt handlers from long mode, which manage switching to real mode and back. Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des. So I do not see why this real mode access infrastructure could not also be used to make a call to C000:(PCI PROM Programming interface code offset), or the respective segment address where the actual VGA BIOS is, to have it initialize the int 10h interface handler, if a hybrid/dual graphics card BIOS is present. I think a single function "InitializeVGABIOSifpresent" to enable access to VGA/VESA BIOS functionality might actually be fairly easy to implement. Furthermore, there is no need at all to access hardware specific stuff like you mentioned, as the necessary functionality is completely covered by the int 10h interface. Imho it could be worth to allocate a small part of the sponsoring budget to put a bounty to motivate people (including possibly me) to implement these improvements regarding suspend/resume and enhanced sc and vt usability. On 1/4/22, Warner Losh wrote: > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > wrote: > >> On 1/4/22, Warner Losh wrote: >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> >> UEFI GOP seems to have the necessary functionalities >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> required would be limited (restore mode and redraw screen from >> buffer). >> > > UEFI GOP isn't available after we start the kernel, so this is a > non-starter. > It works great in the boot loader, but not so good after we boot. It coul= d > work > for S3 sleep to disk where we actually reboot to restore the machine stat= e, > but we don't have sleep to disk today :( > > >> With non-UEFI or old UGA UEFI implementations possibly one could use >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GPU = and >> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change >> modes/resolutions and using sc on UEFI computers. >> > > Ah, if only things were really that simple... I tried variations on that > hack years ago when suspending broke due to video. And it > works for some machines, but not others, was the quick assessment > I made. And the INT xx interface is unavailable on amd64 after we > enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?). > > Warner > > >> But I think you are right, there are probably not too many users who >> would make use of that. >> >> >> On 1/4/22, Warner Losh wrote: >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> > wrote: >> > >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> However, it still does only work when at xorg graphics mode, which >> >> already was topic in this thread. >> >> When using it from console, no matter sc or vt, it still hangs with >> >> dark screen and unresponsive keyboard. >> >> Could finishing the suspend/resume work be sponsored, so that it also >> >> works on console-only computers? >> >> >> > >> > Not without loading the xorg graphics stuff... graphics chips from the >> last >> > 15 or 20 years have lots of chip specific state that only the graphics >> > stuff knows about... IIRC, it only knows about it because it put the >> > graphics into a known state... it's the main reason laptops stopped >> > suspending in the early 2000s... it looks to be a lot of work for a >> > relatively rare use case... >> > >> > Warner >> > >> > >> >> On 12/30/21, Joseph Mingrone wrote: >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> > wrote: >> >> > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> wrote: >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >>> possible >> >> >>> to >> >> >>> add to wiki? >> >> > >> >> >> Certainly. Please do. >> >> > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> > >> >> >> >> >> > >> > From nobody Wed Jan 5 18:22:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A4C4C1934E93 for ; Wed, 5 Jan 2022 18:22:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTdBg3wtCz3rL8 for ; Wed, 5 Jan 2022 18:22:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id u6so73264uaq.0 for ; Wed, 05 Jan 2022 10:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=S1r1bhTuitAB4souaTTOHZGabHwzHyUbxUdW/Qe9yQ5O5cFFjhiAtS+0l49xPSILSt U3s7VDjMd+11xgLMRwV52+G+k5cy0OrN4vpUjNgCyqSf10qURCOOb0byhcZqDD97MZGh +TrgmH3kdmi0N97ZG3xhGGKfYbLywe6mRk1jZUETSVwMVKCy4mm+J9w8q0mSkKJ9cuir X8gEJy8VUvhUWnEp59CURSWqYaksZhZrue2obRJOoFderUN2lTQxd+IkX/TDbMacYutR 31PtASYSRwR+hOynwIlyHBaopZKCjk+KNcFiOTQWGvNJdZjrycFWqhc0Vnt+PCnzXotm mWTQ== 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=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=4x+c3KSbbol9i4MQMRtgRyP8DQm5I3ApqGJ4ax67UFxKCDkaGHytYz+0ZOrGf6Ko0v hxxH5Whpc+EFrzxIeX8TB+DyddQHXm1zC5xarE8bj0TMW0W+bMfacb09NDEw92Imn664 JThIEeBuR4HuG5cgiVcdOScThsY7nCcRJ0+CX9t3bFJh9R/04Gcj5EYzIXp/zjVxsrCg IcK2EghKY6n2HnHVuBSx9/hUYDkpszABoyjSuz7fhQMCqqUEkRg3grVmkehuazk7WXaZ 4i3O8Mq7RTBGMyjbEkGV7VOpgHm0UJqQBb7806FrktgXqge5mDVIClEV3b+8OtQsLQj0 xCcw== X-Gm-Message-State: AOAM533t7w8j5UeH0BzovNnPVsy8nbt/7WsR7QDehjksfWfqR9SallY2 fLtrorb05b5Ba05IqY13YtgkTXlvtw8PorQsb6y9cVDUbOA= X-Google-Smtp-Source: ABdhPJxop6HmGNnvZGV90FoCzdGZu3N9k9pMRfBRkxQAurgYW3/FLOXUpcWjBtakLOIk55kX6eGUNyyN/pSnUTVs7rg= X-Received: by 2002:a67:f8cb:: with SMTP id c11mr17642619vsp.13.1641406970801; Wed, 05 Jan 2022 10:22:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Wed, 5 Jan 2022 11:22:39 -0700 Message-ID: Subject: Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006d458005d4d9d7ee" X-Rspamd-Queue-Id: 4JTdBg3wtCz3rL8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000006d458005d4d9d7ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 5, 2022, 10:09 AM Stefan Blachmann wrote= : > On 1/4/22, Warner Losh wrote: > > 15 or 20 years [...] > > main reason laptops stopped suspending in the early 2000s... [...] > > And the INT xx interface is unavailable on amd64 after we > > enter long mode > > First, you mentioned a hacking session in the "early 2000s". > This makes me wonder whether you might mistake some other thing from > the distance of time, as UEFI was no real thing until ~2010, and was > never a thing on platforms other than amd64 also. Suspend/resume on > FreeBSD only appeared much later, too. > You do know you are talking to someone who has been working on suspend / resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days, right? I'll assume not, because otherwise this is somewhat insulting. I wrote a lot of the original suspend/resume code. I worked on it with the transition to ACPI. I saw the code stop working when the GPUs started needing more state restored than could be done with INT10 interfaces. I tried to implement that on suspend/resume. I helped get workarounds for X11 on suspend/resume to switch to ttyv0 before suspending (which worked for a while, pre drm days). What you say here is factually inaccurate. Second, there is kernel functionality to call real mode interrupt > handlers from long mode, which manage switching to real mode and back. > Just an example, these are being used by vt (via vesa.ko) to switch vesa > modes. > Except that it's kinda unreliable and not enabled for vt because it doesn't work well with UEFI. So I do not see why this real mode access infrastructure could not > also be used to make a call to C000:(PCI PROM Programming interface > code offset), or the respective segment address where the actual VGA > BIOS is, to have it initialize the int 10h interface handler, if a > hybrid/dual graphics card BIOS is present. > I think a single function "InitializeVGABIOSifpresent" to enable > access to VGA/VESA BIOS functionality might actually be fairly easy to > implement. > Furthermore, there is no need at all to access hardware specific stuff > like you mentioned, as the necessary functionality is completely > covered by the int 10h Imho it could be worth to allocate a small part of the sponsoring > budget to put a bounty to motivate people (including possibly me) to > implement these improvements regarding suspend/resume and enhanced sc > and vt usability. > I'm going to disagree. Why bother. Load the kms drm drivers. The suspend/resume code is in those drivers. They work console, X11 and wayland, more or less. It's an absolutely insane idea to spend limited funds on the crazy ideas presented in this thread. They are known to be flakey, unreliable or technically just not possible. Warner On 1/4/22, Warner Losh wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > >> > > > > UEFI GOP isn't available after we start the kernel, so this is a > > non-starter. > > It works great in the boot loader, but not so good after we boot. It > could > > work > > for S3 sleep to disk where we actually reboot to restore the machine > state, > > but we don't have sleep to disk today :( > > > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GP= U and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > >> > > > > Ah, if only things were really that simple... I tried variations on th= at > > hack years ago when suspending broke due to video. And it > > works for some machines, but not others, was the quick assessment > > I made. And the INT xx interface is unavailable on amd64 after we > > enter long mode (I tried this out on my then-current FreeBSD laptop > > which was 32 bit only, so 15 years ago?). > > > > Warner > > > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it al= so > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > > --0000000000006d458005d4d9d7ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 5, 2022, 10:09 AM Stefan = Blachmann <sbl= achmann@gmail.com> wrote:
On= 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> 15 or 20 years [...]
> main reason laptops stopped suspending in the early 2000s... [...]
> And the INT xx interface is unavailable on amd64 after we
> enter long mode

First, you mentioned a hacking session in the "early 2000s".
This makes me wonder whether you might mistake some other thing from
the distance of time, as UEFI was no real thing until ~2010, and was
never a thing on platforms other than amd64 also. Suspend/resume on
FreeBSD only appeared much later, too.

You do know you are talking to someon= e who has been working on suspend / resume since I got my first Libretto 50= CT laptop in the FreeBSD 3.2 days, right? I'll assume not, because othe= rwise this is somewhat insulting. I wrote a lot of the original suspend/res= ume code. I worked on it with the transition to ACPI. I saw the code stop w= orking when the GPUs started needing more state restored than could be done= with INT10 interfaces. I tried to implement that on suspend/resume. I help= ed get workarounds for X11 on suspend/resume to switch to ttyv0 before susp= ending (which worked for a while, pre drm days). What you say here is factu= ally inaccurate.

Second, there is kernel functionality to call real mode interrupt
handlers from long mode, which manage switching to real mode and back.
Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des.

Except th= at it's kinda unreliable and not enabled for vt because it doesn't = work well with UEFI.

So I do not see why this real mode access infrastructure could not
also be used to make a call to C000:(PCI PROM Programming interface
code offset), or the respective segment address where the actual VGA
BIOS is, to have it initialize the int 10h interface handler, if a
hybrid/dual graphics card BIOS is present.
I think a single function "InitializeVGABIOSifpresent" to enable<= br> access to VGA/VESA BIOS functionality might actually be fairly easy to
implement.
Furthermore, there is no need at all to access hardware specific stuff
like you mentioned, as the necessary functionality is completely
covered by the int 10h

=
Imho it could be worth to allocate a small part of the sponsoring
budget to put a bounty to motivate people (including possibly me) to
implement these improvements regarding suspend/resume and enhanced sc
and vt usability.

<= div>I'm going to disagree.

Why bother. Load th= e kms drm drivers. The suspend/resume code is in those
drivers. T= hey work console, X11 and wayland, more or less.=C2=A0 It's an absolute= ly
insane idea to spend limited funds on the crazy ideas presente= d in this thread.
They are known to be flakey, unreliable or tech= nically just not possible.

Warner


On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmai= l.com>
> wrote:
>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>>
>> UEFI GOP seems to have the necessary functionalities
>> (https://wiki.osdev.org/GOP#Get= _the_Current_Mode) so I guess the work
>> required would be limited (restore mode and redraw screen from
>> buffer).
>>
>
> UEFI GOP isn't available after we start the kernel, so this is a > non-starter.
> It works great in the boot loader, but not so good after we boot. It c= ould
> work
> for S3 sleep to disk where we actually reboot to restore the machine s= tate,
> but we don't have sleep to disk today :(
>
>
>> With non-UEFI or old UGA UEFI implementations possibly one could u= se
>> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set u= p GPU and
>> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change
>> modes/resolutions and using sc on UEFI computers.
>>
>
> Ah, if only things were really that simple...=C2=A0 I tried variations= on that
> hack years ago when suspending broke due to video. And it
> works for some machines, but not others, was the quick assessment
> I made. And the INT xx interface is unavailable on amd64 after we
> enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?).
>
> Warner
>
>
>> But I think you are right, there are probably not too many users w= ho
>> would make use of that.
>>
>>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachma= nn@gmail.com>
>> > wrote:
>> >
>> >> Implementing S3 suspend/resume was a sponsored project it= self.
>> >> However, it still does only work when at xorg graphics mo= de, which
>> >> already was topic in this thread.
>> >> When using it from console, no matter sc or vt, it still = hangs with
>> >> dark screen and unresponsive keyboard.
>> >> Could finishing the suspend/resume work be sponsored, so = that it also
>> >> works on console-only computers?
>> >>
>> >
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>> >
>> > Warner
>> >
>> >
>> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wro= te:
>> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm= @FreeBSD.org>
>> >> > wrote:
>> >> >
>> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK &l= t;ozkan.kirik@gmail.com>
>> >> >> wrote:
>> >> >>> I've ideas about enhancing the routing a= rchitecture. Is it
>> >> >>> possible
>> >> >>> to
>> >> >>> add to wiki?
>> >> >
>> >> >> Certainly.=C2=A0 Please do.
>> >> >
>> >> > The link again is https:= //wiki.freebsd.org/2021FoundationCFI
>> >> >
>> >>
>> >>
>> >
>>
>


--0000000000006d458005d4d9d7ee-- From nobody Wed Jan 5 20:14:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 42694193796A for ; Wed, 5 Jan 2022 20:15:10 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTghD60PJz4mJ8 for ; Wed, 5 Jan 2022 20:15:08 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 62B685C0182 for ; Wed, 5 Jan 2022 15:15:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 05 Jan 2022 15:15:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=v239g3OeAYZ+BU9qlGg2kcvR8PK j1A6YjScEiAxytyg=; b=dhsQhAtwyjSxhoVLHaeFfQq6Vu+t6atodExMBhrQQAL yyqJz8ZE/ZTArTbr7fnElnXSA6/j/7oKRjLo05W8HJZzaATPiRKQcv/yHdBS5CMO vJNXU3evhMSV2sFrYZgJBJjzWDTITOLegdGZeLvTPy7BQOFVGkKZdxcyqwHdf4xf Yn8MSxwFWDoxQctuKMjxyMlSkJgqTj26DPWJ6ZSyPyzyAvGSzxQZloKJGttXU0c5 x8tE9qTy2zYa2fnkm7gqhtrHZDGJjLy7gFpF4af8y2ZyvXYfd+jabyVx9RviIlwa MfURFfKBM4JjVHmnax7/rcHWXqdwnGEsh5qBYu8yhiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=v239g3 OeAYZ+BU9qlGg2kcvR8PKj1A6YjScEiAxytyg=; b=bhUW2wjXT47NNdhi6ZaesD eR05lOnJpRicteCjgz8K0G+BpA1t45ly5DZu1RG3ibUySBNaMUn8oIhKV47OG7fv LV4rKmg/GpETTmaRz0okrJNyw2FdG+rlxqDW3HyuZWaX7HJamyKTt/xpRDmjvBKC cYk6R+MMajlM5VaeLeiNamyTTn1dKJ4SZnpn1NRV8XoSPEZ14e7c/D5IVhHtmdbT WI9a9upGzg6jsqjzBjm0RRcl4D1IuVzLEgh6Mfn0LVqkMwRZrT+nFA78Py8cg88P qGq2mPzl3J2S12+5xLm0m0RSQEez+NsTpGQsq2UtaNxf5FZTrHK3ewwdNavskgXA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefjedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefghffgjeeuheefleevffduveelhe efveehuefffeekgfeljeehhffgjedtudekkeenucffohhmrghinhepiiihgihsthdrnhgv thenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvg gthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 5 Jan 2022 15:15:01 -0500 (EST) Date: Wed, 5 Jan 2022 20:14:54 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PoymDLWRtlgmngrA" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JTghD60PJz4mJ8 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=dhsQhAtw; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=bhUW2wjX; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --PoymDLWRtlgmngrA Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >1) Can you share more details on "fails to build". Are you in a position > to share a build log. The last part of the build log from llvm13 is here: https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log It's not the entire build log. i'll try making a better one --=20 J. --PoymDLWRtlgmngrA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHV/C8ACgkQs8o7QhFz NAUB6g//dtNfcrOvtpDYXSTjNOAVYdGn7YkNhz9vR6H0R1pD+R95wMdT3zNejA02 478HmtuhAdfSpa5Wjdi1sCs+vnOBUeTrccVMYwJlquTlktMomXVyPcdoruq5DIuu kSiGO/8DjrklGnDKIJ3rVffnVKVRmvl+E/pu8tSb1nASjd3kweCWU8iQNcuKykhD 7fVXSEqmojk9PcZF65M4V2C+uLO4DFktbVyVvzTrggl8bz2mhk3pqqL1Uc1yjYxE BOACjiGKOKBjldPmjhuTfN5/okj+tj6Znb8eDCXwib7E9owS9/tgErX8z99LWW8H 2Lod27GhmNsOOy6AqNtfWQE+5yTRuic5jgcFK+4bMWgpuWHCwBpbD7LYiflIB5Ni oMGHDK+O3vEqrGEMKbIYPwgMiARkzk6sO4P3bnDYXUtkxFfLQA2V54U4PqQGqi0+ Rr/YENl8/NzN5aIXv3/eDycT3KkRSqD5DxcFNmCN1FeVX8rkLmIRKByl3XqODBI8 +NMA4I3Mn7zGvVXgHFhNXarfdDBDISmVO8KYyvvXQxwCkiP8pW5OxQDX3EXjDYec 7t5K+OgPnWgBh8Q0Y/9XgunyGF8rL6qxz6TXM73CT4JwKwKDtV25vhcJzSIfy8TA NgjZj9DreOj/ShqvUNhXRmTk2ta8dc3BnGvzZuzKsA/Tlfseezw= =Kyam -----END PGP SIGNATURE----- --PoymDLWRtlgmngrA-- From nobody Wed Jan 5 20:45:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C659D193FE64 for ; Wed, 5 Jan 2022 20:45:09 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JThLs4dBRz4sM2; Wed, 5 Jan 2022 20:45:09 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id j11so573531lfg.3; Wed, 05 Jan 2022 12:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3BBC35hokbw3IJizJkcjHV7CwBJtvXV9kipfgysltVc=; b=AbZb6bo5+ll/5Mvpa8NnI90CkUGtY+4f92IsLqD3ZtjU8KmKH6ZzppJicUzlnMtEzH 1RZK+kMoLHiTMvg7vm4BDN2sjQiWADqpTZpxZCvsXXpN8lztV9TblKB31yhF16QzMntB vjabPWrzhDWy0llEN1CAXA3bwKTR9ekzSwMBuNJLP/6coPYghFXN7hyzUfiGjq7WJzVw zAiOg1NO7qyFgGYQejNRV4dHoy0PWiYGnz9O7h6ktTwpBOAU48t0JNgy5o+ms0fts5Lh u2kx2uYPFOMQ5U/zUKpXbRZqW6iCns0+exDl7Nomvp8NuchStbe2WYRx/bmF6A/GdLfH upew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3BBC35hokbw3IJizJkcjHV7CwBJtvXV9kipfgysltVc=; b=QIgrl7Rm+78XBoIVde7yDneLkYCzwxr/9ztMT4We9KGiBhn8YUdKoVmyBmLU52qvkX WDg696rP6LL+KO9Xu833fvwRqAmNT2BJGg88jCPhHyMhEf9d0INzA86Kw2Cs1XeHt6p2 aFYSXCIsxmYqyNxhlAqIfbPasI3se9jZsOQXZ+eRR4IFyX0Ni8J4h/Nl/RamURt/8gjk lo7da2Hey/abqR1F0bqQN2+zNIrkM2V+QzshqZcHmAzZItBzOJwT1Pz/r674JKm6mDjd yqaRuzVEJihl/il5ZxRhcv8rpyD5W3mkGrhPtysh3/4BSsChKfXfb0rNBOSq+B5h6q6R i4eA== X-Gm-Message-State: AOAM530lCYbdSMHpnJWqpcDwT9thXIgbGu4EeaBLf6d8nJXTfefxK2O4 G9/Z1cOIOcJHBYM7Kn8PXMSfirIDCeb9UPi2jB8= X-Google-Smtp-Source: ABdhPJxRsZY6xglXYOS59cMOoP+h84BYqHwUg1EGiVDDhEV9Yc9yhXtsH1kaJOhxtDZO6CUlhVMvUFw05THMPVgI9g4= X-Received: by 2002:a05:6512:5c8:: with SMTP id o8mr48961440lfo.659.1641415506722; Wed, 05 Jan 2022 12:45:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Wed, 5 Jan 2022 12:45:05 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 21:45:05 +0100 Message-ID: Subject: Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Warner Losh Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JThLs4dBRz4sM2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 1/5/22, Warner Losh wrote: > You do know you are talking to someone who has been working on suspend / > resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days, > right? No I did not know this. It was also not my intention to insult. I just believed another guy wrote i= t. But after re-reading his comment, I see that that guy implemented that for the amd64 platform only (proof: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224069#c5 ). As I did not want to make you feel bad, I sincerely apologize, as I highly respect yours, Kims and the others' work. > Why bother. Load the kms drm drivers. The suspend/resume code is in those > drivers. They work console, X11 and wayland, more or less. This is good to know! Because, it is *not* being communicated at all in any of the suspend/resume wiki pages, guides etc that from some release on, loading the drm-kmod stuff became necessary also *if* suspend/resume functionality is needed for console-only computers. Yesterdays' post from @tech-lists about outdated/missing information comes to my mind... If this were communicated, it would have saved all of us a lot of time. > ... the crazy ideas presented in this thread. > They are known to be flakey, unreliable or technically just not possible. Well, imho basically the only crazy idea was to enable the int 10h interface/reinit hardware after exiting the UEFI boot service and when resuming by hackingly calling the hybrid VGA BIOS init. Infrastructure for real mode BIOS access definitely seems to exist, and I guess I'll play around with it, and see how reliable it is. If this works out, then this would be some sort of proof. So I retract this proposal for a sponsored project. Because, the best solution would imho be to update the documentation (handbook suspend/resume section, man zzz acpiconf, maybe apm too, wiki) so it mentions the necessity for kldloading the drm kmod drivers to actually make resuming succeed on console-only computers. I hope everybody agrees if I make the necessary PRs for documentation updat= es. Cheers, Stefan On 1/5/22, Warner Losh wrote: > On Wed, Jan 5, 2022, 10:09 AM Stefan Blachmann > wrote: > >> On 1/4/22, Warner Losh wrote: >> > 15 or 20 years [...] >> > main reason laptops stopped suspending in the early 2000s... [...] >> > And the INT xx interface is unavailable on amd64 after we >> > enter long mode >> >> First, you mentioned a hacking session in the "early 2000s". >> This makes me wonder whether you might mistake some other thing from >> the distance of time, as UEFI was no real thing until ~2010, and was >> never a thing on platforms other than amd64 also. Suspend/resume on >> FreeBSD only appeared much later, too. >> > > You do know you are talking to someone who has been working on suspend / > resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days, > right? I'll assume not, because otherwise this is somewhat insulting. I > wrote a lot of the original suspend/resume code. I worked on it with the > transition to ACPI. I saw the code stop working when the GPUs started > needing more state restored than could be done with INT10 interfaces. I > tried to implement that on suspend/resume. I helped get workarounds for X= 11 > on suspend/resume to switch to ttyv0 before suspending (which worked for = a > while, pre drm days). What you say here is factually inaccurate. > > Second, there is kernel functionality to call real mode interrupt >> handlers from long mode, which manage switching to real mode and back. >> Just an example, these are being used by vt (via vesa.ko) to switch vesa >> modes. >> > > Except that it's kinda unreliable and not enabled for vt because it doesn= 't > work well with UEFI. > > So I do not see why this real mode access infrastructure could not >> also be used to make a call to C000:(PCI PROM Programming interface >> code offset), or the respective segment address where the actual VGA >> BIOS is, to have it initialize the int 10h interface handler, if a >> hybrid/dual graphics card BIOS is present. >> I think a single function "InitializeVGABIOSifpresent" to enable >> access to VGA/VESA BIOS functionality might actually be fairly easy to >> implement. >> Furthermore, there is no need at all to access hardware specific stuff >> like you mentioned, as the necessary functionality is completely >> covered by the int 10h > > > Imho it could be worth to allocate a small part of the sponsoring >> budget to put a bounty to motivate people (including possibly me) to >> implement these improvements regarding suspend/resume and enhanced sc >> and vt usability. >> > > I'm going to disagree. > > Why bother. Load the kms drm drivers. The suspend/resume code is in those > drivers. They work console, X11 and wayland, more or less. It's an > absolutely > insane idea to spend limited funds on the crazy ideas presented in this > thread. > They are known to be flakey, unreliable or technically just not possible. > > Warner > > > On 1/4/22, Warner Losh wrote: >> > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann >> > wrote: >> > >> >> On 1/4/22, Warner Losh wrote: >> >> > Not without loading the xorg graphics stuff... graphics chips from >> >> > the >> >> last >> >> > 15 or 20 years have lots of chip specific state that only the >> >> > graphics >> >> > stuff knows about... IIRC, it only knows about it because it put th= e >> >> > graphics into a known state... it's the main reason laptops stopped >> >> > suspending in the early 2000s... it looks to be a lot of work for a >> >> > relatively rare use case... >> >> >> >> UEFI GOP seems to have the necessary functionalities >> >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work >> >> required would be limited (restore mode and redraw screen from >> >> buffer). >> >> >> > >> > UEFI GOP isn't available after we start the kernel, so this is a >> > non-starter. >> > It works great in the boot loader, but not so good after we boot. It >> could >> > work >> > for S3 sleep to disk where we actually reboot to restore the machine >> state, >> > but we don't have sleep to disk today :( >> > >> > >> >> With non-UEFI or old UGA UEFI implementations possibly one could use >> >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up G= PU and >> >> the int 10h interface, and then set previously used mode+redraw. >> >> BTW, doing that also could both enable vt(4) to change >> >> modes/resolutions and using sc on UEFI computers. >> >> >> > >> > Ah, if only things were really that simple... I tried variations on >> > that >> > hack years ago when suspending broke due to video. And it >> > works for some machines, but not others, was the quick assessment >> > I made. And the INT xx interface is unavailable on amd64 after we >> > enter long mode (I tried this out on my then-current FreeBSD laptop >> > which was 32 bit only, so 15 years ago?). >> > >> > Warner >> > >> > >> >> But I think you are right, there are probably not too many users who >> >> would make use of that. >> >> >> >> >> >> On 1/4/22, Warner Losh wrote: >> >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann >> >> > >> >> > wrote: >> >> > >> >> >> Implementing S3 suspend/resume was a sponsored project itself. >> >> >> However, it still does only work when at xorg graphics mode, which >> >> >> already was topic in this thread. >> >> >> When using it from console, no matter sc or vt, it still hangs wit= h >> >> >> dark screen and unresponsive keyboard. >> >> >> Could finishing the suspend/resume work be sponsored, so that it >> >> >> also >> >> >> works on console-only computers? >> >> >> >> >> > >> >> > Not without loading the xorg graphics stuff... graphics chips from >> >> > the >> >> last >> >> > 15 or 20 years have lots of chip specific state that only the >> >> > graphics >> >> > stuff knows about... IIRC, it only knows about it because it put th= e >> >> > graphics into a known state... it's the main reason laptops stopped >> >> > suspending in the early 2000s... it looks to be a lot of work for a >> >> > relatively rare use case... >> >> > >> >> > Warner >> >> > >> >> > >> >> >> On 12/30/21, Joseph Mingrone wrote: >> >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone >> >> >> > wrote: >> >> >> > >> >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK >> >> >> >> wrote: >> >> >> >>> I've ideas about enhancing the routing architecture. Is it >> >> >> >>> possible >> >> >> >>> to >> >> >> >>> add to wiki? >> >> >> > >> >> >> >> Certainly. Please do. >> >> >> > >> >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> > From nobody Wed Jan 5 20:49:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D8F0A19432E8 for ; Wed, 5 Jan 2022 20:49:53 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JThSJ27Mqz4wTR for ; Wed, 5 Jan 2022 20:49:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 205KnjFM042135 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 5 Jan 2022 12:49:45 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 205Knjix042134 for freebsd-hackers@freebsd.org; Wed, 5 Jan 2022 12:49:45 -0800 (PST) (envelope-from sgk) Date: Wed, 5 Jan 2022 12:49:45 -0800 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: <20220105204945.GA42063@troutmask.apl.washington.edu> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JThSJ27Mqz4wTR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.17 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.16)[-0.160]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.99)[0.993]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jan 05, 2022 at 08:14:54PM +0000, tech-lists wrote: > On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: > > 1) Can you share more details on "fails to build". Are you in a position > > to share a build log. > > The last part of the build log from llvm13 is here: > https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log > > It's not the entire build log. i'll try making a better one Well, did you try the help hint? ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. This would isolate what is actually failing. With that stated, I note the first line of the log contains "FAILED: tools/flang/...". When you configure llvm13 disable the building of flang (i.e., the Fortran compiler). -- Steve From nobody Wed Jan 5 21:19:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B04219254C1 for ; Wed, 5 Jan 2022 21:19:18 +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 4JTj6F6fGzz566L; Wed, 5 Jan 2022 21:19:17 +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 A87F41E95; Wed, 5 Jan 2022 21:19:17 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 5C89D5657D; Wed, 5 Jan 2022 22:19:15 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_DADAE436-4297-4362-8182-113BDEDF2E95"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current From: Dimitry Andric In-Reply-To: <20220105204945.GA42063@troutmask.apl.washington.edu> Date: Wed, 5 Jan 2022 22:19:08 +0100 Cc: FreeBSD Hackers Message-Id: <2D4BE7E5-B5D2-4D3E-B137-2830C2DD80DE@FreeBSD.org> References: <20220105204945.GA42063@troutmask.apl.washington.edu> To: tech-lists X-Mailer: Apple Mail (2.3693.40.0.1.81) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641417557; h=from:from:reply-to:subject:subject:date:date: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=z/UvFN0uE6oTt2M0m1NdBXiJc2vCI+RTPfoqXz/pcqo=; b=Zuk85h9CWPUrvZjQONNJE3nxCG4FDvgZMDRL9x+M2uPutzTudu1g/Ml9QfKVDvzthsRa0C 1jvsoUBCmqqZHMnq17jmnmInb/x2k/6c+uYOqN+raEpGfC8wzVUQPbn5MgHS5dEYa26Vfa 0aWaqq9MAjU7OleghOC8Cf6eweyaJMqXQxNnyWwaaERElqJ1udTge85gK85tmMFWqSFO5r /ptBz6jaXq8CSHokPqLgbJ7u3oFqiFE8TpFXZbSjIap9lix9JarSMgOT7MaDbCljBYUcr6 p/SzowRlja+aabtlCJUxDTO/A0Ksz7WbOAFsp6OjK7B5bcTVT4jNOGcvBzyICQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641417557; a=rsa-sha256; cv=none; b=bx77O8rqmP5bJEzNkJ2SRUn7Bfl0dmBNIN3yFFDd6Ar0pZDngrPI4MQ9C6zJ6/8/uV267v U/45N88bIh0tT/4jI87ZCPsCggseIKjEPcEOH8e65p01ZmiLenJ5KA0OvL5DRPFW1eysD9 w2dId9cx8h+P6cDGftuEDaPeAgtiJoUIlOooPn4Mea6vDq/kTTs3lUkm5GtnenwqY+mla8 MtOjictzEMPbSe5T8T29/4XmJT4y8pTiWBIUSjKlYeUjG9TeJmin6YBT0xlFQUsgahfITA dRL3iWkJ7MoE5hUTGVL/7sDAoxzhiRE8Yw7XNg/qnG4dEB0GJmYVmvlwGjaMjQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_DADAE436-4297-4362-8182-113BDEDF2E95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 Jan 2022, at 21:49, Steve Kargl = wrote: >=20 > On Wed, Jan 05, 2022 at 08:14:54PM +0000, tech-lists wrote: >> On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >>> 1) Can you share more details on "fails to build". Are you in a = position >>> to share a build log. >>=20 >> The last part of the build log from llvm13 is here: >> https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log >>=20 >> It's not the entire build log. i'll try making a better one >=20 > Well, did you try the help hint? >=20 > =3D=3D=3D> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to > the maintainer. >=20 > This would isolate what is actually failing. With that stated, I note > the first line of the log contains "FAILED: tools/flang/...". When = you > configure llvm13 disable the building of flang (i.e., the Fortran = compiler). Indeed, building flang is usually pretty memory intensive, so it is likely that the OP is running into OOM errors. (Though the log is only the last few lines, hiding the actual error.) Turning off flang would help in that case, as would turning off make jobs. -Dimitry --Apple-Mail=_DADAE436-4297-4362-8182-113BDEDF2E95 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYdYLTAAKCRCwXqMKLiCW o3J2AKDKuee2FQagx8tYeoZrKfNyW+q0OwCfV3rUkcd/mZNOQw6OC9toSVLXxrQ= =RHCV -----END PGP SIGNATURE----- --Apple-Mail=_DADAE436-4297-4362-8182-113BDEDF2E95-- From nobody Wed Jan 5 18:22:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1E8B1927DB7 for ; Wed, 5 Jan 2022 21:21:56 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from mail4.nevz.com (mail4.nevz.com [91.240.220.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail4.nevz.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTj9J0Vfjz57jm; Wed, 5 Jan 2022 21:21:56 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from Pickup by Srv032.nevz.com with Microsoft SMTP Server id 14.3.498.0; Wed, 5 Jan 2022 21:21:52 +0000 x-sender: freebsd-hackers+bounces-734-kozarenkoas=nevz.com@FreeBSD.org x-receiver: spam@vSrv021.nevz.com X-Virus-Scanned: amavisd-new at nevz.com X-Authentication-Warning: mailgate.nevz.com: Host [172.16.200.14] claimed to be tmh-chpt003 X-MTA-CheckPoint: {61D5E219-0-CC810AC-15F} X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org 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=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=S1r1bhTuitAB4souaTTOHZGabHwzHyUbxUdW/Qe9yQ5O5cFFjhiAtS+0l49xPSILSt U3s7VDjMd+11xgLMRwV52+G+k5cy0OrN4vpUjNgCyqSf10qURCOOb0byhcZqDD97MZGh +TrgmH3kdmi0N97ZG3xhGGKfYbLywe6mRk1jZUETSVwMVKCy4mm+J9w8q0mSkKJ9cuir X8gEJy8VUvhUWnEp59CURSWqYaksZhZrue2obRJOoFderUN2lTQxd+IkX/TDbMacYutR 31PtASYSRwR+hOynwIlyHBaopZKCjk+KNcFiOTQWGvNJdZjrycFWqhc0Vnt+PCnzXotm mWTQ== 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=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=4x+c3KSbbol9i4MQMRtgRyP8DQm5I3ApqGJ4ax67UFxKCDkaGHytYz+0ZOrGf6Ko0v hxxH5Whpc+EFrzxIeX8TB+DyddQHXm1zC5xarE8bj0TMW0W+bMfacb09NDEw92Imn664 JThIEeBuR4HuG5cgiVcdOScThsY7nCcRJ0+CX9t3bFJh9R/04Gcj5EYzIXp/zjVxsrCg IcK2EghKY6n2HnHVuBSx9/hUYDkpszABoyjSuz7fhQMCqqUEkRg3grVmkehuazk7WXaZ 4i3O8Mq7RTBGMyjbEkGV7VOpgHm0UJqQBb7806FrktgXqge5mDVIClEV3b+8OtQsLQj0 xCcw== X-Gm-Message-State: AOAM533t7w8j5UeH0BzovNnPVsy8nbt/7WsR7QDehjksfWfqR9SallY2 fLtrorb05b5Ba05IqY13YtgkTXlvtw8PorQsb6y9cVDUbOA= X-Google-Smtp-Source: ABdhPJxop6HmGNnvZGV90FoCzdGZu3N9k9pMRfBRkxQAurgYW3/FLOXUpcWjBtakLOIk55kX6eGUNyyN/pSnUTVs7rg= X-Received: by 2002:a67:f8cb:: with SMTP id c11mr17642619vsp.13.1641406970801; Wed, 05 Jan 2022 10:22:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Wed, 5 Jan 2022 11:22:39 -0700 Message-ID: Subject: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann CC: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , "Kyle Evans" , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006d458005d4d9d7ee" X-ThisMailContainsUnwantedMimeParts: N ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641406997; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=ZOBjnVpdipojm2iyOPwi3bF/0+DSea+sLho1Id4MUa9Sp6m9XIkQKz1CEdqvQdRQxePkIu Mwvq5RC9cyzqi8v6dqdBH4uMla7P2U4FaA9v0yw5MBl3UGzKR/7MA4EBlFcvv0dkHspen8 6K8TSXoqBLh216s8pCRTKcNaHboCAMIWEIzxwla1es4hEJSfOpAzuW8LbHAHKLTHtz32zg LEr2r1MG01U7nqriZOR/G/q3qI49sSsRe6bqV6I65TlqogVVs5jvETlarPBPdLtjWatV4p xCbJe5KOyyI1ZTE4ZzGdU89zYws+03DWsxRGF/PWaf/2/RJ3RKuwJvVTTM6Icw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641406997; a=rsa-sha256; cv=none; b=FF6tptZuG+RtIqHWZvNwO8a+ySWiY02Q2xJcNnhhYBVlhK85+TND76xPBgoFNvUvdIx/EB xlkvgez8qG0gJsbPXwLe2tocG8PB7R0vTfHMW6Mc628elXOSyPOMHTi16wH4w6QEIni5QD kAcd/MvgS54i8wuSeiCKr94lo7BJVz65ZcDIf61qmyEzJqKBJXMmOV9hN9bKod0KKaKxbI oJs7+nZg2KNddy2UACN3269tMjz3FI1kv1NQbDFZykr+B2JQg0cJix9PT+zfIESL58cEEl lPqSwQw4M2Ee+MZtBjM/eYtb3npu963RWDYxjONqENEA2ROIcpSeSSrET99EzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-FEAS-DKIM: Valid X-FE-Last-Public-Client-IP: 96.47.72.81 X-FE-Envelope-From: freebsd-hackers+bounces-734-kozarenkoas=nevz.com@freebsd.org X-FE-Policy-ID: 1:1:1:nevz.com X-Greylist: internal networks OS Linux 3.11 and newer X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (mailgate.nevz.com [172.17.206.231]); Wed, 05 Jan 2022 21:23:31 +0300 (MSK) X-Spam-Flag: YES X-Spam-Status: Yes, score=5.9 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,FSL_HELO_NON_FQDN_1=0.001,HEADER_FROM_DIFFERENT_DOMAINS=5,HTML_MESSAGE=1,MAILING_LIST_MULTI=-1,RAZOR2_CF_RANGE_51_100=1.886,RAZOR2_CHECK=0.922 mailgate.nevz.com; whitelist Reported 0 times. [96.47.72.84] [30 mx66.freebsd.org., 10 mx1.freebsd.org.] autolearn=no autolearn_force=no version=3.4.5 X-Spam-Orig-To: ORCPT=rfc822;kozarenkoas@nevz.com X-Spam-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FSL_HELO_NON_FQDN_1 No description available. * 5.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level * mail domains are different * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 1.9 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list * manager X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mailgate.nevz.com X-OriginalArrivalTime: 05 Jan 2022 18:23:37.0663 (UTC) FILETIME=[5B70C4F0:01D80261] X-Rspamd-Queue-Id: 4JTj9J0Vfjz57jm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000006d458005d4d9d7ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 5, 2022, 10:09 AM Stefan Blachmann wrote= : > On 1/4/22, Warner Losh wrote: > > 15 or 20 years [...] > > main reason laptops stopped suspending in the early 2000s... [...] > > And the INT xx interface is unavailable on amd64 after we > > enter long mode > > First, you mentioned a hacking session in the "early 2000s". > This makes me wonder whether you might mistake some other thing from > the distance of time, as UEFI was no real thing until ~2010, and was > never a thing on platforms other than amd64 also. Suspend/resume on > FreeBSD only appeared much later, too. > You do know you are talking to someone who has been working on suspend / resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days, right? I'll assume not, because otherwise this is somewhat insulting. I wrote a lot of the original suspend/resume code. I worked on it with the transition to ACPI. I saw the code stop working when the GPUs started needing more state restored than could be done with INT10 interfaces. I tried to implement that on suspend/resume. I helped get workarounds for X11 on suspend/resume to switch to ttyv0 before suspending (which worked for a while, pre drm days). What you say here is factually inaccurate. Second, there is kernel functionality to call real mode interrupt > handlers from long mode, which manage switching to real mode and back. > Just an example, these are being used by vt (via vesa.ko) to switch vesa > modes. > Except that it's kinda unreliable and not enabled for vt because it doesn't work well with UEFI. So I do not see why this real mode access infrastructure could not > also be used to make a call to C000:(PCI PROM Programming interface > code offset), or the respective segment address where the actual VGA > BIOS is, to have it initialize the int 10h interface handler, if a > hybrid/dual graphics card BIOS is present. > I think a single function "InitializeVGABIOSifpresent" to enable > access to VGA/VESA BIOS functionality might actually be fairly easy to > implement. > Furthermore, there is no need at all to access hardware specific stuff > like you mentioned, as the necessary functionality is completely > covered by the int 10h Imho it could be worth to allocate a small part of the sponsoring > budget to put a bounty to motivate people (including possibly me) to > implement these improvements regarding suspend/resume and enhanced sc > and vt usability. > I'm going to disagree. Why bother. Load the kms drm drivers. The suspend/resume code is in those drivers. They work console, X11 and wayland, more or less. It's an absolutely insane idea to spend limited funds on the crazy ideas presented in this thread. They are known to be flakey, unreliable or technically just not possible. Warner On 1/4/22, Warner Losh wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > >> > > > > UEFI GOP isn't available after we start the kernel, so this is a > > non-starter. > > It works great in the boot loader, but not so good after we boot. It > could > > work > > for S3 sleep to disk where we actually reboot to restore the machine > state, > > but we don't have sleep to disk today :( > > > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GP= U and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > >> > > > > Ah, if only things were really that simple... I tried variations on th= at > > hack years ago when suspending broke due to video. And it > > works for some machines, but not others, was the quick assessment > > I made. And the INT xx interface is unavailable on amd64 after we > > enter long mode (I tried this out on my then-current FreeBSD laptop > > which was 32 bit only, so 15 years ago?). > > > > Warner > > > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it al= so > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > > --0000000000006d458005d4d9d7ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 5, 2022, 10:09 AM Stefan = Blachmann <sbl= achmann@gmail.com> wrote:
On= 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> 15 or 20 years [...]
> main reason laptops stopped suspending in the early 2000s... [...]
> And the INT xx interface is unavailable on amd64 after we
> enter long mode

First, you mentioned a hacking session in the "early 2000s".
This makes me wonder whether you might mistake some other thing from
the distance of time, as UEFI was no real thing until ~2010, and was
never a thing on platforms other than amd64 also. Suspend/resume on
FreeBSD only appeared much later, too.

You do know you are talking to someon= e who has been working on suspend / resume since I got my first Libretto 50= CT laptop in the FreeBSD 3.2 days, right? I'll assume not, because othe= rwise this is somewhat insulting. I wrote a lot of the original suspend/res= ume code. I worked on it with the transition to ACPI. I saw the code stop w= orking when the GPUs started needing more state restored than could be done= with INT10 interfaces. I tried to implement that on suspend/resume. I help= ed get workarounds for X11 on suspend/resume to switch to ttyv0 before susp= ending (which worked for a while, pre drm days). What you say here is factu= ally inaccurate.

Second, there is kernel functionality to call real mode interrupt
handlers from long mode, which manage switching to real mode and back.
Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des.

Except th= at it's kinda unreliable and not enabled for vt because it doesn't = work well with UEFI.

So I do not see why this real mode access infrastructure could not
also be used to make a call to C000:(PCI PROM Programming interface
code offset), or the respective segment address where the actual VGA
BIOS is, to have it initialize the int 10h interface handler, if a
hybrid/dual graphics card BIOS is present.
I think a single function "InitializeVGABIOSifpresent" to enable<= br> access to VGA/VESA BIOS functionality might actually be fairly easy to
implement.
Furthermore, there is no need at all to access hardware specific stuff
like you mentioned, as the necessary functionality is completely
covered by the int 10h

=
Imho it could be worth to allocate a small part of the sponsoring
budget to put a bounty to motivate people (including possibly me) to
implement these improvements regarding suspend/resume and enhanced sc
and vt usability.

<= div>I'm going to disagree.

Why bother. Load th= e kms drm drivers. The suspend/resume code is in those
drivers. T= hey work console, X11 and wayland, more or less.=C2=A0 It's an absolute= ly
insane idea to spend limited funds on the crazy ideas presente= d in this thread.
They are known to be flakey, unreliable or tech= nically just not possible.

Warner


On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmai= l.com>
> wrote:
>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>>
>> UEFI GOP seems to have the necessary functionalities
>> (https://wiki.osdev.org/GOP#Get= _the_Current_Mode) so I guess the work
>> required would be limited (restore mode and redraw screen from
>> buffer).
>>
>
> UEFI GOP isn't available after we start the kernel, so this is a > non-starter.
> It works great in the boot loader, but not so good after we boot. It c= ould
> work
> for S3 sleep to disk where we actually reboot to restore the machine s= tate,
> but we don't have sleep to disk today :(
>
>
>> With non-UEFI or old UGA UEFI implementations possibly one could u= se
>> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set u= p GPU and
>> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change
>> modes/resolutions and using sc on UEFI computers.
>>
>
> Ah, if only things were really that simple...=C2=A0 I tried variations= on that
> hack years ago when suspending broke due to video. And it
> works for some machines, but not others, was the quick assessment
> I made. And the INT xx interface is unavailable on amd64 after we
> enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?).
>
> Warner
>
>
>> But I think you are right, there are probably not too many users w= ho
>> would make use of that.
>>
>>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachma= nn@gmail.com>
>> > wrote:
>> >
>> >> Implementing S3 suspend/resume was a sponsored project it= self.
>> >> However, it still does only work when at xorg graphics mo= de, which
>> >> already was topic in this thread.
>> >> When using it from console, no matter sc or vt, it still = hangs with
>> >> dark screen and unresponsive keyboard.
>> >> Could finishing the suspend/resume work be sponsored, so = that it also
>> >> works on console-only computers?
>> >>
>> >
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>> >
>> > Warner
>> >
>> >
>> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wro= te:
>> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm= @FreeBSD.org>
>> >> > wrote:
>> >> >
>> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK &l= t;ozkan.kirik@gmail.com>
>> >> >> wrote:
>> >> >>> I've ideas about enhancing the routing a= rchitecture. Is it
>> >> >>> possible
>> >> >>> to
>> >> >>> add to wiki?
>> >> >
>> >> >> Certainly.=C2=A0 Please do.
>> >> >
>> >> > The link again is https:= //wiki.freebsd.org/2021FoundationCFI
>> >> >
>> >>
>> >>
>> >
>>
>


--0000000000006d458005d4d9d7ee-- From nobody Wed Jan 5 21:53:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F0231932524 for ; Wed, 5 Jan 2022 21:53:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.ne1.yahoo.com (sonic311-24.consmr.mail.ne1.yahoo.com [66.163.188.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTjtC37bXz3JgQ for ; Wed, 5 Jan 2022 21:53:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641419627; bh=BvtVswJC1LKjSsotoaNFONZjTP54uxnHveAtKSEwKLo=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=O7dbwMCDuiiWNPBUrDHnu4kHQyRbc5BejYMDr/dbS/LyHKxBFIWd0bGOhXJpv891ZS1TqgML7/7yrVIb44UEUJCG5umlzSf9r9lLPOFl/EhkoMfZIGb1fc+lJuniz/QxmpdUm/hZ7ASadj1JR/OD0c3mpTQg+hpVq0fc4fJicmyhVNrHEbi9i9CpYRGf7IthmnXkLgXEkjIVp1Qlh084xxuug/SIgNu2K7P2etQ0jtnGX0/24AhKofzsm7YXxVA5pXjQYaXOV8Gx2S7PT6Q5LclM+NFmbonGFkBFIdU8lR6WPPMw3xUvmypAGj8IFVbXVxHmcOOjlwV6vuNrGkYkUA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1641419627; bh=nxW3QfpvPNGiYNTslLEjOFPnWw+6oPm7O4ftptSWhEc=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=pG4sMOyrkALJ7rFEogdZTsR3YA7Jfn7utB8PHawh4kg+WaAC5GUNIFNvt188fFL+lRhahOO1Slv8tZjbHD9SOkWU/75EETu8da7/gLOrPt2KBKAdwx+DdBDKAEFr0SH/4Qkq4w7tdAlfJ+iLFD72DgZJ6Z6ocVntoQiNA8+1hbZTL5aSvVCCVcKwHh0jYqQYQFTlGlhxYb4+mKcId5i5r2fKitt1GG8q1hFIjMdAWhlpjpNW3b4YrYAIFNeTiKLJfeLcswVfZEo7EaXQKAmWop1dH/K7tb3GgvNtG4kR82PdlrpN7kVTL+L0P9i45tlpMsmYrNhNPljnck1fMuQQ7Q== X-YMail-OSG: zFRfQUcVM1nu409hilXvYAohDqeEGZ6jaAWqm6BUjZVUT0dPOl5pWQyPh42seIg NBvja40TdafsdDKB01uTlMYXeCteqQo6DGIOFD8PGu4u79OqRPbkBYGchqk_FdLksKxKzoHdpimW BaHqDliS6n71qvTGZj.PS8m6PfF0OVYsNIHQROTSQj3zynxxMpn4RW.fvjMtOUZpS5LOpc8MNG0n XUXvjEHNpUL.djlz7k3Fl1kVEiRwI5LGJAPU9QqjrVya3zy0GCTQqdGJDqxnDrbdWsr27ISCMrrU LgGB0HAqg3W1wmUVpFSwdWooA1cDAuup7avOXT9RWN5PKdIQysWDlScTz4K26ejTvflCHNCehb2H 9fdY2m7gSeVBl_AJqVnatbg6Ff1pMkJMwTFY2816qEgE89jheytpqmreTz2nSBNp.m9YHMrxzSO2 WI0uBOA3ekiEpj7jj0Ia.B0Y29b6E0ynrNrKjQ38NQma7IYZJ4aiwgLXFX_Ey4aU9u6peO_fhBP6 WqQ__.xqxbgNMILoE6iTgJvjxGmOxmx1oTVPPWFlUx4txQpfZHMg_ya3fr.wXh5_HYj2Wfsi.Yec 2OJEU5ESeqVRNjqMoxyDSvTG8noICBJtpIxplSvqNGWV7zkUQhmuM6O3vAupnSexiQVcKIugSxhD TVHvqXh5kqtH47qZrVzqrOmeLziz2Q3YSajVZ9OHE4N8g3Av9.qNbxOK275hq97GPV2DcSkHz5I_ nWz6ztR9K6qNK.Tf_SJMl0eXcX5tkIeL.QYz3vCAEPljfTpOX.ZCfV9cfGtI_fBLiWNX1LP2z9FN Pic1TZoynxzkifacN2zkmRToNYoQpmy5co2v_toRMM5IrHPTCwgGkvGFBrpWg1NYFZ6eZGAjDC2D NP85pwi9BKHLeo30qzNQqLmACKhx8SsyJDD6hJIvJbLuASeruUtnJZ7lzC_zyAqDNXaWLKQzRaUQ xs68JOioUga_m8a2N_qqLOiT2.LANV_dGgcyxAoz5Jq_JohXzQ.DPYP4LY72mt2izt4Y4jLsaviU ooROqnaxD4yPRh48TZULLqhO1j6HnQuw5LvbZiAKwT2yY_KCMPWtf9ilhLNV3lVselubvO.UbEF3 JmBt29UHmIqP9AHHgnisv4kpQ1aZPY8JFo7AN6f9AOABsOkQVk11kyt_OGy7RKxEg_SjdyaAmBrJ V_vzT8CXIT62lhGqzdpVhZYf6Kb06hJZKhxlxxbQPpwdOEwinMO9xqLzaBDJ22EH.g4ONL6dZIfq 6FwCtrN3tHs1hCbMYmP3brYgSi5ARsSbEsOphmi3hB69cNCmq3x.8HQf6jBdif76c4NbaSQd8sKx o4vcwQzXFn1oTEQI7QT2ZlFFDpsL1dnVhrFmOvcUrXGosnUzyemFJfTF5Lv_YiSOq9zVCSNF.Zr_ rpA6copkG2dExrEgEB7geb5rGPI.4sUoKXOpas1cqIRWMaXePd_EILx8vDH5ernUqAajy8IN7H31 9wYKmQLeWzabfXgTw7fvN2xHL4F__Fd73kblqxoT3Q744HAMUxZVD6sPx_37JzvkiPRTU5BBSoZj 44qUXoSCNhB9jFI_32n2_tPtnGhvP4ZK5UEcvW03QTYovb0NRycvZT5OSIgIIpCcTLjPzny2rQhD lmo3A8BTNfhZq1BSO8CpF8ypInWL_xKpZ5fEiPCmd7oKNKFGfwyPFNCXbvgQQtqHn6dNJd3mr6H0 M6xm7mGKrE8qlvcV7211zEQZOsxQ1OdS5bDc3c9eII9M6tnLXuIvD1iMmDXRKeI4oPwVRAooSX4D sU.qxT2i33WslvT4Ar5yrbyAURgLO7uUBGRADDvLa_IpGjqq8GC9CLz2uClOb.UXJffKlQYDY.q5 3I2PStDeW3yCz89Ml8nJ_WiC17WeJsAtw8xBJowoqjXlbawzA4KkhxGyXA9sGpftLxQcqljCFYPT u.DIbLRI0Bu674PBuxKeJJk1EaSNA5cdQahHlQvny8F9MWeNPv2KlIb9f2lbEVzQ5XW5kC4rmN6e Wfqd3ET0mXqyrCmKWSXESAZu1dNSdHBdR6jTHkye1L9EDk01fkLEGqpkicVAByqUT5okkK4axx6. 3I7o2uyBGvVoUC4n6SjjF0HI6wEflMYjDdNxjfauWVf1NhBcrX2P9S8dEarBkHllkP6y3_R2aNkg S5BMiNhpFfF72GVDVOEf6xsIBIOhDV2QB9qmJRY2nVywr0OZrfFqU0W5wn0oLG4BD21tKEWNDhGU 5Zwuq8XubdRvA7bLkk0GySXO0w8sZyJucGZo2p4TaAC8mDmiOLrKi7zT1cvGCypCWURpubn5aj56 ZwDoDkVRS.W8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Jan 2022 21:53:47 +0000 Received: by kubenode542.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7f075c737d2d2d110fe20dcf13197e97; Wed, 05 Jan 2022 21:53:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-Id: <31777BF2-3F35-42D1-A411-1D89262D1F62@yahoo.com> Date: Wed, 5 Jan 2022 13:53:40 -0800 To: tech-lists , FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <31777BF2-3F35-42D1-A411-1D89262D1F62.ref@yahoo.com> X-Rspamd-Queue-Id: 4JTjtC37bXz3JgQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=O7dbwMCD; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 66.163.188.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.188.205:from]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[66.163.188.205:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-hackers X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N tech-lists wrote on Date: Wed, 5 Jan 2022 20:14:54 +0000 : > On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: > >1) Can you share more details on "fails to build". Are you in a position > > to share a build log. > > The last part of the build log from llvm13 is here: > > https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log > > > It's not the entire build log. i'll try making a better one Does/did the console output, dmesg -a, or less /var/log/messages show any messages that might be relevant from the time frame? For example: kernel: pid ???? (???), jid ??, uid ??, was killed: out of swap space (Without at least 1 of the 2 below types of messages also appearing, the "out of swap space" part of the message is normally a misnomer.) swap_pager: out of swap space swp_pager_getswapspace(???): failed Another possibly of interest message, would be: swap_pager: indefinite wait buffer: bufobj: ????, blkno: ????, size: ???? There could be others of interest. === Mark Millard marklmi at yahoo.com From nobody Wed Jan 5 22:45:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9321D192120D; Wed, 5 Jan 2022 22:45:45 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTl205r6Rz3jQW; Wed, 5 Jan 2022 22:45:44 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-ot1-x336.google.com with SMTP id 35-20020a9d08a6000000b00579cd5e605eso1123899otf.0; Wed, 05 Jan 2022 14:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=/KRckfimE/fYNS8Yb0YtJAwlFz2QebF4CA96NI5Nn6g=; b=hkD3x1ZTNIEhlfXHWoQCooUZMUOAbgJP1MW/++QSsglLuKUJ/tXek0fyjVag4vKCi/ 28TvgD6YWuUg08uAjMXTR7H2QkXx2aD1r3MwUPONqvn1+3q622CAkG4fyRzexiCIyIlX vxeGE/ZHdTaY86g+nL5ZxIEyNWpmeKVELFAdXvfDcFk5KykiXHPTtb75bpiPziFnPuV2 mrFGt7C31REqnfsQlI1vEQstbuU0dkykd4/pXJi+CF+WlZXtS4HU5itkGulLaRRh9dKn CIFCtN9fST5Pekp5lmjXqPFRF/5i497EvhiWn1RnFgq6EWxtrOgtuLOjGmPJzC+WgQjy oEQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/KRckfimE/fYNS8Yb0YtJAwlFz2QebF4CA96NI5Nn6g=; b=fGGxf7/7Gc317IMBpy3ZvKdR1cqC7KunQ/TflvdKvG7DlQtDhPDzqerlSqtx2Mu26a bWC0kE1dhFLeIx9140dx1qxIL6Ab7K+yRasD9JJIgetxY1orjijDiV/MXaa25OABEdRf 6kB4zbZTFHo54Ke727FCdqlinOkXPu4wOXgXURTYQQdTg6JHvdgZbiarRw2qxyC2TYMm qZjfHl4jXkawm53sDD8pHQTxD4q4iu9I5Z5CCBnOxJ42F6/1K0q2tMR4Y9dQjEQWypIJ 7bnKYUlWhtm7GzT8jMX1lxoVrvbfEdYcvshkQr8O5jAxBwjtPHtEPxPqM3xtq0PBpCx8 u9Zg== X-Gm-Message-State: AOAM533vZ39ZVJR87m/oRPD+GxSInakVjutm6Amp/kY74ezM1ieqlJ7o 8567Zfl7htji3DtA3c922yM5jQMawz10MCdkl2xBBHrjgLdu0w== X-Google-Smtp-Source: ABdhPJztC2sD7sXiRTyxUG0IVH25tBSf6NoF5vs6Rxwpc/qtHg48Y30TzNPIt+dJzw9Ot8GDrUPxPEJ85dyV8Im80V0= X-Received: by 2002:a05:6830:1e97:: with SMTP id n23mr39295896otr.4.1641422737993; Wed, 05 Jan 2022 14:45:37 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Luna Jernberg Date: Wed, 5 Jan 2022 23:45:25 +0100 Message-ID: Subject: FreeBSD and FreeBSD Foundation on the first FLOSS Weekly 2022 To: freebsd-women@freebsd.org, freebsd-chat@freebsd.org, freebsd-hackers@freebsd.org, Martin Jernberg Content-Type: multipart/alternative; boundary="0000000000003972e705d4dd83c9" X-Rspamd-Queue-Id: 4JTl205r6Rz3jQW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hkD3x1ZT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=droidbittin@gmail.com X-Spamd-Result: default: False [0.58 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.93)[0.930]; NEURAL_HAM_LONG(-1.00)[-0.996]; TO_DN_SOME(0.00)[]; URI_COUNT_ODD(1.00)[3]; NEURAL_SPAM_MEDIUM(0.65)[0.650]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::336:from]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000003972e705d4dd83c9 Content-Type: text/plain; charset="UTF-8" https://twit.tv/shows/floss-weekly/episodes/662?autostart=false Deb Godkin from FreeBSD Foundation, guests the first FLOSS Weekly of this year and talks FreeBSD and BSD --0000000000003972e705d4dd83c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://twit.tv/shows/floss-weekly/episodes/662?autosta= rt=3Dfalse=C2=A0

Deb Godkin from FreeBSD Foundat= ion, guests the first FLOSS Weekly of this year and talks FreeBSD and BSD= =C2=A0
--0000000000003972e705d4dd83c9-- From nobody Wed Jan 5 22:45:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B5A0F19211C0 for ; Wed, 5 Jan 2022 22:45:48 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTl232b4Qz3jY6 for ; Wed, 5 Jan 2022 22:45:47 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0CDC45C01B6 for ; Wed, 5 Jan 2022 17:45:47 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 05 Jan 2022 17:45:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=dKPxXHKpJd/bjOANoYuSsWJIiBs EogSTXTUqpmm6LQ0=; b=godx87c1DzBlPEF65w67fHozvZMHibSXe243i+zgRC+ OH9spRWiBEOAejfh3xNKLnGct4znj+kgeehUOoXLe9djLaRdkDQ+Wbj9X5KvbUAD SAmJm1avdcKEcFVXBq0qMMXvoLl19988JH4sXceyjpH5PM+qaCjrLgqL4cAxPe9q 2P2Ul11z6B/QQXJrrS66g+8LnfPgZqFjo0xiKEUbpqOX7ch6FBgsu90oU3EdQwDm +FFutvLWzd7Cl0hjJvgrNmPHOkfwBJd8fms4W+7/ZlTejoe9PysEGjmlIuiYtgQ1 yleYiWuiImmEtbrTTk7tPhv28CuXBi5njhRIZh33zFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=dKPxXH KpJd/bjOANoYuSsWJIiBsEogSTXTUqpmm6LQ0=; b=gNcJZHJHlEg9VDyiokcDWr ZXNCMMoN6nfpKRmdNZMe8V9caAM9xaNY4TR+7hgAOMQi+F/NTO5BEklmBuF3+Phv WQpp5YM9zwRkUbq4KxQG9ajRqA0LIzOPLXp5nFzx6wfbccHqUFJz/DI6V8828fcI n6wCLnL/OFsnOPFTnHRulaaAZG4ridIyR9j/6QQivsmYUj6COIy6Vfkyw5DMCwa/ CWfwW+NSI6nkw9X7f3IMqB7tblVMGSzQLux0yOAzD+EtzoWpPFX/oM2zi/+UIZKy LndHWnV88DCJK5FagC7b1zHZj6WdPK88tzJXflro/1qdNmOjLNg15d2l/9I7W8dw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudefjedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseii hiigshhtrdhnvghtqeenucggtffrrghtthgvrhhnpefghffgjeeuheefleevffduveelhe efveehuefffeekgfeljeehhffgjedtudekkeenucffohhmrghinhepiiihgihsthdrnhgv thenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehtvg gthhdqlhhishhtshesiiihgihsthdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 5 Jan 2022 17:45:46 -0500 (EST) Date: Wed, 5 Jan 2022 22:45:44 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <31777BF2-3F35-42D1-A411-1D89262D1F62.ref@yahoo.com> <31777BF2-3F35-42D1-A411-1D89262D1F62@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtKYdWuXuD9Rlg0t" Content-Disposition: inline In-Reply-To: <31777BF2-3F35-42D1-A411-1D89262D1F62@yahoo.com> X-Rspamd-Queue-Id: 4JTl232b4Qz3jY6 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=godx87c1; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=gNcJZHJH; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.25 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from] X-ThisMailContainsUnwantedMimeParts: N --vtKYdWuXuD9Rlg0t Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 05, 2022 at 01:53:40PM -0800, Mark Millard wrote: >tech-lists wrote on >Date: Wed, 5 Jan 2022 20:14:54 +0000 : > >> On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >> >1) Can you share more details on "fails to build". Are you in a positi= on >> > to share a build log. >> >> The last part of the build log from llvm13 is here: >> >> https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log >> >> >> It's not the entire build log. i'll try making a better one > >Does/did the console output, dmesg -a, or less /var/log/messages show any >messages that might be relevant from the time frame? For example: bingo. This machine was configured (not by me!) with 2GB swap space. It has 16GB RAM. this is with make -j6 and hyperthreads disabled. Jan 5 21:04:31 r5601g kernel: swap_pager: out of swap space Jan 5 21:04:31 r5601g kernel: swp_pager_getswapspace(7): failed Jan 5 21:04:40 r5601g kernel: pid 31026 (c++), jid 0, uid 0, was killed: o= ut=20 of swap space I'll ask the remote end to reinstall, this time with 16GB swap. (I'm thinking maybe the defaults are set too small. The setup was zfs guided install, the "disk" is a WDC PC SN730 SDBQNTY-256G m2 ssd) so, the perl problem was down to DTRACE (which might or might not be=20 a chip or a perl problem) and the llvm13 issue was down to swap resources. thanks everyone for the help --=20 J. --vtKYdWuXuD9Rlg0t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHWH40ACgkQs8o7QhFz NAWkIQ//YpTqx/1aI56epw01PHcKXWavXRdZu5oZ0Z+oCNTiAtPVWGSQPVluNeG7 4onvdCF8t8rLJeV+iFtC2L9+71RUrSvgIrMkYBHeUEO7UTLoVZaZu51eQY9xRYih +BQ7YJUDuJLK/IHIv0cmovaoPR1Fg192jqx01890lxpMCG2KytGjupZS6roi0e6v eor7mrGpyX7pRbn6vA9vDvQpvOepm1zEMSlioULIf8gNIr8BVwqK9UKsj2sVl70/ 3WwZ5lp3DeqDqyiqfhpQpMGfSFAXiBP0BVLpWTYrE4ey9E0NdDv5h+ZoxnJaxUD8 BpYdnFdUZXYa/Bqj7QAOdCOGQSciD5pwrdWBHH0XViOLEJgNiNlR6SE5kqiBiaIL Fo5L2I0Azk0W0CtIvVY4CHx11uchoDOPaSP5x3jsmd1ZA+OF/q0GVgaae4YAKBsv 9KNBDSbDfFb22tGPTbFKBX67tLLUvuokhHZOtAuTk3QOWlLuojjheIx46dS3KqxK QWameD2wR0xEyE0ddKGOlVdj4fYjANNQH9nxQl0XsUndfU2ubkEscUqYbNwB15mX 5feNBPGA6eOzZLsz9BUjNjJuxErYOIA2gRDOTEpD4OiN/454SqHrDoFkshqppAEC zJUwsdzt34M0vuD04XjgziWar1RVpMJALAi+cfCt7IrMLpI4WX0= =vwQ7 -----END PGP SIGNATURE----- --vtKYdWuXuD9Rlg0t-- From nobody Thu Jan 6 10:25:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A10931927ABE for ; Thu, 6 Jan 2022 10:25:19 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JV2YB5CGsz3Qy4 for ; Thu, 6 Jan 2022 10:25:18 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by relay11.mail.gandi.net (Postfix) with ESMTPSA id A8B30100008 for ; Thu, 6 Jan 2022 10:25:10 +0000 (UTC) Date: Thu, 6 Jan 2022 11:25:08 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JV2YB5CGsz3Qy4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.178.231) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.178.231:from] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jan 05, 2022 at 11:22:39AM -0700, Warner Losh wrote: > Why bother. Load the kms drm drivers. The suspend/resume code is in those > drivers. They work console, X11 and wayland, more or less. It's an > absolutely > insane idea to spend limited funds on the crazy ideas presented in this > thread. > They are known to be flakey, unreliable or technically just not possible. The main problem is that modern VGA devices often only have just enough VESA BIOS support to give Windows a generic framebuffer as fallback. Otherwise, I don't think it is as flakey. All that said, spending funds on it would certainly be misdirected. Joerg From nobody Thu Jan 6 15:42:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 11D72192DDD5 for ; Thu, 6 Jan 2022 15:43:01 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JV9bm1rKpz3PX4 for ; Thu, 6 Jan 2022 15:43:00 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id w20so5552306wra.9 for ; Thu, 06 Jan 2022 07:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d8538UsC+psxXUA9XMNSE00TOsD5JZWY5EyZMcR94j4=; b=WoMRbfN2j8oYBF8Yj5Rx3csx64Mr46/Rsd52TxNOZEqo7Fi8jiGzqD8b0PTW34Hmg+ iKfxGPCTQboSxrx+AxRY9lRz/BrBaAhlbw9iOt+epvTB5iF732JcG1frdnTrLZd2lf9T IbREa41ipQ1ZSihCjnkFcsok2Btu04VyFmQmOzEY9ZmD3Cij6DKJ9X7OmTj6J8EuUZD1 GgF8BdblfKsBTREz67fQ8DLw9tIZKeaSY7GX/v/ut2XTWM3g1O3OciFmxIMpuLcaPN8U /+Cz/W59XCGiaJjMeFRRvX+AUi4j6v2TR9w9RBI0vgIIwSynQUh8+wfOIRuzXIvJxQfN nFeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d8538UsC+psxXUA9XMNSE00TOsD5JZWY5EyZMcR94j4=; b=jisc53sdXB9DwAkikSDVvI0a0rN6UOOyEYmz7aq0QLFXCVMdYoSWo9Chh9FUgy/7Q9 170ouNoI4p7bsqwbuuRZSk6wy8Fz6Exa9jaUoekcr46Yy4eTU4rvPd4ik6cXmxXnyDbC nVS56+Oegea6tLCnoW+vANt5iqpZK4Fs0ejaO26bmqqxTNj+WYZ6zXO0f+UqoXYWg4lZ uYgrjqPZlA3H+8WtYbfpEaDmvM5r+Uj1XU5yKRuo8J5Wu5dwDvGBAzHyKxtrWyXa3ppG dQ83feAFjx3favTLNrFZfLki/CBgv/GlnDxabLK+nm9HM3YlG8ZfVuxm8vPQd7KuYMAr MC9A== X-Gm-Message-State: AOAM532Uss6DV+lwV1HD//SUe4B2pJ3x54sFr84UczlaAeB1dkngbRUX MSsrdKA3EydjrjjVoGH9TBdD3Zec1Xc= X-Google-Smtp-Source: ABdhPJzZbSnAt/g0kyAY3pHByVxUlKeod4Ku9oAfbEyg/tv5m6DnaXtMylFvOVZNz1qNQHgNhiMzjw== X-Received: by 2002:a05:6000:1c1d:: with SMTP id ba29mr6973409wrb.235.1641483778927; Thu, 06 Jan 2022 07:42:58 -0800 (PST) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id q206sm2104155wme.8.2022.01.06.07.42.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jan 2022 07:42:58 -0800 (PST) Subject: Re: Call for Foundation-supported Project Ideas To: Michael Schuster Cc: FreeBSD Hackers References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> From: Karel Gardas Message-ID: <2b7022b7-2225-aa19-24fd-d60be9d30d0d@gmail.com> Date: Thu, 6 Jan 2022 16:42:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JV9bm1rKpz3PX4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=WoMRbfN2; 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.37 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.984]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.62)[0.619]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 12/29/21 8:12 PM, Michael Schuster wrote: > Hi Karel, > > On Wed, Dec 29, 2021, 19:32 Karel Gardas > wrote: > > > > On 11/23/21 11:41 PM, Joseph Mingrone wrote: > > Hello FreeBSD community, > > > > The Foundation is seeking suggestions for new projects to > support.  What > > gaps in the Project are not being addressed by the broader community? > > sorry for being late with those: > > 1) implement/port beadm equivalent from Solaris/IlumosOS? Make > freebsd-update process more reversible by using proper boot > environments > and using ZFS snapshots. > > > All of these have been in FreeBSD for quite a while - can't give you > dates or specifics (port vs "builtin"), but I've been using them since > at least 13. Went ahead to properly verify the fact on fresh 13 install on ZFS root and no. The feature is not there yet. E.g. - bectl is presented in 13-p0 - 13-p5 - freebsd-update does not contain any reference to bectl hence it cannot create snapshot on update on 13-p0 - 13-p5. However, freebsd-update in 13-STABLE (source code) contains bectl bits to handle snapshoting on update as proposed for inclusion here: https://reviews.freebsd.org/D21892 So my conclusion is, perhaps with 13-p6 it'll be first time the feature will be user-visible and usable. Sorry for nitpicking but needed to know that for sure. Thanks, Karel From nobody Thu Jan 6 16:33:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 12962193BDEC for ; Thu, 6 Jan 2022 16:34:02 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVBkd1sQpz3nmq for ; Thu, 6 Jan 2022 16:34:01 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12c.google.com with SMTP id g26so6066887lfv.11 for ; Thu, 06 Jan 2022 08:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=efKv8lYZjy7B7a/b4qPg6vs9ffrOfZ3lUPccUrOSqCM=; b=Jrwmo5iRmjkPpiQ0ulE1oZjnukztp5jSoRm0LZNY5hoFdSAmm+PC7v9i6UJ4eYmYBG ggLq8gQ5A6t34b2IKefqlDinoXmMz7+yh5V3PxO+1fQW2oZZ/Df24evodx/EXIDg8god k5NFpwBGjpQreQogdH2Wc0sHCLkM6OTMi58woIfSCTcohPAdAFu2bWbgP3bYj5twX++M shnLlQTATQ0EiIMPEP25T/JU4/B8rQz2ueu8ZFyH7epLkzJX7KubB+GEJQWoA533Z+bN 9DTu6A/MeVBKmpoM60Pw7D2MtwkMFUCw4cQwEeOSNNfzPH5p/tHYzf9jMKu2Rlefufrh RPJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=efKv8lYZjy7B7a/b4qPg6vs9ffrOfZ3lUPccUrOSqCM=; b=colOUIuQr/7eFJBVnz9LK2dgavkk9Bv778oj7he1FyVgfrmMmENNT4HuwdqJHidaOq qWMxQNmKChCirUz9dkhWvbsgLSR5tTh2UvDYjlKBcv2kg8IanEp1T8dSZlYWTjSjME40 KA9Yb9iCI5VVwJQUkQHDp5ha0gr2liaBA/yeeGK9gc0IJZXSyzyV9rJSPaI6jY/4USIY xdK9UDMYQch+ws6xDTtI356fMcadG3H5CCLQTsvswJTmYj2//IhoO9MUEjnXk6PuP470 OnSG9lknG5etG7jGDPit5N+NMpWL4JWBuffL0RyarKXFPqiez7W3RYUJvQgiWyMiutKY 75Fw== X-Gm-Message-State: AOAM533J2o0GvAYPzZ8OjHq5WSp44SlHbjIDSHF0BbgtoPOV929Qx22p oC2vvLU3DUeY3gFuI6d7pFBY43ouayxCLz7lTNIgCHYqx7M= X-Google-Smtp-Source: ABdhPJxpOVEhRT1EVQILK0qY3v9F6prJ1uB0vzycskt4fUTXjlc6t23sXEglzX9W+sbVUMi/T+lu78CMoFtsQfWG3Qw= X-Received: by 2002:a05:6512:2304:: with SMTP id o4mr51307500lfu.563.1641486833473; Thu, 06 Jan 2022 08:33:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Thu, 6 Jan 2022 08:33:52 -0800 (PST) In-Reply-To: References: <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Thu, 6 Jan 2022 17:33:52 +0100 Message-ID: Subject: Re: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JVBkd1sQpz3nmq X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Jrwmo5iR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::12c as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [1.99 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12c:from]; NEURAL_SPAM_SHORT(0.99)[0.995]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Correct. Only late in the discussion Warner mentioned that the kms drm drivers need to be loaded. So my request has became moot. The drm kmod drivers usually are being associated as graphics drivers for xorg. Thus it is not at all intuitive/obvious that these are also required on console-only computers to make resuming succeed. Given this, it is rather a *documentation* *issue*, as the necessity to install/load the drm kmod drivers is *not* mentioned anywhere in the documentation regarding suspend/resume, making users wonder why resuming fails. On 1/6/22, Joerg Sonnenberger wrote: > On Wed, Jan 05, 2022 at 11:22:39AM -0700, Warner Losh wrote: >> Why bother. Load the kms drm drivers. The suspend/resume code is in those >> drivers. They work console, X11 and wayland, more or less. It's an >> absolutely >> insane idea to spend limited funds on the crazy ideas presented in this >> thread. >> They are known to be flakey, unreliable or technically just not possible. > > The main problem is that modern VGA devices often only have just enough > VESA BIOS support to give Windows a generic framebuffer as fallback. > Otherwise, I don't think it is as flakey. All that said, spending funds > on it would certainly be misdirected. > > Joerg > > From nobody Thu Jan 6 16:41:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D6D5193E41B for ; Thu, 6 Jan 2022 16:41:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVBvg3H7sz3qbm for ; Thu, 6 Jan 2022 16:41:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa36.google.com with SMTP id w206so1104795vkd.10 for ; Thu, 06 Jan 2022 08:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xed6ddoP760+qUtb/hseWE60VTg6BYXft4AaSQnwXwQ=; b=BxtUpwbsKWy86M11mHvc/vqGfCxHojC1nNy8VtVhgGxPa4Tt6F19EnPrfs60i0G3Il SOxzaxZ+LBN8X9cmFVNRVJAnbfAwlzzLZU3faiEolgGRCRrZRrmko5gDYklEktiH4uF1 yu+ZqQHa/cBgAp0glD7Vhy9Mt7K8zBHK7UQGyNn+QazxpUDJ0a0uerd4Fz7mJoi4Xyzz F1mC4Y/aRp8ZEhA6Gm1TtWlwd/vqFVgOZTGjMm2mUU42dn2yJ4j67Vtm8Vj92odiupBe K8kCeNPgwD56s+oXgtbhs9zjj4DDK8V/m0UDrcI2n4sa3I/vuC0R9dFXcpH1NhLegXNW 63tQ== 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=xed6ddoP760+qUtb/hseWE60VTg6BYXft4AaSQnwXwQ=; b=QWscSRXNnhqBkE3mSyvkiju7NPTZwdd2cHLVm8lNBkDgTPZ/vkXTRYtfDDH+ra21dZ l1zDU2P7hlsy6CCEz4jkYxXDy5Q+KwWMfCmVKd+edja6zRmGkBChS5nRW0ovjj+i/eyt uf7la/67mOPmFG8gvDF0+4Ofb7hMY0GLTc2ieyZ5impZpsek6lsIhn/mYXXsU6+vcxwu tYeSYY4K7+HLIRahwp62Hu2GI7ssDCSKytxp64Sro5RzILQOTdUupZiwTlzG28HwGWW4 tu1FBwFx6r68/2Gz3JmEERTGicbYNaxatO1aQHUEcTT8WTc5tqLQ4JlJ1HokhgwxqG1V u6YA== X-Gm-Message-State: AOAM5330mL/OT7pA+pJ6o0+r7inbwL5toy+ieuteu9I6QAwyRyuWnZnZ 95BKpiht4k9C72E8vo4CLcugybwanAGRsNY2bT4obJETEjc= X-Google-Smtp-Source: ABdhPJzMqKWLK1cNx9Z+sR5f9DXs1NM5ZUTgPfOv+GrBvFcqs4cy9C/hKUvCsdT6xqwvElejsBYietiZ2W4+Fhy/0Qg= X-Received: by 2002:a1f:1688:: with SMTP id 130mr21130633vkw.27.1641487304662; Thu, 06 Jan 2022 08:41:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Thu, 6 Jan 2022 09:41:33 -0700 Message-ID: Subject: Re: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000b2cf8705d4ec8ba6" X-Rspamd-Queue-Id: 4JVBvg3H7sz3qbm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000b2cf8705d4ec8ba6 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 6, 2022, 9:35 AM Stefan Blachmann wrote: > Correct. > Only late in the discussion Warner mentioned that the kms drm drivers > need to be loaded. > So my request has became moot. > > The drm kmod drivers usually are being associated as graphics drivers for > xorg. > Thus it is not at all intuitive/obvious that these are also required > on console-only computers to make resuming succeed. > > Given this, it is rather a *documentation* *issue*, as the necessity > to install/load the drm kmod drivers is *not* mentioned anywhere in > the documentation regarding suspend/resume, making users wonder why > resuming fails. > Absolutely agreed on need more docs and an update pass. I raised it as part of this year's core team meeting with the foundation. Though this one issue likely can be handled by a simple document PR. Warner > On 1/6/22, Joerg Sonnenberger wrote: > > On Wed, Jan 05, 2022 at 11:22:39AM -0700, Warner Losh wrote: > >> Why bother. Load the kms drm drivers. The suspend/resume code is in > those > >> drivers. They work console, X11 and wayland, more or less. It's an > >> absolutely > >> insane idea to spend limited funds on the crazy ideas presented in this > >> thread. > >> They are known to be flakey, unreliable or technically just not > possible. > > > > The main problem is that modern VGA devices often only have just enough > > VESA BIOS support to give Windows a generic framebuffer as fallback. > > Otherwise, I don't think it is as flakey. All that said, spending funds > > on it would certainly be misdirected. > > > > Joerg > > > > > > --000000000000b2cf8705d4ec8ba6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 6, 2022, 9:35 AM Stefan Blachmann <sblachmann@gmail.com> wrote:
=
Correct.
Only late in the discussion Warner mentioned that the kms drm drivers
need to be loaded.
So my request has became moot.

The drm kmod drivers usually are being associated as graphics drivers for x= org.
Thus it is not at all intuitive/obvious that these are also required
on console-only computers to make resuming succeed.

Given this, it is rather a *documentation* *issue*, as the necessity
to install/load the drm kmod drivers is *not* mentioned anywhere in
the documentation regarding suspend/resume, making users wonder why
resuming fails.

Absolutely agreed on need more docs and an update pass. I ra= ised it as part of this year's core team meeting with the foundation. T= hough this one issue likely can be handled by a simple document PR.

Warner
<= br>

On 1/6/22, Joerg Sonnenberger <joerg@bec.de> wrote:
> On Wed, Jan 05, 2022 at 11:22:39AM -0700, Warner Losh wrote:
>> Why bother. Load the kms drm drivers. The suspend/resume code is i= n those
>> drivers. They work console, X11 and wayland, more or less.=C2=A0 I= t's an
>> absolutely
>> insane idea to spend limited funds on the crazy ideas presented in= this
>> thread.
>> They are known to be flakey, unreliable or technically just not po= ssible.
>
> The main problem is that modern VGA devices often only have just enoug= h
> VESA BIOS support to give Windows a generic framebuffer as fallback. > Otherwise, I don't think it is as flakey. All that said, spending = funds
> on it would certainly be misdirected.
>
> Joerg
>
>

--000000000000b2cf8705d4ec8ba6-- From nobody Thu Jan 6 16:47:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62E69193F3F5 for ; Thu, 6 Jan 2022 16:47:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVC271rsjz3rqX for ; Thu, 6 Jan 2022 16:47:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd29.google.com with SMTP id y70so3833959iof.2 for ; Thu, 06 Jan 2022 08:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYKjuFszelvUEU+J5+lcQjQXpAA82LBdfbrEv8Rj0zU=; b=a7MWKAsdnpGSFVmeVxqFGTrH3iVPcicgfbv10AHrBedCgdFx4G6HqDAUJUyKldn64F uWjPvp+J8R+vaD4wD7GbpQTJA5uTteGT0r5cRFgdJoEpoibYHfarcOqbK4eR6R7uausu cT/eZW2RaSuWSu13T6YSzXE6v8t70n3Hiem3DOQJ31PwrgT56/qxcHACacrDdwChYd7X Da0pBK7omArSm/pzI/gN2mXsKk35KgW+j2rYceor8LU7k8cRJnQPp1FGgpOQdaHu7aCw cV8RRRriVf0Itev+SHL1MqvNwrKGOUL4LUuaeoi9LD6nRGsRLPO6xzm1oktjaqjl7r/0 PYIA== 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=XYKjuFszelvUEU+J5+lcQjQXpAA82LBdfbrEv8Rj0zU=; b=UZ/z4TzowS2+jDwO1/eXxFtuSMDJV4x5clMy4r8Ya5rOgCo9dr5nnAXzoQ1lfLDuEM akWI7XrwUatTmKFGy246PIcTwNA5QMaWVAHowWYIkq0mhDKezLqHR/z+PSb5gFc+nljr Gbr+dak5un/LM1mazhOJlF8ndloyu6siT0SoNiSEOU2Zyfqj8432l9dZ+AhDLOqE78ai rcelT6MEuwnOknMyKTXUP5ry7tjdQmxAijibWlVtSAM1pXJOS7EII09hIbyicv4fvp6R +8N3uHxCirYx2z/9tGvJHdYej9QTMcLfImgfISf5InFB55ziac5jN5kwk9U4eUa+Gsoj HY8w== X-Gm-Message-State: AOAM5316R0SW3d1iQnNdg8gU6+BiuE3uuG2EzZjHiYgmfAWxwF/QuAHh rpn4EsUq+jeSUf24SQ4P0fOPfItNVDtPGRG6TXU= X-Google-Smtp-Source: ABdhPJxmFd/OFUiXCm1Z6AeOQKk/Ka8QBHSJoH/ryum2e5oOKBsN1ZsaJMrVt8KfRH0x31RODCrTXwlkr05Yh/+9lls= X-Received: by 2002:a05:6638:348c:: with SMTP id t12mr29142496jal.269.1641487646313; Thu, 06 Jan 2022 08:47:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <2b7022b7-2225-aa19-24fd-d60be9d30d0d@gmail.com> In-Reply-To: <2b7022b7-2225-aa19-24fd-d60be9d30d0d@gmail.com> From: Michael Schuster Date: Thu, 6 Jan 2022 17:47:13 +0100 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Karel Gardas Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000fce8705d4eca079" X-Rspamd-Queue-Id: 4JVC271rsjz3rqX X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000000fce8705d4eca079 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 6, 2022, 16:42 Karel Gardas wrote: > On 12/29/21 8:12 PM, Michael Schuster wrote: > > Hi Karel, > > > > On Wed, Dec 29, 2021, 19:32 Karel Gardas > > wrote: > > > > > > > > On 11/23/21 11:41 PM, Joseph Mingrone wrote: > > > Hello FreeBSD community, > > > > > > The Foundation is seeking suggestions for new projects to > > support. What > > > gaps in the Project are not being addressed by the broader > community? > > > > sorry for being late with those: > > > > 1) implement/port beadm equivalent from Solaris/IlumosOS? Make > > freebsd-update process more reversible by using proper boot > > environments > > and using ZFS snapshots. > > > > > > All of these have been in FreeBSD for quite a while - can't give you > > dates or specifics (port vs "builtin"), but I've been using them since > > at least 13. > > Went ahead to properly verify the fact on fresh 13 install on ZFS root > and no. The feature is not there yet. E.g. > > - bectl is presented in 13-p0 - 13-p5 > - freebsd-update does not contain any reference to bectl hence it cannot > create snapshot on update on 13-p0 - 13-p5. > Hmmm... I thought I was referring to ZFS, BEs and beadm (equiv) only, not -update. Sorry if my message was confusing (and I'm too lazy to go back and check all the old emails :)) > However, freebsd-update in 13-STABLE (source code) contains bectl bits > to handle snapshoting on update as proposed for inclusion here: > https://reviews.freebsd.org/D21892 > > So my conclusion is, perhaps with 13-p6 it'll be first time the feature > will be user-visible and usable. > > Sorry for nitpicking but needed to know that for sure. > NP Michael > > Thanks, > Karel > --0000000000000fce8705d4eca079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 6, 2022, 16:42 Karel Gardas <gardask@gmail.com> wrote:
On 12/29/21 8:12 PM, Michael Schuster wrote:
> Hi Karel,
>
> On Wed, Dec 29, 2021, 19:32 Karel Gardas <gardask@gmail.com
> <mailto:gardask@gmail.com>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 11/23/21 11:41 PM, Joseph Mingrone wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hello FreeBSD community,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The Foundation is seeking suggestions for new= projects to
>=C2=A0 =C2=A0 =C2=A0support.=C2=A0 What
>=C2=A0 =C2=A0 =C2=A0 > gaps in the Project are not being addressed b= y the broader community?
>
>=C2=A0 =C2=A0 =C2=A0sorry for being late with those:
>
>=C2=A0 =C2=A0 =C2=A01) implement/port beadm equivalent from Solaris/Ilu= mosOS? Make
>=C2=A0 =C2=A0 =C2=A0freebsd-update process more reversible by using pro= per boot
>=C2=A0 =C2=A0 =C2=A0environments
>=C2=A0 =C2=A0 =C2=A0and using ZFS snapshots.
>
>
> All of these have been in FreeBSD for quite a while - can't give y= ou
> dates or specifics (port vs "builtin"), but I've been us= ing them since
> at least 13.

Went ahead to properly verify the fact on fresh 13 install on ZFS root
and no. The feature is not there yet. E.g.

- bectl is presented in 13-p0 - 13-p5
- freebsd-update does not contain any reference to bectl hence it cannot create snapshot on update on 13-p0 - 13-p5.


Hmmm= ... I thought I was referring to ZFS, BEs and beadm (equiv) only, not -upda= te. Sorry if my message was confusing (and I'm too lazy to go back and = check all the old emails :))=C2=A0


However, freebsd-update in 13-STABLE (source code) contains bectl bits
to handle snapshoting on update as proposed for inclusion here:
https://reviews.freebsd.org/D21892

So my conclusion is, perhaps with 13-p6 it'll be first time the feature=
will be user-visible and usable.

Sorry for nitpicking but needed to know that for sure.

NP=C2=A0
Michael=C2=A0
=

Thanks,
Karel
--0000000000000fce8705d4eca079-- From nobody Thu Jan 6 17:54:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD906193186E for ; Thu, 6 Jan 2022 17:54:57 +0000 (UTC) (envelope-from mohamedatef1698@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVDX11PhNz4XTg for ; Thu, 6 Jan 2022 17:54:57 +0000 (UTC) (envelope-from mohamedatef1698@gmail.com) Received: by mail-wm1-x32e.google.com with SMTP id e5so2372471wmq.1 for ; Thu, 06 Jan 2022 09:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=k8GMnUwjwCnbfMGnAUcL7MN8fE22HR3+l/PVQPxQVYU=; b=VtICcz42wZWjhgFxzguPQEzj/rrXPjVcppmFBlS+rDik786kFWgXR+rRHvi2uQC7Uj 6hJxFAouuk1yh906inrNCyrypoTrat9WAyjlcFljl0n0vRG+x8cCV4txaatEkLolAFJz 8nkWF2GteIm5WgYiDbDpHtV9NRXuGiUQxdwdMN24aZ/iLETx+Gt9VMmC53N/kI0ewSTh rxgmw1MSLIDi3bXxjkF7KiLrB2GGlOd/YrIcDtfr08P9xjhcNmehwe9I6KmBbWj3ncEG gmXEMU7ord5vQjfyrdHrxJ6qQFNNGUvnTtgKwP/tzezY7zGbWys5403WisgAMV4KQrst ODKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k8GMnUwjwCnbfMGnAUcL7MN8fE22HR3+l/PVQPxQVYU=; b=NhpFGzyDdcMdv9RApsi6OvSPYjmtE6DrE8D1EryksTUVo3ZHo6lOKN3cLrCvrUby6O gh8vLqLhWbcyT4pfkOkC9yvTLOwLC84KZXlUQiWHg3faoCiy7a/m+AfajQn3Eb0z59+t tbR2x1H8whmPlHAUW1Ue4CihXMLpsjySCLxn9AHOvv/OOA3alF/uNec3JnBqyRE317Cn Hbqf5Q1MyFK0/Jkmo68YOxojfrT6uNKIU+fOK/MaQZvLrrleg3GGQnt9kUuIqvUWBV4f evCJ0ecVjNRUeT1X81ce8WWJ/EYbsB1ZghquCtwzMAt7iRNrSLa3vyk/UgGaE0S24IeG CmLA== X-Gm-Message-State: AOAM5325owMsZcJWbZtENSQdctJthN/3EqFiHOXMFXH/zWO0/wNuI7K7 QTbjuHgIIeKPTgGcpjepTO5ekiq1l8onDNlCiHfNDh4Sv/w= X-Google-Smtp-Source: ABdhPJzghHZIj2sSD1a21scBzBw7+Tc/zCTTGndn8ZcOLKFA+Uj2rVxNL2uLwCs2Rif5jCDnysSGklFq6WYLJf3LWjk= X-Received: by 2002:a05:600c:ad2:: with SMTP id c18mr7761787wmr.177.1641491689598; Thu, 06 Jan 2022 09:54:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mohamed Atef Date: Thu, 6 Jan 2022 19:54:38 +0200 Message-ID: Subject: Volunteer To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000f736d05d4ed9107" X-Rspamd-Queue-Id: 4JVDX11PhNz4XTg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VtICcz42; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mohamedatef1698@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=mohamedatef1698@gmail.com X-Spamd-Result: default: False [-0.00 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000000f736d05d4ed9107 Content-Type: text/plain; charset="UTF-8" Hello great community, My name's Mohamed, I am a computer systems engineering student in my final year. I have strong programming skills and a great understanding of data structures and algorithms. I also understand operating systems concepts (IPC - Memory Management - File System, ...etc). If you have some open projects that I can help with please let me know. I wish I could help this community. I hope to hear from you soon. Mohamed --0000000000000f736d05d4ed9107 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello great community,
=C2=A0=C2=A0=C2= =A0 My name's Mohamed, I am a computer systems engineering student in m= y final year. I have strong programming skills and a great understanding of= data structures and algorithms. I also understand operating systems concep= ts (IPC - Memory Management - File System, ...etc).
If you have s= ome open projects that I can help with please let me know.
I = wish I could help this community.
I hope to hear from you soon.


Mohamed
--0000000000000f736d05d4ed9107-- From nobody Thu Jan 6 20:51:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E07A19397E1 for ; Thu, 6 Jan 2022 20:47:14 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JVJLn0kNPz3Kxy for ; Thu, 6 Jan 2022 20:47:12 +0000 (UTC) (envelope-from pj@smo.de) Received: from localhost (localhost [127.0.0.1]) by mail.adebahr.de (Postfix) with ESMTP id D16A360027584 for ; Thu, 6 Jan 2022 21:47:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=smo.de; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id; s=mail; t= 1641502024; x=1643316425; bh=3m38swn9bg9q50fXFojqdBuziSt28MMTej/ dlsLLpRI=; b=vh0xeaLMYvBDIBHeo0wDpr88RigD0pb5dcqTVhgozFgg71LqyoF pfeA4ZJM/iKEOCWKptQ4avc1ejKqUxYsxuOCSvZhvKgh7A7gDZP9eqjzIojdCcx4 tW2wUJIc4+0C8T3X6fofXb+5mWykjsMcbGPbuHZHJCJS380zWothRaDs= Received: from mail.adebahr.de ([127.0.0.1]) by localhost (mail.adebahr.de [127.0.0.1]) (amavisd-new, port 10026) with LMTP id HljR92NHOIrp for ; Thu, 6 Jan 2022 21:47:04 +0100 (CET) Received: from [192.168.153.212] (p5b239586.dip0.t-ipconnect.de [91.35.149.134]) by mail.adebahr.de (Postfix) with ESMTPSA id A84E56002758D for ; Thu, 6 Jan 2022 21:47:04 +0100 (CET) Message-ID: Date: Thu, 6 Jan 2022 21:51:03 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Volunteer Content-Language: en-US To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JVJLn0kNPz3Kxy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=vh0xeaLM; dmarc=pass (policy=reject) header.from=smo.de; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[smo.de:+]; DMARC_POLICY_ALLOW(-0.50)[smo.de,reject]; 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:198930, ipnet:185.66.176.0/22, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.35.149.134:received] Reply-To: pj@smo.de From: Philipp Ost via freebsd-hackers X-Original-From: Philipp Ost X-ThisMailContainsUnwantedMimeParts: N On 1/6/22 18:54, Mohamed Atef wrote: > If you have some open projects that I can help with please let me know. Welcome! There's a section on contributing in the FreeBSD Wiki which might be worth checking: https://wiki.freebsd.org/FrontPage/Section/Contributing You could also check the open problem reports to see if there's something for you. Happy hacking! Philipp From nobody Mon Jan 10 12:38:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 81DEE1944973 for ; Mon, 10 Jan 2022 12:38:59 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXYKZ43Z5z4gV4 for ; Mon, 10 Jan 2022 12:38:58 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4E59A5C00F7 for ; Mon, 10 Jan 2022 07:38:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 10 Jan 2022 07:38:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= date:from:to:subject:message-id:mime-version:content-type; s= fm1; bh=imG3cdVKaeKMWtuRHJTnixkqsA4GWRvPueGPmfs3hfY=; b=lK5wimvu era3K9NqLI2JLyxBpFsx/RMrEUggmPbo2G/f4zazMEwEOrn/o+6APFH11o1HaLGk KG4bqSlJOJSebQDAGCaAUhuYcAr13IemuKUtcVFtot1sLaLpRtiju1k0oC3qIchf 5uz6rrWJum+ffN9/6ynyarxpMWK9lW40HUSW3E1qdNAUi9cFGDVsrDaquOkCFKUo hiDZMpX4KXZK1J12yFaj8uP1IlAcrBufyagtIZTnrpvo4y5YvcIo13XlPxvGZlCA nd95daqPRpf5z7U3UdWBDvl7owwYO6t/59sEdyD9wxqj1bbHzrggS368U0qtpIIp wr4e+hMhE1JnDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=imG3cdVKaeKMWtuRHJTnixkqsA4GW RvPueGPmfs3hfY=; b=cAHJHfdbsN7i4geoub81rhZwWNVDQoptd8CkdhsVZYL1z DnXQ8msD4hByIx2gUjzlQlBrbkRtRY8yRUoXxdkd/0D6EwjsY+d9fY1Otj2EB6gJ I5mne9cXeBGz2uo1WzXdcAmZY+TRhQAftuZhJ2mKWv1vSoKdHMNWqB0z2g/bmxfK +Ic3Uk15cSLGUckz2f3Y2QxeX2jWHLyf+l9+RT04hBP/jxIVN9KmeHauriUaf9yw dFGVY0NqTKcPP53buzyvYGrCnQTOXa0Epo9DJboVXoErUiOAbGLpsncgu7bj3xbJ jdWr20XwB3CeuJueJqMKOWXWutffjQBaYdPIsDbsg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudehuddgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomhepthgvtghhqdhlihhsthhsuceothgvtghhqdhlihhsthhsseiihiig shhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfeejhfekheegiedvleeltdehgefghf dtkedtvdfgheevhefgvefgueetgeeggeenucffohhmrghinhepfhhrvggvsghsugdrohhr ghdpsghsugdqhhgrrhgufigrrhgvrdhinhhfohenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehtvggthhdqlhhishhtshesiiihgihsthdrnhgv th X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 10 Jan 2022 07:38:50 -0500 (EST) Date: Mon, 10 Jan 2022 12:38:48 +0000 From: tech-lists To: freebsd-hackers@freebsd.org Subject: sane-find-scanner on the USB bus causes a crash Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PV82uTgAbbBYvHzI" Content-Disposition: inline X-Rspamd-Queue-Id: 4JXYKZ43Z5z4gV4 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zyxst.net header.s=fm1 header.b=lK5wimvu; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=cAHJHfdb; dmarc=none; spf=pass (mx1.freebsd.org: domain of tech-lists@zyxst.net designates 66.111.4.28 as permitted sender) smtp.mailfrom=tech-lists@zyxst.net X-Spamd-Result: default: False [-6.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[zyxst.net:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.28:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[zyxst.net:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[zyxst.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from] X-ThisMailContainsUnwantedMimeParts: N --PV82uTgAbbBYvHzI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, There is a *very old* PR open here :=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207431 about this issue. It was from 10.2 then someone else confirmed it was happe= ning on stable/11 and i've found it still happening with stable/13. Posting to= =20 hackers@ hoping someone knowledgeable will look at this. How is it that the usb subsystem can cause a crash to console? I have an old desktop c.2010 vintage im trying to get working well with sta= ble/13. The hw info is at https://bsd-hardware.info/?probe=3D0f0ae001cd The context is stable/13-n248872-2c7441c86ef: Thu Jan 6 02:34:00 UTC 2022= =20 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 8GB RAM, zfs raidz1 (3*1TB disks) packages were installed from pkg.freebsd.org if I run sane-find-scanner -q this happens: Jan 10 00:41:29 kernel: ugen4.2: at usbus4 as expected, but a few seconds later, this happens: Jan 10 00:50:33 kernel: ata2: FAILURE - odd-sized DMA transfer attempt 5 % 2 Jan 10 00:50:33 kernel: ata2: setting up DMA failed Jan 10 00:53:36 syslogd: kernel boot file is /boot/kernel/kernel Jan 10 00:53:36 kernel: ata3: already running! Jan 10 00:53:36 kernel: ata2: already running! Jan 10 00:53:36 kernel: spin lock 0xffffffff81cac3c0 (callout) held by=20 0xfffffe000f91f3a0 (tid 100003) too long resulting in a lockup at next write then drops to console, press any key to= reboot. What info would I need to capture to try to resolve this? The system is fine in every way apart from this. thanks, --=20 J. --PV82uTgAbbBYvHzI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmHcKMwACgkQs8o7QhFz NAX07Q//VUdR01kmScCjU2A4evSNRcLyORjqFzPwtKcg49bU+kDCdhzgNhdDvl7v kz7T0p2WL2/5G0iC8059BzU5mf/tVWGrFGVfDyP78mhKAMM4y9+kaHxwCtUTnFs3 37+jSADPptSVK40QHbDJ+jHqmpatzSutHar23reP5VgHpSaODOtwwGUtYMf5VfE4 bpZQ5lH7GtEim1odOKVHZTDIIJvxe5EfOcVG/MZmLSylDwWv1/d2nk7jx6Oppuf1 T9MEnaEs2g/RHTf1do3lWHoTB4MAXd9BPrrO3Si0fYwFcBlCP+hhB7M/xlbWCeTk S0aixFD6GFvuA0Z8rvjpuB09ZFFsEAt9Zajga6N2qgtZTakxG/JeA3KTZhkiiaeL e6nixvWQewNISicsiUv4WIqYi4p4oruf930E3TmFp3U04HOCr5IgetTWd60kqqPv Tn201oaEoyueb5txcWsyMMajmQ1oP11HavfhdWiQYGi+XJlcJKbD1v41LHg0AIca UOJLm35x3sFSVEBgeNeXtwqJpk5UFUSLiaReQvx2bjmQL3mky+gaV02yT+kGknBx INW1r3soh/BSenwvQC07GMVCMkAaURSAX6V1GZ0PtdxBnrAyKrnwntGoAyZ8qCU4 GoJhNAcEnGKq/nRRQ6QRhBzoDvWngANRFquwDKfF3BqGIWBOR6k= =Zavh -----END PGP SIGNATURE----- --PV82uTgAbbBYvHzI-- From nobody Mon Jan 10 12:55:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CA03819494EF for ; Mon, 10 Jan 2022 12:56:02 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXYjG0V0nz4l3P for ; Mon, 10 Jan 2022 12:56:02 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Date: Mon, 10 Jan 2022 12:55:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1641819359; bh=23l4Y/DxPb/6whLVYkIauFHAjCcVo2pw5zlCULR+njM=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc; b=nPmHR5syhPh/TOoRkdoho4VyYmDKq+M/QeqzGsRTVSzS8GEm+rIRmP9Z7uiDQXa/p mKe0b9EbUka7fTM6A/AuoPDnuLCUDJzUYY+FLy/FQpbGg0pQ/URdf95uATI/mSGF0c bo8b0hf/mWJpZqe8myj65OZ4vJwYwwlkm1rCYM9bUP10CZ5Z3bxQxafyFwJ1R4ol5B oet1bIKSvx6t8UbPDPOkbjIC9VNk1rbZbaCRL0Gq1oF00Fv17fjQPEmZ4cZ7agHDx9 aSWA/+oDBQrfMAJ1gXdvJjTEc/fm7jy6lXk3ulkrDwMZTO0jlbb1bbYstrfpSZcVdu CuZLNldZSil8A== To: "freebsd-hackers@freebsd.org" From: ralph41096 Reply-To: ralph41096 Subject: Out-of-swap killer and SIGTERM signal Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JXYjG0V0nz4l3P X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail2 header.b=nPmHR5sy; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of ralph41096@protonmail.com designates 185.70.43.19 as permitted sender) smtp.mailfrom=ralph41096@protonmail.com X-Spamd-Result: default: False [1.98 / 15.00]; HAS_REPLYTO(0.00)[ralph41096@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.43.19:from]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; NEURAL_SPAM_SHORT(0.99)[0.992]; NEURAL_SPAM_MEDIUM(0.99)[0.994]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_SPAM_LONG(1.00)[0.998]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, Do you think it would be a good idea to introduce the following soft mode for the Out-of-swap killer? Old behaviour: 1) If there is no free swap space left, send SIGKILL signals to the condemned processes. (This is the hard mode.) New behaviour: 1) If there is less than 2 GiB of free swap space, send SIGTERM signals to the condemned processes, then wait for a 5 seconds grace period, then send SIGKILL signals to the condemned processes who are still running. 2) Repeat step 1) until the amount of free swap space becomes greater than 2 GiB. (This is the soft mode.) 3) If the soft mode does not release swap space fast enough, and the amount of free swap space becomes zero, enter hard mode and immediately send SIGKILL signals to the condemned processes. These two system-wide parameters (2 GiB of free swap space, 5 seconds grace period) could be defined in a configuration file, to allow the administrator to change them. The intent is to allow condemned processes to write some data on persistent storage and exit gracefully, when the shortage of swap space does not happen too quickly. Ambert From eugen@grosbein.net Mon Jan 10 13:14:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8DA2194E3AE for ; Mon, 10 Jan 2022 13:15:15 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXZ7P5xm1z4pD4 for ; Mon, 10 Jan 2022 13:15:13 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 20ADF4Fj075048 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jan 2022 13:15:05 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ralph41096@protonmail.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 20ADF3BE000950 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 10 Jan 2022 20:15:03 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Out-of-swap killer and SIGTERM signal To: ralph41096 , "freebsd-hackers@freebsd.org" References: From: Eugene Grosbein Message-ID: <76ec92c8-2ace-e526-45b3-58fcd4ecc061@grosbein.net> Date: Mon, 10 Jan 2022 20:14:57 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4JXZ7P5xm1z4pD4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.09 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[protonmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 10.01.2022 19:55, ralph41096 wrote: > Do you think it would be a good idea to introduce the following soft > mode for the Out-of-swap killer? > > Old behaviour: > 1) If there is no free swap space left, send SIGKILL signals to the > condemned processes. (This is the hard mode.) > > New behaviour: > 1) If there is less than 2 GiB of free swap space, send SIGTERM Keep in mind that swap is optional feature and there are systems running without any swap configured. From nobody Mon Jan 10 13:59:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 10E3E193B35F for ; Mon, 10 Jan 2022 13:59:42 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXb6j6LBXz3DX0 for ; Mon, 10 Jan 2022 13:59:41 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Date: Mon, 10 Jan 2022 13:59:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1641823173; bh=asCvXgQ1R48m4SeRfEYH9usoi0TnWSe2WMB85NMksY4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=KnlOWoI0RLUPwS2kM6hUqu5hvlZto3GgqoFit2aQ0gVBfKBpc1jffyTF1dnG5mYlV Fl6g/IZLmsJXP5HLM5EhL2jIYnW2Ligy54AlvuPJ6fv1IL+CponiSChACUZPTL/bfW 8fIFfqcs/sQAfT0W0VCw2237X4pwNYM539UgSnTqhKtzf5oWeTh8mh3kivs1diuzC/ YU0fq774RyF9ybgQuAzcK5DBByZdUu3ml5VYXkNcgYL5wplg9vGLIYrYroRVd8h31q bSiKjyOKGsA7OKX+klkKYhxGlZEzM+257oBJNq267GoCoLHby1io3aqR1Nnal1FN9j G3W3oX871liSw== To: Eugene Grosbein From: Ambert Cc: "freebsd-hackers@freebsd.org" Reply-To: Ambert Subject: Re: Out-of-swap killer and SIGTERM signal Message-ID: In-Reply-To: <76ec92c8-2ace-e526-45b3-58fcd4ecc061@grosbein.net> References: <76ec92c8-2ace-e526-45b3-58fcd4ecc061@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JXb6j6LBXz3DX0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-01-10, Eugene Grosbein wrote: > Keep in mind that swap is optional feature and there are systems > running without any swap configured. If there is no swap installed on the computer, then the Out-of-swap killer will be awaken in soft mode when there is less than 2 GiB of free RAM left. If there is only 0.7 GiB of swap installed on the computer, then the Out-of-swap killer will be awaken in soft mode when there is less than 1.3 GiB of free RAM left. The administrator can get the old behaviour (no soft mode) by letting any of the two system-wide parameters to its default value (a grace period of zero seconds, a grace space of zero bytes). Ambert From nobody Mon Jan 10 14:57:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5BD7A194CA12 for ; Mon, 10 Jan 2022 14:58:08 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2080.outbound.protection.outlook.com [52.100.215.80]) (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 4JXcQ73b2Qz3R3Q for ; Mon, 10 Jan 2022 14:58:07 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cEEvpKOKsBpOe3ViOe9TtdYEcbXGIADrwz0+TkQrIG+6VAx3Jf57xKTKDQikhFkJX6c0Zby7xGd7dnqVLq7wSZyCAjpFSEm92T3sMnfEhCDOUbN/XAtBVZOcFmaKxZB+9Slx32vPG3eEjy/SUYMgHSleZG9uUByyjhNhUHZ60nHqW5O6pNYVRt2ypM9QkeXFB666PJm+ivxenUhT+oMBoHRf9FHL1dk7lnTSeAEdRIu69eNZft1V7Et9n5TE8jFbY1VK68NEoWCqCnGkNLZ+/cmDUqiuP8lsZcBUj+JCv+8QRn76dDE4GQ5RgVl6JjHmKeVagHXuEPPw59uM82QUJQ== 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=lezO30qfoKZV5ebvIaXdCm1/pISeTRAKaqVRXo0PysA=; b=apbjoPjum2StV/gAXVEX4NL5MGw7yeW/a/6FFY/PH/JLszZjy59GmAVc1RMql+PYVBPaoCS9EsXKluSXLhQOFB1qLNFNmlgKdZo3iYcXKySE1J7kZFmIRGJaGwS41IM+HNcbnVFvkrrA5QbqDclmHMlqBHRwTXa/cea3Fbzi6Wzo3CP0k8vTbLJjfPAOyXXVO7f6Uu1KOP+wizDiRTStzBrjh9B8+wvDwaHZvda7PbYjC3QAXCMehrzw5ns+4CfmIiT7XcAb2j4udVkna9GoVy2GUunCQg+YTKYhXoTibQqVs1jtrYG81K2ItD/th7a26RrCSXl1LXxkMuff+/jxkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lezO30qfoKZV5ebvIaXdCm1/pISeTRAKaqVRXo0PysA=; b=sQ35NnGIrPLTKXm5sh7HmPJ1re8ZG2Mmi44qA0XqrmerkTNj8R/BSMqeCwJZ0K3F6ygheCx5T3H45SkoqZD/ydQ1/ERK3jgRqBRLvZM0JFw8THf0HU2P6xj1TdM9Vq9/lSpU8ITCwRk/tjNEZJDB9VrJJ6QhhFVDhSsnONJDOtPAGXuRqT7ywB/To9FaP0PhAA/gaiMu9V0bz/fGK+E050qSor09WU1XOX5taXHZW40Y5mFsmjgJd1qOiLItjSqk97/8UfWi5wM2OYsvnyW9xciga1hIugc891cYGcpxKlsTDGz/H6gAB8vZKW0O7mucTNAkknXPz0SD0mHA7ODvyA== Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:11a::9) by TYYP286MB1811.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:f9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Mon, 10 Jan 2022 14:57:58 +0000 Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::4d39:4ab4:e041:c6f5]) by TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::4d39:4ab4:e041:c6f5%8]) with mapi id 15.20.4867.011; Mon, 10 Jan 2022 14:57:58 +0000 From: Daniel Cervus To: "freebsd-hackers@FreeBSD.org" Subject: AR9462 still not working properly Thread-Topic: AR9462 still not working properly Thread-Index: AQHX/51q64ieRyYR40Ob8xn4ikKeHaxcZVvf Date: Mon, 10 Jan 2022 14:57:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [hEDWMNHSxaJ73OrPnWvuh4N1ZgYeFB7k] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6df5f6b6-26ea-4b07-2c44-08d9d449977c x-ms-traffictypediagnostic: TYYP286MB1811:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gHRSFG4SoR6sHJHj06CsrsM89LDu8KdXlHGt19jtmfN03lYjIggkdB8ILGvAmvC40P9l/GukWavOaBMyHIoA9ae5bdttqI942zzwxJFF12kV1/CE1/Wlg6EvMQwDoGuxK8R7uv3N2MQSH0XTevkAz83LHoqWLbMq8GttCnOvgFP8DKEsbLRuCN9eKSkxsVA84UnEW64KsiBEoqw2dZJby5w3zYMUOngi2M1I2Q4II0Pt5Vxxa1828+V54DB65m+zk4X2Zflx3j03cJKYLZbxdQPUzaxr1ZqQaNbXwBeO5gsGRv6GDqwWqCk2Bvd+9adp9TTkwk5XMWyJvnLghldVC6oNwmupAvgtPAMUsFQ04cmXud3dJ+SIcUBLuOPZmMqHzbAki0p1YgcHe6iCluesF3oZHxctDSRD/ouxmu2hNmtoAiL02Rcr1LXcUkUSm2Kx9wz72G3RDorpmpBljjR4lH3dXUkQ6pS8rzc1zEyAgNNMs/n6QHTLWZnyikYsj9tlvrNEw8mipd9kCOiR4IpNpS3T724MevgQqbovcsiDBcaY/LLa0xJU92gp5yesUDCEqHB7XW6rML+NEfCkRI0OqA== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?32r764wmG1eGct4nWMDjAlZuO5Z3EvWVrlYBEaF9a1bk6/DUwE8CuZiM?= =?Windows-1252?Q?CVhNsTdhwX5p6C586xQO97UzidLZo4r/mjnI1deho6gAXkLLuyZfFpTX?= =?Windows-1252?Q?iCk6j8sA/vGaoYmHs64GUO5DTtZStvbQ4K07N9kM9/B+U9OezKWMbynF?= =?Windows-1252?Q?ipeueBk65UNBVjBPivAgAMgA3VPCX/nhy+BP33m7/ylp1V7HsGX1Rz+U?= =?Windows-1252?Q?60jWWDRxif2BF5FIuCn1qHfKiFBsJXJpQZc3Swf+QYVZaFMXhgjh703r?= =?Windows-1252?Q?cKQOr4QbnTUEM96dsOE6GphObvg0iAOU8DSuRW4QBD0ySkeAEJHsCIv1?= =?Windows-1252?Q?lnAkvsTg/YwL7YE4LvA+h/qAxGZPiiH+MAOvH2+FkFTxGFCLN8h17C3s?= =?Windows-1252?Q?EJugrLTdWS8Y7l9iZLwh6JSmlRczLuAF743hgy0+07Fb8R+B1nlZK2uW?= =?Windows-1252?Q?clS4XveOGtvQkfmeETdudGM9MMwUA6oKkqX8FdZhGnVu9tQaN1QHYHy+?= =?Windows-1252?Q?NHCwEMh0Lgn6yqgrzVDV/+VFPb03q6SHDKyhPqtCq+ZYtXc4H+z9E1An?= =?Windows-1252?Q?mYeNlVzKeyajSqdpjfPH07+1mfKCe7rAYqPNJG7QpicTakzSFdwNv42s?= =?Windows-1252?Q?2cowgoJYuiFUHqmV/+GaVYG1qSah8z0rbC0PZehPniBvRXKR5xfthihH?= =?Windows-1252?Q?6oXFOR4rGCWIpBG8GT9E83dXMF8d0KHzrfJB209RA9hTtJIVtEP10ESR?= =?Windows-1252?Q?3WrrA4dHQX7ofkeZeKYTOlBIUmv+jVzHsfZnWlg2imEcp4azTxxY32oE?= =?Windows-1252?Q?oa0veXOdiA0c7eXMdtbcnTkJv7wk6ySyCvdO4A3tPKWl4kRdZXiS8B5d?= =?Windows-1252?Q?M8AvqdMLP/jt/yl7lqwPwZV4Kv02QlSoFpvb8twd/pxhOaQKBsAl0RL1?= =?Windows-1252?Q?2828wrS1IxIzvjCcaNF04vNRJUq0eQ/2HYqn95sxw6lF3OJYZRqP7zaO?= =?Windows-1252?Q?AKdlWO/ld6zCPJh9BnzchVaa9Cnl8wK2hANMcHSVZeHxdL52wBI=3D?= Content-Type: multipart/alternative; boundary="_000_TYYP286MB1546FF52504EA36C04EA4C50B8509TYYP286MB1546JPNP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6df5f6b6-26ea-4b07-2c44-08d9d449977c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2022 14:57:58.8365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB1811 X-Rspamd-Queue-Id: 4JXcQ73b2Qz3R3Q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=sQ35NnGI; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 52.100.215.80 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-5.00 / 15.00]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[outlook.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[outlook.com]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[52.100.215.80:from] X-ThisMailContainsUnwantedMimeParts: N --_000_TYYP286MB1546FF52504EA36C04EA4C50B8509TYYP286MB1546JPNP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, everyone. I have been using Dell 1901 (AR9462) wireless card since r= elease 12.2, but minor problems keep occuring. For example, it cannot be re= cognized in bsdconfig, when not connected to networks, error message =93Fai= led to add operating class IE=94 repeates. I remembered someone has told me= that he would deal with that. Now, I have done a brand-new installation of 12.3. But bsdinstall still had= diffculty in scanning Wi-Fis, and after I had tried a few times, no Wi-Fi = could be found at all. How to deal with this? I have put up a PR about that= . I=92m sorry for that I may have described the problem unclearly there. --_000_TYYP286MB1546FF52504EA36C04EA4C50B8509TYYP286MB1546JPNP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hell= o, everyone. I have been using Dell 1901 (AR9462) wireless card since relea= se 12.2, but minor problems keep occuring. For example, it cannot be recogn= ized in bsdconfig, when not connected to networks, error message =93Failed to add operating class IE=94 repeates. I remembered someone has told me that he would deal with th= at.

 

Now,= I have done a brand-new installation of 12.3. But bsdinstall still had dif= fculty in scanning Wi-Fis, and after I had tried a few times, no Wi-Fi coul= d be found at all. How to deal with this? I have put up a PR about that. I= =92m sorry for that I may have described the problem u= nclearly there.

 

--_000_TYYP286MB1546FF52504EA36C04EA4C50B8509TYYP286MB1546JPNP_-- From nobody Mon Jan 10 18:09:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E4E341938E12 for ; Mon, 10 Jan 2022 18:09:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXhg73r5mz4nrY for ; Mon, 10 Jan 2022 18:09:39 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 20AI9QGd030403 for ; Mon, 10 Jan 2022 10:09:32 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 10 Jan 2022 10:09:25 -0800 From: Chris To: freebsd-hackers@freebsd.org Subject: Re: strange compiling problems on AMD Ryzen 5 5600G with freebsd-current In-Reply-To: References: <31777BF2-3F35-42D1-A411-1D89262D1F62.ref@yahoo.com> <31777BF2-3F35-42D1-A411-1D89262D1F62@yahoo.com> User-Agent: UDNSMS/17.0 Message-ID: <312123f17fc5d341fde0a7babae5bf3a@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_e1c0c7139e92aa24d6ca132ccd39c4b2" X-Rspamd-Queue-Id: 4JXhg73r5mz4nrY X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_e1c0c7139e92aa24d6ca132ccd39c4b2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-01-05 14:45, tech-lists wrote: > On Wed, Jan 05, 2022 at 01:53:40PM -0800, Mark Millard wrote: >> tech-lists wrote on >> Date: Wed, 5 Jan 2022 20:14:54 +0000 : >> >>> On Wed, Jan 05, 2022 at 06:55:38PM +1100, Peter Jeremy wrote: >>> >1) Can you share more details on "fails to build". Are you in a position >>> > to share a build log. >>> >>> The last part of the build log from llvm13 is here: >>> >>> https://cloud.zyxst.net/~john/FreeBSD/current/amd64/llvm13.log >>> >>> >>> It's not the entire build log. i'll try making a better one >> >> Does/did the console output, dmesg -a, or less /var/log/messages show any >> messages that might be relevant from the time frame? For example: > > bingo. This machine was configured (not by me!) with 2GB swap space. > It has 16GB RAM. > > this is with make -j6 and hyperthreads disabled. > > Jan 5 21:04:31 r5601g kernel: swap_pager: out of swap space > Jan 5 21:04:31 r5601g kernel: swp_pager_getswapspace(7): failed > Jan 5 21:04:40 r5601g kernel: pid 31026 (c++), jid 0, uid 0, was killed: > out of swap space > > I'll ask the remote end to reinstall, this time with 16GB swap. I think the standard math for a system with this much RAM is RAM/2 (8Gb). IOW 8G should be more than enough. It's been that way for me for ~5yrs on a server serving ~100 hosts and all supporting services. I've also never encountered swap problems building world/kernel/ports using this formula. HTH -- Chris > > (I'm thinking maybe the defaults are set too small. The setup was > zfs guided install, the "disk" is a WDC PC SN730 SDBQNTY-256G m2 ssd) > > so, the perl problem was down to DTRACE (which might or might not be a chip > or a > perl problem) and the llvm13 issue was down to swap resources. > > thanks everyone for the help --=_e1c0c7139e92aa24d6ca132ccd39c4b2 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_e1c0c7139e92aa24d6ca132ccd39c4b2-- From nobody Mon Jan 10 22:11:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 25B3C1937EF0 for ; Mon, 10 Jan 2022 22:11:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXp2428Hkz4h4D for ; Mon, 10 Jan 2022 22:11:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x82c.google.com with SMTP id f17so14059447qtf.8 for ; Mon, 10 Jan 2022 14:11:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=pjSjuVC6BdsEVNT++l/IJSTWIlkXLhGI4uBoMBYzAOQ=; b=ETt+qlninjaki2gIO0OAPnU+5Kqxw1U2zHsQK4twoOet+0oHAN/F8ZImJc2+eWAOR3 6oJFNdF1VyUWT/DB7gklZXTnas2tfLxWdywZtOaL+JQ4y/EHCI82d8vVOsLt7E2yCF8N n8FEpMj/sDOsuz8O75pOHXan33NsQJtsb6wxqNDMSP25zq80+Ov+PLxho84TOwxV0at2 3mhVWHj86XrNyBxM1ZjOm/GaK6kSfkomIGs1ePGHZv5VfXFHJAG43zmxZt/InXLE/+1U T1OqGwgiR/f5q4p5sSdE+dZ0oXezS1tZMxEmj5XMIcEOG4ellTWvcteQXhASu11WvNuU O3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=pjSjuVC6BdsEVNT++l/IJSTWIlkXLhGI4uBoMBYzAOQ=; b=ak9S8m4k/efzyVoE+GEbBtDhNNl+Sdk4cE3T1jHknP7iLMpxaFRS4x1Xs6uYyS3bNR XQIsh3u1JoaSJhvhvP2CsfV1dVcRa+BHvERESFVcHD7gFWfr8ufegXXDQduFFO7dvSi8 oKHzQYqCgrCcOrYzalO/vjq4VcLXubw2g9skNUkOd11jKSe3SkH69oCmIAqWnnlEdbUR /sGr20sdPXtaBkXuzdufXeZPBK4GENUzqrWx4lQrIlgY57gfY6D7xvarEMh70NnGdYPI 3SFHstXMc7EY/uI8E9kFLSyzDNaArZUnshH2A6eYRto78Coe4gsVS0m4BXzW1I7OVumi JIiw== X-Gm-Message-State: AOAM533+Xs983B4zzbu/7FllrncDfeVoLIxqRnWf4tIinBVcBV9ncSCO 9YZL2Qr5S6d2oBtscKi/4S1WjKUykJkISqGwGyFdSkE5r2DR1IKjCDi4AiWaKrIhkmg2lpeVv6S 2EI5D7n9g+Y+UWu3ayskvUyuedF41v+gSvimOl0HuMzaj4Mlszw3YJRsYMpSYWr/id2Gg978IeQ xKNqYtmoBXYQGt X-Google-Smtp-Source: ABdhPJxaYf/xXJ4gHAqBqLLMME3OsFdvbns8305Qo2npqsZKLgJdG8X4duyZQHVdNHnqlUs2wW3pOw== X-Received: by 2002:a05:622a:49:: with SMTP id y9mr1583407qtw.647.1641852677853; Mon, 10 Jan 2022 14:11:17 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id v10sm4938295qkp.105.2022.01.10.14.11.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 14:11:17 -0800 (PST) Date: Mon, 10 Jan 2022 17:11:16 -0500 From: Shawn Webb To: freebsd-hackers@freebsd.org Subject: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sgfvw27rfranexkx" Content-Disposition: inline X-Rspamd-Queue-Id: 4JXp2428Hkz4h4D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=ETt+qlni; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::82c as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-2.92 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_SPAM_SHORT(0.10)[0.102]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_SPAM_LONG(0.07)[0.074]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82c:from]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received] X-ThisMailContainsUnwantedMimeParts: N --sgfvw27rfranexkx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey all, So I'm getting an interesting ZFS-related kernel panic. I've uploaded the core.txt at [0]. I suspect it's related to FreeBSD commit 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge openzfs/zfs@f291fa658 (master) into main). I'm able to reproduce it on a single system with some level of determinism: I'm building the security appliance firmware at ${DAYJOB} in a bhyve VM that's backed by a zvol. The host is a Dell Precision 7540 laptop with a single NVMe drive in it. The VM is configured with a single zvol, booting with UEFI. Looking at the commit email sent to dev-commits-src-all@, I see this: 146 files changed, 4933 insertions(+), 1572 deletions(-) Strangely, when I run `git show 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset of those changes. As a downstream consumer of 14-CURRENT, how am I supposed to even start debugging such a large patchset in any manner that respects my time? It seems to me that breaking up commits into smaller, bite-size chunks would make life easier for those experiencing bugs, especially ones that result in kernel panics. ZFS in and of itself is a beast, and I've yet to study any of its code, so when there's a commit that large, even thinking about debugging it is a daunting task. Needless to say, I'm going to need some hand holding here for debugging this. Anyone have any idea what's going on? I guess this email is to serve three purposes: 1. Report that a bug was introduced recently. 2. Ask for help in squashing the bug. I'm more than happy to test any patches. 3. Start a dialogue on making life just a little easier for downstreams. [0]: https://hardenedbsd.org/~shawn/2022-01-10_zfs_core-r01.txt Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --sgfvw27rfranexkx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmHcrwIACgkQ/y5nonf4 4fqRHQ//abZ9zuVCCr/OSL5+mLZE9A+AZaTq21RIIFvDIhdSmCK01+zCAHMvuCps 6n1mtuYrpvgBY9Sa9aDc/zuseNPTJ604Y2jQADL30kMlTj8+qUAyORMF+/GtOlXi aQzcckSTQgxq/gnY0z6tDgcFtHs4F66IyTXEmRyDt15JX7rd8pO8Z/YyTgj61E1L Kuq88AjnBC5qmqB6AqqkPYm5piEZ2ZJq7JKPhVg6LDqi6wBEgY2zM1fPf3fLN1Dx YRNZnkI/xvoqQFrzFSqoTDRBI6Hj4OPJqAN6AmNCnEomy7HZH8HQZSJLDjyUKJrf /B6Bdo5arJGWBM+ov1WsRBjXVViGj0Fyy6JeVjzoZU439to9lehtZ0uVZf64EuH8 aNdFgcWXloTPOPLHnE623KbieJwQfFVgTsN3u0GeR1RxFN+bTMdV/Y58T3vPasAN CA1N2o3qONqa/MX/UUqQiyBEXE71QAzEzgXUaCnOLQZgdy7FDjz7pL5tyMta2Stz Rba4eFTcliqptKVrSKSHHkQUwl1iQSCOv8nyktiq6qwu17FzmbWnm0Cb+L1lzMAO UwygJH1gipwLMVszB8mE9vCjWz3N1EHuD06EMP/f4japEThfE7KasDRrFOZHFQVB 1cVr+uSx5Fori7w1gYQdOF1hkYpRajJOvX31+M3xA54mpTGvvHo= =EUgs -----END PGP SIGNATURE----- --sgfvw27rfranexkx-- From nobody Mon Jan 10 23:34:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E3C22194E441 for ; Mon, 10 Jan 2022 23:34:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXqsT5v8Cz3CNM for ; Mon, 10 Jan 2022 23:34:05 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72f.google.com with SMTP id u23so4806104qku.5 for ; Mon, 10 Jan 2022 15:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fHAYkYjS5/H9xIv7wrC5kX1Hq8LojbdYG/+vwQIV6Kk=; b=Td1/KN0po2khspXYRdx6OXxqh2pBhv2LYQZ4iGgH0JesQH8am5pNIXt7Lqee+sW9t9 axshhgYV7cVZ7Q4gTQCSNgKb5GruOb81LBHYKBkMLftb0HcRTae/ZjnbZNyAK0GDiWd+ sxL9mkerWoh45XK8uIlKGDSnEzmZDSWIa1Y8yK34hBfewOLHU9+ElzxaK6mpdrhofhmO WjhIx2RLR3UNcJ/i5Vb1OlrD+XDZcXAEGYMyvv9oDwwYVyvvofJb7cCjkC9otv+yr+lE 6tud63WjRqyhbEKR/nl30tcFoFTjTtDclV9y9a04JbcXe2V7Q8jI1KT8E3v+aV4ZSDuN Rw/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=fHAYkYjS5/H9xIv7wrC5kX1Hq8LojbdYG/+vwQIV6Kk=; b=sPEAKJYuH+gk12tG7mWMj9mfRTzV7l9+WRsvtT1NCYS5AcA8bUpQMWSb8YWZFHXpm0 oj0vqrJm7gqxIC32WtV8IsPv6Xg/B0ffkcR5qZ5JgKbb6kYy/UjTL1DddGM9qziney9Y hRs26yk9e9FhMlFpJ5TCLWVrd6CfI6P/WsrAaW5KzFa4wrPmT+IaLE+E32lBEY8Kh8JP R5/Ok+ZJsPHA6l6nSDK5bv7gAYsHYRALIEAdfZwrmLk0e1hDRh+btKRijnWnbxGAlnzq pZZy4QqJIlXXrAb1g08bYTrzx2iysK2cDXPlcpHYiO41SwcBXvYszY+7NVLhvntQnJD6 lYPw== X-Gm-Message-State: AOAM5317T3IgEfRTR1utz0FNXtOhr735Il0kLxGiy+cYKpWe85jDXMTD UXZhp4G680AeLGgZ2Z4tnKzrVVSm6vE= X-Google-Smtp-Source: ABdhPJyaoNhH4y8ot3FvWW7V0ysoqfTJxQlQWCUMjA0zjLm92VaWyCrt+CdAf65HpEmer4+3cbaimw== X-Received: by 2002:a37:a80e:: with SMTP id r14mr1559868qke.655.1641857645377; Mon, 10 Jan 2022 15:34:05 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id l15sm1871273qtx.20.2022.01.10.15.34.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 15:34:04 -0800 (PST) Date: Mon, 10 Jan 2022 18:34:02 -0500 From: Mark Johnston To: Shawn Webb Cc: freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> X-Rspamd-Queue-Id: 4JXqsT5v8Cz3CNM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 10, 2022 at 05:11:16PM -0500, Shawn Webb wrote: > Hey all, > > So I'm getting an interesting ZFS-related kernel panic. I've uploaded > the core.txt at [0]. I suspect it's related to FreeBSD commit > 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge > openzfs/zfs@f291fa658 (master) into main). > > I'm able to reproduce it on a single system with some level of > determinism: I'm building the security appliance firmware at ${DAYJOB} > in a bhyve VM that's backed by a zvol. The host is a Dell Precision > 7540 laptop with a single NVMe drive in it. The VM is configured with > a single zvol, booting with UEFI. > > Looking at the commit email sent to dev-commits-src-all@, I see this: > 146 files changed, 4933 insertions(+), 1572 deletions(-) > > Strangely, when I run `git show > 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset > of those changes. That is a merge commit. You need to specify that you want a diff against the first parent (the preceding FreeBSD), so something equivalent to "git diff --stat 681ce946f^ 681ce946f". Use "git log 681ce946f^2" to see the merged OpenZFS commits. > As a downstream consumer of 14-CURRENT, how am I supposed to even > start debugging such a large patchset in any manner that respects my > time? > > It seems to me that breaking up commits into smaller, bite-size chunks > would make life easier for those experiencing bugs, especially ones > that result in kernel panics. That's up to the upstream project, in this case OpenZFS. > ZFS in and of itself is a beast, and I've yet to study any of its > code, so when there's a commit that large, even thinking about > debugging it is a daunting task. > > Needless to say, I'm going to need some hand holding here for > debugging this. Anyone have any idea what's going on? To start, you'll need to look at the stack trace for the thread with tid 100061. > I guess this email is to serve three purposes: > > 1. Report that a bug was introduced recently. > 2. Ask for help in squashing the bug. I'm more than happy to test any > patches. > 3. Start a dialogue on making life just a little easier for > downstreams. > > [0]: https://hardenedbsd.org/~shawn/2022-01-10_zfs_core-r01.txt From nobody Mon Jan 10 23:43:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F41A41950B66 for ; Mon, 10 Jan 2022 23:43:07 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXr3v6Qkpz3G76; Mon, 10 Jan 2022 23:43:07 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x32e.google.com with SMTP id i5-20020a05683033e500b0057a369ac614so16800217otu.10; Mon, 10 Jan 2022 15:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uqNDlW1VOJXhDn6t1u5Uxt5K3gKGRUWeQg4YIgEBv3E=; b=Xv9t7c05NqHRmcbCnusaWny+SlzHB4bdqnytqiQs2Jp/l91jz5nEsfD48t2urhdEsg q0uD6QK79z9hVJB85rTYdCfRDnX6FLcSkbznzRkQxNTB2T4S84kWoqgVEi8EkIo+1HBG hzhVR0sB1CYI/xvht3JZSnMBzP+G+yU930AeIoUrrQ28MHaWKBLwlNvpF+duS3vCXHkG udcGLtn0AVV7foNxx7EPf5uS/X3m3LP3NhbdmhfGtzehcGPS7Mh48k9b+8Y97E0uEAIG BHsAj5HkFtDp8KBC2G2kTZ9RKgagyP+ewSepZnjui7w7sOa7WxmON0J3z1ferw7l2D6T pUSA== 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=uqNDlW1VOJXhDn6t1u5Uxt5K3gKGRUWeQg4YIgEBv3E=; b=X49GGOKfOP1lIgZvOZ9Y77brRUbIrAGXxRbkwYjqIGujd7jQjyYPUJD83XhOnCtUEs DFVeXI3wvSfgZdLpDSQV8466XNkx1Nhsobx4xr9+hG6toOws1E6jN0ixh1QSUPlQbDTR 4wl4zI6IHJNkZm2brwcqIKaHCuqk7U7r5PwR8HY11uYuLc+KWHaGFxT4iND3Wjrzr8j1 iFHXKq71VvNao4rnX0jXzDAtsfr1UO6SnRzSo1Moe4J/BkabRPVgxy21OZCVl4HKoebV E/uqCMmmtx/iTYABbu0EEOhgvq/Ofx/IvPpzpAzAuT0tK34Y3JUlHm8nQKHTLOIiu+L+ rDbQ== X-Gm-Message-State: AOAM532kSWpPwMpnL8nftOUzF3oj4Ga5zxDNC7zvOaLCuBM1m3Q0W/E2 9On2twPPd9j7TE/qrcO4J5Iu4/roPgMLqkpDD8mTPPml X-Google-Smtp-Source: ABdhPJwe+F3n4hyJHsEjtBf0cNO3irFIPVr1dPjN8G67x/HisH7hOL0laadWJxt0Gk9loyM9tOd2H1JOevcMuR+PXCQ= X-Received: by 2002:a05:6830:13c7:: with SMTP id e7mr1558197otq.302.1641858187272; Mon, 10 Jan 2022 15:43:07 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:7f0a:0:b0:3f5:9e34:628e with HTTP; Mon, 10 Jan 2022 15:43:06 -0800 (PST) In-Reply-To: References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> From: Mateusz Guzik Date: Tue, 11 Jan 2022 00:43:06 +0100 Message-ID: Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets To: Mark Johnston Cc: Shawn Webb , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JXr3v6Qkpz3G76 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 1/11/22, Mark Johnston wrote: > On Mon, Jan 10, 2022 at 05:11:16PM -0500, Shawn Webb wrote: >> Hey all, >> >> So I'm getting an interesting ZFS-related kernel panic. I've uploaded >> the core.txt at [0]. I suspect it's related to FreeBSD commit >> 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge >> openzfs/zfs@f291fa658 (master) into main). >> >> I'm able to reproduce it on a single system with some level of >> determinism: I'm building the security appliance firmware at ${DAYJOB} >> in a bhyve VM that's backed by a zvol. The host is a Dell Precision >> 7540 laptop with a single NVMe drive in it. The VM is configured with >> a single zvol, booting with UEFI. >> >> Looking at the commit email sent to dev-commits-src-all@, I see this: >> 146 files changed, 4933 insertions(+), 1572 deletions(-) >> >> Strangely, when I run `git show >> 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset >> of those changes. > > That is a merge commit. You need to specify that you want a diff > against the first parent (the preceding FreeBSD), so something > equivalent to "git diff --stat 681ce946f^ 681ce946f". Use > "git log 681ce946f^2" to see the merged OpenZFS commits. > >> As a downstream consumer of 14-CURRENT, how am I supposed to even >> start debugging such a large patchset in any manner that respects my >> time? >> >> It seems to me that breaking up commits into smaller, bite-size chunks >> would make life easier for those experiencing bugs, especially ones >> that result in kernel panics. > > That's up to the upstream project, in this case OpenZFS. > >> ZFS in and of itself is a beast, and I've yet to study any of its >> code, so when there's a commit that large, even thinking about >> debugging it is a daunting task. >> >> Needless to say, I'm going to need some hand holding here for >> debugging this. Anyone have any idea what's going on? > > To start, you'll need to look at the stack trace for the thread with tid > 100061. > imo the kernel should be patched to obtain the trace on its own. As the target has interrupts disabled it will have to do it with NMI, but support for that got scrapped in commit 1c29da02798d968eb874b86221333a56393a94c3 Author: Mark Johnston Date: Fri Jan 31 15:43:33 2020 +0000 Reimplement stack capture of running threads on i386 and amd64. >> I guess this email is to serve three purposes: >> >> 1. Report that a bug was introduced recently. >> 2. Ask for help in squashing the bug. I'm more than happy to test any >> patches. >> 3. Start a dialogue on making life just a little easier for >> downstreams. >> >> [0]: https://hardenedbsd.org/~shawn/2022-01-10_zfs_core-r01.txt > > -- Mateusz Guzik From nobody Tue Jan 11 00:10:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 755BA193026C for ; Tue, 11 Jan 2022 00:10:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXrgP2BH7z3M8B for ; Tue, 11 Jan 2022 00:10:25 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x829.google.com with SMTP id h4so5009111qth.11 for ; Mon, 10 Jan 2022 16:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pHUBAotWHB5SvHyVKIqg+mpc95LrWAxD/z2m0AQ3Q94=; b=LG292cRWzsF8HZQbwWGsaYco9ReyGTvT9mYka1c3aWVX2iltQ/wr4CGsxHzNae8ot/ oMTNSHxRKzFUx8WFooiBZGjq4tN/vAKuCtV458iPFVVTMPD9vMGAQe6ns7vTcqnBf1Mm S8QufcIwVMNuVDaxsIfUVRNKKImQXBJnFun8SLqAWMgck8RuMM9zzx33nV7zgVAIJ85c OX0umC07jOuebu9RuwOMrqSHzl45UCXEOFBbI0BFo9lGPKBo/zbRrHtoWd3BXH4AWeY9 j5fNddWnuxU+mr3+s5Cxi92o2we/5QsyUz5kRPKAT0Ue/sGFoTgZ3aar6bDWf+E/QWCm WTvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pHUBAotWHB5SvHyVKIqg+mpc95LrWAxD/z2m0AQ3Q94=; b=efeB1RXllyzmEnjRdF1qw9//THJLWFYipCIwZVmJLb39MK6bIpjH7kByC66P4dgqzq BKK8mNmyTUhV5IBbWe81Nd4UlrOw/RaACmphADFeQBA1uM2CvKNyM9UC8wrrXs8lQ/gt B2eNcIhVCEbjUuR+s8U1Juvc+GovIteg5cYCmC59IqQcGRL8yFN44cJpLmUbSnJn+LyL U9JsFyagV6VCR2mTatOOET00VzxoOmYYVZnwgbrofrzHqQbdrVNsNBzvH0x0PZbUtZ0l SPrYESmtrspzy6zs3HkguBgzty3ESVhFLjYs2ZnxCma6B6BqBQ72g5Uqr1sJnwGl23J9 Yyiw== X-Gm-Message-State: AOAM5324OLbQm6b2sMjD7YmmHVmOgcERV3CPQHqQ4IJLi8Uxatb4KT0x TcEYmQhmdx5mHqUBb2klOed1gA== X-Google-Smtp-Source: ABdhPJxGFdWGQjRz+4CBbfPcmOf0WIU2SO+SWxL/PBESS2PEYur0xcD7XdQo+Yi/ibFw+x4EJok09A== X-Received: by 2002:ac8:57d1:: with SMTP id w17mr1891847qta.453.1641859824745; Mon, 10 Jan 2022 16:10:24 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id u9sm5171762qkp.116.2022.01.10.16.10.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 16:10:24 -0800 (PST) Date: Mon, 10 Jan 2022 19:10:23 -0500 From: Shawn Webb To: Mateusz Guzik Cc: Mark Johnston , freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: <20220111001023.wx5nh64a5zqq7cae@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="um6yum3kqmcg5s5c" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JXrgP2BH7z3M8B X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --um6yum3kqmcg5s5c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2022 at 12:43:06AM +0100, Mateusz Guzik wrote: > On 1/11/22, Mark Johnston wrote: > > On Mon, Jan 10, 2022 at 05:11:16PM -0500, Shawn Webb wrote: > >> Hey all, > >> > >> So I'm getting an interesting ZFS-related kernel panic. I've uploaded > >> the core.txt at [0]. I suspect it's related to FreeBSD commit > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge > >> openzfs/zfs@f291fa658 (master) into main). > >> > >> I'm able to reproduce it on a single system with some level of > >> determinism: I'm building the security appliance firmware at ${DAYJOB} > >> in a bhyve VM that's backed by a zvol. The host is a Dell Precision > >> 7540 laptop with a single NVMe drive in it. The VM is configured with > >> a single zvol, booting with UEFI. > >> > >> Looking at the commit email sent to dev-commits-src-all@, I see this: > >> 146 files changed, 4933 insertions(+), 1572 deletions(-) > >> > >> Strangely, when I run `git show > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset > >> of those changes. > > > > That is a merge commit. You need to specify that you want a diff > > against the first parent (the preceding FreeBSD), so something > > equivalent to "git diff --stat 681ce946f^ 681ce946f". Use > > "git log 681ce946f^2" to see the merged OpenZFS commits. > > > >> As a downstream consumer of 14-CURRENT, how am I supposed to even > >> start debugging such a large patchset in any manner that respects my > >> time? > >> > >> It seems to me that breaking up commits into smaller, bite-size chunks > >> would make life easier for those experiencing bugs, especially ones > >> that result in kernel panics. > > > > That's up to the upstream project, in this case OpenZFS. > > > >> ZFS in and of itself is a beast, and I've yet to study any of its > >> code, so when there's a commit that large, even thinking about > >> debugging it is a daunting task. > >> > >> Needless to say, I'm going to need some hand holding here for > >> debugging this. Anyone have any idea what's going on? > > > > To start, you'll need to look at the stack trace for the thread with tid > > 100061. > > >=20 > imo the kernel should be patched to obtain the trace on its own. As > the target has interrupts disabled it will have to do it with NMI, but > support for that got scrapped in >=20 > commit 1c29da02798d968eb874b86221333a56393a94c3 > Author: Mark Johnston > Date: Fri Jan 31 15:43:33 2020 +0000 >=20 > Reimplement stack capture of running threads on i386 and amd64. I guess it's especially problematic for laptop systems where dropping to the db> prompt isn't an option (nvidia driver on this laptop). I'd have to scrap the entire notion of a GUI, which kinda defeats the purpose of using a laptop. Plugging in a USB memstick and setting debug.trace_on_panic=3D0 is the route I usually take on such systems. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --um6yum3kqmcg5s5c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmHcyu0ACgkQ/y5nonf4 4fqSXQ/+MXeioqkK8F9/nKElYxQg/JhM5FnlY/hhgqrxI1wzF+pYCTU6eyZUWMKK 0a8xC+ws+KMNmpZRQQfQiXTyaLoVP2xR5rMF5IYhX3/Q7CdC97gWuY1NV+AJtmBm I5UXhPBp+hoTxK9DNnzMtw7xDTCDTCDdNCxZikOtUxlrWuFdFqhku5cGE4psj3A/ dmaqSEc6bA34JKbSm/vnOZrF4fMZ7Mtd4d6BTFNNrumT0HT9VfvLykaxIDUz624W Z+3LuLwnN6yXeRwxMW+90MigYk7U38MIpxR8IzMHCPZS7vilMh5FzYcxXNvEP+wG WhnZUbSBZYfSeLsXdGHSB3akQ5Ro0Ev7badeFBUF1g0vVS3WJPMAF+pyTT04Jo6v UAQ6roDKzywQZ0k+1H7F8Tkx+4OJlluttx8WbIUSufpX459PQYs+V+ZQ3vh+tyLj G7UZsbgrmJAsTOhqyJ556L5Cra+lUbu1uGau0e+SOCwHINHU3NicGonV5dLdsX6W QPt9DpK86rnJfIIPmAfuh210jcm8hr9BsGVj3zm8obfNCg5UROiqMSG0Kr6XssS7 SYmc9cjFfYooxyHN1rokw1tMVllf2q19ZgF5z5LGUdnlOaKjHBwMCYNW798xUzC2 xGjWwqUT0JU5Om7LlH1ilik0cbvByaEQwZg9zeHRRefB3Zk4GeU= =y22k -----END PGP SIGNATURE----- --um6yum3kqmcg5s5c-- From nobody Tue Jan 11 00:11:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 217F31930B93 for ; Tue, 11 Jan 2022 00:11:13 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXrhH6scNz3MYl for ; Tue, 11 Jan 2022 00:11:11 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x835.google.com with SMTP id l17so16849049qtk.7 for ; Mon, 10 Jan 2022 16:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yP5ZT4O0Gl16LsjKLYpSqOxTdOROxGVKkGdJ77dsglA=; b=Z8q0LuTVKd62SeR5SIT90Vu65i+fEW7+xXIBLvLK/h3Hj7S6yMQRmqOg47I7izEnzO 2g/MaV3DOfmJUsXpmoHXxoCjecpnGjr5ifrEAmUY2L2FWZk0Ddb1aSoqD2sXqW+3CVtP 6mdRQPOYj/ANeB63smUmbBJj2OO6q3aPEiCgbwlj4HLzmHq0vFlccqJ5n+LMOJH8webd hqsnkvY83H5yPu9EKTckDKa0sfKnoQHzOYwzjdkwaXhv/ezTf170kv13mucKMTs3IHjU 1wmC4za4SmFQcGikGLETPNUBLqLH9oCcP2U9+poM6uHimJhY87PEx21KZzWdlDfrzBJU uaEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=yP5ZT4O0Gl16LsjKLYpSqOxTdOROxGVKkGdJ77dsglA=; b=dax0C1VCbJRfW5VRFR/JppeHKZm+NrzYs6qlH+BuLR+KEFvx+lu/M4ndlOQVnD673P MLfB1ScyOg+EizXigfi8TqfhSAIY4k59eQAyibtoVieB7ITikY4NHW3JWCn95nHfP68H FlPF2p6iArIlo1obZlB20Nim0MS/CywXo4Zez454U/h/e8pj5y5fXxKLW/PR2RWkh8Pv JYv8FtAKt//tmUeijYUvxThk4wIo2UX9jYkc+TURI5eJUrI871J1kiJ5kObejecjiVfq QgTyLMKhXviKcnsz9HotMvxV11Dmw+7xNPUnUKT89w0hlqOeG7gy2f+oIstb/e3BN0xF Ry1Q== X-Gm-Message-State: AOAM530KRppWJvvJaLcTBOENfvz/x4pZitsNH5oEDRvj9+gcvXEQvHD6 ODC3uiyLWrZjDBUbeoEqf7Jsqw== X-Google-Smtp-Source: ABdhPJwJspFcC/62T8713fMM8Jj6zyR/y1XMEwwrUVhBpnRgJTzdDlFKkwsMiWaJGCICyWhgELkNow== X-Received: by 2002:a05:622a:178e:: with SMTP id s14mr256590qtk.688.1641859871388; Mon, 10 Jan 2022 16:11:11 -0800 (PST) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id y17sm2855629qtw.1.2022.01.10.16.11.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 16:11:10 -0800 (PST) Date: Mon, 10 Jan 2022 19:11:10 -0500 From: Shawn Webb To: Mateusz Guzik Cc: Mark Johnston , freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: <20220111001110.medkloif6zghtatg@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> <20220111001023.wx5nh64a5zqq7cae@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vbzw4udfy3tf73no" Content-Disposition: inline In-Reply-To: <20220111001023.wx5nh64a5zqq7cae@mutt-hbsd> X-Rspamd-Queue-Id: 4JXrhH6scNz3MYl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Z8q0LuTV; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.59)[-0.587]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; SUBJECT_HAS_QUESTION(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --vbzw4udfy3tf73no Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 10, 2022 at 07:10:23PM -0500, Shawn Webb wrote: > On Tue, Jan 11, 2022 at 12:43:06AM +0100, Mateusz Guzik wrote: > > On 1/11/22, Mark Johnston wrote: > > > On Mon, Jan 10, 2022 at 05:11:16PM -0500, Shawn Webb wrote: > > >> Hey all, > > >> > > >> So I'm getting an interesting ZFS-related kernel panic. I've uploaded > > >> the core.txt at [0]. I suspect it's related to FreeBSD commit > > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge > > >> openzfs/zfs@f291fa658 (master) into main). > > >> > > >> I'm able to reproduce it on a single system with some level of > > >> determinism: I'm building the security appliance firmware at ${DAYJO= B} > > >> in a bhyve VM that's backed by a zvol. The host is a Dell Precision > > >> 7540 laptop with a single NVMe drive in it. The VM is configured with > > >> a single zvol, booting with UEFI. > > >> > > >> Looking at the commit email sent to dev-commits-src-all@, I see this: > > >> 146 files changed, 4933 insertions(+), 1572 deletions(-) > > >> > > >> Strangely, when I run `git show > > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset > > >> of those changes. > > > > > > That is a merge commit. You need to specify that you want a diff > > > against the first parent (the preceding FreeBSD), so something > > > equivalent to "git diff --stat 681ce946f^ 681ce946f". Use > > > "git log 681ce946f^2" to see the merged OpenZFS commits. > > > > > >> As a downstream consumer of 14-CURRENT, how am I supposed to even > > >> start debugging such a large patchset in any manner that respects my > > >> time? > > >> > > >> It seems to me that breaking up commits into smaller, bite-size chun= ks > > >> would make life easier for those experiencing bugs, especially ones > > >> that result in kernel panics. > > > > > > That's up to the upstream project, in this case OpenZFS. > > > > > >> ZFS in and of itself is a beast, and I've yet to study any of its > > >> code, so when there's a commit that large, even thinking about > > >> debugging it is a daunting task. > > >> > > >> Needless to say, I'm going to need some hand holding here for > > >> debugging this. Anyone have any idea what's going on? > > > > > > To start, you'll need to look at the stack trace for the thread with = tid > > > 100061. > > > > >=20 > > imo the kernel should be patched to obtain the trace on its own. As > > the target has interrupts disabled it will have to do it with NMI, but > > support for that got scrapped in > >=20 > > commit 1c29da02798d968eb874b86221333a56393a94c3 > > Author: Mark Johnston > > Date: Fri Jan 31 15:43:33 2020 +0000 > >=20 > > Reimplement stack capture of running threads on i386 and amd64. >=20 > I guess it's especially problematic for laptop systems where dropping > to the db> prompt isn't an option (nvidia driver on this laptop). I'd > have to scrap the entire notion of a GUI, which kinda defeats the > purpose of using a laptop. >=20 > Plugging in a USB memstick and setting debug.trace_on_panic=3D0 is the > route I usually take on such systems. Sorry, wrong sysctl node. I meant to reference debug.debugger_on_panic. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --vbzw4udfy3tf73no Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmHcyx4ACgkQ/y5nonf4 4fpWrw/+IdLPNu9IUlQaq/iXCbhIP4+oCYA/k3KyhjDW6HL77Il2G4dwMbJ+UVGU QEhBAmPi8Ba3JKzxxy6GQwMff2gkC2ieWCltb3VEdzUvx38inyxzjxRCJ76oljTF CpoFvnRKGsl4yGOwJnhgtCogH1fkB6r2N5CTQ23axTYqops6bAt0SAPkdcXMih8B furpjFJElYBm8VUp1RQ53DbTcTALH6wxWqFYjX/yvlAcxQAPJLPmBy2H7WNXN6uX /ynpTleQW5xzY0emL2aB7J2dnw6fCzqC4Rorj6Qw0ipw8fd+3/JNdQbpPlIWwBlp RSdBbsi2MJvay+jFkX3IEW/eKZWBHHwHGHo1sbgDCc4FKWft6PyPooraVMMjMjhN BhxM8XyRWCMgdXbQHq5K4WLvqdZxmcPBTalBshPmLPNnL5CcifPqVQrH6xaO/JNP 0IiV6ilbUXJIDb5sIeT7tSiGyV0Jo8Bhoh+lVc6LPygqHYW6ujcayELTpTY/JrNJ q/AikJ2TiYLV+qBa1VfflGF2y2T0v0itEapN1QzNuA6HKbvABOljd/v5wR6hkHkG rRQHA2UtjVgVfnqiSo5wT1vTD7eagy/rfgwNUQ92OGJcFXRdlT6mTP3CUbRTH3pz zT+wXcjISqZzdkTHcMOZu2O8isLfPRcQY9T5vyIg3Iz/QEBh3eM= =274Z -----END PGP SIGNATURE----- --vbzw4udfy3tf73no-- From nobody Tue Jan 11 02:50:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 85DA8193D3FF for ; Tue, 11 Jan 2022 02:50:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXwDX3BlLz4ZDF for ; Tue, 11 Jan 2022 02:50:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id c19so59220qtx.3 for ; Mon, 10 Jan 2022 18:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RzibzEmS7euaQACVVoMzLL8s5aOtix9+BTlfFF8yVbU=; b=bxOF40L/qcl6D2rhIAzl497jVzEmM6kcnxeGOb2X3zo5pHfxqCWG9To8oAnr9IFeyO qc4B+/0XsZh2JnQO7+m9M305IiKf4quSgA4S7Kvl36p6gGxBuEVNIBVUykurOfrT2fM6 o8/oO6Pyw3VCsukeulODBEUpHx/u1oyneVK6HFssVMpXYqdRXofbSrbts0ADkuVWXQeD A8U+g6TENd8PS/YFWHKnFgVHTnj37uHWRTBvpUpNL22IKSDYMnvcT8nR5VRSSMvSOb+F JOXAH8VIVSR1RpDLDWGQd0uNIIOOf0RGVsaJHfSxMOU/A5kHCnvc90Q85JCmfK2Hmnor YLKg== 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=RzibzEmS7euaQACVVoMzLL8s5aOtix9+BTlfFF8yVbU=; b=61FHMGMaOaBLFQDT7C6GvJlhWK7Zj51uYHaDwCV+yjISheW4l8IjGfd8SyFjMb7aFm TMJ9aLrpWjytMiP13gFS4Fdf2yLTA2oi287eoTPF4MgEYhq4RjpOuUNzhVKn5z/ZCy8w e1lLopbSk9gZ83PDCr9uXGhaD/S5GU1hl1W+/H+aShkqcOh+OtaYTsJQWQt9uXDW+LuN z6V0Y54FtdA+tZdnMaQp3uxEoxhvPNopF6n2I+aEcgya4C4CbuGr5iOEFAqXqLT6NgWr iPZD/NClwAxJhEC8liBuELuU6tAn6L3mC6P5hRedeXkRELU0KUS4XACpQx0B9y3WEObQ vC6Q== X-Gm-Message-State: AOAM5334Pafn1DzO0ykkGFJZwpBau71SLyJDXDKMpabZgK/A8QRH1Vj6 d2PqvVCbJ9KJ8iu1zSSHK79DHkwxx/o= X-Google-Smtp-Source: ABdhPJyz67FLcfl5u+gAOjsc26ngGwnHd2QA61QYF5FJPainvRcA/AAle3FOa5vfNONlB3j3QqthFw== X-Received: by 2002:a05:622a:5d2:: with SMTP id d18mr2233368qtb.154.1641869445762; Mon, 10 Jan 2022 18:50:45 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id r20sm6214820qkp.21.2022.01.10.18.50.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 18:50:44 -0800 (PST) Date: Mon, 10 Jan 2022 21:50:42 -0500 From: Mark Johnston To: Mateusz Guzik Cc: Shawn Webb , freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4JXwDX3BlLz4ZDF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 11, 2022 at 12:43:06AM +0100, Mateusz Guzik wrote: > On 1/11/22, Mark Johnston wrote: > > On Mon, Jan 10, 2022 at 05:11:16PM -0500, Shawn Webb wrote: > >> Hey all, > >> > >> So I'm getting an interesting ZFS-related kernel panic. I've uploaded > >> the core.txt at [0]. I suspect it's related to FreeBSD commit > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a (zfs: merge > >> openzfs/zfs@f291fa658 (master) into main). > >> > >> I'm able to reproduce it on a single system with some level of > >> determinism: I'm building the security appliance firmware at ${DAYJOB} > >> in a bhyve VM that's backed by a zvol. The host is a Dell Precision > >> 7540 laptop with a single NVMe drive in it. The VM is configured with > >> a single zvol, booting with UEFI. > >> > >> Looking at the commit email sent to dev-commits-src-all@, I see this: > >> 146 files changed, 4933 insertions(+), 1572 deletions(-) > >> > >> Strangely, when I run `git show > >> 681ce946f33e75c590e97c53076e86dff1fe8f4a`, I only see a small subset > >> of those changes. > > > > That is a merge commit. You need to specify that you want a diff > > against the first parent (the preceding FreeBSD), so something > > equivalent to "git diff --stat 681ce946f^ 681ce946f". Use > > "git log 681ce946f^2" to see the merged OpenZFS commits. > > > >> As a downstream consumer of 14-CURRENT, how am I supposed to even > >> start debugging such a large patchset in any manner that respects my > >> time? > >> > >> It seems to me that breaking up commits into smaller, bite-size chunks > >> would make life easier for those experiencing bugs, especially ones > >> that result in kernel panics. > > > > That's up to the upstream project, in this case OpenZFS. > > > >> ZFS in and of itself is a beast, and I've yet to study any of its > >> code, so when there's a commit that large, even thinking about > >> debugging it is a daunting task. > >> > >> Needless to say, I'm going to need some hand holding here for > >> debugging this. Anyone have any idea what's going on? > > > > To start, you'll need to look at the stack trace for the thread with tid > > 100061. > > > > imo the kernel should be patched to obtain the trace on its own. As > the target has interrupts disabled it will have to do it with NMI, but > support for that got scrapped in > > commit 1c29da02798d968eb874b86221333a56393a94c3 > Author: Mark Johnston > Date: Fri Jan 31 15:43:33 2020 +0000 > > Reimplement stack capture of running threads on i386 and amd64. More general and useful, to me at least, is having "acttrace" output available in core.txt. So I propose https://reviews.freebsd.org/D33817 I don't think the NMI-based stack(9) machinery to capture stacks is really very useful here anyway. We already raise NMIs on all CPUs during a panic, so just reuse that and add some handler which can call kdb_backtrace() on the target CPU in ipi_nmi_handler(). From nobody Tue Jan 11 07:28:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 219AD1930A2F for ; Tue, 11 Jan 2022 07:28:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JY2Nv0Xmvz3l77; Tue, 11 Jan 2022 07:28:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641886111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FdZfQo3ngx/hA4yS21aYQ3cd8xnUTGPunJwJHvbX9R8=; b=P9xG/ObL6kvrMDEqXX58wuCDWkGXHWqT2mIPO0GcSDODsdukVZDedJS/d0LE212NyxKLTR 8um+j461/MeWFF5m8Eb+k5/0J3X3AqFndJDngtvL25PXewyNQcQOm2DWJ3Va86ffyGZbP9 iAEnOL+vEAJJE1PKeEkfFcwoDp19znsN70t0wWJxrtLAq0l7W2aiNdWkxsaHgbPIAMvY9L e1a0QWXnPljpT3i4tKXfwMwpNKCJKcYDSJ35y7LHeRGelfr9pqxadbRwPV5UFVcwY3MA7m T/P2ZxxZx2jyIO8gNlZOBj6zxeM16Lf4LOjBwJbrWvmy3M1tC0zLyaIh5FJoIQ== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 6FD001E39; Tue, 11 Jan 2022 07:28:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <1bf39343-c9b2-353c-63e7-8604adc9d391@FreeBSD.org> Date: Tue, 11 Jan 2022 09:28:27 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Content-Language: en-US To: Mateusz Guzik , Mark Johnston Cc: freebsd-hackers@freebsd.org References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641886111; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FdZfQo3ngx/hA4yS21aYQ3cd8xnUTGPunJwJHvbX9R8=; b=NweP1lztloNqQE75HHy+FIyqUK6PL2Ff87eOc3ZKpgytUXgXUszeUs8Du7cwHUdBtcBs38 3sDJ8eeC/lHPRK5XqV63HmMpTQXE8Vhz23ZEjE5DX0+8jsGAtyVCszam0lNKQj/84r3s6G xo3PUZHiLQ5IMDwP/Stbk7FGxczz1/CShDHxEt/ZS2/fLNMzhNN5uxtX+gQ0NGn8srKXZS 5K9nPDGKPSPE7MLRQFkNfOnelzfCmk00lAmn3z2cC0wn21mX3ot/KYHSk/enS1NxaPU/Av 3Y+/gx9U5U/HqECU4xNZgBveo+eBJt4Q3JZfEr3y5J6HS1D+dpduBziNtNQggw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641886111; a=rsa-sha256; cv=none; b=elKR2YD15oDdN0Kx5mt9GQOmnEgOEGjM5Wr77xfLO7erpdAIafrT2oRfyvN2fhFX8rrtRr 9b9+K2dsCFiNba0jO/QOlGOyMTkEc+p+rVxK99Y89TN9b9qE+92rfMqLSpXznf5ab0G9af ohBZrrmmORpGiGKYSOSvgb02m+Kmky2iwztR1jsCeHTxuJqfKfivQtCAB1dkc43X5hzBps uWkLgTW3iQOyOdrFfGm09tEB7wYQTKCNk3bRKmwNX8Au/ytjBOPZZmfMHvj1YPD6vTcPfk Z2c8PiIMIFWOEDFK20hh4iMLABgxAz4CKJXtsiqqBAMFi578n8YHV0+LS4uXPg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/01/2022 01:43, Mateusz Guzik wrote: > imo the kernel should be patched to obtain the trace on its own. As > the target has interrupts disabled it will have to do it with NMI, but > support for that got scrapped in > > commit 1c29da02798d968eb874b86221333a56393a94c3 > Author: Mark Johnston > Date: Fri Jan 31 15:43:33 2020 +0000 > > Reimplement stack capture of running threads on i386 and amd64. This is an off-topic for the thread, but as far as I recall, even when the stack capture (e.g., for procstat -k) was implemented using NMI there was a piece of code in the corresponding NMI handler that skipped the stack tracing if interrupts were disabled. I don't recall / know why. You can see that in the removed stack_nmi_handler() that used to be in sys/x86/x86/stack_machdep.c. -- Andriy Gapon From nobody Tue Jan 11 14:16:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E3B821944E28 for ; Tue, 11 Jan 2022 14:16:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYCS25gzbz4dy5; Tue, 11 Jan 2022 14:16:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82a.google.com with SMTP id s19so18620569qtc.5; Tue, 11 Jan 2022 06:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6KCuWwDoW6FJ3yNfXJMAvbJ+iWwLT7FX+X+SahCwGD0=; b=MQ6FHaNWwi+imL0DHBzAXW561YUQbQEDUDio5J01CriCyT/tiqmlL25qBQbCIjSRNk A+1JBvQQNA/C/XR2+/Tju+V0KTHwUHdhQayrZCQu0k6tLUJrltVRKgiy04nH5KAeUkbM B4OL4i5F5klCzif2YClv1QQa9stv/kkhgkfr2Af46FmtDoH3HFi7RPtQ6QLQYG0dyYb+ UxP97MKBNaj6pkN+5DikjbOtgeKaHFqii9zHFDba+TXfqU+/2L4m0nW1pahvqD9Suphq vKshd31vz22/E85sZ0akOpMsd7dyhXIiyYXv5WxvhEYAOR+n2yLsFmRXOlijJGFNAWDx fOUQ== 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=6KCuWwDoW6FJ3yNfXJMAvbJ+iWwLT7FX+X+SahCwGD0=; b=L/IP0CqkcfZdz7rNIuAr5W/vdLuf540iMYRd3uRewhPjrLJp0kArsFSYI/CSPRIWkN pQ0JpHVbR29TnamlqpJuPS5KPFb9Kz9DAo0YOtpgwYL57BMCIK+DS3aKZHcIj5Q22u2U Q3mCaIMB7t5WZoCcg1aPi8YSnf6TlpcIydCq+oCDtjzrg+eoEi/+0khAacRYc+3yyLwd uXdNqHn/j3p1xHM+LIO8TnUc22M70UJ45hbzkHJLznd4lxwB4HfaTpeR3VWmO2fJRipI aCBk4HqiI/i7VTnq0mWl+EoIyElawvfuoWSvIsjLe2u0Kow1QnBztn48zYzhuS/hQjRo AiEA== X-Gm-Message-State: AOAM533G6LRHwNgAPx0MwGl2N5Dv9VIlTGLcZxRqlZ+/ATwn6RiQTBEk J3Xp9Na4OYLaIQPb9hyuNHM2j8SqfIU= X-Google-Smtp-Source: ABdhPJyPEa+rG9Ovd0P4Sx2zZpOuLJR/cRi/1ktS+WUCFH8QlUmAEcPFW2tF3wvSsggJlNPRlOSjmA== X-Received: by 2002:a05:622a:120b:: with SMTP id y11mr3729766qtx.11.1641910609857; Tue, 11 Jan 2022 06:16:49 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id de39sm6367502qkb.5.2022.01.11.06.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jan 2022 06:16:49 -0800 (PST) Date: Tue, 11 Jan 2022 09:16:46 -0500 From: Mark Johnston To: Andriy Gapon Cc: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> <1bf39343-c9b2-353c-63e7-8604adc9d391@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1bf39343-c9b2-353c-63e7-8604adc9d391@FreeBSD.org> X-Rspamd-Queue-Id: 4JYCS25gzbz4dy5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 11, 2022 at 09:28:27AM +0200, Andriy Gapon wrote: > On 11/01/2022 01:43, Mateusz Guzik wrote: > > imo the kernel should be patched to obtain the trace on its own. As > > the target has interrupts disabled it will have to do it with NMI, but > > support for that got scrapped in > > > > commit 1c29da02798d968eb874b86221333a56393a94c3 > > Author: Mark Johnston > > Date: Fri Jan 31 15:43:33 2020 +0000 > > > > Reimplement stack capture of running threads on i386 and amd64. > > This is an off-topic for the thread, but as far as I recall, even when the stack > capture (e.g., for procstat -k) was implemented using NMI there was a piece of > code in the corresponding NMI handler that skipped the stack tracing if > interrupts were disabled. I don't recall / know why. > You can see that in the removed stack_nmi_handler() that used to be in > sys/x86/x86/stack_machdep.c. I think it may have been to avoid tracing threads in the middle of a context switch, but I can't remember exactly which inconsistencies were problematic. From nobody Tue Jan 11 14:38:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C3A59194C5C6 for ; Tue, 11 Jan 2022 14:38:47 +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 4JYCxM3cbCz4m0y; Tue, 11 Jan 2022 14:38:47 +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 20BEcepT083353 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 11 Jan 2022 16:38:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 20BEcepT083353 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 20BEcesk083352; Tue, 11 Jan 2022 16:38:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Jan 2022 16:38:40 +0200 From: Konstantin Belousov To: Mark Johnston Cc: Andriy Gapon , Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: Debugging a (potentially?) ZFS-related panic, and discussion about large patchsets Message-ID: References: <20220110221116.gustgfgfge6pb5fe@mutt-hbsd> <1bf39343-c9b2-353c-63e7-8604adc9d391@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4JYCxM3cbCz4m0y X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 11, 2022 at 09:16:46AM -0500, Mark Johnston wrote: > On Tue, Jan 11, 2022 at 09:28:27AM +0200, Andriy Gapon wrote: > > On 11/01/2022 01:43, Mateusz Guzik wrote: > > > imo the kernel should be patched to obtain the trace on its own. As > > > the target has interrupts disabled it will have to do it with NMI, but > > > support for that got scrapped in > > > > > > commit 1c29da02798d968eb874b86221333a56393a94c3 > > > Author: Mark Johnston > > > Date: Fri Jan 31 15:43:33 2020 +0000 > > > > > > Reimplement stack capture of running threads on i386 and amd64. > > > > This is an off-topic for the thread, but as far as I recall, even when the stack > > capture (e.g., for procstat -k) was implemented using NMI there was a piece of > > code in the corresponding NMI handler that skipped the stack tracing if > > interrupts were disabled. I don't recall / know why. > > You can see that in the removed stack_nmi_handler() that used to be in > > sys/x86/x86/stack_machdep.c. > > I think it may have been to avoid tracing threads in the middle of a > context switch, but I can't remember exactly which inconsistencies were > problematic. Thread stack can become unmapped any moment it went off cpu. You do not know which place in the context switch code was interrupted. From nobody Wed Jan 12 03:21:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F0029195C081 for ; Wed, 12 Jan 2022 03:21:33 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYXsT6T09z4hkp; Wed, 12 Jan 2022 03:21:33 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641957693; h=from:from:reply-to:subject:subject:date:date: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=jMz88YHsRS42Sq8z96qcrDhgz8lv9Psa92Gr+dAc8Ec=; b=EcdVN4P57wMSXY+vmB4ZF76R/q4+QtIllA+egoX1pu+59bu50o1ZgKEh/JCeBeP/xMP82Y Fl9lOLHXZWB7FSG859kfwcxiwoYyalOocdapP+QK7e+xaq/gZPznKQZ+e9JBFGgoM9fR6i k1tnLIYGIjmrsE2XnTnfpbog9EXyYU5q+8hAqg06qMyAy1aLr+jtk4Jh0WRZwhAcc187SV ySHIjOxckXuKNuqY+RPthBMu/ZzxNaevfZG2ffuZEoOVuShl8tDumHfFmNvf5qqz9+HfJy PG6BIE3SfVQ7OGE4E5zubJtre10DD0c5JbYLCDPiIgw8hSHLfdIGF+Qqmy4eCg== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id D10F9BC1F; Wed, 12 Jan 2022 03:21:32 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Wed, 12 Jan 2022 14:21:25 +1100 From: Peter Jeremy To: ralph41096 Cc: "freebsd-hackers@freebsd.org" Subject: Re: Out-of-swap killer and SIGTERM signal Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YQZS0K7jK4RUas+L" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641957693; h=from:from:reply-to:subject:subject:date:date: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=jMz88YHsRS42Sq8z96qcrDhgz8lv9Psa92Gr+dAc8Ec=; b=CYwQ2A+n0tlZw+Q0lvfVe6shN0sAWl8EQpXhdjhkfW9lYZ0sxfLBJcDYAa17eZHBAXjhxD oPAykdbA21uKorX4k4YRL+KRKeu5gx9vMHRkkChYQDvZp97gh/nvoBAjWDH0nbew5zQRrs K4xLte4tTU8AEaQqUFbo6S6xzoMFQvG9PeW+qNe5e5ZfUFrVO/GfpmrT5fFfJNoBbKRZiz lrZRpG0pF8WdE6qsH9s9uduQ/SA4rANJGSUZf1lXhTcFykateIXIQ4/Zqz/nllpDYPiWWP pXlxUsqvOc1x6/lZSO57FaJtfoU0LX8qIcTLw6DMd6+jMclqqj/K/h0y0B9lVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641957693; a=rsa-sha256; cv=none; b=Cxu6PnxLsD6tJjuwCmt1ZXSqF1UBC4yaUNHCsU8fyYJ6kOOQsw0vn9fL/1hyXjeoOvaBOW SYqLKucRt9AUz2+3hZCLqNxsjeXB6Eco8Z5/icvUfoLlInDZYdwMYsCZio2j2jUFy/dTgl hpsLTcu17KZcTNnQ3v2Msrb/XfDsGiwHIDj+X5OnKrBSg0Z4hm60tHmmkQ9H438aJUEN9A 1HY7DWnCS031psuyR+ZWmrcf49t6Au36Eepz15lnHCuTInDsSM9CQBfzDI5UKYiqvdNynD 3RbvnRQZbtpMeJkDKiYkrkYmo+3MTQDdpsmTwR2jwi+uU1pdlmWiD+ZnzTi/QA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --YQZS0K7jK4RUas+L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Jan-10 12:55:56 +0000, ralph41096 wrote: >Do you think it would be a good idea to introduce the following soft >mode for the Out-of-swap killer? There have been lots of discussions about this in the past, starting in about 1998, (though I agree that it's been about 4 years since the last discussion). I suggest you search for "freebsd+sigdanger" for previous discussions. >New behaviour: > 1) If there is less than 2 GiB of free swap space, send SIGTERM > signals to the condemned processes, then wait for a 5 seconds > grace period, then send SIGKILL signals to the condemned processes > who are still running. 2 GiB seems quite a high limit, especially with a 5s grace period. That implies the system is using swap at 410 MiB/s - which seems unrealistic. It also means that you need to overprovision swap by 2 GiB since the last 2 GiB is effectively unusable. >These two system-wide parameters (2 GiB of free swap space, 5 seconds >grace period) could be defined in a configuration file, to allow the >administrator to change them. The FreeBSD model would be to make them sysctls. --=20 Peter Jeremy --YQZS0K7jK4RUas+L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmHeSTBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzSPkw//V6FrV9st3G2djUBqxbDAccdq3wJNZXdfLerDsMhpBQB693SUoDPszEsE NDQTTDKl9pT6HMaZlyO70gIRQE/KIouxAr3u+N9bvPm9Fh/kg2z+r/15HhGV2mTy Pjik+4WaXmqaBA7PaWvRNc2U7b6mS32jlO9Z/qpHLU3nBbIf+0MU+XhN1hrDO8sm qoTqVFNudPkhNHvjcwKphhHCvKAuyqE0LaRYhUZCv+ARiQrs2TaZKwOkFeyY48yM Ei1i4LQt8XZ/VJ38gXvh2pj8nILQut7hw8Wofo4T3PZnaSNKXqx/vS19CL33gZrq geX4lr5aHKV5J966gpbgM8/suz8Y6cwgaRCqRNGMfUsf3M9xdg0CeTA4ZzW9NEXz qrdBEPXfUT+RfR6Q+SBmeWP4nL/luHDRx6M09GJerYd8hGF2igacf5ZJfdHY7VO/ iHSSK0qaV6moYlyaXb1IYjwIBFSw2qDTWlO8lu1p8qbk0ycTxrQIiWEyTvom41+P 2f5jeEegDJrKRWUqnOBMQJbUW6bmjny2Dl2nAYvgSsd0keB0Pw5RgJaTO81CN5Pf DfGlMEvivX2tdI0kRPaoLKFSWnSwxDiAibfT3RQVBrW9XJgzmePK6Gspb7IXbPYE x2m+GbXbDtIDdgYSvoU0KAJKiU9wGR+utr+UVrkzapPA3jlX5HY= =CN8Y -----END PGP SIGNATURE----- --YQZS0K7jK4RUas+L-- From nobody Wed Jan 12 21:42:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B21401940E4D for ; Wed, 12 Jan 2022 21:42:27 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZ1Hl32p4z4ttF for ; Wed, 12 Jan 2022 21:42:27 +0000 (UTC) (envelope-from ralph41096@protonmail.com) Date: Wed, 12 Jan 2022 21:42:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1642023739; bh=mj5NF5u02UhjoRgfauPojzz8EkmGnlUHehypWqBPKlU=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=bpjOgSxJV0bRe8L8FjEmF+Er3tLjGPMJO+KlWra1Cf0hoH2ZZMaRMaOcTtH8OgrQQ 1nORzd/c3H2+K4rldNooVBzCyvd2MOp5USFctapJDZexzGg0vMAztw8WNrqTghvyUW QEKioc9dyUzJa+M2vvkfqeaYhvvWUg24kLKD1N8sigVDcm4NelVvAqSwX4Hrwfo5/q UeAbAruRvbSO3uqvwq4LBIzNCRaURQTxeSIPOdx1/mkOilGM6MUGRtdSIR4sqXkT+9 So8DgG2Ww1NB3IpMUdymBM6Qm0xURvvx50xC22NFLUvIShYTkowY7zBVw7sQz8hoRx AUBN8+QS7mjwg== To: Peter Jeremy From: Ambert Cc: "freebsd-hackers@freebsd.org" Reply-To: Ambert Subject: Re: Out-of-swap killer and SIGTERM signal Message-ID: In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.7 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4JZ1Hl32p4z4ttF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-01-12, Peter Jeremy wrote: > There have been lots of discussions about this in the past, starting > in about 1998, (though I agree that it's been about 4 years since the > last discussion). I suggest you search for "freebsd+sigdanger" for > previous discussions. Thank you for the keyword. After a search, I find that the previous threads containing the keyword "sigdanger" discuss extensively two subjects: 1) How to exclude a process from the reach of the OOM killer. And how to ask the OOM killer to kill a given process first. 2) How to provide feedback about memory usage to processes, to give them a hint that they should reduce their memory footprint, if possible. This feedback can be a signal sent to all processes, or system-wide flags readable by any process who cares about a potential memory shortage. Those two subjects are interesting, but I am talking about something else. My suggestion is almost never mentionned in previous threads. When it is mentionned [1] [2], there is no objection whatsoever, from anyone. There is not even a comment about it. Sending SIGTERM a few seconds before SIGKILL is useful because it allows a condemned process to exit gracefully, just like it would during a shutdown(8). And it is simple to implement. There is no need to change the algorithm selecting condemned processes, and there is no need to change a single line of code in userland. For the administrator, only two tasks require extra work: - set up a little bit of extra swap during the installation of FreeBSD - set a couple of sysctl values: the duration of the grace period (vm.grace_period =3D zero milliseconds by default), and the amount of extra swap that will not be usable normally (vm.grace_space =3D zero bytes by default) Excerpt from a historical thread: On 1998-04-27, Jordan K. Hubbard wrote: > All the SIGDANGER (Will Robinson) signal is meant to do is give a > process a little _warning_ before it's chosen as the designated > sacrifice for the evening and terminated in an untimely fashion. > > I don't think the question here is "is this a good idea" - it's a > perfectly reasonable idea and one which has been proposed before. > The question here is really "what are the proposed semantics of > this mechanism?", e.g. how long do you wait from the time you > SIGDANGER the process and actually shoot it down, and what > happens if you're also critically short of resources and don't > have much time to wait? [1] https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D209768+0+archive/1998/freeb= sd-hackers/19980426.freebsd-hackers [2] https://lists.freebsd.org/pipermail/freebsd-current/2008-January/081743.htm= l Ambert From nobody Thu Jan 13 08:12:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A284F19428A1 for ; Thu, 13 Jan 2022 08:12:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JZHGq42NCz3JSh for ; Thu, 13 Jan 2022 08:12:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642061555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NBnH4AGcPt4xGmTLfiTCJqVVSdrwtP8eUWj6HWkkEeI=; b=B4ERl4XF4D+A01n94C5nPwst2+tBSlKMa6htYuder7zkawh6DOkfDGHKl2tHJNa+FfKkYy 3ft4e794Ri3gMbZgCpj22URmYWVhl9v5DK2elUIGSSySuKJkXhDzmi68mByC4YZNDdRFIC eVLKT/pYXnCWaI7DLsCIlG9HcBil/AfVA/DAfj9K/IfwWLz+KYQMrKlq5mUmGjsA1bPRdC q9LlMk3FQhwCPk9S3pYaLVCcujQaJHbPScXhHPe/j5MgSM2h1zrDtbGrUoMSLbwQWC49oR T0dieC79TXV3B22sFbGvzUMuTJSc1sLIUMq2z7W5RvPQajiNyYGHaZAixXRbUQ== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 33517299D3 for ; Thu, 13 Jan 2022 08:12:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <54e5f61c-64fd-0ebf-c3cd-d4a7a4cbb7e7@FreeBSD.org> Date: Thu, 13 Jan 2022 10:12:31 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Subject: Re: IO-APIC interrupt delivery mode on Ryzen Content-Language: en-US From: Andriy Gapon To: FreeBSD Hackers References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642061555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NBnH4AGcPt4xGmTLfiTCJqVVSdrwtP8eUWj6HWkkEeI=; b=Y0ZixbdkhuyyVqVA3INiT3GdcLZj8tGSTSXVgaFM8Y0VR3I7dHehU3eLDf7buqm8HxxXoo CpZi7LXit76Q3Qc6r4cvFO0TsdZPUoCNyn0ssMDCyLX02lpyeazV0jXj7l6aIvW02FpxAU 60opFTLXeW1CY3h0O/4nPauCc+k4fZgDQvxHngNzdiAtgqIuzzgEG6CJFgVQx+SXY45GQQ JbqDy3SMWOOArE1lM85qhEQuMkwxSosXeCy2N8bL/agUVnfdIt/iyx8+V7xVe+63bVFEQW 67C4/4hKDJS4OBPbwFBOhfClgCtsB4fsTpD4RqhhZdCYA/iKWvSVvCO/CAO2xA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642061555; a=rsa-sha256; cv=none; b=hVdPUk9w8iiGser6b1RDZoiBGpoxD/pZSaJuRYusY8AV5xbaZ2X3JzfpdDIoSjvaJ/B9zB ttk4KGXp8ToiuA8sZ47YjjLfOhlI2IEO56i3c7PxMgCPLzz0HUoQnrnj6TmjJroPGh2rVO yUXukJV3k+1sXywIwwQewgSomCT/23UCD3/ejpTi1rPqKo3OH2ePnW2ZYGtNEGZmcSbrQ+ Sm30CGe6jXpQs/3kUYEM/r7VLVnrBE6EVbKgzhShNmN7OGJJYRL1trFLxl+KIPFIMq1LQa rDZi3hHXouDjLLx/cidvK0QRw4TJky9zAM1snjbcbRA94Pvds/T/snGcJ3ySjQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 14/02/2018 09:16, Andriy Gapon wrote: > > A while ago I discovered that all AMD IO-APICs (in separate southbridges and in > FCHs) had a bug with respect to how the interrupt delivery mode got interpreted. > I am curious if the problem has been fixed in Ryzen or if it is being carried on. > > I would appreciate any help with testing that. > > The discussion of the problem and the tests I used can be found in this thread: > https://mail.coreboot.org/pipermail/coreboot/2016-October/082148.html > https://mail.coreboot.org/pipermail/coreboot/2016-October/082156.html > > If you are interested and it's not really clear how to conduct a test, please > write me. FWIW, Ryzen IO-APICs do not have the problem. They interpret the delivery mode according to the APIC specification, not the HyperTransport one. -- Andriy Gapon From nobody Sat Jan 15 00:07:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9E9131953D17; Sat, 15 Jan 2022 00:07:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbJQN1jFNz3t8x; Sat, 15 Jan 2022 00:07:39 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-48-130-181.area1b.commufa.jp [123.48.130.181]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 20F07UjA071482; Sat, 15 Jan 2022 09:07:31 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 15 Jan 2022 09:07:30 +0900 From: Tomoaki AOKI To: freebsd-stable@freebsd.org Cc: "Gerard E. Seibert" , FreeBSD Hackers Subject: Re: Intel + Thunderbolt Driver Message-Id: <20220115090730.22f0013604e6c32134c88cc3@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JbJQN1jFNz3t8x X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.48.130.181:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-stable]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FREEMAIL_CC(0.00)[outlook.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 14 Jan 2022 14:39:27 -0500 "Gerard E. Seibert" wrote: > I was just wondering if anyone had heard or knows when FreeBSD will be > able to support Intel's "Thunderbolt" technology? The lack of a driver > that works for FreeBSD has made it impossible for me to update my > system beyond version 11.4. > > https://en.wikipedia.org/wiki/Thunderbolt_(interface) CC'ing -hackers ML, as -stable ML wouldn't fit for this. For anyone on -hackers ML: Related topic is in progress (very very slowly) on [1] below. (Gerard and I are already on it.) You may feel it's unrelated reading the title, but actually it is caused by the behaviour of Intel ThunderBolt controller. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 > > -- > Jerry > > "Eagles may soar, but weasels don't get sucked into jet engines." > -- Tomoaki AOKI From nobody Sat Jan 15 03:01:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 07D0B1950AF4 for ; Sat, 15 Jan 2022 03:01:46 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4JbNHF2GKHz4bWc for ; Sat, 15 Jan 2022 03:01:45 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 1A0CA4C063C for ; Fri, 14 Jan 2022 21:01:45 -0600 (CST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 15 Jan 2022 03:01:44 +0000 From: Pau Amma To: freebsd-hackers@freebsd.org Subject: Suggestions for moving PR 248368 forward? In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.8 Message-ID: <37d4d559ca295c68f474ab40838eab3a@gundo.com> X-Sender: pauamma@gundo.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JbNHF2GKHz4bWc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N (Please cc: me in replies as I only subscribed to the list to ask this and may have to unsubscribe if it proves overwhelming.) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248368 has been gathering dust for close to 1.5 year now and I'm trying to help moving it closer to resolution, because the VirtualBox part at least affects me. One thing I think would be good is for one or more people able to look closely at host and guest kernel behavior and at VirtualBox behavior to determine which contribute to that part of the symptoms. If someone can come up with hard evidence pointing to one of the above, maybe knowing where the problem may lie will help pinpointing it. Figuring out the bare-metal part of the problem would be good too, but it's clearer that only FreeBSD (and maybe some of the computer's firmware) is a possible cause. advTHANKSance. From nobody Mon Jan 17 12:41:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 425D5196DBE5 for ; Mon, 17 Jan 2022 12:42:04 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Received: from mail-4022.proton.ch (mail-4022.proton.ch [185.70.40.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jcs3v2FX5z3s4n for ; Mon, 17 Jan 2022 12:42:03 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Date: Mon, 17 Jan 2022 12:41:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmcyk.xyz; s=protonmail; t=1642423320; bh=0DgQzKbAC4QHW5Tiw6uQLK9oopRkWZKKzrDxvMbKIbE=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc; b=dg54/EZfhaSHuaPowTndivthnvfqoGu+OtXxIQM3u6rbaS6Gk4WrzYElvjK5r2Mgt Pmcka3MZAhMZmDAwmvl2yVqzzDl07awo6I+r3scUrj3CZWYZ/L4xRjnPA3jHFgq8rA YIUuCudxqlA+AFdopnXA++M+EqJY6wxchPWER814= To: "freebsd-hackers@freebsd.org" From: Damian Malarczyk Reply-To: Damian Malarczyk Subject: amd64 syscall ABI (vs. Darwin) Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_Uiz8x1vyUY7OgZROZNN73Ts1dBgCmuR97PcpMC4cM" X-Spam-Status: No, score=2.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD, FROM_SUSPICIOUS_NTLD_FP,HTML_MESSAGE,PDS_OTHER_BAD_TLD shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Jcs3v2FX5z3s4n X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dmcyk.xyz header.s=protonmail header.b="dg54/EZf"; dmarc=none; spf=pass (mx1.freebsd.org: domain of damian@dmcyk.xyz designates 185.70.40.22 as permitted sender) smtp.mailfrom=damian@dmcyk.xyz X-Spamd-Result: default: False [-2.40 / 15.00]; HAS_REPLYTO(0.00)[damian@dmcyk.xyz]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[dmcyk.xyz:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.40.22:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_PHPMAILER_SIG(0.00)[]; DMARC_NA(0.00)[dmcyk.xyz]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[dmcyk.xyz:+]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_Uiz8x1vyUY7OgZROZNN73Ts1dBgCmuR97PcpMC4cM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGVsbG8sCgpJJ20gaGFja2luZyBvbiBhIHRveSBwcm9qZWN0IHRvIHJ1biBEYXJ3aW4gKE1hY2hP KSBiaW5hcmllcyBvbiBGcmVlQlNELgpDdXJyZW50bHkgSSdtIGF0IGEgc3RhZ2Ugb2Ygc3lzY2Fs bHMgc3VwcG9ydCwgYW5kIEkndmUgbm90aWNlZCBhIGRpZmZlcmVuY2UgaW4gdGhlIGFtZDY0IEFC SSB0aGF0IEkgZGlkbid0IGV4cGVjdC4KCkZyZWVCU0QgaXMgY2hhbmdpbmcgdmFsdWVzIG9mIHNv bWUgcmVnaXN0ZXJzIHRoYXQgYXJlbid0IHVzZWQgYXMgdGhlIHN5c2NhbGwgb3V0cHV0LiBlLmcu LCByOC1yMTEgYXJlIGNoYW5nZWQsIHdoaWxlIHIxMi1yMTUgZG9uJ3Qgc2VlbSB0byBiZSBhZmZl Y3RlZC4KVGhhdCdzIG5vdCB0aGUgY2FzZSBvbiBEYXJ3aW4sIGZyb20gd2hhdCBJJ3ZlIHNlZW4g b25seXJheCwgcmR4IHVzZWQgYXMgc3lzY2FsbCByZXN1bHRzIGFyZSBjaGFuZ2VkLgpJdCBsb29r cyBsaWtlIEZyZWVCU0QncyBzeXNjYWxscyBjYWxsaW5nIGNvbnZlbnRpb24gaXMgbW9yZSBsaWtl IHN0YW5kYXJkIGZ1bmN0aW9uIGNhbGxpbmcsIGFuZCByOC1yMTEgc2hvdWxkIGJlIGFsd2F5cyBj YWxsZXIgc2F2ZWQuCgpBdCBhIGZpcnN0IGdsYW5jZSBEYXJ3aW4gYXBwcm9hY2ggc2VlbXMgbW9y ZSBvcHRpbWFsLCBhcyBsZXNzIHJlZ2lzdGVycyBnZXQgY2xvYmJlcmVkLiBJcyB0aGVyZSBhbnkg c3BlY2lmaWMgcmVhc29uIHdoeSB0aGlzIGlzbid0IGFsc28gdGhlIGNhc2Ugb24gRnJlZUJTRD8K SSdtIGFsc28gd29uZGVyaW5nIHdoZXJlIGV4YWN0bHkgdGhlIHJlZ2lzdGVyIHZhbHVlcyBhcmUg Y2hhbmdlZC4gV2hlbiBJIGxvb2sgYXQgdGhldHJhcGZyYW1lIGNvbnRlbnRzIGluIHRoZSBzdl9z ZXRfc3lzY2FsbF9yZXR2YWxzeXN0ZW0gdmVjdG9yIGNhbGxiYWNrIHRoZSByOCByZWdpc3RlciB2 YWx1ZSBpcyBzYW1lIGFzIG9uIHRoZSBpbnB1dCwgc28gaXQgbXVzdCBiZSBjaGFuZ2VkIHNvbWV3 aGVyZSBsYXRlci4gRG9lcyBhbnlvbmUga25vdyB3aGVyZSBleGFjdGx5IHRoaXMgaGFwcGVucz8K ClRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgdGlwcy4KCkhlcmUncmUgdGhlIHByb2dyYW1zIEkg dXNlZCB0byB0ZXN0IHRoaXMgYmVoYXZpb3VyOgotIFtGcmVlQlNEXShodHRwczovL2dpc3QuZ2l0 aHViLmNvbS9kbWN5ay8xMWMyOWIyZDVlNWQzZTA0ZTViOTU0ZTQzZTEyZDM4NCkKLSBbbWFjT1Nd KGh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2RtY3lrL2VkMWM2ZmNjZWQ3ODg0NGM4ZTJlNGEwZmIz ZDE4MzkxKQoKV2hlbiB5b3UgcnVuIHRoZSBtYWNPUyB2ZXJzaW9uIGl0IHdpbCB3cml0ZSB0d2lj ZSB0aGUgbnVtYmVyIG9mIGFyZ3VtZW50cyB0byBzdGRvdXQsIEZyZWVCU0Qgd2lsbCB3cml0ZSB0 aGUgbnVtYmVyIG9ubHkgb25jZSBmb2xsb3dlZCBieSBhIDAsIGJlY2F1c2UgcjggZ290IG92ZXJ3 cml0dGVuLgoKUC5TLiBJJ20gcmVsYXRpdmVseSBuZXcgdG8gRnJlZUJTRCwgYW5kIGZpcnN0IHRp bWUgd3JpdGluZyBoZXJlIG9uIHRoZSBtYWlsaW5nIGxpc3Qgc28gaGVsbG8gZXZlcnlvbmUgOiku CgotIERhbWlhbg== --b1_Uiz8x1vyUY7OgZROZNN73Ts1dBgCmuR97PcpMC4cM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5IZWxsbyw8 YnI+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9 ImxpbmUtaGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNp emUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVj b3JhdGlvbjogbm9uZTsiPkknbSBoYWNraW5nIG9uIGEgdG95IHByb2plY3QgdG8gcnVuIERhcndp biAoTWFjaE8pIGJpbmFyaWVzIG9uIEZyZWVCU0QuPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUt aGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiPkN1cnJlbnRseSBJJ20gYXQgYSBzdGFnZSBvZiBzeXNjYWxscyBzdXBwb3J0LCBh bmQgSSd2ZSBub3RpY2VkIGEgZGlmZmVyZW5jZSBpbiB0aGUgYW1kNjQgQUJJIHRoYXQgSSBkaWRu J3QgZXhwZWN0Ljxicj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyBjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog YXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48YnI+PC9kaXY+ PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAw KTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+RnJlZUJTRCBpcyBjaGFuZ2luZyB2YWx1ZXMgb2Yg c29tZSByZWdpc3RlcnMgdGhhdCBhcmVuJ3QgdXNlZCBhcyB0aGUgc3lzY2FsbCBvdXRwdXQuIGUu Zy4sIHI4LXIxMSBhcmUgY2hhbmdlZCwgd2hpbGUgcjEyLXIxNSBkb24ndCBzZWVtIHRvIGJlIGFm ZmVjdGVkLjxicj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyBjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJp YWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5UaGF0J3Mgbm90IHRo ZSBjYXNlIG9uIERhcndpbiwgZnJvbSB3aGF0IEkndmUgc2VlbiBvbmx5PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxpIHN0eWxlPSJsaW5lLWhlaWdodDog bm9ybWFsOyI+cmF4LCByZHgmbmJzcDs8L2k+dXNlZCBhcyBzeXNjYWxsIHJlc3VsdHMgYXJlIGNo YW5nZWQuPGJyPjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlh bDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPkl0IGxvb2tzIGxpa2Ug RnJlZUJTRCdzIHN5c2NhbGxzIGNhbGxpbmcgY29udmVudGlvbiBpcyBtb3JlIGxpa2Ugc3RhbmRh cmQgZnVuY3Rpb24gY2FsbGluZywgYW5kIHI4LXIxMSBzaG91bGQgYmUgYWx3YXlzIGNhbGxlciBz YXZlZC48YnI+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFs OyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2PjxkaXYg c3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsiPkF0IGEgZmlyc3QgZ2xhbmNlIERhcndpbiBhcHByb2FjaCBz ZWVtcyBtb3JlIG9wdGltYWwsIGFzIGxlc3MgcmVnaXN0ZXJzIGdldCBjbG9iYmVyZWQuIElzIHRo ZXJlIGFueSBzcGVjaWZpYyByZWFzb24gd2h5IHRoaXMgaXNuJ3QgYWxzbyB0aGUgY2FzZSBvbiBG cmVlQlNEPzxicj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyBjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJp YWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5JJ20gYWxzbyB3b25k ZXJpbmcgd2hlcmUgZXhhY3RseSB0aGUgcmVnaXN0ZXIgdmFsdWVzIGFyZSBjaGFuZ2VkLiBXaGVu IEkgbG9vayBhdCB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGkgc3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7Ij50cmFwZnJhbWU8L2k+Jm5ic3A7 Y29udGVudHMgaW4gdGhlJm5ic3A7PGkgc3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7Ij5zdl9z ZXRfc3lzY2FsbF9yZXR2YWw8L2k+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPnN5c3RlbSB2ZWN0b3IgY2FsbGJhY2sgdGhlIDxpPnI4PC9pPiByZWdpc3Rl ciB2YWx1ZSBpcyBzYW1lIGFzIG9uIHRoZSBpbnB1dCwgc28gaXQgbXVzdCBiZSBjaGFuZ2VkIHNv bWV3aGVyZSBsYXRlci4gRG9lcyBhbnlvbmUga25vdyB3aGVyZSBleGFjdGx5IHRoaXMgaGFwcGVu cz88YnI+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6 IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBm b250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiPlRoYW5rcyBpbiBhZHZhbmNlIGZvciBhbnkgdGlwcy48YnI+PC9k aXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJnYigwLCAw LCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUt aGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogbm9ybWFsOyBjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog YXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5IZXJlJ3JlIHRo ZSBwcm9ncmFtcyBJIHVzZWQgdG8gdGVzdCB0aGlzIGJlaGF2aW91cjo8YnI+PC9kaXY+PGRpdiBz dHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyI+LSA8YSBocmVmPSJodHRwczovL2dpc3QuZ2l0aHViLmNvbS9k bWN5ay8xMWMyOWIyZDVlNWQzZTA0ZTViOTU0ZTQzZTEyZDM4NCIgdGFyZ2V0PSJfYmxhbmsiIHRp dGxlPSJodHRwczovL2dpc3QuZ2l0aHViLmNvbS9kbWN5ay8xMWMyOWIyZDVlNWQzZTA0ZTViOTU0 ZTQzZTEyZDM4NCIgcmVsPSJub2ZvbGxvdyI+RnJlZUJTRDwvYT48YnI+PC9kaXY+PGRpdiBzdHls ZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyI+LSA8YSByZWw9Im5vb3BlbmVyIG5vcmVmZXJyZXIiIHRpdGxlPSJo dHRwczovL2dpc3QuZ2l0aHViLmNvbS9kbWN5ay9lZDFjNmZjY2VkNzg4NDRjOGUyZTRhMGZiM2Qx ODM5MSIgdGFyZ2V0PSJfYmxhbmsiIGhyZWY9Imh0dHBzOi8vZ2lzdC5naXRodWIuY29tL2RtY3lr L2VkMWM2ZmNjZWQ3ODg0NGM4ZTJlNGEwZmIzZDE4MzkxIj5tYWNPUzwvYT48YnI+PC9kaXY+PGRp diBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0 OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiPldoZW4geW91IHJ1biB0aGUgbWFjT1MgdmVyc2lvbiBpdCB3aWwgd3JpdGUgdHdpY2UgdGhl IG51bWJlciBvZiBhcmd1bWVudHMgdG8gc3Rkb3V0LCBGcmVlQlNEIHdpbGwgd3JpdGUgdGhlIG51 bWJlciBvbmx5IG9uY2UgZm9sbG93ZWQgYnkgYSAwLCBiZWNhdXNlIHI4IGdvdCBvdmVyd3JpdHRl bi4mbmJzcDs8YnI+PC9kaXY+PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsgY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IGFy aWFsOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGJyPjwvZGl2Pjxk aXYgc3R5bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPlAuUy4gSSdtIHJlbGF0aXZlbHkgbmV3IHRvIEZyZWVC U0QsIGFuZCBmaXJzdCB0aW1lIHdyaXRpbmcgaGVyZSBvbiB0aGUgbWFpbGluZyBsaXN0IHNvIGhl bGxvIGV2ZXJ5b25lIDopLiZuYnNwOzxicj48L2Rpdj48ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDog bm9ybWFsOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 Ij48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siIHN0eWxl PSJsaW5lLWhlaWdodDogbm9ybWFsOyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7Ij48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11 c2VyIiBzdHlsZT0ibGluZS1oZWlnaHQ6IG5vcm1hbDsiPjxkaXYgc3R5bGU9ImxpbmUtaGVpZ2h0 OiBub3JtYWw7Ij4tIERhbWlhbjxicj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxkaXYgY2xhc3M9InByb3Rvbm1haWxf c2lnbmF0dXJlX2Jsb2NrIiBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBmb250LXNpemU6IDE0 cHg7Ij48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90b24gcHJvdG9u bWFpbF9zaWduYXR1cmVfYmxvY2stZW1wdHkiPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+PGJyPjwvZGl2Pg== --b1_Uiz8x1vyUY7OgZROZNN73Ts1dBgCmuR97PcpMC4cM-- From nobody Mon Jan 17 13:04:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 43BBE19539A9 for ; Mon, 17 Jan 2022 13:04:41 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JcsZ01wBlz4VjW for ; Mon, 17 Jan 2022 13:04:40 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id 30so65350594edv.3 for ; Mon, 17 Jan 2022 05:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=fYgIPMoQ5FJn9T55sANicdVyo/y1LTkE6QBrnrItpQM=; b=Zkfx2LFnlBfHQfLJDyI2oIctIM0XozW0KeFpfq/sTkIl9qOFB2MDWxYdyvNiubARbw evxhN8FQn4tHMMeTlYvFKc07Hww8IblUWI6h0Eediuh5aphrgNUss/830+bn2i/Jalel sgwDcpsj58t/jH12qlJQogLZ0P5uCP3GfM5krgX06ONiUPMDiLoA01UbVlEGniCAmtfY UhN/QPkRnlDXcUBuO5iG0Jcum4ye6i9vXtKRMmjHo94H+nnoMe9t9mrtXDvcQuNA835I hhGdaOYYnOHwgbjP2ar/qt5/W3rNCblVJIXH445C2Zvh6mL/EsA0jqYA4b1MubRMsMOo XRMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=fYgIPMoQ5FJn9T55sANicdVyo/y1LTkE6QBrnrItpQM=; b=lw5sK55olWneH61q278fjS4ceVcUsYesG0gIljG/Uhh5XsxQQqNFOTeX2wJKX4sG+g aPqxFBOZsMN5OoJJgH74QAbBuTo9/onNnINPdy8vsTV5RTs8A7s+QmpH/KOxste/cDIG Ea2J0KPCtQy2udFNILTDGlaiia6AuLgtt4Fwg8igBLLnLDTmDD9oSGTcWRILs94k4bWu nt8O95xyqE+Ziqtk52ZQCiRerofSCdlMdk3S25iQ0UKOqnFJ+lsVlOdXpD5c6BwyDNuz re2PGMEtE2qOYPWrtTIJfDf6ynsF9a99lTOUcsKiRQNbqEXv1CLqOFoGW3uGQz6BYUNf z6SA== X-Gm-Message-State: AOAM533/wkI/uMfISoE9/1DB1x3z0b6PwWQmDGwwe0PvXKRBKs9A2FBt uFIoT/n7n9nGcGkVPKNmRaw6pU3dcuQ= X-Google-Smtp-Source: ABdhPJxSr9ElWyr9b7yVAZda5W594gUwwWQG86z/0zIxJlRTfg0DOAtu1HRLtXsYl15lIB6UQLbiog== X-Received: by 2002:a50:c04c:: with SMTP id u12mr20228018edd.107.1642424679264; Mon, 17 Jan 2022 05:04:39 -0800 (PST) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id ky3sm4472346ejc.178.2022.01.17.05.04.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Jan 2022 05:04:38 -0800 (PST) Date: Mon, 17 Jan 2022 14:04:37 +0100 From: Gary Jennejohn To: Damian Malarczyk Cc: "freebsd-hackers@freebsd.org" Subject: Re: amd64 syscall ABI (vs. Darwin) Message-ID: <20220117140437.13663e70@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JcsZ01wBlz4VjW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Zkfx2LFn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-1.98 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.98)[0.977]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 17 Jan 2022 12:41:59 +0000 Damian Malarczyk wrote: > Hello, > > I'm hacking on a toy project to run Darwin (MachO) binaries on FreeBSD. > Currently I'm at a stage of syscalls support, and I've noticed a difference in the amd64 ABI that I didn't expect. > > FreeBSD is changing values of some registers that aren't used as the syscall output. e.g., r8-r11 are changed, while r12-r15 don't seem to be affected. > That's not the case on Darwin, from what I've seen onlyrax, rdx used as syscall results are changed. > It looks like FreeBSD's syscalls calling convention is more like standard function calling, and r8-r11 should be always caller saved. > > At a first glance Darwin approach seems more optimal, as less registers get clobbered. Is there any specific reason why this isn't also the case on FreeBSD? > I'm also wondering where exactly the register values are changed. When I look at thetrapframe contents in the sv_set_syscall_retvalsystem vector callback the r8 register value is same as on the input, so it must be changed somewhere later. Does anyone know where exactly this happens? > > Thanks in advance for any tips. > This happens in the tree in various assembler files. The primary use of these registers appears to be for holding temporary data. Try running this in /usr/src: find -type f -name "*.S" -print0 | xargs -0 grep -e r8 -e r9 -e r10 -e r11 \ --mmap -l $1 > Here're the programs I used to test this behaviour: > - [FreeBSD](https://gist.github.com/dmcyk/11c29b2d5e5d3e04e5b954e43e12d384) > - [macOS](https://gist.github.com/dmcyk/ed1c6fcced78844c8e2e4a0fb3d18391) > > When you run the macOS version it wil write twice the number of arguments to stdout, FreeBSD will write the number only once followed by a 0, because r8 got overwritten. > > P.S. I'm relatively new to FreeBSD, and first time writing here on the mailing list so hello everyone :). > > - Damian -- Gary Jennejohn From nobody Mon Jan 17 13:38:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4A80B196C4C3 for ; Mon, 17 Jan 2022 13:39:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JctKc6QVQz4mxb for ; Mon, 17 Jan 2022 13:39:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 20HDcbYJ073055 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 17 Jan 2022 15:38:40 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 20HDcbvU073054; Mon, 17 Jan 2022 15:38:37 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 17 Jan 2022 15:38:37 +0200 From: Konstantin Belousov To: Damian Malarczyk Cc: "freebsd-hackers@freebsd.org" Subject: Re: amd64 syscall ABI (vs. Darwin) Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4JctKc6QVQz4mxb X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [3.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 17, 2022 at 12:41:59PM +0000, Damian Malarczyk wrote: > Hello, > > I'm hacking on a toy project to run Darwin (MachO) binaries on FreeBSD. > Currently I'm at a stage of syscalls support, and I've noticed a difference in the amd64 ABI that I didn't expect. > > FreeBSD is changing values of some registers that aren't used as the syscall output. e.g., r8-r11 are changed, while r12-r15 don't seem to be affected. > That's not the case on Darwin, from what I've seen onlyrax, rdx used as syscall results are changed. > It looks like FreeBSD's syscalls calling convention is more like standard function calling, and r8-r11 should be always caller saved. It is not 'more like'. FreeBSD follows C ABI for amd64 for syscall registers handling. An additional twist is that the registers which are declared as calleee-clobered are zeroed to avoid kernel data leakage to userspace. > > At a first glance Darwin approach seems more optimal, as less registers get clobbered. Is there any specific reason why this isn't also the case on FreeBSD? > I'm also wondering where exactly the register values are changed. When I look at thetrapframe contents in the sv_set_syscall_retvalsystem vector callback the r8 register value is same as on the input, so it must be changed somewhere later. Does anyone know where exactly this happens? Look at the sys/amd64/amd64/exceptions.S. The fast_syscall entry point is where we receive control after the syscall instruction. > > Thanks in advance for any tips. > > Here're the programs I used to test this behaviour: > - [FreeBSD](https://gist.github.com/dmcyk/11c29b2d5e5d3e04e5b954e43e12d384) > - [macOS](https://gist.github.com/dmcyk/ed1c6fcced78844c8e2e4a0fb3d18391) > > When you run the macOS version it wil write twice the number of arguments to stdout, FreeBSD will write the number only once followed by a 0, because r8 got overwritten. > > P.S. I'm relatively new to FreeBSD, and first time writing here on the mailing list so hello everyone :). > > - Damian From nobody Mon Jan 17 22:31:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A1D81964FE5 for ; Mon, 17 Jan 2022 22:31:20 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jd67q3DrXz4b58 for ; Mon, 17 Jan 2022 22:31:19 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Date: Mon, 17 Jan 2022 22:31:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmcyk.xyz; s=protonmail; t=1642458676; bh=1nsMQRyhSbCOMotn2ZmIrIQo/jyBV7SQbbFH52weeC4=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=A1ZdIr0ncEVJ9sPbcSlae42M58ale8UUXc2wFOxOVuquPUUL4ZGwveo29bNbWODt0 bCj8/d/2+SzhGtQZRmv7NdtxK2d1EYwTw/s7V6115Rx2rNocfxcmyFpo5uDIV/17a+ o7IzZ7xeIBlb38HrDr7uRgO7R6sq2Jrr6BXGcYFc= To: Konstantin Belousov From: Damian's Proton Mail Cc: "freebsd-hackers@freebsd.org" Reply-To: Damian's Proton Mail Subject: Re: amd64 syscall ABI (vs. Darwin) Message-ID: <94B30813-0034-4F90-9AAC-113402A1A3E8@dmcyk.xyz> In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.3 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD, PDS_OTHER_BAD_TLD shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Jd67q3DrXz4b58 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dmcyk.xyz header.s=protonmail header.b=A1ZdIr0n; dmarc=none; spf=pass (mx1.freebsd.org: domain of damian@dmcyk.xyz designates 185.70.43.23 as permitted sender) smtp.mailfrom=damian@dmcyk.xyz X-Spamd-Result: default: False [-1.03 / 15.00]; HAS_REPLYTO(0.00)[damian@dmcyk.xyz]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[dmcyk.xyz:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.43.23:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dmcyk.xyz]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dmcyk.xyz:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-0.53)[-0.529]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17 Jan 2022, at 14:38, Konstantin Belousov wrote= : > > On Mon, Jan 17, 2022 at 12:41:59PM +0000, Damian Malarczyk wrote: >> Hello, >> >> I'm hacking on a toy project to run Darwin (MachO) binaries on FreeBSD. >> Currently I'm at a stage of syscalls support, and I've noticed a differe= nce in the amd64 ABI that I didn't expect. >> >> FreeBSD is changing values of some registers that aren't used as the sys= call output. e.g., r8-r11 are changed, while r12-r15 don't seem to be affec= ted. >> That's not the case on Darwin, from what I've seen onlyrax, rdx used as = syscall results are changed. >> It looks like FreeBSD's syscalls calling convention is more like standar= d function calling, and r8-r11 should be always caller saved. > It is not 'more like'. FreeBSD follows C ABI for amd64 for syscall > registers handling. An additional twist is that the registers which are > declared as calleee-clobered are zeroed to avoid kernel data leakage to > userspace. Oh I see, this explains it then. >> >> At a first glance Darwin approach seems more optimal, as less registers = get clobbered. Is there any specific reason why this isn't also the case on= FreeBSD? >> I'm also wondering where exactly the register values are changed. When I= look at thetrapframe contents in the sv_set_syscall_retvalsystem vector ca= llback the r8 register value is same as on the input, so it must be changed= somewhere later. Does anyone know where exactly this happens? > > Look at the sys/amd64/amd64/exceptions.S. The fast_syscall entry point > is where we receive control after the syscall instruction. A lot of new things in there for me, but the flow is clear. I was able to f= ind corresponding logic in XNU=E2=80=99s sources too. Earlier I said: > At a first glance Darwin approach seems more optimal But it=E2=80=99s instead the opposite/no difference at all, as in Darwin, t= hey explicitly restore/set all registers, including callee saved r12-r15. Explicitly preserving registers would prevent kernel data leakage too. Doin= g so in FreeBSD would also be an ABI compatible change I think, since users= shouldn=E2=80=99t rely on values in those registers. I=E2=80=99m curious if you see any obvious pros/cons with either approach, = or is it just a more arbitrary implementation choice? Not that I=E2=80=99d propose changing the ABI though, I also want my toy pr= oject to work as a plug-in kernel module. I guess the only other option to emulate Darwin's behaviour would be to int= ercept syscalls in userspace somehow first and manually preserve the regist= er values? From nobody Mon Jan 17 22:51:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6996D19730AF for ; Mon, 17 Jan 2022 22:52:08 +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 4Jd6bq3sDMz4l6F for ; Mon, 17 Jan 2022 22:52:07 +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 20HMpqno011824 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 18 Jan 2022 00:51:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 20HMpq43011823; Tue, 18 Jan 2022 00:51:52 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Jan 2022 00:51:52 +0200 From: Konstantin Belousov To: "Damian's Proton Mail" Cc: "freebsd-hackers@freebsd.org" Subject: Re: amd64 syscall ABI (vs. Darwin) Message-ID: References: <94B30813-0034-4F90-9AAC-113402A1A3E8@dmcyk.xyz> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94B30813-0034-4F90-9AAC-113402A1A3E8@dmcyk.xyz> 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: 4Jd6bq3sDMz4l6F X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [3.00 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 17, 2022 at 10:31:09PM +0000, Damian's Proton Mail wrote: > > > On 17 Jan 2022, at 14:38, Konstantin Belousov wrote: > > > > On Mon, Jan 17, 2022 at 12:41:59PM +0000, Damian Malarczyk wrote: > >> Hello, > >> > >> I'm hacking on a toy project to run Darwin (MachO) binaries on FreeBSD. > >> Currently I'm at a stage of syscalls support, and I've noticed a difference in the amd64 ABI that I didn't expect. > >> > >> FreeBSD is changing values of some registers that aren't used as the syscall output. e.g., r8-r11 are changed, while r12-r15 don't seem to be affected. > >> That's not the case on Darwin, from what I've seen onlyrax, rdx used as syscall results are changed. > >> It looks like FreeBSD's syscalls calling convention is more like standard function calling, and r8-r11 should be always caller saved. > > It is not 'more like'. FreeBSD follows C ABI for amd64 for syscall > > registers handling. An additional twist is that the registers which are > > declared as calleee-clobered are zeroed to avoid kernel data leakage to > > userspace. > Oh I see, this explains it then. > > >> > >> At a first glance Darwin approach seems more optimal, as less registers get clobbered. Is there any specific reason why this isn't also the case on FreeBSD? > >> I'm also wondering where exactly the register values are changed. When I look at thetrapframe contents in the sv_set_syscall_retvalsystem vector callback the r8 register value is same as on the input, so it must be changed somewhere later. Does anyone know where exactly this happens? > > > > Look at the sys/amd64/amd64/exceptions.S. The fast_syscall entry point > > is where we receive control after the syscall instruction. > A lot of new things in there for me, but the flow is clear. I was able to find corresponding logic in XNU’s sources too. Earlier I said: > > > At a first glance Darwin approach seems more optimal > But it’s instead the opposite/no difference at all, as in Darwin, they explicitly restore/set all registers, including callee saved r12-r15. > > Explicitly preserving registers would prevent kernel data leakage too. Doing so in FreeBSD would also be an ABI compatible change I think, since users shouldn’t rely on values in those registers. > I’m curious if you see any obvious pros/cons with either approach, or is it just a more arbitrary implementation choice? We preserve everything on syscall entry, it is the SYSCALL instruction behavior that makes it look somewhat convoluted. I suggest you to read the SDM description of the SYSCALL instruction to understand the registers manipulations on entry. On the other hand, on the fast syscall return, we indeed not restore everything. If you want to restore full frame, use PCB_FULL_IRET pcb flag to request iretq return path. > > Not that I’d propose changing the ABI though, I also want my toy project to work as a plug-in kernel module. > I guess the only other option to emulate Darwin's behaviour would be to intercept syscalls in userspace somehow first and manually preserve the register values? To emulate Darwin, you would need specific ABI personality (sysent) in the kernel, which would also provide sv_syscall_ret method. The method can do whatever is needed to the return frame, and set PCB_FULL_IRET to indicate that kernel should load it into CPU GPR file as is. BTW, does Darwin use SYSCALL instruction for syscall entry on amd64? From nobody Mon Jan 17 23:14:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2C4BD195136E for ; Mon, 17 Jan 2022 23:15:07 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jd76K67M2z4t8D for ; Mon, 17 Jan 2022 23:15:05 +0000 (UTC) (envelope-from damian@dmcyk.xyz) Date: Mon, 17 Jan 2022 23:14:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmcyk.xyz; s=protonmail; t=1642461303; bh=3ZU9607iQ3qrc3Hi/ymcgFECibYQWGLVlBWxsFmBie0=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc; b=C9wGFhCa1mRBzV7zdP3J/viXJqSueZQwGhV7BBhSsk4ysAkCGApHPVe6HVf1IWr1E AmvylOItdA4BU5ZYKRB+IBfjml31uz2L5HnzKNqGtrZl2a675T1X27R047RRMS00WJ AqTWLPGj3RgrreE68Y9tWnDMf+k+0HJ3/tBX1nKI= To: Konstantin Belousov From: Damian's Proton Mail Cc: "freebsd-hackers@freebsd.org" Reply-To: Damian's Proton Mail Subject: Re: amd64 syscall ABI (vs. Darwin) Message-ID: <4979A00A-9678-4BAC-881D-71F7533D93F9@dmcyk.xyz> In-Reply-To: References: <94B30813-0034-4F90-9AAC-113402A1A3E8@dmcyk.xyz> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_GMNvESbFpfujOROAvMxN9zwVE2WEQnIpv572aFPvPcw" X-Spam-Status: No, score=1.3 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD, HTML_MESSAGE,PDS_OTHER_BAD_TLD shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4Jd76K67M2z4t8D X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dmcyk.xyz header.s=protonmail header.b=C9wGFhCa; dmarc=none; spf=pass (mx1.freebsd.org: domain of damian@dmcyk.xyz designates 185.70.43.23 as permitted sender) smtp.mailfrom=damian@dmcyk.xyz X-Spamd-Result: default: False [-1.39 / 15.00]; HAS_REPLYTO(0.00)[damian@dmcyk.xyz]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[185.70.43.23:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; DKIM_TRACE(0.00)[dmcyk.xyz:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.993]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dmcyk.xyz:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_PHPMAILER_SIG(0.00)[]; DMARC_NA(0.00)[dmcyk.xyz]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_GMNvESbFpfujOROAvMxN9zwVE2WEQnIpv572aFPvPcw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 PiBPbiAxNyBKYW4gMjAyMiwgYXQgMjM6NTEsIEtvbnN0YW50aW4gQmVsb3Vzb3YgPGtvc3Rpa2Jl bEBnbWFpbC5jb20+IHdyb3RlOgo+Cj4gT24gTW9uLCBKYW4gMTcsIDIwMjIgYXQgMTA6MzE6MDlQ TSArMDAwMCwgRGFtaWFuJ3MgUHJvdG9uIE1haWwgd3JvdGU6Cj4KPj4+IE9uIDE3IEphbiAyMDIy LCBhdCAxNDozOCwgS29uc3RhbnRpbiBCZWxvdXNvdiA8a29zdGlrYmVsQGdtYWlsLmNvbT4gd3Jv dGU6Cj4+Cj4+PiBMb29rIGF0IHRoZSBzeXMvYW1kNjQvYW1kNjQvZXhjZXB0aW9ucy5TLiBUaGUg ZmFzdF9zeXNjYWxsIGVudHJ5IHBvaW50Cj4+PiBpcyB3aGVyZSB3ZSByZWNlaXZlIGNvbnRyb2wg YWZ0ZXIgdGhlIHN5c2NhbGwgaW5zdHJ1Y3Rpb24uCj4+Cj4+IEEgbG90IG9mIG5ldyB0aGluZ3Mg aW4gdGhlcmUgZm9yIG1lLCBidXQgdGhlIGZsb3cgaXMgY2xlYXIuIEkgd2FzIGFibGUgdG8gZmlu ZCBjb3JyZXNwb25kaW5nIGxvZ2ljIGluIFhOVeKAmXMgc291cmNlcyB0b28uIEVhcmxpZXIgSSBz YWlkOgo+Pgo+Pj4gQXQgYSBmaXJzdCBnbGFuY2UgRGFyd2luIGFwcHJvYWNoIHNlZW1zIG1vcmUg b3B0aW1hbAo+Pgo+PiBCdXQgaXTigJlzIGluc3RlYWQgdGhlIG9wcG9zaXRlL25vIGRpZmZlcmVu Y2UgYXQgYWxsLCBhcyBpbiBEYXJ3aW4sIHRoZXkgZXhwbGljaXRseSByZXN0b3JlL3NldCBhbGwg cmVnaXN0ZXJzLCBpbmNsdWRpbmcgY2FsbGVlIHNhdmVkIHIxMi1yMTUuCj4+Cj4+IEV4cGxpY2l0 bHkgcHJlc2VydmluZyByZWdpc3RlcnMgd291bGQgcHJldmVudCBrZXJuZWwgZGF0YSBsZWFrYWdl IHRvby4gRG9pbmcgc28gaW4gRnJlZUJTRCB3b3VsZCBhbHNvIGJlIGFuIEFCSSBjb21wYXRpYmxl IGNoYW5nZSBJIHRoaW5rLCBzaW5jZSB1c2VycyBzaG91bGRu4oCZdCByZWx5IG9uIHZhbHVlcyBp biB0aG9zZSByZWdpc3RlcnMuCj4+IEnigJltIGN1cmlvdXMgaWYgeW91IHNlZSBhbnkgb2J2aW91 cyBwcm9zL2NvbnMgd2l0aCBlaXRoZXIgYXBwcm9hY2gsIG9yIGlzIGl0IGp1c3QgYSBtb3JlIGFy Yml0cmFyeSBpbXBsZW1lbnRhdGlvbiBjaG9pY2U/Cj4KPiBXZSBwcmVzZXJ2ZSBldmVyeXRoaW5n IG9uIHN5c2NhbGwgZW50cnksIGl0IGlzIHRoZSBTWVNDQUxMIGluc3RydWN0aW9uCj4gYmVoYXZp b3IgdGhhdCBtYWtlcyBpdCBsb29rIHNvbWV3aGF0IGNvbnZvbHV0ZWQuIEkgc3VnZ2VzdCB5b3Ug dG8gcmVhZAo+IHRoZSBTRE0gZGVzY3JpcHRpb24gb2YgdGhlIFNZU0NBTEwgaW5zdHJ1Y3Rpb24g dG8gdW5kZXJzdGFuZCB0aGUgcmVnaXN0ZXJzCj4gbWFuaXB1bGF0aW9ucyBvbiBlbnRyeS4KPgo+ IE9uIHRoZSBvdGhlciBoYW5kLCBvbiB0aGUgZmFzdCBzeXNjYWxsIHJldHVybiwgd2UgaW5kZWVk IG5vdCByZXN0b3JlCj4gZXZlcnl0aGluZy4gSWYgeW91IHdhbnQgdG8gcmVzdG9yZSBmdWxsIGZy YW1lLCB1c2UgUENCX0ZVTExfSVJFVCBwY2IKPiBmbGFnIHRvIHJlcXVlc3QgaXJldHEgcmV0dXJu IHBhdGguCj4KPj4gTm90IHRoYXQgSeKAmWQgcHJvcG9zZSBjaGFuZ2luZyB0aGUgQUJJIHRob3Vn aCwgSSBhbHNvIHdhbnQgbXkgdG95IHByb2plY3QgdG8gd29yayBhcyBhIHBsdWctaW4ga2VybmVs IG1vZHVsZS4KPj4gSSBndWVzcyB0aGUgb25seSBvdGhlciBvcHRpb24gdG8gZW11bGF0ZSBEYXJ3 aW4ncyBiZWhhdmlvdXIgd291bGQgYmUgdG8gaW50ZXJjZXB0IHN5c2NhbGxzIGluIHVzZXJzcGFj ZSBzb21laG93IGZpcnN0IGFuZCBtYW51YWxseSBwcmVzZXJ2ZSB0aGUgcmVnaXN0ZXIgdmFsdWVz Pwo+Cj4gVG8gZW11bGF0ZSBEYXJ3aW4sIHlvdSB3b3VsZCBuZWVkIHNwZWNpZmljIEFCSSBwZXJz b25hbGl0eSAoc3lzZW50KSBpbiB0aGUKPiBrZXJuZWwsIHdoaWNoIHdvdWxkIGFsc28gcHJvdmlk ZSBzdl9zeXNjYWxsX3JldCBtZXRob2QuIFRoZSBtZXRob2QgY2FuCj4gZG8gd2hhdGV2ZXIgaXMg bmVlZGVkIHRvIHRoZSByZXR1cm4gZnJhbWUsIGFuZCBzZXQgUENCX0ZVTExfSVJFVCB0byBpbmRp Y2F0ZQo+IHRoYXQga2VybmVsIHNob3VsZCBsb2FkIGl0IGludG8gQ1BVIEdQUiBmaWxlIGFzIGlz Lgo+Cj4gQlRXLCBkb2VzIERhcndpbiB1c2UgU1lTQ0FMTCBpbnN0cnVjdGlvbiBmb3Igc3lzY2Fs bCBlbnRyeSBvbiBhbWQ2ND8KClllcywgaXQgYWxzbyB1c2VzIFNZU0NBTEwuIEFsc28gcmF4L3Jk eCBmb3IgcmV0dXJuIHZhbHVlcyBhbmQgdGhlIGNhcnJ5IGJpdCB0byBpbmRpY2F0ZSBlcnJvcnMu CkV2ZW4gdGhlIHN5c2NhbGwgbnVtYmVycyBhcmUgc2ltaWxhci4gVGhleSB1c2UgZGlmZmVyZW50 IG1hc2tzIHRvIGRpc3Rpbmd1aXNoIEJTRC9NYWNoIHN5c2NhbGxzLCBidXQgdGhlIGVmZmVjdGl2 ZSBCU0Qgc3lzY2FsbCBudW1iZXJzIHNlZW0gdG8gYmUgdGhlIHNhbWUgc28gZmFyLgpTbyBJIGFs cmVhZHkgaGFkIHN5c2VudCBob29rcywgYW5kIFBDQl9GVUxMX0lSRVQgd29ya3MgaW5kZWVkLCB0 aGFua3Mh --b1_GMNvESbFpfujOROAvMxN9zwVE2WEQnIpv572aFPvPcw Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiLz48L2hlYWQ+PGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIi8+PGRpdj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPk9uIDE3IEphbiAyMDIyLCBhdCAyMzo1MSwgS29u c3RhbnRpbiBCZWxvdXNvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvc3Rpa2JlbEBnbWFpbC5jb20i IGNsYXNzPSIiPmtvc3Rpa2JlbEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiLz48ZGl2IGNsYXNzPSIiPjxkaXYgY2xhc3M9 IiI+T24gTW9uLCBKYW4gMTcsIDIwMjIgYXQgMTA6MzE6MDlQTSArMDAwMCwgRGFtaWFuJiMzOTtz IFByb3RvbiBNYWlsIHdyb3RlOjxiciBjbGFzcz0iIi8+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiLz48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5P biAxNyBKYW4gMjAyMiwgYXQgMTQ6MzgsIEtvbnN0YW50aW4gQmVsb3Vzb3YgJmx0OzxhIGhyZWY9 Im1haWx0bzprb3N0aWtiZWxAZ21haWwuY29tIiBjbGFzcz0iIj5rb3N0aWtiZWxAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiLz48YnIgY2xhc3M9IiIvPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Mb29rIGF0IHRoZSBzeXMvYW1kNjQvYW1k NjQvZXhjZXB0aW9ucy5TLiDCoFRoZSBmYXN0X3N5c2NhbGwgZW50cnkgcG9pbnQ8YnIgY2xhc3M9 IiIvPmlzIHdoZXJlIHdlIHJlY2VpdmUgY29udHJvbCBhZnRlciB0aGUgc3lzY2FsbCBpbnN0cnVj dGlvbi48YnIgY2xhc3M9IiIvPjwvYmxvY2txdW90ZT5BIGxvdCBvZiBuZXcgdGhpbmdzIGluIHRo ZXJlIGZvciBtZSwgYnV0IHRoZSBmbG93IGlzIGNsZWFyLiBJIHdhcyBhYmxlIHRvIGZpbmQgY29y cmVzcG9uZGluZyBsb2dpYyBpbiBYTlXigJlzIHNvdXJjZXMgdG9vLiBFYXJsaWVyIEkgc2FpZDo8 YnIgY2xhc3M9IiIvPjxiciBjbGFzcz0iIi8+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+QXQgYSBmaXJzdCBnbGFuY2UgRGFyd2luIGFwcHJvYWNoIHNlZW1zIG1vcmUgb3B0aW1hbDxi ciBjbGFzcz0iIi8+PC9ibG9ja3F1b3RlPkJ1dCBpdOKAmXMgaW5zdGVhZCB0aGUgb3Bwb3NpdGUv bm8gZGlmZmVyZW5jZSBhdCBhbGwsIGFzIGluIERhcndpbiwgdGhleSBleHBsaWNpdGx5IHJlc3Rv cmUvc2V0IGFsbCByZWdpc3RlcnMsIGluY2x1ZGluZyBjYWxsZWUgc2F2ZWQgcjEyLXIxNS48YnIg Y2xhc3M9IiIvPjxiciBjbGFzcz0iIi8+RXhwbGljaXRseSBwcmVzZXJ2aW5nIHJlZ2lzdGVycyB3 b3VsZCBwcmV2ZW50IGtlcm5lbCBkYXRhIGxlYWthZ2UgdG9vLiBEb2luZyBzbyBpbiBGcmVlQlNE IHdvdWxkIGFsc28gYmUgYW4gQUJJIGNvbXBhdGlibGUgY2hhbmdlIEkgdGhpbmssIHNpbmNlIHVz ZXJzIHNob3VsZG7igJl0IHJlbHkgb24gdmFsdWVzIGluIHRob3NlIHJlZ2lzdGVycy48YnIgY2xh c3M9IiIvPknigJltIGN1cmlvdXMgaWYgeW91IHNlZSBhbnkgb2J2aW91cyBwcm9zL2NvbnMgd2l0 aCBlaXRoZXIgYXBwcm9hY2gsIG9yIGlzIGl0IGp1c3QgYSBtb3JlIGFyYml0cmFyeSBpbXBsZW1l bnRhdGlvbiBjaG9pY2U/PGJyIGNsYXNzPSIiLz48L2Jsb2NrcXVvdGU+V2UgcHJlc2VydmUgZXZl cnl0aGluZyBvbiBzeXNjYWxsIGVudHJ5LCBpdCBpcyB0aGUgU1lTQ0FMTCBpbnN0cnVjdGlvbjxi ciBjbGFzcz0iIi8+YmVoYXZpb3IgdGhhdCBtYWtlcyBpdCBsb29rIHNvbWV3aGF0IGNvbnZvbHV0 ZWQuIMKgSSBzdWdnZXN0IHlvdSB0byByZWFkPGJyIGNsYXNzPSIiLz50aGUgU0RNIGRlc2NyaXB0 aW9uIG9mIHRoZSBTWVNDQUxMIGluc3RydWN0aW9uIHRvIHVuZGVyc3RhbmQgdGhlIHJlZ2lzdGVy czxiciBjbGFzcz0iIi8+bWFuaXB1bGF0aW9ucyBvbiBlbnRyeS48YnIgY2xhc3M9IiIvPjxiciBj bGFzcz0iIi8+T24gdGhlIG90aGVyIGhhbmQsIG9uIHRoZSBmYXN0IHN5c2NhbGwgcmV0dXJuLCB3 ZSBpbmRlZWQgbm90IHJlc3RvcmU8YnIgY2xhc3M9IiIvPmV2ZXJ5dGhpbmcuIElmIHlvdSB3YW50 IHRvIHJlc3RvcmUgZnVsbCBmcmFtZSwgdXNlIFBDQl9GVUxMX0lSRVQgcGNiPGJyIGNsYXNzPSIi Lz5mbGFnIHRvIHJlcXVlc3QgaXJldHEgcmV0dXJuIHBhdGguPGJyIGNsYXNzPSIiLz48YnIgY2xh c3M9IiIvPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIi8+Tm90 IHRoYXQgSeKAmWQgcHJvcG9zZSBjaGFuZ2luZyB0aGUgQUJJIHRob3VnaCwgSSBhbHNvIHdhbnQg bXkgdG95IHByb2plY3QgdG8gd29yayBhcyBhIHBsdWctaW4ga2VybmVsIG1vZHVsZS48YnIgY2xh c3M9IiIvPkkgZ3Vlc3MgdGhlIG9ubHkgb3RoZXIgb3B0aW9uIHRvIGVtdWxhdGUgRGFyd2luJiMz OTtzIGJlaGF2aW91ciB3b3VsZCBiZSB0byBpbnRlcmNlcHQgc3lzY2FsbHMgaW4gdXNlcnNwYWNl IHNvbWVob3cgZmlyc3QgYW5kIG1hbnVhbGx5IHByZXNlcnZlIHRoZSByZWdpc3RlciB2YWx1ZXM/ PGJyIGNsYXNzPSIiLz48L2Jsb2NrcXVvdGU+PGJyIGNsYXNzPSIiLz5UbyBlbXVsYXRlIERhcndp biwgeW91IHdvdWxkIG5lZWQgc3BlY2lmaWMgQUJJIHBlcnNvbmFsaXR5IChzeXNlbnQpIGluIHRo ZTxiciBjbGFzcz0iIi8+a2VybmVsLCB3aGljaCB3b3VsZCBhbHNvIHByb3ZpZGUgc3Zfc3lzY2Fs bF9yZXQgbWV0aG9kLiDCoFRoZSBtZXRob2QgY2FuPGJyIGNsYXNzPSIiLz5kbyB3aGF0ZXZlciBp cyBuZWVkZWQgdG8gdGhlIHJldHVybiBmcmFtZSwgYW5kIHNldCBQQ0JfRlVMTF9JUkVUIHRvIGlu ZGljYXRlPGJyIGNsYXNzPSIiLz50aGF0IGtlcm5lbCBzaG91bGQgbG9hZCBpdCBpbnRvIENQVSBH UFIgZmlsZSBhcyBpcy48YnIgY2xhc3M9IiIvPjxiciBjbGFzcz0iIi8+QlRXLCBkb2VzIERhcndp biB1c2UgU1lTQ0FMTCBpbnN0cnVjdGlvbiBmb3Igc3lzY2FsbCBlbnRyeSBvbiBhbWQ2ND88YnIg Y2xhc3M9IiIvPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YnIgY2xhc3M9IiIvPjwvZGl2Pjxk aXY+WWVzLCBpdCBhbHNvIHVzZXMgU1lTQ0FMTC4gQWxzbyByYXgvcmR4IGZvciByZXR1cm4gdmFs dWVzIGFuZCB0aGUgPGkgY2xhc3M9IiI+Y2Fycnk8L2k+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6 IG5vcm1hbDsiIGNsYXNzPSIiPsKgYml0IHRvIGluZGljYXRlIGVycm9ycy48L3NwYW4+PC9kaXY+ PGRpdj48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTogbm9ybWFsOyIgY2xhc3M9IiI+RXZlbiB0aGUg c3lzY2FsbCBudW1iZXJzIGFyZSBzaW1pbGFyLiBUaGV5IHVzZSBkaWZmZXJlbnQgbWFza3MgdG8g ZGlzdGluZ3Vpc2ggQlNEL01hY2ggc3lzY2FsbHMsIGJ1dCB0aGUgZWZmZWN0aXZlIEJTRCBzeXNj YWxsIG51bWJlcnMgc2VlbSB0byBiZSB0aGUgc2FtZSBzbyBmYXIuPC9zcGFuPjwvZGl2PjxkaXY+ U28gSSBhbHJlYWR5IGhhZCBzeXNlbnQgaG9va3MsIGFuZCBQQ0JfRlVMTF9JUkVUIHdvcmtzIGlu ZGVlZCwgdGhhbmtzITwvZGl2PjwvYm9keT48L2h0bWw+ --b1_GMNvESbFpfujOROAvMxN9zwVE2WEQnIpv572aFPvPcw-- From nobody Tue Jan 18 15:21:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F003F195E532 for ; Tue, 18 Jan 2022 15:21:43 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JdXYc0xSKz3KND for ; Tue, 18 Jan 2022 15:21:39 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 34631 invoked by uid 907); 18 Jan 2022 15:21:30 -0000 Received: from i5E86417A.versanet.de (HELO smtpclient.apple) (94.134.65.122) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Wed, 19 Jan 2022 02:21:30 +1100 From: Jan Mikkelsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Joystick with keyboard, mouse and joystick endpoints disconnects after 3-4 seconds Message-Id: <7A70DD3A-48A9-426A-BB73-7DB1B31BE1E0@transactionware.com> Date: Tue, 18 Jan 2022 16:21:25 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JdXYc0xSKz3KND X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of janm@transactionware.com has no SPF policy when checking 203.14.245.7) smtp.mailfrom=janm@transactionware.com X-Spamd-Result: default: False [1.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.72)[0.720]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.71)[0.706]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, When attaching an APEM VM Desktop joystick, = https://www.apem.com/int/vm-desktop-93.html, to a 12.2 system, I get = this sequence of events: ugen0.10: at usbus0 uhid0 numa-domain 0 on uhub2 uhid0: on usbus0 uhid1 numa-domain 0 on uhub2 uhid1: on usbus0 uhid2 numa-domain 0 on uhub2 uhid2: on usbus0 ugen0.10: at usbus0 (disconnected) uhid0: at uhub2, port 5, addr 19 (disconnected) uhid0: detached uhid1: at uhub2, port 5, addr 19 (disconnected) uhid1: detached uhid2: at uhub2, port 5, addr 19 (disconnected) uhid2: detached The disconnection happens about 3-4 seconds after the attachment = completes. The device has three endpoints: A mouse, a keyboard and a joystick. I = have added quirks to have ums and ukbd ignore the device, so that uhid = attaches. I believe that mouse and keyboard endpoints on the same device = are not currently supported. The output from =E2=80=9Cusbconfig dump_all_desc=E2=80=9D is shown = below. Any ideas on where to look to resolve this? Thanks, Jan M. ugen0.10: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL= (12Mbps) pwr=3DON (500mA) bLength =3D 0x0012=20 bDescriptorType =3D 0x0001=20 bcdUSB =3D 0x0200=20 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000=20 bDeviceProtocol =3D 0x0000=20 bMaxPacketSize0 =3D 0x0008=20 idVendor =3D 0x068e=20 idProduct =3D 0x0064=20 bcdDevice =3D 0x0200=20 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0000 bNumConfigurations =3D 0x0001=20 Configuration index 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0002=20 wTotalLength =3D 0x005b=20 bNumInterfaces =3D 0x0003=20 bConfigurationValue =3D 0x0001=20 iConfiguration =3D 0x0000 bmAttributes =3D 0x0080=20 bMaxPower =3D 0x00fa=20 Interface 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0004=20 bInterfaceNumber =3D 0x0000=20 bAlternateSetting =3D 0x0000=20 bNumEndpoints =3D 0x0002=20 bInterfaceClass =3D 0x0003 bInterfaceSubClass =3D 0x0000=20 bInterfaceProtocol =3D 0x0000=20 iInterface =3D 0x0005 Additional Descriptor bLength =3D 0x09 bDescriptorType =3D 0x21 bDescriptorSubType =3D 0x11 RAW dump:=20 0x00 | 0x09, 0x21, 0x11, 0x01, 0x21, 0x01, 0x22, 0x4b,=20 0x08 | 0x00 Endpoint 0 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0082 bmAttributes =3D 0x0003 wMaxPacketSize =3D 0x0040=20 bInterval =3D 0x000a=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 Endpoint 1 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0001 bmAttributes =3D 0x0003 wMaxPacketSize =3D 0x0040=20 bInterval =3D 0x000a=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 Interface 1 bLength =3D 0x0009=20 bDescriptorType =3D 0x0004=20 bInterfaceNumber =3D 0x0001=20 bAlternateSetting =3D 0x0000=20 bNumEndpoints =3D 0x0001=20 bInterfaceClass =3D 0x0003 bInterfaceSubClass =3D 0x0000=20 bInterfaceProtocol =3D 0x0000=20 iInterface =3D 0x0004 Additional Descriptor bLength =3D 0x09 bDescriptorType =3D 0x21 bDescriptorSubType =3D 0x11 RAW dump:=20 0x00 | 0x09, 0x21, 0x11, 0x01, 0x21, 0x01, 0x22, 0x3f,=20 0x08 | 0x00 Endpoint 0 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0083 bmAttributes =3D 0x0003 wMaxPacketSize =3D 0x0008=20 bInterval =3D 0x000a=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 Interface 2 bLength =3D 0x0009=20 bDescriptorType =3D 0x0004=20 bInterfaceNumber =3D 0x0002=20 bAlternateSetting =3D 0x0000=20 bNumEndpoints =3D 0x0001=20 bInterfaceClass =3D 0x0003 bInterfaceSubClass =3D 0x0000=20 bInterfaceProtocol =3D 0x0000=20 iInterface =3D 0x0003 Additional Descriptor bLength =3D 0x09 bDescriptorType =3D 0x21 bDescriptorSubType =3D 0x11 RAW dump:=20 0x00 | 0x09, 0x21, 0x11, 0x01, 0x21, 0x01, 0x22, 0x34,=20 0x08 | 0x00 Endpoint 0 bLength =3D 0x0007=20 bDescriptorType =3D 0x0005=20 bEndpointAddress =3D 0x0084 bmAttributes =3D 0x0003 wMaxPacketSize =3D 0x0008=20 bInterval =3D 0x000a=20 bRefresh =3D 0x0000=20 bSynchAddress =3D 0x0000=20 From nobody Tue Jan 18 21:53:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ACC35195FF62 for ; Tue, 18 Jan 2022 21:54:00 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JdjGH5CFsz4cfc for ; Tue, 18 Jan 2022 21:53:59 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qv1-xf35.google.com with SMTP id h16so729732qvk.10 for ; Tue, 18 Jan 2022 13:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=/1EeSw0HYuenofCgZlq5BCd1BtB2ixwjWS8xN8dflJs=; b=G/aqGZl3c+62zeYweTZAcELosQyrPVAktIprvwleiI76HXpWHYvMNo2x91g5ja4v1J MrBd43AO0X3Q6Gb9aPDqVA2fHddk+E1/v0eR9MY2kRDbRiS+bxtZNsatWlJeMpMQj+vA GfBkuihKx3NyCVUhArNYttUiqaVQQZOmldpCPgfPuY1HvXu0qEV1qR8wqPThKhoDVMgt QB7NjXAE9JGoGC3DCEZxyxFgf/eu4ZOctgegwphlsp3znWda0iZwIC7GLrBltCXA52yF 0hj6Csng8ad3KjKSfVPLcXysh3HzstnZDWBYZtESDioMejVonYqu0rFYkLWo/IXDQpBZ K2YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=/1EeSw0HYuenofCgZlq5BCd1BtB2ixwjWS8xN8dflJs=; b=W0lvD0jfPoAyw46E7E0q7++gDEIeEVWG+/CghpwzgGE+C0K6AEKquAi5fIv4Xh0c2Y 6/WqjbX5lNYqWO14sPCJuX+jw0zVD1KCUkTGquWsLy231NoIIF9YouqrwZbXMoArwhlU Jv5m+kjpVBVO4m4dUpOBD4vP+3/MKeSPzsIRlhnAiLPcP3LoqHKm9vEwcoxTkAvwAdHt 7aGXOdwq6Mkx30ZuTjpH0G8rVhl27Lr6PaCXgY9UvjPa8kiFXrDjf1soKO6TUsbJmx/Q oATQA2gU71HkQ/+xbTGZLRqylJFG8QvoNPV6xGcwn7a5TsmDvB1rj9hoApg3O3GQO7FF Idmw== X-Gm-Message-State: AOAM533mctcaZ/spJNgtKe8ISpAYH1fxZwuar3wRAPYDYYPlpvyaZ3jO b/rZ+iPEvjtS1b+UVZaasRWUgcVXJek= X-Google-Smtp-Source: ABdhPJwGS3O2G/3v55bwifBXle6WxceZ4nMHVM/pH1qg4X1BMmhz1BHoB7hBtHYi9KzC7acIp4JUeQ== X-Received: by 2002:ad4:5964:: with SMTP id eq4mr13914024qvb.106.1642542839043; Tue, 18 Jan 2022 13:53:59 -0800 (PST) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id r2sm469535qkf.49.2022.01.18.13.53.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jan 2022 13:53:58 -0800 (PST) Message-ID: <40405ba8-14b3-90cc-7f19-103928f17da2@gmail.com> Date: Tue, 18 Jan 2022 15:53:57 -0600 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: Joystick with keyboard, mouse and joystick endpoints disconnects after 3-4 seconds Content-Language: en-US To: freebsd-hackers@freebsd.org References: <7A70DD3A-48A9-426A-BB73-7DB1B31BE1E0@transactionware.com> From: Jason Bacon In-Reply-To: <7A70DD3A-48A9-426A-BB73-7DB1B31BE1E0@transactionware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4JdjGH5CFsz4cfc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="G/aqGZl3"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-3.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0: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:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N DQpBcmUgeW91IHJ1bm5pbmcgd2ViY2FtZD8NCg0KSSBoYWQgYSBzaW1pbGFyIHByb2JsZW0g d2l0aCBhIFVTQiBnYW1lcGFkIEkgdXNlIGZvciBjb250cm9sbGluZyBMZWdvIA0Kcm9ib3Rz IG92ZXIgYmx1ZXRvb3RoIHNvbWUgeWVhcnMgYWdvIGFuZCBsZWFybmVkIHRoYXQgd2ViY2Ft ZCBpc24ndCBqdXN0IA0KZm9yIHdlYmNhbXMgYW55bW9yZSwgYnV0IGdyYWJzIG90aGVyIGtp bmRzIG9mIEhJRHMuDQoNCk9uIDEvMTgvMjIgMDk6MjEsIEphbiBNaWtrZWxzZW4gd3JvdGU6 DQo+IEhpLA0KPiANCj4gV2hlbiBhdHRhY2hpbmcgYW4gQVBFTSBWTSBEZXNrdG9wIGpveXN0 aWNrLCBodHRwczovL3d3dy5hcGVtLmNvbS9pbnQvdm0tZGVza3RvcC05My5odG1sLCB0byBh IDEyLjIgc3lzdGVtLCBJIGdldCB0aGlzIHNlcXVlbmNlIG9mIGV2ZW50czoNCj4gDQo+IHVn ZW4wLjEwOiA8Q0ggUHJvZHVjdHMgVk0gRGVza3RvcD4gYXQgdXNidXMwDQo+IHVoaWQwIG51 bWEtZG9tYWluIDAgb24gdWh1YjINCj4gdWhpZDA6IDxWTSBKb3lzdGljayBJbnRlcmZhY2U+ IG9uIHVzYnVzMA0KPiB1aGlkMSBudW1hLWRvbWFpbiAwIG9uIHVodWIyDQo+IHVoaWQxOiA8 Vk0gS2V5Ym9hcmQgSW50ZXJmYWNlPiBvbiB1c2J1czANCj4gdWhpZDIgbnVtYS1kb21haW4g MCBvbiB1aHViMg0KPiB1aGlkMjogPFZNIE1vdXNlIEludGVyZmFjZT4gb24gdXNidXMwDQo+ IHVnZW4wLjEwOiA8Q0ggUHJvZHVjdHMgVk0gRGVza3RvcD4gYXQgdXNidXMwIChkaXNjb25u ZWN0ZWQpDQo+IHVoaWQwOiBhdCB1aHViMiwgcG9ydCA1LCBhZGRyIDE5IChkaXNjb25uZWN0 ZWQpDQo+IHVoaWQwOiBkZXRhY2hlZA0KPiB1aGlkMTogYXQgdWh1YjIsIHBvcnQgNSwgYWRk ciAxOSAoZGlzY29ubmVjdGVkKQ0KPiB1aGlkMTogZGV0YWNoZWQNCj4gdWhpZDI6IGF0IHVo dWIyLCBwb3J0IDUsIGFkZHIgMTkgKGRpc2Nvbm5lY3RlZCkNCj4gdWhpZDI6IGRldGFjaGVk DQo+IA0KPiBUaGUgZGlzY29ubmVjdGlvbiBoYXBwZW5zIGFib3V0IDMtNCBzZWNvbmRzIGFm dGVyIHRoZSBhdHRhY2htZW50IGNvbXBsZXRlcy4NCj4gDQo+IFRoZSBkZXZpY2UgaGFzIHRo cmVlIGVuZHBvaW50czogQSBtb3VzZSwgYSBrZXlib2FyZCBhbmQgYSBqb3lzdGljay4gSSBo YXZlIGFkZGVkIHF1aXJrcyB0byBoYXZlIHVtcyBhbmQgdWtiZCBpZ25vcmUgdGhlIGRldmlj ZSwgc28gdGhhdCB1aGlkIGF0dGFjaGVzLiBJIGJlbGlldmUgdGhhdCBtb3VzZSBhbmQga2V5 Ym9hcmQgZW5kcG9pbnRzIG9uIHRoZSBzYW1lIGRldmljZSBhcmUgbm90IGN1cnJlbnRseSBz dXBwb3J0ZWQuDQo+IA0KPiBUaGUgb3V0cHV0IGZyb20g4oCcdXNiY29uZmlnIGR1bXBfYWxs X2Rlc2PigJ0gaXMgc2hvd24gYmVsb3cuDQo+IA0KPiBBbnkgaWRlYXMgb24gd2hlcmUgdG8g bG9vayB0byByZXNvbHZlIHRoaXM/DQo+IA0KPiBUaGFua3MsDQo+IA0KPiBKYW4gTS4NCj4g DQo+IA0KPiB1Z2VuMC4xMDogPENIIFByb2R1Y3RzIFZNIERlc2t0b3A+IGF0IHVzYnVzMCwg Y2ZnPTAgbWQ9SE9TVCBzcGQ9RlVMTCAoMTJNYnBzKSBwd3I9T04gKDUwMG1BKQ0KPiANCj4g ICAgYkxlbmd0aCA9IDB4MDAxMg0KPiAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDENCj4g ICAgYmNkVVNCID0gMHgwMjAwDQo+ICAgIGJEZXZpY2VDbGFzcyA9IDB4MDAwMCAgPFByb2Jl ZCBieSBpbnRlcmZhY2UgY2xhc3M+DQo+ICAgIGJEZXZpY2VTdWJDbGFzcyA9IDB4MDAwMA0K PiAgICBiRGV2aWNlUHJvdG9jb2wgPSAweDAwMDANCj4gICAgYk1heFBhY2tldFNpemUwID0g MHgwMDA4DQo+ICAgIGlkVmVuZG9yID0gMHgwNjhlDQo+ICAgIGlkUHJvZHVjdCA9IDB4MDA2 NA0KPiAgICBiY2REZXZpY2UgPSAweDAyMDANCj4gICAgaU1hbnVmYWN0dXJlciA9IDB4MDAw MSAgPENIIFByb2R1Y3RzPg0KPiAgICBpUHJvZHVjdCA9IDB4MDAwMiAgPFZNIERlc2t0b3A+ DQo+ICAgIGlTZXJpYWxOdW1iZXIgPSAweDAwMDAgIDxubyBzdHJpbmc+DQo+ICAgIGJOdW1D b25maWd1cmF0aW9ucyA9IDB4MDAwMQ0KPiANCj4gICBDb25maWd1cmF0aW9uIGluZGV4IDAN Cj4gDQo+ICAgICAgYkxlbmd0aCA9IDB4MDAwOQ0KPiAgICAgIGJEZXNjcmlwdG9yVHlwZSA9 IDB4MDAwMg0KPiAgICAgIHdUb3RhbExlbmd0aCA9IDB4MDA1Yg0KPiAgICAgIGJOdW1JbnRl cmZhY2VzID0gMHgwMDAzDQo+ICAgICAgYkNvbmZpZ3VyYXRpb25WYWx1ZSA9IDB4MDAwMQ0K PiAgICAgIGlDb25maWd1cmF0aW9uID0gMHgwMDAwICA8bm8gc3RyaW5nPg0KPiAgICAgIGJt QXR0cmlidXRlcyA9IDB4MDA4MA0KPiAgICAgIGJNYXhQb3dlciA9IDB4MDBmYQ0KPiANCj4g ICAgICBJbnRlcmZhY2UgMA0KPiAgICAgICAgYkxlbmd0aCA9IDB4MDAwOQ0KPiAgICAgICAg YkRlc2NyaXB0b3JUeXBlID0gMHgwMDA0DQo+ICAgICAgICBiSW50ZXJmYWNlTnVtYmVyID0g MHgwMDAwDQo+ICAgICAgICBiQWx0ZXJuYXRlU2V0dGluZyA9IDB4MDAwMA0KPiAgICAgICAg Yk51bUVuZHBvaW50cyA9IDB4MDAwMg0KPiAgICAgICAgYkludGVyZmFjZUNsYXNzID0gMHgw MDAzICA8SElEIGRldmljZT4NCj4gICAgICAgIGJJbnRlcmZhY2VTdWJDbGFzcyA9IDB4MDAw MA0KPiAgICAgICAgYkludGVyZmFjZVByb3RvY29sID0gMHgwMDAwDQo+ICAgICAgICBpSW50 ZXJmYWNlID0gMHgwMDA1ICA8Vk0gSm95c3RpY2sgSW50ZXJmYWNlPg0KPiANCj4gICAgICAg IEFkZGl0aW9uYWwgRGVzY3JpcHRvcg0KPiANCj4gICAgICAgIGJMZW5ndGggPSAweDA5DQo+ ICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDIxDQo+ICAgICAgICBiRGVzY3JpcHRvclN1 YlR5cGUgPSAweDExDQo+ICAgICAgICAgUkFXIGR1bXA6DQo+ICAgICAgICAgMHgwMCB8IDB4 MDksIDB4MjEsIDB4MTEsIDB4MDEsIDB4MjEsIDB4MDEsIDB4MjIsIDB4NGIsDQo+ICAgICAg ICAgMHgwOCB8IDB4MDANCj4gDQo+ICAgICAgIEVuZHBvaW50IDANCj4gICAgICAgICAgYkxl bmd0aCA9IDB4MDAwNw0KPiAgICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDUNCj4g ICAgICAgICAgYkVuZHBvaW50QWRkcmVzcyA9IDB4MDA4MiAgPElOPg0KPiAgICAgICAgICBi bUF0dHJpYnV0ZXMgPSAweDAwMDMgIDxJTlRFUlJVUFQ+DQo+ICAgICAgICAgIHdNYXhQYWNr ZXRTaXplID0gMHgwMDQwDQo+ICAgICAgICAgIGJJbnRlcnZhbCA9IDB4MDAwYQ0KPiAgICAg ICAgICBiUmVmcmVzaCA9IDB4MDAwMA0KPiAgICAgICAgICBiU3luY2hBZGRyZXNzID0gMHgw MDAwDQo+IA0KPiAgICAgICBFbmRwb2ludCAxDQo+ICAgICAgICAgIGJMZW5ndGggPSAweDAw MDcNCj4gICAgICAgICAgYkRlc2NyaXB0b3JUeXBlID0gMHgwMDA1DQo+ICAgICAgICAgIGJF bmRwb2ludEFkZHJlc3MgPSAweDAwMDEgIDxPVVQ+DQo+ICAgICAgICAgIGJtQXR0cmlidXRl cyA9IDB4MDAwMyAgPElOVEVSUlVQVD4NCj4gICAgICAgICAgd01heFBhY2tldFNpemUgPSAw eDAwNDANCj4gICAgICAgICAgYkludGVydmFsID0gMHgwMDBhDQo+ICAgICAgICAgIGJSZWZy ZXNoID0gMHgwMDAwDQo+ICAgICAgICAgIGJTeW5jaEFkZHJlc3MgPSAweDAwMDANCj4gDQo+ IA0KPiAgICAgIEludGVyZmFjZSAxDQo+ICAgICAgICBiTGVuZ3RoID0gMHgwMDA5DQo+ICAg ICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDQNCj4gICAgICAgIGJJbnRlcmZhY2VOdW1i ZXIgPSAweDAwMDENCj4gICAgICAgIGJBbHRlcm5hdGVTZXR0aW5nID0gMHgwMDAwDQo+ICAg ICAgICBiTnVtRW5kcG9pbnRzID0gMHgwMDAxDQo+ICAgICAgICBiSW50ZXJmYWNlQ2xhc3Mg PSAweDAwMDMgIDxISUQgZGV2aWNlPg0KPiAgICAgICAgYkludGVyZmFjZVN1YkNsYXNzID0g MHgwMDAwDQo+ICAgICAgICBiSW50ZXJmYWNlUHJvdG9jb2wgPSAweDAwMDANCj4gICAgICAg IGlJbnRlcmZhY2UgPSAweDAwMDQgIDxWTSBLZXlib2FyZCBJbnRlcmZhY2U+DQo+IA0KPiAg ICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQo+IA0KPiAgICAgICAgYkxlbmd0aCA9IDB4 MDkNCj4gICAgICAgIGJEZXNjcmlwdG9yVHlwZSA9IDB4MjENCj4gICAgICAgIGJEZXNjcmlw dG9yU3ViVHlwZSA9IDB4MTENCj4gICAgICAgICBSQVcgZHVtcDoNCj4gICAgICAgICAweDAw IHwgMHgwOSwgMHgyMSwgMHgxMSwgMHgwMSwgMHgyMSwgMHgwMSwgMHgyMiwgMHgzZiwNCj4g ICAgICAgICAweDA4IHwgMHgwMA0KPiANCj4gICAgICAgRW5kcG9pbnQgMA0KPiAgICAgICAg ICBiTGVuZ3RoID0gMHgwMDA3DQo+ICAgICAgICAgIGJEZXNjcmlwdG9yVHlwZSA9IDB4MDAw NQ0KPiAgICAgICAgICBiRW5kcG9pbnRBZGRyZXNzID0gMHgwMDgzICA8SU4+DQo+ICAgICAg ICAgIGJtQXR0cmlidXRlcyA9IDB4MDAwMyAgPElOVEVSUlVQVD4NCj4gICAgICAgICAgd01h eFBhY2tldFNpemUgPSAweDAwMDgNCj4gICAgICAgICAgYkludGVydmFsID0gMHgwMDBhDQo+ ICAgICAgICAgIGJSZWZyZXNoID0gMHgwMDAwDQo+ICAgICAgICAgIGJTeW5jaEFkZHJlc3Mg PSAweDAwMDANCj4gDQo+IA0KPiAgICAgIEludGVyZmFjZSAyDQo+ICAgICAgICBiTGVuZ3Ro ID0gMHgwMDA5DQo+ICAgICAgICBiRGVzY3JpcHRvclR5cGUgPSAweDAwMDQNCj4gICAgICAg IGJJbnRlcmZhY2VOdW1iZXIgPSAweDAwMDINCj4gICAgICAgIGJBbHRlcm5hdGVTZXR0aW5n ID0gMHgwMDAwDQo+ICAgICAgICBiTnVtRW5kcG9pbnRzID0gMHgwMDAxDQo+ICAgICAgICBi SW50ZXJmYWNlQ2xhc3MgPSAweDAwMDMgIDxISUQgZGV2aWNlPg0KPiAgICAgICAgYkludGVy ZmFjZVN1YkNsYXNzID0gMHgwMDAwDQo+ICAgICAgICBiSW50ZXJmYWNlUHJvdG9jb2wgPSAw eDAwMDANCj4gICAgICAgIGlJbnRlcmZhY2UgPSAweDAwMDMgIDxWTSBNb3VzZSBJbnRlcmZh Y2U+DQo+IA0KPiAgICAgICAgQWRkaXRpb25hbCBEZXNjcmlwdG9yDQo+IA0KPiAgICAgICAg Ykxlbmd0aCA9IDB4MDkNCj4gICAgICAgIGJEZXNjcmlwdG9yVHlwZSA9IDB4MjENCj4gICAg ICAgIGJEZXNjcmlwdG9yU3ViVHlwZSA9IDB4MTENCj4gICAgICAgICBSQVcgZHVtcDoNCj4g ICAgICAgICAweDAwIHwgMHgwOSwgMHgyMSwgMHgxMSwgMHgwMSwgMHgyMSwgMHgwMSwgMHgy MiwgMHgzNCwNCj4gICAgICAgICAweDA4IHwgMHgwMA0KPiANCj4gICAgICAgRW5kcG9pbnQg MA0KPiAgICAgICAgICBiTGVuZ3RoID0gMHgwMDA3DQo+ICAgICAgICAgIGJEZXNjcmlwdG9y VHlwZSA9IDB4MDAwNQ0KPiAgICAgICAgICBiRW5kcG9pbnRBZGRyZXNzID0gMHgwMDg0ICA8 SU4+DQo+ICAgICAgICAgIGJtQXR0cmlidXRlcyA9IDB4MDAwMyAgPElOVEVSUlVQVD4NCj4g ICAgICAgICAgd01heFBhY2tldFNpemUgPSAweDAwMDgNCj4gICAgICAgICAgYkludGVydmFs ID0gMHgwMDBhDQo+ICAgICAgICAgIGJSZWZyZXNoID0gMHgwMDAwDQo+ICAgICAgICAgIGJT eW5jaEFkZHJlc3MgPSAweDAwMDANCj4gDQo+IA0KPiANCg0KDQotLSANCkxpZmUgaXMgYSBn YW1lLiAgUGxheSBoYXJkLCBwbGF5IGZhaXIsIGFuZCBoYXZlIGZ1bi4uLg0K From nobody Wed Jan 19 08:45:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 82C48197182F for ; Wed, 19 Jan 2022 08:45:59 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4JdzkX69Sgz3C4L for ; Wed, 19 Jan 2022 08:45:56 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 70978 invoked by uid 907); 19 Jan 2022 08:45:54 -0000 Received: from i5E8641E9.versanet.de (HELO smtpclient.apple) (94.134.65.233) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Wed, 19 Jan 2022 19:45:54 +1100 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Joystick with keyboard, mouse and joystick endpoints disconnects after 3-4 seconds From: Jan Mikkelsen In-Reply-To: <40405ba8-14b3-90cc-7f19-103928f17da2@gmail.com> Date: Wed, 19 Jan 2022 09:45:47 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <81CCE949-4F7F-4651-B88D-9B1EFC0C5672@transactionware.com> References: <7A70DD3A-48A9-426A-BB73-7DB1B31BE1E0@transactionware.com> <40405ba8-14b3-90cc-7f19-103928f17da2@gmail.com> To: Jason Bacon X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JdzkX69Sgz3C4L X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of janm@transactionware.com has no SPF policy when checking 203.14.245.7) smtp.mailfrom=janm@transactionware.com X-Spamd-Result: default: False [2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 18 Jan 2022, at 22:53, Jason Bacon wrote: >=20 >=20 > Are you running webcamd? >=20 > I had a similar problem with a USB gamepad I use for controlling Lego = robots over bluetooth some years ago and learned that webcamd isn't just = for webcams anymore, but grabs other kinds of HIDs. No, not running webcamd. The problem happens just connecting the device = on a machine sitting at a text login prompt. The HID devices don=E2=80=99t= stay there long enough for anything to use. Regards, Jan M. From nobody Wed Jan 19 11:16:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D3A521966B06 for ; Wed, 19 Jan 2022 11:16:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jf34P5c4zz4v71; Wed, 19 Jan 2022 11:16:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642590997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n0Uif6BsKbNVpqzYm5Y8SwsbpuIfpSUUSyHiek5lufM=; b=F4M5MKyqXbkphTX1tunxTmnsKiEd6d68RZONULsznbeWPtV3PT2tzKMIfEroXx6UuWz8YX FUVRrLqZtdrtL20KBprLYqDreoAchGa6OhMfrygQahAcB2fv5tLDb4OBYU9JCD7Q8jMOwa hZjur1WvN3MSiTttq1EAVXfcYpV1+hBAAIbf5Asf7k7+BisjwijwwYZhaLjF5nxub7T3Tb n5glpVsPm46GckyP9C6vzoddHifyz1ilJMzZH/Xho1Xk8t2YEOcMp/d7JFQdtfEaHnizig jN3GrVByRhSRknpIjCB1o5rAiDp9l9svABhp82/p6ey8Oq48IjYNgDx02xuM4w== Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2CC292193; Wed, 19 Jan 2022 11:16:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Message-ID: <475d4f56-f6c7-ef04-fc17-6fe141f647e8@FreeBSD.org> Date: Wed, 19 Jan 2022 13:16:33 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Subject: Re: Joystick with keyboard, mouse and joystick endpoints disconnects after 3-4 seconds Content-Language: en-US To: Jan Mikkelsen , Jason Bacon Cc: freebsd-hackers@freebsd.org References: <7A70DD3A-48A9-426A-BB73-7DB1B31BE1E0@transactionware.com> <40405ba8-14b3-90cc-7f19-103928f17da2@gmail.com> <81CCE949-4F7F-4651-B88D-9B1EFC0C5672@transactionware.com> From: Andriy Gapon In-Reply-To: <81CCE949-4F7F-4651-B88D-9B1EFC0C5672@transactionware.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1642590997; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n0Uif6BsKbNVpqzYm5Y8SwsbpuIfpSUUSyHiek5lufM=; b=c4//S8Za00ILPE1iApQFQfAR+LhtW/pTKC0bPmsSsVmWI3EgnB4iHWcuhcRK/2Xtz0S40A uJtgbYDZW9emDiQ78smB2RGP2VxWzauVggZcPiwMEKROMhtGXDysWbGhDxEtvBl8G2KH6i RVHI2F0Repux+DpXqbc1c6LPuD+25QHfo3e3MlHO6IPRgRoBSh4mFH5dxNAK1Yqq7qZMTV zZcsdYkzWWVAZCIXhhGNgXsAfmZ4ptSewC/YKzweDRr0ESxgRhS702IrsTALfbHtMZ0eKs xe0R6DbCmaJNLnf/wwILqmW5q1WLVRKG1i5oOFeozxdJcqkSUdpg3DQQx/xjjA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1642590997; a=rsa-sha256; cv=none; b=LnSdp0ZpyWpr0RGvAAs18BZai33b9sUXFN6qgXCxGeIXA4ipFMziH2+zvtcOzm0/u4DWec JDgq2OrhL6fjOUbCPFQ6kP4yWpzJ5Re+K/4Y7mu74FNH195tYdlhYeeqqssTy0Wu0psi7z 0axd5FR5rVkwDN7cIGurEjW4p5/cR6ffFtstB1t7dpDED+N06e9yvlrl3Qkre+qKCxnDKl nyqmzklGDHDW4Kvy39s0lA22nFttD1kwl5u3EARlz70lgah8kmye/o1gCUQQR3cTFvBRI7 /pszkp6eFAE5gAGZNq9vXSHRzE4pBQ8nsuOLqSriF7DK/MX1Rf1vSGbkT8hGYw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 19/01/2022 10:45, Jan Mikkelsen wrote: > >> On 18 Jan 2022, at 22:53, Jason Bacon wrote: >> >> >> Are you running webcamd? >> >> I had a similar problem with a USB gamepad I use for controlling Lego robots over bluetooth some years ago and learned that webcamd isn't just for webcams anymore, but grabs other kinds of HIDs. > > > No, not running webcamd. The problem happens just connecting the device on a machine sitting at a text login prompt. The HID devices don’t stay there long enough for anything to use. Try to capture USB traffic between connect and disconnect with usbdump. Also, I think you would have a higher chance of catching attention of right people if you use usb@ mailing list. -- Andriy Gapon From nobody Thu Jan 20 07:26:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B9D4196CCCF for ; Thu, 20 Jan 2022 07:26:48 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfYwl3GPNz4Th3 for ; Thu, 20 Jan 2022 07:26:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20K7Qjcf051784 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Jan 2022 08:26:45 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642663606; bh=fT6hXNGeAF8X5nrbpLsGlMaDxmBEdcPCGaBUcYQ2Ehw=; h=Date:From:To:Subject:In-Reply-To:References; b=Nd1vB3IYwiWL1BXuzIPSClitqrjFoVZskCJrdsOt5qHWftNTg2UhbM5uG1rDqwlxU 1vwP2Q/S8PczB7/abLiJgwwAGnmSPArHTPBRGOPHgdjRjXZLRLiCZrZ0tgAcHKcUT8 YsOHU1qBUzxNXUblT2jGvAQhylAi4GXJK759FGk0= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20K7Qj0Q048880 for ; Thu, 20 Jan 2022 08:26:45 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20K7QjEW048877 for ; Thu, 20 Jan 2022 08:26:45 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@FreeBSD.org Subject: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: <1642588351-27242-mlmmj-037a935e@FreeBSD.org> Message-ID: <5936ab91-e966-2deb-ac9c-a4a5a0a8a29a@puchar.net> References: <1642588351-27242-mlmmj-037a935e@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4JfYwl3GPNz4Th3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=Nd1vB3IY; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-2.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.69)[-0.688]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-0.53)[-0.530]; DMARC_NA(0.00)[puchar.net]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N tried RPI image for 13.0 and RPI3 image 12.3 both does not boot at all. nothing on serial console at all. What image should i use for this computer? From nobody Thu Jan 20 08:17:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 191D11967A9A for ; Thu, 20 Jan 2022 08:18:03 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jfb3t2CTNz4qC6 for ; Thu, 20 Jan 2022 08:18:02 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-oi1-x233.google.com with SMTP id r138so8334808oie.3 for ; Thu, 20 Jan 2022 00:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8l5j9lBQzEqvUMbBo3rVyEqIX4yAhHFiDhhogZm+8FU=; b=jXm2Ep61FFsbqF4PUFYdAaAQ+m0SQB6IklIYMT/OxxOd4LgQ/cEzwnObjdOHN22BSK 9vh9+JVS6bZr9ujw9iG6X8WvfsW4wxG0YQEO2fwE/2Pl2E+TEBDkYir8vgti1rwID6Mm vM78a7fPIXTQpL0dNtVqiSBMAaby4wdzDfKMiNNSdFdS0N5O8ccv0FpfttWAMJ/akRtz eaofB6s3WAwY9KbtbgkXXNMLPT2lmQjH388LTZGh4SPf+aHW2iSVDWAcl581Q5SIXYFE liJjRPLbQV4uFJOdrUNlK2scnAx+IN4wB/AB/q4RcwljYiXP1hdqx1oIgHMAEtdzhxmG 3edQ== 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=8l5j9lBQzEqvUMbBo3rVyEqIX4yAhHFiDhhogZm+8FU=; b=TsdDl7fyezr2rueFuhQDTQ3HqvZFngrXPllOo/eERlapIc8gMMWPDwB1v1+fzTrr8X 7iP+fP4NqDPG3yBemCh+G2/tuVV0NjRT4lt0jB3QjwpyltNqfCEcQbgY8lBqtdd6rsrl CZJi2EtvGhpC7ifSHzKjPG45iQ/NQqqsRORwZp6m9zqix+pqc6JKrXGynoNLG/J43DfH HSdrpOwUENSKCLG/Q6+9vpWokuWBYH+QN5odAtrGe3D5r+nJXjHdTVdGKtqJl+FH/Pon RAz+yx71gDBYeIX2Mn9NGnEwPzxGDvyxGVm0lsS1pI47tGmE29RisWKiB6rpeooUYPm1 a4gA== X-Gm-Message-State: AOAM530tZPkBhkh07trWdCGLENGs/htsAqkNDJpuZj2V1JGiBsxRQ7vY Tq2gkQ1Ph9S/A/QtntDi7rzQEv9MJtq0mjeDlA3kFYhll8pA4Q== X-Google-Smtp-Source: ABdhPJx6LAQTwVJ6X4AFgZaS599iwDruYcaxobNDbxUveyheNom2A/uX9fc+gw+WXtAvhf+Kzr5CWNzMAf8cF/3EXhA= X-Received: by 2002:a05:6808:178d:: with SMTP id bg13mr6720001oib.94.1642666681677; Thu, 20 Jan 2022 00:18:01 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1642588351-27242-mlmmj-037a935e@FreeBSD.org> <5936ab91-e966-2deb-ac9c-a4a5a0a8a29a@puchar.net> In-Reply-To: <5936ab91-e966-2deb-ac9c-a4a5a0a8a29a@puchar.net> From: Mehmet Erol Sanliturk Date: Thu, 20 Jan 2022 11:17:25 +0300 Message-ID: Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work To: Wojciech Puchar Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000bbb5d05d5ff2420" X-Rspamd-Queue-Id: 4Jfb3t2CTNz4qC6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jXm2Ep61; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-3.87 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.92)[-0.921]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.945]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::233:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000000bbb5d05d5ff2420 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 20, 2022 at 10:27 AM Wojciech Puchar wrote: > tried RPI image for 13.0 and RPI3 image 12.3 > both does not boot at all. nothing on serial console at all. > What image should i use for this computer? > > > https://wiki.freebsd.org/arm/Raspberry%20Pi FreeBSD/ARM on the Raspberry Pi family Please see the latest snapshot release messages in related mailing lists . Mehmet Erol Sanliturk --0000000000000bbb5d05d5ff2420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 20, 2022= at 10:27 AM Wojciech Puchar <wojte= k@puchar.net> wrote:
tried RPI image for 13.0 and RPI3 image 12.3
both does not boot at all. nothing on serial console at all.
What image should i use for this computer?




=C2=A0FreeBSD/ARM on the Raspberry Pi family

=

Please see=C2=A0 the latest snapshot re= lease messages in related mailing lists .



Mehmet Erol Sanliturk

<= br>
--0000000000000bbb5d05d5ff2420-- From nobody Thu Jan 20 16:57:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66D911962B9F for ; Thu, 20 Jan 2022 16:57:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfpZz0cdFz3KC1 for ; Thu, 20 Jan 2022 16:57:14 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20KGv6pi028202 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Jan 2022 17:57:07 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642697827; bh=vL1UxtNgInc4vPYlZot5OfhU279whQtpVP185gsQM3U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dE15nhlDkVjW8LttGzwxN6EVwFA7gB3kg5HeJz0F3hwTYkTQH0QraB9yVASzn7M4z N3pKcFFnugm7WQd8PEIJjzc0z1gNk5WvQ0f+l3+EdaYeKCX6pZIU7kpZSRk/GYX4Ja 8DjYEMHWcQEhRCU5xQgn8FpnaFenrAysw0nxbss8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20KGv6wT050375; Thu, 20 Jan 2022 17:57:06 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20KGv5XE050372; Thu, 20 Jan 2022 17:57:06 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 20 Jan 2022 17:57:05 +0100 (CET) From: Wojciech Puchar To: Mehmet Erol Sanliturk cc: FreeBSD Hackers Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: Message-ID: <10768db2-4417-87d-827-e1bae6217f69@puchar.net> References: <1642588351-27242-mlmmj-037a935e@FreeBSD.org> <5936ab91-e966-2deb-ac9c-a4a5a0a8a29a@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3974694515-2031852017-1642697826=:50371" X-Rspamd-Queue-Id: 4JfpZz0cdFz3KC1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=dE15nhlD; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-0.46 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_XAW(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; CTYPE_MIXED_BOGUS(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.965]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-2031852017-1642697826=:50371 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > > https://wiki.freebsd.org/arm/Raspberry%20Pi >  FreeBSD/ARM on the Raspberry Pi family yes i downloaded 2 - RPI3 and RPI. None works. Led lights up, no console both with OTG or over serial port. > > > Please see  the latest snapshot release messages in related mailing lists . > > > > Mehmet Erol Sanliturk > > > > --3974694515-2031852017-1642697826=:50371-- From nobody Thu Jan 20 20:36:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36170195E333 for ; Thu, 20 Jan 2022 20:37:39 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JfvTG3tVlz4WKC for ; Thu, 20 Jan 2022 20:37:38 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-oi1-x233.google.com with SMTP id s127so10682210oig.2 for ; Thu, 20 Jan 2022 12:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1sX7PfmN6AnHyPrjXI+HCCU9zrfpBq7S+cJUl1XMQQA=; b=lXM6vmc8yWN/EVpXaV5Gtjqr3YkHBRY5q23RTIc42TROyl/+ycKhf4qjW/7ETIkQTh cu8F7Q30IyQy7Pn09+aoFrReTgm9ifpze9tIHVK+jPOSw0SZCZ2pWlG4EPGkCp3yljYV Sg8pIXXXym4B733XrqrKiasPPLwKTRdqKVXBIMs5ItYHUhlB1RDew0idafuMqkqUnFdz 1dZUyA3RfJv+tUiZZCzBlJODitRDrbu7LFBq4rWbY+D98CoAjKW3Ixtn0ErcI3IRYAuk DCQV2Kvva+0et3fSAmfk4MwuFxgQjQvWmURSfC1W9e1xL2kJ0cCEUnlbGw/TaiwbsS6I RaOw== 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=1sX7PfmN6AnHyPrjXI+HCCU9zrfpBq7S+cJUl1XMQQA=; b=VSKncZi3Jdhj6/5FcIDlRG7/O/mncN+M20axRP1tPEIp00OWp8Smst+YLujs1rmRda PfQX2Qdd2DUySHfQVUxCCPtc/Ohf7MpyqWgO1IPYtyDRcZ+Ug5/V11Ls+psQ2fUw3siP kT4RBkRP8HK8eRPfZp/j6/XzlY+Azj8nhvSzRhoUwYG6vWXpuElW5ExIouM8Sfy3FHa4 J8ZckAvtGVxgHBqRRiU9tiEjbIhxvyk7Y5QNQCdwpPZii0IMR9xLYZU1JdnE3NrootzK 5Z5xi32wUUXK8ABlFYSjT/v39P885SdLlbKsMzM9avGL1wSovCBZNL2KQQgL0OxiX1D3 x7jQ== X-Gm-Message-State: AOAM532TdhDwcE+UZuZSgW4tLG3X6ls5r5gkrpxBE+cfP80uNwK//J0H hogTkLD3MeHzOMUrCgLIe5pyfG5Bo9AFSgzNC4cUgieWJsZ++Q== X-Google-Smtp-Source: ABdhPJwFBCIEbpK4YD15AURnK19sCmcu1F3YGgt9pbJ8tggIZVvxbJc0RaTMINZNxJh5x3+Jtok38a0szwyoGxGsE90= X-Received: by 2002:a05:6808:178d:: with SMTP id bg13mr9384345oib.94.1642711051858; Thu, 20 Jan 2022 12:37:31 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1642588351-27242-mlmmj-037a935e@FreeBSD.org> <5936ab91-e966-2deb-ac9c-a4a5a0a8a29a@puchar.net> <10768db2-4417-87d-827-e1bae6217f69@puchar.net> In-Reply-To: <10768db2-4417-87d-827-e1bae6217f69@puchar.net> From: Mehmet Erol Sanliturk Date: Thu, 20 Jan 2022 23:36:55 +0300 Message-ID: Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work To: Wojciech Puchar Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000b6f5ae05d6097884" X-Rspamd-Queue-Id: 4JfvTG3tVlz4WKC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=lXM6vmc8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::233 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::233:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000b6f5ae05d6097884 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 20, 2022 at 7:57 PM Wojciech Puchar wrote: > > > > https://wiki.freebsd.org/arm/Raspberry%20Pi > > FreeBSD/ARM on the Raspberry Pi family > > yes i downloaded 2 - RPI3 and RPI. None works. Led lights up, no console > both with OTG or over serial port. > > https://en.wikipedia.org/wiki/Raspberry_Pi Raspberry Pi https://www.raspberrypi.com/products/raspberry-pi-zero-w/ Raspberry Pi Zero W The Raspberry Pi Zero W extends the Pi Zero family and comes with added wireless LAN and Bluetooth connectivity. You are using Raspberry Pi ZERO . I could not find its CPU version information . It seems that you are selecting an incompatible FreeBSD release or snapshot with its CPU . https://www.itsfoss.net/install-freebsd-on-raspberry-pi-zero-w-pi-4/ Install FreeBSD on Raspberry Pi Zero W & Pi 4 In the above page , the following is written : DOWNLOAD FreeBSD For Raspberry Pi Zero 1. official FreeBSD armv6-RPI-B image downloaded from: ftp://ftp.freebsd.org/pub/FreeBSD/snaps =E2=80=A6 MAGES/12.0 The explicit link is the following : ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/12.0 Here the related CPU version is "armv6" . https://lists.freebsd.org/archives/freebsd-snapshots/2022-January/date.html freebsd-snapshots: FreeBSD Development Snapshot Announcements by date https://lists.freebsd.org/archives/freebsd-snapshots/2022-January/000043.ht= ml New FreeBSD snapshots available: stable/12 (20220113 r371482) From: Glen Barber Date: Thu, 13 Jan 2022 19:55:30 +0000 12.3-STABLE armv6 RPI-B https://www.freebsd.org/where/ Download FreeBSD >From the above page select "RPI-B" : https://download.freebsd.org/releases/arm/armv6/ISO-IMAGES/12.3/FreeBSD-12.= 3-RELEASE-arm-armv6-RPI-B.img.xz OR a snapshot from the below part Development Snapshots an "armv6" one . If "armv6" is wrong , please select the correct CPU version of your board = . Mehmet Erol Sanliturk > > > > > Please see the latest snapshot release messages in related mailing > lists . > > > > > > > > Mehmet Erol Sanliturk > > > > > > > > --000000000000b6f5ae05d6097884 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 20, 2022= at 7:57 PM Wojciech Puchar <wojtek@puchar.net> wrote:
>
> https://wiki.freebsd.org/arm/Raspberry%20Pi
> =C2=A0FreeBSD/ARM on the Raspberry Pi family

yes i downloaded 2 - RPI3 and RPI. None works. Led lights up, no console both with OTG or over serial port.



Raspberry Pi

Raspberry Pi Zero W
The Raspberry Pi Zero W extends the Pi = Zero family and comes with added wireless LAN and Bluetooth connectivity.



Here the related CPU version is=C2=A0 "armv6&quo= t; .


https://lists.freebsd.org/archives/freebsd-snapshots/2022-January/dat= e.html
freebsd-snapshots: FreeBSD Development Snapshot Announ= cements
by date

=

New FreeBSD snapshots available: stable/12 (20220113 r371482)
F= rom: Glen Barber <gjb_at_freebsd.o= rg>
Date: Thu, 13 Jan 2022 19:55:30 +0000
12.3-STABLE armv6 RPI-B

Download FreeBSD

From the above page select=C2=A0 "RPI-B" :
=
OR

a snapshot from the below part

Development Snapshots


= an=C2=A0 "armv6"=C2=A0 one .



If=C2=A0 "armv6" is wrong , please se= lect the correct CPU version of your board .


=


Mehmet Erol Sanliturk



>
>
> Please see=C2=A0 the latest snapshot release messages in related maili= ng lists .
>
>
>
> Mehmet Erol Sanliturk
>
>
>
>
--000000000000b6f5ae05d6097884-- From nobody Thu Jan 20 20:46:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EF1271962A02 for ; Thu, 20 Jan 2022 20:46:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jfvg74s2sz4ZZw for ; Thu, 20 Jan 2022 20:46:11 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642711564; bh=xmVtpaueQrpaHEDUY8uXcJh3j4sFQ5uMpJ92uA9kb5E=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=nfmD5E8wQfxCNLK3Xddqy/e4FLHi8TgyWrqjhNF+5+D3A0e+ZyP07oCXSu6WkmJi25wd66vUR84HJ19Kcym4RpJQ0VTbaPoMH2YmXYnmmlfsFF22DlMcXra9iZlVueMiLahEdcQwGntiG7jsjZ9AkGN3iZHtZoiLszzdHVZtvcP1bny7M4gTgZD8glmka54VNB2y2TLvp7PW12IbJHsCkoISy/D2JHiiL/WljWe1z/VID/NkNLxWs1NrR0OuvIdPs2PEuK3Lny/uA4hGMd/YWfFiW4WuV9/xqcOhT4jsUCGW9Apgq1junJ4zSjCoBgLLIGHZQ3ORrnR58UyM1NdMgw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642711564; bh=c1d1Fxmhr9c1eIBWUOWZdD+Uc1BTUA4WyvMhflVsPKa=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kh94XdzYTWYPBsGgmXdqUPSHvEIpUI8+/uZxejIPoXHkl2W4GYx9rFBwqYhPRfb3aXRXtotdaJ3i4oii0khGutgO0Cb34eP7aeyejUZ+Rd0x75AHDHuf59Kbx5l/8QNBjWNthBSZGCB+gOkGc8OExsKvVagitv3XPqgBAYFQYm4q5J3HY1/KcLNtw3ryC8X95AGKT0uhfRjPEP6xo5X+LiF6+Lgqs1zAZUVEjduB0K8atafmt461g4WjxXer8AYIa+TMaKqVeibAEKm8rlJzfRVeRZ3T+TDajzGalzOlkop1473vsXLYl504un3YHRZVQNJItjD10dydUGTDRqibzg== X-YMail-OSG: .Sq.n8AVM1nc78ZjMj2FNCvQLlQvaExcxv9N29xGpEiJ4R_lJ.FnoSMRkEsBNSg veN_v1OD9etZym1XpoH3jFiEGaV.oLWDs3WH5GWCsxmdmi9mVIpTYODV9Pl_DmGG22MQZE0E1usX YBpaZxxZeyFSqXmsGzbma2YoJ9BWmu8uCGQ.OhtSb7SxgG7hjqZQVLVIHFtFcClSD9JMfMRGdNjJ xKxGjIAEBmsmaX2iojjg7G6RzCnew7a8iqt2ZeV27lPhGdSuiNDjFRyw3ovRzmdHprIdp9avouau leZqe2X_.Wn_iIQTGRqx3er_Olv4XzRzxsW5Zxq4IDx_eQwb.6N.PD0YWVVjdW1l9Fl3lv.Xrjk. jlqQHnNjC8g435xUbz1DIxauc9lqbQQFXbTuAgteer.rp2BcMCpVg99WKj49L0.XRFu_LFA42cD1 oO28vYXuNdfL._xW1tFo4gSAojTJbaUhu8JyofgwTIJozrS04fIq25aAJJsyfvUJzcsQaHFmkJb8 tccz9gDmsbxGRp.NZ0MfAaBkrSeFhOn4.KK9lVfkESBuANZ7VtM0vX2U1tw0_dpbl9A9TuEs2TMx GDjbh46LdH8S21AxjyzafkUs8o6tXP1o5G06gGGS8NlDtZWTpdndvhyXHX1gk1aLzjF6df_bVPzC xgehQLH7KWOgWBOmXD6j9FrVlbyLtI2ppm6Amd9maAcg8ZZ2FwVkA2kFfbHCFFNL8OTozfYNwCeD FsdmmPuZwH6QQoYdmeXGQbZHYp3RhyfH4iFOlAhLjiczhBuCp.VRcDFGv6Z9nswSAo06RxOIe0.W PutoVsLq.h9CUquls4z3h6QPNvlRBiDcgb1hl8KcX2ntTcielr85ZWteP7cMGpr_PrhrlG7Uz5N9 7B6wAvgYDWYD5wSNNjsQbu5vebqdlAg7S.FyY8yeerT8wmy6hYPnJF8etnZk6QyywoIaecfGRhe3 8xsTE6RQjvsmwEcmLt5aMd9GdmqLmGsDqwEnh2n5ep9OKejUH2Nm6ivkNKfPh_fpLhEYaGl_ERxJ 9KOepgyiJkC5dCuPKfB3ama2Fejy3Fb559bXwkHYDUjjRiFh3.zgQUWoMQMcNvlWx6mCnEi8tcMv PeFo.3FjlG.nwINWlDjzo5RnvpyPiSq8OvGxyIz3z1LjIxg8S3b1jfmkB54TmiDmNsg1GtAqZAaj NIfzciD8KQDmtVYa9KKTlKpSsToa9RfDSymhby3VB7j.Vfr5DR4Ioyn58DXBtYe9F100rYBAIaz3 glPVhMpVCrZGtBQUJsX5gLhiu8GTXcDQFB5HAm8pbkQkWQCirDArmvToKRnFREnUquyC4SlWM062 K1DkPFgFxprDVXIya9swARr_8G7P1MaQnPnT6VG8kbw7VgYAEEz6TWOaL0AWKSXB.StCGFiW288h jVv_AdGXdafFNZ.6f60j.DYcY2n_07CF527NHchQ13rkk.cswrESvKc0EINakaSgDNXkbQTh80TJ cTOk7hIDYgmZVviwExHqO5LljsJmzWwXY5iSEUuRbr7tqoB2B5bzfzzerSTI9cYx.3s_5IgNUIqm 2rUo5cbIF3f0kjJjVH6wgnD58b5l6iAPgTmGVMhK6duSGxFak_Fayd_PBZAbO2TCr2howUpyMhl1 BcYIWbv375YHF6poKMiUMLx.E39z_5Bb4JYZbG0Qcz6OtfAbJ6wN5eS8rcRGggvmgyxafCapZ9SE 2Na.Qp3xGPpY7N2LKIEKJaxeaMEFyfxtXT9_21IKCMiScbhU8lOlW5IfyGLiuFNH9m.Tc8.I8uHE 1CqpmwEGGFnQENi.AF_xZxbmBAMPOUtHx737l02YoOlBkdmWRMi5Xa1BdmwKC4eSFMaYpY0X51kM 689h7BmxS4XW3c4coFeK_mjTzHh0om8a_g4t2t1qXa6iXrdz8AK8xLxmx0JS89IWw2m9Py7tCPfi lc3vX3HQioGIie2ovpwFGeeaONz6wiVIv91LQhCiEEy0PmEh10uqL0v_LMTJ.IAX6YhzjHQz18w0 fXiE9zz3wRcWrXU2TbgTaUm9NxR6X.t17_qXv3I2OJ6JtlLkyj8qlaeLbvyUbbdjf9iQ8Xk49Umk JDnnnxAaFKA5u0VEmjiU2Es5FH_EzUtgrK8hHigCvW1fD3NqWVGRTw8RR_CqEhRP9i4YrqVDdHnT _tUvokreEDS2PFNCQ9KwtKk8PwQAuNKKAnN6ByAJpSKVbqZpjGDe3CfE4WHaDErDGln3h7055zcN t1uXE7kqNzdzdFFCWl4gLh3POwBiHyspvAM_MS8w6ZccPa3xX.BmanN_oTS2lHU_.txwQosc19H5 rUU5QS4pFYObrHeAZxIlEEdignFfYswsqYKAcHDGlZWQ7Ae67dI5sxDlj X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 20 Jan 2022 20:46:04 +0000 Received: by kubenode517.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c2d9ad9fd5c9c463b32217b2e5e86e2e; Thu, 20 Jan 2022 20:46:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work Message-Id: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> Date: Thu, 20 Jan 2022 12:46:02 -0800 To: Wojciech Puchar , "freebsd-arm@freebsd.org" , FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> X-Rspamd-Queue-Id: 4Jfvg74s2sz4ZZw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=nfmD5E8w; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.32 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.18)[0.179]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Wojciech Puchar wrote on Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) : > tried RPI image for 13.0 and RPI3 image 12.3 > both does not boot at all. nothing on serial console at all. > What image should i use for this computer? The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W units. That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 relevant. === Mark Millard marklmi at yahoo.com From nobody Thu Jan 20 20:53:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8DB1319681E8 for ; Thu, 20 Jan 2022 20:53:47 +0000 (UTC) (envelope-from alex@protasenko.com) Received: from mail.bkmks.com (mail.bkmks.com [45.79.157.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jfvqt5Nrxz4fy4 for ; Thu, 20 Jan 2022 20:53:46 +0000 (UTC) (envelope-from alex@protasenko.com) Received: from op.localnet (pool-96-242-84-113.nwrknj.fios.verizon.net [96.242.84.113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alex@protasenko.com) by mail.bkmks.com (Postfix) with ESMTPSA id 698C28DD408 for ; Thu, 20 Jan 2022 15:53:40 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.bkmks.com 698C28DD408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bkmks.com; s=mail; t=1642712020; bh=t4CtquhQy5AKfgD7UHD0t8DoKdLUG+5GvZRoza3tDc0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pi4bJdfpMnNGAu/JhN9gSy8uRPfkG00+Y2chIaDp29rMDX/lr5+sWLLPTpC5PXLck 0kAy5kIDXs3eEzHXMdE9Vx7QUDEJHkzy160RO0RTSwrdwUT+1yGiwRa5AW8TAjP8g2 JoEwUrIj+LQciE8a6wmM4NeSmf+Xlru/JE2pzRYM= From: Alex Protasenko To: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work Date: Thu, 20 Jan 2022 15:53:40 -0500 Message-ID: <3800434.EygMn7fWZj@op> In-Reply-To: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2148378.QVy64tNC7p"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4Jfvqt5Nrxz4fy4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bkmks.com header.s=mail header.b=pi4bJdfp; dmarc=none; spf=pass (mx1.freebsd.org: domain of alex@protasenko.com designates 45.79.157.50 as permitted sender) smtp.mailfrom=alex@protasenko.com X-Spamd-Result: default: False [-3.22 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bkmks.com:s=mail]; FREEFALL_USER(0.00)[alex]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[protasenko.com]; NEURAL_SPAM_SHORT(0.84)[0.843]; DKIM_TRACE(0.00)[bkmks.com:+]; NEURAL_HAM_MEDIUM(-0.96)[-0.965]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:63949, ipnet:45.79.128.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.242.84.113:received] X-ThisMailContainsUnwantedMimeParts: N --nextPart2148378.QVy64tNC7p Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii"; protected-headers="v1" From: Alex Protasenko To: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work Date: Thu, 20 Jan 2022 15:53:40 -0500 Message-ID: <3800434.EygMn7fWZj@op> In-Reply-To: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> On Thursday, January 20, 2022 3:46:02 PM EST Mark Millard wrote: > Wojciech Puchar wrote on > > Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) : > > tried RPI image for 13.0 and RPI3 image 12.3 > > both does not boot at all. nothing on serial console at all. > > What image should i use for this computer? > > The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W > units. > > That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 > relevant. > > === > Mark Millard > marklmi at yahoo.com Just in case you're trying to boot off USB stick, that won't work for RPI3 at least with provided boot images. Do use micro SD card to boot. --nextPart2148378.QVy64tNC7p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEpEUgJSMXvtAAevQ/FN3OHn+mGo8FAmHpy9QACgkQFN3OHn+m Go9qQQf8DIqADZfElZ62EbCvYwEPNy9OKl3o1pE/rse3BCuqM8X0ZMWDEAqDogsG U38OedcA2eSTARpnClFyCwJkFRsvGSvX0ylrsXgq2l3faigGBReGWNpGxpKw79hV ZS56wvYUosKvCumi8Wv6x1xDAypgMP3tGXHar58bhvmvmMYd1f62rtxyviWaj4LR UnZPsbf/wSsMtpOq8BnU0i7UkTECCdFdT895JOB/63b9F35aXjtqra0cO8NxEdaO EOJApVeayPDCiHhrg2G+5eiXLCMhZ1ROAlxkD7mXKEI4s/U2K0WcWDjQP1hLzTHk NxWTxagsMpEAzGTeMKRBQvrduBIdtw== =3eEe -----END PGP SIGNATURE----- --nextPart2148378.QVy64tNC7p-- From nobody Fri Jan 21 14:14:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 80866196E410 for ; Fri, 21 Jan 2022 14:14:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgLxF2fXNz3hBW for ; Fri, 21 Jan 2022 14:14:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20LEEsZk051447 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jan 2022 15:14:55 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642774495; bh=ULsgjz6qdx4g8QS3d7G2detWs5vNC2HhjSEDoiCdCi0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ZepPLRfO4ufN5sGQVWhB5PhjX6qJqXExh9qjcfsoyAPDIx/ixmWcymsaCZfQ4RaL3 b7xDxLOIeF+M8Qe5azUyKgMK3zG3nK/hJo/3mOsjXl/PeK7uOt/a8flHeBcCBI7wO4 8GENkUq8iv0LEGGlc1RgGQUOAIMdxjkTUbGLiz+4= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20LEEsck054501; Fri, 21 Jan 2022 15:14:54 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20LEEscJ054498; Fri, 21 Jan 2022 15:14:54 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 21 Jan 2022 15:14:54 +0100 (CET) From: Wojciech Puchar To: Alex Protasenko cc: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: <3800434.EygMn7fWZj@op> Message-ID: <1861fe8f-ff58-ffb0-177f-edf62b9830d0@puchar.net> References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> <3800434.EygMn7fWZj@op> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JgLxF2fXNz3hBW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=ZepPLRfO; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N No i never tried USB boot. recorded now 14.0 RPI image on SD card. plugged SD card to RPI. Plugged USB cable to second port to get OTG. LED blinked for a second then stays lit. Don't see OTG after 2 minutes of waiting. Replugged SD card in my SD card reader and mounted freebsd partition (/dev/da0s2a) /firstboot is still there, /var/log is empty. So i didn't start On chip i see "RP3A0-AU" and "2123" any ideas? On Thu, 20 Jan 2022, Alex Protasenko wrote: > On Thursday, January 20, 2022 3:46:02 PM EST Mark Millard wrote: >> Wojciech Puchar wrote on >> >> Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) : >>> tried RPI image for 13.0 and RPI3 image 12.3 >>> both does not boot at all. nothing on serial console at all. >>> What image should i use for this computer? >> >> The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W >> units. >> >> That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 >> relevant. >> >> === >> Mark Millard >> marklmi at yahoo.com > > Just in case you're trying to boot off USB stick, that won't work for RPI3 at > least with provided boot images. Do use micro SD card to boot. > > From nobody Fri Jan 21 14:17:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 33B09196EBF6 for ; Fri, 21 Jan 2022 14:17:58 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgM0j3NqVz3jR4 for ; Fri, 21 Jan 2022 14:17:57 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20LEHtl9053829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jan 2022 15:17:55 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642774676; bh=rVZsmAaCO70Cqe8mObCNC5Rm/IAORLt61u64zk6bQus=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Dq7nuU7oZbS5FDL7aN9Y44FcQgw2MxvL5XeMbQpdO4CYhKnj9CPPu/F5qYbqrSO2K 3L1ka6h5ZeXslFmvs3D1sa68HG6F/j3/ubf1sOxvTTtKl5LinePoJifuaidvHTB0CR U+kShj4PC2fBQPJ0XY3r0RkPiBE5L5466xHtTtfQ= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20LEHtCi054518; Fri, 21 Jan 2022 15:17:55 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20LEHtpB054515; Fri, 21 Jan 2022 15:17:55 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 21 Jan 2022 15:17:55 +0100 (CET) From: Wojciech Puchar To: Alex Protasenko cc: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: <3800434.EygMn7fWZj@op> Message-ID: <37701197-b7d1-29af-9941-1197d010efcf@puchar.net> References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> <3800434.EygMn7fWZj@op> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JgM0j3NqVz3jR4 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=Dq7nuU7o; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> units. >> >> That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 >> relevant. trying the workaround now. From nobody Fri Jan 21 14:20:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2528C197215B for ; Fri, 21 Jan 2022 14:20:24 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgM3W2N3rz3lMQ for ; Fri, 21 Jan 2022 14:20:23 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20LEKKij055606 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jan 2022 15:20:21 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642774821; bh=y/g/+QtHQAvI+nH4oPugtmLVaMk39FkaaeGqwq1CvI8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fAbi7jwxG4z0ZqNtZ+2JaV/AxqpTL+wIDUmBWevhOnNyq6EWsoRPtw6cGrn2YWLYC kMN3qLdINfJ+piFk8Eadw1s4PpsQ7ldFe3yxazhuxDjqT6JrHM4mffHiqL4GS7shlD /Pb34jpWtTWxn+L98VMlwsKtzzwtopPYnmSOBQHM= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20LEKKBI054540; Fri, 21 Jan 2022 15:20:20 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20LEKKeH054537; Fri, 21 Jan 2022 15:20:20 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 21 Jan 2022 15:20:19 +0100 (CET) From: Wojciech Puchar To: Alex Protasenko cc: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: <3800434.EygMn7fWZj@op> Message-ID: <452d4a78-29d4-8d1e-5c4-8e165c45e885@puchar.net> References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> <3800434.EygMn7fWZj@op> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JgM3W2N3rz3lMQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=fAbi7jwx; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N trying git clone and getting firmware. Simply copying files didn't work. LED still stays lit and it does not work. On Thu, 20 Jan 2022, Alex Protasenko wrote: > On Thursday, January 20, 2022 3:46:02 PM EST Mark Millard wrote: >> Wojciech Puchar wrote on >> >> Date: Thu, 20 Jan 2022 08:26:45 +0100 (CET) : >>> tried RPI image for 13.0 and RPI3 image 12.3 >>> both does not boot at all. nothing on serial console at all. >>> What image should i use for this computer? >> >> The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W >> units. >> >> That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 >> relevant. >> >> === >> Mark Millard >> marklmi at yahoo.com > > Just in case you're trying to boot off USB stick, that won't work for RPI3 at > least with provided boot images. Do use micro SD card to boot. > > From nobody Fri Jan 21 14:50:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CED54195CE8B for ; Fri, 21 Jan 2022 14:50:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JgMkZ6VzBz4R2q for ; Fri, 21 Jan 2022 14:50:46 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20LEoibt078791 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 21 Jan 2022 15:50:44 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1642776645; bh=o42bC4XiDuAWl6nZax3tQxN/zDXXJjeoxb74U6tNFJw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SYhewiMqFkVTA0f6jPQMzDe8Yf4WpMXLRUC/tsMlsLEr2fk0GbYa+GKSGdqzaundg ER4gFDEXI94XvJRtT512rDk9+WjAvYhsX03L0mdIYhegQC9cIH1HV/P8CDiq/Uwqd1 3L8FLXb9P112VGIXSzF06KTg5SAjjIvNW5Arz0qo= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20LEoiEo054619; Fri, 21 Jan 2022 15:50:44 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20LEoihR054616; Fri, 21 Jan 2022 15:50:44 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 21 Jan 2022 15:50:44 +0100 (CET) From: Wojciech Puchar To: Alex Protasenko cc: freebsd-hackers@freebsd.org Subject: Re: Raspberry PI zero W (RPI3A0 written on chip) - does FreeBSD work In-Reply-To: <452d4a78-29d4-8d1e-5c4-8e165c45e885@puchar.net> Message-ID: References: <34E9DC69-E04C-4D6D-A102-49FD88EF7C44.ref@yahoo.com> <34E9DC69-E04C-4D6D-A102-49FD88EF7C44@yahoo.com> <3800434.EygMn7fWZj@op> <452d4a78-29d4-8d1e-5c4-8e165c45e885@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JgMkZ6VzBz4R2q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=SYhewiMq; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.39 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.89)[-0.894]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>> tried RPI image for 13.0 and RPI3 image 12.3 >>>> both does not boot at all. nothing on serial console at all. >>>> What image should i use for this computer? >>> >>> The RPI3A0 label shows up in pictures of Raspberry PI zero 2 W >>> units. >>> >>> That would make https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261147 >>> relevant. >>> tested with firmware from git repository as described in bugzilla. The difference is how led blinks at start, then it stays lit and... nothing goes on From nobody Tue Jan 25 03:16:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 983FA19891AE for ; Tue, 25 Jan 2022 03:17:35 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JjX8t5NMwz3rhT for ; Tue, 25 Jan 2022 03:17:34 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-yb1-xb2b.google.com with SMTP id g81so57623884ybg.10 for ; Mon, 24 Jan 2022 19:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=OjX3Q6YP3qAP29N8R3goC6Ci+5hAl0z3MBBIeKCjq7U=; b=GcoBKtXnY+N3chCUBYaabVVLHNWT+B0zPhLToI2rE3I5pOEGhBtLTb4WDSAUlllUa/ tpS3Y07TSNiex2LNSpJVGKtwnesE1SKkpmp1+qzvf4U6JvUxOmMvPZ4QA5qUHrE3gQQC /oCmMdmaoZBc/4aoIySTzf8/P9s+vV3Xs+NTxHrJVXyZv0SQ/QG+2fnjsl7WZXgvPtuQ 3O/6uSVDh+lC66ORftP4OGxhRgC19bsmf0woaKhm9hPlNK66rfC1kKxUYQ/K3FJhAdv/ fBXy4fBl51d+Knc7yJQrIZe4l3UB+wLEnfnuZHifUai7gtbu/ntjBk4Vbvd6utodbt94 3woQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OjX3Q6YP3qAP29N8R3goC6Ci+5hAl0z3MBBIeKCjq7U=; b=JFqZHS0vq7h4UDE0LiDp7qV8hfyDxb+s1X9LWYfZtka4f2OUp+237FUsvkX5w0rljT UKj9jHUHbkraqYWBclvQ831KfYO6QNMOl/jVuAPHaf89L254HtyvH3OkvyVOnuBu7zdd JocM41UYyVfYpg5cAr4aykwy+qtgq7nlUyrvkaC7cuUL3/TPaw/22WCGJojCPXJnov93 CQ4QMEk9G9HmdailFAoZdzcWmJE8MXu94BOCrXJWJl+PZcqSuQjUI/fO0Pj0yca1qdFR pt1t1ol6JDNVVO3frWT6KT+34505ThGCa2UoKnoxyluqnVwCTIT5FQKiIeM2TB363IDs Qn+w== X-Gm-Message-State: AOAM533tRNGy2L44i3s8XIoVkHEBadHs6MKu53BvZ8GAb5XEJbu3vMcy P2CJvoF7t0U+qFDasxsQbXm65NdP128jr/4sjAR0Yik9 X-Google-Smtp-Source: ABdhPJx8lhxnQPpePF0J+JlrzAdgrGdST83eccTcUN4wZtdwW1pgJ+hxTbjNNf/WRmkovWydhkOu1rkQzwlPrlGdbv0= X-Received: by 2002:a25:8e0d:: with SMTP id p13mr5830563ybl.155.1643080653884; Mon, 24 Jan 2022 19:17:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Lee D Date: Mon, 24 Jan 2022 22:16:58 -0500 Message-ID: Subject: Integrating UFS read-only code into my boot loader To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JjX8t5NMwz3rhT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=GcoBKtXn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of embaudarm@gmail.com designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=embaudarm@gmail.com X-Spamd-Result: default: False [-1.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.20)[-0.200]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi, I am using my own bootloader to directly boot the FreeBSD 13 kernel on my custom Zynq (ARM) board. Currently, I load the kernel from a small DOS partition. I would like to try to integrate UFS into my bootloader so that I can read the kernel, modules and configuration directly from the UFS partition. It only needs to read, not write. In FreeBSD 11.0.1 there was file called: /src/sys/boot/common/ufsread.c That file seemed to be a complete UFS reader in a small, self contained package. It was deleted from the tree a long time ago though. Is this file still good for use with a UFS filesystem created with FreeBSD 13? I saw the whole package of files under /src/sys/ufs/, but those are deeply integrated into the world of the FreeBSD kernel and seem difficult to extract for use in a standalone, bare-metal bootloader program. Also open to other suggestions for how I might integrate UFS into my bootloader. Thanks, Lee From nobody Tue Jan 25 03:23:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00F74198E048 for ; Tue, 25 Jan 2022 03:24:09 +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 4JjXJS4KtBz3wPr for ; Tue, 25 Jan 2022 03:24:08 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643081048; h=from:from:reply-to:subject:subject:date:date: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=8oGGs5myaYMgDRh9+NeRwzGdqTW+F0Yv8TliYOzsVjE=; b=rE7GMlc8UrldnX2bqhxony+FeYAFOOxEgJ5flDdX5QKgzZReAOWSCvyzQffmm0bbS0Wa6n b7nU2OxPku37++4xj5GG0aNiUKU5o294fPFh3suyDjp0zqxPDr3d8WL8Z6MbjEaOUBha2D 6dOhegQxvALnRcmXOl0Oebe6Y8bUJHUbOkBoRAUXAi3NCqntIalBIcJEHUvtr9mUS+Qr4P quGK0nife+DrAHhB2D9wCueLM0yAALu4icA43mO8ZSPXeHbtn3UkYN8AxBmGSuD1xvo+ad JNYskVD/UtypOsPIW36VhezTO0inGmcx5Co6dsxFW4Ckur3omvA6SloEBxicDA== Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 71FD255B3 for ; Tue, 25 Jan 2022 03:24:08 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f175.google.com with SMTP id h4so1563239qtm.2 for ; Mon, 24 Jan 2022 19:24:08 -0800 (PST) X-Gm-Message-State: AOAM5324W/yqSsBwd5KS5oTgs7wwoGQmfjfohL/je4DYX2dEHvmYT28s FcMw+GfNPY+6VjG0sHf2G/E1Q8QI9MMoVvD01RQ= X-Google-Smtp-Source: ABdhPJwJFvBCjV2aWCvYweqbvZfjWlo1YVuHA1wdFFlsSxHOAlvklcl3i/ZTqFv4CtvHE9zs1OuyIAabQjekk4RjkOM= X-Received: by 2002:a05:622a:148d:: with SMTP id t13mr15008869qtx.86.1643081048117; Mon, 24 Jan 2022 19:24:08 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Mon, 24 Jan 2022 21:23:57 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Integrating UFS read-only code into my boot loader To: Lee D Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643081048; h=from:from:reply-to:subject:subject:date:date: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=8oGGs5myaYMgDRh9+NeRwzGdqTW+F0Yv8TliYOzsVjE=; b=ljz3eWJGcAEc6yYAd7ji5+Oo9zQFvnblCYBR6+Qi16o34m1RHGOV8pEd+IdW1wvFyLadeG 21430iNk9hoRnYVzEragF8bhJLyylXNIqm3cVb0IAEVgKY3WC9oxkz4xFo8lZlm94+nzMj 9uGoGZecrl++dFDiaYsZX4VWy12UQ2RAeR6paxvkpecOWBmTMyt/lL8Y+6/ClYsNZR7H8g mEbQdNfybwyu4OnOVCxyGt5wGaOjVjlyjgDJifUpB/MPRFC2kXpDvoCO0DIwJ10QMuUp7j gPsahUnfhMZr7e1d77ESwm1pHLO0vdGjvQnQacprGJiL0JEHQXkVHwv13xofsQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643081048; a=rsa-sha256; cv=none; b=wfLw40gZlRlDSxTNOxPKjbqA3hD/2JOz25pQP2xA0CGb+JRpub091WduSfEi5KyHWuKcyd sAR54J0AJe78LO9qokdBYuSvnmNjfZEoXlLnJ5YNvJ8rD6Vxd917n0JjmIbN5gnY9Oc8nU t1RnP42xpbuG/3KHMZdoYFF/SWvRtlZKUWReX8wrjg0yCCN+vw6T1JztwRENSbTRJSeirl JHSFPaqIGgG0JmCQgJt/SGwnNt7lXaL2S4+7JpADIp/1n415aZONP3AGEwJ+XU3IWwTQOj gFpaKC3qstV4EU5nq/78/G6pybFGrSdj/XsMTD2JB2/QFCIsqcmcfKWDyR15CQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 24, 2022 at 9:17 PM Lee D wrote: > > Hi, > > I am using my own bootloader to directly boot the FreeBSD 13 kernel on > my custom Zynq (ARM) board. > > Currently, I load the kernel from a small DOS partition. > > I would like to try to integrate UFS into my bootloader so that I can > read the kernel, modules and configuration directly from the UFS > partition. It only needs to read, not write. > > In FreeBSD 11.0.1 there was file called: /src/sys/boot/common/ufsread.c > > That file seemed to be a complete UFS reader in a small, self > contained package. It was deleted from the tree a long time ago > though. > Moved- it was moved to stand/libsa/ufsread.c > Is this file still good for use with a UFS filesystem created with FreeBSD 13? > > I saw the whole package of files under /src/sys/ufs/, but those are > deeply integrated into the world of the FreeBSD kernel and seem > difficult to extract for use in a standalone, bare-metal bootloader > program. > > Also open to other suggestions for how I might integrate UFS into my bootloader. > > Thanks, > > Lee > From nobody Tue Jan 25 20:59:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AA49F1975A7E for ; Tue, 25 Jan 2022 20:59:59 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jjzkk4kg0z4gP3 for ; Tue, 25 Jan 2022 20:59:58 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 20PKxj1S033925 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 25 Jan 2022 15:59:51 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> Date: Tue, 25 Jan 2022 15:59:45 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Which disk is which? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4Jjzkk4kg0z4gP3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N "zpool status' tells me which disks are in my pool by diskid. But smartd log messages refer to hardware unit numbers (adaN). How do I convert between the two? -- George From nobody Tue Jan 25 21:03:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 531F8197AA7E for ; Tue, 25 Jan 2022 21:03:28 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jjzpl1bsmz4kkt for ; Tue, 25 Jan 2022 21:03:27 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 20PL3Ksp033963 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 25 Jan 2022 16:03:26 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <389bf8a2-fe21-dd61-5b80-e2e0e6cfefc3@m5p.com> Date: Tue, 25 Jan 2022 16:03:20 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Which disk is which? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> From: George Mitchell In-Reply-To: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4Jjzpl1bsmz4kkt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 1/25/22 15:59, George Mitchell wrote: > "zpool status' tells me which disks are in my pool by diskid.  But > smartd log messages refer to hardware unit numbers (adaN).  How do I > convert between the two?                                   -- George Never mind, I found it in dmesg, where the disk serial number (which happily corresponds to the diskid) is given with the unit number. Please excuse the noise ... -- George From nobody Tue Jan 25 21:04:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 83AD4197B61C for ; Tue, 25 Jan 2022 21:04:21 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jjzql5XX1z4lHd for ; Tue, 25 Jan 2022 21:04:19 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 20PL4Io9031483; Tue, 25 Jan 2022 21:04:18 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 20PL4I5j031482; Tue, 25 Jan 2022 13:04:18 -0800 (PST) (envelope-from david) Date: Tue, 25 Jan 2022 13:04:18 -0800 From: David Wolfskill To: George Mitchell Cc: FreeBSD Hackers Subject: Re: Which disk is which? Message-ID: Mail-Followup-To: David Wolfskill , George Mitchell , FreeBSD Hackers References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7qTxjb/r1FPaLtAW" Content-Disposition: inline In-Reply-To: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> X-Rspamd-Queue-Id: 4Jjzql5XX1z4lHd X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-4.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[catwhisker.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --7qTxjb/r1FPaLtAW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: > "zpool status' tells me which disks are in my pool by diskid. But > smartd log messages refer to hardware unit numbers (adaN). How do I > convert between the two? -- George If your hardware supports it, "sesutil show" may be helpful here. Peace, david --=20 David H. Wolfskill david@catwhisker.org "We can either be loyal to Donald Trump or we can be loyal to the Constitution, but we cannot be both." - Elizabeth ("Liz") Cheney See https://www.catwhisker.org/~david/publickey.gpg for my public key. --7qTxjb/r1FPaLtAW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYfBl0l8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1PctAQDW5kjzFtT5GLM+vA/6bPp9SGgT0p+olUqxISTWmFQ7agD8C5dUMt5MKoGB 4CbdSPKSLYs/1DAH/ahuTME3VSaYtQA= =Kqig -----END PGP SIGNATURE----- --7qTxjb/r1FPaLtAW-- From nobody Tue Jan 25 22:38:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F3F851970807 for ; Tue, 25 Jan 2022 22:38:43 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk1wg1YDjz3vRT for ; Tue, 25 Jan 2022 22:38:43 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 20PMcW1L034203 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 25 Jan 2022 17:38:38 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <4b2820ca-a342-9719-6d7e-ce91395e8c51@m5p.com> Date: Tue, 25 Jan 2022 17:38:32 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Which disk is which? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4Jk1wg1YDjz3vRT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 1/25/22 16:04, David Wolfskill wrote: > On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: >> "zpool status' tells me which disks are in my pool by diskid. But >> smartd log messages refer to hardware unit numbers (adaN). How do I >> convert between the two? -- George > > If your hardware supports it, "sesutil show" may be helpful here. > > Peace, > david > Wow, I never even heard of the "ses" device, but I seem to have one. But "sesutil show" is not at all helpful -- says "ses0:" and nothing else. ("sesutil status" at least says "ses0: OK".) -- George From nobody Tue Jan 25 23:02:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 44029197FD04 for ; Tue, 25 Jan 2022 23:02:33 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk2S842BZz4ZhJ for ; Tue, 25 Jan 2022 23:02:32 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f54.google.com with SMTP id z25-20020a0568301db900b005946f536d85so27882780oti.9 for ; Tue, 25 Jan 2022 15:02:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2r9sB23iMfTYYYERFAkM/EO3PyYouMJRgFwjcVrL7tQ=; b=6osZpuY7dpj1Ms3VjQ6AX+QpoF3i92TXSLkPe+fNVRZVg27ypoZmdPXBGhVRn+DSlo BoOQxorTHN4NuSFjE8O/XSNEGPN4ZBGicz/+fVV9UaJPE9zh/yCJ9MLdlQPuDycKlVfp 5EumIVGyq9rpp7Pdstt9y6AScBWeE31/sl1CuC1rjEjWazmktu9JHe7CAfg/CJ/jVQyg mOn8U+MaKtWuUDIndm/yMxBDzOGQ/qVe9El969OtMLSGSh3DGxO0CO0a0Yfuot6MBn5o 8Ydc+w5NVgfnbtutkCBKoBZSARl4u/MRXQ8wQQjTtVZrVNW0f6FuIfTrI4Nm5242WJWL RFSA== X-Gm-Message-State: AOAM533LAATaU+/6YeJHBasUgv7a0+5KxT05lOnOxAY5Cp5ztb5dajQ4 ogLwoYsmnBjhV/pFVusXu5AndRm8D5JEYzJbBJ2yJ0o+ X-Google-Smtp-Source: ABdhPJwHr8P8XeWf5NEgjiW/vuYYgJmVQ72XJAO0aFxEkN+sIerHzBDKziyNHzH0kGDiqoC76I8ahucClC8asPQzdZ4= X-Received: by 2002:a9d:6210:: with SMTP id g16mr16537023otj.371.1643151746142; Tue, 25 Jan 2022 15:02:26 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> <4b2820ca-a342-9719-6d7e-ce91395e8c51@m5p.com> In-Reply-To: <4b2820ca-a342-9719-6d7e-ce91395e8c51@m5p.com> From: Alan Somers Date: Tue, 25 Jan 2022 16:02:15 -0700 Message-ID: Subject: Re: Which disk is which? To: George Mitchell Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Jk2S842BZz4ZhJ 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 [-1.91 / 15.00]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.54:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.912]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.54:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 25, 2022 at 3:39 PM George Mitchell wrote: > > On 1/25/22 16:04, David Wolfskill wrote: > > On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: > >> "zpool status' tells me which disks are in my pool by diskid. But > >> smartd log messages refer to hardware unit numbers (adaN). How do I > >> convert between the two? -- George > > > > If your hardware supports it, "sesutil show" may be helpful here. > > > > Peace, > > david > > > Wow, I never even heard of the "ses" device, but I seem to have one. > But "sesutil show" is not at all helpful -- says "ses0:" and nothing > else. ("sesutil status" at least says "ses0: OK".) -- George That sounds like you only have an SGPIO device, which is builtin to most SATA controllers, and is almost useless. BTW, you can also use "geom disk list" to correlate device names to diskid. From eugen@eg.sd.rdtc.ru Wed Jan 26 03:20:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9AA74196E64D for ; Wed, 26 Jan 2022 03:20:42 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jk8B03wsvz3lZh for ; Wed, 26 Jan 2022 03:20:39 +0000 (UTC) (envelope-from eugen@eg.sd.rdtc.ru) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 20Q3KVl5074487 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Jan 2022 03:20:32 GMT (envelope-from eugen@eg.sd.rdtc.ru) X-Envelope-From: eugen@eg.sd.rdtc.ru X-Envelope-To: george+freebsd@m5p.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTP id 20Q3KUPV080778; Wed, 26 Jan 2022 10:20:30 +0700 (+07) (envelope-from eugen@eg.sd.rdtc.ru) Received: (from eugen@localhost) by eg.sd.rdtc.ru (8.16.1/8.16.1/Submit) id 20Q3KUBH080777; Wed, 26 Jan 2022 10:20:30 +0700 (+07) (envelope-from eugen) Date: Wed, 26 Jan 2022 10:20:30 +0700 From: Eugene Grosbein To: George Mitchell Cc: FreeBSD Hackers Subject: Re: Which disk is which? Message-ID: <20220126032030.GA80544@rdtc.ru> References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4Jk8B03wsvz3lZh X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of eugen@eg.sd.rdtc.ru has no SPF policy when checking 2a01:4f8:c2c:26d8::2) smtp.mailfrom=eugen@eg.sd.rdtc.ru X-Spamd-Result: default: False [-0.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[eugen@grosbein.net,eugen@eg.sd.rdtc.ru]; R_SPF_NA(0.00)[no SPF record]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[eugen@grosbein.net,eugen@eg.sd.rdtc.ru] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: > "zpool status' tells me which disks are in my pool by diskid. But > smartd log messages refer to hardware unit numbers (adaN). How do I > convert between the two? -- George diskid is disk serial number with "DISK-" prefix and there is diskinfo(8) command in base system that shows it, too: # diskinfo -v /dev/ada1 | grep ident WD-WMAY04452117 # Disk ident. # ls /dev/diskid DISK-WD-WMAY04452117 # smartctl -a /dev/ada1 | grep Serial Serial Number: WD-WMAY0445211 From nobody Wed Jan 26 09:01:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 81A0F1968491 for ; Wed, 26 Jan 2022 09:01:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkHl70dLhz4Qrk for ; Wed, 26 Jan 2022 09:01:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B91A0892AF; Wed, 26 Jan 2022 09:01:14 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 20Q915aU079766 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Jan 2022 09:01:05 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 20Q913h6079761; Wed, 26 Jan 2022 09:01:03 GMT (envelope-from phk) Message-Id: <202201260901.20Q913h6079761@critter.freebsd.dk> To: Eugene Grosbein cc: George Mitchell , FreeBSD Hackers Subject: Re: Which disk is which? In-reply-to: <20220126032030.GA80544@rdtc.ru> From: "Poul-Henning Kamp" References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> <20220126032030.GA80544@rdtc.ru> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <79759.1643187663.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2022 09:01:03 +0000 X-Rspamd-Queue-Id: 4JkHl70dLhz4Qrk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N -------- Eugene Grosbein writes: > On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: > > > "zpool status' tells me which disks are in my pool by diskid. But > > smartd log messages refer to hardware unit numbers (adaN). How do I > > convert between the two? -- George > > diskid is disk serial number with "DISK-" prefix > and there is diskinfo(8) command in base system that shows it, too: Strictly speaking the correct command to use is "glabel status" (or "glabe= l list"). -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Wed Jan 26 09:17:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 20ADB1974B17 for ; Wed, 26 Jan 2022 09:18:04 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkJ6M0p4pz4Xms for ; Wed, 26 Jan 2022 09:18:02 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 20Q9Hsml056730 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Jan 2022 10:17:55 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1643188675; bh=hKdIca5x6hYc25jMrQ3X+CDPKP3VyVUZALDx7PGwJ+k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ljRvlC5QlBK1JjH2oJWqRqQkap/zYRC/Nh4BckolGEZDKT7RcOaBKaeKp11qPCfh2 d1SN+g3MG6PiECpaeheiu3hf75hNCi+zd4cye/J6a2Ll4PUs5fYSqzgN1b5ZF8MUzQ tY4iHEsCPRgph0nMGz2B+4TUhtdMYopKQ5s6Akck= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 20Q9Hsdp082053; Wed, 26 Jan 2022 10:17:54 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 20Q9HslQ082050; Wed, 26 Jan 2022 10:17:54 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 26 Jan 2022 10:17:54 +0100 (CET) From: Wojciech Puchar To: Poul-Henning Kamp cc: Eugene Grosbein , George Mitchell , FreeBSD Hackers Subject: Re: Which disk is which? In-Reply-To: <202201260901.20Q913h6079761@critter.freebsd.dk> Message-ID: References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> <20220126032030.GA80544@rdtc.ru> <202201260901.20Q913h6079761@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JkJ6M0p4pz4Xms X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=ljRvlC5Q; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-1.00 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_TLS_LAST(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.1.144.90:from] X-ThisMailContainsUnwantedMimeParts: N On Wed, 26 Jan 2022, Poul-Henning Kamp wrote: > -------- > Eugene Grosbein writes: >> On Tue, Jan 25, 2022 at 03:59:45PM -0500, George Mitchell wrote: >> >>> "zpool status' tells me which disks are in my pool by diskid. But >>> smartd log messages refer to hardware unit numbers (adaN). How do I >>> convert between the two? -- George >> >> diskid is disk serial number with "DISK-" prefix >> and there is diskinfo(8) command in base system that shows it, too: > > Strictly speaking the correct command to use is "glabel status" (or "glabel list"). > There are no "correct" ways in unix. There are just different ways From nobody Wed Jan 26 09:22:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D68C0197876C for ; Wed, 26 Jan 2022 09:22:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkJCJ6Rr7z4bkP for ; Wed, 26 Jan 2022 09:22:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 5DBCC89295; Wed, 26 Jan 2022 09:22:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 20Q9M93P083750 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Jan 2022 09:22:09 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 20Q9M8dg083749; Wed, 26 Jan 2022 09:22:08 GMT (envelope-from phk) Message-Id: <202201260922.20Q9M8dg083749@critter.freebsd.dk> To: Wojciech Puchar cc: Eugene Grosbein , George Mitchell , FreeBSD Hackers Subject: Re: Which disk is which? In-reply-to: From: "Poul-Henning Kamp" References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> <20220126032030.GA80544@rdtc.ru> <202201260901.20Q913h6079761@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83747.1643188928.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Jan 2022 09:22:08 +0000 X-Rspamd-Queue-Id: 4JkJCJ6Rr7z4bkP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N -------- Wojciech Puchar writes: > > Strictly speaking the correct command to use is "glabel status" (or "g= label list"). > > > There are no "correct" ways in unix. There are just different ways In this case glabel /is/ the correct way, because ZFS might be attached to labels not related to the physical disk, for instance GPT labels or UUIDs. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Wed Jan 26 17:40:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BA4D3196D897 for ; Wed, 26 Jan 2022 17:40:54 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkWGZ081cz4rVq for ; Wed, 26 Jan 2022 17:40:53 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 20QHehDA038072 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 26 Jan 2022 12:40:49 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <6cc04047-f132-1edc-b9b5-1e1d3ff0f631@m5p.com> Date: Wed, 26 Jan 2022 12:40:43 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Which disk is which? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5d4569a7-3198-761e-9fd0-c53567ecb3ea@m5p.com> <20220126032030.GA80544@rdtc.ru> <202201260901.20Q913h6079761@critter.freebsd.dk> <202201260922.20Q9M8dg083749@critter.freebsd.dk> From: George Mitchell In-Reply-To: <202201260922.20Q9M8dg083749@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4JkWGZ081cz4rVq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-0.46 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-0.27)[-0.274]; MIME_BASE64_TEXT(0.10)[]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N T24gMS8yNi8yMiAwNDoyMiwgUG91bC1IZW5uaW5nIEthbXAgd3JvdGU6DQo+IC0tLS0tLS0t DQo+IFdvamNpZWNoIFB1Y2hhciB3cml0ZXM6DQo+IA0KPj4+IFN0cmljdGx5IHNwZWFraW5n IHRoZSBjb3JyZWN0IGNvbW1hbmQgdG8gdXNlIGlzICJnbGFiZWwgc3RhdHVzIiAob3IgImds YWJlbCBsaXN0IikuDQo+Pj4NCj4+IFRoZXJlIGFyZSBubyAiY29ycmVjdCIgd2F5cyBpbiB1 bml4LiBUaGVyZSBhcmUganVzdCBkaWZmZXJlbnQgd2F5cw0KPiANCj4gSW4gdGhpcyBjYXNl IGdsYWJlbCAvaXMvIHRoZSBjb3JyZWN0IHdheSwgYmVjYXVzZSBaRlMgbWlnaHQgYmUNCj4g YXR0YWNoZWQgdG8gbGFiZWxzIG5vdCByZWxhdGVkIHRvIHRoZSBwaHlzaWNhbCBkaXNrLCBm b3IgaW5zdGFuY2UNCj4gR1BUIGxhYmVscyBvciBVVUlEcy4NCj4gDQpUaGFua3MgdG8gYWxs IGZvciB5b3VyIGhlbHAuICBJJ3ZlIGxlYXJuZWQgYWJvdXQgInNlcyIgZGV2aWNlLA0KZGlz a2luZm8gKG5laXRoZXIgb2Ygd2hpY2ggSSBrbmV3IGFib3V0IGJlZm9yZSksIGFuZCBnbGFi ZWwhDQooLS10aG91Z2ggZ2xhYmVsIGlzIHNvbWV3aGF0IG1vcmUgdmVyYm9zZSB0aGFuIG5l Y2Vzc2FyeSBmb3IgdGhlDQpvbmUgaXNzdWUgYXQgaGFuZC4pICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gR2VvcmdlDQo= From nobody Thu Jan 27 21:34:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C3EB197A768; Thu, 27 Jan 2022 21:34:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f181.google.com (mail-il1-f181.google.com [209.85.166.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlDPc4MM5z4hpZ; Thu, 27 Jan 2022 21:34:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f181.google.com with SMTP id z7so3723855ilb.6; Thu, 27 Jan 2022 13:34:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=pCmTekoxF53GYKehsu29xGJx/BnbKO4H/2W+6AfCCCw=; b=oiGtDvnkRbvLD3iePiI7y/ZQf5eDwC+Pcy7DueA7LL3YNaIqdINk9k6QEmr0OX8JFT 1IUMTzr5Jr9e1WFWsbqaiOa/ll3zemE1ezNRq9He/CfcAYrLnGx0l7Ct4COzvlZ0kpnc nNVi4BIqLm0R9EuG1QJH6N6Wb1M5BygwPQ0IuENSl/5E8xEzkJ3Y2660CK0fW6NtVLGW kwbJ0+VX2BtIwx2MoKeo768/kMQifegRuNbXFbPf6A2zdxUGC9PdvYT38y51S4PbxGK0 IOgoa3jdp3U1vJ9P4RiwvXs6EI766azRuE8+vuGd79lJzxqLKJ7ENzJdJsluDnJFaoOd klyQ== X-Gm-Message-State: AOAM531Hx0glhHeP5LN6HFFuNcM64vF+7AQ+VJ5LdQMYM/nqoZKyiUGT ZoSZ8tFwcUb3+GHv8SxDt3tOuXPMjyvWh1EN9crsRqO9 X-Google-Smtp-Source: ABdhPJzUZnk9z//hwccn0HIXaprJZks/fzpoe2QjbnslJUn3zrg5/s+1Rpe2uEZzZMYwoEaQ2Mc+jbB4pOrdI8l7Y4I= X-Received: by 2002:a05:6e02:17c6:: with SMTP id z6mr4092398ilu.75.1643319261673; Thu, 27 Jan 2022 13:34:21 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Thu, 27 Jan 2022 16:34:10 -0500 Message-ID: Subject: Dragonfly Mail Agent (dma) in the base system To: FreeBSD Hackers Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlDPc4MM5z4hpZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.181 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.181:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.181:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) which accepts mail from a local Mail User Agent (MUA) and delivers it locally or to a smarthost for delivery. dma does not accept inbound mail (i.e., it does not listen on port 25) and is not intended to provide the same functionality as a full MTA like postfix or sendmail. It is intended for use cases such as delivering cron(8) mail. Since 2014 we have a copy of dma in the base system available as an optional component, enabled via the WITH_DMAGENT src.conf knob. I am interested in determining whether dma is a viable minimal base system MTA, and if not what gaps remain. If you have enabled DMA on your systems (or are willing to give it a try) and have any feedback or are aware of issues please follow up or submit a PR as appropriate. From nobody Thu Jan 27 22:50:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B0F5F1995CF4; Thu, 27 Jan 2022 22:50:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlG5l4MB9z3qpq; Thu, 27 Jan 2022 22:50:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643323851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lfmBjeN6PV3N95QxdSk6caN+J9VTUoKkd8zURRcxcOY=; b=ufcrqGEZoVVhDcj+4zkK5D3qToK2KUWzIzog6zGNu34AoQ6CSh0yFXot5U25RGtAYILxwV GdjsNDERNxcscWbElwoyDLLafGHLG/fL31y52bp4n9XQfHlhy23J1AGMOFKm92SubngDzP wAm3EciEy50fLcTgRXCTT7G+z3Muwys3Tuv1/djfFDwzeDwhgd33UZnGHl3kQdkHUAnIzp GFJtDrPCdQvg2tCMo4Oe4M7HsedalLcFiL/gFcfBKMwhW2zsp25Pg/f96jCDR4J6xa+tQr yvqELkD98MOC1OaO0x7Ihgb2L+BkVstzmosyAV8N2E4qVAokXU7gVvYec8WXxA== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 047F46EAD; Thu, 27 Jan 2022 22:50:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <642d2921-1011-12fe-69b2-b394282341ae@FreeBSD.org> Date: Thu, 27 Jan 2022 14:50:50 -0800 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Dragonfly Mail Agent (dma) in the base system Content-Language: en-US To: Ed Maste , FreeBSD Hackers Cc: FreeBSD Current References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643323851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lfmBjeN6PV3N95QxdSk6caN+J9VTUoKkd8zURRcxcOY=; b=Zz74tbe8nFHENLDn+vcKx5NMoF7F77WcWM46yuGttBwKf4twF0t/l0x8ZWbZoRSuiM8qn5 CdkYVcbZ3WQFBYhPxyNyDQ/epL5oJbNLbxr903sDnwXvisac+KzEirl1WUMIao5Z2qkzq9 yJchmaII+iO8YIZco8aWx1XdAe0W2QE+/FmDRqlQ3StkD5gf/3n9aGQunyQ+LfzSCWnHV7 mNWifCKb2ht/KUJiVmqok6ccsQJznuwglPMrDlog3jecnLb891x3fyUEydfz0opfIKsDHB O+KccAfj6qJwV6hF0jIaOaZu7vn6bOjSnIMbjMtOIx55/5W/q0Wc8mfFrPgy8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643323851; a=rsa-sha256; cv=none; b=BCyqC3CSlWmBXQz+KqH/ZEdlfw2tNKBFAV+HW8NIvV5sWz3l67zQN7aZevLYMFW1ndKVjp PltiV6LAyFyAbslH3d1QGlHSeK2qye9xHr3jA1azQz9zDAHmlPnKZf03kOshRRKDuzXARo xb5zq0hpGH4htK55qlkOOa5EPUA4JtuoLGmgP7seuIGTFsQlSvqyg5TekmJKtax0TSZi+0 cCvNWxWcPZF5X6wUZX+E/cZ6+18j9WUZnH/ZxWKxw+hWgsgQQHcrv5p8jtMptvrNIs0I0s 2cCA3r9orIc8M8AkoMMGcVVgyew0FYT7+8csGeLYFMupAj+11fuelyB4NI1zwg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 1/27/22 1:34 PM, Ed Maste wrote: > The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) > which accepts mail from a local Mail User Agent (MUA) and delivers it > locally or to a smarthost for delivery. dma does not accept inbound > mail (i.e., it does not listen on port 25) and is not intended to > provide the same functionality as a full MTA like postfix or sendmail. > It is intended for use cases such as delivering cron(8) mail. > > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I've used DMA on systems without local mail accounts to forward cron periodic e-mails just fine. It even supports STARTTLS and SMTP AUTH. I haven't tried using it for simple local delivery to /var/mail/root. -- John Baldwin From nobody Fri Jan 28 00:18:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 68F2E1978712; Fri, 28 Jan 2022 00:19:00 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlJ3R4Y8Pz54qS; Fri, 28 Jan 2022 00:18:59 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [10.5.0.2]) by sdaoden.eu (Postfix) with ESMTPS id BA7A016057; Fri, 28 Jan 2022 01:18:51 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 23B7039C1; Fri, 28 Jan 2022 01:18:50 +0100 (CET) Date: Fri, 28 Jan 2022 01:18:50 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system Message-ID: <20220128001850.FBYGI%steffen@sdaoden.eu> In-Reply-To: References: Mail-Followup-To: Ed Maste , FreeBSD Hackers , FreeBSD Current User-Agent: s-nail v14.9.23-224-g6440afd04d OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4JlJ3R4Y8Pz54qS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-0.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_DN_ALL(0.00)[]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Ed Maste wrote in : |The Dragonfly Mail Agent (dma) is a small Mail Transport Agent (MTA) |which accepts mail from a local Mail User Agent (MUA) and delivers it |locally or to a smarthost for delivery. dma does not accept inbound |mail (i.e., it does not listen on port 25) and is not intended to |provide the same functionality as a full MTA like postfix or sendmail. |It is intended for use cases such as delivering cron(8) mail. | |Since 2014 we have a copy of dma in the base system available as an |optional component, enabled via the WITH_DMAGENT src.conf knob. | |I am interested in determining whether dma is a viable minimal base |system MTA, and if not what gaps remain. If you have enabled DMA on |your systems (or are willing to give it a try) and have any feedback |or are aware of issues please follow up or submit a PR as appropriate. I used it for years and even maintained a package for a Linux distribution (CRUX) until last October, and i think maybe even AlpineLinux before? I know for sure i maintained a package with Author: emaste Date: Fri Oct 27 20:21:09 2017 New Revision: 325047 URL: https://svnweb.freebsd.org/changeset/base/325047 patched on top of it for years. Very basic usage, only local delivery. But i plan to readd the package as part of the postfix-lmdb package i maintain, because, you know, postfix's sendmail(1) and local deliveries need read access to the postfix configuration, and as part of my effort to totally box (unshare + overlay mount) all my daemons which cross ingress/egress (and place their config under /root/hosts/$HOSTNAME), it's need to access /etc/postfix-lmdb is in the way. (The plan is thus to make dma "part of this package" and make it provide /usr/sbin/sendmail, configured to proxy to local SMTP, where postfix then regulary sits.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Jan 28 01:09:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B70DD1986F4F; Fri, 28 Jan 2022 01:10:06 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4JlKBL5bFLz3msZ; Fri, 28 Jan 2022 01:10:02 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 20S19s6Y016665; Fri, 28 Jan 2022 01:09:54 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 20S19sY2016664; Fri, 28 Jan 2022 01:09:54 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> Date: Fri, 28 Jan 2022 01:09:54 +0000 Organization: Dyslexic Fish To: freebsd-hackers@FreeBSD.org, emaste@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Re: Dragonfly Mail Agent (dma) in the base system References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 28 Jan 2022 01:09:55 +0000 (GMT) X-Rspamd-Queue-Id: 4JlKBL5bFLz3msZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-0.13)[-0.132]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Ed Maste wrote: > Since 2014 we have a copy of dma in the base system available as an > optional component, enabled via the WITH_DMAGENT src.conf knob. I thought it was enabled at default! > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I use it on my non-mailservers for delivering both local mail and remote mail (from cron etc. to remote users) via my mailservers as smarthost. It works perfectly. I've been using it for many years. It doesn't run as a daemon - if a message can't be delivered (e.g. smarthost temporarily unavailable), it will be requeued, and the process exits. Don't forget to add the cron entry to retry requeued entries! */30 * * * * root /usr/libexec/dma -q Thus was my only minor "gotcha" - it wasn't obvious from the man pages to add the cron entry (or maybe I just missed it) As for the smarthost configuration, I've successfully used ipv4, ipv6, both on port 25, and non-standard ports. I've also used combinations of non-encrypted, TLS, and opportunistic TLS, - all work as expected. I haven't ever used the smtp-login facility. Cheers, Jamie From nobody Fri Jan 28 01:47:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3BEE8197778A; Fri, 28 Jan 2022 01:47:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlL1q3lWnz4ZmL; Fri, 28 Jan 2022 01:47:43 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id z199so5973529iof.10; Thu, 27 Jan 2022 17:47:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Acb3J3GxLVuitfzzX4zvnY/trFxd2cr7/BBmDaGeuu0=; b=2/Dg5vNv3nNK8Q+u86ndD5+E+CXkbmWL4ETG7I5BwIeN36B2Mune2Ogn2wtae8mUyv o2avkEHf+DhkcmEA55jEQmRCRHM40wx7IALkmrZGvE4H7QPt8MzmodhulUcjYSdxNCtn Dz5UPo93VjB2oxOJ1RO7hMd9p0hXbVibfe480O/6PYh8OI333vdLttDeCeI/NqaSPhOP 4+UCtaHGKj7RuPcp0ItOTSiwEWznSVE4qY41mhQcimCAcNua01iNpCDg+rQevN/5Z+Q0 Na2reUgwMITtftuamgX9ATeKEwifJG55E5F1g73TPgzrgfd7YEOxAzWUEqVEDSfSvGl6 +oKQ== X-Gm-Message-State: AOAM531+7ALYLazbejZRUXMaDT0ZisgfkiD1WC/98iB1OE8uSTnjJH4C CLPU0S4ng9U3Q4r7TIErYklbQa9+ALr8vuUJWbX9FBQh X-Google-Smtp-Source: ABdhPJzsLVpr9ZrfT6oee1iLEcRlvwxevGtVguyKOhDrX4139oFYYLrjvtXnS+NCxigKjU2kVCyvvDlaCi9bFkzyqQw= X-Received: by 2002:a5e:a806:: with SMTP id c6mr3904148ioa.112.1643334457346; Thu, 27 Jan 2022 17:47:37 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> In-Reply-To: <202201280109.20S19sY2016664@donotpassgo.dyslexicfish.net> From: Ed Maste Date: Thu, 27 Jan 2022 20:47:25 -0500 Message-ID: Subject: Re: Dragonfly Mail Agent (dma) in the base system To: Jamie Landeg-Jones Cc: FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlL1q3lWnz4ZmL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.68 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.84)[0.838]; NEURAL_SPAM_SHORT(0.84)[0.842]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.48:from]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.48:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022 at 20:10, Jamie Landeg-Jones wrote: > > Ed Maste wrote: > > > Since 2014 we have a copy of dma in the base system available as an > > optional component, enabled via the WITH_DMAGENT src.conf knob. > > I thought it was enabled at default! Yes, my mistake - by default WITH_DMAGENT is enabled, and /usr/libexec/dma is built. What is not done by default is configuring /etc/mailer.conf to use dma for /usr/sbin/sendmail or /usr/sbin/mailq. From nobody Fri Jan 28 07:57:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D535B197CCB7 for ; Fri, 28 Jan 2022 07:58:00 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlVF354Prz3QLS for ; Fri, 28 Jan 2022 07:57:59 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165022.dip0.t-ipconnect.de [91.22.80.34]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id F0A1A26271 for ; Fri, 28 Jan 2022 08:57:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1643356669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=UOthXL5b50xbmvxx7O2RAbWwHnJ6LKRUi0sneZMM/+s=; b=SqT7HOJ7ni8hspa1Pa4ut4FA48hVeQd7W84wDlUM2GFpQKVru2ALY4bauQUuGa+78Qh22Y zZL8YpKLGpnq2SS38STOHokDnCVsLlRHhOk1JSAjVX7U+lKN3PxajjY2SFeghtbREdyxRT 4cdQptaTdWybEi6fQq37E1SZfdXyIdTjbWyx23V4nb/SoS2Mkz3JxM6PlM+5/IBebWc80I KuzUSQwplXK5Ai016RpqG3RTUdGtF9jnd7TY3yGkET0XIFCvV4+aihQH8azmDWbeD4H9Nx ww57gaTU+2Yb+XsIdHUTnbBAqJUbK/oCnRksE5KjtTzXGrmzcSGtTuVapMnvGg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id C3A958804 for ; Fri, 28 Jan 2022 08:57:45 +0100 (CET) Date: Fri, 28 Jan 2022 08:57:45 +0100 Message-ID: <20220128085745.Horde.kONeD8ytPcUZ6ahvXbVJCdl@webmail.leidinger.net> From: Alexander Leidinger To: freebsd-hackers@freebsd.org Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4JlVF354Prz3QLS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=SqT7HOJ7; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.80.34:received] X-ThisMailContainsUnwantedMimeParts: N Quoting Ed Maste (from Thu, 27 Jan 2022 16:34:10 -0500): > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. I'm using it since years to send the periodic mails as a nullclient to a smarthost (TLS involved). Works even if the system which uses DMA is booting, has a @reboot entry in the crontab and the smarthost exists in a jail of the same machine (little delay in delivery off course). I haven't used it for something else. Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Fri Jan 28 10:16:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7512B198F773; Fri, 28 Jan 2022 10:16:24 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4JlYJl2sHxz3jVx; Fri, 28 Jan 2022 10:16:23 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [192.168.0.252] (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 20SAGGDs064663; Fri, 28 Jan 2022 10:16:16 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Dragonfly Mail Agent (dma) in the base system From: Bob Bishop In-Reply-To: Date: Fri, 28 Jan 2022 10:16:16 +0000 Cc: FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Maste X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4JlYJl2sHxz3jVx X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [1.29 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+mx]; DMARC_NA(0.00)[gid.co.uk]; NEURAL_SPAM_MEDIUM(0.99)[0.990]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > On 27 Jan 2022, at 21:34, Ed Maste wrote: >=20 > The Dragonfly Mail Agent (dma) [etc] We've used it for years on routers and other small boxes to offload mail = from periodic and cron. -- Bob Bishop rb@gid.co.uk From nobody Fri Jan 28 18:04:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 98F461975F30; Fri, 28 Jan 2022 18:04:49 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JlljD6Zhlz4lcQ; Fri, 28 Jan 2022 18:04:48 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f52.google.com with SMTP id r144so8703804iod.9; Fri, 28 Jan 2022 10:04:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MNFtwXB/xUkBewYoqwIPSW2v4RSb9JgYcP5Y81E0w/8=; b=NRN7vDe6LO31ahfd27R81ORi9gMoEI5oSlfNc1L5IDwygNlTloJHk5LQ01jnyGlGOO bAMk4rUxDIKOUXpeC6a35VJzGmTxgfyDNFrisHH93lvCGHX0pkvapFoLOMi9vmmxLTAE +ETTDsh41EhLmoLu04EH2JWTGvfZmiS9ugV3wgcRSKyvNHa8pR9NFQeH1PlO9tuc5qOl dz1q5YsJCyQccn0JevVbvRiEQmlYC8uDO0+9DuECrT9TD2dsKbC4XDpoogPTGH+ofNAm GTvfeG8BzYkLVH08qvZwCt5lBiibK6zxeJ4FJVenmcqXGXvieuVQMUZIvxkWXKeNZZ7H 8Cew== X-Gm-Message-State: AOAM532n2JfZc9oC/WMObmiQXxXIGmTep0Im/aMBQIzlP2YoasF4qIAW rb4E198nrARZHpxg8Q+K1lsVR3AlTlTAEW27/pxoE83WJ6A= X-Google-Smtp-Source: ABdhPJy5K7gHYa/dIexNcmJc90n3yF8wsM6mDaecI/U79L16UoROYOsZivveKXoQGJwlByiow7sVr49Aaay9dd6CusQ= X-Received: by 2002:a02:1181:: with SMTP id 123mr5252003jaf.93.1643393081329; Fri, 28 Jan 2022 10:04:41 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 28 Jan 2022 13:04:28 -0500 Message-ID: Subject: Re: Dragonfly Mail Agent (dma) in the base system To: FreeBSD Hackers Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JlljD6Zhlz4lcQ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.08 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.52:from]; NEURAL_SPAM_LONG(0.08)[0.077]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.52:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 27 Jan 2022 at 16:34, Ed Maste wrote: > > If you have enabled DMA on > your systems (or are willing to give it a try) and have any feedback > or are aware of issues please follow up or submit a PR as appropriate. Thanks everyone for the feedback so far. I think the feedback (including some private mail) can be summarised as: - It works well for the intended use case. - Documentation (FreeBSD handbook) is missing. I have submitted https://bugs.freebsd.org/261536 to track this. - We'd need to address queued mail in some way before it could be the default (e.g. provide a default cron job). From nobody Sun Jan 30 12:14:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 91B8D1991AAE for ; Sun, 30 Jan 2022 12:14:59 +0000 (UTC) (envelope-from Bojan.Novkovic@fer.hr) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30083.outbound.protection.outlook.com [40.107.3.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jmqrf1Q7Nz3pNR for ; Sun, 30 Jan 2022 12:14:58 +0000 (UTC) (envelope-from Bojan.Novkovic@fer.hr) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C5vJPYhZQ++PvyfDyB/OeymlMFxAcd83fhqKGg8K/jI7sinyevqzHMogL+Rd3F6Ylf6eMF2ciCEcO5XgLV576jJH4AfrRv4IxMuO8qZYxQOHnBl1+Bhy7PHWMp5IHR5H7kEHwR8mA7wuydfB7/P0UEU1HEUmgeYbGIPU/3vXVx8BZCu4LJ4I1bF3NfCERuHQaIfYglS7/0HWw3ec2c/moxaC5akly0rE/sy64pj8CBgFrBbHYpjLH6jEwJnKqbWcasLpTnFJa4bv3DuAnyrNaX9pdLc1jIA5t0DSKXJtNNbhiXtcFgD3C9LDsINv4svnJkV4mmRSdV/yKn26LJ/Gpw== 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=EUnHelH7rpULy1q0JvewY3hYh4sxTA5i9TxUneLtkBM=; b=f8EaDqZuS+eaMAPYe+bp3SUmIzQ4sozFv4WbN3m8eV2FdAfJAYKF7JnFSK1Fu+eVD/uxd3l2zPnDmuTGFYCLqFFYNYX+1Y82DPKqD9f5yuabTye15iggZ3trXUqJkGYKPud9cfGEF9Cpj2EcanGD482d4JMmKRwoUUOEEVniSUMfrptLEPB3Oui9LVGjV87FLTa3oV99o1sOhHcgQ4hXpr4bXHx+b3oh3/bMjMj6CZCrFkmT8GctqSzsXxOGKPXd2+MdthPyS4Iw5Q448bissEHnO3fJESdkx+zY9oCRuTaWWCTfuGhQq0hsDL/nI7DYV6CWBZuG1EQJ042XCjN/6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ferhr.onmicrosoft.com; s=selector2-ferhr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EUnHelH7rpULy1q0JvewY3hYh4sxTA5i9TxUneLtkBM=; b=aQCSCWtqInslXzBiz2RHcJnMxhzdqIXAivEo/6l3UmT4cXfIORXhT2hlEvca5E+fodTR98pOWq0+WR3c3Vji7B7qjYA7EiQQiOAMCjVexYLZTFCVEV8pTUvJN+lEOjTwXNgqjabTEzThASbtNqCz4GnnFN6NxrbCKQnAFkk1tlM= Received: from VI1PR08MB3920.eurprd08.prod.outlook.com (2603:10a6:803:c2::27) by DB7PR08MB3210.eurprd08.prod.outlook.com (2603:10a6:5:20::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15; Sun, 30 Jan 2022 12:14:49 +0000 Received: from VI1PR08MB3920.eurprd08.prod.outlook.com ([fe80::a0e0:3a3c:8e24:5f8e]) by VI1PR08MB3920.eurprd08.prod.outlook.com ([fe80::a0e0:3a3c:8e24:5f8e%4]) with mapi id 15.20.4930.021; Sun, 30 Jan 2022 12:14:49 +0000 Message-ID: <81f7a3e2-7f7e-6808-e76d-7e97c4fd2f90@fer.hr> Date: Sun, 30 Jan 2022 13:14:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 From: =?UTF-8?Q?Bojan_Novkovi=c4=87?= Subject: [PATCH] Solaris Doors IPC To: freebsd-hackers@freebsd.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR0602CA0013.eurprd06.prod.outlook.com (2603:10a6:800:bc::23) To VI1PR08MB3920.eurprd08.prod.outlook.com (2603:10a6:803:c2::27) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 953450ab-fe11-44ff-b78a-08d9e3ea1ce0 X-MS-TrafficTypeDiagnostic: DB7PR08MB3210:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6790; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6WHBYlgvq4RAbpM/OxI/2XDK9oeXPdsrTpefaJaDLlXz6xwU3DSb/9YrJV2b/MzUJkgsX71AmXjFK8dA7gXUtNEBwgczDxJ/DMv9Fwqz6R3qJmo/K/hw8chH+ROgX+jMb6PC9cY56gMQcFgNPP6K1hftYfAoVJF+CvkOACgi4CxlSLhmbwJSS+oaAmEfgaBHVWrsJbVU/CDQ9CmcjT3iUBDKf1M+AaT6rydBW1TkHkGO9m0ofxkZUICdiovesBLkNfO9F8onKrDOkU+YaPNCwOth5slCoWFpaHVPftttsBxTDKBgou/BDp4PmFATeYlxn72HHrpqZvli7i3QU44Tkbx4sYBclQMxFz7cRqzFm5a3+yKoSjxHYSCf30sEGQQ6eb7gYpxRLczzD4SicniBJ5yT12cPg7QtEfMk6Jz15JJlGQM5HCY16i9XBK5NVoLHJmcX3v7Qk+H+DVEItJm1L+Kx1jVhW/k2BoZAw3UapHvzB/g124NpmypO44SEMA/anRgnuIcIQ1wAweh6+8Ie6coX5TQdc+p6RUWMFkeAhBNSVKoZzUzOHzgHiJcfuM75jKKO8K2NIR+sWJJIMxEV0DrusCDCdY/LI6DDAl1Xh7s0L1ebktMxwFdx7cCT0UsFFxawDNMEaTLnxdneIanCUIMmDbhApgbJzrvTf+bcZg+GWibMP/e3WCTfkQ4CgUHYq75fy3pQrVk6D7MVGmnVfdSPJbB1JE6FLs4D2z+943WCdGcP+V9i9kbtw37vBkBO/KIn2OUamliQmQcJcyICarTpMqyNmWEFGsxlkEchnRyBqrQpNVuLoMgrMUVh6t6LkCEZfcrJj5mDoHs09gkB3A== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3920.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230001)(366004)(86362001)(31696002)(6486002)(508600001)(36756003)(38100700002)(316002)(786003)(38350700002)(31686004)(66946007)(6916009)(66556008)(66476007)(8676002)(8936002)(966005)(6512007)(4744005)(5660300002)(6506007)(52116002)(2616005)(2906002)(26005)(186003)(43740500002)(45980500001)(20210929001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cktqREtSaWsxQkdaYVZKZUJvenIxZ2VFdTVMMGw3Z2hwMXhqQW9OSW11a2pJ?= =?utf-8?B?b3UrTlcvNitacGt6Rkh5bzcyZFROdml1SDBzcW9PVnN5a0tCVW9Uc2x1M25K?= =?utf-8?B?WUd3aUhsMW1HbHk5WlJxTkhXMWJwaTRhL1djUEZYN2xCUUtWVzk3WUNIdU54?= =?utf-8?B?L1RkS0V6b2IvTHJUWk1wMFp3NkN4cHhaSDl6U1V4aFZXdHJSOXB6eTlEYmhF?= =?utf-8?B?Z1g0d3F4REcxZ1dUd0Y1MGxTQmhhbWZmZUVlWW9CU0trdkpRYTJuKzUxL2tt?= =?utf-8?B?NktCdGQ3R1VGNytPandNVzBzdWlERmNsNG4rRW0ybVZKaFNoK1FNZG1SK2ZP?= =?utf-8?B?T1UzcTJHZ0ZZejBuWUdtOGEyeWlBTTNEVUdNbXVGcmdKamdUeGVZc1BYS2NR?= =?utf-8?B?Q1F0NVBUYVBMc2ZkS25VWUtGMHZBazB4bWt5SG9WNk9kL01ncm4wdUFhMFZm?= =?utf-8?B?cDRrcUlYWlhqekVvY3ZCWTFMZkhpbnJsamc0cWNpV2F3eGNLREh3V3JrdXQ1?= =?utf-8?B?bk9CT21KSWwveUFKMm16MWNjSkY3alNVazIwdjZXK3dHbndPaU93aXIrVmFG?= =?utf-8?B?SEs5bExWbTFkME83dEFVUFNLVlFWNW81dTNoeVVFYUIwY0NXd1Q4V3pWWnVx?= =?utf-8?B?RFMvWU5adjBRMjBhVDg1K0Fldjdsd0RPSE9iTkczM20wcjd1ekV2TUlHNGVv?= =?utf-8?B?bGlkVDJoYkphVDBiaHpOL2hwZFdKSnFiaitBMEhySU9xYnFUNkQyM2o5WFh3?= =?utf-8?B?S2wyZUtVMm1QMXppaEVtT28ybmR2a3R3RmdJeCsvNFNNN2VqVUM1UkVmV1Jj?= =?utf-8?B?L0tlejFQeER5ZUhVcTlMK1ovMUdjQVlUV205c0N0RHBoU1VnZjBGdU1DMkpH?= =?utf-8?B?ZmZXcHlOUklzZzVHWkJpWUh4bFZKMWJPV3ZPMDlPTVh5TWdZRWtocUpnUFlJ?= =?utf-8?B?T2RYVURaYndBbUFxMmVsc3lpZWtkaGpxWXNUYUx5d0kyYUNGUzVsNHlBSmNL?= =?utf-8?B?OXljd2U1T2l4MnFWYjNETFlxaXNWcTFTOUNEUFlLWng3VHF5RjFBZ09vVXFP?= =?utf-8?B?Vmt4V1ZOU2JHN2U0MlZwZ0FQMGNVRlJRV0xpclcvd2dQdjM0MkJWeWZFVUx6?= =?utf-8?B?S1dITWJMWUtzTzJBemEySWlwSFZqdW1yZ3FVRG1wNW5CSS9OQkpTQnRVM2tu?= =?utf-8?B?ZVhzNmt5MmFGem1WejVGajUyWSttb2tCQ1Q4RG4yMHRjK0l3blZHMFh0MnhT?= =?utf-8?B?YnhZczk2TVZEazIvWUtZWkFCdWVieWMxN1gzb3lCWmM1dU5ON0UyU0E0SWxP?= =?utf-8?B?Q1RzS2FPbTFGaXlYQmxOdGtCcUFqSmJIOEFscnBzcGFxbUIvRE8rT2FPZlFz?= =?utf-8?B?WGI0UWxrZVRLWDJxL2xQRHVXVm41QWYzaHl1aUlIUzBlcVdhTU15aGhJc3dq?= =?utf-8?B?UFhHOTliZDBkREZyZmIvWjluclRMV0VkQVdOallUcUgwLzdLVGlsekZ4OXNl?= =?utf-8?B?OFZlMTBuRExNOE5nN0loMmxPMStOZWFFMEJqaVNlOFJrWHMyMGNTQTk5STdL?= =?utf-8?B?M1dPOEUvS1U3RXlGYUZuNTRzSkhxcDZ2YWxRR3lRNnBoWDVJWU5EekU0c0Fh?= =?utf-8?B?UU9BcVB6Y1hINjJCTmEwWFRDM2twZ1g3eEVhNm1OdzVXcEI0UUNqa05oajV3?= =?utf-8?B?aUZTK0ZkaU1OeGZ0TlEwRTl1M0FXLzJEWnhOcjdVOURDSUNHU2x0eUhwMmp6?= =?utf-8?B?bnpwV1hGV1pkM0t3Q1dkRW94WEVqNDlVR3dpRWFHak5VaWxobEZUOFRqYXRr?= =?utf-8?B?TTJKWG10ZDM3YmZKMHdJQ2NiL2RZL2ljWkxXc2dqa05IdmgydWxsSzYwZi9V?= =?utf-8?B?NDN5QXBDSlJxNnowWmVKTGdQcmo2djNRZlg3aE1Bblpsc1Raanc4NXd1RzV6?= =?utf-8?B?c2hIdnZzZEwyZlE4UXZpN3F3d0lEK0doNUQ3SDhjRjVtR0F6b1E3RllQcTRL?= =?utf-8?B?dXJSbFBpd2N1Yms1Q1FjRUhRcGx2bWxQQ1l2N29mTzlmTFdYZitobW5pVXNX?= =?utf-8?B?b0dySEdGa0k1eWNIMkxjRzI1eXlZc3RZeXRlZDYvNi9xcjNpdHZnSFh0ekNx?= =?utf-8?B?YUw0dkxISHBUdkJtNXF3Q2IvcTlYeFE0N1AzdXNQakhRYzFiQXhNMTRYWVJk?= =?utf-8?Q?TmVaU0rrKeyEU8qeKAmBgag=3D?= X-OriginatorOrg: fer.hr X-MS-Exchange-CrossTenant-Network-Message-Id: 953450ab-fe11-44ff-b78a-08d9e3ea1ce0 X-MS-Exchange-CrossTenant-AuthSource: VI1PR08MB3920.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2022 12:14:49.7071 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ca71eddc-cc7b-4e5b-95bd-55b658e696be X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: mQuicm6jBCNnGyKrXjPg7fUkteWLrJtgY1FlfXcU3uaM5DcgOwAS00eaSI5l5EeTVX0FimnzMT3U0oIiXYjOWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3210 X-Rspamd-Queue-Id: 4Jmqrf1Q7Nz3pNR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ferhr.onmicrosoft.com header.s=selector2-ferhr-onmicrosoft-com header.b=aQCSCWtq; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=none; spf=pass (mx1.freebsd.org: domain of Bojan.Novkovic@fer.hr designates 40.107.3.83 as permitted sender) smtp.mailfrom=Bojan.Novkovic@fer.hr X-Spamd-Result: default: False [-3.67 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[ferhr.onmicrosoft.com:s=selector2-ferhr-onmicrosoft-com]; 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]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fer.hr]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[ferhr.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[40.107.3.83:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(0.83)[subject]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.3.83:from] X-ThisMailContainsUnwantedMimeParts: N Hello everyone! I have completed a patch which implements the Solaris Doors IPC mechanism for FreeBSD. Since the patch is huge and requires new library code to be usable, I uploaded the diff and the backing code to a git repo [1] on top of opening a differential on Phabricator [2]. Kind regards, Bojan Novković [1] https://github.com/bnovkov/freebsd-doors [2] https://reviews.freebsd.org/D34097 From nobody Sun Jan 30 21:00:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EC1DD199D4E8 for ; Sun, 30 Jan 2022 21:00:31 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jn3W22nYsz4dC7 for ; Sun, 30 Jan 2022 21:00:30 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id u15so21631988wrt.3 for ; Sun, 30 Jan 2022 13:00:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Xxvw9MBFXa6eEWtpbM8Kfmv7bok96eSaGqdSRWAi6NA=; b=RDbEOkEzyArMHWfVB5OyVlF8BI9ae5Ik42s6cMlL5M/G5o6UeNlsvWIbDsrAzFCgou cwah5rqJNszs7ZUfO439KG5zZ7PQRH7tRuihFC12xC1RLyOxVLgpvpGDRbnij6E4A90W czm1ZNRMoNvfK9lvZJiqp76Dwdz5M9gzt6/eUR2h1rMlpTrs416RW8oPrA/Z08qee0wA VOewQ+1fptnT0EGQkS7Tvg6uYRYptn+jgOnFQe/QG/m8viQUSRdEkytbEe3Q+fPkmGZn ACtnllQjZiAi9/sP7thGOxiAaTbCM/uZF9aX9qTuVjnNjf6Qq26jEQcGMHbFlAMR8qJw Y0Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Xxvw9MBFXa6eEWtpbM8Kfmv7bok96eSaGqdSRWAi6NA=; b=qsanbHJ/4+eJssdOujz4C31+eFVpLRNV+hp1MLYD/tABT5V3u67yHRwMme+26QT7D2 rDSaQsFo22sl4JS+3JMoWQgE2lzhT7hRJVAOag9Sc0vZqxGFXgyal/zvl9G9wzrpq6cQ Hgaowt3EcKnQy9ic0hiVnt8BWeQWgyGmf1c7yQzqlcAf9Gz6LxoOqGNJGpb9zHmKuKaZ +IWgIs6a/A3dsEItqVH1aVq+MALe7kFr1kC+Vk9lNeMGw8ZMGHhIiVjdejXucFa6RuxJ 6RwSO499m6+XaWTxgoPE0bYxoOdCmRffrZQRY3o7Yl1QtFn7+JoMMrPKxbKXLqsUTzLO mtLQ== X-Gm-Message-State: AOAM533wE+3ndmk3dcZDH7anubuBdO+p19VCLTFf9at6Nk5gz2ymJZKf AZs3HQjOA9rvfyFxT+/TxxNLWy9GwBg= X-Google-Smtp-Source: ABdhPJzzvTR721hqC7Npa5cBGsi3aBbm/lIcCM6EVXlwGVA/98mSrm2S0a9QHrFp+AFmPU1GP78hMQ== X-Received: by 2002:a05:6000:1448:: with SMTP id v8mr14568922wrx.43.1643576429050; Sun, 30 Jan 2022 13:00:29 -0800 (PST) Received: from smtpclient.apple ([2a01:cb15:8010:2f00:34da:5f6c:2b9e:9d86]) by smtp.gmail.com with ESMTPSA id j3sm9902219wrb.57.2022.01.30.13.00.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jan 2022 13:00:28 -0800 (PST) From: Paul Floyd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: FOSDEM 2022 Valgrind Message-Id: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> Date: Sun, 30 Jan 2022 22:00:27 +0100 To: Freebsd hackers list X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4Jn3W22nYsz4dC7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=RDbEOkEz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.49 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Next Sunday I=E2=80=99ll be presenting (well, have prerecoded) a = presentation on =E2=80=9CUpstreaming the FreeBSD port=E2=80=9D. This = will be in the Valgrind dev room (not the BSD one). It=E2=80=99s = scheduled at 14:20 Brussels time, duration 55 minutes. https://fosdem.org/2022/schedule/room/dvalgrind/ A+ Paul= From nobody Sun Jan 30 22:25:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D44E7198A911; Sun, 30 Jan 2022 22:25:56 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jn5Pc5Hfnz3qrW; Sun, 30 Jan 2022 22:25:56 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643581556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n2+F2CXeXD0m3NnP4PTuxjPW4YeZk2blas5/CjMj0RU=; b=NRNF2jAztvHHXp/AuSs1lpTwJQE3fibz8YMKhAnc3XgpSNopwGHw6AaWq3jOP0BOLHJIli 5JFpj/VgyoZtQ/qQe6RuAxsGParxGY19jmJqhgmOPqwIIlY6wv6GVKy6RpSo2f7u44uyUb pS5ZEQh6TitwCPRIDd9Bot6xDw37+dsFTJKUyzuFLEwLrEihmBCcNl5qGNTvgnAAYZBQxP wn7QIE1mCNkrk7vqSO91BtPnAvH9fuLe2QTXTJ6ObkJF110GiRtS4VkikExF8du4JKehxt 4RdKQAPHCI27ASG2+orxppTjMDi7cwqvWZTZNsfCXOXR5ezwVB3QA0R/6kniWA== Received: from next.des.no (unknown [84.210.195.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id 72D59A6E2; Sun, 30 Jan 2022 22:25:56 +0000 (UTC) (envelope-from des@freebsd.org) Received: by next.des.no (Postfix, from userid 1001) id 41A118C85; Sun, 30 Jan 2022 23:25:54 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ed Maste Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: (Ed Maste's message of "Thu, 27 Jan 2022 16:34:10 -0500") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix) Date: Sun, 30 Jan 2022 23:25:54 +0100 Message-ID: <86czk8rhcd.fsf@next.des.no> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643581556; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n2+F2CXeXD0m3NnP4PTuxjPW4YeZk2blas5/CjMj0RU=; b=oJBGEl96SMbU7UtT10CV7ilPExA3EV8bSCFqtIf906+WG31O+2JQ5en9mR1vNQcst143Iu inzdXe+0qIOtYVQuHIfiIm8hoxZC0EK2pCGVhfXV78MSh7Yw91hQNQG4+Ng4geQU8rAkAa NxS3p1T8EM84Uwlmy9iW1w/hiJnRoauhzXp6EhHdNZV1kc0FZvoy2zgNEkIrseZDadasLb yFHH96jeLyOTS0pnbPLMicbdpIGgpFnF2E5NKVCPMM0VkUiEcW1/S/NGPkoD/d8p5ijPT3 4HnsaAb60CWStuyAMwvd24/ovL2vKXlf67dbYv+i7s0LEK3qSdC75TsbP7KoOQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643581556; a=rsa-sha256; cv=none; b=NDet+3lhZ8n93gA/M+9a4efoJjxOXLFdK6WbcndYVPSZeFDpxFY9puSnttflQL/2WkrcLZ Di7mJiVMnT0abfLBXxqBtmCjWHeFyDqMtyDHy0PvZ1KGnAt7cV7lYq26r3l4HZbwbFEpJw Z0XbH4I2ZMgcq25KtKszI7+naqLZeO0VpNj5ehFKaz0UN6AuyIEqscyjnu63nLsEFvqy98 mjXauxiWbfB7cFGYmUAOJXGBz5qW0RCmryiQPsVqIAs86SJNwqdbipl06cLtqPmaMteasN xnsLkbQOuij5DpZewX8hhpfJuTzINn1bMBA6hoxge5Sl/xR91gAGXeY8VbFq3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Ed Maste writes: > I am interested in determining whether dma is a viable minimal base > system MTA, and if not what gaps remain. It cannot. Ask bapt@ who was the one to import it, and later abandon the idea of making it our default MTA. The reason was that it does not have a default domain setting, so it cannot handle email from cron, periodic etc. where the recipient is just a user name (usually =E2=80=9Croo= t=E2=80=9D), and the devs were not willing to add that feature. I have email as far back as 2015 on the subject. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Jan 31 01:37:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3BFCF199AEF5 for ; Mon, 31 Jan 2022 01:37:21 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jn9fS1c2Tz4WqJ for ; Mon, 31 Jan 2022 01:37:20 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 8D3674C02A8; Sun, 30 Jan 2022 19:37:19 -0600 (CST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 31 Jan 2022 01:37:19 +0000 From: Pau Amma To: Paul Floyd Cc: Freebsd hackers list Subject: Re: FOSDEM 2022 Valgrind In-Reply-To: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> References: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <9efa80a3390b7041614815dd3e060f45@gundo.com> X-Sender: pauamma@gundo.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Jn9fS1c2Tz4WqJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-1.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.37)[-0.374]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28:c]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-01-30 21:00, Paul Floyd wrote: > Next Sunday I’ll be presenting (well, have prerecoded) a presentation > on “Upstreaming the FreeBSD port”. This will be in the Valgrind dev > room (not the BSD one). It’s scheduled at 14:20 Brussels time, > duration 55 minutes. Because timely accessibility matters: regardless of closed captions (you *are* providing close captions, right?), will you make a text equivalent available at the same time so anyone who needs or prefers to use that can take part meaningfully in discussion? From nobody Mon Jan 31 10:51:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5449E198EFFF for ; Mon, 31 Jan 2022 10:51:55 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnPyL0PyNz4nFs for ; Mon, 31 Jan 2022 10:51:54 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id e2so24621292wra.2 for ; Mon, 31 Jan 2022 02:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=iRSbQ7uFBIXrfvngbPdjO4H0vHw6kbSYgBjfPQjtfYc=; b=P0Kt/TtyfgAa5NpdJ0TDZtMLESnuc+5dz2zLVh69eUb5XVHrCdhtNzxkml42HFerTR v7zb8KnVi4gpxtsyJ/MysOLMiMcA44+kdoOhpqmO3ZDilbpiuAbYmYzYQiPOCDuZPh4U V3F7SDidI9NyS4QplN6SSgjFwOkxzl2GkA/uPJQsxYze3JLPFOEPfBBR1r5r378ANhlY GFxfabybUG4920pkF3ZZbcRREIhZgmYInu6c7qDwiHv42kAM0HuOnc1oIx15NfJF3JVj NsNmYVJFbLSWAZuzCqw2N/WZX5bBTGjqxNViyr0jYorOdZkhSTAXSfoB2SyXypnVykm9 4oUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=iRSbQ7uFBIXrfvngbPdjO4H0vHw6kbSYgBjfPQjtfYc=; b=aG37Ly0rSAMaaCJ3651/wkXUSmUpZCFTHhXyRfDunajKz3No4JxbUEnA2A95wfOmQx vvCTHFbFbwGAGVHwaUm6JEBAjR3Nc9BbT1oISvnukbeGmvkfr1w6Rv2S20daylmGtVWM MMP7CefjFiUQf2tK9Gq2cdG3C+fHsYO2HMSoNEeiZva75aVjXZjJqbX0jE4WoSt90k+G gRVz9dHHgkCADtKlgZKsyEpSH7cJ2Bd+7c3G4oB4bqLkEW+3o+ClrLdow3P6tRRKPsCV v4BzfvscZx+GGIh5+k98hJYxC/vvwhGOBc7IMy+HZK3dgx+ZltO2RB15/1LKD6cY1WOo MAGQ== X-Gm-Message-State: AOAM533rMBqMP/Cddw4dmQ/AYHYmt3jgImpcL5t5feI3U88yvzWkagHI U6rjaHjb5w/OqKAgv/BYMC4oWn8hKTw= X-Google-Smtp-Source: ABdhPJzAxjkLJyP/kaPZ3iNf/q8marOgQoxVg72YQX2dpY8Gd0G1Vtqe7iiXDoaoMNY3uVlNmrfwgg== X-Received: by 2002:adf:ee4e:: with SMTP id w14mr8613444wro.262.1643626306522; Mon, 31 Jan 2022 02:51:46 -0800 (PST) Received: from smtpclient.apple ([2a01:cb15:8010:2f00:cc58:260c:145:9878]) by smtp.gmail.com with ESMTPSA id a18sm11826360wrw.5.2022.01.31.02.51.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jan 2022 02:51:45 -0800 (PST) From: Paul Floyd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: FOSDEM 2022 Valgrind Date: Mon, 31 Jan 2022 11:51:44 +0100 References: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> <9efa80a3390b7041614815dd3e060f45@gundo.com> To: Freebsd hackers list In-Reply-To: <9efa80a3390b7041614815dd3e060f45@gundo.com> Message-Id: <4AC246BA-8BD4-4C1B-AFAA-B330336149C5@gmail.com> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JnPyL0PyNz4nFs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="P0Kt/Tty"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::435 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 31 Jan 2022, at 02:37, Pau Amma wrote: >=20 > Because timely accessibility matters: regardless of closed captions = (you *are* providing close captions, right?), will you make a text = equivalent available at the same time so anyone who needs or prefers to = use that can take part meaningfully in discussion? I just enquired, and no, there are no subtitles. I have uploaded the slides (Keynote and PowerPoint [+ PDF but without = speaker notes]) but my notes are fairly sparse, mainly just reminders to = prompt me. Do you have any preferred format for a transcription? (It=E2=80=99ll = take a while to transcribe. Keynote or a text file would be easiest for = me, plus whatever formats I can convert Keynote to. A+ Paul From nobody Mon Jan 31 12:45:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A32B91988FBA; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnSTW4Gwzz4bYF; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643633135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6XvGQgnutzI5n7mkHS4a+5Sr3hcUL/XX/dMe8JpB4ck=; b=Fb0d+90u03uxHaeFWzL/ubkXv4I4gRUU6DAAM3dkNTTwl7f1yZ1AdeLUHfX7TV+jw++WF8 h71HDVchNvVhyzFjZiBZOMR+z+JkrLwJ2gqyTwoHI/1rB+c7MC4ABkU3KVaeV90e5JeV/g xLqeB6uIwT5rUXmtq96Hqt2hMlGR/XQYDDGRqe/0qeITTzG+5mGBM9X8tBezOqekv+TYHt +emgNy5GW1/jGkVetLNJYDhNBdMJyK7356rlJ73cufGMCWdQPRyBix0p6VFgLIkC+abVDi OR8NWAIojaW5+a9y8D2PcKP89arILUEeWIw2uZlV1bwDoHnU0+QBCW98mf5/hA== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AB61203FB; Mon, 31 Jan 2022 12:45:35 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 0455EAAD72; Mon, 31 Jan 2022 13:45:32 +0100 (CET) Date: Mon, 31 Jan 2022 13:45:31 +0100 From: Baptiste Daroussin To: Dag-Erling =?utf-8?B?U23DuHJncmF2?= Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system Message-ID: <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> References: <86czk8rhcd.fsf@next.des.no> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86czk8rhcd.fsf@next.des.no> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643633135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6XvGQgnutzI5n7mkHS4a+5Sr3hcUL/XX/dMe8JpB4ck=; b=abqSZPBtBVVbcsOpL8AWYSJdLv5WJDkIhrMzs5wdkzQARJfpr0PZZg95wL5mdOQTE+059/ z2Nrt6bfoA6U+y0BFpfME6ICvUGS4a4+5iWLHt7tHHvW9WSxW0cOpRz8cHcgYed3vGrSis P9dMrV6hucBokkH0Gx5SoeZdrrnH9apk5BcqY/4Di3fNb+cXzsYVlF5wr+cBqV6guIKNgT IhA86dZx4ZAVdZksrctZ/G/b4jCw+PVtGmcN5b9CLlKTp6t/2sv4x/4Oax8MVOI+SM6aHA SN99VT9tYdF/VeQPLXU0nFlk7G3gxpaUtQhNUCAxGW9d4MEOCCntWHSFagcAIw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643633135; a=rsa-sha256; cv=none; b=bVbsNxsvf+HCoFptqV4m0j3eXsVnWVSkviR9p83YWYNyU4NBqjbAzj3/Ox8yKR03d3iGhG KzGZ1ZzsAfzgB6NRZrSEojmj+xNpZixUAJjuTy9bh3X1Z8/X5OFuz+guVbygQ0h405E/VP uFW7dyEnSVADBxibBVS6RBWbBJZvHzPZEz9O1SioDDMkk3vCDReoraAviLLrC8MAZgQVtv cSbhS73KehnuuP2jMr2OTq1JvvP0jF/thsXOj16CJKdKHDbBIS9mcjnFit75PR5eH57q1I 2dXTFBJegczpPZiRzdlwfx+Fxw08fKuX7IV0O6faZBAS0pGVpmFiyb778w/haQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Jan 30, 2022 at 11:25:54PM +0100, Dag-Erling Smørgrav wrote: > Ed Maste writes: > > I am interested in determining whether dma is a viable minimal base > > system MTA, and if not what gaps remain. > > It cannot. Ask bapt@ who was the one to import it, and later abandon > the idea of making it our default MTA. The reason was that it does not > have a default domain setting, so it cannot handle email from cron, > periodic etc. where the recipient is just a user name (usually “root”), > and the devs were not willing to add that feature. I have email as far > back as 2015 on the subject. > This has been fixed since. (not by me) Bapt From nobody Mon Jan 31 13:47:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5FE0319924B4; Mon, 31 Jan 2022 13:47:56 +0000 (UTC) (envelope-from des@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnTsS2BFXz3H4Z; Mon, 31 Jan 2022 13:47:56 +0000 (UTC) (envelope-from des@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643636876; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nvySX/DlXtwmCVlrUQ8U74hEemKNMp5vfv1PxLlK0Lo=; b=ardzTiHevKLFxX+smAHyNccm+ai4SQDI+RelTFj/MZ2Mu/r9X/TmzZy2KH6CskL7fsVE1E ecCOURU/IzVxeQA9fuUn0j5vND/s30B75hyXx+ZpayqadTqCawbPfJrQMQtUDEQPi2Y9oH Yc5nTYJ9XU3xjoxPBnWI6XMBEA30Y4k8urQGbgqNGjcFrpsyB8UXZ3+gVqNaePyNmTcFfZ eb1Pu2vDMQgy4bvHuidAZEbYLqYPsimEQ2+n65oSbsD91WXk0OwJphY47fj+GW8wvAheu/ 1g9j9zU6166tNG8DUoMnucaZZ6PXpMXILrypXzzcjrQKus2zsyp2dX6vL0xF/Q== Received: from next.des.no (unknown [84.210.195.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: des) by smtp.freebsd.org (Postfix) with ESMTPSA id D557B213F8; Mon, 31 Jan 2022 13:47:55 +0000 (UTC) (envelope-from des@freebsd.org) Received: by next.des.no (Postfix, from userid 1001) id 40E0089CA; Mon, 31 Jan 2022 14:47:52 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Baptiste Daroussin Cc: Ed Maste , FreeBSD Hackers , FreeBSD Current Subject: Re: Dragonfly Mail Agent (dma) in the base system In-Reply-To: <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> (Baptiste Daroussin's message of "Mon, 31 Jan 2022 13:45:31 +0100") References: <86czk8rhcd.fsf@next.des.no> <20220131124531.aoc7lowc3f7vyjaf@aniel.nours.eu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (berkeley-unix) Date: Mon, 31 Jan 2022 14:47:52 +0100 Message-ID: <865yq02f07.fsf@next.des.no> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643636876; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nvySX/DlXtwmCVlrUQ8U74hEemKNMp5vfv1PxLlK0Lo=; b=skC5QNL8QQcVj+MOOd9WqrQVojz6Ym10ua2aM67XvhZHhOzuUDbx8twIpMYfe4WSImVVRD FsvCriila5IDIbDqsa2jfgtV2SKaMFt3rUYh850YsbKPjfy2cIZC1QXYQJC3m0QQFaZBMb Qgzev0+30tIItzPaOx1hL7qFCrbuzTk1S5uggJniGbG5cwaAw7o6xRPlmbdYVKnpAeCu/K LAqrppbQ6WpEKjqiyLI2hRLeAzCrxqy/M/BmxVYTX79kKl/GLgHSDI6TRRCaIrE+4J9guv gC6qThlqZ/c9m58HhF0v4itTiyafhlfb8H1n8fXwxJKg2pc6ED9G/mcnqX8qSQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643636876; a=rsa-sha256; cv=none; b=XhECk9w0bH3dFbuUO/oHYnwLNSGqXNavUQXN/C2MTFldcKfW87x0nvbYSSLKZEfnVJ8qVA HkKs+2I4659TJ9gPN63N455vByU33JM13P5PGqmN6wIEL9ds6O1cSV+Mx0QPIk+oTczqpw BLGN7Ke3M+tGa35WNOGWltuoshhn8sc5rq5LwXDRpdAkI8M8Gyd0638IEZ6LHGEhtJ5/qU BA4BDXnZp632kEmdmyPPUgiLNizyBecGj65vt/cLmCmmBhOfIocAqchPtJoYO4zR1qs61T LzTwfdR+pAPKdqYUfUCXX411gatfGMRUMo+hdMEu56xwe0Yggij12DesKEGYmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Baptiste Daroussin writes: > Dag-Erling Sm=C3=B8rgrav writes: > > [...] does not have a default domain setting, so it cannot handle > > email from cron, periodic etc. where the recipient is just a user > > name (usually =E2=80=9Croot=E2=80=9D) [...] > This has been fixed since. (not by me) In that case, assuming that it behaves sensibly out of the box, my only objection is the lack of documentation, which I understand is being worked on. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@FreeBSD.org From nobody Mon Jan 31 16:50:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5D5791994B40 for ; Mon, 31 Jan 2022 16:50:46 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4JnYwP2d0Jz3j6J for ; Mon, 31 Jan 2022 16:50:45 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id AEB954C05B1; Mon, 31 Jan 2022 10:50:44 -0600 (CST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 31 Jan 2022 16:50:44 +0000 From: Pau Amma To: Paul Floyd Cc: Freebsd hackers list Subject: Re: FOSDEM 2022 Valgrind In-Reply-To: <4AC246BA-8BD4-4C1B-AFAA-B330336149C5@gmail.com> References: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> <9efa80a3390b7041614815dd3e060f45@gundo.com> <4AC246BA-8BD4-4C1B-AFAA-B330336149C5@gmail.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <5a38179d647563aadace8c5048c6b913@gundo.com> X-Sender: pauamma@gundo.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4JnYwP2d0Jz3j6J X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=quarantine) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-01-31 10:51, Paul Floyd wrote: >> On 31 Jan 2022, at 02:37, Pau Amma wrote: >> >> Because timely accessibility matters: regardless of closed captions >> (you *are* providing close captions, right?), will you make a text >> equivalent available at the same time so anyone who needs or prefers >> to use that can take part meaningfully in discussion? > > I just enquired, and no, there are no subtitles. Thanks for checking. As it happens, I can't make use of them much more than of speech, but for people who need them, that's extremely disheartening news. :-( > I have uploaded the slides (Keynote and PowerPoint [+ PDF but without > speaker notes]) but my notes are fairly sparse, mainly just reminders > to prompt me. Thanks. (Are you speaking of the attachments links to https://fosdem.org/2022/schedule/event/valgrind_freebsd/ ?) > Do you have any preferred format for a transcription? (It’ll take a > while to transcribe. Keynote or a text file would be easiest for me, > plus whatever formats I can convert Keynote to. UTF-8 plain text is fine. (I can use English or French, and maybe and with more effort Tagalog or Modern Greek.) In case you need it, there seems to be a way to convert Keynote files to PDF documents, per https://support.apple.com/en-us/HT202220, but I can't vouch for it. From nobody Tue Feb 1 17:15:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 719DE19A331B for ; Tue, 1 Feb 2022 17:15:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JpBQ60Zmlz4tml for ; Tue, 1 Feb 2022 17:15:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643735710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+Jx69aw4lsCJCyg/OYDqn+FMasBNkw1mp2OOhfIiDws=; b=wUt+zDN7qsr3LLH+MQ9JgRqyu7lOqqwsCpx5qZYWoWZF68qhgYpT4xasNDSLY8Tmprh6E+ D34T3IvQj6beQ6nvYcM7+SoiUe0HkPtkBKcpuRGSd4RuWMQgIE7Jz/QDz9K+Emx20mUNCG WqEknmzpgXczgnyiF6enzchX7AKwpdpgwK7q8BXvu+4XAYBKiOAhulTz6NvHCWZNJD6eep mUsfp2lvZewRxSiscIeVvFVEWE351j6/1rKLKCiWTpV36/RSblA3TEeLvIy2s4ckqB/Vse mK0tMNXIZ4yp8EuqYB/AptwuKshmMFpijOYO1f3xLN2wvVwNJgbsHfEAt6n4PQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id D52472F522 for ; Tue, 1 Feb 2022 17:15:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 8FD242EE84 for ; Tue, 1 Feb 2022 17:15:08 +0000 (GMT) Message-ID: <5152f45a-9d9f-8e50-2d98-b9e49966a5cb@FreeBSD.org> Date: Tue, 1 Feb 2022 17:15:06 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] Solaris Doors IPC Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <81f7a3e2-7f7e-6808-e76d-7e97c4fd2f90@fer.hr> From: David Chisnall In-Reply-To: <81f7a3e2-7f7e-6808-e76d-7e97c4fd2f90@fer.hr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643735710; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+Jx69aw4lsCJCyg/OYDqn+FMasBNkw1mp2OOhfIiDws=; b=xk61Ur58ibieSdiXzEby2/TZ2b6MBlVnJp0tW23dDRt8BeFUn0u3l+UkyslSrs0LPGRCMQ 95StkQ3JQSe2ixrFdSX5b5R+wHt7CcRemYAOw32IqQUOkhPx5S1ZGZxYqnJuUcnabYiePx K5AEVq0J07fOD5lYeHosKQHzD7vv3x+PxITQZ9ZysBB/C6eGMGm/d6hyGqYmS9RaEgOmXE QGXvbyOvbk/G5pluSdZA0fbtj90PcweBuxutau4JlOmh3P7E8cKdx/XeIKCskQbfWcSp+P YuP52nMTKlJ8YkmMmw10Hteap2Zq3tfRY2qREg6EUphjkoficlS4R00wJz5FYw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643735710; a=rsa-sha256; cv=none; b=qsoTVM/+UiagJGQ8TUaYI98YihqghTWaL9xBNEX8HT/yDgrhbDQtkpHDKzVzgL8EU1aU24 rjG76P9YasmADdDsAtpR5sKTlCldQYm8JHyPPgvawlfl21WFmd11N1t9/C5mveB67juMaA h3WN1Yphnqqt4PnSA6nkYcISjML+94z3y+IXjIv2mBHahZcAUpXJNhWE6o8EML5bV9ZGiC qgsxs+UY6cfPxiyn6j0pq4qRK8esTYg3aOBDDKGwSm6VwlUW6uswsk3YbnKLaJXy+1MfYf WmpoWNT9axCb1x45ZiR3oI0DR29ff1AvIxjQf4AHvTCdvHKO6l8u9jrm9jSRkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi Bojan, I am *really* excited to see someone working on Doors. It's a fantastic IPC mechanism and I have some code that would love to be able to use Doors. I had an intern explore the minimum viable kernel support in Linux for this kind of mechanism a couple of years ago. This looks as if it's a straight adaptation of the Solaris Doors kernel API, which was a localisation of Spring Doors fit with the abstractions in the Solaris kernel. I wonder if it's worth taking a step back to see what shape a FreeBSD localisation of Spring Doors would look like. In particular, the Solaris Doors APIs were designed at a time when Solaris was deep in the N:M threading model and a lot of the abstractions (for example, the thread pool logic) were designed on this assumption and on the capability of hardware with very different tradeoffs to today. There are a few somewhat separable bits of Doors that it might be worth trying to land patches for independently. Doors provide: - A low-latency mechanism for directly waking up another thread. This allows RPCs without scheduler latency and is the critical part of Doors - everything else can be implemented with existing primitives. - A mechanism for moving arguments to an RPC from one process to another. This involves (at least) one of three mechanisms: * Copying the argument registers from the source to the target. * Copying small amounts of data through an in-kernel buffer. * Page flipping large objects. * Duplicating file descriptors from the caller to the callee (I'd love to see this extended to support Capsicum and with a revocation mechanism by disallowing dup / dup2 on the fd and having the kernel close it on return from the Door invocation. This would allow temporary delegation of access to files for the duration of a single request. For example, asking another process to append something to a file and guaranteeing that they can't write to the file after they returned). - A 'shuttle' mechanism that allows returns through failure, including in the case of reentrancy where one process invokes another via a door, the second calls back into the first in the same thread, and then crashes. The first thread must be able to unwind to the start of the first door call. - An IDL for defining Door interfaces and generating the call gates. - A mechanism for managing a thread pool. Solaris also provided a mechanism for attaching a Door into the filesystem namespace. I believe this interface was intended to become a generic mechanism for attaching any anonymous IPC mechanism to the filesystem namespace but it was never evolved like this in Solaris. In a 1:1 threading model and a FreeBSD-like kernel, I'd expect that you'd want to move all of the thread-pool management into userspace and provide two kernel primitives for doing this: - A mechanism for waiting on more than one door (including one from another thread in the same process that. - A mechanism for a thread to be notified that there are pending door invocations and that it should create threads to handle them. The second of these could easily be done via kqueue (and so integrated into the main run loop for an event-driven program). I don't think normal fast-path door invocation can go via kqueue and have the scheduler behaviour that's necessary for doors to be useful. For the data transmission, it's not clear what the right separation of concerns is. We now have solid support for anonymous shared memory objects. There isn't a way of moving ownership of pages from anonymous memory to a named file descriptor or anything like Linux's sealing mechanism on memfd. For the KDBUS work in Linux, some of this was punted to userspace. A sysctl to tell userspace the size below which copying via the kernel is expected to be faster than moving ownership of pages, combined with memfd-like sealing would provide one possible implementation without needing the page-flipping policy to be in the kernel. The underlying primitive that we wanted when imagining a less error-prone[1] version of memfd sealing was a mechanism for transitioning memory between MAP_SHARED and MAP_PRIVATE states, such that any write to the pages would be local until you discarded your local copy and went back to seeing things in the original. This seems like the same mechanism that you'd want for the page-flipping path in Doors and so it would be nice to have a general mechanism for it, even if Doors uses it automatically. Looking at your patch, I couldn't quite follow how the Door activation worked. It seemed as if this was just using condition variables to wake up the receiving end and so required the scheduler to decide to invoke the other thread. Sorry if I missed something (a high-level design doc would help here). This is, in my mind, the most important part of Doors to get right: the guarantee from both Spring and Solaris is that the invoked thread runs with the caller's scheduler priority (which avoids priority inversion) and in the caller's quantum (which avoids scheduler latency). Without this, the RPC can have milliseconds of latency in the common case. I'd suggest starting from the point before trying to build a fully featured Doors implementation: what is the minimum thing that you need in the FreeBSD kernel to allow a thread to wake up another and have it run in the same quantum, with the lowest possible latency? David [1] The problem with sealing in memfd is that the security depends on getting the code in error-handling paths right. This code is only ever tested when you're under attack, so it is probably buggy. On 30/01/2022 12:14, Bojan Novković wrote: > Hello everyone! > > I have completed a patch which implements the Solaris Doors IPC > mechanism for FreeBSD. > > Since the patch is huge and requires new library code to be usable, I > uploaded the diff and the backing code to a git repo [1] on top of > opening a differential on Phabricator [2]. > > Kind regards, > Bojan Novković > > [1] https://github.com/bnovkov/freebsd-doors > > [2] https://reviews.freebsd.org/D34097 > > From nobody Wed Feb 2 00:38:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7D9B198C4D5 for ; Wed, 2 Feb 2022 00:41:30 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail07.asahi-net.or.jp (mail07.asahi-net.or.jp [202.224.55.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4JpNK40VNxz55jT; Wed, 2 Feb 2022 00:41:28 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from vmware13.advok.com (pool-96-225-64-148.nwrknj.fios.verizon.net [96.225.64.148]) (Authenticated sender: NR2Y-OOT) by mail07.asahi-net.or.jp (Postfix) with ESMTPSA id 08873C1F2D; Wed, 2 Feb 2022 09:41:18 +0900 (JST) Date: Tue, 1 Feb 2022 19:38:48 -0500 From: Yoshihiro Ota To: Ambert Cc: Peter Jeremy , "freebsd-hackers@freebsd.org" Subject: Re: Out-of-swap killer and SIGTERM signal Message-Id: <20220201193848.71043b06041aa90b541f8c13@j.email.ne.jp> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; i386-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JpNK40VNxz55jT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ota@j.email.ne.jp designates 202.224.55.47 as permitted sender) smtp.mailfrom=ota@j.email.ne.jp X-Spamd-Result: default: False [-0.91 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[96.225.64.148:received]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:202.224.55.0/24]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[email.ne.jp]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.75)[0.753]; NEURAL_HAM_LONG(-0.96)[-0.964]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[protonmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:4685, ipnet:202.224.32.0/19, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[202.224.55.47:from] X-ThisMailContainsUnwantedMimeParts: N Hi, Ambert. On Wed, 12 Jan 2022 21:42:18 +0000 Ambert wrote: > On 2022-01-12, Peter Jeremy wrote: > > There have been lots of discussions about this in the past, starting > > in about 1998, (though I agree that it's been about 4 years since the > > last discussion). I suggest you search for "freebsd+sigdanger" for > > previous discussions. > > Thank you for the keyword. After a search, I find that the previous > threads containing the keyword "sigdanger" discuss extensively two > subjects: > 1) How to exclude a process from the reach of the OOM killer. And > how to ask the OOM killer to kill a given process first. > 2) How to provide feedback about memory usage to processes, to give > them a hint that they should reduce their memory footprint, if > possible. This feedback can be a signal sent to all processes, or > system-wide flags readable by any process who cares about a > potential memory shortage. > > Those two subjects are interesting, but I am talking about something > else. My suggestion is almost never mentionned in previous threads. > When it is mentionned [1] [2], there is no objection whatsoever, from > anyone. There is not even a comment about it. > > Sending SIGTERM a few seconds before SIGKILL is useful because it > allows a condemned process to exit gracefully, just like it would > during a shutdown(8). And it is simple to implement. There is no need > to change the algorithm selecting condemned processes, and there is no > need to change a single line of code in userland. For the > administrator, only two tasks require extra work: > - set up a little bit of extra swap during the installation of > FreeBSD > - set a couple of sysctl values: the duration of the grace period > (vm.grace_period = zero milliseconds by default), and the amount of > extra swap that will not be usable normally (vm.grace_space = zero > bytes by default) Based on my investigations in the past, delivery of signal takes significantly long time in heavily slashing system such that OOM initiate multiple iteration of shooting other processes. In other words, SIGTERM may not reach to processes or also processes may not get enough resources or time to shutdown cleanly. Throughput of random I/O handling of swap devise impacts this a lot. If you use SSD instead of HDD for swap devise, situation may be easier. > Excerpt from a historical thread: > On 1998-04-27, Jordan K. Hubbard wrote: > > All the SIGDANGER (Will Robinson) signal is meant to do is give a > > process a little _warning_ before it's chosen as the designated > > sacrifice for the evening and terminated in an untimely fashion. > > > > I don't think the question here is "is this a good idea" - it's a > > perfectly reasonable idea and one which has been proposed before. > > The question here is really "what are the proposed semantics of > > this mechanism?", e.g. how long do you wait from the time you > > SIGDANGER the process and actually shoot it down, and what > > happens if you're also critically short of resources and don't > > have much time to wait? > > [1] > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=209768+0+archive/1998/freebsd-hackers/19980426.freebsd-hackers > > [2] > https://lists.freebsd.org/pipermail/freebsd-current/2008-January/081743.html > > > Ambert I'm also interested in system monitoring and auto-turning based on sysctl and started below. This is for swap space monitoring: https://github.com/uyota/py-prdanlz/blob/main/examples/swap_usage.md Installation: https://github.com/uyota/py-prdanlz#how-to-install You may be interested in. Hiro From nobody Sat Feb 5 16:52:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0342719ACE94 for ; Sat, 5 Feb 2022 16:52:34 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jrdk85LjLz3pgp for ; Sat, 5 Feb 2022 16:52:32 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id c192so6776266wma.4 for ; Sat, 05 Feb 2022 08:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=rtRO6rxKNfBf9NYde+JVAHsUBMHrubV73vVf9X2yRbA=; b=JWzwuOkMc9eUzcMcCmGGKk2GmEyQEj+JlJT69AGpHHK94jtza5+b5KZdRzlIuCBQcl NHS28cz9vR/UaFpRYcMHnctzATJ3qY5BrzfQOOs6QfjeDGlQQ7dd4S8cl79jUgvfAX9L 1tB9YkEKnb852sTOOjHAMAHLn6G3HEp4tQkmsxOi3ECiR1Hk46ff4KIzm0pZLwBp/8BY hqMAI3c/bI4eKRnskKfOGRnxbDvZXmcs1/lqJN8FLJRLNGde3APfwXhZmztu6eaqaByA Q8uxe7WkauYDITNCycCitjNCXC+MSMq0DxSZ1YEBx485Eig2VKRJ67uX3OwBvMkCC1aQ Q0/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=rtRO6rxKNfBf9NYde+JVAHsUBMHrubV73vVf9X2yRbA=; b=zdqfdUaQF8td9pYNwXqi8ObZoCdRXGES0nXyj/LQ1sKi9FFbebzu6BZ1xBz2nCm9UE sdNynX870vteicR2FqEBFNb4BWpbonAvY+pVDk9QuXSYrhLNHmkTatzQQ2aAENEYA61y X0F3IoMmzWMjWl1OOiij+xh75GsRmZeEik3nNAErFgwidXBGScaqVit23ytKAmZmuJ5e 3OTidW3nh80F12pe4VrR7HPyAbuUfqTDjhKqkeEATT8WAiu4YBn+EP6bGMMm4q0CL7Jm /TAvMIyf9hEjQXmuY39ZOHwrujX4Au+hBwar0AIm76PNt/UQ2OKzoIN8kWRcG6aN9ebe DZiw== X-Gm-Message-State: AOAM530AWe/17BwNELdiWJ/0o4X2SJXGhMG+zvQg8Ge8FrrV0VvVtVOa DQk7t058BQMqazqzOV6iD2Okq6tXGWs= X-Google-Smtp-Source: ABdhPJxuGjcjyDMRC+6UoZci6bu5zJLwCZHN27IOsDPsGdIEYSdCqi4QYBI4OIuWYbBvSyVzdi/z4A== X-Received: by 2002:a1c:4b13:: with SMTP id y19mr7035495wma.129.1644079951722; Sat, 05 Feb 2022 08:52:31 -0800 (PST) Received: from smtpclient.apple ([2a01:cb15:8010:2f00:95b:aaca:1619:a6ae]) by smtp.gmail.com with ESMTPSA id l14sm339895wrs.55.2022.02.05.08.52.31 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Feb 2022 08:52:31 -0800 (PST) From: Paul Floyd Content-Type: multipart/alternative; boundary="Apple-Mail=_DEEAE3BA-068E-445D-9FC6-D5DC9E39151D" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: FOSDEM 2022 Valgrind Date: Sat, 5 Feb 2022 17:52:30 +0100 References: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> <9efa80a3390b7041614815dd3e060f45@gundo.com> <4AC246BA-8BD4-4C1B-AFAA-B330336149C5@gmail.com> <5a38179d647563aadace8c5048c6b913@gundo.com> To: Freebsd hackers list In-Reply-To: <5a38179d647563aadace8c5048c6b913@gundo.com> Message-Id: <82BB862D-4290-4663-92D8-95ADC6D78E81@gmail.com> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4Jrdk85LjLz3pgp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=JWzwuOkM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-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(-0.29)[-0.291]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_DEEAE3BA-068E-445D-9FC6-D5DC9E39151D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 31 Jan 2022, at 17:50, Pau Amma wrote: >>=20 >=20 > UTF-8 plain text is fine. (I can use English or French, and maybe and = with more effort Tagalog or Modern Greek.) In case you need it, there = seems to be a way to convert Keynote files to PDF documents, per = https://support.apple.com/en-us/HT202220, but I can't vouch for it. Hi again I=E2=80=99ve uploaded a plaintext English transcript of the talk. Hand = transcribed so maybe a few typos. (The bottom link below my mugshot = https://fosdem.org/2022/schedule/event/valgrind_freebsd/ = ) A+ Paul --Apple-Mail=_DEEAE3BA-068E-445D-9FC6-D5DC9E39151D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 31 Jan 2022, at 17:50, Pau Amma <pauamma@gundo.com> = wrote:


UTF-8 plain text = is fine. (I can use English or French, and maybe and with more effort = Tagalog or Modern Greek.) In case you need it, there seems to be a way = to convert Keynote files to PDF documents, per https://support.apple.com/en-us/HT202220, but I can't = vouch for it.

Hi again

I=E2=80= =99ve uploaded a plaintext English transcript of the talk. Hand = transcribed so maybe a few typos.

(The= bottom link below my mugshot https://fosdem.org/2022/schedule/event/valgrind_freebsd/)

A+
Paul


= --Apple-Mail=_DEEAE3BA-068E-445D-9FC6-D5DC9E39151D-- From nobody Sat Feb 5 20:44:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BDC0619AA3CE for ; Sat, 5 Feb 2022 20:44:35 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4Jrksv0TQjz4cDl for ; Sat, 5 Feb 2022 20:44:35 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 25C424C0790; Sat, 5 Feb 2022 14:44:28 -0600 (CST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 05 Feb 2022 20:44:27 +0000 From: Pau Amma To: Paul Floyd Cc: Freebsd hackers list Subject: Re: FOSDEM 2022 Valgrind In-Reply-To: <82BB862D-4290-4663-92D8-95ADC6D78E81@gmail.com> References: <21037B0E-7795-43FD-84DC-C3E19783FE76@gmail.com> <9efa80a3390b7041614815dd3e060f45@gundo.com> <4AC246BA-8BD4-4C1B-AFAA-B330336149C5@gmail.com> <5a38179d647563aadace8c5048c6b913@gundo.com> <82BB862D-4290-4663-92D8-95ADC6D78E81@gmail.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: X-Sender: pauamma@gundo.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jrksv0TQjz4cDl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-2.94 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.04)[-0.041]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-02-05 16:52, Paul Floyd wrote: > https://fosdem.org/2022/schedule/event/valgrind_freebsd/ > ) Thanks. I'll look at it tonight. From nobody Sat Feb 5 20:50:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C17019AF05C for ; Sat, 5 Feb 2022 20:50:45 +0000 (UTC) (envelope-from sg2342@googlemail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jrl1069Vfz4gNT for ; Sat, 5 Feb 2022 20:50:44 +0000 (UTC) (envelope-from sg2342@googlemail.com) Received: by mail-ej1-x633.google.com with SMTP id s13so30136332ejy.3 for ; Sat, 05 Feb 2022 12:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=date:from:to:subject:message-id:mime-version:content-disposition; bh=Cnvfs33YrvaCNpCw5WbR7ajbu4OdzFMyHMP050aM36s=; b=ZpCbcarTMA5NhDXEBtpx0D1+varRmu+xSmMMiDDSkKWH8VReB/cMyLTnJaWauQn/3T B5LTYdO4yiye8ChwZxs/KuYNGWl2gj25mfINzjBR2zGEtbqylBuR1E3lOj2AOYiDMA/D ZcL1tnB6uHVPJiyAi4ULf6FjZLFCbwp83Xw+0wrBrUlvewLmE/Peps7StqZ++ITgFJAc q9E4SVGZRmZdd31hLgG1N2h3NlAhduv2SJ1zw5p1e0QD/aZONR4MtxHtbSbznC4bfjRF JY8t4z29XBY/t5zY69n0eVSw1bfh6ms6BOchxmPzp2seLrGhMXGusXaKMeapN4WlTozr jyCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=Cnvfs33YrvaCNpCw5WbR7ajbu4OdzFMyHMP050aM36s=; b=y2mT2tQtcEN1dKif6NYt2RXqJ5CWP0aqh6heEkeD+kfCys4Dg246XY2+b5m/HWIBAI lCaVOlxywtFIg1lsDNKpl38dTSQmmB6xyZ6uPJdtC2y6Fr8ZPrLD2Oh3qb9I7VNyML1V L45UGfR6w6h5Vt+kU1FwlsqDdYD+Zral5unnOrZv9R++afTbTDLoJevApSogUGjw7vqK Sb2rjey2DkU/ijP30qnK40QzVihQPkjQxc/t6MHPoVBblCnHdBbkN2kr5sIEoQQ2Tl68 HqCIWdYuYv80wrUFpA5x6m1aEQbNlKZzNDDKiLZd34JVwrLSqQW4sk3xKTQNOjc03sy+ vwkg== X-Gm-Message-State: AOAM530dkZayfxvBuqtng3YMMp/kbmADrj3qTb6Mz8qQQcZXfUC3odW6 KliFPqwKwsCLNAHgtZQHaEPzcNwID3c+zZ+H X-Google-Smtp-Source: ABdhPJzBVgJ+hN6F5Uw/c2ILnS4vp6sjrRdinMXsvisQrtbV/lmQHH+H8Bl/K589hjFUs5P5SMHQ1Q== X-Received: by 2002:a17:907:d8d:: with SMTP id go13mr4159553ejc.440.1644094243738; Sat, 05 Feb 2022 12:50:43 -0800 (PST) Received: from sahu.ennead.xyz (44-102-142-46.pool.kielnet.net. [46.142.102.44]) by smtp.googlemail.com with ESMTPSA id qw28sm777009ejb.0.2022.02.05.12.50.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Feb 2022 12:50:43 -0800 (PST) Date: Sat, 5 Feb 2022 20:50:41 +0000 From: Stefan Grundmann To: freebsd-hackers@freebsd.org Subject: Rotating (efi) framebuffer console Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4Jrl1069Vfz4gNT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=googlemail.com header.s=20210112 header.b=ZpCbcarT; dmarc=pass (policy=quarantine) header.from=googlemail.com; spf=pass (mx1.freebsd.org: domain of sg2342@googlemail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=sg2342@googlemail.com X-Spamd-Result: default: False [-1.56 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[46.142.102.44:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.53)[-0.528]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.97)[0.967]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, the screen of my brand new GPD Pocket 3 (tiger lake) laptop is in portrait mode and reports a resolution of 1200x1920. I have another older device with the same issue (a GPD Pocket 1). In 2019 johalun@FreeBSD.org wrote on the freebsd-current about an Lenovo Ideapad with a portrait mode screen and raised the question if it would be good to support rotation of the vt_fb console. Since the new GPD Pocket 3 is a nice device and rather well supported in FreeBSD, i thought "how hard can it be" (OpenBSD has fb console rotation and Linux has fbcon=rotate..) The patch (against stable/13, at the end of this mail) works for me(tm): Whenever the width of a frambuffer device is smaller than it's height; a portrait mode screen is assumed and the screen is rotated by 90 degrees clockwise. I write this here for two reasons: 1. give others with similar hardware a chance to avoid the neck-craning issue and 2. offer to work on something that can be reviewed and merged e.g. - implement the rest of the transformations (180 degrees, 270 degrees) - boot-time variable to select behavior - vt(4) man page update For 2. i would like to know if vt_fb.c is even the right place to do this. The framebuffer code in the loader could also get this feature. best regards Stefan Grundmann diff --git a/sys/dev/vt/hw/fb/vt_fb.c b/sys/dev/vt/hw/fb/vt_fb.c index c535d1b753c..19ab5999d89 100644 --- a/sys/dev/vt/hw/fb/vt_fb.c +++ b/sys/dev/vt/hw/fb/vt_fb.c @@ -45,6 +45,8 @@ __FBSDID("$FreeBSD$"); #include #include +#define FB_FLAG_ROTATE 2147483648 + static struct vt_driver vt_fb_driver = { .vd_name = "fb", .vd_init = vt_fb_init, @@ -167,7 +169,13 @@ vt_fb_setpixel(struct vt_device *vd, int x, int y, term_color_t color) info = vd->vd_softc; c = info->fb_cmap[color]; - o = info->fb_stride * y + x * FBTYPE_GET_BYTESPP(info); + + if (info->fb_flags & FB_FLAG_ROTATE) { + o = info->fb_stride * x + + (info->fb_width - (y + 1)) * FBTYPE_GET_BYTESPP(info); + } else { + o = info->fb_stride * y + x * FBTYPE_GET_BYTESPP(info); + } if (info->fb_flags & FB_FLAG_NOWRITE) return; @@ -300,7 +308,13 @@ vt_fb_bitblt_bitmap(struct vt_device *vd, const struct vt_window *vw, /* Skip pixel write, if mask bit not set. */ if (mask != NULL && (mask[byte] & bit) == 0) continue; - o = (y + yi) * info->fb_stride + (x + xi) * bpp; + if (info->fb_flags & FB_FLAG_ROTATE) { + o = (x + xi) * info->fb_stride + + (info->fb_width - (y + yi + 1)) * bpp; + } else { + o = (y + yi) * info->fb_stride + (x + xi) * bpp; + } + o += vd->vd_transpose; cc = pattern[byte] & bit ? fgc : bgc; @@ -464,12 +478,22 @@ vt_fb_init(struct vt_device *vd) term_color_t c; info = vd->vd_softc; - vd->vd_height = MIN(VT_FB_MAX_HEIGHT, info->fb_height); - margin = (info->fb_height - vd->vd_height) >> 1; - vd->vd_transpose = margin * info->fb_stride; - vd->vd_width = MIN(VT_FB_MAX_WIDTH, info->fb_width); - margin = (info->fb_width - vd->vd_width) >> 1; - vd->vd_transpose += margin * (info->fb_bpp / NBBY); + if (info->fb_height > info->fb_width) { /*assume 90 degrees clockwise rotation*/ + info->fb_flags |= FB_FLAG_ROTATE; + vd->vd_height = MIN(VT_FB_MAX_HEIGHT, info->fb_width); + vd->vd_width = MIN(VT_FB_MAX_WIDTH, info->fb_height); + margin = (info->fb_height - vd->vd_width) >> 1; + vd->vd_transpose = margin * info->fb_stride; + margin = (info->fb_width - vd->vd_height) >> 1; + vd->vd_transpose += margin * (info->fb_bpp / NBBY); + } else { + vd->vd_height = MIN(VT_FB_MAX_HEIGHT, info->fb_height); + margin = (info->fb_height - vd->vd_height) >> 1; + vd->vd_transpose = margin * info->fb_stride; + vd->vd_width = MIN(VT_FB_MAX_WIDTH, info->fb_width); + margin = (info->fb_width - vd->vd_width) >> 1; + vd->vd_transpose += margin * (info->fb_bpp / NBBY); + } vd->vd_video_dev = info->fb_video_dev; if (info->fb_size == 0) From nobody Sun Feb 6 13:19:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C674619A5487 for ; Sun, 6 Feb 2022 13:19:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Js8xS45hcz4Y9x for ; Sun, 6 Feb 2022 13:19:08 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 216DJ0iQ037472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Feb 2022 14:19:01 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1644153541; bh=nXU9Sx7nMQBIwMRhCJIuiE49Zr3cjIlAHF/PcczlTmc=; h=Date:From:To:Subject; b=HYFBNLlEmKkwksJp4inZRp8gaCN30Yil+XmhbE9d+VMxsehAV9cIXUDZmbn3/sJ0F bbjifvIN226BG6GL3F1Yq3vF5rCW+A3QbK2FhPAdUSmnZPE0xbwRKQ3Wws5/S+7hS2 VnQA49aWsfdC2l8NbBKg9G/5XISXwY4heg8wDElo= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 216DJ0W1010475 for ; Sun, 6 Feb 2022 14:19:00 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 216DJ0Fr010472 for ; Sun, 6 Feb 2022 14:19:00 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Feb 2022 14:19:00 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: trying to run FreeBSD/amd64 - Celeron J1900 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4Js8xS45hcz4Y9x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=HYFBNLlE; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[puchar.net]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Tried to run FreeBSD on small low power PC with this CPU (which is 64-bit i've checked). Loader start, loads kernel then hangs just before "Booting..." should appear. Tried both 12.3 and 13.0 memstick image. same result. Where could be a problem? From nobody Sun Feb 6 13:40:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD2AA19B208B for ; Sun, 6 Feb 2022 13:40:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Js9QK14bwz4h20 for ; Sun, 6 Feb 2022 13:40:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 216DecQX099589 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Feb 2022 14:40:39 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1644154839; bh=+i9B/F765p6ElrFgzKsQXcyzUgqxrJrnq4fNvrutIzU=; h=Date:From:To:Subject:In-Reply-To:References; b=J0E6ZLQ6NzIebOCijoccmrOhoS/lkJDjdLac5dB2hsxk3zqR0iQRex8k3dtaMM/uR P400qGeAp+h7TvLdlsooEPiXgomDhllJmd1neUPiXyGhu1v3t6aAxQT0zD5JL7hge9 rSGr+4NCYr4YBG8CLqADes6CZQOEMED1TeaqKhjc= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 216DecIv010615 for ; Sun, 6 Feb 2022 14:40:38 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 216DecV9010612 for ; Sun, 6 Feb 2022 14:40:38 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Feb 2022 14:40:38 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Re: trying to run FreeBSD/amd64 - Celeron J1900 In-Reply-To: Message-ID: <6e9dd181-ee6c-80a0-a861-d430136ebea0@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Js9QK14bwz4h20 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=J0E6ZLQ6; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-0.77)[-0.767]; DMARC_NA(0.00)[puchar.net]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N found that other have the problems. kern.vty=sc fixes it On Sun, 6 Feb 2022, Wojciech Puchar wrote: > Tried to run FreeBSD on small low power PC with this CPU (which is 64-bit > i've checked). > > Loader start, loads kernel then hangs just before "Booting..." should appear. > > Tried both 12.3 and 13.0 memstick image. same result. Where could be a > problem? > > From eugen@grosbein.net Sun Feb 6 14:00:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C62A1198FA64 for ; Sun, 6 Feb 2022 14:01:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Js9sm6z11z4q0d for ; Sun, 6 Feb 2022 14:01:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 216E0pnM011383 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Feb 2022 14:00:52 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-hackers@freebsd.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 216E0oWE099251 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 6 Feb 2022 21:00:50 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: trying to run FreeBSD/amd64 - Celeron J1900 To: freebsd-hackers@freebsd.org References: <6e9dd181-ee6c-80a0-a861-d430136ebea0@puchar.net> Cc: Wojciech Puchar From: Eugene Grosbein Message-ID: Date: Sun, 6 Feb 2022 21:00:41 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <6e9dd181-ee6c-80a0-a861-d430136ebea0@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4Js9sm6z11z4q0d X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.70 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.68)[-0.675]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[62.231.161.221:server fail,2a01:4f8:c2c:26d8::2:query timed out]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.07)[0.073]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.02.2022 20:40, Wojciech Puchar wrote: > found that other have the problems. kern.vty=sc fixes it If you are forced to use vt(4) for some reason (e.g. no CSM/BIOS legacy support in the motherboard), there is a workaround for vt: hw.vga.acpi_ignore_no_vga=1 From nobody Sun Feb 6 14:38:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E1BE19B6242 for ; Sun, 6 Feb 2022 14:38:09 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsBhc41Rvz3LLT for ; Sun, 6 Feb 2022 14:38:08 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 216Ec6SM017177 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Feb 2022 15:38:06 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1644158286; bh=WnHbNXh5AT4FqJEcGKqz5vPB2JQrqbPu3HbD6RUlYUY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NldXY70gaQuMMotLoZmn2IBJCTed3rgkxpX+xZE4PCZm4BxQOdXsmbfSUk/2Giw9y 16Pxft80wVdAAvBJQ6ixc6x3ISSAM5nTtkhHfTfJH9irPND2XwPATk7AWtbUjQAhL9 7ACUlmcmNCNNxDORGi1BLdgBiOPazX1yh5pZK+c8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 216Ec5FH010832; Sun, 6 Feb 2022 15:38:05 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 216Ec57p010829; Sun, 6 Feb 2022 15:38:05 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Feb 2022 15:38:05 +0100 (CET) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: trying to run FreeBSD/amd64 - Celeron J1900 In-Reply-To: Message-ID: References: <6e9dd181-ee6c-80a0-a861-d430136ebea0@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4JsBhc41Rvz3LLT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=NldXY70g; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 6 Feb 2022, Eugene Grosbein wrote: > 06.02.2022 20:40, Wojciech Puchar wrote: > >> found that other have the problems. kern.vty=sc fixes it > > If you are forced to use vt(4) for some reason (e.g. no CSM/BIOS legacy support in the motherboard), > there is a workaround for vt: > > hw.vga.acpi_ignore_no_vga=1 > > no i don't. but thank you From nobody Sun Feb 6 14:40:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3ECA719B6E24 for ; Sun, 6 Feb 2022 14:40:37 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsBlS36vfz3MBS for ; Sun, 6 Feb 2022 14:40:36 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 216EeYQn017835 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Feb 2022 15:40:34 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1644158434; bh=PPbcNOcAJCs2w+ihWNYpL9SV+ko1ltl0KJje4dP+xNM=; h=Date:From:To:Subject; b=n4xLbiz3vpxi/N2Ib6rJ5EhH616QdYvJZVtpQmh7ybgC/SiyjM3gK1HOHj+mBeDx8 +qr1YyFChIjUWqScg7Wpmspj6kSnHwAFcHDaSqN1Koqh0OdBYtYHB6KWbXfB1tWbxL 6BV/TvSUkZu6p86j/eS7AhDa9rQWUBSNF6Z3KsZ0= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 216EeYAE010851 for ; Sun, 6 Feb 2022 15:40:34 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 216EeY7F010848 for ; Sun, 6 Feb 2022 15:40:34 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Feb 2022 15:40:34 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: AX88179A doesn't attach on boot Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4JsBlS36vfz3MBS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=n4xLbiz3; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[puchar.net]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N i wanted second gigabit ethernet so i bought USB gigabit interface When i boot FreeBSD (stable 12) and THEN plug it in, works fine ugen0.4: at usbus0 axge0 on uhub0 axge0: on usbus0 miibus1: on axge0 ukphy0: PHY 3 on miibus1 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow if i boot with card plugged it i'm getting: ugen0.1: <0x8086 XHCI root HUB> at usbus0 uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub0: 7 ports with 7 removable, self powered Root mount waiting for: CAM usbus0 Root mount waiting for: CAM usbus0 Root mount waiting for: CAM usbus0 Root mount waiting for: CAM usbus0 ada0 at ahcich1 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number 829D07570E8500011066 ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 57241MB (117231408 512 byte sectors) Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 3 ports with 3 removable, self powered ugen0.3: at usbus0 ukbd0 on uhub1 ukbd0: on usbus0 kbd1 at ukbd0 uhid0 on uhub1 uhid0: on usbus0 mountroot: waiting for device /dev/ada0a... lo0: link state changed to UP re0: link state changed to DOWN I have to unplug and replug for it to work. After it attaches it works fine. Is there any workaround for it? From nobody Mon Feb 7 15:04:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CECED19BEED9 for ; Mon, 7 Feb 2022 15:05:07 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsqFG4jLSz3sbk for ; Mon, 7 Feb 2022 15:05:06 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy06.your-server.de ([78.46.172.3]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1nH5Za-0002Jv-Sj for freebsd-hackers@freebsd.org; Mon, 07 Feb 2022 16:04:58 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nH5Za-000A8D-Ps for freebsd-hackers@freebsd.org; Mon, 07 Feb 2022 16:04:58 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 77ACD480089 for ; Mon, 7 Feb 2022 16:04:58 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xNhUl522syyh for ; Mon, 7 Feb 2022 16:04:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 33C9C4800B6 for ; Mon, 7 Feb 2022 16:04:58 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YGncpdURx1Ud for ; Mon, 7 Feb 2022 16:04:58 +0100 (CET) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 09487480089 for ; Mon, 7 Feb 2022 16:04:58 +0100 (CET) Message-ID: Date: Mon, 7 Feb 2022 16:04:56 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: FreeBSD Hackers From: Sebastian Huber Subject: ntp_init() looks like a nop Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.5/26446/Mon Feb 7 10:43:31 2022) X-Rspamd-Queue-Id: 4JsqFG4jLSz3sbk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-3.15 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_NA(0.00)[embedded-brains.de]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.981]; NEURAL_HAM_MEDIUM(-0.87)[-0.873]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I review currently the kern_ntptime.c module since I would like to use=20 it in RTEMS. I have a question to ntp_init(): /* * ntp_init() - initialize variables and structures * * This routine must be called after the kernel variables hz and tick * are set or changed and before the next tick interrupt. In this * particular implementation, these values are assumed set elsewhere in * the kernel. The design allows the clock frequency and tick interval * to be changed while the system is running. So, this routine should * probably be integrated with the code that does that. */ static void ntp_init(void) { /* * The following variables are initialized only at startup. Only * those structures not cleared by the compiler need to be * initialized, and these only in the simulator. In the actual * kernel, any nonzero values here will quickly evaporate. */ L_CLR(time_offset); L_CLR(time_freq); #ifdef PPS_SYNC pps_tf[0].tv_sec =3D pps_tf[0].tv_nsec =3D 0; pps_tf[1].tv_sec =3D pps_tf[1].tv_nsec =3D 0; pps_tf[2].tv_sec =3D pps_tf[2].tv_nsec =3D 0; pps_fcount =3D 0; L_CLR(pps_freq); #endif /* PPS_SYNC */=09 } SYSINIT(ntpclocks, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, ntp_init, NULL); The ntp_init() function sets a couple of global variables to zero. These=20 variables should be in the .bss section. Are they not already cleared=20 during the kernel loading? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Feb 7 15:18:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F8B919A83BC for ; Mon, 7 Feb 2022 15:18:44 +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 4JsqXz496tz4TQ7 for ; Mon, 7 Feb 2022 15:18:43 +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 217FITWH004320 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Feb 2022 17:18:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 217FITLF004319; Mon, 7 Feb 2022 17:18:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Feb 2022 17:18:29 +0200 From: Konstantin Belousov To: Sebastian Huber Cc: FreeBSD Hackers Subject: Re: ntp_init() looks like a nop Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4JsqXz496tz4TQ7 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [2.88 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_SPAM_SHORT(0.88)[0.881]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, Feb 07, 2022 at 04:04:56PM +0100, Sebastian Huber wrote: > Hello, > > I review currently the kern_ntptime.c module since I would like to use it in > RTEMS. I have a question to ntp_init(): > > /* > * ntp_init() - initialize variables and structures > * > * This routine must be called after the kernel variables hz and tick > * are set or changed and before the next tick interrupt. In this > * particular implementation, these values are assumed set elsewhere in > * the kernel. The design allows the clock frequency and tick interval > * to be changed while the system is running. So, this routine should > * probably be integrated with the code that does that. > */ > static void > ntp_init(void) > { > > /* > * The following variables are initialized only at startup. Only > * those structures not cleared by the compiler need to be > * initialized, and these only in the simulator. In the actual > * kernel, any nonzero values here will quickly evaporate. > */ > L_CLR(time_offset); > L_CLR(time_freq); > #ifdef PPS_SYNC > pps_tf[0].tv_sec = pps_tf[0].tv_nsec = 0; > pps_tf[1].tv_sec = pps_tf[1].tv_nsec = 0; > pps_tf[2].tv_sec = pps_tf[2].tv_nsec = 0; > pps_fcount = 0; > L_CLR(pps_freq); > #endif /* PPS_SYNC */ > } > > SYSINIT(ntpclocks, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, ntp_init, NULL); > > The ntp_init() function sets a couple of global variables to zero. These > variables should be in the .bss section. Are they not already cleared during > the kernel loading? This is nop indeed, be it linked in kernel, or loaded as a module. From nobody Mon Feb 7 16:40:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0E84419B6C11; Mon, 7 Feb 2022 16:40:41 +0000 (UTC) (envelope-from mhorne@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 4JssMX6qNKz3Hdp; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=UW//J2e6EJPVioIyKNM19XdQNYfD7snsV35WAkh5HcqWrIHX0pKJ8x0/eYlEVM+Scs9gfn vkSNb754BbY+3Bnzggo0RMmX0BKzeblbEZUqMFktFE1Ifsp3He6023hqdnk486R7i2VzGq bCYoWzy2xHZFdvCxksq4FJgsj3YjMz8lVEHFkWQFkVty7uDYkZ4i3gjoCuuXJcpR25Y3hl XJ5VZcL73pHSrSp5fvFPYjwwhy2H0D1o0OEJXmkWtEn5ijDhfoEj4RKBg/d0pZjyz4mqsp /HZwOJnPQo3WW4isCqUERyb7ZCKRqyuA8vmXCHh+jGLRLibcHusB+OcpRX4m9g== Received: from [192.168.1.106] (host-173-212-73-28.public.eastlink.ca [173.212.73.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id 9956B2E6B4; Mon, 7 Feb 2022 16:40:40 +0000 (UTC) (envelope-from mhorne@freebsd.org) Message-ID: Date: Mon, 7 Feb 2022 12:40:39 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 From: Mitchell Horne Subject: Re: A new boot-time trace framework To: "Bjoern A. Zeeb" Cc: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org References: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Language: en-CA In-Reply-To: <5E5F06E4-F0FA-45F9-B121-88C69CA15A25@lists.zabbadoz.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644252041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T/KoK/hQoOv46E6KCjFqedmVwze2aU2XSbb7gzvWPcQ=; b=Ssi+58zxyS8AQjffHROJ7oVn3DKzQ/rJyCDDwsk35TJ87nvWWmUzYUSCzKg9sYMTASxy7g aUcWIcyCutrrJkq0k26NPbdEuKnKluor0LROB8VIGXKOy+hVWWqgmTtVf9GwO8+OgqEyRF HxbbUfO0Ft2mbFqqaBtaRg5L6963gmBjZQaElBwgueHv/EfCKSnvK+rF7LsZpmg6pmK1UI 2DvbAu+V2LJupuwRoVaESBJAzRyrGvdNvl/98uM8cCcyVqARMwSGIZ7Y3smNpRze8UVpjo YyjL90N0F5t6ZZ2Km5PQqxLkarK6uAqDvzPl7IrT+3v2G0Y5xkwBrf8s0X+Abg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644252041; a=rsa-sha256; cv=none; b=iNyTUWjgP1k7ZDRM/3fOrdnsuj6IqWuj/9unyW7HHYipNFiM/DsS6iqHxhZNz7yo+Gks1+ KZ4p5H/M9bdFwVn4QArk9Q/zqAfQzXspjjByHNmlH8OFAYY83HsqctXn3stzMMvz9e1Bcc aSZvjmx2yioDV0AujmCjvNeSpn3VORX9p6k1uSHQq61UMIDoK4RI66jyfxTma3bqL1Hsrm 4qaMmEc01vqY/WRW+EWO0Bnf53LVWkbxl+mFsgGtTZSn5oADyCQCiL1AFGoj9kyd5nAVux ClfTL14QROCIIR3QPIMfEFAqaGFOMdU2MmAdJY/iWbuWyJl0fdVt3IazOP63sQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/10/21 13:39, Bjoern A. Zeeb wrote: > On 10 Nov 2021, at 16:26, Mitchell Horne wrote: > >> Unlike TSLOG, I intend for this work to be compiled in to the kernel >> by default, but disabled behind a tunable (kern.boottrace.enabled). >> The cost of doing so should be minimal, only a couple of syscalls >> added to init(8) at most. > Hi, apologies for my delayed reply here. > I think if you really want to have this on by default (whether that make > sense or not for the majority of people) I’d at least avoid the function > call and reduce it to a branch which is super-easy to do. > Good suggestion, the latest version has this change. > My honest feeling is that another of the at least 3 other tracing > mechanisms existing these days be better extended and improved rather > than another one added;  we were always joking about 3 firewalls but if > we keep going this path we can soon start joking about 9 tracing > mechanisms and that will be a major mess for sysadmins.  I can see from > when this work was coming and back then it might have made sense this > way; but more than a decade has passed.. > Thanks for your input. In general, I agree with you; it is preferable to extend existing mechanisms than add something new with duplicated functionality, and I tend to look for this option first. Conversely, I feel that a one-size-fits all tracing framework is not possible, as what data is captured and how it is presented is highly dependent on the meaning/nature of that data. Put differently, we will always require more than one tracing mechanism for different types of tracing tasks. In reviewing the existing tracing options, I did not find that building this functionality on top of them to be any easier or more desirable. TSLOG covers much of the same area but with a different notion of tracing (i.e. recursive event tracing based around function entry/exit as opposed to one-shot events). The intended consumer of its data is a set of python scripts, so it is presented much differently than the human-readable log of events that boottrace produces. KTR has a KTR_INIT class that appears completely unused and comes close to realizing the same purpose, but would still require the addition of a whole new interface for creating new ktr events from userspace. Rather than bend these existing tools to meet these needs it seems better to me to leave them to do what they are good at, and instead add something new that is purpose-built and equally limited in scope (for which the work is already complete). > /bz On another note, it was misleading of me to call boottrace a 'framework', as this implies a much wider scope than what it achieves. More accurate would be to call it a facility. I intend to move forward and commit this work later this week if there are no lingering comments. Cheers, Mitchell From nobody Mon Feb 7 17:00:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F32C19C261A for ; Mon, 7 Feb 2022 17:00:53 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jsspm2bQbz3QwS for ; Mon, 7 Feb 2022 17:00:48 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy06.your-server.de ([78.46.172.3]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1nH7Ne-0006Iq-Pf for freebsd-hackers@freebsd.org; Mon, 07 Feb 2022 18:00:46 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nH7Ne-000QFM-Mz for freebsd-hackers@freebsd.org; Mon, 07 Feb 2022 18:00:46 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 6A93148007D for ; Mon, 7 Feb 2022 18:00:46 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1VsRp7StiGJR for ; Mon, 7 Feb 2022 18:00:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 22EFD4800A6 for ; Mon, 7 Feb 2022 18:00:46 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GdprJCr1EWqb for ; Mon, 7 Feb 2022 18:00:46 +0100 (CET) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 05DF048007D for ; Mon, 7 Feb 2022 18:00:46 +0100 (CET) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH] kern_ntptime.c: Remove ntp_init() Date: Mon, 7 Feb 2022 18:00:43 +0100 Message-Id: <20220207170043.62630-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.26.2 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.5/26446/Mon Feb 7 10:43:31 2022) X-Rspamd-Queue-Id: 4Jsspm2bQbz3QwS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.20 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148:c]; R_MISSING_CHARSET(2.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BLOCKLISTDE_FAIL(0.00)[85.10.215.148:query timed out,78.46.172.3:query timed out,82.100.198.138:query timed out]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; DMARC_NA(0.00)[embedded-brains.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The ntp_init() function did set a couple of global objects to zero. Thes= e objects are in the .bss section and already initialized to zero during ke= rnel or module loading. --- sys/kern/kern_ntptime.c | 34 ---------------------------------- 1 file changed, 34 deletions(-) diff --git a/sys/kern/kern_ntptime.c b/sys/kern/kern_ntptime.c index a8418248abd7..96f14a408bcb 100644 --- a/sys/kern/kern_ntptime.c +++ b/sys/kern/kern_ntptime.c @@ -207,7 +207,6 @@ static long pps_errcnt; /* calibration errors */ * End of phase/frequency-lock loop (PLL/FLL) definitions */ =20 -static void ntp_init(void); static void hardupdate(long offset); static void ntp_gettime1(struct ntptimeval *ntvp); static bool ntp_is_time_error(int tsl); @@ -632,39 +631,6 @@ ntp_update_second(int64_t *adjustment, time_t *newse= c) NTP_UNLOCK(); } =20 -/* - * ntp_init() - initialize variables and structures - * - * This routine must be called after the kernel variables hz and tick - * are set or changed and before the next tick interrupt. In this - * particular implementation, these values are assumed set elsewhere in - * the kernel. The design allows the clock frequency and tick interval - * to be changed while the system is running. So, this routine should - * probably be integrated with the code that does that. - */ -static void -ntp_init(void) -{ - - /* - * The following variables are initialized only at startup. Only - * those structures not cleared by the compiler need to be - * initialized, and these only in the simulator. In the actual - * kernel, any nonzero values here will quickly evaporate. - */ - L_CLR(time_offset); - L_CLR(time_freq); -#ifdef PPS_SYNC - pps_tf[0].tv_sec =3D pps_tf[0].tv_nsec =3D 0; - pps_tf[1].tv_sec =3D pps_tf[1].tv_nsec =3D 0; - pps_tf[2].tv_sec =3D pps_tf[2].tv_nsec =3D 0; - pps_fcount =3D 0; - L_CLR(pps_freq); -#endif /* PPS_SYNC */ =20 -} - -SYSINIT(ntpclocks, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, ntp_init, NULL); - /* * hardupdate() - local clock update * --=20 2.26.2 From nobody Mon Feb 7 18:04:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2B9F519592E1 for ; Mon, 7 Feb 2022 18:04:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsvDd3S4Rz4bYY for ; Mon, 7 Feb 2022 18:04:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id o15so8335669vki.2 for ; Mon, 07 Feb 2022 10:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GPhjG5d6zzlWTP3JccLg/C2GGchcibnBBmjjxgqFYnA=; b=ioOaV20Bd+5SSOzMXL56LdDYnz3Lsb9sYjn9PoaNk3n35IS2qSfu09eXyObTxC5hE8 59Nn7+85paw3RW5irxyvCFppA94N5sBOwwmHXEcGrkCL9FX+KUp4ja+Mwqh8ZWICScep bZCCUQyIPgWKR27zfh3nkFEJeBsA7F16j0JSGnq/ZEiEsbF5f7p4dLz4S6Q4EhXXTtzF 2nY5ZkIouyCAtRQvvAzA0AWp+lbieOhW+QoBxluCDFi/9lenLluGoDETWa87MUQpAU4S QRnm9NDAyMI18IABd8uMwRtZYYA8zSwwlkoJvYP1dPEeCcqxeCvpuUMYtxVvYDkWcTkE 2UKA== 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=GPhjG5d6zzlWTP3JccLg/C2GGchcibnBBmjjxgqFYnA=; b=MAfhws4luUss4fMjVFQdXCDbYvxsnWYHf34STPkYZQepiRl5cE7OFsStnuSyp6HqNt agJrG4MSGZw2QipVj174G4U7yj12jsitLWRnxXTP1m8jXdjXttkVzHVVn7rfVVHy5rn8 bSKhRKud/aqnbOp97StnhVPdvNKktMAYOcYgoyFSXKwgT9V1vgPoh4KUdVKZ+FtYo5IX ppKUUdi4fufWM0JkiuX+lbJGtPlkgY7njJm2RPGtUc5lEHw4sUOXRAGNhDHjk14r1Bro eInS6bZ0TNUsNVhbHKthwbez9uSHrUMQX1rENYGDzObbVtiiuCv187H3dmBMybylOVHz biMQ== X-Gm-Message-State: AOAM530cQCqfLSyFVQyl1DInXElSqLdA/uvku38NiWl0A+kZy63DqIPL mxH+jlETtLeLBvj8Ddgowne3Qlw5SAKdoAey1ONbFg== X-Google-Smtp-Source: ABdhPJwuzBclgCU449Hy/s9BPtABxCIHK3mrTprYRwQPkPMeVylVGuOZImw3b3uUNdXMybK4rILDuDj149KSlZPyteQ= X-Received: by 2002:a05:6122:181a:: with SMTP id ay26mr215092vkb.5.1644257088689; Mon, 07 Feb 2022 10:04:48 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 7 Feb 2022 11:04:37 -0700 Message-ID: Subject: Re: ntp_init() looks like a nop To: Konstantin Belousov Cc: Sebastian Huber , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000b0ea4d05d7716fe2" X-Rspamd-Queue-Id: 4JsvDd3S4Rz4bYY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ioOaV20B; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.93 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.94)[-0.944]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000b0ea4d05d7716fe2 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 7, 2022 at 8:20 AM Konstantin Belousov wrote: > On Mon, Feb 07, 2022 at 04:04:56PM +0100, Sebastian Huber wrote: > > Hello, > > > > I review currently the kern_ntptime.c module since I would like to use > it in > > RTEMS. I have a question to ntp_init(): > > > > /* > > * ntp_init() - initialize variables and structures > > * > > * This routine must be called after the kernel variables hz and tick > > * are set or changed and before the next tick interrupt. In this > > * particular implementation, these values are assumed set elsewhere in > > * the kernel. The design allows the clock frequency and tick interval > > * to be changed while the system is running. So, this routine should > > * probably be integrated with the code that does that. > > */ > > static void > > ntp_init(void) > > { > > > > /* > > * The following variables are initialized only at startup. Only > > * those structures not cleared by the compiler need to be > > * initialized, and these only in the simulator. In the actual > > * kernel, any nonzero values here will quickly evaporate. > > */ > > L_CLR(time_offset); > > L_CLR(time_freq); > > #ifdef PPS_SYNC > > pps_tf[0].tv_sec = pps_tf[0].tv_nsec = 0; > > pps_tf[1].tv_sec = pps_tf[1].tv_nsec = 0; > > pps_tf[2].tv_sec = pps_tf[2].tv_nsec = 0; > > pps_fcount = 0; > > L_CLR(pps_freq); > > #endif /* PPS_SYNC */ > > } > > > > SYSINIT(ntpclocks, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, ntp_init, NULL); > > > > The ntp_init() function sets a couple of global variables to zero. These > > variables should be in the .bss section. Are they not already cleared > during > > the kernel loading? > This is nop indeed, be it linked in kernel, or loaded as a module. > I just looked at the posted patch, and I concur. Warner --000000000000b0ea4d05d7716fe2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 7, 2022 at 8:20 AM Konsta= ntin Belousov <kostikbel@gmail.co= m> wrote:
On Mon, Feb 07, 2022 at 04:04:56PM +0100, Sebastian Huber wrote:
> Hello,
>
> I review currently the kern_ntptime.c module since I would like to use= it in
> RTEMS. I have a question to ntp_init():
>
> /*
>=C2=A0 * ntp_init() - initialize variables and structures
>=C2=A0 *
>=C2=A0 * This routine must be called after the kernel variables hz and = tick
>=C2=A0 * are set or changed and before the next tick interrupt. In this=
>=C2=A0 * particular implementation, these values are assumed set elsewh= ere in
>=C2=A0 * the kernel. The design allows the clock frequency and tick int= erval
>=C2=A0 * to be changed while the system is running. So, this routine sh= ould
>=C2=A0 * probably be integrated with the code that does that.
>=C2=A0 */
> static void
> ntp_init(void)
> {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/*
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * The following variables are initialized o= nly at startup. Only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * those structures not cleared by the compi= ler need to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * initialized, and these only in the simula= tor. In the actual
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * kernel, any nonzero values here will quic= kly evaporate.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0L_CLR(time_offset);
>=C2=A0 =C2=A0 =C2=A0 =C2=A0L_CLR(time_freq);
> #ifdef PPS_SYNC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pps_tf[0].tv_sec =3D pps_tf[0].tv_nsec =3D 0= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pps_tf[1].tv_sec =3D pps_tf[1].tv_nsec =3D 0= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pps_tf[2].tv_sec =3D pps_tf[2].tv_nsec =3D 0= ;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pps_fcount =3D 0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0L_CLR(pps_freq);
> #endif /* PPS_SYNC */
> }
>
> SYSINIT(ntpclocks, SI_SUB_CLOCKS, SI_ORDER_MIDDLE, ntp_init, NULL); >
> The ntp_init() function sets a couple of global variables to zero. The= se
> variables should be in the .bss section. Are they not already cleared = during
> the kernel loading?
This is nop indeed, be it linked in kernel, or loaded as a module.

I just looked at the posted patch, and I concur= .

Warner=C2=A0
--000000000000b0ea4d05d7716fe2-- From nobody Mon Feb 7 20:32:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2246219B4533 for ; Mon, 7 Feb 2022 20:32:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JsyWX0BG8z4bHC for ; Mon, 7 Feb 2022 20:32:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 8BA6589284; Mon, 7 Feb 2022 20:32:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 217KWUuI085793 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Feb 2022 20:32:31 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 217KWUdU085792; Mon, 7 Feb 2022 20:32:30 GMT (envelope-from phk) Message-Id: <202202072032.217KWUdU085792@critter.freebsd.dk> To: Sebastian Huber cc: FreeBSD Hackers Subject: Re: ntp_init() looks like a nop In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85790.1644265950.1@critter.freebsd.dk> Date: Mon, 07 Feb 2022 20:32:30 +0000 X-Rspamd-Queue-Id: 4JsyWX0BG8z4bHC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Sebastian Huber writes: > The ntp_init() function sets a couple of global variables to zero. These=20 > variables should be in the .bss section. Are they not already cleared=20 > during the kernel loading? They are, but I kept the code to minimize the diff relative to Dave Mills original version of the code. It can go no. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Feb 7 21:31:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 049B919AF5D0 for ; Mon, 7 Feb 2022 21:32:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jszqj5jp0z3FfP for ; Mon, 7 Feb 2022 21:32:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id u25so8630442vkk.3 for ; Mon, 07 Feb 2022 13:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Or/GETZvdeqaw2uCx2LaEGYd87UdUFJEVKUuej3iGEU=; b=Dj7zgdfmDvsCZOGcLN8DuSZBfSzehEgbNF+JPiB97uZ6FQ+eSkWHZ39TrGUspuMIkC 2hBp7noIx+RIQsPUnYWWGayJgR5j8Piy45ePMx30dyP5k2FnBc5hVckYzmDx3vKPWPB4 v95/o6a6ByNmCyShFchE4u40xn+ucO5QRvcNgDXcoKxGYlN6kaVbvP5IEbitLz7E5g+E /Tu+DiaKVHjDkGdR+grWAmEcGuJ3lbRipmaoMqwMfq3ryYOKZNS1FvaTHn91hM9sEXz0 eqQO78Eni9adZlppe4KpaoQHBKp23iOIYnesZO4QEBUwBiyk+fxLXNf77F5Y6+4CjczB g7vA== 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=Or/GETZvdeqaw2uCx2LaEGYd87UdUFJEVKUuej3iGEU=; b=qrA/aW4D9tB76YnQfU2Ml1Wy8eeh8dcG7XkQHI81wGrtVvFiwQcZ5rMtEZxXCbDqb2 wZDlGOcsizaRJsrBIb4phha2c06UvRzHLWz4tRc2S1lvf3MfS5Mm5br9xT6abG+VMT0K 6rBpRCeqfvGvEAWNKnFrAPhd5Z7bDQ0lpy+nzFPU3ZjxBGLqRmQQ/Jczx0ePpI8VlqMp h55bKwoZa/9kgGqs28kHUuBHDZe90/AjSv0Eljmq0fajfzEM/lN5NStIpx5/qrmJuv3W uTlI1jIggjwrfO8JkHfimePchuA8360LwwUETbljpgal4Aep0YwV+8pa9IdxI72rF7Fq SF8g== X-Gm-Message-State: AOAM533yb1dSYrVeMw+ObtWid/tuUeFgSESnlqONdh84nyZLs2PowXGz cVpe1OsaSwTMh6/BlKncVbIBig3MQ96tHd0Sh9PjZg3qDho= X-Google-Smtp-Source: ABdhPJzc7iqEUvVB+0s/mvzQFpJvJMOIyqHvwKJLU7gIf6ctKzGKQjH4xWLAUSBkSY7OAItT7Kjzt518vd3uIMjeQmg= X-Received: by 2002:a05:6122:130e:: with SMTP id e14mr660905vkp.26.1644269521309; Mon, 07 Feb 2022 13:32:01 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202202072032.217KWUdU085792@critter.freebsd.dk> In-Reply-To: <202202072032.217KWUdU085792@critter.freebsd.dk> From: Warner Losh Date: Mon, 7 Feb 2022 14:31:49 -0700 Message-ID: Subject: Re: ntp_init() looks like a nop To: Poul-Henning Kamp Cc: Sebastian Huber , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000bba63305d77454bc" X-Rspamd-Queue-Id: 4Jszqj5jp0z3FfP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Dj7zgdfm; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.98)[0.978]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000bba63305d77454bc Content-Type: text/plain; charset="UTF-8" On Mon, Feb 7, 2022 at 1:34 PM Poul-Henning Kamp wrote: > -------- > Sebastian Huber writes: > > > The ntp_init() function sets a couple of global variables to zero. > These=20 > > variables should be in the .bss section. Are they not already cleared=20 > > during the kernel loading? > > They are, but I kept the code to minimize the diff relative to Dave Mills > original version of the code. > > It can go no. > I think I lost the email race. I just pushed Sebastian's changes. Is this a request to not do this? If so, I'll revert. Warner --000000000000bba63305d77454bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 7, 2022 at 1:34 PM Poul-H= enning Kamp <phk@phk.freebsd.dk> wrote:
---= -----
Sebastian Huber writes:

> The ntp_init() function sets a couple of global variables to zero. The= se=3D20
> variables should be in the .bss section. Are they not already cleared= =3D20
> during the kernel loading?

They are, but I kept the code to minimize the diff relative to Dave Mills original version of the code.

It can go no.


--000000000000bba63305d77454bc-- From nobody Mon Feb 7 21:59:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7BDC419A1F9D for ; Mon, 7 Feb 2022 21:59:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jt0Rc2N5vz3kQ7 for ; Mon, 7 Feb 2022 21:59:39 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id D60AD89295; Mon, 7 Feb 2022 21:59:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 217LxKrV086128 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 7 Feb 2022 21:59:20 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 217LxJbj086127; Mon, 7 Feb 2022 21:59:19 GMT (envelope-from phk) Message-Id: <202202072159.217LxJbj086127@critter.freebsd.dk> To: Warner Losh cc: Sebastian Huber , FreeBSD Hackers Subject: Re: ntp_init() looks like a nop In-reply-to: From: "Poul-Henning Kamp" References: <202202072032.217KWUdU085792@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86125.1644271159.1@critter.freebsd.dk> Date: Mon, 07 Feb 2022 21:59:19 +0000 X-Rspamd-Queue-Id: 4Jt0Rc2N5vz3kQ7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Warner Losh writes: > > It can go no. > > > > I think I lost the email race. I just pushed Sebastian's changes. Is this a > request to not do this? If so, I'll revert. No, that is my T480's keyboard wearing out, so the 'w' didn't take :-/ I'm fine with removing it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Feb 7 23:04:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 811D719A2312 for ; Mon, 7 Feb 2022 23:04:57 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jt1tw6BD5z4h5F for ; Mon, 7 Feb 2022 23:04:56 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ot1-x332.google.com with SMTP id w27-20020a9d5a9b000000b005a17d68ae89so11971617oth.12 for ; Mon, 07 Feb 2022 15:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h8Rf/V+ImoLbJnHLXC/RTiOFG3r1jKlDzeLnZQA49ao=; b=Gf3ZculpLm+bk0hFjNF8nvEWEwzA/whuhJLlCqWidMUd0LptIewVFFqcvg762rvTzB o+XWxEfhWcS0ZT6dPdnfijXAFTRy13b2hj+YZ0UMiyqfFFABWmm3GUfDU5D736sgNkuB 1jwzLC/LQ7wzxlfqjnk81OW6R2by9V8WyyUJffE7gOwRq24KnWnryCPh8L6ZCyNsuU0/ 7EfuepqPiK2JxFaYoSfp+re4ql5ltA00SLDVF8JEzhHGryckZGoZDGdy4uAnxf+5aosD KBb2BPvhXLTPJa8ONELO9JYZs3f+qSjcdSz/sLdgRJunXyCnKZVwBWJ1lAeihQYyC2LW JOGg== 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=h8Rf/V+ImoLbJnHLXC/RTiOFG3r1jKlDzeLnZQA49ao=; b=SgPK2OBRVqLv3a2+is3IF7IUrQs059BdCnoekG4N55f4N2+MLR5oSxpNqqefg0480B 6osqAtGtZ2BsVSrO93okOvVcsER0WwW7ffz55S2F69Hzp02o+d/Mt7o/YwGigTf7LSs8 u5l6XdU5ipQsJWkbEMXNAtWJc1Hy9CUvq9kW5QESsjV1zyEQKR0UJT9Me0L+tlW1zM5M ccFtlXH7qO8ccmu1Sa7xJrj0y5NCeEZlKdOxwHi51Zxsic4DwyFXUyqRPGAdHHc4XFuT 6EkmNk19AtBhwjohCP/kzz78xS+BoqiWBtQCYBz7erD4pDQ7pIKXI1l1vVoRasR+u6q/ eGqg== X-Gm-Message-State: AOAM531AVXE77aPCjge1fbRX0lSuyYumtTonZORrXEviGD8AnWPWN9ME KCvCkP+qWRGy4eeBkWtDfuz5nPYiFc9mYjr+lOQ= X-Google-Smtp-Source: ABdhPJwex54PMjp3ft6E9UnLyEdhUOMkFJIuEfzMA1fjKpbTrML1cldLJOcbvro8RMtj9hX8iLPnEeOXKDnYVXFxrdw= X-Received: by 2002:a9d:6041:: with SMTP id v1mr842376otj.35.1644275095992; Mon, 07 Feb 2022 15:04:55 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202202072032.217KWUdU085792@critter.freebsd.dk> In-Reply-To: From: Mehmet Erol Sanliturk Date: Tue, 8 Feb 2022 02:04:19 +0300 Message-ID: Subject: Re: ntp_init() looks like a nop To: Warner Losh Cc: Poul-Henning Kamp , Sebastian Huber , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000027cbc05d775a146" X-Rspamd-Queue-Id: 4Jt1tw6BD5z4h5F X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Gf3Zculp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::332 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::332:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000027cbc05d775a146 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 8, 2022 at 12:33 AM Warner Losh wrote: > > > On Mon, Feb 7, 2022 at 1:34 PM Poul-Henning Kamp > wrote: > >> -------- >> Sebastian Huber writes: >> >> > The ntp_init() function sets a couple of global variables to zero. >> These=20 >> > variables should be in the .bss section. Are they not already cleared=20 >> > during the kernel loading? >> >> They are, but I kept the code to minimize the diff relative to Dave Mills >> original version of the code. >> >> It can go no. >> > > I think I lost the email race. I just pushed Sebastian's changes. Is this > a request to not do this? If so, I'll revert. > > Warner > My reply is not an answer to your question , but I want to make a remark . I am developing a software about "A multi-media information management system" ( a continuation of my PhD thesis demonstration program ) having around 12 000 Pascal procedures . For "Record"-s , I am doing the following : By using a script system , I am generating many Procedures about operations on that "Record" , such as : (1) Allocate (2) Initialize (3) ... (n) Dispose In your case , it is said that "in another part this record is initialized ..." Assume that , "another part" is modified to ignore this initialization , and there is not a call to an initializer . In Turkish , this is called "To load a liver to a cat" ( I am sorry to say that ) . To prevent such disastrous possibilities ( after losing significant times to understand what is the reason ) I have developed such an approach . My ideas are like that . Obviously you know much better than me how to develop FreeBSD . With my best wishes , Mehmet Erol Sanliturk --000000000000027cbc05d775a146 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 8, 2022 = at 12:33 AM Warner Losh <imp@bsdimp.co= m> wrote:


On Mon, Feb 7, 2022 at 1:34 PM Poul-= Henning Kamp <ph= k@phk.freebsd.dk> wrote:
--------
Sebastian Huber writes:

> The ntp_init() function sets a couple of global variables to zero. The= se=3D20
> variables should be in the .bss section. Are they not already cleared= =3D20
> during the kernel loading?

They are, but I kept the code to minimize the diff relative to Dave Mills original version of the code.

It can go no.

I think I lost the email = race. I just pushed Sebastian's changes. Is this a request to not do th= is? If so, I'll revert.

Warner=C2=A0



My reply is not an answer to your question , but I want to make a rem= ark .


I am developin= g a software about "A multi-media information management system"<= /div>
( a continuation of my PhD thesis demonstration program ) ha= ving around=C2=A0 12 000
Pascal procedures .
=

For=C2=A0 "Record"-s , I = am doing the following :

By using a scri= pt system , I am generating many Procedures =C2=A0 about=C2=A0 operations o= n that
"Record" , such as :
(1) All= ocate
(2) Initialize
(3) ...

(n) Dispose


In your case , it is said that "in another par= t this record is initialized ..."

= Assume that ,=C2=A0=C2=A0 "another part" is modified to ignore th= is initialization , and there is not
a call to=C2=A0 an init= ializer .=C2=A0

In Turkish , this i= s called "To load a liver to a cat"=C2=A0 ( I am sorry to say tha= t ) .

To prevent such disastrous possibi= lities ( after losing significant times to understand
= what is the reason ) I have developed such an approach .

My ideas are like that .



Obviously y= ou know much better than me how to develop FreeBSD .

With my best wishes ,


Mehmet Erol Sanliturk








=C2=A0
--000000000000027cbc05d775a146-- From nobody Tue Feb 8 08:41:28 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6E80319AD625 for ; Tue, 8 Feb 2022 08:42:01 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtGhl3mfTz3pGq for ; Tue, 8 Feb 2022 08:41:58 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b1653d5.dip0.t-ipconnect.de [91.22.83.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id A0B652AD7B for ; Tue, 8 Feb 2022 09:41:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1644309709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=oKjcL6GX9UhYCgsAGz1uKQ7hhLRbQUbuyaiYdeogaeo=; b=cqTM9bqa1qEwHYsPA4NMN1RSyatbO+OwcheOHAKnGtZxgvXU4eYEJg62IqSdG/CV2JxMCo AqjDnTxu5Tg3qTXZShb2PmHE1MY0dc5FgEMeBarERNqv/FSyTYceVN45YJFRGw7KZTNZXP 3Ny7T5LszbBdlGjrlGq3XtoL9iXgqgpT/JnrdYlji4mUVcf+OSDTOA0PlwmHclUbfLba4r Gfj18qMCu82SH7/rU4hjdMlEgp4hVzTjyoMFTj+5CcLeIsVBVWeyNSj2pDgVkreaah3f/7 CXOI5jysKQY/k+PvxDA2W8MNKtcFjpKlvsbt2b7EyVlrdYt76sT2W7KTw8wdYw== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 1090AA411 for ; Tue, 8 Feb 2022 09:41:31 +0100 (CET) Date: Tue, 08 Feb 2022 09:41:28 +0100 Message-ID: <20220208094128.Horde.LqeAS3LDe4RHYSV3IH2XY96@webmail.leidinger.net> From: Alexander Leidinger To: hackers@freebsd.org Subject: Behavior of /dev/pts in a jail? Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4JtGhl3mfTz3pGq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=cqTM9bqa; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.83.213:received] X-ThisMailContainsUnwantedMimeParts: N Hi, I'm debugging a problem with gnupg on -current (as of Jan 20, but I see this problem since several months). The pinentry-tty program fails to ask for a PW. One of the gnupg authors found a bug which makes the pinentry-tty program segfault (fixed in v1.2.0), but this doesn't solve the problem (converts the segfault into a error output). We narrowed the problem down to gpg-agent not being able to see anything in /dev/pts and as such not being able to open my tty. So: - a jail with devfs - login into the jail via "jexec zsh" followed by "su - " - a shell-wrapper for pinentry-tty which "ls -la /dev/pts" into a logfile - in the user-zsh inside the jail, I can see /dev/pts/2 (my tty) as being rw for me in "ls -la /dev/pts" with the same uid as my user (the user id inside the jail and the user id to which I ssh-ed on the jail-host are the same) - executing gpg in this same shell in a way which is supposed to ask for a PW results in the pinentry-wrapper being called and /dev/pts being completely empty in the ls output in the logfile -> no PW being asked - doing a ls of /dev/pts afterwards inside the shell still shows /dev/pts/2 Neither gpg nor gpg-agent are SUID. This behavior surprises me. The non-root shell I use inside the jail sees /dev/pts/2. This shell forks gpg which forks gpg-agent which forks pinentry-tty. As such I would expect /dev/pts/2 being visible to pinentry-tty. For me either this entry in the FS should be visible to all processes of this user, or to none. What am I missing here? Gnupg ticket: https://dev.gnupg.org/T5814 Workaround if someone has the same problem: "gpg --pinentry-mode=loopback ..." Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Tue Feb 8 12:37:32 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C3F519ADE7B for ; Tue, 8 Feb 2022 12:38:03 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtMx62cGcz4ccm for ; Tue, 8 Feb 2022 12:38:02 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 07c3e891; Tue, 8 Feb 2022 12:37:58 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 7fc0d7b1 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Tue, 8 Feb 2022 12:37:56 +0000 (UTC) Date: Tue, 8 Feb 2022 13:37:32 +0100 From: Michael Gmelin To: Alexander Leidinger Cc: hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? Message-ID: <20220208133732.500611e3.grembo@freebsd.org> In-Reply-To: <20220208094128.Horde.LqeAS3LDe4RHYSV3IH2XY96@webmail.leidinger.net> References: <20220208094128.Horde.LqeAS3LDe4RHYSV3IH2XY96@webmail.leidinger.net> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4JtMx62cGcz4ccm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-1.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 08 Feb 2022 09:41:28 +0100 Alexander Leidinger wrote: > Hi, > > I'm debugging a problem with gnupg on -current (as of Jan 20, but I > see this problem since several months). The pinentry-tty program > fails to ask for a PW. One of the gnupg authors found a bug which > makes the pinentry-tty program segfault (fixed in v1.2.0), but this > doesn't solve the problem (converts the segfault into a error > output). We narrowed the problem down to gpg-agent not being able to > see anything in /dev/pts and as such not being able to open my tty. > > So: > - a jail with devfs > - login into the jail via "jexec zsh" followed by "su - " > - a shell-wrapper for pinentry-tty which "ls -la /dev/pts" into a > logfile > - in the user-zsh inside the jail, I can see /dev/pts/2 (my tty) as > being rw for me in "ls -la /dev/pts" with the same uid as my user > (the user id inside the jail and the user id to which I ssh-ed on the > jail-host are the same) > - executing gpg in this same shell in a way which is supposed to > ask for a PW results in the pinentry-wrapper being called and > /dev/pts being completely empty in the ls output in the logfile -> no > PW being asked > - doing a ls of /dev/pts afterwards inside the shell still shows > /dev/pts/2 > > Neither gpg nor gpg-agent are SUID. > > This behavior surprises me. The non-root shell I use inside the jail > sees /dev/pts/2. This shell forks gpg which forks gpg-agent which > forks pinentry-tty. As such I would expect /dev/pts/2 being visible > to pinentry-tty. > > For me either this entry in the FS should be visible to all processes > of this user, or to none. > > What am I missing here? I've seen a similar problem with jails running on top of bhyve (in that case, doing ssh wouldn't work). The solution back then was to add ttyu* to devfs rules _before_ starting the jail: devfs rule -s 3 add 3250 path "ttyu*" unhide Not sure if what you're seeing is related, but it feels a bit like that. See also https://lists.freebsd.org/archives/freebsd-current/2021-August/000409.html Cheers Michael > > Gnupg ticket: https://dev.gnupg.org/T5814 > Workaround if someone has the same problem: "gpg > --pinentry-mode=loopback ..." > > Bye, > Alexander. > -- Michael Gmelin From nobody Tue Feb 8 15:32:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2691E19A9064; Tue, 8 Feb 2022 15:32:35 +0000 (UTC) (envelope-from weh@microsoft.com) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2117.outbound.protection.outlook.com [40.107.215.117]) (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 4JtRpN6rcDz3CMD; Tue, 8 Feb 2022 15:32:28 +0000 (UTC) (envelope-from weh@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kl/jRBVi+K+fyh2Zh7AhPgceH+supoQwaOHBAp763t2ZAKAOQJ8Yn9nf2RAY+Zk70VaDojE0O3GPAYpHjn2csBmIVYmUANoTRDqAdXMt4uswvkoB//yHCu8UvTbwdp/8l0qmqhDhC87wv5ntQ22FrbMUSGMjfud7de0VE10O601uiIYnBnzFnJvMwuNfhtne9m+E7beJiSzWJUTWoP3Fu1J1bUKulQ5e3/oJMtZWCC0213y3Sogxli/v7T7/AfhLO6oEXgFAUu2TuEpfMAkBPtdogG34ttZOqUYX1D+1JojjnG438rWxYztnQL9bSFOTzHtaivTWIaz4rGcSTqCQdw== 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=iXbaZIY0jMMVxsgEKBwYF4ERgLjjcrDa7pftaoXLWnI=; b=NwbxxWsKFqRrGPBl6lFnpHCxduMOm1Uu+mW/ZVKDbTbr1QUy9zr31WuhKIm+OtCOcDxZUNLagX2GURiwD6HhnVdqLkbT83NoY5SUQSe81fHohyeE0+u93xkLRxeV8Y8O4ZLOV6kBnZWCqIDmtXY7Z9/eGgFHGcAzDV4r7KeoQjl/Xfg7AvDqLRem0n0DoKZakSmgzabT5kS+oGFPFkoIwyJBks+C5WyCokrIt+aN715K5mz6LIUDN7d007I/inGBZZN8M/28EUn/vW62DPhMZ89Tx1d92Qu9+6pFb7j/AybCYVfvB/aVqjxTmzxWRtH+YZHPAWS3U/+Y11hPbWPDYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iXbaZIY0jMMVxsgEKBwYF4ERgLjjcrDa7pftaoXLWnI=; b=AkCzUf5y8RcRVIU20+y1AMrSX5vC2Eh5POQ4vxnbGR4Z3QipraW9usmn3I5sbHzAFsA3R81vy6q9Ut7il85jyxb97PSSKzDfP6tMDNpbU8/vmsGhplm/00kmrj2wcApL71NoVIhReZdC/Ioq1LvcvPqgmC0yOd1WHU09NY/o7jc= Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM (2603:1096:4:fc::7) by KL1P15301MB0482.APCP153.PROD.OUTLOOK.COM (2603:1096:820:53::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.2; Tue, 8 Feb 2022 15:32:15 +0000 Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::d84a:68fc:eddf:506a]) by SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::d84a:68fc:eddf:506a%7]) with mapi id 15.20.4995.004; Tue, 8 Feb 2022 15:32:15 +0000 From: Wei Hu To: "freebsd-hackers@FreeBSD.org" CC: "freebsd-net@FreeBSD.org" Subject: Receive Side Coalescing(RSC) and LRO Thread-Topic: Receive Side Coalescing(RSC) and LRO Thread-Index: Adgc/x74lPUJFYOSSR+HOxEg0whDpQ== Date: Tue, 8 Feb 2022 15:32:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e8428f51-6f01-49d3-b91b-c2a250195773;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-02-08T15:14:27Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b17cc1e-3785-4937-d2e1-08d9eb182f4e x-ms-traffictypediagnostic: KL1P15301MB0482:EE_ x-ms-exchange-atpmessageproperties: SA|SL x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hMZipzXj82uzV2T0/Y+S4qYUZOUceTatNaWPAnhpbDa7pX7giwiItavcPP6gYBNSXm9DyyJqN+D8/4UMGcAXyHRrN23N1fJX2eRlf2ueaAVKm0aNpTkFB0AnAvJlfouxV9lxRCmD0Jeea4s0LGz5m8C+a96UGr+Cy4r5hDE+gU7RrYn0u/SXXFysQK/hWq79zM1WXM2zhArPDaUpAkYVcdCZFvW9yEOc7JlgR66oZAZrpaJiRsHn2HFVrz9meDdRlZVJCiftmetg+U5QaRmCDmFoyTtoIy1iJ7S1Fwr9WGqXxLTYilc5zW4yZgDeEETtanfor40hQgozn1tucE+tl++wvk6jQ3U94s/5U2ELoeqXo5VOGtomo7Ncoj+QNq2gvuWaNEFF/7FkVKjEPY5hIpGYwE4KnEduqW8CmDVv31wMqPP17E0hghVGb5/UtG6UFGkpvjTabghsSzKij4kkRZBwmRR+eYvd1ujH0r4BqbbMIHC5iuORsOcqlQyiedPkAzVKaAnlbDCyCttjG2VuqkDwuy+cPgn2FiF6rJPqgQFH19FlIH17WTNfowyZKLUyS4XcaGWjZSIHS6kAjCrjTNAiVp919tTneComk3yE3K64wOu7VJOmcgm71u8yTEyKehn+GC021ii1GVnUqrbiw23XfDz1M6cpIBJfXg9W6mHXTtdcO786mGj4Fn8ZSmk0hetdvsTxrExLcntbZFyOLZ4OqiVH4wfHdPxifKjq1FFO+SGIAAX7exdAIuhKk5nR x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SI2P153MB0441.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(33656002)(55016003)(66946007)(82960400001)(82950400001)(38100700002)(186003)(450100002)(5660300002)(8990500004)(7696005)(66556008)(38070700005)(122000001)(4744005)(2906002)(8936002)(76116006)(66476007)(86362001)(52536014)(316002)(4326008)(26005)(71200400001)(10290500003)(508600001)(8676002)(9686003)(64756008)(66446008)(6506007)(6916009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Q4mspvdZ2IXGTSNisM68onTNEU7EwbkHC8BQvXtYo9BpVHvSxHBDB19LHJov?= =?us-ascii?Q?LM8ynSLkTViGIYE+0xUTpslEEeOZNZoNyguRUtJgoMexnqHTACLKX/zxKans?= =?us-ascii?Q?F3U4qeXb3Gs5VXUb7zcRVLdflipO5efQPkoPB6uJPEWUrSSmfpTKHDeOr7wq?= =?us-ascii?Q?ndeBt4Bv90i1db/I2Pbw36LDN2w6AgjkK1D9FFD0JfdDEp1bNGAhKBCq6OYX?= =?us-ascii?Q?VHK+TOq8K3Q/x/45Aa0CjyDlWV6i5lMLXfJbQ8T66YBlike0tuosXSljT94P?= =?us-ascii?Q?qJMPwXrN2SbZUQqcAxkLHUnuVOIcxt98ERq6WfFCYgFGV+2XZJlvX8DjRKmX?= =?us-ascii?Q?WSCxtuW8oNe/LtgM86E2USR669V3Siwhaxei3Q5Bhf3v0VtnRz5W+2bjy/ez?= =?us-ascii?Q?6MNrlDrFXAPPx/0/RcjoHRoSyyzLQAXLYqbZQhjQZk/79MUKLJstWFOEMdav?= =?us-ascii?Q?ctmDbYK6gE8vIUg1tfNrdP8ge/0VuTTK5EuQHRjYUHqAPuA0uYmNApYgAgMn?= =?us-ascii?Q?/S3ayce8/neTnEfPcAnMFZBWp13oVXIKAFS9MfA13eKw4sJ3kNIzxVofyfuI?= =?us-ascii?Q?wOThEnZPkHHga7LHfddj8UGixsnP5jVl/S1M+bINijX1CRiJbqPExBLO+1sf?= =?us-ascii?Q?+RY0dq9c8BXMKm4Cy6S1PNVrCeBUHRolYQvf948E+4TUbrFZN64e7l00Zb3y?= =?us-ascii?Q?Np/FPaKd0pichtftkQx/KQqCDiiYmKqqrl/a6X/5al+ALXAm4sDB5ASCPd2H?= =?us-ascii?Q?+HLHMcGWdowvvb1MSWtllZKCCnJoNvhs4xCbpZ+BhmwLmCff9Y0kzHhigKSz?= =?us-ascii?Q?D8gY27IQNGpfJBwDNL4OTIK7BrJZA0IcPhNkhvuP16s+oORHJbcVuGPSs8Bx?= =?us-ascii?Q?TwOFBKIn4y1NPnMRPC/J5zbGaaMqtulBDiJ9TdwDmqIcH5B2gvuJSDcuL127?= =?us-ascii?Q?Ribx2CHywoQGUOOixAaihmE2TH9inHDKTEP5GfFFYVuwlI1ISuL9Goq1CBhN?= =?us-ascii?Q?gaq4j6KOo/nSa5Od8GLuYWSiPbVJuxj5wqPdkUMer1V6a5yE3sd9QqAh/G9b?= =?us-ascii?Q?TLlM1/SHpCWv4JwE8jUUur8WpCTAVkCgNd5HZUxKZhDpV5fesr5g5AjmfOmf?= =?us-ascii?Q?72aNfi4qH7ORpUJPIAARaMja5mpp4Ep5dOIc1Aqe9S2hIoq4v+KpVjH5JqDe?= =?us-ascii?Q?iFFtTTOoWX1DsAnMQUIAncM/UOCcdYamNEF0Q1eLJFhvS85lfNWgealwvKP7?= =?us-ascii?Q?MVnS33sdkuRjHDdg8YYjV73PCt7VK8at1b3NaJh8/GGGXpmf11ZN+GXvxiQR?= =?us-ascii?Q?9rEoKCKzZSfq2UZfUsS4r80qH5Mk0QmJD/oWO7ykJdDH5SEquAOK2M+R0pOV?= =?us-ascii?Q?ADKK4511UFIffo3f1HH4IWhz7vXsKhuw1y2DQvmn9T3vChihFd9/vy3HQeSk?= =?us-ascii?Q?8BKO2iTOx6GcdlQxcmMxduGCjYFHVp1Y/pv0fpZukDL5J3bPS6Dgg98/xReh?= =?us-ascii?Q?wTZE1nEGMRf51Ha4ilx0Bh3Gi2XwuzRkaMDoOsfXwoUBhu49mwJrcpVPsWrv?= =?us-ascii?Q?kxQvSIk9mdfAcoknbZ6U610Ibgjue/DyO1YlV9icxyr6lB+Cx2beB+zJc8ZF?= =?us-ascii?Q?bZEb+lcdcnF4/rlDpQhD5L8=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SI2P153MB0441.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 2b17cc1e-3785-4937-d2e1-08d9eb182f4e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2022 15:32:15.2663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8/TQpqiP6mbNPZbXSuIaHNfcOQ+7YDvxv/ftzrRJkVYmzP3u4HNrujI7UTFScIlhiWkClOz/uRSYd5sfR+rJJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0482 X-Rspamd-Queue-Id: 4JtRpN6rcDz3CMD X-Spamd-Bar: ---------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=AkCzUf5y; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of weh@microsoft.com designates 40.107.215.117 as permitted sender) smtp.mailfrom=weh@microsoft.com X-Spamd-Result: default: False [-10.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; 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]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[microsoft.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.215.117:from]; BLOCKLISTDE_FAIL(0.00)[2603:1096:4:fc::7:server fail,40.107.215.117:server fail]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-net]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.215.117:from] X-ThisMailContainsUnwantedMimeParts: N Hi, I am trying to find the term that FreeBSD uses for the network offloading f= eature like RSC. RSC is Microsoft's term which is essentially the same as L= RO in Linux, in which the packet aggregation happens on the hardware NIC. The LRO on FreeBSD seems different. It looks to be the GRO in Linux, in whi= ch the packet aggregation happens in software above the NIC driver. There = is a feature bit IFCAP_LRO in net/if.h. So, is there a different feature bit on FreeBSD which means only for the ha= rdware RSC/LRO? Or does the IFCAP_LRO mean both hardware and software LRO? = What I want to achieve is to let user disable the hardware RSC/LRO and leav= e software LRO untouched on FreeBSD. What is the proper way to differentiat= e these two on FreeBSD? Thanks, Wei=20 From nobody Wed Feb 9 10:37:37 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2898919BD9ED for ; Wed, 9 Feb 2022 10:38:10 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtxDJ4sGfz3p4x; Wed, 9 Feb 2022 10:38:08 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b1653d5.dip0.t-ipconnect.de [91.22.83.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 852C52C33B; Wed, 9 Feb 2022 11:37:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1644403078; h=from:from:reply-to:subject:subject:date:date: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=qW/rWjwZCCojC4vQ7Y3XJG50T/RhJizB702ODLc/cfM=; b=Y3mp1/6JMLJ7Vpq7UDEbMOKZPG2JVw0sLSFOzEyLwEm4oGwkg4lUpC6nx22vUYVxM2juXS VoNs8BfT+knl6GvSRFdunKDckPt2dzI6xZxV0KmK9xFl2Zex4JGS8ecxqP36NM0vCblPCu tzM2RDdfwJuexka9rtuhpqUJHfL0iR/hgrjQXHkfBIrKUTVOiix1GdA6x/cxfsJTNtHmcP I3p8fj6XlVn2lZjv5dQERYnJdsyfdBV1SZhkXTEOocn1OBj53/XlSV5Y89tHzBXkJiAXI4 qD7IXuEszTmqueOPMeUiWBXyL30oaTqm5J5oluLUphHq37ipEf55qIqtNQMnzw== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 1D2356209; Wed, 9 Feb 2022 11:37:47 +0100 (CET) Date: Wed, 09 Feb 2022 11:37:37 +0100 Message-ID: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> From: Alexander Leidinger To: Michael Gmelin Cc: hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? References: <20220208094128.Horde.LqeAS3LDe4RHYSV3IH2XY96@webmail.leidinger.net> <20220208133732.500611e3.grembo@freebsd.org> In-Reply-To: <20220208133732.500611e3.grembo@freebsd.org> Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4JtxDJ4sGfz3p4x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="Y3mp1/6J"; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.83.213:received] X-ThisMailContainsUnwantedMimeParts: N Quoting Michael Gmelin (from Tue, 8 Feb 2022 13:37:32 +0100): > I've seen a similar problem with jails running on top of bhyve (in that > case, doing ssh wouldn't work). > > The solution back then was to add ttyu* to devfs rules _before_ starting > the jail: > > devfs rule -s 3 add 3250 path "ttyu*" unhide > > Not sure if what you're seeing is related, but it feels a bit like that. > > See also > https://lists.freebsd.org/archives/freebsd-current/2021-August/000409.html I tried that now. It doesn't help. I'm not really surprised, as there is no ttyu* device visible on the host itself (serial devices disabled in bios). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Wed Feb 9 11:56:49 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BACCF19A78A9 for ; Wed, 9 Feb 2022 11:57:03 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtyzL3XfQz4tJ6; Wed, 9 Feb 2022 11:57:02 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 148b7285; Wed, 9 Feb 2022 11:56:53 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 2af07ad6 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 9 Feb 2022 11:56:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Behavior of /dev/pts in a jail? From: Michael Gmelin In-Reply-To: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> Date: Wed, 9 Feb 2022 12:56:49 +0100 Cc: hackers@freebsd.org Message-Id: <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> To: Alexander Leidinger X-Mailer: iPhone Mail (19C63) X-Rspamd-Queue-Id: 4JtyzL3XfQz4tJ6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-1.59 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.998]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 9. Feb 2022, at 11:38, Alexander Leidinger wr= ote: >=20 > =EF=BB=BFQuoting Michael Gmelin (from Tue, 8 Feb 2022= 13:37:32 +0100): >=20 >> I've seen a similar problem with jails running on top of bhyve (in that >> case, doing ssh wouldn't work). >>=20 >> The solution back then was to add ttyu* to devfs rules _before_ starting >> the jail: >>=20 >> devfs rule -s 3 add 3250 path "ttyu*" unhide >>=20 >> Not sure if what you're seeing is related, but it feels a bit like that. >>=20 >> See also >> https://lists.freebsd.org/archives/freebsd-current/2021-August/000409.htm= l >=20 > I tried that now. It doesn't help. I'm not really surprised, as there is n= o ttyu* device visible on the host itself (serial devices disabled in bios).= >=20 > Bye, > Alexander. >=20 Hi Alex, I was able to reproduce the issue locally. The problem is caused by jexec inheriting the pty from the jail host. If you use a pty that was created inside of the jail, gpg-agent/pinentry wor= ks as expected. This can be accomplished, e.g., by running tmux inside of the jail: jexec gpgtest pkg install tmux tmux gpg --gen-key Running sshd inside of the jail and connecting to it using ssh has the same e= ffect. Cheers Michael From nobody Wed Feb 9 12:22:13 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DD9EA19BA404 for ; Wed, 9 Feb 2022 12:22:26 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JtzXd6vWyz3MbW; Wed, 9 Feb 2022 12:22:25 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b1653d5.dip0.t-ipconnect.de [91.22.83.213]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id F19B52C3C5; Wed, 9 Feb 2022 13:22:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1644409343; h=from:from:reply-to:subject:subject:date:date: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=pRTQ9Js8dTUe3oSeYttmcoD5EFVSvLQLZ0l0BxkIfj0=; b=Em8kdkEjOg8J5WuG17bX5i5yPRI1WsV6wOI7RBXBz1x4tAueP1eOAUJ4fd7eF8JMJt5ltH Pok7WGtmGQFTWHixN/VVO8lX00MKXw78WtjkmCpERwudBIE/a0Hdo6we7nnJjqOv8kl2co g0K6BLpSXpXmyVrLCDZl/hVc12EemMaSQd53LtbXRN/iq7pS2s6lncCI+Ni7pS/hvYOu2V h8GbCgBg6zSQNMG+Use9FC6J0ygYxJO+QH1mVJUgDL7ED8bJje1ngiZm7/ZBOeJt+NuCJ+ LMqKiNa5qI5vqKjehoNqyHYsf46KHe6fOBAp/WTF+4yCDfkr+DbkylAoKJN94g== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id BF3646604; Wed, 9 Feb 2022 13:22:18 +0100 (CET) Date: Wed, 09 Feb 2022 13:22:13 +0100 Message-ID: <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> From: Alexander Leidinger To: Michael Gmelin Cc: hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> In-Reply-To: <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> Accept-Language: de,en Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Disposition: inline X-Rspamd-Queue-Id: 4JtzXd6vWyz3MbW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=Em8kdkEj; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.83.213:received] X-ThisMailContainsUnwantedMimeParts: N Quoting Michael Gmelin (from Wed, 9 Feb 2022 12:56:49 +0100): > I was able to reproduce the issue locally. > > The problem is caused by jexec inheriting the pty from the jail host. > > If you use a pty that was created inside of the jail, > gpg-agent/pinentry works as expected. > > This can be accomplished, e.g., by running tmux inside of the jail: > > jexec gpgtest > pkg install tmux > tmux > gpg --gen-key > > Running sshd inside of the jail and connecting to it using ssh has > the same effect. I confirm (with ssh instead of jexec) the behavior. What I don't understand is how this works. ls is not build-in to the shell. So how can it be that the jexec-ed shell can fork ls and it sees the content of /dev/pts/, and the ls forked from gpg->gpg-agent->pinentry-wrapper can't? And how could we fix this (or why wouldn't we want to fix it)? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Wed Feb 9 13:21:52 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A2E1E19AF2B1 for ; Wed, 9 Feb 2022 13:22:31 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jv0sy2Vdfz4VDS; Wed, 9 Feb 2022 13:22:30 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 47cb3433; Wed, 9 Feb 2022 13:22:26 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id c78928e7 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 9 Feb 2022 13:22:25 +0000 (UTC) Date: Wed, 9 Feb 2022 14:21:52 +0100 From: Michael Gmelin To: Alexander Leidinger Cc: Michael Gmelin , hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? Message-ID: <20220209142152.13373548.grembo@freebsd.org> In-Reply-To: <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jv0sy2Vdfz4VDS X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-1.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 09 Feb 2022 13:22:13 +0100 Alexander Leidinger wrote: > Quoting Michael Gmelin (from Wed, 9 Feb 2022 > 12:56:49 +0100): > > > I was able to reproduce the issue locally. > > > > The problem is caused by jexec inheriting the pty from the jail > > host. > > > > If you use a pty that was created inside of the jail, > > gpg-agent/pinentry works as expected. > > > > This can be accomplished, e.g., by running tmux inside of the jail: > > > > jexec gpgtest > > pkg install tmux > > tmux > > gpg --gen-key > > > > Running sshd inside of the jail and connecting to it using ssh has > > the same effect. > > I confirm (with ssh instead of jexec) the behavior. > > What I don't understand is how this works. ls is not build-in to the > shell. So how can it be that the jexec-ed shell can fork ls and it > sees the content of /dev/pts/, and the ls forked from > gpg->gpg-agent->pinentry-wrapper can't? gpg-agent starts as a daemon, so it detaches from the controlling terminal, closing all open fds to the pty. You can test this yourself easily: [root@gpgtest ~]# cat >test.sh<<"EOF" #!/bin/sh sleep .5 echo echo "/dev/pts contains $(ls /dev/pts | wc -l | xargs) files" EOF [root@gpgtest ~]# chmod 755 test.sh [root@gpgtest ~]# ./test.sh /dev/pts contains 1 files [root@gpgtest /]# daemon ./test.sh [root@gpgtest /]# /dev/pts contains 0 files You can also compare the file descriptors opened by your shell vs those opened by gpg-agent using `procstat -f `. > And how could we fix this (or > why wouldn't we want to fix it)? I think that the current behavior is already hacky, but makes jexec more useful in practice (so you *can* actually do ssh from one jail to another without having to create a new pty), thanks to entries in devfs.rules. In the end, jexec just calls jail_attach, it's not starting a whole new user session. Expanding this to daemonized processes would make things a lot more complex (like: is this the pty created from within the jail or one created outside of it, what happens to it if the user session on the jail host ends, etc.). The one thing I could see is adding a parameter to jexec that makes it allocate a new pty within the jail (similar to what ssh would do). This would also workaround the issues I had with bhyve (ttyu* not being allowed to seen inside the jail). Or write a thin wrapper that is called inside of the jail, to run a program in a newly allocated pty. Maybe someone with more insights to how jails work internally could give their input here. In the meantime, tmux is probably the most lightweight way of working around this in your specific use-case, without having to run sshd. Cheers Michael p.s. Once you know what you're looking for, you can find mailing list and forum entries about it going back some 15 years, which include pretty much the same workarounds I came up with *sigh* > > Bye, > Alexander. > -- Michael Gmelin From nobody Wed Feb 9 13:37:09 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D3FA419B8B44 for ; Wed, 9 Feb 2022 13:37:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jv1C402Wbz4cPY; Wed, 9 Feb 2022 13:37:20 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 1090E16057; Wed, 9 Feb 2022 14:37:12 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 08F4E5E8DF; Wed, 9 Feb 2022 14:37:09 +0100 (CET) Date: Wed, 09 Feb 2022 14:37:09 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Michael Gmelin Cc: Alexander Leidinger , hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? Message-ID: <20220209133709.NBhO-%steffen@sdaoden.eu> In-Reply-To: <20220209142152.13373548.grembo@freebsd.org> References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> <20220209142152.13373548.grembo@freebsd.org> User-Agent: s-nail v14.9.23-233-gc02d5a13cc OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4Jv1C402Wbz4cPY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-1.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Michael Gmelin wrote in <20220209142152.13373548.grembo@freebsd.org>: |On Wed, 09 Feb 2022 13:22:13 +0100 |Alexander Leidinger wrote: |> Quoting Michael Gmelin (from Wed, 9 Feb 2022 |> 12:56:49 +0100): |> |>> I was able to reproduce the issue locally. |>> |>> The problem is caused by jexec inheriting the pty from the jail |>> host. |>> |>> If you use a pty that was created inside of the jail, |>> gpg-agent/pinentry works as expected. |>> |>> This can be accomplished, e.g., by running tmux inside of the jail: |>> |>> jexec gpgtest |>> pkg install tmux |>> tmux |>> gpg --gen-key ... |Maybe someone with more insights to how jails work internally could |give their input here. | |In the meantime, tmux is probably the most lightweight way of working |around this in your specific use-case, without having to run sshd. dtach. It is much more lightweight. I use it on the server to hold a containerized irssi-proxy instance to which i can connect to via VPN (from a of window of my local tmux). I track it for years now (it is stable for many years) after having been pointed to it by a good Japanese Spirit that sometimes crosses here and there .. and it just works. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Wed Feb 9 13:56:04 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 45EE819A71F6 for ; Wed, 9 Feb 2022 13:56:46 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jv1dT2ScTz4mDx; Wed, 9 Feb 2022 13:56:45 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id e666bedc; Wed, 9 Feb 2022 13:56:42 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 02ec8a2a (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 9 Feb 2022 13:56:33 +0000 (UTC) Date: Wed, 9 Feb 2022 14:56:04 +0100 From: Michael Gmelin To: Steffen Nurpmeso Cc: Michael Gmelin , Alexander Leidinger , hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? Message-ID: <20220209145604.3698c387.grembo@freebsd.org> In-Reply-To: <20220209133709.NBhO-%steffen@sdaoden.eu> References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> <20220209142152.13373548.grembo@freebsd.org> <20220209133709.NBhO-%steffen@sdaoden.eu> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Jv1dT2ScTz4mDx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 213.239.217.29 is neither permitted nor denied by domain of grembo@freebsd.org) smtp.mailfrom=grembo@freebsd.org X-Spamd-Result: default: False [-0.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[grembo]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.81)[-0.805]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.965]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 09 Feb 2022 14:37:09 +0100 Steffen Nurpmeso wrote: > Michael Gmelin wrote in > <20220209142152.13373548.grembo@freebsd.org>: > |On Wed, 09 Feb 2022 13:22:13 +0100 > |Alexander Leidinger wrote: > |> Quoting Michael Gmelin (from Wed, 9 Feb 2022 > |> 12:56:49 +0100): > |> > |>> I was able to reproduce the issue locally. > |>> > |>> The problem is caused by jexec inheriting the pty from the jail > |>> host. > |>> > |>> If you use a pty that was created inside of the jail, > |>> gpg-agent/pinentry works as expected. > |>> > |>> This can be accomplished, e.g., by running tmux inside of the > jail: |>> > |>> jexec gpgtest > |>> pkg install tmux > |>> tmux > |>> gpg --gen-key > ... > |Maybe someone with more insights to how jails work internally could > |give their input here. > | > |In the meantime, tmux is probably the most lightweight way of > working |around this in your specific use-case, without having to run > sshd. > > dtach. It is much more lightweight. I use it on the server to > hold a containerized irssi-proxy instance to which i can connect > to via VPN (from a of window of my local tmux). > I track it for years now (it is stable for many years) after > having been pointed to it by a good Japanese Spirit that sometimes > crosses here and there .. and it just works. That's another option I wasn't aware of, thanks. If it's for the occasional interactive session, you can also use the script(1) command that comes with base (which also makes use of openpty(3)), so no need to install any packages: $ script /dev/null gpg --gen-key Cheers Michael -- Michael Gmelin From nobody Thu Feb 10 08:25:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E0C9419A7FC0 for ; Thu, 10 Feb 2022 08:25:36 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvVDw1XPQz4XhB for ; Thu, 10 Feb 2022 08:25:36 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.61.147] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nI4lb-00065r-W2 for freebsd-hackers@freebsd.org; Thu, 10 Feb 2022 09:25:28 +0100 Date: Thu, 10 Feb 2022 09:25:26 +0100 From: Matthias Apitz To: freebsd-hackers@freebsd.org Subject: how to restrict file access below some top directory Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.61.147 X-Rspamd-Queue-Id: 4JvVDw1XPQz4XhB X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of guru@unixarea.de has no SPF policy when checking 178.254.4.101) smtp.mailfrom=guru@unixarea.de X-Spamd-Result: default: False [1.28 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; HAS_XOIP(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_NOT_FQDN(0.50)[]; NEURAL_SPAM_SHORT(0.22)[0.217]; NEURAL_SPAM_LONG(0.66)[0.661]; DMARC_NA(0.00)[unixarea.de]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-hackers]; 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:42730, ipnet:178.254.0.0/19, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[188.174.61.147:received] X-ThisMailContainsUnwantedMimeParts: N Hello, I want restrict in a C- or Perl-written application the file access to only files below some top directory, say /var/spool/dir/ and not allowing, for example, access to /var/spool/dir/../../../etc/passwd Ofc, this could be done easy with chroot(2), but this would require root permision. Any other ideas? matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub "Wenn mich jemand fragt, woher ich komme, sag ich immer: aus dem netteren Teil von Deutschland." Yvonne in "Die Kinder von Hoy" Grit Lemke, S.244 "If someone asks me where I come from, I always say: from the nicer one part of Germany." Yvonne in "Die Kinder von Hoy" Grit Lemke, page 244 From nobody Thu Feb 10 08:30:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8197A19AAF54 for ; Thu, 10 Feb 2022 08:31:01 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvVM56Vfgz4b3T for ; Thu, 10 Feb 2022 08:30:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 892ED89284; Thu, 10 Feb 2022 08:30:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 21A8UWYi016363 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 10 Feb 2022 08:30:32 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 21A8UVSP016362; Thu, 10 Feb 2022 08:30:31 GMT (envelope-from phk) Message-Id: <202202100830.21A8UVSP016362@critter.freebsd.dk> To: Matthias Apitz cc: freebsd-hackers@freebsd.org Subject: Re: how to restrict file access below some top directory In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16360.1644481831.1@critter.freebsd.dk> Date: Thu, 10 Feb 2022 08:30:31 +0000 X-Rspamd-Queue-Id: 4JvVM56Vfgz4b3T X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; BLOCKLISTDE_FAIL(0.00)[130.225.244.222:server fail]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Matthias Apitz writes: > > Hello, > > I want restrict in a C- or Perl-written application the file access to > only files below some top directory, say > > /var/spool/dir/ > > and not allowing, for example, access to /var/spool/dir/../../../etc/passwd > Ofc, this could be done easy with chroot(2), but this would require root > permision. Any other ideas? Jails. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Thu Feb 10 08:54:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2C29B19BA8DD for ; Thu, 10 Feb 2022 08:54:49 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvVtd0fMqz4l45; Thu, 10 Feb 2022 08:54:49 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644483289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cd3kzyaXGOAk+FAo5jRlI8wdOL9Z9ru2cU6/rQEmEqc=; b=iwbKaKcesQpufYryXoS96LwlfocOdmRNPdMPsH7uB2qzPiwNl+jLnCOi9oOkEQI9yCYATV krt2dVxfGoSrj+/CrHXcl4nhf8Z0N8C5d+0DQey1G/pOuelQok0fUgUg20MLEKrC+5V1HL Rra0kuy8Rw3we3/u4n1OIgMdPxJIPadBJMVBi29ARXSpDMuc94FlcHWYmQfIgZfWWA0+9v d2jcsbnAyIIl8erIU85gGcPzgKGEl50f/fmK/mRDUXQi8zQsFHaNJNjFSz/8K4n3Iq57RK f1DMico2rz9bIWsnp2XKrih9GXfNawckc7M22sQzEzoP279f+8ukHu+6dMvA7g== Received: from [IPV6:2003:cd:5f1f:8f00:51ae:46aa:8393:af10] (p200300cd5f1f8f0051ae46aa8393af10.dip0.t-ipconnect.de [IPv6:2003:cd:5f1f:8f00:51ae:46aa:8393:af10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 99ED42D94B; Thu, 10 Feb 2022 08:54:48 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <9e9426bd-c063-0d26-0694-9c0932f7c63e@FreeBSD.org> Date: Thu, 10 Feb 2022 09:54:45 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: how to restrict file access below some top directory Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------AE0voxisgXBGshCCH9j8Z6a3" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644483289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cd3kzyaXGOAk+FAo5jRlI8wdOL9Z9ru2cU6/rQEmEqc=; b=uaQhubfY/NBZRtdkWd3gTJYnZlRfswDOzEb/5P3rxVGabd8oir0EAIpf/aZFleYJx8GXcs ZWPO0+q22Fv1XhATqg7+pibUxBU/glzFDCAqIzSjdXbC2g6aUANjl3atLG6Snw5lry73p3 Tdk7EO6Orf3wV6Vl7cIpKlu9q6OHjMW4SlgOAqZfS0JIgVSMSytHiDYkUt6pDuUVHH+Aqp HxJoKiY8LNuqPB+64ZeaH5YuyqW2Yjafv+k0bB9TqaqXUKZq0n4E0VHWj9B+ARG0KbZu/G vu8dr9ZrLMz9Y8YKng+K75i8fp97xW411TKJGh/+GOM46CrmcNQ7/OzcbHicjQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644483289; a=rsa-sha256; cv=none; b=NRvrbbMhMcWXI4Tzy+XJ8uAc1LA7rEXnPsahP/hW7egkOIVgpD4t27PqmVZQY+d1YHItk+ E1WZSZeE2qPyzno94rhRSd7UzNfG/VABKtoBBEBTj79UTSTSfu1M8TyydyvwM9dCQebm5x QbdxK2X12FRsxga20+CSdKGTcx/19T1PQq9hkm8QqU/yVzXCNDGSxs4hbMctcXM3H+Dnj5 1FHpwMGp+D1Lln1gtyZ9gCke0RuPtmm4o8KzVZwO5LWLGr9YTgOFHYnuBpyslOTNWjoxOJ w+xGVM7zwXUNHwSD68MXp9KfDMzVPClFNhv1ifuFB2UK1OnlGQ3Ax8g/EpUqhA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------AE0voxisgXBGshCCH9j8Z6a3 Content-Type: multipart/mixed; boundary="------------Rz1doImUc6YJEXGn8fkWtJou"; protected-headers="v1" From: Stefan Esser To: freebsd-hackers@freebsd.org Message-ID: <9e9426bd-c063-0d26-0694-9c0932f7c63e@FreeBSD.org> Subject: Re: how to restrict file access below some top directory References: In-Reply-To: --------------Rz1doImUc6YJEXGn8fkWtJou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 10.02.22 um 09:25 schrieb Matthias Apitz: >=20 > Hello, >=20 > I want restrict in a C- or Perl-written application the file access to > only files below some top directory, say >=20 > /var/spool/dir/ >=20 > and not allowing, for example, access to /var/spool/dir/../../../etc/pa= sswd > Ofc, this could be done easy with chroot(2), but this would require roo= t > permision. Any other ideas? Hi Matthias, how about openat() in combination with capsicum? =46rom the open(4) / openat(4) man-page: In capsicum(4) capability mode, open() is not permitted. The path argument to openat() must be strictly relative to a file descriptor = fd. path must not be an absolute path and must not contain ".." componen= ts which cause the path resolution to escape the directory hierarchy starting at fd. Additionally, no symbolic link in path may target absolute path or contain escaping ".." components. fd must not be AT_FDCWD. If the vfs.lookup_cap_dotdot sysctl(3) MIB is set to zero, ".." components in the paths, used in capability mode, are completely disabled. If the vfs.lookup_cap_dotdot_nonlocal MIB is set to zero,= ".." is not allowed if found on non-local filesystem. Gru=C3=9F, STefan --------------Rz1doImUc6YJEXGn8fkWtJou-- --------------AE0voxisgXBGshCCH9j8Z6a3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmIE0tUFAwAAAAAACgkQR+u171r99UTx XAf8De+MqeEhs6eGofVd6TwBst6h/MYqwIooA9Z9flUmq5gWQfpJR7pVxv+1DW/J6FjmWuyOZc1M KmK2kM6QFHf4cSlzMhMguoGK9+Cu7HoRRD3aLFhf0V+NqjriPkrmmNsMMFLYlxfFQ5SRrdIvF1wp npsmVCsGn0LQdifXqdeEOfltsD/5g7XhaALAVV5ZrHWYEAx6UCJJM1Z131ZkrLJg5fPYnEsfTXa+ oyV2EjBFm8LmkSyNOXBu5Q2hGKHCqO0duGhEe37FjnffmMK0LG69w56c2A6zuuFrxUbFmYOuZBlX dUYKxaOkiOd6Ns7fStcLZ5Du0ByuJC3qpiHAgYDYLQ== =lmLS -----END PGP SIGNATURE----- --------------AE0voxisgXBGshCCH9j8Z6a3-- From nobody Thu Feb 10 09:13:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B00E719C4649 for ; Thu, 10 Feb 2022 09:13:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvWHn12b0z4sT6; Thu, 10 Feb 2022 09:13:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644484389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YyapbXwnQY0iyKVa9SFMzZ8e3/dX0PYU/nahnmRab9I=; b=rL4uraoWRFqAbq/snjyhm0Jv+dJueXCzHgbqKcTp5vTJ+0z0BgLJS54N+5BzIL7fOoEUc6 74c+cR35cBwFsgqoysL/FcBIAYkXS5f6wGdZ8VOdddnYL3hU7ntnKrqjSmAtJppicN5kJ9 koTaTHqRnhttV0E9Rqag2YjszIKciMDVbIOk+S9vlHj3Bh0W9jjGOzJa211JP2ODEF2JpG PQ35wiIh3xCks5SsNpRKr3ruySzSlcF0Kn69ooL0jLPuGe6gM+rhMmtHEio54KUl4nOTtT a9/DLx6erpGLCcxJ3eRGZr3VrZnjYCeocXSpLO28ZGH6sWfm5nPR8Zpe4RSELA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id C5FE62DAE1; Thu, 10 Feb 2022 09:13:08 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.64] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id E8D9E2EFF9; Thu, 10 Feb 2022 09:13:07 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: how to restrict file access below some top directory From: David Chisnall In-Reply-To: Date: Thu, 10 Feb 2022 09:13:07 +0000 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DAD732E-BCE7-4D3A-B259-418FFA70BBC1@FreeBSD.org> References: To: Matthias Apitz X-Mailer: Apple Mail (2.3608.120.23.2.7) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644484389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YyapbXwnQY0iyKVa9SFMzZ8e3/dX0PYU/nahnmRab9I=; b=x+Zex9fylLUnaYF9697GfSd/oaQ53H/B8ITPGSU9uSqcDXqGccfbs4xiyNbm76OcUqSU81 UQnVTsVRsy0kdeixaWFu44vi41Yh4+BfJ27h9iz1Vv4vLtx+pNekvb3aVu0oErNYC1oSTs uu227+kx9e6iWtRWmiBQyWVz3QZkTAJW0LpaiFK/BiLk/p7ZPLbt92FaWWEWZMo7w4ET/d WTDmEjEv83eCX0TU2XjcB7HSzGm+jnB6CF1ZJpC+DNWnDt1d7s7Pycg7xUYQ9D+Ct7nUjY 6JxzB+eU8m7BPviiSKpOM5CN4fzNak1VVLdSmf2FgvE5D0IZu7d6sACsfYBv8A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644484389; a=rsa-sha256; cv=none; b=Y01ijCTa5dpm4iLydFUiKHTKkduXQw11A2K+g9iixMztMJHRRfy8P3/DxIOriGI/otcHJE FhqZcbhDYzqpwIlQHNsO0UGnGfpf2CbD4SJLYAhG73SrL0TviJ+/VS/m85go2UYOxTjJx+ mGZlwbFLDpdFFY07VPSD4m4RQ7vknvRWK5LENSP0cBHZUWMPORD7hl1TLeQ7F/5oF+tfzK m/1/ert99bzOSeedWHKnx20ssWSQQcbFnBQ5n5xwd+/rjgQq90WiWorawemwZF1gbQ+AgV SaXXljezhR7c/rgxTuskSqN8LB6n2bmMzkzh01vxg8loFuSEGfVHyBd3c0KxuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi, > On 10 Feb 2022, at 08:25, Matthias Apitz wrote: >=20 > I want restrict in a C- or Perl-written application the file access to > only files below some top directory, say >=20 > /var/spool/dir/ >=20 > and not allowing, for example, access to = /var/spool/dir/../../../etc/passwd > Ofc, this could be done easy with chroot(2), but this would require = root > permision. Any other ideas? There are (at least?) four ways of doing this with FreeBSD: You can use chroot. This provides a simple redefinition of the root of = the filesystem. All dependencies (shared libraries and so on) must be = below the new root. You can use nullfs mounts to set up this hierarchy = to include read-only views of existing things (such as /lib, /usr/lib). = Note that chroot doesn=E2=80=99t restrict anything other than the = filesystem namespace. SysV IPC, sockets, and so on are unrestricted. = Note that you must be root to enter a chroot, but root can fairly easily = escape from the chroot, so you need to setuid after entering it. You can use a jail: https://docs.freebsd.org/en/books/handbook/jails/ This has the same set of requirements as a chroot (the process can=E2=80=99= t access anything outside of the new root, so the new root must have all = support files needed) but gives you a much more complete environment. = You can restrict access to the network and other IPC namespaces to the = jail and you can also have multiple user accounts inside. Root in a = jail is not the same as root outside and (modulo kernel bugs), root in = the jail can=E2=80=99t escape, so it=E2=80=99s safe to run things as = root in the jail. You can write a MAC policy that restricts access to the hierarchy:=20 https://docs.freebsd.org/en/books/handbook/mac/ This has the advantage that it=E2=80=99s non-invasive and makes it = possible to poke holes in the restriction for things like shared = libraries but writing the policy can be complex. The BSD Extended MAC = policy provides firewall-like rules that let you constrain a user to a = subset of the filesystem, which is probably the simplest way of writing = this kind of policy. https://www.freebsd.org/cgi/man.cgi?query=3Dmac_bsdextended You can use Capsicum: https://www.freebsd.org/cgi/man.cgi?query=3Dcapsicum This requires source-code modification. Once you call `cap_enter`, you = have no access to any global namespace (filesystem, IPC, network, and so = on) but if you=E2=80=99ve opened /var/spool/dir then you can use = `openat` to open files below that location in the filesystem namespace. = You can also apply fine-grained restrictions to file descriptors (for = example, granting read-only access to certain directories or append-only = access to certain files). We=E2=80=99re using this in Verona with a = lightweight RPC mechanism to invoke untrusted shared libraries and proxy = any calls to access things in the global that they need (open, connect, = bind) to the parent process, which can enforce policy. David From nobody Thu Feb 10 16:21:03 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E7B8C19C2D43 for ; Thu, 10 Feb 2022 16:21:14 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jvhnj02jRz4gwZ; Thu, 10 Feb 2022 16:21:12 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id D4F6916057; Thu, 10 Feb 2022 17:21:04 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 84A2A5E90E; Thu, 10 Feb 2022 17:21:03 +0100 (CET) Date: Thu, 10 Feb 2022 17:21:03 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Michael Gmelin Cc: Alexander Leidinger , hackers@freebsd.org Subject: Re: Behavior of /dev/pts in a jail? Message-ID: <20220210162103.4PrOq%steffen@sdaoden.eu> In-Reply-To: <20220209145604.3698c387.grembo@freebsd.org> References: <20220209113737.Horde.8QntfZV4xEkYdmHjXMgCpHN@webmail.leidinger.net> <77267259-0758-4C04-867D-77A896D133E4@freebsd.org> <20220209132213.Horde.hjhX_GoM3qNT-7ucnNXd-ae@webmail.leidinger.net> <20220209142152.13373548.grembo@freebsd.org> <20220209133709.NBhO-%steffen@sdaoden.eu> <20220209145604.3698c387.grembo@freebsd.org> User-Agent: s-nail v14.9.23-233-gc02d5a13cc OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4Jvhnj02jRz4gwZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-1.27 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Michael Gmelin wrote in <20220209145604.3698c387.grembo@freebsd.org>: |On Wed, 09 Feb 2022 14:37:09 +0100 |Steffen Nurpmeso wrote: |> Michael Gmelin wrote in |> <20220209142152.13373548.grembo@freebsd.org>: |>|On Wed, 09 Feb 2022 13:22:13 +0100 |>|Alexander Leidinger wrote: |>|> Quoting Michael Gmelin (from Wed, 9 Feb 2022 |>|> 12:56:49 +0100): ... |>|>> The problem is caused by jexec inheriting the pty from the jail |>|>> host. |>|>> |>|>> If you use a pty that was created inside of the jail, |>|>> gpg-agent/pinentry works as expected. |>|>> |>|>> This can be accomplished, e.g., by running tmux inside of the |> jail: |>> ... |>|In the meantime, tmux is probably the most lightweight way of |> working |around this in your specific use-case, without having to run |> sshd. |> |> dtach. It is much more lightweight. I use it on the server to |> hold a containerized irssi-proxy instance to which i can connect |> to via VPN (from a of window of my local tmux). ... |That's another option I wasn't aware of, thanks. | |If it's for the occasional interactive session, you can also use |the script(1) command that comes with base (which also makes use of |openpty(3)), so no need to install any packages: | | $ script /dev/null gpg --gen-key That is really tricky and i would never have thought of it. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Tue Feb 15 21:06:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6A07319CC6F0 for ; Tue, 15 Feb 2022 21:06:47 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jyttt4gpMz3FbQ for ; Tue, 15 Feb 2022 21:06:46 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id q8so2582640iod.2 for ; Tue, 15 Feb 2022 13:06:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d/Pt1ieXyG+qv/0iOhKn/A3FD/k/sIAiN1Ico8mb3WA=; b=QIMpU+SRlL6ai/w5IFsMzI/pKS1M7IKt481IrAJzKWTjZ2Ndb+IX1/F04A3EjYdQa0 vflgLRrD6sOIkN+VUIHRb2w5WQZACsAGyxYiHEPqZ2mu25bP4+0btdQYfczZh8qCwcyB oCgGL/bGnW8dcN8Y7lm4scFZ4ap2SsxpUFsqvnioxdUsjDgha+3SGLKoHJI/A518TWg4 Rf8NxYdBcsRGcP170p0BiapufEsXAEsq4ZvEtvFvH09pKmQD4P5cI5PmdhanlO3skkcm E11T9Hlfh0sCWJMlQ2WpLYJetgBQLqczIHTXPNob0xRUsvEFUTZo4YHzpTOp8dAncPW5 sYMw== X-Gm-Message-State: AOAM531bcECqMsmU/wkcf7MIwkgemA0BYzVFsBtfVzNakhbZSVbgiXFc glYpn6GD5z9Zv6+vdFXViw4bYkIl0AzN3u5RB1rXQV/C X-Google-Smtp-Source: ABdhPJw7dKBL14uPWgfnZjuB+PoiOJd3Dt48nlg3x878OV9vnPkdZJAjJMkvG31/xZ2pbnOorKb/NfEIqMNNvexibp8= X-Received: by 2002:a6b:5c06:: with SMTP id z6mr473757ioh.140.1644959205784; Tue, 15 Feb 2022 13:06:45 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <69e878bf-9379-f97e-0c9b-011952fd3daf@sentex.net> In-Reply-To: <69e878bf-9379-f97e-0c9b-011952fd3daf@sentex.net> From: Ed Maste Date: Tue, 15 Feb 2022 16:06:34 -0500 Message-ID: Subject: golang bugs [was: Call for Foundation-supported Project Ideas] To: Mike Tancsa Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Jyttt4gpMz3FbQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.25 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.25)[-0.249]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.50:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.50:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Sun, 28 Nov 2021 at 13:40, mike tancsa wrote: > > On 11/23/2021 5:41 PM, Joseph Mingrone wrote: > > Hello FreeBSD community, > > > > The Foundation is seeking suggestions for new projects to support. What > > gaps in the Project are not being addressed by the broader community? > > Maybe some bug squashing on the FreeBSD golang runtime. There are a > number of open issues. Would be great to see better support as its > getting to be a more popular dev platform. A quick follow-up on this - there were a couple of fairly significant "golang" issues that were due to FreeBSD kernel bugs, and were addressed recently: - https://github.com/golang/go/issues/46272 - https://github.com/zrepl/zrepl/issues/343 A search for open golang issues labeled OS-FreeBSD turns up 22 issues: https://github.com/golang/go/issues?q=is%3Aissue+is%3Aopen+label%3AOS-FreeBSD+ A quick look turned up a couple that warrant some investigation but nothing of exceptional concern. If go users have input on specific bugs of note or use cases that can help guide the investigation or prioritization I'm happy to have that feedback. From nobody Thu Feb 17 07:17:44 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F090219C9CA1 for ; Thu, 17 Feb 2022 07:17:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzmPY5FzMz3NXP for ; Thu, 17 Feb 2022 07:17:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=oUd+FHz+X0a6hyAQtyDx673u08S44r1syxTLO0QzcO8=; b=hneSQm1xorPeFZi2Axl9jqGY4x5MvyYHHBKxuwCUV1QnLdIeos+6pNRbAmEoEPXbGrTAXtKFv0v+Y2PMjF+Fs63gfgNuhKGzOZgbstx99br09k4xLj5md/68yxC/M3s+TFxoQiEM5OMAeXRhIG0mDo2fWYH2NmGKkskXmy9NMa7UBp+QKbt+WipuaPeGGQ6O7dRUxn/EBKLejjiwWMhhIXBam6TlQ2ucAYARie+mN3+c7qjedbwvY2ZoCCwUzMJh9YNcjRJn7YIGZM+2TLQg/FAQ9oye52SJXL0qQIHZnn9Hl7lvwdmVHyG2mp/PMPiLOu6NpkFQ3/cyshUNXgkSvA==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nKb2v-000P34-1G for hackers@freebsd.org; Thu, 17 Feb 2022 09:17:45 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: usb CH9102 serial chip Message-Id: Date: Thu, 17 Feb 2022 09:17:44 +0200 To: freebsd- X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JzmPY5FzMz3NXP X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=hneSQm1x; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.01)[0.008]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MLMMJ_DEST(0.00)[hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hi, is there some quirk to enable this chip? it=E2=80=99s an new riskv esp32 board but I can only use the usb to = download software, no console output from it. thanks, danny From nobody Thu Feb 17 07:36:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6420019CD536 for ; Thu, 17 Feb 2022 07:36:58 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzmqY2Rm8z3Qh5 for ; Thu, 17 Feb 2022 07:36:57 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Thu, 17 Feb 2022 08:36:48 +0100 id 00DD6044.620DFB10.0000B787 Date: Thu, 17 Feb 2022 08:36:47 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: usb CH9102 serial chip Message-ID: <20220217083647.4a11b67a@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JzmqY2Rm8z3Qh5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-3.06 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.77)[-0.775]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, 17 Feb 2022 09:17:44 +0200 Daniel Braniss wrote: > hi, > is there some quirk to enable this chip? > it=E2=80=99s an new riskv esp32 board but I can only use the usb to downl= oad > software, no console output from it. >=20 Hi, no answer from me here, just a hint - most probably this question is suited more for freebsd-usb mailing list. Also, some output, maybe from usbconfig or relevant lines from dmesg would be helpfull for anyone with the knowledge to offer some insight... Regards, Milan From nobody Thu Feb 17 09:09:58 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 434A519DEAF7 for ; Thu, 17 Feb 2022 09:10:36 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzpvZ01Wmz3w7Q for ; Thu, 17 Feb 2022 09:10:33 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21H9AEo1041703 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 17 Feb 2022 19:40:15 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1645089020; bh=w6XAsi+yVQJXnhZxpVVaZc89GZQq5I+ijISRe1dFcyk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Z0iDMS99xHyoNWU86E/bB9fr7DyXLJ3sjpvr6QDcs+9sOQJkl62c7ij2lssSiPJ9s XUqur0etSNdq906IVrbYn9mkVlRqEy92ABRLPZWEnV79PxQfWg3JYAdaYwjGwyg4N7 PzfrkWUKOH8u/F4ydPXllk+So+XCmcQJny7r/iCY= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21H99wXE039095 for ; Thu, 17 Feb 2022 19:39:58 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:4490:1d13:a302:f4a7 Received: from smtpclient.apple (2403-5800-5200-4700-4490-1d13-a302-f4a7.ip6.aussiebb.net [2403:5800:5200:4700:4490:1d13:a302:f4a7]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21H99w2A039090; Thu, 17 Feb 2022 19:39:58 +1030 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: usb CH9102 serial chip From: "Daniel O'Connor" In-Reply-To: Date: Thu, 17 Feb 2022 19:39:58 +1030 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> References: To: Daniel Braniss X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.5 () No, score=0.5 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JzpvZ01Wmz3w7Q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=Z0iDMS99; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17 Feb 2022, at 17:47, Daniel Braniss wrote: > is there some quirk to enable this chip? > it=E2=80=99s an new riskv esp32 board but I can only use the usb to = download software, no console output from it. Are you saying that you can flash the board with it? If that is the case then the chip/driver are working fine since that = requires bidirectional communication etc.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Feb 17 09:20:34 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76AE719C1EA0; Thu, 17 Feb 2022 09:20:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jzq793m1Wz4Sp1; Thu, 17 Feb 2022 09:20:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=TxkbuM00Tw8U7zIq1+G/ba1yuRngKvgfxFqV9U5wBbU=; b=wdrugC6qCT2M3+bOGZvEfI6CXCNDMjXW1Wc9jkYMB0JsdcFKniMRnGtENfUsvm0GNOT6UpvJ9FIqgDqgB2uYUVIHeVPVihd77GIqsyi0RUAvpiUklpDKAwxX2+7QFXjTkEX8NYHP3KZyDocegNmazEQYegHHDycTc9C65Fbsc/zTtfR/Z93U+XpyeuNC3zfCqoW7ct18dksCUutokiev45h+mdLpWfLxcZ9Tzb5OfVzAFohNbVXWtUGGX6LzltNc2vyEhnYrLbo6CQ2EcDpbrhquZc/KBDQz0bNl/QeXJ4U15zEhN+jsv7+rQ7RQOejQU68kxvUFiU63cjfkUYqoUw==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nKcxn-0005VX-4z; Thu, 17 Feb 2022 11:20:35 +0200 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb CH9102 serial chip From: Daniel Braniss In-Reply-To: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> Date: Thu, 17 Feb 2022 11:20:34 +0200 Cc: freebsd- , "usb@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> To: Daniel O'Connor X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Jzq793m1Wz4Sp1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=wdrugC6q; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.29 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[hackers,usb]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17 Feb 2022, at 11:09, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 17 Feb 2022, at 17:47, Daniel Braniss wrote: >> is there some quirk to enable this chip? >> it=E2=80=99s an new riskv esp32 board but I can only use the usb to = download software, no console output from it. >=20 > Are you saying that you can flash the board with it? >=20 > If that is the case then the chip/driver are working fine since that = requires bidirectional communication etc.. >=20 but that works only if I power up the board while pressing a button, = then it also appears as /dev/ttyU0, and so then I can flash, after reset, the device is gone and there are = errors ( BTW, the flashed image workes): Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) Feb 17 09:47:01 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR Feb 17 09:47:01 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) Feb 17 09:47:03 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR Feb 17 09:47:03 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) Feb 17 09:47:05 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR Feb 17 09:47:06 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) Feb 17 09:47:08 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR Feb 17 09:47:08 pampero kernel: ugen0.4: at usbus0 = (disconnected) Feb 17 09:47:08 pampero kernel: uhub_reattach_port: could not allocate = new device > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum >=20 cheers, danny From nobody Thu Feb 17 09:30:33 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8327519C4BE5 for ; Thu, 17 Feb 2022 09:31:02 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzqM95lW6z4WRH for ; Thu, 17 Feb 2022 09:31:01 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21H9UiqJ057349 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 17 Feb 2022 20:00:55 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1645090259; bh=K0EBehxC9f3/yXUfEN6ulvNWnMXgeESSE7KCAOIL718=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=S3UuXOgUiLuvOksT2kbM9lc8L0+pINQobtY+fHPphxZvaj/s8TEw8HbMdICi8TwCf Yg7xOaHPqEJipfHMvM3TJB7NbHCVTJtUvn4dgXPU2GwhOaYpAZHommJmWWT43twWt2 o/LfdrsGpYmHOAv9wGk08hIwv9HeQHJgWX6lqqoU= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21H9UYj3057336 for ; Thu, 17 Feb 2022 20:00:34 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:4490:1d13:a302:f4a7 Received: from smtpclient.apple (2403-5800-5200-4700-4490-1d13-a302-f4a7.ip6.aussiebb.net [2403:5800:5200:4700:4490:1d13:a302:f4a7]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21H9UX44057330; Thu, 17 Feb 2022 20:00:34 +1030 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: usb CH9102 serial chip From: "Daniel O'Connor" In-Reply-To: Date: Thu, 17 Feb 2022 20:00:33 +1030 Cc: freebsd- , "usb@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <013FB4BA-7D32-4FFB-AFD3-E594CF638A66@dons.net.au> References: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> To: Daniel Braniss X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.5 () No, score=0.5 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4JzqM95lW6z4WRH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=S3UuXOgU; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17 Feb 2022, at 19:50, Daniel Braniss wrote: >=20 >> If that is the case then the chip/driver are working fine since that = requires bidirectional communication etc.. >>=20 >=20 > but that works only if I power up the board while pressing a button, = then it also appears as /dev/ttyU0, and > so then I can flash, after reset, the device is gone and there are = errors ( BTW, the flashed image workes): >=20 > Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: getting device = descriptor at addr 4 failed, USB_ERR_IOERROR > Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) What sort of dev board is it? Seems very strange the USB UART would behave differently unless it's = wired up in an unusual way IMO. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Feb 17 09:34:27 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 81F9819C6894; Thu, 17 Feb 2022 09:34:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzqR86BCzz4Y9D; Thu, 17 Feb 2022 09:34:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=O2dSlINkR+Uq8i7HYox8r8qe2hE34iflFkxAlCxrXc0=; b=Hphxj1y6vC63EM6uIE+VvAzWmtQCuc+ZqPO1yGaFCc8Bv7GjApS53iFoyYkpk6FoEUe2YpNOTvxYT270Un6UFGW+jM+CZT0rXd29ZuK9yLOBqBS0kDegQ1oejAvrhatWex20MPvzgHXokM/ovjMPmth28RpvdgMG2S4XIHvarFipM1xSFqZSTRLi+QlvF+EZpkJxGK4v3sPipE3j4f3TYr1M0FJ5J7iioMkJxckJr2BppQIj5zcSVFocj3IX8gBBMDqvN3TlkNyg8QFz8ZNXM0KteA5O6TR+xW3BRUERz5PIHwS1wU1LRNB4Ae0w4Ns02Hhrl1toEIzuPsqNH+Xc1Q==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nKdBD-00066v-5J; Thu, 17 Feb 2022 11:34:27 +0200 From: Daniel Braniss Message-Id: <17E09096-A45B-43F5-BFE4-7645E8A2275D@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_7CB45CB7-F310-4F07-8AC9-447C364B58C9" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: usb CH9102 serial chip Date: Thu, 17 Feb 2022 11:34:27 +0200 In-Reply-To: <013FB4BA-7D32-4FFB-AFD3-E594CF638A66@dons.net.au> Cc: freebsd- , "usb@freebsd.org" To: Daniel O'Connor References: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> <013FB4BA-7D32-4FFB-AFD3-E594CF638A66@dons.net.au> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4JzqR86BCzz4Y9D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=Hphxj1y6; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers,usb]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_7CB45CB7-F310-4F07-8AC9-447C364B58C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 17 Feb 2022, at 11:30, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 17 Feb 2022, at 19:50, Daniel Braniss wrote: >>=20 >>> If that is the case then the chip/driver are working fine since that = requires bidirectional communication etc.. >>>=20 >>=20 >> but that works only if I power up the board while pressing a button, = then it also appears as /dev/ttyU0, and >> so then I can flash, after reset, the device is gone and there are = errors ( BTW, the flashed image workes): >>=20 >> Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: getting = device descriptor at addr 4 failed, USB_ERR_IOERROR >> Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) >=20 > What sort of dev board is it? m5 stamp C3U = https://shop.m5stack.com/products/m5stamp-c3u-mate-with-pin-headers?_pos=3D= 2&_sid=3D3df9b5f0d&_ss=3Dr&variant=3D42341016633601 = >=20 > Seems very strange the USB UART would behave differently unless it's = wired up in an unusual way IMO. >=20 > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum >=20 >=20 --Apple-Mail=_7CB45CB7-F310-4F07-8AC9-447C364B58C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 17 Feb 2022, at 11:30, Daniel O'Connor <darius@dons.net.au> = wrote:



On 17 Feb 2022, at 19:50, Daniel Braniss <danny@cs.huji.ac.il>= wrote:

If that is the case then the chip/driver are working fine = since that requires bidirectional communication etc..


but that works only if I power up = the board while pressing a button, then it also appears as /dev/ttyU0, = and
so then I can flash, after reset, the device is gone = and there are errors ( BTW, the flashed image workes):

Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: = getting device descriptor at addr 4 failed, USB_ERR_IOERROR
Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: = addr=3D4, set address failed! (USB_ERR_IOERROR, ignored)

What sort of dev board is it?
m5 stamp C3U


Seems very strange the USB = UART would behave differently unless it's wired up in an unusual way = IMO.

--
Daniel O'Connor
"The nice thing about standards is that there
are= so many of them to choose from."
-- Andrew Tanenbaum



= --Apple-Mail=_7CB45CB7-F310-4F07-8AC9-447C364B58C9-- From nobody Thu Feb 17 09:48:40 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3BA7119C94C1 for ; Thu, 17 Feb 2022 09:49:01 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jzqlw0w2Qz4bNM for ; Thu, 17 Feb 2022 09:48:59 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 21H9mi6n068168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 17 Feb 2022 20:18:53 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1645091337; bh=z6nFtwHEwyhiuwNrT2NQjdaJN5Cxj/cMbgjPl0IYiRg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YyjXibdcfNdBTr9qmzdUiKuZ3onPGNaD+DS5ZGhaf8Bz4ufx49Rj/wuPatU2mFH6L WMuGPm4IvmgG7xxp6FkQtj6CbYGIbgaSM12pvbona7pWI9jk4E2wD2eW+c2oZIMv4A 2FHQ7Ch9ua2tRvd4byQumQ9E0sPnJ17mo7dtc3X0= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 21H9meDd068164 for ; Thu, 17 Feb 2022 20:18:40 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:4490:1d13:a302:f4a7 Received: from smtpclient.apple (2403-5800-5200-4700-4490-1d13-a302-f4a7.ip6.aussiebb.net [2403:5800:5200:4700:4490:1d13:a302:f4a7]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 21H9me7p068158; Thu, 17 Feb 2022 20:18:40 +1030 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: usb CH9102 serial chip From: "Daniel O'Connor" In-Reply-To: <17E09096-A45B-43F5-BFE4-7645E8A2275D@cs.huji.ac.il> Date: Thu, 17 Feb 2022 20:18:40 +1030 Cc: freebsd- , "usb@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> <013FB4BA-7D32-4FFB-AFD3-E594CF638A66@dons.net.au> <17E09096-A45B-43F5-BFE4-7645E8A2275D@cs.huji.ac.il> To: Daniel Braniss X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Spam-Score: 0.5 () No, score=0.5 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4Jzqlw0w2Qz4bNM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=YyjXibdc; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800:5000::/36, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 17 Feb 2022, at 20:04, Daniel Braniss wrote: >> On 17 Feb 2022, at 11:30, Daniel O'Connor wrote: >>=20 >>> On 17 Feb 2022, at 19:50, Daniel Braniss = wrote: >>>=20 >>>> If that is the case then the chip/driver are working fine since = that requires bidirectional communication etc.. >>>>=20 >>>=20 >>> but that works only if I power up the board while pressing a button, = then it also appears as /dev/ttyU0, and >>> so then I can flash, after reset, the device is gone and there are = errors ( BTW, the flashed image workes): >>>=20 >>> Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: getting = device descriptor at addr 4 failed, USB_ERR_IOERROR >>> Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: addr=3D4, set = address failed! (USB_ERR_IOERROR, ignored) >>=20 >> What sort of dev board is it? > m5 stamp C3U > = https://shop.m5stack.com/products/m5stamp-c3u-mate-with-pin-headers?_pos=3D= 2&_sid=3D3df9b5f0d&_ss=3Dr&variant=3D42341016633601 According to the docs the 'U' variant doesn't have a serial chip on it. = If you look at the schematic the USB +/- pins go straight to the MCU. I suspect it has a boot loader which emulates the CH9102, when your code = is running it is whatever that does with the USB port, so if there is a = bug or whatever then it will exhibit weird behaviour. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Feb 17 13:12:51 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D85E319CE550; Thu, 17 Feb 2022 13:12:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzwHC5Ntvz3JkL; Thu, 17 Feb 2022 13:12:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=l7AhjBdRPUl+PvLcIrjk7I8I7lWORGvnQfOgMqJsBvI=; b=QdHZ7BMMf8xeTuArH/yT451jGng5Oox+XvQInS99979Vv0P79zwZaLvNC8yXyzl4QfsACOFVxXNJ+O+yRuBM7b4HREIrEcMqXwghxDxelVEDHH2EvZv8xZoMBal0elsfMGyIGO7ZmSIaTTjsg4sCEHn3CyOTXGS0xNEjzSaYq6/FNzX4yNtpjBM5Fn4F6+XT7Ew7WDM1RcZtPFHptJ70S2rYbHrpAl04kKl9BTznhZDrahGKZsg/DYk66Kz8aVmGUUeUddo7paxFfqSYYpMkzWfOt4MjsVa2u0yWOFY2otGNIiD8wTlXaNk3wQHFu5Vxwhd2CDQo7QDPO1tzO3ZEsg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nKgaZ-000FiX-R7; Thu, 17 Feb 2022 15:12:51 +0200 From: Daniel Braniss Message-Id: <59810B39-C889-436F-8BC4-81680E09154B@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_89F3905D-F8FB-42AA-A831-8CE40CE41E81" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: usb CH9102 serial chip Date: Thu, 17 Feb 2022 15:12:51 +0200 In-Reply-To: Cc: freebsd- , "usb@freebsd.org" To: Daniel O'Connor References: <7DD6E1FA-3EA4-44D9-A272-9E51FB9F2BFC@dons.net.au> <013FB4BA-7D32-4FFB-AFD3-E594CF638A66@dons.net.au> <17E09096-A45B-43F5-BFE4-7645E8A2275D@cs.huji.ac.il> X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: 4JzwHC5Ntvz3JkL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=QdHZ7BMM; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers,usb]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_89F3905D-F8FB-42AA-A831-8CE40CE41E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Feb 2022, at 11:48, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 17 Feb 2022, at 20:04, Daniel Braniss wrote: >>> On 17 Feb 2022, at 11:30, Daniel O'Connor = wrote: >>>=20 >>>> On 17 Feb 2022, at 19:50, Daniel Braniss = wrote: >>>>=20 >>>>> If that is the case then the chip/driver are working fine since = that requires bidirectional communication etc.. >>>>>=20 >>>>=20 >>>> but that works only if I power up the board while pressing a = button, then it also appears as /dev/ttyU0, and >>>> so then I can flash, after reset, the device is gone and there are = errors ( BTW, the flashed image workes): >>>>=20 >>>> Feb 17 09:46:59 pampero kernel: usbd_setup_device_desc: getting = device descriptor at addr 4 failed, USB_ERR_IOERROR >>>> Feb 17 09:47:00 pampero kernel: usbd_req_re_enumerate: addr=3D4, = set address failed! (USB_ERR_IOERROR, ignored) >>>=20 >>> What sort of dev board is it? >> m5 stamp C3U >> = https://shop.m5stack.com/products/m5stamp-c3u-mate-with-pin-headers?_pos=3D= 2&_sid=3D3df9b5f0d&_ss=3Dr&variant=3D42341016633601 >=20 > According to the docs the 'U' variant doesn't have a serial chip on = it. If you look at the schematic the USB +/- pins go straight to the = MCU. >=20 RTFM, then again RTFM :-) to quote: By default, USB CDC is not enabled, the serial port output started by = C3U will be output through UART0, if you need to output through USB, = please use IDE to make it USB CDC before downloading the program option = enabled. (Arduino users can enable it through Tools->USB CDC on = Boot-Enabled, IDF users please refer to ESP IDF official documentation.) now to hunt down the =E2=80=98official documentation=E2=80=99. thanks, danny > I suspect it has a boot loader which emulates the CH9102, when your = code is running it is whatever that does with the USB port, so if there = is a bug or whatever then it will exhibit weird behaviour. >=20 > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum --Apple-Mail=_89F3905D-F8FB-42AA-A831-8CE40CE41E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 Feb 2022, at 11:48, Daniel O'Connor <darius@dons.net.au> = wrote:



On 17 = Feb 2022, at 20:04, Daniel Braniss <danny@cs.huji.ac.il>= wrote:
On 17 Feb = 2022, at 11:30, Daniel O'Connor <darius@dons.net.au> wrote:

On 17 Feb 2022, at = 19:50, Daniel Braniss <danny@cs.huji.ac.il> wrote:

If that is the case then = the chip/driver are working fine since that requires bidirectional = communication etc..


but that works only if I power up the board while pressing a = button, then it also appears as /dev/ttyU0, and
so then I = can flash, after reset, the device is gone and there are errors ( BTW, = the flashed image workes):

Feb 17 09:46:59 = pampero kernel: usbd_setup_device_desc: getting device descriptor at = addr 4 failed, USB_ERR_IOERROR
Feb 17 09:47:00 pampero = kernel: usbd_req_re_enumerate: addr=3D4, set address failed! = (USB_ERR_IOERROR, ignored)

What = sort of dev board is it?
m5 stamp = C3U
https://shop.m5stack.com/products/m5stamp-c3u-mate-with-pin-hea= ders?_pos=3D2&_sid=3D3df9b5f0d&_ss=3Dr&variant=3D4234101663360= 1

According to the docs the 'U' variant doesn't have a serial = chip on it. If you look at the schematic the USB +/- pins go straight to = the MCU.

RTFM, then again RTFM = :-)
to quote:
By default, USB CDC is not enabled, = the serial port output started by=20 C3U will be output through UART0, if you need to output through USB,=20 please use IDE to make it USB CDC before downloading the program option=20= enabled. (Arduino users can enable it through Tools->USB CDC on = Boot-Enabled, IDF users please refer to = ESP IDF official documentation.)
now to hunt down the = =E2=80=98official documentation=E2=80=99.

thanks,
danny


I suspect it has a boot loader which emulates the CH9102, = when your code is running it is whatever that does with the USB port, so = if there is a bug or whatever then it will exhibit weird = behaviour.

--
Daniel = O'Connor
"The nice = thing about standards is that there
are so many of them to choose from."
-- Andrew = Tanenbaum

= --Apple-Mail=_89F3905D-F8FB-42AA-A831-8CE40CE41E81-- From nobody Fri Feb 18 14:28:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D514119D24DA for ; Fri, 18 Feb 2022 14:28:05 +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 4K0YvT2jm1z4v72 for ; Fri, 18 Feb 2022 14:28:05 +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=ruA5jucBMZaW4JZzSDt+ESISNE+q3e5e8fXxES0KyNE=; b=pQyzm4U1jMiEGyEPC7Y91i2azb 095EsXpQKMX3jX5vcgVV4OOE4dhaW7Ift/CFzYvhhB2EIlY0ZneUbYPdITcc1W90UYVokMx9cbWtL V3XC5Q7sSIvaJJVo5tnOhoFYtMRpKInmgg3G7AjlpBmRA5q/rmBOqeyUGooIwLMJswntXEhepbpVv CuL3pfSuc/nFDaHjl1GXiZqR/q/3XFBpmgfQKPcZVrE65XqZXwghGFOPtnaRwmorkgexjpJOTpO5J ZKIwbX3ZwA8A2nP8RfKUzgK3GItXZ2sqkk5M8srZWrUGu3VnD89lBj9eX31VvWWjGr9MfdwwbVLcK EDpd7Azw==; 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 1nL4Eu-006lsk-2s for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 15:28:04 +0100 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nL4Et-000Ofc-OB for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 14:28:03 +0000 Date: Fri, 18 Feb 2022 15:28:03 +0100 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: How to generate a Makefile.depend? Message-ID: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yr4lmp3iiwo25i2y" Content-Disposition: inline User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: 4K0YvT2jm1z4v72 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=pQyzm4U1; 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]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --yr4lmp3iiwo25i2y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm trying to add a little tool to my local tree and I'm stuck with something I *assume* should be simple. As I understand it, there should be a Makefile.depend in its directory, listing all the dir dependencies, and this should be somehow auto-generated from .meta files. I just can't figure out how to do it. I have this very simple Makefile for it: --- # $FreeBSD$ PACKAGE=3D runtime PROG=3D pam_unix-helper MAN=3D # no manpage, internally used by pam_unix.so LIBADD=3D crypt BINOWN=3D root BINMODE=3D4555 =2Einclude --- It builds just fine (using meta mode), so what do I need to do to get the corresponding Makefile.depend? TIA, 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 --yr4lmp3iiwo25i2y Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmIPrOUACgkQPvKLCrwC 2ir2/Qf/R6Io9F2NkXwbRzN3hBQ+2EpUiBEuJu8r1Sz8gASwhNhAjC9vbWb8wvo7 ikIuk19XwWFFCSky7ZbQiKQw6tU6lqHXDIEq0N16nuUWreBeIVFLll98yEnjsU9s JJgkVpIyQzHb26N6Su/8KmQ7Il5Kybbrld0zwYLhnCcSRN+UBAAU+uwRLmj8HnKa jhA3jOlUfiUw/NDnTTxoSsHDQd4UxqeJS4BmyB9rJMHizGE4xFV6R0BiMVqw/Okm 2pSWHL9zuPmhATQ1mPemFdHUoBVh2uoDgb1M/oBvyV6LzHmkqJQKJh1WwxnmorRi p7p7e1r+Gg4+zgJDuGGzrcmpioH4LQ== =1iyo -----END PGP SIGNATURE----- --yr4lmp3iiwo25i2y-- From eugen@grosbein.net Fri Feb 18 15:08:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7904719DA5F3 for ; Fri, 18 Feb 2022 15:08:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0ZpM3pp2z3J28 for ; Fri, 18 Feb 2022 15:08:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@[62.231.161.221]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 21IF8Yfu065181 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Feb 2022 15:08:34 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-hackers@freebsd.org Received: from [10.58.0.11] ([10.58.0.11]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 21IF87B0027676 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 18 Feb 2022 22:08:32 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: How to generate a Makefile.depend? To: freebsd-hackers@freebsd.org, Felix Palmen References: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> From: Eugene Grosbein Message-ID: Date: Fri, 18 Feb 2022 22:08:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4K0ZpM3pp2z3J28 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.13 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-0.86)[-0.859]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_MEDIUM(-0.17)[-0.173]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 18.02.2022 21:28, Felix Palmen wrote: > I'm trying to add a little tool to my local tree and I'm stuck with > something I *assume* should be simple. As I understand it, there should > be a Makefile.depend in its directory, listing all the dir dependencies, > and this should be somehow auto-generated from .meta files. I just can't > figure out how to do it. > > I have this very simple Makefile for it: > --- > # $FreeBSD$ > > PACKAGE= runtime > > PROG= pam_unix-helper > MAN= # no manpage, internally used by pam_unix.so > > LIBADD= crypt > > BINOWN= root > BINMODE=4555 > > .include > --- > > It builds just fine (using meta mode), so what do I need to do to get > the corresponding Makefile.depend? Take a look at comments in the file /usr/share/mk/bsd.dep.mk Generally you run "make depend", but it tells that "meta+filemon mode will track dependencies itself", so no depend files used in this case. From nobody Fri Feb 18 15:44:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0CD4E19C37B3 for ; Fri, 18 Feb 2022 15:45:02 +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 4K0bcF6r25z3hcR for ; Fri, 18 Feb 2022 15:45:01 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645199102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z07w5g5rT5fyFl4uNdYvKv8lSgrbUjMJH8j3Gp47LWI=; b=N6oDTGhvGnO7KUqEJhOJr1+35wyFPRPKE2F4LUMUwBR4AH99pqqKZdJZinzQibyRxLWfdc sUTsXtKJfr2j90NJMknQ2/TxBLy62ccuM1WjR57E1WSN2ndep6BziZOnvii6qQDXqI/8be aA/80elCnveW3VIdfuuv/qZ/W5ZqZnfTBjidqirqAIOAKYilcVSyU4HpkcAaLZM/yZrwFI Hv2lh7ZdcFnORjAm16GPjptPbUci3BXwbziIcRADCZyLbeOTHO2nfBsYFC7mfVrmtfDJ2K v/lVvKcTTScR4eKsOX0DQfL/GlruSf/EK7gqke0R8cMWgItP7lhcf1cbKuGZBA== Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id C504C17F8 for ; Fri, 18 Feb 2022 15:45:01 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f44.google.com with SMTP id fh9so15502629qvb.1 for ; Fri, 18 Feb 2022 07:45:01 -0800 (PST) X-Gm-Message-State: AOAM533eEbS9CpmVqyD5D/jfUjwYHcIap+SMq9sMJKewL4EFJe7Bi6nP oGOOtNJ52SVo4fuXAdBmWTtb6xXDRGfWGmYoQLc= X-Google-Smtp-Source: ABdhPJwIrbqaFiVP7swGt05AWV7Dt14hFaOmxrFBQHGWEw0g9JxPgjIEpUFDQKyYCcQVBswuzwWN/PxPR0r0o87z63w= X-Received: by 2002:a05:622a:590:b0:2dc:ed41:5ac6 with SMTP id c16-20020a05622a059000b002dced415ac6mr7142468qtb.444.1645199101101; Fri, 18 Feb 2022 07:45:01 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> In-Reply-To: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> From: Kyle Evans Date: Fri, 18 Feb 2022 09:44:50 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to generate a Makefile.depend? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645199102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z07w5g5rT5fyFl4uNdYvKv8lSgrbUjMJH8j3Gp47LWI=; b=EE82tXtf2AYP4DNNt7krbrgGpYlHY/8lij46a+Un9uWEOuYV10MgEadMfV8nKcgCXZngVx IgH5tL8bWVI6ah5c5Hd3L7h1TMZjuzN84jOHVUBViS0snuuNUT730RZendGf5se+UsiZQ3 Ocipp8Rp1AQD3+EYB+oUJHf2Vkr/ohNeC+IzhfS2yoc5VjDItW9bhhYZ/TtSI5QJOV2/w+ H9foyu9SxVxENueJ2dr63JE11ECFAipC/tK9/8JndGI4zGo1g8gDDfCkYZegR65pGlKycn pzKQJVkb6x6dNdNWTMeiCY0DEGEFF8Us3mbBIJuSV8o7z5StV+06/Spoc1Y0hA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645199102; a=rsa-sha256; cv=none; b=SISjwGwFuKuP9J1TkS6e6NWRK92LjqiCk2NNp3IBfJJEKCjD6JHWBtNvZe/wzVRdP3j1KA oNxzDKT2M6L01LWNdC6+MPXAHQFKMsPlJboxH7Q0CgFIlgGCsKrK+oj6k7Dz24pK1PmI6R btB9YNvuuC2O7Zt2RWQ7Q2UDNNSbIZWrugERlKlM2sgtYguLvINox2IdfNFP0gctpnJYt7 tbxarhfAmA8VKilUS/+bS0TGrMY0L3d51JnaO/njPN+S+wbl98o1So5ucs8pUrrqq/YAB7 ArQgZNtzoLVFPD1PIiCh8wQLCByINBAYn0iQl4UmmjWFZNydsw8jVJ2BA6gHEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Feb 18, 2022 at 8:28 AM Felix Palmen wrote: > > I'm trying to add a little tool to my local tree and I'm stuck with > something I *assume* should be simple. As I understand it, there should > be a Makefile.depend in its directory, listing all the dir dependencies, > and this should be somehow auto-generated from .meta files. I just can't > figure out how to do it. > > I have this very simple Makefile for it: > --- > # $FreeBSD$ > > PACKAGE= runtime > > PROG= pam_unix-helper > MAN= # no manpage, internally used by pam_unix.so > > LIBADD= crypt > > BINOWN= root > BINMODE=4555 > > .include > --- > > It builds just fine (using meta mode), so what do I need to do to get > the corresponding Makefile.depend? > Makefile.depend falls in "do not worry about it" territory; they're only used for dirdeps mode, which to my understanding will tolerate and generate the missing Makefile.depend as it goes anyways. bdrewery or sjg periodically commit/update .depend files. Thanks, Kyle Evans From nobody Fri Feb 18 15:48:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 87EA319C4AFC for ; Fri, 18 Feb 2022 15:48:30 +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 4K0bhG0fbKz3jYh for ; Fri, 18 Feb 2022 15:48:30 +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=dQ/ZlWhYupxO7TSNpQBCBp5aTUDnEE+oOCrWYaDLL8Q=; b=L//+ABNZH73decCl0kff2S41Ec 8qOZJpkbBLOZanf174tJ2TI6/iiOS1vtDTH+HDf5r3mG/r0DyDnHdlNib+8i0bpCmyU19vhzf0UKo w07EkyRA3cukGx2+vq6xZB/7zIRjCnJbE6b3hr3mKZmdbyoopzSoyJe3znhSkIp2/V8o4h6amSoA4 Bf7sEFgBrdWJxZ0l4u+/A5jtPBf5LxhC9j40h8wpSGJGUzoxGoLqIFsc5pa1bjH/fs6Ig+dk1GeWt 2W9pYCRisloWPCWAT9c/T09L/zAW7u9wsMzsnPFzWdlWFKDaQmfY7PybtipU4ulc9diQMXPdVUQLH E5cqq1TA==; 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 1nL5Ui-006m4a-J0 for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 16:48:28 +0100 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nL5Ui-000P7m-7V for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 15:48:28 +0000 Date: Fri, 18 Feb 2022 16:48:27 +0100 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: How to generate a Makefile.depend? Message-ID: <20220218154827.uxa6siux64lncsog@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2vupeaemgbywxwhh" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: 4K0bhG0fbKz3jYh X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b="L//+ABNZ"; 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]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --2vupeaemgbywxwhh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Eugene Grosbein [20220218 22:08]: > Take a look at comments in the file /usr/share/mk/bsd.dep.mk > Generally you run "make depend", but it tells that > "meta+filemon mode will track dependencies itself", so no depend files us= ed in this case. I don't think that really cuts it: make depend just does nothing here. But I assume these DIRDEPS are needed to avoid the classic recursive make problem of building something before the dependencies were built. I found there's share/mk/gendirdeps.mk to build a Makefile.depend (using some shell or python script), and share/mk/meta.autodep.mk to somehow automate that process, but I just can't figure out how to actually use any of that... Or are you telling me all the Makefile.depend files in the tree are deprecated and should be removed? --=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 --2vupeaemgbywxwhh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmIPv8sACgkQPvKLCrwC 2ioHYQf/XFzzeIVoifq/r15ndjkVthc30kDRiJTFHKmruKRfoAlENI8sTVMzZLyJ nm23kONZEjx1u4TSTyIm2lXE9jEFLkGXwFDoZOPf8OgmcIsENLaEwbipbQ1plIoN oQHiqV5izFVcrk/Q7VOxUlpyvwmznqih8LLyxRmgX86sP3NOPY0TzpHhvcOJjRqB VwFQCi6YpK2qquor0M9jKK1OLE+5g6gCoyWKe62NStvu+TMH1Z1JY6AmiaHn+PeB tveWBGc6KfeSinxjVm6WaPwuWHlx1n0Od8Q6TSYnEdlHNPMDL1YLoB6OD2vrbJtv vqp6eEZyXWWxELozijLDBA8NYpIljA== =poB3 -----END PGP SIGNATURE----- --2vupeaemgbywxwhh-- From nobody Fri Feb 18 16:57:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7856819D291C for ; Fri, 18 Feb 2022 16:57:07 +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 4K0dCQ5FT4z3tcT for ; Fri, 18 Feb 2022 16:57:06 +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=i/ZoYuyrNJzUN5V/5Jfz6JrbKZ8RRqLTXlwMApvQ9YU=; b=kfWwKl0bD0bb+SrQCKqwdR24DJ lrz82/W8rqYb4yaddCDvp7umrd5bjrIISMy6nGHq88w1rkYw5iNJVtcVCPCZQ7HlaXQBmArQzZ4lg TZinr2B+LHV3UDq0As1BTA03s/EvyrAsFrQxjZv67sgHavf5UK6Ae922mHEdGSVrxafUzXCXtDs79 RVcc3+ehq1GlurBOBvqSqYA1nD4vVbhSrk5vxsWCLMhLIHBJ6huuUv3Rcrsv4g3bL0JzVG6FI6PWl WhQfs39x3InThr2m4SL1S7Bo0nwLY/wJXIYBEKZmqxZW1P8PYjyDRSe+AYaFH4nmlRpUco63RzEMY k3pe5j7Q==; 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 1nL6Z5-006mFO-KC for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 17:57:03 +0100 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nL6Z5-000PXg-8t for freebsd-hackers@freebsd.org; Fri, 18 Feb 2022 16:57:03 +0000 Date: Fri, 18 Feb 2022 17:57:02 +0100 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: How to generate a Makefile.depend? Message-ID: <20220218165702.jlfiqrngjzsc2b45@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ucrrvffzonjbkhjs" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: 4K0dCQ5FT4z3tcT X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=kfWwKl0b; 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]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --ucrrvffzonjbkhjs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kyle Evans [20220218 09:44]: > Makefile.depend falls in "do not worry about it" territory; they're > only used for dirdeps mode, which to my understanding will tolerate > and generate the missing Makefile.depend as it goes anyways. bdrewery > or sjg periodically commit/update .depend files. Oh, that's really good to know, thanks! I guess I was confused because I found some old slides and other stuff about meta mode suggesting you had to generate them somehow, but lacking clear instructions. Could be worth mentioning in the developers handbook! So, to phab we go soon I guess, thanks again. --=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 --ucrrvffzonjbkhjs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmIPz9kACgkQPvKLCrwC 2iqszQf/Rc7fYFX3N/a0V/losJhpmNuXkMvmarxjke2Icw0mVAPwWk7hntOTL+FP G688Vk3IxXFeVERhoCk36R5w2oMK0eTEOeqyArgQYEB5qkubouT0PzQlb6hnK6Rm JzL76+ccYIYHBcp+Q2g0MR152V85C/gVXaw9rh7ZWE0mhEP8oNhUmAT6Z/onYDtr adXFj4gWzWzAQftiW/+0QU7hXevFB+eA5xWKcmfXq5A0REcwA7S0nkWG8W1QVbHW 96Vdkt6lIuDsPHUgu95oavrEMHvaCZpihu5e2XL6BJshRGG/z6JqcUrBtaG2awWU RFKhAl3I8WPdM6Tpnb1R5qo1upvkrg== =mdr5 -----END PGP SIGNATURE----- --ucrrvffzonjbkhjs-- From nobody Fri Feb 18 17:19:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4449E19D738C for ; Fri, 18 Feb 2022 17:19:40 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K0djR2bqjz4Sgf for ; Fri, 18 Feb 2022 17:19:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa31.google.com with SMTP id f12so5184022vkl.2 for ; Fri, 18 Feb 2022 09:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6EqcDh/982mWqmMfDg5uTfmgWVqCZF70GmSiawHoaWI=; b=NAxqUQ/sX9G3FQq2bIhEdN9WB7G3Fo7dnfLHr11sVwTUPIq/ccxHGd1v+ck3mnevOH VGLh8KrvnKSEX/g814BLpqkjVQy3EoAddPe5cibgOuYcdpcR8yixzDTtxz7pOhdvepsg 2YnyugUtlHNvKesIS1/8OikEQ6M/X18wkYuCOchUOMSjeeKxil1m/DuqCY6ap3elMkrr 7ZtTUv+mO48QUgb2e+45X4sZGUbHpLrVvKhUw7F2xvOFmLfL0nc/9ie5oNrh0u04Uw+R zrzC5Mr13BjE7pKdZfPxpmJZLYiCxv9YVAj3KodFgbqHKrUA8B22VO0/ZnFg9qWYrhDL stOw== 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=6EqcDh/982mWqmMfDg5uTfmgWVqCZF70GmSiawHoaWI=; b=c/7pOp8rOCMvv+UBmUVZo04xYURqDNB1+hXiMlnkGS+40guiY7xiWz/05/7dMd1OcC tajTdD3CJzyUl/VJg7JFuL/XK3MmZGoC2cL3fENZIAzrIDSiPaY0j24KAuRjJDmzoSIQ ltZYEGWahzpwYpoKDJjG/VgZvVtc0/rwobK0rpTJk9YE8AWkPsI5yTrans4jH2RDuxKe NXndk8Bi0wpBL5A1t/wddjd/bGtdAAO0iFuhK0NtpI5KuR4LNsP+sTj6+Iv2ChMvn/g3 377+loizktWdjzb53WseqapSNFU2iP0xw1spBlLNq8bPckpnEsNwEEaIAtTzXxjFatRA B4Qg== X-Gm-Message-State: AOAM530ACD2KXuKrdAsGbk5sm4h7L7MOus419AkuUtyBEERFepnieoKZ /i/6YAmz89tZk7HBW1BKKl0eF5MpZ0p+Rn0B+mxI9XkUseE= X-Google-Smtp-Source: ABdhPJwtnyGyi0Ss63PgIrS4BBdsSLdAa+YrI/kJbpvs23jep+86DbRR8hOQXuSLsl14kwZVQqN58bARhVGlFy7rSCY= X-Received: by 2002:a05:6122:509:b0:331:188f:76cb with SMTP id x9-20020a056122050900b00331188f76cbmr4217626vko.40.1645204778433; Fri, 18 Feb 2022 09:19:38 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> <20220218165702.jlfiqrngjzsc2b45@nexus.home.palmen-it.de> In-Reply-To: <20220218165702.jlfiqrngjzsc2b45@nexus.home.palmen-it.de> From: Warner Losh Date: Fri, 18 Feb 2022 10:19:27 -0700 Message-ID: Subject: Re: How to generate a Makefile.depend? To: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000066d55c05d84e1653" X-Rspamd-Queue-Id: 4K0djR2bqjz4Sgf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="NAxqUQ/s"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(0.73)[0.728]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000066d55c05d84e1653 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 18, 2022 at 9:58 AM Felix Palmen wrote: > * Kyle Evans [20220218 09:44]: > > Makefile.depend falls in "do not worry about it" territory; they're > > only used for dirdeps mode, which to my understanding will tolerate > > and generate the missing Makefile.depend as it goes anyways. bdrewery > > or sjg periodically commit/update .depend files. > > Oh, that's really good to know, thanks! > > I guess I was confused because I found some old slides and other stuff > about meta mode suggesting you had to generate them somehow, but lacking > clear instructions. Could be worth mentioning in the developers > handbook! > > So, to phab we go soon I guess, thanks again. > So, Makefile.depend is used only for dirdep mode. It is not used for normal META mode. In dirdep mode, you can cd src/bin/ls and type make from a clean tree. It will rebuild libc, csu, compiler_rt and whatever else ls might depend on. Unless you are using dirdep and have mostly clean trees, you won't notice if it's missing. There is an out-of-tree python script that generates these from time to time quickly. There's a make target 'make bootstrap-this' which will generate it for the current directory (I believe, I'm reading code here). There's also a 'make bootstrap-empty' that might be needed depending on the bootstrap method. I *think* from the comments you could do a meta mode build, which would populate the objdir with all the artifacts that the above targets use to generate Makefile.depend and then use the above target to generate the Makefile.depend for the one directory. I usually don't bother, as I know these are regenerated from time to time, but I'm always happy to change my workflow if there's enough hassle to people from it. Warner --00000000000066d55c05d84e1653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Feb 18, 2022 at 9:58 AM Felix= Palmen <felix@palmen-it.de>= ; wrote:
* Kyle = Evans <kevans@fr= eebsd.org> [20220218 09:44]:
> Makefile.depend falls in "do not worry about it" territory; = they're
> only used for dirdeps mode, which to my understanding will tolerate > and generate the missing Makefile.depend as it goes anyways. bdrewery<= br> > or sjg periodically commit/update .depend files.

Oh, that's really good to know, thanks!

I guess I was confused because I found some old slides and other stuff
about meta mode suggesting you had to generate them somehow, but lacking clear instructions. Could be worth mentioning in the developers
handbook!

So, to phab we go soon I guess, thanks again.

So, Makefile.depend is used only for dirdep mode. It is not used for=
normal META mode. In dirdep mode, you can cd src/bin/ls and type=
make from a clean tree. It will rebuild libc, csu, compiler_rt a= nd whatever
else ls might depend on. Unless you are using dirdep = and have mostly
clean trees, you won't notice if it's mis= sing. There is an out-of-tree python
script that generates these = from time to time quickly. There's a make target
'make bo= otstrap-this' which will generate it for the current directory (I
=
believe, I'm reading code here). There's also a 'make boot= strap-empty'
that might be needed depending on the bootstrap = method.

I *think* from the comments you could do a= meta mode build, which
would populate the objdir with all the ar= tifacts that the above targets use
to generate Makefile.depend an= d then use the above target to generate
the Makefile.depend for t= he one directory.

I usually don't bother, as I= know these are regenerated from time to
time, but I'm always= happy to change my workflow if there's enough
hassle to peop= le from it.

Warner
--00000000000066d55c05d84e1653-- From nobody Sat Feb 19 10:17:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E710919C552A for ; Sat, 19 Feb 2022 10:17:11 +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 4K14HW1GWfz3lJ9 for ; Sat, 19 Feb 2022 10:17:11 +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=cjt3FzRQ1EHfXQlpDyp56MbsEHLnwQga5pc6fG5H058=; b=16D6B2Ae3R513bN40JXkpdl94q fuApInli1zRHdbc/hxkVMc1dKgToPXdwBUlFwo6XggChgR5nbkpNVPZHFOuLme6oIY4W8HIz/NHFw 8LbOaPUKYieb3wcgv68nv5nuN3KQuppVXbGR7eWza/3a8F5QllYrUQlv1T+b2uko+NwU/qJ7mTjtk JOqowEF7pq6Yj9IxCpwioZDmcB+CCXJLQ7p5WOlK6JxsBO1mChWGMRaE0Y4XeRUZRGBe1MaOL34id QHeiq4cpG8x0/Jj7kvGfNjTe8CZaiQCZXbRoMGWj3HtCxvopEEEjuo1M0E4TYjdQ5Pk08X2AHtVLi UKrmerjw==; 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 1nLMnd-006phm-Q2 for freebsd-hackers@freebsd.org; Sat, 19 Feb 2022 11:17:09 +0100 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nLMnd-0006yg-ER for freebsd-hackers@freebsd.org; Sat, 19 Feb 2022 10:17:09 +0000 Date: Sat, 19 Feb 2022 11:17:08 +0100 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: New suid-root helper for pam_unix auth -- how to review? Message-ID: <20220219101708.cq3flvfigm5hafkf@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l73nijwh532ntpcd" Content-Disposition: inline User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: 4K14HW1GWfz3lJ9 X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=16D6B2Ae; 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]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --l73nijwh532ntpcd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable So, I added some code to allow pam_unix authentication for non-privileged processes by using a suid-root helper internally, and uploaded my code to phabricator: https://reviews.freebsd.org/D34322 That's the top of a 3-commits-stack, with the first commit only fixing some tiny error I came across, the second adds the helper and the last modifies pam_unix to use the new helper. My question now is, how should I proceed to get a review? In MAINTAINERS, I read des@ is maintaining libpam -- does this apply to modules as well, so should I add him as a reviewer? There's also the wording "email only" and I'm not sure what that means -- should I send him the patches by mail instead of adding him on phabricator? Thanks, 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 --l73nijwh532ntpcd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmIQw54ACgkQPvKLCrwC 2ioyjQgAgqQURG9VjlVFiIXsP6iAw76l3pq9R1u/vwICvA4R9gV/LGdt0mLxQn58 oAllOu86Lb7l4vLPdFXAC7Fehzh9Xkbqt7WYk+gQz5ykAdnPX3mDmBqO2Ppf21Hn 2YdD1dX8AmaSd78qtmrJpzes99s2blqdkuWQ6gFS9PE/PEyVZOss8ZPkgPLEB1pS hvDc4oenQbHCwx8qKtd7/HQR7tKE9pSdHqEq66XAC801JG3Js1m/VJyYZGFS4vqt mCgX9Zk2Si8mQu2n0UtXioiE/ZVnucwSSHsgruwjMevl7NDzMMuqW5GHhsSwViwD Ps8yQdR12QQwfg1P3EzM7juEkEy3rQ== =l5cD -----END PGP SIGNATURE----- --l73nijwh532ntpcd-- From nobody Sat Feb 19 11:31:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EB6E419D1787 for ; Sat, 19 Feb 2022 11:31:50 +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 4K15xf3b4Sz3rwt for ; Sat, 19 Feb 2022 11:31:50 +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=nCbubCjyaeX7nYYTpjEoRkC2lhH9lgRBgidKNFHMwGA=; b=xeifTxiz0IORcftsBeML7Ndq9Z 0fBLhOM1yVYcaZ0y8krFTRtqdYclci7QO+TcqwQgRH0d5Fl9vagy455FPkYv60GUOvHmGEvfhCf0/ FUwK2iOfWZ2zyubypFzbtbJWcHnVXv2B9jHdFqePNR1x425momzWicx6DWRRsMdDy0ydHi/HFbxK0 a/ykMSXcHuyRfKnEkoqWNjy/TsVN/u85gM+qfnWGBe5dY+kIQ6TKv40Ns8fSGtrtW9STLSrgHbuwg guoachPrvU6c151zYloV/fDaUTTHKSBIM7kuKBT97QRlJbeHMaYK2nzwZtNkbM6FrjKW9oBWXN8MX z+HT57WA==; 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 1nLNxt-006pwh-0w for freebsd-hackers@freebsd.org; Sat, 19 Feb 2022 12:31:49 +0100 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nLNxs-0007OB-Gi for freebsd-hackers@freebsd.org; Sat, 19 Feb 2022 11:31:48 +0000 Date: Sat, 19 Feb 2022 12:31:47 +0100 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: How to generate a Makefile.depend? Message-ID: <20220219113147.ylfyxkwdh3binnds@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <20220218142803.t444nf77dh2sfkgb@nexus.home.palmen-it.de> <20220218165702.jlfiqrngjzsc2b45@nexus.home.palmen-it.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="b2vryzjfsrc44gek" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20211029 X-Rspamd-Queue-Id: 4K15xf3b4Sz3rwt X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=xeifTxiz; 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]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --b2vryzjfsrc44gek Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Warner Losh [20220218 10:19]: > script that generates these from time to time quickly. There's a make tar= get > 'make bootstrap-this' which will generate it for the current directory (I > believe, I'm reading code here). There's also a 'make bootstrap-empty' > that might be needed depending on the bootstrap method. Thanks for the suggestion! I tried both targets in my new directory with the simple Makefile for a binary (prog), and they're both unknown :o Having learned now it's fine to submit something without this Makefile.depend, I decided to just go for it :) --=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 --b2vryzjfsrc44gek Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmIQ1SMACgkQPvKLCrwC 2iom0wgAm1dEnaHVfoN57GDivRwLPzFiUoHRblrth/Jd2xIK7KhlKFtMnsT5PLCf eeBJ+e33SzGAVI2lu4P++N0WSX++5MqIJfDtm1yJ5QO9xkG0P8irchIFAuVsBbV2 GsJ7u4lsEjYFRnX9NmOB8Iga8Tp6Bk6oUH/PitwlriTcjDa8aMIJDIAFPqUJazSq bglzcmiP87AxglbtRvzgVImKXr7uyxki8Oss2CcOLe29LIg+yVahFVd1cs8R+tzG CyHJ5Pr8nXBM9N3gJjPudsS0rL8A0GGPM2kfx3ht6AtOV/7AvlJgDYthykrPUq5E /IipzQGAfaaAWdJfP150IV0JsezGIQ== =BygT -----END PGP SIGNATURE----- --b2vryzjfsrc44gek-- From nobody Mon Feb 21 10:44:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AC4AE19C914D for ; Mon, 21 Feb 2022 10:44:38 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K2JpF4cdvz4kl3 for ; Mon, 21 Feb 2022 10:44:37 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 21LAiSZm092247 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 21 Feb 2022 11:44:28 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1645440268; bh=2P+vyF3iR+XidYZFWzQ1UuOIAFgLSNhxakXtM74fuCg=; h=Date:From:To:Subject; b=m1nC7OwIe3LJnwVkC+caAiWX04OMU2D31bmOUq6T0j+hmRMHBXTZ94JuVbUF+PsBO t/YWJu6wip9hEuFdh1LCdaW8W94gHGaw6WOa7Hvttk5aLJicAUfRPTaR4yQEV0PcZE vOSnoI78PSKpAPAqjzazphAsqAdJex5sZYPayuQ0= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 21LAiRH9006240 for ; Mon, 21 Feb 2022 11:44:27 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 21LAiRGV006237 for ; Mon, 21 Feb 2022 11:44:27 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 21 Feb 2022 11:44:27 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: problem with USB-CD drive Message-ID: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4K2JpF4cdvz4kl3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=m1nC7OwI; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[puchar.net]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I wrote software for microcontroller with USB device port that presents itself as USB CD and includes ISO9660 image. It works under windows - "CD" is detected and files readable it works under MacOS - same It mostly works under FreeBSD. FreeBSD detects it properly ugen1.5: at usbus1 umass0 on uhub5 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0: Attached to scbus3 cd1 at umass-sim0 bus 0 scbus3 target 0 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: Serial Number 220123456789 cd1: 1.000MB/s transfers cd1: 16MB (8192 2048 byte sectors) cd1: quirks=0x10<10_BYTE_ONLY> i can read sectors by dd, by single (bs=2k) or multiple. Other communication (vendor specific SCSI commands - used to configure/control the device with our software) - works properly. If i make an image (first 34 sectors, device presents itself as 16MB to prevent problems with some OSes but everything later are zeros) - it is good - did cmp with original image file. i can do mdconfig, mount_cd9660 on this file and everything is fine. BUT mount_cd9660 /dev/cd1 /mnt results in: mount_cd9660: /dev/cd1: Invalid argument There is no kernel messages. How could i find out what is exactly a problem? From nobody Tue Feb 22 17:34:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B502919EB8D8 for ; Tue, 22 Feb 2022 17:35:04 +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 4K35sN4j3bz3kXk for ; Tue, 22 Feb 2022 17:35:04 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645551304; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=nzSkLicbYzHEnsxAfQ3Pxz69pVmFQw9RW8amvygQOPY=; b=U3QZ08I+3IlFp49xitTGP+PM49ZTEeCgqe+5upJWOcGnB0cGUDPBC54Rfi0JugMqWnfsSS aBOg7es4DL1a0tPYJ9n/O4LKQbcehJJ/CugTIgIivBWBlLYkyxe/SWs7XUbpFpfwxV6wSp gzVdbPiPcRXaDivsDCo18Kasx1Zn+rnE/DxvqYy8LeJIpVFbTgXExZa6sIxB/obZeLNI7A K7WUBPRnxgQmzwlbRJsb4kRBbMWDnXlKOu+bnm94w+O6DOMK3/dMUkDtmnM1PiFRUupKlS r4hxAa/AsS9yesdy0Wg91P5l1u+2HdhsUxkMJUFnsvMt8sLWOT2ruQ7fu/fnUw== Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 7D10C22247 for ; Tue, 22 Feb 2022 17:35:04 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f172.google.com with SMTP id n185so528938qke.5 for ; Tue, 22 Feb 2022 09:35:04 -0800 (PST) X-Gm-Message-State: AOAM530n5u30GaQhQnTWaM78+bb54Y4zoSUBOXJ7nHuS0DyRS1ttD5F9 B8OOaeYmi3Io3aI0IUpe3cwCZ/xHij+Aqp8Lpeo= X-Google-Smtp-Source: ABdhPJyLippYicQzpiRitAS1709HVDLDZcUJzHfc+W03j0h04Klk8nGM3GjMsFDn6ZzI2NPCi56JA0PZfQKuflUB2D8= X-Received: by 2002:a05:620a:240a:b0:648:c490:41c with SMTP id d10-20020a05620a240a00b00648c490041cmr9194066qkn.365.1645551304111; Tue, 22 Feb 2022 09:35:04 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Tue, 22 Feb 2022 11:34:48 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: iconv changes To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645551304; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=nzSkLicbYzHEnsxAfQ3Pxz69pVmFQw9RW8amvygQOPY=; b=TI4yWdExXBRkmZHOuGjOVjQ0cITPPr/zPh4z8LLHhTCNTbe4xHSUTQPYGKIrtwMsVhj8IU RUX9f1TWkB2hjzcI9opv+9zVmUh3iNTvc1cZ+zI2A+rknzKPPSA8w6Amk+kTcGW6m42Nj9 0/NE6znTbC9DCmV6i7oTo9hjPKDCXG6Nfm/gsnpglD5bNlqImsqHAIpJ5k8aWOgONwVrQ+ yKVoaTQNxp/cvuHrEjtIRtrE7jy5gn45GfNKvYs48XOT0nuI5tOkAIFpM5C1zGDEAwfRRb m/9ODipCCPvjeCoKTgDMMMbX40Dtm8K4obuTWVYeGsHX2znV/A+VoRdW8ZZa9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645551304; a=rsa-sha256; cv=none; b=TSh2DDSEgs2reWe8iutzzTMKT57UA1wey9Q52iBsyx/a2Ee7ul7tjw7j5fmE8LdG7c5JK0 J3QqSfkOA5bpZEFNukim5BnY2bsodNhf1NxnY7ZW/eT3QN/EZA25chB/c1pCFbscYXs7zV q8i+Xo902BFNsplkuNveRXh5Khhq1XKjZnjfTsVbdfE3yqLtDazXkb9SKe9gltbaFaItLj G9dJgi5ZB9Cs8wiuUD3CIZzXLNjviGNvKlIvoT/+PHrTDIocqDTDSaHEQAZKsrjw1FBVS3 OMQA+KetdRRMaN1RQ6nwuueaqmcXAcHIgaijLVcGg5YEYVZ09AM5YXXb/ynKiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello! Results of `git log` were somewhat inconclusive, so I'm casting a bit of a wider net here; I've got four changes just posted to Phabricator for iconv and iconv modules that could use some third party review. These largely pertain to //IGNORE support: - https://reviews.freebsd.org/D34342 ("iconv: only conditionally use ICONV_SET_DISCARD_ILSEQ") - https://reviews.freebsd.org/D34343 ("libc: iconv: push option ignore into citrus_iconv_open()") - https://reviews.freebsd.org/D34344 ("libc: iconv: add mb_cur_min for encoder traits") - https://reviews.freebsd.org/D34345 ("iconv_std: complete the //IGNORE support") The short version is that //IGNORE is only partially implemented at the moment if you consider the behavior it was trying to model: GNU libiconv. With GNU libiconv, you can use it to, e.g., sanitize a UTF-8 string by removing illegal sequences rather than truncating. These reviews aim to fix it so that it works the same for our libiconv, which would previously only ignore EILSEQ that arise as a result of csmapper failures and not those that arise in initial mbrtowc. Thanks, Kyle Evans From nobody Wed Feb 23 18:10:56 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D89D19ED9B4 for ; Wed, 23 Feb 2022 18:11:40 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3kd72krnz3KP9; Wed, 23 Feb 2022 18:11:39 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-2d62593ad9bso220506257b3.8; Wed, 23 Feb 2022 10:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=xc4k8CoPqh4dynQjQg202DKvTXTfSjFbuA7Hndh/wAg=; b=qxSxZHHXj116RcgeGH7toUoswbrZTv6UpzESrkkzVrcaugoApKkoI43w/j+c1ob20i ONpBbKgrm9RO74O7sb8kyVpClJJV86s3BMkeW3W7ib93BbM8pW3BIyjWotpPbOWPHwcE +FY/Pg/1sY+Lkjf1AAS/jKaxXfXNgkAr6Gl6ef0PbIQ2P/LHBPjp+pDgB15A6Fzq0wl1 9EuN1r1QNIDFI1lAJYpb+xIEPUYxJOT8DTqUGEl4IgI1enfmUmx4D1FqmUf2C0399aws 6pOHg/3uqXGyyeNfcd3Ohs+bx0n52TaRCZqc0SeOVBLCLO961KarbneGt0mV2KAz39JN V11Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xc4k8CoPqh4dynQjQg202DKvTXTfSjFbuA7Hndh/wAg=; b=jXwR1GHBuDcUcrMw8M7CLEe2QdN8fYvfLJy5/Lip4rocj0FTNRTFLZPbWbr5ESDweE kW/l5nHRkff8B6sx7KqZ9LoAINcSZgOKJ27/TWgxb/ALlu19gwDduGLdSjgkPKbQI5en M7N7mOyQxil5mWDi9EJYaiBxjORn+Yd3SF2rTs3BpAObGamk6mOXlWU6ImIm1oQiNIVS n9U6H9Au24RCmjm65QTnnRbpylVVeSe0hgEhTvOmF+pLDu8TfeXmJn3/1CMuECXVD2F6 DjwZ4xpPjnasG76tFQR3+JBZyW44JGoqYexHfE/pd26v6nVIZmunqHcH2IYOpJ0AE/Mr MgGQ== X-Gm-Message-State: AOAM531CYU+4kf/TLieZNEBAZv7mmjU3qkb61P73dAybJxtKWLU5IYGD lHzttFl4YjbfPwQ6kZfLt4sdTzjPZabH11+OyeHWl5ULiDU= X-Google-Smtp-Source: ABdhPJz3ULK8JBcXL01T0epcrXWSFFQ+ZcSZJFJbXyz4y/d1VfnkE9EkOBUdAWvu4S3XfCrofGVcqF01KrraOa5qrTI= X-Received: by 2002:a81:9b81:0:b0:2ca:287c:6d62 with SMTP id s123-20020a819b81000000b002ca287c6d62mr784334ywg.519.1645639893021; Wed, 23 Feb 2022 10:11:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Wed, 23 Feb 2022 19:10:56 +0100 Message-ID: Subject: No physically installed OS can boot if a device is passed through at the same time,using any kind of recent FreeBSD version as host OS (13R,13-STABLE and 14-CURRENT are involved) To: hackers@freebsd.org, developers@freebsd.org, Aryeh Friedman Content-Type: multipart/alternative; boundary="00000000000040795f05d8b36591" X-Rspamd-Queue-Id: 4K3kd72krnz3KP9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qxSxZHHX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1135 as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[7]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1135:from]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000040795f05d8b36591 Content-Type: text/plain; charset="UTF-8" Hello to everyone. I'm using bhyve on FreeBSD 13R p7 and I'm trying to pass thru my USB controller and / or my graphic card (Geforce RTX 2080 ti) while at the same time I would like to boot a physically installed OS. I can choose between 3 operating systems (Ubuntu,Windows and FreeBSD 13) that I have installed physically on a SATA and / or NVME disk and I'm trying to call them inside the bhyve parameter using the virtio-blk driver and the ahci-hd driver. The problems that come out from this setup are different and concatenated. Anyway,those OS won't boot because it seems that the devices that I pass thru interferes with the booting process. If I don't pass thru any device,they can boot properly. In addition,my graphic card seems to have an additional problem. It seems that it is not passed correctly when I use FreeBSD 13R (it is if I use FreeBSD 14 Current and 13-stable). Below I want to show you different cases to explain the problems that I'm experimenting : CASE 0) Without passing thru the USB controller and the graphic card on Ubuntu 21.10 / Windows 11 (installed physically) can boot properly with these parameters On FreeBSD 13R : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 BdsDxe: loading Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-061F-A385" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0) BdsDxe: starting Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-061F-A385" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0) CASE 1) Passing thru the USB controller and the graphic card and booting from a physical installation of Ubuntu 21.10 / Windows 11 (and also with the physical installation of FreeBSD 14 CURRENT as guest os) on a nvme disk on FreeBSD 13R : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2,passthru,1/0/0 \ -s 3:0,passthru,2/0/0 \ -s 3:1,passthru,2/0/1 \ -s 3:2,passthru,2/0/2 \ -s 3:3,passthru,2/0/3 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 Sometimes Assertion failed: (error == 0), function modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_emul.c, line 501: Abort / sometimes black screen frozen CASE 2) Passing thru the USB controller and booting from a physical installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with the physical installation of FreeBSD 14 CURRENT as guest os) on FreeBSD 13R : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2,passthru,1/0/0 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 = BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-061F-A385" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0): Not Found CASE 3) Passing thru the graphic card and booting from a physical installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with the physical installation of FreeBSD 14 CURRENT as guest os) on FreeBSD 13R : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2:0,passthru,2/0/0 \ -s 2:1,passthru,2/0/1 \ -s 2:2,passthru,2/0/2 \ -s 2:3,passthru,2/0/3 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 = Assertion failed: (error == 0), function modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_emul.c, line 501 : Abort case 4) Booting from a physical installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with the physical installation of FreeBSD 13R as guest os) on FreeBSD 13-STABLE : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 it can boot. case 5) Passing thru the graphic card and booting from a physical installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with the physical installation of FreeBSD 13R as guest os) on FreeBSD 13-STABLE : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2:0,passthru,2/0/0 \ -s 2:1,passthru,2/0/1 \ -s 2:2,passthru,2/0/2 \ -s 2:3,passthru,2/0/3 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 it won't boot : BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DISK BHYVE-EE1E-05D9-14BB" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0): Not Found case 6) Passing thru my USB controller and the graphic card and booting from a physical installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with the physical installation of FreeBSD 13R as guest os) on FreeBSD 13-STABLE : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2:0,passthru,1/0/0 \ -s 3:0,passthru,2/0/0 \ -s 3:1,passthru,2/0/1 \ -s 3:2,passthru,2/0/2 \ -s 3:3,passthru,2/0/3 \ -s 8,virtio-net,tap1 \ -s 29,fbuf,tcp=0.0.0.0:5901,w=1440,h=900,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ -l com1,stdio \ vm1 it won't boot : BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DISK BHYVE-EE1E-05D9-14BB" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0): Not Found. SUMMARY : It seems there is some serious bug in every version of freebsd,13 release,13 stable and 14 current,that does not allow to boot any kind of physically installed OS if it is passed through any kind of device. I've already opened a bug report and no one seems to work on it. Would someone take care of these bugs ? thanks. -- Mario. --00000000000040795f05d8b36591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to everyone.

I'm using bhyve on FreeBSD 1= 3R p7 and I'm trying to pass thru my USB controller and / or my graphic= card (Geforce RTX 2080 ti) while at the same time I would like to boot a p= hysically installed OS. I can choose between 3 operating systems (Ubuntu,Wi= ndows and FreeBSD 13) that I have installed physically on a SATA and / or N= VME disk and I'm trying to call them inside the bhyve parameter using t= he virtio-blk driver and the ahci-hd driver. The problems that come out fro= m this setup are different and concatenated. Anyway,those OS won't boot= because it seems that the devices that I pass thru interferes with the boo= ting process. If I don't pass thru any device,they can boot properly. I= n addition,my graphic card seems to have an additional problem. It seems th= at it is not passed correctly when I use FreeBSD 13R (it is if I use FreeBS= D 14 Current and 13-stable). Below I want to show you different cases to ex= plain the problems that I'm experimenting :

CASE 0) Without pass= ing thru the USB controller and the graphic card on Ubuntu 21.10 / Windows = 11 (installed physically) can boot properly with these parameters On FreeBS= D 13R :

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H \<= br>-s 0,hostbridge \
-s 1,ahci-hd,/dev/nvd0 \
-s 8,virtio-net,tap1 \<= br>-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D14= 40,h=3D900,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/= local/share/uefi-firmware/BHYVE_UEFI.fd \
-l com1,stdio \
vm1

= BdsDxe: loading Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-061F-A385&qu= ot; from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0)
BdsDxe: starting= Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-061F-A385" from PciRoo= t(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0)

CASE 1) Passing thru the US= B controller and the graphic card and booting from a physical installation = of Ubuntu 21.10 / Windows 11 (and also with the physical installation of Fr= eeBSD 14 CURRENT as guest os) on a nvme disk on FreeBSD 13R :

bhyve = -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H \
-s 0,hostbridge \<= br>-s 1,ahci-hd,/dev/nvd0 \
-s 2,passthru,1/0/0 \
-s 3:0,passthru,2/0= /0 \
-s 3:1,passthru,2/0/1 \
-s 3:2,passthru,2/0/2 \
-s 3:3,passth= ru,2/0/3 \
-s 8,virtio-net,tap1 \
-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D1440,h=3D900,wait \
-s 30,xhci,tablet= \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.f= d \
-l com1,stdio \
vm1

Sometimes Assertion failed: (error =3D= =3D 0), function modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_= emul.c, line 501: Abort / sometimes black screen frozen

CASE 2) Pass= ing thru the USB controller and booting from a physical installation of Ubu= ntu 21.10 / Windows 11 on a nvme disk (and also with the physical installat= ion of FreeBSD 14 CURRENT as guest os) on FreeBSD 13R :

bhyve -S -c = sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H \
-s 0,hostbridge \
-s = 1,ahci-hd,/dev/nvd0 \
-s 2,passthru,1/0/0 \
-s 8,virtio-net,tap1 \-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D1440= ,h=3D900,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/lo= cal/share/uefi-firmware/BHYVE_UEFI.fd \
-l com1,stdio \
vm1

= =3D BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DISK BHYVE-51F3-0= 61F-A385" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFFF,0x0): Not Fou= nd

CASE 3) Passing thru the graphic card and booting from a physical= installation of Ubuntu 21.10 / Windows 11 on a nvme disk (and also with th= e physical installation of FreeBSD 14 CURRENT as guest os) on FreeBSD 13R :=

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H \
-s 0= ,hostbridge \
-s 1,ahci-hd,/dev/nvd0 \
-s 2:0,passthru,2/0/0 \
-s = 2:1,passthru,2/0/1 \
-s 2:2,passthru,2/0/2 \
-s 2:3,passthru,2/0/3 \<= br>-s 8,virtio-net,tap1 \
-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D1440,h=3D900,wait \
-s 30,xhci,tablet \
-s 31= ,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
-l c= om1,stdio \
vm1

=3D Assertion failed: (error =3D=3D 0), function = modify_bar_registration, file /usr/src/usr.sbin/bhyve/pci_emul.c, line 501 = : Abort

case 4) Booting from a physical installation of Ubuntu 21.10= / Windows 11 on a nvme disk (and also with the physical installation of Fr= eeBSD 13R as guest os) on FreeBSD 13-STABLE :

bhyve -S -c sockets=3D= 1,cores=3D2,threads=3D2 -m 4G -w -H \
-s 0,hostbridge \
-s 1,ahci-hd,= /dev/nvd0 \
-s 8,virtio-net,tap1 \
-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D1440,h=3D900,wait \
-s 30,xhci,table= t \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.= fd \
-l com1,stdio \
vm1

it can boot.

case 5) Passing t= hru the graphic card and booting from a physical installation of Ubuntu 21.= 10 / Windows 11 on a nvme disk (and also with the physical installation of = FreeBSD 13R as guest os) on FreeBSD 13-STABLE :

bhyve -S -c sockets= =3D1,cores=3D2,threads=3D2 -m 4G -w -H \
-s 0,hostbridge \
-s 1,ahci-= hd,/dev/nvd0 \
-s 2:0,passthru,2/0/0 \
-s 2:1,passthru,2/0/1 \
-s = 2:2,passthru,2/0/2 \
-s 2:3,passthru,2/0/3 \
-s 8,virtio-net,tap1 \-s 29,fbuf,tcp=3D0.0.0.0:5901,w=3D144= 0,h=3D900,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/l= ocal/share/uefi-firmware/BHYVE_UEFI.fd \
-l com1,stdio \
vm1

i= t won't boot : BdsDxe: failed to load Boot0001 "UEFI BHYVE SATA DI= SK BHYVE-EE1E-05D9-14BB" from PciRoot(0x0)/Pci(0x1,0x0)/Sata(0x0,0xFFF= F,0x0): Not Found

case 6) Passing thru my USB controller and the gra= phic card and booting from a physical installation of Ubuntu 21.10 / Window= s 11 on a nvme disk (and also with the physical installation of FreeBSD 13R= as guest os) on FreeBSD 13-STABLE :

bhyve -S -c sockets=3D1,cores= =3D2,threads=3D2 -m 4G -w -H \
-s 0,hostbridge \
-s 1,ahci-hd,/dev/nv= d0 \
-s 2:0,passthru,1/0/0 \
-s 3:0,passthru,2/0/0 \
-s 3:1,passth= ru,2/0/1 \
-s 3:2,passthru,2/0/2 \
-s 3:3,passthru,2/0/3 \
-s 8,vi= rtio-net,tap1 \
-s 29,fbuf,tcp=3D0.0.0.0= :5901,w=3D1440,h=3D900,wait \
-s 30,xhci,tablet \
-s 31,lpc \
= -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
-l com1,stdio = \
vm1

it won't boot : BdsDxe: failed to load Boot0001 "U= EFI BHYVE SATA DISK BHYVE-EE1E-05D9-14BB" from PciRoot(0x0)/Pci(0x1,0x= 0)/Sata(0x0,0xFFFF,0x0): Not Found.

SUMMARY : It seems there is some= serious bug in every version of freebsd,13 release,13 stable and 14 curren= t,that does not allow to boot any kind of physically installed OS if it is = passed through any kind of device. I've already opened a bug report and= no one seems to work on it. Would someone take care of these bugs ? thanks= .

--
Mario.
--00000000000040795f05d8b36591-- From nobody Thu Feb 24 00:14:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 47F9219E4538 for ; Thu, 24 Feb 2022 00:14:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K3th93LYNz3ClS for ; Thu, 24 Feb 2022 00:14:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x136.google.com with SMTP id c14so498225ilm.4 for ; Wed, 23 Feb 2022 16:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=8/r9vfFjkC43YjbKOUQkM+8r7LO54E3WPhTlBV8Ob+Q=; b=IkqRzcUoagWKPhCFuxlDhL4458g4l7aJNr+gsxqOO3Sb9S8iM1B+zNWFR9XKaoAO7W 6ihDUGdbIYZKusjJF2DRt24MW65qke0DuTuPsoblUrLWfeDO77ULCvsjFk60KsQv7czB wSKUtDQpDqPoW3dttOCjcNZMfSpxU6ArhXXpptpj05j98LNAU9V9qW3SGVcg7Eb7tY3Q IRDSip1UXDUyKoc0CL9haidPd6Zv3++IZXpOcPYwNVXdzy4Ac0w/OnMMhv7biqzglQ58 JeZOPcQxCgxAmfSbvX5uLgaFAezQOhMF+/qMIm8+FNWnF0/8RoOyKxvvXa39baEeaNF+ dJtg== 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 :mime-version:content-disposition; bh=8/r9vfFjkC43YjbKOUQkM+8r7LO54E3WPhTlBV8Ob+Q=; b=62WTjHnwZlX+hvi/X+nl7pEgl01XZ3DajvAUucnKplTjbXRppbYilY2QWCjKhe/jW6 JKrk9uzCuX9dSWo7sSTjCo25JBHBWRRdVnM3MKjKITaxQS4/VrHHtZ6GwkSz2xxhFhUz IkR8N3n49+B3GhcbYMvS3L+oEq5fYQDRGIWFsPYKxvWxxfbY6e9916yQE3q7wZ5pRqLc U/ICKHXj4nti1YskVi35STzTKhAdfIyZ55PKqLwKN24HbKbdrPO+4r6/04PFsGwz19Wv e/m6RciLDtRJguz99DrEkm//paFU+tIiYwHSqka0UE4wP2pGkEWRijSsxsxG8fwQ0J0z /XcQ== X-Gm-Message-State: AOAM530NKqtR5nhriExcLOr9gAjw4t2YN7f/iRS4ksgAj5kKnxFnyjH0 YcniwxqzX29OOqZP2xm5Xrsp1luZaCU= X-Google-Smtp-Source: ABdhPJxosPNYY77OcaC21Q53Hot9QC2bE2+nOyVdnwqSx4dKxFl0ITpXb+wFP51NLDNfA6bwRg6HeQ== X-Received: by 2002:a92:c261:0:b0:2c2:8b62:f6f4 with SMTP id h1-20020a92c261000000b002c28b62f6f4mr120005ild.108.1645661682887; Wed, 23 Feb 2022 16:14:42 -0800 (PST) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id j14sm749311ilc.62.2022.02.23.16.14.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 16:14:41 -0800 (PST) Date: Wed, 23 Feb 2022 19:14:39 -0500 From: Mark Johnston To: freebsd-hackers@freebsd.org Cc: domagoj.stolfa@gmail.com Subject: patches for CTFv3 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4K3th93LYNz3ClS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IkqRzcUo; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I've finished a first draft of some patches which extend the CTF (compact C type format) definitions, making them a bit less compact but increasing the limit on the number of permitted C types, as an amd64 GENERIC kernel has been close to the limit for a while now, causing frustrating dtrace failures. The new format is CTFv3, compatible at least in principle with binutils libctf. The patches add support for v3 to various CTF producers and consumers. The one which adds v3 definitions is https://reviews.freebsd.org/D34360 and the rest can be viewed under the "stack" tab. In particular, the limit on the number of representable types grows from 2^{15} to 2^{31} - 1, hopefully enough to last for a while. The kernel's CTF section grows somewhat. The (zlib-compressed) on-disk size for an amd64 kernel increases from 1.02MB to 1.08MB, and the uncompressed size increases from 2.50MB to 3.31MB. In other words, the impact is hopefully unnoticeable if one's not using dtrace, and otherwise I believe the increase in memory usage isn't prohibitive. With the patches, libctf and ctfdump handle both v2 and v3. ctfconvert is changed to always emit v3, and ctfmerge can merge v2 and v3 containers, always creating a v3 container. The kernel works with v2 or v3, i.e., there should be no problem using dtrace with an updated kernel and an old version of the CTF toolchain. If it really becomes useful to be able to request v2 output from ctfconvert and ctfmerge, it could be added, but I don't have a reason to implement it yet. Any feedback on the changes would be appreciated. Thanks, -Mark From nobody Fri Feb 25 14:23:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DF94D19E8777 for ; Fri, 25 Feb 2022 14:23:41 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K4sT86PX0z3tKF for ; Fri, 25 Feb 2022 14:23:40 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 25 Feb 2022 15:23:32 +0100 id 00DD6040.6218E664.00006578 Date: Fri, 25 Feb 2022 15:23:21 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: Rotating (efi) framebuffer console Message-ID: <20220225152321.4b339ec3@zeta.dino.sk> In-Reply-To: References: X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K4sT86PX0z3tKF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-3.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.975]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 5 Feb 2022 20:50:41 +0000 Stefan Grundmann wrote: > Hi, > > the screen of my brand new GPD Pocket 3 (tiger lake) laptop is in > portrait mode and reports a resolution of 1200x1920. I have another > older device with the same issue (a GPD Pocket 1). > In 2019 johalun@FreeBSD.org wrote on the freebsd-current about an > Lenovo Ideapad with a portrait mode screen and raised the question if > it would be good to support rotation of the vt_fb console. > Hi, I just acquired a GPD Micro PC, which shows exactly the same issue, albeit with different resolution. Your patch comes just in time for me... > Since the new GPD Pocket 3 is a nice device and rather well supported > in FreeBSD, i thought "how hard can it be" (OpenBSD has fb console > rotation and Linux has fbcon=rotate..) > > The patch (against stable/13, at the end of this mail) works for > me(tm): Whenever the width of a frambuffer device is smaller than > it's height; a portrait mode screen is assumed and the screen is > rotated by 90 degrees clockwise. > After patching fresh stable/13 sources, doing full rebuild and reinstall, this works for me nicely. Thanks for the patch. > I write this here for two reasons: > > 1. give others with similar hardware a chance to avoid the > neck-craning issue > Thanks, this helps. I could use this device now in console mode with no issue. Just one small thing remains - loader output is still rotated. I have no idea how could this issue be solved properly, possibly similar patch for screen driver in loader (I did not look in the sources in stand directory). > 2. offer to work on something that can be reviewed and merged e. g. > - implement the rest of the transformations (180 degrees, 270 > degrees) > - boot-time variable to select behavior > - vt(4) man page update > > For 2. i would like to know if vt_fb.c is even the right place to do > this. The framebuffer code in the loader could also get this feature. > [ snip ] I'd like to ask whether you have some more hacks - for now, pressing power button while running FreeBSD does nothing, some driver/handler is missing, possibly for other parts of hardware as well, but overall, device runs nicely under FreeBSD. I am going to try X here, but this requires some work to build :) Once again, thanks for the patch. Regards, Milan From nobody Wed Mar 2 01:49:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B634019FBCC9 for ; Wed, 2 Mar 2022 01:49:35 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7cVk3jD9z4gcV for ; Wed, 2 Mar 2022 01:49:34 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 2221nQpX089928 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Mar 2022 17:49:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 2221nPgV089926; Tue, 1 Mar 2022 17:49:25 -0800 (PST) (envelope-from jmg) Date: Tue, 1 Mar 2022 17:49:25 -0800 From: John-Mark Gurney To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive Message-ID: <20220302014925.GA88842@funkthat.com> Mail-Followup-To: Wojciech Puchar , freebsd-hackers@freebsd.org References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 01 Mar 2022 17:49:26 -0800 (PST) X-Rspamd-Queue-Id: 4K7cVk3jD9z4gcV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 208.87.223.18) smtp.mailfrom=jmg@gold.funkthat.com X-Spamd-Result: default: False [-0.11 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.64)[0.642]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:32354, ipnet:208.87.216.0/21, country:US]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com] X-ThisMailContainsUnwantedMimeParts: N Wojciech Puchar wrote this message on Mon, Feb 21, 2022 at 11:44 +0100: > I wrote software for microcontroller with USB device port that presents > itself as USB CD and includes ISO9660 image. Is this an ST micro? I have a couple outstanding issues where ST hasn't implemented the USB spec properly in their reference code causing issues w/ FreeBSD... This isn't in the CD code, but other reference device classes... > It works under windows - "CD" is detected and files readable > it works under MacOS - same > It mostly works under FreeBSD. > > > FreeBSD detects it properly > > > ugen1.5: at usbus1 > umass0 on uhub5 > umass0: on > usbus1 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:3:0: Attached to scbus3 > cd1 at umass-sim0 bus 0 scbus3 target 0 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: Serial Number 220123456789 > cd1: 1.000MB/s transfers > cd1: 16MB (8192 2048 byte sectors) > cd1: quirks=0x10<10_BYTE_ONLY> > > > > i can read sectors by dd, by single (bs=2k) or multiple. > Other communication (vendor specific SCSI commands - used to > configure/control the device with our software) - works properly. > > > If i make an image (first 34 sectors, device presents itself as 16MB > to prevent problems with some OSes but everything later are zeros) - it is > good - did cmp with original image file. > > i can do mdconfig, mount_cd9660 on this file and everything is fine. > > > BUT > > mount_cd9660 /dev/cd1 /mnt > > results in: > > mount_cd9660: /dev/cd1: Invalid argument > > There is no kernel messages. > > How could i find out what is exactly a problem? run usbdump to see what the commands are, and see if there is anything that could be causing issues. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From eugen@grosbein.net Wed Mar 2 04:23:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B8D2619F16BC for ; Wed, 2 Mar 2022 04:23:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7gws0gvtz3Dw0 for ; Wed, 2 Mar 2022 04:23:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 2224Nl1O014675 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Mar 2022 04:23:48 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] ([10.58.0.11]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 2224NL2N059184 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Mar 2022 11:23:46 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: problem with USB-CD drive To: Wojciech Puchar , freebsd-hackers@freebsd.org References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> From: Eugene Grosbein Message-ID: <21050393-470a-8539-1324-3482d64c4870@grosbein.net> Date: Wed, 2 Mar 2022 11:23:11 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4K7gws0gvtz3Dw0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.92 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.954]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.13)[0.132]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 21.02.2022 17:44, Wojciech Puchar wrote: > i can read sectors by dd, by single (bs=2k) or multiple. > Other communication (vendor specific SCSI commands - used to configure/control the device with our software) - works properly. > If i make an image (first 34 sectors, device presents itself as 16MB > to prevent problems with some OSes but everything later are zeros) - it is good - did cmp with original image file. > > i can do mdconfig, mount_cd9660 on this file and everything is fine. > > > BUT > > mount_cd9660 /dev/cd1 /mnt > > results in: > > mount_cd9660: /dev/cd1: Invalid argument > > There is no kernel messages. > > How could i find out what is exactly a problem? It looks like the device or driver do not like size of reading request, f.e. short read. It should be possible to verify that using several ways: 1) run "ktrace -i mount_cd9660 ..." then study ouput of kdump; 2) enable debug logs at GEOM level, use sysctl kern.geom.debugflags=255 (beware of large amount of logs) then run mount_cd9660 3) use gcache(8) that is capable of limiting minimum request size by caching "extra" data, but try using only single gcache(8) instance per system because of known instability in the gcache code when you create multiple geom_cache's. From nobody Wed Mar 2 08:59:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B3C619FFAED for ; Wed, 2 Mar 2022 08:59:17 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7p2X2DPnz4ST2 for ; Wed, 2 Mar 2022 08:59:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2228x6Qr072488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Mar 2022 09:59:07 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1646211547; bh=OPKCV9p7DtYc+ASiuCIAmg5CrGci1ky3ipvie41HqZ0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jHfF9WsJNg8Eb0xfF3B0yFaHzRtfCiKTbwAqry5sorcnKRwak3t/yC1AnXvR+knM7 axVPKUSLcf3Z6Z4BPS63W/ujPTvFYH2FzxobQDRVB4gDmxtFzz6sXVhX5szigY+Bcq SNlp1pRBNkQ/wIySNmTrDGNKy6/rWA+/iNDJPhVE= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2228x6Pu021051; Wed, 2 Mar 2022 09:59:06 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2228x5Y2021048; Wed, 2 Mar 2022 09:59:06 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 2 Mar 2022 09:59:05 +0100 (CET) From: Wojciech Puchar To: John-Mark Gurney cc: freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive In-Reply-To: <20220302014925.GA88842@funkthat.com> Message-ID: <2de67fd5-40d9-55fc-18ea-671aa096bab5@puchar.net> References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <20220302014925.GA88842@funkthat.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4K7p2X2DPnz4ST2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=jHfF9WsJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Wojciech Puchar wrote this message on Mon, Feb 21, 2022 at 11:44 +0100: >> I wrote software for microcontroller with USB device port that presents >> itself as USB CD and includes ISO9660 image. > > Is this an ST micro? I have a couple outstanding issues where ST hasn't No it's PIC32. Nevertheless it does not matter - i wrote everything myself from scratch using only PIC32MX and USB documentation. I am almost sure i didn't implement some of SCSI commands properly so FreeBSD doesn't properly behave, while windows/MacOS doesn't care. The question is how to debug it on host side - what exactly is wrong. From nobody Wed Mar 2 09:07:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 687861A01ECD for ; Wed, 2 Mar 2022 09:07:52 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7pDR3Vwhz4TsF for ; Wed, 2 Mar 2022 09:07:51 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 22297mDX082238 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Mar 2022 10:07:49 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1646212069; bh=WlSU4YzzcAwlUVuw1QgdP3ASGIPE0a2k2ue9cYD4ETU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sGQvIGlTmv7ByPxbXtXEiKjVo7MDxl8jmNcMvtlsTgCk7xVtqMnpth6s//Ht13D6N ns4OzW2KcDfvTcjTj+1otB4swL9T5nKp+w+H1Xa8/Uu/VDjFX/ScWXuf0FXk4+xznw 0wgfa8/nc8O8bwRzDSVoGvuzpTaUMP2yibDXCIPU= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 22297mtG021090; Wed, 2 Mar 2022 10:07:48 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 22297lkr021087; Wed, 2 Mar 2022 10:07:48 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 2 Mar 2022 10:07:47 +0100 (CET) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive In-Reply-To: <21050393-470a-8539-1324-3482d64c4870@grosbein.net> Message-ID: <50bcd532-934a-31f0-855e-d643417dd89@puchar.net> References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <21050393-470a-8539-1324-3482d64c4870@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4K7pDR3Vwhz4TsF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=sGQvIGlT; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > It looks like the device or driver do not like size of reading request, > f.e. short read. It should be possible to verify that using several ways: > > 1) run "ktrace -i mount_cd9660 ..." then study ouput of kdump; 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } 847 mount_cd9660 RET lstat 0 847 mount_cd9660 CALL stat(0x7fffffffe440,0x7fffffffe3a0) 847 mount_cd9660 NAMI "/mnt" 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } 847 mount_cd9660 RET stat 0 847 mount_cd9660 CALL openat(AT_FDCWD,0x7fffffffee6d,0) 847 mount_cd9660 NAMI "/dev/cd1" 847 mount_cd9660 RET openat 3 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCHEADER,0x7fffffffeb88) 847 mount_cd9660 RET ioctl 0 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCENTRYS,0x7fffffffeb60) 847 mount_cd9660 RET ioctl 0 847 mount_cd9660 CALL close(0x3) 847 mount_cd9660 RET close 0 847 mount_cd9660 CALL mmap(0,0x200000,0x3,0x1002,0xffffffff,0) 847 mount_cd9660 RET mmap 34376515584/0x801000000 847 mount_cd9660 CALL nmount(0x801015080,0x8,0x1) 847 mount_cd9660 NAMI "/mnt" 847 mount_cd9660 NAMI "/mnt" 847 mount_cd9660 NAMI "/dev/cd1" 847 mount_cd9660 RET nmount -1 errno 22 Invalid argument could you please help me to understand this? is it something about CDIOREADTOCHEADER and CDIOREADTOCENTRYS returning not what it should return? > 2) enable debug logs at GEOM level, use sysctl kern.geom.debugflags=255 > (beware of large amount of logs) then run mount_cd9660 > 3) use gcache(8) that is capable of limiting minimum request size by caching "extra" data, > but try using only single gcache(8) instance per system because of known instability in the gcache code > when you create multiple geom_cache's. > > did gcache with 2kB blocks. works fine. Seems like a problem is here - some requests are not handled. now i tested reading it with dd with 2,4,8,16 and 32kB blocks. seems fine. trying to read with blocks like 1k, 512 doesn't work but it is i think normal - CDs have 2kB blocks. real CD drive behaves the same way. From nobody Wed Mar 2 15:12:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3DF9B19FBE3B for ; Wed, 2 Mar 2022 15:13:07 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7yKr3S98z3BxL for ; Wed, 2 Mar 2022 15:13:04 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: by mail-vs1-xe32.google.com with SMTP id g21so2191079vsp.6 for ; Wed, 02 Mar 2022 07:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=3s9grxDflIC9MTtWqixjXDcoHeLBsWQW3nYI1Xb+lSc=; b=jJB5hAwq1+3CC9EyEx7jMOiaM6TXR7APFcxThvZzaV64gCFzpXyDmH0CAgD1LhM4mE +GHjLQu+6ioN6g6ZR5lVzM4IGEnoJ5VybsQPP8Vov0Ph6wTkb5pyy3WoA/r4EQEz0Qn2 K3WQKsACm00+tpYxRCrqEAu8lDNVIFx+eoZ9F1CGXXoP+A/GWS19dUT5rc1NQvweI0Uh 1wTzR63/Ox8iif+fp9uNXL9Sb14MNbHiVddqNOsb8pu9qozDi09zTjpLjRnZZFRriBuL SbosVcVzDNSjA2MDKCCrRBdxDr4NnoxKEcJs+h9t74m5FipmLig4UAaQRa7swPNSVJBf uDgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3s9grxDflIC9MTtWqixjXDcoHeLBsWQW3nYI1Xb+lSc=; b=Ic1NO8AMv1kZ2wEDUGvvgadOMJhmg1kGj1XkX8JZyTDBWV4U7qEOoxpfmL7nPUs3JV Df9GTOZQMS3Wjv0FvJUn9mgG7Rm3Qq9B8sBJ5C2lwv4Auz3KO/0mYACEqzN5J6IQ0TFU gp43JaEVkeSIgADuTM8sziFpizmHIRc6MXtBVO/SAH4YouHgDCuqe3uMLQQ5fvyXKinG R6ee4WfZ/9klkcnK/oZ4t20UQ+xXYDQeRQLNAYStclODg7eAlCZidY/xGWHNgyBxQ7+L EGyTg6lYskiIjUxz2DHB/KxeuftFFnBWNiBKZlci5hNPj4P2b9yytcTkYnrZDIurGPCX 9/Qg== X-Gm-Message-State: AOAM530IYaZ5gNTcS/IC3S1LmuFiXmjWbXHlAWzcIP631qME0r8CMlrl CyoSX9ONLfw8145FtDDwPLJrpkrK51ACYoE7vJUfYIqu X-Google-Smtp-Source: ABdhPJxBjyvUOKFKdlW2wWtK1F5FZ6mMRgGTs/hB/0rHGNnFWag2uu3BfayEbYxVe5fLVkidI8e3b+UiEpojGPrv4No= X-Received: by 2002:a05:6102:34f4:b0:31b:9861:7cfa with SMTP id bi20-20020a05610234f400b0031b98617cfamr12202652vsb.64.1646233983337; Wed, 02 Mar 2022 07:13:03 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Arka Sharma Date: Wed, 2 Mar 2022 20:42:52 +0530 Message-ID: Subject: Difference in shared object dependency To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cb494105d93db7dc" X-Rspamd-Queue-Id: 4K7yKr3S98z3BxL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jJB5hAwq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of arkasw1988@gmail.com designates 2607:f8b0:4864:20::e32 as permitted sender) smtp.mailfrom=arkasw1988@gmail.com X-Spamd-Result: default: False [-2.84 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; 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-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.16)[0.161]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e32:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000cb494105d93db7dc Content-Type: text/plain; charset="UTF-8" Hi All, I am using 'ldd -a' to list the shared object dependencies of executable as well as using 'procstat -v' to dump the mapping which also lists the mapping of shared objects in process address space. I have noticed in some cases 'procstat' lists some additional .so files (not counting the ld-elf.so). Can somebody please tell me what's going on here ? Regards, Arka --000000000000cb494105d93db7dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am using 'ldd -a' to = list the shared object dependencies of executable as well as using 'pro= cstat -v' to dump the mapping which also lists the mapping of shared ob= jects in process address space. I have noticed in some cases 'procstat&= #39; lists some additional .so files (not counting the ld-elf.so). Can some= body please tell me what's going on here ?

Reg= ards,
Arka


--000000000000cb494105d93db7dc-- From nobody Wed Mar 2 15:26:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E09C319FEA09 for ; Wed, 2 Mar 2022 15:26:11 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7ycz1646z3FS0 for ; Wed, 2 Mar 2022 15:26:11 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qt1-x830.google.com with SMTP id t28so1887998qtc.7 for ; Wed, 02 Mar 2022 07:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=38Qxvl1eyMN5LVWJQfrCUY0bqKBBW9OD6J5lGya3tnc=; b=f20eJ4DAZOMpEaaebACjPZzerygkUK5YHgngPyv6otx9I0u+O3VtHVt0x9O2JiTjHa AtB0J1JlO91qJiKFPpiH2Do10pQAYtI1eew/p94vtPPtvap3U16hvkXeL//K1PS+vTTK ChnQjOdbz0tfCj80BzkGa0+0ffR9tlrC7RuF9OMJG6lXI0fX0PmooXnKH+tgYR5JT8NV YSh/gSgk+5ISfWpSZr/e+0/qZyG9A+gXFaTu6Btm7XpLHjFLxpOFqnpkzAMU1MOu6qzP 3dlcb8TRYkQmFbnFoj/nRtOJvkFtpdTjTF9tIqqEzy89SDsx1fee/jvSEvck/WCZg4Dg cqXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=38Qxvl1eyMN5LVWJQfrCUY0bqKBBW9OD6J5lGya3tnc=; b=HnT4COlUAufNBqBmVZzxc3i3J2iqWH96RyVOcU+GuDSJRob5xBpVMHiGH0Vfa2tWiy zAnFrmBv9J3nq272mR3n3GrJs6q8O1KhtcjJ71D8WEbhdFFNbLQ9x2oUdf+UwGMGYLGg aL3qmBFs/VV9y7gpA5gT9KQ6UgyYKS8uHgAUTVwg9pOyCuN4NsYt23385SDuwg/KFTCM 17E9HAOTCpladLPZT2jqijVPFh0UI6Rk/YLpRseNuo7C8XA2tS+wwLHl1W1QKC9MT7gB FT00pIfu0FDoqQVtUbL7mSaAsxhnZ+89BtliN9iGqb9SoCBZSoeIH0ImFNWG0karZL2T 7yKg== X-Gm-Message-State: AOAM533VeMhBAyDJI0DsNVVjO+0rjA70IQiMT06FSlFlX2sGeQPCmd3E OSEOKjrgulwlHnCYtYMd5s0yoMUfv/27rg== X-Google-Smtp-Source: ABdhPJz582VmYMt1BTaj8cO8yBZXPKHri8nhhKVlYxkpWepGQ5sXaIzy7QewjGMWP6wJ6rXCcRvnmw== X-Received: by 2002:a05:622a:44b:b0:2df:f837:a94a with SMTP id o11-20020a05622a044b00b002dff837a94amr15211094qtx.423.1646234770565; Wed, 02 Mar 2022 07:26:10 -0800 (PST) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id i3-20020a05620a074300b006630cbe7ec0sm4526159qki.90.2022.03.02.07.26.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Mar 2022 07:26:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: problem with USB-CD drive From: Bakul Shah In-Reply-To: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> Date: Wed, 2 Mar 2022 07:26:08 -0800 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> To: Wojciech Puchar X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 4K7ycz1646z3FS0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=f20eJ4DA; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[iitbombay.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Feb 21, 2022, at 2:44 AM, Wojciech Puchar wrote: >=20 > I wrote software for microcontroller with USB device port that = presents itself as USB CD and includes ISO9660 image. >=20 > It works under windows - "CD" is detected and files readable > it works under MacOS - same > It mostly works under FreeBSD. > There is no kernel messages. ... >=20 > How could i find out what is exactly a problem? >=20 Would usbdump(8) be of any help?= From nobody Wed Mar 2 15:32:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F35F719D815D for ; Wed, 2 Mar 2022 15:32:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7ym82B8sz3H4W for ; Wed, 2 Mar 2022 15:32:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id 10so927462uar.9 for ; Wed, 02 Mar 2022 07:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nKtjPxkDlxu8kkAnsNYNacooEhf474GyIJhbqZj3MyY=; b=vvI2ooKMReCcjzUKohk/VBJyf4VShv1BrwUo8ZMKH9tGLFQppiMO4gBYg4y+EQTM4v INJHXYBMJT2IX5at4EhLh3VKY3Usw7/NE/omrV1I7HTQvRc5N35svI5f/c+DQflxf9yQ BUXGmbKZmK/f7szHVw0UzJAMG1cq3kzDKq9w1F3uQZ3JPHkMikm78ADEkoyg1BTbvh2a DhxFVSSPcfVxYKnuuhuJZvV1TWv6XcEFyCDavqw3t8WoYqbVREq/6NDtXZVguw99WZB3 dQD+186TqWhe4eOGPxNLJIgwGrPnOpWNtlRK0M1brqLW9zHiiDWMFDAyPSVb7xc+gG85 hkWg== 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=nKtjPxkDlxu8kkAnsNYNacooEhf474GyIJhbqZj3MyY=; b=EpCOTydq5YYtCmMbsns9fgFFP24oTndDF/cwwtfALY8P/8hor1YD2fA5kyk10ELDWy b+4fKzmSvmYnOiYZqqQed0G1Nq2xi5KqokcqvNV3pshHssfGl+s1nC8q+oAnpXfV8FHa PUYLfrKK82GAySsz0aggpr1G87ni71f/hzkM3yFm7vljhDsRN0a9+pRKxfz2O9Q18ZXg Q+jAGYxZTeU0Sz2NOwQGZ+PTM9DH5S7uUBvjDZYJdqOTIHuyAWqU9Rp1d1B3nXFhQbaR T8+S40eIGn1OAh/tuZR9/ZKBgUFSy8iONNCKHI91l8u5l0q8QvsmAZ76QQTkywtIys1V /6zA== X-Gm-Message-State: AOAM531LoJoOIGXtflSUL54rk9tSx1+ZIIlOSW6v3klST3VaKpBOf3rU uaFIHEykTVuVdGikRvRmhp/cvTJxWTEgvoYf1YgfwA== X-Google-Smtp-Source: ABdhPJzGcxJLMwF1j/2N//htDV+LCN3lojEOIJhEoBFCYOVRPfJzJLvROjbLVrLEoc8NGdePweJjfxXc5MIfti7ZikQ= X-Received: by 2002:ab0:13ad:0:b0:340:22f4:574d with SMTP id m42-20020ab013ad000000b0034022f4574dmr12663747uae.102.1646235143562; Wed, 02 Mar 2022 07:32:23 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 2 Mar 2022 08:32:12 -0700 Message-ID: Subject: Re: Difference in shared object dependency To: Arka Sharma Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f2f92505d93dfcaa" X-Rspamd-Queue-Id: 4K7ym82B8sz3H4W X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=vvI2ooKM; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::934) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::934:from]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000f2f92505d93dfcaa Content-Type: text/plain; charset="UTF-8" On Wed, Mar 2, 2022 at 8:14 AM Arka Sharma wrote: > I am using 'ldd -a' to list the shared object dependencies of executable > as well as using 'procstat -v' to dump the mapping which also lists the > mapping of shared objects in process address space. I have noticed in some > cases 'procstat' lists some additional .so files (not counting the > ld-elf.so). Can somebody please tell me what's going on here ? > Are they repeats, but with different versions, of what ldd -a shows? If so, then you have a partially upgraded system and will likely be in a world of pain until you upgrade completely. Alternatively, you might be seeing a program that uses dlopen to map in other modules which is pulling in these libraries. In that case, it's normal. Warner --000000000000f2f92505d93dfcaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000f2f92505d93dfcaa-- From eugen@grosbein.net Wed Mar 2 16:44:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D2F8319F0A80 for ; Wed, 2 Mar 2022 16:45:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K80NZ6qX2z4QlM for ; Wed, 2 Mar 2022 16:45:34 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 222GjUhb023532 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Mar 2022 16:45:31 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] ([10.58.0.11]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 222Gj496063927 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Mar 2022 23:45:29 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: problem with USB-CD drive To: Wojciech Puchar References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <21050393-470a-8539-1324-3482d64c4870@grosbein.net> <50bcd532-934a-31f0-855e-d643417dd89@puchar.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <2a3e46b6-3f93-bd7f-f6b2-bac2e3c6a1b2@grosbein.net> Date: Wed, 2 Mar 2022 23:44:59 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <50bcd532-934a-31f0-855e-d643417dd89@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4K80NZ6qX2z4QlM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 02.03.2022 16:07, Wojciech Puchar wrote: >> It looks like the device or driver do not like size of reading request, >> f.e. short read. It should be possible to verify that using several ways: >> 1) run "ktrace -i mount_cd9660 ..." then study ouput of kdump; > 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 > 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } > 847 mount_cd9660 RET lstat 0 > 847 mount_cd9660 CALL stat(0x7fffffffe440,0x7fffffffe3a0) > 847 mount_cd9660 NAMI "/mnt" > 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 > 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } > 847 mount_cd9660 RET stat 0 > 847 mount_cd9660 CALL openat(AT_FDCWD,0x7fffffffee6d,0) > 847 mount_cd9660 NAMI "/dev/cd1" > 847 mount_cd9660 RET openat 3 > 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCHEADER,0x7fffffffeb88) > 847 mount_cd9660 RET ioctl 0 > 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCENTRYS,0x7fffffffeb60) > 847 mount_cd9660 RET ioctl 0 > 847 mount_cd9660 CALL close(0x3) > 847 mount_cd9660 RET close 0 > 847 mount_cd9660 CALL mmap(0,0x200000,0x3,0x1002,0xffffffff,0) > 847 mount_cd9660 RET mmap 34376515584/0x801000000 > 847 mount_cd9660 CALL nmount(0x801015080,0x8,0x1) > 847 mount_cd9660 NAMI "/mnt" > 847 mount_cd9660 NAMI "/mnt" > 847 mount_cd9660 NAMI "/dev/cd1" > 847 mount_cd9660 RET nmount -1 errno 22 Invalid argument > could you please help me to understand this? > is it something about CDIOREADTOCHEADER and CDIOREADTOCENTRYS returning not what it should return? No. We see here that at user level the sequence breaks on nmount system call. There is no more details but we may assume that nmount leads to short reads inside the kernel land (and breaks). >> 2) enable debug logs at GEOM level, use sysctl kern.geom.debugflags=255 >> (beware of large amount of logs) then run mount_cd9660 >> 3) use gcache(8) that is capable of limiting minimum request size by caching "extra" data, >> but try using only single gcache(8) instance per system because of known instability in the gcache code >> when you create multiple geom_cache's. >> > did gcache with 2kB blocks. works fine. Seems like a problem is here - some requests are not handled. > > now i tested reading it with dd with 2,4,8,16 and 32kB blocks. seems fine. > > trying to read with blocks like 1k, 512 doesn't work but it is i think normal - CDs have 2kB blocks. > > real CD drive behaves the same way. It's time to enable geom logs to look at size of read requests going to low level driver. From eugen@grosbein.net Wed Mar 2 16:56:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4903C19F2C97 for ; Wed, 2 Mar 2022 16:56:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K80dM4FHGz4SdD for ; Wed, 2 Mar 2022 16:56:39 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 222GubZO023659 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Mar 2022 16:56:37 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] ([10.58.0.11]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 222GuBUS064060 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 2 Mar 2022 23:56:36 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: problem with USB-CD drive To: Wojciech Puchar , John-Mark Gurney References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <20220302014925.GA88842@funkthat.com> <2de67fd5-40d9-55fc-18ea-671aa096bab5@puchar.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Wed, 2 Mar 2022 23:56:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <2de67fd5-40d9-55fc-18ea-671aa096bab5@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4K80dM4FHGz4SdD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.08 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 02.03.2022 15:59, Wojciech Puchar wrote: >> Wojciech Puchar wrote this message on Mon, Feb 21, 2022 at 11:44 +0100: >>> I wrote software for microcontroller with USB device port that presents >>> itself as USB CD and includes ISO9660 image. >> >> Is this an ST micro? I have a couple outstanding issues where ST hasn't > > No it's PIC32. Nevertheless it does not matter - i wrote everything myself from scratch using only PIC32MX and USB documentation. > > I am almost sure i didn't implement some of SCSI commands properly so FreeBSD doesn't properly behave, while windows/MacOS doesn't care. > > The question is how to debug it on host side - what exactly is wrong. Use sysctl kern.cam.dflags to enable CAM-level debugging. Debugging flags are documented at in the file sys/cam/cam_debug.h From nobody Thu Mar 3 21:02:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8375B19F2FDE for ; Thu, 3 Mar 2022 21:03:11 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K8k3L2GbKz3QZK for ; Thu, 3 Mar 2022 21:03:09 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 223L2xQq012485 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Mar 2022 22:02:59 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1646341380; bh=4U+IW3rF6f6iJt2a/fIGNs1GLQzV7c76t5IKfdoHzzQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=A+yr3rvb/CEb+Uiasj8KARGYse94BptU1DjZPU6K0HiJFPLs2cY+JyVQRwdxtDOjv R5UDNJ2cacZMC2AeBBEskTqXErLpMBKZfNoA+cI0vVcbm9APU3IV5PeTybWzWkWiRJ dFd7UyO5UWVymgkiyoOJUkPR/dF6wq2q9nVhXHHs= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 223L2xdw027025; Thu, 3 Mar 2022 22:02:59 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 223L2www027022; Thu, 3 Mar 2022 22:02:59 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 3 Mar 2022 22:02:58 +0100 (CET) From: Wojciech Puchar To: Bakul Shah cc: freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive In-Reply-To: Message-ID: <652438a5-cd24-472d-f59f-5d2a9eed175@puchar.net> References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4K8k3L2GbKz3QZK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=A+yr3rvb; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N no. it's a problem on SCSI side of protocol On Wed, 2 Mar 2022, Bakul Shah wrote: > On Feb 21, 2022, at 2:44 AM, Wojciech Puchar wrote: >> >> I wrote software for microcontroller with USB device port that presents itself as USB CD and includes ISO9660 image. >> >> It works under windows - "CD" is detected and files readable >> it works under MacOS - same >> It mostly works under FreeBSD. >> There is no kernel messages. > ... >> >> How could i find out what is exactly a problem? >> > > Would usbdump(8) be of any help? > > From nobody Thu Mar 3 21:03:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 299F319F3328 for ; Thu, 3 Mar 2022 21:03:23 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K8k3Z4Qwrz3Qd8 for ; Thu, 3 Mar 2022 21:03:22 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 223L3KRu012553 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Mar 2022 22:03:21 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1646341401; bh=TkeeVb5ozvoJD+IBTVGFeuy7nJ6aNbVF4W2XlBqGQrQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=h8Zl+FnbDvNSDLSrXSI1TSUeM8YMqJCS6figXustnvmYyCyhJGiOzydzTq5VDNtEG MQpSI67mbxtdBpKFAQijSpm+epn/Y8WsnB4Oqw3FU7ON+VKWkRLrZgU6crN7WQwJQv IioYZNBwC4B37JLr3Ul/kCSqGWSidVefiFbV3ShM= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 223L3KLQ027033; Thu, 3 Mar 2022 22:03:20 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 223L3JgJ027030; Thu, 3 Mar 2022 22:03:20 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 3 Mar 2022 22:03:19 +0100 (CET) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive In-Reply-To: <2a3e46b6-3f93-bd7f-f6b2-bac2e3c6a1b2@grosbein.net> Message-ID: References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <21050393-470a-8539-1324-3482d64c4870@grosbein.net> <50bcd532-934a-31f0-855e-d643417dd89@puchar.net> <2a3e46b6-3f93-bd7f-f6b2-bac2e3c6a1b2@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4K8k3Z4Qwrz3Qd8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=h8Zl+Fnb; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N will do next week On Wed, 2 Mar 2022, Eugene Grosbein wrote: > 02.03.2022 16:07, Wojciech Puchar wrote: > >>> It looks like the device or driver do not like size of reading request, >>> f.e. short read. It should be possible to verify that using several ways: >>> 1) run "ktrace -i mount_cd9660 ..." then study ouput of kdump; >> 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 >> 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } >> 847 mount_cd9660 RET lstat 0 >> 847 mount_cd9660 CALL stat(0x7fffffffe440,0x7fffffffe3a0) >> 847 mount_cd9660 NAMI "/mnt" >> 847 mount_cd9660 STRU struct stat {dev=156, ino=261120, mode=040755, nlink=2, uid=0, gid=0, rdev=2085752, atime=1581328619, mtime=15 >> 81328630.081523000, ctime=1581328648.345917000, birthtime=315532800, size=1024, blksize=32768, blocks=8, flags=0x0 } >> 847 mount_cd9660 RET stat 0 >> 847 mount_cd9660 CALL openat(AT_FDCWD,0x7fffffffee6d,0) >> 847 mount_cd9660 NAMI "/dev/cd1" >> 847 mount_cd9660 RET openat 3 >> 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCHEADER,0x7fffffffeb88) >> 847 mount_cd9660 RET ioctl 0 >> 847 mount_cd9660 CALL ioctl(0x3,CDIOREADTOCENTRYS,0x7fffffffeb60) >> 847 mount_cd9660 RET ioctl 0 >> 847 mount_cd9660 CALL close(0x3) >> 847 mount_cd9660 RET close 0 >> 847 mount_cd9660 CALL mmap(0,0x200000,0x3,0x1002,0xffffffff,0) >> 847 mount_cd9660 RET mmap 34376515584/0x801000000 >> 847 mount_cd9660 CALL nmount(0x801015080,0x8,0x1) >> 847 mount_cd9660 NAMI "/mnt" >> 847 mount_cd9660 NAMI "/mnt" >> 847 mount_cd9660 NAMI "/dev/cd1" >> 847 mount_cd9660 RET nmount -1 errno 22 Invalid argument >> could you please help me to understand this? >> is it something about CDIOREADTOCHEADER and CDIOREADTOCENTRYS returning not what it should return? > > No. We see here that at user level the sequence breaks on nmount system call. > There is no more details but we may assume that nmount leads to short reads inside the kernel land (and breaks). > >>> 2) enable debug logs at GEOM level, use sysctl kern.geom.debugflags=255 >>> (beware of large amount of logs) then run mount_cd9660 >>> 3) use gcache(8) that is capable of limiting minimum request size by caching "extra" data, >>> but try using only single gcache(8) instance per system because of known instability in the gcache code >>> when you create multiple geom_cache's. >>> >> did gcache with 2kB blocks. works fine. Seems like a problem is here - some requests are not handled. >> >> now i tested reading it with dd with 2,4,8,16 and 32kB blocks. seems fine. >> >> trying to read with blocks like 1k, 512 doesn't work but it is i think normal - CDs have 2kB blocks. >> >> real CD drive behaves the same way. > > It's time to enable geom logs to look at size of read requests going to low level driver. > > > From nobody Thu Mar 3 21:10:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A3CE819F57CE for ; Thu, 3 Mar 2022 21:10:35 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K8kCt6DTRz3jkY for ; Thu, 3 Mar 2022 21:10:34 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 223LAWUY014334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Mar 2022 22:10:33 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1646341833; bh=wJAvZhdNHwgvf7FYGVfx3GmXETVWuSHtgjim6A7btQI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=mxpo1Dj99zICRLPkLfmaY1lyZQKTPwthQhVoUoC+7FJ3fTJpP3wys7AqlYZhpljFV IRncCNLNS0Vv1WrZzKvlP+KVK/nAB+xN2XGBO7UCG3R/GdmPi8ETKr13F2D2PShYtp N9shdjESu+xs8BJciDeSybqM1tnKJM5KbXl2TMyc= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 223LAWlC027064; Thu, 3 Mar 2022 22:10:32 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 223LAVDd027061; Thu, 3 Mar 2022 22:10:31 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 3 Mar 2022 22:10:31 +0100 (CET) From: Wojciech Puchar To: Eugene Grosbein cc: John-Mark Gurney , freebsd-hackers@freebsd.org Subject: Re: problem with USB-CD drive In-Reply-To: Message-ID: <8f255987-db8b-b1ee-3732-b587c35c9d40@puchar.net> References: <197d435-6c4b-a60-4e6f-ea4ee515b8f4@puchar.net> <20220302014925.GA88842@funkthat.com> <2de67fd5-40d9-55fc-18ea-671aa096bab5@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4K8kCt6DTRz3jkY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=mxpo1Dj9; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> The question is how to debug it on host side - what exactly is wrong. > > Use sysctl kern.cam.dflags to enable CAM-level debugging. That's what i will do next week with access to the device. It is not really a problem - end users use windows, unix users don't need to mount this image at all in fact. User level program to control this devices (using vendor specific SCSI commands) works fine on unix (FreeBSD and linux) windows and mac OS without problems. For sure that's wrong response to some of few CD-specific SCSI commands i implemented. or maybe some missing. More importantly - when i was implementing this it worked properly under FreeBSD in some point WITHOUT most SCSI command implemented (READ was implemented and few others). Actually i implemented this reading SCSI specs but often - just doing camcontrol on real CD drive to see what to respond :) And not implementing more than needed - all microcontroller side code, including all USB/SCSI handling, firmware update code with decryption AND CD image (decompressed on the fly) fits in PIC32MX bootloader space - 12kB ;) From nobody Fri Mar 4 13:42:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 151CF19EDDF1 for ; Fri, 4 Mar 2022 13:42:40 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K98Db0q6Cz3GCg for ; Fri, 4 Mar 2022 13:42:38 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 04 Mar 2022 14:42:36 +0100 id 00DADCA4.6222174C.00000756 Date: Fri, 4 Mar 2022 14:42:35 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: GPD Micro PC serial port Message-ID: <20220304144235.26276414@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) Importance: high X-Priority: 1 (Highest) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K98Db0q6Cz3GCg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-3.06 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.76)[-0.763]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; HAS_X_PRIO_ONE(0.00)[1] X-ThisMailContainsUnwantedMimeParts: N Hi, for mobile usage I've got Micro PC from GPD, some description and data here: https://www.amazon.com/Industry-Portable-Computer-Notebook-Graphics/dp/B07QYZHM8F I managed to install dual boot FreeBSD/Windows here. Working with FreeBSD 13 here, it was possible to verify working ethernet, wifi, X on both internal display and HDMI connected monitor, and all basic devices. I've put dmesg from at https://dmesgd.nycbug.org/index.cgi?do=view&id=6461 There is one think I'd like to get into working state - serial port. In Windows, it is COM2 with standard I/O address and IRQ, however, I see nothing in FreeBSD... has somebody any hint for me? I did not work with bluetooth, yet. Regards, Milan From eugen@grosbein.net Fri Mar 4 13:51:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1CD7319F005F for ; Fri, 4 Mar 2022 13:52:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K98S31976z3HVV for ; Fri, 4 Mar 2022 13:52:35 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 224DqNAq048691 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Mar 2022 13:52:24 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-hackers@dino.sk Received: from [10.58.0.11] ([10.58.0.11]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 224DpuiN084807 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 4 Mar 2022 20:52:21 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: GPD Micro PC serial port To: Milan Obuch , freebsd-hackers@freebsd.org References: <20220304144235.26276414@zeta.dino.sk> From: Eugene Grosbein Message-ID: Date: Fri, 4 Mar 2022 20:51:50 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20220304144235.26276414@zeta.dino.sk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4K98S31976z3HVV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-1.72 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.77)[-0.769]; NEURAL_HAM_LONG(-0.85)[-0.850]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 04.03.2022 20:42, Milan Obuch wrote: > Hi, > > for mobile usage I've got Micro PC from GPD, some description and data > here: > > https://www.amazon.com/Industry-Portable-Computer-Notebook-Graphics/dp/B07QYZHM8F > > I managed to install dual boot FreeBSD/Windows here. Working with > FreeBSD 13 here, it was possible to verify working ethernet, wifi, X > on both internal display and HDMI connected monitor, and all basic > devices. > > I've put dmesg from at https://dmesgd.nycbug.org/index.cgi?do=view&id=6461 > > There is one think I'd like to get into working state - serial port. In > Windows, it is COM2 with standard I/O address and IRQ, however, I see > nothing in FreeBSD... has somebody any hint for me? You seem to use custom kernel configuration. Did you try GENERIC? Can you share your kernel config? Also output of "pciconf -lv" and "dmidecode" commands ("pkg install dmidecode" for the latter). From nobody Fri Mar 4 15:16:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B28D919FFFEB for ; Fri, 4 Mar 2022 15:16:13 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9BJX4qCtz3jjQ for ; Fri, 4 Mar 2022 15:16:12 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Fri, 04 Mar 2022 16:16:10 +0100 id 00DADC7E.62222D3A.0000129A Date: Fri, 4 Mar 2022 16:16:09 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: GPD Micro PC power button and lid close [originally Re: GPD Micro PC serial port] Message-ID: <20220304161609.5654c1b3@zeta.dino.sk> In-Reply-To: References: <20220304144235.26276414@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mailhost.netlabit.sk-4762-1646406970-0001-2" X-Rspamd-Queue-Id: 4K9BJX4qCtz3jjQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-2.63 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.83)[-0.831]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[dino.sk]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_mailhost.netlabit.sk-4762-1646406970-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline On Fri, 4 Mar 2022 20:51:50 +0700 Eugene Grosbein wrote: > 04.03.2022 20:42, Milan Obuch wrote: > > > Hi, > > > > for mobile usage I've got Micro PC from GPD, some description and > > data here: > > > > https://www.amazon.com/Industry-Portable-Computer-Notebook-Graphics/dp/B07QYZHM8F > > > > I managed to install dual boot FreeBSD/Windows here. Working with > > FreeBSD 13 here, it was possible to verify working ethernet, wifi, X > > on both internal display and HDMI connected monitor, and all basic > > devices. > > > > I've put dmesg from at > > https://dmesgd.nycbug.org/index.cgi?do=view&id=6461 > > > > There is one think I'd like to get into working state - serial > > port. In Windows, it is COM2 with standard I/O address and IRQ, > > however, I see nothing in FreeBSD... has somebody any hint for me? > > You seem to use custom kernel configuration. Did you try GENERIC? > Can you share your kernel config? Also output of "pciconf -lv" > and "dmidecode" commands ("pkg install dmidecode" for the latter). > Yes, I use custom kernel, basically MINIMAL with some modules loaded via loader.conf, other automatically and i915kms from rc.conf. As I verified correct values are in device.hints, I found the solution - loading module uart.ko from running system installed uart2..uart5 (no idea what it is used for, you'll see them in some data provided), but loading it from loader.conf brings uart1..uart5. Problem solved, I just verified it is exactly the port on back. Just for info, output from 'pciconf -lv' is attached. 'dmidecode' output added as well. Now, with serial port working, I see there is something else I forgot - power button does nothing when FreeBSD is running, just long press powers it off without proper shutdown sequence. 'dmesg | grep acpi' tells acpi0: cpu0: on acpi0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 atrtc0: port 0x70-0x77 on acpi0 hpet0: iomem 0xfed00000-0xfed003ff irq 8 on acpi0 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 so there should be something handling power button (and lid close event, as well). Any idea here? Regards, Milan --=_mailhost.netlabit.sk-4762-1646406970-0001-2 Content-Type: application/octet-stream; name=pciconf-lv Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pciconf-lv aG9zdGIwQHBjaTA6MDowOjA6ICAgICAgY2xhc3M9MHgwNjAwMDAgcmV2PTB4MDYgaGRyPTB4MDAg dmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgzMWYwIHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4 MDAwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAg PSAnR2VtaW5pIExha2UgSG9zdCBCcmlkZ2UnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyAgID0gSE9TVC1QQ0kKbm9uZTBAcGNpMDowOjA6MTogICAgICAgY2xhc3M9MHgxMTgw MDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgzMThjIHN1YnZlbmRv cj0weDgwODYgc3ViZGV2aWNlPTB4NzI3MAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnQ2VsZXJvbi9QZW50aXVtIFNpbHZlciBQcm9jZXNzb3Ig RHluYW1pYyBQbGF0Zm9ybSBhbmQgVGhlcm1hbCBGcmFtZXdvcmsgUHJvY2Vzc29yIFBhcnRpY2lw YW50JwogICAgY2xhc3MgICAgICA9IGRhc3AKdmdhcGNpMEBwY2kwOjA6MjowOiAgICAgY2xhc3M9 MHgwMzAwMDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgzMTg1IHN1 YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBD b3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnR2VtaW5pTGFrZSBbVUhEIEdyYXBoaWNzIDYw MF0nCiAgICBjbGFzcyAgICAgID0gZGlzcGxheQogICAgc3ViY2xhc3MgICA9IFZHQQpoZGFjMEBw Y2kwOjA6MTQ6MDogICAgICBjbGFzcz0weDA0MDMwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9 MHg4MDg2IGRldmljZT0weDMxOTggc3VidmVuZG9yPTB4MTBlYyBzdWJkZXZpY2U9MHgwMDAwCiAg ICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxl cm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nlc3NvciBIaWdoIERlZmluaXRpb24gQXVkaW8nCiAgICBj bGFzcyAgICAgID0gbXVsdGltZWRpYQogICAgc3ViY2xhc3MgICA9IEhEQQpub25lMUBwY2kwOjA6 MTU6MDogICAgICBjbGFzcz0weDA3ODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weDMxOWEgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1Bl bnRpdW0gU2lsdmVyIFByb2Nlc3NvciBUcnVzdGVkIEV4ZWN1dGlvbiBFbmdpbmUgSW50ZXJmYWNl JwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwphaGNpMEBwY2kwOjA6MTg6MDogICAgICBj bGFzcz0weDAxMDYwMSByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMx ZTMgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0lu dGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVy IFByb2Nlc3NvciBTQVRBIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdl CiAgICBzdWJjbGFzcyAgID0gU0FUQQpwY2liMUBwY2kwOjA6MTk6MDogICAgICBjbGFzcz0weDA2 MDQwMCByZXY9MHhmNiBoZHI9MHgwMSB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxZDggc3VidmVu ZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdHZW1pbmkgTGFrZSBQQ0kgRXhwcmVzcyBSb290IFBv cnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQpwY2li MkBwY2kwOjA6MTk6MjogICAgICBjbGFzcz0weDA2MDQwMCByZXY9MHhmNiBoZHI9MHgwMSB2ZW5k b3I9MHg4MDg2IGRldmljZT0weDMxZGEgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3Mjcw CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdH ZW1pbmkgTGFrZSBQQ0kgRXhwcmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdl CiAgICBzdWJjbGFzcyAgID0gUENJLVBDSQp4aGNpMEBwY2kwOjA6MjE6MDogICAgICBjbGFzcz0w eDBjMDMzMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxYTggc3Vi dmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENv cnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nl c3NvciBVU0IgMy4wIHhIQ0kgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVz CiAgICBzdWJjbGFzcyAgID0gVVNCCmlnNGlpYzBAcGNpMDowOjIyOjA6ICAgIGNsYXNzPTB4MTE4 MDAwIHJldj0weDA2IGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MzFhYyBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDcyNzAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ0NlbGVyb24vUGVudGl1bSBTaWx2ZXIgUHJvY2Vzc29y IFNlcmlhbCBJTyBJMkMgSG9zdCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGRhc3AKaWc0 aWljMUBwY2kwOjA6MjI6MTogICAgY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVu ZG9yPTB4ODA4NiBkZXZpY2U9MHgzMWFlIHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4NzI3 MAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAn Q2VsZXJvbi9QZW50aXVtIFNpbHZlciBQcm9jZXNzb3IgU2VyaWFsIElPIEkyQyBIb3N0IENvbnRy b2xsZXInCiAgICBjbGFzcyAgICAgID0gZGFzcAppZzRpaWMyQHBjaTA6MDoyMjoyOiAgICBjbGFz cz0weDExODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxYjAg c3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVs IENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IGRhc3AKaWc0aWljM0BwY2kwOjA6MjI6Mzog ICAgY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHgzMWIyIHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4NzI3MAogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCmlnNGlpYzRAcGNpMDow OjIzOjA6ICAgIGNsYXNzPTB4MTE4MDAwIHJldj0weDA2IGhkcj0weDAwIHZlbmRvcj0weDgwODYg ZGV2aWNlPTB4MzFiNCBzdWJ2ZW5kb3I9MHg4MDg2IHN1YmRldmljZT0weDcyNzAKICAgIHZlbmRv ciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICAgID0gZGFzcAppZzRpaWM1 QHBjaTA6MDoyMzoxOiAgICBjbGFzcz0weDExODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9 MHg4MDg2IGRldmljZT0weDMxYjYgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAg ICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgICA9IGRhc3AK aWc0aWljNkBwY2kwOjA6MjM6MjogICAgY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDYgaGRyPTB4MDAg dmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgzMWI4IHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4 NzI3MAogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAg PSBkYXNwCmlnNGlpYzdAcGNpMDowOjIzOjM6ICAgIGNsYXNzPTB4MTE4MDAwIHJldj0weDA2IGhk cj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MzFiYSBzdWJ2ZW5kb3I9MHg4MDg2IHN1YmRl dmljZT0weDcyNzAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBjbGFz cyAgICAgID0gZGFzcAp1YXJ0MkBwY2kwOjA6MjQ6MDogICAgICBjbGFzcz0weDExODAwMCByZXY9 MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxYmMgc3VidmVuZG9yPTB4ODA4 NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nlc3NvciBTZXJpYWwg SU8gVUFSVCBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gZGFzcAp1YXJ0M0BwY2kw OjA6MjQ6MTogICAgICBjbGFzcz0weDExODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDMxYmUgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9u L1BlbnRpdW0gU2lsdmVyIFByb2Nlc3NvciBTZXJpYWwgSU8gVUFSVCBIb3N0IENvbnRyb2xsZXIn CiAgICBjbGFzcyAgICAgID0gZGFzcAp1YXJ0NEBwY2kwOjA6MjQ6MjogICAgICBjbGFzcz0weDEx ODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxYzAgc3VidmVu ZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBv cmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nlc3Nv ciBTZXJpYWwgSU8gVUFSVCBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gZGFzcAp1 YXJ0NUBwY2kwOjA6MjQ6MzogICAgICBjbGFzcz0weDExODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2 ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxZWUgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3 MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9 ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nlc3NvciBTZXJpYWwgSU8gVUFSVCBIb3N0IENv bnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gZGFzcApub25lMkBwY2kwOjA6MjU6MDogICAgICBj bGFzcz0weDExODAwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMx YzIgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0lu dGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVy IFByb2Nlc3NvciBTZXJpYWwgSU8gU1BJIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAg PSBkYXNwCm5vbmUzQHBjaTA6MDoyNToxOiAgICAgIGNsYXNzPTB4MTE4MDAwIHJldj0weDA2IGhk cj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MzFjNCBzdWJ2ZW5kb3I9MHg4MDg2IHN1YmRl dmljZT0weDcyNzAKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZp Y2UgICAgID0gJ0NlbGVyb24vUGVudGl1bSBTaWx2ZXIgUHJvY2Vzc29yIFNlcmlhbCBJTyBTUEkg SG9zdCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IGRhc3AKbm9uZTRAcGNpMDowOjI1OjI6 ICAgICAgY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHgzMWM2IHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4NzI3MAogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnQ2VsZXJvbi9QZW50aXVt IFNpbHZlciBQcm9jZXNzb3IgU2VyaWFsIElPIFNQSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFz cyAgICAgID0gZGFzcApzZGhjaV9wY2kwQHBjaTA6MDoyODowOiBjbGFzcz0weDA4MDUwMSByZXY9 MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMxY2Mgc3VidmVuZG9yPTB4ODA4 NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwog ICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2lsdmVyIFByb2Nlc3NvciBTREEgU3Rh bmRhcmQgQ29tcGxpYW50IFNEIEhvc3QgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBiYXNl IHBlcmlwaGVyYWwKICAgIHN1YmNsYXNzICAgPSBTRCBob3N0IGNvbnRyb2xsZXIKaXNhYjBAcGNp MDowOjMxOjA6ICAgICAgY2xhc3M9MHgwNjAxMDAgcmV2PTB4MDYgaGRyPTB4MDAgdmVuZG9yPTB4 ODA4NiBkZXZpY2U9MHgzMWU4IHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4NzI3MAogICAg dmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnQ2VsZXJv bi9QZW50aXVtIFNpbHZlciBQcm9jZXNzb3IgTFBDIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0gUENJLUlTQQppY2hzbWIwQHBjaTA6MDozMToxOiAg ICBjbGFzcz0weDBjMDUwMCByZXY9MHgwNiBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0w eDMxZDQgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg3MjcwCiAgICB2ZW5kb3IgICAgID0g J0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdDZWxlcm9uL1BlbnRpdW0gU2ls dmVyIFByb2Nlc3NvciBHYXVzc2lhbiBNaXh0dXJlIE1vZGVsJwogICAgY2xhc3MgICAgICA9IHNl cmlhbCBidXMKICAgIHN1YmNsYXNzICAgPSBTTUJ1cwppd20wQHBjaTA6MTowOjA6ICAgICAgICBj bGFzcz0weDAyODAwMCByZXY9MHg1OSBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5 NWEgc3VidmVuZG9yPTB4ODA4NiBzdWJkZXZpY2U9MHg5MDEwCiAgICB2ZW5kb3IgICAgID0gJ0lu dGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdXaXJlbGVzcyA3MjY1JwogICAgY2xh c3MgICAgICA9IG5ldHdvcmsKcmUwQHBjaTA6MjowOjA6IGNsYXNzPTB4MDIwMDAwIHJldj0weDE1 IGhkcj0weDAwIHZlbmRvcj0weDEwZWMgZGV2aWNlPTB4ODE2OCBzdWJ2ZW5kb3I9MHgxMGVjIHN1 YmRldmljZT0weDAxMjMKICAgIHZlbmRvciAgICAgPSAnUmVhbHRlayBTZW1pY29uZHVjdG9yIENv LiwgTHRkLicKICAgIGRldmljZSAgICAgPSAnUlRMODExMS84MTY4Lzg0MTEgUENJIEV4cHJlc3Mg R2lnYWJpdCBFdGhlcm5ldCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IG5ldHdvcmsKICAg IHN1YmNsYXNzICAgPSBldGhlcm5ldAo= --=_mailhost.netlabit.sk-4762-1646406970-0001-2 Content-Type: application/octet-stream; name=dmidecode Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dmidecode IyBkbWlkZWNvZGUgMy4zCiMgU01CSU9TIGVudHJ5IHBvaW50IGF0IDB4NzllZGIwMDAKRm91bmQg U01CSU9TIGVudHJ5IHBvaW50IGluIEVGSSwgcmVhZGluZyB0YWJsZSBmcm9tIC9kZXYvbWVtLgpT TUJJT1MgMy4yIHByZXNlbnQuCjc0IHN0cnVjdHVyZXMgb2NjdXB5aW5nIDI2NzUgYnl0ZXMuClRh YmxlIGF0IDB4NzlFRDgwMDAuCgpIYW5kbGUgMHgwMDAwLCBETUkgdHlwZSAwLCAyNiBieXRlcwpC SU9TIEluZm9ybWF0aW9uCglWZW5kb3I6IEFtZXJpY2FuIE1lZ2F0cmVuZHMgSW5jLgoJVmVyc2lv bjogNC4xOAoJUmVsZWFzZSBEYXRlOiAwNi8wMS8yMDIwCglBZGRyZXNzOiAweEYwMDAwCglSdW50 aW1lIFNpemU6IDY0IGtCCglST00gU2l6ZTogNDkyOCBrQgoJQ2hhcmFjdGVyaXN0aWNzOgoJCVBD SSBpcyBzdXBwb3J0ZWQKCQlCSU9TIGlzIHVwZ3JhZGVhYmxlCgkJQklPUyBzaGFkb3dpbmcgaXMg YWxsb3dlZAoJCUJvb3QgZnJvbSBDRCBpcyBzdXBwb3J0ZWQKCQlTZWxlY3RhYmxlIGJvb3QgaXMg c3VwcG9ydGVkCgkJQklPUyBST00gaXMgc29ja2V0ZWQKCQlFREQgaXMgc3VwcG9ydGVkCgkJNS4y NSIvMS4yIE1CIGZsb3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIv NzIwIGtCIGZsb3BweSBzZXJ2aWNlcyBhcmUgc3VwcG9ydGVkIChpbnQgMTNoKQoJCTMuNSIvMi44 OCBNQiBmbG9wcHkgc2VydmljZXMgYXJlIHN1cHBvcnRlZCAoaW50IDEzaCkKCQlQcmludCBzY3Jl ZW4gc2VydmljZSBpcyBzdXBwb3J0ZWQgKGludCA1aCkKCQlTZXJpYWwgc2VydmljZXMgYXJlIHN1 cHBvcnRlZCAoaW50IDE0aCkKCQlQcmludGVyIHNlcnZpY2VzIGFyZSBzdXBwb3J0ZWQgKGludCAx N2gpCgkJQUNQSSBpcyBzdXBwb3J0ZWQKCQlVU0IgbGVnYWN5IGlzIHN1cHBvcnRlZAoJCUJJT1Mg Ym9vdCBzcGVjaWZpY2F0aW9uIGlzIHN1cHBvcnRlZAoJCVRhcmdldGVkIGNvbnRlbnQgZGlzdHJp YnV0aW9uIGlzIHN1cHBvcnRlZAoJCVVFRkkgaXMgc3VwcG9ydGVkCglCSU9TIFJldmlzaW9uOiA1 LjEzCglGaXJtd2FyZSBSZXZpc2lvbjogNC44CgpIYW5kbGUgMHgwMDAxLCBETUkgdHlwZSAxLCAy NyBieXRlcwpTeXN0ZW0gSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJlcjogR1BECglQcm9kdWN0IE5h bWU6IE1pY3JvUEMKCVZlcnNpb246IERlZmF1bHQgc3RyaW5nCglTZXJpYWwgTnVtYmVyOiBEZWZh dWx0IHN0cmluZwoJVVVJRDogMDMwMDAyMDAtMDQwMC0wNTAwLTAwMDYtMDAwNzAwMDgwMDA5CglX YWtlLXVwIFR5cGU6IFBvd2VyIFN3aXRjaAoJU0tVIE51bWJlcjogRGVmYXVsdCBzdHJpbmcKCUZh bWlseTogRGVmYXVsdCBzdHJpbmcKCkhhbmRsZSAweDAwMDIsIERNSSB0eXBlIDIsIDE1IGJ5dGVz CkJhc2UgQm9hcmQgSW5mb3JtYXRpb24KCU1hbnVmYWN0dXJlcjogR1BECglQcm9kdWN0IE5hbWU6 IE1pY3JvUEMKCVZlcnNpb246IERlZmF1bHQgc3RyaW5nCglTZXJpYWwgTnVtYmVyOiBEZWZhdWx0 IHN0cmluZwoJQXNzZXQgVGFnOiBEZWZhdWx0IHN0cmluZwoJRmVhdHVyZXM6CgkJQm9hcmQgaXMg YSBob3N0aW5nIGJvYXJkCgkJQm9hcmQgaXMgcmVwbGFjZWFibGUKCUxvY2F0aW9uIEluIENoYXNz aXM6IERlZmF1bHQgc3RyaW5nCglDaGFzc2lzIEhhbmRsZTogMHgwMDAzCglUeXBlOiBNb3RoZXJi b2FyZAoJQ29udGFpbmVkIE9iamVjdCBIYW5kbGVzOiAwCgpIYW5kbGUgMHgwMDAzLCBETUkgdHlw ZSAzLCAyMiBieXRlcwpDaGFzc2lzIEluZm9ybWF0aW9uCglNYW51ZmFjdHVyZXI6IERlZmF1bHQg c3RyaW5nCglUeXBlOiBOb3RlYm9vawoJTG9jazogTm90IFByZXNlbnQKCVZlcnNpb246IERlZmF1 bHQgc3RyaW5nCglTZXJpYWwgTnVtYmVyOiBEZWZhdWx0IHN0cmluZwoJQXNzZXQgVGFnOiBEZWZh dWx0IHN0cmluZwoJQm9vdC11cCBTdGF0ZTogU2FmZQoJUG93ZXIgU3VwcGx5IFN0YXRlOiBTYWZl CglUaGVybWFsIFN0YXRlOiBTYWZlCglTZWN1cml0eSBTdGF0dXM6IE5vbmUKCU9FTSBJbmZvcm1h dGlvbjogMHgwMDAwMDAwMAoJSGVpZ2h0OiBVbnNwZWNpZmllZAoJTnVtYmVyIE9mIFBvd2VyIENv cmRzOiAxCglDb250YWluZWQgRWxlbWVudHM6IDAKCVNLVSBOdW1iZXI6IERlZmF1bHQgc3RyaW5n CgpIYW5kbGUgMHgwMDA4LCBETUkgdHlwZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9y bWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogSjFBMQoJSW50ZXJuYWwgQ29u bmVjdG9yIFR5cGU6IE5vbmUKCUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBQUzJNb3Vz ZQoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IFBTLzIKCVBvcnQgVHlwZTogTW91c2UgUG9ydAoK SGFuZGxlIDB4MDAwOSwgRE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1h dGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IEoxQTEKCUludGVybmFsIENvbm5l Y3RvciBUeXBlOiBOb25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogS2V5Ym9hcmQK CUV4dGVybmFsIENvbm5lY3RvciBUeXBlOiBQUy8yCglQb3J0IFR5cGU6IEtleWJvYXJkIFBvcnQK CkhhbmRsZSAweDAwMEEsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3Jt YXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKMkExCglJbnRlcm5hbCBDb25u ZWN0b3IgVHlwZTogTm9uZQoJRXh0ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IFRWIE91dAoJ RXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE1pbmkgQ2VudHJvbmljcyBUeXBlLTE0CglQb3J0IFR5 cGU6IE90aGVyCgpIYW5kbGUgMHgwMDBCLCBETUkgdHlwZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVj dG9yIEluZm9ybWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogSjJBMkEKCUlu dGVybmFsIENvbm5lY3RvciBUeXBlOiBOb25lCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRv cjogQ09NIEEKCUV4dGVybmFsIENvbm5lY3RvciBUeXBlOiBEQi05IG1hbGUKCVBvcnQgVHlwZTog U2VyaWFsIFBvcnQgMTY1NTBBIENvbXBhdGlibGUKCkhhbmRsZSAweDAwMEMsIERNSSB0eXBlIDgs IDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBE ZXNpZ25hdG9yOiBKMkEyQgoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCUV4dGVybmFs IFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBWaWRlbwoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IERC LTE1IGZlbWFsZQoJUG9ydCBUeXBlOiBWaWRlbyBQb3J0CgpIYW5kbGUgMHgwMDBELCBETUkgdHlw ZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9ybWF0aW9uCglJbnRlcm5hbCBSZWZlcmVu Y2UgRGVzaWduYXRvcjogSjNBMQoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCUV4dGVy bmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBVU0IxCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTog QWNjZXNzIEJ1cyAoVVNCKQoJUG9ydCBUeXBlOiBVU0IKCkhhbmRsZSAweDAwMEUsIERNSSB0eXBl IDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5j ZSBEZXNpZ25hdG9yOiBKM0ExCglJbnRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9uZQoJRXh0ZXJu YWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IFVTQjIKCUV4dGVybmFsIENvbm5lY3RvciBUeXBlOiBB Y2Nlc3MgQnVzIChVU0IpCglQb3J0IFR5cGU6IFVTQgoKSGFuZGxlIDB4MDAwRiwgRE1JIHR5cGUg OCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNl IERlc2lnbmF0b3I6IEozQTEKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBOb25lCglFeHRlcm5h bCBSZWZlcmVuY2UgRGVzaWduYXRvcjogVVNCMwoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IEFj Y2VzcyBCdXMgKFVTQikKCVBvcnQgVHlwZTogVVNCCgpIYW5kbGUgMHgwMDEwLCBETUkgdHlwZSA4 LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9ybWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2Ug RGVzaWduYXRvcjogSjlBMSAtIFRQTSBIRFIKCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBPdGhl cgoJRXh0ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUV4dGVybmFs IENvbm5lY3RvciBUeXBlOiBOb25lCglQb3J0IFR5cGU6IE90aGVyCgpIYW5kbGUgMHgwMDExLCBE TUkgdHlwZSA4LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9ybWF0aW9uCglJbnRlcm5hbCBS ZWZlcmVuY2UgRGVzaWduYXRvcjogSjlDMSAtIFBDSUUgRE9DS0lORyBDT05OCglJbnRlcm5hbCBD b25uZWN0b3IgVHlwZTogT3RoZXIKCUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBOb3Qg U3BlY2lmaWVkCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9uZQoJUG9ydCBUeXBlOiBPdGhl cgoKSGFuZGxlIDB4MDAxMiwgRE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5lY3RvciBJbmZv cm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IEoyQjMgLSBDUFUgRkFOCglJ bnRlcm5hbCBDb25uZWN0b3IgVHlwZTogT3RoZXIKCUV4dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25h dG9yOiBOb3QgU3BlY2lmaWVkCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9uZQoJUG9ydCBU eXBlOiBPdGhlcgoKSGFuZGxlIDB4MDAxMywgRE1JIHR5cGUgOCwgOSBieXRlcwpQb3J0IENvbm5l Y3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IEo2QzIgLSBF WFQgSERNSQoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVu Y2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5v bmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMTQsIERNSSB0eXBlIDgsIDkgYnl0ZXMK UG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9y OiBKM0MxIC0gR01DSCBGQU4KCUludGVybmFsIENvbm5lY3RvciBUeXBlOiBPdGhlcgoJRXh0ZXJu YWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6IE5vdCBTcGVjaWZpZWQKCUV4dGVybmFsIENvbm5lY3Rv ciBUeXBlOiBOb25lCglQb3J0IFR5cGU6IE90aGVyCgpIYW5kbGUgMHgwMDE1LCBETUkgdHlwZSA4 LCA5IGJ5dGVzClBvcnQgQ29ubmVjdG9yIEluZm9ybWF0aW9uCglJbnRlcm5hbCBSZWZlcmVuY2Ug RGVzaWduYXRvcjogSjFEMSAtIElUUAoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglF eHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29u bmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMTYsIERNSSB0 eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVy ZW5jZSBEZXNpZ25hdG9yOiBKOUUyIC0gTURDIElOVFBTUgoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5 cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJ RXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAw eDAwMTcsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUlu dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKOUU0IC0gTURDIElOVFBTUgoJSW50ZXJuYWwg Q29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90 IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3Ro ZXIKCkhhbmRsZSAweDAwMTgsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5m b3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKOUUzIC0gTFBDIEhPVCBE T0NLSU5HCglJbnRlcm5hbCBDb25uZWN0b3IgVHlwZTogT3RoZXIKCUV4dGVybmFsIFJlZmVyZW5j ZSBEZXNpZ25hdG9yOiBOb3QgU3BlY2lmaWVkCglFeHRlcm5hbCBDb25uZWN0b3IgVHlwZTogTm9u ZQoJUG9ydCBUeXBlOiBPdGhlcgoKSGFuZGxlIDB4MDAxOSwgRE1JIHR5cGUgOCwgOSBieXRlcwpQ b3J0IENvbm5lY3RvciBJbmZvcm1hdGlvbgoJSW50ZXJuYWwgUmVmZXJlbmNlIERlc2lnbmF0b3I6 IEo5RTEgLSBTQ0FOIE1BVFJJWAoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRl cm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVj dG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMUEsIERNSSB0eXBl IDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5j ZSBEZXNpZ25hdG9yOiBKOUcxIC0gTFBDIFNJREUgQkFORAoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5 cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJ RXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAw eDAwMUIsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUlu dGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKOEYxIC0gVU5JRklFRAoJSW50ZXJuYWwgQ29u bmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNw ZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIK CkhhbmRsZSAweDAwMUMsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3Jt YXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKNkYxIC0gTFZEUwoJSW50ZXJu YWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjog Tm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTog T3RoZXIKCkhhbmRsZSAweDAwMUQsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBDb25uZWN0b3Ig SW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKMkYxIC0gTEFJIEZB TgoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZlcmVuY2UgRGVz aWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE5vbmUKCVBv cnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMUUsIERNSSB0eXBlIDgsIDkgYnl0ZXMKUG9ydCBD b25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25hdG9yOiBKMkcx IC0gR0ZYIFZJRAoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRlcm5hbCBSZWZl cmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVjdG9yIFR5cGU6 IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMUYsIERNSSB0eXBlIDgsIDkgYnl0 ZXMKUG9ydCBDb25uZWN0b3IgSW5mb3JtYXRpb24KCUludGVybmFsIFJlZmVyZW5jZSBEZXNpZ25h dG9yOiBKMUc2IC0gQUMgSkFDSwoJSW50ZXJuYWwgQ29ubmVjdG9yIFR5cGU6IE90aGVyCglFeHRl cm5hbCBSZWZlcmVuY2UgRGVzaWduYXRvcjogTm90IFNwZWNpZmllZAoJRXh0ZXJuYWwgQ29ubmVj dG9yIFR5cGU6IE5vbmUKCVBvcnQgVHlwZTogT3RoZXIKCkhhbmRsZSAweDAwMjAsIERNSSB0eXBl IDEwLCA2IGJ5dGVzCk9uIEJvYXJkIERldmljZSBJbmZvcm1hdGlvbgoJVHlwZTogVmlkZW8KCVN0 YXR1czogRW5hYmxlZAoJRGVzY3JpcHRpb246ICAgIFRvIEJlIEZpbGxlZCBCeSBPLkUuTS4KCkhh bmRsZSAweDAwMjEsIERNSSB0eXBlIDExLCA1IGJ5dGVzCk9FTSBTdHJpbmdzCglTdHJpbmcgMTog RGVmYXVsdCBzdHJpbmcKCkhhbmRsZSAweDAwMjIsIERNSSB0eXBlIDEyLCA1IGJ5dGVzClN5c3Rl bSBDb25maWd1cmF0aW9uIE9wdGlvbnMKCU9wdGlvbiAxOiBEZWZhdWx0IHN0cmluZwoKSGFuZGxl IDB4MDAyMywgRE1JIHR5cGUgMTYsIDIzIGJ5dGVzClBoeXNpY2FsIE1lbW9yeSBBcnJheQoJTG9j YXRpb246IFN5c3RlbSBCb2FyZCBPciBNb3RoZXJib2FyZAoJVXNlOiBTeXN0ZW0gTWVtb3J5CglF cnJvciBDb3JyZWN0aW9uIFR5cGU6IE5vbmUKCU1heGltdW0gQ2FwYWNpdHk6IDMyIEdCCglFcnJv ciBJbmZvcm1hdGlvbiBIYW5kbGU6IE5vdCBQcm92aWRlZAoJTnVtYmVyIE9mIERldmljZXM6IDIK CkhhbmRsZSAweDAwMjQsIERNSSB0eXBlIDE5LCAzMSBieXRlcwpNZW1vcnkgQXJyYXkgTWFwcGVk IEFkZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNz OiAweDAwMUZGRkZGRkZGCglSYW5nZSBTaXplOiA4IEdCCglQaHlzaWNhbCBBcnJheSBIYW5kbGU6 IDB4MDAyMwoJUGFydGl0aW9uIFdpZHRoOiAyCgpIYW5kbGUgMHgwMDI1LCBETUkgdHlwZSAxNywg ODQgYnl0ZXMKTWVtb3J5IERldmljZQoJQXJyYXkgSGFuZGxlOiAweDAwMjMKCUVycm9yIEluZm9y bWF0aW9uIEhhbmRsZTogTm90IFByb3ZpZGVkCglUb3RhbCBXaWR0aDogMTYgYml0cwoJRGF0YSBX aWR0aDogMTYgYml0cwoJU2l6ZTogNCBHQgoJRm9ybSBGYWN0b3I6IERJTU0KCVNldDogTm9uZQoJ TG9jYXRvcjogQTFfRElNTTAKCUJhbmsgTG9jYXRvcjogQTFfQkFOSzAKCVR5cGU6IExQRERSNAoJ VHlwZSBEZXRhaWw6IFN5bmNocm9ub3VzCglTcGVlZDogMjEzMyBNVC9zCglNYW51ZmFjdHVyZXI6 IEFCQ0QKCVNlcmlhbCBOdW1iZXI6IDEyMzQKCUFzc2V0IFRhZzogOTg3NjU0MzIxMAoJUGFydCBO dW1iZXI6IDEyMzQ1Njc4OTAxMjM0NTY3OAoJUmFuazogVW5rbm93bgoJQ29uZmlndXJlZCBNZW1v cnkgU3BlZWQ6IDIxMzMgTVQvcwoJTWluaW11bSBWb2x0YWdlOiAxLjEgVgoJTWF4aW11bSBWb2x0 YWdlOiAxLjUgVgoJQ29uZmlndXJlZCBWb2x0YWdlOiAxLjEgVgoJTWVtb3J5IFRlY2hub2xvZ3k6 IERSQU0KCU1lbW9yeSBPcGVyYXRpbmcgTW9kZSBDYXBhYmlsaXR5OiBWb2xhdGlsZSBtZW1vcnkK CUZpcm13YXJlIFZlcnNpb246IE5vdCBTcGVjaWZpZWQKCU1vZHVsZSBNYW51ZmFjdHVyZXIgSUQ6 IFVua25vd24KCU1vZHVsZSBQcm9kdWN0IElEOiBVbmtub3duCglNZW1vcnkgU3Vic3lzdGVtIENv bnRyb2xsZXIgTWFudWZhY3R1cmVyIElEOiBVbmtub3duCglNZW1vcnkgU3Vic3lzdGVtIENvbnRy b2xsZXIgUHJvZHVjdCBJRDogVW5rbm93bgoJTm9uLVZvbGF0aWxlIFNpemU6IE5vbmUKCVZvbGF0 aWxlIFNpemU6IDQgR0IKCUNhY2hlIFNpemU6IE5vbmUKCUxvZ2ljYWwgU2l6ZTogTm9uZQoKSGFu ZGxlIDB4MDAyNiwgRE1JIHR5cGUgMjAsIDM1IGJ5dGVzCk1lbW9yeSBEZXZpY2UgTWFwcGVkIEFk ZHJlc3MKCVN0YXJ0aW5nIEFkZHJlc3M6IDB4MDAwMDAwMDAwMDAKCUVuZGluZyBBZGRyZXNzOiAw eDAwMEZGRkZGRkZGCglSYW5nZSBTaXplOiA0IEdCCglQaHlzaWNhbCBEZXZpY2UgSGFuZGxlOiAw eDAwMjUKCU1lbW9yeSBBcnJheSBNYXBwZWQgQWRkcmVzcyBIYW5kbGU6IDB4MDAyNAoJUGFydGl0 aW9uIFJvdyBQb3NpdGlvbjogVW5rbm93bgoJSW50ZXJsZWF2ZSBQb3NpdGlvbjogMQoJSW50ZXJs ZWF2ZWQgRGF0YSBEZXB0aDogMgoKSGFuZGxlIDB4MDAyNywgRE1JIHR5cGUgMTcsIDg0IGJ5dGVz Ck1lbW9yeSBEZXZpY2UKCUFycmF5IEhhbmRsZTogMHgwMDIzCglFcnJvciBJbmZvcm1hdGlvbiBI YW5kbGU6IE5vdCBQcm92aWRlZAoJVG90YWwgV2lkdGg6IDE2IGJpdHMKCURhdGEgV2lkdGg6IDE2 IGJpdHMKCVNpemU6IDQgR0IKCUZvcm0gRmFjdG9yOiBESU1NCglTZXQ6IE5vbmUKCUxvY2F0b3I6 IEExX0RJTU0xCglCYW5rIExvY2F0b3I6IEExX0JBTksxCglUeXBlOiBMUEREUjQKCVR5cGUgRGV0 YWlsOiBTeW5jaHJvbm91cwoJU3BlZWQ6IDIxMzMgTVQvcwoJTWFudWZhY3R1cmVyOiBBQkNECglT ZXJpYWwgTnVtYmVyOiAxMjM0CglBc3NldCBUYWc6IDk4NzY1NDMyMTAKCVBhcnQgTnVtYmVyOiAx MjM0NTY3ODkwMTIzNDU2NzgKCVJhbms6IFVua25vd24KCUNvbmZpZ3VyZWQgTWVtb3J5IFNwZWVk OiAyMTMzIE1UL3MKCU1pbmltdW0gVm9sdGFnZTogMS4xIFYKCU1heGltdW0gVm9sdGFnZTogMS41 IFYKCUNvbmZpZ3VyZWQgVm9sdGFnZTogMS4xIFYKCU1lbW9yeSBUZWNobm9sb2d5OiBEUkFNCglN ZW1vcnkgT3BlcmF0aW5nIE1vZGUgQ2FwYWJpbGl0eTogVm9sYXRpbGUgbWVtb3J5CglGaXJtd2Fy ZSBWZXJzaW9uOiBOb3QgU3BlY2lmaWVkCglNb2R1bGUgTWFudWZhY3R1cmVyIElEOiBVbmtub3du CglNb2R1bGUgUHJvZHVjdCBJRDogVW5rbm93bgoJTWVtb3J5IFN1YnN5c3RlbSBDb250cm9sbGVy IE1hbnVmYWN0dXJlciBJRDogVW5rbm93bgoJTWVtb3J5IFN1YnN5c3RlbSBDb250cm9sbGVyIFBy b2R1Y3QgSUQ6IFVua25vd24KCU5vbi1Wb2xhdGlsZSBTaXplOiBOb25lCglWb2xhdGlsZSBTaXpl OiA0IEdCCglDYWNoZSBTaXplOiBOb25lCglMb2dpY2FsIFNpemU6IE5vbmUKCkhhbmRsZSAweDAw MjgsIERNSSB0eXBlIDIwLCAzNSBieXRlcwpNZW1vcnkgRGV2aWNlIE1hcHBlZCBBZGRyZXNzCglT dGFydGluZyBBZGRyZXNzOiAweDAwMTAwMDAwMDAwCglFbmRpbmcgQWRkcmVzczogMHgwMDFGRkZG RkZGRgoJUmFuZ2UgU2l6ZTogNCBHQgoJUGh5c2ljYWwgRGV2aWNlIEhhbmRsZTogMHgwMDI3CglN ZW1vcnkgQXJyYXkgTWFwcGVkIEFkZHJlc3MgSGFuZGxlOiAweDAwMjQKCVBhcnRpdGlvbiBSb3cg UG9zaXRpb246IFVua25vd24KCUludGVybGVhdmUgUG9zaXRpb246IDIKCUludGVybGVhdmVkIERh dGEgRGVwdGg6IDIKCkhhbmRsZSAweDAwMjksIERNSSB0eXBlIDMyLCAyMCBieXRlcwpTeXN0ZW0g Qm9vdCBJbmZvcm1hdGlvbgoJU3RhdHVzOiBObyBlcnJvcnMgZGV0ZWN0ZWQKCkhhbmRsZSAweDAw MkEsIERNSSB0eXBlIDQzLCAzMSBieXRlcwpUUE0gRGV2aWNlCglWZW5kb3IgSUQ6IENUTkkKCVNw ZWNpZmljYXRpb24gVmVyc2lvbjogMi4wCglGaXJtd2FyZSBSZXZpc2lvbjogNDAyLjAKCURlc2Ny aXB0aW9uOiBJTlRFTAoJQ2hhcmFjdGVyaXN0aWNzOgoJCUZhbWlseSBjb25maWd1cmFibGUgdmlh IHBsYXRmb3JtIHNvZnR3YXJlIHN1cHBvcnQKCU9FTS1zcGVjaWZpYyBJbmZvcm1hdGlvbjogMHgw MDAwMDAwMAoKSGFuZGxlIDB4MDAyRiwgRE1JIHR5cGUgNywgMjcgYnl0ZXMKQ2FjaGUgSW5mb3Jt YXRpb24KCVNvY2tldCBEZXNpZ25hdGlvbjogQ1BVIEludGVybmFsIEwxCglDb25maWd1cmF0aW9u OiBFbmFibGVkLCBOb3QgU29ja2V0ZWQsIExldmVsIDEKCU9wZXJhdGlvbmFsIE1vZGU6IFdyaXRl IEJhY2sKCUxvY2F0aW9uOiBJbnRlcm5hbAoJSW5zdGFsbGVkIFNpemU6IDE2ODAgR0IKCU1heGlt dW0gU2l6ZTogMTc2MCBHQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJU3luY2hyb25vdXMKCUlu c3RhbGxlZCBTUkFNIFR5cGU6IFN5bmNocm9ub3VzCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29y cmVjdGlvbiBUeXBlOiBQYXJpdHkKCVN5c3RlbSBUeXBlOiBPdGhlcgoJQXNzb2NpYXRpdml0eTog T3RoZXIKCkhhbmRsZSAweDAwMzAsIERNSSB0eXBlIDcsIDI3IGJ5dGVzCkNhY2hlIEluZm9ybWF0 aW9uCglTb2NrZXQgRGVzaWduYXRpb246IENQVSBJbnRlcm5hbCBMMgoJQ29uZmlndXJhdGlvbjog RW5hYmxlZCwgTm90IFNvY2tldGVkLCBMZXZlbCAyCglPcGVyYXRpb25hbCBNb2RlOiBXcml0ZSBC YWNrCglMb2NhdGlvbjogSW50ZXJuYWwKCUluc3RhbGxlZCBTaXplOiAxMDgzIEdCCglNYXhpbXVt IFNpemU6IDExNyBrQgoJU3VwcG9ydGVkIFNSQU0gVHlwZXM6CgkJU3luY2hyb25vdXMKCUluc3Rh bGxlZCBTUkFNIFR5cGU6IFN5bmNocm9ub3VzCglTcGVlZDogVW5rbm93bgoJRXJyb3IgQ29ycmVj dGlvbiBUeXBlOiBTaW5nbGUtYml0IEVDQwoJU3lzdGVtIFR5cGU6IFVuaWZpZWQKCUFzc29jaWF0 aXZpdHk6IDE2LXdheSBTZXQtYXNzb2NpYXRpdmUKCkhhbmRsZSAweDAwMzEsIERNSSB0eXBlIDQs IDQ4IGJ5dGVzClByb2Nlc3NvciBJbmZvcm1hdGlvbgoJU29ja2V0IERlc2lnbmF0aW9uOiBTT0NL RVQgMAoJVHlwZTogQ2VudHJhbCBQcm9jZXNzb3IKCUZhbWlseTogQ2VsZXJvbgoJTWFudWZhY3R1 cmVyOiBJbnRlbAoJSUQ6IEE4IDA2IDA3IDAwIEZGIEZCIEVCIEJGCglTaWduYXR1cmU6IFR5cGUg MCwgRmFtaWx5IDYsIE1vZGVsIDEyMiwgU3RlcHBpbmcgOAoJRmxhZ3M6CgkJRlBVIChGbG9hdGlu Zy1wb2ludCB1bml0IG9uLWNoaXApCgkJVk1FIChWaXJ0dWFsIG1vZGUgZXh0ZW5zaW9uKQoJCURF IChEZWJ1Z2dpbmcgZXh0ZW5zaW9uKQoJCVBTRSAoUGFnZSBzaXplIGV4dGVuc2lvbikKCQlUU0Mg KFRpbWUgc3RhbXAgY291bnRlcikKCQlNU1IgKE1vZGVsIHNwZWNpZmljIHJlZ2lzdGVycykKCQlQ QUUgKFBoeXNpY2FsIGFkZHJlc3MgZXh0ZW5zaW9uKQoJCU1DRSAoTWFjaGluZSBjaGVjayBleGNl cHRpb24pCgkJQ1g4IChDTVBYQ0hHOCBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJQVBJQyAoT24t Y2hpcCBBUElDIGhhcmR3YXJlIHN1cHBvcnRlZCkKCQlTRVAgKEZhc3Qgc3lzdGVtIGNhbGwpCgkJ TVRSUiAoTWVtb3J5IHR5cGUgcmFuZ2UgcmVnaXN0ZXJzKQoJCVBHRSAoUGFnZSBnbG9iYWwgZW5h YmxlKQoJCU1DQSAoTWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUpCgkJQ01PViAoQ29uZGl0aW9u YWwgbW92ZSBpbnN0cnVjdGlvbiBzdXBwb3J0ZWQpCgkJUEFUIChQYWdlIGF0dHJpYnV0ZSB0YWJs ZSkKCQlQU0UtMzYgKDM2LWJpdCBwYWdlIHNpemUgZXh0ZW5zaW9uKQoJCUNMRlNIIChDTEZMVVNI IGluc3RydWN0aW9uIHN1cHBvcnRlZCkKCQlEUyAoRGVidWcgc3RvcmUpCgkJQUNQSSAoQUNQSSBz dXBwb3J0ZWQpCgkJTU1YIChNTVggdGVjaG5vbG9neSBzdXBwb3J0ZWQpCgkJRlhTUiAoRlhTQVZF IGFuZCBGWFNUT1IgaW5zdHJ1Y3Rpb25zIHN1cHBvcnRlZCkKCQlTU0UgKFN0cmVhbWluZyBTSU1E IGV4dGVuc2lvbnMpCgkJU1NFMiAoU3RyZWFtaW5nIFNJTUQgZXh0ZW5zaW9ucyAyKQoJCVNTIChT ZWxmLXNub29wKQoJCUhUVCAoTXVsdGktdGhyZWFkaW5nKQoJCVRNIChUaGVybWFsIG1vbml0b3Ig c3VwcG9ydGVkKQoJCVBCRSAoUGVuZGluZyBicmVhayBlbmFibGVkKQoJVmVyc2lvbjogSW50ZWwo UikgQ2VsZXJvbihSKSBONDEyMCBDUFUgQCAxLjEwR0h6CglWb2x0YWdlOiAxLjIgVgoJRXh0ZXJu YWwgQ2xvY2s6IDEwMCBNSHoKCU1heCBTcGVlZDogMjcwMCBNSHoKCUN1cnJlbnQgU3BlZWQ6IDEx MDAgTUh6CglTdGF0dXM6IFBvcHVsYXRlZCwgRW5hYmxlZAoJVXBncmFkZTogT3RoZXIKCUwxIENh Y2hlIEhhbmRsZTogMHgwMDJGCglMMiBDYWNoZSBIYW5kbGU6IDB4MDAzMAoJTDMgQ2FjaGUgSGFu ZGxlOiBOb3QgUHJvdmlkZWQKCVNlcmlhbCBOdW1iZXI6IE5vdCBTcGVjaWZpZWQKCUFzc2V0IFRh ZzogRmlsbCBCeSBPRU0KCVBhcnQgTnVtYmVyOiBGaWxsIEJ5IE9FTQoJQ29yZSBDb3VudDogNAoJ Q29yZSBFbmFibGVkOiA0CglUaHJlYWQgQ291bnQ6IDQKCUNoYXJhY3RlcmlzdGljczoKCQk2NC1i aXQgY2FwYWJsZQoKSGFuZGxlIDB4MDAzMiwgRE1JIHR5cGUgNDEsIDExIGJ5dGVzCk9uYm9hcmQg RGV2aWNlCglSZWZlcmVuY2UgRGVzaWduYXRpb246IE9uYm9hcmQgLSBSVEsgRXRoZXJuZXQKCVR5 cGU6IEV0aGVybmV0CglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDEKCUJ1cyBBZGRy ZXNzOiAwMDAwOjAyOjAwLjAKCkhhbmRsZSAweDAwMzMsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpP bmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5 cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDEKCUJ1cyBBZGRyZXNz OiAwMDAwOjAwOjAwLjAKCkhhbmRsZSAweDAwMzQsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJv YXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6 IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDIKCUJ1cyBBZGRyZXNzOiAw MDAwOjAwOjAwLjEKCkhhbmRsZSAweDAwMzUsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJk IERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gVmlkZW8KCVR5cGU6IFZp ZGVvCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDEKCUJ1cyBBZGRyZXNzOiAwMDAw OjAwOjAyLjAKCkhhbmRsZSAweDAwMzYsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERl dmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVy CglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDMKCUJ1cyBBZGRyZXNzOiAwMDAwOjAw OjBkLjAKCkhhbmRsZSAweDAwMzcsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmlj ZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglT dGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDQKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjBk LjIKCkhhbmRsZSAweDAwMzgsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJ UmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gU291bmQKCVR5cGU6IFNvdW5kCglTdGF0 dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDEKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjBlLjAK CkhhbmRsZSAweDAwMzksIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVm ZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6 IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDUKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjBmLjAKCkhh bmRsZSAweDAwM0EsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJl bmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gU0FUQQoJVHlwZTogU0FUQSBDb250cm9sbGVyCglT dGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDEKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjEy LjAKCkhhbmRsZSAweDAwM0IsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJ UmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0 dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDYKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE1LjAK CkhhbmRsZSAweDAwM0MsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVm ZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6 IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDcKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE2LjAKCkhh bmRsZSAweDAwM0QsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJl bmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVu YWJsZWQKCVR5cGUgSW5zdGFuY2U6IDgKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE2LjEKCkhhbmRs ZSAweDAwM0UsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNl IERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJs ZWQKCVR5cGUgSW5zdGFuY2U6IDkKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE2LjIKCkhhbmRsZSAw eDAwM0YsIERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERl c2lnbmF0aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQK CVR5cGUgSW5zdGFuY2U6IDEwCglCdXMgQWRkcmVzczogMDAwMDowMDoxNi4zCgpIYW5kbGUgMHgw MDQwLCBETUkgdHlwZSA0MSwgMTEgYnl0ZXMKT25ib2FyZCBEZXZpY2UKCVJlZmVyZW5jZSBEZXNp Z25hdGlvbjogT25ib2FyZCAtIE90aGVyCglUeXBlOiBPdGhlcgoJU3RhdHVzOiBFbmFibGVkCglU eXBlIEluc3RhbmNlOiAxMQoJQnVzIEFkZHJlc3M6IDAwMDA6MDA6MTcuMAoKSGFuZGxlIDB4MDA0 MSwgRE1JIHR5cGUgNDEsIDExIGJ5dGVzCk9uYm9hcmQgRGV2aWNlCglSZWZlcmVuY2UgRGVzaWdu YXRpb246IE9uYm9hcmQgLSBPdGhlcgoJVHlwZTogT3RoZXIKCVN0YXR1czogRW5hYmxlZAoJVHlw ZSBJbnN0YW5jZTogMTIKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE3LjEKCkhhbmRsZSAweDAwNDIs IERNSSB0eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0 aW9uOiBPbmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUg SW5zdGFuY2U6IDEzCglCdXMgQWRkcmVzczogMDAwMDowMDoxNy4yCgpIYW5kbGUgMHgwMDQzLCBE TUkgdHlwZSA0MSwgMTEgYnl0ZXMKT25ib2FyZCBEZXZpY2UKCVJlZmVyZW5jZSBEZXNpZ25hdGlv bjogT25ib2FyZCAtIE90aGVyCglUeXBlOiBPdGhlcgoJU3RhdHVzOiBFbmFibGVkCglUeXBlIElu c3RhbmNlOiAxNAoJQnVzIEFkZHJlc3M6IDAwMDA6MDA6MTcuMwoKSGFuZGxlIDB4MDA0NCwgRE1J IHR5cGUgNDEsIDExIGJ5dGVzCk9uYm9hcmQgRGV2aWNlCglSZWZlcmVuY2UgRGVzaWduYXRpb246 IE9uYm9hcmQgLSBPdGhlcgoJVHlwZTogT3RoZXIKCVN0YXR1czogRW5hYmxlZAoJVHlwZSBJbnN0 YW5jZTogMTUKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE4LjAKCkhhbmRsZSAweDAwNDUsIERNSSB0 eXBlIDQxLCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBP bmJvYXJkIC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFu Y2U6IDE2CglCdXMgQWRkcmVzczogMDAwMDowMDoxOC4xCgpIYW5kbGUgMHgwMDQ2LCBETUkgdHlw ZSA0MSwgMTEgYnl0ZXMKT25ib2FyZCBEZXZpY2UKCVJlZmVyZW5jZSBEZXNpZ25hdGlvbjogT25i b2FyZCAtIE90aGVyCglUeXBlOiBPdGhlcgoJU3RhdHVzOiBFbmFibGVkCglUeXBlIEluc3RhbmNl OiAxNwoJQnVzIEFkZHJlc3M6IDAwMDA6MDA6MTguMgoKSGFuZGxlIDB4MDA0NywgRE1JIHR5cGUg NDEsIDExIGJ5dGVzCk9uYm9hcmQgRGV2aWNlCglSZWZlcmVuY2UgRGVzaWduYXRpb246IE9uYm9h cmQgLSBPdGhlcgoJVHlwZTogT3RoZXIKCVN0YXR1czogRW5hYmxlZAoJVHlwZSBJbnN0YW5jZTog MTgKCUJ1cyBBZGRyZXNzOiAwMDAwOjAwOjE4LjMKCkhhbmRsZSAweDAwNDgsIERNSSB0eXBlIDQx LCAxMSBieXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJk IC0gT3RoZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDE5 CglCdXMgQWRkcmVzczogMDAwMDowMDoxOS4wCgpIYW5kbGUgMHgwMDQ5LCBETUkgdHlwZSA0MSwg MTEgYnl0ZXMKT25ib2FyZCBEZXZpY2UKCVJlZmVyZW5jZSBEZXNpZ25hdGlvbjogT25ib2FyZCAt IE90aGVyCglUeXBlOiBPdGhlcgoJU3RhdHVzOiBFbmFibGVkCglUeXBlIEluc3RhbmNlOiAyMAoJ QnVzIEFkZHJlc3M6IDAwMDA6MDA6MTkuMQoKSGFuZGxlIDB4MDA0QSwgRE1JIHR5cGUgNDEsIDEx IGJ5dGVzCk9uYm9hcmQgRGV2aWNlCglSZWZlcmVuY2UgRGVzaWduYXRpb246IE9uYm9hcmQgLSBP dGhlcgoJVHlwZTogT3RoZXIKCVN0YXR1czogRW5hYmxlZAoJVHlwZSBJbnN0YW5jZTogMjEKCUJ1 cyBBZGRyZXNzOiAwMDAwOjAwOjE5LjIKCkhhbmRsZSAweDAwNEIsIERNSSB0eXBlIDQxLCAxMSBi eXRlcwpPbmJvYXJkIERldmljZQoJUmVmZXJlbmNlIERlc2lnbmF0aW9uOiBPbmJvYXJkIC0gT3Ro ZXIKCVR5cGU6IE90aGVyCglTdGF0dXM6IEVuYWJsZWQKCVR5cGUgSW5zdGFuY2U6IDIyCglCdXMg QWRkcmVzczogMDAwMDowMDoxYy4wCgpIYW5kbGUgMHgwMDRDLCBETUkgdHlwZSA0MSwgMTEgYnl0 ZXMKT25ib2FyZCBEZXZpY2UKCVJlZmVyZW5jZSBEZXNpZ25hdGlvbjogT25ib2FyZCAtIE90aGVy CglUeXBlOiBPdGhlcgoJU3RhdHVzOiBFbmFibGVkCglUeXBlIEluc3RhbmNlOiAyMwoJQnVzIEFk ZHJlc3M6IDAwMDA6MDA6MWYuMAoKSGFuZGxlIDB4MDA0RCwgRE1JIHR5cGUgNDEsIDExIGJ5dGVz Ck9uYm9hcmQgRGV2aWNlCglSZWZlcmVuY2UgRGVzaWduYXRpb246IE9uYm9hcmQgLSBPdGhlcgoJ VHlwZTogT3RoZXIKCVN0YXR1czogRW5hYmxlZAoJVHlwZSBJbnN0YW5jZTogMjQKCUJ1cyBBZGRy ZXNzOiAwMDAwOjAwOjFmLjEKCkhhbmRsZSAweDAwNEUsIERNSSB0eXBlIDksIDE5IGJ5dGVzClN5 c3RlbSBTbG90IEluZm9ybWF0aW9uCglEZXNpZ25hdGlvbjogSjdIMQoJVHlwZTogeDQgUENJIEV4 cHJlc3MgMiB4NAoJQ3VycmVudCBVc2FnZTogSW4gVXNlCglMZW5ndGg6IFNob3J0CglJRDogMAoJ Q2hhcmFjdGVyaXN0aWNzOgoJCTMuMyBWIGlzIHByb3ZpZGVkCgkJT3BlbmluZyBpcyBzaGFyZWQK CQlQTUUgc2lnbmFsIGlzIHN1cHBvcnRlZAoJQnVzIEFkZHJlc3M6IDAwMDA6MDA6MTMuMAoJRGF0 YSBCdXMgV2lkdGg6IDEwCglQZWVyIERldmljZXM6IDAKCkhhbmRsZSAweDAwNEYsIERNSSB0eXBl IDksIDE5IGJ5dGVzClN5c3RlbSBTbG90IEluZm9ybWF0aW9uCglEZXNpZ25hdGlvbjogSjhIMQoJ VHlwZTogeDIgUENJIEV4cHJlc3MgMiB4MgoJQ3VycmVudCBVc2FnZTogQXZhaWxhYmxlCglMZW5n dGg6IFNob3J0CglJRDogMQoJQ2hhcmFjdGVyaXN0aWNzOgoJCTMuMyBWIGlzIHByb3ZpZGVkCgkJ T3BlbmluZyBpcyBzaGFyZWQKCQlQTUUgc2lnbmFsIGlzIHN1cHBvcnRlZAoJQnVzIEFkZHJlc3M6 IDAwMDA6MDA6MTQuMAoJRGF0YSBCdXMgV2lkdGg6IDkKCVBlZXIgRGV2aWNlczogMAoKSGFuZGxl IDB4MDA1MCwgRE1JIHR5cGUgMTMsIDIyIGJ5dGVzCkJJT1MgTGFuZ3VhZ2UgSW5mb3JtYXRpb24K CUxhbmd1YWdlIERlc2NyaXB0aW9uIEZvcm1hdDogTG9uZwoJSW5zdGFsbGFibGUgTGFuZ3VhZ2Vz OiAxCgkJZW58VVN8aXNvODg1OS0xCglDdXJyZW50bHkgSW5zdGFsbGVkIExhbmd1YWdlOiBlbnxV U3xpc284ODU5LTEKCkhhbmRsZSAweDAwNTEsIERNSSB0eXBlIDEyNywgNCBieXRlcwpFbmQgT2Yg VGFibGUKCg== --=_mailhost.netlabit.sk-4762-1646406970-0001-2-- From nobody Sat Mar 5 18:19:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 58B0219EB3BF for ; Sat, 5 Mar 2022 18:19:45 +0000 (UTC) (envelope-from georg.lastname@web.de) Received: from mout.web.de (mout.web.de [212.227.15.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.web.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9tKr1VXDz3PRP for ; Sat, 5 Mar 2022 18:19:44 +0000 (UTC) (envelope-from georg.lastname@web.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1646504375; bh=Rl9gorq04Z3egxI82VdtWdLO3qXtfl7pxcbAjg9M0ug=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=ULHQ51czWlix73p0xOOOADP4Z/uGAtn7BzaEEYgMdaqgWbbA8+IOJsglBp67+rpN5 IVkkmpWKZmD29tyYbt/N45qqBzEJAIxcyL7lmAL5RwTALU+lKhPVxYgGWVL75UKevC 0Ksz+sADQlOm5H1UJMUL6QePI9xrFfpCjLlCoCPQ= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [10.236.197.8] ([10.236.197.8]) by msvc-mesg-web112.server.lan (via HTTP); Sat, 5 Mar 2022 19:19:35 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-ID: From: georg.lastname@web.de To: Milan Obuch Cc: freebsd-hackers@freebsd.org Subject: Aw: GPD Micro PC power button and lid close [originally Re: GPD Micro PC serial port] Content-Type: text/plain; charset=UTF-8 Importance: normal Sensitivity: Normal Date: Sat, 5 Mar 2022 19:19:35 +0100 In-Reply-To: <20220304161609.5654c1b3@zeta.dino.sk> References: <20220304144235.26276414@zeta.dino.sk> <20220304161609.5654c1b3@zeta.dino.sk> X-Priority: 3 X-Provags-ID: V03:K1:140XLdCHKT+wKJzbecKw0TKC1DK5V3bVtD7tyDsDrLwbi4FFCsCNqCYFErqYb8U5xwEtT jsmLLSFl95us0g5eCYZpgbZ9Lm9561vMI8fEAj5nynrP6am8jIm0by4Z940Vw9zQ09Tan2am3hSM ix/L/8CLr/1BREwAhw6OoKIKGFRLFezGAMCnZ8dLGcxuFhY7f/BzGLh8fDN94BxW48gND8NdSD05 RFRy2yjQKt9XUoSqcLpD3lafJAppYzE3eoARCybNfND17TXsVPd3Ovk6LyK/43HtAiAM7gUg7gGw KVy/vexw+BUnl00FEQ8RYaK X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:M+M/4bRYs58=:hjFyHIKSTLp3Qj4Yx2eN/v +gQ44i6DYoMf9OxWRZd668r+KnqWide10aeufeTeLsEWYn2MouNskTeSDoo2okNTbfJpkNrfi KKniIYPAmOetMT9HYa+gdVvxJ1PsQx4eoKCI9vQa6Qa0StdhN6hKedwv1iofZiVrf07I0nhkY lSudMFRVMLKNCNmg1UJbwNI/V5kg2+Ks0xU0wCkqNGne18D/2HupGak4zlIGFBhpfO9t8RHmr NqA+ZN6bN9cpmqk6VaSX6+vfu4QV6EzSY+lM0ssOxO71NDRSSWJYSrMF/CRbFdmrAo94mZ4BQ +Fbw3nlweYncsatDqCYdT7bGFC7PRdbqJXHmV1LZkalXa+IT43xxT5+reRa1j/XgdUPIZeS1J pir7zcCqRuBYYqnyhSYxgOLwbDwNhzs9vowKcX2bQ/QOqKmHQCukcgtcsoCh7NctWaPWKAYhX Oq6C80GZhB7Ea1tgQx2TdErawLcrlFZdDGLwCiYV8xMdvrUej/FBdVd4XyBL6ghV5fJ1TvSah 2H3c+AebxxHBKms6cxdYVOf90MT8Orqz5WBQl+HBCKMNf+m+8j4X/D7hFXg8gid+zS/ow8tWg xnE4rPhGU1r7qfN7l8fqM2J7qeMtGQlFGq9zF3ndOGyBthYzX3FMHAs+UVzIQo9iXIv9b9hHh XKWuWzzLvM2vE8DVH4vVFF0wvp7abu9ZyrImcScxUr9EfJoXI+1Z2CmBr3TaxkI0shPXxAzMo B7OXOvd/yA36IWjWlgx675MZT6t+9kHlDz+6UpvdBlWZ8bepTzd59vKAwHuyFwdf/mzJTY94j RsbERkG Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4K9tKr1VXDz3PRP X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=web.de header.s=dbaedf251592 header.b=ULHQ51cz; dmarc=pass (policy=none) header.from=web.de; spf=pass (mx1.freebsd.org: domain of georg.lastname@web.de designates 212.227.15.3 as permitted sender) smtp.mailfrom=georg.lastname@web.de X-Spamd-Result: default: False [-4.60 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[web.de]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; RWL_MAILSPIKE_GOOD(0.00)[212.227.15.3:from]; DKIM_TRACE(0.00)[web.de:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[web.de,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[web.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.3:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[web.de:s=dbaedf251592]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[web.de:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > Gesendet: Freitag, den 04.03.2022 um 16:16 Uhr > Von: "Milan Obuch" > An: freebsd-hackers@freebsd.org > Betreff: GPD Micro PC power button and lid close [originally Re: GPD Mic= ro PC serial port] > > On Fri, 4 Mar 2022 20:51:50 +0700 > Eugene Grosbein wrote: > > > 04.03.2022 20:42, Milan Obuch wrote: > > > > > Hi, > > > > > > for mobile usage I've got Micro PC from GPD, some description and > > > data here: > > > > > > https://www.amazon.com/Industry-Portable-Computer-Notebook-Graphics/= dp/B07QYZHM8F > > > > > > I managed to install dual boot FreeBSD/Windows here. Working with > > > FreeBSD 13 here, it was possible to verify working ethernet, wifi, X > > > on both internal display and HDMI connected monitor, and all basic > > > devices. > > > > > > I've put dmesg from at > > > https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D6461 > > > > > > There is one think I'd like to get into working state - serial > > > port. In Windows, it is COM2 with standard I/O address and IRQ, > > > however, I see nothing in FreeBSD... has somebody any hint for me? > > > > You seem to use custom kernel configuration. Did you try GENERIC? > > Can you share your kernel config? Also output of "pciconf -lv" > > and "dmidecode" commands ("pkg install dmidecode" for the latter). > > > > Yes, I use custom kernel, basically MINIMAL with some modules loaded > via loader.conf, other automatically and i915kms from rc.conf. As I > verified correct values are in device.hints, I found the solution - > loading module uart.ko from running system installed uart2..uart5 (no > idea what it is used for, you'll see them in some data provided), but > loading it from loader.conf brings uart1..uart5. Problem solved, I just > verified it is exactly the port on back. > > Just for info, output from 'pciconf -lv' is attached. 'dmidecode' > output added as well. Now, with serial port working, I see there is > something else I forgot - power button does nothing when FreeBSD is > running, just long press powers it off without proper shutdown > sequence. 'dmesg | grep acpi' tells > > acpi0: > cpu0: on acpi0 > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > atrtc0: port 0x70-0x77 on acpi0 > hpet0: iomem 0xfed00000-0xfed003ff irq 8 on= acpi0 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > > so there should be something handling power button (and lid close > event, as well). Any idea here? > > Regards, > Milan Hey, You can turn on verbose logging of acpi with "hw.acpi.verbose" kernel envi= ronment variable. On pressing the power button, you should see the log "po= wer button pressed\n" and maybe more.. Maybe this cpu doesnt support sleep state S5 (I'm a noob), as it should be= triggered when pressing the power button (see the hw.acpi.power_button_s= tate sysctl). From nobody Sat Mar 5 18:40:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8ED5919EF82F for ; Sat, 5 Mar 2022 18:40:31 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9tnp2ynkz3gyV for ; Sat, 5 Mar 2022 18:40:30 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mailhost.netlabit.sk with ESMTPSA; Sat, 05 Mar 2022 19:40:21 +0100 id 00DADC7E.6223AE95.0000C17B Date: Sat, 5 Mar 2022 19:40:20 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: Re: GPD Micro PC power button and lid close Message-ID: <20220305194020.1b86f11c@zeta.dino.sk> In-Reply-To: References: <20220304144235.26276414@zeta.dino.sk> <20220304161609.5654c1b3@zeta.dino.sk> X-Mailer: Claws Mail 3.18.0git333 (GTK+ 2.24.33; i386-portbld-freebsd11.4) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K9tnp2ynkz3gyV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-hackers@dino.sk designates 84.245.65.72 as permitted sender) smtp.mailfrom=freebsd-hackers@dino.sk X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 5 Mar 2022 19:19:35 +0100 georg.lastname@web.de wrote: > > Gesendet: Freitag, den 04.03.2022 um 16:16 Uhr > > Von: "Milan Obuch" > > An: freebsd-hackers@freebsd.org > > Betreff: GPD Micro PC power button and lid close [originally Re: > > GPD Micro PC serial port] [ snip ] > > Just for info, output from 'pciconf -lv' is attached. 'dmidecode' > > output added as well. Now, with serial port working, I see there is > > something else I forgot - power button does nothing when FreeBSD is > > running, just long press powers it off without proper shutdown > > sequence. 'dmesg | grep acpi' tells > > > > acpi0: > > cpu0: on acpi0 > > attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 > > atrtc0: port 0x70-0x77 on acpi0 > > hpet0: iomem 0xfed00000-0xfed003ff irq > > 8 on acpi0 acpi_timer0: <32-bit timer at 3.579545MHz> port > > 0x408-0x40b on acpi0 acpi_ec0: port > > 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff > > on acpi0 acpi_button0: on acpi0 > > acpi_tz0: on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > > acpi_acad0: on acpi0 > > battery0: on acpi0 > > acpi_lid0: on acpi0 > > > > so there should be something handling power button (and lid close > > event, as well). Any idea here? > > > > Regards, > > Milan > > Hey, > > You can turn on verbose logging of acpi with "hw.acpi.verbose" kernel > environment variable. On pressing the power button, you should see > the log "power button pressed\n" and maybe more.. Maybe this cpu > doesnt support sleep state S5 (I'm a noob), as it should be triggered > when pressing the power button (see the hw.acpi.power_button_state > sysctl). > This is output of 'sysctl hw.acpi' (minus battery, acline and thermal objects, not relevant here): hw.acpi.cpu.cx_lowest: C1 hw.acpi.reset_video: 0 hw.acpi.handle_reboot: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 1 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.suspend_state: S3 hw.acpi.standby_state: NONE hw.acpi.lid_switch_state: NONE hw.acpi.sleep_button_state: S3 hw.acpi.power_button_state: S5 hw.acpi.supported_sleep_state: S3 S4 S5 Setting hw.acpi.verbose to 1 did not achieve anything in console log, i.e. pressing power button does not geenrate any event logged there. Regards, Milan From nobody Fri Mar 11 02:21:18 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BA8F61A1BA0F; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KF8nC4c0Wz4gLD; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646965279; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=uJP7+WG22kNTkZZMa+ZoHfGOuI5Gy+T7XJ4OPziUd2Q=; b=aQAJERfb9wYfKbjEJidt/JdZTPL6SHO4M2NE+wrtqo/drgdj4bgRg7dRyuVeAHi6QqmAmR 6+EoHu6rSNJRYu1rx+TEs7wpdd9llN5jf2ZCoabtBixXVe1Vk+4jMPiFP62TTRg10qazhl kSQUUXpyCujE4Z0QQv3ZUsZyJdos4QTjkvDVFvWXmUOfNi0y6kkI3keJQDQxmXGbsdWykT yf+b138cJYjMmPPkksEYmDgSWypkaGEHlKRKWLxxP5ePudE/VcVbbQKkwKMIlNof2mHEEl 69Z7zbmGOt9I1rLelRQygCJzUqSjV/XTyC0pvt333N9fFXwcXGztux3hLJ4frg== Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-173-250.dhcp-dynamic.fibreop.ns.bellaliant.net [156.34.173.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jrm/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 11CBF26C04; Fri, 11 Mar 2022 02:21:19 +0000 (UTC) (envelope-from jrm@freebsd.org) From: Joseph Mingrone To: hackers@FreeBSD.org Cc: current@FreeBSD.org, stable@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Fourth Quarter 2021 Date: Thu, 10 Mar 2022 22:21:18 -0400 Message-ID: <86czitgrfl.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646965279; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=uJP7+WG22kNTkZZMa+ZoHfGOuI5Gy+T7XJ4OPziUd2Q=; b=b0/cK2n/RpWd5wZk1ZJFLfwLH0fzc6En1vgKoZiys4inzpAUXfr06Ono2muvK1r7rBI8Os OBVZTc0RStrJZNrtEm96iYbXK1i3O/0keS2TgHF/ZJ4i2I3MFXl9zE/agDsL6FkQIOao2k hl7a5gouO3RAVUwcHJFDMm0yA7XejXTIHE5yvaelAzKts6rT8Oi/6o0H1tX45CbsMOFWUn wGeWKKNjgfeABTINaWfTohI/zkHXk1+HTqp0LX91rq/nkCzrE2H0IZFWO/X92L9o9n+3zh 50ok5OKFG/+2IUU9HnShG4RDr9Khyul5XjqtDi+5NB5QeMiqcsl+4NZ8AfwwCw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646965279; a=rsa-sha256; cv=none; b=WqN8wneto/LPxwjYWUMvY97QqQ6EkJ1H7uOhdheEG9Rd3JVV8TTwn+cpfEQwHIK6swLsIS ZzMkAKJj9CgtmeNxXYxT8H57o/KcN/SZuc2OL4krhYecZdhnfXEcGLfPr5gL1xI1Ms+dlj DEAjOTPJB6JCC4fA5jAwXm5Ty56ySVJnPwsBNN8tgVve1aYprwJoHBokuiM4778uU+nYgx Xq6EoMfsAEypHevX1OK0dWGrlzia3Y4mNF0UnoQeq784kewZKdNsDsGnjwql6GuzM6hdOY Nu1fTZQ2RLBMu+Mp59E52SN8O83uAlUOhvYbcrI7vzKVVPGIKIuRYjOGIaknLg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RnJlZUJTRCBRdWFydGVybHkgU3RhdHVzIFJlcG9ydCA0dGggUXVhcnRlciAyMDIxDQoNClRoaXMg cmVwb3J0IGNvdmVycyBGcmVlQlNEIHJlbGF0ZWQgcHJvamVjdHMgZm9yIHRoZSBwZXJpb2QgYmV0 d2VlbiBPY3RvYmVyIGFuZA0KRGVjZW1iZXIuIEl0IGlzIHRoZSBmb3VydGggb2YgZm91ciBwbGFu bmVkIHJlcG9ydHMgZm9yIDIwMjEsIGFuZCBjb250YWlucyAxOQ0KZW50cmllcy4gSGlnaGxpZ2h0 cyBpbmNsdWRlIGZhc3RlciBib290IHRpbWVzLCBtb3JlIExMREIgd29yaywgYSBiYXNlIE9wZW5T U0gNCnVwZGF0ZSwgYW5kIG1vcmUgd2lyZWxlc3MgZGV2ZWxvcG1lbnQuDQoNCllvdXJzLA0KUGF1 IEFtbWEsIERhbmllbCBFYmRydXAsIEpvaG4tTWFyayBHdXJuZXksIGFuZCBKb2UgTWluZ3JvbmUN Cg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSBDQpUYWJsZSBvZiBDb250ZW50cw0KDQogIOKAoiBGcmVlQlNEIFRlYW0gUmVw b3J0cw0KICAgICAg4pahIEZyZWVCU0QgRm91bmRhdGlvbg0KICAgICAg4pahIFBvcnRzIENvbGxl Y3Rpb24NCiAgICAgIOKWoSBEb2N1bWVudGF0aW9uIEVuZ2luZWVyaW5nIFRlYW0NCiAgICAgIOKW oSBGcmVlQlNEIFdlYnNpdGUgUmV2YW1wIC0gV2ViQXBwcyB3b3JraW5nIGdyb3VwDQogIOKAoiBQ cm9qZWN0cw0KICAgICAg4pahIEVuYWJsZSBBU0xSIGJ5IGRlZmF1bHQgZm9yIDY0LWJpdCBleGVj dXRhYmxlcw0KICAgICAg4pahIEJvb3QgUGVyZm9ybWFuY2UgSW1wcm92ZW1lbnRzDQogICAgICDi lqEgTExEQiBEZWJ1Z2dlciBJbXByb3ZlbWVudHMNCiAgICAgIOKWoSBOWFAgTFMxMDI4QS8xMDI3 QSBTb0Mgc3VwcG9ydA0KICAgICAg4pahIHNjaGVkX2dldGNwdSgyKSwgbWVtYmFycmllcigyKSwg YW5kIHJzZXEoMikgc3lzY2FsbHMNCiAgICAgIOKWoSBCYXNlIFN5c3RlbSBPcGVuU1NIIFVwZGF0 ZQ0KICAgICAg4pahIFZEU08gb24gYW1kNjQNCiAg4oCiIEtlcm5lbA0KICAgICAg4pahIFRoZSBB VlggYnVnIG9uIGFtZDY0DQogICAgICDilqEgRU5BIEZyZWVCU0QgRHJpdmVyIFVwZGF0ZQ0KICAg ICAg4pahIEludGVsIFdpcmVsZXNzIGRyaXZlciBzdXBwb3J0DQogICAgICDilqEgS2VybmVsIENy eXB0byBjaGFuZ2VzIHRvIHN1cHBvcnQgV2lyZUd1YXJkDQogIOKAoiBQb3J0cw0KICAgICAg4pah IEtERSBvbiBGcmVlQlNEDQogICAgICDilqEgRnJlZUJTRCBPZmZpY2UgVGVhbQ0KICDigKIgVGhp cmQtUGFydHkgUHJvamVjdHMNCiAgICAgIOKWoSBoZWxsb1N5c3RlbQ0KICAgICAg4pahIENvbnRh aW5lcnMgJiBGcmVlQlNEOiBQb3QsIFBvdGx1Y2sgJiBQb3RtYW4NCg0K4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkZy ZWVCU0QgVGVhbSBSZXBvcnRzDQoNCkVudHJpZXMgZnJvbSB0aGUgdmFyaW91cyBvZmZpY2lhbCBh bmQgc2VtaS1vZmZpY2lhbCB0ZWFtcywgYXMgZm91bmQgaW4gdGhlDQpBZG1pbmlzdHJhdGlvbiBQ YWdlLg0KDQpGcmVlQlNEIEZvdW5kYXRpb24NCg0KTGlua3M6DQpGcmVlQlNEIEZvdW5kYXRpb24g VVJMOiBodHRwczovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcNClRlY2hub2xvZ3kgUm9hZG1h cCBVUkw6IGh0dHBzOi8vRnJlZUJTREZvdW5kYXRpb24ub3JnL2Jsb2cvdGVjaG5vbG9neS1yb2Fk bWFwLw0KRG9uYXRlIFVSTDogaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRpb24ub3JnL2RvbmF0 ZS8NCkZvdW5kYXRpb24gUGFydG5lcnNoaXAgUHJvZ3JhbSBVUkw6IGh0dHBzOi8vd3d3LkZyZWVC U0RGb3VuZGF0aW9uLm9yZy8NCkZyZWVCU0QtZm91bmRhdGlvbi1wYXJ0bmVyc2hpcC1wcm9ncmFt DQpGcmVlQlNEIEpvdXJuYWwgVVJMOiBodHRwczovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcv am91cm5hbC8NCkZvdW5kYXRpb24gTmV3cyBhbmQgRXZlbnRzIFVSTDogaHR0cHM6Ly93d3cuRnJl ZUJTREZvdW5kYXRpb24ub3JnLw0KbmV3cy1hbmQtZXZlbnRzLw0KDQpDb250YWN0OiBEZWIgR29v ZGtpbiA8ZGViQEZyZWVCU0RGb3VuZGF0aW9uLm9yZz4NCg0KVGhlIEZyZWVCU0QgRm91bmRhdGlv biBpcyBhIDUwMShjKSgzKSBub24tcHJvZml0IG9yZ2FuaXphdGlvbiBkZWRpY2F0ZWQgdG8NCnN1 cHBvcnRpbmcgYW5kIHByb21vdGluZyB0aGUgRnJlZUJTRCBQcm9qZWN0IGFuZCBjb21tdW5pdHkg d29ybGR3aWRlLiBEb25hdGlvbnMNCmZyb20gaW5kaXZpZHVhbHMgYW5kIGNvcnBvcmF0aW9ucyBh cmUgdXNlZCB0byBmdW5kIGFuZCBtYW5hZ2Ugc29mdHdhcmUNCmRldmVsb3BtZW50IHByb2plY3Rz LCBjb25mZXJlbmNlcywgYW5kIGRldmVsb3BlciBzdW1taXRzLiBXZSBhbHNvIHByb3ZpZGUNCnRy YXZlbCBncmFudHMgdG8gRnJlZUJTRCBjb250cmlidXRvcnMsIHB1cmNoYXNlIGFuZCBzdXBwb3J0 IGhhcmR3YXJlIHRvIGltcHJvdmUNCmFuZCBtYWludGFpbiBGcmVlQlNEIGluZnJhc3RydWN0dXJl LCBhbmQgcHJvdmlkZSByZXNvdXJjZXMgdG8gaW1wcm92ZSBzZWN1cml0eSwNCnF1YWxpdHkgYXNz dXJhbmNlLCBhbmQgcmVsZWFzZSBlbmdpbmVlcmluZyBlZmZvcnRzLiBXZSBwdWJsaXNoIG1hcmtl dGluZw0KbWF0ZXJpYWwgdG8gcHJvbW90ZSwgZWR1Y2F0ZSwgYW5kIGFkdm9jYXRlIGZvciB0aGUg RnJlZUJTRCBQcm9qZWN0LCBmYWNpbGl0YXRlDQpjb2xsYWJvcmF0aW9uIGJldHdlZW4gY29tbWVy Y2lhbCB2ZW5kb3JzIGFuZCBGcmVlQlNEIGRldmVsb3BlcnMsIGFuZCBmaW5hbGx5LA0KcmVwcmVz ZW50IHRoZSBGcmVlQlNEIFByb2plY3QgaW4gZXhlY3V0aW5nIGNvbnRyYWN0cywgbGljZW5zZSBh Z3JlZW1lbnRzLCBhbmQNCm90aGVyIGxlZ2FsIGFycmFuZ2VtZW50cyB0aGF0IHJlcXVpcmUgYSBy ZWNvZ25pemVkIGxlZ2FsIGVudGl0eS4NCg0KSGVyZSBhcmUgc29tZSBoaWdobGlnaHRzIG9mIHdo YXQgd2UgZGlkIHRvIGhlbHAgRnJlZUJTRCBsYXN0IHF1YXJ0ZXI6DQoNCkZ1bmRyYWlzaW5nIEVm Zm9ydHMNCg0KV2UgZGlkIGl0ISBXZSBtZXQgb3VyIDIwMjEgZnVuZHJhaXNpbmcgZ29hbCBieSBy YWlzaW5nICQxLDI4MSw0MzchISBPbiBiZWhhbGYNCm9mIHRoZSBGb3VuZGF0aW9uLCBJIHdhbnQg dG8gdGhhbmsgeW91IGZvciB5b3VyIGZpbmFuY2lhbCBzdXBwb3J0IGxhc3QgeWVhciwNCnRoYXQg d2lsbCBoZWxwIHVzIGNvbnRpbnVlIGFuZCBpbmNyZWFzZSBvdXIgc3VwcG9ydCBmb3IgRnJlZUJT RCBpbiAyMDIyLiBJbg0KYWRkaXRpb24sIGZvbGtzIGFyZSBhbHJlYWR5IHNlbmRpbmcgdXMgdGhl aXIgMjAyMiBjb250cmlidXRpb25zLCB3aGljaCBpcw0KaW5jcmVkaWJseSBoZWFydHdhcm1pbmch IFdl4oCZbGwgc3RhcnQgdXBkYXRpbmcgdGhlIGZ1bmRyYWlzaW5nIG1ldGVyIGZvciAyMDIyIGJ5 DQp0aGUgZW5kIG9mIEphbnVhcnkuDQoNCkluIHRoaXMgUXVhcnRlcmx5IFN0YXR1cyByZXBvcnQg eW914oCZbGwgcmVhZCBhYm91dCBtYW55IG9mIHRoZSBhcmVhcyB3ZSBmdW5kZWQNCmluIFE0IHRv IGltcHJvdmUgRnJlZUJTRCBhbmQgYWR2b2NhdGUgZm9yIHRoZSBQcm9qZWN0ICh0aGUgdHdvIG1h aW4gYXJlYXMgd2UNCnNwZW5kIG1vbmV5IG9uKS4gQ2hlY2sgb3V0IHJlcG9ydHMgb24gdGhlIGV4 dGVybmFsbHkgZnVuZGVkIHByb2plY3RzIGxpa2UgTExEQg0Kc3VwcG9ydCwgUmFpZC1aIEV4cGFu c2lvbiwgV2lyZUd1YXJkLCBhbmQgd2lmaSwgYXMgd2VsbCBhcywgaW50ZXJuYWxseQ0Kc3VwcG9y dGVkIHdvcmsgbGlrZSBpbXByb3ZlZCBzZWN1cml0eSwgdGllci0xIGFyY2hpdGVjdHVyZSBzdXBw b3J0LCBhbmQNCnByb3ZpZGluZyBvbmxpbmUgb3Bwb3J0dW5pdGllcyB0byBjb25uZWN0IGFuZCBl ZHVjYXRlIHRoZSBjb21tdW5pdHkuDQoNCklmIHlvdSB3YW50IHRvIGhlbHAgdXMgY29udGludWUg b3VyIGVmZm9ydHMsIHBsZWFzZSBjb25zaWRlciBtYWtpbmcgYSBkb25hdGlvbg0KdG93YXJkcyBv dXIgMjAyMiBmdW5kcmFpc2luZyBjYW1wYWlnbiEgaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRp b24ub3JnL2RvbmF0ZS8uDQoNCldlIGFsc28gaGF2ZSBhIFBhcnRuZXJzaGlwIFByb2dyYW0gZm9y IGxhcmdlciBjb21tZXJjaWFsIGRvbm9ycy4gWW91IGNhbiByZWFkDQphYm91dCBpdCBhdCBodHRw czovL3d3dy5GcmVlQlNERm91bmRhdGlvbi5vcmcvDQpGcmVlQlNELWZvdW5kYXRpb24tcGFydG5l cnNoaXAtcHJvZ3JhbS8uDQoNCk9TIEltcHJvdmVtZW50cw0KDQpEdXJpbmcgdGhlIGZvdXJ0aCBx dWFydGVyLCBGb3VuZGF0aW9uIHN0YWZmIGFuZCBncmFudCByZWNpcGllbnRzIGNvbW1pdHRlZCA0 NzINCnNyYyB0cmVlIGNoYW5nZXMsIDk4IHBvcnRzIHRyZWUgY2hhbmdlcywgYW5kIDExIGRvYyB0 cmVlIGNoYW5nZXMuIFRoaXMNCnJlcHJlc2VudHMgNDElLCA0MSUsIGFuZCAxMyUgb2Ygc3JjLCBw b3J0cywgYW5kIGRvYyBjb21taXRzIGlkZW50aWZ5aW5nIGENCnNwb25zb3IuDQoNCllvdSBjYW4g cmVhZCBhYm91dCBGb3VuZGF0aW9uLXNwb25zb3JlZCBwcm9qZWN0cyBpbiBpbmRpdmlkdWFsIHF1 YXJ0ZXJseSByZXBvcnQNCmVudHJpZXM6DQoNCiAg4oCiIFRoZSBBVlggYnVnIG9uIGFtZDY0DQoN CiAg4oCiIENyeXB0byBjaGFuZ2VzIGZvciBXaXJlR3VyYXJkDQoNCiAg4oCiIEludGVsIFdpcmVs ZXNzIGRyaXZlciBzdXBwb3J0DQoNCiAg4oCiIExMREIgRGVidWdnZXIgSW1wcm92ZW1lbnRzDQoN CiAg4oCiIEJhc2UgU3lzdGVtIE9wZW5TU0ggVXBkYXRlDQoNCiAg4oCiIHNjaGVkX2dldGNwdSgy KSwgbWVtYmFycmllcigyKSwgYW5kIHJzZXEoMikgc3lzY2FsbHMNCg0KICDigKIgVkRTTyBvbiBh bWQ2NA0KDQpIZXJlIGlzIGEgc21hbGwgc2FtcGxlIG9mIG90aGVyIGJhc2Ugc3lzdGVtIGltcHJv dmVtZW50cyBmcm9tIEZvdW5kYXRpb24NCmRldmVsb3BlcnMgdGhpcyBxdWFydGVyIHRoYXQgZG8g bm90IGhhdmUgc2VwYXJhdGUgcmVwb3J0IGVudHJpZXMuDQoNCmtlcm4ucHJvYy5wYXRobmFtZSBj YW5vbmljYWwgaGFyZCBsaW5rDQoNClNvbWUgcHJvZ3JhbXMgYWRqdXN0IHRoZWlyIGJlaGF2aW9y IGRlcGVuZGluZyBvbiB3aGljaCBuYW1lIHdhcyB1c2VkIGZvcg0KZXhlY3V0aW9uLiBGb3IgdGhl c2UgcHJvZ3JhbXMsIGl0IGlzIG9mdGVuIGltcG9ydGFudCB0byBoYXZlIGEgY29uc2lzdGVudCBu YW1lDQppbiBhcmd2WzBdLCBzeXNjdGwga2Vybi5wcm9jLnBhdGhuYW1lLCBhdXh2IEFUX0VYRUNQ QVRILCBhbmQgYW55IHByb2NmcyBmaWxlDQpzeW1saW5rLiBCZWZvcmUgdGhpcyB3b3JrLCBhbGwg bGlzdGVkIGtlcm5lbCBpbnRlcmZhY2VzIHRyaWVkIHRvIGNhbGN1bGF0ZSBzb21lDQpuYW1lIGZv ciB0aGUgdGV4dCB2bm9kZSBhbmQgcmV0dXJuZWQgdGhlIHJlc3VsdC4gSWYgdGhlIGV4ZWN1dGVk IGJpbmFyeSBoYXMNCm1vcmUgdGhhbiBvbmUgaGFyZGxpbmssIHRoZSByZXR1cm5lZCBuYW1lcyB3 ZXJlIGFyYml0cmFyaWx5IGNob3NlbiBmcm9tIHRoZQ0KbGlzdCBvZiB2YWxpZCBuYW1lcyBmb3Ig dGhlIGZpbGUuIEFmdGVyIHdvcmsgY29tcGxldGVkIHRoaXMgcXVhcnRlciBieQ0KRm91bmRhdGlv biBkZXZlbG9wZXIgS29uc3RhbnRpbiBCZWxvdXNvdiwgdGhlIHN5c3RlbSBub3cgaG9sZHMgdGhl IHBhcmVudA0KZGlyZWN0b3J5IGFuZCB0aGUgbmFtZSBvZiB0aGUgdGV4dCBmaWxlIGZvciB0aGUg cnVubmluZyBpbWFnZS4gVGhpcyBpcyB1c2VkIHRvDQpyZWNvbnN0cnVjdCB0aGUgY29ycmVjdCBu YW1lIG9mIHRoZSB0ZXh0IGZpbGUgd2hlbiByZXF1ZXN0ZWQuDQoNCnN3YXBvbi9zd2Fwb2ZmLCBm aWxlIHN3YXBwaW5nDQoNCkFmdGVyIHdvcmsgdG8gZml4IGFzc2VydHMgZm9yIGNoYXJhY3RlciBk ZXZpY2Ugdm5vZGUgbG9ja2luZywgdGhlcmUgd2FzIGENCnJlcG9ydCB0aGF0IHN3YXAgb24gZmls ZSBjb2RlIGJyb2tlIHRoZSBWRlMgbG9ja2luZyBwcm90b2NvbC4gU29tZSBvdGhlcg0KcmVncmVz c2lvbnMgaW4gdGhlIHN3YXAgb24gZmlsZSB3ZXJlIGFsc28gaWRlbnRpZmllZC4gRm9yIGluc3Rh bmNlLCBvbg0Kc2h1dGRvd24sIGZpbGVzeXN0ZW1zIHdlcmUgdW5tb3VudGVkIGJlZm9yZSBzd2Fw b2ZmLCB3aGljaCBtYWtlcyBzd2Fwb2ZmIHBhbmljDQpvbiBwYWdlLWluLiBUaGVzZSBidWdzIHdl cmUgZml4ZWQgYW5kIGEgc3dhcG9mZigyKSBmZWF0dXJlIHdhcyBhZGRlZCB0byBhdm9pZA0Kc29t ZSB2ZXJ5IGNvbnNlcnZhdGl2ZSBlc3RpbWF0aW9ucyBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IG1l bW9yeSBhbmQgc3dhcCBzcGFjZQ0Kc2hvcnRhZ2VzLg0KDQpmY250bChGX0tJTkZPKQ0KDQpBcHBs aWNhdGlvbiBkZXZlbG9wZXJzIG9mdGVuIHJlcXVlc3QgYW4gaW50ZXJmYWNlIHRvIHJldHVybiB0 aGUgZmlsZSBwYXRoIGZvcg0KYW4gb3BlbiBmaWxlIGRlc2NyaXB0b3IuIE91ciBvbmx5IHVzZWZ1 bCBmYWNpbGl0eSBmb3IgdGhpcyB3YXMNCmtlcm4ucHJvYy5maWxlZGVzYyBzeXNjdGwsIHdoaWNo IGlzIHNvbWV3aGF0IHVzYWJsZSwgYnV0IGluY3VycyB0b28gaGlnaCBvZiBhbg0Kb3ZlcmhlYWQg d2hlbiBhIHByb2Nlc3MgaGFzIG1hbnkgb3BlbiBmaWxlcy4gQSBmY250bChGX0tJTkZPKSBpbnRl cmZhY2Ugd2FzDQphZGRlZCwgd2hpY2ggcmV0dXJucyBhIHN0cnVjdCBraW5mb19maWxlIGp1c3Qg Zm9yIHRoZSBzcGVjaWZpZWQgZmlsZQ0KZGVzY3JpcHRvci4gQW1vbmcgb3RoZXIgdXNlZnVsIGRh dGEsIGtpbmZvX2ZpbGUgcHJvdmlkZXMgdGhlIGNhbGN1bGF0ZWQgcGF0aCwNCndoZW4gYXZhaWxh YmxlLg0KDQpDb250aW51b3VzIEludGVncmF0aW9uIGFuZCBRdWFsaXR5IEFzc3VyYW5jZQ0KDQpU aGUgRm91bmRhdGlvbiBwcm92aWRlcyBhIGZ1bGwtdGltZSBzdGFmZiBtZW1iZXIgYW5kIGZ1bmRz IHByb2plY3RzIHRvIGltcHJvdmUNCmNvbnRpbnVvdXMgaW50ZWdyYXRpb24sIGF1dG9tYXRlZCB0 ZXN0aW5nLCBhbmQgb3ZlcmFsbCBxdWFsaXR5IGFzc3VyYW5jZQ0KZWZmb3J0cyBmb3IgdGhlIEZy ZWVCU0QgcHJvamVjdC4NCg0KU3VwcG9ydGluZyBGcmVlQlNEIEluZnJhc3RydWN0dXJlDQoNClRo ZSBGb3VuZGF0aW9uIHByb3ZpZGVzIGhhcmR3YXJlIGFuZCBzdXBwb3J0IGZvciB0aGUgUHJvamVj dC4gSW4gdGhlIGZvdXJ0aA0KcXVhcnRlciBvZiAyMDIxLCB3ZSBiZWdhbiBzZWFyY2hpbmcgZm9y IGEgbmV3IEF1c3RyYWxpYW4gbWlycm9yIHNlcnZlci4gQXQgdGhlDQp0aW1lIG9mIHdyaXRpbmcs IHRoZSBzZXJ2ZXIgaXMgcHVyY2hhc2VkLCBidXQgd2l0aCBkZWxheXMgb2J0YWluaW5nIGNvbXBv bmVudHMNCmFuZCBzaGlwcGluZywgaXQgbWF5IG5vdCBiZSBhY3RpdmUgdW50aWwgdGhlIHNlY29u ZCBvciB0aGlyZCBxdWFydGVyIG9mIDIwMjIuDQpCZXR0ZXIgYW5kIGZhc3RlciBhY2Nlc3MgdG8g b3VyIHNpdGVzIGZvciB0aGUgQXVzdHJhbGlhbiBGcmVlQlNEIGNvbW11bml0eSBpcw0KY29taW5n Lg0KDQpGcmVlQlNEIEFkdm9jYWN5IGFuZCBFZHVjYXRpb24NCg0KTXVjaCBvZiBvdXIgZWZmb3J0 IGlzIGRlZGljYXRlZCB0byBQcm9qZWN0IGFkdm9jYWN5LiBUaGlzIG1heSBpbnZvbHZlDQpoaWdo bGlnaHRpbmcgaW50ZXJlc3RpbmcgRnJlZUJTRCB3b3JrLCBwcm9kdWNpbmcgbGl0ZXJhdHVyZSwg YXR0ZW5kaW5nIGV2ZW50cywNCm9yIGdpdmluZyBwcmVzZW50YXRpb25zLiBUaGUgZ29hbCBvZiB0 aGUgbGl0ZXJhdHVyZSB3ZSBwcm9kdWNlIGlzIHRvIHRlYWNoDQpwZW9wbGUgRnJlZUJTRCBiYXNp Y3MgYW5kIGhlbHAgbWFrZSB0aGVpciBwYXRoIHRvIGFkb3B0aW9uIG9yIGNvbnRyaWJ1dGlvbg0K ZWFzaWVyLiBPdGhlciB0aGFuIGF0dGVuZGluZyBhbmQgcHJlc2VudGluZyBhdCBldmVudHMsIHdl IGVuY291cmFnZSBhbmQgaGVscA0KY29tbXVuaXR5IG1lbWJlcnMgcnVuIHRoZWlyIG93biBGcmVl QlNEIGV2ZW50cywgZ2l2ZSBwcmVzZW50YXRpb25zLCBvciBzdGFmZg0KRnJlZUJTRCB0YWJsZXMu DQoNClRoZSBGcmVlQlNEIEZvdW5kYXRpb24gc3BvbnNvcnMgbWFueSBjb25mZXJlbmNlcywgZXZl bnRzLCBhbmQgc3VtbWl0cyBhcm91bmQNCnRoZSBnbG9iZS4gVGhlc2UgZXZlbnRzIGNhbiBiZSBC U0QtcmVsYXRlZCwgb3BlbiBzb3VyY2UsIG9yIHRlY2hub2xvZ3kgZXZlbnRzDQpnZWFyZWQgdG93 YXJkcyB1bmRlcnJlcHJlc2VudGVkIGdyb3Vwcy4gV2Ugc3VwcG9ydCB0aGUgRnJlZUJTRC1mb2N1 c2VkIGV2ZW50cw0KdG8gaGVscCBwcm92aWRlIGEgdmVudWUgZm9yIHNoYXJpbmcga25vd2xlZGdl LCB3b3JraW5nIHRvZ2V0aGVyIG9uIHByb2plY3RzLA0KYW5kIGZhY2lsaXRhdGluZyBjb2xsYWJv cmF0aW9uIGJldHdlZW4gZGV2ZWxvcGVycyBhbmQgY29tbWVyY2lhbCB1c2Vycy4gVGhpcw0KYWxs IGhlbHBzIHByb3ZpZGUgYSBoZWFsdGh5IGVjb3N5c3RlbS4gV2Ugc3VwcG9ydCB0aGUgbm9uLUZy ZWVCU0QgZXZlbnRzIHRvDQpwcm9tb3RlIGFuZCByYWlzZSBhd2FyZW5lc3Mgb2YgRnJlZUJTRCwg dG8gaW5jcmVhc2UgdGhlIHVzZSBvZiBGcmVlQlNEIGluDQpkaWZmZXJlbnQgYXBwbGljYXRpb25z LCBhbmQgdG8gcmVjcnVpdCBtb3JlIGNvbnRyaWJ1dG9ycyB0byB0aGUgUHJvamVjdC4gV2UgYXJl DQpjb250aW51aW5nIHRvIGF0dGVuZCB2aXJ0dWFsIGV2ZW50cyBhbmQgaGVsZCBhIHZpcnR1YWwg dmVuZG9yIHN1bW1pdCB0aGlzIHBhc3QNCk5vdmVtYmVyLg0KDQpDaGVjayBvdXQgc29tZSBvZiB0 aGUgYWR2b2NhY3kgYW5kIGVkdWNhdGlvbiB3b3JrIHdlIGRpZCBsYXN0IHF1YXJ0ZXI6DQoNCiAg 4oCiIFByb21vdGVkIGFuZCBwYXJ0aWNpcGF0ZWQgYXMgYSBtZWRpYSBzcG9uc29yIGZvciBBTEwg VGhpbmdzIE9wZW4gMjAyMQ0KDQogIOKAoiBDb21taXR0ZWQgdG8gYmVpbmcgYSBNZWRpYSBTcG9u c29yIGZvciBTQ0FMRSAxOXgNCg0KICDigKIgQ29tbWl0dGVkIHRvIGhvc3RpbmcgYSBzdGFuZCBh dCBGT1NERU0gMjAyMg0KDQogIOKAoiBTZW50IG91dCB0aGUgRmFsbCAyMDIxIE5ld3NsZXR0ZXIN Cg0KICDigKIgSGVsZCBhIEZyZWVCU0QgRnJpZGF5IHRhbGs6IFRoZSBXcml0aW5nIFNjaG9sYXLi gJlzIEd1aWRlIHRvIEZyZWVCU0QsICh0ZXh0DQogICAgZXF1aXZhbGVudCkNCg0KICDigKIgR2F2 ZSBhIEZvdW5kYXRpb24gdGFsayBhdCBTZW1pLUJ1ZywgTm92ZW1iZXIgMTYsIDIwMjENCg0KICDi gKIgR2F2ZSBGb3VuZGF0aW9uIGFuZCBGcmVlQlNEIHRhbGtzIGF0IFNlYWdhdGUgT1NQTywgRGVj ZW1iZXIgOSwgMjAyMQ0KDQogIOKAoiBIZWxwZWQgb3JnYW5pemUgdGhlIDIgZGF5IEZyZWVCU0Qg VmlydHVhbCBWZW5kb3IgU3VtbWl0LCBOb3ZlbWJlciAxOC0xOSwNCiAgICAyMDIxLiBWaWRlb3Mg Y2FuIGJlIGZvdW5kIG9uIHRoZSBQcm9qZWN04oCZcyBZb3V0dWJlIENoYW5uZWwNCg0KICDigKIg TmV3IGJsb2cgYW5kIHZpZGVvIHBvc3RzOg0KDQogICAgICDilqEgRnJlZUJTRCBGb3VuZGF0aW9u IEZhbGwgMjAyMSBVcGRhdGUNCg0KICAgICAg4pahIDIwMjEgaW4gUmV2aWV3OiBBZHZvY2FjeQ0K DQogICAgICDilqEgMjAyMSBpbiBSZXZpZXc6IEluZnJhc3RydWN0dXJlIFN1cHBvcnQNCg0KICAg ICAg4pahIDIwMjEgaW4gUmV2aWV3OiBTb2Z0d2FyZSBEZXZlbG9wbWVudA0KDQogICAgICDilqEg T3BlbiBTb3VyY2UgU3VtbWl0IDIwMjEgQ29uZmVyZW5jZSBSZWNhcA0KDQogIOKAoiBOZXcgSG93 LVRvIEd1aWRlOiBJbnRyb2R1Y3Rpb24gdG8gRnJlZUJTRA0KDQpXZSBoZWxwIGVkdWNhdGUgdGhl IHdvcmxkIGFib3V0IEZyZWVCU0QgYnkgcHVibGlzaGluZyB0aGUgcHJvZmVzc2lvbmFsbHkNCnBy b2R1Y2VkIEZyZWVCU0QgSm91cm5hbC4gQXMgd2UgbWVudGlvbmVkIHByZXZpb3VzbHksIHRoZSBG cmVlQlNEIEpvdXJuYWwgaXMNCm5vdyBhIGZyZWUgcHVibGljYXRpb24uIEZpbmQgb3V0IG1vcmUg YW5kIGFjY2VzcyB0aGUgbGF0ZXN0IGlzc3VlcyBhdCBodHRwczovLw0Kd3d3LkZyZWVCU0Rmb3Vu ZGF0aW9uLm9yZy9qb3VybmFsLy4NCg0KWW91IGNhbiBmaW5kIG91dCBtb3JlIGFib3V0IGV2ZW50 cyB3ZSBhdHRlbmRlZCBhbmQgdXBjb21pbmcgZXZlbnRzIGF0IGh0dHBzOi8vDQp3d3cuRnJlZUJT RGZvdW5kYXRpb24ub3JnL25ld3MtYW5kLWV2ZW50cy8uDQoNCkxlZ2FsL0ZyZWVCU0QgSVANCg0K VGhlIEZvdW5kYXRpb24gb3ducyB0aGUgRnJlZUJTRCB0cmFkZW1hcmtzLCBhbmQgaXQgaXMgb3Vy IHJlc3BvbnNpYmlsaXR5IHRvDQpwcm90ZWN0IHRoZW0uIFdlIGFsc28gcHJvdmlkZSBsZWdhbCBz dXBwb3J0IGZvciB0aGUgY29yZSB0ZWFtIHRvIGludmVzdGlnYXRlDQpxdWVzdGlvbnMgdGhhdCBh cmlzZS4NCg0KR28gdG8gaHR0cHM6Ly93d3cuRnJlZUJTREZvdW5kYXRpb24ub3JnIHRvIGZpbmQg bW9yZSBhYm91dCBob3cgd2Ugc3VwcG9ydA0KRnJlZUJTRCBhbmQgaG93IHdlIGNhbiBoZWxwIHlv dSENCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSBDQoNClBvcnRzIENvbGxlY3Rpb24NCg0KTGlua3M6DQpBYm91dCBGcmVl QlNEIFBvcnRzIFVSTDogaHR0cHM6Ly93d3cuRnJlZUJTRC5vcmcvcG9ydHMvDQpDb250cmlidXRp bmcgdG8gUG9ydHMgVVJMOiBodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYXJ0aWNsZXMvY29u dHJpYnV0aW5nLyMNCnBvcnRzLWNvbnRyaWJ1dGluZw0KRnJlZUJTRCBQb3J0cyBNb25pdG9yaW5n IFVSTDogaHR0cDovL3BvcnRzbW9uLmZyZWVic2Qub3JnLw0KUG9ydHMgTWFuYWdlbWVudCBUZWFt IFVSTDogaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvcG9ydG1nci8NClBvcnRzIFRhcmJhbGwgVVJM OiBodHRwOi8vZnRwLmZyZWVic2Qub3JnL3B1Yi9GcmVlQlNEL3BvcnRzL3BvcnRzLw0KDQpDb250 YWN0OiBSZW7DqSBMYWRhbiA8cG9ydG1nci1zZWNyZXRhcnlARnJlZUJTRC5vcmc+DQpDb250YWN0 OiBGcmVlQlNEIFBvcnRzIE1hbmFnZW1lbnQgVGVhbSA8cG9ydG1nckBGcmVlQlNELm9yZz4NCg0K VGhlIFBvcnRzIE1hbmFnZW1lbnQgVGVhbSBpcyByZXNwb25zaWJsZSBmb3Igb3ZlcnNlZWluZyB0 aGUgb3ZlcmFsbCBkaXJlY3Rpb24NCm9mIHRoZSBQb3J0cyBUcmVlLCBidWlsZGluZyBwYWNrYWdl cywgYW5kIHBlcnNvbm5lbCBtYXR0ZXJzLiBCZWxvdyBpcyB3aGF0DQpoYXBwZW5lZCBpbiB0aGUg bGFzdCBxdWFydGVyLg0KDQpXZSBjdXJyZW50bHkgaGF2ZSA0Niw3MDAgcG9ydHMgaW4gdGhlIFBv cnRzIENvbGxlY3Rpb24gYWNjb3JkaW5nIHRvIEZyZXNoUG9ydHMuDQpUaGVyZSBhcmUgY3VycmVu dGx5IDIsNjY2IG9wZW4gcG9ydHMgUFJzIG9mIHdoaWNoIDYxMSBhcmUgdW5hc3NpZ25lZC4gVGhp cw0KcXVhcnRlciBzYXcgOSw1MzUgY29tbWl0cyBmcm9tIDE2NiBjb21taXR0ZXJzIG9uIHRoZSBt YWluIGJyYW5jaCBhbmQgNjQ0DQpjb21taXRzIGZyb20gNjIgY29tbWl0dGVycyBvbiB0aGUgcXVh cnRlcmx5IGJyYW5jaC4gQ29tcGFyZWQgdG8gbGFzdCBxdWFydGVyLA0KdGhpcyBtZWFucyBhIHNs aWdodCBkcm9wIGluIHRoZSBudW1iZXIgb2YgY29tbWl0cyBhbHRob3VnaCBtb3JlIGNvbW1pdHRl cnMgd2VyZQ0KYWN0aXZlLCBhbmQgYSBzbGlnaHQgaW5jcmVhc2UgaW4gdGhlIG51bWJlciBvZiBv cGVuIFBScy4NCg0KRHVyaW5nIHRoZSBsYXN0IHF1YXJ0ZXIsIHdlIHdlbGNvbWVkIERyaWVzIE1p Y2hpZWxzIChkcmllc21AKSBhbmQgc2FpZCBnb29kYnllDQp0byBrdXJpeWFtYUAgYW5kIGZqb2VA LiBUaGVyZSB3YXMgYWxzbyBhIGNoYW5nZSBpbiBwb3J0bWdyOiBhZGFtd0Agc3RlcHBlZCBkb3du DQphZnRlciBmaXZlIHllYXJzIG9mIHNlcnZpY2UgYW5kIHRjYmVybmVyQCBpcyBub3cgYSBmdWxs IG1lbWJlciBvZiBwb3J0bWdyQC4NCg0KVGhyZWUgbmV3IFVTRVMgd2VyZSBpbnRyb2R1Y2VkOg0K DQogIOKAoiBtYWdpY2sgdG8gaGFuZGxlIGRlcGVuZGVuY2llcyBvbiBJbWFnZU1hZ2ljaw0KDQog IOKAoiBub2RlanMgdG8gcHJvdmlkZSBzdXBwb3J0IGZvciBOb2RlSlMgKHdpdGggYSBuZXcgZGVm YXVsdCB2ZXJzaW9uIE5PREVKUz0NCiAgICBsdHMpDQoNCiAg4oCiIHRyaWdnZXIgdG8gaGFuZGxl IHBrZyB0cmlnZ2VycyB1c2luZyB0aGUgVFJJR0dFUlMgdmFyaWFibGUNCg0KVGhlIGRlZmF1bHQg dmVyc2lvbiBvZiBQR1NRTCBzd2l0Y2hlZCB0byAxMy4gRnVydGhlcm1vcmUsIElOU1RBTExTX0lD T05TIGhhcw0KYmVlbiByZXBsYWNlZCBieSBhIHRyaWdnZXIgb24gZ3RrLXVwZGF0ZS1pY29uLWNh Y2hlIGFuZCB0aGUgbWFjcm8gaXMgbm8gbG9uZ2VyDQpmdW5jdGlvbmFsLg0KDQpBcyBhbHdheXMs IHRoZXJlIHdlcmUgc29tZSB1cGRhdGVzIHRvICJiaWciIHBhY2thZ2VzOiBwa2cgd2FzIHVwZGF0 ZWQgdG8NCjEuMTcuNSwgQ2hyb21pdW0gdG8gOTQuMC40NjA2LjgxXzMsIGFuZCBGaXJlZm94IHRv IDk1LjAuMl8xLDIuIFJ1YnkgMy4xLjAgYW5kDQpQeXRob24gMy4xMSBhcmUgbm93IGF2YWlsYWJs ZSBmb3IgdXNlIGJ5IHVzZXJzIGFuZCBvdGhlciBwb3J0cy4NCg0K4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkRvY3Vt ZW50YXRpb24gRW5naW5lZXJpbmcgVGVhbQ0KDQpMaW5rczoNCkZyZWVCU0QgRG9jdW1lbnRhdGlv biBQcm9qZWN0IFVSTDogaHR0cHM6Ly93d3cuZnJlZWJzZC5vcmcvZG9jcHJvai8NCkZyZWVCU0Qg RG9jdW1lbnRhdGlvbiBQcm9qZWN0IFByaW1lciBmb3IgTmV3IENvbnRyaWJ1dG9ycyBVUkw6IGh0 dHBzOi8vDQpkb2NzLmZyZWVic2Qub3JnL2VuL2Jvb2tzL2ZkcC1wcmltZXIvDQpEb2N1bWVudGF0 aW9uIEVuZ2luZWVyaW5nIFRlYW0gVVJMOiBodHRwczovL3d3dy5mcmVlYnNkLm9yZy9hZG1pbmlz dHJhdGlvbi8jDQp0LWRvY2VuZw0KDQpDb250YWN0OiBGcmVlQlNEIERvY2VuZyBUZWFtIDxkb2Nl bmdARnJlZUJTRC5vcmc+DQoNClRoZSBkb2NlbmdAIHRlYW0gaXMgYSBib2R5IHRvIGhhbmRsZSBz b21lIG9mIHRoZSBtZXRhLXByb2plY3QgaXNzdWVzIGFzc29jaWF0ZWQNCndpdGggdGhlIEZyZWVC U0QgRG9jdW1lbnRhdGlvbiBQcm9qZWN0OyBmb3IgbW9yZSBpbmZvcm1hdGlvbiwgc2VlIEZyZWVC U0QNCkRvY2VuZyBUZWFtIENoYXJ0ZXIuDQoNCk5vIG5ldyBkb2N1bWVudGF0aW9uIGNvbW1pdCBi aXQgd2FzIGdyYW50ZWQgZHVyaW5nIHRoZSBsYXN0IHF1YXJ0ZXIsIGFuZCBvbmx5DQpvbmUgY29t bWl0IGJpdCB3YXMgc2FmZSBrZXB0Lg0KDQpTZXZlcmFsIHRhc2tzIHdlcmUgY29tcGxldGVkIHJl bGF0ZWQgdG8gdGhlIGRvYyB0cmVlIGR1cmluZyB0aGUgbGFzdCBxdWFydGVyOg0KDQogIOKAoiBB IENPUFlSSUdIVCBmaWxlIHdhcyBhZGRlZCBpbiB0aGUgcm9vdCBkaXJlY3Rvcnkgb2YgdGhlIGRv YyByZXBvc2l0b3J5LiBUaGUNCiAgICBsaWNlbnNlIHdhcyBhbHNvIHVwZGF0ZWQgdG8gcmVmbGVj dCB0aGUgY3VycmVudCB0b29sY2hhaW4gdGhlIHByb2plY3QgaXMNCiAgICB1c2luZyBub3cuDQoN CiAg4oCiIENsZWFudXAgb2YgTWFpbG1hbiBpbmZvcm1hdGlvbiBpbiB0aGUgZG9jIHRyZWUuIEZv bGxvd2luZyBtYWlsaW5nIGxpc3RzDQogICAgbWlncmF0aW9uIGZyb20gTWFpbG1hbiB0byBNbG1t aiwgdmVyeSBvbGQgbWFpbGluZyBsaXN0cyB3ZXJlIHJlbW92ZWQ7IG1vc3QNCiAgICBvZiB0aGUg d29yayB3YXMgbWFkZSBvbiBFbmdsaXNoIGRvY3VtZW50cy4NCg0KICDigKIgVGFnIEZyZWVCU0Qg ZG9jc2V0IGZvciAxMi4zLVJFTEVBU0UuDQoNCiAg4oCiIFVwZGF0ZSBhbGwgcG9ydHMvcGFja2Fn ZXMgbWlzYy9mcmVlYnNkLWRvYy0qLg0KDQogIOKAoiBNb3ZlIGFydGljbGVzL2NvbnRyaWJ1dG9y cy9jb250cmliLSogZmlsZXMgdG8gdGhlIGRvYyBzaGFyZWQgZGlyZWN0b3J5Lg0KDQogIOKAoiBB ZGQgb3B0aW9uIGluIGRvY3VtZW50YXRpb24gTWFrZWZpbGUgdG8gYXJjaGl2ZS9jb21wcmVzcyBE b2N1bWVudGF0aW9uL0hUTUwNCiAgICBvZmZsaW5lIGZpbGVzLCBhIG5lY2Vzc2FyeSBzdGVwIGJl Zm9yZSB1cGRhdGluZyBodHRwczovLw0KICAgIGRvd25sb2FkLmZyZWVic2Qub3JnL2Z0cC8uIFRo aXMgd2FzIGFmdGVyIGEgZGlzY3Vzc2lvbiB3aXRoIGNsdXN0ZXJhZG1AIHRvDQogICAgdXBkYXRl IHRoZSBvZmZsaW5lIGFzc2V0cyAoSFRNTC9QREYpLg0KDQogIOKAoiBBZGQgZXhwZXJpbWVudGFs IHN1cHBvcnQgZm9yIEVQVUIgb3V0cHV0IChib29rcy9hcnRpY2xlcykuDQoNCiAg4oCiIFRhbGtp bmcgd2l0aCBjbHVzdGVyYWRtQCB0byBpbXByb3ZlIHRoZSBwZXJmb3JtYW5jZSBvZiBodHRwczov Lw0KICAgIHd3dy5mcmVlYnNkLm9yZyBhbmQgaHR0cHM6Ly9kb2NzLmZyZWVic2Qub3JnLg0KDQri lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIENCg0KRnJlZUJTRCBXZWJzaXRlIFJldmFtcCAtIFdlYkFwcHMgd29ya2luZyBncm91 cA0KDQpDb250YWN0OiBTZXJnaW8gQ2FybGF2aWxsYSA8Y2FybGF2aWxsYUBGcmVlQlNELm9yZz4N Cg0KV29ya2luZyBncm91cCBpbiBjaGFyZ2Ugb2YgY3JlYXRpbmcgdGhlIG5ldyBGcmVlQlNEIERv Y3VtZW50YXRpb24gUG9ydGFsIGFuZA0KcmVkZXNpZ25pbmcgdGhlIEZyZWVCU0QgbWFpbiB3ZWJz aXRlIGFuZCBpdHMgY29tcG9uZW50cy4gRnJlZUJTRCBkZXZlbG9wZXJzIGNhbg0KZm9sbG93IGFu ZCBqb2luIHRoZSB3b3JraW5nIGdyb3VwIG9uIHRoZSBGcmVlQlNEIFNsYWNrIGNoYW5uZWwgI3dn LXd3dzIxLiBUaGUNCndvcmsgd2lsbCBiZSBkaXZpZGVkIGludG8gZm91ciBwaGFzZXM6DQoNCiAx LiBSZWRlc2lnbiBvZiB0aGUgRG9jdW1lbnRhdGlvbiBQb3J0YWwNCg0KICAgIENyZWF0ZSBhIG5l dyBkZXNpZ24sIHJlc3BvbnNpdmUgYW5kIHdpdGggZ2xvYmFsIHNlYXJjaC4gKENvbXBsZXRlKQ0K DQogICAgQWN0aXZhdGUgYW4gZWRpdCBsaW5rIGluIHRoZSBEb2N1bWVudGF0aW9uIChib29rcy9h cnRpY2xlcykgcG9pbnRpbmcgdG8NCiAgICBHaXRIdWIgYW5kIGVuY291cmFnaW5nIEdpdEh1YiBw dWxsIHJlcXVlc3RzLiAoQ29tcGxldGUpDQoNCiAyLiBSZWRlc2lnbiBvZiB0aGUgTWFudWFsIFBh Z2VzIG9uIHdlYg0KDQogICAgU2NyaXB0cyB0byBnZW5lcmF0ZSB0aGUgSFRNTCBwYWdlcyB1c2lu ZyBtYW5kb2MuIChXb3JrIGluIHByb2dyZXNzKQ0KDQogMy4gUmVkZXNpZ24gb2YgdGhlIFBvcnRz IHBhZ2Ugb24gd2ViDQoNCiAgICBQb3J0cyBzY3JpcHRzIHRvIGNyZWF0ZSBhbiBhcHBsaWNhdGlv bnMgcG9ydGFsLiAoV29yayBpbiBwcm9ncmVzcykNCg0KIDQuIFJlZGVzaWduIG9mIHRoZSBGcmVl QlNEIG1haW4gd2Vic2l0ZQ0KDQogICAgTmV3IGRlc2lnbiwgcmVzcG9uc2l2ZSBhbmQgZGFyayB0 aGVtZS4gKE5vdCBzdGFydGVkKQ0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KUHJvamVjdHMNCg0KUHJvamVjdHMg dGhhdCBzcGFuIG11bHRpcGxlIGNhdGVnb3JpZXMsIGZyb20gdGhlIGtlcm5lbCBhbmQgdXNlcnNw YWNlIHRvIHRoZQ0KUG9ydHMgQ29sbGVjdGlvbiBvciBleHRlcm5hbCBwcm9qZWN0cy4NCg0KRW5h YmxlIEFTTFIgYnkgZGVmYXVsdCBmb3IgNjQtYml0IGV4ZWN1dGFibGVzDQoNCkNvbnRhY3Q6IERh d2lkIEdvcmVja2kgPGRnckBzZW1paGFsZi5jb20+DQpDb250YWN0OiBNYXJjaW4gV29qdGFzIDxt d0BzZW1paGFsZi5jb20+DQoNCkFkZHJlc3MgU3BhY2UgTGF5b3V0IFJhbmRvbWl6YXRpb24gKEFT TFIpIGlzIGFuIGV4cGxvaXQgbWl0aWdhdGlvbiB0ZWNobmlxdWUNCmltcGxlbWVudGVkIGluIHRo ZSBtYWpvcml0eSBvZiBtb2Rlcm4gb3BlcmF0aW5nIHN5c3RlbXMuIEl0IGludm9sdmVzIHJhbmRv bWx5DQpwb3NpdGlvbmluZyB0aGUgYmFzZSBhZGRyZXNzIG9mIGFuIGV4ZWN1dGFibGUgYW5kIHRo ZSBwb3NpdGlvbiBvZiBsaWJyYXJpZXMsDQpoZWFwLCBhbmQgc3RhY2ssIGluIGEgcHJvY2Vzc+KA mXMgYWRkcmVzcyBzcGFjZS4gQWx0aG91Z2ggb3ZlciB0aGUgeWVhcnMgQVNMUg0KcHJvdmVkIHRv IG5vdCBndWFyYW50ZWUgZnVsbCBPUyBzZWN1cml0eSBvbiBpdHMgb3duLCB0aGlzIG1lY2hhbmlz bSBjYW4gbWFrZQ0KZXhwbG9pdGF0aW9uIG1vcmUgZGlmZmljdWx0Lg0KDQpUaGUgU2VtaWhhbGYg dGVhbSBtYWRlIGFuIGVmZm9ydCB0byBzd2l0Y2ggb24gdGhlIGFkZHJlc3MgbWFwIHJhbmRvbWl6 YXRpb24gZm9yDQpQSUUgKFBvc2l0aW9uIEluZGVwZW5kZW50IEV4ZWN1dGFibGVzKSAmIG5vbi1Q SUUgNjQtYml0IGJpbmFyaWVzLiBPbmNlIHRoZQ0KcGF0Y2ggd2FzIG1lcmdlZCB0byBIRUFELCB0 aGUgQVNMUiBmZWF0dXJlIGJlY2FtZSBlbmFibGVkIGZvciBhbGwgNjQtYml0DQphcmNoaXRlY3R1 cmVzLg0KDQpBZGRpdGlvbmFsbHksIHRoZSBtZW50aW9uZWQgY2hhbmdlIGRpc2FibGVkIFNCUkss IGluIG9yZGVyIHRvIGFsbG93IHV0aWxpemF0aW9uDQpvZiB0aGUgYnNzIGdyb3cgcmVnaW9uIGZv ciBtYXBwaW5ncy4gSXQgaGFzIG5vIGVmZmVjdCB3aXRob3V0IEFTTFIsIHNvIGl0IHdhcw0KYXBw bGllZCB0byBhbGwgYXJjaGl0ZWN0dXJlcy4NCg0KVE9ETzoNCg0KICDigKIgSW1wcm92ZSBzdGFj a2dhcCBmZWF0dXJlIGltcGxlbWVudGF0aW9uLg0KDQogIOKAoiBNRkMgdG8gc3RhYmxlLzEzIGJy YW5jaC4NCg0KU3BvbnNvcjogU3Rvcm1zaGllbGQNCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkJvb3QgUGVyZm9y bWFuY2UgSW1wcm92ZW1lbnRzDQoNCkxpbmtzOg0KV2lraSBwYWdlIFVSTDogaHR0cHM6Ly93aWtp LmZyZWVic2Qub3JnL0Jvb3RUaW1lDQpPUyBib290IHRpbWUgY29tcGFyaXNvbiBVUkw6IGh0dHBz Oi8vd3d3LmRhZW1vbm9sb2d5Lm5ldC9ibG9nLw0KMjAyMS0wOC0xMi1FQzItYm9vdC10aW1lLWJl bmNobWFya2luZy5odG1sDQoNCkNvbnRhY3Q6IENvbGluIFBlcmNpdmFsIDxjcGVyY2l2YUBGcmVl QlNELm9yZz4NCg0KQ29saW4gUGVyY2l2YWwgaXMgY29vcmRpbmF0aW5nIGFuIGVmZm9ydCB0byBz cGVlZCB1cCB0aGUgRnJlZUJTRCBib290IHByb2Nlc3MuDQpGb3IgYmVuY2htYXJraW5nIHB1cnBv c2VzLCBoZSBpcyBwcmltYXJpbHkgdXNpbmcgYW4gRUMyIGM1LnhsYXJnZSBpbnN0YW5jZSBhcyBh DQpyZWZlcmVuY2UgcGxhdGZvcm0gYW5kIGlzIG1lYXN1cmluZyB0aGUgdGltZSBiZXR3ZWVuIHdo ZW4gdGhlIHZpcnR1YWwgbWFjaGluZQ0KZW50ZXJzIHRoZSBFQzIgInJ1bm5pbmciIHN0YXRlIGFu ZCB3aGVuIGl0IGlzIHBvc3NpYmxlIHRvIFNTSCBpbnRvIHRoZQ0KaW5zdGFuY2UuDQoNClRoaXMg d29yayBzdGFydGVkIGluIDIwMTcsIGFuZCBhcyBvZiB0aGUgZW5kIG9mIFNlcHRlbWJlciAyMDIx IHRoZSBGcmVlQlNEIGJvb3QNCnRpbWUgd2FzIHJlZHVjZWQgZnJvbSBhcHByb3hpbWF0ZWx5IDMw IHNlY29uZHMgdG8gYXBwcm94aW1hdGVseSAxNSBzZWNvbmRzLg0KDQpEdXJpbmcgMjAyMVE0LCBm dXJ0aGVyIGltcHJvdmVtZW50cyBoYXZlIHNoYXZlZCBtb3JlIHRpbWUgb2ZmIHRoZSBib290IHBy b2Nlc3MsDQp0YWtpbmcgaXQgZG93biB0byByb3VnaGx5IDEwIHNlY29uZHMuIEEgZnVydGhlciA0 IHNlY29uZHMgb2YgaW1wcm92ZW1lbnRzIGFyZQ0KaW4gcHJvY2Vzcy4NCg0KSW4gYWRkaXRpb24s IHRoZSB1c2VybGFuZCBib290IHByb2Nlc3MgaXMgbm93IGJlaW5nIHByb2ZpbGVkIHVzaW5nIFRT TE9HLA0KbWFraW5nIGl0IHBvc3NpYmxlIHRvIHNlZSBmbGFtZWNoYXJ0cyBvZiB0aGUgZW50aXJl IGJvb3QgcHJvY2VzczsgYW5kIHRoZQ0KZWMyLWJvb3QtYmVuY2ggdG9vbCBpcyBub3cgYWJsZSB0 byBnZW5lcmF0ZSBNUDQgdmlkZW9zIG9mIHRoZSBib290IHByb2Nlc3MgYnkNCnRha2luZyBzbmFw c2hvdHMgb2YgdGhlIEVDMiBWR0EgY29uc29sZS4NCg0KSXNzdWVzIGFyZSBsaXN0ZWQgb24gdGhl IHdpa2kgcGFnZSBhcyB0aGV5IGFyZSBpZGVudGlmaWVkOyB0aGUgd2lraSBwYWdlIGFsc28NCmhh cyBpbnN0cnVjdGlvbnMgZm9yIHBlcmZvcm1pbmcgcHJvZmlsaW5nLiBVc2VycyBhcmUgZW5jb3Vy YWdlZCB0byBwcm9maWxlIHRoZQ0KYm9vdCBwcm9jZXNzIG9uIHRoZWlyIG93biBzeXN0ZW1zLCBp biBjYXNlIHRoZXkgZXhwZXJpZW5jZSBkZWxheXMgd2hpY2ggZG9u4oCZdA0Kc2hvdyB1cCBvbiB0 aGUgc3lzdGVtIENvbGluIGlzIHVzaW5nIGZvciB0ZXN0aW5nLg0KDQpUaGlzIHdvcmsgaXMgc3Vw cG9ydGVkIGJ5IENvbGlu4oCZcyBGcmVlQlNEL0VDMiBQYXRyZW9uLg0KDQpTcG9uc29yOiBodHRw czovL3d3dy5wYXRyZW9uLmNvbS9jcGVyY2l2YQ0KDQrilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KTExEQiBEZWJ1Z2dl ciBJbXByb3ZlbWVudHMNCg0KTGlua3M6DQpNb3JpdHogU3lzdGVtcyBQcm9qZWN0IERlc2NyaXB0 aW9uIFVSTDogaHR0cHM6Ly93d3cubW9yaXR6LnN5c3RlbXMvYmxvZy8NCmZyZWVic2Qta2dkYi1z dXBwb3J0LWluLWxsZGIvDQpQcm9ncmVzcyBSZXBvcnQgMyBVUkw6IGh0dHBzOi8vd3d3Lm1vcml0 ei5zeXN0ZW1zL2Jsb2cvDQpsbGRiLXNlcmlhbC1wb3J0LWNvbW11bmljYXRpb24tc3VwcG9ydC8N ClByb2dyZXNzIFJlcG9ydCA0IFVSTDogaHR0cHM6Ly93d3cubW9yaXR6LnN5c3RlbXMvYmxvZy8N CmxsZGItZnJlZWJzZC1rZXJuZWwtY29yZS1kdW1wLXN1cHBvcnQvDQpMTFZNIEdpdCBSZXBvc2l0 b3J5IFVSTDogaHR0cHM6Ly9naXRodWIuY29tL21vcml0ei1zeXN0ZW1zL2xsdm0tcHJvamVjdA0K bGliZmJzZHZtY29yZSBHaXQgUmVwb3NpdG9yeSBVUkw6IGh0dHBzOi8vZ2l0aHViLmNvbS9tb3Jp dHotc3lzdGVtcy8NCmxpYmZic2R2bWNvcmUNCg0KQ29udGFjdDogS2FtaWwgUnl0YXJvd3NraSA8 a2FtaWxAbW9yaXR6LnN5c3RlbXM+DQpDb250YWN0OiBNaWNoYcWCIEfDs3JueSA8bWdvcm55QG1v cml0ei5zeXN0ZW1zPg0KDQpBY2NvcmRpbmcgdG8gdGhlIHVwc3RyZWFtIGRlc2NyaXB0aW9uLCAi TExEQiBpcyBhIG5leHQgZ2VuZXJhdGlvbiwNCmhpZ2gtcGVyZm9ybWFuY2UgZGVidWdnZXIuIEl0 IGlzIGJ1aWx0IGFzIGEgc2V0IG9mIHJldXNhYmxlIGNvbXBvbmVudHMgd2hpY2gNCmhpZ2hseSBs ZXZlcmFnZSBleGlzdGluZyBsaWJyYXJpZXMgaW4gdGhlIGxhcmdlciBMTFZNIFByb2plY3QsIHN1 Y2ggYXMgdGhlDQpDbGFuZyBleHByZXNzaW9uIHBhcnNlciBhbmQgTExWTSBkaXNhc3NlbWJsZXIu Ig0KDQpGcmVlQlNEIGluY2x1ZGVzIExMREIgaW4gdGhlIGJhc2Ugc3lzdGVtLiBBdCBwcmVzZW50 LCBpdCBoYXMgc29tZSBsaW1pdGF0aW9ucw0KY29tcGFyZWQgdG8gdGhlIEdOVSBHREIgZGVidWdn ZXIsIGFuZCBkb2VzIG5vdCB5ZXQgcHJvdmlkZSBhIGNvbXBsZXRlDQpyZXBsYWNlbWVudC4gVGhp cyBwcm9qZWN0IHNwYW5zIGZyb20gSnVseSAyMDIxIHRvIEphbnVhcnkgMjAyMiBhbmQgYWltcyB0 byBtYWtlDQpMTERCIHN1aXRhYmxlIGZvciBkZWJ1Z2dpbmcgRnJlZUJTRCBrZXJuZWxzLg0KDQpU aGUgZWFybGllciBwYXJ0IG9mIHRoZSBwcm9qZWN0IHdhcyBmb2N1c2VkIG9uIGltcHJvdmluZyBj b21wYXRpYmlsaXR5IGJldHdlZW4NCkxMREIgYW5kIG90aGVyIHNlcnZlcnMgaW1wbGVtZW50aW5n IHRoZSBHREIgUmVtb3RlIFByb3RvY29sLiBUaGlzIHdhcyBmb2xsb3dlZA0KYnkgaW1wbGVtZW50 aW5nIGEgZnVsbHktZmVhdHVyZWQgc2VyaWFsIHBvcnQgc3VwcG9ydCBhbmQgdGhlbiBzdXBwb3J0 IGZvcg0KRnJlZUJTRCBrZXJuZWwgY29yZSBkdW1wcyAodm1jb3JlcykuDQoNClRoZSBMTERCIGNs aWVudCBnYWluZWQgbXVjaCBpbXByb3ZlZCBzdXBwb3J0IGZvciBjb25uZWN0aW5nIHRvIHRoZSBy ZW1vdGUNCnNlcnZlciBvdmVyIGEgc2VyaWFsIHBvcnQsIGFuZCB0aGUgTExEQiBzZXJ2ZXIgZ2Fp bmVkIHN1cHBvcnQgZm9yIGFjY2VwdGluZw0KY29tbXVuaWNhdGlvbiBvdmVyIGEgc2VyaWFsIHBv cnQuIFRoaXMgb3BlbmVkIHRoZSBwb3NzaWJpbGl0eSBvZiB1c2luZyBMTERCIHRvDQpkZWJ1ZyBl bWJlZGRlZCBkZXZpY2VzIHRoYXQgdXNlIHRoZSBSUzIzMiBpbnRlcmZhY2UuIEl0IGNhbiBhbHNv IGFpZCBkZWJ1Z2dpbmcNCmtlcm5lbHMgb24gcmVndWxhciBQQ3MgYXMgaXQgZG9lcyBub3QgcmVs eSBvbiB0aGUgbmV0d29yayBzdGFjay4NCg0KU3VwcG9ydCBmb3IgRnJlZUJTRCB2bWNvcmVzIGhh cyBhbHNvIGJlZW4gYWRkZWQgdG8gTExEQi4gVGhpcyBtYWtlcyBpdCBwb3NzaWJsZQ0KdG8gaW5z cGVjdCB0aGUgY3Jhc2hlZCBrZXJuZWwgc3RhdGUgd2l0aG91dCBoYXZpbmcgdG8gcmVzb3J0IHRv IEtHREIgb3INCm1hbnVhbGx5IGNvbnZlcnQgdGhlIHZtY29yZSBpbnRvIHRoZSBzdGFuZGFyZCBF TEYgZm9ybWF0IHN1cHBvcnRlZCBieSBMTERCLg0KDQpUaGUgaW50cm9kdWNlZCBjaGFuZ2VzIGFy ZSBleHBlY3RlZCB0byBiZSBzaGlwcGVkIHdpdGggTExEQiAxNC4wLg0KDQpTcG9uc29yOiBUaGUg RnJlZUJTRCBGb3VuZGF0aW9uDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpOWFAgTFMxMDI4QS8xMDI3QSBTb0Mg c3VwcG9ydA0KDQpDb250YWN0OiBLb3JuZWwgRHVsxJliYSA8bWluZGFsQHNlbWloYWxmLmNvbT4N CkNvbnRhY3Q6IEFydHVyIFJvamVrIDxhckBzZW1paGFsZi5jb20+DQpDb250YWN0OiBIdWJlcnQg TWF6dXIgPGh1bUBzZW1paGFsZi5jb20+DQpDb250YWN0OiBXb2pjaWVjaCBNYWNlayA8d21hQHNl bWloYWxmLmNvbT4NCg0KVGhlIFNlbWloYWxmIHRlYW0gaGFzIGJlZW4gd29ya2luZyBvbiBhZGRp bmcgdGhlIEZyZWVCU0Qgc3VwcG9ydCBmb3IgdGhlIE5YUA0KTFMxMDI4QSBTb0MsIGFzIHdlbGwg YXMgaXRzIEdQVS1sZXNzIHZhcmlhbnQgKE5YUCBMUzEwMjdBKS4NCg0KTlhQIExTMTAyOEEvTFMx MDI3QSBTb0MgaXMgYSBkdWFsLWNvcmUgNjQtYml0IEFSTXY4IENvcnRleC1BNzIgYXBwbGljYXRp b24NCnByb2Nlc3NvciB3aXRoIGhpZ2gtc3BlZWQgcGVyaXBoZXJhbHMgc3VjaCBhcyAyIFRpbWUt U2Vuc2l0aXZlDQpOZXR3b3JraW5nLWNhcGFibGUgKFRTTikgRXRoZXJuZXQgY29udHJvbGxlcnMs IHF1YWQtcG9ydCBUU04tZW5hYmxlZCBzd2l0Y2gsDQpQQ0lFLCBTRC9NTUMsIFVTQjMuMCBhbmQg b3RoZXJzLg0KDQpUaGUgb3JpZ2luYWwgc3VwcG9ydCB3YXMgZXh0ZW5kZWQgaW4gdGhlIGZvbGxv d2luZyB3YXk6DQoNCiAg4oCiIEVORVRDIEV0aGVybmV0IGRyaXZlcg0KDQogICAgICDilqEgQWRk IHN1cHBvcnQgZm9yIFBIWSBpbnRlcnJ1cHRzDQoNCiAgICAgIOKWoSBGaXggVklEL21jYXN0IGFk ZHJlc3MgaGFzaCBjYWxjdWxhdGlvbg0KDQogICAgICDilqEgU2VyaWFsaXplIE1ESU8gdHJhbnNh Y3Rpb25zDQoNCiAgICAgIOKWoSBBbGxvdyBsb2FkaW5nIGRyaXZlciBhcyBhIG1vZHVsZQ0KDQog IOKAoiBJbXByb3ZlbWVudHMgaW4gdGhlIEZTTCBTREhDSSBkcml2ZXINCg0KICAgICAg4pahIEFk ZCBzdXBwb3J0IGZvciBIUzIwMC9IUzQwMCBtb2Rlcw0KDQogICAgICDilqEgQWRkIGZ1bGwgc3Vw cG9ydCBmb3Igc29mdHdhcmUgcmVzZXQNCg0KICAgICAg4pahIFByb3ZpZGUgbW9yZSBhY2N1cmF0 ZSBjbGsgY2FsY3VsYXRpb24NCg0KICAgICAg4pahIEltcGxlbWVudCBwdWxzZSB3aWR0aCBkZXRl Y3Rpb24gZXJyYXRhDQoNCiAgICAgIOKWoSBGaXggdmNjcSByZWNvbmZpZ3VyYXRpb24NCg0KICDi gKIgRkxFWCBTUEkgTk9SIGNvbnRyb2xsZXIgZHJpdmVyDQoNCiAg4oCiIEFkZGl0aW9uYWwgZmVh dHVyZXM6DQoNCiAgICAgIOKWoSBUTVA0NjEgdGhlcm1hbCBzZW5zb3IgZHJpdmVyDQoNCiAgICAg IOKWoSBQQ0Y4NTA2MyBSVEMgZHJpdmVyIGRyaXZlcg0KDQogICAgICDilqEgVENBNjQwOCBJMkMg R1BJTyBleHBhbmRlciBkcml2ZXINCg0KVE9ETzoNCg0KICDigKIgSW1wcm92ZSBNTUMgSFMyMDAv SFM0MDAgc3VwcG9ydCBmb3Igb3RoZXIgU29DcyB1c2luZyB0aGUgRlNMIFNESENJDQogICAgY29u dHJvbGxlci4NCg0KU3BvbnNvcjogQWxzdG9tIEdyb3VwDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpzY2hlZF9n ZXRjcHUoMiksIG1lbWJhcnJpZXIoMiksIGFuZCByc2VxKDIpIHN5c2NhbGxzDQoNCkNvbnRhY3Q6 IEtvbnN0YW50aW4gQmVsb3Vzb3YgPGtpYkBGcmVlQlNELm9yZz4NCg0KTGlua3M6DQpMaW51eCBt YW5wYWdlIGZvciBtZW1iYXJyaWVyKDIpIFVSTDogaHR0cHM6Ly9raWIua2lldi51YS9raWIvbWVt YmFycmllci5wZGYNCm1lbWJhcnJpZXIoMikgaW1wbGVtZW50YXRpb24gVVJMOiBodHRwczovL3Jl dmlld3MuZnJlZWJzZC5vcmcvRDMyMzYwDQpMaW51eCBtYW5wYWdlIGZvciByc2VxKDIpIFVSTDog aHR0cHM6Ly9raWIua2lldi51YS9raWIvcnNlcS5wZGYNCnJzZXEoMikgYW5kIHVzZXJzcGFjZSBi aW5kaW5ncyBpbXBsZW1lbnRhdGlvbiBVUkw6IGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy8N CkQzMjUwNQ0KDQpMaW51eCBwcm92aWRlcyBhIHNldCBvZiBzeXNjYWxscyB0aGF0IGFsbG93IHRv IGRldmVsb3AgbW9zdGx5IHN5c2NhbGwtbGVzcw0Kc2NhbGFibGUgYWxnb3JpdGhtcyBpbiB1c2Vy c3BhY2UuIFRoZSBtZWNoYW5pc21zIGFyZSBiYXNlZCBvbiBvcHRpbWlzdGljDQpleGVjdXRpb24g dXNpbmcgQ1BVLWxvY2FsIGRhdGEgd2l0aCB0aGUgYXNzdW1wdGlvbiB0aGF0IHJhcmUgZXZlbnRz IGxpa2UNCmNvbnRleHQgc3dpdGNoZXMgb3Igc2lnbmFsIGRlbGl2ZXJ5IGRvIG5vdCBvY2N1ciBm b3IgdGhlIGdpdmVuIGNhbGN1bGF0aW9uLCBhbmQNCmlmIHRoZXkgZG8gb2NjdXIsIHJvbGxiYWNr IGFuZCByZXN0YXJ0IGlzIHBlcmZvcm1lZC4gVGhpcyB2ZXJ5IGhpZ2gtbGV2ZWwNCmFwcHJvYWNo IGlzIHVzZWQsIGFzIEkgdW5kZXJzdGFuZCwgZm9yIGltcGxlbWVudGF0aW9uIG9mIHRvb2xzIGxp a2UgVVJDVSwgZmFzdA0KbWFsbG9jIGFsbG9jYXRvcnMgKHRjbWFsbG9jKSBhbmQgb3RoZXIgdXNl cnNwYWNlIGluZnJhc3RydWN0dXJlIHByb2plY3RzIGFpbWVkDQphdCBsYXJnZSBwYXJ0aXRpb25l ZCBtYWNoaW5lcy4NCg0KRm9yIGluc3RhbmNlLCBzY2hlZF9nZXRjcHUoMikgc3lzY2FsbCByZXR1 cm5zIHRoZSBDUFUgaWQgb2YgdGhlIENQVSB3aGVyZSB0aGUNCmN1cnJlbnQgdGhyZWFkIGlzIGN1 cnJlbnRseSBleGVjdXRpbmcuIE9uIGFtZDY0LCBpZiBhdmFpbGFibGUsIHdlIHVzZSBhIFJEVFND UA0Kb3IgUkRQSUQgaW5zdHJ1Y3Rpb24gdG8gcXVlcnkgdGhlIENQVSBpZCB3aXRob3V0IGNoYW5n aW5nIENQVSBtb2RlLCBvdGhlcndpc2UNCnRoaXMgaXMgYSBsaWdodC13ZWlnaHQgc3lzY2FsbC4g T2YgY291cnNlLCB0aGUgYW5zd2VyIHByb3ZpZGVkIGlzIG9ic29sZXRlIHRoZQ0KbW9tZW50IGl0 IGlzIGNyZWF0ZWQsIGV2ZW4gYmVmb3JlIGl0IGlzIHJldHVybmVkIHRvIHVzZXJzcGFjZS4gQnV0 IGl0IGFsbG93cw0Kc2VlZGluZyB2YWx1ZXMgaW4gc29tZSBzdHJ1Y3R1cmVzIHRoYXQgYXJlIHZh bGlkIGZvciBhIGxvbmcgdGltZSAoYXQgdGhlIENQVQ0Kc3BlZWQgc2NhbGUpIGFuZCBhcmUgYXV0 b21hdGljYWxseSBjb3JyZWN0ZWQgb24gZXhjZXB0aW9uYWwgY29udHJvbCBmbG93IGV2ZW50cw0K bGlrZSBjb250ZXh0IHN3aXRjaGVzLCBhbmQgdXNlcnNwYWNlIGNhbiBlaXRoZXIgZGV0ZWN0IGFu ZCByb2xsYmFjayBvciBzeW5jIGFuZA0Kcm9sbGJhY2sgd2l0aCB0aGUgZXhjZXB0aW9ucy4NCg0K VGhlcmUgYXJlIHR3byBjb3JuZXJzdG9uZSBzeXNjYWxscyB0aGF0IGFsbG93IHVzZXJzcGFjZSB0 byBpbXBsZW1lbnQgdGhlc2UNCmVmZmljaWVudCBhbGdvcml0aG1zOiBtZW1iYXJyaWVyKDIpIGFu ZCByc2VxKDIpLg0KDQpNZW1iYXJyaWVyIGlzIGEgZmFjaWxpdHkgdGhhdCBoZWxwcyBpbXBsZW1l bnRpbmcgZmFzdCBDUFUgb3JkZXJpbmcgYmFycmllcnMsDQp0eXBpY2FsbHkgdXNlZCBmb3IgYXN5 bW1ldHJpYy9iaWFzZWQgbG9ja2luZy4gSW4gdGhlc2UgbG9jayBpbXBsZW1lbnRhdGlvbg0Kc2No ZW1lcywgdGhlIG93bmVyIG9mIHRoZSBvYmplY3Qgb2Z0ZW4gYXNzdW1lcyB0aGF0IHRoZXJlIGFy ZSBjb250ZW5kZXJzLw0KcGFyYWxsZWwgdGhyZWFkcyB0aGF0IG5lZWQgY29vcmRpbmF0aW5nIHdp dGguIElmIHNvbWUgdGhyZWFkIHN0YXJ0cyBhY2Nlc3NpbmcNCnRoZSBzYW1lIHJlc291cmNlLCB0 aGVuIGl0IGlzIGl0cyBkdXR5IHRvIGVuc3VyZSBjb3JyZWN0bmVzcy4gRXhhbXBsZXMgb2YNCid0 cmFwcycgdGhhdCBmYXN0IGNvZGUgcGF0aCB1dGlsaXplIGFyZSByZWFkcyBmcm9tIGEgZGVkaWNh dGVkIHBhZ2UgdGhhdCBpcw0KdW5tYXBwZWQgYnkgY29udGVuZGVycywgdG8gc3dpdGNoIHRoZSBm YXN0IHBhdGggdG8gdGhlIHNsb3cgb25lLiBPciB3ZSBjb3VsZA0Kc2VuZCBhIHNpZ25hbCB0byBh bGwgdGhyZWFkcyB0aGF0IHBvdGVudGlhbGx5IGhhdmUgYWNjZXNzIHRvIHRoYXQgb2JqZWN0LCB0 bw0KaW5zZXJ0IGEgYmFycmllci4gT3Igd2UgY2FuIHVzZSB0aGUgbWVtYmFycmllcigyKSBmYWNp bGl0eSwgd2hpY2ggaW5jdXJzDQpzaWduaWZpY2FudGx5IGxlc3Mgb3ZlcmhlYWQgdGhhbiBzaWdu YWxsaW5nIGFsbCB0aHJlYWRzLg0KDQpNZW1iYXJyaWVyKDIpIGluc2VydHMgYSBiYXJyaWVyLCB3 aGljaCBpcyB0aGUgdHlwaWNhbCB1bmRlcmx5aW5nIGhhcmR3YXJlDQpvcGVyYXRpb24gdG8gZW5z dXJlIG9yZGVyaW5nLCBpbnRvIHRoZSBzcGVjaWZpZWQgc2V0IG9mIENQVXMsIGlmIHRoZXNlIENQ VXMgYXJlDQpleGVjdXRpbmcgdGhlIHNwZWNpZmllZCB0aHJlYWQuIElmIHRoZXNlIENQVXMgYXJl IG5vdCBleGVjdXRpbmcgdGhlIHRhcmdldGVkDQp0aHJlYWRzLCBpdCBpcyBhc3N1bWVkIHRoYXQg c2VxdWVudGlhbCBjb25zaXN0ZW5jeSBndWFyYW50ZWVzIGZyb20gdGhlIGNvbnRleHQNCnN3aXRj aCBhcmUgZW5vdWdoIHRvIGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50IG9mIG1lbWJhcnJpZXIoMiku IE92ZXJhbGwsIHRoZQ0KZmFzdCBwYXRoIGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IHNsb3cg aW5zdHJ1Y3Rpb25zLCBhbmQgdGhlIHNsb3cgcGF0aA0KaW5qZWN0cyByZXF1aXJlZCBmZW5jZXMg aW50byB0aGUgZmFzdCBwYXRoIGF0IHRoZSBjb3N0IG9mIElQSS4NCg0KVGhlIGZhY2lsaXR5IHRv IGRldGVjdCBleGNlcHRpb25hbCBjb25kaXRpb25zIGluIHRoZSB1c2Vyc3BhY2UgdGhyZWFkIGV4 ZWN1dGlvbg0Kd2FzIGRldmVsb3BlZCBpbiBMaW51eCBhbmQgY2FsbGVkIHJzZXEoMikuIEl0IGlz IGEgZmVhdHVyZSBvZnRlbiBjYWxsZWQNClJlc3RhcnRhYmxlIEF0b21pYyBTZXF1ZW5jZXMsIHdo aWNoIGV4cGxhaW5zIHRoZSBhY3JvbnltLiBUaGUgYWJpbGl0eSB0bw0KY2hlYXBseSBkbyB0aGF0 IGFsbG93cyBjb2RlIGxvbmdlciB0aGFuIGEgc2luZ2xlIGluc3RydWN0aW9uIHRvIGV4ZWN1dGUN CmF0b21pY2FsbHksIHdpdGhvdXQgdGhlIG5lZWQgdG8gcHJvcG9zZSBhbmQgaW1wbGVtZW50IHVu c2FmZSBvcGVyYXRpb25zIGxpa2UNCmRpc2FibGluZyBwcmVlbXB0aW9uLCB3aGljaCBpcyBub3Qg ZmVhc2libGUgZm9yIHVzZXJzcGFjZS4gRm9yIGluc3RhbmNlLCBjb2RlDQptaWdodCB1c2UgQ1BV LWxvY2FsIHJlc291cmNlcywgd2hpY2ggb3RoZXJ3aXNlIGRvZXMgbm90IGNvcGUgd2VsbCB3aXRo IGNvbnRleHQNCnN3aXRjaGVzLiBUaGVyZSBjYW5ub3QgYmUgYW4gYW5hbG9nIG9mIGNyaXRpY2Fs X2VudGVyKDkpIGluIHVzZXJzcGFjZS4gKEENCmZhY2lsaXR5IHRvIGNoZWFwbHkgYmxvY2sgc2ln bmFsIGRlbGl2ZXJ5IGV4aXN0cyBpbiBGcmVlQlNELCBzZWUgc2lnZmFzdGJsb2NrDQooMiksIGJ1 dCBjb3JyZWN0bHkgdXNpbmcgaXQgaXMgcHJvdmFibHkgdG9vIGhhcmQgdG8gaW1wbGVtZW50IGlu DQpnZW5lcmFsLXB1cnBvc2UgY29kZSwgZXNwLiBiZWNhdXNlIGl0IHJlcXVpcmVzIHZlcnNpb24t ZGVwZW5kZW50IGNvb3JkaW5hdGlvbg0Kd2l0aCBydGRsIGFuZCBsaWJ0aHIuKQ0KDQpyc2VxKDIp IHRha2VzIHBlci10aHJlYWQgYmxvY2sgb2YgbWVtb3J5LCB3aGVyZSB0aGUgdGhyZWFkIHdyaXRl cyB0aGUgY3VycmVudA0KQ1BVIGlkIChzZWUgc2NoZWRfZ2V0Y3B1KDIpKSBhbmQgc3BlY2lmaWVz IHRoZSBibG9jayBvZiBjcml0aWNhbCBjb2RlIHRoYXQgbXVzdA0KYmUgdW53b3VuZCBpZiBhbiBl eGNlcHRpb25hbCBzaXR1YXRpb24gbGlrZSBhIGNvbnRleHQgc3dpdGNoIG9jY3VycmVkIHdoaWxl IHRoZQ0KYmxvY2sgd2FzIGV4ZWN1dGluZy4gVGhlIGZhc3QgY29kZSBwYXRoIHVzZXMgcGVyLWNw dSBkYXRhIGFuZCB0eXBpY2FsbHkgZG9lcw0Kbm90IG5lZWQgYW55IGNvcnJlY3Rpb25zLCBidXQg d291bGQgYSBjb250ZXh0IHN3aXRjaCBvY2N1ciwgdHJhbnNmZXIgb2YgY29udHJvbA0KdG8gdGhl IGFib3J0IGhhbmRsZXIgaW5mb3JtcyB1c2Vyc3BhY2UgYWJvdXQgdGhlIGV2ZW50LiBTbyBpbnN0 ZWFkIG9mIGRpc2FibGluZw0KY29udGV4dCBzd2l0Y2hlcywgY29kZSBjYW4gY2hlYXBseSBjaGVj ayBmb3Igb25lIGFmdGVyIHRoZSBjYWxjdWxhdGlvbiBhbmQNCnJldHJ5IGlmIG5lZWRlZC4NCg0K QW4gaW50ZXJlc3RpbmcgcnNlcSgyKSBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgaXMgdGhhdCBpdCBp cyBpbXBvc3NpYmxlIChhbmQgbm90DQpuZWVkZWQpIHRvIGFjY2Vzcy91cGRhdGUgcnNlcSBzdHJ1 Y3R1cmVzIGZyb20ga2VybmVsIGR1cmluZyB0aGUgYWN0dWFsIGNvbnRleHQNCnN3aXRjaCwgYmVj YXVzZSB3ZSBjYW5ub3QgYWNjZXNzIHVzZXJzcGFjZSBmcm9tIHVuZGVyIGEgc3BpbmxvY2suIElu IG90aGVyDQp3b3JkcywgdGhyZWFkcyB1c2luZyByc2VxIGRvIG5vdCBpbmN1ciBhbnkgcGVyZm9y bWFuY2UgY29zdCBmcm9tIHN5c3RlbS1nbG9iYWwNCmNvbnRleHQgc3dpdGNoZXMuIEluc3RlYWQs IGlmIHRoZSBwcm9jZXNzIHJlZ2lzdGVyZWQgZm9yIHJzZXEoMiksIG9uIGFueSByZXR1cm4NCnRv IHVzZXIgbW9kZSB3ZSBjaGVjayBpZiBhbnkgZXhjZXB0aW9uYWwgZXZlbnRzIGhhcHBlbmVkIHdo aWxlIHRoZSB0aHJlYWQgd2FzDQppbiB0aGUga2VybmVsIChjb250ZXh0IHN3aXRjaGVzIG1heSBo YXBwZW4gb25seSB3aGlsZSB0aGUgdGhyZWFkIGlzIGluIGtlcm5lbA0KbW9kZSksIGFuZCBpZiBh IGNvbnRleHQgc3dpdGNoIGluZGVlZCBvY2N1cmVkLCB3ZSBmaXJlIGFuIGFzdCB0byBjaGVjayB3 aGV0aGVyDQp0aGUgcHJvZ3JhbSBjb3VudGVyIGlzIGluc2lkZSB0aGUgY3JpdGljYWwgc2VjdGlv biBhbmQganVtcCB0byB0aGUgYWJvcnQNCmhhbmRsZXIgaWYgaXQgaXMuDQoNClRoZSBpbXBsZW1l bnRhdGlvbnMgb2YgbWVtYmFycmllcigyKSBhbmQgcnNlcSgyKSBhcmUgY2xlYW4tcm9vbTogSSB1 c2VkIExpbnV4DQptYW51YWwgcGFnZXMgYXMgdGhlIHJlZmVyZW5jZSBhbmQgcHVibGljIGRpc2N1 c3Npb25zIG9mIHRoZSBmZWF0dXJlcyBmb3INCmNsYXJpZnlpbmcgY29ybmVyIGNhc2VzLiBPbiBM aW51eC9nbGliYywgdGhlcmUgd2FzIG5vIHN0YWJsZSBnbGliYyBpbnRlcmZhY2UgdG8NCnRoZSBy c2VxIGZhY2lsaXR5LiBPbmUgcHJvcG9zZWQgaW50ZWdyYXRpb24gd2FzIGNvbW1pdHRlZCB0aGVu IHJldmVydGVkIGZyb20NCmdsaWJjLiBJdCBtaWdodCBiZSBwcnVkZW50IHRvIHdhaXQgc29tZSBt b3JlIGZvciB0aGUgcnNlcSgyKSBpbnRlcmZhY2UgdG8NCnN0YWJpbGl6ZSBpbiBnbGliYyBiZWZv cmUgcHJvdmlkaW5nIGl0IGluIG91ciBsaWJjIG9yIHRvIHJlbHkgb24gdGlnaHQNCmludGVncmF0 aW9uIGJldHdlZW4ga2VybmVsIGFuZCB1c2Vyc3BhY2UgaW4gb3VyIGJhc2Ugc3lzdGVtLCBhbmQg dXNlIEFCSSB0cmlja3MNCmxpa2Ugc3ltYm9sIHZlcnNpb25pbmcgdG8gZXZvbHZlIHRoZSBpbnRl cmZhY2UuIFRoZXJlIGlzIG5vIGdvYWwgdG8gYmUgMTAwJQ0KY29tcGF0aWJsZSB3aXRoIExpbnV4 IGFueXdheS4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIEN Cg0KQmFzZSBTeXN0ZW0gT3BlblNTSCBVcGRhdGUNCg0KTGlua3M6DQpPcGVuU1NIIFVSTDogaHR0 cHM6Ly93d3cub3BlbnNzaC5jb20vDQpBbm5vdW5jZW1lbnQgdG8gZnJlZWJzZC1zZWN1cml0eUAg VVJMOiBodHRwczovL2xpc3RzLmZyZWVic2Qub3JnL3BpcGVybWFpbC8NCmZyZWVic2Qtc2VjdXJp dHkvMjAyMS1TZXB0ZW1iZXIvMDEwNDczLmh0bWwNCg0KQ29udGFjdDogRWQgTWFzdGUgPGVtYXN0 ZUBmcmVlYnNkLm9yZz4NCg0KT3BlblNTSCwgYSBzdWl0ZSBvZiByZW1vdGUgbG9naW4gYW5kIGZp bGUgdHJhbnNmZXIgdG9vbHMsIHdhcyB1cGRhdGVkIGZyb20NCnZlcnNpb24gOC43cDEgdG8gOC44 cDEgaW4gdGhlIEZyZWVCU0QgYmFzZSBzeXN0ZW0uDQoNCk5PVEU6IE9wZW5TU0ggOC44cDEgZGlz YWJsZXMgdGhlIHNzaC1yc2Egc2lnbmF0dXJlIHNjaGVtZSBieSBkZWZhdWx0LiBGb3IgbW9yZQ0K aW5mb3JtYXRpb24gcGxlYXNlIHNlZSB0aGUgSW1wb3J0YW50IG5vdGUgZm9yIGZ1dHVyZSBGcmVl QlNEIGJhc2Ugc3lzdGVtDQpPcGVuU1NIIHVwZGF0ZSBtYWlsaW5nIGxpc3QgcG9zdC4NCg0KT3Bl blNTSCBzdXBwb3J0cyBGSURPL1UyRiBkZXZpY2VzLCBhbmQgc3VwcG9ydCBpcyBub3cgZW5hYmxl ZCBpbiB0aGUgYmFzZQ0Kc3lzdGVtLg0KDQpOZXh0IHN0ZXBzIGluY2x1ZGUgaW50ZWdyYXRpbmcg VTJGIGtleSBkZXZkIHJ1bGVzIGludG8gdGhlIGJhc2Ugc3lzdGVtLCBhbmQNCm1lcmdpbmcgdGhl IHVwZGF0ZWQgT3BlblNTSCBhbmQgRklETy9VMkYgc3VwcG9ydCB0byBzdGFibGUgYnJhbmNoZXMu DQoNClNwb25zb3I6IFRoZSBGcmVlQlNEIEZvdW5kYXRpb24NCg0K4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNClZEU08g b24gYW1kNjQNCg0KQ29udGFjdDogS29uc3RhbnRpbiBCZWxvdXNvdiA8a2liQEZyZWVCU0Qub3Jn Pg0KDQpBIFZEU08sIG9yIFZpcnR1YWwgRHluYW1pYyBTaGFyZWQgT2JqZWN0LCBpcyBhIHNoYXJl ZCBvYmplY3QgKG1vcmUgY29tbW9ubHkNCmNhbGxlZCBkeW5hbWljIGxpYnJhcnkpIHRoYXQgaXMg aW5zZXJ0ZWQgaW50byB0aGUgZXhlY3V0ZWQgaW1hZ2UgYnkgYSBqb2ludA0KZWZmb3J0IG9mIHRo ZSBrZXJuZWwgYW5kIHRoZSBkeW5hbWljIGxpbmtlci4gSXQgZG9lcyBub3QgZXhpc3RzIG9uIGRp c2sgYXMgYQ0Kc3RhbmRhbG9uZSAuc28sIGFuZCB0aGVyZSBhcmUgbm8gaW5zdHJ1Y3Rpb25zIGlu IHRoZSBFTEYgZm9ybWF0IHRoYXQgY2F1c2UgdGhlDQppbnNlcnRpb24uIEl0IGlzIGRvbmUgYnkg dGhlIHN5c3RlbSB0byBpbXBsZW1lbnQgc29tZSBmdW5jdGlvbmFsaXR5IGZvciB0aGUgQw0KcnVu dGltZSBpbXBsZW1lbnRhdGlvbiBjb21wb25lbnRzLg0KDQpGcmVlQlNEIGFscmVhZHkgaGFzIGEg bG90IG9mIGZlYXR1cmVzIHR5cGljYWxseSBkb25lIHVzaW5nIFZEU08gKGluIExpbnV4KSwgYnV0 DQpyZWFsbHkgbm90IHJlcXVpcmluZyB0aGF0IGNvbXBsaWNhdGlvbi4gVGhlIG1haW4gcmVhc29u IHdoeSBpdCBpcyBwb3NzaWJsZSBpcw0KdGhlIG9mdGVuIG1lbnRpb25lZCBjby1ldm9sdXRpb24g b2YgdGhlIGtlcm5lbCBhbmQgQyBydW50aW1lLiBXZSBjYW4gbmF0dXJhbGx5DQppbnRyb2R1Y2Ug ZmVhdHVyZXMgdGhhdCByZXF1aXJlIGltcGxlbWVudGF0aW9uIGJvdGggaW4ga2VybmVsLCBhbmQg c3VwcG9ydCBpbg0KdGhlIHVzZXJzcGFjZSBwYXJ0cywgc2luY2UgRnJlZUJTRCBpcyBkZXZlbG9w ZWQgYXMgYSB3aG9sZS4gU3VycHJpc2luZ2x5LCBpdA0KYWxzbyBhbGxvd3MgdGhlIGtlcm5lbCBh bmQgZHluYW1pYyBsaW5rZXIgdG8ga25vdyBtdWNoIGxlc3MgKGFuZCBub3QgZW5mb3JjZQ0KYW55 dGhpbmcpIGFib3V0IHVzZXJzcGFjZSBjb25zdW1lcnMgb2YgaW50ZXJmYWNlcy4NCg0KRm9yIGlu c3RhbmNlLCBhIHN5c2NhbGwtbGVzcyB3YWxsIGNsb2NrIHdhcyBpbXBsZW1lbnRlZCBsb25nIGFn bywgYnkgdGhlIGtlcm5lbA0KcHJvdmlkaW5nIGEgdGltZSBoYW5kcyBibG9iIGluIHRoZSBzaGFy ZWQgcGFnZSwgYW5kIHRoZSBDIGxpYnJhcnkga25vd2luZyBhYm91dA0KaXRzIGxvY2F0aW9uIGFu ZCB0aGUgc3VwcG9ydGVkIGFsZ29yaXRobXMuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgVkRTTyB0 aGF0DQppbnRlcnBvc2VzIHNvbWUgbGliYyBzeW1ib2xzIG9yIHByb3ZpZGVzIHNlcnZpY2VzIHRo YXQgYXJlIG5hbWVkIGJ5IGtub3duDQpzeW1ib2xzIHRvIHVzZXJsYW5kLg0KDQpGcm9tIGFsbCB0 aGUgeWVhcnMgb2YgZXhwZXJpZW5jZSB3aXRoIHRoaXMgcHNldWRvLVZEU08gYXBwcm9hY2gsIHRo ZSBvbmx5DQpmZWF0dXJlIHRoYXQgd2FzIGltcG9zc2libGUgdG8gaW1wbGVtZW50IHdpdGhvdXQg cHJvdmlkaW5nIHJlYWwgVkRTTyBzdXBwb3J0DQp3YXMgdGhlIHNpZ25hbCB0cmFtcG9saW5lIERX QVJGIGFubm90YXRpb25zLCBmb3IgdGhlIGJlbmVmaXQgb2Ygc3RhY2sNCnVud2luZGVycy4NCg0K V2hlbiB0aGUga2VybmVsIGRlbGl2ZXJzIHNpZ25hbCB0byB1c2VybGFuZCwgaXQgY2hhbmdlcyBz b21lIGtleSByZWdpc3RlcnMNCihsaWtlIHRoZSBpbnN0cnVjdGlvbiBwb2ludGVyLCB0aGUgc3Rh Y2sgcG9pbnRlciwgYW5kIHdoYXRldmVyIGVsc2UgaXMgbmVlZGVkDQpieSB0aGUgYXJjaGl0ZWN0 dXJlKSBhbmQgcHVzaGVzIHRoZSBzYXZlZCBpbWFnZSBvZiB0aGUgd2hvbGUgdXNlcm1vZGUgQ1BV IHN0YXRlDQooY29udGV4dCkgb250byB0aGUgdXNlciBzdGFjay4gVGhlbiwgY29udHJvbCBpcyBw YXNzZWQgdG8gYSBzbWFsbCBwaWVjZSBvZiBjb2RlDQpsb2NhdGVkIGluIHRoZSBzaGFyZWQgcGFn ZSAoc2lnbmFsIHRyYW1wb2xpbmUpLCB3aGljaCBjYWxscyB0aGUgdXNlciBoYW5kbGVyDQpmdW5j dGlvbiBhbmQgb24gcmV0dXJuIGZyb20gdGhlIGhhbmRsZXIgaXNzdWVzIGEgc2lncmV0dXJuKDIp IHN5c2NhbGwgdG8gcmVsb2FkDQp0aGUgb2xkIGNvbnRleHQuDQoNCkZyb20gdGhpcyBkZXNjcmlw dGlvbiwgaXQgaXMgY2xlYXIgdGhhdCB0aGUgc3RhdGUgb2YgdGhlIG1hY2hpbmUgZHVyaW5nDQp0 cmFtcG9saW5lIGV4ZWN1dGlvbiBpcyBxdWl0ZSBkaWZmZXJlbnQgZnJvbSB0aGUgbm9ybWFsIEMg Y2FsbGluZyBmcmFtZXMuDQpVbndpbmRlcnMgdGhhdCBoYW5kbGUgdGhpbmdzIGxpa2UgQysrIGV4 Y2VwdGlvbnMsIFJ1c3QgcGFuaWNzLCBvciBvdGhlciBzaW1pbGFyDQptZWNoYW5pc21zIGluIHNw ZWNpZmljIGxhbmd1YWdlIHJ1bnRpbWVzLCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIHNwZWNpYWxu ZXNzIG9mDQp0aGUgdHJhbXBvbGluZSBmcmFtZS4gVGhlIGN1cnJlbnQgYXBwcm9hY2ggaXMgdG8g aGFyZGNvZGUgdGhlIGRldGVjdGlvbiBvZiB0aGUNCnRyYW1wb2xpbmUsIGUuZy4gYnkgbWF0Y2hp bmcgdGhlIGluc3RydWN0aW9uIHBvaW50ZXIgYWdhaW5zdCBzeXNjdGwNCmtlcm4ucHJvYy5zaWd0 cmFtcC4NCg0KRFdBUkYgYW5ub3RhdGlvbnMgYXJlIGVub3VnaCB0byBwcm92aWRlIHRoZSByZXF1 aXJlZCBpbmZvcm1hdGlvbiB0byB1bndpbmRlcnMNCnRvIG1ha2UgdGhlIHRyYW1wb2xpbmUgZnJh bWUgbm90IHNwZWNpYWwgYW55bW9yZSwgYnV0IHRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlcmUNCmlz IG5vIHdheSBmb3IgdW53aW5kZXJzIHRvIGZpbmQgdGhlIGFubm90YXRpb24gd2l0aG91dCBpbnRy b2R1Y2luZyBldmVuIG1vcmUNCnNwZWNpYWxuZXNzLiBJbnN0ZWFkLCB3ZSBjYW4gaW5zZXJ0IGEg VkRTTyB0aGF0IG9ubHkgc2VydmVzIHRvIGFwcGVhciBpbiB0aGUNCmVudW1lcmF0aW9uIG9mIERT T3MgbG9hZGVkIGludG8gdGhlIHByb2Nlc3MsIHdpdGggZWl0aGVyIGRsX2l0ZXJhdGVfcGhkcigz KQ0KKGluLXByb2Nlc3MpIG9yIHJfZGVidWcgKHJlbW90ZSksIHdpdGggUFRfR05VX0VIX0ZSQU1F IGhlYWRlciBwb2ludGluZyB0byB0aGUNCnJvb3Qgb2YgRFdBUkYgaW5mby4NCg0KVGhpcyBpcyBl eGFjdGx5IHdoYXQgdGhlIFZEU08gb24gRnJlZUJTRCBkb2VzOiBpdCB3cmFwcyBzaWduYWwgdHJh bXBvbGluZSBiaXRzDQphbmQgdGhlaXIgRFdBUkYgYW5ub3RhdGlvbiAoLmNmaSkgaW50byBhIHNo YXJlZCBvYmplY3QsIHdoaWNoIGlzIHB1dCBpbnRvIHRoZQ0Kc2hhcmVkIHBhZ2UgYW5kIGxpbmtl ZCBieSBydGxkKDEpIGludG8gdGhlIHNldCBvZiBwcmVsb2FkZWQgb2JqZWN0cyB1cG9uIGltYWdl DQphY3RpdmF0aW9uLg0KDQpFZmZvcnRzIHdlcmUgbWFkZSB0byBzdHJpcCBhcyBtYW55IHVubmVl ZGVkIHN0cnVjdHVyZXMgYW5kIGFzIG11Y2ggcGFkZGluZyBhcw0KcG9zc2libGUgZnJvbSB0aGUg VkRTTyBpbWFnZSwgYmVjYXVzZSBpdCBjb25zdW1lcyBzcGFjZSBpbiB0aGUgc2hhcmVkIHBhZ2Uu IEl0DQp3YXMgcHVzaGVkIGFzIGZhciBhcyB0aGUgY29tbW9uIGRlbm9taW5hdG9yIG9mIGxsZCBh bmQgbGQuYmZkIGFsbG93ZWQsIHdpdGgNCnNldmVyYWwgdHJpY2tzIGRvbmUgYnkgbGlua2VyIHNj cmlwdHMgYW5kIHNvbWUgdXNlIG9mIHNlZW1pbmdseSB1bmRvY3VtZW50ZWQNCmxpbmtlciBvcHRp b25zLg0KDQpXZSBuZWVkIGF0IGxlYXN0IHR3byBWRFNPcyBmb3IgYW1kNjQ6IGEgNjQtYml0IG9u ZSBmb3IgbmF0aXZlIGJpbmFyaWVzIGFuZCBhDQozMi1iaXQgb25lIGZvciBpYTMyIGJpbmFyaWVz LiBXaXRoIHRoZSBzaXplIG9mIGVhY2ggVkRTTyBhcm91bmQgMS41S0IsIHNwYWNlDQpiZWNvbWVz IHJlYWxseSB0aWdodCBpbiB0aGUgc2hhcmVkIHBhZ2UsIHdoaWNoIG5lZWRzIHNwYWNlIGZvciBv dGhlciBzdHVmZiBhcw0Kd2VsbCwgbGlrZSB0aW1laGFuZHMgb3IgcmFuZG9tIGdlbmVyYXRvciBz ZWVkcy4NCg0KQnVpbGQgc2NyaXB0cyBlbmZvcmNlIHRoYXQgVkRTT3MgZG8gbm90IGdyb3cgbGFy Z2VyIHRoYW4gMks7IGlmIHRoZXkgZG8sIHdlDQpuZWVkIHRvIGV4dGVuZCBzaGFyZWQgcGFnZSB0 byBiZWNvbWUgYXQgbGVhc3QgdHdvIHNoYXJlZCBwYWdlcy4gU2NyaXB0cyBhbHNvDQplbmZvcmNl IHRoYXQgVkRTTyBhcmUgcHVyZSBwb3NpdGlvbi1pbmRlcGVuZGVudCwgbm90IHJlcXVpcmluZyBy ZWxvY2F0aW9ucyBmb3INCmVpdGhlciBjb2RlIG9yIG1ldGFkYXRhICguY2ZpKS4NCg0KU3BvbnNv cjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KS2VybmVsDQoNClVwZGF0 ZXMgdG8ga2VybmVsIHN1YnN5c3RlbXMvZmVhdHVyZXMsIGRyaXZlciBzdXBwb3J0LCBmaWxlc3lz dGVtcywgYW5kIG1vcmUuDQoNClRoZSBBVlggYnVnIG9uIGFtZDY0DQoNCkNvbW1pdDogNzNiMzU3 YmU5MjM4IFVSTDogaHR0cHM6Ly9jZ2l0LmZyZWVic2Qub3JnL3NyYy9jb21taXQvP2lkPQ0KNzNi MzU3YmU5MjM4NWNiYjcwYmExOWU3MDIzYTczNmFmMmM2YjQ5Mw0KDQpDb250YWN0OiBLb25zdGFu dGluIEJlbG91c292IDxraWJARnJlZUJTRC5vcmc+DQoNClNvbWUgQ1BVcyBzdXBwb3J0IHRoZSBz byBjYWxsZWQgaW5pdCBvcHRpbWl6YXRpb24gZm9yIFhTQVZFLCBidXQgbm90IGFsbCBDUFVzDQpk by4gQW5kIHdoZW4gdGhleSBkbywgJ2FjY29yZGluZyB0byBjb21wbGV4IGludGVybmFsIG1pY3Jv YXJjaGl0ZWN0dXJhbA0KY29uZGl0aW9ucycsIHRoZSBvcHRpbWl6YXRpb24gbWlnaHQgaGFwcGVu IG9yIG5vdC4gQmFzaWNhbGx5LCB0aGlzIG1lYW5zIHRoYXQNCnNvbWV0aW1lcyB0aGUgQ1BVIGRv ZXMgbm90IHdyaXRlIGFsbCBvZiB0aGUgc3RhdGUgb24gWFNBVkUgYW5kIHJlY29yZHMgaW4NCnhz dGF0ZV9idiB0aGF0IGl0IGRpZCBub3QuDQoNCk9uIHNpZ25hbCBkZWxpdmVyeSwgdGhlIE9TIHBy b3ZpZGVzIHRoZSBzYXZlZCBjb250ZXh0IGludGVycnVwdGVkIGJ5IHRoZSBzaWduYWwNCnRvIHRo ZSBzaWduYWwgaGFuZGxlci4gVGhlIGNvbnRleHQgaW5jbHVkZXMgYWxsIENQVSBzdGF0ZSBhdmFp bGFibGUgdG8NCnVzZXJzcGFjZSwgaW5jbHVkaW5nIEZQVSByZWdpc3RlcnMgKFhTQVZFIGFyZWEp LiBBbHNvLCBvbiByZXR1cm4gZnJvbSB0aGUNCnNpZ25hbCBoYW5kbGVyLCBjb250ZXh0IGlzIHJl c3RvcmVkLCB3aGljaCBhbGxvd3MgdGhlIGhhbmRsZXIgdG8gbW9kaWZ5IHRoZQ0KbWFpbiBwcm9n cmFtIGZsb3cuIFdoZW4gaW5pdCBvcHRpbWl6YXRpb24ga2lja3MgaW4sIHRoZSBPUyB0cmllcyB0 byBoaWRlIGluaXQNCnN0YXRlIG9wdGltaXphdGlvbiBmcm9tIHRoZSBzaWduYWwgaGFuZGxlciwg YnkgZmlsbGluZyBub24tc2F2ZWQgcGFydHMgb2YgdGhlDQpYU0FWRSBhcmVhLg0KDQpUaGlzIGlz IHdoZXJlIHRoZSBwcm9ibGVtIGhhcHBlbnMuIEZvciBzdGF0ZXMgcGFydHMgMCAoeDg3KSBhbmQg MSAoU1NFL1hNTSksDQpJbnRlbCBDUFVzIGRvIG5vdCBwcm92aWRlIGFuIGVudW1lcmF0aW9uIG9m IGxheW91dCBpbiBDUFVJRCwgYXNzdW1pbmcgdGhhdCB0aGUNCk9TIGtub3dzIGFib3V0IHRoZSBy ZWdpb25zIGFueXdheS4gVGhlIGJ1ZyB3YXMgdGhhdCB0aGUgYW1kNjQga2VybmVsIGhhcmRjb2Rl ZA0KYSAzMmJpdCBzaXplIGZvciB0aGUgWE1NIHNhdmUgYXJlYSwgZWZmZWN0aXZlbHkgZmlsbGlu ZyAlWE1NOC0lWE1NMTUgd2l0aA0KZ2FyYmFnZSBvbiBzaWduYWwgcmV0dXJuIHdoZW4gaW5pdCBv cHRpbWl6YXRpb24ga2lja2VkIGluLCBiZWNhdXNlIG9ubHkNCnNwZWNpZmllZCBwYXJ0IG9mIHRo ZSBTU0Ugc2F2ZSBhcmVhIHdhcyBjb3BpZWQgZnJvbSB0aGUgY2Fub25pY2FsIHNhdmUgYXJlYS4N Cg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KRU5BIEZy ZWVCU0QgRHJpdmVyIFVwZGF0ZQ0KDQpMaW5rczoNCkVOQSBSRUFETUUgVVJMOiBodHRwczovL2dp dGh1Yi5jb20vYW16bi9hbXpuLWRyaXZlcnMvYmxvYi9tYXN0ZXIva2VybmVsL2Zic2QvDQplbmEv UkVBRE1FDQoNCkNvbnRhY3Q6IE1pY2hhbCBLcmF3Y3p5ayA8bWtAc2VtaWhhbGYuY29tPg0KQ29u dGFjdDogRGF3aWQgR29yZWNraSA8ZGdyQHNlbWloYWxmLmNvbT4NCkNvbnRhY3Q6IE1hcmNpbiBX b2p0YXMgPG13QHNlbWloYWxmLmNvbT4NCg0KRU5BIChFbGFzdGljIE5ldHdvcmsgQWRhcHRlcikg aXMgdGhlIHNtYXJ0IE5JQyBhdmFpbGFibGUgaW4gdGhlIHZpcnR1YWxpemVkDQplbnZpcm9ubWVu dCBvZiBBbWF6b24gV2ViIFNlcnZpY2VzIChBV1MpLiBUaGUgRU5BIGRyaXZlciBzdXBwb3J0cyBt dWx0aXBsZQ0KdHJhbnNtaXQgYW5kIHJlY2VpdmUgcXVldWVzIGFuZCBjYW4gaGFuZGxlIHVwIHRv IDEwMCBHYi9zIG9mIG5ldHdvcmsgdHJhZmZpYywNCmRlcGVuZGluZyBvbiB0aGUgaW5zdGFuY2Ug dHlwZSBvbiB3aGljaCBpdCBpcyB1c2VkLg0KDQpDb21wbGV0ZWQgc2luY2UgdGhlIGxhc3QgdXBk YXRlOg0KDQogIOKAoiBBZGQgSVB2NiBsYXllciA0IGNoZWNrc3VtIG9mZmxvYWQgc3VwcG9ydCB0 byB0aGUgZHJpdmVyDQoNCiAg4oCiIEFkZCBOVU1BIGF3YXJlbmVzcyB0byB0aGUgZHJpdmVyIHdo ZW4gdGhlIFJTUyBrZXJuZWwgb3B0aW9uIGlzIGVuYWJsZWQNCg0KICDigKIgUmV3b3JrIHZhbGlk YXRpb24gb2YgdGhlIFR4IHJlcXVlc3QgSUQNCg0KICDigKIgQ2hhbmdlIGxpZmV0aW1lIG9mIHRo ZSBkcml2ZXLigJlzIHRpbWVyIHNlcnZpY2UNCg0KICDigKIgQXZvaWQgcmVzZXQgdHJpZ2dlcmlu ZyB3aGVuIHRoZSBkZXZpY2UgaXMgdW5yZXNwb25zaXZlDQoNCldvcmsgaW4gcHJvZ3Jlc3M6DQoN CiAg4oCiIFByb3RvdHlwZSB0aGUgZHJpdmVyIHBvcnQgdG8gdGhlIGlmbGliIGZyYW1ld29yaw0K DQogIOKAoiBUZXN0cyBvZiB0aGUgaW5jb21pbmcgRU5BIGRyaXZlciByZWxlYXNlICh2Mi41LjAp DQoNClNwb25zb3I6IEFtYXpvbi5jb20gSW5jDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpJbnRlbCBXaXJlbGVz cyBkcml2ZXIgc3VwcG9ydA0KDQpMaW5rczoNCml3bHdpZmkgc3RhdHVzIEZyZWVCU0Qgd2lraSBw YWdlIFVSTDogaHR0cHM6Ly93aWtpLmZyZWVic2Qub3JnL1dpRmkvSXdsd2lmaQ0KDQpDb250YWN0 OiBCam9lcm4gQS4gWmVlYiA8YnpARnJlZUJTRC5PUkc+DQoNClRoZSBJbnRlbCBXaXJlbGVzcyBk cml2ZXIgdXBkYXRlIHByb2plY3QgYWltcyB0byBicmluZyBzdXBwb3J0IGZvciBuZXdlcg0KY2hp cHNldHMgYWxvbmcgd2l0aCBtYWM4MDIxMSBMaW51eEtQSSBjb21wYXQgY29kZS4gVGhlIGR1YWwt bGljZW5zZWQgSW50ZWwNCmRyaXZlciBjb2RlIHdhcyBwb3J0ZWQgaW4gdGhlIHBhc3QgZm9yIHRo ZSBpd20oNCkgbmF0aXZlIGRyaXZlcjsgdXNpbmcgdGhlDQpMaW51eEtQSSBjb21wYXQgZnJhbWV3 b3JrIGFsbG93cyB1cyB0byB1c2UgdGhlIGRyaXZlciBkaXJlY3RseSwgd2l0aCBvbmx5IHZlcnkN Cm1pbm9yIG1vZGlmaWNhdGlvbnMgdGhhdCB3ZSBob3BlIHdpbGwgYmUgaW5jb3Jwb3JhdGVkIGlu dG8gdGhlIG9yaWdpbmFsIGRyaXZlci4NCg0KRHVyaW5nIERlY2VtYmVyIHRoZSBkcml2ZXIsIGZp cm13YXJlLCBhbmQgYWxsIHJlbWFpbmluZyBMaW51eEtQSSBjb21wYXRpYmlsaXR5DQpjb2RlIHdl cmUgY29tbWl0dGVkIHRvIEZyZWVCU0QgbWFpbiAoSEVBRCkgYW5kIG1lcmdlZCB0byB0aGUgc3Rh YmxlLzEzIGJyYW5jaC4NCkZ1cnRoZXIgZml4ZXMsIHVwZGF0ZXMsIGFuZCBpbXByb3ZlbWVudHMg d2lsbCBnbyBkaXJlY3RseSBpbnRvIEZyZWVCU0QsIG1lYW5pbmcNCnRoZSBuZWVkIHRvIGFwcGx5 IHNuYXBzaG90cyBpcyBnb25lIGFuZCBjaGFuZ2VzIGNhbiBiZSBkaXN0cmlidXRlZCBtb3JlIHRp bWVseS4NCg0KRHVyaW5nIHRoZSBsYXN0IG1vbnRocyB3ZSB0cmllZCB0byBlbnN1cmUgdGhhdCB0 aGUgbGF0ZXN0IEFYMjEwIGNoaXBzZXRzIGFyZQ0Kc3VwcG9ydGVkLiBUaGUgY29tcGF0IGNvZGUg d2FzIHJlc3RydWN0dXJlZCBib3RoIHRvIGJlIGFibGUgdG8gYmV0dGVyIHRyYWNlIGFuZA0KZGVi dWcgdGhlIG1hYzgwMjExIGNvbXBhdGliaWxpdHkgbGF5ZXIsIGJ1dCBhbHNvIHRvIGtlZXAgdGhl IG5ldDgwMjExIGFuZA0KbWFjODAyMTEgc3RhdGUgbWFjaGluZXMgZm9yIHN0YXRpb25zIGJldHRl ciBpbiBzeW5jLg0KDQpXaGlsZSB3ZSBrZWVwIHVwZGF0aW5nIHRoZSBkcml2ZXIgYW5kIGFsbCB0 aGUgY29tcGF0IGNvZGUgbmVlZGVkIGZvciB0aGF0LCB0aGUNCmZvY3VzIHJlbWFpbnMgb24gc3Rh YmlsaXR5IGFuZCBhZGRpbmcgc3VwcG9ydCBmb3IgbmV3ZXIgODAyLjExIHN0YW5kYXJkcy4gVGhl DQpkcml2ZXIgaXMgc3RpbGwgc2V0IHRvIDExYS9iL2ctb25seSBhbmQgMTFuIHdpbGwgYmUgbmV4 dCBiZWZvcmUgd2UgbG9vayBhdA0KMTFhYy4NCg0KV2l0aCB0aGUgY29kZSBpbiBGcmVlQlNEIGdp dCB3ZSBhbnRpY2lwYXRlIGJyb2FkZXIgdGVzdGluZyBhbmQgd2l0aCB0aGF0IGFsc28NCnNvbWUg ZmFsbG91dC4gRm9yIHRoZSBsYXRlc3Qgc3RhdGUgb2YgdGhlIGRldmVsb3BtZW50LCBwbGVhc2Ug Zm9sbG93IHRoZQ0KcmVmZXJlbmNlZCB3aWtpIHBhZ2UgYW5kIHRoZSBmcmVlYnNkLXdpcmVsZXNz IG1haWxpbmcgbGlzdC4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlvbg0KDQrilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIENCg0KS2VybmVsIENyeXB0byBjaGFuZ2VzIHRvIHN1cHBvcnQgV2lyZUd1YXJkDQoNCkNv bnRhY3Q6IEpvaG4gQmFsZHdpbiA8amhiQEZyZWVCU0Qub3JnPg0KDQpEdXJpbmcgdGhlIHBhc3Qg ZmV3IG1vbnRocywgSSBtZXJnZWQgc2V2ZXJhbCBjaGFuZ2VzIHRvIHRoZSBrZXJuZWwgdG8gYmV0 dGVyDQpzdXBwb3J0IHRoZSBXaXJlR3VhcmQgZHJpdmVyLiBUaGVzZSBpbmNsdWRlIGV4dGVuc2lv bnMgdG8gdGhlICdzdHJ1Y3QNCmVuY194Zm9ybScgaW50ZXJmYWNlIHRvIGJldHRlciBzdXBwb3J0 IEFFQUQgY2lwaGVycywgY2hhbmdlcyB0byAnc3RydWN0DQplbmNfeGZvcm0nIHRvIHN1cHBvcnQg bXVsdGktYmxvY2sgb3BlcmF0aW9ucyBmb3IgaW1wcm92ZWQgcGVyZm9ybWFuY2UsIGFuZCB0aGUN CmFkZGl0aW9uIG9mIHRoZSBYQ2hhQ2hhMjAtUG9seTEzMDUgQUVBRCBjaXBoZXIgc3VpdGUgdG8g T0NGLiBBZGRpdGlvbmFsbHksIHRoZQ0Ka2VybmVsIG5vdyBpbmNsdWRlcyBhIG5ldyAiZGlyZWN0 IiBBUEkgZm9yIENoYUNoYTIwLVBvbHkxMzA1IG9wZXJhdGlvbnMgb24NCnNtYWxsLCBmbGF0IGJ1 ZmZlcnMuIEEgY2hhbmdlIGluIHJldmlldyBhZGRzIGFuIEFQSSB0byBzdXBwb3J0IGN1cnZlMjU1 MTkNCm9wZXJhdGlvbnMuIFdpdGggdGhlc2UgY2hhbmdlcywgdGhlIFdpcmVHdWFyZCBkcml2ZXIg aXMgbW9zdGx5IGFibGUgdG8gdXNlDQpjcnlwdG8gQVBJcyBmcm9tIHRoZSBrZXJuZWwgcmF0aGVy IHRoYW4gaXRzIGludGVybmFsIGltcGxlbWVudGF0aW9ucy4NCg0KSW4gcGFyYWxsZWwgSSBoYXZl IGJlZW4gdXBkYXRpbmcgdGhlIFdpcmVHdWFyZCBkcml2ZXIgdG8gdXNlIHRoZSBuZXcgQVBJcw0K dmVyaWZ5aW5nIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGUgZXhpc3RpbmcgZHJpdmVyLiBPbmUg b2YgdGhlIG5leHQgdGFza3MgaXMNCnRvIHJlZmluZSB0aGVzZSBjaGFuZ2VzIChhbG9uZyB3aXRo IHNvbWUgbWlub3IgYnVnIGZpeGVzKSBhcyBjYW5kaWRhdGVzIGZvcg0KdXBzdHJlYW1pbmcgaW50 byB0aGUgV2lyZUd1YXJkIGRyaXZlci4NCg0KU3BvbnNvcjogVGhlIEZyZWVCU0QgRm91bmRhdGlv bg0KDQrilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIENCg0KUG9ydHMNCg0KQ2hhbmdlcyBhZmZlY3RpbmcgdGhlIFBvcnRzIENv bGxlY3Rpb24sIHdoZXRoZXIgc3dlZXBpbmcgY2hhbmdlcyB0aGF0IHRvdWNoDQptb3N0IG9mIHRo ZSB0cmVlLCBvciBpbmRpdmlkdWFsIHBvcnRzIHRoZW1zZWx2ZXMuDQoNCktERSBvbiBGcmVlQlNE DQoNCkxpbmtzOg0KS0RFIEZyZWVCU0QgVVJMOiBodHRwczovL2ZyZWVic2Qua2RlLm9yZy8NCktE RSBDb21tdW5pdHkgRnJlZUJTRCBVUkw6IGh0dHBzOi8vY29tbXVuaXR5LmtkZS5vcmcvRnJlZUJT RA0KDQpDb250YWN0OiBBZHJpYWFuIGRlIEdyb290IDxrZGVARnJlZUJTRC5vcmc+DQoNClRoZSBL REUgb24gRnJlZUJTRCBwcm9qZWN0IGFpbXMgdG8gcGFja2FnZSB0aGUgc29mdHdhcmUgZnJvbSB0 aGUgS0RFIENvbW11bml0eSwNCmFsb25nIHdpdGggZGVwZW5kZW5jaWVzIGFuZCByZWxhdGVkIHNv ZnR3YXJlLCBmb3IgdGhlIEZyZWVCU0QgcG9ydHMgdHJlZS4gVGhhdA0KaW5jbHVkZXMgYSBmdWxs IGRlc2t0b3AgZW52aXJvbm1lbnQgY2FsbGVkIEtERSBQbGFzbWEgKGZvciBib3RoIFgxMSBhbmQN CldheWxhbmQpIGFuZCBodW5kcmVkcyBvZiBhcHBsaWNhdGlvbnMgdGhhdCBjYW4gYmUgdXNlZCBv biBhbnkgRnJlZUJTRCBtYWNoaW5lLg0KDQpUaGUgS0RFIHRlYW0gKGtkZUApIGlzIHBhcnQgb2Yg ZGVza3RvcEAgYW5kIHgxMUAgYXMgd2VsbCwgYnVpbGRpbmcgdGhlIHNvZnR3YXJlDQpzdGFjayB0 byBtYWtlIEZyZWVCU0QgYmVhdXRpZnVsIGFuZCB1c2FibGUgYXMgYSBkYWlseS1kcml2ZXIgZ3Jh cGhpY3MtYmFzZWQNCmRlc2t0b3AgbWFjaGluZS4NCg0KICDigKIgSnVzdCB0d28gQ01ha2UgdXBk YXRlcyB0aGlzIHF1YXJ0ZXIsIGVuZGluZyB1cCB3aXRoIENNYWtlIDMuMjIuMS4gU29tZSBtb3Jl DQogICAgcGF0Y2hlcyBoYXZlIGxhbmRlZCB1cHN0cmVhbSwgYW5kIENNYWtlIGlzIHNvb24gdG8g c3dpdGNoIHRvIHNoYXJlL21hbiBmb3INCiAgICBtYW5wYWdlcyBvbiBGcmVlQlNELiBXaGVuIGl0 IGRvZXMsIHRoZXJlIHdpbGwgYmUgcGxlbnR5IG9mIHBrZy1wbGlzdCBjaHVybi4NCg0KICDigKIg TW9udGhseSByZWxlYXNlcyBvZiBLREUgRnJhbWV3b3JrcywgS0RFIFBsYXNtYSwgYW5kIEtERSBH ZWFyIGtlcHQgdGhlDQogICAgZXhwLXJ1bnMgZ29pbmcuIGtkZUAgd291bGQgbGlrZSB0byB0aGFu ayBBbnRvaW5lIGZvciBvdmVyc2VlaW5nIG91ciBtYW55DQogICAgZXhwLXJ1biByZXF1ZXN0cy4g V2UgYXJlIG5vdyBhdCBLREUgRnJhbWV3b3JrcyA1Ljg5IChsYXRlc3QgcmVsZWFzZSBhcyBvZg0K ICAgIERlY2VtYmVyIDIwMjEpLCBLREUgUGxhc21hIERlc2t0b3AgNS4yMy40IGFuZCBLREUgR2Vh ciAyMS4xMi4NCg0KICDigKIgUXQgNSBpcyBub3QgcmVjZWl2aW5nIGFueSBvcGVuIHNvdXJjZSB1 cGRhdGVzIGZyb20gdGhlIFF0IENvbXBhbnksIGJ1dCB0aGUNCiAgICBLREUgQ29tbXVuaXR5IG1h aW50YWlucyBpdHMgb3duIHNldCBvZiBwYXRjaGVzIHRoYXQgYmFja3BvcnQgbWFueSBmaXhlcw0K ICAgIGZyb20gUXQgNi4gV29yayBpcyB1bmRlcndheSB0byBpbXBvcnQgdGhlIEtERSBwYXRjaCBj b2xsZWN0aW9uLg0KDQogIOKAoiBRdCA2IHJlbWFpbnMgdGFudGFsaXppbmdseSBjbG9zZS4gVGhl cmUgaGFzbuKAmXQgYmVlbiByZWFsIHByb2dyZXNzIG9uIHRoZQ0KICAgIGNyYXNoLW9uLWV4aXQg cHJvYmxlbSwgdGhvdWdoLg0KDQogIOKAoiBkZXNrdXRpbHMva2FsZW5kYXIgaXMgYSByZWxhdGl2 ZWx5IG5ldyBwb3J0IHRoYXQgdXNlcyBLREUgdGVjaG5vbG9naWVzIGZvcg0KICAgIGEgZGVza3Rv cCAoYXBwb2ludG1lbnRzKSBjYWxlbmRhci4NCg0KICDigKIgZGVza3V0aWxzL2xhdHRlLWRvY2ss IGFuIGFsdGVybmF0aXZlIGxhdW5jaGVyIGZvciBLREUgUGxhc21hIChhbmQgb3RoZXINCiAgICBl bnZpcm9ubWVudHMpIHdhcyB1cGRhdGVkIHRvIGVhY2ggb2YgaXRzIGJ1Z2ZpeCByZWxlYXNlcy4N Cg0KICDigKIgZGV2ZWwvcWJzIGFuZCBkZXZlbC9xdGNyZWF0b3Igd2VyZSB1cGRhdGVkLiBRYnMg KG9yICJRdCBCdWlsZCBTeXN0ZW0iKSBpcyBhDQogICAgZGVjbGFyYXRpdmUgYnVpbGQgc3lzdGVt IHN0eWxlZCBhbG9uZyB0aGUgbGluZXMgb2YgZGVjbGFyYXRpdmUgUU1MDQogICAgcHJvZ3JhbXMu IChOb3RlIHRoYXQgUWJzIGlzIG5vdCB1c2VkIGJ5IFF0IGl0c2VsZikuDQoNCiAg4oCiIGdyYXBo aWNzL2RpZ2lrYW0gd2FzIHVwZGF0ZWQgdG8gdGhlIGxhdGVzdCByZWxlYXNlIGFuZCBub3cgc3Vw cG9ydHMgYm90aA0KICAgIEltYWdlTWFnaWNrIDYgYW5kIEltYWdlTWFnaWNrIDcuIFNwZWFraW5n IG9mIHdoaWNoLCBhIG5ldyBVU0VTPW1hZ2ljayB3YXMNCiAgICBpbnRyb2R1Y2VkIHRvIHNpbXBs aWZ5IHBvcnRzIHRoYXQgZGVwZW5kIGluIEltYWdlTWFnaWNrLg0KDQogIOKAoiBncmFwaGljcy9r c25pcCwgb25lIG9mIHNldmVyYWwgc2NyZWVuc2hvdC1hcHBsaWNhdGlvbnMgZm9yIEtERSBQbGFz bWEgKGFuZA0KICAgIG90aGVyIGVudmlyb25tZW50cykgaGFkIGEgbG90cy1vZi1idWdmaXhlcyB1 cGRhdGUuDQoNCiAg4oCiIGdyYXBoaWNzL3NrYW5wYWdlIGlzIGEgbmV3IHBvcnQgdGhhdCBzY2Fu cyBtdWx0aXBsZSBwYWdlcyBhbmQgcHJvZHVjZXMgYQ0KICAgIFBERiBvZiB0aGUgd2hvbGUuDQoN CiAg4oCiIG11bHRpbWVkaWEvcXQ1LW11bHRpbWVkaWEgbm93IGlnbm9yZXMgZ3N0cmVhbWVyLWds IChyYXRoZXIgdGhhbiBpbXBsaWNpdGx5DQogICAgYnVpbGRpbmcgd2l0aCBpdCBhcyBhIGRlcGVu ZGVuY3kgaWYgaXQgaXMgaW5zdGFsbGVkIGEgYnVpbGQgdGltZSkuDQoNCiAg4oCiIG5ldC1pbS9y dXFvbGEgaXMgYSBSb2NrZXQgQ2hhdCBjbGllbnQsIHVwZGF0ZWQgdG8gdGhlIGxhdGVzdCByZWxl YXNlLg0KDQogIOKAoiBzZWN1cml0eS9xdGtleWNoYWluIGhhcyBhIG5ldyByZWxlYXNlLg0KDQpF bHNld2hlcmUgaW4gdGhlIHNvZnR3YXJlIHN0YWNrLCBrZGVAIGFsc28gbWFpbnRhaW5zIHBvcnRz IHRoYXQgc3VwcG9ydCB0aGUNCmRlc2t0b3AgaW4gZ2VuZXJhbC4gU29tZSBoaWdobGlnaHRzIGFy ZToNCg0KICDigKIgZGV2ZWwvbGlicGhvbmVudW1iZXIga2VlcHMgY2hhc2luZyBjaGFuZ2VzIHRv IHRoZSB3b3JsZOKAmXMgcGhvbmUgbnVtYmVycw0KICAgICh0aGUgRnJlZUJTRCBmb3VuZGF0aW9u IGNhbiBiZSByZWFjaGVkIGF0ICsxLjcyMC4yMDcuNTE0MikuDQoNCiAg4oCiIGdyYXBoaWNzL3Bv cHBsZXIgdXBkYXRlZCB0aGlzIG11Y2gtdXNlZCBQREYtcmVuZGVyaW5nIGxpYnJhcnkuDQoNCiAg 4oCiIG11bHRpbWVkaWEvcGlwZXdpcmUsIHRoZSBhdWRpby1hbmQtdmlkZW8gc3VjY2Vzc29yIHRv IHB1bHNlYXVkaW8sIHdhcw0KICAgIHVwZGF0ZWQgYW5kIG5vdyBzdXBwb3J0cyBTU0wgYXMgd2Vs bC4NCg0KICDigKIgbmV0L3B5LXB5dHJhZGZyaSBnb3Qgc2V2ZXJhbCB1cGRhdGVzIHNvIHlvdSBj YW4gY29udHJvbCB5b3VyIGxpZ2h0cyBmcm9tDQogICAgRnJlZUJTRC4NCg0KICDigKIgcHJpbnQv ZnJlZXR5cGUyIHdhcyB1cGRhdGVkIHRvIHRoZSBsYXRlc3QgcmVsZWFzZTsgcmVsYXRlZGx5LCB0 aGVyZSB3YXMgYW0NCiAgICB1cGRhdGUgdG8geDExLXRvb2xraXRzL2xpYlhmdC4NCg0KICDigKIg cHJpbnQvaGFyZmJ1enosIHRoZSB0ZXh0LXNoYXBpbmcgbGlicmFyeSwgd2FzIHVwZGF0ZWQgZm9y IG1vcmUgZm9udCB0eXBlDQogICAgc3VwcG9ydC4NCg0KICDigKIgc3lzdXRpbHMvYnNkaXNrcyBp cyBhbiBpbXBsZW1lbnRhdGlvbiBvZiBEQnVzIGludGVyZmFjZXMgZm9yIGV4YW1pbmluZw0KICAg IGRpc2tzIChkcml2ZXMsIHBhcnRpdGlvbnMsIGV0Yy4pLiBJdCBpcyBhbHNvIHVzZWQgZm9yIHJl bW92YWJsZS1kaXNrDQogICAgbm90aWZpY2F0aW9ucy4NCg0KICDigKIgeDExLXRoZW1lcy9hZHdh aXRhLXF0LCB3aGljaCBjb25uZWN0cyB0aGUgYWR3YWl0YSB0aGVtZSBlbmdpbmUgdG8gUXQtYmFz ZWQNCiAgICBhcHBsaWNhdGlvbnMsIHdhcyB1cGRhdGVkLg0KDQrilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHi lIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIHilIENCg0KRnJlZUJT RCBPZmZpY2UgVGVhbQ0KDQpMaW5rczoNClRoZSBGcmVlQlNEIE9mZmljZSBwcm9qZWN0IFVSTDog aHR0cHM6Ly93aWtpLmZyZWVic2Qub3JnL09mZmljZQ0KDQpDb250YWN0OiBGcmVlQlNEIE9mZmlj ZSB0ZWFtIE1MIDxvZmZpY2VARnJlZUJTRC5vcmc+DQpDb250YWN0OiBEaW1hIFBhbm92IDxmbHVm ZnlARnJlZUJTRC5vcmc+DQpDb250YWN0OiBMaS1XZW4gSHN1IDxsd2hzdUBGcmVlQlNELm9yZz4N Cg0KVGhlIEZyZWVCU0QgT2ZmaWNlIHRlYW0gd29ya3Mgb24gYSBudW1iZXIgb2Ygb2ZmaWNlLXJl bGF0ZWQgc29mdHdhcmUgc3VpdGVzIGFuZA0KdG9vbHMgc3VjaCBhcyBPcGVuT2ZmaWNlIGFuZCBM aWJyZU9mZmljZS4NCg0KV29yayBkdXJpbmcgdGhpcyBxdWFydGVyIHdhcyBmb2N1c2VkIG9uIHBy b3ZpZGluZyB0aGUgbGF0ZXN0IHN0YWJsZSByZWxlYXNlIG9mDQpMaWJyZU9mZmljZSBzdWl0ZSBh bmQgY29tcGFuaW9uIGFwcHMgdG8gYWxsIEZyZWVCU0QgdXNlcnMuDQoNCkxhdGVzdCBhbmQgcXVh cnRlcmx5IHBvcnRzIGJyYW5jaGVzIGdvdCBhIG5ldyBicmFuY2ggKDcuMikgb2YgdGhlIExpYnJl T2ZmaWNlDQpzdWl0ZSBhbmQgdXBkYXRlZCB0byB0aGUgNy4yLjQgcmVsZWFzZSB3aGlsZSBuZXcg cHJlbGVhc2VzIHN1Y2ggYXMgNy4yLjUuUkMyDQphbmQgNy4zLjAuUkMxIGFyZSBjb29raW5nIGlu IHRoZSBXSVAgc3RhZ2UgYXJlYS4NCg0KTWVhbndoaWxlLCBvdXIgV0lQIHJlcG9zaXRvcnkgZ290 IGJhY2sgYSB3b3JraW5nIENJIGluc3RhbmNlIGFnYWluLCB0aGFua3MgdG8NCkxpLVdlbiBIc3Uu DQoNCkFsc28gd2UgYXJlIHN0aWxsIHdvcmtpbmcgb24gdGhlIEJvb3N0IFdJUCByZXBvc2l0b3J5 IHRvIGJyaW5nIHRoZSBsYXRlc3QgQm9vc3QNCmxpYnJhcnkgdG8gdGhlIHBvcnRzLg0KDQpXZSBh cmUgbG9va2luZyBmb3IgcGVvcGxlIHRvIGhlbHAgd2l0aCB0aGUgb3BlbiB0YXNrczoNCg0KICDi gKIgVGhlIG9wZW4gYnVncyBsaXN0IGNvbnRhaW5zIGFsbCBmaWxlZCBpc3N1ZXMgd2hpY2ggbmVl ZCBzb21lIGF0dGVudGlvbg0KDQogIOKAoiBVcHN0cmVhbSBsb2NhbCBwYXRjaGVzIGluIHBvcnRz DQoNClBhdGNoZXMsIGNvbW1lbnRzIGFuZCBvYmplY3Rpb25zIGFyZSBhbHdheXMgd2VsY29tZSBp biB0aGUgbWFpbGluZyBsaXN0IGFuZA0KYnVnemlsbGEuDQoNCuKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0KDQpUaGlyZC1Q YXJ0eSBQcm9qZWN0cw0KDQpNYW55IHByb2plY3RzIGJ1aWxkIHVwb24gRnJlZUJTRCBvciBpbmNv cnBvcmF0ZSBjb21wb25lbnRzIG9mIEZyZWVCU0QgaW50bw0KdGhlaXIgcHJvamVjdC4gQXMgdGhl c2UgcHJvamVjdHMgbWF5IGJlIG9mIGludGVyZXN0IHRvIHRoZSBicm9hZGVyIEZyZWVCU0QNCmNv bW11bml0eSwgd2Ugc29tZXRpbWVzIGluY2x1ZGUgYnJpZWYgdXBkYXRlcyBzdWJtaXR0ZWQgYnkg dGhlc2UgcHJvamVjdHMgaW4NCm91ciBxdWFydGVybHkgcmVwb3J0LiBUaGUgRnJlZUJTRCBwcm9q ZWN0IG1ha2VzIG5vIHJlcHJlc2VudGF0aW9uIGFzIHRvIHRoZQ0KYWNjdXJhY3kgb3IgdmVyYWNp dHkgb2YgYW55IGNsYWltcyBpbiB0aGVzZSBzdWJtaXNzaW9ucy4NCg0KaGVsbG9TeXN0ZW0NCg0K TGlua3M6DQpEb2N1bWVudGF0aW9uIFVSTDogaHR0cHM6Ly9oZWxsb3N5c3RlbS5naXRodWIuaW8v DQoNCkNvbnRhY3Q6IFNpbW9uIFBldGVyIDxwcm9ib25vQHB1cmVkYXJ3aW4ub3JnPg0KQ29udGFj dDogI2hlbGxvU3lzdGVtIG9uIGlyYy5saWJlcmEuY2hhdCwgbWlycm9yZWQgdG8gI2hlbGxvU3lz dGVtOm1hdHJpeC5vcmcNCm9uIE1hdHJpeA0KDQpXaGF0IGlzIGhlbGxvU3lzdGVtPw0KDQpoZWxs b1N5c3RlbSBpcyBGcmVlQlNEIHByZWNvbmZpZ3VyZWQgYXMgYSBkZXNrdG9wIG9wZXJhdGluZyBz eXN0ZW0gd2l0aCBhIGZvY3VzDQpvbiBzaW1wbGljaXR5LCBlbGVnYW5jZSwgYW5kIHVzYWJpbGl0 eS4gSXRzIGRlc2lnbiBmb2xsb3dzIHRoZSDigJxMZXNzLCBidXQNCmJldHRlcuKAnSBwaGlsb3Nv cGh5Lg0KDQpRNCAyMDIxIFN0YXR1cw0KDQogIOKAoiBWZXJzaW9uIDAuNy4wIG9mIGhlbGxvU3lz dGVtIGhhcyBiZWVuIHB1Ymxpc2hlZCBpbmNsdWRpbmcgbWFueSBjb250cmlidXRlZA0KICAgIGZl YXR1cmVzIGFuZCBidWdmaXhlcw0KDQogICAgICDilqEgaGVsbG9TeXN0ZW0gaXMgbm93IGJhc2Vk IG9uIEZyZWVCU0QgMTMuMC1SRUxFQVNFDQoNCiAgICAgIOKWoSBDb21wbGV0ZWx5IHJld29ya2Vk IExpdmUgSVNPIGFyY2hpdGVjdHVyZSwgcmVzdWx0aW5nIGluIDEvM3JkIGJvb3QgdGltZQ0KICAg ICAgICBhbmQgdW5kZXIgODAwIE1CIHNpemUgKGZpdHMgYSBDRC1ST00pDQoNCiAgICAgIOKWoSBE ZXZlbG9wZXIgVG9vbHMgYXJlIG5vdyBhIHNlcGFyYXRlIGRvd25sb2FkDQoNCiAgICAgIOKWoSBE aXNrIEltYWdlcyBhcmUgaW5jcmVhc2luZ2x5IHVzZWQgdGhyb3VnaG91dCB0aGUgc3lzdGVtLCBz dWNoIGFzIGZvcg0KICAgICAgICBhcHBsaWNhdGlvbiBkaXN0cmlidXRpb24gYW5kIExpbnV4dWxh dG9yIHVzZXJsYW5kIGRlcGxveW1lbnQNCg0KICAgICAg4pahIE1hbnkgbmV3IGZlYXR1cmVzIGFu ZCBHVUkgdXRpbGl0aWVzIHRvIG1ha2UgdGhlIGRlc2t0b3AgbW9yZSB1c2FibGUgZm9yDQogICAg ICAgICJtZXJlIG1vcnRhbHMiIHdpdGhvdXQgdGhlIG5lZWQgZm9yIGEgdGVybWluYWwNCg0KSW5z dGFsbGFibGUgTGl2ZSBJU08gaW1hZ2VzIGFuZCBhIGZ1bGwgY2hhbmdlbG9nIGFyZSBhdmFpbGFi bGUgYXQgaHR0cHM6Ly8NCmdpdGh1Yi5jb20vaGVsbG9TeXN0ZW0vSVNPL3JlbGVhc2VzL3RhZy9y MC43LjANCg0KQ29udHJpYnV0aW5nDQoNClRoZSBwcm9qZWN0IGFwcHJlY2lhdGVzIGNvbnRyaWJ1 dGlvbnMgaW4gdmFyaW91cyBhcmVhcy4NCg0K4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB 4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSB4pSBDQoNCkNvbnRhaW5lcnMgJiBGcmVl QlNEOiBQb3QsIFBvdGx1Y2sgJiBQb3RtYW4NCg0KTGlua3M6DQpQb3Qgb24gZ2l0aHViIFVSTDog aHR0cHM6Ly9naXRodWIuY29tL3BpenphbWlnL3BvdA0KUG90bHVjayBSZXBvc2l0b3J5ICYgUHJv amVjdCBVUkw6IGh0dHBzOi8vcG90bHVjay5ob25leWd1aWRlLm5ldC8NClBvdGx1Y2sgb24gZ2l0 aHViIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2hueS1nZC9wb3RsdWNrDQpQb3RtYW4gb24gZ2l0 aHViIFVSTDogaHR0cHM6Ly9naXRodWIuY29tL2dyZW1iby9wb3RtYW4NCg0KQ29udGFjdDogTHVj YSBQaXp6YW1pZ2xpbyAoUG90KSA8cGl6emFtaWdAZnJlZWJzZC5vcmc+DQpDb250YWN0OiBTdGVw aGFuIExpY2h0ZW5hdWVyIChQb3RsdWNrKSA8c2xAaG9uZXlndWlkZS5ldT4NCkNvbnRhY3Q6IE1p Y2hhZWwgR21lbGluIChQb3RtYW4pIDxncmVtYm9ARnJlZUJTRC5vcmc+DQoNClBvdCBpcyBhIGph aWwgbWFuYWdlbWVudCB0b29sIHRoYXQgYWxzbyBzdXBwb3J0cyBvcmNoZXN0cmF0aW9uIHRocm91 Z2ggTm9tYWQuDQoNCkluIHRoZSBsYXN0IHF1YXJ0ZXIsIGEgbmV3IHJlbGVhc2UgMC4xNC4wIHdp dGggYSBudW1iZXIgb2YgZml4ZXMgYW5kIGZlYXR1cmVzDQpsaWtlIHRoZSBuZXcgY29weS1pbi1m bHYgY29tbWFuZCB3YXMgbWFkZSBhdmFpbGFibGUuDQoNClBvdGx1Y2sgYWltcyB0byBiZSB0byBG cmVlQlNEIGFuZCBQb3Qgd2hhdCBEb2NrZXJodWIgaXMgdG8gTGludXggYW5kIERvY2tlcjogYQ0K cmVwb3NpdG9yeSBvZiBQb3QgZmxhdm91cnMgYW5kIGNvbXBsZXRlIGNvbnRhaW5lciBpbWFnZXMg Zm9yIHVzYWdlIHdpdGggUG90IGFuZA0KaW4gbWFueSBjYXNlcyBOb21hZC4NCg0KSGVyZSB3ZSBh Z2FpbiBoYWQgYSBidXN5IHF1YXJ0ZXIuIEFsbCBpbWFnZXMgaGF2ZSBiZWVuIHJlYnVpbHQgZm9y IEZyZWVCU0QgMTIuMw0KYW5kIHBvdCAwLjEzLjAuDQpBbHNvIHRoZSBpbWFnZXMgdGhhdCBjYW4g YmUgdXNlZCB0byBidWlsZCBhIHZpcnR1YWwgZGF0YSBjZW50ZXIgbGlrZSBOb21hZCwNCkNvbnN1 bCBhbmQgVmF1bHQgaGF2ZSByZWNlaXZlZCBhIGxvdCBtb3JlIHRlbmRlciBsb3ZlIGFuZCBjYXJl IGFuZCBhcmUNCm1lYW53aGlsZSBpbiBwcmUtcHJvZHVjdGlvbiB1c2Ugb24gYSBjbHVzdGVyIGF0 IGEgZmludGVjaC4NCk5vdCBhbGwgdGhlc2UgY2hhbmdlcyBoYXZlIHlldCBiZWVuIGNvbW1pdHRl ZCB0byB0aGUgZ2l0aHViIHJlcG9zaXRvcnkgdGhvdWdoLA0KdGhpcyBpcyBwbGFubmVkIGZvciB0 aGUgbmV4dCBxdWFydGVyLiBBZGRpdGlvbmFsbHksIG5ldyBpbWFnZXMgbGlrZQ0KbXVsdGktbWFz dGVyIE9wZW5MREFQIGhhdmUgYmVlbiBhZGRlZCwgdG9vLg0KDQpQb3RtYW4gYWltcyB0byBzaW1w bGlmeSBidWlsZGluZyBQb3QgaW1hZ2VzIHdpdGggVmFncmFudCBhbmQgVmlydHVhbEJveCBiYXNl ZA0Kb24gdGhlIFBvdGx1Y2sgYXBwcm9hY2gsIGUuZy4gYXMgcGFydCBvZiBhIERldk9wcyB3b3Jr ZmxvdyBmb3Igc29mdHdhcmUNCmRldmVsb3BtZW50IGluY2x1ZGluZyB0ZXN0aW5nIGFuZCBwdWJs aXNoaW5nIHRoZW0gdG8gYSByZXBvc2l0b3J5Lg0KDQpIZXJlIHdlIGhhdmUgbm90IHlldCBtYWRl IGEgbG90IG9mIGhlYWR3YXkgd2l0aCBvdXIgcGxhbiB0byB1dGlsaXNlIFBvdG1hbiBpbg0KdGhl IFBvdGx1Y2sgbGlicmFyeSBidWlsZCBwcm9jZXNzIGJ1dCB0aGlzIGlzIHN0aWxsIG9uIG91ciBU T0RPLWxpc3QsIGxpa2UNCmltcHJvdmluZyB0aGUgZG9jdW1lbnRhdGlvbiBmb3IgdXNpbmcgdGhl IFZpcnR1YWwgREMgaW1hZ2VzIGZyb20gdGhlIFBvdGx1Y2sNCmxpYnJhcnkuDQoNCkFzIGFsd2F5 cywgZmVlZGJhY2sgYW5kIHBhdGNoZXMgYXJlIHdlbGNvbWUuDQoNCuKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKU geKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgeKUgQ0K --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKkBAEBCgCOFiEEVbCTpybDiFVxIrrVNqQMg7DW754FAmIqsh5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUQHGpybUBmcmVl YnNkLm9yZwAKCRA2pAyDsNbvnj1pD/41O1IJ9LMpGJjwDEJ1h4uDQWgbvduuH1Mi 6qwYY9lD/o3/K2cOAfImmkjqJG5sepE6i8Nr9OKG0xHwSrumB+2V/3bJydujCENI SouKllhGUsUDo4tHBHgaTWIe30wjhaI2NSk6kqmSI4UJ030qrxaPamfx2pN8IRVz OPYW5JwisaEFwp0UXTtGY2cFZA8gb0YTvhrazRzH8sQGNOYkHOzHpSUozRc+9D9G GinMHOdmqsJ4ewj/9M24u3HJ4+aBLH8XaYt8MyJho5RBwIn52Z8358M5abDPkEbS 4xKYrktagp79kOSU7nNUoBEKdxCLeKrd7pvdQK9jd5st0PItWuAbd2QTQiYDtoUc Q3R/T68FpMxPS1kSCJ1siDui214eNPHQIfhdwOXSDCRTm4oIYzaxAUsBdV5uvoJr 1NUtRfXSbAyxDze/qDVOPeyzuZoo0C/4KwSbX0YRfYa1EoSvJgRIJd8jbLK0MRBe cqR/WYmyOJhTVh+QL368gbfEwQ9ZlkXEwUtofqZkM2yC4Lje6Dr7OYKArfOkgFWt pMGudE/qiKdTFVE/VvWeDQ/wmq1agVqZEX204YEyszuwXn5DH4tLqoqlydZoHcAL d0EfWO/Z8RTIokc/4I+mB6A2YOH4QIo+h7NH7naoPfuFNf5PNwzwVfNYok0dgbd+ e31h8a10rw== =TTeE -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 16 12:06:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 93AC71A11283 for ; Wed, 16 Mar 2022 12:06:44 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01olkn2030.outbound.protection.outlook.com [40.92.98.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJTXM4pd7z4bJb for ; Wed, 16 Mar 2022 12:06:43 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mj7Gye5LiRHQh8oCxrLC12SsGi4UiIlmn7IGftn5DN3NFhKPJuoty4wmapA+UCjYXpgvUXqzHKSag78N5cm0u84D1ytkhu7rmZ4JWgrwKgVyWxedVBBproHqoKkunkKuiGVHZTSmMrGhXSYG64PQKJS447HpeUbkk9jiDrNa9eAAnWImoINJK8s5Sap1+Hfs2y7TqVCZ4aX5rtQ2wtSIPb5i8DE7zhDJQnq4/FUnzH3Pa7ZaYAOZuHq7IdmGuF1dF0jGV/ouVX9i8YhEgPwC1GsZscebehbpQ8FqNI7k1A8JLx3E7qsm6cn4FxAx6s5lh215hhpCE3P+PRueSEg6/Q== 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=ZYUkwWqYpn/8ENEvdwrhsTm/69PsmQDLm1AVZmXd5Ls=; b=F+dgzWz1CsLZpCQNCV50mmed4YMZu5WpOgUt/Cm59iB6sbqoQFYapckgy58MrPv82DGkzlyoWbXCST99heKY2MjGHwIzL2Xexbg5EmGcs8f34NAxMsZxda7A7DVwOWZromfFCGey3UuNfyRKn2cYxNB2uVQX/wQvzHbtISxd8k9Eoec196SlQ4DL4+JuV3dqHTvqNid8GdXjoHJWMPnjF9pBZYJ2V76pNUYnskWIPsiUCbJEz9iut3if5aIuxQlfmcURJU2X+chNe8XLfJZ63Uf58N2N9QiLxjgbQ92On1ijWepSPF1IJpzmfiK6TlsgP+TRG9hBKBvXe4ZrnYrR3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZYUkwWqYpn/8ENEvdwrhsTm/69PsmQDLm1AVZmXd5Ls=; b=Cg3JvsFN4MfZNAJMTac3XeDIiLNtmhrtHnBHPJUhygyndFXli7aGyyPdQoj60qYsuaaIdoSNa2EgevzC+LEYKZMaS/p8eoHco7rrfz8HYMgN2PQfjgiJvvrVUZBcJfTQG+HuadIxjKT5Gv93Vsf/hD/UqUZQ1RtiCOkhgMPngI5NC6OK7b9wohTCCucl3COYNgWnyj+v7iazTQVmtpPnKE2HlS8S2wRLpM3y2ZOrB07bQCxLlKD6rvUskGEtLG3GshsRJHw5fG/OYPnFsSOSq4tZCDOmOSnOjaFRtlKJZ3NmxnBBhfQlIpYYUso3pJo8psUWsE6GKDWop6ge5sWofQ== Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:11a::9) by OS3P286MB2490.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:1f1::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.24; Wed, 16 Mar 2022 12:06:35 +0000 Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b]) by TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b%7]) with mapi id 15.20.5081.015; Wed, 16 Mar 2022 12:06:35 +0000 From: Daniel Cervus To: "freebsd-hackers@freebsd.org" Subject: AR9462 still not working properly Thread-Topic: AR9462 still not working properly Thread-Index: AQHX/51q64ieRyYR40Ob8xn4ikKeHaxzy0KDgE6Rkwg= Date: Wed, 16 Mar 2022 12:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [tO0x3XivKDJI6t6cSyVV7Tz3/q+oKbAU] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 456e8de8-da92-4142-81a9-08da07456ab9 x-ms-traffictypediagnostic: OS3P286MB2490:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NQTYGiKM8ckRTAqWJHd8JqQOz5UwKULRBf9x8SaK2xFKEWQlomfxYG5B9XCFxsedOMG98EaVf5CFIcJwjI05uBq50qxXPYA3CGA9+AOqsaSbnZ8qZpZotDU4Mw6z50VZ/qlsnOiAMNqv1z/OiH7FxCnWtghzi9iDNXtsq1OOsWejAUxhRF615PLh07twh/8jICM/AEGLzjvLO5JmZg6bT61tCWuQlhjWFXUsEUOj/h2OKfsSc7YXbEaqnqdiT+DL4SNWy9hvaj19IyETUQJgbQuToLZmY7NtSzUzKwBiFXBKXoEzVFYnVco4G7Rr9fcEYpC8UliNs3VAmotiWWAkea2TduuJpXtcBWNFpYI/wpSfnVTkMgumVQtgYhJF/Ic/HFdfhbcisRwz8xK/LApPHpFYQG/kKBX6A5eE+uFFFSJr2VPHvAO/Ef/R1LBhJhDtGTr4+2lAh2b7EqoVfqe9+8Ft2/i+EtVj8+RbRtou/ySv2JUpunSivE6WZMoCRTmN7FG7stsOL/yJpYtvgRmdtEUclYEh4bb59qEqVhbzCt9sBp1bNMrImQp3fWy9sS4lvfVh5dt3VqMaWmtaWprZsA== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?FONlr+velOqH70OhZiWL7shu42BLVXiz4yNrWm2RX9h4E/ImLLSR7kAe?= =?Windows-1252?Q?ZZgthPOVqUn/5dCv4BZYmgXzbLPpdvKeFJrXLoUdRDE2HZSRyXrMlniD?= =?Windows-1252?Q?U8N9f5/i5VKuDPaCEJ616vmHd2LhzAPur3P2faoh65IlEaFOWrCjRmPK?= =?Windows-1252?Q?s4xVi3SOvl0GR2nd/oCY7qXZsA3ObRled7Y4dz5V+Fk2dDmqoMNEejZ0?= =?Windows-1252?Q?yiwzDS394lDNcEujBpIpOtFOOCy7JkKiq15XHdrMLyz7xQWa4KBDGEsO?= =?Windows-1252?Q?+8hFZCvys5ttnil6AvenEnsazA9h9iZ24qmectRKxxWu/G1mmZoj2lBh?= =?Windows-1252?Q?pvKCdHxL9j5G9TQTkwHqhRiSbNps0h1hNiLWXIxDyIB4UUbzC2X5ZeGy?= =?Windows-1252?Q?L1ak4QMJfBc3wlr05va/IO0EOPuOqcWfwYMRPgBgD1jiwf/kpyOCSLvq?= =?Windows-1252?Q?/szWwkiPq4kUPKkNPYSMkInSt4UppJJBVJMHskarEZzOYP8eLaGRv7mZ?= =?Windows-1252?Q?6WGndrKdmtAjd8AAxa8zCFd/yNXjfCwqD/yf9YdRKdRi4NAI+77njQsF?= =?Windows-1252?Q?KroMQv2U0k8AMjYsZz14GA8XYRjfDCSYg0YDW7YWNC6zfEmBbR6G04sW?= =?Windows-1252?Q?D+0osC9Hg7lCo4T+8lkK6fJs+QcEbTiD5E0WwRB/2NE6kZcOAnsAOZgn?= =?Windows-1252?Q?7+pVguQZBs6lLfM8DLDAi3Kn1h9vLb/kNiWNdjqsNu/MEDc4xVHPwum5?= =?Windows-1252?Q?8roxzKP0WbSP1J5V5M45SPYIZJsUUyISfXEnRANCMjcOZST2eOMbavrz?= =?Windows-1252?Q?nXf/oNnUFx48QRxvjnu8JhNbZhm2MewelurLSDyYIbjB5E+iT1Tb/11C?= =?Windows-1252?Q?QWW2Px5Dvb4sr1isGZOcRnNiLvGPP5nk/CL/6JptVfQSAhqlHNJ/mvZV?= =?Windows-1252?Q?Bmiv1jRW90fpxFdpweAqUT2zG7a/5fNDUJeK1jIbF42/9iMtVZRYPWVT?= =?Windows-1252?Q?9eK4uqscSTqMK7utTXt9QnMsAOIfMNFNDEHKxX1ZP9yx1a2mVtXUrKSQ?= =?Windows-1252?Q?p5k4lR4W0xIXJh46w0cUiB7st82t9Q6ytG8PBCeEMPtfh5MODIBcVRHG?= =?Windows-1252?Q?N/jpTf2pLBTBXHabAmkftxczQv8765lyjQz5jidcNk6K6MKFs8mncPR0?= =?Windows-1252?Q?QEaQWZJF0jeSWLYArbCuH16V6cSh0RcFQ2OXunEC7nQ/UtXW9ao8jSZV?= =?Windows-1252?Q?zqCw7HAMb4rTvjwa3HiQPjqrnlbW+fX3AhCxUcEt?= Content-Type: multipart/alternative; boundary="_000_TYYP286MB154630E3F7A92BB689AD3ED9B8119TYYP286MB1546JPNP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 456e8de8-da92-4142-81a9-08da07456ab9 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 12:06:35.0714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS3P286MB2490 X-Rspamd-Queue-Id: 4KJTXM4pd7z4bJb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=Cg3JvsFN; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 40.92.98.30 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.88 / 15.00]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[outlook.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; RCVD_IN_DNSWL_NONE(0.00)[40.92.98.30:from]; NEURAL_HAM_SHORT(-0.93)[-0.933]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[outlook.com]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.98.30:from] X-ThisMailContainsUnwantedMimeParts: N --_000_TYYP286MB154630E3F7A92BB689AD3ED9B8119TYYP286MB1546JPNP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, everyone. I have been using Dell 1901 (AR9462) wireless card since r= elease 12.2, but minor problems keep occuring. For example, it cannot be re= cognized in bsdconfig, when not connected to networks, error message =93Fai= led to add operating class IE=94 repeates. I remembered someone has told me= that he would deal with that. Now, I have done a brand-new installation of 12.3. But bsdinstall still had= diffculty in scanning Wi-Fis, and after I had tried a few times, no Wi-Fi = could be found at all. How to deal with this? I have put up a PR about that= . I=92m sorry for that I may have described the problem unclearly there. An= d is there any information I need to provide? --_000_TYYP286MB154630E3F7A92BB689AD3ED9B8119TYYP286MB1546JPNP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello, everyone. I have been us= ing Dell 1901 (AR9462) wireless card since release 12.2, but minor problems= keep occuring. For example, it cannot be recognized in bsdconfig, when not= connected to networks, error message =93Failed to add operating class IE=94 repeates. I remembered someone has = told me that he would deal with that.

Now, I have done a brand-new installation of = 12.3. But bsdinstall still had diffculty in scanning Wi-Fis, and after I ha= d tried a few times, no Wi-Fi could be found at all. How to deal with this? I have put up a PR about that. I=92m = sorry for that I may have described the problem unclearly there. And is the= re any information I need to provide?

 

--_000_TYYP286MB154630E3F7A92BB689AD3ED9B8119TYYP286MB1546JPNP_-- From nobody Wed Mar 16 12:51:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F2501A1CCD0 for ; Wed, 16 Mar 2022 12:51:59 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJVXZ0M0pz4jdN for ; Wed, 16 Mar 2022 12:51:58 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x734.google.com with SMTP id 85so1705585qkm.9 for ; Wed, 16 Mar 2022 05:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=5Kis4S2T0fPDUP03CgvQuMes4MokZ5Y8YBrsEXeERMQ=; b=mNRRBsz33QonHhoLN8DLRe4uv0Uoxphoxi9zZ4q8wZmI4MNXBRUCDAbMVjbiX62fmz w7C6FUhsighc85nEo7QkbtXbB5CVhLzi+NANNYFPReQ54T+FWXeVc6TpLFtcYLuOPPF9 NfhDn+DDzf36LtdFLwT1VnuXD5OKplOzRz/l895Jq8cp+dyIWPmXo/uAcL59St8pdj2A shcYWPPGEVC9APLz6GMb/j20pHxp4NUciVTBsdceSD8vWhryGmXQhhKbJokv6JAQqCZa KIPRze8EMNGAQ6pPaCMQDV4uVOaoHGQgRV1EQ1s4ud4jjrBHCJpQV0nrINVCp6kd71rD Zr+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=5Kis4S2T0fPDUP03CgvQuMes4MokZ5Y8YBrsEXeERMQ=; b=KXtVXZJUuogbEpK6kBfMw8i2ejyJHG2zg1tTsLdYhnMEOJPDzxhIZu1IlfkQTdvuyZ qpKlK4VlglDZKbYQjGUTA0Aytyw0fw/Pr84rtAOslwLTmVfV4kUkuWa8AAwYNGfrspCI gZOL1dKT6OSkwv/yFQweIGrLpAR9FvhOAntA7f4pEGbW9BY3Id7Lq+COCE3kdh514au9 7yjPZ0KZNN1zZZCfSpr3HwRMdWlLY0HeL3K9rA5SAxC2MJ75bz5L4uAebh2isrb73FNt 8SfbOtnMj/padCae7/kbqMdCb38AJLTj94BnTaxJYMBeEwcoiC/R1lP1MGnVW9q4Y9rj NVwA== X-Gm-Message-State: AOAM532T1gTWh4tUw0U7TPBr5hZRc7bKneA//wvNo/bzeh5+/dmZlnMw z0vUV+dTITwu4LiYa3+sRMSDM6Jr3KY= X-Google-Smtp-Source: ABdhPJxjWH5dKsSJXPoNx7VhsemzTIifj9OyT2kqsqzP2VQjskpVfLK/dLCkn0PUSZYlRfMxWQK9qQ== X-Received: by 2002:a05:620a:2912:b0:67b:249e:3ffb with SMTP id m18-20020a05620a291200b0067b249e3ffbmr20325049qkp.777.1647435117354; Wed, 16 Mar 2022 05:51:57 -0700 (PDT) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id n143-20020a37a495000000b0067b12bc1d7bsm848360qke.13.2022.03.16.05.51.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Mar 2022 05:51:56 -0700 (PDT) Message-ID: Date: Wed, 16 Mar 2022 07:51:55 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: AR9462 still not working properly Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4KJVXZ0M0pz4jdN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mNRRBsz3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::734 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-0.14 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0: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:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.84)[0.840]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.92)[0.924]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::734:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N T24gMy8xNi8yMiAwNzowNiwgRGFuaWVsIENlcnZ1cyB3cm90ZToNCj4gSGVsbG8sIGV2ZXJ5 b25lLiBJIGhhdmUgYmVlbiB1c2luZyBEZWxsIDE5MDEgKEFSOTQ2Mikgd2lyZWxlc3MgY2Fy ZCANCj4gc2luY2UgcmVsZWFzZSAxMi4yLCBidXQgbWlub3IgcHJvYmxlbXMga2VlcCBvY2N1 cmluZy4gRm9yIGV4YW1wbGUsIGl0IA0KPiBjYW5ub3QgYmUgcmVjb2duaXplZCBpbiBic2Rj b25maWcsIHdoZW4gbm90IGNvbm5lY3RlZCB0byBuZXR3b3JrcywgZXJyb3IgDQo+IG1lc3Nh Z2Ug4oCcRmFpbGVkIHRvIGFkZCBvcGVyYXRpbmcgY2xhc3MgSUXigJ0gcmVwZWF0ZXMuIEkg cmVtZW1iZXJlZCANCj4gc29tZW9uZSBoYXMgdG9sZCBtZSB0aGF0IGhlIHdvdWxkIGRlYWwg d2l0aCB0aGF0Lg0KPiANCj4gTm93LCBJIGhhdmUgZG9uZSBhIGJyYW5kLW5ldyBpbnN0YWxs YXRpb24gb2YgMTIuMy4gQnV0IGJzZGluc3RhbGwgc3RpbGwgDQo+IGhhZCBkaWZmY3VsdHkg aW4gc2Nhbm5pbmcgV2ktRmlzLCBhbmQgYWZ0ZXIgSSBoYWQgdHJpZWQgYSBmZXcgdGltZXMs IG5vIA0KPiBXaS1GaSBjb3VsZCBiZSBmb3VuZCBhdCBhbGwuIEhvdyB0byBkZWFsIHdpdGgg dGhpcz8gSSBoYXZlIHB1dCB1cCBhIFBSIA0KPiBhYm91dCB0aGF0LiBJ4oCZbSBzb3JyeSBm b3IgdGhhdCBJIG1heSBoYXZlIGRlc2NyaWJlZCB0aGUgcHJvYmxlbSANCj4gdW5jbGVhcmx5 IHRoZXJlLiBBbmQgaXMgdGhlcmUgYW55IGluZm9ybWF0aW9uIEkgbmVlZCB0byBwcm92aWRl Pw0KPiANCg0KSXMgdGhlcmUgYSBwcm9ibGVtIHdpdGggMTMueCAob3IgZXZlbiAxNCkgb24g dGhpcyBtYWNoaW5lPyAgV2hpbGUgMTIueCANCmlzIGZ1bGx5IHN1cHBvcnRlZCBhbmQgd2ls bCByZWNlaXZlIGFsbCBzZWN1cml0eSBmaXhlcywgaXQgd29uJ3Qgc2VlIA0KbXVjaCBpbiB0 aGUgd2F5IG9mIG5ldyBkcml2ZXIgZGV2ZWxvcG1lbnQuDQoNCklmIHlvdSBuZWVkIGEgc3Rv cC1nYXAgc29sdXRpb24sIEkndmUgaGFkIGdvb2QgZXhwZXJpZW5jZXMgd2l0aCBFZGltYXgg DQpVU0IgV2lGaSBkb25nbGVzLCBlLmcuOiANCmh0dHBzOi8vd3d3LmVkaW1heC5jb20vZWRp bWF4L21lcmNoYW5kaXNlL21lcmNoYW5kaXNlX2RldGFpbC9kYXRhL2VkaW1heC9pbi93aXJl bGVzc19hZGFwdGVyc19uMTUwL2V3LTc4MTF1bi8uIA0KICBJIHVzZWQgdGhlbSBvbiBhIExl bm92byB1bnRpbCB0aGUgbmF0aXZlIGRyaXZlciB3YXMgZGV2ZWxvcGVkLCBhbmQgb24gDQpN YWNzIHdpdGggQnJvYWRjb21tIFdpRmkgdGhhdCdzIGEgcGFpbiBpZiBpdCB3b3JrcyBhdCBh bGwuDQoNCi0tIA0KTGlmZSBpcyBhIGdhbWUuICBQbGF5IGhhcmQsIHBsYXkgZmFpciwgYW5k IGhhdmUgZnVuLi4uDQo= From nobody Wed Mar 16 12:53:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B4541A1D90B for ; Wed, 16 Mar 2022 12:53:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJVZH0hXTz4kc9 for ; Wed, 16 Mar 2022 12:53:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x430.google.com with SMTP id u10so2820864wra.9 for ; Wed, 16 Mar 2022 05:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=p+5LdSJZEX9Q2Ao6A9vlop6jqavz7EN1d/AweGtI+BM=; b=ZNne+hIRTba1cpAADhuMyzEjiUFuAGWDYb2P0M/x/tkP/QSVsVbd1whqanBDcbSfEE E2DdVi8/iPRelz3zJhNXImjHllSax1RM/epLPKPkSo78u5Odp4piY0lrs32Xq3pRLVdb aL9mpQ1wSzSHnjO7sFVxt9DrqfOCqjocZiYFCGL7M7hzKSp8zT3tzPjXjmU7CMKdXu86 ba0SANrcZU1k5Oe+CSnbJ6Q8W3spQHvy1ufdR90oHQ2yhSHaIpSwq3bFpNDbmEXnYG8F wbtokXKv22M8WCOliGD8LSsTxDRLbEqGZwjDwSdsOIHeTTselRYealvQJcAEcQRiAFJI 8Zpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=p+5LdSJZEX9Q2Ao6A9vlop6jqavz7EN1d/AweGtI+BM=; b=FLfFXyFsbmUTor7ydp2kuBfkuqknJvCBujxin0ajvYmHoQcRC9bwFe19APh48gQ9B0 byrkqfkP6ZVU5TIrd8o6AC6QcqEMdMlsJPXHO6a4GmhA3F77d1HBmzoGbgrPtsCFTwIA Tk3JD/gO+BX2m5RhyOWRL5d6zXxy+wfTQJWur4mZe23diCl5doylgb9ezmHfDWyIDis7 MD3OJGRXTku2FsACrAukayC214CW2mhNS2dYpzczC88vrS3L22I9ar+1R3Y1X8BkAxdo FmvNgyR8WtHF2209z5A5yC6fblzuvGAzbjqm6qsHRQN/9u8R/OwqkAB5cd/m5TApJ5tD eosQ== X-Gm-Message-State: AOAM533vgQpwVuXb3qLeXZlMGElDfW1qYZJOAn9UKw9j4liJErAFy5Hk zkoIX3mMcnp9jH8F9gf19ijeraW9BPI= X-Google-Smtp-Source: ABdhPJz90noriz9q6F5v6nt4xYpBnHmhDVYLzyxtOkR7OHo4qRoU1WZBgE/UXbXRupl86RvJ8n5ulA== X-Received: by 2002:a05:6000:2cf:b0:203:7326:cae5 with SMTP id o15-20020a05600002cf00b002037326cae5mr24161832wry.198.1647435200537; Wed, 16 Mar 2022 05:53:20 -0700 (PDT) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id bg42-20020a05600c3caa00b00380deeaae72sm3914726wmb.1.2022.03.16.05.53.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 05:53:19 -0700 (PDT) Date: Wed, 16 Mar 2022 13:53:11 +0100 From: Gary Jennejohn To: Daniel Cervus Cc: "freebsd-hackers@freebsd.org" Subject: Re: AR9462 still not working properly Message-ID: <20220316135311.71d80332@ernst.home> In-Reply-To: References: Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KJVZH0hXTz4kc9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZNne+hIR; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::430 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-0.02 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[outlook.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.98)[0.984]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::430:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 16 Mar 2022 12:06:35 +0000 Daniel Cervus wrote: > Hello, everyone. I have been using Dell 1901 (AR9462) wireless card > since release 12.2, but minor problems keep occuring. For example, > it cannot be recognized in bsdconfig, when not connected to > networks, error message ?Failed to add operating class IE? repeates. > I remembered someone has told me that he would deal with that. > Now, I have done a brand-new installation of 12.3. But bsdinstall > still had diffculty in scanning Wi-Fis, and after I had tried a few > times, no Wi-Fi could be found at all. How to deal with this? I > have put up a PR about that. I?m sorry for that I may have > described the problem unclearly there. And is there any information > I need to provide? > Adding a link to the PR would make things easier for people interested in helping. -- Gary Jennejohn From nobody Wed Mar 16 13:06:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 97C101A2204B for ; Wed, 16 Mar 2022 13:07:03 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2085.outbound.protection.outlook.com [40.92.99.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 4KJVsy5fHLz4msv for ; Wed, 16 Mar 2022 13:07:02 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DX2qxFzes008fACx4HdBjlIF2jDAtcP/gKmGR9IdlcgxFqq9ObCpt66LA4yfioWwutxB7CYHd5Athp55rSdVdKo+Rb3VhAfLqaMZtjgz1K06CnzLFaemMr7D0qq1pCVNkC+TCGTAja/a/u7rBfVJuLgFG0pAXcT/wP3YN+hYczPAU7K0nzPXrutJWnH4Ar49Nkaa3u3410aXmIZ3g9ly3ULaMM/SiF5A+TKJueXBxm7nypGfbhpxM6MooWEWNLJQ4PoVr4fboESeDSBjUDUJLWKV1Ra2WOchxY9gBcYC1+1cdNP0TtVF13xTOl4OaPXqEd8SSukPFWXlAk+wcjwK0Q== 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=ftDQHVCjyGwVMziPIbbIWt1doiR1s4Qgug+IeOO066M=; b=d++5vdLWbZN4CArNIGubY6S2/N/Zm/+dNF4hY+1NUwTDg7NNIBdL3B9BeWqqoWkc0i4ajUTxRwpzNgLtcI+gYl4q+6xsjS5q1woCc253Q3H0/HpQNpTb0EsNwcK4IHrbFq3ewqqqJGauoLUrTb1FGYFakIvO19TWI1F3XdNGdqFsuBB1ECXKQt7OwUPdE0XwChlq7oQvpiBdDu/lpAOGkc8s0lPZpR6I+4N2KBkvNa0jG4ZjbyK3g3WMKWG9RegZojZpppYWqkewIsT8Lwn9pYkzcYCN29+aa4irblxIR7QZhzZNFklVcStog9nLyc8dKuAjVESVW1HQ0zuArPr78A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ftDQHVCjyGwVMziPIbbIWt1doiR1s4Qgug+IeOO066M=; b=e3VROjURDSFlHTerzUFViuulg6WMIbJZU4a1EjW6P7Bz/PaxaeEJjmPga7oo5U1wq4yFBvx87N7YQfM/yFiCkLw0AkW29g8q3AySwLcKRUNuKh5fiZjsRk4lmPIm1Tqa7L3Vt1tuuQJQI1hCWr+h+/tXscymDu6INwGcANG/WVhSsrPwfekfcg0DVYPjN/F1JzOpjnX5dLvNQyQqToTB7pkyeW5AXkSOLdMfz4c5OSe/aw65ciirTbW1o5/IbmA9S74CcKJl1anhQ02FXi11H5QaaZ4sUH/n3Q3hqYYskMAQ2uiGmYajQhprMllcu5VEWGgaNwpIlOjH34/JhAhz6A== Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:11a::9) by TYYP286MB1148.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:cf::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.24; Wed, 16 Mar 2022 13:06:53 +0000 Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b]) by TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b%7]) with mapi id 15.20.5081.015; Wed, 16 Mar 2022 13:06:53 +0000 From: Daniel Cervus To: Jason Bacon CC: "freebsd-hackers@freebsd.org" Subject: Re: AR9462 still not working properly Thread-Topic: AR9462 still not working properly Thread-Index: AQHX/51q64ieRyYR40Ob8xn4ikKeHaxzy0KDgE6RkwiAAA0rgIAABC6d Date: Wed, 16 Mar 2022 13:06:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [3R8wnwfsSMQRC11ixmCSmHrqXHWlooPglBt85XmMphksiBpqrakx4Y0r5GKVOxFP] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc673b91-5829-463a-d362-08da074dd747 x-ms-traffictypediagnostic: TYYP286MB1148:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Op0gSuJd3NwTQmjSx3wXaTmiqGXQcsQj5r3c25oY/BFngHKzS2o4Vu4HDbVb0LdItGbg9B0XJwSGneyL7Qm6nxnauKQfcgsGL29yaU/YSVWPUMxd47K8fNLQvH3igT7bfCuhwmmRGXFh7IGx9QMKLzh0X+Ae0CM8vQ+eRVKbMV+vv65GjUltPGPjPokfVGXN/ZpnrDh4rnuc/58T/QFD1fQavykJFqHe0/QUc602h0KNeAzPsOnxPENtnPmj1O+NHqRHo0EUL6YlQ6ko7s1S4H70m0zC7YdazVkRwbKtqLbhXd6A4xa/GjqPMkKCmrTkoJzRCz3gj7xfYX6C+eR6y4IFKkfUqlekoPD6yTOlE5atsQTgIEPWY+U4w37JUErxwnAFtnRRNVW9iZVKgVImHT25eM+YsrL5Q6gb4m0Uc6xgA4cnULe99v7omVNp5kix8pltug/qtDnTbyLpciehXaiNLhKxNk8K99ZiGCe2Pn9SeSGLmxDIVF+C9UN8shn+k/xsp7kECp4ul7Ub/GtxiJKnTOA+bLfi4lL4rBWzFsfKShQbJmquC5uhozL9q5C3kvRV/csg2yfJZuZFesbFWcMEBZhQ+Zm7I3qfS0GdTPrqaHWAbEOQT6gSbIdIgWmo x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SndCcVhvbUtTL0trMTUxTStjcWxOK3NFODBYNFJickFGcmxYaVpjNE1hTkUz?= =?utf-8?B?K1BtbU9qVWdNdHhqZTZoSW8xeU1LZE5RMWNTMTlCM1VUUFdOeFhZOStuUmZl?= =?utf-8?B?Z3pOTVJFNVF5ZEhLOW9TTVF3cEorTWdCeXNlUmR6a012bGhabHdCTkxZVkRK?= =?utf-8?B?M1lIaWRaUWFsckIzQ1ZCY3V0UEJUeWpmWlZnZTd3ZWUzQW1mbmJqL3FBaVph?= =?utf-8?B?QUtWMTVyMDlVbmZXQkQ5NzNBOWNqTnY0RHUraWVMTmVJUDNxTmhUT1h4dkxR?= =?utf-8?B?b1daUnlPWW5OaDR3TnpoVTlXMGJFTTE3d1Y4bHlOL1E5YTFlSHp1blZqZDFy?= =?utf-8?B?L3l3emxSaGxtVjRkR0NoVi9SaHpjTTZ5dWxYODQyMFpYd00wUThveFk5dHlM?= =?utf-8?B?dWswL1J3RHY1MjEzc3JYVFg3Ung0M3FYelZFTFRMVUphYkdmOHFIRnNaaFlB?= =?utf-8?B?cGZ0dXBlQ25hTjFjdFMzUUNtc2FFT1F2MEVGdWR6S01PMERUSSt5c0RoMHFN?= =?utf-8?B?NVdKcGJ1bDNadzM1ak9hbDZ0Y0xuUGt6M3UvZUF6QXprTC9nbUNTSlpTbVVU?= =?utf-8?B?eitaaEIranB3amsxcmpGRDREeGI0RWVXOTZwWUxFZXpPbmNSUXVGbWFjQkts?= =?utf-8?B?MHZvTWlRcXVJcVFyYUJ5NzZkZjFLK3BxM2VKSkVJeXpTeWZ5SGVnMlJaekFV?= =?utf-8?B?WjNtYVJpUzBTSVB6M21TY0N4U2JHd1ZSRStQN1l1U3VFckRkaWR0cDlDTFBO?= =?utf-8?B?WDJvVzQrSTArN0l3eDVSK3lpM2F0M21GdlVDMDNnRTdKYmpVdUxDMVo1cEFt?= =?utf-8?B?MUpVWnAyY21Wc1FHdmtMd0ZRa3RSU0s0aEx1VjU3Uk9pSEM1c3FYNVg4d2JX?= =?utf-8?B?ZDl6bmtxQXRuMkNUbDljRUJobG54QmZzeWdyNENhMmkraWFyTEhZU1RiaWlM?= =?utf-8?B?U2ExT3c1NGdCS0E3NkozMk5PVmluK1ZuMFI5dElVM3BlMU5yMFgwcDhpcHMw?= =?utf-8?B?TEFoR3p6MWFUbDZmOHBmK2F1TkM0ZUl2bGlQbW1sZDRNRlpQK21VOUhBZ09P?= =?utf-8?B?U0sxU2NqMm9ydnVtRTBZRkFqZHpVd0FOdjJub0JsbmtVNXUxWHR4NlBFRUdD?= =?utf-8?B?UkYrOVhGWGJMQm9DQUI4b2dIajBEaGFScmpwb0RYUVJaTGlKanMzaVQ1YVNz?= =?utf-8?B?eVRqOTYwM0lLS3VGa2VDNmZtbTQ3L3hCbmlzanpueWZYQWNldjMxUFBya0gz?= =?utf-8?B?TUdoZ0txT0c1ajBkSGdqbzh5T0taNzdWQ3ZNU3BJanVtT3ZrbGR1SjJPMnpO?= =?utf-8?B?cnNraURQajAwVUlaRng1eEFKbDlURjRWbEdYc29EaTBXOXVMdmgrbFFWK00w?= =?utf-8?B?L21nMjRldkk3QUlObFZudXBwOGNGUGdRdlJyeURqem54WkRPR2k5VUkyaTY2?= =?utf-8?B?VWp1dEpwOVM2NUpaQkNveGxMeDM3a3JzUUdRN29HdUwwWG5ESUUzZGNuUmJC?= =?utf-8?B?NCtBWFNHOVpUOWFiZkxZRmlzUmtLU2dBNTZ5ajZ2WSt4bXg5UTBvT0ZLa3dL?= =?utf-8?B?eGsxRmpZanNhSFdxaGd1OTJxMktsUWViZ0tVUUcvZmpYMjQ4cFYyN0lDV0dp?= =?utf-8?Q?e3SXz8MGxNEVuL2az8bIDFhac9l+b31udi1TgnpzQWvo=3D?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: bc673b91-5829-463a-d362-08da074dd747 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 13:06:53.1549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB1148 X-Rspamd-Queue-Id: 4KJVsy5fHLz4msv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=e3VROjUR; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 40.92.99.85 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.68 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[outlook.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; FREEMAIL_ENVFROM(0.00)[outlook.com]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; NEURAL_HAM_MEDIUM(-0.88)[-0.878]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.964]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.92.99.85:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.99.85:from] X-ThisMailContainsUnwantedMimeParts: N SSBndWVzcyBpdOKAmXMgc3RpbGwgdGhlIHNhbWUsIGJlY2F1c2UgQVI5NDYyIGlzIGZ1bGx5IHN1 cHBvcnRlZCBpbiAxMiwgYW5kIHllcyBpdOKAmXMgYSAxMC15ZWFyIG9sZCBjb21wdXRlci4gSSBk b27igJl0IGhhdmUgdGhlIGltbWVkaWF0ZSBuZWVkIHRvIHVwZ3JhZGUuDQoNCldoYXTigJlzIG1v cmUsIEkgaGF2ZSBhbHJlYWR5IHJlcGxhY2VkIHRoZSBOSUMgYmVjYXVzZSBJIGhhZCBjb25maXJt ZWQgQVI5NDYyIGlzIGZ1bGx5IHN1cHBvcnRlZCENCg0KPiBJcyB0aGVyZSBhIHByb2JsZW0gd2l0 aCAxMy54IChvciBldmVuIDE0KSBvbiB0aGlzIG1hY2hpbmU/ICBXaGlsZSAxMi54IGlzIGZ1bGx5 IHN1cHBvcnRlZCBhbmQgd2lsbCByZWNlaXZlIGFsbCBzZWN1cml0eSBmaXhlcywgaXQgd29uJ3Qg c2VlIG11Y2ggaW4gdGhlIHdheSBvZiBuZXcgZHJpdmVyIGRldmVsb3BtZW50Lg0KPiANCj4gSWYg eW91IG5lZWQgYSBzdG9wLWdhcCBzb2x1dGlvbiwgSSd2ZSBoYWQgZ29vZCBleHBlcmllbmNlcyB3 aXRoIEVkaW1heCBVU0IgV2lGaSBkb25nbGVzLCBlLmcuOiBodHRwczovL3d3dy5lZGltYXguY29t L2VkaW1heC9tZXJjaGFuZGlzZS9tZXJjaGFuZGlzZV9kZXRhaWwvZGF0YS9lZGltYXgvaW4vd2ly ZWxlc3NfYWRhcHRlcnNfbjE1MC9ldy03ODExdW4vLiAgSSB1c2VkIHRoZW0gb24gYSBMZW5vdm8g dW50aWwgdGhlIG5hdGl2ZSBkcml2ZXIgd2FzIGRldmVsb3BlZCwgYW5kIG9uIE1hY3Mgd2l0aCBC cm9hZGNvbW0gV2lGaSB0aGF0J3MgYSBwYWluIGlmIGl0IHdvcmtzIGF0IGFsbC4NCj4gDQo+IC0t IA0KPiBMaWZlIGlzIGEgZ2FtZS4gIFBsYXkgaGFyZCwgcGxheSBmYWlyLCBhbmQgaGF2ZSBmdW4u Li4NCg== From nobody Wed Mar 16 13:17:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D3A21A24F7E for ; Wed, 16 Mar 2022 13:17:45 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01olkn2030.outbound.protection.outlook.com [40.92.99.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJW6J14ycz4pps for ; Wed, 16 Mar 2022 13:17:44 +0000 (UTC) (envelope-from DanieltheDeer@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nP8tsCcQ9FwsE/TQasHrXA5hJ1LMLhLtvEzaAyIpwQ99AEHQk5UumTQOxIAeNpeHUIxASULK9LHIHZV0qg4SazgganIWkxA/ghbEPEIld6eN0FOnOPHoxCdABeQFOE3kkI0Lf84ZtS8Fi/EfX1rmSy6+cdhrjeK5pFkS+wcf6eyie9DUzRbkV2tskjEUznohEgxy4GutCYyP7b4tGTJ5P1Ld6Bu9jiE8BtANOgVXh8DakLxBs88ZU1+8zx/310ioV3UzwhUA0KGxt7zwbYF+mXqbZ+NF5n94jd60v7qKD7JflFVVOD26WhGtJ4vNupG1XwQZiBqW0flCv5a/bvK4qQ== 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=l+e4omCVeGjhpZT5SwMbdmUroExIcyhANHpIDMuylnA=; b=mk0ppfeNWREpce6Sr9pnL1V1fLfTQCL1r2eYq8Ih1pa15j/l2KH3asREZOMKc0z0tKqZ2UGxKW2VYAuHAiS3fQSed5VeksFxIq3VE/6czklFP5vqa+5GEEFaUoWeNXES0TLIuVb7kE6JUSflKqOnEYTLIBdGvZ+t8guTsAQuqU5qPyHwgY68zCudfzzfPOtgJuWnIR+tB59pa2QwkdmZDpfgiiCMOABSDy1kyfyq+SnwCtxCkIVgRA5tfmpBKzY2ak2U8wMc+nwdjzonIOcO4Vt8cUqWR8GkWakFg5JxeG+dt2Hkby+CU0Lgg1whGYzZ4zlDViK0SFwW2cXZQQfs3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l+e4omCVeGjhpZT5SwMbdmUroExIcyhANHpIDMuylnA=; b=L4V7DqG1xwgpSKmGLcuWN+Ha065Stplgfv+bpV5p2cYS85d2R+KGwHDh2FfQbfT8bB48vYs2BGAW61gda6jKNiUlfWUYC1882RQ1SArd2+t6F55PEU7OR0VTo0wKnhuwFiyONfQUst2yPZjNrHR0uFJgUSZ5KYuxonmOTXN5T5tIZfMG+p9guy5PHAmYQheUdmYKswgsCQN93rX2YxQOPrmoV4zJLgMstUZxEWHCOIRk5HQJYxzNb4xEG6OqK3qdp8BtH9q9JDAZ6jB0blPZEvgzSqIKUlKpupdke1pM3a/5tRSTLCv0Y9eVfCFi6bNBvsewkKChWWpeV6IRw3ER3A== Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:11a::9) by OSZP286MB0694.JPNP286.PROD.OUTLOOK.COM (2603:1096:604:ea::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.25; Wed, 16 Mar 2022 13:17:35 +0000 Received: from TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b]) by TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM ([fe80::f4c3:40fa:279f:f16b%7]) with mapi id 15.20.5081.015; Wed, 16 Mar 2022 13:17:35 +0000 From: Daniel Cervus To: "freebsd-hackers@freebsd.org" Subject: AR9462 still not working properly Thread-Topic: AR9462 still not working properly Thread-Index: AQHYOTgz7cK22Gk4sES5SVyJ1awRCQ== Date: Wed, 16 Mar 2022 13:17:35 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [mlK//mCdhZK7qIex2iQOL8MeXjWRVV3Hkjpjar9Oemy40FyltFTtBsndiIu1ORPI] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa869e0f-158c-4ada-783d-08da074f563a x-ms-traffictypediagnostic: OSZP286MB0694:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Drr4PcT7YD5cfOOOKUGlYAse0qpngfiJ6ndJjfEYIvW1V9UZhiWn4u66UYn7iEJZUIWOPXzjrU4BNBBLeKC58O2WhpRauuNL7y/nhJr3VohJl6FN+xTbtnnwafEy34wS9s0iu9oCods2RFvwJLa1GhuS0f1We4LFwMErSsYaqvjZJlCnppHKSsqBuV0YnsBQhBVr1epOcvmsYPhN7SS6Hl6LiK0PFv8615bH1Kvyf6E7uIJd2TZqqnIKdCejFdRzGOD7BBJgUw4XFDMCvvqXpJInHzknwUeBZmy3xPBjeuHcF+FZPpFqw9B1tkti9s+SUVq4R6kiaT8IQ6xY1PMrFLknDfIUzGJJ0Cy1PW6L/rtWuiDSI8Gx8L3SWn9WEkk2EKVqxvDmwZ8CBh9B0Y4NvNIs7FjbHEpURE6fcROo9EO46PGE7DG8fsy6tBWtbuuPdKA7D2yRBj1cNnwA+Cu1gRUJtwLl4A7Vo86cZ90DIIPUORbha158B/4nfd2WKv0GTgOZovsilnxmR9qNir2Xv+UkmqJlaXUM0JeUzzwGd3/MqtQGOcHlSivOh87eTOFejlyB/Kdm06EbEU8xJZoe3Q== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bkozK3BjZHRBMEcxanR6d2ZGcnE2cnFzelRLdTZVMEQxRmdHdDdkNHVsd3Nz?= =?utf-8?B?NGR1NlY5d1lmM0ZsNWtMM1hFMlI0WkFOcWZnV2J2c3V2anJ4SkkwbjlDWjRI?= =?utf-8?B?WGVXaU8zbTRxeUFOalVIS0wzeFdXU2JKMFVjU1FtZCtta1VnaGtvSk9CN2VW?= =?utf-8?B?WkVBeDRsZy9rOUdyQ0V1V3J2TUwxS3YrVWN6ZVdHQy9NUUFYdXhvUnVWaTEw?= =?utf-8?B?YzJOQnBRdEZzZ0h3bXpuT0plVUVCVEFpOExzUjNoNlB5cnJqUTdNdGFEaTZl?= =?utf-8?B?aE5kN01Xc3kxWGEzdmVneSswV1lWaVZmME15L2FMdUk0cGp2OG12V0tWdmw1?= =?utf-8?B?czdDTTVheVlvSk5RbGVBbmU1dS90RkNIZTk5RWI4c0lBVjRLWjR2N21XanpF?= =?utf-8?B?TTFHcDFSNXBKNS9yYVBJcmo5N0xlWGluQS9LOXFDZHZzc0xBL3loNU5nVGk4?= =?utf-8?B?MWFaNXNId0VyTDM5WUhYZFBNVFlpeGVTZ3AzbURkL1RXMXFqNUE2RzNWZUU1?= =?utf-8?B?Mmw5MzRFcHAxcEVNY20yM3J3REVRSWt0ZDROckFNb2liOXF0bnEzd2piMmVF?= =?utf-8?B?SXczSnYrQytacDBqeFlZNzgvelBhVEE4SHJ2NTkwQ05sbXFlS2hiSDFlL1Zo?= =?utf-8?B?WmhYSmdCbHpjTjEyS2orN0k4N3VVMmU0NklRa1ZoWEJTdEl5QWJWOTZadlZj?= =?utf-8?B?Sk43SjhId3d6Q0JkbFNSd0Y5R044YlhoM2YrTzZDaVA1VUl0dXE3R3pmMVcz?= =?utf-8?B?RG5kU1R2dEZYdHdNUlE2Vi9rS3J0Y3pQcld2cjVoWk9GK2lMSG8wcm9KQ3ht?= =?utf-8?B?ZjAzb1RFZWRyUlZtVW5xL25Rd0pndXdMUC93aEdyaWdZbHg3WlllRjhmV2Vk?= =?utf-8?B?bUNGTDdvMk5CR1UvNmRlTFV4OXN0S0NMOWZzRmVsa1huY3RSdmo3ZmZSNnhL?= =?utf-8?B?MDc4RG1xMXhmMmxjMmgwa3V5cDZURzJOamRYeWV3d3diS3RJOTJ1R1ExY1pO?= =?utf-8?B?T0Z6SlNUaWszYjFWdHhzb3lvVzlmQm1RWFpUbG9HNWFLS0xNYUNyRVZYVlJJ?= =?utf-8?B?bENmdVhicThhdTVnUEhRN1NqdEN1cHlQZTVydFI2WUkvYnhkUjJ5Rm5XY0ow?= =?utf-8?B?WHR6QmIrdDUyTEJDd1NQWmRxTFlEdVN5RFB0QkxhZWdaWWxKNzhmU0xKeTJB?= =?utf-8?B?aVg2Qm9vUmNWMGgxbS82QjBCN0JkZzJTSEJ5dEVOcEhQQkEvYWEwVmxKRElz?= =?utf-8?B?TFBSUGl0VzlkL2RpQTVXSWtxTzBpV0dDcFk2Si9zVTVHbGcxd3RXVnl3VGla?= =?utf-8?B?OFp4b24zdG9kYm5vMzFOMUZ2L2VJNmduUUZCSlBvWGhEMzdEei9IbVFFdW5O?= =?utf-8?B?N3VWb1BuWE5mdlFkNE5MbnlUMXZ0M3puRFVsS1JGMlRYYlhaU296WEhqRkc4?= =?utf-8?B?d2k2ck1Bc2pZQmtkNlRHdzBBQ2haaHdiU2tLRHZpRWNFSTYzWnNlZktHODFD?= =?utf-8?B?YlNXdk81eTRxM09UckNmMUVQMVJLZjVCTXlFRllvWmpTbk1kdm5wWERUL05T?= =?utf-8?B?aC9TM3JqVzZ1YmQ0M3JaVHhZZmZkUFlKZWlzcEFaVDF4NWxDaG9FVzhJblhs?= =?utf-8?Q?0SWxX7/hXeJRUhAvtsgVKzsPB2Mwzmg4JvCVUB/1bzSE=3D?= Content-Type: multipart/alternative; boundary="_000_TYYP286MB1546C50BAD715FAAC7E8C578B8119TYYP286MB1546JPNP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYYP286MB1546.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: fa869e0f-158c-4ada-783d-08da074f563a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 13:17:35.6360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSZP286MB0694 X-Rspamd-Queue-Id: 4KJW6J14ycz4pps X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=outlook.com header.s=selector1 header.b=L4V7DqG1; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=outlook.com; spf=pass (mx1.freebsd.org: domain of DanieltheDeer@outlook.com designates 40.92.99.30 as permitted sender) smtp.mailfrom=DanieltheDeer@outlook.com X-Spamd-Result: default: False [-4.23 / 15.00]; FREEMAIL_FROM(0.00)[outlook.com]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[outlook.com:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[outlook.com,none]; NEURAL_HAM_SHORT(-0.91)[-0.910]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; ASN(0.00)[asn:8075, ipnet:40.80.0.0/12, country:US]; FREEMAIL_ENVFROM(0.00)[outlook.com]; DWL_DNSWL_NONE(0.00)[outlook.com:dkim]; NEURAL_HAM_MEDIUM(-0.46)[-0.459]; R_DKIM_ALLOW(-0.20)[outlook.com:s=selector1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.960]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[40.92.99.30:from]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.92.99.30:from] X-ThisMailContainsUnwantedMimeParts: N --_000_TYYP286MB1546C50BAD715FAAC7E8C578B8119TYYP286MB1546JPNP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 77u/DQpIZWxsbywgZXZlcnlvbmUuIEkgaGF2ZSBiZWVuIHVzaW5nIERlbGwgMTkwMSAoQVI5NDYy KSB3aXJlbGVzcyBjYXJkIHNpbmNlIHJlbGVhc2UgMTIuMiwgYnV0IG1pbm9yIHByb2JsZW1zIGtl ZXAgb2NjdXJpbmcuIEZvciBleGFtcGxlLCBpdCBjYW5ub3QgYmUgcmVjb2duaXplZCBpbiBic2Rj b25maWcsIHdoZW4gbm90IGNvbm5lY3RlZCB0byBuZXR3b3JrcywgZXJyb3IgbWVzc2FnZSDigJxG YWlsZWQgdG8gYWRkIG9wZXJhdGluZyBjbGFzcyBJReKAnSByZXBlYXRlcy4gSSByZW1lbWJlcmVk IHNvbWVvbmUgaGFzIHRvbGQgbWUgdGhhdCBoZSB3b3VsZCBkZWFsIHdpdGggdGhhdC4NCk5vdywg SSBoYXZlIGRvbmUgYSBicmFuZC1uZXcgaW5zdGFsbGF0aW9uIG9mIDEyLjMuIEJ1dCBic2RpbnN0 YWxsIHN0aWxsIGhhZCBkaWZmY3VsdHkgaW4gc2Nhbm5pbmcgV2ktRmlzLCBhbmQgYWZ0ZXIgSSBo YWQgdHJpZWQgYSBmZXcgdGltZXMsIG5vIFdpLUZpIGNvdWxkIGJlIGZvdW5kIGF0IGFsbC4gSG93 IHRvIGRlYWwgd2l0aCB0aGlzPyBJIGhhdmUgcHV0IHVwIGEgUFIgYWJvdXQgdGhhdC4gSeKAmW0g c29ycnkgZm9yIHRoYXQgSSBtYXkgaGF2ZSBkZXNjcmliZWQgdGhlIHByb2JsZW0gdW5jbGVhcmx5 IHRoZXJlLiBBbmQgaXMgdGhlcmUgYW55IGluZm9ybWF0aW9uIEkgbmVlZCB0byBwcm92aWRlPw0K DQpUaGUgUFIgaXMgQnVnIDI1NjI1NS4NCg== --_000_TYYP286MB1546C50BAD715FAAC7E8C578B8119TYYP286MB1546JPNP_ Content-Type: text/html; charset="utf-8" Content-ID: <9756A143E0832543AE33288343453A6A@sct-15-20-4755-11-msonline-outlook-05f45.templateTenant> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPG1ldGEgbmFtZT0iR2VuZXJhdG9y IiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQogPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBh bm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpT aW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGNtOw0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dy YXBoOw0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6RGVuZ1hpYW47fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KLyogUGFnZSBEZWZpbml0 aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbywgZXZlcnlv bmUuIEkgaGF2ZSBiZWVuIHVzaW5nIERlbGwgMTkwMSAoQVI5NDYyKSB3aXJlbGVzcyBjYXJkIHNp bmNlIHJlbGVhc2UgMTIuMiwgYnV0IG1pbm9yIHByb2JsZW1zIGtlZXAgb2NjdXJpbmcuIEZvciBl eGFtcGxlLCBpdCBjYW5ub3QgYmUgcmVjb2duaXplZCBpbiBic2Rjb25maWcsIHdoZW4gbm90IGNv bm5lY3RlZCB0byBuZXR3b3JrcywgZXJyb3IgbWVzc2FnZQ0KIOKAnEZhaWxlZCB0byBhZGQgb3Bl cmF0aW5nIGNsYXNzIElF4oCdIHJlcGVhdGVzLiBJIHJlbWVtYmVyZWQgc29tZW9uZSBoYXMgdG9s ZCBtZSB0aGF0IGhlIHdvdWxkIGRlYWwgd2l0aCB0aGF0Ljwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3csIEkgaGF2ZSBkb25lIGEgYnJhbmQt bmV3IGluc3RhbGxhdGlvbiBvZiAxMi4zLiBCdXQgYnNkaW5zdGFsbCBzdGlsbCBoYWQgZGlmZmN1 bHR5IGluIHNjYW5uaW5nIFdpLUZpcywgYW5kIGFmdGVyIEkgaGFkIHRyaWVkIGEgZmV3IHRpbWVz LCBubyBXaS1GaSBjb3VsZCBiZQ0KIGZvdW5kIGF0IGFsbC4gSG93IHRvIGRlYWwgd2l0aCB0aGlz PyBJIGhhdmUgcHV0IHVwIGEgUFIgYWJvdXQgdGhhdC4gSeKAmW0gc29ycnkgZm9yIHRoYXQgSSBt YXkgaGF2ZSBkZXNjcmliZWQgdGhlIHByb2JsZW0gdW5jbGVhcmx5IHRoZXJlLiBBbmQgaXMgdGhl cmUgYW55IGluZm9ybWF0aW9uIEkgbmVlZCB0byBwcm92aWRlPzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFBSIGlzDQo8dT5CdWcg MjU2MjU1LjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_TYYP286MB1546C50BAD715FAAC7E8C578B8119TYYP286MB1546JPNP_-- From nobody Wed Mar 16 13:43:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7E2D81A2BE99 for ; Wed, 16 Mar 2022 13:43:12 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KJWgg3PTlz3Bsf for ; Wed, 16 Mar 2022 13:43:11 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qt1-x82e.google.com with SMTP id 10so1722911qtz.11 for ; Wed, 16 Mar 2022 06:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=iuqmki6E6V+RSgfK6eDv+rpDm18N0BTldgmr46ln6EA=; b=LgJZlTUMf8Hwjj4gQcIu9Zajqv4QaP4bE19pT0yN93BkGq1U0mEztzbgiiS2odW9dH mG6+8hj7+4f4p+n/bxRzsXiJd03tVooPrqWlS4jWMIs/6QgE3nZ2PjRRSHXFQ+v//iBn DlksFuMWpbBinkW2hSsv9xM/2GW1vusnoIiMJ+Yq5MpfkPVdWzOIlz2srHTXxRMuK7cz 3Jm5a1frS5QI8i0R5tDa4ZDtOvWpcsvR+pMjPGypIAMqcEX4CUe4BXtkA/8pxILA6AeI m9MaVvr3eTe09AX5FctRp+VNs559BvHlKldJQWPFbc6juqzwsdohuXQWDHo52UsvnXt0 hHrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=iuqmki6E6V+RSgfK6eDv+rpDm18N0BTldgmr46ln6EA=; b=UhQD7g7RktxbX+PO2ZXfiksWlfBkHc0oj+1CqU5XHLv4bJ9NCldWPDEuUDh3k7dn9x MB9r1zxqqQyud497ATmPxgrBzggtT7wznqA//LQcajoz2vfXJQL3Tg7VOTJqundjJ4lJ otEO4hJsHPYODGETTp7RlICWPwxkkB+/iRGGAc6j/VOu5reYOOir6Wr7IxvDDUXq4/UH W1Mbssdo7mLa1m6zOTyvaIgraSTR166mYw9EtXpWUjQMalY1IOvNgFgnOAmKGkcNUyJk aB1P7L1BxNQmzROidFJCIIjAyyQqPgxsy4Sl6BnMygQsw+9nvlGrTFOiAaiZ9/ontVi/ j66g== X-Gm-Message-State: AOAM530yxKNax9NP/qPuZWpndwD3NPgJXJkFHmI/kdqUsAehfSbMAN2Y V8eAe9DrD5OS6P21VpzweYhn0vXyOfQ= X-Google-Smtp-Source: ABdhPJxpaWl0WDj7W/75NuJQ3hgyY9GJoYFV/mUJ4/eWm+VmNrZmDerAgkc4C9HcB9rNRp9ogZg0Pw== X-Received: by 2002:a05:622a:45:b0:2e1:a40c:51fe with SMTP id y5-20020a05622a004500b002e1a40c51femr36607qtw.131.1647438190811; Wed, 16 Mar 2022 06:43:10 -0700 (PDT) Received: from ?IPV6:2603:6000:a401:3a00:223:24ff:fe37:c4d7? (2603-6000-a401-3a00-0223-24ff-fe37-c4d7.res6.spectrum.com. [2603:6000:a401:3a00:223:24ff:fe37:c4d7]) by smtp.gmail.com with ESMTPSA id s5-20020a37a905000000b0067d35f2fdb1sm904397qke.37.2022.03.16.06.43.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Mar 2022 06:43:10 -0700 (PDT) Message-ID: Date: Wed, 16 Mar 2022 08:43:09 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: AR9462 still not working properly Content-Language: en-US To: Daniel Cervus Cc: "freebsd-hackers@freebsd.org" References: From: Jason Bacon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4KJWgg3PTlz3Bsf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LgJZlTUM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::82e as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-0.14 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[outlook.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.76)[0.760]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.995]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82e:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N DQoiRnVsbHkgc3VwcG9ydGVkIiBkb2Vzbid0IG1lYW4gZGV2ZWxvcG1lbnQgaGFzIHN0b3Bw ZWQuICBUaGVyZSBhcmUgDQpvbmdvaW5nIGltcHJvdmVtZW50cyBpbiBtb3N0IGRyaXZlcnMg dGhhdCBtYXkgbGVhZCB0byBiZXR0ZXIgc3RhYmlsaXR5IA0KYW5kIHBlcmZvcm1hbmNlLg0K DQpPbiAzLzE2LzIyIDA4OjA2LCBEYW5pZWwgQ2VydnVzIHdyb3RlOg0KPiBJIGd1ZXNzIGl0 4oCZcyBzdGlsbCB0aGUgc2FtZSwgYmVjYXVzZSBBUjk0NjIgaXMgZnVsbHkgc3VwcG9ydGVk IGluIDEyLCBhbmQgeWVzIGl04oCZcyBhIDEwLXllYXIgb2xkIGNvbXB1dGVyLiBJIGRvbuKA mXQgaGF2ZSB0aGUgaW1tZWRpYXRlIG5lZWQgdG8gdXBncmFkZS4NCj4gDQo+IFdoYXTigJlz IG1vcmUsIEkgaGF2ZSBhbHJlYWR5IHJlcGxhY2VkIHRoZSBOSUMgYmVjYXVzZSBJIGhhZCBj b25maXJtZWQgQVI5NDYyIGlzIGZ1bGx5IHN1cHBvcnRlZCENCj4gDQo+PiBJcyB0aGVyZSBh IHByb2JsZW0gd2l0aCAxMy54IChvciBldmVuIDE0KSBvbiB0aGlzIG1hY2hpbmU/ICBXaGls ZSAxMi54IGlzIGZ1bGx5IHN1cHBvcnRlZCBhbmQgd2lsbCByZWNlaXZlIGFsbCBzZWN1cml0 eSBmaXhlcywgaXQgd29uJ3Qgc2VlIG11Y2ggaW4gdGhlIHdheSBvZiBuZXcgZHJpdmVyIGRl dmVsb3BtZW50Lg0KPj4NCj4+IElmIHlvdSBuZWVkIGEgc3RvcC1nYXAgc29sdXRpb24sIEkn dmUgaGFkIGdvb2QgZXhwZXJpZW5jZXMgd2l0aCBFZGltYXggVVNCIFdpRmkgZG9uZ2xlcywg ZS5nLjogaHR0cHM6Ly93d3cuZWRpbWF4LmNvbS9lZGltYXgvbWVyY2hhbmRpc2UvbWVyY2hh bmRpc2VfZGV0YWlsL2RhdGEvZWRpbWF4L2luL3dpcmVsZXNzX2FkYXB0ZXJzX24xNTAvZXct NzgxMXVuLy4gIEkgdXNlZCB0aGVtIG9uIGEgTGVub3ZvIHVudGlsIHRoZSBuYXRpdmUgZHJp dmVyIHdhcyBkZXZlbG9wZWQsIGFuZCBvbiBNYWNzIHdpdGggQnJvYWRjb21tIFdpRmkgdGhh dCdzIGEgcGFpbiBpZiBpdCB3b3JrcyBhdCBhbGwuDQo+Pg0KPj4gLS0gDQo+PiBMaWZlIGlz IGEgZ2FtZS4gIFBsYXkgaGFyZCwgcGxheSBmYWlyLCBhbmQgaGF2ZSBmdW4uLi4NCg0KDQot LSANCkxpZmUgaXMgYSBnYW1lLiAgUGxheSBoYXJkLCBwbGF5IGZhaXIsIGFuZCBoYXZlIGZ1 bi4uLg0K From nobody Fri Mar 18 09:52:47 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B33DD1A1C2BA for ; Fri, 18 Mar 2022 09:53:08 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from mailin.dlr.de (mailin.dlr.de [194.94.201.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailin.dlr.de", Issuer "DFN-Verein Global Issuing CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKfTH57H3z3l2X for ; Fri, 18 Mar 2022 09:53:07 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) X-IPAS-Result: =?us-ascii?q?A2HaBAAUVTRi/xiKuApagQmGbLQ3CwEBAQEBAQEBAQgBQ?= =?us-ascii?q?QQBAYk3JjgTAQIEAQEBAQMCAwEBAQEBAQMBAQYBAQEBAQEGBAEBAoEYhS9Gg?= =?us-ascii?q?jUihDVRAT5CJgEEG7NEgTOBAYRrhRCBPJEZig+FMgSYMnEdgUjBUweCEoE/n?= =?us-ascii?q?1wwFZZLkXKWW6ZZAgQCBAUCFoF4UYEucYM5UBcCD5xwgS0CBgsBAQMJjjyBE?= =?us-ascii?q?gEB?= IronPort-PHdr: A9a23:MWOIdR+xkTJ2F/9uWRa8ngc9DxPPW53KNwIYoqAql6hJOvz6uci4Z gqGvqsm1AGBdL6YwsoMs/DRvaHkVD5Iyre6m1dGTqZxUQQYg94dhQ0qDZ3NI0T6KPn3c35yR 5waBxdq8H6hLEdaBtv1aUHMrX2u9z4SHQj0ORZoKujvFYPekdq72/qv95DdYghEiyaxbLJvJ xiqsAvdsdUbj5F/Iagr0BvJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4U KdXDC86PGAv5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4 KdxUBLmiDkJOSMl8G/ZicJwjb5Urh2uqBFk347UeYOVOOZicq/BY98XQ3dKUMZLVyxGB4Oxd 4wCAegbMuZCs4n9okYOrQekCQSxHuPg0DlIiWLq3aAhzushFRvG0BY9EN0QqXnZqsj+O6gOX +6v1qbI0SnDYO1M2Tf78IXFbx4srP+MUL9ubMbc1UciGQPFg1ietYHoPi2Z2/oTvmWH8uZsS P6ihm4ppQ9/oDWhydsghpfXio8UyV3K+iV3zYAoLtO7UE52ecOoHIdKuy2HNIZ7TdkuT3xmt Ss50LEKp5G2cDAXxJkl2RLTceKLf5WS7h7+VuucIC10iG9jdbminRi961Kgxff5VsSs1VZKq TdKncfUu3AW0hzT9tCHSvxg/ke9wTqP1x7c6uVDIU0sm6TVLZAvzLEwmJQTtkrNHSj4ll/og KKZeUsr+/al5/7mYrXgup+cLZV7hhvjPaQqgMyzG/k3PRYWU2ia/+SzyqHj8FXkTLlWlPE6j 6rUvZ/AKcgGqKO0ABVZ3pgs5hqnCjepytUYnX0JLFJffxKHipDkNVPUL/DiEfe/hkmskCtxy /3bJL3uGJPNIWXfkLr6YLl971RcxBAuwt9B/55UDKoOL+rpWkDtrNzYEgM5Mwuszur6ENl9z J8RWXqTAq+FN6PfqV+I6fgzLOmPeoAVoi39JuMr5/70k3A2h0QSfbK00pcNb3C4BPtmcA2lZ i+4gt4KEmoQpSIwVuHngkaOFzlJaCDhcbg742RvKIu8EYLeWsaHmrWH0DuTEplMIGxLXAPfW Uz0fpmJDq9fIBmZJdVsx2RsaA== IronPort-Data: A9a23:8FsXKa0/au8ovcEl0vbD5UNzkn2cJEfYwER7XKvMYLTBsI5bpzJVn TAbWjyGbvneN2T8Ldonao7l/BwEvJSEmtA1SVRq3Hw8FHgiRegppDi6wuUcGwvIc6UvmWo+t 512huHodZxyFjmFzvuUGuCJQUNUjMlkfZKhTr+cUsxNbVU8En150kszw7dRbrNA2LBVPSvc4 bsenOWCYDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyV94KYkGE2EByCQrr+4vwKNb 72rILmRpgs19vq2Yz+vuu6TnkYiGtY+MeUS45b/tmfLbhVq/0QPPqgH2PU0eRpOtDqDuM1Kk 8Rr9sWPCjgqL/Ddl7FIO/VYO3kW0axu1JvrDFaRlO229xeaXkvHhfRoEFs/e4Ec4KB7DAmi9 9RBcHZUPkzF3rnmhujnIgVvrp1LwM3DHIoFpnR90XfzF/8gTYzrT6HQo9NVtNs1rp4QRKiBP JRDAdZpRBCDOEBwEXQHMYAzxdr13UbDcmB/h3vA8MLb5ECWlmSdyoPFMNPeedGQXu1bhEuVr HnKuWPjDXkn2Me3xT6J/3yig+7KhXmnVZIZUry+6uRjxlGX3CofBXX6SGeGnBVwsWbmM/o3F qDe0nNGQXQanKBzcuTAYg== IronPort-HdrOrdr: A9a23:PBaNqqO93ErTOcBcTumjsMiBIKoaSvp037By7TEVdfUnSL39qy nIpoVh6faUskdoZJhOo7C90CfrewK+yXcY2+Qs1NSZLXPbUQmTXeNfBOLZqlWKcREWndQz6U 4USclD4arLY2SS4/yX3ODyKadG/DDOytHPuQ7x9QYVcT1X X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,191,1643670000"; d="scan'208";a="66167362" From: To: Subject: Odd behaviour after disk conversion (partition disappeared) Thread-Topic: Odd behaviour after disk conversion (partition disappeared) Thread-Index: Adg6rZ8uURv9QK1cRxSgY6lXPo3Q9g== Date: Fri, 18 Mar 2022 09:52:47 +0000 Deferred-Delivery: Fri, 18 Mar 2022 09:52:38 +0000 Message-ID: <7e5669b2afe842b3bbc16737d8a3066c@dlr.de> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4KKfTH57H3z3l2X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of Hartmut.Brandt@dlr.de designates 194.94.201.12 as permitted sender) smtp.mailfrom=Hartmut.Brandt@dlr.de X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dlr.de]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_EXCELLENT(0.00)[194.94.201.12:from]; RCVD_IN_DNSWL_MED(-0.20)[194.94.201.12:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:194.94.0.0/15, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I have a virtual machine on Hyper-V running 12.1-RELEASE-p2. Root is mounted on /dev/da0s1a. Now we have converted the disk image from .vhdx to .vmdk to use it on a VMware workstation. Now the BSD partitions disappeared, but the thing still boots, but from /dev/ada0s1. Of course I cannot see the swap partition anymore. gpart show da0 on the old image shows: =3D> 63 62914497 da0 MBR (30G) 63 1 - free - (512B) 64 62914495 1 freebsd [active] (30G) 62914559 1 - free - (512B) and gpart show da0s1: =3D> 0 62914495 da0s1 BSD (30G) 0 58720256 1 freebsd-ufs (28G) 58720256 3145728 2 freebsd-swap (1.5G) 61865984 1048511 - free - (512M) on the new image gpart show ada0: =3D> 63 62914497 da0 MBR (30G) 63 1 - free - (512B) 64 62914495 1 freebsd [active] (30G) 62914559 1 - free - (512B) and gpart show ada0s1: gpart: No such geom: ada0s1. What happened? The conversion process is supposed to make a 1:1 copy of the disk image. Cheers, harti From eugen@grosbein.net Fri Mar 18 10:32:24 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D54E1A269AB for ; Fri, 18 Mar 2022 10:33:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKgMV3CPpz3sS6 for ; Fri, 18 Mar 2022 10:33:10 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 22IAWvI8070697 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Mar 2022 10:32:57 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Hartmut.Brandt@dlr.de Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 22IAWV1h060251 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 18 Mar 2022 17:32:56 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Odd behaviour after disk conversion (partition disappeared) To: Hartmut.Brandt@dlr.de, hackers@freebsd.org References: <7e5669b2afe842b3bbc16737d8a3066c@dlr.de> From: Eugene Grosbein Message-ID: Date: Fri, 18 Mar 2022 17:32:24 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <7e5669b2afe842b3bbc16737d8a3066c@dlr.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KKgMV3CPpz3sS6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.01 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.912]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 18.03.2022 16:52, Hartmut.Brandt@dlr.de wrote: > Hi, > > I have a virtual machine on Hyper-V running 12.1-RELEASE-p2. Root is > mounted on /dev/da0s1a. Now we have converted the disk image from .vhdx to > .vmdk to use it on a VMware workstation. Now the BSD partitions > disappeared, but the thing still boots, but from /dev/ada0s1. Of course I > cannot see the swap partition anymore. > > gpart show da0 on the old image shows: > => 63 62914497 da0 MBR (30G) > 63 1 - free - (512B) > 64 62914495 1 freebsd [active] (30G) > 62914559 1 - free - (512B) > > and gpart show da0s1: > => 0 62914495 da0s1 BSD (30G) > 0 58720256 1 freebsd-ufs (28G) > 58720256 3145728 2 freebsd-swap (1.5G) > 61865984 1048511 - free - (512M) > > on the new image gpart show ada0: > => 63 62914497 da0 MBR (30G) > 63 1 - free - (512B) > 64 62914495 1 freebsd [active] (30G) > 62914559 1 - free - (512B) > > and gpart show ada0s1: > gpart: No such geom: ada0s1. > > What happened? The conversion process is supposed to make a 1:1 copy of > the disk image. I guess it was not about conversion but something else changed, too. But the root cause is your da0s1 and da0s1a having same offset from the beginning of da0 and this is bad. One should not create 'a' partition at zero offset inside BSD label but either create 'b' partition at the beginning of the slice and 'a' after 'b', or use non-zero offset for 'a'. Or else you can hit this problem with GEOM tasting order due to ambiguity. From nobody Fri Mar 18 10:52:18 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3A2181A2B153 for ; Fri, 18 Mar 2022 10:52:28 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKgnl15TPz3wNR for ; Fri, 18 Mar 2022 10:52:27 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id m30so1363646wrb.1 for ; Fri, 18 Mar 2022 03:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=YR0nHMERUg2sH4D2mFHZ0PX6cz25T3GA2AP9cCCRS+A=; b=mCxyazhZy6MeBS0EvdIPPJKI4XLAE77jEyzkL+snIEGG490s19GJ0OtwE4pACMPMIC s1a8+54BE4A3OL9MA12XbA4IhTsV6C29XlNvupJOUspocFPMqCyalXvixdqVyMyCtfJp cDs04pjJ5ObItpp+xcXvq2k5PLiZoSFcGvY0iQ5quM/T9liQzjIvpAf0s06yfYrnGd+c dwi2i3YxPzCyNvN0pjGzbrq/jcQylxz9qrQbzfegCqzSQAPzC/hXJ+TEyiXaezo9DaFF h22rJ25mgVruOZRvkKvDrBG6AUNy93MKipAj4GtHtcoxdOUcX/ki95jITn1RlcNI1fvx t7+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=YR0nHMERUg2sH4D2mFHZ0PX6cz25T3GA2AP9cCCRS+A=; b=7ju/mQ9flNcFMEIEWsEDFXBSGrzC3Xw02DjHETQn4lMsgiF411EdBf+4Ki6/LuBx7s q52+ZmI8d4MBanNtenu3KyNwZSEvUAvGIoo54ezvCknnZC/ddpTtu4Uc2RD7URnTT6jM m3/ZwQBZZ05bFnsSIj4/oezFDbilnMMlE3Cv4aI7YOmDcsyWn1vbKvumeSC/xYgZJQF7 hdi1TPUZxLSUvS9PfUrfbIAZ01VzEtiOdsCBiYADUTMlclvnQEEpjgcxYVV8XXAMnLJ6 v4V3S6hODM6NtDOVeWhO9XgS0TW6dDI20rke5x1JaBFhDMXEQSZN3VNFXLtaf2/nUYY7 VQaw== X-Gm-Message-State: AOAM533P03qxBRZTCsgwFcW59BAiUlZu0yXFz9RtkPvdWWC/zeDWN8UX pP414jalCyBn2Yz/BLhk+R0= X-Google-Smtp-Source: ABdhPJwend5ZqQpdGLF9pdEceBVkOc20sLzYiw3K4KIzTviU8+JFL4aJOOJG2DX64JGN4ApNRS2XkQ== X-Received: by 2002:adf:816e:0:b0:1e4:ad2b:cb24 with SMTP id 101-20020adf816e000000b001e4ad2bcb24mr7721301wrm.521.1647600746017; Fri, 18 Mar 2022 03:52:26 -0700 (PDT) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id m4-20020a7bcb84000000b00389efb7a5b4sm6227001wmi.17.2022.03.18.03.52.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Mar 2022 03:52:25 -0700 (PDT) Date: Fri, 18 Mar 2022 11:52:18 +0100 From: Gary Jennejohn To: Cc: Subject: Re: Odd behaviour after disk conversion (partition disappeared) Message-ID: <20220318115218.0938a421@ernst.home> In-Reply-To: <7e5669b2afe842b3bbc16737d8a3066c@dlr.de> References: <7e5669b2afe842b3bbc16737d8a3066c@dlr.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KKgnl15TPz3wNR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mCxyazhZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-3.03 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.97)[-0.971]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.06)[-0.056]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; MLMMJ_DEST(0.00)[hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Mar 2022 09:52:47 +0000 wrote: > Hi, > > I have a virtual machine on Hyper-V running 12.1-RELEASE-p2. Root is > mounted on /dev/da0s1a. Now we have converted the disk image from .vhdx to > .vmdk to use it on a VMware workstation. Now the BSD partitions > disappeared, but the thing still boots, but from /dev/ada0s1. Of course I > cannot see the swap partition anymore. > > gpart show da0 on the old image shows: > [...] > 63 1 - free - (512B) > 64 62914495 1 freebsd [active] (30G) > 62914559 1 - free - (512B) > > and gpart show da0s1: > [...] > 0 58720256 1 freebsd-ufs (28G) > 58720256 3145728 2 freebsd-swap (1.5G) > 61865984 1048511 - free - (512M) > > on the new image gpart show ada0: > [...] > 63 1 - free - (512B) > 64 62914495 1 freebsd [active] (30G) > 62914559 1 - free - (512B) > > and gpart show ada0s1: > gpart: No such geom: ada0s1. > > What happened? The conversion process is supposed to make a 1:1 copy of > the disk image. > This doesn't answer your question, but you could try running swapctl -lh to see how much swap the kernel sees and which partition is used. -- Gary Jennejohn From nobody Fri Mar 18 14:16:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B14641A1AAF5 for ; Fri, 18 Mar 2022 14:16:33 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKmKD0hXtz3P1f for ; Fri, 18 Mar 2022 14:16:31 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-31-137.area1b.commufa.jp [123.1.31.137]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 22IEGMwm054652 for ; Fri, 18 Mar 2022 23:16:23 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 18 Mar 2022 23:16:22 +0900 From: Tomoaki AOKI To: FreeBSD Hackers Subject: Providing base OpenSSL *.pc files needed Message-Id: <20220318231622.1f511123b97c76f2bbe1568a@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KKmKD0hXtz3P1f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.58 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.31.137:received] X-ThisMailContainsUnwantedMimeParts: N Can someone look into Bug 257659 [1]? I've encountered Bug 262569 [2]. ports git d4c9792fda7f introduced LIB_DEPENDS with security/openssl, maybe because security/tpm2-tss 3.2.0 hesitates to build without *.pc of OpenSSL. This causes ports depending on base OpenSSL to fail, even on fetch. Putting partially modified *.pc files of security/openssl I've uploaded on Bug 257659 into /usr/libdata/pkgconfig, applying the patch I've uploaded on Bug 262569 and deinstalling security/openssl allowed me to build security/tpm2-tss, updating ports depending on base OpenSSL to succeed. */usr/ports/Mk/bsd.default-versions.mk defaults to base unless any ports one is already installed or manually specified via DEFAULT_VERSIONS. And /usr/ports/Mk/Uses/ssl.mk disallows coexistence of ports build against base OpenSSL and against ports security/openssl*. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262569 -- Tomoaki AOKI From nobody Fri Mar 18 19:58:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B1501A2B316 for ; Fri, 18 Mar 2022 19:58:31 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KKvvp6Xjwz3QZJ; Fri, 18 Mar 2022 19:58:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647633510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sDZThKiZrdHy3NPtko2XGc8LNKM5fTaYEDCC/QMXgng=; b=UVhRmSH4S8rmb2om/Y9wXwrVHJQ9BVOhlgFovG/lX8q/KEPjWHhcHcnbWWhdZigMFR9RpR Z/cyNi+RhKyIIQzJg7D6vRYQ1QJoc5PeHgVeByP+FRFcL4ulGvf8VowKZzDhs0jOCJ+Woq jz6WOcW6P0WOKOqY4g4wilcYiDpTv/pW+BEStJOQmDOemKItE7ToKOAJd1s4bE607lN59u pdxL34sSIgRyboiQ9a1DynI9RGhGzZrq4YdeZifT8u5siE8ztW5DsI7LBqPWgLlAg4lJUY skN9bFet/SS0DAVKQxe2+/BuZAQ8cRSf+nrcFcg4O7YECyrYDFrmqc3fUXYsNA== Received: from freefall.freebsd.org (pool-100-8-53-238.nwrknj.fios.verizon.net [100.8.53.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id B4DB027DD1; Fri, 18 Mar 2022 19:58:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: <6c8e873e-fbe0-b857-1842-307c979a95e8@FreeBSD.org> Date: Fri, 18 Mar 2022 15:58:30 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Tomoaki AOKI , FreeBSD Hackers References: <20220318231622.1f511123b97c76f2bbe1568a@dec.sakura.ne.jp> From: Jung-uk Kim Organization: FreeBSD.org Subject: Re: Providing base OpenSSL *.pc files needed In-Reply-To: <20220318231622.1f511123b97c76f2bbe1568a@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647633510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sDZThKiZrdHy3NPtko2XGc8LNKM5fTaYEDCC/QMXgng=; b=r3g7B+8eOOBqUr9y+TJoz5JZR8bCODS4eobG39a9JvBWSKgs4T2nFtFG+9obIBvIfUacdt a2UUbR4U2gCv4GPuTM1yGZMely54Sqxi/cewoIEhKNUKeICyAPnbFClSQuwfI0LttWOPN8 dqOzsxrdCQLoslOMORHkNC6envoluTlx6W4cCgaqpEbdCRCjMjrp5usFd8+6eEejAM+gCx H9IdAeDKQY8yoSlenUGB66UtTVooG3HHbdrl3L3ILtQ7iJ1VLBcNs/YZqqP7AjlqZt7+2W UmDxw1bywVQGVtkgiB/Gm13DGwsb+RXcJj2OehM5lFPEfVGjAMBbK8e5VBp4yQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647633510; a=rsa-sha256; cv=none; b=Je27KMWePz6Q2RKRzvV8KJ7ZxE8KBZhWIZDQyPbK1CpC5+ziJMTEFu7YljuJRfRYP4VWfr DC2LIWkoFBxcF3/OGiec5Kb07bm1kICxdHJUtOIs9oEJFFRvpAFqOeeQPkMb1V+dQvLeEl 1HI6j5sNaJiyrbehNG7zCKp0llEPc1ntmrB05mkXWTVVOWAwn3TgI/WSkCqD/5U0jfFJgs sQLX77C2936UM/qs9j2OR5cZda1+0/qAmEOICENGxRTXeKVrLCPctvzKMmqIcoj7DRKIAC FFWAqA015T3BpMTGFd+hNZIMQYWwLSpdl2P5KN2irNy4ELBnC24akml1S7cckQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 22. 3. 18., Tomoaki AOKI wrote: > Can someone look into Bug 257659 [1]? > > I've encountered Bug 262569 [2]. > > ports git d4c9792fda7f introduced LIB_DEPENDS with > security/openssl, maybe because security/tpm2-tss > 3.2.0 hesitates to build without *.pc of OpenSSL. > > This causes ports depending on base OpenSSL to fail, > even on fetch. > > Putting partially modified *.pc files of security/openssl I've > uploaded on Bug 257659 into /usr/libdata/pkgconfig, applying > the patch I've uploaded on Bug 262569 and deinstalling > security/openssl allowed me to build security/tpm2-tss, updating > ports depending on base OpenSSL to succeed. > > */usr/ports/Mk/bsd.default-versions.mk defaults to base unless > any ports one is already installed or manually specified via > DEFAULT_VERSIONS. And /usr/ports/Mk/Uses/ssl.mk disallows > coexistence of ports build against base OpenSSL and against > ports security/openssl*. I personally don't think adding these files in the base is a good idea. However, it's portmgr's decision because it may break existing ports. Besides, portmgr owns ports/Mk/bsd.default-versions.mk and ports/Mk/Uses/ssl. > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659 > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262569 Note I fixed PR262569 today. https://cgit.freebsd.org/ports/commit/?id=aca6f9b18e874c73ac68990a2439ccec0be66ef0 Jung-uk Kim From nobody Sat Mar 19 03:17:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 982D61A2C06E for ; Sat, 19 Mar 2022 03:17:07 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KL5dt2R3qz4TjK; Sat, 19 Mar 2022 03:17:06 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-31-137.area1b.commufa.jp [123.1.31.137]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 22J3H3KN056871; Sat, 19 Mar 2022 12:17:04 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 19 Mar 2022 12:17:03 +0900 From: Tomoaki AOKI To: Jung-uk Kim Cc: FreeBSD Hackers Subject: Re: Providing base OpenSSL *.pc files needed Message-Id: <20220319121703.475bed3bf22e163f6d190aa5@dec.sakura.ne.jp> In-Reply-To: <6c8e873e-fbe0-b857-1842-307c979a95e8@FreeBSD.org> References: <20220318231622.1f511123b97c76f2bbe1568a@dec.sakura.ne.jp> <6c8e873e-fbe0-b857-1842-307c979a95e8@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KL5dt2R3qz4TjK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [0.41 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.986]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.977]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.31.137:received] X-ThisMailContainsUnwantedMimeParts: N On Fri, 18 Mar 2022 15:58:30 -0400 Jung-uk Kim wrote: > On 22. 3. 18., Tomoaki AOKI wrote: > > Can someone look into Bug 257659 [1]? > > > > I've encountered Bug 262569 [2]. > > > > ports git d4c9792fda7f introduced LIB_DEPENDS with > > security/openssl, maybe because security/tpm2-tss > > 3.2.0 hesitates to build without *.pc of OpenSSL. > > > > This causes ports depending on base OpenSSL to fail, > > even on fetch. > > > > Putting partially modified *.pc files of security/openssl I've > > uploaded on Bug 257659 into /usr/libdata/pkgconfig, applying > > the patch I've uploaded on Bug 262569 and deinstalling > > security/openssl allowed me to build security/tpm2-tss, updating > > ports depending on base OpenSSL to succeed. > > > > */usr/ports/Mk/bsd.default-versions.mk defaults to base unless > > any ports one is already installed or manually specified via > > DEFAULT_VERSIONS. And /usr/ports/Mk/Uses/ssl.mk disallows > > coexistence of ports build against base OpenSSL and against > > ports security/openssl*. > > I personally don't think adding these files in the base is a good idea. > However, it's portmgr's decision because it may break existing ports. > Besides, portmgr owns ports/Mk/bsd.default-versions.mk and > ports/Mk/Uses/ssl. Agreed that it should be a decision by portmgr, as I already commented on Bug 257659. > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659 > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262569 > > Note I fixed PR262569 today. > > https://cgit.freebsd.org/ports/commit/?id=aca6f9b18e874c73ac68990a2439ccec0be66ef0 > > Jung-uk Kim Thanks for the fix! Confirmed OK without installing 3 *.pc files. But as I commented on Bug 257659 and Bug 262569, if CONFIGURE_ENV= part of your fix is generic enough, it would be better set on Mk/Uses/ssl.mk to avoid this kind of disaster. -- Tomoaki AOKI From nobody Sun Mar 20 11:03:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AA83C1A27CB2 for ; Sun, 20 Mar 2022 11:03:51 +0000 (UTC) (envelope-from mandree@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 4KLvxz4QWqz3py7 for ; Sun, 20 Mar 2022 11:03:51 +0000 (UTC) (envelope-from mandree@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647774231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XJyTBgE9iJZwh5Kw2i0bzBTkKAAz6Mc2pZPk+rzqcbQ=; b=GqXBlW9AnjkjqZ/f/Fj+ns5IopuDfRVgDVFJwar4YbhuDckGdpKQjvGn/JHauVa9X3fgsZ 9kCV3zan/7IbAh95DTjfbXEc96N9wAhUEDwM2NF3XcDq9ZYu7Anco+vn9P0BSACHDMywr1 Dg5FpEnh5PaOocTbmmBADqW34VjTLm5O10Di3mYJihJ1+3Xo4+11hND2ozhpIUcPv0yA9L OT+X2DNeX1djzu8c5e6eHCTeisKHWYJfMMvOeSpGhG1qqd62Yd8mvZ2crubbBNOGe3M18v TURB2p/L8huQjKeit5t2U1jEMyXggN+QaOCw9B/jvf/W1Oi2O8oCM7L1Qc3T8g== Received: from mandree.no-ip.org (p200300d027377900de65dff1a874e1cc.dip0.t-ipconnect.de [IPv6:2003:d0:2737:7900:de65:dff1:a874:e1cc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mandree/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 5ADA0CE0F for ; Sun, 20 Mar 2022 11:03:51 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by ryzen.an3e.de (Postfix) with ESMTP id C191434BE9E for ; Sun, 20 Mar 2022 12:03:47 +0100 (CET) Message-ID: <45809de5-e9c3-3d37-fa93-6ca38f098906@FreeBSD.org> Date: Sun, 20 Mar 2022 12:03:47 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: Providing base OpenSSL *.pc files needed Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20220318231622.1f511123b97c76f2bbe1568a@dec.sakura.ne.jp> <6c8e873e-fbe0-b857-1842-307c979a95e8@FreeBSD.org> From: Matthias Andree In-Reply-To: <6c8e873e-fbe0-b857-1842-307c979a95e8@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1647774231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XJyTBgE9iJZwh5Kw2i0bzBTkKAAz6Mc2pZPk+rzqcbQ=; b=ORe4L/nm2VaxHP2btMGK98BY17d7nYToHmKM2G00SLvRi9rDHIycwo5kCx8FYa7ZY+7Mn4 QkedunN2q6UqWJK257xUM76bBC1m+9GoF2JQienycDC+KPEx2VhksvgMNcZ/osBX80aqIL kbCrZSiEvQVYDuVa9tqzRx5gQg1D7IRFg34XSNZIQ2rqrAYL0ROpxR8bIZVJ0W5e8ART+P pc/zEVU3bQsFPMbfqfMMhpdddsNbYIEXpRxfg2h/ScjNHwbYNxxKqXkatlPu649bKiuR6D 2gJ3zLcwDROn3PGaDE/Tc537QpbTJgQzZz5BjumJ/YTwTYmvuEh/zkcMqAUnqA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1647774231; a=rsa-sha256; cv=none; b=UKUvSnaUC8T+tT1ehD9z5lBKBqXtJPXghIDQCPrX5uzpYA5p58GDiLHtKNzeZVymvUTxSY orJW4pAFRKK/FfE/V6/tMwFeGC+TlLgWJfhm8bhKmmHf63cJl1YlNc+PtYo8xR4gKnbVJn PMBjMvDYp3tiyLXXfPujqBwDdJSm6r80IhM9yv6cUOXNPn/orSbLWdy/wECS7UlJxZ4hie Ibxcbr5s9J65P80GkoRyE2Tuyv3ZKOWfNHuMNVjh9Pevjd96kO4xEJxBCYOwkIT1/5+il2 q/5d642oxagseK2OePN/M6GS2Vl3j9jqxShaRIlKobTSxCtsNwrrgGDtTVebAg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Am 18.03.22 um 20:58 schrieb Jung-uk Kim: > On 22. 3. 18., Tomoaki AOKI wrote: >> Can someone look into Bug 257659 [1]? >> >> I've encountered Bug 262569 [2]. >> >> ports git d4c9792fda7f introduced LIB_DEPENDS with >> security/openssl, maybe because security/tpm2-tss >> 3.2.0 hesitates to build without *.pc of OpenSSL. >> >> This causes ports depending on base OpenSSL to fail, >> even on fetch. >> >> Putting partially modified *.pc files of security/openssl I've >> uploaded on Bug 257659 into /usr/libdata/pkgconfig, applying >> the patch I've uploaded on Bug 262569 and deinstalling >> security/openssl allowed me to build security/tpm2-tss, updating >> ports depending on base OpenSSL to succeed. >> >>   */usr/ports/Mk/bsd.default-versions.mk defaults to base unless >>    any ports one is already installed or manually specified via >>    DEFAULT_VERSIONS. And /usr/ports/Mk/Uses/ssl.mk disallows >>    coexistence of ports build against base OpenSSL and against >>    ports security/openssl*. > > I personally don't think adding these files in the base is a good idea. >  However, it's portmgr's decision because it may break existing ports. >  Besides, portmgr owns ports/Mk/bsd.default-versions.mk and > ports/Mk/Uses/ssl. > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659 > > [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262569 > > Note I fixed PR262569 today. > > https://cgit.freebsd.org/ports/commit/?id=aca6f9b18e874c73ac68990a2439ccec0be66ef0 > > > Jung-uk Kim > Hello, the thing is that anything that uses OpenSSL with meson will want pkg-config support and it is a porting obstacle. Maybe we can do an -exp run equivalent to see how much fallout adding .pc files triggers among ports. Regards, Matthias From nobody Mon Mar 21 03:49:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 092211A214BB for ; Mon, 21 Mar 2022 03:50:34 +0000 (UTC) (envelope-from the.latticeheart@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KMLHY0fGfz3R9w for ; Mon, 21 Mar 2022 03:50:33 +0000 (UTC) (envelope-from the.latticeheart@gmail.com) Received: by mail-pj1-x1036.google.com with SMTP id o3-20020a17090a3d4300b001c6bc749227so5908256pjf.1 for ; Sun, 20 Mar 2022 20:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=1MULVzLskgIkdVJbBoJN4YEbTCFMQ5a8n6bLbUXQoRA=; b=J4VAX/GKlg94TMg5Rjq8jJDEG1Gi17sKzbYv8Oc2NKYPyu98wYaA4q3UulTrgwK3xH KsiIOTdlW7toIAL+JuGo4jlqXHpSwkx8J4ZlAIzdVxeA+zR/RZo1kxXYdTvrVtu/6r4D jWEb+CGkzUVw/OUZCZ5hbJyww+Z8JzxRnTu0sKzFrTp4suCwRDcCWv9MRTFFRktXUh9F ftU3UP7BU4SPxNVA8NbEKLzC7VmX/JNWId0Q4KXQqewp+oxXnfZYKPJemya4PKQeCaiQ 5+8r7+9AFz0NoPyi2pJaKYuGTHRH2pnZbSv8IyB3Oxt/CGSw/Z+jTA/j5ftkqOC2DHNB 8LIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=1MULVzLskgIkdVJbBoJN4YEbTCFMQ5a8n6bLbUXQoRA=; b=v4zkwBywCuDcVkH83fzVb2XgS0r3pK86rER9lqw16cHRCnV7e6FxRcrqx8bvdJB2Bd vk+W74zq63x1Z4MwxOYiyioTvrnPWq0TN1OVHIumv1pVcyOy2pNyaGyg2a9X3m5VLvxi GoDobCD1zwXLL8BOb48GnodIJZklVl8WpGO/0E+KDrHbwwlqp9W1JFdWsrVeqzTml5t4 VH5BSHiShjtyvIKJMHj6h+lz1j/hu0nAc6cBUq5PmWpBquBQQWYvi6ZP/9j2EtCCyBtx /8mEzY3kkqDFceboF19qdiAAVz2CM9UTKjyhgXa7Vqw4P54btuc7f2g6eZvWqsZVpLxQ 0gDg== X-Gm-Message-State: AOAM530GpGc2iOJF2PcN3ogO0P+M2jfaCxpenPd7DSLVJSF1UrHJasBV GU7pR1EJlbDTIeNaaRvnKUFX7yoZ71dyFA== X-Google-Smtp-Source: ABdhPJyZfAN/fbtWJrVNwoljek2Nvx3kSDZLEVvCYudHe269/fdxMYZBoMOYaZC2e7/ruubl/k2TaQ== X-Received: by 2002:a17:90b:4a06:b0:1c7:2020:b5b9 with SMTP id kk6-20020a17090b4a0600b001c72020b5b9mr2548658pjb.58.1647834631960; Sun, 20 Mar 2022 20:50:31 -0700 (PDT) Received: from [192.168.0.17] (125-9-4-59.rev.home.ne.jp. [125.9.4.59]) by smtp.gmail.com with ESMTPSA id o5-20020a056a0015c500b004f76735be68sm17910377pfu.216.2022.03.20.20.50.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Mar 2022 20:50:31 -0700 (PDT) Message-ID: Date: Mon, 21 Mar 2022 12:49:39 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 To: freebsd-hackers@FreeBSD.org Content-Language: en-US From: Soichiro Ueda Subject: Please advice on applying GSoC Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KMLHY0fGfz3R9w X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="J4VAX/GK"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of thelatticeheart@gmail.com designates 2607:f8b0:4864:20::1036 as permitted sender) smtp.mailfrom=thelatticeheart@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.991]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1036:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! I'm Soichiro Ueda, a university student from Japan. I'm thinking of participate in GSoC. I'm interested in the idea of eBPF XDP Hooks. Before submitting a proposal, I'm planning to send a patch to understand the source code of FreeBSD, and the idea. But I'm wondering what tasks should I tackle. Do you have any ideas? Biography I'm a junior in Kyoto University. I major in Compurter Scienece. I've worked for some internships as a software engineer. Now I work in a startup, developing a SaaS which automates quotation work in international logistics. Talking about experiences related to this GSoC project, I've developed a NIC driver from scratch for MikanOS, which is an operating system targeting x86_64 for people who learn operating system development. I've implemented protocols of Ethernet, ARP, IP, ICMP for MikanOS, and I've successed to send ping requests to servers in the Internet and receive responses. I've made a processor using Verilog and FPGA for practical in the university. Now I learn operating systems by reimplementing MikanOS. MikanOS: https://github.com/uchan-nos/mikanos My work of MikanOS network: https://github.com/Saza-ku/mikanos-nic/tree/nic From nobody Mon Mar 21 21:23:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C663E1A2436F for ; Mon, 21 Mar 2022 21:23:44 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KMnfl63GRz3C9C for ; Mon, 21 Mar 2022 21:23:43 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: by mail-qk1-f169.google.com with SMTP id g8so12709652qke.2 for ; Mon, 21 Mar 2022 14:23:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=toSdfYHFPjPxEZcrZ0dsyQ4lTqCvlV0meE4GkmAZheE=; b=X4q3+9tEZM89voZayZCRMv7StMRodcMGqYS3VoVsG1P+H3YB39YxMcN4bYLk5wkdgd ZUcacShmnZRj+v3p5S4S9N5HNGsQAGKR/YZ2ox0diD2l1ryGG6Z0I6y223ea4mv/bQ+g 3p7rdne89rSqCRRuAEieQjzDWrolEeupNCwQPuGz6bTK9Io904gmsVjJDQFKAzYn2azu 9JFt2Pk3w0J0pZFwn81NYmLgEa/76Kk3IlM8geacLN0BFtPmw+mY1ZuU8bMUrmHB3CMo zYk8AJZuCFpb+bTbmR3iqrr0k3uktVyf1e4JeXibs+uOhohllCD75z0ko3koZD5CUlSL fJkA== X-Gm-Message-State: AOAM5313k/dWlrZz9vXAH8JtgxkV8BjB8fAOPwF8u7H42+VVvciIvPcy oVD1NqmPpPtvFyBvbvl3C6cr9XalC8v2xw4i X-Google-Smtp-Source: ABdhPJx7Dhnjpc4eaVrVk9lsFyUR1NkdaWPQStA2aUYvH5bfoLV1hm3QupD22v6+77OUGIFmvxCmlQ== X-Received: by 2002:a37:8805:0:b0:67b:2de7:a799 with SMTP id k5-20020a378805000000b0067b2de7a799mr13626726qkd.533.1647897822915; Mon, 21 Mar 2022 14:23:42 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (drmons0544w-156-34-173-250.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.173.250]) by smtp.gmail.com with ESMTPSA id s5-20020a05620a29c500b0067eaafac4d3sm1210999qkp.99.2022.03.21.14.23.42 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Mar 2022 14:23:42 -0700 (PDT) From: Joseph Mingrone To: Soichiro Ueda Cc: freebsd-hackers@FreeBSD.org Subject: Re: Please advice on applying GSoC References: Date: Mon, 21 Mar 2022 18:23:41 -0300 In-Reply-To: (Soichiro Ueda's message of "Mon, 21 Mar 2022 12:49:39 +0900") Message-ID: <86a6djvw2q.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (berkeley-unix) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4KMnfl63GRz3C9C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jrm@ftfl.ca designates 209.85.222.169 as permitted sender) smtp.mailfrom=jrm@ftfl.ca X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[jrm@FreeBSD.org,jrm@ftfl.ca]; RECEIVED_SPAMHAUS_PBL(0.00)[156.34.173.250:received]; 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)[jrm@FreeBSD.org,jrm@ftfl.ca]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jrm]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.169:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.169:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N [Resending with my address that's subscribed to the list] Hello! On Mon, 2022-03-21 at 12:49, Soichiro Ueda wrote: > Hi! I'm Soichiro Ueda, a university student from Japan. > I'm thinking of participate in GSoC. I'm interested in the idea of eBPF XDP Hooks. > Before submitting a proposal, I'm planning to send a patch to understand the source code of FreeBSD, and the idea. > But I'm wondering what tasks should I tackle. Do you have any ideas? We have an article about contributing to FreeBSD at https://docs.freebsd.org/en/articles/contributing/ or in Japanese at https://docs.freebsd.org/en/articles/contributing/ . Perhaps the most useful point for you would be '1.3. Work through the PR Database'. To get FreeBSD set up, the FreeBSD Handbook will also be useful. http://freebsd.org/handbook or https://docs.freebsd.org/ja/books/handbook/. > Biography > I'm a junior in Kyoto University. I major in Compurter Scienece. > I've worked for some internships as a software engineer. Now I work in a startup, developing a SaaS which automates quotation work in international logistics. > Talking about experiences related to this GSoC project, > I've developed a NIC driver from scratch for MikanOS, which is an operating system targeting x86_64 for people who learn operating system development. > I've implemented protocols of Ethernet, ARP, IP, ICMP for MikanOS, and I've successed to send ping requests to servers in the Internet and receive responses. > I've made a processor using Verilog and FPGA for practical in the university. > Now I learn operating systems by reimplementing MikanOS. > MikanOS: https://github.com/uchan-nos/mikanos > My work of MikanOS network: https://github.com/Saza-ku/mikanos-nic/tree/nic Thanks for your interest. If you have problems getting started, please don't hesitate to ask more questions. Joe From nobody Tue Mar 22 12:57:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2CE631A3E555 for ; Tue, 22 Mar 2022 12:58:30 +0000 (UTC) (envelope-from the.latticeheart@gmail.com) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KNBPK32TNz3tKn for ; Tue, 22 Mar 2022 12:58:29 +0000 (UTC) (envelope-from the.latticeheart@gmail.com) Received: by mail-pj1-x1029.google.com with SMTP id mz9-20020a17090b378900b001c657559290so2602189pjb.2 for ; Tue, 22 Mar 2022 05:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=EDiLVNWxeGTZpP+CxtjidPFn0tJFHG2bLuoUrWD9BUQ=; b=EzY6ZN0GWnY1gNQeb1W/+5SqWDCAAGzNhO7uSLFBjO7zGyvbVXxCBqHTcN2Om6sqZt FIPrtpFCAllxBfKzuc40PyxHXFLYbWEDI4NU4HhROxuOR9QrBiaJLjm/QYxNRfpFoJfO ezqUPHAfhGl5c5Wj+BLgGder62ExmKJz0Q82EMhbD1ycXDOYIUy9UTiJMfDn2s4ESJZG c5qNj0aNRC5k7KuInqOTBBHFlRCHbllixCz5laD3HXaj0W04m0S83li7fj7fMFQKL39Z dd36l+V2Hh0oykuMdQT5pdBzNCnef6IGERi8K7LnVlc61vsAiAeH27laiM8PgKCw8bAe r1Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=EDiLVNWxeGTZpP+CxtjidPFn0tJFHG2bLuoUrWD9BUQ=; b=F+MEsAF5zfbvH2zdJfZS9i4NqakDc4md91bY+P+GYsjkioTvxfJ423T6ekaC8UVsqq Cop9F3ensBB5mDStP74X9XvUEUMur6h8QCyYpKEF+PTingoqZa1JRjlFe0V8iO0t/CP9 5UG0CclTqxBOHqr0PVMRJ7sm1NYDplJw9IZr1GxxtvqmFmXpJmUXlV2qv7YrXMkCsd55 +rOm4Eu1vMwtbRL53uNPjzxt7G4OxHl44fEkQ+AdYrYV8YWYNUaitwozw9BEQSCH+Rzj 2rsd3dLmZEVUHacT9WPtGm4RGZIf8Fy9F9Nx3g3OGOoVyZbvtkR1dKxATULW/qNWa32K 90dg== X-Gm-Message-State: AOAM530YFDOoBBC1u+u4WkxgpHgNu2J7rve4dEncL7T402fWsqs8HYU/ zHPmoG4eNs2SbT9GCi8nc8OPPNdHs/8qvw== X-Google-Smtp-Source: ABdhPJyw7gq1wuftTGE5T+9G90JQkAJmumj1gwARqJIEZdwFFhepGU2xwlQOBnIvKdnSNpn0nV2dww== X-Received: by 2002:a17:903:2406:b0:14d:2f71:2e6d with SMTP id e6-20020a170903240600b0014d2f712e6dmr17841026plo.98.1647953908466; Tue, 22 Mar 2022 05:58:28 -0700 (PDT) Received: from [192.168.0.17] (125-9-4-59.rev.home.ne.jp. [125.9.4.59]) by smtp.gmail.com with ESMTPSA id j23-20020a17090ae61700b001c6bb352763sm2813237pjy.52.2022.03.22.05.58.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Mar 2022 05:58:27 -0700 (PDT) Message-ID: <2d45d763-5496-51c0-40fa-31efe1dc0ff8@gmail.com> Date: Tue, 22 Mar 2022 21:57:34 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Please advice on applying GSoC Content-Language: en-US To: Joseph Mingrone Cc: freebsd-hackers@FreeBSD.org References: <86ee2vvw89.fsf@phe.ftfl.ca> From: Soichiro Ueda In-Reply-To: <86ee2vvw89.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KNBPK32TNz3tKn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=EzY6ZN0G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of thelatticeheart@gmail.com designates 2607:f8b0:4864:20::1029 as permitted sender) smtp.mailfrom=thelatticeheart@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.986]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1029:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Joe. Thanks for the reply! I'll look over the PR Database. Soichiro On 2022/03/22 6:20, Joseph Mingrone wrote: > Hello! > > On Mon, 2022-03-21 at 12:49, Soichiro Ueda wrote: > >> Hi! I'm Soichiro Ueda, a university student from Japan. >> I'm thinking of participate in GSoC. I'm interested in the idea of eBPF XDP Hooks. >> Before submitting a proposal, I'm planning to send a patch to understand the source code of FreeBSD, and the idea. >> But I'm wondering what tasks should I tackle. Do you have any ideas? > We have an article about contributing to FreeBSD at > https://docs.freebsd.org/en/articles/contributing/ or in Japanese at > https://docs.freebsd.org/en/articles/contributing/ . Perhaps the most > useful point for you would be '1.3. Work through the PR Database'. > > To get FreeBSD set up, the FreeBSD Handbook will also be useful. > http://freebsd.org/handbook or > https://docs.freebsd.org/ja/books/handbook/. > >> Biography >> I'm a junior in Kyoto University. I major in Compurter Scienece. >> I've worked for some internships as a software engineer. Now I work in a startup, developing a SaaS which automates quotation work in international logistics. >> Talking about experiences related to this GSoC project, >> I've developed a NIC driver from scratch for MikanOS, which is an operating system targeting x86_64 for people who learn operating system development. >> I've implemented protocols of Ethernet, ARP, IP, ICMP for MikanOS, and I've successed to send ping requests to servers in the Internet and receive responses. >> I've made a processor using Verilog and FPGA for practical in the university. >> Now I learn operating systems by reimplementing MikanOS. >> MikanOS: https://github.com/uchan-nos/mikanos >> My work of MikanOS network: https://github.com/Saza-ku/mikanos-nic/tree/nic > Thanks for your interest. If you have problems getting started, please > don't hesitate to ask more questions. > > Joe From nobody Wed Mar 23 20:31:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 937E41A28F5F for ; Wed, 23 Mar 2022 20:31:19 +0000 (UTC) (envelope-from phil@freebsd.org) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KP0PL39lYz4f9y; Wed, 23 Mar 2022 20:31:18 +0000 (UTC) (envelope-from phil@freebsd.org) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 22NGAjat025582; Wed, 23 Mar 2022 13:31:12 -0700 Received: from nam02-bn1-obe.outbound.protection.outlook.com (mail-bn1nam07lp2042.outbound.protection.outlook.com [104.47.51.42]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3eygncbur5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Mar 2022 13:31:11 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KUunSsn6DstYiZWv9cn4xoYq9WWGgSG52T4l5UIrjSBRJ4D2Ln7HupdBecO9LLWTHEYC5iUn2s58siHmmTLrh+4/BdMhYRFJWefa7fknuHRG3ojBoRyuYGzqNhvu1hjG5PiiMMBwsGvlHBfayXXltb/sFzQ2fJT1P7K41Q8/Xj6E4fYnRiF8z1s69xsOxmRbaQ0r6+wlyr2t/xS6/NKH29T5sHDhO550aQ6dR57Aj34f4jz99LkD1So4ddWXfYwmv9Ijen+lMrgsuBSM0jKGZ58Bq55VcEcYD8KDthNB5V+hdcm5YU+rsQI1TDe4SUCKKiGW+ECNMLE5EblKBvllpw== 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=/iUpukdpw1SLk+i7vaQiwg527kRCT/HeURV2R49dtzM=; b=PWvI/QaYcDaQqMwOIy10l0ZccvX3k970Chh1IxGeHBUuBh/HtPXPR0ceNEDmDcXfMVxYD/UxaimPiSyrPTfJ9j5j3kukT+FMxaTHOjkFw4cJd4SstU2TU00uuanfN3yX4rSoXEO0TQizMMWdVNWYMEUpbMZ5c9+w8rynLGxwtYPMe6d3hmyVXZIjEKgE8m/fwVAKYQR3LUfJHKaKeGyfFe8KQDpskmCezJV2IpFFnq5oNd+VFSkvlDNzF8KG9o7yGntFbieBYkqGVPluuSaLu9jcCew41zaBQ1Wi0OW8wm1NOAnJqVuYOHIzEQKb8dVazvcD3faglpeag40AYgw/aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.14) smtp.rcpttodomain=freebsd.org smtp.mailfrom=freebsd.org; dmarc=none action=none header.from=freebsd.org; dkim=none (message not signed); arc=none Received: from MWHPR12CA0058.namprd12.prod.outlook.com (2603:10b6:300:103::20) by PH0PR05MB8463.namprd05.prod.outlook.com (2603:10b6:510:cd::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.15; Wed, 23 Mar 2022 20:31:10 +0000 Received: from MW2NAM12FT027.eop-nam12.prod.protection.outlook.com (2603:10b6:300:103:cafe::98) by MWHPR12CA0058.outlook.office365.com (2603:10b6:300:103::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.17 via Frontend Transport; Wed, 23 Mar 2022 20:31:10 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.242.14) smtp.mailfrom=freebsd.org; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=freebsd.org; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning freebsd.org discourages use of 66.129.242.14 as permitted sender) Received: from p-exchfe-eqx-01.jnpr.net (66.129.242.14) by MW2NAM12FT027.mail.protection.outlook.com (10.13.180.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5102.7 via Frontend Transport; Wed, 23 Mar 2022 20:31:09 +0000 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchfe-eqx-01.jnpr.net (10.104.9.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.27; Wed, 23 Mar 2022 15:31:09 -0500 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.27; Wed, 23 Mar 2022 15:31:09 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.27 via Frontend Transport; Wed, 23 Mar 2022 15:31:08 -0500 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.10]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 22NKV85V007936; Wed, 23 Mar 2022 13:31:08 -0700 (envelope-from phil@freebsd.org) Received: from [172.25.4.159] (localhost [127.0.0.1]) by idle.juniper.net (8.16.1/8.16.1) with ESMTP id 22NKNTFr026369; Wed, 23 Mar 2022 16:23:29 -0400 (EDT) (envelope-from phil@freebsd.org) From: Phil Shafer To: FreeBSD Hackers CC: "Simon J. Gerraty" Subject: What's the locale for system files (e.g. /etc/fstab)? Date: Wed, 23 Mar 2022 16:31:08 -0400 X-Mailer: MailMate (1.13.2r5673) Message-ID: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a2bdca03-107a-46d9-1955-08da0d0c10da X-MS-TrafficTypeDiagnostic: PH0PR05MB8463:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-JNPR-Received-From: outside X-MS-Exchange-SenderADCheck: 2 X-MS-Exchange-AntiSpam-Relay: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q3SUBRNQmvworerFmMDczU79kGAmeFzakgqRpTERNtgjJFikckt25lHQXT9oB/ABIBvNb/a/yn8JlPwGqndNBcwX0SX+dbU/a8aiUD+px/9ziWPHIunFnaWDI6Uz+1Sm8cRw96ApZ1JAsD6I5yFyBhuhNupPEZQEHWCd1O/Dc1Mz3YHL8LPkgTPOiQciz4BTq2rAwASRStN2i0eAleOJJyTljcCEUHjENkynvdE6IQ7X26gFDbGfkJg4/0Tm0OkwDDF3H1OSptH5u3f1E3K+pO49QHAdvH1Dt0402q3Qq82SjFf8Dj16YCTpvubZm1m40h+ZeIOOe6QEn2hjiU42Fi+85LY5wXvg52BTWBJk5XwodtI6bIych7h6ZyExFVFVK1rbu5pN5ivcG9DOIH1o4zDm4mLFcrN0bNv6X3p6K3w6SkNhGC9uPOQofgl5rIlrlIts9PZh25qaHa5QcfgogoIOwozxHkBDzoFm1VvIE2V1Tysfde4/UelKFb+HVFNK5pzHJzUdT9ZS3wE7V6f3X/OGw9FmvUqnVL6zbTdCZURu1/BJBxTG3f1NQtdr29yn/P1GeSXQUIYAzCPUn5W+hrCvWiP03NmFx5h+6EaIQ48bALOvFY8iHDTPGbjzIdh984psOfdKniRstZ93BySNgrCcBJE/W6TciB62pVD13x6QjT/helxkgcf8rN81htIG X-Forefront-Antispam-Report: CIP:66.129.242.14;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-01.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230001)(4636009)(46966006)(40470700004)(6666004)(2906002)(26005)(53546011)(70586007)(70206006)(86362001)(36756003)(6636002)(6916009)(336012)(508600001)(7126003)(35950700001)(47076005)(450100002)(33656002)(82310400004)(81166007)(356005)(8936002)(5660300002)(4326008)(8676002)(316002)(2616005)(37006003)(40460700003);DIR:OUT;SFP:1022; X-OriginatorOrg: junipernetworks.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2022 20:31:09.9062 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2bdca03-107a-46d9-1955-08da0d0c10da X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.242.14];Helo=[p-exchfe-eqx-01.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT027.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB8463 X-Proofpoint-GUID: briQ4amP9HSiQiRlxxIWEPZfXkDPjBYa X-Proofpoint-ORIG-GUID: briQ4amP9HSiQiRlxxIWEPZfXkDPjBYa X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.850,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-23_08,2022-03-23_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 bulkscore=0 clxscore=1011 lowpriorityscore=0 phishscore=0 spamscore=0 mlxlogscore=661 suspectscore=0 malwarescore=0 priorityscore=1501 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203230106 X-Rspamd-Queue-Id: 4KP0PL39lYz4f9y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=none; spf=softfail (mx1.freebsd.org: 67.231.152.164 is neither permitted nor denied by domain of phil@freebsd.org) smtp.mailfrom=phil@freebsd.org X-Spamd-Result: default: False [-1.27 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEFALL_USER(0.00)[phil]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.93)[0.928]; NEURAL_HAM_LONG(-1.00)[-0.998]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[104.47.51.42:received]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCVD_COUNT_SEVEN(0.00)[11]; RCVD_IN_DNSWL_LOW(-0.10)[67.231.152.164:from] X-ThisMailContainsUnwantedMimeParts: N On 23 Mar 2022, at 11:51, Piotr Pawel Stefaniak wrote: > mount: make libxo support more locale-aware > > "special", "node", and "mounter" are not guaranteed to be encoded > with > UTF-8. Use the appropriate modifier. > > - xo_emit("{:special}{L: on }{:node}{L: (}{:fstype}", > sfp->f_mntfromname, > + xo_emit("{:special/%hs}{L: on }{:node/%hs}{L: (}{:fstype}", > sfp->f_mntfromname, sfp->f_mntonname, sfp->f_fstypename); This recent "mount" patch highlights a libxo-related problem for which I don't have a solution: There are several files for which the encoding is not known. Since locale is user specific, we don't know how to interpret the contents of /etc/fstab. It's assumably been encoded with the format of the user who wrote it, but that information is lost. Put more generally, there's not a system-wide place which declares the encoding for system files, which leads to this problem where we interpret files from one user's locale using another user's locale. One solution would a symlink in /etc that "points to" the name of the current system-wide locale name. % ls -Fl /etc/locale lrwxr-xr-x 1 root wheel 7 Mar 23 15:42 /etc/locale@ -> C.UTF-8 (Or "/etc/system.locale" ?) If the symlink doesn't exist, would "C.UTF-8" be a suitable default moving forwards? It certainly would not be backwards compatible, since an existing fstab could have non-UTF-8 strings in it, encoded with the locale of the user who touched the file. But there's really no backwards compatible solution, given that there's no guarantee that (for any specific FreeBSD system) all system files were written with the same locale. Fun, eh? ;^) Opinions, thoughts, please? Thanks, Phil From nobody Thu Mar 24 15:19:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C9971A3A822 for ; Thu, 24 Mar 2022 15:19:12 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPTQl0HXqz4Wbd; Thu, 24 Mar 2022 15:19:10 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 22OFJ3ST098650; Thu, 24 Mar 2022 08:19:03 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 22OFJ3Mk098649; Thu, 24 Mar 2022 08:19:03 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> Subject: Re: What's the locale for system files (e.g. /etc/fstab)? In-Reply-To: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> To: Phil Shafer Date: Thu, 24 Mar 2022 08:19:03 -0700 (PDT) CC: FreeBSD Hackers , "Simon J. Gerraty" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4KPTQl0HXqz4Wbd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-0.14 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.15)[-0.146]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.900]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > On 23 Mar 2022, at 11:51, Piotr Pawel Stefaniak wrote: > > mount: make libxo support more locale-aware > > > > "special", "node", and "mounter" are not guaranteed to be encoded > > with > > UTF-8. Use the appropriate modifier. > > > > - xo_emit("{:special}{L: on }{:node}{L: (}{:fstype}", > > sfp->f_mntfromname, > > + xo_emit("{:special/%hs}{L: on }{:node/%hs}{L: (}{:fstype}", > > sfp->f_mntfromname, > sfp->f_mntonname, sfp->f_fstypename); > > This recent "mount" patch highlights a libxo-related problem for which I > don't have a solution: > > There are several files for which the encoding is not known. Since > locale is user specific, we don't know how to interpret the contents of > /etc/fstab. It's assumably been encoded with the format of the user who > wrote it, but that information is lost. Since you say "locale is user specific" it makes me want to say that this should come from the environment set by "default:" in /etc/login.conf, no need for a new file or anything special. > > Put more generally, there's not a system-wide place which declares the > encoding for system files, which leads to this problem where we > interpret files from one user's locale using another user's locale. Well /etc/login.conf *IS* a system wide declaration of this type of stuff, both lang= and charset= are declared there. > > One solution would a symlink in /etc that "points to" the name of the > current system-wide locale name. > > % ls -Fl /etc/locale > lrwxr-xr-x 1 root wheel 7 Mar 23 15:42 /etc/locale@ -> C.UTF-8 grep lang /etc/login.conf: :lang=C.UTF-8: :lang=ru_RU.UTF-8:\ Probably what you want? > > (Or "/etc/system.locale" ?) > > If the symlink doesn't exist, would "C.UTF-8" be a suitable default > moving forwards? It certainly would not be backwards compatible, since > an existing fstab could have non-UTF-8 strings in it, encoded with the > locale of the user who touched the file. But there's really no > backwards compatible solution, given that there's no guarantee that (for > any specific FreeBSD system) all system files were written with the same > locale. Fun, eh? ;^) > > Opinions, thoughts, please? > > Thanks, > Phil > > -- Rod Grimes rgrimes@freebsd.org From nobody Thu Mar 24 15:31:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00F1C1A3EA1A for ; Thu, 24 Mar 2022 15:31:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPTjM6LPRz4c08 for ; Thu, 24 Mar 2022 15:31:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92d.google.com with SMTP id b37so2179001uad.12 for ; Thu, 24 Mar 2022 08:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PSPHqmKQP6eOg38MOo5mDQRr+7xhdqE1cwQdy+AZml8=; b=HvcNqOccaQLyJpioHgmQzdRjB/ne6Z5BNNLKsAs0ryKVF/HyHsqHJ1eh07Qs0j35xw A6N1JMk5qlAj6xQAD/DTQOw1aYKPockjM9lZzLFF0VOMGYw/89v+j5+CMQWLYmFE1nP3 snA4XN8ynnUFKDxaVEjf6MzUtTKdgyo/7il5e3QoLoYaDUB5h72233vFTcw/1Of0NU3L Ad/Rv9m3TIaHcKWj5Fad48A7gLYS8JlOzrUIclaV1TsAqcxrIRs+xIc46U55CbVKOrRN DwYGgrG1064021svfDNrAy1JxcEt4SFHRSPYCdIJDBCE9ZWn156HhKJQYrCI1uvdlwsO y1CA== 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=PSPHqmKQP6eOg38MOo5mDQRr+7xhdqE1cwQdy+AZml8=; b=KsMa5Haey2/oAFUjFbxhmGNJho5vmxwTEGkNyrAMYIOnedLGhbjndk+2kI6KjNzS/H 2hQZdH8QsJQ4tGcLR5ZvI7D8L6w/GwljZwdgsEZnLHiEulZ0j6W3OuWyY+oBFfj1Zg2y TaDzOZxaB4BeSxXf83LGiQciaifZ7B6IxpC48oTQCgZbi33Xvdhc41TE0SU96hK/ydM+ cz7iJhZrC5fzkCYya6vMTrPDPYYHKRWG3Skw7DxrQ5kq5xS9QwNm55VPvuzLhgkilglY SaABs0sc4tBxbCKccv8FbFdc6MDqXlZUxx2VFs/xHCXWkFbnth0gMWeRKcDnCeCoDyAE xX+A== X-Gm-Message-State: AOAM531GTP9oe6xg+wa5Mhx80MT74AwRpT+nZZ8RwTSkhpIRZRU4cAp7 v1Kk9TqGp32/RTcmAkL6ssqgh9Yum3vub0wkCDryNx17UUQ= X-Google-Smtp-Source: ABdhPJxpSPWjFWQEYVt7RkOavZNPaPUcHOE0q2ImWkkkHeVCxlL6zAipLYfxn2V3IY9ARBoKB+/5sRCsta63A19A1Y8= X-Received: by 2002:ab0:6804:0:b0:33c:6fe1:3266 with SMTP id z4-20020ab06804000000b0033c6fe13266mr2651982uar.91.1648135905426; Thu, 24 Mar 2022 08:31:45 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> In-Reply-To: <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> From: Warner Losh Date: Thu, 24 Mar 2022 09:31:33 -0600 Message-ID: Subject: Re: What's the locale for system files (e.g. /etc/fstab)? To: "Rodney W. Grimes" Cc: Phil Shafer , FreeBSD Hackers , "Simon J. Gerraty" Content-Type: multipart/alternative; boundary="0000000000002f5cc205daf88b12" X-Rspamd-Queue-Id: 4KPTjM6LPRz4c08 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=HvcNqOcc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [0.14 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.854]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(0.99)[0.992]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92d:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000002f5cc205daf88b12 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 24, 2022, 9:20 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > On 23 Mar 2022, at 11:51, Piotr Pawel Stefaniak wrote: > > > mount: make libxo support more locale-aware > > > > > > "special", "node", and "mounter" are not guaranteed to be encoded > > > with > > > UTF-8. Use the appropriate modifier. > > > > > > - xo_emit("{:special}{L: on }{:node}{L: (}{:fstype}", > > > sfp->f_mntfromname, > > > + xo_emit("{:special/%hs}{L: on }{:node/%hs}{L: (}{:fstype}", > > > sfp->f_mntfromname, > > sfp->f_mntonname, sfp->f_fstypename); > > > > This recent "mount" patch highlights a libxo-related problem for which I > > don't have a solution: > > > > There are several files for which the encoding is not known. Since > > locale is user specific, we don't know how to interpret the contents of > > /etc/fstab. It's assumably been encoded with the format of the user who > > wrote it, but that information is lost. > > Since you say "locale is user specific" it makes me want to say that > this should come from the environment set by "default:" in /etc/login.conf, > no need for a new file or anything special. > Config files, like fstab, have no locale and parsing them with a locale leads to errors, even when the user or the system has a nondefault locale. > > > Put more generally, there's not a system-wide place which declares the > > encoding for system files, which leads to this problem where we > > interpret files from one user's locale using another user's locale. > > Well /etc/login.conf *IS* a system wide declaration of this type of > stuff, both lang= and charset= are declared there. > Since system wide files like yhese are always parsed without a locale, this information is correct, but I'm not sure how it applies. It is always C.UTF-8. Anything else may, or may not, work based on accidents of coincident encoding. Not everything can change locales, and the fstab and other parsing routines in libc assume C.UTF-8 or even just the ascii-7/8 subset. > > > One solution would a symlink in /etc that "points to" the name of the > > current system-wide locale name. > > > > % ls -Fl /etc/locale > > lrwxr-xr-x 1 root wheel 7 Mar 23 15:42 /etc/locale@ -> C.UTF-8 > > grep lang /etc/login.conf: > :lang=C.UTF-8: > :lang=ru_RU.UTF-8:\ > > Probably what you want? > You can get this with the locale routines, no? No need for grep. Warner > > > (Or "/etc/system.locale" ?) > > > > If the symlink doesn't exist, would "C.UTF-8" be a suitable default > > moving forwards? It certainly would not be backwards compatible, since > > an existing fstab could have non-UTF-8 strings in it, encoded with the > > locale of the user who touched the file. But there's really no > > backwards compatible solution, given that there's no guarantee that (for > > any specific FreeBSD system) all system files were written with the same > > locale. Fun, eh? ;^) > > > > Opinions, thoughts, please? > > > > Thanks, > > Phil > > > > > > -- > Rod Grimes > rgrimes@freebsd.org > > --0000000000002f5cc205daf88b12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 24, 2022, 9:20 AM Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net= > wrote:
> On 23 Mar 2022= , at 11:51, Piotr Pawel Stefaniak wrote:
> > mount: make libxo support more locale-aware
> >
> >=C2=A0 =C2=A0 "special", "node", and "mou= nter" are not guaranteed to be encoded
> > with
> >=C2=A0 =C2=A0 UTF-8. Use the appropriate modifier.
> >
> > -=C2=A0 =C2=A0 =C2=A0 =C2=A0xo_emit("{:special}{L: on }{:nod= e}{L: (}{:fstype}",
> > sfp->f_mntfromname,
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0xo_emit("{:special/%hs}{L: on }{= :node/%hs}{L: (}{:fstype}",
> > sfp->f_mntfromname,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sfp->f_mntonname, s= fp->f_fstypename);
>
> This recent "mount" patch highlights a libxo-related problem= for which I
> don't have a solution:
>
> There are several files for which the encoding is not known.=C2=A0 Sin= ce
> locale is user specific, we don't know how to interpret the conten= ts of
> /etc/fstab.=C2=A0 It's assumably been encoded with the format of t= he user who
> wrote it, but that information is lost.

Since you say "locale is user specific" it makes me want to say t= hat
this should come from the environment set by "default:" in /etc/l= ogin.conf,
no need for a new file or anything special.

Config files, like fstab, have n= o locale and parsing them with a locale leads to errors, even when the user= or the system has a nondefault locale.=C2=A0

>
> Put more generally, there's not a system-wide place which declares= the
> encoding for system files, which leads to this problem where we
> interpret files from one user's locale using another user's lo= cale.

Well /etc/login.conf *IS* a system wide declaration of this type of
stuff, both lang=3D and charset=3D are declared there.

Since system wide fil= es like yhese are always parsed without a locale, this information is corre= ct, but I'm not sure how it applies.

<= div dir=3D"auto">It is always=C2=A0 C.UTF-8. Anything else may, or may not,= work based on accidents of coincident encoding. Not everything can change = locales, and the fstab and other parsing routines in libc assume C.UTF-8 or= even just the ascii-7/8 subset.

>
> One solution would a symlink in /etc that "points to" the na= me of the
> current system-wide locale name.
>
> % ls -Fl /etc/locale
> lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 7 Mar 23 15:42 /etc/locale@ = -> C.UTF-8

grep lang /etc/login.conf:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 :lang=3DC.UTF-8:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 :lang=3Dru_RU.UTF-8:\

Probably what you want?

<= /div>
You can get this with the locale routines, no? No ne= ed for grep.

Warner

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> >
> (Or "/etc/system.locale" ?)
>
> If the symlink doesn't exist, would "C.UTF-8" be a suita= ble default
> moving forwards?=C2=A0 It certainly would not be backwards compatible,= since
> an existing fstab could have non-UTF-8 strings in it, encoded with the=
> locale of the user who touched the file.=C2=A0 But there's really = no
> backwards compatible solution, given that there's no guarantee tha= t (for
> any specific FreeBSD system) all system files were written with the sa= me
> locale.=C2=A0 Fun, eh? ;^)
>
> Opinions, thoughts, please?
>
> Thanks,
>=C2=A0 =C2=A0Phil
>
>

--
Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org

--0000000000002f5cc205daf88b12-- From nobody Thu Mar 24 16:39:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 21E931A277AF for ; Thu, 24 Mar 2022 16:40:00 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPWCz09Cnz4nrv for ; Thu, 24 Mar 2022 16:39:59 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-yb1-xb2d.google.com with SMTP id v35so9409546ybi.10 for ; Thu, 24 Mar 2022 09:39:59 -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=SQQrSuLhViYFMSqQ+9wr50FT11JytxDefH7nVFYE33A=; b=dtaJKR+tOpOPiWyTVbf70H8gga/xlQk9BUex5ZiMODJLqjYFlG2bAxJVM1Lqly1OhQ 5FDgsHWvsJlCt4iCfKjiH6hsZrbRP3yXiZxBQtOkMUz0CEaADO1hl4s1JYXyEefrnF6D T5aNF3ix/5+FNN4h3AKfv8mqUqyQZ4O7zmcjQQ/qioaTT7QsSVU77BdUHYDsAxGNS3hc 3LGklg0eTWhg3cXgc2O0GdEi7DfM+SohWLGqM3A9KnvHgcT8IbRu0OXx+sKk+xTI6Tr3 91WiKhgJutULDgN9XqEDaKcHanySOAP3KIVR4Rwh4E7eG2InMf+nEFSC2jXzvfqcZKUc PO+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SQQrSuLhViYFMSqQ+9wr50FT11JytxDefH7nVFYE33A=; b=Ec56PoP2ZR9E/tcQG48bWhBgE1VMFtcmeU/lMJdJVGXfAlTkQ1qbnwfrs+X74tDIQQ Vn2g0YOAzQs2GsnbFb1sSlOOZPBzkenyXxxi5GEKYYlp10emYFk5BeiGBua4NZbb02du stNTTfg1JvX2MZehF6tXHHmfIRZHeH9Y6YEsriD6g89thrknTr253mlKyCzXoD2nRaI3 gTpHlKP90wrgXi+dhOp55WqppdYazrKWdwZnfL6TcI2ELR53pBAs6CgXH5f1Yr/SNoRL qihceNldHlspdPoIQpLsecDO3MXo5wK9N3SXSspV7xpAKMc8whFNQT/DqUsOhDHYLhrL Ul5Q== X-Gm-Message-State: AOAM533972T2aPSSRVKWS4cUp4vabdgkXcfOGI1v1vJ3CHeevXEpPB+E Hsic9wGpJxOECMBo26yjAt9BHSpxlgfErLlVSW+1MLZA X-Google-Smtp-Source: ABdhPJxOoQKzzBfuQ33Nl+m0Najm4tm80MSrZEY52+9WRFwuU4DjuOVPSN5BiCHQAUlEf+KDbMpeMuCrXUN9oOVCRjw= X-Received: by 2002:a25:3887:0:b0:633:714f:1449 with SMTP id f129-20020a253887000000b00633714f1449mr5269883yba.635.1648139998319; Thu, 24 Mar 2022 09:39:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ryan Stone Date: Thu, 24 Mar 2022 12:39:47 -0400 Message-ID: Subject: Re: Please advice on applying GSoC To: Soichiro Ueda Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KPWCz09Cnz4nrv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=dtaJKR+t; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rysto32@gmail.com designates 2607:f8b0:4864:20::b2d as permitted sender) smtp.mailfrom=rysto32@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Thanks for your interest! Unfortunately I don't believe that there has been any development on EBPF for FreeBSD for the past couple of years. At this point I don't anticipate seeing EBPF merge into the project. So unfortunately I can't really recommend any of the EBPF projects listed on the wiki as a GSoC project. If you are interested in non-EBPF projects, though, I'd definitely recommend that you pursue them. Sorry for the bad news, Ryan On Sun, Mar 20, 2022 at 11:50 PM Soichiro Ueda wrote: > > Hi! I'm Soichiro Ueda, a university student from Japan. > > I'm thinking of participate in GSoC. I'm interested in the idea of eBPF > XDP Hooks. > Before submitting a proposal, I'm planning to send a patch to understand > the source code of FreeBSD, and the idea. > But I'm wondering what tasks should I tackle. Do you have any ideas? > > Biography > I'm a junior in Kyoto University. I major in Compurter Scienece. > I've worked for some internships as a software engineer. Now I work in a > startup, developing a SaaS which automates quotation work in > international logistics. > > Talking about experiences related to this GSoC project, > > I've developed a NIC driver from scratch for MikanOS, which is an > operating system targeting x86_64 for people who learn operating system > development. > I've implemented protocols of Ethernet, ARP, IP, ICMP for MikanOS, and > I've successed to send ping requests to servers in the Internet and > receive responses. > > I've made a processor using Verilog and FPGA for practical in the > university. > > Now I learn operating systems by reimplementing MikanOS. > > MikanOS: https://github.com/uchan-nos/mikanos > My work of MikanOS network: https://github.com/Saza-ku/mikanos-nic/tree/nic > > From nobody Thu Mar 24 17:13:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A7231A32471 for ; Thu, 24 Mar 2022 17:13:04 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPWy64SGnz3Fyn for ; Thu, 24 Mar 2022 17:13:02 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: (Authenticated sender: ganael.laplanche@martymac.org) by mail.gandi.net (Postfix) with ESMTPSA id 88F7D40009 for ; Thu, 24 Mar 2022 17:13:01 +0000 (UTC) Message-ID: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> Date: Thu, 24 Mar 2022 18:13:01 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 From: Ganael Laplanche Subject: Our /bin/sh and process group IDs To: freebsd-hackers@freebsd.org Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KPWy64SGnz3Fyn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ganael.laplanche@martymac.org designates 217.70.183.194 as permitted sender) smtp.mailfrom=ganael.laplanche@martymac.org X-Spamd-Result: default: False [-1.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[217.70.183.194:from]; R_SPF_ALLOW(-0.20)[+ip4:217.70.183.192/28:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[martymac.org]; NEURAL_SPAM_SHORT(0.91)[0.910]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.194:from] X-ThisMailContainsUnwantedMimeParts: N Hello, I am trying to fork a sub-shell with its own process group id through a function that must itself be executed in the background. It should work with the following code: #---- #!/bin/sh # Parent shell IDs ps -o pid,ppid,pgid,comm -p $$ test_func () { set -m { /bin/sh -c 'sleep 1' ; } & # Forked shell IDs (pgid should be different from parent, # but it is not) ps -o pid,ppid,pgid,comm -p $! } # The following does not work: test_func & # ...but it works when function is not executed in the background: #test_func sleep 2 exit 0 #---- Unfortunately, with our /bin/sh, the sleeping process gets the *same* process group ID as its parent. I've tested several shell implementations; it works with : /usr/local/bin/bash --posix 'test.sh' # from bash-5.1.16 /usr/local/bin/zsh --emulate sh 'test.sh' # from zsh-5.8.1 /usr/local/bin/ksh93 'test.sh' # from ksh93-devel-2020.06.30 /usr/local/bin/mksh 'test.sh' # from mksh-59c /usr/local/bin/ksh 'test.sh' # from pdksh-5.2.14p2_6 but not with : /bin/sh 'test.sh' # on 13.0-RELEASE-p8 /usr/local/bin/dash 'test.sh' # from dash-0.5.11.5 am I missing something ? Any help welcome :) Best regards, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From nobody Thu Mar 24 19:12:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F48E1A2680B for ; Thu, 24 Mar 2022 19:12:24 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPZbq2rRGz3q90 for ; Thu, 24 Mar 2022 19:12:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa31.google.com with SMTP id e7so3085358vkh.2 for ; Thu, 24 Mar 2022 12:12: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=/4NnRAf1kecyoq+Psv47A8NN/m+ktL2Eq8EcP2sWYjw=; b=ez8bbcb9QyRVnqXIY5LOIQ6I01N2yoyXj1zCqrX7zZJhx9voOoilpIywm1d2yXsN/V PgE0U+YTe+zanVOx5NJX59PQbOxLB4CNQrjuKD9tf29QBXKaVpSClo+j3R1rK4lle7aC 1CbEKIHyRp1vvFS3OhAfHZpeu+KHrcRxp2PaG/w8YFGnpYHIL16Dx9uN890yDXSbD4RI /ec9wLiM8kketLdlk5fpEeepyaYiVX+dt62jlVmwy91GYA0cwiUUSlYbS5Ro/U5XMIHQ hvoNKsif2biCIyeppA5GTlqLaFchEEYuPoy1QkMSkALiFkkWa0w1MND2MUs+lsDRmwOy AgSQ== 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=/4NnRAf1kecyoq+Psv47A8NN/m+ktL2Eq8EcP2sWYjw=; b=CA91vi+e5nUib5VLPHfxMn9nhJY+PjGJ2E/FHGzLTXpeIto077a5E0dD+9WMLxP+g8 gh5JBI65JyXJ0Yk26ydz030Y8wvepBWElU8NRc7AAyBVXMRNKTcpBjvVRxTr12ASd+1d bnMDYjtocHx7R/2LpLbAiUrHmBi+gSCwd3/hq2hOz1b33scsRdZLdVRk7Ba3bwSBvxGB nxNDtyRVtNd3U26bxYRA8CamtCYTl6nGHqxet+HBAemaf4z2UnIU+o/qcam6U+OMwspE OsHe3dRliiwV2VnOM1mJoCf+muGj9dY07KIlYDustiziUpOFcsxp+p+OTP70XT9HQQK1 RmrA== X-Gm-Message-State: AOAM532LwEJWp4bHXoad7WW4OwHF5MkcmhNJz3tqyeRtQlMoc+4/zlRq ox8XSvSjyG5DeKD5a/pUrkSr4rU6uD18swzzyqTYjQ== X-Google-Smtp-Source: ABdhPJwf1rYEM+amgUqCl+wwMj3NkXo1UxXNtzWYIN2Mzx1ffknI9lnFbKRPWTb/yBhj6c5yrUZKBWCQlIKpNv4RckQ= X-Received: by 2002:a05:6122:2229:b0:32d:1642:b58b with SMTP id bb41-20020a056122222900b0032d1642b58bmr3293799vkb.27.1648149142368; Thu, 24 Mar 2022 12:12:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> <71356.1648139436@kaos.jnpr.net> In-Reply-To: <71356.1648139436@kaos.jnpr.net> From: Warner Losh Date: Thu, 24 Mar 2022 13:12:10 -0600 Message-ID: Subject: Re: What's the locale for system files (e.g. /etc/fstab)? To: "Simon J. Gerraty" Cc: "Rodney W. Grimes" , Phil Shafer , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000002b090005dafba03c" X-Rspamd-Queue-Id: 4KPZbq2rRGz3q90 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=ez8bbcb9; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.21 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.55)[-0.554]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.65)[-0.655]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a31:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000002b090005dafba03c Content-Type: text/plain; charset="UTF-8" On Thu, Mar 24, 2022, 10:30 AM Simon J. Gerraty wrote: > Warner Losh wrote: > > Config files, like fstab, have no locale and parsing them with a locale > leads to errors, even when the user or the system has a nondefault locale. > > > > > > > > Put more generally, there's not a system-wide place which declares the > > > encoding for system files, which leads to this problem where we > > > interpret files from one user's locale using another user's locale. > > > > Well /etc/login.conf *IS* a system wide declaration of this type of > > stuff, both lang= and charset= are declared there. > > > > Since system wide files like yhese are always parsed without a locale, > this information is correct, but I'm not sure how it applies. > > > > It is always C.UTF-8. Anything else may, or may not, work based on > accidents of coincident encoding. Not everything can change locales, and > the fstab and other parsing routines in libc assume C.UTF-8 or even just > the ascii-7/8 subset. > > > > > > > > One solution would a symlink in /etc that "points to" the name of the > > > current system-wide locale name. > > > > > > % ls -Fl /etc/locale > > > lrwxr-xr-x 1 root wheel 7 Mar 23 15:42 /etc/locale@ -> C.UTF-8 > > > > grep lang /etc/login.conf: > > :lang=C.UTF-8: > > :lang=ru_RU.UTF-8:\ > > > > Probably what you want? > > I doubt it, one is from the entry for Russian users ;-) > > > > > You can get this with the locale routines, no? No need for grep. > > I suspect not. > > AFAIK virtually everything about locale support tells you about the > locale for the current process - which does not necessarily inform you > of the locale that was in effect when a system file was last edited. > > I don't even know if it is guaranteed that everything that reads system > files groks random locales - or what happens when you have 3 admins each > prefering a different locale, do different entries in fstab for example > get impacted and the result thus not readable by anyone? > > There's probably something to be said for enforcing something like > C.UTF-8 for system files. > That is the primary reason for system files always being C.UTF-8... There is no way to tag it as anything else... and some of these files are often parsed from a context that can't set the locale, like the boot loader or the kernel... also, these files have a format that was defined back in the 7bit ascii time frame. They also don't make use of the text in a way that isn't literal... Having said that, I'm unsure how you'd mount / from fstab, or if that is well defined. The kernel just presents a string of bytes not containing /... Warner --sjg > --0000000000002b090005dafba03c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Mar 24, 2022, 10:30 AM Simon J. Gerraty <sjg@juniper.net> wrote:
Warner Losh <imp@bsdimp.com> wrote:
> Config files, like fstab, have no locale and parsing them with a local= e leads to errors, even when the user or the system has a nondefault locale= .
>
> >
> > Put more generally, there's not a system-wide place which dec= lares the
> > encoding for system files, which leads to this problem where we > > interpret files from one user's locale using another user'= ;s locale.
>
> Well /etc/login.conf *IS* a system wide declaration of this type of > stuff, both lang=3D and charset=3D are declared there.
>
> Since system wide files like yhese are always parsed without a locale,= this information is correct, but I'm not sure how it applies.
>
> It is always=C2=A0 C.UTF-8. Anything else may, or may not, work based = on accidents of coincident encoding. Not everything can change locales, and= the fstab and other parsing routines in libc assume C.UTF-8 or even just t= he ascii-7/8 subset.
>
> >
> > One solution would a symlink in /etc that "points to" t= he name of the
> > current system-wide locale name.
> >
> > % ls -Fl /etc/locale
> > lrwxr-xr-x=C2=A0 1 root=C2=A0 wheel=C2=A0 7 Mar 23 15:42 /etc/loc= ale@ -> C.UTF-8
>
> grep lang /etc/login.conf:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:lang=3DC.UTF-8:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:lang=3Dru_RU.UTF-8:\
>
> Probably what you want?

I doubt it, one is from the entry for Russian users ;-)

>
> You can get this with the locale routines, no? No need for grep.

I suspect not.

AFAIK virtually everything about locale support tells you about the
locale for the current process - which does not necessarily inform you
of the locale that was in effect when a system file was last edited.

I don't even know if it is guaranteed that everything that reads system=
files groks random locales - or what happens when you have 3 admins each prefering a different locale, do different entries in fstab for example
get impacted and the result thus not readable by anyone?

There's probably something to be said for enforcing something like
C.UTF-8 for system files.
That is the primary reason for system files always= being C.UTF-8... There is no way to tag it as anything else... and some of= these files are often parsed from a context that can't set the locale,= like the boot loader or the kernel... also, these files have a format that= was defined back in the 7bit ascii time frame. They also don't make us= e of the text in a way that isn't literal...
Having said that, I'm unsure how you'd mou= nt /<kanji-for-neko> from fstab, or if that is well defined. The kern= el just presents a string of bytes not containing /...

Warner=C2=A0

--sjg
--0000000000002b090005dafba03c-- From nobody Fri Mar 25 04:08:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6BB9E1A364B5 for ; Fri, 25 Mar 2022 04:09:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPpW046zRz4VJ0 for ; Fri, 25 Mar 2022 04:09:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x932.google.com with SMTP id i26so2889774uap.6 for ; Thu, 24 Mar 2022 21:09:00 -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=r/yeDJx2xM2/YBuk8VA9ROcAgKr6rLeSmMn0AMXwIr4=; b=w63WoJGo7LWZv9O60e1Ze+DuKk4/ShxAIGDKQ+RAunPR5rvTQxG3k7D84Y1mfNnQSh 8hCX8bkKTXt40CjSWdKrpUGMKXQMdXpapO2mzF9//xfi+kcXAN8VPjPYXVG6KlObd8qX LDs1JAE2GsuSErx0h8/VUOg4bmvj5g0C+7RCkWO7bXYXpZa3hdX5CK8p1t+UTpJK6vJE q64eQnaoggKXpcRE+gEsbTldcR5tmIgtijZHZ5rY7PCcoaPBtzPquhquuFc2RyAPB1Ku McMSLsRTrtnSqYGcmcC+vYPtledsznGZ8VOoxMddwj9TcukLseu4Gkprxi2dNINpLZa7 Yfnw== 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=r/yeDJx2xM2/YBuk8VA9ROcAgKr6rLeSmMn0AMXwIr4=; b=vkEcvuR6L6TmLijFmft/ko53XxusluDWx+M93AeXYo5RdxZH99t9HNaz2KgP2atXi4 QrKbRmExzJx5xjoQHnmkvH25ja0JMqSs/jQgtC4/OtFXGBbrlGKll/EGp4vmeFCytSmD ceVuPuDBXd1oOoEK9VvRjqKGKtcqaGnYSn1/3pJ5es+CbrFROo2UStWhZUc0hkdM4FOn pHPIyJ+jX71tfMI/jdVpeVqbCPz5f/WZdU4ECKDNkAK93X9Or9BLNndCFqUjY36lPr6p SKTs/fMBeMITNaZQeGxwjLeziryleE7cv0vgdoQYQtXlD7+L7KZpwdswUO9YKYaC/5N8 Vo9g== X-Gm-Message-State: AOAM530uoUcbuHFcq1OxZCvQfAem7XSiz7wrD34tnz44bG2R2G4NLEzw 1Y/vFDx5fnvN4GO3C+ZxARqqaNPyz+YJWaQOF4cPSA== X-Google-Smtp-Source: ABdhPJzbF+yCFB0D2MVaMHOUksC+jWVgWRjusO1MHplpNouZc1JXY8bzE8n2qPWPQrBp+hCI4C39caCWwOA09Z2lDc0= X-Received: by 2002:ab0:6804:0:b0:33c:6fe1:3266 with SMTP id z4-20020ab06804000000b0033c6fe13266mr3973712uar.91.1648181334131; Thu, 24 Mar 2022 21:08:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> <71356.1648139436@kaos.jnpr.net> In-Reply-To: From: Warner Losh Date: Thu, 24 Mar 2022 22:08:47 -0600 Message-ID: Subject: Re: What's the locale for system files (e.g. /etc/fstab)? To: Phil Shafer Cc: "Simon J. Gerraty" , "Rodney W. Grimes" , Phil Shafer , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f25ecf05db031ebb" X-Rspamd-Queue-Id: 4KPpW046zRz4VJ0 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=w63WoJGo; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::932) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.96 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.963]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::932:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000f25ecf05db031ebb Content-Type: text/plain; charset="UTF-8" On Thu, Mar 24, 2022 at 2:51 PM Phil Shafer wrote: > On 24 Mar 2022, at 15:12, Warner Losh wrote: > > On Thu, Mar 24, 2022, 10:30 AM Simon J. Gerraty > > > wrote: > >> AFAIK virtually everything about locale support tells you about the > >> locale for the current process - which does not necessarily inform > >> you > >> of the locale that was in effect when a system file was last edited. > > Exactly. The value is $LANG is transient, leaving no clue about the > encoding of the data. > > >> There's probably something to be said for enforcing something like > >> C.UTF-8 for system files. > > I'd like to have UTF-8 as a given, or at least something definitive like > the symlink idea. Something that tells df, mount, etc how to treat the > value, so that it knows if it's locale-based ("%hs" for libxo) or utf-8 > ("%s" for libxo). > Right now we use %s for these things in all the other utilities (or have traditionally done so, I've not checked recently). We don't setup the locale stuff in these programs at all, so to match historic practice, I think libxo should use %s. > > That is the primary reason for system files always being C.UTF-8... > > There is no way to tag it as anything else... and some of these files > > are often parsed from a context that can't set the locale, like the > > boot loader or the kernel... also, these files have a format that was > > defined back in the 7bit ascii time frame. They also don't make use of > > the text in a way that isn't literal... > > Exactly. There's just no way to know in the current setup. And > declaring it UTF-8 will break anyone currently using locale-based > values. Using the symlink has the value of allowing a simple fix ("sudo > ln -s $LANG /etc/locale"). > Except it's not a simple fix. Sure, you can find this value, but nothing will use it, necessarily. Since there's little value and little need, I think it would be more hassle than it's worth absent a much more extensive audit. For system wide things like config files, we assume C.UTF-8 or the lessor ASCII-7 (or maybe ASCII-8). > Having said that, I'm unsure how you'd mount / from > > fstab, or if that is well defined. The kernel just presents a string > > of bytes not containing /... > > Currently it's not well defined, just a string of bytes, which has > worked fine so far, but it's a problem for adding libxo support to df > and mount, since the strings being used don't have a known encoding. > And JSON, XML, or HTML are UTF-8, so we need to know how to treat them. > The patch under review changes mount to use "%hs" which means that > strings will be locale-based, but that means they will be interpreted > using the current process's $LANG, which may not be how the file was > encoded. > Right. They are de-facto C.UTC-8, at least at the top level these days. That's why I think we should use %s unless someone does extensive testing and auditing of these programs to see if they still work (along with test suites to make sure they still work). We should not be in the business of promising that we can set the locale in any meaningful way and have it work for system-level things. In addition, we'd need to add a test suite to test the boot loader so that the presence of non-C.UTC-8 encoded strings in /etc/fstab doesn't cause it to misbehave. My big worry is that this will open up a big can of worms for people that have a system-wide default set to not be C.UTC-8 and these changes will cause subtle behavior changes that we have to play whack-a-mole with in the forums and PR database. They may not be obviously related to this change at first, and you may be hard to track down to fix what comes up. I will be the first to admit that I feel a bit burned by the locale stuff in global settings since I had to rip out a bunch of locale things in our awk because they caused weird compatibility problems with awk scripts written in other systems. Warner > Thanks, > Phil > > --000000000000f25ecf05db031ebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 24, 2022 at 2:51 PM Phil = Shafer <phil@juniper.net> wro= te:
On 24 Mar 20= 22, at 15:12, Warner Losh wrote:
> On Thu, Mar 24, 2022, 10:30 AM Simon J. Gerraty
> <sjg@juniper.n= et<mailto:sjg@j= uniper.net>> wrote:
>> AFAIK virtually everything about locale support tells you about th= e
>> locale for the current process - which does not necessarily inform=
>> you
>> of the locale that was in effect when a system file was last edite= d.

Exactly.=C2=A0 The value is $LANG is transient, leaving no clue about the <= br> encoding of the data.

>> There's probably something to be said for enforcing something = like
>> C.UTF-8 for system files.

I'd like to have UTF-8 as a given, or at least something definitive lik= e
the symlink idea.=C2=A0 Something that tells df, mount, etc how to treat th= e
value, so that it knows if it's locale-based ("%hs" for libxo= ) or utf-8
("%s" for libxo).

Right now w= e use %s for these things in all the other utilities (or have
tra= ditionally done so, I've not checked recently). We don't setup the<= /div>
locale stuff in these programs at all, so to match historic pract= ice,
I think libxo should use %s.
=C2=A0
> That is the primary reason for system files always being C.UTF-8... > There is no way to tag it as anything else... and some of these files =
> are often parsed from a context that can't set the locale, like th= e
> boot loader or the kernel... also, these files have a format that was =
> defined back in the 7bit ascii time frame. They also don't make us= e of
> the text in a way that isn't literal...

Exactly.=C2=A0 There's just no way to know in the current setup.=C2=A0 = And
declaring it UTF-8 will break anyone currently using locale-based
values.=C2=A0 Using the symlink has the value of allowing a simple fix (&qu= ot;sudo
ln -s $LANG /etc/locale").

Except = it's not a simple fix. Sure, you can find this value, but nothing
=
will use it, necessarily. Since there's little value and little ne= ed, I
think it would be more hassle than it's worth absent a = much more
extensive audit. For system wide things like config fil= es, we assume
C.UTF-8 or the lessor ASCII-7 (or maybe ASCII-8).

> H= aving said that, I'm unsure how you'd mount /<kanji-for-neko>= from
> fstab, or if that is well defined. The kernel just presents a string <= br> > of bytes not containing /...

Currently it's not well defined, just a string of bytes, which has
worked fine so far, but it's a problem for adding libxo support to df <= br> and mount, since the strings being used don't have a known encoding.=C2= =A0
And JSON, XML, or HTML are UTF-8, so we need to know how to treat them.=C2= =A0
The patch under review changes mount to use "%hs" which means tha= t
strings will be locale-based, but that means they will be interpreted
using the current process's $LANG, which may not be how the file was encoded.

Right. They are de-facto C.UTC= -8, at least at the top level these days. That's
why I think = we should use %s unless someone does extensive testing and
auditi= ng of these programs to see if they still work (along with test suites
to make sure they still work). We should not be in the business of pr= omising
that we can set the locale in any meaningful way and have= it work for system-level
things. In addition, we'd need to a= dd a test suite to test the boot loader so
that the presence=C2= =A0of non-C.UTC-8 encoded strings in /etc/fstab doesn't cause it
<= div>to misbehave. My big worry is that this will open up a big can of worms= for people
that have a system-wide default set to not be C.UTC-8= and these changes will
cause subtle behavior changes that we hav= e to play whack-a-mole with in
the forums and PR database. They m= ay not be obviously related to this change
at first, and you may = be hard to track down to fix what comes up.

I will= be the first to admit that I feel a bit burned by the locale stuff in glob= al
settings since I had to rip out a bunch of locale things in ou= r awk because they
caused weird compatibility problems with awk s= cripts written in other systems.

Warner
= =C2=A0
Thanks,
=C2=A0 Phil

--000000000000f25ecf05db031ebb-- From nobody Fri Mar 25 08:52:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 603641A2DFF9 for ; Fri, 25 Mar 2022 08:52:23 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KPwnz2Fflz3NRQ for ; Fri, 25 Mar 2022 08:52:23 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648198343; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zYPBtTLZHS1abWf9axuyzsfXct/vH4KIL+OiRub/UXw=; b=CCQ2Ux9hF1scHBIk8N0TlrMaHiMrvGtbMmhYLUxVjjgLn8K+LmvEJshWJitAfBfcIzByfA OCPZUP6tXDDBjeHKWclrHSoFNbLjB7eRLil88GYwPUucsSgFc6yNxUO5n3Ulw0x/Wf1wXR Fg0LrMIXXQlhGu5l5GGMk7ZCFOkkpDcViY+RErKAZunAjRMWq7Jq+qgowsGNwF+XngBEjr HKXf2qMbYbr12wgkIMxFwX5HBNNyzATwRfgJ+xBw2Tju/F82mP9BgSE9PUTXQLuxO8jFh0 KkIt9oZlsvia6hCS5mEnPTg7L6kc7pRNhm0XKy81AflEF113n+TOaXdy3A9dWg== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 2E783AE2F for ; Fri, 25 Mar 2022 08:52:23 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 6D72F2F6DE for ; Fri, 25 Mar 2022 08:52:22 +0000 (GMT) Message-ID: <27c92ee9-a4e2-ce6d-16b0-f0cef2961520@FreeBSD.org> Date: Fri, 25 Mar 2022 08:52:21 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: What's the locale for system files (e.g. /etc/fstab)? Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> <71356.1648139436@kaos.jnpr.net> From: David Chisnall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648198343; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zYPBtTLZHS1abWf9axuyzsfXct/vH4KIL+OiRub/UXw=; b=ak3njJ6RxYLHAP8zPExYexin/RbcQ/Dv39HVCW2wlLM48FqrHlZ6rZSqSchFHLzMnQcVpQ VsOK2edR8C1OVJ78qfiGopem2/MBbrohrgNPjWd7763DpHxTsBhwdwxx99eqM5L+KsYhhM srZIrWRlbEb0gaeLPiGSlRC3H83hi8fpwRF+u9a0CCn1vh9wIgPUtmFhlES+4TQbaHWWzf n+epqaQrqpgFWnwtDvnefY9YkqOY8PW8spoty03QyFtXoM1XjLAnNDEfmZ9UHKkGi6s1yY KTDMtPgtFLgTh4F8RuJiF/qkao8DM6YMdU4XbZc98QDW9tlV29eYgfw4aP1x2w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648198343; a=rsa-sha256; cv=none; b=fxpgZ8qrLFdmjY1FCOeXwe8jSCj7fFYrcQ43YrPM9vc/TUBfOAYVRArNc7spZrTyX7zeJV uLaGYDPDX0YJ0T+5bej81I7Ek63V+RWk+w2D8dsg3j2Ym9AwxQ3KGlZZzn1M8dkUIO04o3 YhvBv9EBJeL3xbDILXLu2yN08K8sbIy9H3qEepQXyq8dq/ACPAChhhGOVLS3XtPNbT/DCL syTMFJ/kw4gXhXTaySi374GbRC+qXEwF2tS7DeAIoJbnc6GBm9hJI5+k6c9PdtVllYdvIz C9hnQEe/Y3ETWUGhK8KLJ279Jo2lxJdagr7LV4gGs72ma5h3zAxr1mGSB3XoJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 25/03/2022 04:08, Warner Losh wrote: > Right. They are de-facto C.UTC-8, at least at the top level these days. Of the C.UTF-8 locale, I believe the .UTF-8 bit is the important one. The C bit controls collation order (we're not doing locale-aware sorting of these files), decimal and thousands separators (not used), and things like currency symbols (not important for system files). I wonder if we should write a UTF-8 BOM to the front of the default versions of these files and skip it in things that parse them. This would mean that anyone who opens the file in any unicode-aware editor (i.e. pretty-much anything these days) would automatically have the correct encoding set. Whether they're writing with a Japanese, English, French, or whatever locale set, the text encoding will be correct and the kernel / tools can keep their current assumptions (assuming that we explicitly document the separator characters in things like fstab to be tabs / spaces and not anything that unicode thinks is whitespace, which we do at least for fstab, I didn't check the man pages for any other files). David From nobody Fri Mar 25 11:10:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 72C551A25C44 for ; Fri, 25 Mar 2022 11:10:14 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4KPzs14FsMz4SvL for ; Fri, 25 Mar 2022 11:10:13 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id BB42D4C0714; Fri, 25 Mar 2022 06:10:05 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 25 Mar 2022 11:10:05 +0000 From: Pau Amma To: Warner Losh Cc: FreeBSD Hackers Subject: Re: What's the locale for system files (e.g. /etc/fstab)? In-Reply-To: References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> <71356.1648139436@kaos.jnpr.net> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <7773a0c73c77649efaf9f748ee8bb0b4@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KPzs14FsMz4SvL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N (pruned cc: to just the list) On 2022-03-25 04:08, Warner Losh wrote: > On Thu, Mar 24, 2022 at 2:51 PM Phil Shafer wrote: > >> On 24 Mar 2022, at 15:12, Warner Losh wrote: >> > That is the primary reason for system files always being C.UTF-8... >> > There is no way to tag it as anything else... and some of these files >> > are often parsed from a context that can't set the locale, like the >> > boot loader or the kernel... also, these files have a format that was >> > defined back in the 7bit ascii time frame. They also don't make use of >> > the text in a way that isn't literal... >> >> Exactly. There's just no way to know in the current setup. And >> declaring it UTF-8 will break anyone currently using locale-based >> values. Using the symlink has the value of allowing a simple fix >> ("sudo >> ln -s $LANG /etc/locale"). > > Except it's not a simple fix. Sure, you can find this value, but > nothing > will use it, necessarily. Since there's little value and little need, I > think it would be more hassle than it's worth absent a much more > extensive audit. For system wide things like config files, we assume > C.UTF-8 or the lessor ASCII-7 (or maybe ASCII-8). There's no ASCII-8. (If you meant 8859-*, there's 15 or 16, which essentially means "no".) Assuming ASCII (and therefore 7-bit) went out of style last millenium. Anything that expects or enforces something other than Unicode (which for all practical purposes means UTF-8) needs to be fixed urgently. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From eugen@grosbein.net Fri Mar 25 11:24:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CE671A2B4E2 for ; Fri, 25 Mar 2022 11:24:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ09w730hz4ZlG for ; Fri, 25 Mar 2022 11:24:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 22PBOiQj071759 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Mar 2022 11:24:44 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: ganael.laplanche@martymac.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 22PBOEf6067148 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 25 Mar 2022 18:24:39 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Our /bin/sh and process group IDs To: Ganael Laplanche , freebsd-hackers@freebsd.org References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> From: Eugene Grosbein Message-ID: Date: Fri, 25 Mar 2022 18:24:08 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KQ09w730hz4ZlG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.08 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 25.03.2022 0:13, Ganael Laplanche wrote: > am I missing something ? > > Any help welcome :) Try "set -m" beforehand. From nobody Fri Mar 25 11:41:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 545531A306E6 for ; Fri, 25 Mar 2022 11:41:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ0Xx0Vn3z4fD0 for ; Fri, 25 Mar 2022 11:41:21 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648208481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=IeeUCHPgG59NKk6B5zxY/LvwebyC9I5iG/TNDxoPUb0=; b=VuPsYNFdqJF0KRBw2Eo5nFk3y4/OL4qu+fQMe69K7Tq7sc47euoKMPGQeL3+MSEbfI0Um+ ygTQVvoEaRCIm107BMMD3GOuIzfJrg+zuxzsZaQZuPPvwlLZWB62sNNUFl32inbZzItYR+ f5VbhtJn+rzd95QSmTYpt5NMJGLmh+E25DdPWvDq0jG3FBAc4TC7cDrgrpzy3ZbCuISfHt ds/5bLmmFcx/HShfWAZ9dcbYAQMWqBSfJyT1ikgSmJzjQUbsBXFJkJTvZBoGn0epwiYpL4 Tm2AubpKcM0Y5whzs9JG3hKZEEecMwY19YuyzIzcOFF8axanJNEh5a/KmGeB/Q== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id E3E4CCCD5 for ; Fri, 25 Mar 2022 11:41:20 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id BB8582F6E4 for ; Fri, 25 Mar 2022 11:41:19 +0000 (GMT) Message-ID: Date: Fri, 25 Mar 2022 11:41:18 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-GB To: freebsd-hackers From: David Chisnall Subject: Getting the current thread's stack base / size on FreeBSD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648208481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=IeeUCHPgG59NKk6B5zxY/LvwebyC9I5iG/TNDxoPUb0=; b=WpuVSIXjKDIQj6XF7zkZoeLwNRXCey/wBGQY8NN8cj7wkETkKgROqzTDs5to5DKYhVJ8p5 KktUQI+PeRI8DTprzM8kJiWwaRSevxl9qf+6i6uEVFu/ZHE/siUBcre/nhpwdBZUhuihnS ElAKpNZGH3ZaBmjzCuw90hCLBV1byE0YsAIN1IKAzPh3AQ9IfCLzSnc98TLt4ndImcrItU l8TAsIwnJcovzl6yoT0IGbtHmnSQHN+NNQV0z3ErPjufSk6xzK4+AxmyBIGVoA/uT+Odx1 jsL6QWxp1FQqz3oqczD/pPD5z0sSO1O4jMkWDNcwUHvPFIjbmKI4z/YLf4UHwQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648208481; a=rsa-sha256; cv=none; b=YxV76RjL3oGyilXy1KqE4ZppRx1m03n4R0I/Kjhq1fnMwLVu3M4QZJIRNaWuG+GPaO88UC c9uRIYgKeSM3TfFWt6H+T4Bn4vl5sNEGsyXuqNaWrfRI3Rx6e4SkxkKIaw9gpzqhAF2+h/ XDGaZ4CV9rfgy/iBvuvzrt5ldmp0aPuZouz+mkV4UZ+5FAo34THW0G+HbW2lYfNnpLO1tn p/szQnbbPWPBCnMY5Gs8qUql7j5Ile3JDsakEYJ/4Iue7ECoqKiDaNCITxGREpTs9uzWDJ Aiz9Iu6iluUj2pycBnSjtQaWhNhnb2+84VH3BlNFz4gbbnJtxFqNVP5HgYX+ZA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi all, I'm trying to get the VAVM[1] WebAssembly runtime working on FreeBSD. In its platform-specific code, they need to find the base and size of the current stack. They have code for Linux and macOS, using different non-standard pthread extensions, but I couldn't see a mechanism for doing this on FreeBSD. Is there an API for this? Darwin provides a pair of _np APIs for getting these values. Glibc provides an API for getting the pthread attributes for the current thread, which is a bit more general and useful. Adding this to libthr would be a fairly simple change, if it doesn't exist already. Am I missing an existing mechanism? David [1] https://wavm.github.io/ From nobody Fri Mar 25 11:54:53 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 116871A3501B; Fri, 25 Mar 2022 11:55:31 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ0sG3zHsz4hxY; Fri, 25 Mar 2022 11:55:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-2e6650cde1bso79891597b3.12; Fri, 25 Mar 2022 04:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=iShWTSIeDsy4Hnopo6XPpfxjyxISP22sXUHsBvVNk18=; b=LwCyFCtAvLkRStQRD/IP6ekXpco0kq3esoU4Y2vs3KnCiVERCbXPPhUf++chnk6WUg +4FrrQOEBjvWMhWxscMkNx0ElLplDzkqeS7bLCrTAOB0myB+EU+rYFa1AYvxDluc6LDD npVkmx+C2vBLAc7ZyzImEHqh6pmpos4856W8VuxybLbaKUGBRPZnXi6tbXBc7nRCLFdC YvWYrf+bEylc6lPHwbBqVwTGyV4TkrRiRZB/1qGdKCf9FJiFdjXPi89GmmNrRTsKqioe fOG8oJdMHAsXQzv+nSIelN7ebMPz9m/ZufZ6V+Kg3BNpuPk1bv8mJWvkVQjZNPVhONg2 gsTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iShWTSIeDsy4Hnopo6XPpfxjyxISP22sXUHsBvVNk18=; b=AjX2uhR3Ang352LQkXXbI2wOsbYAxjIekLkIMKz9b3IsCf0nd/PY3uU8x6dcllHIyK Sf0fXS+yV+M0IgUecD5k42evW/pU6Zu/oDHBDNNtPtHCGLm3XA+C/MsrzrPjf1ax96aM DVmJP8c30p6gKZXTfqt8uR1FHgC12q3i1z/KxN6sUCF3PXJNPmgxcPd1sUnNOtZk5kHC zrRek7vvNUudVZozRyRUeEuR09bg10OEyFka1afC1pSiB6ihgDhIHGp1GJUiv25x2FPV sdw4QQHmhykG+Pvhh4ZEC3jBmYaGxqAAEc4EoTRtbkXZz4pWxziFIHBuWyOuS0MnMn8q Xl1g== X-Gm-Message-State: AOAM531b7w3C/A1aqRBMUV9PTXuvXK1xtrri9GH9Xy6ZPk8vBibwDpWi +yUBT80tdtrcJpdztQkeerXh0Zj9HAJf/S8neptJpRILmdkY3kMy X-Google-Smtp-Source: ABdhPJzMJgmU51bqiO0GAZI/mv3CVarJgM+xVKkxuM7RVAQ1ybmJm6gX19zwCcacC/f/5GAuIKRZev/X/33W5zkmEmo= X-Received: by 2002:a81:2f4d:0:b0:2e5:f342:a5a7 with SMTP id v74-20020a812f4d000000b002e5f342a5a7mr9855565ywv.287.1648209329568; Fri, 25 Mar 2022 04:55:29 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Fri, 25 Mar 2022 12:54:53 +0100 Message-ID: Subject: Virtio-win driver (virtio-blk and virtio-scsi) don't work when they are used on bhyve with Windows 11 as guest os To: FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009ac17405db09a3ae" X-Rspamd-Queue-Id: 4KQ0sG3zHsz4hxY X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LwCyFCtA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::112c as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-1.85 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.11)[0.110]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112c:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000009ac17405db09a3ae Content-Type: text/plain; charset="UTF-8" Hello. What I want to achieve is to pass thru two of my NTFS "formatted" disks to a Windows 11 VM,but without passing them thru using the USB controller in FreeBSD with a bhyve virtual machine (in the example below I tried to boot Windows 11 from the nvme disk nvd0. I'm using this FreeBSD version : FreeBSD marietto 13.0-RELEASE FreeBSD 13.0-RELEASE #8 n244809-dff3dead3734: Wed Feb 23 13:16:32 CET 2022 marietto@marietto:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I've configured the bhyve VM like this : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2,virtio-blk,/dev/da4p2 \ -s 3,virtio-blk,/dev/da2p1 \ -s 8,virtio-net,tap4 \ -s 10,hda,play=/dev/dsp,rec=/dev/dsp \ -s 29,fbuf,tcp=[0.0.0.0:5904](http://0.0.0.0:5904/),w=1440,h=900 \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \ vm4 < /dev/null & sleep 2 && vncviewer 0:4 These are the NTFS disks that I would like to see inside the Windows 11 guest os : -s 2,virtio-blk,/dev/da4p2 \ -s 3,virtio-blk,/dev/da2p1 \ => 34 19532873661 da4 GPT (9.1T) 34 32734 1 ms-reserved (16M) 32768 19532838912 2 ms-basic-data (9.1T) 19532871680 2015 - free - (1.0M) => 34 23437705149 da2 GPT (11T) 34 2014 - free - (1.0M) 2048 23437701120 1 ms-basic-data (11T) 23437703168 2015 - free - (1.0M) As you can see I've used the virtio-blk driver,so inside the Windows 11 VM I've installed the latest version of the virtio drivers. The disks attached are 0 byte large,so they aren't recognized by Windows 11. Is this a bug or what ? They are USB 3.0 disks. You can give a look at the images below if u want to have a better understanding : https://forums.freebsd.org/attachments/1-jpg.13311/ https://forums.freebsd.org/attachments/2-jpg.13312/ I've tried also like this : bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 1,ahci-hd,/dev/nvd0 \ -s 2,virtio-blk,/dev/da4 \ -s 3,virtio-blk,/dev/da2 \ -s 8,virtio-net,tap4 \ -s 10,hda,play=/dev/dsp,rec=/dev/dsp \ -s 29,fbuf,tcp=[0.0.0.0:5904](http://0.0.0.0:5904/),w=1440,h=900 \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \ vm4 < /dev/null & sleep 2 && vncviewer 0:4 and I get this error : *Assertion failed: (n >= 2 && n <= BLOCKIF_IOV_MAX + 2), function pci_vtblk_proc, file /usr/src/usr.sbin/bhyve/pci_virtio_block.c, line 324.* I have tried also with : -s 2,virtio-scsi,/dev/da4p2 \ -s 3,virtio-scsi,/dev/da2p1 \ and I have also installed the virtio-scsi driver on Windows 11,that has been accepted by windows,but the disks aren't recognized : https://forums.freebsd.org/attachments/screenshot_2022-03-13_11-23-54-jpg.13321/ https://forums.freebsd.org/attachments/screenshot_2022-03-13_11-10-16-jpg.13320/ Finally I tried by virtualizing ubuntu with bhyve using the virtio-scsi driver on ubuntu as guest os and it worked,so there is a bug only on the drivers for windows. You can see what happens with ubuntu going on the freebsd forum at this address : https://forums.FreeBSD.org/threads/usb-3-0-disks-not-recognized-by-windows-if-passed-through-as-slots.84402/post-559924 I have also opened a bug request below,but no one replied until now. https://github.com/virtio-win/kvm-guest-drivers-windows/issues/747 -- Mario. --0000000000009ac17405db09a3ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

<= table>

What I want to ach= ieve is to pass thru two of my NTFS=20 "formatted" disks to a Windows 11 VM,but without passing them thr= u using the USB controller in FreeBSD with a bhyve virtual machine (in the=20 example below I tried to boot Windows 11 from the nvme disk nvd0.


I'm using this FreeBSD version = :


FreeBSD marietto 13.0-RELEASE FreeBSD 13.0-RELEASE #8 n=
244809-dff3dead3734: Wed Feb 23 13:16:32 CET
2022     marietto@marietto:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


I've configured the bhyve VM li= ke this :


bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 1,ahci-hd,/dev/nvd0 \
-s 2,virtio-blk,/dev/da4p2 \
-s 3,virtio-blk,/dev/da2p1 \
-s 8,virtio-net,tap4 \
-s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \
-s 29,fbuf,tcp=3D[0.0.0.0:5904](http://0.0.0.0:5904/),w=3D1440,h=3D900 \
-s 30,xhci,tablet \
-s 31,lpc \                          =20
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \
vm4 < /dev/null & sleep 2 && vncviewer 0:4


These are the NTFS disks that I wou= ld like to see inside the Windows 11 guest os :


-s 2,virtio-blk,/dev/da4p2 \
-s 3,virtio-blk,/dev/da2p1 \


=3D>         34  19532873661  da4  GPT  (9.1T)
           34        32734    1  ms-reserved  (16M)
32768  19532838912    2  ms-basic-data  (9.1T)
19532871680         2015       - free -  (1.0M)


=3D>         34  23437705149  da2  GPT  (11T)
           34         2014       - free -  (1.0M)
2048  23437701120    1  ms-basic-data  (11T)
23437703168         2015       - free -  (1.0M)


As you can see I've used the vi= rtio-blk driver,so inside=20 the Windows 11 VM I've installed the latest version of the virtio=20 drivers. The disks attached are 0 byte large,so they aren't recognized= =20 by Windows 11. Is this a bug or what ? They are USB 3.0 disks. You can=20 give a look at the images below if u want to have a better understanding :


https://for= ums.freebsd.org/attachments/1-jpg.13311/
https://forums.freebsd.org/attachments/2-jpg.13312/=


I've tried also like this :


bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w =
-H -A \
-s 0,hostbridge \
-s 1,ahci-hd,/dev/nvd0 \
-s 2,virtio-blk,/dev/da4 \
-s 3,virtio-blk,/dev/da2 \
-s 8,virtio-net,tap4 \
-s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \
-s 29,fbuf,tcp=3D[0.0.0.0:5904](http://0.0.0.0:5904/),w=3D1440,h=3D900 \
-s 30,xhci,tablet \
-s 31,lpc \                          =20
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \
vm4 < /dev/null & sleep 2 && vncviewer 0:4


and I get this error :


Assertion = failed: (n >=3D 2 && n <=3D=20 BLOCKIF_IOV_MAX + 2), function pci_vtblk_proc, file=20 /usr/src/usr.sbin/bhyve/pci_virtio_block.c, line 324.


I have tried also with :


-s 2,virtio-scsi,/dev/da4p2 \
-s 3,virtio-scsi,/dev/da2p1 \


and I have also installed the virti= o-scsi driver on=20 Windows 11,that has been accepted by windows,but the disks aren't=20 recognized :


https://forums.freebsd.org/attachments/screenshot_2022-03= -13_11-23-54-jpg.13321/
https://forums.freebsd= .org/attachments/screenshot_2022-03-13_11-10-16-jpg.13320/


Finally I tried by virtualizing ubu= ntu with bhyve using=20 the virtio-scsi driver on ubuntu as guest os and it worked,so there is a bug only on the drivers for windows. You can see what happens with=20 ubuntu going on the freebsd forum at this address :


=

https://forums.FreeBSD.org/threads/usb-3-0= -disks-not-recognized-by-windows-if-passed-through-as-slots.84402/post-5599= 24


I have also opened a bug = request below,but no one replied until now.



--
Mario.
--0000000000009ac17405db09a3ae-- From nobody Fri Mar 25 12:14:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0291D1A38EF9 for ; Fri, 25 Mar 2022 12:14:57 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ1Hg6RgNz4lpx for ; Fri, 25 Mar 2022 12:14:55 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: (Authenticated sender: ganael.laplanche@martymac.org) by mail.gandi.net (Postfix) with ESMTPSA id 3CEE5FF808; Fri, 25 Mar 2022 12:14:45 +0000 (UTC) From: Ganael Laplanche To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Our /bin/sh and process group IDs Date: Fri, 25 Mar 2022 13:14:43 +0100 Message-ID: <3524693.ZKXgePsUey@dmc12.centralesupelec.fr> In-Reply-To: References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4KQ1Hg6RgNz4lpx X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ganael.laplanche@martymac.org designates 2001:4b98:dc4:8::229 as permitted sender) smtp.mailfrom=ganael.laplanche@martymac.org X-Spamd-Result: default: False [-0.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.48)[-0.483]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[martymac.org]; NEURAL_SPAM_SHORT(0.92)[0.925]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; CTE_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::229:from] X-ThisMailContainsUnwantedMimeParts: N On Friday, March 25, 2022 12:24:08 PM CET Eugene Grosbein wrote: Hello Eugene, Thanks for your anwser. > Try "set -m" beforehand. It is set, from within test_func () : set -m { /bin/sh -c 'sleep 1' ; } & I would expect the line : { /bin/sh -c 'sleep 1' ; } & to be forked in a new process group, which is not the case. -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From nobody Fri Mar 25 12:55:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CBD311A435EF for ; Fri, 25 Mar 2022 12:55:33 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ2BY5RJNz4vMt for ; Fri, 25 Mar 2022 12:55:33 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648212933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld/kBh3oocoPfrW7B3rHXs4WsDF6OK307CxGfg59ojs=; b=taH0wxG/GcTPxS/+WPjxeHBNN1jS1QxDce09InRUxkgdrajUzXrjbOA/OEARTJ5ZYNwcOY UlTQn3Ao5MMYsV7CgFVFH4gCxNicbMN7v5JagHEunw67GG4XYHBEMCU+xELd1s8X8MUJMQ 5o4fsaBceekSTJ+SStXUxTrM5rVRAGb4y2Xx4MnGKm+CP/NxUEcOEMBY02/aa/CQCpu0VA W9ORoz4ZL2sdMOPuBWdQeO7vPrmkylDhXL3DLxWt1tTZxM7wSvCk1zHxQ7mLg1MabxEoSu ceZprs9jravQHrIYc5Yoc17NeNzVJfpDTc6k4xIfKpVXc6y5tQH1005KqfkPPQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 9476BCFB9 for ; Fri, 25 Mar 2022 12:55:33 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 96A532F6E6 for ; Fri, 25 Mar 2022 12:55:32 +0000 (GMT) Message-ID: <69e08ba5-210d-eaab-2ba0-170360b307d4@FreeBSD.org> Date: Fri, 25 Mar 2022 12:55:31 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Getting the current thread's stack base / size on FreeBSD Content-Language: en-GB To: freebsd-hackers@freebsd.org References: From: David Chisnall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648212933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld/kBh3oocoPfrW7B3rHXs4WsDF6OK307CxGfg59ojs=; b=LUDePOb4pR3s+zWShsoZv06Ym8aG13Xez6YBKG4waSnv4Ehnav3DXCuPNJ6UIy+zwdsQZ4 7SLRmTYT6kF6+8eD/20AZzf6gPeMsfa/cA4FhysoIrvjoGzt+Bp3gwooVlk2JH3gkTbPSf 7VJLQFweVbR3N3g+O2Azsw5Bru9AYoPwODsasmHyCU/47LWnF9kECuRcwVbVFqVVDtPewA miZc0NMZ0W/VCgyIdQ2LE8eil5D7UvHoXhRenXWEtOCovrtloNcaoiDZ9KqEsnB3ou06Uk gbj2aj3QSlrjTyX0onLwg1jPnRRNQCQhJ//rqbKubb1XBERBZL3JyVr3cIT96w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648212933; a=rsa-sha256; cv=none; b=R4q/zP9d1SgxveHTP1boHtqynsfojmLEZp2qSWIfzROMImEMBX4LwleXkSHsgYcxEWGrdo w4aB60RUw2JHPPJR3/HY0ZEUhhrmTZ1CzVKTdk1u1bVqLP8mItEgtg3BfbnoC43nGXxwxT 2YhSW8DU7NyjVzh96Dmye3kdoNKdq+LsXRKYM6gVRrp/Mfj6mYLYo+QwxIYg+qNIShylvs d2Mixh7K1+9ff7haoX9oWLHD3Och2INHszAAikmrtqTwUOWUGnw/79S6e/oQOW45QtVjpJ KdATwXNS++fIvhghjSNkner+PX3KUPRqPRUrCwTCkgx4ZCv0GKpB82kGoFajxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Never mind, libthr also exposes pthread_attr_get_np. I missed it because it has the same semantics as the glibc version but a slightly different spelling. David On 25/03/2022 11:41, David Chisnall wrote: > > Hi all, > > I'm trying to get the VAVM[1] WebAssembly runtime working on FreeBSD. In > its platform-specific code, they need to find the base and size of the > current stack.  They have code for Linux and macOS, using different > non-standard pthread extensions, but I couldn't see a mechanism for > doing this on FreeBSD.  Is there an API for this? > > Darwin provides a pair of _np APIs for getting these values.  Glibc > provides an API for getting the pthread attributes for the current > thread, which is a bit more general and useful.  Adding this to libthr > would be a fairly simple change, if it doesn't exist already.  Am I > missing an existing mechanism? > > David > > [1] https://wavm.github.io/ > From nobody Fri Mar 25 13:06:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3BDD71A463A0 for ; Fri, 25 Mar 2022 13:07:05 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ2Rr0sb5z3CwP for ; Fri, 25 Mar 2022 13:07:04 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: by mail-ed1-f45.google.com with SMTP id h4so1407048edr.3 for ; Fri, 25 Mar 2022 06:07:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=QWCCq5Scpx8q5I3keFBYXkD0i2Z0+YhRAl7yLSXkGMI=; b=Be734bzSZtnGI1E3pf3YAyXJOKe+GqEpzk5K12G6ErjcwQrSQ4q/Q+dLQl1dhSBxkk 2a4MrfSpbxwkgMPYQ9kYE+lEmh7rqOcsCSQwlUeKy186CrhCYVkUSN6HsauqKXU8sXjj 7ldPxVMzn6K9apYoLhLxBBLdbv/3UxsaBlboHBm8Wc3ej2asXtQjinO6OY0LzKdFdSUy T6nkLtYQlL0LUzM5wZLlW3oHz8CMF4WMVIvD/XR4QDL8UYrTTBZNWTzJTh9h0CEgsffP pdCUCbhoFa0VZSZERRlDlWh7nLyf/JiWNTkqf0cuZJbjtooHVXUepFwPm2z8siZhaXTn hGOg== X-Gm-Message-State: AOAM531+0Lv2YWdXzL9b71axlRmrOuUS8MMd6uOUHzOZa7RZseGeLdUI TFijPHE119HUSBztFLHbIwpZ7c3Oa9zUrMEz X-Google-Smtp-Source: ABdhPJxGuQacBS/sNymbfmOkjWUSBy3/s5fSlAVVBGfj0rw/qu/4OVn7eSDDm/TdsxlLt51O/+421g== X-Received: by 2002:a05:6402:42c6:b0:419:276c:4a64 with SMTP id i6-20020a05640242c600b00419276c4a64mr13004765edc.119.1648213617450; Fri, 25 Mar 2022 06:06:57 -0700 (PDT) Received: from vps.markoturk.info (cpe-109-60-8-3.st3.cable.xnet.hr. [109.60.8.3]) by smtp.gmail.com with ESMTPSA id dm8-20020a170907948800b006dfe5b317d3sm2447403ejc.75.2022.03.25.06.06.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Mar 2022 06:06:56 -0700 (PDT) Date: Fri, 25 Mar 2022 14:06:55 +0100 From: Marko Turk To: freebsd-hackers@freebsd.org Subject: Inactive vs ZFS ARC memory priority Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bXArPL3y0jOtpkLG" Content-Disposition: inline X-Rspamd-Queue-Id: 4KQ2Rr0sb5z3CwP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.85.208.45 is neither permitted nor denied by domain of markoml@markoturk.info) smtp.mailfrom=markoml@markoturk.info X-Spamd-Result: default: False [-5.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[109.60.8.3:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[markoturk.info]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.45:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_TLS_ALL(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.45:from] X-ThisMailContainsUnwantedMimeParts: N --bXArPL3y0jOtpkLG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I have a workstation with 32GB or RAM, running recent 12.3-STABLE. vfs.zfs.arc_max is set to "16G". After a few hours of uptime I get this memory usage: Mem: 327M Active, 3007M Inact, 58M Laundry, 20G Wired, 7986M Free ARC: 15G Total, 1723M MFU, 12G MRU, 9032K Anon, 246M Header, 987M Other 13G Compressed, 31G Uncompressed, 2.44:1 Ratio Swap: 4096M Total, 4096M Free All looks good, ZFS ARC is used almost completely up to arc_max. And it stays like this for days. Then I do a make buildworld & buildkernel. And I get this: Mem: 663M Active, 20G Inact, 879M Laundry, 8560M Wired, 1445M Free ARC: 4351M Total, 984M MFU, 2176M MRU, 14M Anon, 37M Header, 1140M Other 2453M Compressed, 5405M Uncompressed, 2.20:1 Ratio Swap: 4096M Total, 4096M Free A lot of memory is in Inactive, and ARC decreased. I think this is still OK. But what I expect to happen eventually is that ARC will grow again and push old data from Inactive. This never happens. I can leave it for days with a lot of disk activity and nothing changes. Seems like old data in Inactive has higher priority than ARC. Why is that so? Can I improve this somehow? If I do something memory intesive, Inacive will decrease. This works as expected, I get something like this: Mem: 659M Active, 16G Inact, 851M Laundry, 9337M Wired, 4343M Free ARC: 5144M Total, 1207M MFU, 2712M MRU, 7275K Anon, 82M Header, 1135M Other 2885M Compressed, 6647M Uncompressed, 2.30:1 Ratio Swap: 4096M Total, 4096M Free After that the ARC will grow and fill the empty memory. But on it's own it will never push Inactive down. Why is old data in Inactive higher priority than new data in ARC? Regards, Marko --bXArPL3y0jOtpkLG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhGJv+o0FoHlUFxVJ0ArzBirlGugFAmI9vm4ACgkQ0ArzBirl GugvwQ//fVxQFFpUE9fV0xS1GcwB67vveJvslHTl/pfGRUXJP8AiURNNP9x0nRwI howvNB4/yVxnOCYphQPORN+NQP9Y42+/ga7ZLyQMZ4AgmprjWQyQaY0LUWDQ56dA SZSZPevFGVSblL2tyecmC0usWFV7aT3Hyy0NxmShwxs2d+UC1muWK3zRuGeYcrvq QW7vcKUMtpEXKhoU8+8wT5YqueaezadDq44rEdxBSba1sIFEOxZITsAlMqljiOoY R03dOashQ4SROzNKnfnTX054OwDQMBdSROP00Vg4VpNHzcbE9WLxZ+IiPg8da+Ha MQTIjJJB9rhF3Xy3MvEzkb3LqEJsADOMA1iaFPaF+iNGsiH1fAhRy1/4BHzu7U42 ACqs+eYhdEoSqZqW4pHPPEr1IDw/ADfF/zREK1CT+of4vInDOq1DDbsivK4OT/K8 GMlWIwjPvJ2FSm4UYmxsI95Uz/FVdYf/1qILFEwK3ixm2/GXcSzW1V5OfZWvXkyF 073zGFMOmQbevunjHplRwH6cqtunhoY6UAnYVI4vVCTxqABnEIkr2yJQhu5Ia4EY bUtyzcZhvynkOwushG7Q+1EbVtaocCIxivv6GN8rwznT8qf2JrzRW3hYtUp54deA 7wMrwmFrw3qMudViORovtSYkkONWFMrmOY5B3R7Up6bWm1ghFM8= =k1mG -----END PGP SIGNATURE----- --bXArPL3y0jOtpkLG-- From nobody Fri Mar 25 14:27:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BF9B81A48CF6 for ; Fri, 25 Mar 2022 14:27:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQ4DX6F2Bz4jvL for ; Fri, 25 Mar 2022 14:27:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92c.google.com with SMTP id k11so3060865uap.1 for ; Fri, 25 Mar 2022 07:27:24 -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=21MJM0uToIs9YTx2RPRc9bI8y69W/C6Jjq2aPhkiAOQ=; b=CY4LN4Q3g9hw69L4MQWr/deguEdZd/xxcr94ydilXXHSy69zxlvb+5X5RUVFP0QmGn bFT7R8Nz8Cq/yJ2vfcSgef0loFo0ukTNEC0qHkqm5gNKZzQFfJc/g1xvkzPJh7Nb4GUR yppkI2BGvWu3poqXH89FynuQW14cqXsa50bn42PgaG2fBeYFz7DxUxZi4AeJ8rR8T8W7 g3G8FFYWkTM3pUryxnbV5v8xQwQrc6VDYnRI1wyh2ScfVeokkViwC/NxnvFt1XtO7/A+ wZtYZh6llmhadA1lKs+/ucJjQNdkkCphX91u4au9lZ/zmRj1DZoAmj7L7D/nM478DyXR uHmg== 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=21MJM0uToIs9YTx2RPRc9bI8y69W/C6Jjq2aPhkiAOQ=; b=VE63OAximi4y4jMTlTj6ezP3W0cM5svACX+XOfqaiwPfoOoJ4sWpPg4A7jatwDUYAg dVyOzhWbIQ80tXNh8nqr8J2ZzyXTeeDpnQw7mJxmXeCdrrOuHOrc1roXDYtXG+ORvUCY 7jhKpD70KdxBJiLrRoLUqk1eayaxP50VklprXYWkaM2u7QscXkBTscDkW9QWqmW/paA7 r0J6Z1dPlVWX2eLFq+A+yuNFKZevM5zpZPTCZfDBH6kbrR1rajdXPNyHeeI6VSYcYBcD BK6fhCGmdjmT1LmVGxVFNZmBSeLztwQEMyCB+NmfswRGokp8keB0YZs4HCP240cyBUrS e28w== X-Gm-Message-State: AOAM530Ml8RHICfhbkCzkx2T9tMVMXY0Zy3sbrm7dRdNqeCT0kbNk/gT z7/ZTXURNNfzKZzG5z+N/ag8liSzpoDxPvWT4IDfEg4U4vcsBA== X-Google-Smtp-Source: ABdhPJyces/Z41NrP+iswjhI8mLZtk1YBpCydyE5wQTVaTnqQXAoNoPEF/iDMPA03fSvTCde0DEkkyQE9XxiHh4etpc= X-Received: by 2002:ab0:67cf:0:b0:341:257f:ce52 with SMTP id w15-20020ab067cf000000b00341257fce52mr4804907uar.109.1648218444117; Fri, 25 Mar 2022 07:27:24 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <70B211BB-15BA-47A4-8F9C-C833AA8C1EAA@freebsd.org> <202203241519.22OFJ3Mk098649@gndrsh.dnsmgr.net> <71356.1648139436@kaos.jnpr.net> <7773a0c73c77649efaf9f748ee8bb0b4@gundo.com> In-Reply-To: <7773a0c73c77649efaf9f748ee8bb0b4@gundo.com> From: Warner Losh Date: Fri, 25 Mar 2022 08:27:12 -0600 Message-ID: Subject: Re: What's the locale for system files (e.g. /etc/fstab)? To: Pau Amma Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000dfc90105db0bc2bc" X-Rspamd-Queue-Id: 4KQ4DX6F2Bz4jvL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=CY4LN4Q3; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::92c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::92c:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000dfc90105db0bc2bc Content-Type: text/plain; charset="UTF-8" On Fri, Mar 25, 2022, 5:10 AM Pau Amma wrote: > (pruned cc: to just the list) > > On 2022-03-25 04:08, Warner Losh wrote: > > On Thu, Mar 24, 2022 at 2:51 PM Phil Shafer wrote: > > > >> On 24 Mar 2022, at 15:12, Warner Losh wrote: > >> > That is the primary reason for system files always being C.UTF-8... > >> > There is no way to tag it as anything else... and some of these files > >> > are often parsed from a context that can't set the locale, like the > >> > boot loader or the kernel... also, these files have a format that was > >> > defined back in the 7bit ascii time frame. They also don't make use of > >> > the text in a way that isn't literal... > >> > >> Exactly. There's just no way to know in the current setup. And > >> declaring it UTF-8 will break anyone currently using locale-based > >> values. Using the symlink has the value of allowing a simple fix > >> ("sudo > >> ln -s $LANG /etc/locale"). > > > > Except it's not a simple fix. Sure, you can find this value, but > > nothing > > will use it, necessarily. Since there's little value and little need, I > > think it would be more hassle than it's worth absent a much more > > extensive audit. For system wide things like config files, we assume > > C.UTF-8 or the lessor ASCII-7 (or maybe ASCII-8). > > There's no ASCII-8. (If you meant 8859-*, there's 15 or 16, which > essentially means "no".) Assuming ASCII (and therefore 7-bit) went out > of style last millenium. Anything that expects or enforces something > other than Unicode (which for all practical purposes means UTF-8) needs > to be fixed urgently. > Ascii-8 here is just a sloppy shorthand for no multi byte character support. All the parsing routines just look for certain fixed byte separators for sequences of bytes. This will likely never change, but if it does a lot of work to prove correctness needs to happen and all the things that read these files would need to change. UTF-8 works because it mostly avoids encodings that would get in the way of this naive code since the encoding sequences can't have 7bit ascii values in them and all the special characters are 7bit ascii. Warner -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > > --000000000000dfc90105db0bc2bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 25, 2022, 5:10 AM Pau Amma <pauamma@gund= o.com> wrote:
(pruned cc: to= just the list)

On 2022-03-25 04:08, Warner Losh wrote:
> On Thu, Mar 24, 2022 at 2:51 PM Phil Shafer <phil@juniper.= net> wrote:
>
>> On 24 Mar 2022, at 15:12, Warner Losh wrote:
>> > That is the primary reason for system files always being C.UT= F-8...
>> > There is no way to tag it as anything else... and some of the= se files
>> > are often parsed from a context that can't set the locale= , like the
>> > boot loader or the kernel... also, these files have a format = that was
>> > defined back in the 7bit ascii time frame. They also don'= t make use of
>> > the text in a way that isn't literal...
>>
>> Exactly.=C2=A0 There's just no way to know in the current setu= p.=C2=A0 And
>> declaring it UTF-8 will break anyone currently using locale-based<= br> >> values.=C2=A0 Using the symlink has the value of allowing a simple= fix
>> ("sudo
>> ln -s $LANG /etc/locale").
>
> Except it's not a simple fix. Sure, you can find this value, but <= br> > nothing
> will use it, necessarily. Since there's little value and little ne= ed, I
> think it would be more hassle than it's worth absent a much more > extensive audit. For system wide things like config files, we assume > C.UTF-8 or the lessor ASCII-7 (or maybe ASCII-8).

There's no ASCII-8. (If you meant 8859-*, there's 15 or 16, which <= br> essentially means "no".) Assuming ASCII (and therefore 7-bit) wen= t out
of style last millenium. Anything that expects or enforces something
other than Unicode (which for all practical purposes means UTF-8) needs to be fixed urgently.

Ascii-8 here is just a sloppy shorthand for no multi b= yte character support. All the parsing routines just look for certain fixed= byte separators for sequences of bytes. This will likely never change, but= if it does a lot of work to prove correctness needs to happen and all the = things that read these files would need to change.
<= br>
UTF-8 works because it mostly avoids encodings t= hat would get in the way of this naive code since the encoding sequences ca= n't have 7bit ascii values in them and all the special characters are 7= bit ascii.

Warner
<= div dir=3D"auto">
--
#BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters
#StandWithUkrainians
English: he/him/his (singular they/them/their/theirs OK)
French: il/le/lui (iel/iel and ielle/ielle OK)
Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)

--000000000000dfc90105db0bc2bc-- From nobody Fri Mar 25 19:13:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AC6A1A2D617 for ; Fri, 25 Mar 2022 19:13:32 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQBZh09c7z4cwP; Fri, 25 Mar 2022 19:13:32 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648235612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wG2KOv6btFH4zb5ApHeXMzZdYNiLVNRIGBizc1xSI84=; b=TOEF437MNTGar47yHsWS4PQB0yEcJTPRSEc24abWRqUOxp23YAFYu6OpJMDDMt8px46Lcy UO5ERyW5tmeDGEXW/ffuMnlIsRMYTs0WwImUu5k83o9Bq+r37XJam4H+FpuVpZRIV4b0Y3 ZtFXlzxfACSEFyo/hJ1oGBLlKXnYxF9MG6Q/KmdYgxwa4SMpUnLz22ttWq1vz+LqyhxBXV qi2ea23R7ercNdYdomPp9+/DSRDn9BKR5IutnqQ31LT5In4Q4n8/gNGH1AI4Pp8o6ubEvn RshnDaMFgU/+dSZ5QR9ESsmn9TZVbM2S+LuIBG3bV1FLocdfpUvhNA6GArLenA== Received: from mail.xzibition.com (unknown [127.0.1.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 did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id C6A91106D7; Fri, 25 Mar 2022 19:13:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id CEA4D2D961; Fri, 25 Mar 2022 12:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id vpJEHxAOEH4C; Fri, 25 Mar 2022 12:13:28 -0700 (PDT) Message-ID: <243ebc92-26a1-e5e7-67fe-1477ed6b5f7a@FreeBSD.org> DKIM-Filter: OpenDKIM Filter v2.10.3 mail.xzibition.com 0B1C02D959 Date: Fri, 25 Mar 2022 12:13:27 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Ganael Laplanche , freebsd-hackers@freebsd.org References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> From: Bryan Drewery Organization: FreeBSD Subject: Re: Our /bin/sh and process group IDs In-Reply-To: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648235612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wG2KOv6btFH4zb5ApHeXMzZdYNiLVNRIGBizc1xSI84=; b=RG3Gc51+u36a9kAT3xeObFSWLf53+P9eboA/kBpv8SvtCPe7X6ChAnWGXAt+nK9dorfgdJ qJpgcjgYNWBSnRtNijWImAzciFMjkMfz3xaPnp0Hz+pJFTAYiKB+DWdIHx/mTAAJl+zR5G kViOJ63sNMgm0LavfXzwGLCXSdzMA+mmms+GohdLcZWmIf156LBp7s2bVifQkRzT/PG5/i ScfG+cCKLEqWbTCz9tepACbfI35fOZyKi4GaMeSKWQi97I183OQ7WBt8jBHgCOoQCm2Znr /9Cmg+MHqyxVC+4IvfcvR6YtH7Z2I4cmvER3Cdq7DnuG8Miy40m2wYj+qGqhBw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648235612; a=rsa-sha256; cv=none; b=gsuXrJb/Qnlhtv9rkyBrO2oBJvV4mSKJ0qBRJ6l9KrurWV0Yo29VIC6QdRyH+ORW3mL8oP gi8QV9rQNXJfpIM+Hq3iLQQ9KGafym9CA9ctJJ1zfQcmtCyT+JyPWsVuPif7rGWV69V0sz sTDqa8ayv5NcElBaFhmXuEykFDA1oVoJi2sGRedmxR0Blqmy7d+XYDeoacO431vUcX2t7U Crv5bLWuVNJyAgrWQHvEtb7VU0QxeaY6pCdSITgp1YmASCUdl9R1obHBhXb7QhpkxpDFtH ph4gs84WDZvUlp9JGovcKqilTOXHDd2fJDc/eTlQU1wGgIcyAc/BkLuyoxz2QQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 3/24/2022 10:13 AM, Ganael Laplanche wrote: > Hello, > > I am trying to fork a sub-shell with its own process group id through a > function that must itself be executed in the background. > > It should work with the following code: > > #---- > #!/bin/sh > > # Parent shell IDs > ps -o pid,ppid,pgid,comm -p $$ > > test_func () { >   set -m >   { /bin/sh -c 'sleep 1' ; } & >   # Forked shell IDs (pgid should be different from parent, >   # but it is not) >   ps -o pid,ppid,pgid,comm -p $! set -m needs to be set from the parent process, not child. In this example test_func is a child *and* the sleep is a child which is also very racy. Here's a pattern I use that works: #! /bin/sh ps -o pid,ppid,pgid,comm -p $$ test_func() { mypid=$(sh -c 'echo $PPID') ps -o pid,ppid,pgid,comm -p $mypid } spawn() { local - # cause -m to revert back on return set -m "$@" & } spawn test_func ps -o pid,ppid,pgid,comm -p $! > } > > # The following does not work: > test_func & > # ...but it works when function is not executed in the background: > #test_func > > sleep 2 > exit 0 > #---- > > Unfortunately, with our /bin/sh, the sleeping process gets the *same* > process group ID as its parent. > > I've tested several shell implementations; it works with : > > /usr/local/bin/bash --posix 'test.sh'     # from bash-5.1.16 > /usr/local/bin/zsh --emulate sh 'test.sh' # from zsh-5.8.1 > /usr/local/bin/ksh93 'test.sh'            # from ksh93-devel-2020.06.30 > /usr/local/bin/mksh 'test.sh'             # from mksh-59c > /usr/local/bin/ksh 'test.sh'              # from pdksh-5.2.14p2_6 > > but not with : > > /bin/sh 'test.sh'                         # on 13.0-RELEASE-p8 > /usr/local/bin/dash 'test.sh'             # from dash-0.5.11.5 > > am I missing something ? > > Any help welcome :) > > Best regards, > -- Bryan Drewery From nobody Sat Mar 26 14:52:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 766891A38360 for ; Sat, 26 Mar 2022 14:52:51 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQhlQ1b8Yz3l7X; Sat, 26 Mar 2022 14:52:50 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: (Authenticated sender: ganael.laplanche@martymac.org) by mail.gandi.net (Postfix) with ESMTPSA id C764CFF805; Sat, 26 Mar 2022 14:52:40 +0000 (UTC) Message-ID: <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> Date: Sat, 26 Mar 2022 15:52:40 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Our /bin/sh and process group IDs Content-Language: en-US To: Bryan Drewery , freebsd-hackers@freebsd.org References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> <243ebc92-26a1-e5e7-67fe-1477ed6b5f7a@FreeBSD.org> From: Ganael Laplanche In-Reply-To: <243ebc92-26a1-e5e7-67fe-1477ed6b5f7a@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KQhlQ1b8Yz3l7X X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ganael.laplanche@martymac.org designates 2001:4b98:dc4:8::229 as permitted sender) smtp.mailfrom=ganael.laplanche@martymac.org X-Spamd-Result: default: False [-1.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[martymac.org]; NEURAL_HAM_LONG(-0.93)[-0.933]; NEURAL_SPAM_SHORT(0.84)[0.838]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::229:from] X-ThisMailContainsUnwantedMimeParts: N Le 25/03/2022 Ă  20:13, Bryan Drewery a ĂŠcrit : Hello Bryan, > set -m needs to be set from the parent process, not child. Thanks for those clarifications. Is that something required by POSIX (I could not find any documentation about that) ? Or is it a limitation (or bug) of our implementation ? Other shells -mostly- do not behave that way (see my original post). > In this example test_func is a child *and* the sleep is a child which is also > very racy. Here's a pattern I use that works: > [...] Unfortunately, in my case, spawn would have to be called from a sub-process already forked (from a background function, executed as a child process) ; so that wouldn't work either. Anyway, thanks for the hint :) Cheers, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From nobody Sat Mar 26 19:39:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 151FD1A31D7F for ; Sat, 26 Mar 2022 19:40:01 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mail02.stack.nl (scw01.stack.nl [51.15.111.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "ecc.stack.nl", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQq6l2c8qz3FDF; Sat, 26 Mar 2022 19:39:59 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail02.stack.nl (Postfix) with ESMTP id B63F01E03CA; Sat, 26 Mar 2022 19:39:52 +0000 (UTC) Received: from mail02.stack.nl ([127.0.0.1]) by localhost (mail02.stack.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJPWAZp4sps7; Sat, 26 Mar 2022 19:39:50 +0000 (UTC) Received: from blade.stack.nl (blade.stack.nl [192.168.121.130]) by mail02.stack.nl (Postfix) with ESMTP id E67E71E03C5; Sat, 26 Mar 2022 19:39:50 +0000 (UTC) Received: by blade.stack.nl (Postfix, from userid 1677) id D6278237C50; Sat, 26 Mar 2022 20:39:50 +0100 (CET) Date: Sat, 26 Mar 2022 20:39:50 +0100 From: Jilles Tjoelker To: Ganael Laplanche Cc: Bryan Drewery , freebsd-hackers@freebsd.org Subject: Re: Our /bin/sh and process group IDs Message-ID: <20220326193950.GA1667@stack.nl> References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> <243ebc92-26a1-e5e7-67fe-1477ed6b5f7a@FreeBSD.org> <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4KQq6l2c8qz3FDF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jilles@stack.nl designates 51.15.111.152 as permitted sender) smtp.mailfrom=jilles@stack.nl X-Spamd-Result: default: False [0.21 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jilles]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:51.15.111.152]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[stack.nl]; NEURAL_HAM_LONG(-0.99)[-0.989]; NEURAL_SPAM_MEDIUM(0.89)[0.887]; NEURAL_SPAM_SHORT(0.62)[0.616]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:51.15.0.0/17, country:FR]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Mar 26, 2022 at 03:52:40PM +0100, Ganael Laplanche wrote: > Le 25/03/2022 ŕ 20:13, Bryan Drewery a écrit : > Hello Bryan, > > set -m needs to be set from the parent process, not child. > Thanks for those clarifications. > Is that something required by POSIX (I could not find any documentation > about that) ? Or is it a limitation (or bug) of our implementation ? Other > shells -mostly- do not behave that way (see my original post). This appears to be a gray area, and the exact behaviour varies across shells. For example, with stty tostop in effect, sh -c '(set -m; echo "echo from background" & wait "$!"); echo "wait returns $?"' has a variety of behaviours: * with FreeBSD sh, dash and also ksh93, it prints both lines * with mksh, it only prints the "wait returns 0" line * with bash, it hangs (as expected with a new process group) I think it is definitely undesirable for set -m to have an effect across multiple levels of subshells by default, since it makes the innermost processes immediately escape from the outer process group supervision again. As it is now, FreeBSD sh has implemented this by ignoring set -m from a process other than the first process (so for example sh -c '(set -m; echo "echo from background" & wait "$!"; echo "wait returns $?")' still hangs with tostop in effect, since this particular subshell is implemented without creating a new process), but perhaps this could be extended a bit more. > > In this example test_func is a child *and* the sleep is a child which > > is also very racy. Here's a pattern I use that works: > > [...] > Unfortunately, in my case, spawn would have to be called from a sub-process > already forked (from a background function, executed as a child process) ; > so that wouldn't work either. Anyway, thanks for the hint :) A second workaround is to start a new instance of sh. -- Jilles Tjoelker From nobody Sat Mar 26 20:43:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8A8F61A4250E for ; Sat, 26 Mar 2022 20:43:10 +0000 (UTC) (envelope-from tux2bsd@protonmail.com) Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch [185.70.40.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KQrWd3sWrz3R78 for ; Sat, 26 Mar 2022 20:43:09 +0000 (UTC) (envelope-from tux2bsd@protonmail.com) Date: Sat, 26 Mar 2022 20:43:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1648327387; bh=Dlq70TH8e4nAou0CTmNW+U39UPJPre1x/5upXFsi/GM=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=Lk5JkUiQyR0oBBL1wn3ZNU3wX5IyqUxSCGXB6pzujWdUOMoA/kM/thr+KrpT+8G1s ogHqXZXan9hCDrsPfckEiPHxs8xlGycjL20dlmb8eonw2+r0sCsPJGhUdFASGzFOtj 7pzeQLKkk7rXJf5kFQde7adyMhc6lvSCgn2vxrEpfrPs5e4+hotA8jfkv0dZJlTWCr bjBNwUpuVwkuWmJeQrPmyylratnIl3/hiama8RQtcLG50UBaiUNWAaNNnlmcVGJvOJ nMZdKJqld/IzY0Xx2joku2Jztnx0ZktVaBF+ubDjwoCHk4XNt9FRAq7IjSUu6UGtlv 95qqISwf/EAlA== To: "freebsd-hackers@freebsd.org" From: tux2bsd Reply-To: tux2bsd Subject: Re: Call for Foundation-supported Project Ideas Message-ID: In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KQrWd3sWrz3R78 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail header.b=Lk5JkUiQ; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (mx1.freebsd.org: domain of tux2bsd@protonmail.com designates 185.70.40.138 as permitted sender) smtp.mailfrom=tux2bsd@protonmail.com X-Spamd-Result: default: False [-2.12 / 15.00]; HAS_REPLYTO(0.00)[tux2bsd@protonmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[protonmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[protonmail.com]; NEURAL_HAM_LONG(-0.98)[-0.976]; NEURAL_SPAM_MEDIUM(0.85)[0.854]; RCPT_COUNT_ONE(0.00)[1]; RWL_MAILSPIKE_EXCELLENT(0.00)[185.70.40.138:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; DKIM_TRACE(0.00)[protonmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tuesday, November 30th, 2021 at 8:35 PM, tux2bsd wrote: > Some help to fix freebsd-update , a very longstanding poor performance pr= oblem I took the time to investigate and provide an attempt to fix, > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258863 This was considered and listed, thank you. > https://wiki.freebsd.org/2021FoundationCFI , freebsd-update improvemen= ts > https://lists.freebsd.org/archives/freebsd-hackers/2021-November/0005= 52.html After a recent epiphany I implemented the improvement a different way. I've written a script that improves the efficiency of updating FreeBSD, her= e it is: https://github.com/tux2bsd/freebsd-update-probe This satisfies my goal, I hope a few other people find it useful. Thanks tux2bsd From nobody Mon Mar 28 09:37:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 694291A490AD for ; Mon, 28 Mar 2022 09:37:35 +0000 (UTC) (envelope-from kfv@kfv.io) Received: from mail.kfv.io (mail.kfv.io [95.217.128.176]) (using TLSv1.3 with cipher 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 "kfv.io", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRnfj6QYCz3H2P for ; Mon, 28 Mar 2022 09:37:33 +0000 (UTC) (envelope-from kfv@kfv.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kfv.io; s=dkim; t=1648460245; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=EiDBskmZq2xRQ4xqsjCpMWciMB0tFLI1WvWtraM3aOE=; b=Gyi8rXtqCZL7MnUmFP9EPRxY18AO6mffy9mC/EOhhSj1M2y3auJdvCEhPdIdkNf9Nlw7T3 i6dbgCNeygL/j/EoFE9FrSBimBuCYOpvWFi1FHzF22/+pnxqaSQLjQktSnxsb+IZM/Lh4Z /JzgdS2cNHfaHbrBLSZnNelmJopKkFrFEm8Rt682i7hTK0BlJOouD8Wkx5DE/MGA4ts407 Qjfmc9S+Hpg52qUOsKaOeJspj24gBePLyAPnv2Es+42OxY+Nem1SfrzntaJRaznrwyYsnd s/ZlDDdS0OiSZpQbhSK7yDryJeIaD5IWSgaVQxTO3AJ/mNjJRh3OEr7VDVZ7Ww== Received: from x1 (46.30.188.148.static.quadranet.com [46.30.188.148]) by srv.kfv.io (OpenSMTPD) with ESMTPSA id 8539c895 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 28 Mar 2022 09:37:25 +0000 (UTC) Date: Mon, 28 Mar 2022 09:37:22 +0000 From: Faraz Vahedi To: freebsd-hackers@FreeBSD.org Subject: poudriere-image(8) and the required /usr/freebsd-dist files for installation Message-ID: <20220328093722.a6rgj4hqtspphxz7@x1> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wlulo2e6nip3qfb7" Content-Disposition: inline X-Rspamd-Queue-Id: 4KRnfj6QYCz3H2P X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kfv.io header.s=dkim header.b=Gyi8rXtq; dmarc=pass (policy=reject) header.from=kfv.io; spf=pass (mx1.freebsd.org: domain of kfv@kfv.io designates 95.217.128.176 as permitted sender) smtp.mailfrom=kfv@kfv.io X-Spamd-Result: default: False [-5.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[kfv.io:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.217.128.176]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[kfv.io:+]; DMARC_POLICY_ALLOW(-0.50)[kfv.io,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --wlulo2e6nip3qfb7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Greetings hackers, I have heard a lot about the poudriere-image(8), and it seems to be widely used despite maturity. I gave it a try, and it indeed works fantastically. But there are a few things I could not yet find a proper way to resolve. The most important one is that the final image does not contain the required /usr/freebsd-dist files, and therefore it either should fetch them or fails to proceed with the installation. How would you handle it when the ``packagelist'' is provided and you cannot fetch and overlay the files from upstream? I appreciate any help. Cheers. Respectfully, Faraz --wlulo2e6nip3qfb7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEER72OR2ke+5+zBDNGxovV64RZlvEFAmJBgdEACgkQxovV64RZ lvFJ4wf9EsAyLt8yINSB+5IwL/vtduqyNZ8HS9HHpdUlivRKmzprmIpgpF4Ag5/Q lp3CEzg4gDyr+m9XKNG0wWrwRW1CzEBmDnoM/hcbnmrGx9kFWmkb+7hmRlT6kyed KggD51qIipyFaRrWUzjwLhm9+hxofLwebymEw+5cG6Ofqog4jI1yb2NgKtCMt+Pq fpav0cbV/pcvYV2ubPl8AvopJ2iuvpgSOypOOZ9Lam6hERx8SdKQuNorO9egwHrr xpS74unj4Hl9N0fzH8z/suRWcRRnLZWlhOrE3yysMLD5kAxiCqeZt2wYF+wLQ7K/ KiArioD5j59kyreyU+q1qbdvW+6CoA== =Iwgu -----END PGP SIGNATURE----- --wlulo2e6nip3qfb7-- From nobody Mon Mar 28 09:37:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 839511A49263 for ; Mon, 28 Mar 2022 09:37:53 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRng469rGz3HJf for ; Mon, 28 Mar 2022 09:37:52 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qt1-x834.google.com with SMTP id s11so11810155qtc.3 for ; Mon, 28 Mar 2022 02:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:from:to :subject:content-transfer-encoding; bh=skCZIRa/zevGz86UhXGS6sOQEawH1dOuJfA8ex0M+nY=; b=ox5ff/cAE2NI8O15mQ9vZZRVbX3mQo3+muliL1E1nBUqxl9WdzARl3ES5u99RMXkye w79U/8BG20MlrJFv9CLWV4Pz9kRw2N1cim9ArsDrJnTHyicj9vZmsKSR9bVGfiQWhW+M ScnFspLzvZFqHJnVMvs2bWD4IWnB8PlGc3eUDLbWLbUh1uZLLj+JGMtv7izgAOMuo+rS BFE7J+AmbWE1zaUloezstfrVFFjISoxOrIN/3QN2vvYi0pPDHTsL04g6JSTiSQSf9chr Yxlgh3QSK58XRH/Z8loqLESWfu7RFJOE5hxxLwN2/0jWFl+ZQo/qNwxijsfjJ2S3PHAa afrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:from:to:subject:content-transfer-encoding; bh=skCZIRa/zevGz86UhXGS6sOQEawH1dOuJfA8ex0M+nY=; b=FIULg9IGHYsVGv3pZuSdCymw9F44poHcat4sp3MLW29sbomRt+ka9nqXNuLBRvhT9U UFZpiUUZfJRPFDVRXeFZ+AGkN+R3zoOivCD5dy+nMQwAJPAzK9SXfoeob6+8OvS2FpCd 9IALVmD9+stzlFr/w01Pso6OMzlN1xs6DShyFvYJRp6AsMwexkdCLptIhEX/o32arupo JNPXLunhGuIdC6Okf+73uUOQbTSikG9yB7IPbbARA826B+Lw5TzZos5DQb4tWMgh6/ya QawZE1b158rbAZsphukcVpso3t6WO1oJqpJET7rTOEDfFh+Rv7NClxTOCoAiDHkqZ7JI yZSw== X-Gm-Message-State: AOAM530OGEsAZ2Rnhq+m0U/MivzHRd6ty5cCXbrJ7kd3qgkK+UyJkouu I1ZSDryJsB/rmzdt+b9r6M3Qwshgy4U= X-Google-Smtp-Source: ABdhPJy+YXA6RjIdtUtrh7shSTtkHXnHP4vh05RrM+IRll0yldHGhZKgf2YD1+bHVFysVj+Ox9WcBQ== X-Received: by 2002:ac8:5a46:0:b0:2e2:2edd:374 with SMTP id o6-20020ac85a46000000b002e22edd0374mr20441764qta.295.1648460265997; Mon, 28 Mar 2022 02:37:45 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id f17-20020ac87f11000000b002e1e831366asm12221078qtk.77.2022.03.28.02.37.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Mar 2022 02:37:45 -0700 (PDT) Message-ID: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> Date: Mon, 28 Mar 2022 05:37:44 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Mathieu To: freebsd-hackers@FreeBSD.org Subject: curtain: WIP sandboxing mechanism with pledge()/unveil() support Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KRng469rGz3HJf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ox5ff/cA"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::834 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::834:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello list.  Since a while I've been working on and off on a pledge()/unveil() implementation for FreeBSD.  I also wanted it to be able to sandbox arbitrary programs that might not expect it with no (or very minor) modifications.  So I just kept adding to it until it could do that well enough.  I'm still working on it, and there are some known issues and some things I'm not sure are done correctly, but overall it's in a very functional state now. It can run unmodified most utilities and desktop apps (though dbus/dconf/etc are trouble), server daemons, buildworld and whole shell/desktop sessions sandboxed. https://github.com/Math2/freebsd-pledge https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md It can be broken up in 4 parts: 1) A MAC module that implements most of the functionality.  2) The userland library, sandboxing utility, configs and tests.  3) Various kernel changes needed to support it (including new MAC handlers and extended syscall filtering).  4) Small changes/fixes to the base userland (things like adding reporting to ps and modifying some utilities to use $TMPDIR so that they can be properly sandboxed).  So 1) and 2) could be in a port.  And I tried to minimize 3) and 4) as much as possible. I noted some problems/limitations in the CURTAIN-ISSUES file.  At this point I'm mostly wondering about the general design being acceptable for merging eventually.  Because most of this could be part of a port, but not all of it.  And the way that it deals with filesystem access restrictions in particular is kludgy.  So any feedback/testing welcome. It still lacks documentation (in part because I'm not sure of what could still change) so I'm going to give an overview of it here and show some examples and that's going to be the documentation for now.  And I'll describe the kernel changes that it needed.  So that's going to be a bit of a long email. What it can do: ~~~~~~~~~~~~~~~ It can restrict syscalls and various abilities (by categories that were based on OpenBSD's pledge promises), ioctls, sysctls, socket options/address families, priv(9) privileges, and filesystem access by path.  It can be used at the same time as jails and Capsicum (their restrictions are also enforced on top of it). It can be used in a nested manner.  A program that inherits sandbox restrictions can do its own internal sandboxing or sandbox programs that it run (which can then do the same, etc).  The permissions of new sandboxes are always a subset of the inherited sandbox. Certain kernel operations are protected by "barriers" which only allow a sandboxed process to operate on kernel objects that were created by itself or a descendant sandbox.  There are barriers for inspecting/signaling/debugging processes, POSIX/SysV IPC objects, PTYs, etc.  Barriers have their own hierarchy which can diverge from the process hierarchy. Restrictions can be specified in configuration files and can be associated with named "tags".  Tags are assumed to match application names, they're prefixed with "_" when they don't (just the convention I've been using so far).  Enabling a tag may cause other tags to be enabled depending on configurations.  Permissions associated with different tags are merged in a purely additive manner.  Configurations can be spread in multiple files and directories (/usr/local/etc/curtain.{conf,d} can be used for packages, ~/.curtain.{conf,d} for user customizations).  It'll check the .d directories for files named after the enabled tags. Usage examples: ~~~~~~~~~~~~~~~ curtain(1) is the wrapper utility to sandbox arbitrary programs. Default permissions are in /etc/defaults/curtain.conf and /etc/curtain.conf. Here a bunch of examples.  A bit random, but they demonstrate a lot of the functionality. $ curtain id Not very exciting, but it works.  The default permissions don't give it access to the user DB so it only shows numeric IDs.  It can be given access with the "_pwddb" tag: $ curtain -t _pwddb id It's possible to nest sandboxes, but it needs the "curtain" tag because the curtain config files are not unveiled by default (they could be though, maybe they should be...). Here, id cannot read the user DB because the outer sandbox doesn't allow it: $ curtain -t curtain curtain -t _pwddb id But this way it can: $ curtain -t curtain -t _pwddb curtain -t _pwddb id Starts a sandboxed shell session with access to ~/work in a clean environment: $ mkdir -p ~/work && curtain -p ~/work:rwx -S You'll probably miss your dotfiles though.  If you browse around you'll see what paths get unveiled by default. If you try to list processes: $ curtain ps -ax You'll just see the ps process itself.  It can be allowed to see processes outside of it like that: $ curtain -d ability-pass:ps ps -ax But it will not be allowed to signal, reprioritize or debug them (there are other "abilities" for that).  The "-pass" means to allow the ability in a "passthrough" manner (beyond the sandbox's barrier).  Visibility could also be blocked at an outer sandbox's barrier, like so: $ curtain -t curtain curtain -d ability-pass:ps ps -ax Give read-only access to the current directory and list files: $ curtain -p . ls If you have $CLICOLOR set, it may look less colorful than usual. curtain(1) is a bit paranoid and will filter out most control characters written to the TTY by default (and set $TERM to "dumb").  They can be let through with -R: $ curtain -R -p . ls And -T can be used to stop it from doing PTY wrapping altogether and give the program direct access to the TTY (which is less secure, but there are ioctl restrictions). Per-path permissions can be specified after a ":".  More specific paths override the permissions of less specific paths. $ curtain -p .:rw -p ./secret: -p ./dev:rwx -p ./data:r ... Then those paths would have those permissions:     ./:rw     ./123:rw     ./secret:     ./dev:rwx     ./dev/123:rwx     ./data:r     ./data/123:r As an example of how nested sandboxing is handled, if you were then to do this within this sandbox (don't forget to give it the "curtain" tag): $ curtain -p .:r -p ./dev:rx -p ./data:rw ... Then the permissions would end up being:     ./:r     ./123:r     ./secret:     ./dev:rx     ./dev/123:rx     ./data:r     ./data/123:r root processes can be sandboxed too.  Some privileges are allowed by default (which is similar to the set of privileges allowed by jails), but most are denied.  As are accesses to most /dev and /etc files.  For example, tcpdump will not be able to use bpf(4): # curtain tcpdump But there's a tag for that: # curtain -t _bpf tcpdump Something else that won't work: $ curtain node -e 'console.log(2+2)' It wants to do a PROT_EXEC mprotect(2) which is not allowed by default.  By default, PROT_EXEC is only allowed when mmap(2)'ing files that are unveiled for execution. $ curtain -d ability:prot_exec node -e 'console.log(2+2)' Just what is allowed by default?  Well it's kind of arbitrary and messy and there are 10 levels of it. curtain(1) uses a 10-levels "permissions tower" usable with options -0 to -9 (which enable tags "_level0" to "_level9"). These are mostly just meant to be used as a quick way to try giving programs more or less access from the command-line (ideally a profile should be made to give programs just what they need). The default level currently is 5 (which is fairly permissive compared to most pledge(3)'d applications).  All levels are intended to be securely containable, but each level exposes a greater attack surface than the previous one.  Level 9 is the "please just work" level.  It allows to use all ioctls and to read all sysctls and almost all rare syscalls.  Filesystem access is still very restricted though so you've still got to figure out what unveils the program needs. And there's another dimension to it which is the "unsafety level".  Directives in the config files can be suffixed with one or more "!" to indicate that the permissions that it gives are potentially unsafe, depending on circumstances, or could be surprising or undesired.  The directive only applies when curtain(1) is invoked with as many or more "-!" options.  This was more useful at the beginning when many features weren't properly sandboxed yet.  Now it's not used as much.  But I still find it useful.  The way I'm using it is "!" is probably no big deal but you might want to check it if you're paranoid, "!!" has a real risk of allowing escapes in certain plausible scenarios, and "!!!" is very likely insecure unless special precautions are taken. I'm still not sure what the defaults should be or how they could be better organized.  The "unsafety" is an odd thing to expose to the user and as much as possible I tried to make it unnecessary. So anyway, a shorter way to make nodejs work is to use level 6 which allows PROT_EXEC on anonymous memory (and to execute binaries in $TMPDIR too): $ curtain -6 node -e 'console.log(2+2)' Now with X programs: $ curtain -X xlogo $ curtain -X xterm -X gives "untrusted" X11 access, -Y "trusted" access (like with ssh) and -W is for Wayland. There's an example config file with sample application profiles that can be enabled by uncommenting the include line in /etc/curtain.conf (and reading this file is a good way to see how the whole thing works).  Profiles can be used with -a/-A.  Both simply enable the tag named after the program.  -A is a shortcut that also enables "unsafety level" 1 (most profiles don't actually need it, but some do, so I just use it all the time). $ curtain -XA xterm $ curtain -XA firefox $ curtain -XA chrome $ curtain -XA falkon $ curtain -XA qbittorrent $ curtain -XA hexchat $ curtain -XA gimp $ curtain -XA audacious # curtain -A tcpdump Programs started this way still have the default level 5 permissions in addition to their profile permissions. Option -k ("kill") enables "strict" mode where the default becomes level 1 and programs are sent SIGKILL when trying to do something forbidden (otherwise they just get EPERM errors).  I made those two things go together because unexpected restrictions can make programs misbehave and this could lead to security issues.  This reduces the attack surface but it also means you've got to figure out the permissions just right or your programs are going to get killed a lot.  Also, trying to access non-unveiled files does not cause a SIGKILL to be sent yet, so missing unveils have the potential to cause insecure misbehavior too. See the config files here: https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.defaults https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.sample How well does it generally work? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well, there are some problems. First of all, "untrusted" X11 access doesn't work all that great. Some programs are just unstable with it.  Firefox used to crash a lot with X11 errors but for some reason it seems to have gotten a lot better recently.  But there might be thick borders around menus, client-side decorated windows won't be movable, the system tray won't work, selection/clipboard will only work one direction.  And it'll be slower.  The alternative is to give them "trusted" X11 access but that's very insecure.  And even untrusted access isn't so secure either, untrusted programs are not isolated from one another IIUC.  And who knows what the window manager, panels and others could be doing with the window properties of untrusted clients...  And this exposes the huge complexity of the X11 server. Wayland's security is supposed to be much better, but it depends on how the compositors handle security on the extra protocols that they support and IIUC there's not a consensus on how it should be handled yet and most compositors still lack security restrictions (but apparently some people just compile out their support for insecure protocols). Programs that have built-in support for privilege-separation and self-sandboxing can solve this by not giving direct access to the display to the sandboxed parts.  And that's something that this implementation means to support (which can be done on top of sandboxing the application as a whole).  But it's not a general solution. Also, dbus/dconf/pulseaudio/etc are not dealt with very well yet. They're just ignored really.  And (a bit surprisingly) many programs seem OK with that.  fontconfig will complain a lot but if the font caches are already up to date it doesn't look like it matters (startup will be much slower otherwise).  pulseaudio will just die when firefox tries to start it but then it'll fallback to using OSS directly (sndio works too).  Thumbnail caches won't be accessible.  The XDG shared recent documents list won't work. dconf will be completely non-functional and some programs won't be able to save their settings.  Etc.  And even when it works, "desktop integration" in general is going to be very degraded.  A program trying to launch the desktop environment's handler program to open a file or URL probably won't work because it'll inherit a too restrictive sandbox.  I haven't really gotten into trying to deal with this better yet.  I see that there are dbus proxy services for sandboxing on Linux.  It would probably need something like that. There are some scripts to sandbox programs with separate XDG directories or separate $HOME in /usr/share/examples/curtain/. But I wish doing this wouldn't be necessary... For non-desktop programs, it generally just works (if you give them enough permissions).  The main thing causing trouble is usually /tmp. About the userland parts: ~~~~~~~~~~~~~~~~~~~~~~~~~ libcurtain is a wrapper around the sandboxing syscall.  It allows to assign permissions to "slots" which then get merged.  Path permissions can override each others (most specific wins) within a slot, but across slots they are merged in a non-interfering way (a more specific permissions never cancels out less specific permissions from a different slot).  Permissions from different bracketed sections of config files are added to different slots, so they all get merged in this way. Config files are also handled by libcurtain.  Applications can use libcurtain directly to sandbox themselves using tags, but the API for that is more complex than it should be and I'm probably going to make more changes to it. I added a freebsd_simple_sandbox() function directly to libc that tries to load libcurtain and applies a tag.  The idea is to make it as easy as possible to add configurable, opportunistic sandboxing to applications without having to link them to libcurtain.  It can be called multiple times at different stages of initialization of an application, or for different sub-processes, etc.  The application just specifies a tag for each call and the details are in the config files.  Conceivably, there could be different backends implementing the sandboxing. libcurtain also contains the pledge()/unveil() implementation.  On OpenBSD, pledge/unveil are available directly in libc (with the declarations in unistd.h), but the portable versions of some OpenBSD programs have problems if pledge/unveil are available on non-OpenBSD platforms because they just don't expect that.  After fixing them, maybe auto-loading wrappers could be added directly to libc too so that they just work without having to deal with libcurtain dependencies. About the kernel-side parts: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Most of the implementation is in a separate mac_curtain module, but it also needed some changes spread out in the kernel to support it.  That's what would need to be merged. The biggest change is adding "sysfils".  It initially just meant "syscall filters" but now it's more of a general category of things that the kernel can do.  Syscalls can be associated with zero or more required sysfils and some explicit sysfil checks were added in various places in the kernel as needed.  ucreds have a set of allowed sysfils.  Sysfils are represented as simple bitmaps and checks are fast.  Capsicum was slightly modified to make use of a sysfil bit to simplify syscall entry checks. Sysfils are meant to be part of the internal kernel API, they're not exposed to the userland.  The curtain module exposes intermediate "abilities" instead. Some checks that checked for "capability mode" now check for a more general "restricted mode" instead.  A process is considered in restricted mode whenever its ucred is missing any sysfil bit. MAC handlers were added to let curtain hook into places that didn't have MAC checks.  Some of those new handlers definitively seem out of place.  The new vnode "walk" functions are more of a low-level mechanism than just a security policy.  And many of the new handlers want to restrict access to certain functionality as a whole (e.g. ioctls, sockopts, procctls, etc) rather than compare labels.  But it seemed like the best place to add them because MAC already did most of what was needed.  So I've been treating the MAC framework like it stands for "Modular Access Checks" or something. The curtain permissions are stored in "curtain" objects.  Process ucreds have their labels point to a curtain.  Curtains have pointers to "barrier" objects, which contain the hierarchical linkage needed to restrict access to protected kernel objects. Those kernel objects have their labels point directly to barriers.  Barriers can outlive their curtains.  When a ucred loses its last reference from a process, it is "trimmed" and its label curtain pointer "decays" into a pointer to the curtain's barrier so that the curtain can be freed (because curtains can be a few KBs and they can hold vnode references).  A lot of objects hold references to ucreds, so they could build up a lot without this. Processes can sandbox themselves with curtainctl(2).  They have to specify the full set of permissions they want to retain.  The requested permissions are then masked with the current curtain (if any).  This involves dealing with inheritance relationships between permissions (as the new curtain can have permissions more specific than the old and vice versa). Kernel-side handling of filesystem path unveiling was the hardest part to deal with (given the "statelessness" of the vnode API) and it kind of is all a big kludge.  I tried to make it as nice as possible and wrapped the whole thing behind a MAC API (it used to be a lot worse than that). Each directory "unveil" acts like a sort of chroot barrier but with specific permissions.  There's a per-thread "tracker" with a circular buffer that remembers the permissions for the previous N looked-up vnodes.  N only needs to be 2 as far as I can tell (most syscalls only need 1, but linkat() for example needs 2).  The tracker has weak vnode references and doesn't need to be cleaned up after syscalls.  namei() calls the new MAC handlers to manage the tracker during path lookup.  fget*() also adds a tracker entry.  Then the access check MAC handlers can find permissions for the passed vnodes in the tracker.  This only works because almost all of the kernel code that work on vnodes first get a reference from namei()/fget*() and then don't call VOP_LOOKUP() directly themselves.  It's messy but one good thing with it is that it usually "fails-secure" if the tracker was mismanaged because it won't find the vnode in it and it defaults to deny. From nobody Mon Mar 28 10:11:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 127CB1A514FA for ; Mon, 28 Mar 2022 10:11:33 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mail.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRpPv4zQ2z3NbH for ; Mon, 28 Mar 2022 10:11:31 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1648462289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CiwvoECvl0ZA3q5QL0t0lZLCVfOgar1vy/ubmsUn4s8=; b=VcK0b1AC/2tg+rtb9G8pkZMUzAqe5rMc/1viJIrCQJEq6e18YvscjtfTgJrcxRIgk8Ez2W XYLDIlrKeM/wFmbGgrH/ODoaJkSpkDjoBMp30cWC+LXYHElnLxKqWQfL11WiJvV9j3G3FB eBqiW3ksb8Q+Bb/PKIx3C9FBNIweIhM= Received: from skull.home.blih.net (lfbn-idf2-1-1209-45.w90-92.abo.wanadoo.fr [90.92.34.45]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 42064f43 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 28 Mar 2022 10:11:29 +0000 (UTC) Date: Mon, 28 Mar 2022 12:11:29 +0200 From: Emmanuel Vadot To: Faraz Vahedi Cc: freebsd-hackers@FreeBSD.org Subject: Re: poudriere-image(8) and the required /usr/freebsd-dist files for installation Message-Id: <20220328121129.0abf16e6518d8daba5c7712c@bidouilliste.com> In-Reply-To: <20220328093722.a6rgj4hqtspphxz7@x1> References: <20220328093722.a6rgj4hqtspphxz7@x1> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KRpPv4zQ2z3NbH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=VcK0b1AC; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.30)[0.295]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, On Mon, 28 Mar 2022 09:37:22 +0000 Faraz Vahedi wrote: > Greetings hackers, > > I have heard a lot about the poudriere-image(8), and it seems to be > widely used despite maturity. > > I gave it a try, and it indeed works fantastically. But there are a > few things I could not yet find a proper way to resolve. The most > important one is that the final image does not contain the required > /usr/freebsd-dist files, and therefore it either should fetch them > or fails to proceed with the installation. > > How would you handle it when the ``packagelist'' is provided and > you cannot fetch and overlay the files from upstream? > > I appreciate any help. Cheers. > > Respectfully, > Faraz The goal for poudriere-image was never to be able to provide installer images. The only goal is to provide live image that can be booted from usb, network, or directly dd on a disk. Cheers, -- Emmanuel Vadot From nobody Mon Mar 28 10:20:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F0CF91A533E9 for ; Mon, 28 Mar 2022 10:20:16 +0000 (UTC) (envelope-from kfv@kfv.io) Received: from mail.kfv.io (mail.kfv.io [95.217.128.176]) (using TLSv1.3 with cipher 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 "kfv.io", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRpbz0KtJz3QTL for ; Mon, 28 Mar 2022 10:20:14 +0000 (UTC) (envelope-from kfv@kfv.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kfv.io; s=dkim; t=1648462813; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7wg57+F5oAwvfFGlWNfH7EokyChmzxfADBGCXZlJFXg=; b=pqfI306CYkfFm9fJ5BUhSKRCg6+uuNe/RF42VWZdQhDWc8wl2v2jk6K22YUrL6llK7qC6X Gt7Os4KKci/98Onl31+DlMhFRNQwUfBVCikWer8gCcdBYmoxoA7/rhfhYBYhs7qOHPK58L 0LCUBD7H4Fsr1tLT0eREqVHLPDrnoVTJB6hH2GKVbsyO+YKa+bxBWvO1Dyaz//cNf+eXFF 6u/P6STcjna1dTIJtXcwCMOqXIS5rwWATQVyeBHpiZgrfvW/TGc2Qz45oMnlUzByEJ97Pm +76+ayb/GzhEu8RMbppO2uQt392VDOyB2EZSYqyHXq1giuGMPVeVqn7XWig8Xw== Received: from x1 (46.30.188.148.static.quadranet.com [46.30.188.148]) by srv.kfv.io (OpenSMTPD) with ESMTPSA id 576f297f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 28 Mar 2022 10:20:12 +0000 (UTC) Date: Mon, 28 Mar 2022 10:20:09 +0000 From: Faraz Vahedi To: freebsd-hackers@freebsd.org Subject: Re: poudriere-image(8) and the required /usr/freebsd-dist files for installation Message-ID: <20220328102009.uki5x3u4t5mhgbzn@x1> References: <20220328093722.a6rgj4hqtspphxz7@x1> <20220328121129.0abf16e6518d8daba5c7712c@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n2rpjggfrwxge6b6" Content-Disposition: inline In-Reply-To: <20220328121129.0abf16e6518d8daba5c7712c@bidouilliste.com> X-Rspamd-Queue-Id: 4KRpbz0KtJz3QTL X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kfv.io header.s=dkim header.b=pqfI306C; dmarc=pass (policy=reject) header.from=kfv.io; spf=pass (mx1.freebsd.org: domain of kfv@kfv.io designates 95.217.128.176 as permitted sender) smtp.mailfrom=kfv@kfv.io X-Spamd-Result: default: False [-5.34 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[kfv.io:s=dkim]; NEURAL_HAM_MEDIUM(-0.77)[-0.766]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.217.128.176]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[kfv.io:+]; DMARC_POLICY_ALLOW(-0.50)[kfv.io,reject]; NEURAL_HAM_SHORT(-0.98)[-0.976]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --n2rpjggfrwxge6b6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Emmanuel, Oh, I see! Thank you for the quick response. Cheers, Faraz On Mon, Mar 28, 2022 at 12:11:29PM +0200, Emmanuel Vadot wrote: >=20 > Hi, >=20 > On Mon, 28 Mar 2022 09:37:22 +0000 > Faraz Vahedi wrote: >=20 > > Greetings hackers, > >=20 > > I have heard a lot about the poudriere-image(8), and it seems to be > > widely used despite maturity. > >=20 > > I gave it a try, and it indeed works fantastically. But there are a > > few things I could not yet find a proper way to resolve. The most > > important one is that the final image does not contain the required > > /usr/freebsd-dist files, and therefore it either should fetch them > > or fails to proceed with the installation. > >=20 > > How would you handle it when the ``packagelist'' is provided and > > you cannot fetch and overlay the files from upstream? > >=20 > > I appreciate any help. Cheers. > >=20 > > Respectfully, > > Faraz >=20 > The goal for poudriere-image was never to be able to provide installer > images. The only goal is to provide live image that can be booted from > usb, network, or directly dd on a disk. >=20 > Cheers, >=20 > --=20 > Emmanuel Vadot >=20 --n2rpjggfrwxge6b6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEER72OR2ke+5+zBDNGxovV64RZlvEFAmJBi9kACgkQxovV64RZ lvFXQgf/TEynS1NzsR5AgwCp7fQ85BqY5X2tgSpxITUOLBwwhiZIpjflId23P/xE QSzsQZI67v/MKEfUXjCLH9cFc2ryNob5mMBOJa0RGf2qil73VPN7KSu/9PYS828I HETuPhFsBHqR9gAfm6rLYJzerxi38RsnlMvZWXDfFcrXsO0E1cmx8Ee67c8oOW1R LnbDoN9SKJG1ez2cqGTNl1liaL7X8IRzaln4KZMB4U3I2NLr+v9kCjJkcrk/22RC ZtSuHehr5eO8hrEjyL03tvD4CF85JRD4GEoQO53SEyNqVBUCyPB5av0Ndb1UNh4M QMLXeJkN+KSqJiJGQhQZYIXJb1WHBg== =jUNT -----END PGP SIGNATURE----- --n2rpjggfrwxge6b6-- From nobody Mon Mar 28 10:29:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 933A71A559EA for ; Mon, 28 Mar 2022 10:29:22 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRppT3jBXz3jJX; Mon, 28 Mar 2022 10:29:21 +0000 (UTC) (envelope-from ganael.laplanche@martymac.org) Received: (Authenticated sender: ganael.laplanche@martymac.org) by mail.gandi.net (Postfix) with ESMTPSA id 23307240008; Mon, 28 Mar 2022 10:29:13 +0000 (UTC) From: Ganael Laplanche To: Jilles Tjoelker Cc: Bryan Drewery , freebsd-hackers@freebsd.org Subject: Re: Our /bin/sh and process group IDs Date: Mon, 28 Mar 2022 12:29:10 +0200 Message-ID: <5667029.Zv9zXsTiuT@home.martymac.org> In-Reply-To: <20220326193950.GA1667@stack.nl> References: <48e49ad0-a12a-d10b-5867-da9736c6c1fd@martymac.org> <9745f2ef-3aae-5548-c8db-5da7d4ce11e7@martymac.org> <20220326193950.GA1667@stack.nl> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 4KRppT3jBXz3jJX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ganael.laplanche@martymac.org designates 217.70.178.230 as permitted sender) smtp.mailfrom=ganael.laplanche@martymac.org X-Spamd-Result: default: False [0.21 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.70.178.230:from]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.178.192/26]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[martymac.org]; NEURAL_HAM_LONG(-0.88)[-0.881]; NEURAL_SPAM_MEDIUM(0.62)[0.625]; NEURAL_SPAM_SHORT(0.37)[0.371]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; CTE_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.178.230:from] X-ThisMailContainsUnwantedMimeParts: N On Saturday, March 26, 2022 8:39:50 PM CEST Jilles Tjoelker wrote: Hello Jilles, > This appears to be a gray area, and the exact behaviour varies across > shells. For example, with stty tostop in effect, > [...] > > I think it is definitely undesirable for set -m to have an effect > across multiple levels of subshells by default, since it makes the > innermost processes immediately escape from the outer process group > supervision again. > > As it is now, FreeBSD sh has implemented this by ignoring set -m from > a process other than the first process Right. Thanks for those interesting examples & explanations. > A second workaround is to start a new instance of sh. Yep ! Thanks again, -- Ganael LAPLANCHE http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac , http://www.FreeBSD.org From nobody Mon Mar 28 12:32:12 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4A0D51A4DB72; Mon, 28 Mar 2022 12:32:50 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KRsXx4n8vz4bvr; Mon, 28 Mar 2022 12:32:49 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id o5so25728477ybe.2; Mon, 28 Mar 2022 05:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JQiiR+fvZ4/mwRf0qxdA4MOHSv49GID/bS75CqRqUCg=; b=ci53On1mJ6ezHipyiUzmqttahX8IYOGX/TiXOMbZXV+mzYb/3lvubLSTKBbadecIAS xpXP12MLsGXpcUOI/aZ6zXEmGw183ZyPGHPFa6/e3PGaffuEL+1IGT80428v90t6OSnz VXNQtCXDW4ndnZ1nvHLY5acsM4BMkXApu4g35Nl3cc07MKANnuxzwUlYgke9tdy9BpYX pTiYnHZBvjzN54IuQRK6fsWqrpOtmjGCrMGDKV9iVgVEDDQ2i3i3li4cs8PVri+VNRz5 P8F1tEvyxSASco4BD1rLJBBQ2tCg2gpWS/A7E2b3nUVYBKezJsesIUWL3FTulolpEdTJ l4UQ== 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=JQiiR+fvZ4/mwRf0qxdA4MOHSv49GID/bS75CqRqUCg=; b=Z7OHIhuxpmCuYLDvdLB4XbZDLDq44akQApqFfkf12EimwYvavt0d/WW921v6L8RkI3 t52tJQCwllWezV3+OK88zAtlP6eu/8okMaU1o9TVYVYkJGChxGngZ70WBZ9bKm2lirwm vLPpP74S6hs7pUntsl4qhA85KBTDWonO1+9nTD3uIFUYEPSIsMCM0NQXO5WGOXOO6JRM HUWV+tGepybaFPOcGdYfdjqe3bfPbT1ZplWFJ9MBeiDDSLBvb4xFdrT4iD8qDyOkQxTl rAIQKQg3ykNyu5MIE5D6oSoG10i48WYa0zVWBIh3pbtDlnxO8xHSDOtqC3Rh2Hj2CkWt /Lzg== X-Gm-Message-State: AOAM533kmUt8sau/7gSGvhNfpUi0d/mzuhbRtXdeGV+HXr1IRLT6ewzK hl1wdO92pQCGFSHrTdbURpMiJh5eXfQJwtk+T5RbTcRASc0= X-Google-Smtp-Source: ABdhPJwyrnUfXQhjltXLZmJ62PCHRKJ0ddlCLCZTQrwGRDCF7OPgn/Zz5PqP/7pHRYQp73jB08QMzsjOWDKbycmTUBg= X-Received: by 2002:a25:e08f:0:b0:633:7d68:f21a with SMTP id x137-20020a25e08f000000b006337d68f21amr22326118ybg.650.1648470768684; Mon, 28 Mar 2022 05:32:48 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <02ee01d8421f$cf723f20$6e56bd60$@tubnor.net> In-Reply-To: <02ee01d8421f$cf723f20$6e56bd60$@tubnor.net> From: Mario Marietto Date: Mon, 28 Mar 2022 14:32:12 +0200 Message-ID: Subject: Re: Virtio-win driver (virtio-blk and virtio-scsi) don't work when they are used on bhyve with Windows 11 as guest os To: jason@tubnor.net, =?UTF-8?Q?Corvin_K=C3=B6hne?= Cc: FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009711e305db468255" X-Rspamd-Queue-Id: 4KRsXx4n8vz4bvr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ci53On1m; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [0.69 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from]; HTTP_TO_IP(1.00)[]; NEURAL_SPAM_LONG(0.68)[0.676]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; NEURAL_HAM_SHORT(-0.98)[-0.978]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000009711e305db468255 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've just installed the virtio driver version suggested by Corvin (0.185) and it works fine in Windows. So,now I can pass those NTFS disks without using the USB controller. That's so cool. Bhyve becoming even more and more interesting. I'm happy thanks to everyone. It works even in Linux without passing the disks using the USB controller. Maybe I can make a lighter /boot/loader.conf file,excluding the USB controllers..... Il giorno dom 27 mar 2022 alle ore 23:15 ha scritto: > > > > > > > What I want to achieve is to pass thru two of my NTFS "formatted" disks t= o > a Windows 11 VM,but without passing them thru using the USB controller in > FreeBSD with a bhyve virtual machine (in the example below I tried to boo= t > Windows 11 from the nvme disk nvd0. > > I've configured the bhyve VM like this : > > > > bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ > > -s 0,hostbridge \ > > -s 1,ahci-hd,/dev/nvd0 \ > > -s 2,virtio-blk,/dev/da4p2 \ > > -s 3,virtio-blk,/dev/da2p1 \ > > -s 8,virtio-net,tap4 \ > > -s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \ > > -s 29,fbuf,tcp=3D[0.0.0.0:5904](http://0.0.0.0:5904/),w=3D1440,h=3D900 \ > > -s 30,xhci,tablet \ > > -s 31,lpc \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \ > > vm4 < /dev/null & sleep 2 && vncviewer 0:4 > > > > These are the NTFS disks that I would like to see inside the Windows 11 > guest os : > > > -s 2,virtio-blk,/dev/da4p2 \ > > -s 3,virtio-blk,/dev/da2p1 \ > > > > > > =3D> 34 19532873661 da4 GPT (9.1T) > > 34 32734 1 ms-reserved (16M) > > 32768 19532838912 2 ms-basic-data (9.1T) > > 19532871680 2015 - free - (1.0M) > > > > > > =3D> 34 23437705149 da2 GPT (11T) > > 34 2014 - free - (1.0M) > > 2048 23437701120 1 ms-basic-data (11T) > > 23437703168 2015 - free - (1.0M) > > I've tried also like this : > > > bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ > > -s 0,hostbridge \ > > -s 1,ahci-hd,/dev/nvd0 \ > > -s 2,virtio-blk,/dev/da4 \ > > -s 3,virtio-blk,/dev/da2 \ > > -s 8,virtio-net,tap4 \ > > -s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \ > > -s 29,fbuf,tcp=3D[0.0.0.0:5904](http://0.0.0.0:5904/),w=3D1440,h=3D900 \ > > -s 30,xhci,tablet \ > > -s 31,lpc \ > > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \ > > vm4 < /dev/null & sleep 2 && vncviewer 0:4 > > > > and I get this error : > > > > *Assertion failed: (n >=3D 2 && n <=3D BLOCKIF_IOV_MAX + 2), function > pci_vtblk_proc, file /usr/src/usr.sbin/bhyve/pci_virtio_block.c, line 324= .* > > I have also opened a bug request below,but no one replied until now. > > > > Use nvme or ahci-hd for da4/da2 and see what you get. The whole disk need= s > to go in there so Windows sees the GPT label. The other thing that comes = to > mind is that FreeBSD has hold of the disks and won=E2=80=99t allow them t= o be > inserted, similar to issues when passing zvol into guests when volmode<>d= ev. > > > > Cheers, > > > > Jason. > --=20 Mario. --0000000000009711e305db468255 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've just installed the virtio driver version suggeste= d by Corvin (0.185) and it works fine in Windows. So,now I can pass those N= TFS disks without using the USB controller. That's so cool. Bhyve becom= ing even more and more interesting. I'm happy thanks to everyone. It wo= rks even in Linux without passing the disks using the USB controller. Maybe= I can make a lighter /boot/loader.conf file,excluding the USB controllers.= ....

Il giorno dom 27 mar 2022 alle ore 23:15 <jason@tubnor.net> ha scritto:

=C2=A0

=C2=A0

=C2=A0

What I want to achieve = is to pass thru two of my NTFS "formatted" disks to a Windows 11 = VM,but without passing them thru using the USB controller in FreeBSD with a= bhyve virtual machine (in the example below I tried to boot Windows 11 fro= m the nvme disk nvd0.

I've configured the bhyve VM = like this :

=C2=A0
bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A =
\
-s 0,hostbridge \
-s 1,ahci-hd,/dev/nvd0 \
=
-s 2,virtio-blk,/dev/da4p2 \
-s =
3,virtio-blk,/dev/da2p1 \
-s 8,virtio-=
net,tap4 \
-s 10,hda,play=3D/dev/dsp,r=
ec=3D/dev/dsp \
-s 29,fbuf,tcp=3D[0.0.=
0.0:5904](http://0.0.0.0=
:5904/),w=3D1440,h=3D900 \
-s 30,x=
hci,tablet \
-s 31,lpc \=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
-l bootrom,/usr/local/share/uefi-firmware/=
BHYVE_BHF_CODE.fd \
vm4 < /dev/null=
 & sleep 2 && vncviewer 0:4

= =C2=A0

These are the NTFS disks that I would like to se= e inside the Windows 11 guest os :


-s =
2,virtio-blk,/dev/da4p2 \
-s 3,virtio-=
blk,/dev/da2p1 \
=C2=A0<=
/code>
=C2=A0
=3D>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34=C2=A0 19532873661=C2=A0=
 da4=C2=A0 GPT=C2=A0 (9.1T)
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 34=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 32734=C2=A0=C2=A0=C2=A0 1=C2=A0 ms-reserved=C2=A0 (16=
M)
32768=C2=A0 19532838912=C2=A0=C2=A0=
=C2=A0 2=C2=A0 ms-basic-data=C2=A0 (9.1T)
19532871680=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2015=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - free -=C2=A0 (1.0M)
=C2=A0
=C2=A0=

=3D>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 34=C2=A0 23437705149=C2=A0 da2=C2=A0 GPT=C2=A0 (11T)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 34=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2014=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - free -=C2=A0 (1.0M)
2048=C2=A0 23437701120=C2=A0=C2=A0=C2=A0 1=C2=A0 ms-basic-da=
ta=C2=A0 (11T)
23437703168=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2015=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0- free -=C2=A0 (1.0M)

I've tried = also like this :


bhyve -S -c sockets=
=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
=
-s 0,hostbridge \
-s 1,ahci-hd,/=
dev/nvd0 \
-s 2,virtio-blk,/dev/da4 \<=
u>
-s 3,virtio-blk,/dev/da2 \
-s 8,virtio-net,tap4 \
= 
-s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \<=
/pre>
-s 29,fbuf,tcp=3D[0.0.0.0:5904](http://0.0.0.0:5904/),w=3D1440,h=3D900 \=

-s 30,xhci,tablet \
-s 31,lpc \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
-l b=
ootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \
vm4 < /dev/null & sleep 2 && vncviewer 0=
:4

=C2=A0

and I get = this error :

=C2=A0

Assertion failed: (n &g= t;=3D 2 && n <=3D BLOCKIF_IOV_MAX + 2), function pci_vtblk_proc,= file /usr/src/usr.sbin/bhyve/pci_virtio_block.c, line 324.=

I have also opened a bug request below,but no one repl= ied until now.

=C2=A0

Use nvme or ahci-hd for da4/da2 and see what you get. = The whole disk needs to go in there so Windows sees the GPT label. The othe= r thing that comes to mind is that FreeBSD has hold of the disks and won=E2= =80=99t allow them to be inserted, similar to issues when passing zvol into= guests when volmode<>dev.

=C2=A0

Chee= rs,

=C2=A0

Jason.



--
Mario.
--0000000000009711e305db468255-- From nobody Tue Mar 29 08:34:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7E9B1A36FAF for ; Tue, 29 Mar 2022 08:34:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSNC73kmjz3Mw0 for ; Tue, 29 Mar 2022 08:34:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648542851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dIrsssPG9KdZoFhAsET7fWphc47wJPvSblL2hDiA7ic=; b=XSZfTCdkWNtWCFJAG14T2hG3Jk1UY43RRuZFV/QNX4PlZOEFACE8ZPOek/K+EcaaYfmY9z vups0aRW+fSewJHPIDyVA6GRgdQhbQR83C7riJPh/Em6ulDhh1HrNP7ChLjAfG+BL5abZK s9UCGou3WK/TkRqy2s2NUBsdMTOjyRCjTobvpiyrDSUUQjhGxO/PiiFwdrT3cAKiyZvYUM 8I2o685N7ErBlI22O+KxRXEXshtjOH8+Q257haDjBpC0kB3CPFbQOzjaFW9aheyB1CXpXG vCFL2Xz13cbxIx0hJ2xCl4yjP9QLdDcoxUFXQ0CQT6xLlo03JJaGSLw3RN14WA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 01ED42EEF0 for ; Tue, 29 Mar 2022 08:34:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [10.164.186.150] (unknown [167.220.197.22]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 1F4652F797 for ; Tue, 29 Mar 2022 09:34:09 +0100 (BST) Message-ID: <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> Date: Tue, 29 Mar 2022 09:34:08 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> From: David Chisnall In-Reply-To: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648542851; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dIrsssPG9KdZoFhAsET7fWphc47wJPvSblL2hDiA7ic=; b=UwHHXM23olVn1f1SXkXUGw9KUYv0Xh03xKCHPrfOykRroxDCaevKLJGfFi8uBwdWGLf0NT SIK1naDOFpWtB6WjPumqf0C6SD/AtM5u6P0hKD6Bh0+9VP1gmg2TIYdd949pyO2MwT6i3J wGvRetRfqoObhyNMoYiUl+uy+Cr5Slpzls6Wse/vPK1Sv3U2pKCHZLn+WpTK9Kj1VGQeCQ qFMDZeoC05OHI1euJhm/8FVQdnjuoaKp/c43lqySYWrW14FeWPnS1Ng2lbgPH1ROak65eL /oHNkW0eR7MGeix+WQFyP/FpLsIC987HRmj9psGkJSE6k8GspSk/l/8CU5nf5Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648542851; a=rsa-sha256; cv=none; b=hcGQMXS+vlEnytaedkcUwR0JvR4BRqZd8AUwF4jDL7MneZA0FWAyzMxNLoKKD1W5Joz3oE Flr3tfCQ8u4AkPEWfW1BennF2fBaVGTSzy4snnyOckOlkpuH78o/kVj8dIupH9+KDxckiq txmxhkR+BQN5KoJQMkVbymftUDQSBFukBorIWswtqHo4PtSI0s61DEs1HFt/yQc3n6jQ1b qv+uWquyK89eeTrPMXpy88xjDfqmp2O735Ey+NCZBQQKVTpHeDke8CPVes4B5LcRhtSEE2 sdg7EedaKGHAN4sQsoXAK/X5YBcm4FXOUi0UPRTYEuqc6e0JRDF8B3YX+BxTWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi, Does pledge actually require kernel support? I'd have thought that it could be implemented on top of Capsicum as a purely userland abstraction (more easily with libc help, but even with an LD_PRELOADed library along the lines of libpreopen). In Verona, we're able to use Capsicum to run unmodified libraries in a sandbox, for example, including handling raw system calls: https://github.com/microsoft/verona/tree/master/experiments/process_sandbox It would be good to understand why this needs more kernel attack surface. David On 28/03/2022 10:37, Mathieu wrote: > Hello list.  Since a while I've been working on and off on a > pledge()/unveil() implementation for FreeBSD.  I also wanted it to be > able to sandbox arbitrary programs that might not expect it with no (or > very minor) modifications.  So I just kept adding to it until it could > do that well enough.  I'm still working on it, and there are some known > issues and some things I'm not sure are done correctly, but overall it's > in a very functional state now. It can run unmodified most utilities and > desktop apps (though dbus/dconf/etc are trouble), server daemons, > buildworld and whole shell/desktop sessions sandboxed. > > https://github.com/Math2/freebsd-pledge > https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md > > It can be broken up in 4 parts: 1) A MAC module that implements most of > the functionality.  2) The userland library, sandboxing utility, configs > and tests.  3) Various kernel changes needed to support it (including > new MAC handlers and extended syscall filtering).  4) Small > changes/fixes to the base userland (things like adding reporting to ps > and modifying some utilities to use $TMPDIR so that they can be properly > sandboxed).  So 1) and 2) could be in a port.  And I tried to minimize > 3) and 4) as much as possible. > > I noted some problems/limitations in the CURTAIN-ISSUES file.  At this > point I'm mostly wondering about the general design being acceptable for > merging eventually.  Because most of this could be part of a port, but > not all of it.  And the way that it deals with filesystem access > restrictions in particular is kludgy.  So any feedback/testing welcome. > > It still lacks documentation (in part because I'm not sure of what could > still change) so I'm going to give an overview of it here and show some > examples and that's going to be the documentation for now.  And I'll > describe the kernel changes that it needed.  So that's going to be a bit > of a long email. > > What it can do: > ~~~~~~~~~~~~~~~ > > It can restrict syscalls and various abilities (by categories that were > based on OpenBSD's pledge promises), ioctls, sysctls, socket > options/address families, priv(9) privileges, and filesystem access by > path.  It can be used at the same time as jails and Capsicum (their > restrictions are also enforced on top of it). > > It can be used in a nested manner.  A program that inherits sandbox > restrictions can do its own internal sandboxing or sandbox programs that > it run (which can then do the same, etc).  The permissions of new > sandboxes are always a subset of the inherited sandbox. > > Certain kernel operations are protected by "barriers" which only allow a > sandboxed process to operate on kernel objects that were created by > itself or a descendant sandbox.  There are barriers for > inspecting/signaling/debugging processes, POSIX/SysV IPC objects, PTYs, > etc.  Barriers have their own hierarchy which can diverge from the > process hierarchy. > > Restrictions can be specified in configuration files and can be > associated with named "tags".  Tags are assumed to match application > names, they're prefixed with "_" when they don't (just the convention > I've been using so far).  Enabling a tag may cause other tags to be > enabled depending on configurations.  Permissions associated with > different tags are merged in a purely additive manner.  Configurations > can be spread in multiple files and directories > (/usr/local/etc/curtain.{conf,d} can be used for packages, > ~/.curtain.{conf,d} for user customizations).  It'll check the .d > directories for files named after the enabled tags. > > Usage examples: > ~~~~~~~~~~~~~~~ > > curtain(1) is the wrapper utility to sandbox arbitrary programs. Default > permissions are in /etc/defaults/curtain.conf and /etc/curtain.conf. > > Here a bunch of examples.  A bit random, but they demonstrate a lot of > the functionality. > > $ curtain id > > Not very exciting, but it works.  The default permissions don't give it > access to the user DB so it only shows numeric IDs.  It can be given > access with the "_pwddb" tag: > > $ curtain -t _pwddb id > > It's possible to nest sandboxes, but it needs the "curtain" tag because > the curtain config files are not unveiled by default (they could be > though, maybe they should be...). > > Here, id cannot read the user DB because the outer sandbox doesn't allow > it: > > $ curtain -t curtain curtain -t _pwddb id > > But this way it can: > > $ curtain -t curtain -t _pwddb curtain -t _pwddb id > > Starts a sandboxed shell session with access to ~/work in a clean > environment: > > $ mkdir -p ~/work && curtain -p ~/work:rwx -S > > You'll probably miss your dotfiles though.  If you browse around you'll > see what paths get unveiled by default. > > If you try to list processes: > > $ curtain ps -ax > > You'll just see the ps process itself.  It can be allowed to see > processes outside of it like that: > > $ curtain -d ability-pass:ps ps -ax > > But it will not be allowed to signal, reprioritize or debug them (there > are other "abilities" for that).  The "-pass" means to allow the ability > in a "passthrough" manner (beyond the sandbox's barrier).  Visibility > could also be blocked at an outer sandbox's barrier, like so: > > $ curtain -t curtain curtain -d ability-pass:ps ps -ax > > Give read-only access to the current directory and list files: > > $ curtain -p . ls > > If you have $CLICOLOR set, it may look less colorful than usual. > curtain(1) is a bit paranoid and will filter out most control characters > written to the TTY by default (and set $TERM to "dumb").  They can be > let through with -R: > > $ curtain -R -p . ls > > And -T can be used to stop it from doing PTY wrapping altogether and > give the program direct access to the TTY (which is less secure, but > there are ioctl restrictions). > > Per-path permissions can be specified after a ":".  More specific paths > override the permissions of less specific paths. > > $ curtain -p .:rw -p ./secret: -p ./dev:rwx -p ./data:r ... > > Then those paths would have those permissions: >     ./:rw >     ./123:rw >     ./secret: >     ./dev:rwx >     ./dev/123:rwx >     ./data:r >     ./data/123:r > > As an example of how nested sandboxing is handled, if you were then to > do this within this sandbox (don't forget to give it the "curtain" tag): > > $ curtain -p .:r -p ./dev:rx -p ./data:rw ... > > Then the permissions would end up being: >     ./:r >     ./123:r >     ./secret: >     ./dev:rx >     ./dev/123:rx >     ./data:r >     ./data/123:r > > root processes can be sandboxed too.  Some privileges are allowed by > default (which is similar to the set of privileges allowed by jails), > but most are denied.  As are accesses to most /dev and /etc files.  For > example, tcpdump will not be able to use bpf(4): > > # curtain tcpdump > > But there's a tag for that: > > # curtain -t _bpf tcpdump > > Something else that won't work: > > $ curtain node -e 'console.log(2+2)' > > It wants to do a PROT_EXEC mprotect(2) which is not allowed by default. > By default, PROT_EXEC is only allowed when mmap(2)'ing files that are > unveiled for execution. > > $ curtain -d ability:prot_exec node -e 'console.log(2+2)' > > Just what is allowed by default?  Well it's kind of arbitrary and messy > and there are 10 levels of it. > > curtain(1) uses a 10-levels "permissions tower" usable with options -0 > to -9 (which enable tags "_level0" to "_level9"). These are mostly just > meant to be used as a quick way to try giving programs more or less > access from the command-line (ideally a profile should be made to give > programs just what they need). The default level currently is 5 (which > is fairly permissive compared to most pledge(3)'d applications).  All > levels are intended to be securely containable, but each level exposes a > greater attack surface than the previous one.  Level 9 is the "please > just work" level.  It allows to use all ioctls and to read all sysctls > and almost all rare syscalls.  Filesystem access is still very > restricted though so you've still got to figure out what unveils the > program needs. > > And there's another dimension to it which is the "unsafety level". > Directives in the config files can be suffixed with one or more "!" to > indicate that the permissions that it gives are potentially unsafe, > depending on circumstances, or could be surprising or undesired.  The > directive only applies when curtain(1) is invoked with as many or more > "-!" options.  This was more useful at the beginning when many features > weren't properly sandboxed yet.  Now it's not used as much.  But I still > find it useful.  The way I'm using it is "!" is probably no big deal but > you might want to check it if you're paranoid, "!!" has a real risk of > allowing escapes in certain plausible scenarios, and "!!!" is very > likely insecure unless special precautions are taken. > > I'm still not sure what the defaults should be or how they could be > better organized.  The "unsafety" is an odd thing to expose to the user > and as much as possible I tried to make it unnecessary. > > So anyway, a shorter way to make nodejs work is to use level 6 which > allows PROT_EXEC on anonymous memory (and to execute binaries in $TMPDIR > too): > > $ curtain -6 node -e 'console.log(2+2)' > > Now with X programs: > > $ curtain -X xlogo > $ curtain -X xterm > > -X gives "untrusted" X11 access, -Y "trusted" access (like with ssh) and > -W is for Wayland. > > There's an example config file with sample application profiles that can > be enabled by uncommenting the include line in /etc/curtain.conf (and > reading this file is a good way to see how the whole thing works). > Profiles can be used with -a/-A.  Both simply enable the tag named after > the program.  -A is a shortcut that also enables "unsafety level" 1 > (most profiles don't actually need it, but some do, so I just use it all > the time). > > $ curtain -XA xterm > $ curtain -XA firefox > $ curtain -XA chrome > $ curtain -XA falkon > $ curtain -XA qbittorrent > $ curtain -XA hexchat > $ curtain -XA gimp > $ curtain -XA audacious > # curtain -A tcpdump > > Programs started this way still have the default level 5 permissions in > addition to their profile permissions. > > Option -k ("kill") enables "strict" mode where the default becomes level > 1 and programs are sent SIGKILL when trying to do something forbidden > (otherwise they just get EPERM errors).  I made those two things go > together because unexpected restrictions can make programs misbehave and > this could lead to security issues.  This reduces the attack surface but > it also means you've got to figure out the permissions just right or > your programs are going to get killed a lot.  Also, trying to access > non-unveiled files does not cause a SIGKILL to be sent yet, so missing > unveils have the potential to cause insecure misbehavior too. > > See the config files here: > > https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.defaults > > https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.sample > > > How well does it generally work? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Well, there are some problems. > > First of all, "untrusted" X11 access doesn't work all that great. Some > programs are just unstable with it.  Firefox used to crash a lot with > X11 errors but for some reason it seems to have gotten a lot better > recently.  But there might be thick borders around menus, client-side > decorated windows won't be movable, the system tray won't work, > selection/clipboard will only work one direction.  And it'll be slower. > The alternative is to give them "trusted" X11 access but that's very > insecure.  And even untrusted access isn't so secure either, untrusted > programs are not isolated from one another IIUC.  And who knows what the > window manager, panels and others could be doing with the window > properties of untrusted clients...  And this exposes the huge complexity > of the X11 server. > > Wayland's security is supposed to be much better, but it depends on how > the compositors handle security on the extra protocols that they support > and IIUC there's not a consensus on how it should be handled yet and > most compositors still lack security restrictions (but apparently some > people just compile out their support for insecure protocols). > > Programs that have built-in support for privilege-separation and > self-sandboxing can solve this by not giving direct access to the > display to the sandboxed parts.  And that's something that this > implementation means to support (which can be done on top of sandboxing > the application as a whole).  But it's not a general solution. > > Also, dbus/dconf/pulseaudio/etc are not dealt with very well yet. > They're just ignored really.  And (a bit surprisingly) many programs > seem OK with that.  fontconfig will complain a lot but if the font > caches are already up to date it doesn't look like it matters (startup > will be much slower otherwise).  pulseaudio will just die when firefox > tries to start it but then it'll fallback to using OSS directly (sndio > works too).  Thumbnail caches won't be accessible.  The XDG shared > recent documents list won't work. dconf will be completely > non-functional and some programs won't be able to save their settings. > Etc.  And even when it works, "desktop integration" in general is going > to be very degraded.  A program trying to launch the desktop > environment's handler program to open a file or URL probably won't work > because it'll inherit a too restrictive sandbox.  I haven't really > gotten into trying to deal with this better yet.  I see that there are > dbus proxy services for sandboxing on Linux.  It would probably need > something like that. > > There are some scripts to sandbox programs with separate XDG directories > or separate $HOME in /usr/share/examples/curtain/. But I wish doing this > wouldn't be necessary... > > For non-desktop programs, it generally just works (if you give them > enough permissions).  The main thing causing trouble is usually /tmp. > > About the userland parts: > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > libcurtain is a wrapper around the sandboxing syscall.  It allows to > assign permissions to "slots" which then get merged.  Path permissions > can override each others (most specific wins) within a slot, but across > slots they are merged in a non-interfering way (a more specific > permissions never cancels out less specific permissions from a different > slot).  Permissions from different bracketed sections of config files > are added to different slots, so they all get merged in this way. > > Config files are also handled by libcurtain.  Applications can use > libcurtain directly to sandbox themselves using tags, but the API for > that is more complex than it should be and I'm probably going to make > more changes to it. > > I added a freebsd_simple_sandbox() function directly to libc that tries > to load libcurtain and applies a tag.  The idea is to make it as easy as > possible to add configurable, opportunistic sandboxing to applications > without having to link them to libcurtain.  It can be called multiple > times at different stages of initialization of an application, or for > different sub-processes, etc.  The application just specifies a tag for > each call and the details are in the config files.  Conceivably, there > could be different backends implementing the sandboxing. > > libcurtain also contains the pledge()/unveil() implementation.  On > OpenBSD, pledge/unveil are available directly in libc (with the > declarations in unistd.h), but the portable versions of some OpenBSD > programs have problems if pledge/unveil are available on non-OpenBSD > platforms because they just don't expect that.  After fixing them, maybe > auto-loading wrappers could be added directly to libc too so that they > just work without having to deal with libcurtain dependencies. > > About the kernel-side parts: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Most of the implementation is in a separate mac_curtain module, but it > also needed some changes spread out in the kernel to support it.  That's > what would need to be merged. > > The biggest change is adding "sysfils".  It initially just meant > "syscall filters" but now it's more of a general category of things that > the kernel can do.  Syscalls can be associated with zero or more > required sysfils and some explicit sysfil checks were added in various > places in the kernel as needed.  ucreds have a set of allowed sysfils. > Sysfils are represented as simple bitmaps and checks are fast.  Capsicum > was slightly modified to make use of a sysfil bit to simplify syscall > entry checks. > > Sysfils are meant to be part of the internal kernel API, they're not > exposed to the userland.  The curtain module exposes intermediate > "abilities" instead. > > Some checks that checked for "capability mode" now check for a more > general "restricted mode" instead.  A process is considered in > restricted mode whenever its ucred is missing any sysfil bit. > > MAC handlers were added to let curtain hook into places that didn't have > MAC checks.  Some of those new handlers definitively seem out of place. > The new vnode "walk" functions are more of a low-level mechanism than > just a security policy.  And many of the new handlers want to restrict > access to certain functionality as a whole (e.g. ioctls, sockopts, > procctls, etc) rather than compare labels.  But it seemed like the best > place to add them because MAC already did most of what was needed.  So > I've been treating the MAC framework like it stands for "Modular Access > Checks" or something. > > The curtain permissions are stored in "curtain" objects.  Process ucreds > have their labels point to a curtain.  Curtains have pointers to > "barrier" objects, which contain the hierarchical linkage needed to > restrict access to protected kernel objects. Those kernel objects have > their labels point directly to barriers.  Barriers can outlive their > curtains.  When a ucred loses its last reference from a process, it is > "trimmed" and its label curtain pointer "decays" into a pointer to the > curtain's barrier so that the curtain can be freed (because curtains can > be a few KBs and they can hold vnode references).  A lot of objects hold > references to ucreds, so they could build up a lot without this. > > Processes can sandbox themselves with curtainctl(2).  They have to > specify the full set of permissions they want to retain.  The requested > permissions are then masked with the current curtain (if any).  This > involves dealing with inheritance relationships between permissions (as > the new curtain can have permissions more specific than the old and vice > versa). > > Kernel-side handling of filesystem path unveiling was the hardest part > to deal with (given the "statelessness" of the vnode API) and it kind of > is all a big kludge.  I tried to make it as nice as possible and wrapped > the whole thing behind a MAC API (it used to be a lot worse than that). > > Each directory "unveil" acts like a sort of chroot barrier but with > specific permissions.  There's a per-thread "tracker" with a circular > buffer that remembers the permissions for the previous N looked-up > vnodes.  N only needs to be 2 as far as I can tell (most syscalls only > need 1, but linkat() for example needs 2).  The tracker has weak vnode > references and doesn't need to be cleaned up after syscalls.  namei() > calls the new MAC handlers to manage the tracker during path lookup. > fget*() also adds a tracker entry.  Then the access check MAC handlers > can find permissions for the passed vnodes in the tracker.  This only > works because almost all of the kernel code that work on vnodes first > get a reference from namei()/fget*() and then don't call VOP_LOOKUP() > directly themselves.  It's messy but one good thing with it is that it > usually "fails-secure" if the tracker was mismanaged because it won't > find the vnode in it and it defaults to deny. > > > From nobody Tue Mar 29 17:32:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7B8E61A4EDA5 for ; Tue, 29 Mar 2022 17:32:45 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSc8X1S0cz4hGr for ; Tue, 29 Mar 2022 17:32:44 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qk1-x72a.google.com with SMTP id 1so14662878qke.1 for ; Tue, 29 Mar 2022 10:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=CUd3jkUnKZvbVjOgpcj4qNXvSK/R7Vqwt4RR/kZHwEA=; b=H70hILbzoRMPpxiRHOyCH51fE+WgkyGVSmJNMa28BBTSOyHRirszFQ4I5/HhTzN5je QqCtbsxpP0l//w8iPkrhOXntw3trWV7aCAhVMMcKZ00tAw1TfVDiMqBgiOOOB/w5pt+D rY1D2wNiLx1PABsGcoEXlt72Kc/cYDOj7dymy0Q4nh48/xHGRuwYXITDvw9cJZxPXI1y 1ExHNJqUKIVCUTOx2TNz+eqnwFaHSi4MtliCdGy5SC63v4AjWw7/uQpEtT+jG1xC+Yml zkY3rowjyZjlyX6S+NZ/UqZfl+Hw0cOEDC5/SjyQIfsKfx/OG3DeG9XzJQKeFS/0z6jy UyBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=CUd3jkUnKZvbVjOgpcj4qNXvSK/R7Vqwt4RR/kZHwEA=; b=iPK66bz0ermezRoQ/ItPMJp142ke95kh7kJRxbjWNX7qePFh7JsGFVN1NapWiXcjtN 3wi5DDU+mKEJTdXjSReuU8IY58uq9Ky0h+YgUKXqiAbi6umK0iUn+ifCaVmM3UxqIMMb +h1n3KHbB7hhmsgbyJjhhduD7wAexTcad2Ps7Fi117V338r1TUtli9Yn141zMyXi1got 7NmN9OaiU+DAXlGYFruvr5ddvJRSuy6U0h2uOlXSQ/MeEDYqhKPvyjNBVTJFEGCeDCkf /uFK2t+KE/ice+DLguq3H78wpcUWxORF23jDSOKJIAV089hePJNeZXZZfNCjhohPwa0C DOVQ== X-Gm-Message-State: AOAM5338lcUayCwZkuM1CikgtgG4H1pxAFaDGjDwz90XW5NS6/mKEiGs VJgAP5YJnDLnsDSEkfrvPLXZQ6qgvwk= X-Google-Smtp-Source: ABdhPJyflwnj5hz550HlJ0G03jgz9rOdR2Lat7jOuZA5iPtCE01+PlxD74xVBnuifW2vzsp3RzkQNQ== X-Received: by 2002:a05:620a:25a:b0:67d:43a6:8892 with SMTP id q26-20020a05620a025a00b0067d43a68892mr21233699qkn.659.1648575163215; Tue, 29 Mar 2022 10:32:43 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id 188-20020a3709c5000000b0067b147584c2sm9764208qkj.102.2022.03.29.10.32.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Mar 2022 10:32:42 -0700 (PDT) Message-ID: <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> Date: Tue, 29 Mar 2022 13:32:41 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support To: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> Content-Language: en-US In-Reply-To: <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KSc8X1S0cz4hGr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=H70hILbz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-3.23 / 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:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.23)[-0.226]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/29/22 04:34, David Chisnall wrote: > Hi, > > Does pledge actually require kernel support?  I'd have thought that it > could be implemented on top of Capsicum as a purely userland > abstraction (more easily with libc help, but even with an LD_PRELOADed > library along the lines of libpreopen).  In Verona, we're able to use > Capsicum to run unmodified libraries in a sandbox, for example, > including handling raw system calls: > > https://github.com/microsoft/verona/tree/master/experiments/process_sandbox > > > It would be good to understand why this needs more kernel attack surface. > > David If it can work like that then it's pretty cool.  It could be a lot more secure.  But it's just not the way I went with. Re-implementing so much kernel functionality in userland seems like a lot of work. Because I wanted my module to be able to sandbox (almost) everything that the OS can run.  Including whole process hierarchies that execute other programs and use process management and shared memory, etc.  That's a lot of little details to get right...  So I went with the same route that jails, other MAC modules and even Capsicum are implemented: with access checks in the kernel itself.  And most of these checks were already in place with MAC hooks. pledge()/unveil() are usually used for fairly well-disciplined applications that either don't run other programs or run very specific programs that are also well-disciplined and don't expect too much (unless you just drop the pledges on execve()). Pledged applications usually reduce the kernel attack surface a lot, but you don't run arbitrary programs with pledge (and that wasn't one of its goals AFAIK).  But that's what I wanted my module to be able to do.  I'd say it has become a bit of a weird hybrid between a "container" framework and an exploit mitigation framework at this point.  You can run a `make buildworld` with it, build/install/run random programs isolated in your project directories, sandbox shell/desktop sessions as a whole, etc.  And then within those sandboxes, nested applications can do their own sandboxing on top of it (with this module (and its pledge/unveil compat) or Capsicum (and possibly other compat layers built on top of it)).  The "inner" programs can use more restrictive sandboxes that don't expose as much kernel functionality.  But for the "outer" programs the whole thing slides more towards being "containers"/"jails" (and the more complex it would have been to do purely in userland I believe). From nobody Tue Mar 29 18:14:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE44C1A3A930 for ; Tue, 29 Mar 2022 18:14:31 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSd4l0RvYz4qrs for ; Tue, 29 Mar 2022 18:14:31 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf34.google.com with SMTP id kd21so12107574qvb.6 for ; Tue, 29 Mar 2022 11:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BvSsH8UTqhcTj6ja7QQIcFN717X7ASiLCbSabHnS4sU=; b=ikm74WjqkQGadDH81dPt2iBAL1mmXvPjJML2B1Rr3igAaEoJqIvqDlcW+T5tnFsWaD Lahl8Wfn+xIa5gcgSk+w+gBh2hTRGBNdBxOjJms3tL+Mkv/mPQoKNe1ZVl59h2L4QJzH SGOfYRznTYf7Rm1Ov0qShmN36dOrJoSALdgksRw/2SJCDvPD0YVC2+tqbRHmnSG6LJ+M I7vA5odiZuph44vhk+LR1aOOpl2Zu1h7rWCAQG7zUSI4suLC4rRJs1APzLKLRdaejdW5 dZcv7QwZa0CzEXoaJK2WZNPTluBIgoQ/PPGR/1JyI6+sU6Rrk5gCV/WWtRNVtjFXbrf9 GPjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BvSsH8UTqhcTj6ja7QQIcFN717X7ASiLCbSabHnS4sU=; b=bR02ybQwvxqQSzIFTnMIktaKRS6EzuyuL60kS65y5tApTGqrk3fvlQz+6335PPwFFS DZmNvWvUudJ0SGCpl6k9zGLqluOXch1hNVV9TxQYHP8JHRsr6Jy74RjI0Ys1dCEcI7kl zXYbkM61+5UCcJigI1viUYzQryqXPVv5UkRRyqH1ekKLi2RWApTJCX+mX4RaYp5p2NQP 5dvHWCR5cpEjPosR7cgcJjqotwC8P5NVzbCmJygRPdthDivaf7DIHS1cMFvo2wqR+iPX cLQmCDwCg5lvPekX6radMeAZrXoonVDRFuEo4c5cKEASV42KBkpCVO/Scp5O2Nqnsx/7 KptQ== X-Gm-Message-State: AOAM531czkHk/w1nBTzYV0hCdx6kwjCkHs26pqNmm4uvRvNqQuYpBo18 /fsTwDO+HibKKpt6WW7N8ExErX1yEi/hWQft X-Google-Smtp-Source: ABdhPJwUsMEh2vT/3qHUIQNNFxCUrLbp3AwtAlklvg2Cz2O23I3sXcIyfCsfw1zs3eXE6rN5260Ywg== X-Received: by 2002:a05:6214:23c6:b0:433:8a2:c244 with SMTP id hr6-20020a05621423c600b0043308a2c244mr27890449qvb.88.1648577670256; Tue, 29 Mar 2022 11:14:30 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id v5-20020a05622a144500b002e1c7d027b1sm14950801qtx.66.2022.03.29.11.14.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 11:14:29 -0700 (PDT) Date: Tue, 29 Mar 2022 14:14:28 -0400 From: Shawn Webb To: Mathieu Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nle2gt4bfiwu4icn" Content-Disposition: inline In-Reply-To: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> X-Rspamd-Queue-Id: 4KSd4l0RvYz4qrs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=ikm74Wjq; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-3.38 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.72)[0.720]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f34:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --nle2gt4bfiwu4icn Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote: > Hello list.=A0 Since a while I've been working on and off on a > pledge()/unveil() implementation for FreeBSD.=A0 I also wanted it to be a= ble > to sandbox arbitrary programs that might not expect it with no (or very > minor) modifications.=A0 So I just kept adding to it until it could do th= at > well enough.=A0 I'm still working on it, and there are some known issues = and > some things I'm not sure are done correctly, but overall it's in a very > functional state now. It can run unmodified most utilities and desktop ap= ps > (though dbus/dconf/etc are trouble), server daemons, buildworld and whole > shell/desktop sessions sandboxed. >=20 > https://github.com/Math2/freebsd-pledge > https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md >=20 > It can be broken up in 4 parts: 1) A MAC module that implements most of t= he > functionality.=A0 2) The userland library, sandboxing utility, configs and > tests.=A0 3) Various kernel changes needed to support it (including new M= AC > handlers and extended syscall filtering).=A0 4) Small changes/fixes to the > base userland (things like adding reporting to ps and modifying some > utilities to use $TMPDIR so that they can be properly sandboxed).=A0 So 1= ) and > 2) could be in a port.=A0 And I tried to minimize 3) and 4) as much as > possible. >=20 > I noted some problems/limitations in the CURTAIN-ISSUES file.=A0 At this = point > I'm mostly wondering about the general design being acceptable for merging > eventually.=A0 Because most of this could be part of a port, but not all = of > it.=A0 And the way that it deals with filesystem access restrictions in > particular is kludgy.=A0 So any feedback/testing welcome. >=20 > It still lacks documentation (in part because I'm not sure of what could > still change) so I'm going to give an overview of it here and show some > examples and that's going to be the documentation for now.=A0 And I'll > describe the kernel changes that it needed.=A0 So that's going to be a bi= t of > a long email. Hey Mathieu, Thanks a lot for working on this! I'm incredibly excited to see this work progress and mature. I'd love to start reviewing your work. One thing that would make it easier to review would be if you used a feature branch rather than relying on the main branch. That way, a simple `git diff` command could be used to generate a diff between your code and stock freebsd. If you'd like an example of that, take a look at HardenedBSD's repo[0]. We have two relevant branches: freebsd/current/main <- FreeBSD's sources hardened/current/main <- HardenedBSD's patches applied on top of FreeBSD's sources Users can then simply run `git diff origin/freebsd/current/main` to see all the changes we've made (assuming the user is currently working on the hardened/current/master branch.) [0]: https://git.hardenedbsd.org/HardenedBSD/hardenedbsd Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --nle2gt4bfiwu4icn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmJDTIIACgkQ/y5nonf4 4foWABAAhOzaiAR80J3PwjwIJEdbD3i74BXyi4TkqrhSlcuOFz+i7eoYbjYYrXyZ K4bKvziS+zeAB2Hml80+sa2f/Zw2pJHIenDkmQPPB1pSeGVAyxB4CoYXbkcQtctN hch2cbyBZswCv9U4Wc4KvxMys87R57I6oyX+DSPeZVfAJUjWbvbvXjakdEhyoGUj EN0MqtEVcuMStliDTlfZuPOTyQMP+VOTWNyl+6vDenxce/OGmw65Kyd7g8v8sfbZ hkP0s1Npye+ApDCdwG9SCQRkrZwoYdVNlA48flf5Q7zDRfVSnV2mEfbhjmHo5qya dVVihLkLVewETSSap/WtRlg2tp7e04lzsfH8NgD8ICZE16gOFlhbnykNNeOkhmqZ SyN8t5JOzR77KlPbp3qqymOxdWBYyt15Nq4tt1aerRVVFUOIIJpvNQL8NAMI1uzi u3KB92Ks30Odewc11ax0IXn90yxLmDQ99M9TMW02mDJUpuWKH0tHisxd+nk/wC+J 1OOcr4+X2E72//V0M6QQk43XbOHH5sSnIyM5saLL0gCfREHI3KgH/sxj0sr5lscv jk/FNiErYRKPg4F+Wk5FS20R8HDyMQmhsMkWCAVe8MvWTUsdCjSIy/wykJhd01S0 +Ss5831DOHTJU2j98livG2FCOxO2TPDAy74hY6mPMxlFxMY73Tk= =kGuv -----END PGP SIGNATURE----- --nle2gt4bfiwu4icn-- From nobody Tue Mar 29 19:46:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 67FEF1A527E9 for ; Tue, 29 Mar 2022 19:46:12 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSg6W3W7Mz57N6 for ; Tue, 29 Mar 2022 19:46:11 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qv1-xf2b.google.com with SMTP id ke15so15220284qvb.11 for ; Tue, 29 Mar 2022 12:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=FK+l0wY/Xc0mJXewc+qD0U/ZhK8xyuhpHVXww6X7Qcc=; b=OJ6XGQBbFYCZzuIgehU7Obtn8xu5eOHI/LOZvBmPKTVgh4jsTItbMBT6C4owHE5sKK rsIuDh3N80fxpRqFlY51xTRaevXUGN+1fnWtx97z9kSwkiFB4nL3SabldHjhjJV2HdlP qAL93m4JZISeJkF4wVkV1mWuiLmGzSh6emzQV2YK2hy97FUolzK0Pm5QUCjPE6t2hBdl 8GUUphpRyIGz1sZiFKpGmFhIZqUbQuFzr8f7j6HKp5k/jgDjJq/JpzX4h2c5uYsQrqW/ XmuVoF5gfwdaZO7k8qT0qMaLQsfol1ILABdQCEeyrgN1FdtpNXH4liI5To/hUStz4Zbb JhdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=FK+l0wY/Xc0mJXewc+qD0U/ZhK8xyuhpHVXww6X7Qcc=; b=A1A8GQGWxGFPaC05WmgDRTeqPrrJ661xQCYppEFTWkNc2nkX6IWHCrvWApDJYMOWSs PhIS/6DutJ3nKQwgWp2Wh8vj12GSrTy6ikL2EwzsvUJ8V/0HQ6Vsk7qfHvo+reX+1uRe +/eu+t+Fqesjj9eOYW1I5OyPFktzgvqOYgKywFfoN5h1FAE9dXJVESJ4zWjloJ2b7rup n7JQQ6EJL3lpwg01ejG2WwJuvTHrpA0tVrxYWd1fAvnuEVErCRqyEjxUE6MoC4kkLpkn fS4h51Zh4Usr7c1jt8QZbmrWkb6n3Iq0HN6cU7wBTZv8VCJcCKoJjJNckNW6jMoh1wrz ZJ6g== X-Gm-Message-State: AOAM531V2eQMyj7tA61CtqundUNOmD3wJD3a+H7RRYPCyFkvrl26CPJh 8mBG/Rb9swdHRa3uYfgOtfYQ+RPB9kg= X-Google-Smtp-Source: ABdhPJw+9XUjtDPlHph/YMmGCEDX4ZmgVAYnWA58SPZFuSmPEnKy5tA7GxLiLnAL44T8hQ5ZC4cXCQ== X-Received: by 2002:a05:6214:20e4:b0:441:8031:9152 with SMTP id 4-20020a05621420e400b0044180319152mr22588592qvk.115.1648583170863; Tue, 29 Mar 2022 12:46:10 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id n143-20020a37a495000000b0067b12bc1d7bsm9971750qke.13.2022.03.29.12.46.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Mar 2022 12:46:10 -0700 (PDT) Message-ID: Date: Tue, 29 Mar 2022 15:46:09 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Shawn Webb Cc: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KSg6W3W7Mz57N6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=OJ6XGQBb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::f2b as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2b:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/29/22 14:14, Shawn Webb wrote: > On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote: >> Hello list.  Since a while I've been working on and off on a >> pledge()/unveil() implementation for FreeBSD.  I also wanted it to be able >> to sandbox arbitrary programs that might not expect it with no (or very >> minor) modifications.  So I just kept adding to it until it could do that >> well enough.  I'm still working on it, and there are some known issues and >> some things I'm not sure are done correctly, but overall it's in a very >> functional state now. It can run unmodified most utilities and desktop apps >> (though dbus/dconf/etc are trouble), server daemons, buildworld and whole >> shell/desktop sessions sandboxed. >> >> https://github.com/Math2/freebsd-pledge >> https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md >> >> It can be broken up in 4 parts: 1) A MAC module that implements most of the >> functionality.  2) The userland library, sandboxing utility, configs and >> tests.  3) Various kernel changes needed to support it (including new MAC >> handlers and extended syscall filtering).  4) Small changes/fixes to the >> base userland (things like adding reporting to ps and modifying some >> utilities to use $TMPDIR so that they can be properly sandboxed).  So 1) and >> 2) could be in a port.  And I tried to minimize 3) and 4) as much as >> possible. >> >> I noted some problems/limitations in the CURTAIN-ISSUES file.  At this point >> I'm mostly wondering about the general design being acceptable for merging >> eventually.  Because most of this could be part of a port, but not all of >> it.  And the way that it deals with filesystem access restrictions in >> particular is kludgy.  So any feedback/testing welcome. >> >> It still lacks documentation (in part because I'm not sure of what could >> still change) so I'm going to give an overview of it here and show some >> examples and that's going to be the documentation for now.  And I'll >> describe the kernel changes that it needed.  So that's going to be a bit of >> a long email. > Hey Mathieu, > > Thanks a lot for working on this! I'm incredibly excited to see this > work progress and mature. Hey! Thanks, nice to hear that. > I'd love to start reviewing your work. One thing that would make it > easier to review would be if you used a feature branch rather than > relying on the main branch. That way, a simple `git diff` command > could be used to generate a diff between your code and stock freebsd. > > If you'd like an example of that, take a look at HardenedBSD's > repo[0]. We have two relevant branches: > > freebsd/current/main <- FreeBSD's sources > hardened/current/main <- HardenedBSD's patches applied on top of > FreeBSD's sources > > Users can then simply run `git diff origin/freebsd/current/main` to > see all the changes we've made (assuming the user is currently working > on the hardened/current/master branch.) > > [0]: https://git.hardenedbsd.org/HardenedBSD/hardenedbsd I gotta be honest, I'm never too sure if I understand what git is doing. So I try to keep it simple. I'm going to create a "stock" branch and keep it pointing *exactly* to what I've been merging from. Lemme know if that works. I'm not too sure I'd be using a more elaborate branch layout correctly... This is going to be a lot of work to review so yeah I'd try to set this up to make it easier but I could just make it worse too heh. The way I've been comparing my changes to stock so far was with 3 dots diff: `git diff freebsd/main...main`. Also, I gotta warn you, the lack of comments is just terrible in some places. This project turned out to be a lot more complicated than I had hoped. Correctly handling "slots" and inheritance/masking between sandboxes was harder than I thought. Most of the complexity are in the library and MAC module. But I think it probably was necessary complexity to get the (mostly) seamlessly nestable sandboxing system that I wanted... > > Thanks, > From nobody Tue Mar 29 21:12:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4C3BE1A42091 for ; Tue, 29 Mar 2022 21:12:33 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSj283b4Bz3gyV for ; Tue, 29 Mar 2022 21:12:32 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x82a.google.com with SMTP id c4so16472946qtx.1 for ; Tue, 29 Mar 2022 14:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=GZcmhVLyhCAPTCqZ8QpFADjls7+4IC0Ik102W8Xe+24=; b=C/ahKsX0QHgdxnvXDcoMqkKOom8EhdzofENnHj9qPuEK2GLVG80wuc2rMiUzF+gxj4 DrhOSFdx6GxrMQ/rjrVWqywhdSjRjSLcuNkn0qIinpeNz5Z9bIoOF4pygzVX902LCva6 a6XnUcqkg1p7fCgB+d/+UNIsVe0DXSsItyG9P6//ssArPt8RQAeUysDYOrhifC4ZL+ww G0aBeY8V8taRLBJ1hI8pnPFKKirfH1wZ1vAzqAOxHJh1gE3So+Br3rUFzynQbeHIqkUC lNz95B7Fjl2d9zwtFxfuw7MDFQq71Xba2iKOCCjoJJjQNWvOUQhsr3jZGLNB++0wzKm6 joZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=GZcmhVLyhCAPTCqZ8QpFADjls7+4IC0Ik102W8Xe+24=; b=12a1jhr6OswV29J80NParwMvdK66bSgKp/cbcGSrd4KlbgnMLvx/8tvx7br4bIxocc 4SY1uErr/KeKsIV0CH+R9+/RyCYBA0ZzeI4m/oRDKtun/glLeSfZqToqNBo6v9sRA5bx ocSr37+ZzSt04gYHp9UbsqGiFHodrQgvZTrnV6nHb+yrIPvrynZzB8s6gHJMmbdQUlGi 93bpog8SNsgxbVOtRSlK7jk0QqyYIZDWzvLLR+PXu4C/k1XZ1y4ho/d8jSkMFJ6XVWAs Kz5XEBdn/ZQ4Qbvmc5JT7mttMn88HlP1NCCDz+3DmyrWhcwkbTCPjKeWbf3dWjLdKMQ7 w1EA== X-Gm-Message-State: AOAM531Ck5zcxEDijfARXm4ZXjdNxDa+KUD7sduUbVIALtzHEq6b9pNn lqvye3TIBiK2ryIWztYTabnANQ== X-Google-Smtp-Source: ABdhPJwthrkKct8p46VepY56HQbksA+niMJlxMnc+b3H2UjTToYYaLVg8GWCsoRbw2gj/AcMBy6Tow== X-Received: by 2002:ac8:7f92:0:b0:2e1:c9ca:cbbc with SMTP id z18-20020ac87f92000000b002e1c9cacbbcmr29735982qtj.103.1648588351773; Tue, 29 Mar 2022 14:12:31 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id r17-20020a05620a299100b00680b43004bfsm8678507qkp.45.2022.03.29.14.12.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 14:12:31 -0700 (PDT) Date: Tue, 29 Mar 2022 17:12:30 -0400 From: Shawn Webb To: Mathieu Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220329211230.2dufhnikhaqyovwc@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r56sicskwccqyk53" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KSj283b4Bz3gyV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="C/ahKsX0"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-3.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.850]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --r56sicskwccqyk53 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2022 at 03:46:09PM -0400, Mathieu wrote: > On 3/29/22 14:14, Shawn Webb wrote: > > On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote: > > > Hello list.=A0 Since a while I've been working on and off on a > > > pledge()/unveil() implementation for FreeBSD.=A0 I also wanted it to = be able > > > to sandbox arbitrary programs that might not expect it with no (or ve= ry > > > minor) modifications.=A0 So I just kept adding to it until it could d= o that > > > well enough.=A0 I'm still working on it, and there are some known iss= ues and > > > some things I'm not sure are done correctly, but overall it's in a ve= ry > > > functional state now. It can run unmodified most utilities and deskto= p apps > > > (though dbus/dconf/etc are trouble), server daemons, buildworld and w= hole > > > shell/desktop sessions sandboxed. > > >=20 > > > https://github.com/Math2/freebsd-pledge > > > https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md > > >=20 > > > It can be broken up in 4 parts: 1) A MAC module that implements most = of the > > > functionality.=A0 2) The userland library, sandboxing utility, config= s and > > > tests.=A0 3) Various kernel changes needed to support it (including n= ew MAC > > > handlers and extended syscall filtering).=A0 4) Small changes/fixes t= o the > > > base userland (things like adding reporting to ps and modifying some > > > utilities to use $TMPDIR so that they can be properly sandboxed).=A0 = So 1) and > > > 2) could be in a port.=A0 And I tried to minimize 3) and 4) as much as > > > possible. > > >=20 > > > I noted some problems/limitations in the CURTAIN-ISSUES file.=A0 At t= his point > > > I'm mostly wondering about the general design being acceptable for me= rging > > > eventually.=A0 Because most of this could be part of a port, but not = all of > > > it.=A0 And the way that it deals with filesystem access restrictions = in > > > particular is kludgy.=A0 So any feedback/testing welcome. > > >=20 > > > It still lacks documentation (in part because I'm not sure of what co= uld > > > still change) so I'm going to give an overview of it here and show so= me > > > examples and that's going to be the documentation for now.=A0 And I'll > > > describe the kernel changes that it needed.=A0 So that's going to be = a bit of > > > a long email. > > Hey Mathieu, > >=20 > > Thanks a lot for working on this! I'm incredibly excited to see this > > work progress and mature. >=20 >=20 > Hey! Thanks, nice to hear that. >=20 >=20 > > I'd love to start reviewing your work. One thing that would make it > > easier to review would be if you used a feature branch rather than > > relying on the main branch. That way, a simple `git diff` command > > could be used to generate a diff between your code and stock freebsd. > >=20 > > If you'd like an example of that, take a look at HardenedBSD's > > repo[0]. We have two relevant branches: > >=20 > > freebsd/current/main <- FreeBSD's sources > > hardened/current/main <- HardenedBSD's patches applied on top of > > FreeBSD's sources > >=20 > > Users can then simply run `git diff origin/freebsd/current/main` to > > see all the changes we've made (assuming the user is currently working > > on the hardened/current/master branch.) > >=20 > > [0]: https://git.hardenedbsd.org/HardenedBSD/hardenedbsd >=20 >=20 > I gotta be honest, I'm never too sure if I understand what git is doing. = So > I try to keep it simple. I'm going to create a "stock" branch and keep it > pointing *exactly* to what I've been merging from. Lemme know if that wor= ks. > I'm not too sure I'd be using a more elaborate branch layout correctly... > This is going to be a lot of work to review so yeah I'd try to set this up > to make it easier but I could just make it worse too heh. The way I've be= en > comparing my changes to stock so far was with 3 dots diff: `git diff > freebsd/main...main`. I quickly forked your repo, and created two branches: freebsd/current/main and curtain/current/main: https://github.com/lattera/freebsd-pledge So now freebsd/current/main can be updated first, then you can merge in freebsd/current/main into curtain/current/main. Hopefully you find that useful. >=20 > Also, I gotta warn you, the lack of comments is just terrible in some > places. This project turned out to be a lot more complicated than I had > hoped. Correctly handling "slots" and inheritance/masking between sandbox= es > was harder than I thought. Most of the complexity are in the library and = MAC > module. But I think it probably was necessary complexity to get the (most= ly) > seamlessly nestable sandboxing system that I wanted... Totally understood. This is a work in progress and there's likely a lot to still be worked out (as you've already mentioned.) My work load at ${DAYJOB} is a bit tight at the moment, but I do plan on taking some time off soon. During that time off, I'll start peeking at the code. I'll make sure to keep an eye on the project in the meantime, though. Thanks again! --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --r56sicskwccqyk53 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmJDdjwACgkQ/y5nonf4 4fqEuQ//ZlThk02cVv8qeujzauPDaXyVJyA1sb1RZMKOkVwyAxvLW1jkSb3EADga eEw70NzsUU7WNHWiRykec4cChRKOm1NuTiK5+jrxIPZD6odn6HHqdIohi2bOTl0t 1FnqAvVR57gEKBIwDBFnf/yB2YGJzBQ5Fh36ADl+e1Um1u2abY/ZoG1vImglle4R yALYAd9qzWWd7j0sM7S3nSTKybEAdtgttKJGaL8ym/kI7g93gBZ5jGNWSromNCi4 a+ZslPTfO4GFWwHVgdgiC/AEkiExH1XbG9c/yD4dAL9J9m0lxXPh6NCdsIu3iltr Kb0qPZs4qc9g5aEa2DPLJC/IZDcYUJeVvf8Lz3FHBF4pNvGb9wvw+IhwVwWpHq+W qTfawaGtuG6ZZW51xoQy/oB9dCwkApP4Oe0MIvHjaG4IKhm+w3j0phwdsZ/isj51 Swtl9Swm9zOh6RW5W0xcjHMkbYdSFGS7/4MmrzK8epsRN3gdEYzf5lZ06piu4KEn nQq2LcU7ewV0F8nBJ4PlNrq+42a+0yrxiDwY1XPPZHoCWwOHZ7vybhOloaP8KUgv Yx9IwI3UUkxUOYL+C+uKhcKHvpYgW792YVce8dsQpqKI7GrwXjr6S37pUUe6tROX tAIfi/e9IyWbmu/bJ9hZoGdKhlBPIxYk9eZqje3voQnabll8PtE= =Lny8 -----END PGP SIGNATURE----- --r56sicskwccqyk53-- From nobody Tue Mar 29 23:27:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECAC21A3DC7E for ; Tue, 29 Mar 2022 23:27:59 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KSm2Q4Y28z4dNd for ; Tue, 29 Mar 2022 23:27:58 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qt1-x833.google.com with SMTP id b18so16703958qtk.13 for ; Tue, 29 Mar 2022 16:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=quQf/LEBBYM+rB9MEVZwcyXgy9EIqnonXf66hMcfskA=; b=hB0xBJCxzkiFks3YTImovLVjciyOdtwB30sHlvQooPQv0zsnpul8cUzw3DIwRaPJop 2sSr3A/dR8OZ9zozeRtlR3RavBc3KTzjbArH+lrp64aL6VzNOSS6Ld2NzCj4JEwSwcSx t/eLKHdYfTi19MrwXPpr4hN+d0dU5eWCNq+Ubcul9T8R+4Jsixap4hwi3okQB5Cc2tJI laFo/QP8oq0hHulvZju+QqyP9eMRakh0bfc5pmGGVeZAqSFcGM5aY8/psu6fTQKM1LeZ WsXl3mQ6X9Lz76S8mNKnMRZZUe+Fdg7jMlf6R26DU1D+/jgMhyy+EHiG+Xasj50YT+9A s9aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=quQf/LEBBYM+rB9MEVZwcyXgy9EIqnonXf66hMcfskA=; b=0samX9otyDTZuaMuipXz3/u//RIBtnbD50iOJv5NJPzBZbOwBBz/I9blsH1YtgNvP4 P8495893Z+Vss/98Kg1PyIiYwVD4R+GYWH2Uhpn+qS1DoupEBmGmp/8FKb4Eybg2INya qcUdN2IGhrJ69UsP37HXxFDJ1WbfoVA56tDPSGtjaDE8obvW714u3QRxl1uo53M4cjY7 IA0h7U3c88d+wkGijMAKynN3oU1iILSHxmUJCpFgroOQ+6RkggQxxi87aRUSnod/Woku 4NE1gP8gs3GKJmxeItgWMkzBYoVrq5tJX19CxdaY5gCPEI/qe9RPko96gLy656APCZfH Z8Jw== X-Gm-Message-State: AOAM5334nDM84D/i8DBP5/+eDubTpaozZj1Z/YzIj4HYozig6JgxagP0 9lXcH7rwsyO7+3sUA3ECVcI= X-Google-Smtp-Source: ABdhPJwpb0AxP3uVItjddSQ4kA3WbU8kCxcxo1lR4PtglRy5kyPceMGCb5L3/QBB1djLKHDJGgXWSg== X-Received: by 2002:a05:622a:3c7:b0:2e1:cdf9:666b with SMTP id k7-20020a05622a03c700b002e1cdf9666bmr30389949qtx.438.1648596477930; Tue, 29 Mar 2022 16:27:57 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id b17-20020a05622a021100b002e1f86db385sm15865351qtx.68.2022.03.29.16.27.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Mar 2022 16:27:57 -0700 (PDT) Message-ID: Date: Tue, 29 Mar 2022 19:27:56 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Shawn Webb Cc: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220329181428.n3db2x57nnn64yfx@mutt-hbsd> <20220329211230.2dufhnikhaqyovwc@mutt-hbsd> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <20220329211230.2dufhnikhaqyovwc@mutt-hbsd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KSm2Q4Y28z4dNd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hB0xBJCx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::833 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-3.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.406]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::833:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/29/22 17:12, Shawn Webb wrote: > On Tue, Mar 29, 2022 at 03:46:09PM -0400, Mathieu wrote: >> On 3/29/22 14:14, Shawn Webb wrote: >>> On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote: >>>> Hello list.  Since a while I've been working on and off on a >>>> pledge()/unveil() implementation for FreeBSD.  I also wanted it to be able >>>> to sandbox arbitrary programs that might not expect it with no (or very >>>> minor) modifications.  So I just kept adding to it until it could do that >>>> well enough.  I'm still working on it, and there are some known issues and >>>> some things I'm not sure are done correctly, but overall it's in a very >>>> functional state now. It can run unmodified most utilities and desktop apps >>>> (though dbus/dconf/etc are trouble), server daemons, buildworld and whole >>>> shell/desktop sessions sandboxed. >>>> >>>> https://github.com/Math2/freebsd-pledge >>>> https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md >>>> >>>> It can be broken up in 4 parts: 1) A MAC module that implements most of the >>>> functionality.  2) The userland library, sandboxing utility, configs and >>>> tests.  3) Various kernel changes needed to support it (including new MAC >>>> handlers and extended syscall filtering).  4) Small changes/fixes to the >>>> base userland (things like adding reporting to ps and modifying some >>>> utilities to use $TMPDIR so that they can be properly sandboxed).  So 1) and >>>> 2) could be in a port.  And I tried to minimize 3) and 4) as much as >>>> possible. >>>> >>>> I noted some problems/limitations in the CURTAIN-ISSUES file.  At this point >>>> I'm mostly wondering about the general design being acceptable for merging >>>> eventually.  Because most of this could be part of a port, but not all of >>>> it.  And the way that it deals with filesystem access restrictions in >>>> particular is kludgy.  So any feedback/testing welcome. >>>> >>>> It still lacks documentation (in part because I'm not sure of what could >>>> still change) so I'm going to give an overview of it here and show some >>>> examples and that's going to be the documentation for now.  And I'll >>>> describe the kernel changes that it needed.  So that's going to be a bit of >>>> a long email. >>> Hey Mathieu, >>> >>> Thanks a lot for working on this! I'm incredibly excited to see this >>> work progress and mature. >> >> Hey! Thanks, nice to hear that. >> >> >>> I'd love to start reviewing your work. One thing that would make it >>> easier to review would be if you used a feature branch rather than >>> relying on the main branch. That way, a simple `git diff` command >>> could be used to generate a diff between your code and stock freebsd. >>> >>> If you'd like an example of that, take a look at HardenedBSD's >>> repo[0]. We have two relevant branches: >>> >>> freebsd/current/main <- FreeBSD's sources >>> hardened/current/main <- HardenedBSD's patches applied on top of >>> FreeBSD's sources >>> >>> Users can then simply run `git diff origin/freebsd/current/main` to >>> see all the changes we've made (assuming the user is currently working >>> on the hardened/current/master branch.) >>> >>> [0]: https://git.hardenedbsd.org/HardenedBSD/hardenedbsd >> >> I gotta be honest, I'm never too sure if I understand what git is doing. So >> I try to keep it simple. I'm going to create a "stock" branch and keep it >> pointing *exactly* to what I've been merging from. Lemme know if that works. >> I'm not too sure I'd be using a more elaborate branch layout correctly... >> This is going to be a lot of work to review so yeah I'd try to set this up >> to make it easier but I could just make it worse too heh. The way I've been >> comparing my changes to stock so far was with 3 dots diff: `git diff >> freebsd/main...main`. > I quickly forked your repo, and created two branches: > freebsd/current/main and curtain/current/main: > > https://github.com/lattera/freebsd-pledge > > So now freebsd/current/main can be updated first, then you can merge > in freebsd/current/main into curtain/current/main. Hopefully you find > that useful. Ok I think I get it. I'm being confused with what rearranging branches means for a cloned repo on github... I'm sure it's not that complicated but I'm gonna have another look at it later more carefully to make sure I don't break everything. I just noticed that I have a zillion "users"/"projects" branches in that github repo too. They must be from before main FreeBSD repo switched to git. That repo was cloned a while ago. And they're ALL out of date. Ah, I was probably supposed to click an "update upstream" button somewhere on github to keep all of this synchronized... Yeah I'm gonna clean this up and use your branch structure. > >> Also, I gotta warn you, the lack of comments is just terrible in some >> places. This project turned out to be a lot more complicated than I had >> hoped. Correctly handling "slots" and inheritance/masking between sandboxes >> was harder than I thought. Most of the complexity are in the library and MAC >> module. But I think it probably was necessary complexity to get the (mostly) >> seamlessly nestable sandboxing system that I wanted... > Totally understood. This is a work in progress and there's likely a > lot to still be worked out (as you've already mentioned.) Yes. But (hopefully) I think I'm done redesigning it and changing how it integrates with the rest of the kernel (I had tried a few approaches already...). Which should hopefully mean less merge conflicts happening. I'll have a look at what the conflicts are like with HardenedBSD's main after rearranging my branches. > > My work load at ${DAYJOB} is a bit tight at the moment, but I do plan > on taking some time off soon. During that time off, I'll start peeking > at the code. I'll make sure to keep an eye on the project in the > meantime, though. Alright! Lemme know how this goes. I'd be glad to see this merged in HardenedBSD too. For FreeBSD I was thinking most of this could become a port, but there might be advantages in merging the whole thing in base to make it easier to use sandboxing more places (like base daemons, rc.d/periodic scripts, maybe login.conf support for it, etc). > Thanks again! > Sure thing From nobody Wed Mar 30 07:22:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 339711A4326E for ; Wed, 30 Mar 2022 07:22:14 +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 4KSyYf13k1z4l8F; Wed, 30 Mar 2022 07:22:14 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648624934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qki8StSxVbALlhZ0WiaKqsukZ0wRKlizcdhU9hzzr+U=; b=cN7mE85cBZ3ywUrXmJX0IAfQcrCAVvqp+OoDNt9mTy8SI1dYe4vR6btZDC6CiQqzjge7z6 cz9mBrDumYGsWpxJHgQY8m69NeWoTXizoWWh2TfxTaSsU605s04zKDReOBza8+gmnBeiRH 127FTTcRS5dopoi+Gg8mgmBEY4rFeKk0nGGsD+4z9sluNQGw9KbZTB0mIHQvfHv24bxD62 G6icNiEgT12kY/2OAb2jbsrgK8dqtW8+7Vusi23aZHEd+j+IRXaRKL/71HsKePIySe/HDN ppbydFEWOHcXNQe34Ls08CDoUtjj01U9mi09BACqMnieLFhksy+9QTkIC8dB8w== 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 AF1C52D63; Wed, 30 Mar 2022 07:22:13 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id CC63A48984; Wed, 30 Mar 2022 09:22:10 +0200 (CEST) Date: Wed, 30 Mar 2022 09:22:10 +0200 From: Baptiste Daroussin To: Mathieu Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220330072210.icontj4n7hcqwtql@aniel.nours.eu> References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648624934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qki8StSxVbALlhZ0WiaKqsukZ0wRKlizcdhU9hzzr+U=; b=fF+oSMjF/vmOEuk1KlqScXmnsx3P8LhIbMxqI1tFxXi8heghIxKfiXHz/oOg0mMBWzhJFh HCVtJ9j8OS20kK4r2yFUOVXb6Bd2RaffsH2AUV6i85uXH6nHTj0ZV1IPcjD1w+W2AI9OgN 7CNGP3cg9dvjbAfCVOyr0YEMNeQxSL7qMGyJszyZbraTsV6TINrdGjuCOjbv5zfkc23OAI PNymbjVfvNOKy5ljwl9q0vD19dXNE/LtgMSO043v1eTeoMbgY5+EplV1xpAv9HLnYp0Up9 gi6UnUO23M1/aUKPe/ZTHVud8OqF3C0Ztb+DZY4nxaWvzyAr1bjbbMTChXDQgQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648624934; a=rsa-sha256; cv=none; b=tXf4amI+hlRpOLHLyPBczSDHGaARUEYcnsZd7f0TDpo3L6dBHpdtTjKLNGnAvkB0/8Ic4M nTyNo+AG8iWrumSbG/ElHfg3SWb0+IpmSOyJMrMFHrdjAAEmxHXm/FuQoTSxuFLDjtJe7R 5UxQU5H7+TT8RjCQdq/SIB5lTczvWszvfkXfHjbTV6D/YdjBRL3rI4uZEBqGyuAxP1kbzk esIaT3VxXFCjRDdbX7JugrhkrQMwx6VelzCwLMuPkc/e1EYZifnr2xRy2dqsuAgPvFZUK+ 0dXuoBaC3OabbQ9NWmm6G8DQnIKvrdGxNSU+eUH3SexbERNckeVYSjUDsXQdag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Mar 28, 2022 at 05:37:44AM -0400, Mathieu wrote: > Hello list.  Since a while I've been working on and off on a > pledge()/unveil() implementation for FreeBSD.  I also wanted it to be able > to sandbox arbitrary programs that might not expect it with no (or very > minor) modifications.  So I just kept adding to it until it could do that > well enough.  I'm still working on it, and there are some known issues and > some things I'm not sure are done correctly, but overall it's in a very > functional state now. It can run unmodified most utilities and desktop apps > (though dbus/dconf/etc are trouble), server daemons, buildworld and whole > shell/desktop sessions sandboxed. > > https://github.com/Math2/freebsd-pledge > https://github.com/Math2/freebsd-pledge/blob/main/CURTAIN-README.md > > It can be broken up in 4 parts: 1) A MAC module that implements most of the > functionality.  2) The userland library, sandboxing utility, configs and > tests.  3) Various kernel changes needed to support it (including new MAC > handlers and extended syscall filtering).  4) Small changes/fixes to the > base userland (things like adding reporting to ps and modifying some > utilities to use $TMPDIR so that they can be properly sandboxed).  So 1) and > 2) could be in a port.  And I tried to minimize 3) and 4) as much as > possible. > > I noted some problems/limitations in the CURTAIN-ISSUES file.  At this point > I'm mostly wondering about the general design being acceptable for merging > eventually.  Because most of this could be part of a port, but not all of > it.  And the way that it deals with filesystem access restrictions in > particular is kludgy.  So any feedback/testing welcome. > > It still lacks documentation (in part because I'm not sure of what could > still change) so I'm going to give an overview of it here and show some > examples and that's going to be the documentation for now.  And I'll > describe the kernel changes that it needed.  So that's going to be a bit of > a long email. > > What it can do: > ~~~~~~~~~~~~~~~ > > It can restrict syscalls and various abilities (by categories that were > based on OpenBSD's pledge promises), ioctls, sysctls, socket options/address > families, priv(9) privileges, and filesystem access by path.  It can be used > at the same time as jails and Capsicum (their restrictions are also enforced > on top of it). > > It can be used in a nested manner.  A program that inherits sandbox > restrictions can do its own internal sandboxing or sandbox programs that it > run (which can then do the same, etc).  The permissions of new sandboxes are > always a subset of the inherited sandbox. > > Certain kernel operations are protected by "barriers" which only allow a > sandboxed process to operate on kernel objects that were created by itself > or a descendant sandbox.  There are barriers for > inspecting/signaling/debugging processes, POSIX/SysV IPC objects, PTYs, > etc.  Barriers have their own hierarchy which can diverge from the process > hierarchy. > > Restrictions can be specified in configuration files and can be associated > with named "tags".  Tags are assumed to match application names, they're > prefixed with "_" when they don't (just the convention I've been using so > far).  Enabling a tag may cause other tags to be enabled depending on > configurations.  Permissions associated with different tags are merged in a > purely additive manner.  Configurations can be spread in multiple files and > directories (/usr/local/etc/curtain.{conf,d} can be used for packages, > ~/.curtain.{conf,d} for user customizations).  It'll check the .d > directories for files named after the enabled tags. > > Usage examples: > ~~~~~~~~~~~~~~~ > > curtain(1) is the wrapper utility to sandbox arbitrary programs. Default > permissions are in /etc/defaults/curtain.conf and /etc/curtain.conf. > > Here a bunch of examples.  A bit random, but they demonstrate a lot of the > functionality. > > $ curtain id > > Not very exciting, but it works.  The default permissions don't give it > access to the user DB so it only shows numeric IDs.  It can be given access > with the "_pwddb" tag: > > $ curtain -t _pwddb id > > It's possible to nest sandboxes, but it needs the "curtain" tag because the > curtain config files are not unveiled by default (they could be though, > maybe they should be...). > > Here, id cannot read the user DB because the outer sandbox doesn't allow it: > > $ curtain -t curtain curtain -t _pwddb id > > But this way it can: > > $ curtain -t curtain -t _pwddb curtain -t _pwddb id > > Starts a sandboxed shell session with access to ~/work in a clean > environment: > > $ mkdir -p ~/work && curtain -p ~/work:rwx -S > > You'll probably miss your dotfiles though.  If you browse around you'll see > what paths get unveiled by default. > > If you try to list processes: > > $ curtain ps -ax > > You'll just see the ps process itself.  It can be allowed to see processes > outside of it like that: > > $ curtain -d ability-pass:ps ps -ax > > But it will not be allowed to signal, reprioritize or debug them (there are > other "abilities" for that).  The "-pass" means to allow the ability in a > "passthrough" manner (beyond the sandbox's barrier).  Visibility could also > be blocked at an outer sandbox's barrier, like so: > > $ curtain -t curtain curtain -d ability-pass:ps ps -ax > > Give read-only access to the current directory and list files: > > $ curtain -p . ls > > If you have $CLICOLOR set, it may look less colorful than usual. curtain(1) > is a bit paranoid and will filter out most control characters written to the > TTY by default (and set $TERM to "dumb").  They can be let through with -R: > > $ curtain -R -p . ls > > And -T can be used to stop it from doing PTY wrapping altogether and give > the program direct access to the TTY (which is less secure, but there are > ioctl restrictions). > > Per-path permissions can be specified after a ":".  More specific paths > override the permissions of less specific paths. > > $ curtain -p .:rw -p ./secret: -p ./dev:rwx -p ./data:r ... > > Then those paths would have those permissions: >     ./:rw >     ./123:rw >     ./secret: >     ./dev:rwx >     ./dev/123:rwx >     ./data:r >     ./data/123:r > > As an example of how nested sandboxing is handled, if you were then to do > this within this sandbox (don't forget to give it the "curtain" tag): > > $ curtain -p .:r -p ./dev:rx -p ./data:rw ... > > Then the permissions would end up being: >     ./:r >     ./123:r >     ./secret: >     ./dev:rx >     ./dev/123:rx >     ./data:r >     ./data/123:r > > root processes can be sandboxed too.  Some privileges are allowed by default > (which is similar to the set of privileges allowed by jails), but most are > denied.  As are accesses to most /dev and /etc files.  For example, tcpdump > will not be able to use bpf(4): > > # curtain tcpdump > > But there's a tag for that: > > # curtain -t _bpf tcpdump > > Something else that won't work: > > $ curtain node -e 'console.log(2+2)' > > It wants to do a PROT_EXEC mprotect(2) which is not allowed by default.  By > default, PROT_EXEC is only allowed when mmap(2)'ing files that are unveiled > for execution. > > $ curtain -d ability:prot_exec node -e 'console.log(2+2)' > > Just what is allowed by default?  Well it's kind of arbitrary and messy and > there are 10 levels of it. > > curtain(1) uses a 10-levels "permissions tower" usable with options -0 to -9 > (which enable tags "_level0" to "_level9"). These are mostly just meant to > be used as a quick way to try giving programs more or less access from the > command-line (ideally a profile should be made to give programs just what > they need). The default level currently is 5 (which is fairly permissive > compared to most pledge(3)'d applications).  All levels are intended to be > securely containable, but each level exposes a greater attack surface than > the previous one.  Level 9 is the "please just work" level.  It allows to > use all ioctls and to read all sysctls and almost all rare syscalls.  > Filesystem access is still very restricted though so you've still got to > figure out what unveils the program needs. > > And there's another dimension to it which is the "unsafety level".  > Directives in the config files can be suffixed with one or more "!" to > indicate that the permissions that it gives are potentially unsafe, > depending on circumstances, or could be surprising or undesired.  The > directive only applies when curtain(1) is invoked with as many or more "-!" > options.  This was more useful at the beginning when many features weren't > properly sandboxed yet.  Now it's not used as much.  But I still find it > useful.  The way I'm using it is "!" is probably no big deal but you might > want to check it if you're paranoid, "!!" has a real risk of allowing > escapes in certain plausible scenarios, and "!!!" is very likely insecure > unless special precautions are taken. > > I'm still not sure what the defaults should be or how they could be better > organized.  The "unsafety" is an odd thing to expose to the user and as much > as possible I tried to make it unnecessary. > > So anyway, a shorter way to make nodejs work is to use level 6 which allows > PROT_EXEC on anonymous memory (and to execute binaries in $TMPDIR too): > > $ curtain -6 node -e 'console.log(2+2)' > > Now with X programs: > > $ curtain -X xlogo > $ curtain -X xterm > > -X gives "untrusted" X11 access, -Y "trusted" access (like with ssh) and -W > is for Wayland. > > There's an example config file with sample application profiles that can be > enabled by uncommenting the include line in /etc/curtain.conf (and reading > this file is a good way to see how the whole thing works).  Profiles can be > used with -a/-A.  Both simply enable the tag named after the program.  -A is > a shortcut that also enables "unsafety level" 1 (most profiles don't > actually need it, but some do, so I just use it all the time). > > $ curtain -XA xterm > $ curtain -XA firefox > $ curtain -XA chrome > $ curtain -XA falkon > $ curtain -XA qbittorrent > $ curtain -XA hexchat > $ curtain -XA gimp > $ curtain -XA audacious > # curtain -A tcpdump > > Programs started this way still have the default level 5 permissions in > addition to their profile permissions. > > Option -k ("kill") enables "strict" mode where the default becomes level 1 > and programs are sent SIGKILL when trying to do something forbidden > (otherwise they just get EPERM errors).  I made those two things go together > because unexpected restrictions can make programs misbehave and this could > lead to security issues.  This reduces the attack surface but it also means > you've got to figure out the permissions just right or your programs are > going to get killed a lot.  Also, trying to access non-unveiled files does > not cause a SIGKILL to be sent yet, so missing unveils have the potential to > cause insecure misbehavior too. > > See the config files here: > > https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.defaults > https://github.com/Math2/freebsd-pledge/blob/main/lib/libcurtain/curtain.conf.sample > > How well does it generally work? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Well, there are some problems. > > First of all, "untrusted" X11 access doesn't work all that great. Some > programs are just unstable with it.  Firefox used to crash a lot with X11 > errors but for some reason it seems to have gotten a lot better recently.  > But there might be thick borders around menus, client-side decorated windows > won't be movable, the system tray won't work, selection/clipboard will only > work one direction.  And it'll be slower.  The alternative is to give them > "trusted" X11 access but that's very insecure.  And even untrusted access > isn't so secure either, untrusted programs are not isolated from one another > IIUC.  And who knows what the window manager, panels and others could be > doing with the window properties of untrusted clients...  And this exposes > the huge complexity of the X11 server. > > Wayland's security is supposed to be much better, but it depends on how the > compositors handle security on the extra protocols that they support and > IIUC there's not a consensus on how it should be handled yet and most > compositors still lack security restrictions (but apparently some people > just compile out their support for insecure protocols). > > Programs that have built-in support for privilege-separation and > self-sandboxing can solve this by not giving direct access to the display to > the sandboxed parts.  And that's something that this implementation means to > support (which can be done on top of sandboxing the application as a > whole).  But it's not a general solution. > > Also, dbus/dconf/pulseaudio/etc are not dealt with very well yet. They're > just ignored really.  And (a bit surprisingly) many programs seem OK with > that.  fontconfig will complain a lot but if the font caches are already up > to date it doesn't look like it matters (startup will be much slower > otherwise).  pulseaudio will just die when firefox tries to start it but > then it'll fallback to using OSS directly (sndio works too).  Thumbnail > caches won't be accessible.  The XDG shared recent documents list won't > work. dconf will be completely non-functional and some programs won't be > able to save their settings.  Etc.  And even when it works, "desktop > integration" in general is going to be very degraded.  A program trying to > launch the desktop environment's handler program to open a file or URL > probably won't work because it'll inherit a too restrictive sandbox.  I > haven't really gotten into trying to deal with this better yet.  I see that > there are dbus proxy services for sandboxing on Linux.  It would probably > need something like that. > > There are some scripts to sandbox programs with separate XDG directories or > separate $HOME in /usr/share/examples/curtain/. But I wish doing this > wouldn't be necessary... > > For non-desktop programs, it generally just works (if you give them enough > permissions).  The main thing causing trouble is usually /tmp. > > About the userland parts: > ~~~~~~~~~~~~~~~~~~~~~~~~~ > > libcurtain is a wrapper around the sandboxing syscall.  It allows to assign > permissions to "slots" which then get merged.  Path permissions can override > each others (most specific wins) within a slot, but across slots they are > merged in a non-interfering way (a more specific permissions never cancels > out less specific permissions from a different slot).  Permissions from > different bracketed sections of config files are added to different slots, > so they all get merged in this way. > > Config files are also handled by libcurtain.  Applications can use > libcurtain directly to sandbox themselves using tags, but the API for that > is more complex than it should be and I'm probably going to make more > changes to it. > > I added a freebsd_simple_sandbox() function directly to libc that tries to > load libcurtain and applies a tag.  The idea is to make it as easy as > possible to add configurable, opportunistic sandboxing to applications > without having to link them to libcurtain.  It can be called multiple times > at different stages of initialization of an application, or for different > sub-processes, etc.  The application just specifies a tag for each call and > the details are in the config files.  Conceivably, there could be different > backends implementing the sandboxing. > > libcurtain also contains the pledge()/unveil() implementation.  On OpenBSD, > pledge/unveil are available directly in libc (with the declarations in > unistd.h), but the portable versions of some OpenBSD programs have problems > if pledge/unveil are available on non-OpenBSD platforms because they just > don't expect that.  After fixing them, maybe auto-loading wrappers could be > added directly to libc too so that they just work without having to deal > with libcurtain dependencies. > > About the kernel-side parts: > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Most of the implementation is in a separate mac_curtain module, but it also > needed some changes spread out in the kernel to support it.  That's what > would need to be merged. > > The biggest change is adding "sysfils".  It initially just meant "syscall > filters" but now it's more of a general category of things that the kernel > can do.  Syscalls can be associated with zero or more required sysfils and > some explicit sysfil checks were added in various places in the kernel as > needed.  ucreds have a set of allowed sysfils.  Sysfils are represented as > simple bitmaps and checks are fast.  Capsicum was slightly modified to make > use of a sysfil bit to simplify syscall entry checks. > > Sysfils are meant to be part of the internal kernel API, they're not exposed > to the userland.  The curtain module exposes intermediate "abilities" > instead. > > Some checks that checked for "capability mode" now check for a more general > "restricted mode" instead.  A process is considered in restricted mode > whenever its ucred is missing any sysfil bit. > > MAC handlers were added to let curtain hook into places that didn't have MAC > checks.  Some of those new handlers definitively seem out of place.  The new > vnode "walk" functions are more of a low-level mechanism than just a > security policy.  And many of the new handlers want to restrict access to > certain functionality as a whole (e.g. ioctls, sockopts, procctls, etc) > rather than compare labels.  But it seemed like the best place to add them > because MAC already did most of what was needed.  So I've been treating the > MAC framework like it stands for "Modular Access Checks" or something. > > The curtain permissions are stored in "curtain" objects.  Process ucreds > have their labels point to a curtain.  Curtains have pointers to "barrier" > objects, which contain the hierarchical linkage needed to restrict access to > protected kernel objects. Those kernel objects have their labels point > directly to barriers.  Barriers can outlive their curtains.  When a ucred > loses its last reference from a process, it is "trimmed" and its label > curtain pointer "decays" into a pointer to the curtain's barrier so that the > curtain can be freed (because curtains can be a few KBs and they can hold > vnode references).  A lot of objects hold references to ucreds, so they > could build up a lot without this. > > Processes can sandbox themselves with curtainctl(2).  They have to specify > the full set of permissions they want to retain.  The requested permissions > are then masked with the current curtain (if any).  This involves dealing > with inheritance relationships between permissions (as the new curtain can > have permissions more specific than the old and vice versa). > > Kernel-side handling of filesystem path unveiling was the hardest part to > deal with (given the "statelessness" of the vnode API) and it kind of is all > a big kludge.  I tried to make it as nice as possible and wrapped the whole > thing behind a MAC API (it used to be a lot worse than that). > > Each directory "unveil" acts like a sort of chroot barrier but with specific > permissions.  There's a per-thread "tracker" with a circular buffer that > remembers the permissions for the previous N looked-up vnodes.  N only needs > to be 2 as far as I can tell (most syscalls only need 1, but linkat() for > example needs 2).  The tracker has weak vnode references and doesn't need to > be cleaned up after syscalls.  namei() calls the new MAC handlers to manage > the tracker during path lookup.  fget*() also adds a tracker entry.  Then > the access check MAC handlers can find permissions for the passed vnodes in > the tracker.  This only works because almost all of the kernel code that > work on vnodes first get a reference from namei()/fget*() and then don't > call VOP_LOOKUP() directly themselves.  It's messy but one good thing with > it is that it usually "fails-secure" if the tracker was mismanaged because > it won't find the vnode in it and it defaults to deny. > > > Hello Mathieu, First of all, thank you for this amazing work, leveraging the mac framework to build curtain is imho an excellent idea, I personnally see a curtain like approach as complementary to a capsicum approach rather than an antagonist feature, I can see many possible usage of curtains in freebsd in particular in the port framework! To allow to integrate and permit reviews from developers, I think we can/should split the review. The first thing will probably me imho to start a review process of the sysfilt feature, this is probably the part that will need most of the back and forth discussion given the rest is pretty isolated (mac module, userland). Can you isolate the sysfils code and start a review in phabricator? If you need help for this don't hesitate to ask me ;) Again thanks for the huge work. Best regards, Bapt From nobody Wed Mar 30 16:14:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2891D1A34735 for ; Wed, 30 Mar 2022 16:14:44 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTBN26Xr0z3t27 for ; Wed, 30 Mar 2022 16:14:42 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f182.google.com with SMTP id 14so10164838ily.11 for ; Wed, 30 Mar 2022 09:14:42 -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=maGTE4092P61htpemOd5Ah0BZPSIPjfHtdMZ3tM39kA=; b=awb3OsdtcTSktLBtoDhw1xeX3dPRpNZ2JELk2VO6dr8SXdNIGeZ36StaWH/LRn7Zg3 eC6EtbefWxXKuXPTNR7WHL8sC03NDVCrb87V5Uwxk7CXagB+NrpYwe+haksSxjXxfBK4 HVVSjQJ2JyC8XUJUBDWSC1bOZ5Dlz+AtaA9EOyx8T2q+lWIEwAgyYqQrmwsi9O8zPdjE yvsBGogPpEu48JJyPYXbB7OMzDVL4xv2C7xRR2+KO3EQyCDw1A447giwbRZAR+4fMhfp u2XL1RbCd4YHjyggXahVLjOFJ99QHHoOpEH/6ojx0qf7veb/pI0B6FnqScUbWIZ/b4Ji Ye+w== X-Gm-Message-State: AOAM532Sh7bOMmr6V6h4XiJOFt/WpgGxWACj3T2rLbmveON2kpqj0y+9 18IsZDKyhuH84Xdf95VvpljrZsm6cPcADCam0g0= X-Google-Smtp-Source: ABdhPJzo9UPeTsOLzkmVBSRaKZnTjJ6RIkEvzhPEJ/rmLOuFITXU7OCALsm0wrOOewGe/dMe22WCr/LRtSE9WICiwMY= X-Received: by 2002:a05:6e02:1c2a:b0:2c9:defa:d061 with SMTP id m10-20020a056e021c2a00b002c9defad061mr2938619ilh.260.1648656882058; Wed, 30 Mar 2022 09:14:42 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> In-Reply-To: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> From: Ed Maste Date: Wed, 30 Mar 2022 12:14:29 -0400 Message-ID: Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support To: Mathieu Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KTBN26Xr0z3t27 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.64 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.96)[0.964]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.605]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.182:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.182:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, 28 Mar 2022 at 05:38, Mathieu wrote: > > Hello list. Since a while I've been working on and off on a > pledge()/unveil() implementation for FreeBSD. I also wanted it to be > able to sandbox arbitrary programs that might not expect it with no (or > very minor) modifications. Interesting work - I'm happy to see development with the mac framework and I plan to take a good look at it once I have a bit more time. I have a couple of quick comments from an initial brief look. First, the update to pledge's declaration in crypto/openssh/openbsd-compat belongs upstream in the openssh-portable project; we'll then just pick it up with a subsequent import. Second, following on from David Chisnall's comment about userland abstraction, there's another example of this concept in the "Super Capsicumizer 9000" at https://github.com/unrelentingtech/capsicumizer. It interposes libc and uses LD_PRELOAD, so won't work with statically linked binaries (and has other limitations) but the example it presents is sandboxing an unmodified gedit. From nobody Wed Mar 30 17:52:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76B3C1A3B168 for ; Wed, 30 Mar 2022 17:52:12 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTDXW4ycbz4pV1; Wed, 30 Mar 2022 17:52:11 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id w141so17023642qkb.6; Wed, 30 Mar 2022 10:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to:content-transfer-encoding; bh=rKbhRL1wiqLNsWh3J7aI+GC9sE8miOwptFt2+6YX6ro=; b=fVsThHTgrcrqt8qoXwIQjbr8ZqHBu2mksC/zwSKfH/qvlqwQr4ImirscPLS5K3Nu2j kdCrBQZozIjZylOwyp+E33AXTIXdgMVg8KrPEptE/2qFqsgdZxRWtAT1QzqUZlj7F85/ hWwKrRaafF7kYizkqBJwtkT886TskrZ79Yrl9Na1OMCoJCJuoSZ+pqjwseYgQenFSI4z fhQBFw6r+SEJpLpfsDEbUNOrfbZY0EfDxLMAQgvwiE+rKCjyUO9dDPfTK1P+dBUnrVRm De9VFf1xwQq8NEkjC3f0KQxv1aw8DgS12DdjHJbA2Y1w8f1mOLxYdcjiLmJpcP/a2sF/ 1FtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=rKbhRL1wiqLNsWh3J7aI+GC9sE8miOwptFt2+6YX6ro=; b=l7t86m0OJ6Gxm+HASAxWr+6Os5i6rpmbiFE+BDS7IIqPbv3jiJvKobGzcz+bEBMSGc clNHJwge+JwcZ6IryAXvHzWJ1WQ/ShfvFIXqGW0NuX8ZdzHTQ7a9m3vtjpI0Elp6WZM2 NMSK1lTPCO/v0oGjByRVxDVMKlv0dM9hYPCk2wbFB1kh3iu2XCPjTKCsl7BwHSySJiJ9 2jORLstX2YhZbG3MJMsbu4HrOx/zsQNAYqyo2oibvM/eoDz8mnpBtJgl08p92mMlp7Df GS6WfnxsXjlT8fs61Nn6Edj1CPYsHN/dyHXx94v8824xn/nL8mMLw0XkVY5FIRGFmeIi bcEw== X-Gm-Message-State: AOAM533AKPOHlRlaupzP238B7OKbh3YL9COz/0W71BQNSLABJWaMkReZ jORj2Et9sg6UBTFNqnqo2wKZ4tsJ3Hk= X-Google-Smtp-Source: ABdhPJxJJbp+5pq8RTSe8pYhJdK+jXp8LgEy3KHmjDSM+woLi7mHoi8qotUYCEpS4q6KZojMpHsNbg== X-Received: by 2002:a37:67c6:0:b0:67b:1153:a63a with SMTP id b189-20020a3767c6000000b0067b1153a63amr581256qkc.695.1648662730718; Wed, 30 Mar 2022 10:52:10 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id 11-20020ac8590b000000b002e1e5c5c866sm18711868qty.42.2022.03.30.10.52.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Mar 2022 10:52:10 -0700 (PDT) Message-ID: <8df2d609-0a0d-0a25-4918-a27c91c3790a@gmail.com> Date: Wed, 30 Mar 2022 13:52:09 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Baptiste Daroussin Cc: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220330072210.icontj4n7hcqwtql@aniel.nours.eu> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <20220330072210.icontj4n7hcqwtql@aniel.nours.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KTDXW4ycbz4pV1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fVsThHTg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 3/30/22 03:22, Baptiste Daroussin wrote: > Hello Mathieu, > First of all, thank you for this amazing work, leveraging the mac framework to > build curtain is imho an excellent idea, I personnally see a curtain like > approach as complementary to a capsicum approach rather than an antagonist > feature, I can see many possible usage of curtains in freebsd in particular in > the port framework! Alright! One nice thing with the MAC approach is that many of the checks were already carefully placed to not deviate too much from expected behavior for applications.  At first I tried to do all of the checks in namei() and this often made syscalls fail too early with the wrong errnos and this confuses some programs.  When I figured out the right place to add the checks it was almost always right next to a MAC check. Also, if I hadn't used a MAC module and added a new layer instead, you could say that it would have been the fifth (!!!) general access control mechanism in the kernel (after traditional UNIX, Capsicum, jails and MAC).  This was starting to feel like a bit much.  So the MAC framework, it's not a perfect fit for some of what this module wants to do but it could be worse. Also, if you combine curtains with chroots you kind of get jails. It's chroot escape-proof because unveils deny access to the outer directories like any other.  Privileges are restricted.  It doesn't have all the features of jails but it's very jail-like. Just to say, the MAC framework was pretty close to being able to implement jails too. > To allow to integrate and permit reviews from developers, I think we can/should > split the review. The first thing will probably me imho to start a review > process of the sysfilt feature, this is probably the part that will need most of > the back and forth discussion given the rest is pretty isolated (mac module, > userland). Yeah I think it's a good idea.  I could do some minor cleanups and add some comments while at it before submitting it. I'm still working on this, but the majority of the changes should be in the userland and the module itself now. And getting some feedback on the kernel parts (and eventually knowing that they're in an acceptable state) would help.  The module works well enough already that I don't think that there's anything critical that would require extra changes to the rest of the kernel (unless some problem is found). I think the kernel changes could be broken up something like this: 1) Sysfils.  Adds annotations to every syscall in syscalls.master (Linuxulator could be done later too).  Generalizes the Capsicum flag to a sysfils bitmap both for sysents and ucreds.  Changes to the syscall entry checks.  Some sysfil checks spread out in the kernel. 2) There are some small modifications that I believe are bug fixes or minor improvements or basically have no effect in the current state of things (but are important for mac_curtain). 3) The new MAC handlers.  That's a significant part too and it can be separate from sysfils.  This would include the new call sites in vfs_lookup() (and there's some extra logic too).  New call sites in SysV/POSIX IPC modules (and some other changes to path handling).  There's a function that deals with getdirentries() filtering directly in the MAC framework (the MAC hooks only deal with the dirents one by one) that maybe doesn't belong there. vn_open() got a new flag. 4) Various modifications that are specifically to support mac_curtain.  I tried to minimize those but there are some. struct thread/proc need new fields (opaque pointers for unveil tracking/caching).  struct file needs a few extra integer fields (I really tried to get rid of those but couldn't figure out a good way).  I also added "sysctl_shadow" objects to kern_sysctl.c. These are handles that can outlast sysctl_oids.  It's not elegant, but mac_curtain needs it.  At first I thought that I could add long-lived references to sysctl_oids and I designed the curtain data structure for that.  Then I realized that sysctl_oids get totally nuked when a module unloads.  They get unmapped from memory with the rest of the module's data and there's no holding on to them (IIUC).  So I added an intermediate data structure between sysctl_oids and curtains. The mallocs with non-sleepable locks in the SysV IPC module with late label initializations are annoying but this could be fixed separately (it might need a bit of code restructuring...).  Making the module fplookup-friendly would probably need some changes to the MAC framework itself, this can be done separately too. There are others, but not critical and can be done separately. > Can you isolate the sysfils code and start a review in phabricator? If you need > help for this don't hesitate to ask me ;) Yup, I'm on it. > Again thanks for the huge work. No problem! This is gonna be a lot of work to review so thanks to anyone involved too. > > Best regards, > Bapt From nobody Wed Mar 30 18:22:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 66A181A43B62 for ; Wed, 30 Mar 2022 18:22:56 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTFCz4wDjz4vhL; Wed, 30 Mar 2022 18:22:55 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qv1-xf35.google.com with SMTP id kl29so17528056qvb.2; Wed, 30 Mar 2022 11:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:cc:subject:in-reply-to:content-transfer-encoding; bh=9PXQuueF4nfIv61ophFPJAYVOucIdtxlt2Ta9vTdRjE=; b=PjfRnLyYsPdRUpjx/Sn1UeLB9AziYEz/AEiDsZpWr2PqVucAkCnru+qabqk0hrNlCD KS9A7BxfSj5VgT/Zu5rnxnjwX1OZsZXLvXn8oXKuyWx4ak+MmhLRFIXde1LUy4qAIOGD YX4mtMyu/b22IPtVuWmnxBbg1fSNlD74DpPg8uT1QI+KzQO1S33eetpVEOJ4seR7crIU NtuhDjXS2ycSCZ9BcZYea7OzKPiM/0kiLM4f/xG5uEtbtIKTjy9N+KPvBacifPm2VeM1 maN1P66iO/dCyWkLfUjyWJYi4MjE48eWPPSc1OYAlAygMaxE/luTSr/WUiZzHTdQnua4 U81g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:cc:subject:in-reply-to :content-transfer-encoding; bh=9PXQuueF4nfIv61ophFPJAYVOucIdtxlt2Ta9vTdRjE=; b=MGgWDJA2ss3MrlTEhgz9x+RPDs+7l0qb9O/xI52f2nvaeFumM64jbk1b2ZLAU61dkd XLoIVF4NIg5eKYEIod+GsQ5KEMQ9Ed2LQ40kfCc0ueMLIdLUgkZYRIcECkMgsXREszPI 0OLv6e/crukHdDqfaV0oS7JsdTuK6KZxZ0QKenlwxlt9HcaUHzxOUTLtaUqrvzyQpFpn 7qTl2dIwZa+vioujIOp3jBEB6EjRomd/v8eV0P4sM3ppPS4LHTQLkY7q6tT1cLv41KwF yoLsUL46n8tUZtKN3BWrJ7oQlF5yqOK5zzw49AK3yYCugw0u2Zd4xQUotdp//Pv02XMN OUbw== X-Gm-Message-State: AOAM533/q3imRPaqZ9EyfAWweCeBN7CIsLkvQeJxmEHSCK5YIOsX6yBu B53qfvtO8ixHuURf8nXRfgQJcBusgOY= X-Google-Smtp-Source: ABdhPJzAyijxG2o2Mpqcmozt5NS7HSE4B1200/iVjEKMV5gPQHvaFlK0ZKowBOzQKLNXguo7pA1Myw== X-Received: by 2002:a05:6214:766:b0:441:a5df:8ace with SMTP id f6-20020a056214076600b00441a5df8acemr739708qvz.87.1648664574932; Wed, 30 Mar 2022 11:22:54 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id p17-20020a37a611000000b0067b2b2c41fasm11528664qke.81.2022.03.30.11.22.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Mar 2022 11:22:54 -0700 (PDT) Message-ID: Date: Wed, 30 Mar 2022 14:22:53 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Ed Maste References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> From: Mathieu Cc: freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KTFCz4wDjz4vhL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PjfRnLyY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::f35 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-2.68 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.29)[0.294]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f35:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 3/30/22 12:14, Ed Maste wrote: > On Mon, 28 Mar 2022 at 05:38, Mathieu wrote: >> Hello list. Since a while I've been working on and off on a >> pledge()/unveil() implementation for FreeBSD. I also wanted it to be >> able to sandbox arbitrary programs that might not expect it with no (or >> very minor) modifications. > Interesting work - I'm happy to see development with the mac framework > and I plan to take a good look at it once I have a bit more time. Alright! I have to say, it's definitively doing things that MAC wasn't designed for, but that's the best way I found to interface my module with the rest of the kernel. > > I have a couple of quick comments from an initial brief look. First, > the update to pledge's declaration in crypto/openssh/openbsd-compat > belongs upstream in the openssh-portable project; we'll then just pick > it up with a subsequent import. Oh yeah, I think this change used to be necessary when I had put the prototype for pledge() in (and prototype conflicts led to build failures).  Probably not needed anymore. > Second, following on from David > Chisnall's comment about userland abstraction, there's another example > of this concept in the "Super Capsicumizer 9000" at > https://github.com/unrelentingtech/capsicumizer. It interposes libc > and uses LD_PRELOAD, so won't work with statically linked binaries > (and has other limitations) but the example it presents is sandboxing > an unmodified gedit. Yeah I saw that.  Maybe I was wrong not to go with that approach.  I thought it would be too hard to make it complete enough to run everything I would want it to run.  A lot of programs are very finicky.  That's what I found out while working on this. I see the advantages that it would have though, this could shield a huge chunk of the kernel's complexity from applications (no matter how much complex functionality the applications demand).  I can imagine that it could replace VMs in many cases for the isolation that it brings.  If anyone's working on that I think it would be worth it. But in the meantime, my module does it the more conventional way and it's advanced enough to run browsers and whole shell sessions, test suites, etc. From nobody Wed Mar 30 19:51:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A9FF1A5989F for ; Wed, 30 Mar 2022 19:52:02 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTHBm75YQz3jRV for ; Wed, 30 Mar 2022 19:52:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72a.google.com with SMTP id q200so4333097qke.7 for ; Wed, 30 Mar 2022 12:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=sLDOwNoYtRf5aUmu1YLggt60bPtcAWn4RJkBxzBMAx4=; b=f6n/VELD7xElDNLwKHCGKBKE7t99PomSXiWusKwzuYlwnHAzLnaFxvV89i39a2dqb4 stRgPoFmtLBNi0fcDB9UZ/EJBVK1vmHFBoKLHSwQBX0VC+zKYost5skYEMLxmiEBTWoP HfTUGtpnbwDbIWIgKeupColUQY0DREEaJTLY+b42xCHz/rl9DaoHocP21r+NrRjKy5bj TtwMACuqFfs17WgDG8a4NJg0btZwt3NXdO3bnklra4TVfXMnzIfhZKLQVod/hJcopT74 Vz1Qvx1knfan/w+PNhiclbKrV2wJ/Wa1tddk0gxvVe27qY+8FT4siLdz8J9txTxnZwte Lq5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sLDOwNoYtRf5aUmu1YLggt60bPtcAWn4RJkBxzBMAx4=; b=WDGWK20oyFnyuiyRON1ky8Y7LaO9j0YyJbkJRHJkXsRES3v/Cnm/kUDtDjAy079Nir nsMILWeJFUW5TsAuucoXxig9sUzBXRKUfK+QbxsI/j5cGelfS2Q13hTdV2hbaCPy73vQ nEWoJjJNOLu++sGC80DVF7/NEIH4/PcYGm4uPX9A8GnGoo7zRgbjzRXOQKfFYyw7PZGS 7u4WY4/PjMNFDpyxDAooDCJATd2RosYdW35jUB8z9OhM5QdPFhadGNYjS9arQhRhmloK czDN3le/hXsnau2RKALDO1F9hza4PgvAsZyGJ6rIoQLAIcERwJpfJu6QIo0eIY/nsgSL Js0Q== X-Gm-Message-State: AOAM530cqVeiu3XzbyDHfluCOAxH/7dwSuA93PcaJKzuPMuf3meCtw7j 9yb7erJ7YPETlUr90I1/2J2Suw== X-Google-Smtp-Source: ABdhPJz8+tcpgKNDw/8mJe1Gde68LE8tcd4XPOANmBBdGneAogDBHH3iXGZSsi7N5rHnMzvphi3aew== X-Received: by 2002:a05:620a:125a:b0:67e:ce2e:f2bd with SMTP id a26-20020a05620a125a00b0067ece2ef2bdmr1012751qkl.336.1648669920409; Wed, 30 Mar 2022 12:52:00 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id j11-20020a37a00b000000b0067b436faccesm11220171qke.122.2022.03.30.12.51.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Mar 2022 12:51:59 -0700 (PDT) Date: Wed, 30 Mar 2022 15:51:59 -0400 From: Shawn Webb To: Mathieu Cc: Baptiste Daroussin , freebsd-hackers@FreeBSD.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220330195159.zraxrpgjcu6kcwae@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <20220330072210.icontj4n7hcqwtql@aniel.nours.eu> <8df2d609-0a0d-0a25-4918-a27c91c3790a@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="z3regbayyxs4mrei" Content-Disposition: inline In-Reply-To: <8df2d609-0a0d-0a25-4918-a27c91c3790a@gmail.com> X-Rspamd-Queue-Id: 4KTHBm75YQz3jRV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b="f6n/VELD"; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-3.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.99)[-0.989]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_SPAM_MEDIUM(0.55)[0.553]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --z3regbayyxs4mrei Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2022 at 01:52:09PM -0400, Mathieu wrote: > On 3/30/22 03:22, Baptiste Daroussin wrote: > > Hello Mathieu, > > First of all, thank you for this amazing work, leveraging the mac frame= work to > > build curtain is imho an excellent idea, I personnally see a curtain li= ke > > approach as complementary to a capsicum approach rather than an antagon= ist > > feature, I can see many possible usage of curtains in freebsd in partic= ular in > > the port framework! >=20 >=20 > Alright! >=20 > One nice thing with the MAC approach is that many of the checks were alre= ady > carefully placed to not deviate too much from expected behavior for > applications.=A0 At first I tried to do all of the checks in namei() and = this > often made syscalls fail too early with the wrong errnos and this confuses > some programs.=A0 When I figured out the right place to add the checks it= was > almost always right next to a MAC check. >=20 > Also, if I hadn't used a MAC module and added a new layer instead, you co= uld > say that it would have been the fifth (!!!) general access control mechan= ism > in the kernel (after traditional UNIX, Capsicum, jails and MAC).=A0 This = was > starting to feel like a bit much.=A0 So the MAC framework, it's not a per= fect > fit for some of what this module wants to do but it could be worse. While I think using the MAC framework here was definitely the right choice, I also think it's important to note the one major downside of the MAC framework: function pointers. A kernel exploit could nullify one or more MAC calls by overwriting a function pointer. Additionally, in certain circumstances, a function pointer could be overwritten to point to another spot in memory. The next time the fptr is called, the originally intended code isn't executed--rather, a new code path. Again, I think using MAC here is the right way to go. Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --z3regbayyxs4mrei Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmJEtNwACgkQ/y5nonf4 4fpjAg//bFb4nturw6rSY/MpDj3mVps0OeYncRynpc+apbKI5qHIINN1fxf3mPJ5 F0Eklg1F0IJdxzTSFVy94iEPDrDi39zJyp5LW8GM4tEdtPcdVw3tHhdOUhZ/DWdh NhvSNNQ5yRANzXr8YsXIMyiHrgO+D48mcXiKD8fhrM/iXc0dPW8coNJkHiU9etQV vnxhMmch5iN6g7IS4rZOsp9mbstKD2YZVat3ETJTnwGxdD3X23WVF4tu5K9+cfvb rA4XD/ve5IcVDsZKzxt5EoSBJm3dz9KkdczP1JeiLNTK6EWm8cFLfK26weDTGM5l /YuprWGmChW0TthPZSA7jLPpdYAj2JcwM5Lo7IMGpVsxmZKqAo4ftNCkR1WzKbt+ zeycvXFsKaRL0+DxtyYzPILAg+RAHI1c/XDFewpR6uKweM5IJjsVZYQWg59GiJOP /WxdPMqLxT9Q2Df9rSZFpYa6yUt3ms4f5nuDtBdAQP3b9VE6N6t6yw17UwuCTyuC BHAPxOpoIgdkdcrx0xx0fGkASnwqBDLmKPyiSKqtmI+DBMpXbURSxhNMMVv6gNGu NvsOiJZi2JLrJJY0O/L4Z+Lvdl3gr4DtjxaAQB6/sfnNne93ASQ8NyeedLgMoowu guDbHD4PeGrTuGYx9TxY3gEY4iQr69QPRQi2Gm9aQ48s/Ixx+ps= =QZsf -----END PGP SIGNATURE----- --z3regbayyxs4mrei-- From nobody Wed Mar 30 19:56:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D037C1A5B098; Wed, 30 Mar 2022 19:56:49 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTHJJ6Hxtz3klx; Wed, 30 Mar 2022 19:56:48 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua1-x935.google.com with SMTP id w21so9454931uan.3; Wed, 30 Mar 2022 12:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=6k4arAmUSZ95+uwmorfQipmcUVU68Hn2mWmLx2Yc0CY=; b=aOBu0nJJ9uFyOo7tgqWTvKFtUzyfmhBiSis4RMFzXn7mGfG+WAIaUCNqlNYA653ls5 4uvkCQcoov0js4ViECcFWZj7NqTqoJXYQ7DNc9eT52dHQDqy3EX1cJJER4TcsTKcsUh5 YMqGmPoPbbhWcNGJzdI3Gf3e9jt206yJx9z1c4jszytZ3olUvHi9XJb7hrmjaMHjmmHg 63ymFYtGxRDkILZE/L6Y/+GryKNLvUqUcHTfGgyNudYjtUA9T5tFPrn46BGIpEs1Q7Ni Zn67Nyph6WIQ9k/xxZn1AmUTRhWpObt93f3pW2mb8Ppolo/99AeUyqzJdT5z0WsczjIG dQ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6k4arAmUSZ95+uwmorfQipmcUVU68Hn2mWmLx2Yc0CY=; b=Y887nPrIfwmpfnVkkYLXfJU9zpD2JPYqUrLoTZINWs4TUbF4bGLgb3biCnG53oE1Rh flZ8MLln7MkznN3GN7nvD8XEGNqVrhThPVddoW+/NLkmUIh8GvLnAlIPhOEOwpTt4Ah6 8RQAfTz0Hz6BLA2qkQMfHd4d/pu9HCE58g/l+FjbekHZBVxC0I/kyDGcmcOG9STWnoRO nGOPD+UT3+HkxS478OmBHJrKu3G7Ev6k/zyotAZk6VbKj6Uv7DrdT+PJSsibk/FGpaDd 1Gp+Zm1XXMDXcsrIyuj8icrgxiBCmnjNHDNa69Q49CZuL1cunloRbbV9zI+OlAVhywD9 F/mw== X-Gm-Message-State: AOAM533o3w20m5athXOU5ANDQ/1CrS7Z8Nd2Xrdk9lrG32Gc4IdO6Ecj nK4JTYfj51Jo7nSxY4VrVMaObxUerVMPs/4XgxbFwFfI8f5d5HuRW1c= X-Google-Smtp-Source: ABdhPJxzcsHcm6OK1PdlF8TMsnuSPatTQfBFoh0p8pifa4x1rMleO3OwWWtH3UcqxKxicfJjMR37gaQB88/oNBVNDjw= X-Received: by 2002:a9f:3b2e:0:b0:347:33ae:e5e4 with SMTP id i46-20020a9f3b2e000000b0034733aee5e4mr676748uah.49.1648670208082; Wed, 30 Mar 2022 12:56:48 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:612c:14c1:b0:2a2:beee:4b76 with HTTP; Wed, 30 Mar 2022 12:56:47 -0700 (PDT) From: grarpamp Date: Wed, 30 Mar 2022 15:56:47 -0400 Message-ID: Subject: Sysctl Undoc Problem [was: vfs.nfsd.tcphighwater] To: freebsd-doc@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KTHJJ6Hxtz3klx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=aOBu0nJJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::935 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.73 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.27)[0.271]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::935:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-doc,freebsd-hackers,freebsd-questions]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N > the lack of documentation leaves me wondering what to do > ... > Then there's no indication of what value should be reasonable. In fact it's not even clear what unit we are talking about (bytes? kB? some unspecified count?). > If vfs.nfsd.tcphighwater had a starting value I could think about doubling it, raising it tenfold or whatever; alas it's default value is 0. > Some forums show people used some apparently random value like 300000, while admitting they had no idea what they were doing. Too many undoc sysctl exist. No one should be allowed to commit a new sysctl without documenting its rationale and usage in the same commit, to respective doc files. Existing should be surveyed and reformed. Beneficial thing is sysctl could be made programmatic enough to collate all of them into a table denoting documentation element checkmarks for each, distribute doc effort to subgroups, etc. Maybe some effort already exist to do this. From nobody Thu Mar 31 10:24:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 46AB91A5615C for ; Thu, 31 Mar 2022 10:24:49 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTfYr4mz7z4ybD for ; Thu, 31 Mar 2022 10:24:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648722289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fhQwPICDq7bbC10ob8EU1VP4W9PQFO2dbtMRy5PdZ5Q=; b=nOesgy6xdF30mVzmap8X6Izi5l0j+tDgNKkZqC6cPfm86Tbgees0/WUgOuwp5jf0VQulr0 aMqf7YhDykSxJFoW9025UKeijMh8VdSxx56nITOlbMXH7xPnc29cFxR7FHsIGOPiN2rJ1F LOfKrCyhPeeEKYLiCmSYCGtQUGIp9PGoSlEJ1IvSd1gfQZu9rcAeUnBE4LTULsZsi5L/fA A1Ve0uPIl5t77KUPMuVIPkLpQoTQUFvX7A/pMCsVGKSUchVK55yCUs8X4ZsZFP4mzAsEvz l1FCxxVc9tqUbnc8fS43IU6md+hoycvSplSpcwP/PzzrkKRnAFT82Zxj8EeEvA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 710A321C14 for ; Thu, 31 Mar 2022 10:24:48 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id AD70A3030D for ; Thu, 31 Mar 2022 11:24:45 +0100 (BST) Message-ID: <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> Date: Thu, 31 Mar 2022 11:24:43 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> From: David Chisnall In-Reply-To: <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1648722289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fhQwPICDq7bbC10ob8EU1VP4W9PQFO2dbtMRy5PdZ5Q=; b=jdRdh6sg8JbY5RuHaoKqL/yfhYHqk/pBsS1bWxBLzJfVUaX6bDvyHzTJJQ19YL0wCKoH1y dsi4Zkgnp3fsjS52BfQxNLd9BGlrig+rUS/bLGjCNHKxBXtf5scSj3vOPxXvisZhqzo7ch XCOS9a13Dn6MAnXlNdK4p7f8PsGg4Bf2R8HgevjjHFpGsaK2TwUxavU6+fkxy6AGfNqOTV egezFYqYYr8gx/cktjHTYN5oye6x79In5GdUeAml3/yh5NH3eaXXrGEuKIzENYVCDE7FAd EygzFJpY/X9sDDOSJ47h6YsQQS9XcrpufY8Xk7HTKYcYxwzGlF+0MM1SRlsInQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1648722289; a=rsa-sha256; cv=none; b=MtZN6jaxrAGUy/UH3SuXIsbfHHpEQ3QWsu4suuzyOeyNtUc6x/TqTBcttN49k3Yo0t3FUC w+7PFrXkg1FZhDIkfxKH/1xxmbZLbjeVlX97fb4MFm5Wsh65+znml6m/Oy+z84RgW+2PN3 8YzCRCJZBR/4rum2AcAL+pz2wLy8Y/kc0zkpg83xM5NY8X7JIFHatelP3CUxfb53Y6ps4D kFhjpBibd6kHakaqfcdV3iri3Od+sXTfYkNXHGnGNFiywd80bXUiwBhYxksnIg5uYpj0xL EO4bQbocv7oOOClqJTMLEZmXO8JevdBiAsBjQg7M5nZ4fgzha6Uhw5IyF27sog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 29/03/2022 18:32, Mathieu wrote: > On 3/29/22 04:34, David Chisnall wrote: >> Hi, >> >> Does pledge actually require kernel support?  I'd have thought that it >> could be implemented on top of Capsicum as a purely userland >> abstraction (more easily with libc help, but even with an LD_PRELOADed >> library along the lines of libpreopen).  In Verona, we're able to use >> Capsicum to run unmodified libraries in a sandbox, for example, >> including handling raw system calls: >> >> https://github.com/microsoft/verona/tree/master/experiments/process_sandbox >> >> >> It would be good to understand why this needs more kernel attack surface. >> >> David > > If it can work like that then it's pretty cool.  It could be a lot more > secure.  But it's just not the way I went with. Re-implementing so much > kernel functionality in userland seems like a lot of work. Because I > wanted my module to be able to sandbox (almost) everything that the OS > can run.  Including whole process hierarchies that execute other > programs and use process management and shared memory, etc.  That's a > lot of little details to get right...  So I went with the same route > that jails, other MAC modules and even Capsicum are implemented: with > access checks in the kernel itself.  And most of these checks were > already in place with MAC hooks. My concern with adding it to the kernel is that anything that does path-based checks is *incredibly* hard to get right and it will fail open. To date, there are zero examples of path-based sandboxing mechanisms deployed in the wild that have not had vulnerabilities arising from the nature of the problem. The filesystem is, inherently, concurrent. A process can mutate the shape of the filesystem graph while you are doing path-based checks, mostly around the handling of '..' in paths. Jails and Capsicum sidestep this in different ways: Jails effectively punt the problem to the jail orchestration code. They provide very strong restrictions on the paths, with a single root and allowing all access within this. There are a few restrictions on what you can do from outside of a jail to avoid allowing the jailed process to exploit TOCTOU differences and escaping but fortunately these align with the use of jails as isolated containers containing (minimal) base system. Capsicum simply disallows '..' in paths. If you want to support it in user code then you must do path resolution in userspace. You may still have TOCTOU bugs, but they'll all fail closed: you will try to resolve the result, discover that you don't have a file descriptor corresponding to the path, and fail. > pledge()/unveil() are usually used for fairly well-disciplined > applications that either don't run other programs or run very specific > programs that are also well-disciplined and don't expect too much > (unless you just drop the pledges on execve()). The execve hole is the reason that I have little interest in pledge as an enforcement mechanism. If a process can just execve itself to escape, then that's a trivial hole to exploit unless you're incredibly careful to make sure that the process does not have the ability to create or read files with executable privilege on the filesystem. In contrast, something using Capsicum can create child processes but they inherit the same limitations. It can inherit file descriptors from the parent, so if it is using something like libpreopen then it can inherit a large number of file descriptors for any of the files / directories that it should be permitted to open. Since rtld was extended to allow direct execution mode, you can launch dynamically linked binaries in Capsicum mode. With the SIGCAP things in https://reviews.freebsd.org/D33248, it becomes easy to write a signal handler that intercepts blocked system calls and handles them (I'm running with this applied and doing exactly that), so this can be transparent to any dynamically linked binary. > Pledged applications usually reduce the kernel attack surface a lot, but > you don't run arbitrary programs with pledge (and that wasn't one of its > goals AFAIK).  But that's what I wanted my module to be able to do.  I'd > say it has become a bit of a weird hybrid between a "container" > framework and an exploit mitigation framework at this point.  You can > run a `make buildworld` with it, build/install/run random programs > isolated in your project directories, sandbox shell/desktop sessions as > a whole, etc.  And then within those sandboxes, nested applications can > do their own sandboxing on top of it (with this module (and its > pledge/unveil compat) or Capsicum (and possibly other compat layers > built on top of it)).  The "inner" programs can use more restrictive > sandboxes that don't expose as much kernel functionality.  But for the > "outer" programs the whole thing slides more towards being > "containers"/"jails" (and the more complex it would have been to do > purely in userland I believe). So how do you avoid TOCTOU bugs in your path logic? I don't disagree with the goals, I worry that you're doing something that is intrinsically almost impossible to get right. David From nobody Thu Mar 31 19:33:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 754FC1A4AA43 for ; Thu, 31 Mar 2022 19:33:26 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTtks4lTtz3nJt; Thu, 31 Mar 2022 19:33:25 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f47.google.com with SMTP id g21so664290iom.13; Thu, 31 Mar 2022 12:33:25 -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=Vhzw79STTkoLDNS50Hw406gAjy7PToj0Fkh4NqUJZDA=; b=J2+CrsNaAOzfKp1lY9mwp2ID2xvppMcnFdPzj8BC5YSsgGaKPRST2QoXfL3L4cznpE qNowqLdJK6CaA1u1Zabyyk/h1DsUEzVjs5p1NO2DI7NXJCyjHdBGFrzyh7OuERdMK2xj 0phFF9MA7tZThbZYZvVRoKiXH9WQGxXtVtNd1UX5QeWtmORiTvIZAyEsc5qaAD6jKyq/ 5wf302LmlgbOL+0v1xnAXTr71KpBHuLVoXv4ANpioDITzrxkM20G6/fyg4rta7A6D5y2 ewgLn9AlhwsZZ2drijL8r5K74uJWXnx/gkjCOzmCrsZV9/pgnRCe2PTFV9q0ccDQEw1b 7AXA== X-Gm-Message-State: AOAM531uJPdFK3WL7NKxWGnmn++3pcHpew0clAiOYAWibnoFcRL4uwt6 cC2QLGlEvhRq1S8Mag7MyMHxEA4MiF7l1+9bO3+luajT X-Google-Smtp-Source: ABdhPJz9rY2fZvaSMAfpUxH227X8KvzzPJuJqrmSQmLuLOY+ohkTmEnCE1a89G54C4le6i3684sh/PISH0iQKlNeRWg= X-Received: by 2002:a6b:8bd7:0:b0:646:2804:5c73 with SMTP id n206-20020a6b8bd7000000b0064628045c73mr14607271iod.112.1648755198919; Thu, 31 Mar 2022 12:33:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> In-Reply-To: <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> From: Ed Maste Date: Thu, 31 Mar 2022 15:33:06 -0400 Message-ID: Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support To: David Chisnall Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KTtks4lTtz3nJt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.73)[-0.727]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.47:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.47:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 31 Mar 2022 at 06:25, David Chisnall wrote: > > Capsicum simply disallows '..' in paths. This is no longer true as of 7359fdcf5ffa. During a lookup the kernel checks that each ".." component specifies a directory that has already been visited in this name lookup call. > The execve hole is the reason that I have little interest in pledge as > an enforcement mechanism. Note that execve is only available if the "exec" keyword is specified. The child does not inherit the parent's limits, though. From nobody Thu Mar 31 19:37:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 26A961A4C726 for ; Thu, 31 Mar 2022 19:37:37 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTtqh1qn4z3pl2 for ; Thu, 31 Mar 2022 19:37:36 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf2a.google.com with SMTP id e22so373271qvf.9 for ; Thu, 31 Mar 2022 12:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Qj0YtbZHgOxwNVTqRESKux6iIBjq7T9eUQOVyf0emJs=; b=Mh0bMvK+NgMe3pklMKwqUND9DRFrfkb5RyDPJGqOXpIeGyQ92MxzV/nFuhZyM0cP4r wlgr0P/9BBnd680KC3M2tTdXWmdZI2yOmBArQFTdYKddU5icRMJLzsws4uGRc6G0yJQ9 KhiCFGY9FN+lnkU4aNdN6V7zr18WXbcxzACkXf1zh9/Z3RUENTW/mLD7ndl+FxxQ8R8z nGDIP9Fmxn5vEbSVsGDmmZUnOVv2RxFzG4IsLL3xbJ1qyv4XJ/CNfeNJLxLRwB2hnll4 yrYploPcr2ozTFMq/ces8imCkLq8KeNrFUtUsAsrPEhmtTSP1LefFl/SMi6EupfDNxJc z0Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Qj0YtbZHgOxwNVTqRESKux6iIBjq7T9eUQOVyf0emJs=; b=ThfRbKcGLXyVGmQzNmYMRDJa5PsQV3h2X9RbWKC1femJa2q52RfgI9k2hbyD3EQfGj +wuGx/tLzG+b7zc9unPtUDuOjhg/gh3kEll28+Fp0Q181t86s+Vqfg4rQCIpXcMk+ZrR anNoll8bbwbYTLicxMxWGGFhvBOsmpdJVut4Nuoab+fnMvvZ1a2ynfmIe7rNwmLFfuDY XXbJul7LPvFgEPf6uLaori7TovgZjRyFo1QnWxRIEWxyni6sKAdmS4FOyDm9/c4xDkTI ShaI86UpHWB2cFvD3/LvguoUe3nDSR9Cgx8jZwwUKblE2X5LiuYduy2lEwOlV97sZUj6 Dh9A== X-Gm-Message-State: AOAM530WeAgBtu5xIer6x4lhUen6T3Ysvjt+QXveO1tVieMk096WndtT av+q1BPFkq+m805uL91OpH0GmA== X-Google-Smtp-Source: ABdhPJyuf57VdZYtnAhE6savUWM0hdeyggmPH5b7V3OM8oBmp//bnwVmoogFOviBZVPjZdhxaT8tdQ== X-Received: by 2002:a05:6214:f2f:b0:441:1bd3:1539 with SMTP id iw15-20020a0562140f2f00b004411bd31539mr5268199qvb.56.1648755455678; Thu, 31 Mar 2022 12:37:35 -0700 (PDT) Received: from mutt-hbsd (pool-100-16-224-136.bltmmd.fios.verizon.net. [100.16.224.136]) by smtp.gmail.com with ESMTPSA id p17-20020a37a611000000b0067b2b2c41fasm125896qke.81.2022.03.31.12.37.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Mar 2022 12:37:35 -0700 (PDT) Date: Thu, 31 Mar 2022 15:37:34 -0400 From: Shawn Webb To: Ed Maste Cc: David Chisnall , FreeBSD Hackers Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support Message-ID: <20220331193734.3pwhap2443gd33hg@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 14.0-CURRENT-HBSD FreeBSD 14.0-CURRENT-HBSD X-PGP-Key: https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/blob/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ph6ib4uu6ovyuodt" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KTtqh1qn4z3pl2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Mh0bMvK+; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::f2a as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-4.96 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; NEURAL_HAM_SHORT(-0.86)[-0.860]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.224.136:received] X-ThisMailContainsUnwantedMimeParts: N --ph6ib4uu6ovyuodt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2022 at 03:33:06PM -0400, Ed Maste wrote: > On Thu, 31 Mar 2022 at 06:25, David Chisnall wrote: > > > > Capsicum simply disallows '..' in paths. >=20 > This is no longer true as of 7359fdcf5ffa. During a lookup the kernel > checks that each ".." component specifies a directory that has already > been visited in this name lookup call. >=20 > > The execve hole is the reason that I have little interest in pledge as > > an enforcement mechanism. >=20 > Note that execve is only available if the "exec" keyword is specified. > The child does not inherit the parent's limits, though. I wonder if there's opportunity here for a little divergence. I think inheritance would be a good thing. But this is more a philosophical and subjective argument than a technical one. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A= 4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --ph6ib4uu6ovyuodt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAmJGAvwACgkQ/y5nonf4 4foOEQ//WCETIFfsCTzVRqAhWFR0Cksm5CnQJ3Q07Olk4ZCSHK8qQZM5KhYug4Si THDcBmF671qwhm4H7rALyeH+4II9uHTRnWK3FsyfUEO96CD3Nzl8cqKOPiMZ/Gwz 1VmTsaUYmdODGjtGC/AgTXp9+4mQGd1jXAO7Kdk57WYMsK8fxQ+YpDth2ejmOtrQ itdiHMB5R5B8OUO3ULB+3tEs1U0uDap1RpzejAnFv7T1NTNOGyIrjow9KbuLf092 mUuBqA0yJPDni46Sqq4FvvKQnuEXNLZ60jiIrKvqYqEcJmZKRb1IZ/0vR4wLkfWt ZnqdQoSH9EQh1TPTYZD5TT4kIbVkR9201Q8EOqQ0HvrlWQ7ka4LYyuAazTGLr8H3 WOZVUSzntxVnCeLUNG5TLIMxduJpQBFbrkuLnN63JIfmEN66fORk0v12BuJ5yiZA RgywFXvA55EDfLLP7nF4WKrg9Aif7JoXh9afx/glSjKJmbKjxWDgoIypJchmeJ4D PHIV2KU8/PGq36aQvtD4Hs//51zrgCU1NsszmwY75WYvspFSwgMLHbm+uNqmsUiT 6I7LWSol3y0hcJdPRCCmQMRuA3JCqUXUOJze1PlN3hBYyIu4W5Mmx50l/O3skz5w hS61Ta0aKM72RSGp7u6pGL0h1lNPGb1xameiACYMrk+3sWORGLo= =rLMD -----END PGP SIGNATURE----- --ph6ib4uu6ovyuodt-- From nobody Thu Mar 31 22:55:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F5421A5D498 for ; Thu, 31 Mar 2022 22:55:46 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTzDK4DQvz4v5c for ; Thu, 31 Mar 2022 22:55:45 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qt1-x832.google.com with SMTP id c4so852443qtx.1 for ; Thu, 31 Mar 2022 15:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=hm0c9jTgHP7s/68fQAofTPG5CK6FtKQjjA+gBrXd2TU=; b=YGnKzrjZgZQ1Op05s9BWkJV3X6yCVvZ30AR3D9JFwF5r9/8OZeHSI80yaCQUjWHfnj SH0SNOaVdig8yZgj8Z9uglLbnjrA9MdIiybcxU2M50t9RwkxPIvgr1bn9uqVOT9P694p zfnF/ymst6jAyx/aSe26xOCxgZX7SbQGEL2eNCqt4FBVg3tpcvsTBbzmcFe5zYyBHXTx a5d7XbARX8innz/3Gs67FDtQJ1KRvUY/EQmpBTQQ1pN03t+CyCHD9UVwlF0QQi8sy9qR MvIc/wiT660irwWnDDbkMVv7K/PQSDdy3tfcIzQeALeYnlqUC61vbCxeoVaTMBUtI3PY jJnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=hm0c9jTgHP7s/68fQAofTPG5CK6FtKQjjA+gBrXd2TU=; b=cZTjzv7YwFROcegJFRSXecwBbynV9pMwe5uPOS4SLj82cc3RDU8dB3yiotsXAzQFbM GAdZxqFpU76CSyUgpaBSu1spH7ZUpPSDDglF9ZDrrBGZl79prE2G8nhyykjam/3t4NnA y0+Yje9M2E7lOW33Z1ZIEg3MJ3dc9mDWveipq/3ogNWoEz90G0mzmXfL+5PCk92pTNTW ckg65n9ZZglckhNRWq/zOvHPehkfK2LqpKmdzxSCrTiP7nLunYtDPgE/c4xO0gMUbXyD GzlKQU2jFXF8IiVYd23ZGd9jePs3wIfZpy0legNvMsRXKRoo0SIlkC2Zx3yAfO3w9S6h nEZg== X-Gm-Message-State: AOAM533rqnQ2qttmLQAPQWsGHYY8TOI6D1IjIPmVVtyIGapuVCZawqCS PjXOzFcQDmVElCC1ejRmwaJvHtdsk1I= X-Google-Smtp-Source: ABdhPJz4qMLjTOrd/+ldm8Ds8hV+ynBgNE4SPF/m3C70MQarU5T/4ERHai3UkWS/Le3O+jJOLWDeXQ== X-Received: by 2002:a05:622a:413:b0:2e1:eb5a:c640 with SMTP id n19-20020a05622a041300b002e1eb5ac640mr6365533qtx.594.1648767338592; Thu, 31 Mar 2022 15:55:38 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id w22-20020ac87e96000000b002eb8e71950csm569455qtj.71.2022.03.31.15.55.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 15:55:37 -0700 (PDT) Message-ID: Date: Thu, 31 Mar 2022 18:55:36 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: freebsd-hackers@freebsd.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KTzDK4DQvz4v5c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=YGnKzrjZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6: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:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/31/22 06:24, David Chisnall wrote: > On 29/03/2022 18:32, Mathieu wrote: >> On 3/29/22 04:34, David Chisnall wrote: >>> Hi, >>> >>> Does pledge actually require kernel support?  I'd have thought that >>> it could be implemented on top of Capsicum as a purely userland >>> abstraction (more easily with libc help, but even with an >>> LD_PRELOADed library along the lines of libpreopen). In Verona, >>> we're able to use Capsicum to run unmodified libraries in a sandbox, >>> for example, including handling raw system calls: >>> >>> https://github.com/microsoft/verona/tree/master/experiments/process_sandbox >>> >>> >>> It would be good to understand why this needs more kernel attack >>> surface. >>> >>> David >> >> If it can work like that then it's pretty cool.  It could be a lot >> more secure.  But it's just not the way I went with. Re-implementing >> so much kernel functionality in userland seems like a lot of work. >> Because I wanted my module to be able to sandbox (almost) everything >> that the OS can run.  Including whole process hierarchies that >> execute other programs and use process management and shared memory, >> etc.  That's a lot of little details to get right...  So I went with >> the same route that jails, other MAC modules and even Capsicum are >> implemented: with access checks in the kernel itself.  And most of >> these checks were already in place with MAC hooks. > > My concern with adding it to the kernel is that anything that does > path-based checks is *incredibly* hard to get right and it will fail > open.  To date, there are zero examples of path-based sandboxing > mechanisms deployed in the wild that have not had vulnerabilities > arising from the nature of the problem.  The filesystem is, > inherently, concurrent.  A process can mutate the shape of the > filesystem graph while you are doing path-based checks, mostly around > the handling of '..' in paths.  Jails and Capsicum sidestep this in > different ways: > > Jails effectively punt the problem to the jail orchestration code.  > They provide very strong restrictions on the paths, with a single root > and allowing all access within this.  There are a few restrictions on > what you can do from outside of a jail to avoid allowing the jailed > process to exploit TOCTOU differences and escaping but fortunately > these align with the use of jails as isolated containers containing > (minimal) base system. > > Capsicum simply disallows '..' in paths.  If you want to support it in > user code then you must do path resolution in userspace. You may still > have TOCTOU bugs, but they'll all fail closed: you will try to resolve > the result, discover that you don't have a file descriptor > corresponding to the path, and fail. Yeah it's by far the hardest part of this module for the reasons you describe.  Directories can move while you're holding references to them or even while you're traversing them.  I mean, this is hell.  My implementation has flaws, but I believe that they have a limited impact, but one of them is a big deal and it means you have to be careful with what you do from outside the sandbox.  I'll try to explain below for anyone interested.  It's similar to the situation with jails.  I still hope I can improve it though. > >> pledge()/unveil() are usually used for fairly well-disciplined >> applications that either don't run other programs or run very >> specific programs that are also well-disciplined and don't expect too >> much (unless you just drop the pledges on execve()). > > The execve hole is the reason that I have little interest in pledge as > an enforcement mechanism.  If a process can just execve itself to > escape, then that's a trivial hole to exploit unless you're incredibly > careful to make sure that the process does not have the ability to > create or read files with executable privilege on the filesystem. I see this with some other sandboxing frameworks too, they allow to execute other programs with higher permissions.  That's something I wanted to avoid completely.  Look how difficult it is to write safe setugid binaries.  All programs you'd allow to run would have to be safe too. pledge() can inherit its restrictions though. If you specify restrictions on the second argument, the executed process will never be able to drop those. Unveils will be inherited as well (but it will not be possible to use unveil() again, so this is not fully "nestable" sandboxing as I call it). But pledge() isn't always used like that because a lot of programs just won't work with inherited pledge restrictions if they weren't designed for it. That's what I wanted my module to support better. > > In contrast, something using Capsicum can create child processes but > they inherit the same limitations.  It can inherit file descriptors > from the parent, so if it is using something like libpreopen then it > can inherit a large number of file descriptors for any of the files / > directories that it should be permitted to open. With my module, generally the sandbox is inherited.  When you use it with curtain(1), that's how it is.  The ability to drop the restrictions on-exec was mostly added for pledge() compatibility. And since my module is designed for arbitrary nesting, what actually happens when you request to drop restrictions on-exec with pledge() is that you return to the restrictions that your process inherited at first (which is no restrictions only if you started with no restrictions). > > Since rtld was extended to allow direct execution mode, you can launch > dynamically linked binaries in Capsicum mode.  With the SIGCAP things > in https://reviews.freebsd.org/D33248, it becomes easy to write a > signal handler that intercepts blocked system calls and handles them > (I'm running with this applied and doing exactly that), so this can be > transparent to any dynamically linked binary. Yeah it's interesting.  I see the "process descriptor" thing too that could make process management capability-based.  Getting a general compat layer built on top of Capsicum could be the best of both worlds. > >> Pledged applications usually reduce the kernel attack surface a lot, >> but you don't run arbitrary programs with pledge (and that wasn't one >> of its goals AFAIK). But that's what I wanted my module to be able to >> do.  I'd say it has become a bit of a weird hybrid between a >> "container" framework and an exploit mitigation framework at this >> point. You can run a `make buildworld` with it, build/install/run >> random programs isolated in your project directories, sandbox >> shell/desktop sessions as a whole, etc.  And then within those >> sandboxes, nested applications can do their own sandboxing on top of >> it (with this module (and its pledge/unveil compat) or Capsicum (and >> possibly other compat layers built on top of it)).  The "inner" >> programs can use more restrictive sandboxes that don't expose as much >> kernel functionality.  But for the "outer" programs the whole thing >> slides more towards being "containers"/"jails" (and the more complex >> it would have been to do purely in userland I believe). > > So how do you avoid TOCTOU bugs in your path logic?  I don't disagree > with the goals, I worry that you're doing something that is > intrinsically almost impossible to get right. > > David > > You're right, it's not done right.  Not fully so.  The security rests on the module never allowing sandboxed processes to alter the directory hierarchy in a way that could cause exploitable confusion.  But if the alterations come from outside, then it can be unsafe.  This is similar to jails but (as you said) it's probably less risky there because of the way jails tend to be used. And I could be wrong about all of this... this is going to need auditing. But IIUC, the risk mainly comes from moving directories from inside of the sandbox to outside of it. Say you sandbox firefox and it has write access to ~/.firefox and a separate $TMPDIR, moving any sub-directory from inside of those to somewhere outside is extremely unsafe.  But moving directories between ~/.firefox and the $TMPDIR, this is fine.  Moving directories from outside to inside, also fine (but they better stay in there).  You could expect no one to do that, but say firefox has access to ~/Downloads though, moving directories out of it is a lot more tempting... So that's a big flaw. Moving directories from a writable sandboxed directory to a read-only sandboxed directory is also dangerous for the same reasons. But all of this has to be done from outside the sandbox. I'm not super happy with it.  I wish there could be protections for that.  But I'm not sure how.  I'd have to keep thinking about it. But for now you have to be careful with what you do from outside of the sandbox to directories unveiled inside of it.  I think it's tolerable.  Even if just barely...  In practice I can imagine it causing problems. The actual implementation is not all that complicated in principle and somewhat similar to jails in some ways.  Instead of the process having one "jail root directory", it has as many as it has unveils. Each curtain unveil entry holds a vnode reference to its directory. And, when you unveil a path, ALL parent directories are also added to the curtain as unveil entries (with permissions to traverse them). When path lookup starts, if needed, it'll ascend the directory hierarchy to find the unveil entry that "covers" the start directory.  After this, checks are strictly done against the curtain, there's no more searching for parent directories.  The module just reacts to traversals of directories that it knows about. Whenever you land on a directory during path lookup (including after ".." lookups), the curtain is searched for the vnode.  The dangerous part of it is when you descend into a directory with no corresponding curtain unveil entries.  Then it switches into "uncharted" mode where it assumes that ALL files can inherit the parent unveil's permissions.  But this is only until you hit another vnode that the curtain knows about.  Then it'll leave "uncharted" mode and inherited permissions will not carry upwards during ".." lookups.  Each unveil (and all of their parent directories) act like a sort of firewall for the hierarchy confusion down below (or at least that's the idea).  And to cause confusion within this outer directory "skeleton", you need to have permissions to alter it in the first place! But within "uncharted" directories anything can happen (using the permissions of the unveil that covers it).  If you can move a directory into the depths of another directory, you can trick curtain into using the permissions of the moved directory on the content of the target directory (curtain won't know where the directory really is when it handles ".." lookups).  But here's the thing: to move that directory there, the unveils must give write access to both the source and target directories in the first place!  So what was gained?  The hierarchy confusion isn't so bad. That's a lie though.  You can get permissions to modify file attributes on a directory for which you only had write permissions this way (those can be separate unveil permissions).  That's something I'll try to fix.  It's just a problem for writable directories that can be moved though, separate file attribute change permissions are still useful for /dev files for example (sandboxed root processes are correctly prevented from changing permissions on /dev/null even if they can write to it). All of this is kind of hard to reason about...  So I hope I got this right (and there could be bugs too obviously). From nobody Thu Mar 31 23:07:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AD1EA1A5FED6 for ; Thu, 31 Mar 2022 23:07:46 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KTzV94mjRz3D2H for ; Thu, 31 Mar 2022 23:07:45 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id j21so907542qta.0 for ; Thu, 31 Mar 2022 16:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=mV5weIf8v65fIs6C0cLBFOLzPU+6AjYqEOvQbXSXxJk=; b=KVUB6bBykIx4fZtv1owY97oA/D2jL+DrayrD8pgHPUu4nZCTZKtU+mp8bdVa9K0XbT l2+QxbOmox18JoxBSGJaP07aoOQL50I+CUvn4S69sODUC6+7sbmUt5B1Y5g0QKd/O5Rs FlGwwkK5Lgmz92J1shh8bvOg816sBClpUz2W94D91j/ojG0r5MU0KMwplHq5pTmRjz4Z sRNnDw90g4o/CvAmTOjMokmJH3L+782b716sJV2W9fnDc0PDrODFQEORzqTPXZtXntv+ gDkdfHWcEIvWvF36ETiP/CbJNF0Bft4Qye4DAcqWdHQUNSut/6sytKRQe5rvecTRlGje NMBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=mV5weIf8v65fIs6C0cLBFOLzPU+6AjYqEOvQbXSXxJk=; b=RgkcRGsU1kBQiOU5NB+twY4sHn1/zt82Svk+tr1W3MWxHNwiwz1hXKgYP+zfKPYq6q fpCfInyOVnHSNTil0IfHS9k0/1tJWoo31cVK7n/8Qqj0NMbnXHnb39clY0mtlDo61IfO ZcgMNbvq/xEA8kjD0AkRGlJNDW2oVMxx85OK1chp76JgEIYH/rCdHm4FRby5I9psJi9Y FqeT3RkZTFBSE/fCWloPh4qWKSpb70HPlKffZMwRsqYr8JL6dTOZX0Hzk1xRNh6a5wk9 yJSeUdamExXLykblSpGAgAX0Pj2t6ROW6H33BIul9CCoM8gMGifnKMH/hZxeM9l9H/pS L/lA== X-Gm-Message-State: AOAM5327Cf5H29hqqIaoyPjEabyfyZACqSNglCoB5eB64vdffNRF42Dg /QNcx+TC1DqjqA5Y8ESFiQYp+xjGhwQ= X-Google-Smtp-Source: ABdhPJzTikWbnF4O7mL6WeC/gX8blcbInBUKPUtbKnFa7fS0HtFO3cYzkaj9GG6SoXfE8aaH4EMOiw== X-Received: by 2002:ac8:4e8b:0:b0:2e2:129b:35f1 with SMTP id 11-20020ac84e8b000000b002e2129b35f1mr6456887qtp.387.1648768059354; Thu, 31 Mar 2022 16:07:39 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id r64-20020a37a843000000b0067b0cf40b18sm390884qke.69.2022.03.31.16.07.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Mar 2022 16:07:38 -0700 (PDT) Message-ID: <93290001-7aaa-4576-170a-6c215eaba6ed@gmail.com> Date: Thu, 31 Mar 2022 19:07:37 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: freebsd-hackers@FreeBSD.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> <20220331193734.3pwhap2443gd33hg@mutt-hbsd> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <20220331193734.3pwhap2443gd33hg@mutt-hbsd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KTzV94mjRz3D2H X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KVUB6bBy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::829 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::829:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/31/22 15:37, Shawn Webb wrote: > On Thu, Mar 31, 2022 at 03:33:06PM -0400, Ed Maste wrote: >> On Thu, 31 Mar 2022 at 06:25, David Chisnall wrote: >>> Capsicum simply disallows '..' in paths. >> This is no longer true as of 7359fdcf5ffa. During a lookup the kernel >> checks that each ".." component specifies a directory that has already >> been visited in this name lookup call. >> >>> The execve hole is the reason that I have little interest in pledge as >>> an enforcement mechanism. >> Note that execve is only available if the "exec" keyword is specified. >> The child does not inherit the parent's limits, though. It does not inherit the restrictions passed as pledge()'s first argument, but it gets the restrictions passed as the second argument (if it is non-NULL) and it can't get rid of those ever. If the executed programs then execute other programs, they will also be restricted to a subset of those restrictions. But you have to actually make use of the second argument (but the child program might not be able to tolerate it...). > I wonder if there's opportunity here for a little divergence. I think > inheritance would be a good thing. But this is more a philosophical > and subjective argument than a technical one. > There's divergeance in my module already, but I tried to keep the pledge() implementation compatible. If you use pledge() alone, this (hopefully) makes no significant difference. But if you use curtain(1), curtain(3) directly or the freebsd_simple_sandbox() wrapper I added, sandbox restrictions are all inherited (irreversibly) by default. And if you use pledge() on top of an inherited curtain, the pledged applications can get rid of its own pledge restrictions on-exec, but it cannot get rid of the inherited curtain restrictions in any way.  (Unless I screwed up!) It's this whole pledge() execve() question that made me come up with an altered design that is fully nestable.  Now pledge() support is sort of "emulated" on top of the more general curtain mechanism. From nobody Fri Apr 1 10:37:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AFD0B1A571B5 for ; Fri, 1 Apr 2022 10:37:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVGpX3CTtz3jn2; Fri, 1 Apr 2022 10:37:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 92D4589284; Fri, 1 Apr 2022 10:37:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 231AbnUa002361 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 1 Apr 2022 10:37:49 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 231AbmQ7002360; Fri, 1 Apr 2022 10:37:48 GMT (envelope-from phk) Message-Id: <202204011037.231AbmQ7002360@critter.freebsd.dk> To: David Chisnall cc: freebsd-hackers@freebsd.org Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-reply-to: <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> From: "Poul-Henning Kamp" References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2358.1648809468.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 01 Apr 2022 10:37:48 +0000 X-Rspamd-Queue-Id: 4KVGpX3CTtz3jn2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- David Chisnall writes: > > pledge()/unveil() are usually used for fairly well-disciplined = > > applications that either don't run other programs or run very specific= = > > programs that are also well-disciplined and don't expect too much = > > (unless you just drop the pledges on execve()). > > The execve hole is the reason that I have little interest in pledge as = > an enforcement mechanism. That (and the name) is why I have never seen it as an enforcement mechanis= m, but only as a special case of asserts: "I pledge that I'm not going to ... (until I tell you otherwise), fail me= if I do". It is not obvious to me what role the "curtain" proposal is intended to pl= ay, or what role the originator of that proposal think pledge()/unveil() has ? What is the level of ambition and the use-cases here ? -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Apr 1 22:51:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D4B1E1A5227B for ; Fri, 1 Apr 2022 22:51:54 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KVb5Q074Rz4hgh for ; Fri, 1 Apr 2022 22:51:54 +0000 (UTC) (envelope-from sigsys@gmail.com) Received: by mail-qv1-xf34.google.com with SMTP id b17so3112850qvf.12 for ; Fri, 01 Apr 2022 15:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to :references:from:subject:in-reply-to:content-transfer-encoding; bh=nzRagAcsO0CP9g+9D8KePydI8IZxPlpSM7iBH9r3VBQ=; b=QRBYj3WcFaj0imX7l8x5TuXQqSB1NFR/crNNH0vINAIhFuPtnO9nnvYbdqJ049NTdD gsQD73s6JpzFy4+cI/KjE/xfm/h1EVTsMBU4k8WuW2AM23V2T4+Rz9b7AKBnK5P55JYx GpWv/TMgEoJN6m4uPUGyqKx20mOQAmLb3us4P7CyIzhdWdwVXSVqy77L767lqBM006XY 2eZ4LlFdwrFHiHF1yfRR6i7mhDKU+oy+RcmfwqWV6eDKSO4oBRHHKrWqJcRElIh0Bw2S OuEIB9IF08KZwl61E+1YSIEUgIddYe3ymkWBti8R8ilxTWyOGFXM2ne+YsmxiczdfYGl RObA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:references:from:subject:in-reply-to :content-transfer-encoding; bh=nzRagAcsO0CP9g+9D8KePydI8IZxPlpSM7iBH9r3VBQ=; b=BtFhJmxIlwLmts242mMYNf9ikyvytPR315Y7x78h0WesdKhJgzUvDhNdEXpnGtFBXU h0Qa5z5xcIUIaFOhw6EV+Itk1bDg1abwrqGiktrB/y1OUub3maimJaq5MElw7kloV+k4 kOgmMbBZVM6wgxngSLOXc6iUF69L6EVPh6AthlyOyw3bk2i77fG4QhI31b/meIYc/o73 Okc3tAFb6hjSqkgsmIeuIov4GNMGHCa5W2ogjGwF8P4UAjJaOwD1oD33NUDo8XqQCEQ6 MvIGAYK8TY4Gxhqmjy5dXOGvOUfNpUho7jG5gA0SIlK6Ztxj6hReWrdczBKpAgfBOIlZ ka1A== X-Gm-Message-State: AOAM530bI61xK4tMnxgX/liza86KH5OzGA6mooTA5IsSKKOAziGhl8fg YvLRhK659LO4aB4BzQ2sU2KN9TYURpg= X-Google-Smtp-Source: ABdhPJyxR6fYyq1ztsgGpdMHo0eqXW/yHjsRDs6OhAI9Pb9XPlALVl+rTLjgNkRuxRvdOmH5xy8HWA== X-Received: by 2002:a05:6214:d42:b0:441:831b:fa1b with SMTP id 2-20020a0562140d4200b00441831bfa1bmr34068529qvr.130.1648853513048; Fri, 01 Apr 2022 15:51:53 -0700 (PDT) Received: from [10.0.0.2] ([162.156.254.107]) by smtp.gmail.com with ESMTPSA id h14-20020a05622a170e00b002e1a65754d8sm2749330qtk.91.2022.04.01.15.51.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Apr 2022 15:51:52 -0700 (PDT) Message-ID: <84f115a9-62e9-669c-24c3-caa9d7cbecb7@gmail.com> Date: Fri, 1 Apr 2022 18:51:51 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: freebsd-hackers@freebsd.org References: <25b5c60f-b9cc-78af-86d7-1cc714232364@gmail.com> <01320c49-fa7e-99d2-5840-3c61bb8c0d57@FreeBSD.org> <2d103b77-84d4-fbd7-d957-21b9aa4d5d79@gmail.com> <16ab7cdb-32b4-5ffe-f6a8-a657383b3078@FreeBSD.org> <202204011037.231AbmQ7002360@critter.freebsd.dk> From: Mathieu Subject: Re: curtain: WIP sandboxing mechanism with pledge()/unveil() support In-Reply-To: <202204011037.231AbmQ7002360@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4KVb5Q074Rz4hgh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QRBYj3Wc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sigsys@gmail.com designates 2607:f8b0:4864:20::f34 as permitted sender) smtp.mailfrom=sigsys@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f34:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 4/1/22 06:37, Poul-Henning Kamp wrote: > -------- > David Chisnall writes: > >>> pledge()/unveil() are usually used for fairly well-disciplined >>> applications that either don't run other programs or run very specific >>> programs that are also well-disciplined and don't expect too much >>> (unless you just drop the pledges on execve()). >> The execve hole is the reason that I have little interest in pledge as >> an enforcement mechanism. > That (and the name) is why I have never seen it as an enforcement mechanism, but only as a special case of asserts: > > "I pledge that I'm not going to ... (until I tell you otherwise), fail me if I do". > > It is not obvious to me what role the "curtain" proposal is intended to play, > or what role the originator of that proposal think pledge()/unveil() has ? Not sure how I would define what pledge()/unveil() are on OpenBSD.  I think that they don't like the words "containers" or "sandboxes" for some reason (those are poorly defined terms anyway).  I have more often seen it described as an "exploit-mitigation" mechanism.  I believe that reducing the kernel attack surface was a big priority for them (while it's more of a secondary goal for me).  But as far as I can tell, the enforcement is solid.  How much of a "sandbox" it really is depends on the pledge promises and unveils that you use.  The "execve hole" is just there if you ask for it. And it's a bit difficult to explain how curtain/pledge are different as mechanisms without enumerating all of the details that are different.  But they added up enough that I thought it was better to give it a different name and a different API rather than trying to mold pledge() into something it wasn't designed to be.  And with a separate API I didn't have to worry about breaking pledge()/unveil() compatibility all the time. The main problems I had with pledge()/unveil() for my goals were: 1) pledge() is capable of sandboxing unsuspecting programs but only to some extent.  There are a lot of little details that will make many programs fail.  With curtain(1) you can get much more of a real UNIX-like environment while (hopefully!) remaining isolated.  And what really helped with that was that on FreeBSD, kernel access checks were already modularized.  So it's much easier to expose more kernel functionality while maintaining isolation. 2) pledge() is nestable, but unveil() is not.  Once you "commit" your unveils, you can't ever use unveil() again (nor can any of the programs you execute).  And unveil is essential for sandboxing.  That's a problem if you, say, run a whole shell session sandboxed, and then try to sandbox something within it (or run something that tries to self-sandbox itself automatically). Or say if you wanted to sandbox firefox as a whole on top of firefox using pledge()/unveil() internally (to get proper isolation in-between its own processes as well).  All of this works with my curtain module. 3) I wanted restrictions to be more configurable in userland (partly to help with testing applications).  I didn't want to have to modify the kernel every time I wanted to add permissions for a certain sysctl, ioctl, privilege, socket option, etc.  That's the main reason I used a completely different API.  Also, on OpenBSD, the paths allowed by certain promises (e.g. "/dev/stdout" for "stdio", "/etc/resolv.conf" for "dns", etc) are hardcoded in the kernel and the semantics are different than from user unveils.  I moved this to the userland too and there's a unified method to unveil paths (which also helps fixing problem 2). 4) unveil() doesn't reveal the directory "skeleton" above the paths that you unveil (you generally get ENOENT trying to stat() or list parent directories).  This makes a lot of programs unhappy (especially GUI ones).  With curtain(1) by default you get a filtered view of the FS instead (but the unveil(3) compatibility still behaves like on OpenBSD). To run unsuspecting programs, you'd use the curtain(1) utility.  And there's a configuration system to manage permissions.  This does not use pledge() at all anywhere, it uses a new curtain(3) API (and the underlying curtainctl(2) syscall). I think the nearest analogy to curtain(1) is "firejail" on Linux, not pledge(). > What is the level of ambition and the use-cases here ? > To easily run EVERYTHING sandboxed.  Realistically it won't be able to.  But it's the goal.  If a program doesn't work, then why not?  It should. For desktop apps, the main problems are programs that ignore $TMPDIR, dbus/dconf and untrusted X11 problems.  And many KDE apps that need their own separate XDG directories to work for now. But browsers work, audio players work, gimp works, qbittorrent works, libreoffice works if you give it access to /tmp. Sandboxing whole shell sessions work.  You can build/run untrusted programs and confine the whole thing to the current directory (but you need to be very careful with the way you run git in it for example).  These aren't things that you do with pledge(), but it's what curtain(1) was designed to do and it tries to make it convenient. There are other use cases, like something I'd call "last-ditch" sandboxing for server programs that need to run as root (say to authenticate users and switch credentials).  It's possible to run samba for example with read-only access to the needed system files, read-write access to its own state/logs directories and restrict its access to specific data directories you want to share.  I believe that this can maintain system integrity if samba is compromised.  This becomes a bit like "traditional MAC" with the integrity labels, but it can be setup on an application-by-application basis rather than the whole system.  It might not be worth it if the most important thing on the server to begin with are those data directories, but at the very least it could make forensics easier if there's a breach.  There are examples of this in the sample config file. From nobody Tue Apr 5 13:17:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A90591A9B570 for ; Tue, 5 Apr 2022 13:18:37 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXpB26X4cz3qDN for ; Tue, 5 Apr 2022 13:18:33 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 235DI86a073998 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 5 Apr 2022 22:48:17 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1649164701; bh=p1dQ5vMYW5dfuJrR8rIeqVXvL3gi3jsEUX3Pn0YOR3E=; h=From:Date:Subject:To; b=tF+OCrNqm60sA649oyxQVq+2QfPaW21I01UQ4mkT4W4dAi1EXIymwygvDxmrcx0Rf 1rMXfwZgSBoRz3DW6ztxeli6CnuaC7J53EH0he9x9ljkjkvF+TOTKBC3qn3qMUaRbG 4ONEhGmVZzebCmwLHTvl4B8MYPrzHOlDsFQiei5I= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 235DHs5M073988 for ; Tue, 5 Apr 2022 22:47:54 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:911c:5511:b47e:d9d Received: from smtpclient.apple (2403-5800-5200-4700-911c-5511-b47e-d9d.ip6.aussiebb.net [2403:5800:5200:4700:911c:5511:b47e:d9d]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 235DHrYU073985; Tue, 05 Apr 2022 22:47:53 +0930 From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Date: Tue, 5 Apr 2022 22:47:53 +0930 Subject: PEFS and advisory locking on ZFS Message-Id: <03F69985-51A4-4A35-801C-CFC7B40B766D@dons.net.au> To: freebsd-hackers X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Score: 0.7 () No, score=0.7 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4KXpB26X4cz3qDN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=tF+OCrNq; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I maintain the PEFS port/project (https://github.com/freebsd-pefs/pefs/) = which is an encrypted file system which transparently runs on top of = other file systems. I've updated it to work OK however someone has discovered that if it's = running on top of ZFS then locking doesn't work, >1 process can own a = lock (as tested with lockf) It FreeBSD 13.1-RC1 (tested with releng/13.1-n250053-6fe29001573 GENERIC = arm64) - when testing on -current (14.0-CURRENT #1 main-3468cd95c) it = does work. I tried implemented VOP_ADVLOCK but it didn't help (not really = surprising but still). The test is pretty simple, if /testtank is ZFS, then: # Create crypto FS sudo mkdir -p /testtank/test/pefs echo test123 >keyfile sudo pefs addchain -fZj keyfile /testtank/test/pefs # Mount it and add the key sudo pefs mount /testtank/test/pefs /testtank/test/pefs sudo pefs addkey -cj keyhole /testtank/test/pefs # Test locking sudo lockf -k -t 0 /testtank/test/pefs/lock sleep 5 & sudo lockf -k -t 0 /testtank/test/pefs/lock echo foo When it's working the second lockf will print: lockf: /testtank/test/pefs/lock: already locked ZFS itself is fine, the lock test passes if PEFS isn't mounted, and on = the same version PEFS on UFS works fine also. I plan on bisecting it but if anyone has a suggestion I'm all ears. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Tue Apr 5 20:57:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 932771AA0606 for ; Tue, 5 Apr 2022 20:57:47 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oa1-f42.google.com (mail-oa1-f42.google.com [209.85.160.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KY0Mt3sfcz4j1g for ; Tue, 5 Apr 2022 20:57:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-de3ca1efbaso724920fac.9 for ; Tue, 05 Apr 2022 13:57:46 -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=UZjsFujz+Rz+2b/FCym41tIixDj5aaQzaoCFqa3u7jY=; b=A9fybsfJ84PuE0RDvLNQtnkDIW1r9ykRvWH8lraW2JG5owIkbpn0dfM2USEuqZTaSi 50v7RCUHjPUULndkoguHIiFDcyxiPVjxwBsJkHDBXETeyGa3sUhWL6e+klHZqzrQcdGH M9nKq6wf8sY5qhncF4CYRQs0Qt0wymO9ySPbAO1DWmDYqfqi2XBRjeyYeZSQOPiDCO9C i0SLiIYzbuW1x8GIOBxDeR45YAd8SuCPkalpSJyxJggMeo2JAjpFUwMz1q5UaAGbR0TT koeG/hKyQwSo/60BpSoL4rKFzebyH0RcjJwiQKjt3KvdPWz6y9s6HX14k2Ts67F6SYBg dNxw== X-Gm-Message-State: AOAM533hm7zScgFfaOhpAG2joieNbyyvB1aJ7E4H5lAtAPupsF8E5xHf mubgOKNp2siJzqw59HBEkN990k6ibz3TI0OFEYsHVyr8 X-Google-Smtp-Source: ABdhPJxn/ofE5YOj+LpCjAwI0Nu2EP0Nx2O1ve37Wf3EY5Jq0X1lH11vGBhifbmzZ8wJ1B8dOB8jSkQmtGoRI9t98RE= X-Received: by 2002:a05:6870:a2d2:b0:d7:60ca:5065 with SMTP id w18-20020a056870a2d200b000d760ca5065mr2549739oak.72.1649192260230; Tue, 05 Apr 2022 13:57:40 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <03F69985-51A4-4A35-801C-CFC7B40B766D@dons.net.au> In-Reply-To: <03F69985-51A4-4A35-801C-CFC7B40B766D@dons.net.au> From: Alan Somers Date: Tue, 5 Apr 2022 14:57:29 -0600 Message-ID: Subject: Re: PEFS and advisory locking on ZFS To: "Daniel O'Connor" Cc: freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KY0Mt3sfcz4j1g X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.42 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.93 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.42:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.94)[-0.937]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.42:from]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-hackers]; 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 Tue, Apr 5, 2022 at 7:19 AM Daniel O'Connor wrote: > > Hi, > I maintain the PEFS port/project (https://github.com/freebsd-pefs/pefs/) which is an encrypted file system which transparently runs on top of other file systems. > > I've updated it to work OK however someone has discovered that if it's running on top of ZFS then locking doesn't work, >1 process can own a lock (as tested with lockf) > > It FreeBSD 13.1-RC1 (tested with releng/13.1-n250053-6fe29001573 GENERIC arm64) - when testing on -current (14.0-CURRENT #1 main-3468cd95c) it does work. > > I tried implemented VOP_ADVLOCK but it didn't help (not really surprising but still). > > The test is pretty simple, if /testtank is ZFS, then: > > # Create crypto FS > sudo mkdir -p /testtank/test/pefs > echo test123 >keyfile > sudo pefs addchain -fZj keyfile /testtank/test/pefs > > # Mount it and add the key > sudo pefs mount /testtank/test/pefs /testtank/test/pefs > sudo pefs addkey -cj keyhole /testtank/test/pefs > > # Test locking > sudo lockf -k -t 0 /testtank/test/pefs/lock sleep 5 & > sudo lockf -k -t 0 /testtank/test/pefs/lock echo foo > > When it's working the second lockf will print: > lockf: /testtank/test/pefs/lock: already locked > > ZFS itself is fine, the lock test passes if PEFS isn't mounted, and on the same version PEFS on UFS works fine also. > > I plan on bisecting it but if anyone has a suggestion I'm all ears. > > Thanks. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum Does it use flock or fcntl with F_GETLK/F_SETLK? Or worse, does it mix the two? Is fusefs involved? And does it work on top of UFS? From nobody Tue Apr 5 22:11:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CAF6B1A8805E for ; Tue, 5 Apr 2022 22:12:24 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KY21y3MKnz4vgV for ; Tue, 5 Apr 2022 22:12:21 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 235MC9vH067862 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 6 Apr 2022 07:42:13 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1649196737; bh=hajmV3m2B7HG11aP6JpmFdHE9SHVIGpaBxHfMH5MVV4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dU/KXoU/u5g8WyCp5v8YHbj3Sq27yJuiNnHj1zKkwwxiqsoiTqH1uwkBsE98MAnQ3 EPJtjaWLDC6eZUTCvLtYNQr7DdAtmmZVHL/xN8MkQ5pSkVfmR/kCrGQwlfx73GXCiJ uISZESRRX+Cef4R8j1Q92XZeSQeoIJXTFQMOtANg= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 235MBrJ5067827 for ; Wed, 6 Apr 2022 07:41:53 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-0ce1a11234c790b6ab6410cd70c6fdb820520472: 2403:5800:5200:4700:911c:5511:b47e:d9d Received: from smtpclient.apple (2403-5800-5200-4700-911c-5511-b47e-d9d.ip6.aussiebb.net [2403:5800:5200:4700:911c:5511:b47e:d9d]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 235MBq9W067822; Wed, 06 Apr 2022 07:41:53 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: PEFS and advisory locking on ZFS From: "Daniel O'Connor" In-Reply-To: Date: Wed, 6 Apr 2022 07:41:52 +0930 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <7EA062FC-54F8-48BB-958A-84C92652BEA3@dons.net.au> References: <03F69985-51A4-4A35-801C-CFC7B40B766D@dons.net.au> To: Alan Somers X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Score: 0.7 () No, score=0.7 required=5.0 tests=KHOP_HELO_FCRDNS, PDS_RDNS_DYNAMIC_FP,RDNS_DYNAMIC,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 4KY21y3MKnz4vgV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b="dU/KXoU/"; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 6 Apr 2022, at 06:27, Alan Somers wrote: >> ZFS itself is fine, the lock test passes if PEFS isn't mounted, and = on the same version PEFS on UFS works fine also. >>=20 >> I plan on bisecting it but if anyone has a suggestion I'm all ears. >=20 > Does it use flock or fcntl with F_GETLK/F_SETLK? Or worse, does it > mix the two? Is fusefs involved? And does it work on top of UFS? I tested with lockf(1) which uses flock(3) but the odd part is it works = on top of UFS but not ZFS.. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Wed Apr 6 11:18:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AEDF01AA6A25 for ; Wed, 6 Apr 2022 11:18:51 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYMTQ64yZz4dHr for ; Wed, 6 Apr 2022 11:18:50 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 1AD4260C109 for ; Wed, 6 Apr 2022 13:18:49 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_94ea2695193cf369660b9253165fcef5" Date: Wed, 06 Apr 2022 13:18:49 +0200 From: egoitz@ramattack.net To: Freebsd hackers Subject: Desperate with 870 QVO and ZFS Message-ID: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYMTQ64yZz4dHr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-1.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.946]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.876]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --=_94ea2695193cf369660b9253165fcef5 Content-Type: multipart/alternative; boundary="=_fa7f63b00c51f44a9a0b358901477e45" --=_fa7f63b00c51f44a9a0b358901477e45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Good morning, I write this post with the expectation that perhaps someone could help me I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. The problem I'm facing is that they could be running just fine and suddenly at some peak hour, the IO goes to 60 or 70% and the machine becomes extremely slow. ZFS is all by default, except the sync parameter which is set disabled. Apart from that the ARC is limited to 64GB. But even this is extremely odd. The used ARC is near 20GB. I have seen, that meta cache in arc is very near to the limit that FreeBSD automatically sets depending on the size of the ARC you set. It seems that almost all ARC is used by meta cache. I have seen this effect in all my mail servers with this hardware and software config. I do attach a zfs-stats output, but from now that the servers are not so loaded as described. I do explain. I run a couple of Cyrus instances in these servers. One as master, one as slave on each server. The commented situation from above, happens when both Cyrus instances become master, so when we are using two Cyrus instances giving service in the same machine. For avoiding issues, know we have balanced and we have a master and a slave in each server. You know, a slave instance has almost no io and only a single connection for replication. So the zfs-stats output is from now we have let's say half of load in each server, because they have one master and one slave instance. As said before, when I place two masters in same server, perhaps all day works, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increase) but it seems like if the IO where not being able to be served, let's say more than a limit. More than a concrete io limit (I'd say 60%). I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later... I have get a nice performance when copying for instance mailboxes from five to five.... I can flood a gigabit interface when copying mailboxes between servers from five to five.... they seem to perform.... Could anyone please shed us some light in this issue?. I don't really know what to think. Best regards, --=_fa7f63b00c51f44a9a0b358901477e45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
Good morning,

I write this post with = the expectation that perhaps someone could help me 3D":)"

I am running= some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other= Samsung SSD disks) disks as storage. They can easily have from 1500 to 200= 0 concurrent connections. The machines have 128GB of ram and the CPU is alm= ost absolutely idle. The disk IO is normally at 30 or 40% percent at most= =2E

The problem I'm facing is that they could be running just = fine and suddenly at some peak hour, the IO goes to 60 or 70% and the machi= ne becomes extremely slow. ZFS is all by default, except the sync parameter= which is set disabled. Apart from that the ARC is limited to 64GB. But eve= n this is extremely odd. The used ARC is near 20GB. I have seen, that meta = cache in arc is very near to the limit that FreeBSD automatically sets depe= nding on the size of the ARC you set. It seems that almost all ARC is used = by meta cache. I have seen this effect in all my mail servers with this har= dware and software config.

I do attach a zfs-stats output, but= from now that the servers are not so loaded as described. I do explain. I = run a couple of Cyrus instances in these servers. One as master, one as sla= ve on each server. The commented situation from above, happens when both Cy= rus instances become master, so when we are using two Cyrus instances givin= g service in the same machine. For avoiding issues, know we have balanced a= nd we have a master and a slave in each server. You know, a slave instance = has almost no io and only a single connection for replication. So the zfs-s= tats output is from now we have let's say half of load in each server, beca= use they have one master and one slave instance.

As said befor= e, when I place two masters in same server, perhaps all day works, but just= at 11:00 am (for example) the IO goes to 60% (it doesn't increase) but it = seems like if the IO where not being able to be served, let's say more than= a limit. More than a concrete io limit (I'd say 60%).

I don't= really know if, perhaps the QVO technology could be the guilty here.... be= cause... they say are desktop computers disks... but later... I have get a = nice performance when copying for instance mailboxes from five to five...= =2E I can flood a gigabit interface when copying mailboxes between servers = from five to five.... they seem to perform....

Could anyone pl= ease shed us some light in this issue?. I don't really know what to think= =2E

Best regards,
 


--=_fa7f63b00c51f44a9a0b358901477e45-- --=_94ea2695193cf369660b9253165fcef5 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=zfs-stats.txt Content-Disposition: attachment; filename=zfs-stats.txt; size=12369 L3RtcC96ZnMtc3RhdHMgLWEKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpaRlMgU3Vic3lzdGVtIFJlcG9ydAkJ CQlXZWQgQXByICA2IDExOjU4OjE4IDIwMjIKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpTeXN0ZW0gSW5mb3Jt YXRpb246CgoJS2VybmVsIFZlcnNpb246CQkJCTEyMDIwMDAgKG9zcmVsZGF0ZSkKCUhhcmR3YXJl IFBsYXRmb3JtOgkJCWFtZDY0CglQcm9jZXNzb3IgQXJjaGl0ZWN0dXJlOgkJCWFtZDY0CgoJWkZT IFN0b3JhZ2UgcG9vbCBWZXJzaW9uOgkJNTAwMAoJWkZTIEZpbGVzeXN0ZW0gVmVyc2lvbjoJCQk1 CgpGcmVlQlNEIDEyLjItUkVMRUFTRS1wNiByMzY5ODU1IEdFTkVSSUMgMTE6NThBTSAgdXAgMTQ4 IGRheXMsIDIwOjI5LCAxIHVzZXIsIGxvYWQgYXZlcmFnZXM6IDIuMTEsIDIuNDcsIDIuMjYKCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQoKU3lzdGVtIE1lbW9yeToKCgkzLjI0JQk0LjAzCUdpQiBBY3RpdmUsCTcx LjUwJQk4OC45MwlHaUIgSW5hY3QKCTIyLjc4JQkyOC4zMwlHaUIgV2lyZWQsCTAuMDAlCTAJQnl0 ZXMgQ2FjaGUKCTIuMjUlCTIuODAJR2lCIEZyZWUsCTAuMjMlCTI5Mi42MQlNaUIgR2FwCgoJUmVh bCBJbnN0YWxsZWQ6CQkJCTEyOC4wMAlHaUIKCVJlYWwgQXZhaWxhYmxlOgkJCTk5LjcwJQkxMjcu NjIJR2lCCglSZWFsIE1hbmFnZWQ6CQkJOTcuNDclCTEyNC4zOQlHaUIKCglMb2dpY2FsIFRvdGFs OgkJCQkxMjguMDAJR2lCCglMb2dpY2FsIFVzZWQ6CQkJMjguMzMlCTM2LjI2CUdpQgoJTG9naWNh bCBGcmVlOgkJCTcxLjY3JQk5MS43NAlHaUIKCktlcm5lbCBNZW1vcnk6CQkJCQkzLjIxCUdpQgoJ RGF0YToJCQkJOTguODIlCTMuMTcJR2lCCglUZXh0OgkJCQkxLjE4JQkzOC42NQlNaUIKCktlcm5l bCBNZW1vcnkgTWFwOgkJCQkxMjQuMzkJR2lCCglTaXplOgkJCQkyMi4zNCUJMjcuNzkJR2lCCglG cmVlOgkJCQk3Ny42NiUJOTYuNjAJR2lCCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkFSQyBTdW1tYXJ5OiAo SEVBTFRIWSkKCU1lbW9yeSBUaHJvdHRsZSBDb3VudDoJCQkwCgpBUkMgTWlzYzoKCURlbGV0ZWQ6 CQkJCTEuNzgJYgoJTXV0ZXggTWlzc2VzOgkJCQkxODcuMjUJbQoJRXZpY3QgU2tpcHM6CQkJCTg3 LjM1CWIKCkFSQyBTaXplOgkJCQkyOS4yNSUJMTguNzIJR2lCCglUYXJnZXQgU2l6ZTogKEFkYXB0 aXZlKQkJMTIuNTAlCTguMDAJR2lCCglNaW4gU2l6ZSAoSGFyZCBMaW1pdCk6CQkxMi41MCUJOC4w MAlHaUIKCU1heCBTaXplIChIaWdoIFdhdGVyKToJCTg6MQk2NC4wMAlHaUIKCURlY29tcHJlc3Nl ZCBEYXRhIFNpemU6CQkJOS41MglHaUIKCUNvbXByZXNzaW9uIEZhY3RvcjoJCQkwLjUxCgpBUkMg U2l6ZSBCcmVha2Rvd246CglSZWNlbnRseSBVc2VkIENhY2hlIFNpemU6CTIuNjclCTUxMi4wMAlN aUIKCUZyZXF1ZW50bHkgVXNlZCBDYWNoZSBTaXplOgk5Ny4zMyUJMTguMjIJR2lCCgpBUkMgSGFz aCBCcmVha2Rvd246CglFbGVtZW50cyBNYXg6CQkJCTMuMTEJbQoJRWxlbWVudHMgQ3VycmVudDoJ CTE5LjIxJQk1OTYuNjIJawoJQ29sbGlzaW9uczoJCQkJMjAzLjY0CW0KCUNoYWluIE1heDoJCQkJ NQoJQ2hhaW5zOgkJCQkJMTAuMjMJawoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpBUkMgRWZmaWNpZW5jeToJ CQkJCTE4OC4wNgliCglDYWNoZSBIaXQgUmF0aW86CQk5OC42MyUJMTg1LjQ4CWIKCUNhY2hlIE1p c3MgUmF0aW86CQkxLjM3JQkyLjU4CWIKCUFjdHVhbCBIaXQgUmF0aW86CQk5OC42MiUJMTg1LjQ2 CWIKCglEYXRhIERlbWFuZCBFZmZpY2llbmN5OgkJOTguNDQlCTU3LjM2CWIKCURhdGEgUHJlZmV0 Y2ggRWZmaWNpZW5jeToJMi40NSUJODU5LjAzCW0KCglDQUNIRSBISVRTIEJZIENBQ0hFIExJU1Q6 CgkgIE1vc3QgUmVjZW50bHkgVXNlZDoJCTEwLjg5JQkyMC4yMAliCgkgIE1vc3QgRnJlcXVlbnRs eSBVc2VkOgkJODkuMTAlCTE2NS4yNgliCgkgIE1vc3QgUmVjZW50bHkgVXNlZCBHaG9zdDoJMC4w NyUJMTM4LjcwCW0KCSAgTW9zdCBGcmVxdWVudGx5IFVzZWQgR2hvc3Q6CTAuMTYlCTMwMC44NAlt CgoJQ0FDSEUgSElUUyBCWSBEQVRBIFRZUEU6CgkgIERlbWFuZCBEYXRhOgkJCTMwLjQ0JQk1Ni40 NgliCgkgIFByZWZldGNoIERhdGE6CQkwLjAxJQkyMS4wMQltCgkgIERlbWFuZCBNZXRhZGF0YToJ CTY5LjU0JQkxMjguOTgJYgoJICBQcmVmZXRjaCBNZXRhZGF0YToJCTAuMDElCTE2LjA5CW0KCglD QUNIRSBNSVNTRVMgQlkgREFUQSBUWVBFOgoJICBEZW1hbmQgRGF0YToJCQkzNC43NSUJODk2LjY3 CW0KCSAgUHJlZmV0Y2ggRGF0YToJCTMyLjQ3JQk4MzguMDIJbQoJICBEZW1hbmQgTWV0YWRhdGE6 CQkzMS4xOCUJODA0LjU3CW0KCSAgUHJlZmV0Y2ggTWV0YWRhdGE6CQkxLjYwJQk0MS4yNwltCgot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KCkwyQVJDIGlzIGRpc2FibGVkCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClBlciBk YXRhc2V0IHN0YXRpc3RpY3MgYXJlIG5vdCBhdmFpbGFibGUKCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKRmls ZS1MZXZlbCBQcmVmZXRjaDoKCkRNVSBFZmZpY2llbmN5OgkJCQkJODMuNTIJYgoJSGl0IFJhdGlv OgkJCTIuNzQlCTIuMjkJYgoJTWlzcyBSYXRpbzoJCQk5Ny4yNiUJODEuMjMJYgoKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCgpWREVWIGNhY2hlIGlzIGRpc2FibGVkCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClpGUyBUdW5h YmxlcyAoc3lzY3RsKToKCWtlcm4ubWF4dXNlcnMgICAgICAgICAgICAgICAgICAgICAgICAgICA4 NTAzCgl2bS5rbWVtX3NpemUgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTMzNTYwMzA3NzEy Cgl2bS5rbWVtX3NpemVfc2NhbGUgICAgICAgICAgICAgICAgICAgICAgMQoJdm0ua21lbV9zaXpl X21pbiAgICAgICAgICAgICAgICAgICAgICAgIDAKCXZtLmttZW1fc2l6ZV9tYXggICAgICAgICAg ICAgICAgICAgICAgICAxMzE5NDEzOTUwODc0Cgl2ZnMuemZzLnRyaW0ubWF4X2ludGVydmFsICAg ICAgICAgICAgICAgMQoJdmZzLnpmcy50cmltLnRpbWVvdXQgICAgICAgICAgICAgICAgICAgIDMw Cgl2ZnMuemZzLnRyaW0udHhnX2RlbGF5ICAgICAgICAgICAgICAgICAgMzIKCXZmcy56ZnMudHJp bS5lbmFibGVkICAgICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLnZvbC5pbW1lZGlhdGVfd3Jp dGVfc3ogICAgICAgICAgMzI3NjgKCXZmcy56ZnMudm9sLnVubWFwX3N5bmNfZW5hYmxlZCAgICAg ICAgICAwCgl2ZnMuemZzLnZvbC51bm1hcF9lbmFibGVkICAgICAgICAgICAgICAgMQoJdmZzLnpm cy52b2wucmVjdXJzaXZlICAgICAgICAgICAgICAgICAgIDAKCXZmcy56ZnMudm9sLm1vZGUgICAg ICAgICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLnZlcnNpb24uenBsICAgICAgICAgICAgICAg ICAgICAgNQoJdmZzLnpmcy52ZXJzaW9uLnNwYSAgICAgICAgICAgICAgICAgICAgIDUwMDAKCXZm cy56ZnMudmVyc2lvbi5hY2wgICAgICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLnZlcnNpb24u aW9jdGwgICAgICAgICAgICAgICAgICAgNwoJdmZzLnpmcy5kZWJ1ZyAgICAgICAgICAgICAgICAg ICAgICAgICAgIDAKCXZmcy56ZnMuc3VwZXJfb3duZXIgICAgICAgICAgICAgICAgICAgICAwCgl2 ZnMuemZzLmltbWVkaWF0ZV93cml0ZV9zeiAgICAgICAgICAgICAgMzI3NjgKCXZmcy56ZnMuc3lu Y19wYXNzX3Jld3JpdGUgICAgICAgICAgICAgICAyCgl2ZnMuemZzLnN5bmNfcGFzc19kb250X2Nv bXByZXNzICAgICAgICAgNQoJdmZzLnpmcy5zeW5jX3Bhc3NfZGVmZXJyZWRfZnJlZSAgICAgICAg IDIKCXZmcy56ZnMuemlvLmR2YV90aHJvdHRsZV9lbmFibGVkICAgICAgICAxCgl2ZnMuemZzLnpp by5leGNsdWRlX21ldGFkYXRhICAgICAgICAgICAgMAoJdmZzLnpmcy56aW8udXNlX3VtYSAgICAg ICAgICAgICAgICAgICAgIDEKCXZmcy56ZnMuemlvLnRhc2txX2JhdGNoX3BjdCAgICAgICAgICAg ICA3NQoJdmZzLnpmcy56aWxfbWF4YmxvY2tzaXplICAgICAgICAgICAgICAgIDEzMTA3MgoJdmZz Lnpmcy56aWxfc2xvZ19idWxrICAgICAgICAgICAgICAgICAgIDc4NjQzMgoJdmZzLnpmcy56aWxf bm9jYWNoZWZsdXNoICAgICAgICAgICAgICAgIDAKCXZmcy56ZnMuemlsX3JlcGxheV9kaXNhYmxl ICAgICAgICAgICAgICAwCgl2ZnMuemZzLmNhY2hlX2ZsdXNoX2Rpc2FibGUgICAgICAgICAgICAg MAoJdmZzLnpmcy5zdGFuZGFyZF9zbV9ibGtzeiAgICAgICAgICAgICAgIDEzMTA3MgoJdmZzLnpm cy5kdGxfc21fYmxrc3ogICAgICAgICAgICAgICAgICAgIDQwOTYKCXZmcy56ZnMubWluX2F1dG9f YXNoaWZ0ICAgICAgICAgICAgICAgICAxMgoJdmZzLnpmcy5tYXhfYXV0b19hc2hpZnQgICAgICAg ICAgICAgICAgIDEzCgl2ZnMuemZzLnZkZXYudHJpbV9tYXhfcGVuZGluZyAgICAgICAgICAgMTAw MDAKCXZmcy56ZnMudmRldi5iaW9fZGVsZXRlX2Rpc2FibGUgICAgICAgICAwCgl2ZnMuemZzLnZk ZXYuYmlvX2ZsdXNoX2Rpc2FibGUgICAgICAgICAgMAoJdmZzLnpmcy52ZGV2LmRlZl9xdWV1ZV9k ZXB0aCAgICAgICAgICAgIDMyCgl2ZnMuemZzLnZkZXYucXVldWVfZGVwdGhfcGN0ICAgICAgICAg ICAgMTAwMAoJdmZzLnpmcy52ZGV2LndyaXRlX2dhcF9saW1pdCAgICAgICAgICAgIDQwOTYKCXZm cy56ZnMudmRldi5yZWFkX2dhcF9saW1pdCAgICAgICAgICAgICAzMjc2OAoJdmZzLnpmcy52ZGV2 LmFnZ3JlZ2F0aW9uX2xpbWl0X25vbl9yb3RhdGluZzEzMTA3MgoJdmZzLnpmcy52ZGV2LmFnZ3Jl Z2F0aW9uX2xpbWl0ICAgICAgICAgIDEwNDg1NzYKCXZmcy56ZnMudmRldi5pbml0aWFsaXppbmdf bWF4X2FjdGl2ZSAgICAxCgl2ZnMuemZzLnZkZXYuaW5pdGlhbGl6aW5nX21pbl9hY3RpdmUgICAg MQoJdmZzLnpmcy52ZGV2LnJlbW92YWxfbWF4X2FjdGl2ZSAgICAgICAgIDIKCXZmcy56ZnMudmRl di5yZW1vdmFsX21pbl9hY3RpdmUgICAgICAgICAxCgl2ZnMuemZzLnZkZXYudHJpbV9tYXhfYWN0 aXZlICAgICAgICAgICAgNjQKCXZmcy56ZnMudmRldi50cmltX21pbl9hY3RpdmUgICAgICAgICAg ICAxCgl2ZnMuemZzLnZkZXYuc2NydWJfbWF4X2FjdGl2ZSAgICAgICAgICAgMgoJdmZzLnpmcy52 ZGV2LnNjcnViX21pbl9hY3RpdmUgICAgICAgICAgIDEKCXZmcy56ZnMudmRldi5hc3luY193cml0 ZV9tYXhfYWN0aXZlICAgICAxMAoJdmZzLnpmcy52ZGV2LmFzeW5jX3dyaXRlX21pbl9hY3RpdmUg ICAgIDEKCXZmcy56ZnMudmRldi5hc3luY19yZWFkX21heF9hY3RpdmUgICAgICAzCgl2ZnMuemZz LnZkZXYuYXN5bmNfcmVhZF9taW5fYWN0aXZlICAgICAgMQoJdmZzLnpmcy52ZGV2LnN5bmNfd3Jp dGVfbWF4X2FjdGl2ZSAgICAgIDEwCgl2ZnMuemZzLnZkZXYuc3luY193cml0ZV9taW5fYWN0aXZl ICAgICAgMTAKCXZmcy56ZnMudmRldi5zeW5jX3JlYWRfbWF4X2FjdGl2ZSAgICAgICAxMAoJdmZz Lnpmcy52ZGV2LnN5bmNfcmVhZF9taW5fYWN0aXZlICAgICAgIDEwCgl2ZnMuemZzLnZkZXYubWF4 X2FjdGl2ZSAgICAgICAgICAgICAgICAgMTAwMAoJdmZzLnpmcy52ZGV2LmFzeW5jX3dyaXRlX2Fj dGl2ZV9tYXhfZGlydHlfcGVyY2VudDYwCgl2ZnMuemZzLnZkZXYuYXN5bmNfd3JpdGVfYWN0aXZl X21pbl9kaXJ0eV9wZXJjZW50MzAKCXZmcy56ZnMudmRldi5taXJyb3Iubm9uX3JvdGF0aW5nX3Nl ZWtfaW5jMQoJdmZzLnpmcy52ZGV2Lm1pcnJvci5ub25fcm90YXRpbmdfaW5jICAgIDAKCXZmcy56 ZnMudmRldi5taXJyb3Iucm90YXRpbmdfc2Vla19vZmZzZXQxMDQ4NTc2Cgl2ZnMuemZzLnZkZXYu bWlycm9yLnJvdGF0aW5nX3NlZWtfaW5jICAgNQoJdmZzLnpmcy52ZGV2Lm1pcnJvci5yb3RhdGlu Z19pbmMgICAgICAgIDAKCXZmcy56ZnMudmRldi50cmltX29uX2luaXQgICAgICAgICAgICAgICAx Cgl2ZnMuemZzLnZkZXYuY2FjaGUuYnNoaWZ0ICAgICAgICAgICAgICAgMTYKCXZmcy56ZnMudmRl di5jYWNoZS5zaXplICAgICAgICAgICAgICAgICAwCgl2ZnMuemZzLnZkZXYuY2FjaGUubWF4ICAg ICAgICAgICAgICAgICAgMTYzODQKCXZmcy56ZnMudmRldi52YWxpZGF0ZV9za2lwICAgICAgICAg ICAgICAwCgl2ZnMuemZzLnZkZXYubWF4X21zX3NoaWZ0ICAgICAgICAgICAgICAgMzQKCXZmcy56 ZnMudmRldi5kZWZhdWx0X21zX3NoaWZ0ICAgICAgICAgICAyOQoJdmZzLnpmcy52ZGV2Lm1heF9t c19jb3VudF9saW1pdCAgICAgICAgIDEzMTA3MgoJdmZzLnpmcy52ZGV2Lm1pbl9tc19jb3VudCAg ICAgICAgICAgICAgIDE2Cgl2ZnMuemZzLnZkZXYuZGVmYXVsdF9tc19jb3VudCAgICAgICAgICAg MjAwCgl2ZnMuemZzLnR4Zy50aW1lb3V0ICAgICAgICAgICAgICAgICAgICAgNQoJdmZzLnpmcy5z cGFjZV9tYXBfaWJzICAgICAgICAgICAgICAgICAgIDE0Cgl2ZnMuemZzLnNwZWNpYWxfY2xhc3Nf bWV0YWRhdGFfcmVzZXJ2ZV9wY3QyNQoJdmZzLnpmcy51c2VyX2luZGlyZWN0X2lzX3NwZWNpYWwg ICAgICAgIDEKCXZmcy56ZnMuZGR0X2RhdGFfaXNfc3BlY2lhbCAgICAgICAgICAgICAxCgl2ZnMu emZzLnNwYV9hbGxvY2F0b3JzICAgICAgICAgICAgICAgICAgNAoJdmZzLnpmcy5zcGFfbWluX3Ns b3AgICAgICAgICAgICAgICAgICAgIDEzNDIxNzcyOAoJdmZzLnpmcy5zcGFfc2xvcF9zaGlmdCAg ICAgICAgICAgICAgICAgIDUKCXZmcy56ZnMuc3BhX2FzaXplX2luZmxhdGlvbiAgICAgICAgICAg ICAyNAoJdmZzLnpmcy5kZWFkbWFuX2VuYWJsZWQgICAgICAgICAgICAgICAgIDEKCXZmcy56ZnMu ZGVhZG1hbl9jaGVja3RpbWVfbXMgICAgICAgICAgICA1MDAwCgl2ZnMuemZzLmRlYWRtYW5fc3lu Y3RpbWVfbXMgICAgICAgICAgICAgMTAwMDAwMAoJdmZzLnpmcy5kZWJ1Z2ZsYWdzICAgICAgICAg ICAgICAgICAgICAgIDAKCXZmcy56ZnMucmVjb3ZlciAgICAgICAgICAgICAgICAgICAgICAgICAw Cgl2ZnMuemZzLnNwYV9sb2FkX3ZlcmlmeV9kYXRhICAgICAgICAgICAgMQoJdmZzLnpmcy5zcGFf bG9hZF92ZXJpZnlfbWV0YWRhdGEgICAgICAgIDEKCXZmcy56ZnMuc3BhX2xvYWRfdmVyaWZ5X21h eGluZmxpZ2h0ICAgICAxMDAwMAoJdmZzLnpmcy5tYXhfbWlzc2luZ190dmRzX3NjYW4gICAgICAg ICAgIDAKCXZmcy56ZnMubWF4X21pc3NpbmdfdHZkc19jYWNoZWZpbGUgICAgICAyCgl2ZnMuemZz Lm1heF9taXNzaW5nX3R2ZHMgICAgICAgICAgICAgICAgMAoJdmZzLnpmcy5zcGFfbG9hZF9wcmlu dF92ZGV2X3RyZWUgICAgICAgIDAKCXZmcy56ZnMuY2N3X3JldHJ5X2ludGVydmFsICAgICAgICAg ICAgICAzMDAKCXZmcy56ZnMuY2hlY2tfaG9zdGlkICAgICAgICAgICAgICAgICAgICAxCgl2ZnMu emZzLm11bHRpaG9zdF9mYWlsX2ludGVydmFscyAgICAgICAgMTAKCXZmcy56ZnMubXVsdGlob3N0 X2ltcG9ydF9pbnRlcnZhbHMgICAgICAyMAoJdmZzLnpmcy5tdWx0aWhvc3RfaW50ZXJ2YWwgICAg ICAgICAgICAgIDEwMDAKCXZmcy56ZnMubWdfZnJhZ21lbnRhdGlvbl90aHJlc2hvbGQgICAgICA4 NQoJdmZzLnpmcy5tZ19ub2FsbG9jX3RocmVzaG9sZCAgICAgICAgICAgIDAKCXZmcy56ZnMuY29u ZGVuc2VfcGN0ICAgICAgICAgICAgICAgICAgICAyMDAKCXZmcy56ZnMubWV0YXNsYWJfc21fYmxr c3ogICAgICAgICAgICAgICA0MDk2Cgl2ZnMuemZzLm1ldGFzbGFiLmJpYXNfZW5hYmxlZCAgICAg ICAgICAgMQoJdmZzLnpmcy5tZXRhc2xhYi5sYmFfd2VpZ2h0aW5nX2VuYWJsZWQgIDEKCXZmcy56 ZnMubWV0YXNsYWIuZnJhZ21lbnRhdGlvbl9mYWN0b3JfZW5hYmxlZDEKCXZmcy56ZnMubWV0YXNs YWIucHJlbG9hZF9lbmFibGVkICAgICAgICAxCgl2ZnMuemZzLm1ldGFzbGFiLnByZWxvYWRfbGlt aXQgICAgICAgICAgMwoJdmZzLnpmcy5tZXRhc2xhYi51bmxvYWRfZGVsYXkgICAgICAgICAgIDgK CXZmcy56ZnMubWV0YXNsYWIubG9hZF9wY3QgICAgICAgICAgICAgICA1MAoJdmZzLnpmcy5tZXRh c2xhYi5taW5fYWxsb2Nfc2l6ZSAgICAgICAgIDMzNTU0NDMyCgl2ZnMuemZzLm1ldGFzbGFiLmRm X2ZyZWVfcGN0ICAgICAgICAgICAgNAoJdmZzLnpmcy5tZXRhc2xhYi5kZl9hbGxvY190aHJlc2hv bGQgICAgIDEzMTA3MgoJdmZzLnpmcy5tZXRhc2xhYi5kZWJ1Z191bmxvYWQgICAgICAgICAgIDAK CXZmcy56ZnMubWV0YXNsYWIuZGVidWdfbG9hZCAgICAgICAgICAgICAwCgl2ZnMuemZzLm1ldGFz bGFiLmZyYWdtZW50YXRpb25fdGhyZXNob2xkNzAKCXZmcy56ZnMubWV0YXNsYWIuZm9yY2VfZ2Fu Z2luZyAgICAgICAgICAxNjc3NzIxNwoJdmZzLnpmcy5mcmVlX2Jwb2JqX2VuYWJsZWQgICAgICAg ICAgICAgIDEKCXZmcy56ZnMuZnJlZV9tYXhfYmxvY2tzICAgICAgICAgICAgICAgICAtMQoJdmZz Lnpmcy56ZnNfc2Nhbl9jaGVja3BvaW50X2ludGVydmFsICAgIDcyMDAKCXZmcy56ZnMuemZzX3Nj YW5fbGVnYWN5ICAgICAgICAgICAgICAgICAwCgl2ZnMuemZzLm5vX3NjcnViX3ByZWZldGNoICAg ICAgICAgICAgICAgMAoJdmZzLnpmcy5ub19zY3J1Yl9pbyAgICAgICAgICAgICAgICAgICAgIDAK CXZmcy56ZnMucmVzaWx2ZXJfbWluX3RpbWVfbXMgICAgICAgICAgICAzMDAwCgl2ZnMuemZzLmZy ZWVfbWluX3RpbWVfbXMgICAgICAgICAgICAgICAgMTAwMAoJdmZzLnpmcy5zY2FuX21pbl90aW1l X21zICAgICAgICAgICAgICAgIDEwMDAKCXZmcy56ZnMuc2Nhbl9pZGxlICAgICAgICAgICAgICAg ICAgICAgICA1MAoJdmZzLnpmcy5zY3J1Yl9kZWxheSAgICAgICAgICAgICAgICAgICAgIDQKCXZm cy56ZnMucmVzaWx2ZXJfZGVsYXkgICAgICAgICAgICAgICAgICAyCgl2ZnMuemZzLnpmZXRjaC5h cnJheV9yZF9zeiAgICAgICAgICAgICAgMTA0ODU3NgoJdmZzLnpmcy56ZmV0Y2gubWF4X2lkaXN0 YW5jZSAgICAgICAgICAgIDY3MTA4ODY0Cgl2ZnMuemZzLnpmZXRjaC5tYXhfZGlzdGFuY2UgICAg ICAgICAgICAgODM4ODYwOAoJdmZzLnpmcy56ZmV0Y2gubWluX3NlY19yZWFwICAgICAgICAgICAg IDIKCXZmcy56ZnMuemZldGNoLm1heF9zdHJlYW1zICAgICAgICAgICAgICA4Cgl2ZnMuemZzLnBy ZWZldGNoX2Rpc2FibGUgICAgICAgICAgICAgICAgMAoJdmZzLnpmcy5kZWxheV9zY2FsZSAgICAg ICAgICAgICAgICAgICAgIDUwMDAwMAoJdmZzLnpmcy5kZWxheV9taW5fZGlydHlfcGVyY2VudCAg ICAgICAgIDYwCgl2ZnMuemZzLmRpcnR5X2RhdGFfc3luY19wY3QgICAgICAgICAgICAgMjAKCXZm cy56ZnMuZGlydHlfZGF0YV9tYXhfcGVyY2VudCAgICAgICAgICAxMAoJdmZzLnpmcy5kaXJ0eV9k YXRhX21heF9tYXggICAgICAgICAgICAgIDQyOTQ5NjcyOTYKCXZmcy56ZnMuZGlydHlfZGF0YV9t YXggICAgICAgICAgICAgICAgICA0Mjk0OTY3Mjk2Cgl2ZnMuemZzLm1heF9yZWNvcmRzaXplICAg ICAgICAgICAgICAgICAgMTA0ODU3NgoJdmZzLnpmcy5kZWZhdWx0X2licyAgICAgICAgICAgICAg ICAgICAgIDE3Cgl2ZnMuemZzLmRlZmF1bHRfYnMgICAgICAgICAgICAgICAgICAgICAgOQoJdmZz Lnpmcy5zZW5kX2hvbGVzX3dpdGhvdXRfYmlydGhfdGltZSAgIDEKCXZmcy56ZnMubWRjb21wX2Rp c2FibGUgICAgICAgICAgICAgICAgICAwCgl2ZnMuemZzLnBlcl90eGdfZGlydHlfZnJlZXNfcGVy Y2VudCAgICAgNQoJdmZzLnpmcy5ub3B3cml0ZV9lbmFibGVkICAgICAgICAgICAgICAgIDEKCXZm cy56ZnMuZGVkdXAucHJlZmV0Y2ggICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLmRidWZfY2Fj aGVfbG93YXRlcl9wY3QgICAgICAgICAgMTAKCXZmcy56ZnMuZGJ1Zl9jYWNoZV9oaXdhdGVyX3Bj dCAgICAgICAgICAxMAoJdmZzLnpmcy5kYnVmX21ldGFkYXRhX2NhY2hlX292ZXJmbG93ICAgIDAK CXZmcy56ZnMuZGJ1Zl9tZXRhZGF0YV9jYWNoZV9zaGlmdCAgICAgICA2Cgl2ZnMuemZzLmRidWZf Y2FjaGVfc2hpZnQgICAgICAgICAgICAgICAgNQoJdmZzLnpmcy5kYnVmX21ldGFkYXRhX2NhY2hl X21heF9ieXRlcyAgIDEwNzM3NDE4MjQKCXZmcy56ZnMuZGJ1Zl9jYWNoZV9tYXhfYnl0ZXMgICAg ICAgICAgICAyMTQ3NDgzNjQ4Cgl2ZnMuemZzLmFyY19taW5fcHJlc2NpZW50X3ByZWZldGNoX21z ICAgNgoJdmZzLnpmcy5hcmNfbWluX3ByZWZldGNoX21zICAgICAgICAgICAgIDEKCXZmcy56ZnMu bDJjX29ubHlfc2l6ZSAgICAgICAgICAgICAgICAgICAwCgl2ZnMuemZzLm1mdV9naG9zdF9kYXRh X2VzaXplICAgICAgICAgICAgMTQ2NjE1MzQ3MgoJdmZzLnpmcy5tZnVfZ2hvc3RfbWV0YWRhdGFf ZXNpemUgICAgICAgIDcwNzIzODA0MTYKCXZmcy56ZnMubWZ1X2dob3N0X3NpemUgICAgICAgICAg ICAgICAgICA4NTM4NTMzODg4Cgl2ZnMuemZzLm1mdV9kYXRhX2VzaXplICAgICAgICAgICAgICAg ICAgMAoJdmZzLnpmcy5tZnVfbWV0YWRhdGFfZXNpemUgICAgICAgICAgICAgIDAKCXZmcy56ZnMu bWZ1X3NpemUgICAgICAgICAgICAgICAgICAgICAgICA5ODMxMjcwNDAKCXZmcy56ZnMubXJ1X2do b3N0X2RhdGFfZXNpemUgICAgICAgICAgICAwCgl2ZnMuemZzLm1ydV9naG9zdF9tZXRhZGF0YV9l c2l6ZSAgICAgICAgMAoJdmZzLnpmcy5tcnVfZ2hvc3Rfc2l6ZSAgICAgICAgICAgICAgICAgIDAK CXZmcy56ZnMubXJ1X2RhdGFfZXNpemUgICAgICAgICAgICAgICAgICAwCgl2ZnMuemZzLm1ydV9t ZXRhZGF0YV9lc2l6ZSAgICAgICAgICAgICAgMAoJdmZzLnpmcy5tcnVfc2l6ZSAgICAgICAgICAg ICAgICAgICAgICAgIDEyOTAzMzUxMjk2Cgl2ZnMuemZzLmFub25fZGF0YV9lc2l6ZSAgICAgICAg ICAgICAgICAgMAoJdmZzLnpmcy5hbm9uX21ldGFkYXRhX2VzaXplICAgICAgICAgICAgIDAKCXZm cy56ZnMuYW5vbl9zaXplICAgICAgICAgICAgICAgICAgICAgICAxMjUxMjI1NjAKCXZmcy56ZnMu bDJhcmNfbm9ydyAgICAgICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLmwyYXJjX2ZlZWRfYWdh aW4gICAgICAgICAgICAgICAgMQoJdmZzLnpmcy5sMmFyY19ub3ByZWZldGNoICAgICAgICAgICAg ICAgIDEKCXZmcy56ZnMubDJhcmNfZmVlZF9taW5fbXMgICAgICAgICAgICAgICAyMDAKCXZmcy56 ZnMubDJhcmNfZmVlZF9zZWNzICAgICAgICAgICAgICAgICAxCgl2ZnMuemZzLmwyYXJjX2hlYWRy b29tICAgICAgICAgICAgICAgICAgMgoJdmZzLnpmcy5sMmFyY193cml0ZV9ib29zdCAgICAgICAg ICAgICAgIDgzODg2MDgKCXZmcy56ZnMubDJhcmNfd3JpdGVfbWF4ICAgICAgICAgICAgICAgICA4 Mzg4NjA4Cgl2ZnMuemZzLmFyY19tZXRhX3N0cmF0ZWd5ICAgICAgICAgICAgICAgMAoJdmZzLnpm cy5hcmNfbWV0YV9saW1pdCAgICAgICAgICAgICAgICAgIDE3MTc5ODY5MTg0Cgl2ZnMuemZzLmFy Y19mcmVlX3RhcmdldCAgICAgICAgICAgICAgICAgNjk0NzI0Cgl2ZnMuemZzLmFyY19rbWVtX2Nh Y2hlX3JlYXBfcmV0cnlfbXMgICAgMTAwMAoJdmZzLnpmcy5jb21wcmVzc2VkX2FyY19lbmFibGVk ICAgICAgICAgIDEKCXZmcy56ZnMuYXJjX2dyb3dfcmV0cnkgICAgICAgICAgICAgICAgICA2MAoJ dmZzLnpmcy5hcmNfc2hyaW5rX3NoaWZ0ICAgICAgICAgICAgICAgIDcKCXZmcy56ZnMuYXJjX2F2 ZXJhZ2VfYmxvY2tzaXplICAgICAgICAgICA4MTkyCgl2ZnMuemZzLmFyY19ub19ncm93X3NoaWZ0 ICAgICAgICAgICAgICAgNQoJdmZzLnpmcy5hcmNfbWluICAgICAgICAgICAgICAgICAgICAgICAg IDg1ODk5MzQ1OTIKCXZmcy56ZnMuYXJjX21heCAgICAgICAgICAgICAgICAgICAgICAgICA2ODcx OTQ3NjczNgoJdmZzLnpmcy5hYmRfY2h1bmtfc2l6ZSAgICAgICAgICAgICAgICAgIDQwOTYKCXZm cy56ZnMuYWJkX3NjYXR0ZXJfZW5hYmxlZCAgICAgICAgICAgICAxCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K --=_94ea2695193cf369660b9253165fcef5-- From nobody Wed Apr 6 11:28:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 25EB11A81972 for ; Wed, 6 Apr 2022 11:28:11 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYMhB21bXz4gJg for ; Wed, 6 Apr 2022 11:28:10 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 8AE4F60C6DC for ; Wed, 6 Apr 2022 13:28:08 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fffcb86f423d1cf347c249b0853ca3ae" Date: Wed, 06 Apr 2022 13:28:08 +0200 From: egoitz@ramattack.net To: Freebsd hackers Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYMhB21bXz4gJg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_fffcb86f423d1cf347c249b0853ca3ae Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The most extrange thing is... When machine boots ARC is in 40 value of GB used (for instance), but later decreases to 20GB (and this is not an example... is exact) in all my servers.... it's like if the ARC metadata which is more or less 17GB would limite the whole ARC..... With the traffic of this machines, it should I suppose the ARC should be larger than it is... and ARC in loader.conf is limited to 64GB (the half the ram this machines have) El 2022-04-06 13:18, egoitz@ramattack.net escribiĂł: > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Good morning, > > I write this post with the expectation that perhaps someone could help me > > I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. > > The problem I'm facing is that they could be running just fine and suddenly at some peak hour, the IO goes to 60 or 70% and the machine becomes extremely slow. ZFS is all by default, except the sync parameter which is set disabled. Apart from that the ARC is limited to 64GB. But even this is extremely odd. The used ARC is near 20GB. I have seen, that meta cache in arc is very near to the limit that FreeBSD automatically sets depending on the size of the ARC you set. It seems that almost all ARC is used by meta cache. I have seen this effect in all my mail servers with this hardware and software config. > > I do attach a zfs-stats output, but from now that the servers are not so loaded as described. I do explain. I run a couple of Cyrus instances in these servers. One as master, one as slave on each server. The commented situation from above, happens when both Cyrus instances become master, so when we are using two Cyrus instances giving service in the same machine. For avoiding issues, know we have balanced and we have a master and a slave in each server. You know, a slave instance has almost no io and only a single connection for replication. So the zfs-stats output is from now we have let's say half of load in each server, because they have one master and one slave instance. > > As said before, when I place two masters in same server, perhaps all day works, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increase) but it seems like if the IO where not being able to be served, let's say more than a limit. More than a concrete io limit (I'd say 60%). > > I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later... I have get a nice performance when copying for instance mailboxes from five to five.... I can flood a gigabit interface when copying mailboxes between servers from five to five.... they seem to perform.... > > Could anyone please shed us some light in this issue?. I don't really know what to think. > > Best regards, > > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. --=_fffcb86f423d1cf347c249b0853ca3ae Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

The most extrange thing is... When machine boots ARC is = in 40 value of GB used (for instance), but later decreases to 20GB (and thi= s is not an example... is exact) in all my servers.... it's like if the ARC= metadata which is more or less 17GB would limite the whole ARC.....

 

With the traffic of this machines, it should I suppose t= he ARC should be larger than it is... and ARC in loader.conf is limited to = 64GB (the half the ram this machines have)

 


El 2022-04-06 13:18, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Good morning,

I write this post with = the expectation that perhaps someone could help me 3D":)"

I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (n= ot EVO or other Samsung SSD disks) disks as storage. They can easily have f= rom 1500 to 2000 concurrent connections. The machines have 128GB of ram and= the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% pe= rcent at most.

The problem I'm facing is that they could be ru= nning just fine and suddenly at some peak hour, the IO goes to 60 or 70% an= d the machine becomes extremely slow. ZFS is all by default, except the syn= c parameter which is set disabled. Apart from that the ARC is limited to 64= GB. But even this is extremely odd. The used ARC is near 20GB. I have seen,= that meta cache in arc is very near to the limit that FreeBSD automaticall= y sets depending on the size of the ARC you set. It seems that almost all A= RC is used by meta cache. I have seen this effect in all my mail servers wi= th this hardware and software config.

I do attach a zfs-stats = output, but from now that the servers are not so loaded as described. I do = explain. I run a couple of Cyrus instances in these servers. One as master,= one as slave on each server. The commented situation from above, happens w= hen both Cyrus instances become master, so when we are using two Cyrus inst= ances giving service in the same machine. For avoiding issues, know we have= balanced and we have a master and a slave in each server. You know, a slav= e instance has almost no io and only a single connection for replication. S= o the zfs-stats output is from now we have let's say half of load in each s= erver, because they have one master and one slave instance.

As= said before, when I place two masters in same server, perhaps all day work= s, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increa= se) but it seems like if the IO where not being able to be served, let's sa= y more than a limit. More than a concrete io limit (I'd say 60%).
I don't really know if, perhaps the QVO technology could be the guilty = here.... because... they say are desktop computers disks... but later... I = have get a nice performance when copying for instance mailboxes from five t= o five.... I can flood a gigabit interface when copying mailboxes between s= ervers from five to five.... they seem to perform....

Could an= yone please shed us some light in this issue?. I don't really know what to = think.

Best regards,
 




ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.
--=_fffcb86f423d1cf347c249b0853ca3ae-- From nobody Wed Apr 6 11:28:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 966A01A81E70; Wed, 6 Apr 2022 11:28:48 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYMhv4tm0z4gLP; Wed, 6 Apr 2022 11:28:47 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id D560C60C055; Wed, 6 Apr 2022 13:28:45 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2094f57367545a643dbb74ca4f8ba24d" Date: Wed, 06 Apr 2022 13:28:45 +0200 From: egoitz@ramattack.net To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYMhv4tm0z4gLP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain,multipart/related]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_2094f57367545a643dbb74ca4f8ba24d Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The most extrange thing is... When machine boots ARC is in 40 value of GB used (for instance), but later decreases to 20GB (and this is not an example... is exact) in all my servers.... it's like if the ARC metadata which is more or less 17GB would limite the whole ARC..... With the traffic of this machines, it should I suppose the ARC should be larger than it is... and ARC in loader.conf is limited to 64GB (the half the ram this machines have) El 2022-04-06 13:15, egoitz@ramattack.net escribiĂł: > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Good morning, > > I write this post with the expectation that perhaps someone could help me > > I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. > > The problem I'm facing is that they could be running just fine and suddenly at some peak hour, the IO goes to 60 or 70% and the machine becomes extremely slow. ZFS is all by default, except the sync parameter which is set disabled. Apart from that the ARC is limited to 64GB. But even this is extremely odd. The used ARC is near 20GB. I have seen, that meta cache in arc is very near to the limit that FreeBSD automatically sets depending on the size of the ARC you set. It seems that almost all ARC is used by meta cache. I have seen this effect in all my mail servers with this hardware and software config. > > I do attach a zfs-stats output, but from now that the servers are not so loaded as described. I do explain. I run a couple of Cyrus instances in these servers. One as master, one as slave on each server. The commented situation from above, happens when both Cyrus instances become master, so when we are using two Cyrus instances giving service in the same machine. For avoiding issues, know we have balanced and we have a master and a slave in each server. You know, a slave instance has almost no io and only a single connection for replication. So the zfs-stats output is from now we have let's say half of load in each server, because they have one master and one slave instance. > > As said before, when I place two masters in same server, perhaps all day works, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increase) but it seems like if the IO where not being able to be served, let's say more than a limit. More than a concrete io limit (I'd say 60%). > > I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later... I have get a nice performance when copying for instance mailboxes from five to five.... I can flood a gigabit interface when copying mailboxes between servers from five to five.... they seem to perform.... > > Could anyone please shed us some light in this issue?. I don't really know what to think. > > Best regards, > > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. --=_2094f57367545a643dbb74ca4f8ba24d Content-Type: multipart/related; boundary="=_6e3b5663f91f7c881feb9dbfb751600c" --=_6e3b5663f91f7c881feb9dbfb751600c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

The most extrange thing is... When machine boots ARC is = in 40 value of GB used (for instance), but later decreases to 20GB (and thi= s is not an example... is exact) in all my servers.... it's like if the ARC= metadata which is more or less 17GB would limite the whole ARC.....

 

With the traffic of this machines, it should I suppose t= he ARC should be larger than it is... and ARC in loader.conf is limited to = 64GB (the half the ram this machines have)

 


El 2022-04-06 13:15, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Good morning,

I write this post with = the expectation that perhaps someone could help me 3D":)"

I am running = some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other = Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000= concurrent connections. The machines have 128GB of ram and the CPU is almo= st absolutely idle. The disk IO is normally at 30 or 40% percent at most.
The problem I'm facing is that they could be running just fine = and suddenly at some peak hour, the IO goes to 60 or 70% and the machine be= comes extremely slow. ZFS is all by default, except the sync parameter whic= h is set disabled. Apart from that the ARC is limited to 64GB. But even thi= s is extremely odd. The used ARC is near 20GB. I have seen, that meta cache= in arc is very near to the limit that FreeBSD automatically sets depending= on the size of the ARC you set. It seems that almost all ARC is used by me= ta cache. I have seen this effect in all my mail servers with this hardware= and software config.

I do attach a zfs-stats output, but from= now that the servers are not so loaded as described. I do explain. I run a= couple of Cyrus instances in these servers. One as master, one as slave on= each server. The commented situation from above, happens when both Cyrus i= nstances become master, so when we are using two Cyrus instances giving ser= vice in the same machine. For avoiding issues, know we have balanced and we= have a master and a slave in each server. You know, a slave instance has a= lmost no io and only a single connection for replication. So the zfs-stats = output is from now we have let's say half of load in each server, because t= hey have one master and one slave instance.

As said before, wh= en I place two masters in same server, perhaps all day works, but just at 1= 1:00 am (for example) the IO goes to 60% (it doesn't increase) but it seems= like if the IO where not being able to be served, let's say more than a li= mit. More than a concrete io limit (I'd say 60%).

I don't real= ly know if, perhaps the QVO technology could be the guilty here.... because= =2E.. they say are desktop computers disks... but later... I have get a nic= e performance when copying for instance mailboxes from five to five.... I c= an flood a gigabit interface when copying mailboxes between servers from fi= ve to five.... they seem to perform....

Could anyone please sh= ed us some light in this issue?. I don't really know what to think.
<= br /> Best regards,
 




ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.
--=_6e3b5663f91f7c881feb9dbfb751600c Content-Transfer-Encoding: base64 Content-ID: <1649244525624d796dc0952013070694@ramattack.net> Content-Type: image/gif; name=d8974688.gif Content-Disposition: inline; filename=d8974688.gif; size=42 R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7 --=_6e3b5663f91f7c881feb9dbfb751600c-- --=_2094f57367545a643dbb74ca4f8ba24d-- From nobody Wed Apr 6 11:26:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F02D31A84645 for ; Wed, 6 Apr 2022 11:32:11 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYMmn2hFXz4kFZ for ; Wed, 6 Apr 2022 11:32:08 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 2EDBE60C575; Wed, 6 Apr 2022 13:26:24 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_7b94aa3284999df1ebddce202b1f53e2" Date: Wed, 06 Apr 2022 13:26:24 +0200 From: egoitz@ramattack.net To: Freebsd hackers Cc: owner-freebsd-hackers@freebsd.org Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYMmn2hFXz4kFZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_7b94aa3284999df1ebddce202b1f53e2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The most extrange thing is... When machine boots ARC is in 40 value of GB used (for instance), but later decreases to 20GB (and this is not an example... is exact) in all my servers.... it's like if the ARC metadata which is more or less 17GB would limite the whole ARC..... With the traffic of this machines, it should I suppose the ARC should be larger than it is... and ARC in loader.conf is limited to 64GB (the half the ram this machines have) El 2022-04-06 13:18, egoitz@ramattack.net escribiĂł: > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Good morning, > > I write this post with the expectation that perhaps someone could help me > > I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. > > The problem I'm facing is that they could be running just fine and suddenly at some peak hour, the IO goes to 60 or 70% and the machine becomes extremely slow. ZFS is all by default, except the sync parameter which is set disabled. Apart from that the ARC is limited to 64GB. But even this is extremely odd. The used ARC is near 20GB. I have seen, that meta cache in arc is very near to the limit that FreeBSD automatically sets depending on the size of the ARC you set. It seems that almost all ARC is used by meta cache. I have seen this effect in all my mail servers with this hardware and software config. > > I do attach a zfs-stats output, but from now that the servers are not so loaded as described. I do explain. I run a couple of Cyrus instances in these servers. One as master, one as slave on each server. The commented situation from above, happens when both Cyrus instances become master, so when we are using two Cyrus instances giving service in the same machine. For avoiding issues, know we have balanced and we have a master and a slave in each server. You know, a slave instance has almost no io and only a single connection for replication. So the zfs-stats output is from now we have let's say half of load in each server, because they have one master and one slave instance. > > As said before, when I place two masters in same server, perhaps all day works, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increase) but it seems like if the IO where not being able to be served, let's say more than a limit. More than a concrete io limit (I'd say 60%). > > I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later... I have get a nice performance when copying for instance mailboxes from five to five.... I can flood a gigabit interface when copying mailboxes between servers from five to five.... they seem to perform.... > > Could anyone please shed us some light in this issue?. I don't really know what to think. > > Best regards, > > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. --=_7b94aa3284999df1ebddce202b1f53e2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

The most extrange thing is... When machine boots ARC is = in 40 value of GB used (for instance), but later decreases to 20GB (and thi= s is not an example... is exact) in all my servers.... it's like if the ARC= metadata which is more or less 17GB would limite the whole ARC.....

 

With the traffic of this machines, it should I suppose t= he ARC should be larger than it is... and ARC in loader.conf is limited to = 64GB (the half the ram this machines have)

 


El 2022-04-06 13:18, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Good morning,

I write this post with = the expectation that perhaps someone could help me 3D":)"

I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (n= ot EVO or other Samsung SSD disks) disks as storage. They can easily have f= rom 1500 to 2000 concurrent connections. The machines have 128GB of ram and= the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% pe= rcent at most.

The problem I'm facing is that they could be ru= nning just fine and suddenly at some peak hour, the IO goes to 60 or 70% an= d the machine becomes extremely slow. ZFS is all by default, except the syn= c parameter which is set disabled. Apart from that the ARC is limited to 64= GB. But even this is extremely odd. The used ARC is near 20GB. I have seen,= that meta cache in arc is very near to the limit that FreeBSD automaticall= y sets depending on the size of the ARC you set. It seems that almost all A= RC is used by meta cache. I have seen this effect in all my mail servers wi= th this hardware and software config.

I do attach a zfs-stats = output, but from now that the servers are not so loaded as described. I do = explain. I run a couple of Cyrus instances in these servers. One as master,= one as slave on each server. The commented situation from above, happens w= hen both Cyrus instances become master, so when we are using two Cyrus inst= ances giving service in the same machine. For avoiding issues, know we have= balanced and we have a master and a slave in each server. You know, a slav= e instance has almost no io and only a single connection for replication. S= o the zfs-stats output is from now we have let's say half of load in each s= erver, because they have one master and one slave instance.

As= said before, when I place two masters in same server, perhaps all day work= s, but just at 11:00 am (for example) the IO goes to 60% (it doesn't increa= se) but it seems like if the IO where not being able to be served, let's sa= y more than a limit. More than a concrete io limit (I'd say 60%).
I don't really know if, perhaps the QVO technology could be the guilty = here.... because... they say are desktop computers disks... but later... I = have get a nice performance when copying for instance mailboxes from five t= o five.... I can flood a gigabit interface when copying mailboxes between s= ervers from five to five.... they seem to perform....

Could an= yone please shed us some light in this issue?. I don't really know what to = think.

Best regards,
 




ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.
--=_7b94aa3284999df1ebddce202b1f53e2-- From eugen@grosbein.net Wed Apr 6 11:42:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F0C211A888B5 for ; Wed, 6 Apr 2022 11:43:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYN1r0Mpmz4npf for ; Wed, 6 Apr 2022 11:43:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 236BhJWq054666 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 11:43:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: egoitz@ramattack.net Received: from [10.58.0.11] (dadv@dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 236Bgrmu090755 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 6 Apr 2022 18:43:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Desperate with 870 QVO and ZFS To: egoitz@ramattack.net, Freebsd hackers References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> From: Eugene Grosbein Message-ID: <15a86fae-90fd-951d-50e0-48f9be8b4bbc@grosbein.net> Date: Wed, 6 Apr 2022 18:42:53 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KYN1r0Mpmz4npf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.13 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.790]; NEURAL_HAM_LONG(-0.33)[-0.331]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.09)[0.089]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.04.2022 18:18, egoitz@ramattack.net wrote: > Good morning, > > I write this post with the expectation that perhaps someone could help me :) > > I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. > > The problem I'm facing is that they could be running just fine and suddenly at some peak hour, > the IO goes to 60 or 70% and the machine becomes extremely slow. You should run: gstat -adpI3s And monitor all values, especially "deletes": d/s, next KBps and ms/d. If you have many delete operations (including ZFS snapshort destroying), it may result in massive chunks of TRIM operations sent to SSD. Some SSD products have abysmal TRIM performance. From nobody Wed Apr 6 12:02:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 87CCB1A8D768 for ; Wed, 6 Apr 2022 12:03:02 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYNSP3NyQz4t4x for ; Wed, 6 Apr 2022 12:03:00 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id A003760C658; Wed, 6 Apr 2022 14:02:57 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_e9fc600bd2777d5700eb4010e802ed4d" Date: Wed, 06 Apr 2022 14:02:57 +0200 From: egoitz@ramattack.net To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: <15a86fae-90fd-951d-50e0-48f9be8b4bbc@grosbein.net> References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> <15a86fae-90fd-951d-50e0-48f9be8b4bbc@grosbein.net> Message-ID: <109127fb4e43e70cd548fecde2c1f755@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYNSP3NyQz4t4x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_e9fc600bd2777d5700eb4010e802ed4d Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Eugene, No... I normally don't have many delete operations..... in fact the bast majority of them are left for the night... they are done at 2,3,4 am in the morning.... We may have 600 deletes/sec at busy times (acording to what I see in gstat and calculating when having two masters).... I don't think is a trim issue, because where removing snapshots in same disks as these ones, but in another different machines (of another service) and there are no issues... they hold virtual machines... it's not mail.... but I assume something should be seen too if trims where the issue... I honestly think, it could have something to do with concurrency.... the disks have issues when you have perhaps 2200 users for instance and in peak hours only!.... but how a disk... could be suffering of concurrency?. The controller should only be able to do an operation at the own same time... so there's not exist paralelism there... I can't really understand what happens.... Regards, El 2022-04-06 13:42, Eugene Grosbein escribiĂł: > 06.04.2022 18:18, egoitz@ramattack.net wrote: > >> Good morning, >> >> I write this post with the expectation that perhaps someone could help me :) >> >> I am running some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other Samsung SSD disks) disks as storage. They can easily have from 1500 to 2000 concurrent connections. The machines have 128GB of ram and the CPU is almost absolutely idle. The disk IO is normally at 30 or 40% percent at most. >> >> The problem I'm facing is that they could be running just fine and suddenly at some peak hour, >> the IO goes to 60 or 70% and the machine becomes extremely slow. > > You should run: gstat -adpI3s > And monitor all values, especially "deletes": d/s, next KBps and ms/d. > > If you have many delete operations (including ZFS snapshort destroying), > it may result in massive chunks of TRIM operations sent to SSD. > Some SSD products have abysmal TRIM performance. --=_e9fc600bd2777d5700eb4010e802ed4d Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Eugene,


No... I normally don't have many delete operations..... in fact the bast= majority of them are left for the night... they are done at 2,3,4 am in th= e morning....

We may have 600 deletes/sec at busy times (acording to what I see in gst= at and calculating when having two masters)....

I don't think is a trim issue, because where removing snapshots in same = disks as these ones, but in another different machines (of another service)= and there are no issues... they hold virtual machines... it's not mail..= =2E. but I assume something should be seen too if trims where the issue..= =2E

I honestly think, it could have something to do with concurrency.... the= disks have issues when you have perhaps 2200 users for instance and in pea= k hours only!.... but how a disk... could be suffering of concurrency?. The= controller should only be able to do an operation at the own same time..= =2E so there's not exist paralelism there... I can't really understand what= happens....

Regards,


 


El 2022-04-06 13:42, Eugene Grosbein escribió:

=
06.04.2022 18:18, egoitz@ram= attack.net wrote:

Good morning,

I write this post with the = expectation that perhaps someone could help me :)

I am running= some mail servers with FreeBSD and ZFS. They use 870 QVO (not EVO or other= Samsung SSD disks) disks as storage. They can easily have from 1500 to 200= 0 concurrent connections. The machines have 128GB of ram and the CPU is alm= ost absolutely idle. The disk IO is normally at 30 or 40% percent at most= =2E

The problem I'm facing is that they could be running just = fine and suddenly at some peak hour,
the IO goes to 60 or 70% and the= machine becomes extremely slow.

You should run: gstat -adpI3s
And monitor all values, especial= ly "deletes": d/s, next KBps and ms/d.

If you have many delete= operations (including ZFS snapshort destroying),
it may result in ma= ssive chunks of TRIM operations sent to SSD.
Some SSD products have a= bysmal TRIM performance.


--=_e9fc600bd2777d5700eb4010e802ed4d-- From eugen@grosbein.net Wed Apr 6 12:23:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D8AB31A92DD0 for ; Wed, 6 Apr 2022 12:23:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYNwF07Z9z4wwr for ; Wed, 6 Apr 2022 12:23:40 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 236CNc0l055024 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 12:23:38 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: egoitz@ramattack.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 236CNCCs090960 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 6 Apr 2022 19:23:37 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Desperate with 870 QVO and ZFS To: egoitz@ramattack.net References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> <15a86fae-90fd-951d-50e0-48f9be8b4bbc@grosbein.net> <109127fb4e43e70cd548fecde2c1f755@ramattack.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <3b0451a3-01ec-9f30-4eb4-4cbcd91f78cf@grosbein.net> Date: Wed, 6 Apr 2022 19:23:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <109127fb4e43e70cd548fecde2c1f755@ramattack.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KYNwF07Z9z4wwr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.03 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.793]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.56)[-0.562]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.49)[0.489]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.04.2022 19:02, egoitz@ramattack.net wrote: > Hi Eugene, > > > No... I normally don't have many delete operations..... in fact the bast majority of them are left for the night... they are done at 2,3,4 am in the morning.... > > We may have 600 deletes/sec at busy times (acording to what I see in gstat and calculating when having two masters).... As I've said, you need to monitor ALL values, there no unimportant ones on that screen. Look also at ms/r, ms/w and ms/d - that is, milliseconds per read operation, per write and per delete. Do these times grow at peak time? From nobody Wed Apr 6 14:26:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C83E1A94002 for ; Wed, 6 Apr 2022 14:26:58 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYRfT2RXWz3P6Z for ; Wed, 6 Apr 2022 14:26:56 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id 6A9A660C6EB; Wed, 6 Apr 2022 16:26:53 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_03a51938caf864ccc70ca989be3d2b44" Date: Wed, 06 Apr 2022 16:26:53 +0200 From: egoitz@ramattack.net To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS In-Reply-To: <3b0451a3-01ec-9f30-4eb4-4cbcd91f78cf@grosbein.net> References: <6cf6c03c5a4aa8128575ec4e2f70b168@ramattack.net> <15a86fae-90fd-951d-50e0-48f9be8b4bbc@grosbein.net> <109127fb4e43e70cd548fecde2c1f755@ramattack.net> <3b0451a3-01ec-9f30-4eb4-4cbcd91f78cf@grosbein.net> Message-ID: <15ce19eff500edfead2b56ea38cace7b@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYRfT2RXWz3P6Z X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_03a51938caf864ccc70ca989be3d2b44 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Eugene, Thank you so much really! As those values seem to be related to basically the average service time in the disks and the average service times increases in crisis moments... I assume yes it does... I will obviously keep an eye on them... sure... Thanks again! Regards, El 2022-04-06 14:23, Eugene Grosbein escribiĂł: > 06.04.2022 19:02, egoitz@ramattack.net wrote: > >> Hi Eugene, >> >> No... I normally don't have many delete operations..... in fact the bast majority of them are left for the night... they are done at 2,3,4 am in the morning.... >> >> We may have 600 deletes/sec at busy times (acording to what I see in gstat and calculating when having two masters).... > > As I've said, you need to monitor ALL values, there no unimportant ones on that screen. > Look also at ms/r, ms/w and ms/d - that is, milliseconds per read operation, per write and per delete. > Do these times grow at peak time? --=_03a51938caf864ccc70ca989be3d2b44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Eugene,


Thank you so much really!


As those values seem to be related to basically the average service time= in the disks and the average service times increases in crisis moments..= =2E I assume yes it does...


I will obviously keep an eye on them... sure...


Thanks again!


Regards,


 


El 2022-04-06 14:23, Eugene Grosbein escribió:

=
06.04.2022 19:02, egoitz@ram= attack.net wrote:
Hi Eugene,


No... I normally don't = have many delete operations..... in fact the bast majority of them are left= for the night... they are done at 2,3,4 am in the morning....

= We may have 600 deletes/sec at busy times (acording to what I see in gstat= and calculating when having two masters)....

As I've said, you need to monitor ALL values, there no unimportant o= nes on that screen.
Look also at ms/r, ms/w and ms/d - that is, milli= seconds per read operation, per write and per delete.
Do these times = grow at peak time?

--=_03a51938caf864ccc70ca989be3d2b44-- From nobody Wed Apr 6 14:36:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2BB861A9766C; Wed, 6 Apr 2022 14:36:48 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYRsp5Qf7z3hrB; Wed, 6 Apr 2022 14:36:45 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id B81CB60C64B; Wed, 6 Apr 2022 16:36:42 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_99711a23deca8e31b3fd04d620ec3dd4" Date: Wed, 06 Apr 2022 16:36:42 +0200 From: egoitz@ramattack.net To: Rainer Duffner Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> Message-ID: <0ef282aee34b441f1991334e2edbcaec@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYRsp5Qf7z3hrB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_99711a23deca8e31b3fd04d620ec3dd4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Rainer! Thank you so much for your help :) :) Well I assume they are in a datacenter and should not be a power outage.... About dataset size... yes... our ones are big... they can be 3-4 TB easily each dataset..... We bought them, because as they are for mailboxes and mailboxes grow and grow.... for having space for hosting them... We knew they had some speed issues, but those speed issues, we thought (as Samsung explains in the QVO site) they started after exceeding the speeding buffer this disks have. We though that meanwhile you didn't exceed it's capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps we were wrong?. Best regards, El 2022-04-06 14:56, Rainer Duffner escribió: >> Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net: >> I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later. > > Yeah, they are. > > Most likely, they don't have some sort of super-cap. > > A power-failure might totally toast the filesystem. > > These disks are - IMO - designed to accelerate read-operations. Their sustained write-performance is usually mediocre, at best. > > They might work well for small data-sets - because that is really written to some cache and the firmware just claims it's „written", but once the data-set becomes big enough, they are about as fast as a fast SATA-disk. > > https://www.tomshardware.com/reviews/samsung-970-evo-plus-ssd,5608.html --=_99711a23deca8e31b3fd04d620ec3dd4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Rainer!


Thank you so much for your help :) :)

Well I assume they are in a datacenter and should not be a power outage= =2E...

About dataset size... yes... our ones are big... they can be 3-4 TB easi= ly each dataset.....

We bought them, because as they are for mailboxes and mailboxes grow and= grow.... for having space for hosting them...

We knew they had some speed issues, but those speed issues, we thought (= as Samsung explains in the QVO site) they started after exceeding the speed= ing buffer this disks have. We though that meanwhile you didn't exceed it's= capacity (the capacity of the speeding buffer) no speed problem arises. Pe= rhaps we were wrong?.


Best regards,



El 2022-04-06 14:56, Rainer Duffner escribió:



Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net:

I don't really know if, perhaps the QVO technolo= gy could be the guilty here.... because... they say are desktop computers d= isks... but later.

 
Yeah, they are.
 
Most likely, they don't have some sort of super-cap.
 
A power-failure might totally toast the filesystem.
 
These disks are - IMO -  designed to accelerate read-operations= =2E Their sustained write-performance is usually mediocre, at best.
 
They might work well for small data-sets - because that is really writ= ten to some cache and the firmware just claims it's „written", but on= ce the data-set becomes big enough, they are about as fast as a fast SATA-d= isk.
 
 
 
 
--=_99711a23deca8e31b3fd04d620ec3dd4-- From nobody Wed Apr 6 15:30:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 92CF11A83BBB; Wed, 6 Apr 2022 15:30:52 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYT4C3mk8z3svy; Wed, 6 Apr 2022 15:30:51 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 6607560C676; Wed, 6 Apr 2022 17:30:49 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_aa8d0836ba0370d8efdf8758a7e3ea30" Date: Wed, 06 Apr 2022 17:30:49 +0200 From: egoitz@ramattack.net To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: <0ef282aee34b441f1991334e2edbcaec@ramattack.net> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Message-ID: <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYT4C3mk8z3svy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_aa8d0836ba0370d8efdf8758a7e3ea30 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 One perhaps important note!! When this happens... almost all processes appear in top in the following state: txg state or txg-> bio.... perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be increased, decreased.... I'm afraid of doing some chage ana finally ending up with an inestable server.... I'm not an expert in handling these values.... Any recommendation?. Best regards, El 2022-04-06 16:36, egoitz@ramattack.net escribió: > ATENCION: Este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Hi Rainer! > > Thank you so much for your help :) :) > > Well I assume they are in a datacenter and should not be a power outage.... > > About dataset size... yes... our ones are big... they can be 3-4 TB easily each dataset..... > > We bought them, because as they are for mailboxes and mailboxes grow and grow.... for having space for hosting them... > > We knew they had some speed issues, but those speed issues, we thought (as Samsung explains in the QVO site) they started after exceeding the speeding buffer this disks have. We though that meanwhile you didn't exceed it's capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps we were wrong?. > > Best regards, > > El 2022-04-06 14:56, Rainer Duffner escribió: > > Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net: > I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later. > > Yeah, they are. > > Most likely, they don't have some sort of super-cap. > > A power-failure might totally toast the filesystem. > > These disks are - IMO - designed to accelerate read-operations. Their sustained write-performance is usually mediocre, at best. > > They might work well for small data-sets - because that is really written to some cache and the firmware just claims it's „written", but once the data-set becomes big enough, they are about as fast as a fast SATA-disk. > > https://www.tomshardware.com/reviews/samsung-970-evo-plus-ssd,5608.html --=_aa8d0836ba0370d8efdf8758a7e3ea30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

One perhaps important note!!


When this happens... almost all processes appear in top in the following= state:


txg state or

txg->

bio....


perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs= =2Ezfs.vdev.async_write_active_max_dirty_percent be increased, decreased.= =2E.. I'm afraid of doing some chage ana finally ending up with an inestabl= e server.... I'm not an expert in handling these values....


Any recommendation?.


Best regards,

 


El 2022-04-06 16:36, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Hi Rainer!


Thank you so much for your help :) :)

Well I assume they are in a datacenter and should not be a power outage= =2E...

About dataset size... yes... our ones are big... they can be 3-4 TB easi= ly each dataset.....

We bought them, because as they are for mailboxes and mailboxes grow and= grow.... for having space for hosting them...

We knew they had some speed issues, but those speed issues, we thought (= as Samsung explains in the QVO site) they started after exceeding the speed= ing buffer this disks have. We though that meanwhile you didn't exceed it's= capacity (the capacity of the speeding buffer) no speed problem arises. Pe= rhaps we were wrong?.


Best regards,



El 2022-04-06 14:56, Rainer Duffner escribió:



Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net:

I don't really know if, perhaps the QVO technolo= gy could be the guilty here.... because... they say are desktop computers d= isks... but later.

 
Yeah, they are.
 
Most likely, they don't have some sort of super-cap.
 
A power-failure might totally toast the filesystem.
 
These disks are - IMO -  designed to accelerate read-operations= =2E Their sustained write-performance is usually mediocre, at best.
 
They might work well for small data-sets - because that is really writ= ten to some cache and the firmware just claims it's „written", but on= ce the data-set becomes big enough, they are about as fast as a fast SATA-d= isk.
 
 
 
 
--=_aa8d0836ba0370d8efdf8758a7e3ea30-- From nobody Wed Apr 6 15:43:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0B3581A873E2; Wed, 6 Apr 2022 15:43:37 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYTLw164tz4Rt7; Wed, 6 Apr 2022 15:43:36 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649259816; h=from:from:reply-to:subject:subject:date:date: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=DszpBHls3d9k0db5g8HTfayx6XUbGeuJVLcEKqu7X00=; b=Gc5xuom5FY9xOpw9pbd1F6xAo9h6fFjjX6ZZa0srj87yA97Uu0xMLJwlwn29DiJqmS9lUW 6rBc9B/LUBjAL9JHluoyLecZG7WPTnLnLEPPGAvYvf3YpF6hdPZtLdyJnIacTrcTWqZecc jGl7MrQSGn3OkOQyrus9vri9gEPhUe698IJAZIKrSzcwCtA9Q78KvAXoAIRSu88kvfGct8 BeknFduPoU5/w4PknQGlUiHqCOszLY2/XqhVi2EZFXmUCMgfXRKj8tWsSxjC1cu0WihEtp 1PpW9FVAy00CMNWFZgSnHOoRBHw3G/TVcikzZf6ozAsF+20TZoWPEDas69Z0Lw== Received: from [IPV6:2003:cd:5f22:6f00:a5c2:9043:ac1c:2c06] (p200300cd5f226f00a5c29043ac1c2c06.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:a5c2:9043:ac1c:2c06]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C2DF02234; Wed, 6 Apr 2022 15:43:32 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Wed, 6 Apr 2022 17:43:27 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> From: Stefan Esser In-Reply-To: <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xWEDst9IZgYvLPukN2ga6r9b" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649259816; h=from:from:reply-to:subject:subject:date:date: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=DszpBHls3d9k0db5g8HTfayx6XUbGeuJVLcEKqu7X00=; b=aN4rR0ArnFTHAcbxMwgavfJPkS5+OKQlPfEt1Et1uxmcF+JlZXt0XA3/T7la/p1horP/zj WOseXuHjUAkNWnLPN2aeh5cq+TTuB3/9XrhmOF3NDjuj59dF5ikvm0pvAhqZ6GfbWNxFTD zIPeu0BwVtRLTujVxtYvsWhk9syiPIrVfmjaL40GxcnIuwocG2gMs0ygkn9P5okXCX+ZTy ztX0bnRWvrPKSQjztLOY6TiTSagOw8H6L9InjiPlXdF3TsJxxuK+LRecN9+90HbGQRHzxb 8lyj0IQtmdFmSoZI7o0sHk0TkiBus9KSDJ1ITSaYRKyPkCiw3BZ9TQDw2YHISQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649259816; a=rsa-sha256; cv=none; b=Kh0/OSy2P0jg8Ud2tGvmRxYZEOwkXWAVZpjm83vZci17DkOsyBf8dW34XMZ5BukYz2EVBV ogoweL4BZh0pL34FGqJ8cL0/CioGC8N/qydaux+MobxVFKyvDfX8fTOlR6QOclh225o63Z ubUAOVUytF5H+3ku//KvSceootMPYY1/UOOjPImCZsAjTiWXyz54Y2gKSyfAF0J7LG4bf0 fCiWAbNWnTWYlEfcUGE3SRnKQrPk+htaTT2APKWkRX5jGvDxlO3EYzHcQU7ie+qjRv8EuX 4kAmnhFgsgOiYSoCB2OSqti+/Y3ux1IFIZ5OV8+vv0n1muQusDn97SPRphb9Mw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xWEDst9IZgYvLPukN2ga6r9b Content-Type: multipart/mixed; boundary="------------gUL8upCKsfSinXvRen5NU9ab"; protected-headers="v1" From: Stefan Esser To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Message-ID: Subject: Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> In-Reply-To: <0ef282aee34b441f1991334e2edbcaec@ramattack.net> --------------gUL8upCKsfSinXvRen5NU9ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: > Hi Rainer! >=20 > Thank you so much for your help :) :) >=20 > Well I assume they are in a datacenter and should not be a power outage= =2E... >=20 > About dataset size... yes... our ones are big... they can be 3-4 TB eas= ily each > dataset..... >=20 > We bought them, because as they are for mailboxes and mailboxes grow an= d > grow.... for having space for hosting them... Which mailbox format (e.g. mbox, maildir, ...) do you use? > We knew they had some speed issues, but those speed issues, we thought = (as > Samsung explains in the QVO site) they started after exceeding the spee= ding > buffer this disks have. We though that meanwhile you didn't exceed it's= > capacity (the capacity of the speeding buffer) no speed problem arises.= Perhaps > we were wrong?. These drives are meant for small loads in a typical PC use case, i.e. some installations of software in the few GB range, else only files of a few MB being written, perhaps an import of media files that range from tens to a few hundred MB at a time, but less often than once a day. As the SSD fills, the space available for the single level write cache gets smaller (on many SSDs, I have no numbers for this particular device), and thus the amount of data that can be written at single cell speed shrinks as the SSD gets full. I have just looked up the size of the SLC cache, it is specified to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB version, smaller models will have a smaller SLC cache). But after writing those few GB at a speed of some 500 MB/s (i.e. after 12 to 150 seconds), the drive will need several minutes to transfer those writes to the quad-level cells, and will operate at a fraction of the nominal performance during that time. (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the 2 TB model.) And cheap SSDs often have no RAM cache (not checked, but I'd be surprised if the QVO had one) and thus cannot keep bookkeeping date in such a cache, further limiting the performance under load. And the resilience (max. amount of data written over its lifetime) is also quite low - I hope those drives are used in some kind of RAID configuration. The 870 QVO is specified for 370 full capacity writes, i.e. 370 TB for the 1 TB model. That's still a few hundred GB a day - but only if the write amplification stays in a reasonable range ... --------------gUL8upCKsfSinXvRen5NU9ab-- --------------xWEDst9IZgYvLPukN2ga6r9b Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJNtR8FAwAAAAAACgkQR+u171r99UQX jggAh1PLi41CMsG6xbRvf9KA3JRSYjHGSCr3soAi5Su5VZmVNts3ocVUONOfR4yoTj/JGZ0HYvwi iQm4PxPLS7Fj69joQnernx6Dhem6yg8hJSwrU3HDZQ4lIDSQ2B220+uz9MrqImu21JvDxIRzmgH+ kQ7Q3+ZoxCi0BJX83yL8sh0wMA5tLrV1e8IKrpBR/mLiwQZRoaOPKXKx29eP4Q8St57UySGfGL13 O33jTgM8sAAGkImgAa2JzXRhYQ2KY5QnplYv1cxk6Zbpuq1TgovqGm3pzak0i1kTiK95K3tWYhMh 2ne2gmnXcO6CGu+QeUapXJN10sefE8gRNrBDLzpjJg== =HKc2 -----END PGP SIGNATURE----- --------------xWEDst9IZgYvLPukN2ga6r9b-- From nobody Wed Apr 6 15:48:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AEEFF1A8A975; Wed, 6 Apr 2022 15:56:47 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYTf621Wdz4W0C; Wed, 6 Apr 2022 15:56:44 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id 1F6F860C6A8; Wed, 6 Apr 2022 17:48:31 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a4ce21118f18db79ad9328c5f2cebb5a" Date: Wed, 06 Apr 2022 17:48:31 +0200 From: egoitz@ramattack.net To: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Cc: owner-freebsd-fs@freebsd.org Subject: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> Message-ID: <29f0eee5b502758126bf4cfa2d8e3517@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYTf621Wdz4W0C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_a4ce21118f18db79ad9328c5f2cebb5a Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I have been thinking and.... I got the following tunables now : vfs.zfs.arc_meta_strategy: 0 vfs.zfs.arc_meta_limit: 17179869184 kstat.zfs.misc.arcstats.arc_meta_min: 4294967296 kstat.zfs.misc.arcstats.arc_meta_max: 19386809344 kstat.zfs.misc.arcstats.arc_meta_limit: 17179869184 kstat.zfs.misc.arcstats.arc_meta_used: 16870668480 vfs.zfs.arc_max: 68719476736 and top sais : ARC: 19G Total, 1505M MFU, 12G MRU, 6519K Anon, 175M Header, 5687M Other When using even 128GB of vfs.zfs.arc_max (instead of 64GB I have now set) the ARC wasn't approximating to it's max usable size.... Can perhaps that could have something to do with that fact that arc meta values are almost at the limit set?. Perhaps increasing vfs.zfs.arc_meta_limit or kstat.zfs.misc.arcstats.arc_meta_limit (I suppose the first one is the one to increase) could cause a better performance and perhaps a better usage and better take advantage of having 64GB max of ARC set?. I say it because now it doesn't use more than 19GB in total ARC memory.... As always said, any opinion or idea would be very highly appreciated. Cheers, El 2022-04-06 17:30, egoitz@ramattack.net escribió: > ATENCION: Este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > One perhaps important note!! > > When this happens... almost all processes appear in top in the following state: > > txg state or > > txg-> > > bio.... > > perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be increased, decreased.... I'm afraid of doing some chage ana finally ending up with an inestable server.... I'm not an expert in handling these values.... > > Any recommendation?. > > Best regards, > > El 2022-04-06 16:36, egoitz@ramattack.net escribió: > > ATENCION: Este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Hi Rainer! > > Thank you so much for your help :) :) > > Well I assume they are in a datacenter and should not be a power outage.... > > About dataset size... yes... our ones are big... they can be 3-4 TB easily each dataset..... > > We bought them, because as they are for mailboxes and mailboxes grow and grow.... for having space for hosting them... > > We knew they had some speed issues, but those speed issues, we thought (as Samsung explains in the QVO site) they started after exceeding the speeding buffer this disks have. We though that meanwhile you didn't exceed it's capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps we were wrong?. > > Best regards, > > El 2022-04-06 14:56, Rainer Duffner escribió: > > Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net: > I don't really know if, perhaps the QVO technology could be the guilty here.... because... they say are desktop computers disks... but later. > > Yeah, they are. > > Most likely, they don't have some sort of super-cap. > > A power-failure might totally toast the filesystem. > > These disks are - IMO - designed to accelerate read-operations. Their sustained write-performance is usually mediocre, at best. > > They might work well for small data-sets - because that is really written to some cache and the firmware just claims it's „written", but once the data-set becomes big enough, they are about as fast as a fast SATA-disk. > > https://www.tomshardware.com/reviews/samsung-970-evo-plus-ssd,5608.html --=_a4ce21118f18db79ad9328c5f2cebb5a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I have been thinking and.... I got the following tunables now :

vfs.zfs.arc_meta_strategy: 0
vfs.zfs.arc_meta_limit: 17179869184kstat.zfs.misc.arcstats.arc_meta_min: 4294967296
kstat.zfs.misc.arc= stats.arc_meta_max: 19386809344
kstat.zfs.misc.arcstats.arc_meta_limit= : 17179869184
kstat.zfs.misc.arcstats.arc_meta_used: 16870668480
= vfs.zfs.arc_max: 68719476736

and top sais :

ARC: 19G Total, 1505M MFU, 12G MRU, 6519K Anon, 175M Header, 5687M Other=


When using even 128GB of vfs.zfs.arc_max (instead of 64GB I have now set= ) the ARC wasn't approximating to it's max usable size.... Can perhaps that= could have something to do with that fact that arc meta values are almost = at the limit set?. Perhaps increasing vfs.zfs.arc_meta_limit or kstat.zfs= =2Emisc.arcstats.arc_meta_limit (I suppose the first one is the one to incr= ease) could cause a better performance and perhaps a better usage and bette= r take advantage of having 64GB max of ARC set?. I say it because now it do= esn't use more than 19GB in total ARC memory....


As always said, any opinion or idea would be very highly appreciated.


Cheers,


 


El 2022-04-06 17:30, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

One perhaps important note!!


When this happens... almost all processes appear in top in the following= state:


txg state or

txg->

bio....


perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs= =2Ezfs.vdev.async_write_active_max_dirty_percent be increased, decreased.= =2E.. I'm afraid of doing some chage ana finally ending up with an inestabl= e server.... I'm not an expert in handling these values....


Any recommendation?.


Best regards,

 


El 2022-04-06 16:36, egoitz@ramattack.net escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Hi Rainer!


Thank you so much for your help :) :)

Well I assume they are in a datacenter and should not be a power outage= =2E...

About dataset size... yes... our ones are big... they can be 3-4 TB easi= ly each dataset.....

We bought them, because as they are for mailboxes and mailboxes grow and= grow.... for having space for hosting them...

We knew they had some speed issues, but those speed issues, we thought (= as Samsung explains in the QVO site) they started after exceeding the speed= ing buffer this disks have. We though that meanwhile you didn't exceed it's= capacity (the capacity of the speeding buffer) no speed problem arises. Pe= rhaps we were wrong?.


Best regards,



El 2022-04-06 14:56, Rainer Duffner escribió:



Am 06.04.2022 um 13:15 schrieb egoitz@ramattack.net:

I don't really know if, perhaps the QVO technolo= gy could be the guilty here.... because... they say are desktop computers d= isks... but later.

 
Yeah, they are.
 
Most likely, they don't have some sort of super-cap.
 
A power-failure might totally toast the filesystem.
 
These disks are - IMO -  designed to accelerate read-operations= =2E Their sustained write-performance is usually mediocre, at best.
 
They might work well for small data-sets - because that is really writ= ten to some cache and the firmware just claims it's „written", but on= ce the data-set becomes big enough, they are about as fast as a fast SATA-d= isk.
 
 
 
 
--=_a4ce21118f18db79ad9328c5f2cebb5a-- From eugen@grosbein.net Wed Apr 6 16:14:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7848B1A8F2A7; Wed, 6 Apr 2022 16:15:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYV3f0Bzhz4bLk; Wed, 6 Apr 2022 16:15:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 236GFMI2057370 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 16:15:23 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: egoitz@ramattack.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 236GEvnk092344 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 6 Apr 2022 23:15:22 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Desperate with 870 QVO and ZFS To: egoitz@ramattack.net, freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> From: Eugene Grosbein Message-ID: Date: Wed, 6 Apr 2022 23:14:51 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KYV3f0Bzhz4bLk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-performance,freebsd-hackers,freebsd-fs]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.04.2022 22:30, egoitz@ramattack.net пишет: > One perhaps important note!! > > > When this happens... almost all processes appear in top in the following state: > > > txg state or > > txg-> > > bio.... > > > perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be increased, decreased.... I'm afraid of doing some chage ana finally ending up with an inestable server.... I'm not an expert in handling these values.... > > > Any recommendation?. 1) Make sure the pool has enough free space because ZFS can became crawling slow otherwise. 2) Increase recordsize upto 1MB for file systems located in the pool so ZFS is allowed to use bigger request sizes for read/write operations 3) If you use compression, look if achieved compressratio worth it and if not (<1.4 f.e.) then better disable compression to avoid its overhead; 4) try "zfs set redundant_metadata=most" to decrease amount of small writes to the file systems; 5) If you have good power supply and stable (non-crashing) OS, try increasing sysctl vfs.zfs.txg.timeout from defaule 5sec, but do not be extreme (f.e. upto 10sec). Maybe it will increase amount of long writes and decrease amount of short writes, that is good. From nobody Wed Apr 6 16:34:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 94E3B1A93BAB; Wed, 6 Apr 2022 16:35:01 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYVVC4tX0z4ftP; Wed, 6 Apr 2022 16:34:59 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 4B1C660C60B; Wed, 6 Apr 2022 18:34:56 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9e84ea9eb28b05e81541398ce76d2803" Date: Wed, 06 Apr 2022 18:34:56 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYVVC4tX0z4ftP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_9e84ea9eb28b05e81541398ce76d2803 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Stefan! Thank you so much for your answer!!. I do answer below in green bold for instance... for a better distinction.... Very thankful for all your comments Stefan!!! :) :) :) Cheers!! El 2022-04-06 17:43, Stefan Esser escribió: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: > >> Hi Rainer! >> >> Thank you so much for your help :) :) >> >> Well I assume they are in a datacenter and should not be a power outage.... >> >> About dataset size... yes... our ones are big... they can be 3-4 TB easily each >> dataset..... >> >> We bought them, because as they are for mailboxes and mailboxes grow and >> grow.... for having space for hosting them... > > Which mailbox format (e.g. mbox, maildir, ...) do you use? > > I'M RUNNING CYRUS IMAP SO SORT OF MAILDIR... TOO MANY LITTLE FILES NORMALLY..... SOMETIMES DIRECTORIES WITH TONS OF LITTLE FILES.... > >> We knew they had some speed issues, but those speed issues, we thought (as >> Samsung explains in the QVO site) they started after exceeding the speeding >> buffer this disks have. We though that meanwhile you didn't exceed it's >> capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps >> we were wrong?. > > These drives are meant for small loads in a typical PC use case, > i.e. some installations of software in the few GB range, else only > files of a few MB being written, perhaps an import of media files > that range from tens to a few hundred MB at a time, but less often > than once a day. > > WE MOVE, YOU KNOW... LOTS OF LITTLE FILES... AND LOT'S OF DIFFERENT CONCURRENT MODIFICATIONS BY 1500-2000 CONCURRENT IMAP CONNECTIONS WE HAVE... > > As the SSD fills, the space available for the single level write > cache gets smaller > > THE SINGLE LEVEL WRITE CACHE IS THE CACHE THESE SSD DRIVERS HAVE, FOR COMPENSATING THE SPEED ISSUES THEY HAVE DUE TO USING QLC MEMORY?. DO YOU REFER TO THAT?. SORRY I DON'T UNDERSTAND WELL THIS PARAGRAPH. > > (on many SSDs, I have no numbers for this > particular device), and thus the amount of data that can be > written at single cell speed shrinks as the SSD gets full. > > I have just looked up the size of the SLC cache, it is specified > to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB > version, smaller models will have a smaller SLC cache). > > ASSUMING YOU WERE TALKING ABOUT THE CACHE FOR COMPENSATING SPEED WE PREVIOUSLY COMMENTED, I SHOULD SAY THESE ARE THE 870 QVO BUT THE 8TB VERSION. SO THEY SHOULD HAVE THE BIGGEST CACHE FOR COMPENSATING THE SPEED ISSUES... > > But after writing those few GB at a speed of some 500 MB/s (i.e. > after 12 to 150 seconds), the drive will need several minutes to > transfer those writes to the quad-level cells, and will operate > at a fraction of the nominal performance during that time. > (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the > 2 TB model.) > > WELL WE ARE IN THE 8TB MODEL. I THINK I HAVE UNDERSTOOD WHAT YOU WROTE IN PREVIOUS PARAGRAPH. YOU SAID THEY CAN BE FAST BUT NOT CONSTANTLY, BECAUSE LATER THEY HAVE TO WRITE ALL THAT TO THEIR PERPETUAL STORAGE FROM THE CACHE. AND THAT'S SLOW. AM I WRONG?. EVEN IN THE 8TB MODEL YOU THINK STEFAN?. > > THE MAIN PROBLEM WE ARE FACING IS THAT IN SOME PEAK MOMENTS, WHEN THE MACHINE SERVES CONNECTIONS FOR ALL THE INSTANCES IT HAS, AND ONLY AS SAID IN SOME PEAK MOMENTS... LIKE THE 09AM OR THE 11AM.... IT SEEMS THE MACHINE BECOMES SLOWER... AND LIKE IF THE DISKS WEREN'T ABLE TO SERVE ALL THEY HAVE TO SERVE.... IN THESE MOMENTS, NO BIG FILES ARE MOVED... BUT AS WE HAVE 1800-2000 CONCURRENT IMAP CONNECTIONS... NORMALLY THEY ARE DOING EACH ONE... LITTLE CHANGES IN THEIR MAILBOX. DO YOU THINK PERHAPS THIS DISKS THEN ARE NOT APPROPRIATE FOR THIS KIND OF USAGE?- > > And cheap SSDs often have no RAM cache (not checked, but I'd be > surprised if the QVO had one) and thus cannot keep bookkeeping date > in such a cache, further limiting the performance under load. > > THIS BROCHURE (HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/BROCHURE/870_SERIES_BROCHURE.PDF AND THE DATASHEET HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/DATA-SHEET/SAMSUNG_SSD_870_QVO_DATA_SHEET_REV1.1.PDF) SAIS IF I HAVE READ PROPERLY, THE 8TB DRIVE HAS 8GB OF RAM?. I ASSUME THAT IS WHAT THEY CALL THE TURBO WRITE CACHE?. > > And the resilience (max. amount of data written over its lifetime) > is also quite low - I hope those drives are used in some kind of > RAID configuration. > > YEP WE USE RAIDZ-2 > > The 870 QVO is specified for 370 full capacity > writes, i.e. 370 TB for the 1 TB model. That's still a few hundred > GB a day - but only if the write amplification stays in a reasonable > range ... > > WELL YES... 2880TB IN OUR CASE....NOT BAD.. ISN'T IT? --=_9e84ea9eb28b05e81541398ce76d2803 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Stefan!


Thank you so much for your answer!!. I do answer below in green bold for= instance... for a better distinction....


Very thankful for all your comments Stefan!!! :) :) :)


Cheers!!

 


El 2022-04-06 17:43, Stefan Esser escribió:

= ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde f= uera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no= ser que reconozca el remitente y sepa que el contenido es seguro.
Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net:
Hi Rainer!

Thank you so much for your hel= p :) :)

Well I assume they are in a datacenter and should not = be a power outage....

About dataset size... yes... our ones ar= e big... they can be 3-4 TB easily each
dataset.....

We = bought them, because as they are for mailboxes and mailboxes grow and
= grow.... for having space for hosting them...

Which mailbox format (e.g. mbox, maildir, ...) do you use?
=  
= I'm running Cyrus imap so sort of M= aildir... too many little files normally..... Sometimes directories with to= ns of little files....

We knew they had some speed issues, but those speed is= sues, we thought (as
Samsung explains in the QVO site) they started a= fter exceeding the speeding
buffer this disks have. We though that me= anwhile you didn't exceed it's
capacity (the capacity of the speeding= buffer) no speed problem arises. Perhaps
we were wrong?.
These drives are meant for small loads in a typical PC use case,
i.e. some installations of software in the few GB range, else only
= files of a few MB being written, perhaps an import of media files
th= at range from tens to a few hundred MB at a time, but less often
than= once a day.
=  
= We move, you know... lots of little= files... and lot's of different concurrent modifications by 1500-2000 conc= urrent imap connections we have...
=
As the SSD fills, the space available for the single level write
cache gets smaller
=  
= The single level write cache is the= cache these ssd drivers have, for compensating the speed issues they have = due to using qlc memory?. Do you refer to that?. Sorry I don't understand w= ell this paragraph.
=  
= (on many SSDs, I have no numbers for this
particular device), and thu= s the amount of data that can be
written at single cell speed shrinks= as the SSD gets full.
=  
=

I have just looked up the size of the SLC cache, it is specif= ied
to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB=
version, smaller models will have a smaller SLC cache).
=  
= Assuming you were talking about the= cache for compensating speed we previously commented, I should say these a= re the 870 QVO but the 8TB version. So they should have the biggest cache f= or compensating the speed issues...
=  
=

But after writing those few GB at a speed of some 500 MB/s (i= =2Ee.
after 12 to 150 seconds), the drive will need several minutes t= o
transfer those writes to the quad-level cells, and will operate
at a fraction of the nominal performance during that time.
(QLC wr= ites max out at 80 MB/s for the 1 TB model, 160 MB/s for the
2 TB mod= el.)
=  
= Well we are in the 8TB model. I thi= nk I have understood what you wrote in previous paragraph. You said they ca= n be fast but not constantly, because later they have to write all that to = their perpetual storage from the cache. And that's slow. Am I wrong?. Even = in the 8TB model you think Stefan?.
=  
= The main problem we are facing is t= hat in some peak moments, when the machine serves connections for all the i= nstances it has, and only as said in some peak moments... like the 09am or = the 11am.... it seems the machine becomes slower... and like if the disks w= eren't able to serve all they have to serve.... In these moments, no big fi= les are moved... but as we have 1800-2000 concurrent imap connections... no= rmally they are doing each one... little changes in their mailbox. Do you t= hink perhaps this disks then are not appropriate for this kind of usage?-

And cheap SSDs often have no RAM cache (not che= cked, but I'd be
surprised if the QVO had one) and thus cannot keep b= ookkeeping date
in such a cache, further limiting the performance und= er load.
=  
= This brochure (https://semiconductor.samsung.com/resources/brochure/87= 0_Series_Brochure.pdf and the datasheet https://semiconductor.samsung= =2Ecom/resources/data-sheet/Samsung_SSD_870_QVO_Data_Sheet_Rev1.1.pdf) sais= if I have read properly, the 8TB drive has 8GB of ram?. I assume that is w= hat they call the turbo write cache?.

And the = resilience (max. amount of data written over its lifetime)
is also qu= ite low - I hope those drives are used in some kind of
RAID configura= tion.
=  
= Yep we use raidz-2<= /div>
=  
= The 870 QVO is specified for 370 full capacity
writes, i.e. 370 TB fo= r the 1 TB model. That's still a few hundred
GB a day - but only if t= he write amplification stays in a reasonable
range ...
=  
= Well yes... 2880TB in our case...= =2Enot bad.. isn't it?
--=_9e84ea9eb28b05e81541398ce76d2803-- From nobody Wed Apr 6 16:51:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 437DE1A983A4; Wed, 6 Apr 2022 16:51:55 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYVsk0NY1z4lVF; Wed, 6 Apr 2022 16:51:52 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id 027BD60C6BF; Wed, 6 Apr 2022 18:51:49 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_be6199b7d5e868a9b11faca98e7631c5" Date: Wed, 06 Apr 2022 18:51:49 +0200 From: egoitz@ramattack.net To: Eugene Grosbein Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> Message-ID: <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYVsk0NY1z4lVF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_be6199b7d5e868a9b11faca98e7631c5 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Eugene!!! Thank you so much really again mate :) :) :) About your recommendations... Eugene, if some of them wouldn't be working as expected, could we revert some or all of them or perhaps some of your recommendations below need to be definitive?. I do answer below in green bold for better distinction :) :) El 2022-04-06 18:14, Eugene Grosbein escribió: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > 06.04.2022 22:30, egoitz@ramattack.net пишет: > >> One perhaps important note!! >> >> When this happens... almost all processes appear in top in the following state: >> >> txg state or >> >> txg-> >> >> bio.... >> >> perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be increased, decreased.... I'm afraid of doing some chage ana finally ending up with an inestable server.... I'm not an expert in handling these values.... >> >> Any recommendation?. > > 1) Make sure the pool has enough free space because ZFS can became crawling slow otherwise. > > THIS IS JUST AN EXAMPLE... BUT YOU CAN SEE ALL SIMILARLY.... > > ZPOOL LIST > NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT > ZROOT 448G 2.27G 446G - - 1% 0% 1.00X ONLINE - > MAIL_DATASET 58.2T 19.4T 38.8T - - 32% 33% 1.00X ONLINE - > > 2) Increase recordsize upto 1MB for file systems located in the pool > so ZFS is allowed to use bigger request sizes for read/write operations > > WE HAVE THE DEFAULT... SO 128K... > > 3) If you use compression, look if achieved compressratio worth it and > if not (<1.4 f.e.) then better disable compression to avoid its overhead; > > WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... > > WE SHOULD SAY WE HAVE LOTS OF CPU... > > 4) try "zfs set redundant_metadata=most" to decrease amount of small writes to the file systems; > > OK.... > > 5) If you have good power supply and stable (non-crashing) OS, try increasing > sysctl vfs.zfs.txg.timeout from defaule 5sec, but do not be extreme (f.e. upto 10sec). > Maybe it will increase amount of long writes and decrease amount of short writes, that is good. > > WELL I HAVE SYNC IN DISABLED IN THE DATASETS... DO YOU STILL THINK IT'S GOOD TO CHANGE IT?. JUST A QUESTION OF PERSON WANTING TO LEARN :) . > > WHAT ABOUT THE VFS.ZFS.DIRTY_DATA_MAX AND THE VFS.ZFS.DIRTY_DATA_MAX_MAX, WOULD YOU INCREASE THEM FROM 4GB IT'S SET NOW?. > > THANKS A LOT EUGENE!!!! > CHEERS!! --=_be6199b7d5e868a9b11faca98e7631c5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Eugene!!!


Thank you so much really again mate  :) :) :)


About your recommendations... Eugene, if some of them wouldn't be workin= g as expected, could we revert some or all of them or perhaps some of your = recommendations below need to be definitive?.


I do answer below in green bold for better distinction :) :)



 


El 2022-04-06 18:14, Eugene Grosbein escribió:

= ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde f= uera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no= ser que reconozca el remitente y sepa que el contenido es seguro.
06.04.2022 22:30, egoitz@ramat= tack.net =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
One perhaps important note!!


When = this happens... almost all processes appear in top in the following state:<= br />

txg state or

txg->

bio..= =2E.


perhaps should the the vfs.zfs.dirty_data_max, vfs= =2Ezfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be in= creased, decreased.... I'm afraid of doing some chage ana finally ending up= with an inestable server.... I'm not an expert in handling these values.= =2E..


Any recommendation?.

1) Make sure the pool has enough free space because ZFS can became c= rawling slow otherwise.
=  
= This is just an example... but you = can see all similarly....
=  
= zpool list
NAME     &nbs= p;       SIZE  ALLOC   FREE&nb= sp; CKPOINT  EXPANDSZ   FRAG    CAP  DED= UP  HEALTH  ALTROOT
zroot          = ;   448G  2.27G   446G    &nbs= p;   -         - &nb= sp;   1%     0%  1.00x  ONLINE = ; -
mail_datas= et  58.2T  19.4T  38.8T      &= nbsp; -         -   = 32%    33%  1.00x  ONLINE  -=


2) Increase recordsize upto 1MB for file systems locate= d in the pool
so ZFS is allowed to use bigger request sizes for read/= write operations
=  
= We have the default... so 128K...

3) If you use compression, look if achieved com= pressratio worth it and
if not (<1.4 f.e.) then better disable com= pression to avoid its overhead;
=  
= We don't use compression as it's no= t set by default. Some people say you should have it enabled.... but.... ju= st for avoid having some data compressed some other not (in case you enable= and later disable) and finally for avoid accessing to information with dif= ferent cpu costs of handling... we have not touched compression....<= /strong>
=  
= We should say we have lots of CPU= =2E..
=

4) try "zfs set redundant_metadata=3Dmost" to decrease amount= of small writes to the file systems;
=  
= Ok....
=

5) If you have good power supply and stable (non-crashing) OS= , try increasing
sysctl vfs.zfs.txg.timeout from defaule 5sec, but do= not be extreme (f.e. upto 10sec).
Maybe it will increase amount of l= ong writes and decrease amount of short writes, that is good.
=  
= Well I have sync in disabled in the= datasets... do you still think it's good to change it?. Just a question of= person wanting to learn :) .
=  
= What about the vfs.zfs.dirty_data_m= ax and the vfs.zfs.dirty_data_max_max, would you increase them from 4GB it'= s set now?.
=  
=  
=  
=  
=  
=  
=  
=  
=  
=  
=  
=  
= Thanks a lot Eugene!!!!
= Cheers!!
--=_be6199b7d5e868a9b11faca98e7631c5-- From eugen@grosbein.net Wed Apr 6 18:10:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD9D11A37675; Wed, 6 Apr 2022 18:10:55 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYXct5Ypzz3MfF; Wed, 6 Apr 2022 18:10:54 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 236IAp5j058598 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Apr 2022 18:10:52 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: egoitz@ramattack.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 236IAPF0092951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 7 Apr 2022 01:10:50 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS To: egoitz@ramattack.net References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance From: Eugene Grosbein Message-ID: Date: Thu, 7 Apr 2022 01:10:20 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KYXct5Ypzz3MfF X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-performance,freebsd-hackers,freebsd-fs]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 06.04.2022 23:51, egoitz@ramattack.net wrote: > About your recommendations... Eugene, if some of them wouldn't be working as expected, > could we revert some or all of them Yes, it all can be reverted. Just write down original sysctl values if you are going to change it. > 1) Make sure the pool has enough free space because ZFS can became crawling slow otherwise. > > *This is just an example... but you can see all similarly....* > > *zpool list* > *NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT* > *zroot 448G 2.27G 446G - - 1% 0% 1.00x ONLINE -* > *mail_dataset 58.2T 19.4T 38.8T - - 32% 33% 1.00x ONLINE -* It's all right. > 2) Increase recordsize upto 1MB for file systems located in the pool > so ZFS is allowed to use bigger request sizes for read/write operations > > *We have the default... so 128K...* It will not hurt increasing it upto 1MB. > 5) If you have good power supply and stable (non-crashing) OS, try increasing > sysctl vfs.zfs.txg.timeout from defaule 5sec, but do not be extreme (f.e. upto 10sec). > Maybe it will increase amount of long writes and decrease amount of short writes, that is good. > > *Well I have sync in disabled in the datasets... do you still think it's good to change it? Yes, try it. Disabling sync makes sense if you have lots of fsync() operations but other small writes are not affected unless you raise vfs.zfs.txg.timeout > *What about the vfs.zfs.dirty_data_max and the vfs.zfs.dirty_data_max_max, would you increase them from 4GB it's set now?.* Never tried that and cannot tell. From nobody Wed Apr 6 20:43:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 612D21A94AD9; Wed, 6 Apr 2022 20:44:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYc1X2RkDz4gKb; Wed, 6 Apr 2022 20:44:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 236KhqDK072088 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 Apr 2022 16:43:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:434:73cd:9d42:28ad] ([IPv6:2607:f3e0:0:4:434:73cd:9d42:28ad]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 236Khnm3007273 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 6 Apr 2022 16:43:49 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Wed, 6 Apr 2022 16:43:49 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: Bob Friesenhahn , egoitz@ramattack.net Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> From: mike tancsa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4KYc1X2RkDz4gKb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-3.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.78)[-0.782]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received] X-ThisMailContainsUnwantedMimeParts: N On 4/6/2022 4:18 PM, Bob Friesenhahn wrote: > On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: >>> >>> WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY >>> YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME >>> DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER >>> DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH >>> DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... > > There seems to be a problem with your caps-lock key. > > Since it seems that you said that you are using maildir for your mail > server, it is likely very useful if you do enable even rather mild > compression (e.g. lz4) since this will reduce the write work-load and > even short files will be stored more efficiently. > FYI, a couple of our big zfs  mailspools sees a 1.24x and 1.23x compress ratio with lz4.  We use Maildir format as well.  They are not RELENG_13 so not sure how zstd would fair.     ---Mike From nobody Wed Apr 6 21:49:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B1871AA6E8B; Wed, 6 Apr 2022 21:49:21 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYdSx1J3Rz3BqT; Wed, 6 Apr 2022 21:49:21 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649281761; h=from:from:reply-to:subject:subject:date:date: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=NTQDA7AmEiqtZXUltjZC6r1zqKWrWLTuqyQu/QurDx8=; b=gb/sw9et6KM9TPLK36zERnOOE6ihAh7FHW0Z5Fgu10FhytX/Y4J4Pnd4u2AlvMSr8DL7Kg iRDaVGq2tiA5Yz7RzmwkeTQxw3flBHgJmswMtg8EOC1gl/L6SIqgBKMVJ4ICBWBxc95STj fSxZCei8tWY+Pwm4+qpUrzivT6+QMaMMm2ig9Wlk6oFlv+yEKwmxiHaqhQpVVpPCqystKX 1MPoTCNvMJgUU7gyYkTGWICu5UvV4fBq9gtF1ErEGXDeqCQ1w3ENkbV79lPsZ6knddmHRz 6YK0Vv0o6WEPzjboA8bpJY6rC5cS6KIfq81o7l4IM/VRAkx566gjymcWXm8a9g== Received: from [IPV6:2003:cd:5f22:6f00:953e:7ee1:500e:87a1] (p200300cd5f226f00953e7ee1500e87a1.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:953e:7ee1:500e:87a1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 176914D30; Wed, 6 Apr 2022 21:49:19 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Wed, 6 Apr 2022 23:49:15 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Lic1usorjc8S7FifC6L0nUmq" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649281761; h=from:from:reply-to:subject:subject:date:date: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=NTQDA7AmEiqtZXUltjZC6r1zqKWrWLTuqyQu/QurDx8=; b=v5/9q0D36uM6by3oYOW443+rDA3y21ugXHLeseeuzJs6uALdA6p7lQNGhL/K5PLN0SncDG Ze2s0aAILCb2FaUJDRp5csshI8Bd9nT+L5jXZJrOKJ7L4RHetAoNVXCj2/Onql93fRJft7 0IIaiCTwWEkQWgpWvpqm8VhLvNkr1LlxW5Ml6Oh7uxJgefQH/r0Y5jKry+tmSeRtIvNAdc 2kaZJrECFKqL+zOJeb5qObc1ss0F4ViPi/wrPL3DXSGn6Cc2J/hdU6A18B4fGGMJEtVOeJ +Ln/wIfCbLW+CMB3b86IlBeIF6YaestXttvguHQa68/IgnQl+mCKQ9TkFYvjqw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649281761; a=rsa-sha256; cv=none; b=KT9L8BUHeIW4nZrivqVSEpnzwZ2veeKiP2ovXRvBoh2v+loi8Ts72fDcwkndPNSnqlNzPQ CD1E9/NP2epXmB33xK+oL9fJN1k0ZbmLf9uC8jasQwU77EQM7jKDKbuLu1rSHhNC2Avw3r Q+0lAxAyhzDjMAoF4MoAND7D7RAMkOLMeRvKMjRnYKV4FMCLtN+LTtXs2bLcr+j+hQ74Rv D1mKpI60anTgLJDuSxe0ScgthHQ1MpvgjLUTRFPuB/g1Bz10QS/jTP/IAWKkWua97/6hQV PCaznQuyUuI+N+IFFpJ2JhW1zuQfJUgJMP3Vt4tzVxYuM1WPzVcSeYA0EMUtRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Lic1usorjc8S7FifC6L0nUmq Content-Type: multipart/mixed; boundary="------------OGljiRSjG08yilMHhaNFyDtW"; protected-headers="v1" From: Stefan Esser To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Message-ID: Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> In-Reply-To: --------------OGljiRSjG08yilMHhaNFyDtW Content-Type: multipart/alternative; boundary="------------ASZf2V7VPlu8lceG03SodTv5" --------------ASZf2V7VPlu8lceG03SodTv5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.04.22 um 18:34 schrieb egoitz@ramattack.net: > Hi Stefan! > > Thank you so much for your answer!!. I do answer below in green bold fo= r > instance... for a better distinction.... > > Very thankful for all your comments Stefan!!! :) :) :) > > Cheers!! > Hi, glad to hear that it is useful information - I'll add comments below ... > El 2022-04-06 17:43, Stefan Esser escribi=C3=B3: > >> ATENCION >> ATENCION >> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. = No >> pinche en los enlaces ni abra los adjuntos a no ser que reconozca el >> remitente y sepa que el contenido es seguro. >> >> Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: >>> Hi Rainer! >>> >>> Thank you so much for your help :) :) >>> >>> Well I assume they are in a datacenter and should not be a power outa= ge.... >>> >>> About dataset size... yes... our ones are big... they can be 3-4 TB e= asily each >>> dataset..... >>> >>> We bought them, because as they are for mailboxes and mailboxes grow = and >>> grow.... for having space for hosting them... >> >> Which mailbox format (e.g. mbox, maildir, ...) do you use? >> =C2=A0 >> *I'm running Cyrus imap so sort of Maildir... too many little files >> normally..... Sometimes directories with tons of little files....* Assuming that many mails are much smaller than the erase block size of th= e SSD, this may cause issues. (You may know the following ...) For example, if you have message sizes of 8 KB and an erase block size of= 64 KB (just guessing), then 8 mails will be in an erase block. If half the mail= s are deleted, then the erase block will still occupy 64 KB, but only hold 32 K= B of useful data (and the SSD will only be aware of this fact if TRIM has sign= aled which data is no longer relevant). The SSD will copy several partially fi= lled erase blocks together in a smaller number of free blocks, which then are = fully utilized. Later deletions will repeat this game, and your data will be co= pied multiple times until it has aged (and the user is less likely to delete f= urther messages). This leads to "write amplification" - data is internally moved= around and thus written multiple times. Larger mails are less of an issue since they span multiple erase blocks, = which will be completely freed when such a message is deleted. Samsung has a lot of experience and generally good strategies to deal wit= h such a situation, but SSDs specified for use in storage systems might be much = better suited for that kind of usage profile. >>> We knew they had some speed issues, but those speed issues, we though= t (as >>> Samsung explains in the QVO site) they started after exceeding the sp= eeding >>> buffer this disks have. We though that meanwhile you didn't exceed it= 's >>> capacity (the capacity of the speeding buffer) no speed problem arise= s. Perhaps >>> we were wrong?. >> >> These drives are meant for small loads in a typical PC use case, >> i.e. some installations of software in the few GB range, else only >> files of a few MB being written, perhaps an import of media files >> that range from tens to a few hundred MB at a time, but less often >> than once a day. >> =C2=A0 >> *We move, you know... lots of little files... and lot's of different >> concurrent modifications by 1500-2000 concurrent imap connections we h= ave...* I do not expect the read load to be a problem (except possibly when the S= SD is moving data from SLC to QLC blocks, but even then reads will get priority= ). But writes and trims might very well overwhelm the SSD, especially when its g= etting full. Keeping a part of the SSD unused (excluded from the partitions crea= ted) will lead to a large pool of unused blocks. This will reduce the write amplification - there are many free blocks in the "unpartitioned part" of= the SSD, and thus there is less urgency to compact partially filled blocks. (= E.g. if you include only 3/4 of the SSD capacity in a partition used for the Z= POOL, then 1/4 of each erase block could be free due to deletions/TRIM without = any compactions required to hold all this data.) Keeping a significant percentage of the SSD unallocated is a good strateg= y to improve its performance and resilience. >> As the SSD fills, the space available for the single level write >> cache gets smaller >> =C2=A0 >> *The single level write cache is the cache these ssd drivers have, for= >> compensating the speed issues they have due to using qlc memory?. Do y= ou >> refer to that?. Sorry I don't understand well this paragraph.* Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC c= ache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as 24 = GB of data in QLC mode. A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (600= GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells). Therefore, the fraction of the cells used as an SLC cache is reduced when= it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cells).= And with less SLC cells available for short term storage of data the probability of data being copied to QLC cells before the irrelevant messa= ges have been deleted is significantly increased. And that will again lead to= many more blocks with "holes" (deleted messages) in them, which then need to b= e copied possibly multiple times to compact them. >> (on many SSDs, I have no numbers for this >> particular device), and thus the amount of data that can be >> written at single cell speed shrinks as the SSD gets full. >> =C2=A0 >> >> >> I have just looked up the size of the SLC cache, it is specified >> to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB >> version, smaller models will have a smaller SLC cache). >> =C2=A0 >> *Assuming you were talking about the cache for compensating speed we >> previously commented, I should say these are the 870 QVO but the 8TB >> version. So they should have the biggest cache for compensating the sp= eed >> issues...* I have looked up the data: the larger versions of the 870 QVO have the sa= me SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB more = if there are enough free blocks. >> But after writing those few GB at a speed of some 500 MB/s (i.e. >> after 12 to 150 seconds), the drive will need several minutes to >> transfer those writes to the quad-level cells, and will operate >> at a fraction of the nominal performance during that time. >> (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the >> 2 TB model.) >> =C2=A0 >> *Well we are in the 8TB model. I think I have understood what you wrot= e in >> previous paragraph. You said they can be fast but not constantly, beca= use >> later they have to write all that to their perpetual storage from the = cache. >> And that's slow. Am I wrong?. Even in the 8TB model you think Stefan?.= * The controller in the SSD supports a given number of channels (e.g 4), ea= ch of which can access a Flash chip independently of the others. Small SSDs oft= en have less Flash chips than there are channels (and thus a lower throughpu= t, especially for writes), but the larger models often have more chips than channels and thus the performance is capped. In the case of the 870 QVO, the controller supports 8 channels, which all= ows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has only = 4 Flash chips and is thus limited to 80 MB/s in that situation, while the l= arger versions have 8, 16, or 32 chips. But due to the limited number of channe= ls, the write rate is limited to 160 MB/s even for the 8 TB model. If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in this= limit. >> *The main problem we are facing is that in some peak moments, when the= >> machine serves connections for all the instances it has, and only as s= aid in >> some peak moments... like the 09am or the 11am.... it seems the machin= e >> becomes slower... and like if the disks weren't able to serve all they= have >> to serve.... In these moments, no big files are moved... but as we hav= e >> 1800-2000 concurrent imap connections... normally they are doing each = one... >> little changes in their mailbox. Do you think perhaps this disks then = are >> not appropriate for this kind of usage?-* I'd guess that the drives get into a state in which they have to recycle = lots of partially free blocks (i.e. perform kind of a garbage collection) and = then three kinds of operations are competing with each other: 1. reads (generally prioritized) 2. writes (filling the SLC cache up to its maximum size) 3. compactions of partially filled blocks (required to make free blocks available for re-use) Writes can only proceed if there are sufficient free blocks, which on a f= illed SSD with partially filled erase blocks means that operations of type 3. n= eed to be performed with priority to not stall all writes. My assumption is that this is what you are observing under peak load. >> And cheap SSDs often have no RAM cache (not checked, but I'd be >> surprised if the QVO had one) and thus cannot keep bookkeeping date >> in such a cache, further limiting the performance under load. >> =C2=A0 >> *This brochure >> (https://semiconductor.samsung.com/resources/brochure/870_Series_Broch= ure.pdf >> and the datasheet >> https://semiconductor.samsung.com/resources/data-sheet/Samsung_SSD_870= _QVO_Data_Sheet_Rev1.1.pdf) >> sais if I have read properly, the 8TB drive has 8GB of ram?. I assume = that >> is what they call the turbo write cache?.* No, the turbo write cache consists of the cells used in SLC mode (which c= an be any cells, not only cells in a specific area of the flash chip). The RAM is needed for fast lookup of the position of data for reads and o= f free blocks for writes. There is no simple relation between SSD "block number" (in the sense of a= disk block on some track of a magnetic disk) and its storage location on the F= lash chip. If an existing "data block" (what would be a sector on a hard disk = drive) is overwritten, it is instead written at the end of an "open" erase block= , and a pointer from that "block number" to the location on the chip is stored = in an index. This index is written to Flash storage and could be read from it, = but it is much faster to have a RAM with these pointers that can be accessed independently of the Flash chips. This RAM is required for high transacti= on rates (especially random reads), but it does not really help speed up wri= tes. >> And the resilience (max. amount of data written over its lifetime) >> is also quite low - I hope those drives are used in some kind of >> RAID configuration. >> =C2=A0 >> *Yep we use raidz-2* Makes sense ... But you know that you multiply the amount of data written= due to the redundancy. If a single 8 KB block is written, for example, 3 * 8 KB will written if = you take the 2 redundant copies into account. >> The 870 QVO is specified for 370 full capacity >> writes, i.e. 370 TB for the 1 TB model. That's still a few hundred >> GB a day - but only if the write amplification stays in a reasonable >> range ... >> =C2=A0 >> *Well yes... 2880TB in our case....not bad.. isn't it?* I assume that 2880 TB is your total storage capacity? That's not too bad,= in fact. ;-) This would be 360 * 8 TB ... Even at 160 MB/s per 8 TB SSD this would allow for more than 50 GB/s of w= rite throughput (if all writes were evenly distributed). Taking all odds into account, I'd guess that at least 10 GB/s can be continuously written (if supported by the CPUs and controllers). But this may not be true if the drive is simultaneously reading, trimming= , and writing ... I have seen advice to not use compression in a high load scenario in some= other reply. I tend to disagree: Since you seem to be limited when the SLC cache is exhausted, you should get better performance if you compress your data. I= have found that zstd-2 works well for me (giving a significant overall reducti= on of size at reasonable additional CPU load). Since ZFS allows to switch compressions algorithms at any time, you can experiment with different algorithms and levels. One advantage of ZFS compression is that it applies to the ARC, too. And = a compression factor of 2 should easily be achieved when storing mail (not = for =2Edocx, .pdf, .jpg files though). Having more data in the ARC will reduc= e the read pressure on the SSDs and will give them more cycles for garbage collections (which are performed in the background and required to always= have a sufficient reserve of free flash blocks for writes). I'd give it a try - and if it reduces your storage requirements by 10% on= ly, then keep 10% of each SSD unused (not assigned to any partition). That wi= ll greatly improve the resilience of your SSDs, reduce the write-amplificati= on, will allow the SLC cache to stay at its large value, and may make a large= difference to the effective performance under high load. Regards, STefan ** --------------ASZf2V7VPlu8lceG03SodTv5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Am 06.04.22 um 18:34 schrieb egoitz@ramattack.net:

Hi Stefan!

Thank you so much for your answer!!. I do answer below in green bold for instance... for a better distinction....

Very thankful for all your comments Stefan!!! :) :) :)

Cheers!!

Hi,

glad to hear that it is useful information - I'll add comments below ...

El 2022-04-06 17:43, Stefan Esser escribi=C3=B3:

ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.

Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net:
Hi Rainer!

Thank you so much for your help :) :)

Well I assume they are in a datacenter and should not be a power outage....

About dataset size... yes... our ones are big... they can be 3-4 TB easily each
dataset.....

We bought them, because as they are for mailboxes and mailboxes grow and
grow.... for having space for hosting them...

Which mailbox format (e.g. mbox, maildir, ...) do you use?
=C2=A0
I'm running Cyrus imap so sort of Maildir... too many little files normally..... Sometimes directories with tons of little files....

Assuming that many mails are much smaller than the erase block size of the SSD, this may cause issues. (You may know the following ...)

For example, if you have message sizes of 8 KB and an erase block size of 64 KB (just guessing), then 8 mails will be in an erase block. If half the mails are deleted, then the erase block will still occupy 64 KB, but only hold 32 KB of useful data (and the SSD will only be aware of this fact if TRIM has signaled which data is no longer relevant). The SSD will copy several partially filled erase blocks together in a smaller number of free blocks, which then are fully utilized. Later deletions will repeat this game, and your data will be copied multiple times until it has aged (and the user is less likely to delete further messages). This leads to "write amplification" - data is internally moved around and thus written multiple times.

Larger mails are less of an issue since they span multiple erase blocks, which will be completely freed when such a message is deleted.

Samsung has a lot of experience and generally good strategies to deal with such a situation, but SSDs specified for use in storage systems might be much better suited for that kind of usage profile.

We knew they had some speed issues, but those speed issues, we thought (as
Samsung explains in the QVO site) they started after exceeding the speeding
buffer this disks have. We though that meanwhile you didn't exceed it's
capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps
we were wrong?.

These drives are meant for small loads in a typical PC use case,
i.e. some installations of software in the few GB range, else only
files of a few MB being written, perhaps an import of media files
that range from tens to a few hundred MB at a time, but less often
than once a day.
=C2=A0
We move, you= know... lots of little files... and lot's of different concurrent modifications by 1500-2000 concurrent imap connections we have...

I do not expect the read load to be a problem (except possibly when the SSD is moving data from SLC to QLC blocks, but even then reads will get priority). But writes and trims might very well overwhelm the SSD, especially when its getting full. Keeping a part of the SSD unused (excluded from the partitions created) will lead to a large pool of unused blocks. This will reduce the write amplification - there are many free blocks in the "unpartitioned part" of the SSD, and thus there is less urgency to compact partially filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a partition used for the ZPOOL, then 1/4 of each erase block could be free due to deletions/TRIM without any compactions required to hold all this data.)

Keeping a significant percentage of the SSD unallocated is a good strategy to improve its performance and resilience.

As the SSD fills, the space available for the single level write
cache gets smaller
=C2=A0
The single level write cache is the cache these ssd drivers have, for compensating the speed issues they have due to using qlc memory?. Do you refer to that?. Sorry I don't understand well this paragraph.

Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as 24 GB of data in QLC mode.

A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (600 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells).

Therefore, the fraction of the cells used as an SLC cache is reduced when it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cells).

And with less SLC cells available for short term storage of data the probability of data being copied to QLC cells before the irrelevant messages have been deleted is significantly increased. And that will again lead to many more blocks with "holes" (deleted messages) in them, which then need to be copied possibly multiple times to compact them.

(on many SSDs, I have no numbers for this
particular device), and thus the amount of data that can be
written at single cell speed shrinks as the SSD gets full.
=C2=A0


I have just looked up the size of the SLC cache, it is specified
to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB
version, smaller models will have a smaller SLC cache).
=C2=A0
Assuming you= were talking about the cache for compensating speed we previously commented, I should say these are the 870 QVO but the 8TB version. So they should have the biggest cache for compensating the speed issues...

I have looked up the data: the larger versions of the 870 QVO have the same SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB more if there are enough free blocks.

But after writing those few GB at a speed of some 500 MB/s (i.e.
after 12 to 150 seconds), the drive will need several minutes to
transfer those writes to the quad-level cells, and will operate
at a fraction of the nominal performance during that time.
(QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the
2 TB model.)
=C2=A0
Well we are in the 8TB model. I think I have understood what you wrote in previous paragraph. You said they can be fast but not constantly, because later they have to write all that to their perpetual storage from the cache. And that's slow. Am I wrong?. Even in the 8TB model you think Stefan?.

The controller in the SSD supports a given number of channels (e.g 4), each of which can access a Flash chip independently of the others. Small SSDs often have less Flash chips than there are channels (and thus a lower throughput, especially for writes), but the larger models often have more chips than channels and thus the performance is capped.

In the case of the 870 QVO, the controller supports 8 channels, which allows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has only 4 Flash chips and is thus limited to 80 MB/s in that situation, while the larger versions have 8, 16, or 32 chips. But due to the limited number of channels, the write rate is limited to 160 MB/s even for the 8 TB model.

If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in this limit.

The main problem we are facing is that in some peak moments, when the machine serves connections for all the instances it has, and only as said in some peak moments... like the 09am or the 11am.... it seems the machine becomes slower... and like if the disks weren't able to serve all they have to serve.... In these moments, no big files are moved... but as we have 1800-2000 concurrent imap connections... normally they are doing each one... little changes in their mailbox. Do you think perhaps this disks then are not appropriate for this kind of usage?-<= /span>

I'd guess that the drives get into a state in which they have to recycle lots of partially free blocks (i.e. perform kind of a garbage collection) and then three kinds of operations are competing with each other:

  1. reads (generally prioritized)
  2. writes (filling the SLC cache up to its maximum size)
  3. compactions of partially filled blocks (required to make free blocks available for re-use)

Writes can only proceed if there are sufficient free blocks, which on a filled SSD with partially filled erase blocks means that operations of type 3. need to be performed with priority to not stall all writes.

My assumption is that this is what you are observing under peak load.

And cheap SSDs often have no RAM cache (not checked, but I'd be
surprised if the QVO had one) and thus cannot keep bookkeeping date
in such a cache, further limiting the performance under load.
=C2=A0
This brochur= e (= https://semiconductor.samsung.com/resources/brochure/870_Series_Brochure.= pdf and the datasheet https= ://semiconductor.samsung.com/resources/data-sheet/Samsung_SSD_870_QVO_Dat= a_Sheet_Rev1.1.pdf) sais if I have read properly, the 8TB drive has 8GB of ram?. I assume that is what they call the turbo write cache?.

No, the turbo write cache consists of the cells used in SLC mode (which can be any cells, not only cells in a specific area of the flash chip).

The RAM is needed for fast lookup of the position of data for reads and of free blocks for writes.

There is no simple relation between SSD "block number" (in the sense of a disk block on some track of a magnetic disk) and its storage location on the Flash chip. If an existing "data block" (what would be a sector on a hard disk drive) is overwritten, it is instead written at the end of an "open" erase block, and a pointer from that "block number" to the location on the chip is stored in an index. This index is written to Flash storage and could be read from it, but it is much faster to have a RAM with these pointers that can be accessed independently of the Flash chips. This RAM is required for high transaction rates (especially random reads), but it does not really help speed up writes.

And the resilience (max. amount of data written over its lifetime)
is also quite low - I hope those drives are used in some kind of
RAID configuration.
=C2=A0
Yep we use raidz-2

Makes sense ... But you know that you multiply the amount of data written due to the redundancy.

If a single 8 KB block is written, for example, 3 * 8 KB will written if you take the 2 redundant copies into account.

The 870 QVO is specified for 370 full capacity
writes, i.e. 370 TB for the 1 TB model. That's still a few hundred
GB a day - but only if the write amplification stays in a reasonable
range ...
=C2=A0
Well yes... 2880TB in our case....not bad.. isn't it?

I assume that 2880 TB is your total storage capacity? That's not too bad, in fact. ;-)

This would be 360 * 8 TB ...

Even at 160 MB/s per 8 TB SSD this would allow for more than 50 GB/s of write throughput (if all writes were evenly distributed).

Taking all odds into account, I'd guess that at least 10 GB/s can be continuously written (if supported by the CPUs and controllers).

But this may not be true if the drive is simultaneously reading, trimming, and writing ...


I have seen advice to not use compression in a high load scenario in some other reply.

I tend to disagree: Since you seem to be limited when the SLC cache is exhausted, you should get better performance if you compress your data. I have found that zstd-2 works well for me (giving a significant overall reduction of size at reasonable additional CPU load). Since ZFS allows to switch compressions algorithms at any time, you can experiment with different algorithms and levels.

One advantage of ZFS compression is that it applies to the ARC, too. And a compression factor of 2 should easily be achieved when storing mail (not for .docx, .pdf, .jpg files though). Having more data in the ARC will reduce the read pressure on the SSDs and will give them more cycles for garbage collections (which are performed in the background and required to always have a sufficient reserve of free flash blocks for writes).

I'd give it a try - and if it reduces your storage requirements by 10% only, then keep 10% of each SSD unused (not assigned to any partition). That will greatly improve the resilience of your SSDs, reduce the write-amplification, will allow the SLC cache to stay at its large value, and may make a large difference to the effective performance under high load.

Regards, STefan

--------------ASZf2V7VPlu8lceG03SodTv5-- --------------OGljiRSjG08yilMHhaNFyDtW-- --------------Lic1usorjc8S7FifC6L0nUmq Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJOCtsFAwAAAAAACgkQR+u171r99USt jAf+Jqn2i8WZUDjj7wNiYznxQzyyjhsmvUb2d7NygsZaC0lcdNuEpjkhWG+Cn7tc5mPuWkbP2nz0 HGpERxnAnf+6chQw6E/3ZXVKCBM+HdiVw1HpmnX91K5FiLecnPC8aD5VlFsrGg7LpTtKBLCwgwls ssSPRqJvI5wYZEsiGydp/nMcaJeruVOXpjwH7kUDy5HvANKOdtM3X2JJMxHbwPsqtbwo8nGAiE9r NaNLI9hO0Ljfud4rgCaHo0dWq9sD9zAKOvbmDbSGgQbgVXxgh2Oz+lVmfHfC6MMGcM57K1HJ+LnH QXhvEcKQif+HVq2LNpwkTRjJdY4a0ajeGSIFS5FXuA== =LAcb -----END PGP SIGNATURE----- --------------Lic1usorjc8S7FifC6L0nUmq-- From nobody Wed Apr 6 21:59:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 928531A82E25; Wed, 6 Apr 2022 21:59:54 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYdj63FN7z3GN9; Wed, 6 Apr 2022 21:59:54 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649282394; h=from:from:reply-to:subject:subject:date:date: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=xS37a09f2j+D6oXvbNy3JpSp355g06Zi0IFCWDhLayM=; b=codISLKMW2nW2y3AwW5BRK1iehmBlyuvYdeaV45nRx3GMHJmC4sceWUpcsJ+Zns+6Afwy5 s5wx3XGj9OIFWP1TdhEMbEBQ94UGRi3HBGA4B6QbqTZOJ210JlHKNxvG2a35h9FuNrCA10 xsGKmNE0XyRpflCnBt6oOtkus3oJTFYPQobA+Z35sogdsmyZboLBz8j8XWMzv9WdD2y4nq kL+hxgzidxJ+TXqxE4aVD492T8K6Cax9tUW7vMYIXmrR33UAbCMiTZlTBfBu1I8IKdvjHn lzpqtbtUQzI32m4mymNrmM5QEhbxV/1mh/DjK0uOLy6XmAaeAVfGZMPE5xdK6A== Received: from [IPV6:2003:cd:5f22:6f00:953e:7ee1:500e:87a1] (p200300cd5f226f00953e7ee1500e87a1.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:953e:7ee1:500e:87a1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9F8A35E79; Wed, 6 Apr 2022 21:59:52 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <0702dc56-28ba-7e99-d599-1036634d79e3@FreeBSD.org> Date: Wed, 6 Apr 2022 23:59:50 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: mike tancsa , Bob Friesenhahn , egoitz@ramattack.net Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------2AmGM1Q6OeFqsRTohjQ1sr1u" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649282394; h=from:from:reply-to:subject:subject:date:date: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=xS37a09f2j+D6oXvbNy3JpSp355g06Zi0IFCWDhLayM=; b=LG0qHNBBEyPUrLC60qVGeR9xgTyLM5oZFNXhLwMLBBaRPMu69owI+TFY1SLZAQA+fKffIw Ap0T6ghK7ux71ilX8YdGf3JJJXQIxFHcUg57naKbEahuMjvJIyn/QJjlkdpfaLrJOnAvAY +Puxtjkjf5qsVCc/B8kruuj1F9auIA6BGnWMWK4R8eMD7bnENKrLwdtgen9Cn3yfT7Wf0Q ocAwgNhSQcQX2hVPSCfVMkslG+FoArobAVf+h4n605/Hos15KBw6k2f8bYnncNhrKR1clJ 4CAbni3TBA0HwoGgNe5jvSwAg7QjkFB39EXY1OHN92k11DrcTO/rGWM5mrXttw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649282394; a=rsa-sha256; cv=none; b=lc/d+Wp/isGygaYGCYvCBC5sW1+xGOXpnqBgsIIz8g3DE8mMdvkZXn42D4kKR8k5lBH+E5 qUoRfRm5H963+2IunYSSl12gbgpopEe409ATzxTktT7W3shhY5cfy+598s6S5tXahWI948 vi0Py1nJLg5OwaT/Dw1iRM9En3Vd7+fdfZH94d3mftlfszzC5NQkmfZrKjyBSt64MWfLC8 6xKUQpfKBhU6LGXOLZz9NCo/ebgFjjjE/RLQSnVtH6qqxfT00obfsnm+iPT+91ivxUkUgF s8GCA0Kcs90NNQG31zGDSxWEBPw896Yfcyx824EMvtFhYVYuoFzarg9G0U0QBg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------2AmGM1Q6OeFqsRTohjQ1sr1u Content-Type: multipart/mixed; boundary="------------lhrXooAciDl05L70ht5xs4WV"; protected-headers="v1" From: Stefan Esser To: mike tancsa , Bob Friesenhahn , egoitz@ramattack.net Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org, Freebsd performance Message-ID: <0702dc56-28ba-7e99-d599-1036634d79e3@FreeBSD.org> Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> In-Reply-To: --------------lhrXooAciDl05L70ht5xs4WV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.04.22 um 22:43 schrieb mike tancsa: > On 4/6/2022 4:18 PM, Bob Friesenhahn wrote: >> On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: >>>> >>>> WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY= YOU >>>> SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA >>>> COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND= >>>> FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS = OF >>>> HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... >> >> There seems to be a problem with your caps-lock key. >> >> Since it seems that you said that you are using maildir for your mail = server, >> it is likely very useful if you do enable even rather mild compression= (e.g. >> lz4) since this will reduce the write work-load and even short files w= ill be >> stored more efficiently. >> > FYI, a couple of our big zfs=C2=A0 mailspools sees a 1.24x and 1.23x co= mpress ratio > with lz4.=C2=A0 We use Maildir format as well.=C2=A0 They are not RELEN= G_13 so not sure > how zstd would fair. I have got much better compression at same or less load by use of zstd-2 compared to lz4. Perhaps not typical, since this is a dovecot mdbox formatted mail pool holding mostly plain text messages without large attachments: $ df /var/mdbox Filesystem 1K-blocks Used Avail Capacity Mounted on system/var/mdbox 7234048944 9170888 7224878056 0% /var/mdbox $ zfs get compression,compressratio,used,logicalused system/var/mdbox NAME PROPERTY VALUE SOURCE system/var/mdbox compression zstd-2 inherited from system/va= r system/var/mdbox compressratio 2.29x - system/var/mdbox used 8.76G - system/var/mdbox logicalused 20.0G - Regards, STefan --------------lhrXooAciDl05L70ht5xs4WV-- --------------2AmGM1Q6OeFqsRTohjQ1sr1u Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJODVYFAwAAAAAACgkQR+u171r99UQH 3ggAjrm6XN5FfQ0OjamthevN4N2u/LyQAdJtTxB2Ta2BHBMDSrH969d/Ed7zHbpATNmtiGCDEVGS 5P93HzFDeE9dZRIp2yvIPOKhm1xuNlaK6anw31yMOhuTs+HkFZrW85/lqtkUyJgga82We9r7yTl7 JWsuLlNrBR6PmVLyi4GztB7wEF9JOd4oTCIye+001uP8OHtto4h5mX5APubPEaqZKk0mTCenfptZ ZVG+9q8xVj04jRp2Gia87XeODZ/Cvx1KsGzz5r+o2QBPxGKyO8Y7AaHWrRiJT4Rj6HW8T4F2ooNn x7rBKOwEUvnIQqDu7Pz8fQtIMVdv2Atc+SizWpARRA== =YgKS -----END PGP SIGNATURE----- --------------2AmGM1Q6OeFqsRTohjQ1sr1u-- From nobody Thu Apr 7 07:59:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 05C4C1A97DC7; Thu, 7 Apr 2022 07:59:35 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYv126R78z3KyW; Thu, 7 Apr 2022 07:59:34 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649318375; h=from:from:reply-to:subject:subject:date:date: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=m2HUVrbEq7o9ase+zDUCti07l48rJ+nU2EpdAQMDQ38=; b=NMnF19bzpHf2nHHVB1YxAjcApV7iALDxLIvW6idngan6XSg0GeYmvFdpcwm2/zvQ/+Ga4J 7ek0Evu1q19J1y6m+FT/veoZWm7xFnz6pm8EKkXfay5gVNWeCpyihq0zFetyPVKrEXXYR8 yHcEibj27FCtdbcevPD3Huzq+9UgVKon1u8uPyO8MCPaqO52ZV5LU72ERviW6LSs80ewxK eYIs9tydKw1vh2ZQY/fd8lGOv4pJXhIThInO1WiOFFXkK60CWjIuLkJ9Vqh9KQYrWVbkBx Jel3ssLOEUyAw+tVxjCASoU6//o3kZdel7elQKdv7Ei/vNs+k/mySkoWbINFMQ== Received: from [IPV6:2003:cd:5f22:6f00:34ed:cacb:3b28:daf] (p200300cd5f226f0034edcacb3b280daf.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:34ed:cacb:3b28:daf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id D6D7EA066; Thu, 7 Apr 2022 07:59:33 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <49f43af5-e145-c793-959d-ab1596421d81@FreeBSD.org> Date: Thu, 7 Apr 2022 09:59:27 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: egoitz@ramattack.net References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> From: Stefan Esser Cc: Jan Bramkamp , performance@freebsd.org, "freebsd-fs@freebsd.org" , FreeBSD Hackers In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------o4K5Sngmd3lLPnmlzLRzMtEK" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649318374; h=from:from:reply-to:subject:subject:date:date: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=m2HUVrbEq7o9ase+zDUCti07l48rJ+nU2EpdAQMDQ38=; b=IWML0cH5d0UJDKTcEQqANYFGYOX7ABIcJAQ+YDeHZ4QAbaUZSpBJrCNxrZZsrvCAkwnMTY K74KzXtXJVTxHPp78gm2hLlPomWFSHeFMV3VJPRXJ+PFFuX4SA+nhQcOh28iO9JCM7hyJX PLLdH0kXGvvIq2o0ovvwQ0Liy7kQTp0BKz19FyYcMsGRzHAg7kzduV535q1Pw7JFIHoR2T IYbeGPMhAXrLbNSZyxLz6AKgw95LS8srBqWqkSKFmlr22ZpoEjXdnYCUy2EnPz/7WON5RX RxN3OqalkAJKygy71QOovZXkBhNZUej5Mwz4dAaEzOaAOJDe5HgTWrD17kqW+Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649318374; a=rsa-sha256; cv=none; b=rApmUo+lAfX/P6o4SLQ68AGoD/Sx5BGrWCkFyCWD0/bXXVIBQWGs+Pi6shFlSIB6ZB5gIj ElK74KW/VSc62QR/K6s27Ji9I9iZy36zaE+AviLY5VURhHI0tyjl2jAF/AjsHaQQj0zqoh qNk++uhsi7umP6jnoQXI0DIXi8k98Jx48smYnExyveQfodOG60etpx2AgF/fT50iwOCtVQ bYbSc2Q5JFOBf4CRadmSUa8EMDNTVBnWlrJK6FGjN6mzMkisWg+s+N+S7z0ZK+jxMyXyAH NDvOmGPsf+5g3aWQz7Y5dNLIGe8PsGQ1Yx4n6FftSPBRddbI0b5akns9ejNw3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------o4K5Sngmd3lLPnmlzLRzMtEK Content-Type: multipart/mixed; boundary="------------ce4Isv9Wdp6yhBkTY0YsttW0"; protected-headers="v1" From: Stefan Esser To: egoitz@ramattack.net Cc: Jan Bramkamp , performance@freebsd.org, "freebsd-fs@freebsd.org" , FreeBSD Hackers Message-ID: <49f43af5-e145-c793-959d-ab1596421d81@FreeBSD.org> Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> In-Reply-To: --------------ce4Isv9Wdp6yhBkTY0YsttW0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.04.22 um 23:19 schrieb Jan Bramkamp: > On 06.04.22 22:43, mike tancsa wrote: >> On 4/6/2022 4:18 PM, Bob Friesenhahn wrote: >>> On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: >>>>> >>>>> WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SA= Y YOU >>>>> SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA >>>>> COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AN= D >>>>> FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS= OF >>>>> HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... >>> >>> There seems to be a problem with your caps-lock key. >>> >>> Since it seems that you said that you are using maildir for your mail= >>> server, it is likely very useful if you do enable even rather mild >>> compression (e.g. lz4) since this will reduce the write work-load and= even >>> short files will be stored more efficiently. >>> >> FYI, a couple of our big zfs=C2=A0 mailspools sees a 1.24x and 1.23x c= ompress >> ratio with lz4.=C2=A0 We use Maildir format as well.=C2=A0 They are no= t RELENG_13 so >> not sure how zstd would fair. > I've found that Dovecot's mdbox format compresses a lot better than Mai= ldir (or > sdbox), because it stores multiple messages per file resulting in files= large > enough to contain enough exploitable reduncancy to compress down to the= next > smaller blocksize. In a corporate or education environment where users = tend to > send the same medium to large attachments multiple times to multiple re= cipients > on the same server Dovecot's single instance storage is a game changer.= It > reduced my IMAP storage requirements by a *factor* of 4.7 which allowed= me to > get rid of spinning disks for the mail servers instead of playing losin= g games > with hybrid storage. Dovecot also supports zlib compression in the appl= ication > instead of punting it to the file system. I don't know if Cyrus IMAP of= fers > similar features, but if it does I would recommend evaluating them inst= ead of > compressing or deduplicating at the file system level. I have not compared dovecot's zlib compression with zstd-2 on the file sy= stem, but since I use the latter on all my ZFS file systems (excepts those that= exclusively hold compressed files and media), I'm using it for Dovecot md= box files, too. I get a compression ratio of 2,29 with ZFS zstd-2, maybe I sh= ould copy the files over into a zlib compressed mdbox for comparison ... One large advantage of the mdbox format in the context of the mail server= set-up at the start of this thread is that deletions are only registered = in an index file (while mbox needs a rewrite of potentially large parts of t= he mail folder and mdir immediately deletes files (TRIM) and updates inodes = and directory entries, causing multiple writes per deleted message). With mdbox you can delay all "expensive" file system operations to the point of least load each day, for example. Such a compression run is also= well suited for SSDs, since it does not perform random updates that punch= holes in a large number of erase blocks (which then will need to be garba= ge collected, causing write amplification to put further load and stress on the SSD). --------------ce4Isv9Wdp6yhBkTY0YsttW0-- --------------o4K5Sngmd3lLPnmlzLRzMtEK Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJOmd8FAwAAAAAACgkQR+u171r99UQz fQgAj/0scy7zAbl1SoRPExnKQSTSk320RX81cVGflFCk2hDHRKeF9bScO22aZil0nYKaCKPR1Mps kyujxrmFpTgWjrjhNe7noHe5sz3LlGplXB7YNMKr0eujF1VC9YrlSvQLGTDFJeJyIRcI7EjSAgoy 8aLZjMG8rI7XCiMo1y+bpJqyWsElxYFoiomi2h2fkZ5MFZtWfyqPNaCFd2e4YHW6x6WYS9/H9ZDc k3E6GoFUaoRIuHC5dw2HbeUxBr72TYRLZgSH5pMBlk0cN60QNHkOBiBahbyzPVA/U1IJqCSVTWJP 7ZUNURO6nTn71io0o148Jho31IitSdxA4cuaJOOIVg== =DqKu -----END PGP SIGNATURE----- --------------o4K5Sngmd3lLPnmlzLRzMtEK-- From nobody Thu Apr 7 08:49:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 388251AA426B; Thu, 7 Apr 2022 08:49:21 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYw6R6nMZz3k6B; Thu, 7 Apr 2022 08:49:19 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id DADEA60C641; Thu, 7 Apr 2022 10:49:15 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_85ed0b4a49488ec1a940cb1f7fed0376" Date: Thu, 07 Apr 2022 10:49:15 +0200 From: egoitz@ramattack.net To: Eugene Grosbein Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Message-ID: <55000f00fb64510e8ef6b8ad858d8855@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYw6R6nMZz3k6B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_85ed0b4a49488ec1a940cb1f7fed0376 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Good morning Eugene!! Thank you so much for your help mate :) :) really :) :) Ok I take good notes of all you have replied me below :) :) Very very thankful for your help really :) Cheers, El 2022-04-06 20:10, Eugene Grosbein escribiĂł: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > 06.04.2022 23:51, egoitz@ramattack.net wrote: > >> About your recommendations... Eugene, if some of them wouldn't be working as expected, >> could we revert some or all of them > > Yes, it all can be reverted. > Just write down original sysctl values if you are going to change it. > >> 1) Make sure the pool has enough free space because ZFS can became crawling slow otherwise. >> >> *This is just an example... but you can see all similarly....* >> >> *zpool list* >> *NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT* >> *zroot 448G 2.27G 446G - - 1% 0% 1.00x ONLINE -* >> *mail_dataset 58.2T 19.4T 38.8T - - 32% 33% 1.00x ONLINE -* > > It's all right. > >> 2) Increase recordsize upto 1MB for file systems located in the pool >> so ZFS is allowed to use bigger request sizes for read/write operations >> >> *We have the default... so 128K...* > > It will not hurt increasing it upto 1MB. > >> 5) If you have good power supply and stable (non-crashing) OS, try increasing >> sysctl vfs.zfs.txg.timeout from defaule 5sec, but do not be extreme (f.e. upto 10sec). >> Maybe it will increase amount of long writes and decrease amount of short writes, that is good. >> >> *Well I have sync in disabled in the datasets... do you still think it's good to change it? > > Yes, try it. Disabling sync makes sense if you have lots of fsync() operations > but other small writes are not affected unless you raise vfs.zfs.txg.timeout > >> *What about the vfs.zfs.dirty_data_max and the vfs.zfs.dirty_data_max_max, would you increase them from 4GB it's set now?.* > > Never tried that and cannot tell. --=_85ed0b4a49488ec1a940cb1f7fed0376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Good morning Eugene!!


Thank you so much for your help mate :) :) really :) :)


Ok I take good notes of all you have replied me below :) :)


Very very thankful for your help really :)


Cheers,

 


El 2022-04-06 20:10, Eugene Grosbein escribió:

= ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde f= uera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no= ser que reconozca el remitente y sepa que el contenido es seguro.
06.04.2022 23:51, egoitz@ramat= tack.net wrote:

About your recommendations... Eugene, if some of them = wouldn't be working as expected,
could we revert some or all of them<= /blockquote>
Yes, it all can be reverted.
Just write down original sysctl v= alues if you are going to change it.

1) Make sure the pool has enough free space because ZF= S can became crawling slow otherwise.
 
*This is just an e= xample... but you can see all similarly....*
 
*zpool list= *
*NAME           &= nbsp; SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ &= nbsp; FRAG    CAP  DEDUP  HEALTH  ALTROO= T*
*zroot           = ;  448G  2.27G   446G     &nbs= p;  -         -  &nb= sp;  1%     0%  1.00x  ONLINE  = ;-*
*mail_dataset  58.2T  19.4T  38.8T   &nb= sp;    -        &nbs= p;-    32%    33%  1.00x  ONLINE &n= bsp;-*

It's all right.

2) Increase recordsize upto 1MB for file systems locat= ed in the pool
so ZFS is allowed to use bigger request sizes for read= /write operations
 
*We have the default... so 128K...*
It will not hurt increasing it upto 1MB.

5) If you have good power supply and stable (non-crash= ing) OS, try increasing
sysctl vfs.zfs.txg.timeout from defaule 5sec,= but do not be extreme (f.e. upto 10sec).
Maybe it will increase amou= nt of long writes and decrease amount of short writes, that is good.
=  
*Well I have sync in disabled in the datasets... do you still = think it's good to change it?

Yes, try it. Disabling sync makes sense if you have lots of fsync() = operations
but other small writes are not affected unless you raise v= fs.zfs.txg.timeout

*What about the vfs.zfs.dirty_data_max and the vfs.zfs= =2Edirty_data_max_max, would you increase them from 4GB it's set now?.*
Never tried that and cannot tell.
--=_85ed0b4a49488ec1a940cb1f7fed0376-- From nobody Thu Apr 7 08:56:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C741A1AA6C09; Thu, 7 Apr 2022 08:56:30 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYwGj2cvcz3mnC; Thu, 7 Apr 2022 08:56:28 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 6808A60C149; Thu, 7 Apr 2022 10:56:26 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_d38b5728c4674c13e58315ae3b5e7d2c" Date: Thu, 07 Apr 2022 10:56:26 +0200 From: egoitz@ramattack.net To: Bob Friesenhahn Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance , owner-freebsd-fs@freebsd.org Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYwGj2cvcz3mnC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_d38b5728c4674c13e58315ae3b5e7d2c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Bob! Thank you so much really for your comments :) :) Wow! I wouldn't have wanted to write in capital letters.... I would have sworn not to have done.... Apologies for that really ..... Note taking mate. We didn't changed almost nothing than the sync param, for avoid modifying the most we could the default config of ZFS. We thought it could perhaps be the most stable config and we have not disk space problems so... Apart of that, for avoid load coming from compression/decompression.... although we have lots of cpu too..... Thanks a lot Bob :) Cheers, El 2022-04-06 22:18, Bob Friesenhahn escribiĂł: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: > WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... There seems to be a problem with your caps-lock key. Since it seems that you said that you are using maildir for your mail server, it is likely very useful if you do enable even rather mild compression (e.g. lz4) since this will reduce the write work-load and even short files will be stored more efficiently. Bob --=_d38b5728c4674c13e58315ae3b5e7d2c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Bob!


Thank you so much really for your comments :) :)


Wow! I wouldn't have wanted to write in capital letters.... I would have= sworn not to have done.... Apologies for that really .....


Note taking mate. We didn't changed almost nothing than the sync param, = for avoid modifying the most we could the default config of ZFS. We thought= it could perhaps be the most stable config and we have not disk space prob= lems so... Apart of that, for avoid load coming from compression/decompress= ion.... although we have lots of cpu too.....


Thanks a lot Bob :)


Cheers,

 


El 2022-04-06 22:18, Bob Friesenhahn escribió:

= ATENCION
ATENCION
ATENCION= !!! Este correo se ha enviado desde fuer= a de la organizacion. No pinche en los&n= bsp;enlaces ni abra los adjuntos a no se= r que reconozca el remitente y sepa que&= nbsp;el contenido es seguro.

On Wed, 6 Apr 2022, egoitz@ramattack.net wrote:

WE DO= N'T USE COMPRESSION AS IT'S NOT SET BY&n= bsp;DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE&= nbsp;IT ENABLED.... BUT.... JUST FOR AVOID HA= VING SOME DATA COMPRESSED SOME OTHER NOT = ;(IN CASE YOU ENABLE AND LATER DISABLE) = AND FINALLY FOR AVOID ACCESSING TO INFORMATIO= N WITH DIFFERENT CPU COSTS OF HANDLING...&nbs= p;WE HAVE NOT TOUCHED COMPRESSION....

There seems to b= e a problem with your caps-lock key.
Since it seems that you said that you are using maildir for you= r mail server, it is likely very useful if you do enable even rather mild c= ompression (e.g. lz4) since this will reduce the write work-load and even s= hort files will be stored more efficiently.

Bob
--=_d38b5728c4674c13e58315ae3b5e7d2c-- From nobody Thu Apr 7 08:59:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 901611A80E64; Thu, 7 Apr 2022 08:59:53 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYwLc4b9Kz3pb3; Thu, 7 Apr 2022 08:59:52 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id A23F660C6A9; Thu, 7 Apr 2022 10:59:50 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_c2807b764a57b09883b960b84ffbc8e7" Date: Thu, 07 Apr 2022 10:59:50 +0200 From: egoitz@ramattack.net To: mike tancsa Cc: Bob Friesenhahn , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Message-ID: <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYwLc4b9Kz3pb3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_c2807b764a57b09883b960b84ffbc8e7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Mike! Thanks a lot for your comment. I see. As said before, we didn't really enable compression because we just keep the config as FreeBSD leaves by default. Apart from that, having tons of disk space and well... for avoiding the load of compress/decompress... The main reason was it was not enabled by default really and not to have seen a real reason for it.... was not more than that.... I appreciate your comments really :) Cheers, El 2022-04-06 22:43, mike tancsa escribiĂł: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > On 4/6/2022 4:18 PM, Bob Friesenhahn wrote: On Wed, 6 Apr 2022, egoitz@ramattack.net wrote: > WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... There seems to be a problem with your caps-lock key. Since it seems that you said that you are using maildir for your mail server, it is likely very useful if you do enable even rather mild compression (e.g. lz4) since this will reduce the write work-load and even short files will be stored more efficiently. FYI, a couple of our big zfs mailspools sees a 1.24x and 1.23x compress ratio with lz4. We use Maildir format as well. They are not RELENG_13 so not sure how zstd would fair. ---Mike --=_c2807b764a57b09883b960b84ffbc8e7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Mike!


Thanks a lot for your comment. I see. As said before, we didn't really e= nable compression because we just keep the config as FreeBSD leaves by defa= ult. Apart from that, having tons of disk space and well... for avoiding th= e load of compress/decompress... The main reason was it was not enabled by = default really and not to have seen a real reason for it.... was not more t= han that....


I appreciate your comments really :)


Cheers,

 


El 2022-04-06 22:43, mike tancsa escribió:

= ATENCION
ATENCION
ATENCION= !!! Este correo se ha enviado desde fuer= a de la organizacion. No pinche en los&n= bsp;enlaces ni abra los adjuntos a no se= r que reconozca el remitente y sepa que&= nbsp;el contenido es seguro.

On 4/6/2022 4:18 PM, Bob = ;Friesenhahn wrote:
On Wed, = ;6 Apr 2022, egoitz@= ramattack.net wrote:

WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEF= AULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID= HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER D= ISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU C= OSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION....

There seems to b= e a problem with your caps-lock key.
Since it seems that you said that you are using maildir for you= r mail server, it is likely very useful if you do enable even rather mild c= ompression (e.g. lz4) since this will reduce the write work-load and even s= hort files will be stored more efficiently.
FYI, a couple of our big zfs  mailspools sees a 1.24x and 1.23x compre= ss ratio with lz4.  We use Maildir format as well.  They are not = RELENG_13 so not sure how zstd would fair.

    ---Mike

--=_c2807b764a57b09883b960b84ffbc8e7-- From nobody Thu Apr 7 10:05:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6937A1A9104B; Thu, 7 Apr 2022 10:05:46 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYxpf1mgPz4VgL; Thu, 7 Apr 2022 10:05:46 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649325946; h=from:from:reply-to:subject:subject:date:date: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=5VyYb2yVup9mr10ClzHwP1P7qCT1D6ac9qjMWMQpYPk=; b=J9AwR7QGgnmSa3A7RyFhNZlz+Dxw2twvndSx8IPIRNsDTVooRRHtoZ7h1+gMQOh0VEb9r1 lV84OzxPP0ykzqwJsFRlsPDVTItjJQK0q1yLpWMK6p1bKkkEgFNLQ81K4P3LUFIiMClYvp +/fme73HUjV1rrWZqai8D1vqbGTfryPa3J+UdAaiwDx2440i0uBtb1g8RxtGbOAoiU42ro q7ZvA62+gwZ2bF8X3LMFFE5pLaKmQi4cDzfATAkWsjMEO74+N7QG0rU1Oj/s8S0YRkWj/M 7G5MkwcilTG0mFsIJx1CbCU/lCrqqNotRBGp2lagrbX7F6pW1AlyW0DViyMAKQ== Received: from [IPV6:2003:cd:5f22:6f00:34ed:cacb:3b28:daf] (p200300cd5f226f0034edcacb3b280daf.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:34ed:cacb:3b28:daf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 57989B868; Thu, 7 Apr 2022 10:05:45 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> Date: Thu, 7 Apr 2022 12:05:42 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS Content-Language: en-US From: Stefan Esser To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------R8ub0be6TPBsoV0UvSwjPqsv" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649325946; h=from:from:reply-to:subject:subject:date:date: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=5VyYb2yVup9mr10ClzHwP1P7qCT1D6ac9qjMWMQpYPk=; b=RWVkDqf8CQrXjJevQVFL0cShsK6iSZaO1jgE2Bi17Mnlp9ugcTH7ulNWb7xwGAtQUp37P7 w3iX6N9imCTlq1qr1VW74CVMGcRRhHJMty/o6myH3BBue0yalPYyhPeo8tZPooYkkYXV92 TMnvXkls2R8OOcsMCvywiIn1ZKIihEhBaZn1db4MLOUe05VMrCvPXgyBsgE6hrtxLVcJzL jK0v5ylRXmKuP9f2iFcfPVYjbyReNcRsCRifFXziero9bJLodjprmIBgBGhRe0KrQqckia cJgbD/ILyDZGJFRbK9NP8Je+Yy5abeS1DhYGSR8qPgD361vy44hLJEqC8qSOWQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649325946; a=rsa-sha256; cv=none; b=lPlxEMv0z3Ynd/DOBaq3/QIOwZxMQwY6ptua//2UhvaqXxm++Pu4qtZzIYesl0IM0/C9t6 X0vcIGvQVRC0QYFKC1MXPnLTiLaIy8o2CwyLOMqALay/wYBwKj1aa4jTYKPiD5DUNNOMdP 9NbMeoWpU4VjsfaJy4iEk45Rtmv1ndzwr/jp6AcGne1bY8ELaAloPZ+yLTAqK77r+k1TeF hmmTFElyuRL7pk/YgQGpin+ZczqnQeqyCn4TnpR9XxB2afGIP70VXOR/O8tA58kVN96Hda pWpqinjZuhwvX1miJwCsFB6wwdC4vk8QSdFbW0ivMT3aEKdZznYQtV/d63+s9A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------R8ub0be6TPBsoV0UvSwjPqsv Content-Type: multipart/mixed; boundary="------------MH3UBEk8xxTm08glzsqFwYDD"; protected-headers="v1" From: Stefan Esser To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Message-ID: <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> Subject: Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> In-Reply-To: --------------MH3UBEk8xxTm08glzsqFwYDD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.04.22 um 23:49 schrieb Stefan Esser: > Am 06.04.22 um 18:34 schrieb egoitz@ramattack.net: >=20 >>> The 870 QVO is specified for 370 full capacity >>> writes, i.e. 370 TB for the 1 TB model. That's still a few hundred >>> GB a day - but only if the write amplification stays in a reasonable >>> range ... >>> =C2=A0 >>> *Well yes... 2880TB in our case....not bad.. isn't it?* >=20 > I assume that 2880 TB is your total storage capacity? That's not too ba= d, in > fact. ;-) I just noticed that this is not the extreme total size of a ZFS pool (should have noticed this while answering late at night ...) And no, a specified life-time of 2880 TB written is not much, it is at the absolute lower end of currently available SSDs at 360 TB per 1 TB of capacity. This is equivalent to 360 total capacity writes, but given the high amount of write amplification that can be assumed to occur in your use case, I'd heavily over-provision a system with such SSDs ... (or rather: strictly avoid them in a non-consumer setting). --------------MH3UBEk8xxTm08glzsqFwYDD-- --------------R8ub0be6TPBsoV0UvSwjPqsv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJOt3YFAwAAAAAACgkQR+u171r99USG 4AgAqvLdjcqRhYzJHDNPIR+8TN0JKwMia2AI7dwFi/edSRFtjP50d/sbgxhP7xkf6a13LuLypubc UK2ldNCHlczP/9m5+uG2MTb9E24Pc1bpX4o459oFzx7MGRyRksMmMKnNyidiVIx4W/ihfZa0b/5K ICbgTmE79RIc3tX8cn77Kp8W8asjABCE2vgqTLtyJpfuhBSg60flkjMAOoBwsyXDNKvEDWWuR3zU U4kxS00DZ2Cb8EHMmi5yiyH+GqoJWRH55BYl0bw3ppDubbQuEZWJojcMZ2eWFJYcC29LkYvCUDrc YgesfZGPQ9eTk1cbKq01ZOCk4zOsgt2PcmFla759oQ== =GJ82 -----END PGP SIGNATURE----- --------------R8ub0be6TPBsoV0UvSwjPqsv-- From nobody Thu Apr 7 11:25:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1DE191A86A2A; Thu, 7 Apr 2022 11:25:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYzb31Xn5z4mwN; Thu, 7 Apr 2022 11:25:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 237BPnGI010096 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Apr 2022 07:25:49 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:434:73cd:9d42:28ad] ([IPv6:2607:f3e0:0:4:434:73cd:9d42:28ad]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 237BPlhB073256 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 7 Apr 2022 07:25:48 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Thu, 7 Apr 2022 07:25:47 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS Content-Language: en-US To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> From: mike tancsa In-Reply-To: <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4KYzb31Xn5z4mwN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-2.75 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.35)[-0.349]; FREEFALL_USER(0.00)[mike]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received] X-ThisMailContainsUnwantedMimeParts: N On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: > > Hi Mike! > > Thanks a lot for your comment. I see. As said before, we didn't really > enable compression because we just keep the config as FreeBSD leaves > by default. Apart from that, having tons of disk space and well... for > avoiding the load of compress/decompress... The main reason was it was > not enabled by default really and not to have seen a real reason for > it.... was not more than that....I appreciate your comments really :) Hi,     With respect to compression, I think there is a sweet spot somewhere, where compression makes things faster if your disk IO is the limiting factor and you have spare CPU capacity.  I have a separate 13.x zfs server with ztsd enabled and I get compression rations of 15:1 as it stores a lot of giant JSON txt files. Think of the extreme case where you do something like dd if=/dev/zero of=/tank/junk.bin bs=1m count=10000 as this is a 20G file that takes just a few hundred bytes of write IO on a compressed system. Obviously, as the compress ratio reduces in the real world the benefits become less.  Where that diminishing return is, not sure.  But something to keep in mind     ---Mike From nobody Thu Apr 7 12:30:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 679491A9AAC5; Thu, 7 Apr 2022 12:31:00 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ12B28vFz3M2k; Thu, 7 Apr 2022 12:30:57 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id 35B5A60C4C4; Thu, 7 Apr 2022 14:30:48 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_ccf36dab3b44229808a0a46435736314" Date: Thu, 07 Apr 2022 14:30:47 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ12B28vFz3M2k X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_ccf36dab3b44229808a0a46435736314 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Stefan, An extremely interesting answer and email. Extremely thankful for all your deep explatanations...... They are like gold for us really.... I answer below and in blue bold for better distinction between your lines and mine ones... El 2022-04-06 23:49, Stefan Esser escribió: > ATENCION: Este correo se ha enviado desde fuera de la organización. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Am 06.04.22 um 18:34 schrieb egoitz@ramattack.net: > >> Hi Stefan! >> >> Thank you so much for your answer!!. I do answer below in green bold for instance... for a better distinction.... >> >> Very thankful for all your comments Stefan!!! :) :) :) >> >> Cheers!! > > Hi, > > glad to hear that it is useful information - I'll add comments below ... > > EXTREMELY HELPFUL INFORMATION REALLY! THANK YOU SO MUCH STEFFAN REALLY. VERY VERY THANKFUL FOR YOUR NICE HELP!. > > El 2022-04-06 17:43, Stefan Esser escribió: > > Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: Hi Rainer! > > Thank you so much for your help :) :) > > Well I assume they are in a datacenter and should not be a power outage.... > > About dataset size... yes... our ones are big... they can be 3-4 TB easily each > dataset..... > > We bought them, because as they are for mailboxes and mailboxes grow and > grow.... for having space for hosting them... > Which mailbox format (e.g. mbox, maildir, ...) do you use? > > I'M RUNNING CYRUS IMAP SO SORT OF MAILDIR... TOO MANY LITTLE FILES NORMALLY..... SOMETIMES DIRECTORIES WITH TONS OF LITTLE FILES.... Assuming that many mails are much smaller than the erase block size of the SSD, this may cause issues. (You may know the following ...) For example, if you have message sizes of 8 KB and an erase block size of 64 KB (just guessing), then 8 mails will be in an erase block. If half the mails are deleted, then the erase block will still occupy 64 KB, but only hold 32 KB of useful data (and the SSD will only be aware of this fact if TRIM has signaled which data is no longer relevant). The SSD will copy several partially filled erase blocks together in a smaller number of free blocks, which then are fully utilized. Later deletions will repeat this game, and your data will be copied multiple times until it has aged (and the user is less likely to delete further messages). This leads to "write amplification" - data is internally moved around and thus written multiple times. STEFAN!! YOU ARE NICE!! I THINK THIS COULD EXPLAIN ALL OUR PROBLEM. SO, WHY WE ARE HAVING THE MOST RANDOMNESS IN OUR PERFORMANCE DEGRADATION AND THAT DOES NOT NECESSARILY HAS TO MATCH WITH THE MOST IO PEAK HOURS... THAT I COULD CAUSE THAT PERFORMANCE DEGRADATION JUST BY DELETING A COUPLE OF HUGE (PERHAPS 200.000 MAILS) MAIL FOLDERS IN A MIDDLE TRAFFIC HOUR TIME!! THE PROBLEM IS THAT BY WHAT I KNOW, ERASE BLOCK SIZE OF AN SSD DISK IS SOMETHING FIXED IN THE DISK FIRMWARE. I DON'T REALLY KNOW IF PERHAPS IT COULD BE MODIFIED WITH SAMSUNG MAGICIAN OR THOSE KIND OF TOOL OF SAMSUNG.... ELSE I DON'T REALLY SEE THE MANNER OF IMPROVING IT... BECAUSE APART FROM THAT, YOU ARE DELETING A FILE IN RAIDZ-2 ARRAY... NO JUST IN A DISK... I ASSUME ALIGNING CHUNK SIZE, WITH RECORD SIZE AND WITH THE "SECRET" ERASE SIZE OF THE SSD, PERHAPS COULD BE SLIGHTLY COMPENSATED?. Larger mails are less of an issue since they span multiple erase blocks, which will be completely freed when such a message is deleted. I SEE I SEE STEFAN... Samsung has a lot of experience and generally good strategies to deal with such a situation, but SSDs specified for use in storage systems might be much better suited for that kind of usage profile. YES... AND THE DISKS FOR OUR PURPOSE... PERHAPS WEREN'T QVOS.... > We knew they had some speed issues, but those speed issues, we thought (as > Samsung explains in the QVO site) they started after exceeding the speeding > buffer this disks have. We though that meanwhile you didn't exceed it's > capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps > we were wrong?. > These drives are meant for small loads in a typical PC use case, > i.e. some installations of software in the few GB range, else only > files of a few MB being written, perhaps an import of media files > that range from tens to a few hundred MB at a time, but less often > than once a day. > > WE MOVE, YOU KNOW... LOTS OF LITTLE FILES... AND LOT'S OF DIFFERENT CONCURRENT MODIFICATIONS BY 1500-2000 CONCURRENT IMAP CONNECTIONS WE HAVE... I do not expect the read load to be a problem (except possibly when the SSD is moving data from SLC to QLC blocks, but even then reads will get priority). But writes and trims might very well overwhelm the SSD, especially when its getting full. Keeping a part of the SSD unused (excluded from the partitions created) will lead to a large pool of unused blocks. This will reduce the write amplification - there are many free blocks in the "unpartitioned part" of the SSD, and thus there is less urgency to compact partially filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a partition used for the ZPOOL, then 1/4 of each erase block could be free due to deletions/TRIM without any compactions required to hold all this data.) Keeping a significant percentage of the SSD unallocated is a good strategy to improve its performance and resilience. WELL, WE HAVE ALLOCATED ALL THE DISK SPACE... BUT NOT USED... JUST ALLOCATED.... YOU KNOW... WE DO A ZPOOL CREATE WITH THE WHOLE DISKS..... >> As the SSD fills, the space available for the single level write >> cache gets smaller >> >> THE SINGLE LEVEL WRITE CACHE IS THE CACHE THESE SSD DRIVERS HAVE, FOR COMPENSATING THE SPEED ISSUES THEY HAVE DUE TO USING QLC MEMORY?. DO YOU REFER TO THAT?. SORRY I DON'T UNDERSTAND WELL THIS PARAGRAPH. Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as 24 GB of data in QLC mode. OK, TRUE.... YES.... A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (600 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells). AHH! YOU MEAN THAT SLC CAPACITY FOR SPEEDING UP THE QLC DISKS, IS OBTAINED FROM EACH SINGLE LAYER OF THE QLC?. Therefore, the fraction of the cells used as an SLC cache is reduced when it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cells). SORRY I DON'T GET THIS LAST SENTENCE... DON'T UNDERSTAND IT BECAUSE I DON'T REALLY KNOW THE MEANING OF TN... BUT I THINK I'M GETTING THE IDEA IF YOU SAY THAT EACH QLC LAYER, HAS IT'S OWN SLC CACHE OBTAINED FROM THE DISK SPACE AVAIABLE FOR EACH QLC LAYER.... And with less SLC cells available for short term storage of data the probability of data being copied to QLC cells before the irrelevant messages have been deleted is significantly increased. And that will again lead to many more blocks with "holes" (deleted messages) in them, which then need to be copied possibly multiple times to compact them. IF I CORRECT ABOVE, I THINK I GOT THE IDEA YES.... >> (on many SSDs, I have no numbers for this >> particular device), and thus the amount of data that can be >> written at single cell speed shrinks as the SSD gets full. >> >> I have just looked up the size of the SLC cache, it is specified >> to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB >> version, smaller models will have a smaller SLC cache). >> >> ASSUMING YOU WERE TALKING ABOUT THE CACHE FOR COMPENSATING SPEED WE PREVIOUSLY COMMENTED, I SHOULD SAY THESE ARE THE 870 QVO BUT THE 8TB VERSION. SO THEY SHOULD HAVE THE BIGGEST CACHE FOR COMPENSATING THE SPEED ISSUES... I have looked up the data: the larger versions of the 870 QVO have the same SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB more if there are enough free blocks. OURS ONE IS THE 8TB MODEL SO I ASSUME IT COULD HAVE BIGGER LIMITS. THE DISKS ARE MOSTLY EMPTY, REALLY.... SO... FOR INSTANCE.... ZPOOL LIST NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT ROOT_DATASET 448G 2.29G 446G - - 1% 0% 1.00X ONLINE - MAIL_DATASET 58.2T 11.8T 46.4T - - 26% 20% 1.00X ONLINE - I SUPPOSE FRAGMENTATION AFFECTS TOO.... >> But after writing those few GB at a speed of some 500 MB/s (i.e. >> after 12 to 150 seconds), the drive will need several minutes to >> transfer those writes to the quad-level cells, and will operate >> at a fraction of the nominal performance during that time. >> (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the >> 2 TB model.) >> >> WELL WE ARE IN THE 8TB MODEL. I THINK I HAVE UNDERSTOOD WHAT YOU WROTE IN PREVIOUS PARAGRAPH. YOU SAID THEY CAN BE FAST BUT NOT CONSTANTLY, BECAUSE LATER THEY HAVE TO WRITE ALL THAT TO THEIR PERPETUAL STORAGE FROM THE CACHE. AND THAT'S SLOW. AM I WRONG?. EVEN IN THE 8TB MODEL YOU THINK STEFAN?. The controller in the SSD supports a given number of channels (e.g 4), each of which can access a Flash chip independently of the others. Small SSDs often have less Flash chips than there are channels (and thus a lower throughput, especially for writes), but the larger models often have more chips than channels and thus the performance is capped. THIS IS TOTALLY LOGICAL. IF A QVO DISK WOULD OUTPERFORM BEST OR SIMILAR THAN AN INTEL WITHOUT CONSEQUENCES.... WHO WAS GOING TO BUY A EXPENSIVE INTEL ENTERPRISE?. In the case of the 870 QVO, the controller supports 8 channels, which allows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has only 4 Flash chips and is thus limited to 80 MB/s in that situation, while the larger versions have 8, 16, or 32 chips. But due to the limited number of channels, the write rate is limited to 160 MB/s even for the 8 TB model. TOTALLY LOGICAL STEFAN... If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in this limit. >> THE MAIN PROBLEM WE ARE FACING IS THAT IN SOME PEAK MOMENTS, WHEN THE MACHINE SERVES CONNECTIONS FOR ALL THE INSTANCES IT HAS, AND ONLY AS SAID IN SOME PEAK MOMENTS... LIKE THE 09AM OR THE 11AM.... IT SEEMS THE MACHINE BECOMES SLOWER... AND LIKE IF THE DISKS WEREN'T ABLE TO SERVE ALL THEY HAVE TO SERVE.... IN THESE MOMENTS, NO BIG FILES ARE MOVED... BUT AS WE HAVE 1800-2000 CONCURRENT IMAP CONNECTIONS... NORMALLY THEY ARE DOING EACH ONE... LITTLE CHANGES IN THEIR MAILBOX. DO YOU THINK PERHAPS THIS DISKS THEN ARE NOT APPROPRIATE FOR THIS KIND OF USAGE?- I'd guess that the drives get into a state in which they have to recycle lots of partially free blocks (i.e. perform kind of a garbage collection) and then three kinds of operations are competing with each other: * reads (generally prioritized) * writes (filling the SLC cache up to its maximum size) * compactions of partially filled blocks (required to make free blocks available for re-use) Writes can only proceed if there are sufficient free blocks, which on a filled SSD with partially filled erase blocks means that operations of type 3. need to be performed with priority to not stall all writes. My assumption is that this is what you are observing under peak load. IT COULD BE ALTHOUGH THE DISKS ARE NOT FILLED.... THE POOL ARE AT 20 OR 30% OF CAPACITY AND FRAGMENTATION FROM 20%-30% (AS ZPOOL LIST STATES). >> And cheap SSDs often have no RAM cache (not checked, but I'd be >> surprised if the QVO had one) and thus cannot keep bookkeeping date >> in such a cache, further limiting the performance under load. >> >> THIS BROCHURE (HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/BROCHURE/870_SERIES_BROCHURE.PDF AND THE DATASHEET HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/DATA-SHEET/SAMSUNG_SSD_870_QVO_DATA_SHEET_REV1.1.PDF) SAIS IF I HAVE READ PROPERLY, THE 8TB DRIVE HAS 8GB OF RAM?. I ASSUME THAT IS WHAT THEY CALL THE TURBO WRITE CACHE?. No, the turbo write cache consists of the cells used in SLC mode (which can be any cells, not only cells in a specific area of the flash chip). I SEE I SEE.... The RAM is needed for fast lookup of the position of data for reads and of free blocks for writes. OUR ONES... SEEM TO HAVE 8GB LPDDR4 OF RAM.... AS DATASHEET STATES.... There is no simple relation between SSD "block number" (in the sense of a disk block on some track of a magnetic disk) and its storage location on the Flash chip. If an existing "data block" (what would be a sector on a hard disk drive) is overwritten, it is instead written at the end of an "open" erase block, and a pointer from that "block number" to the location on the chip is stored in an index. This index is written to Flash storage and could be read from it, but it is much faster to have a RAM with these pointers that can be accessed independently of the Flash chips. This RAM is required for high transaction rates (especially random reads), but it does not really help speed up writes. I SEE... I SEE.... I GOT IT... >> And the resilience (max. amount of data written over its lifetime) >> is also quite low - I hope those drives are used in some kind of >> RAID configuration. >> >> YEP WE USE RAIDZ-2 Makes sense ... But you know that you multiply the amount of data written due to the redundancy. If a single 8 KB block is written, for example, 3 * 8 KB will written if you take the 2 redundant copies into account. I SEE I SEE.... >> The 870 QVO is specified for 370 full capacity >> writes, i.e. 370 TB for the 1 TB model. That's still a few hundred >> GB a day - but only if the write amplification stays in a reasonable >> range ... >> >> WELL YES... 2880TB IN OUR CASE....NOT BAD.. ISN'T IT? I assume that 2880 TB is your total storage capacity? That's not too bad, in fact. ;-) NO... THE TOTAL NUMBER OF WRITES YOU CAN DO....BEFORE THE DISK "BREAKS".... LOL :) :) ... WE ARE HAVING STORAGES OF 50TB DUE TO 8 DISKS OF 8TB IN RAIDZ-2.... This would be 360 * 8 TB ... Even at 160 MB/s per 8 TB SSD this would allow for more than 50 GB/s of write throughput (if all writes were evenly distributed). Taking all odds into account, I'd guess that at least 10 GB/s can be continuously written (if supported by the CPUs and controllers). But this may not be true if the drive is simultaneously reading, trimming, and writing ... I SEE.... IT'S EXTREMELY MISLEADING YOU KNOW... BECAUSE... YOU CAN COPY FIVE MAILBOXES OF 50GB CONCURRENTLY FOR INSTANCE.... AND YOU FLOOD A GIGABIT INTERFACE COPYING (OBVIOUSLY BECAUSE DISKS CAN KEEP THAT THROUGHPUT)... BUT LATER.... YOU SEE... YOU ARE IN AN HOUR THAT YESTERDAY, AND EVEN 4 DAYS BEFORE YOU HAVE NOT HAD ANY ISSUES... AND THAT DAY... YOU SEE THE COMMENTED ISSUE... EVEN NOT BEING EXACTLY AT A PEAK HOUR (PERHAPS IS TWO HOURS LATER THE PEAK HOUR EVEN)... OR... BUT I WASN'T NOTICING ABOUT ALL THINGS YOU SAY IN THIS EMAIL.... I have seen advice to not use compression in a high load scenario in some other reply. I tend to disagree: Since you seem to be limited when the SLC cache is exhausted, you should get better performance if you compress your data. I have found that zstd-2 works well for me (giving a significant overall reduction of size at reasonable additional CPU load). Since ZFS allows to switch compressions algorithms at any time, you can experiment with different algorithms and levels. I SEE... YOU SAY COMPRESSION SHOULD BE ENABLED.... THE MAIN REASON BECAUSE WE HAVE NOT ENABLED IT YET, IS FOR KEEPING THE SYSTEM THE MOST NEAR POSSIBLE TO CONFIG DEFAULTS... YOU KNOW... FOR LATER BEING ABLE TO ASK IN THIS MAILING LISTS IF WE HAVE AN ISSUE... BECAUSE YOU KNOW... IT WOULD BE FAR MORE EASIER TO ASK ABOUT SOMETHING STRANGE YOU ARE SEEING WHEN THAT STRANGE THING IS NEAR TO A WELL TESTED CONFIG, LIKE THE CONFIG BY DEFAULT.... BUT NOW YOU SAY STEFAN... IF YOU SWITCH BETWEEN COMPRESSION ALGORITHMS YOU WILL END UP WITH A MIX OF DIFFERENT FILES COMPRESSED IN A DIFFERENT MANNER... THAT IS NOT A BIT DISASTER LATER?. DOESN'T AFFECT PERFORMANCE IN SOME MANNER?. One advantage of ZFS compression is that it applies to the ARC, too. And a compression factor of 2 should easily be achieved when storing mail (not for .docx, .pdf, .jpg files though). Having more data in the ARC will reduce the read pressure on the SSDs and will give them more cycles for garbage collections (which are performed in the background and required to always have a sufficient reserve of free flash blocks for writes). WE WOULD USE I ASSUME THE LZ4... WHICH IS THE LESS "EXPENSIVE" COMPRESSION ALGORITHM FOR THE CPU... AND I ASSUME TOO FOR AVOIDING DELAY ACCESSING DATA... DO YOU RECOMMEND ANOTHER ONE?. DO YOU ALWAYS RECOMMEND COMPRESSION THEN?. I'd give it a try - and if it reduces your storage requirements by 10% only, then keep 10% of each SSD unused (not assigned to any partition). That will greatly improve the resilience of your SSDs, reduce the write-amplification, will allow the SLC cache to stay at its large value, and may make a large difference to the effective performance under high load. BUT WHEN YOU ENABLE COMPRESSION... ONLY GETS COMPRESSED THE NEW DATA MODIFIED OR ENTERED. AM I WRONG?. BY THE WAY, WE HAVE MORE OR LESS 1/4 OF EACH DISK USED (12 TB ALLOCATED IN A POLL STATED BY ZPOOL LIST, DIVIDED BETWEEN 8 DISKS OF 8TB...)... DO YOU THINK WE COULD BE SUFFERING ON WRITE AMPLIFICATION AND SO... HAVING A SO LITTLE DISK SPACE USED IN EACH DISK?. Regards, STefan HEY MATE, YOUR MAIL IS INCREDIBLE. IT HAS HELPED AS A LOT. CAN WE INVITE YOU A CUP OF COFFEE OR A BEER THROUGH PAYPAL OR SIMILAR?. CAN I HELP YOU IN SOME MANNER?. CHEERS! --=_ccf36dab3b44229808a0a46435736314 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Stefan,


An extremely interesting answer and email. Extremely thankful for all yo= ur deep explatanations...... They are like gold for us really....


I answer below and in blue bold for better distinction between your line= s and mine ones...

 


El 2022-04-06 23:49, Stefan Esser escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Am 06.04.22 um 18:34 schrieb egoitz@ramattack.net:

Hi Stefan!

Thank you so much for your answer!!. I do answer below in green bold for= instance... for a better distinction....

Very thankful for all your comments Stefan!!! :) :) :)

Cheers!!

Hi,

glad to hear that it is useful information - I'll add comments below .= =2E.


Extremely helpful information re= ally! Thank you so much Steffan really. Very very thankful for your nice he= lp!.


El 2022-04-06 17:43, Stefan Esser escribió:



Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net:
Hi Rainer!

Thank you so much for your help :) :)
=
Well I assume they are in a datacenter and should not be a power ou= tage....

About dataset size... yes... our ones are big... they= can be 3-4 TB easily each
dataset.....

We bought them, = because as they are for mailboxes and mailboxes grow and
grow.... for= having space for hosting them...

Which mailbox format (e.g. mbox, maildir, ...) do you use?
 
I'm running Cyrus imap so sort of = Maildir... too many little files normally..... Sometimes directories with t= ons of little files....

Assuming that many mails are much smaller than the erase block size of t= he SSD, this may cause issues. (You may know the following ...)

For example, if you have message sizes of 8 KB and an erase block size o= f 64 KB (just guessing), then 8 mails will be in an erase block. If half th= e mails are deleted, then the erase block will still occupy 64 KB, but only= hold 32 KB of useful data (and the SSD will only be aware of this fact if = TRIM has signaled which data is no longer relevant). The SSD will copy seve= ral partially filled erase blocks together in a smaller number of free bloc= ks, which then are fully utilized. Later deletions will repeat this game, a= nd your data will be copied multiple times until it has aged (and the user = is less likely to delete further messages). This leads to "write amplificat= ion" - data is internally moved around and thus written multiple times.


Stefan!! you are nice!! I think = this could explain all our problem. So, why we are having the most randomne= ss in our performance degradation and that does not necessarily has to matc= h with the most io peak hours... That I could cause that performance degrad= ation just by deleting a couple of huge (perhaps 200.000 mails) mail folder= s in a middle traffic hour time!!


The problem is that by what I kn= ow, erase block size of an SSD disk is something fixed in the disk firmware= =2E I don't really know if perhaps it could be modified with Samsung magici= an or those kind of tool of Samsung.... else I don't really see the manner = of improving it... because apart from that, you are deleting a file in raid= z-2 array... no just in a disk... I assume aligning chunk size, with record= size and with the "secret" erase size of the ssd, perhaps could be slightl= y compensated?.

Larger mails are less of an issue since they span multiple erase blocks,= which will be completely freed when such a message is deleted.

I see I see Stefan...

Samsung has a lot of experience and generally good strategies to deal wi= th such a situation, but SSDs specified for use in storage systems might be= much better suited for that kind of usage profile.

Yes... and the disks for our pur= pose... perhaps weren't QVOs....


We knew they had some speed issues, but those speed issues, we thou= ght (as
Samsung explains in the QVO site) they started after exceedin= g the speeding
buffer this disks have. We though that meanwhile you d= idn't exceed it's
capacity (the capacity of the speeding buffer) no s= peed problem arises. Perhaps
we were wrong?.

These drives are meant for small loads in a typical PC use case,
i.e. some installations of software in the few GB range, else only
= files of a few MB being written, perhaps an import of media files
th= at range from tens to a few hundred MB at a time, but less often
than= once a day.
 
We move, you know... lots of littl= e files... and lot's of different concurrent modifications by 1500-2000 con= current imap connections we have...

I do not expect the read load to be a problem (except possibly when the = SSD is moving data from SLC to QLC blocks, but even then reads will get pri= ority). But writes and trims might very well overwhelm the SSD, especially = when its getting full. Keeping a part of the SSD unused (excluded from the = partitions created) will lead to a large pool of unused blocks. This will r= educe the write amplification - there are many free blocks in the "unpartit= ioned part" of the SSD, and thus there is less urgency to compact partially= filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a part= ition used for the ZPOOL, then 1/4 of each erase block could be free due to= deletions/TRIM without any compactions required to hold all this data.)

Keeping a significant percentage of the SSD unallocated is a good strate= gy to improve its performance and resilience.

Well, we have allocated all the = disk space... but not used... just allocated.... you know... we do a zpool = create with the whole disks.....

As the SSD fills, the space available for the single level write
cac= he gets smaller
 
The single level write cache is th= e cache these ssd drivers have, for compensating the speed issues they have= due to using qlc memory?. Do you refer to that?. Sorry I don't understand = well this paragraph.

Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC = cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as= 24 GB of data in QLC mode.

Ok, true.... yes....

A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (60= 0 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells).

Ahh! you mean that SLC capacity = for speeding up the QLC disks, is obtained from each single layer of the QL= C?.

Therefore, the fraction of the cells used as an SLC cache is reduced whe= n it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cell= s).

Sorry I don't get this last sent= ence... don't understand it because I don't really know the meaning of tn= =2E..

but I think I'm getting the idea= if you say that each QLC layer, has it's own SLC cache obtained from the d= isk space avaiable for each QLC layer....

And with less SLC cells available for short term storage of data the pro= bability of data being copied to QLC cells before the irrelevant messages h= ave been deleted is significantly increased. And that will again lead to ma= ny more blocks with "holes" (deleted messages) in them, which then need to = be copied possibly multiple times to compact them.

If I correct above, I think I go= t the idea yes....

(on many SSDs, I have no numbers for this
particular device), and thus the amount of data that can be
written = at single cell speed shrinks as the SSD gets full.
 


I have just looked up the size of the SLC cache, it is speci= fied
to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 T= B
version, smaller models will have a smaller SLC cache).
 
Assuming you were talking about th= e cache for compensating speed we previously commented, I should say these = are the 870 QVO but the 8TB version. So they should have the biggest cache = for compensating the speed issues...

I have looked up the data: the larger versions of the 870 QVO have the s= ame SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB= more if there are enough free blocks.

Ours one is the 8TB model so I a= ssume it could have bigger limits. The disks are mostly empty, really.... s= o... for instance....

zpool list
= NAME     &= nbsp;       SIZE  ALLOC   FREE=   CKPOINT  EXPANDSZ   FRAG    CAP  = DEDUP  HEALTH  ALTROOT
root_dataset        = ;     448G  2.29G   446G  &nbs= p;     -        = ; -     1%     0%  1.00x = ONLINE  -
I suppose fragmentation affects = too....

But after writing those few GB at a speed of some 500 MB/s (i.e.
aft= er 12 to 150 seconds), the drive will need several minutes to
transfe= r those writes to the quad-level cells, and will operate
at a fractio= n of the nominal performance during that time.
(QLC writes max out at= 80 MB/s for the 1 TB model, 160 MB/s for the
2 TB model.)
 
Well we are in the 8TB model. I th= ink I have understood what you wrote in previous paragraph. You said they c= an be fast but not constantly, because later they have to write all that to= their perpetual storage from the cache. And that's slow. Am I wrong?. Even= in the 8TB model you think Stefan?.

The controller in the SSD supports a given number of channels (e.g 4), e= ach of which can access a Flash chip independently of the others. Small SSD= s often have less Flash chips than there are channels (and thus a lower thr= oughput, especially for writes), but the larger models often have more chip= s than channels and thus the performance is capped.

This is totally logical. If a QV= O disk would outperform best or similar than an Intel without consequences= =2E... who was going to buy a expensive Intel enterprise?.<= /p>

In the case of the 870 QVO, the controller supports 8 channels, which al= lows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has= only 4 Flash chips and is thus limited to 80 MB/s in that situation, while= the larger versions have 8, 16, or 32 chips. But due to the limited number= of channels, the write rate is limited to 160 MB/s even for the 8 TB model= =2E

Totally logical Stefan...=

If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in thi= s limit.

The main problem we are facing is = that in some peak moments, when the machine serves connections for all the = instances it has, and only as said in some peak moments... like the 09am or= the 11am.... it seems the machine becomes slower... and like if the disks = weren't able to serve all they have to serve.... In these moments, no big f= iles are moved... but as we have 1800-2000 concurrent imap connections... n= ormally they are doing each one... little changes in their mailbox. Do you = think perhaps this disks then are not appropriate for this kind of usage?-<= /strong>

I'd guess that the drives get into a state in which they have to recycle= lots of partially free blocks (i.e. perform kind of a garbage collection) = and then three kinds of operations are competing with each other:

  1. reads (generally prioritized)
  2. writes (filling the SLC cache up to its maximum size)
  3. compactions of partially filled blocks (required to make free blocks av= ailable for re-use)

Writes can only proceed if there are sufficient free blocks, which on a = filled SSD with partially filled erase blocks means that operations of type= 3. need to be performed with priority to not stall all writes.

My assumption is that this is what you are observing under peak load.

It could be although the disks a= re not filled.... the pool are at 20 or 30% of capacity and fragmentation f= rom 20%-30% (as zpool list states).

And cheap SSDs often have no RAM cache (not checked, but I'd be
surp= rised if the QVO had one) and thus cannot keep bookkeeping date
in su= ch a cache, further limiting the performance under load.
 
This brochure (https://semiconductor.samsung.com/resources/brochu= re/870_Series_Brochure.pdf and the datasheet https://semiconductor.samsung.com/resources/data-sheet/Samsung_S= SD_870_QVO_Data_Sheet_Rev1.1.pdf) sais if I have read properly, the 8TB= drive has 8GB of ram?. I assume that is what they call the turbo write cac= he?.

No, the turbo write cache consists of the cells used in SLC mode (which = can be any cells, not only cells in a specific area of the flash chip).

I see I see....<= /p>

The RAM is needed for fast lookup of the position of data for reads and = of free blocks for writes.

Our ones... seem to have 8GB LPD= DR4 of ram.... as datasheet states....

There is no simple relation between SSD "block number" (in the sense of = a disk block on some track of a magnetic disk) and its storage location on = the Flash chip. If an existing "data block" (what would be a sector on a ha= rd disk drive) is overwritten, it is instead written at the end of an "open= " erase block, and a pointer from that "block number" to the location on th= e chip is stored in an index. This index is written to Flash storage and co= uld be read from it, but it is much faster to have a RAM with these pointer= s that can be accessed independently of the Flash chips. This RAM is requir= ed for high transaction rates (especially random reads), but it does not re= ally help speed up writes.

I see... I see.... I got it...


And the resilience (max. amount of data written over its lifetime)
i= s also quite low - I hope those drives are used in some kind of
RAID = configuration.
 
Yep we use raidz-2=

Makes sense ... But you know that you multiply the amount of data writte= n due to the redundancy.

If a single 8 KB block is written, for example, 3 * 8 KB will written if= you take the 2 redundant copies into account.

I see I see....<= /p>


The 870 QVO is specified for 370 full capacity
writes, i.e. 370 TB f= or the 1 TB model. That's still a few hundred
GB a day - but only if = the write amplification stays in a reasonable
range ...
 
Well yes... 2880TB in our case..= =2E.not bad.. isn't it?

I assume that 2880 TB is your total storage capacity? That's not too bad= , in fact. ;-)

No... the total number of writes= you can do....before the disk "breaks"....


lol :) :)  ... we are havin= g storages of 50TB due to 8 disks of 8TB in raidz-2....


This would be 360 * 8 TB ...

Even at 160 MB/s per 8 TB SSD this would allow for more than 50 GB/s of = write throughput (if all writes were evenly distributed).

Taking all odds into account, I'd guess that at least 10 GB/s can be con= tinuously written (if supported by the CPUs and controllers).

But this may not be true if the drive is simultaneously reading, trimmin= g, and writing ...

I see.... It's extremely mislead= ing you know... because... you can copy five mailboxes of 50GB concurrently= for instance.... and you flood a gigabit interface copying (obviously beca= use disks can keep that throughput)... but later.... you see... you are in = an hour that yesterday, and even 4 days before you have not had any issues= =2E.. and that day... you see the commented issue... even not being exactly= at a peak hour (perhaps is two hours later the peak hour even)... or... bu= t I wasn't noticing about all things you say in this email....

I have seen advice to not use compression in a high load scenario in som= e other reply.

I tend to disagree: Since you seem to be limited when the SLC cache is e= xhausted, you should get better performance if you compress your data. I ha= ve found that zstd-2 works well for me (giving a significant overall reduct= ion of size at reasonable additional CPU load). Since ZFS allows to switch = compressions algorithms at any time, you can experiment with different algo= rithms and levels.

I see... you say compression sho= uld be enabled.... The main reason because we have not enabled it yet, is f= or keeping the system the most near possible to config defaults... you know= =2E.. for later being able to ask in this mailing lists if we have an issue= =2E.. because you know... it would be far more easier to ask about somethin= g strange you are seeing when that strange thing is near to a well tested c= onfig, like the config by default....

But now you say Stefan... if you= switch between compression algorithms you will end up with a mix of differ= ent files compressed in a different manner... that is not a bit disaster la= ter?. Doesn't affect performance in some manner?.

One advantage of ZFS compression is that it applies to the ARC, too. And= a compression factor of 2 should easily be achieved when storing mail (not= for .docx, .pdf, .jpg files though). Having more data in the ARC will redu= ce the read pressure on the SSDs and will give them more cycles for garbage= collections (which are performed in the background and required to always = have a sufficient reserve of free flash blocks for writes).

We would use I assume the lz4.= =2E. which is the less "expensive" compression algorithm for the CPU... and= I assume too for avoiding delay accessing data... do you recommend another= one?. Do you always recommend compression then?.

I'd give it a try - and if it reduces your storage requirements by 10% o= nly, then keep 10% of each SSD unused (not assigned to any partition). That= will greatly improve the resilience of your SSDs, reduce the write-amplifi= cation, will allow the SLC cache to stay at its large value, and may make a= large difference to the effective performance under high load.

But when you enable compression= =2E.. only gets compressed the new data modified or entered. Am I wrong?.

By the way, we have more or less= 1/4 of each disk used (12 TB allocated in a poll stated by zpool list, div= ided between 8 disks of 8TB...)... do you think we could be suffering on wr= ite amplification and so... having a so little disk space used in each disk= ?.

Regards, STefan

Hey mate, your mail is incredibl= e. It has helped as a lot. Can we invite you a cup of coffee or a beer thro= ugh Paypal or similar?. Can I help you in some manner?.


Cheers!


--=_ccf36dab3b44229808a0a46435736314-- From nobody Thu Apr 7 13:39:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 003991A8A500; Thu, 7 Apr 2022 13:40:04 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ2Yt5pt4z4TQY; Thu, 7 Apr 2022 13:40:01 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id AA01060C45C; Thu, 7 Apr 2022 15:39:58 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_cc796372be3f66b49dc427201012caa6" Date: Thu, 07 Apr 2022 15:39:58 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: mike tancsa , Bob Friesenhahn , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <0702dc56-28ba-7e99-d599-1036634d79e3@FreeBSD.org> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <0702dc56-28ba-7e99-d599-1036634d79e3@FreeBSD.org> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ2Yt5pt4z4TQY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_cc796372be3f66b49dc427201012caa6 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Stefan!!, Thank you so much. I can't be more thankful. I answer below in bold blue for instance... for better seeing my answers.... El 2022-04-06 23:59, Stefan Esser escribiĂł: > I have got much better compression at same or less load by use of zstd-2 > compared to lz4. > > I ASSUME PEOPLE WOULD NORMALLY USES LZOP DUE TO IT'S KNOWN LIGHT CPU LOAD NEEDED... > I TAKE NOT TOO OF ZSTD-2.... > > Perhaps not typical, since this is a dovecot mdbox formatted mail pool > holding mostly plain text messages without large attachments: > > $ df /var/mdbox > Filesystem 1K-blocks Used Avail Capacity Mounted on > system/var/mdbox 7234048944 9170888 7224878056 0% /var/mdbox > > $ zfs get compression,compressratio,used,logicalused system/var/mdbox > NAME PROPERTY VALUE SOURCE > system/var/mdbox compression zstd-2 inherited from system/var > system/var/mdbox compressratio 2.29x - > system/var/mdbox used 8.76G - > system/var/mdbox logicalused 20.0G - > > Regards, STefan > > NICE TO KNOW STEFAN, NICE TO KNOW!, > > CHEERS, --=_cc796372be3f66b49dc427201012caa6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Stefan!!,


Thank you so much. I can't be more thankful.


I answer below in bold blue for instance... for better seeing my answers= =2E...

 


El 2022-04-06 23:59, Stefan Esser escribió:

=
I have got much better compression at same or less load by use of zs= td-2
compared to lz4.
=  
= I assume people would normally uses= lzop due to it's known light cpu load needed...
= I take not too of zstd-2....=
=

Perhaps not typical, since this is a dovecot mdbox formatted = mail pool
holding mostly plain text messages without large attachment= s:

$ df /var/mdbox
Filesystem     &n= bsp;  1K-blocks    Used     &n= bsp;Avail Capacity  Mounted on
system/var/mdbox 7234048944 91708= 88 7224878056     0%    /var/mdbox
=
$ zfs get compression,compressratio,used,logicalused system/var/mdb= ox
NAME           &= nbsp;  PROPERTY       VALUE  &= nbsp;        SOURCE
system/va= r/mdbox  compression    zstd-2     =      inherited from system/var
system/var/md= box  compressratio  2.29x       &nb= sp;   -
system/var/mdbox  used    =        8.76G     &nb= sp;     -
system/var/mdbox  logicalused=    20.0G         &n= bsp; -

Regards, STefan
=  
= Nice to know Stefan, nice to know!,=
=  
= Cheers,
--=_cc796372be3f66b49dc427201012caa6-- From nobody Thu Apr 7 13:43:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F6141A8C3C4; Thu, 7 Apr 2022 13:43:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ2dv4Jvmz4WyC; Thu, 7 Apr 2022 13:43:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 237DhUu3068410 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 7 Apr 2022 09:43:30 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:434:73cd:9d42:28ad] ([IPv6:2607:f3e0:0:4:434:73cd:9d42:28ad]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 237DhTQ2017476 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 7 Apr 2022 09:43:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <217020e3-0092-b269-96e4-dd77bdcde110@sentex.net> Date: Thu, 7 Apr 2022 09:43:29 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS Content-Language: en-US From: mike tancsa To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4KZ2dv4Jvmz4WyC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-3.27 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.87)[-0.869]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received] X-ThisMailContainsUnwantedMimeParts: N On 4/7/2022 7:25 AM, mike tancsa wrote: > On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: >> >> Hi Mike! >> >> Thanks a lot for your comment. I see. As said before, we didn't >> really enable compression because we just keep the config as FreeBSD >> leaves by default. Apart from that, having tons of disk space and >> well... for avoiding the load of compress/decompress... The main >> reason was it was not enabled by default really and not to have seen >> a real reason for it.... was not more than that....I appreciate your >> comments really :) > > > Think of the extreme case where you do something like > > dd if=/dev/zero of=/tank/junk.bin bs=1m count=10000 > > as this is a 20G file that takes just a few hundred bytes of write IO > on a compressed system. Obviously, as the compress ratio reduces in > the real world the benefits become less.  Where that diminishing > return is, not sure.  But something to keep in mind > > You might also want to have a look at this article which I found quite helpful https://klarasystems.com/articles/openzfs1-understanding-transparent-compression/     ---Mike From nobody Thu Apr 7 13:53:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 240921A90AA1; Thu, 7 Apr 2022 13:53:17 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ2s80CnXz4bfR; Thu, 7 Apr 2022 13:53:14 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 5746F60C4A4; Thu, 7 Apr 2022 15:53:06 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9966c949ad7be3a0f79023829a1cf786" Date: Thu, 07 Apr 2022 15:53:06 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: Jan Bramkamp , performance@freebsd.org, freebsd-fs@freebsd.org, FreeBSD Hackers Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <49f43af5-e145-c793-959d-ab1596421d81@FreeBSD.org> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <49f43af5-e145-c793-959d-ab1596421d81@FreeBSD.org> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ2s80CnXz4bfR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_9966c949ad7be3a0f79023829a1cf786 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Stefan, Thanks a lot again, mate. Answering below in bold blue... El 2022-04-07 09:59, Stefan Esser escribió: > I have not compared dovecot's zlib compression with zstd-2 on the file system, > but since I use the latter on all my ZFS file systems (excepts those that > exclusively hold compressed files and media), I'm using it for Dovecot mdbox > files, too. I get a compression ratio of 2,29 with ZFS zstd-2, maybe I should > copy the files over into a zlib compressed mdbox for comparison ... > > WE ARE RUNNING CYRUS HERE... ALTHOUGH THAT CHECK SOUNDS INTERESTING... > > One large advantage of the mdbox format in the context of the mail server > set-up at the start of this thread is that deletions are only registered in > an index file (while mbox needs a rewrite of potentially large parts of the > mail folder and mdir immediately deletes files (TRIM) and updates inodes and > directory entries, causing multiple writes per deleted message). > > I SEE... REALLY SAID... I LOVE CYRUS... IT'S REPLICATION IS EXTREMELY RELIABLE... > > SOME TIME NOW... DOVECOT DIDN'T HAD REPLICATION... AND WE HAVE SOME DEVELOPMENTS DONE FROM SOME TIME NOW FOR CYRUS IMAP... > > BUT GOOD TO KNOW TO ABOUT OTHER SOFTWARE'S ADVANTAGES... > > With mdbox you can delay all "expensive" file system operations to the > point of least load each day, for example. Such a compression run is also > well suited for SSDs, since it does not perform random updates that punch > holes in a large number of erase blocks (which then will need to be garbage > collected, causing write amplification to put further load and stress on > the SSD). > > WE DON'T DELETE MAIL DURING DAY HOURS. WE USE A FEATURE OF CYRUS CALLED EXPUNGE DELAYED. THE DELETED EMAIL IS DELETED FROM DISK AT 04AM (UNTIL THAT MOMENT IS JUST TAGGED AS DELETED IN A CYRUS DATABASE). THE EXCEPTION HAPPENS WHEN YOU RENAME A FOLDER OR DELETE AN ENTIRE FOLDER. IF YOU DELETE AN ENTIRE FOLDER, I THINK IT GETS COPIED TO A DELETED/..WHATEVER.. FOLDER AND THEN YES... IT COPIES AND LATER DELETES... > > APART FROM THAT, CYRUS DOES A LOT OF DATABASE CHECKPOINTING, CAUSING DATABASES TO BE COPIED TO A NEW CREATED ONE AND THE OLD ONE TO BE DELETED. THIS ARE THE ONLY REMOVALS WE DO DURING DAY TIME. THE REST IS DONE FROM 04AM TO 05AM, WHEN THERE'S NO LOAD. > > CHEERS!!! --=_9966c949ad7be3a0f79023829a1cf786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Stefan,


Thanks a lot again, mate. Answering below in bold blue...

 


El 2022-04-07 09:59, Stefan Esser escribió:

=
I have not compared dovecot's zlib compression with zstd-2 on the fi= le system,
but since I use the latter on all my ZFS file systems (exc= epts those that
exclusively hold compressed files and media), I'm usi= ng it for Dovecot mdbox
files, too. I get a compression ratio of 2,29= with ZFS zstd-2, maybe I should
copy the files over into a zlib comp= ressed mdbox for comparison ...
=  
= We are running Cyrus here... althou= gh that check sounds interesting...

One large = advantage of the mdbox format in the context of the mail server
set-u= p at the start of this thread is that deletions are only registered in
an index file (while mbox needs a rewrite of potentially large parts of t= he
mail folder and mdir immediately deletes files (TRIM) and updates = inodes and
directory entries, causing multiple writes per deleted mes= sage).
=  
= I see... really said... I love Cyru= s... it's replication is extremely reliable...
=  
= Some time now... Dovecot didn't had= replication... and we have some developments done from some time now for C= yrus IMAP...
=  
= But good to know to about other sof= tware's advantages...

With mdbox you can delay= all "expensive" file system operations to the
point of least load ea= ch day, for example. Such a compression run is also
well suited for S= SDs, since it does not perform random updates that punch
holes in a l= arge number of erase blocks (which then will need to be garbage
colle= cted, causing write amplification to put further load and stress on
t= he SSD).
=  
= We don't delete mail during day hou= rs. We use a feature of Cyrus called expunge delayed. The deleted email is = deleted from disk at 04am (until that moment is just tagged as deleted in a= Cyrus database). The exception happens when you rename a folder or delete = an entire folder. If you delete an entire folder, I think it gets copied to= a DELETED/..whatever.. folder and then yes... it copies and later deletes= =2E..
=  
= Apart from that, Cyrus does a lot o= f database checkpointing, causing databases to be copied to a new created o= ne and the old one to be deleted. This are the only removals we do during d= ay time. The rest is done from 04am to 05am, when there's no load.
=  
= Cheers!!!
--=_9966c949ad7be3a0f79023829a1cf786-- From nobody Thu Apr 7 13:57:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B1721A931A5; Thu, 7 Apr 2022 13:57:37 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ2y807fRz4dhJ; Thu, 7 Apr 2022 13:57:36 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id F221A60C10A; Thu, 7 Apr 2022 15:57:33 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_49ce93a42b87a5e038a30c28c67e0d83" Date: Thu, 07 Apr 2022 15:57:33 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <4ef109e8-bd7b-1398-2bc9-191e261d5c06@FreeBSD.org> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ2y807fRz4dhJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_49ce93a42b87a5e038a30c28c67e0d83 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi!! Thanks ;) really man :) Answering below in bold blue... El 2022-04-07 12:05, Stefan Esser escribiĂł: > I just noticed that this is not the extreme total size of a ZFS pool > (should have noticed this while answering late at night ...) > > And no, a specified life-time of 2880 TB written is not much, it is > at the absolute lower end of currently available SSDs at 360 TB per > 1 TB of capacity. > > YEP THAT'S IT... > > This is equivalent to 360 total capacity writes, but given the high > amount of write amplification that can be assumed to occur in your > use case, I'd heavily over-provision a system with such SSDs ... > (or rather: strictly avoid them in a non-consumer setting). > > It's slightly late for over-provisioning... you know... we have done the zpool create with the whole disk..not just a slice.... > > WE CAN TRY TO BE SLIGHTLY FAR FROM THE 80% CAPACITY LIMIT BUT.... NOT POSSIBLE NOW... AT LEAST FOR THIS GROUP OF SERVERS... > > CHEERS! --=_49ce93a42b87a5e038a30c28c67e0d83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi!!


Thanks ;) really man :)


Answering below in bold blue...

 


El 2022-04-07 12:05, Stefan Esser escribió:

=

I just noticed that this is not the extreme total size of a ZF= S pool
(should have noticed this while answering late at night ...)
And no, a specified life-time of 2880 TB written is not much, i= t is
at the absolute lower end of currently available SSDs at 360 TB = per
1 TB of capacity.
=  
= Yep that's it...
This is equivalent to 360 total capacity writes, but given the h= igh
amount of write amplification that can be assumed to occur in you= r
use case, I'd heavily over-provision a system with such SSDs ... (or rather: strictly avoid them in a non-consumer setting).
=  
= It's slightly late for over-provisioning... you know... we have done the zp= ool create with the whole disk..not just a slice....
=  
= We can try to be slightly far from = the 80% capacity limit but.... not possible now... at least for this group = of servers...
=  
= Cheers!
--=_49ce93a42b87a5e038a30c28c67e0d83-- From nobody Thu Apr 7 14:01:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F299B1A9499D; Thu, 7 Apr 2022 14:01:07 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ32B4GXpz4gtl; Thu, 7 Apr 2022 14:01:06 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id A4C8160C00B; Thu, 7 Apr 2022 16:01:04 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_74b7e4b05962e4b9793f3fbab21fa2c0" Date: Thu, 07 Apr 2022 16:01:04 +0200 From: egoitz@ramattack.net To: mike tancsa Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> Message-ID: <1c114208ae8387fc7c4291d1cc66227e@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ32B4GXpz4gtl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_74b7e4b05962e4b9793f3fbab21fa2c0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Mike! Thanks a lot for your answer :) :) and your time :) :) Answering below in blue bold... El 2022-04-07 13:25, mike tancsa escribiĂł: > On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: > >> > Hi, > > With respect to compression, I think there is a sweet spot somewhere, where compression makes things faster if your disk IO is the limiting factor and you have spare CPU capacity. I have a separate 13.x zfs server with ztsd enabled and I get compression rations of 15:1 as it stores a lot of giant JSON txt files. > > ZTSD OR ZTSD-2 AS IN SOME MAIL PREVIOUS STEFAN STATED?. I ASSUME ARE NOT THE SAME... ARE THEY?. > > Think of the extreme case where you do something like > > dd if=/dev/zero of=/tank/junk.bin bs=1m count=10000 > > as this is a 20G file that takes just a few hundred bytes of write IO on a compressed system. Obviously, as the compress ratio reduces in the real world the benefits become less. Where that diminishing return is, not sure. But something to keep in mind > > TOTALLY TRUE AND TOTALLY AGREE MIKE!! > CHEERS!! --=_74b7e4b05962e4b9793f3fbab21fa2c0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Mike!


Thanks a lot for your answer :) :) and your time :) :)


Answering below in blue bold...

 


El 2022-04-07 13:25, mike tancsa escribió:

=
On 4/7/2022 4:59 = ;AM, egoitz@ramattack.net&= nbsp;wrote:

Hi,

  &n= bsp; With respect to compression, I think there is a sweet spot somewhere, = where compression makes things faster if your disk IO is the limiting facto= r and you have spare CPU capacity.  I have a separate 13.x zfs server = with ztsd enabled and I get compression rations of 15:1 as it stores a lot = of giant JSON txt files.
=  
= ztsd or ztsd-2 as in some mail prev= ious Stefan stated?. I assume are not the same... are they?.

Think of the&= nbsp;extreme case where you do something like=

dd if=3D/dev= /zero of=3D/tank/junk.bin bs=3D1m count=3D10000
=  
= as this is a 20G file that takes just a few hundred bytes of write IO on a = compressed system. Obviously, as the compress ratio reduces in the real wor= ld the benefits become less.  Where that diminishing return is, not su= re.  But something to keep in mind
=  
= Totally true and totally agree Mike= !!
=  
Cheers!! --=_74b7e4b05962e4b9793f3fbab21fa2c0-- From nobody Thu Apr 7 14:02:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 42EBC1A956E8; Thu, 7 Apr 2022 14:02:21 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZ33b5367z4hm4; Thu, 7 Apr 2022 14:02:19 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id E0F1060C82E; Thu, 7 Apr 2022 16:02:16 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_14f3bd38668fdecfedfad3f860fc22f3" Date: Thu, 07 Apr 2022 16:02:16 +0200 From: egoitz@ramattack.net To: mike tancsa Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: <217020e3-0092-b269-96e4-dd77bdcde110@sentex.net> References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> <609373d106c2244a8a2a3e2ca5e6eb73@ramattack.net> <217020e3-0092-b269-96e4-dd77bdcde110@sentex.net> Message-ID: X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZ33b5367z4hm4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_14f3bd38668fdecfedfad3f860fc22f3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Sure!!! good to know mate!!! Thanks Mike!! El 2022-04-07 15:43, mike tancsa escribiĂł: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > On 4/7/2022 7:25 AM, mike tancsa wrote: On 4/7/2022 4:59 AM, egoitz@ramattack.net wrote: > Hi Mike! > > Thanks a lot for your comment. I see. As said before, we didn't really enable compression because we just keep the config as FreeBSD leaves by default. Apart from that, having tons of disk space and well... for avoiding the load of compress/decompress... The main reason was it was not enabled by default really and not to have seen a real reason for it.... was not more than that....I appreciate your comments really :) > > Think of the extreme case where you do something like > > dd if=/dev/zero of=/tank/junk.bin bs=1m count=10000 > > as this is a 20G file that takes just a few hundred bytes of write IO on a compressed system. Obviously, as the compress ratio reduces in the real world the benefits become less. Where that diminishing return is, not sure. But something to keep in mind You might also want to have a look at this article which I found quite helpful https://klarasystems.com/articles/openzfs1-understanding-transparent-compression/ ---Mike --=_14f3bd38668fdecfedfad3f860fc22f3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Sure!!! good to know mate!!!


Thanks Mike!!

 


El 2022-04-07 15:43, mike tancsa escribió:

= ATENCION
ATENCION
ATENCION= !!! Este correo se ha enviado desde fuer= a de la organizacion. No pinche en los&n= bsp;enlaces ni abra los adjuntos a no se= r que reconozca el remitente y sepa que&= nbsp;el contenido es seguro.

On 4/7/2022 7:25 AM, mike&nbs= p;tancsa wrote:
On 4/7/2022&= nbsp;4:59 AM, egoitz@rama= ttack.net wrote:

Hi Mi= ke!

Thanks a lot for your comment. I see. As said befor= e, we didn't really enable compression because we just keep the config as F= reeBSD leaves by default. Apart from that, having tons of disk space and we= ll... for avoiding the load of compress/decompress... The main reason was i= t was not enabled by default really and not to have seen a real reason for = it.... was not more than that....I appreciate your comments really :)

Think of the&n= bsp;extreme case where you do something like<= /span>

dd if=3D/dev/= zero of=3D/tank/junk.bin bs=3D1m count=3D10000
=
as this is a 20G file that takes just a few hundred bytes of write I= O on a compressed system. Obviously, as the compress ratio reduces in the r= eal world the benefits become less.  Where that diminishing return is,= not sure.  But something to keep in mind

You might also want to have a look at this article which I found quite help= ful


https://klarasystems.com= /articles/openzfs1-understanding-transparent-compression/
=

    = ---Mike

--=_14f3bd38668fdecfedfad3f860fc22f3-- From nobody Thu Apr 7 20:02:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 660F61A905DB; Thu, 7 Apr 2022 20:02:54 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZC3d25QJz3Fx1; Thu, 7 Apr 2022 20:02:53 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ej1-x631.google.com with SMTP id i27so13094297ejd.9; Thu, 07 Apr 2022 13:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=iEKptgaYpUnOO67t7UZ8Yg1/49jS1d6Us3VWd7IOOdU=; b=eNM0exi6dJC9wV1oyEyZGIAQzTuKiuCYUg0+s4DxdGdKVHqBw3aU+DEdX3QuYhYZnb cqMfUAIsRWScuBrNCz6uJ2gjzJPjEoCasSzF3n4grJWWcodkMGkisSGAmeRH21/FUEpH E9UPU6P6Yq+UpXsBkSMFv9M+h0Dhf/ea/YM9agFSYStJibJ8+CKAt6oD06BSBV9rqAH8 84IZmPg53WLItEffS2aq0YupJiWtnyDYcATTjy2tViOimQ0vT9YAlL0tYLpgnHhRgxGs tbGBjy50FQ89E0saHl8AHCUFfeSXErOoQ/mTxuKdBqN9JWX5IJoAzSJiyxemnm//enIf sinA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iEKptgaYpUnOO67t7UZ8Yg1/49jS1d6Us3VWd7IOOdU=; b=umPTJWofq0pvV+AN+UlNRrnvgPzxWBSSmqWI0iPVIrj8jhKpas3wUOnJ8usfFzB2p3 Tidv5i0BZXNfm6KzxOWFYuscDnJ4NbIBUB9ZjNaQyUY+Hqh/Zqh2pSt5dRjN4rEaPxyU clEay0KBx8oDuU8AS7SIPOMIofmRUmzNSewwsEASthkWckGnyhy3wUDGISm2RqM4Fx9o cQQq264ZSH7aSC63b6NAp6yQ9QmLBLp949fXr72uP6CzkkkO8Qdx4rVFh2rTyHkclLeQ xYMzlP7/IafMWh/InGQoxASj9spnW5yS8PtiKgKPjrdDWN+q2r1GdbpOb9yMZpq14LHm XvBA== X-Gm-Message-State: AOAM530u3JGHS6QBCbrrgOVgucHkRMf2d+Y5zdThm31ZUIIglTchSQbH eyqJhvSU7ZVtsV1vNqaIBYEhe7mwzqxh1I98ou0WMNqTErX/NnLU4qU= X-Google-Smtp-Source: ABdhPJx2gY2F0XaL8l+lpntvd6jQN1lCsA1mmXkepsIayYVv5vrTucMcC8rwnrNMEdOKxoKOThF6uS9LAj+i0NvUZjw= X-Received: by 2002:a17:907:7286:b0:6df:f778:2585 with SMTP id dt6-20020a170907728600b006dff7782585mr14422472ejc.244.1649361765912; Thu, 07 Apr 2022 13:02:45 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:ab4:9c81:0:0:0:0:0 with HTTP; Thu, 7 Apr 2022 13:02:45 -0700 (PDT) From: grarpamp Date: Thu, 7 Apr 2022 16:02:45 -0400 Message-ID: Subject: List Mail Formatting Netiquette [ie: 870 QVO] To: freebsd-hackers@freebsd.org Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KZC3d25QJz3Fx1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eNM0exi6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-fs,freebsd-performance,freebsd-questions]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 4/7/22, egoitz@ramattack.net wrote: > I answer below in bold blue for instance... > for better seeing my answers.... While you may think that helps people, in reality it does not, and it actually makes peoples mails much worse for the proper text based email using world, and sits among other random formats that randoms try to stuff down other peoples mailboxes, and they might not even show up in search engines, archives, onscreen, phones, etc. Read up on classic proper email formatting netiquette where, for very good reasons, it tells everyone to... turn off HTML mail, and to quit top posting and quit bulk quoting, and to trim what you're replying to down to only the relevant minimum context while writing your replies underneath that, and to delete addressees already present within list addresses, and to quit SHOUTING ALL CAPS, and to wrap non-code lines at around 68 chars, and to not break header threading (in-reply-to and references) when replying. This reminder actually for all lists and senders. Clean... https://docs.freebsd.org/cgi/getmsg.cgi?fetch=1514528+0+current/freebsd-hackers vs Chaos... https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3049898+0+current/freebsd-hackers https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3049898+0+current/freebsd-hackers+raw https://lists.freebsd.org/archives/freebsd-hackers/2022-April/000975.html https://lists.freebsd.org/archives/freebsd-hackers/2022-April/000975.txt Import the raw archives into your MUA to see even worse unreadably formatted things, and nice clean things too... rsync -nHaxi bit0.us-west.freebsd.org::FreeBSD-mailarchive/ Use the clean habit mailiquette rules to make reading the world better for everyone :) From nobody Fri Apr 8 11:14:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5F68D1A89133; Fri, 8 Apr 2022 11:14:29 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZbHT1nGhz4rdQ; Fri, 8 Apr 2022 11:14:29 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649416469; h=from:from:reply-to:subject:subject:date:date: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=JlfXsy1DWMiP2fVpvEdmDICcRyZdKcm3477CxCwciNE=; b=Y6LhFNt3WUDToCHPlXDod+JjjeS2FY/J2jIloPEnNhXOV9FDKr9cJQb1V++NRzEM1UERTp jI23Rprjxa1V0rrGYBlwm49iE2X/ja2I9Tf+UNWb9RozDIXpiR8zByltboDcpJjWZ6HEm5 A1HDlxji4iJcsf+8tJyvvTDqdZ3c+z5SJnwe+Y4DrNBcmLfZgvUyt4EUc2nNR8F3BWKNFn SXbRNwJQ9xPxhM/1N09ifCmQbafAsF9TaxYC4dNjoUaTq/S8sSK39JO/xwx0b6Hj4ZwZYZ DWg4RiRmnKngl/ks1Gv4qlx9ZZqsnCALJnGPihWjcsO11kvxvdIk+n1GFzytCA== Received: from [IPV6:2003:cd:5f22:6f00:acb8:ea4e:7d58:95d3] (p200300cd5f226f00acb8ea4e7d5895d3.dip0.t-ipconnect.de [IPv6:2003:cd:5f22:6f00:acb8:ea4e:7d58:95d3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 3446729D1D; Fri, 8 Apr 2022 11:14:28 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: Date: Fri, 8 Apr 2022 13:14:24 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: Stefan Esser Subject: Re: Desperate with 870 QVO and ZFS To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Content-Language: en-US In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------TD2ASvjzfpo4JyxrFz8JyiVP" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649416469; h=from:from:reply-to:subject:subject:date:date: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=JlfXsy1DWMiP2fVpvEdmDICcRyZdKcm3477CxCwciNE=; b=IXz5kNfN6/gK87Bf0RxfSqtmz2VZjPDhepICW9REQpiljoVUgpcckFjxx47bHN2L0BqifB 9cpYwYl9Eh97xYJzhb1MdamL03nz0HGWR+gY8fCgqy97CzrJmmY3RdkOOI4Zq0Yz2MGDCe CD7IAVJSWSiB8Sw+eyj/FzCM6UjIwdrtunr83VoWu7WvBA1tKJo3TxAjySFQLR1w3Usi2u BpzvrBGOI9M/1snImXDynjsDnraMcyfdAgTJ4sHmkadfFxDRd+veqPWJlOLpPtlTwd/9Ia MN3n6hgFCcr7fGs+9e3YUjikKCmzg0r8bN4/G1RmxPKv2D9kpTCziUufYrcUuA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649416469; a=rsa-sha256; cv=none; b=NyzkQYnw9EkFAz5oOmjM4k+WMKdyljH4w9H3KOYLL3/lSfbdOwfMsk9/9sfaLQ9U6QlwbB TZRXIV3oCBtIYl6Jgy9kwMrDXMd0yzA9TuXp7CtdeIyMAlvIxHRdj2/TkBbYzGf9+TUe5F tbUnzJbaWHKGZlEqtrVxOGwU5eI/y2CeTWuUVBVXiMkTTuMYdCXEM1uopIx0/omBCdMwH2 W12zvrJ634Fd037bWR/5gP+AYWjxKzGmYbV3roX0QPVmKWD76tz587NCuXJEcRwZon1lkR 9gO9p5BqVEax7ZkE+2Uxi1hknhkT+le2uRMD9pPvvK7B+8GSHDmOvYbwpyRrpg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------TD2ASvjzfpo4JyxrFz8JyiVP Content-Type: multipart/mixed; boundary="------------O0ssWPEiEQcQgZRJEKUGD0ko"; protected-headers="v1" From: Stefan Esser To: egoitz@ramattack.net Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Message-ID: Subject: Re: Desperate with 870 QVO and ZFS References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> In-Reply-To: --------------O0ssWPEiEQcQgZRJEKUGD0ko Content-Type: multipart/alternative; boundary="------------5zqkLuBRyXvluXGRQjtNvCUK" --------------5zqkLuBRyXvluXGRQjtNvCUK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 07.04.22 um 14:30 schrieb egoitz@ramattack.net: > El 2022-04-06 23:49, Stefan Esser escribi=C3=B3: >>> >>> El 2022-04-06 17:43, Stefan Esser escribi=C3=B3: >>> >>> >>> Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: >>> >>> Hi Rainer! >>> >>> Thank you so much for your help :) :) >>> >>> Well I assume they are in a datacenter and should not be a po= wer >>> outage.... >>> >>> About dataset size... yes... our ones are big... they can be = 3-4 TB >>> easily each >>> dataset..... >>> >>> We bought them, because as they are for mailboxes and mailbox= es >>> grow and >>> grow.... for having space for hosting them... >>> >>> >>> Which mailbox format (e.g. mbox, maildir, ...) do you use? >>> =C2=A0 >>> *I'm running Cyrus imap so sort of Maildir... too many little fil= es >>> normally..... Sometimes directories with tons of little files....= * >>> >> Assuming that many mails are much smaller than the erase block size of= the >> SSD, this may cause issues. (You may know the following ...) >> >> For example, if you have message sizes of 8 KB and an erase block size= of 64 >> KB (just guessing), then 8 mails will be in an erase block. If half th= e >> mails are deleted, then the erase block will still occupy 64 KB, but o= nly >> hold 32 KB of useful data (and the SSD will only be aware of this fact= if >> TRIM has signaled which data is no longer relevant). The SSD will copy= >> several partially filled erase blocks together in a smaller number of = free >> blocks, which then are fully utilized. Later deletions will repeat thi= s >> game, and your data will be copied multiple times until it has aged (a= nd the >> user is less likely to delete further messages). This leads to "write >> amplification" - data is internally moved around and thus written mult= iple >> times. >> >> >> *Stefan!! you are nice!! I think this could explain all our problem. S= o, why >> we are having the most randomness in our performance degradation and t= hat >> does not necessarily has to match with the most io peak hours... That = I >> could cause that performance degradation just by deleting a couple of = huge >> (perhaps 200.000 mails) mail folders in a middle traffic hour time!!* >> Yes, if deleting large amounts of data triggers performance issues (and t= he disk does not have a deficient TRIM implementation), then the issue is li= kely to be due to internal garbage collections colliding with other operations= =2E >> >> *The problem is that by what I know, erase block size of an SSD disk i= s >> something fixed in the disk firmware. I don't really know if perhaps i= t >> could be modified with Samsung magician or those kind of tool of Samsu= ng.... >> else I don't really see the manner of improving it... because apart fr= om >> that, you are deleting a file in raidz-2 array... no just in a disk...= I >> assume aligning chunk size, with record size and with the "secret" era= se >> size of the ssd, perhaps could be slightly compensated?.* >> The erase block size is a fixed hardware feature of each flash chip. Ther= e is a block size for writes (e.g. 8 KB) and many such blocks are combined in on= e erase block (of e.g. 64 KB, probably larger in todays SSDs), they can onl= y be returned to the free block pool all together. And if some of these writab= le blocks hold live data, they must be preserved by collecting them in newly= allocated free blocks. An example of what might happen, showing a simplified layout of files 1, = 2, 3 (with writable blocks 1a, 1b, ..., 2a, 2b, ... and "--" for stale data of= deleted files, ".." for erased/writable flash blocks) in an SSD might be:= erase block 1: |1a|1b|--|--|2a|--|--|3a| erase block 2; |--|--|--|2b|--|--|--|1c| erase block 3; |2c|1d|3b|3c|--|--|--|--| erase block 4; |..|..|..|..|..|..|..|..| This is just a random example how data could be laid out on the physical storage array. It is assumed that the 3 erase blocks once were completely= occupied In this example, 10 of 32 writable blocks are occupied, and only one free= erase block exists. This situation must not persist, since the SSD needs more empty erase blo= cks. 10/32 of the capacity is used for data, but 3/4 of the blocks are occupie= d and not immediately available for new data. The garbage collection might combine erase blocks 1 and 3 into a currentl= y free one, e.g. erase block 4: erase block 1; |..|..|..|..|..|..|..|..| erase block 2; |--|--|--|2b|--|--|--|1c| erase block 3; |..|..|..|..|..|..|..|..| erase block 4: |1a|1b|2a|3a|2c|1d|3b|3c| Now only 2/4 of the capacity is not available for new data (which is stil= l a lot more than 10/32, but better than before). Now assume file 2 is deleted: erase block 1; |..|..|..|..|..|..|..|..| erase block 2; |--|--|--|--|--|--|--|1c| erase block 3; |..|..|..|..|..|..|..|..| erase block 4: |1a|1b|--|3a|--|1d|3b|3c| There is now a new sparsely used erase block 4, and it will soon need to = be garbage collected, too - in fact it could be combined with the live data = from erase block 2, but this may be delayed until there is demand for more era= sed blocks (since e.g. file 1 or 3 might also have been deleted by then). The garbage collection does not know which data blocks belong to which fi= le, and therefore it cannot collect the data belonging to a file into a singl= e erase block. Blocks are allocated as data comes in (as long as enough SLC= cells are available in this area, else directly in QLC cells). Your many parall= el updates will cause fractions of each larger file to be spread out over ma= ny erase blocks. As you can see, a single file that is deleted may affect many erase block= s, and you have to take redundancy into consideration, which will multiply the e= ffect by a factor of up to 3 for small files (one ZFS allocation block). And remember: deleting a message in mdir format will free the data blocks, bu= t will also remove the directory entry, causing additional meta-data writes (aga= in multiplied by the raid redundancy). A consumer SSD would normally see only very few parallel writes, and sequ= ential writes of full files will have a high chance to put the data of each file= contiguously in the minimum number of erase blocks, allowing to free mult= iple complete erase blocks when such a file is deleted and thus obviating the = need for many garbage collection copies (that occur if data from several indep= endent files is in one erase block). Actual SSDs have many more cells than advertised. Some 10% to 20% may be = kept as a reserve for aging blocks that e.g. may have failed kind of a "read-after-write test" (implemented in the write function, which adds ch= arges to the cells until they return the correct read-outs). BTW: Having an ashift value that is lower than the internal write block s= ize may also lead to higher write amplification values, but a large ashift ma= y lead to more wasted capacity, which may become an issue if typical file length= are much smaller than the allocation granularity that results from the ashift= value. >> Larger mails are less of an issue since they span multiple erase block= s, >> which will be completely freed when such a message is deleted. >> >> *I see I see Stefan...* >> >> Samsung has a lot of experience and generally good strategies to deal = with >> such a situation, but SSDs specified for use in storage systems might = be >> much better suited for that kind of usage profile. >> >> *Yes... and the disks for our purpose... perhaps weren't QVOs....* >> You should have got (much more expensive) server grade SSDs, IMHO. But even 4 * 2 TB QVO (or better EVO) drives per each 8 TB QVO drive woul= d result in better performance (but would need a lot of extra SATA ports). In fact, I'm not sure whether rotating media and a reasonable L2ARC consi= sting of a fast M.2 SSD plus a mirror of small SSDs for a LOG device would not = be a better match for your use case. Reading the L2ARC would be very fast, wri= tes would be purely sequential and relatively slow, you could choose a suitab= le L2ARC strategy (caching of file data vs. meta data), and the LOG device w= ould support fast fsync() operations required for reliable mail systems (which= confirm data is on stable storage before acknowledging the reception to t= he sender). >>> We knew they had some speed issues, but those speed issues, w= e >>> thought (as >>> Samsung explains in the QVO site) they started after exceedin= g the >>> speeding >>> buffer this disks have. We though that meanwhile you didn't e= xceed it's >>> capacity (the capacity of the speeding buffer) no speed probl= em >>> arises. Perhaps >>> we were wrong?. >>> >>> >>> These drives are meant for small loads in a typical PC use case, >>> i.e. some installations of software in the few GB range, else onl= y >>> files of a few MB being written, perhaps an import of media files= >>> that range from tens to a few hundred MB at a time, but less ofte= n >>> than once a day. >>> =C2=A0 >>> *We move, you know... lots of little files... and lot's of differ= ent >>> concurrent modifications by 1500-2000 concurrent imap connections= we >>> have...* >>> >> I do not expect the read load to be a problem (except possibly when th= e SSD >> is moving data from SLC to QLC blocks, but even then reads will get >> priority). But writes and trims might very well overwhelm the SSD, >> especially when its getting full. Keeping a part of the SSD unused (ex= cluded >> from the partitions created) will lead to a large pool of unused block= s. >> This will reduce the write amplification - there are many free blocks = in the >> "unpartitioned part" of the SSD, and thus there is less urgency to com= pact >> partially filled blocks. (E.g. if you include only 3/4 of the SSD capa= city >> in a partition used for the ZPOOL, then 1/4 of each erase block could = be >> free due to deletions/TRIM without any compactions required to hold al= l this >> data.) >> >> Keeping a significant percentage of the SSD unallocated is a good stra= tegy >> to improve its performance and resilience. >> >> *Well, we have allocated all the disk space... but not used... just >> allocated.... you know... we do a zpool create with the whole disks...= =2E.* >> I think the only chance for a solution that does not require new hardware= is to make sure, only some 80% of the SSDs are used (i.e. allocate only 80% for= ZFS, leave 20% unallocated). This will significantly reduce the rate of garbag= e collections and thus reduce the load they cause. I'd use a fast encryption algorithm (zstd - choose a level that does not overwhelm the CPU, there are benchmark results for ZFS with zstd, and I f= ound zstd-2 to be best for my use case). This will more than make up for the s= pace you left unallocated on the SSDs. A different mail box format might help, too - I'm happy with dovecot's md= box format, which is as fast but much more efficient than mdir. >>> As the SSD fills, the space available for the single level write >>> cache gets smaller >>> =C2=A0 >>> *The single level write cache is the cache these ssd drivers have= , for >>> compensating the speed issues they have due to using qlc memory?.= Do >>> you refer to that?. Sorry I don't understand well this paragraph.= * >>> >> Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SL= C >> cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cel= ls as >> 24 GB of data in QLC mode. >> >> *Ok, true.... yes....* >> >> A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (= 600 GB >> in 150 tn QLC cells plus 100 GB in 100 tn SLC cells). >> >> *Ahh! you mean that SLC capacity for speeding up the QLC disks, is obt= ained >> from each single layer of the QLC?.* >> There are no specific SLC cells. A fraction of the QLC capable cells is o= nly written with only 1 instead of 4 bits. This is a much simpler process, si= nce there are only 2 charge levels per cell that are used, while QLC uses 16 = charge levels, and you can only add charge (must not overshoot), therefore only = small increments are added until the correct value can be read out). But since SLC cells take away specified capacity (which is calculated ass= uming all cells hold 4 bits each, not only 1 bit), their number is limited and shrinks as demand for QLC cells grows. The advantage of the SLC cache is fast writes, but also that data in it m= ay have become stale (trimmed) and thus will never be copied over into a QLC= block. But as the SSD fills and the size of the SLC cache shrinks, this capability will be mostly lost, and lots of very short lived data is stor= ed in QLC cells, which will quickly become partially stale and thus needing compaction as explained above. >> Therefore, the fraction of the cells used as an SLC cache is reduced w= hen it >> gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cell= s). >> >> *Sorry I don't get this last sentence... don't understand it because I= don't >> really know the meaning of tn... * >> >> *but I think I'm getting the idea if you say that each QLC layer, has = it's >> own SLC cache obtained from the disk space avaiable for each QLC layer= =2E...* >> >> And with less SLC cells available for short term storage of data the >> probability of data being copied to QLC cells before the irrelevant me= ssages >> have been deleted is significantly increased. And that will again lead= to >> many more blocks with "holes" (deleted messages) in them, which then n= eed to >> be copied possibly multiple times to compact them. >> >> *If I correct above, I think I got the idea yes....* >> >>> (on many SSDs, I have no numbers for this >>> particular device), and thus the amount of data that can be >>> written at single cell speed shrinks as the SSD gets full. >>> =C2=A0 >>> >>> I have just looked up the size of the SLC cache, it is specified >>> to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB= >>> version, smaller models will have a smaller SLC cache). >>> =C2=A0 >>> *Assuming you were talking about the cache for compensating speed= we >>> previously commented, I should say these are the 870 QVO but the = 8TB >>> version. So they should have the biggest cache for compensating t= he >>> speed issues...* >>> >> I have looked up the data: the larger versions of the 870 QVO have the= same >> SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 G= B more >> if there are enough free blocks. >> >> *Ours one is the 8TB model so I assume it could have bigger limits. Th= e >> disks are mostly empty, really.... so... for instance....* >> >> *zpool list* >> *NAME=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 SIZE=C2=A0 ALLOC=C2=A0=C2=A0 FREE=C2=A0 CKPOINT=C2=A0 EXPANDSZ=C2=A0= =C2=A0 FRAG=C2=A0=C2=A0=C2=A0 CAP=C2=A0 >> DEDUP=C2=A0 HEALTH=C2=A0 ALTROOT* >> *root_dataset=C2=A0 448G=C2=A0 2.29G=C2=A0=C2=A0 446G=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -=C2=A0=C2=A0=C2=A0=C2=A0 1%=C2=A0=C2=A0=C2=A0=C2=A0 0%=C2=A0 1.00x=C2=A0= >> ONLINE=C2=A0 -* >> *mail_dataset=C2=A0 58.2T=C2=A0 11.8T=C2=A0 46.4T=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -= =C2=A0=C2=A0=C2=A0 26%=C2=A0=C2=A0=C2=A0 20%=C2=A0 1.00x=C2=A0 >> ONLINE=C2=A0 -* >> Ok, seems you have got 10 * 8 TB in a raidz2 configuration. Only 20% of the mail dataset is in use, the situation will become much wo= rse when the pool will fill up! >> *I suppose fragmentation affects too....* >> On magnetic media fragmentation means that a file is spread out over the = disk in a non-optimal way, causing access latencies due to seeks and rotationa= l delay. That kind of fragmentation is not really relevant for SSDs, which = allow for fast random access to the cells. And the FRAG value shown by the "zpool list" command is not about fragmen= tation of files at all, it is about the structure of free space. Anyway less rel= evant for SSDs than for classic hard disk drives. >>> But after writing those few GB at a speed of some 500 MB/s (i.e. >>> after 12 to 150 seconds), the drive will need several minutes to >>> transfer those writes to the quad-level cells, and will operate >>> at a fraction of the nominal performance during that time. >>> (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for t= he >>> 2 TB model.) >>> =C2=A0 >>> *Well we are in the 8TB model. I think I have understood what you= wrote >>> in previous paragraph. You said they can be fast but not constant= ly, >>> because later they have to write all that to their perpetual stor= age >>> from the cache. And that's slow. Am I wrong?. Even in the 8TB mod= el you >>> think Stefan?.* >>> >> The controller in the SSD supports a given number of channels (e.g 4),= each >> of which can access a Flash chip independently of the others. Small SS= Ds >> often have less Flash chips than there are channels (and thus a lower >> throughput, especially for writes), but the larger models often have m= ore >> chips than channels and thus the performance is capped. >> >> *This is totally logical. If a QVO disk would outperform best or simil= ar >> than an Intel without consequences.... who was going to buy a expensiv= e >> Intel enterprise?.* >> The QVO is bandwidth limited due to the SATA data rate of 6 Mbit/s anyway= , and it is optimized for reads (which are not significantly slower than offere= d by the TLC models). This is a viable concept for a consumer PC, but not for = a server. >> >> In the case of the 870 QVO, the controller supports 8 channels, which = allows >> it to write 160 MB/s into the QLC cells. The 1 TB model apparently has= only >> 4 Flash chips and is thus limited to 80 MB/s in that situation, while = the >> larger versions have 8, 16, or 32 chips. But due to the limited number= of >> channels, the write rate is limited to 160 MB/s even for the 8 TB mode= l. >> >> *Totally logical Stefan...* >> >> If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in t= his limit. >> >>> *The main problem we are facing is that in some peak moments, whe= n the >>> machine serves connections for all the instances it has, and only= as >>> said in some peak moments... like the 09am or the 11am.... it see= ms the >>> machine becomes slower... and like if the disks weren't able to s= erve >>> all they have to serve.... In these moments, no big files are mov= ed... >>> but as we have 1800-2000 concurrent imap connections... normally = they >>> are doing each one... little changes in their mailbox. Do you thi= nk >>> perhaps this disks then are not appropriate for this kind of usag= e?-* >>> >> I'd guess that the drives get into a state in which they have to recyc= le >> lots of partially free blocks (i.e. perform kind of a garbage collecti= on) >> and then three kinds of operations are competing with each other: >> >> 1. reads (generally prioritized) >> 2. writes (filling the SLC cache up to its maximum size) >> 3. compactions of partially filled blocks (required to make free bloc= ks >> available for re-use) >> >> Writes can only proceed if there are sufficient free blocks, which on = a >> filled SSD with partially filled erase blocks means that operations of= type >> 3. need to be performed with priority to not stall all writes. >> >> My assumption is that this is what you are observing under peak load. >> >> *It could be although the disks are not filled.... the pool are at 20 = or 30% >> of capacity and fragmentation from 20%-30% (as zpool list states).* >> Yes, and that means that your issues will become much more critical over = time when the free space shrinks and garbage collections will be required at a= n even faster rate, with the SLC cache becoming less and less effective to weed = out short lived files as an additional factor that will increase write amplif= ication. >>> >>> And cheap SSDs often have no RAM cache (not checked, but I'd be >>> surprised if the QVO had one) and thus cannot keep bookkeeping da= te >>> in such a cache, further limiting the performance under load. >>> =C2=A0 >>> *This brochure >>> (https://semiconductor.samsung.com/resources/brochure/870_Series_= Brochure.pdf >>> and the datasheet >>> https://semiconductor.samsung.com/resources/data-sheet/Samsung_SS= D_870_QVO_Data_Sheet_Rev1.1.pdf) >>> sais if I have read properly, the 8TB drive has 8GB of ram?. I as= sume >>> that is what they call the turbo write cache?.* >>> >> No, the turbo write cache consists of the cells used in SLC mode (whic= h can >> be any cells, not only cells in a specific area of the flash chip). >> >> *I see I see....* >> >> The RAM is needed for fast lookup of the position of data for reads an= d of >> free blocks for writes. >> >> *Our ones... seem to have 8GB LPDDR4 of ram.... as datasheet states...= =2E* >> Yes, and it makes sense that the RAM size is proportional to the capacity= since a few bytes are required per addressable data block. If the block size was 8 KB the RAM could hold 8 bytes (e.g. a pointer and= some status flags) for each logically addressable block. But there is no infor= mation about the actual internal structure of the QVO that I know of. [...] >> >> *I see.... It's extremely misleading you know... because... you can co= py >> five mailboxes of 50GB concurrently for instance.... and you flood a g= igabit >> interface copying (obviously because disks can keep that throughput)..= =2E but >> later.... you see... you are in an hour that yesterday, and even 4 day= s >> before you have not had any issues... and that day... you see the comm= ented >> issue... even not being exactly at a peak hour (perhaps is two hours l= ater >> the peak hour even)... or... but I wasn't noticing about all things yo= u say >> in this email....* >> >> I have seen advice to not use compression in a high load scenario in s= ome >> other reply. >> >> I tend to disagree: Since you seem to be limited when the SLC cache is= >> exhausted, you should get better performance if you compress your data= =2E I >> have found that zstd-2 works well for me (giving a significant overall= >> reduction of size at reasonable additional CPU load). Since ZFS allows= to >> switch compressions algorithms at any time, you can experiment with >> different algorithms and levels. >> >> *I see... you say compression should be enabled.... The main reason be= cause >> we have not enabled it yet, is for keeping the system the most near po= ssible >> to config defaults... you know... for later being able to ask in this >> mailing lists if we have an issue... because you know... it would be f= ar >> more easier to ask about something strange you are seeing when that st= range >> thing is near to a well tested config, like the config by default....*= >> >> *But now you say Stefan... if you switch between compression algorithm= s you >> will end up with a mix of different files compressed in a different >> manner... that is not a bit disaster later?. Doesn't affect performanc= e in >> some manner?.* >> The compression used is stored in the per file information, each file in = a dataset could have been written with a different compression method and l= evel. Blocks are independently compressed - a file level compression may be mor= e effective. Large mail files will contain incompressible attachments (alre= ady compressed), but in base64 encoding. This should allow a compression rati= o of ~1,3. Small files will be plain text or HTML, offering much better compre= ssion factors. >> >> One advantage of ZFS compression is that it applies to the ARC, too. A= nd a >> compression factor of 2 should easily be achieved when storing mail (n= ot for >> .docx, .pdf, .jpg files though). Having more data in the ARC will redu= ce the >> read pressure on the SSDs and will give them more cycles for garbage >> collections (which are performed in the background and required to alw= ays >> have a sufficient reserve of free flash blocks for writes). >> >> *We would use I assume the lz4... which is the less "expensive" compre= ssion >> algorithm for the CPU... and I assume too for avoiding delay accessing= >> data... do you recommend another one?. Do you always recommend compres= sion >> then?.* >> I'd prefer zstd over lz4 since it offers a much higher compression ratio.= Zstd offers higher compression ratios than lz4 at similar or better decompression speed, but may be somewhat slower compressing the data. But= in my opinion this is outweighed by the higher effective amount of data in the ARC/L2ARC possible with zstd. For some benchmarks of different compression algorithms available for ZFS= and compared to uncompressed mode see the extensive results published by Jude= Allan: https://docs.google.com/spreadsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTg= nXm2yPtiUQ/edit?usp=3Dsharing The SQL benchmarks might best resemble your use case - but remember that = a significant reduction of the amount of data being written to the SSDs m= ight be more important than the highest transaction rate, since your SSDs= put a low upper limit on that when highly loaded. >> I'd give it a try - and if it reduces your storage requirements by 10%= only, >> then keep 10% of each SSD unused (not assigned to any partition). That= will >> greatly improve the resilience of your SSDs, reduce the write-amplific= ation, >> will allow the SLC cache to stay at its large value, and may make a la= rge >> difference to the effective performance under high load. >> >> *But when you enable compression... only gets compressed the new data >> modified or entered. Am I wrong?.* >> Compression is per file system data block (at most 1 MB if you set the blocksize to that value). Each such block is compressed independently of = all others, to not require more than 1 block to be read and decompressed when= randomly reading a file. If a block does not shrink when compressed (it m= ay contain compressed file data) the block is written to disk as-is (uncompr= essed). >> >> ** >> >> *By the way, we have more or less 1/4 of each disk used (12 TB allocat= ed in >> a poll stated by zpool list, divided between 8 disks of 8TB...)... do = you >> think we could be suffering on write amplification and so... having a = so >> little disk space used in each disk?.* >> Your use case will cause a lot of garbage collections and this particular= high write amplification values. >> >> Regards, STefan >> >> *Hey mate, your mail is incredible. It has helped as a lot. Can we inv= ite >> you a cup of coffee or a beer through Paypal or similar?. Can I help y= ou in >> some manner?.* >> Thanks, I'm glad to help, and I'd appreciate to hear whether you get your= setup optimized for the purpose (and how well it holds up when you approach the= capacity limits of your drives). I'm always interested in experience of users with different use cases tha= n I have (just being a developer with too much archived mail and media collec= ted over a few decades). Regards, STefan --------------5zqkLuBRyXvluXGRQjtNvCUK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Am 07.04.22 um 14:30 schrieb egoitz@ramattack.net:
El 2022-04-06 23:49, Stefan Esser escribi=C3=B3:

El 2022-04-06 17:43, Stefan Esser escribi=C3=B3:


Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net:
Hi Rainer!

Thank you so much for your help :) :)

Well I assume they are in a datacenter and should not be a power outage....

About dataset size... yes... our ones are big... they can be 3-4 TB easily each
dataset.....

We bought them, because as they are for mailboxes and mailboxes grow and
grow.... for having space for hosting them...
Which mailbox format (e.g. mbox, maildir, ...) do you use?<= /div>
=C2=A0
I'm running Cyrus imap so sort of Maildir... too many little files normally..... Sometimes directories with tons of little files....

Assuming that many mails are much smaller than the erase block size of the SSD, this may cause issues. (You may know the following ...)

For example, if you have message sizes of 8 KB and an erase block size of 64 KB (just guessing), then 8 mails will be in an erase block. If half the mails are deleted, then the erase block will still occupy 64 KB, but only hold 32 KB of useful data (and the SSD will only be aware of this fact if TRIM has signaled which data is no longer relevant). The SSD will copy several partially filled erase blocks together in a smaller number of free blocks, which then are fully utilized. Later deletions will repeat this game, and your data will be copied multiple times until it has aged (and the user is less likely to delete further messages). This leads to "write amplification" - data is internally moved around and thus written multiple times.


Stefan!! you are nice!= ! I think this could explain all our problem. So, why we are having the most randomness in our performance degradation and that does not necessarily has to match with the most io peak hours... That I could cause that performance degradation just by deleting a couple of huge (perhaps 200.000 mails) mail folders in a middle traffic hour time!!

Yes, if deleting large amounts of data triggers performance issues (and the disk does not have a deficient TRIM implementation), then the issue is likely to be due to internal garbage collections colliding with other operations.

The problem is that by= what I know, erase block size of an SSD disk is something fixed in the disk firmware. I don't really know if perhaps it could be modified with Samsung magician or those kind of tool of Samsung.... else I don't really see the manner of improving it... because apart from that, you are deleting a file in raidz-2 array... no just in a disk... I assume aligning chunk size, with record size and with the "secret" erase size of the ssd, perhaps could be slightly compensated?.

The erase block size is a fixed hardware feature of each flash chip. There is a block size for writes (e.g. 8 KB) and many such blocks are combined in one erase block (of e.g. 64 KB, probably larger in todays SSDs), they can only be returned to the free block pool all together. And if some of these writable blocks hold live data, they must be preserved by collecting them in newly allocated free blocks.

An example of what might happen, showing a simplified layout of files 1, 2, 3 (with writable blocks 1a, 1b, ..., 2a, 2b, ... and "--" for stale data of deleted files, ".." for erased/writable flash blocks) in an SSD might be:

erase block 1: |1a|1b|--|--|2a|--|--|3a|<= /font>

erase block 2; |--|--|--|2b|--|--|--|1c|<= /font>

erase block 3; |2c|1d|3b|3c|--|--|--|--|<= /font>

erase block 4; |..|..|..|..|..|..|..|..|<= /font>

This is just a random example how data could be laid out on the physical storage array. It is assumed that the 3 erase blocks once were completely occupied

In this example, 10 of 32 writable blocks are occupied, and only one free erase block exists.

This situation must not persist, since the SSD needs more empty erase blocks. 10/32 of the capacity is used for data, but 3/4 of the blocks are occupied and not immediately available for new data.

The garbage collection might combine erase blocks 1 and 3 into a currently free one, e.g. erase block 4:

erase block 1; |..|..|..|..|..|..|..|..|

erase block 2; |--|--|--|2b|--|--|--|1c|<= /font>

erase block 3; |..|..|..|..|..|..|..|..|<= /font>

erase block 4: |1a|1b|2a|3a|2c|1d|3b|3c|<= /font>

Now only 2/4 of the capacity is not available for new data (which is still a lot more than 10/32, but better than before).

Now assume file 2 is deleted:

erase block 1; |..|..|..|..|..|..|..|..| =

erase block 2; |--|--|--|--|--|--|--|1c|<= /font>

erase block 3; |..|..|..|..|..|..|..|..|<= /font>

erase block 4: |1a|1b|--|3a|--|1d|3b|3c|<= /font>

There is now a new sparsely used erase block 4, and it will soon need to be garbage collected, too - in fact it could be combined with the live data from erase block 2, but this may be delayed until there is demand for more erased blocks (since e.g. file 1 or 3 might also have been deleted by then).

The garbage collection does not know which data blocks belong to which file, and therefore it cannot collect the data belonging to a file into a single erase block. Blocks are allocated as data comes in (as long as enough SLC cells are available in this area, else directly in QLC cells). Your many parallel updates will cause fractions of each larger file to be spread out over many erase blocks.

As you can see, a single file that is deleted may affect many erase blocks, and you have to take redundancy into consideration, which will multiply the effect by a factor of up to 3 for small files (one ZFS allocation block). And remember: deleting a message in mdir format will free the data blocks, but will also remove the directory entry, causing additional meta-data writes (again multiplied by the raid redundancy).

A consumer SSD would normally see only very few parallel writes, and sequential writes of full files will have a high chance to put the data of each file contiguously in the minimum number of erase blocks, allowing to free multiple complete erase blocks when such a file is deleted and thus obviating the need for many garbage collection copies (that occur if data from several independent files is in one erase block).

Actual SSDs have many more cells than advertised. Some 10% to 20% may be kept as a reserve for aging blocks that e.g. may have failed kind of a "read-after-write test" (implemented in the write function, which adds charges to the cells until they return the correct read-outs).

BTW: Having an ashift value that is lower than the internal write block size may also lead to higher write amplification values, but a large ashift may lead to more wasted capacity, which may become an issue if typical file length are much smaller than the allocation granularity that results from the ashift value.

Larger mails are less of an issue since they span multiple erase blocks, which will be completely freed when such a message is deleted.

I see I see Stefan...<= /span>

Samsung has a lot of experience and generally good strategies to deal with such a situation, but SSDs specified for use in storage systems might be much better suited for that kind of usage profile.

Yes... and the disks for our purpose... perhaps weren't QVOs....=

You should have got (much more expensive) server grade SSDs, IMHO.

But even 4 * 2 TB QVO (or better EVO) drives per each 8 TB QVO drive would result in better performance (but would need a lot of extra SATA ports).

In fact, I'm not sure whether rotating media and a reasonable L2ARC consisting of a fast M.2 SSD plus a mirror of small SSDs for a LOG device would not be a better match for your use case. Reading the L2ARC would be very fast, writes would be purely sequential and relatively slow, you could choose a suitable L2ARC strategy (caching of file data vs. meta data), and the LOG device would support fast fsync() operations required for reliable mail systems (which confirm data is on stable storage before acknowledging the reception to the sender).

We knew they had some speed issues, but those speed issues, we thought (as
Samsung explains in the QVO site) they started after exceeding the speeding
buffer this disks have. We though that meanwhile you didn't exceed it's
capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps
we were wrong?.

These drives are meant for small loads in a typical PC use case,
i.e. some installations of software in the few GB range, else only
files of a few MB being written, perhaps an import of media files
that range from tens to a few hundred MB at a time, but less often
than once a day.
=C2=A0
We move= , you know... lots of little files... and lot's of different concurrent modifications by 1500-2000 concurrent imap connections we have...<= /div>

I do not expect the read load to be a problem (except possibly when the SSD is moving data from SLC to QLC blocks, but even then reads will get priority). But writes and trims might very well overwhelm the SSD, especially when its getting full. Keeping a part of the SSD unused (excluded from the partitions created) will lead to a large pool of unused blocks. This will reduce the write amplification - there are many free blocks in the "unpartitioned part" of the SSD, and thus there is less urgency to compact partially filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a partition used for the ZPOOL, then 1/4 of each erase block could be free due to deletions/TRIM without any compactions required to hold all this data.)

Keeping a significant percentage of the SSD unallocated is a good strategy to improve its performance and resilience.

Well, we have allocate= d all the disk space... but not used... just allocated.... you know... we do a zpool create with the whole disks.....<= /span>

I think the only chance for a solution that does not require new hardware is to make sure, only some 80% of the SSDs are used (i.e. allocate only 80% for ZFS, leave 20% unallocated). This will significantly reduce the rate of garbage collections and thus reduce the load they cause.

I'd use a fast encryption algorithm (zstd - choose a level that does not overwhelm the CPU, there are benchmark results for ZFS with zstd, and I found zstd-2 to be best for my use case). This will more than make up for the space you left unallocated on the SSDs.

A different mail box format might help, too - I'm happy with dovecot's mdbox format, which is as fast but much more efficient than mdir.

As the SSD fills, the space available for the single level write
cache gets smaller
=C2=A0
The single level write cache is the cache these ssd drivers have, for compensating the speed issues they have due to using qlc memory?. Do you refer to that?. Sorry I don't understand well this paragraph.

Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as 24 GB of data in QLC mode.

Ok, true.... yes....

A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (600 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells).

Ahh! you mean that SLC= capacity for speeding up the QLC disks, is obtained from each single layer of the QLC?.

There are no specific SLC cells. A fraction of the QLC capable cells is only written with only 1 instead of 4 bits. This is a much simpler process, since there are only 2 charge levels per cell that are used, while QLC uses 16 charge levels, and you can only add charge (must not overshoot), therefore only small increments are added until the correct value can be read out).

But since SLC cells take away specified capacity (which is calculated assuming all cells hold 4 bits each, not only 1 bit), their number is limited and shrinks as demand for QLC cells grows.<= /p>

The advantage of the SLC cache is fast writes, but also that data in it may have become stale (trimmed) and thus will never be copied over into a QLC block. But as the SSD fills and the size of the SLC cache shrinks, this capability will be mostly lost, and lots of very short lived data is stored in QLC cells, which will quickly become partially stale and thus needing compaction as explained above.

Therefore, the fraction of the cells used as an SLC cache is reduced when it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cells).

Sorry I don't get this= last sentence... don't understand it because I don't really know the meaning of tn...

but I think I'm gettin= g the idea if you say that each QLC layer, has it's own SLC cache obtained from the disk space avaiable for each QLC layer....

And with less SLC cells available for short term storage of data the probability of data being copied to QLC cells before the irrelevant messages have been deleted is significantly increased. And that will again lead to many more blocks with "holes" (deleted messages) in them, which then need to be copied possibly multiple times to compact them.

If I correct above, I think I got the idea yes....

(on many SSDs, I have no numbers for this
particular device), and thus the amount of data that can be
written at single cell speed shrinks as the SSD gets full.<= /div>
=C2=A0

I have just looked up the size of the SLC cache, it is specified
to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB
version, smaller models will have a smaller SLC cache).
=C2=A0
Assumin= g you were talking about the cache for compensating speed we previously commented, I should say these are the 870 QVO but the 8TB version. So they should have the biggest cache for compensating the speed issues...<= /span>

I have looked up the data: the larger versions of the 870 QVO have the same SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB more if there are enough free blocks.

Ours one is the 8TB model so I assume it could have bigger limits. The disks are mostly empty, really.... so... for instance....<= /strong>

zpool list
NAME=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SIZE=C2=A0 ALLOC=C2=A0=C2=A0 FREE=C2=A0 CKPOINT=C2=A0 EXPANDSZ=C2=A0=C2= =A0 FRAG=C2=A0=C2=A0=C2=A0 CAP=C2=A0 DEDUP=C2=A0 HEALTH=C2=A0 ALTROOT
root_dataset=C2=A0 448G= =C2=A0 2.29G=C2=A0=C2=A0 446G=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0= =C2=A0 1%=C2=A0=C2=A0=C2=A0=C2=A0 0%=C2=A0 1.00x=C2=A0 ONLINE=C2=A0 -
mail_dataset=C2=A0 58.2= T=C2=A0 11.8T=C2=A0 46.4T=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -=C2=A0=C2=A0=C2=A0 26= %=C2=A0=C2=A0=C2=A0 20%=C2=A0 1.00x=C2=A0 ONLINE=C2=A0 -

Ok, seems you have got 10 * 8 TB in a raidz2 configuration.

Only 20% of the mail dataset is in use, the situation will become much worse when the pool will fill up!

I suppose fragmentatio= n affects too....

On magnetic media fragmentation means that a file is spread out over the disk in a non-optimal way, causing access latencies due to seeks and rotational delay. That kind of fragmentation is not really relevant for SSDs, which allow for fast random access to the cells.

And the FRAG value shown by the "zpool list" command is not about fragmentation of files at all, it is about the structure of free space. Anyway less relevant for SSDs than for classic hard disk drives.

But after writing those few GB at a speed of some 500 MB/s (i.e.
after 12 to 150 seconds), the drive will need several minutes to
transfer those writes to the quad-level cells, and will operate
at a fraction of the nominal performance during that time.<= br> (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the
2 TB model.)
=C2=A0
Well we= are in the 8TB model. I think I have understood what you wrote in previous paragraph. You said they can be fast but not constantly, because later they have to write all that to their perpetual storage from the cache. And that's slow. Am I wrong?. Even in the 8TB model you think Stefan?.

The controller in the SSD supports a given number of channels (e.g 4), each of which can access a Flash chip independently of the others. Small SSDs often have less Flash chips than there are channels (and thus a lower throughput, especially for writes), but the larger models often have more chips than channels and thus the performance is capped.

This is totally logical. If a QVO disk would outperform best or similar than an Intel without consequences.... who was going to buy a expensive Intel enterprise?.

The QVO is bandwidth limited due to the SATA data rate of 6 Mbit/s anyway, and it is optimized for reads (which are not significantly slower than offered by the TLC models). This is a viable concept for a consumer PC, but not for a server.

In the case of the 870 QVO, the controller supports 8 channels, which allows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has only 4 Flash chips and is thus limited to 80 MB/s in that situation, while the larger versions have 8, 16, or 32 chips. But due to the limited number of channels, the write rate is limited to 160 MB/s even for the 8 TB model.

Totally logical Stefan...

If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in this limit.

The mai= n problem we are facing is that in some peak moments, when the machine serves connections for all the instances it has, and only as said in some peak moments... like the 09am or the 11am.... it seems the machine becomes slower... and like if the disks weren't able to serve all they have to serve.... In these moments, no big files are moved... but as we have 1800-2000 concurrent imap connections... normally they are doing each one... little changes in their mailbox. Do you think perhaps this disks then are not appropriate for this kind of usage?-

I'd guess that the drives get into a state in which they have to recycle lots of partially free blocks (i.e. perform kind of a garbage collection) and then three kinds of operations are competing with each other:

  1. reads (generally prioritized)
  2. writes (filling the SLC cache up to its maximum size)
  3. compactions of partially filled blocks (required to make free blocks available for re-use)

Writes can only proceed if there are sufficient free blocks, which on a filled SSD with partially filled erase blocks means that operations of type 3. need to be performed with priority to not stall all writes.

My assumption is that this is what you are observing under peak load.

It could be although the disks are not filled.... the pool are at 20 or 30% of capacity and fragmentation from 20%-30% (as zpool list states).

Yes, and that means that your issues will become much more critical over time when the free space shrinks and garbage collections will be required at an even faster rate, with the SLC cache becoming less and less effective to weed out short lived files as an additional factor that will increase write amplification.
And cheap SSDs often have no RAM cache (not checked, but I'd be
surprised if the QVO had one) and thus cannot keep bookkeeping date
in such a cache, further limiting the performance under load.
=C2=A0
This brochure (https://semiconductor.samsun= g.com/resources/brochure/870_Series_Brochure.pdf and the datasheet https://semiconductor.samsun= g.com/resources/data-sheet/Samsung_SSD_870_QVO_Data_Sheet_Rev1.1.pdf)= sais if I have read properly, the 8TB drive has 8GB of ram?. I assume that is what they call the turbo write cache?.

No, the turbo write cache consists of the cells used in SLC mode (which can be any cells, not only cells in a specific area of the flash chip).

I see I see....=

The RAM is needed for fast lookup of the position of data for reads and of free blocks for writes.

Our ones... seem to have 8GB LPDDR4 of ram.... as datasheet states....

Yes, and it makes sense that the RAM size is proportional to the capacity since a few bytes are required per addressable data block.

If the block size was 8 KB the RAM could hold 8 bytes (e.g. a pointer and some status flags) for each logically addressable block. But there is no information about the actual internal structure of the QVO that I know of.

[...]

I see.... It's extremely misleading you know... because... you can copy five mailboxes of 50GB concurrently for instance.... and you flood a gigabit interface copying (obviously because disks can keep that throughput)... but later.... you see... you are in an hour that yesterday, and even 4 days before you have not had any issues... and that day... you see the commented issue... even not being exactly at a peak hour (perhaps is two hours later the peak hour even)... or... but I wasn't noticing about all things you say in this email....

I have seen advice to not use compression in a high load scenario in some other reply.

I tend to disagree: Since you seem to be limited when the SLC cache is exhausted, you should get better performance if you compress your data. I have found that zstd-2 works well for me (giving a significant overall reduction of size at reasonable additional CPU load). Since ZFS allows to switch compressions algorithms at any time, you can experiment with different algorithms and levels.

I see... you say compression should be enabled.... The main reason because we have not enabled it yet, is for keeping the system the most near possible to config defaults... you know... for later being able to ask in this mailing lists if we have an issue... because you know... it would be far more easier to ask about something strange you are seeing when that strange thing is near to a well tested config, like the config by default....

But now you say Stefan... if you switch between compression algorithms you will end up with a mix of different files compressed in a different manner... that is not a bit disaster later?. Doesn't affect performance in some manner?.=

The compression used is stored in the per file information, each file in a dataset could have been written with a different compression method and level. Blocks are independently compressed - a file level compression may be more effective. Large mail files will contain incompressible attachments (already compressed), but in base64 encoding. This should allow a compression ratio of ~1,3. Small files will be plain text or HTML, offering much better compression factors.

One advantage of ZFS compression is that it applies to the ARC, too. And a compression factor of 2 should easily be achieved when storing mail (not for .docx, .pdf, .jpg files though). Having more data in the ARC will reduce the read pressure on the SSDs and will give them more cycles for garbage collections (which are performed in the background and required to always have a sufficient reserve of free flash blocks for writes).

We would use I assume the lz4... which is the less "expensive" compression algorithm for the CPU... and I assume too for avoiding delay accessing data... do you recommend another one?. Do you always recommend compression then?.

=

I'd prefer zstd over lz4 since it offers a much higher compression ratio.

Zstd offers higher compression ratios than lz4 at similar or better decompression speed, but may be somewhat slower compressing the data. But in my opinion this is outweighed by the higher effective amount of data in the ARC/L2ARC possible with zstd.

For some benchmarks of different compression algorithms available for ZFS and compared to uncompressed mode see the extensive results published by Jude Allan:

https://docs.google.com/sprea=
dsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTgnXm2yPtiUQ/edit?usp=3Dsharing=


The SQL benchmarks might best resemble your use case - but remember that =
a significant reduction of the amount of data being written to the SSDs m=
ight be more important than the highest transaction rate, since your SSDs=
 put a low upper limit on that when highly loaded.

I'd give it a try - and if it reduces your storage requirements by 10% only, then keep 10% of each SSD unused (not assigned to any partition). That will greatly improve the resilience of your SSDs, reduce the write-amplification, will allow the SLC cache to stay at its large value, and may make a large difference to the effective performance under high load.<= /p>

But when you enable compression... only gets compressed the new data modified or entered. Am I wrong?.

Compression is per file system data block (at most 1 MB if you set the blocksize to that value). Each such block is compressed independently of all others, to not require more than 1 block to be read and decompressed when randomly reading a file. If a block does not shrink when compressed (it may contain compressed file data) the block is written to disk as-is (uncompressed).

By the way, we have more or less 1/4 of each disk used (12 TB allocated in a poll stated by zpool list, divided between 8 disks of 8TB...)... do you think we could be suffering on write amplification and so... having a so little disk space used in each disk?.

Your use case will cause a lot of garbage collections and this particular high write amplification values.

Regards, STefan

Hey mate, your mail is= incredible. It has helped as a lot. Can we invite you a cup of coffee or a beer through Paypal or similar?. Can I help you in some manner?.

Thanks, I'm glad to help, and I'd appreciate to hear whether you get your setup optimized for the purpose (and how well it holds up when you approach the capacity limits of your drives).

I'm always interested in experience of users with different use cases than I have (just being a developer with too much archived mail and media collected over a few decades).

Regards, STefan

--------------5zqkLuBRyXvluXGRQjtNvCUK-- --------------O0ssWPEiEQcQgZRJEKUGD0ko-- --------------TD2ASvjzfpo4JyxrFz8JyiVP Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmJQGRAFAwAAAAAACgkQR+u171r99UTJ 4gf6A4flCtMFuYpldXh1g1ln+Nio4LQGooOn69VSJw4KhihTBqy5ZR8scfhKetf8/miSx/0Akvsc WqZA9bEy67LXbUCekfbuUXQdO8ikXY1H64fecl4ZQZwItnIacKKD6TEIuBDe5sda0N+S2n7mNE/N d3EhNEyQTBOVvOx4vHdQaz+xAR6FFXstc14bs6BaSjROUndk21zO2IE8KMXkxH4RiWqoRuny3Po7 Uz3q0/+rcPSe9GHLw3BOHbvo89NdCFwlgBv5CXDMnEqqeW7ECdZiHn14XL/F30L8zCi2c3eTbD4Q AJeoKbBsmzSaud3opYrv2oCr8UOWiSLEJOkYAyvJeA== =tDUQ -----END PGP SIGNATURE----- --------------TD2ASvjzfpo4JyxrFz8JyiVP-- From nobody Fri Apr 8 15:20:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BA97A9F33BF for ; Fri, 8 Apr 2022 15:21:02 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZhlx6Ydhz4gGt for ; Fri, 8 Apr 2022 15:21:01 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x736.google.com with SMTP id b33so5048874qkp.13 for ; Fri, 08 Apr 2022 08:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=pvO9NX2tNuZLSQPbGxlCftNJmN06nLijo1lme/jpzHU=; b=jtOSDRIOG4+FI7vDmkmx/X+/Ke/zI96bwWjVhf0F46R/dkcKqnbsGGy+5aaZFETOun ffrB4MkVKju2zke0L4AytkbswEDb9HIVLkF6827fbPKMiMUWyQVhCY/JaYc5auD4+K0p h5YXAEALqJhtB7l/4XcUW+T7wpLZTMJdvWNTAY4vyd1QBYQcV4R/M+eYN6E7VU6Y17dc 6e0YYwKagdgsDiNtO/RLO1QXCv7RmBKAPlLSSnPhG65B7I/E6olj6gK23E+MORp379yb YTgLtGW+VTTpPvgWS+l+ut0xSDicXxkFLHcZ0b3PuyC08jpKqjXGVflg+lGJklGoAcDu fFyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pvO9NX2tNuZLSQPbGxlCftNJmN06nLijo1lme/jpzHU=; b=JywC+g/WFhc+xZx7QvfA2RBJeCZuZKCLRSaXAbud50JOlh8S7fRrRc9+eKsrrMcA4T fXGSf1Lv11KSiRfHtZubiy0uErzXKRO3RRAYSNYlJiIY5mta0LNpE5OXfD/mN+MCMjK6 NSe+tgq21PBPS/kux4LLe51JpyZ7Tv5uQaTiBYOicg6Mn/GzZg/FiXDkKlEWw6LXZKqj E4mxSnC6E6PayHYH2tcW0prwKEHr10KEyyTX4HGK4P1HAK/f16mKZEpnVcCCNhLrl/4F v7UYy306uLAXYCu1pnbV+zZ0LJlgbbBLr7NI+zu6bkQtLUzJUL6Th2k2Y6h2OorcDVUT 7/Pg== X-Gm-Message-State: AOAM530Ky2mlSN3eVMZo/BdCfBePL1iloXkMhgqf84hpVKEy3Wa5GgL9 lriqVvYeXFukNFK6qQ/BzdHNLg+GND6kn1XhKOTdh5Rms9NUMQ== X-Google-Smtp-Source: ABdhPJxe5lVaHEWq1Ra7B/P+JnvrOa6w85zUhDaLwMqFaUGx0qYoFYsA+kUubRcgWn2ML24TsFTIE+daq8433lI/vgE= X-Received: by 2002:a37:9a83:0:b0:67b:31be:2ac2 with SMTP id c125-20020a379a83000000b0067b31be2ac2mr13511942qke.416.1649431261174; Fri, 08 Apr 2022 08:21:01 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Jake Freeland Date: Fri, 8 Apr 2022 10:20:50 -0500 Message-ID: Subject: Lost GSoC Work in Perforce Repo To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000067712605dc2624eb" X-Rspamd-Queue-Id: 4KZhlx6Ydhz4gGt X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=jtOSDRIO; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::736) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-0.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; URI_COUNT_ODD(1.00)[1]; DMARC_NA(0.00)[technologyfriends.net]; DKIM_TRACE(0.00)[technologyfriends.net:~]; NEURAL_SPAM_LONG(0.96)[0.964]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000067712605dc2624eb Content-Type: text/plain; charset="UTF-8" Hi there, I am trying to dig up some work from a Google Summer of Code project back in 2008. I contacted the developer and they provided this link to retrieve it: https://web.archive.org/web/20180218121528/https://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2008/&c=AN8@//depot/projects/soc2008/rfrench_mpls/?ac=83 . The code appears to be nested in the `//depot/projects/soc2008/rfrench_mpls/` directory from the depot tree back when FreeBSD used Perforce to manage experimental projects. I was wondering if anyone still has access to this code? I plan on finishing the work that this particular developer started for the upcoming 2022 GSoC. Having access to those files would prove helpful. Thank you, Jake Freeland --00000000000067712605dc2624eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I am trying to dig up some wo= rk from a Google Summer of Code
project back in 2008. I contacted= the developer and they provided
this link to retrieve it:
<= div>

The co= de appears to be nested in the `//depot/projects/soc2008/rfrench_mpls/`
directory from the depot tree back when FreeBSD used Perforce to man= age
experimental projects. I was wondering if anyone still has ac= cess to this code?

I plan on finishing the work th= at this particular developer started for the
upcoming 2022 GSoC. = Having access to those files would prove=C2=A0helpful.

=
Thank you,
Jake Freeland
--00000000000067712605dc2624eb-- From nobody Fri Apr 8 17:41:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E838E1A879CD; Fri, 8 Apr 2022 17:41:22 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZlss2FNpz3j5J; Fri, 8 Apr 2022 17:41:20 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id A585B60C13A; Fri, 8 Apr 2022 19:41:11 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_fe85fe2db536d584a8585a29da09a2df" Date: Fri, 08 Apr 2022 19:41:11 +0200 From: egoitz@ramattack.net To: Stefan Esser Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> Message-ID: <3d24c87110b4a155e3f14d53a9309c61@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KZlss2FNpz3j5J X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_fe85fe2db536d584a8585a29da09a2df Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Stefan, Again extremely grateful. It's an absolute honor to receive your help.. really.... I have read this mail now but I need to read it slower and in a more relaxed way.... When I do that I'll answer you (during the weekend or on Monday at most). Don't worry I will keep you updated with news :) :) . I promise :) :) Cheers! El 2022-04-08 13:14, Stefan Esser escribiĂł: > ATENCION: Este correo se ha enviado desde fuera de la organizaciĂłn. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Am 07.04.22 um 14:30 schrieb egoitz@ramattack.net: El 2022-04-06 23:49, Stefan Esser escribiĂł: > > El 2022-04-06 17:43, Stefan Esser escribiĂł: > > Am 06.04.22 um 16:36 schrieb egoitz@ramattack.net: Hi Rainer! > > Thank you so much for your help :) :) > > Well I assume they are in a datacenter and should not be a power outage.... > > About dataset size... yes... our ones are big... they can be 3-4 TB easily each > dataset..... > > We bought them, because as they are for mailboxes and mailboxes grow and > grow.... for having space for hosting them... > Which mailbox format (e.g. mbox, maildir, ...) do you use? > > I'M RUNNING CYRUS IMAP SO SORT OF MAILDIR... TOO MANY LITTLE FILES NORMALLY..... SOMETIMES DIRECTORIES WITH TONS OF LITTLE FILES.... Assuming that many mails are much smaller than the erase block size of the SSD, this may cause issues. (You may know the following ...) For example, if you have message sizes of 8 KB and an erase block size of 64 KB (just guessing), then 8 mails will be in an erase block. If half the mails are deleted, then the erase block will still occupy 64 KB, but only hold 32 KB of useful data (and the SSD will only be aware of this fact if TRIM has signaled which data is no longer relevant). The SSD will copy several partially filled erase blocks together in a smaller number of free blocks, which then are fully utilized. Later deletions will repeat this game, and your data will be copied multiple times until it has aged (and the user is less likely to delete further messages). This leads to "write amplification" - data is internally moved around and thus written multiple times. STEFAN!! YOU ARE NICE!! I THINK THIS COULD EXPLAIN ALL OUR PROBLEM. SO, WHY WE ARE HAVING THE MOST RANDOMNESS IN OUR PERFORMANCE DEGRADATION AND THAT DOES NOT NECESSARILY HAS TO MATCH WITH THE MOST IO PEAK HOURS... THAT I COULD CAUSE THAT PERFORMANCE DEGRADATION JUST BY DELETING A COUPLE OF HUGE (PERHAPS 200.000 MAILS) MAIL FOLDERS IN A MIDDLE TRAFFIC HOUR TIME!! Yes, if deleting large amounts of data triggers performance issues (and the disk does not have a deficient TRIM implementation), then the issue is likely to be due to internal garbage collections colliding with other operations. >> THE PROBLEM IS THAT BY WHAT I KNOW, ERASE BLOCK SIZE OF AN SSD DISK IS SOMETHING FIXED IN THE DISK FIRMWARE. I DON'T REALLY KNOW IF PERHAPS IT COULD BE MODIFIED WITH SAMSUNG MAGICIAN OR THOSE KIND OF TOOL OF SAMSUNG.... ELSE I DON'T REALLY SEE THE MANNER OF IMPROVING IT... BECAUSE APART FROM THAT, YOU ARE DELETING A FILE IN RAIDZ-2 ARRAY... NO JUST IN A DISK... I ASSUME ALIGNING CHUNK SIZE, WITH RECORD SIZE AND WITH THE "SECRET" ERASE SIZE OF THE SSD, PERHAPS COULD BE SLIGHTLY COMPENSATED?. The erase block size is a fixed hardware feature of each flash chip. There is a block size for writes (e.g. 8 KB) and many such blocks are combined in one erase block (of e.g. 64 KB, probably larger in todays SSDs), they can only be returned to the free block pool all together. And if some of these writable blocks hold live data, they must be preserved by collecting them in newly allocated free blocks. An example of what might happen, showing a simplified layout of files 1, 2, 3 (with writable blocks 1a, 1b, ..., 2a, 2b, ... and "--" for stale data of deleted files, ".." for erased/writable flash blocks) in an SSD might be: erase block 1: |1a|1b|--|--|2a|--|--|3a| erase block 2; |--|--|--|2b|--|--|--|1c| erase block 3; |2c|1d|3b|3c|--|--|--|--| erase block 4; |..|..|..|..|..|..|..|..| This is just a random example how data could be laid out on the physical storage array. It is assumed that the 3 erase blocks once were completely occupied In this example, 10 of 32 writable blocks are occupied, and only one free erase block exists. This situation must not persist, since the SSD needs more empty erase blocks. 10/32 of the capacity is used for data, but 3/4 of the blocks are occupied and not immediately available for new data. The garbage collection might combine erase blocks 1 and 3 into a currently free one, e.g. erase block 4: erase block 1; |..|..|..|..|..|..|..|..| erase block 2; |--|--|--|2b|--|--|--|1c| erase block 3; |..|..|..|..|..|..|..|..| erase block 4: |1a|1b|2a|3a|2c|1d|3b|3c| Now only 2/4 of the capacity is not available for new data (which is still a lot more than 10/32, but better than before). Now assume file 2 is deleted: erase block 1; |..|..|..|..|..|..|..|..| erase block 2; |--|--|--|--|--|--|--|1c| erase block 3; |..|..|..|..|..|..|..|..| erase block 4: |1a|1b|--|3a|--|1d|3b|3c| There is now a new sparsely used erase block 4, and it will soon need to be garbage collected, too - in fact it could be combined with the live data from erase block 2, but this may be delayed until there is demand for more erased blocks (since e.g. file 1 or 3 might also have been deleted by then). The garbage collection does not know which data blocks belong to which file, and therefore it cannot collect the data belonging to a file into a single erase block. Blocks are allocated as data comes in (as long as enough SLC cells are available in this area, else directly in QLC cells). Your many parallel updates will cause fractions of each larger file to be spread out over many erase blocks. As you can see, a single file that is deleted may affect many erase blocks, and you have to take redundancy into consideration, which will multiply the effect by a factor of up to 3 for small files (one ZFS allocation block). And remember: deleting a message in mdir format will free the data blocks, but will also remove the directory entry, causing additional meta-data writes (again multiplied by the raid redundancy). A consumer SSD would normally see only very few parallel writes, and sequential writes of full files will have a high chance to put the data of each file contiguously in the minimum number of erase blocks, allowing to free multiple complete erase blocks when such a file is deleted and thus obviating the need for many garbage collection copies (that occur if data from several independent files is in one erase block). Actual SSDs have many more cells than advertised. Some 10% to 20% may be kept as a reserve for aging blocks that e.g. may have failed kind of a "read-after-write test" (implemented in the write function, which adds charges to the cells until they return the correct read-outs). BTW: Having an ashift value that is lower than the internal write block size may also lead to higher write amplification values, but a large ashift may lead to more wasted capacity, which may become an issue if typical file length are much smaller than the allocation granularity that results from the ashift value. >> Larger mails are less of an issue since they span multiple erase blocks, which will be completely freed when such a message is deleted. >> >> I SEE I SEE STEFAN... >> >> Samsung has a lot of experience and generally good strategies to deal with such a situation, but SSDs specified for use in storage systems might be much better suited for that kind of usage profile. >> >> YES... AND THE DISKS FOR OUR PURPOSE... PERHAPS WEREN'T QVOS.... You should have got (much more expensive) server grade SSDs, IMHO. But even 4 * 2 TB QVO (or better EVO) drives per each 8 TB QVO drive would result in better performance (but would need a lot of extra SATA ports). In fact, I'm not sure whether rotating media and a reasonable L2ARC consisting of a fast M.2 SSD plus a mirror of small SSDs for a LOG device would not be a better match for your use case. Reading the L2ARC would be very fast, writes would be purely sequential and relatively slow, you could choose a suitable L2ARC strategy (caching of file data vs. meta data), and the LOG device would support fast fsync() operations required for reliable mail systems (which confirm data is on stable storage before acknowledging the reception to the sender). > We knew they had some speed issues, but those speed issues, we thought (as > Samsung explains in the QVO site) they started after exceeding the speeding > buffer this disks have. We though that meanwhile you didn't exceed it's > capacity (the capacity of the speeding buffer) no speed problem arises. Perhaps > we were wrong?. > These drives are meant for small loads in a typical PC use case, > i.e. some installations of software in the few GB range, else only > files of a few MB being written, perhaps an import of media files > that range from tens to a few hundred MB at a time, but less often > than once a day. > > WE MOVE, YOU KNOW... LOTS OF LITTLE FILES... AND LOT'S OF DIFFERENT CONCURRENT MODIFICATIONS BY 1500-2000 CONCURRENT IMAP CONNECTIONS WE HAVE... I do not expect the read load to be a problem (except possibly when the SSD is moving data from SLC to QLC blocks, but even then reads will get priority). But writes and trims might very well overwhelm the SSD, especially when its getting full. Keeping a part of the SSD unused (excluded from the partitions created) will lead to a large pool of unused blocks. This will reduce the write amplification - there are many free blocks in the "unpartitioned part" of the SSD, and thus there is less urgency to compact partially filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a partition used for the ZPOOL, then 1/4 of each erase block could be free due to deletions/TRIM without any compactions required to hold all this data.) Keeping a significant percentage of the SSD unallocated is a good strategy to improve its performance and resilience. WELL, WE HAVE ALLOCATED ALL THE DISK SPACE... BUT NOT USED... JUST ALLOCATED.... YOU KNOW... WE DO A ZPOOL CREATE WITH THE WHOLE DISKS..... I think the only chance for a solution that does not require new hardware is to make sure, only some 80% of the SSDs are used (i.e. allocate only 80% for ZFS, leave 20% unallocated). This will significantly reduce the rate of garbage collections and thus reduce the load they cause. I'd use a fast encryption algorithm (zstd - choose a level that does not overwhelm the CPU, there are benchmark results for ZFS with zstd, and I found zstd-2 to be best for my use case). This will more than make up for the space you left unallocated on the SSDs. A different mail box format might help, too - I'm happy with dovecot's mdbox format, which is as fast but much more efficient than mdir. > As the SSD fills, the space available for the single level write > cache gets smaller > > THE SINGLE LEVEL WRITE CACHE IS THE CACHE THESE SSD DRIVERS HAVE, FOR COMPENSATING THE SPEED ISSUES THEY HAVE DUE TO USING QLC MEMORY?. DO YOU REFER TO THAT?. SORRY I DON'T UNDERSTAND WELL THIS PARAGRAPH. Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as 24 GB of data in QLC mode. OK, TRUE.... YES.... A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (600 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells). AHH! YOU MEAN THAT SLC CAPACITY FOR SPEEDING UP THE QLC DISKS, IS OBTAINED FROM EACH SINGLE LAYER OF THE QLC?. There are no specific SLC cells. A fraction of the QLC capable cells is only written with only 1 instead of 4 bits. This is a much simpler process, since there are only 2 charge levels per cell that are used, while QLC uses 16 charge levels, and you can only add charge (must not overshoot), therefore only small increments are added until the correct value can be read out). But since SLC cells take away specified capacity (which is calculated assuming all cells hold 4 bits each, not only 1 bit), their number is limited and shrinks as demand for QLC cells grows. The advantage of the SLC cache is fast writes, but also that data in it may have become stale (trimmed) and thus will never be copied over into a QLC block. But as the SSD fills and the size of the SLC cache shrinks, this capability will be mostly lost, and lots of very short lived data is stored in QLC cells, which will quickly become partially stale and thus needing compaction as explained above. > Therefore, the fraction of the cells used as an SLC cache is reduced when it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cells). > > SORRY I DON'T GET THIS LAST SENTENCE... DON'T UNDERSTAND IT BECAUSE I DON'T REALLY KNOW THE MEANING OF TN... > > BUT I THINK I'M GETTING THE IDEA IF YOU SAY THAT EACH QLC LAYER, HAS IT'S OWN SLC CACHE OBTAINED FROM THE DISK SPACE AVAIABLE FOR EACH QLC LAYER.... > > And with less SLC cells available for short term storage of data the probability of data being copied to QLC cells before the irrelevant messages have been deleted is significantly increased. And that will again lead to many more blocks with "holes" (deleted messages) in them, which then need to be copied possibly multiple times to compact them. > > IF I CORRECT ABOVE, I THINK I GOT THE IDEA YES.... (on many SSDs, I have no numbers for this > particular device), and thus the amount of data that can be > written at single cell speed shrinks as the SSD gets full. > > I have just looked up the size of the SLC cache, it is specified > to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB > version, smaller models will have a smaller SLC cache). > > ASSUMING YOU WERE TALKING ABOUT THE CACHE FOR COMPENSATING SPEED WE PREVIOUSLY COMMENTED, I SHOULD SAY THESE ARE THE 870 QVO BUT THE 8TB VERSION. SO THEY SHOULD HAVE THE BIGGEST CACHE FOR COMPENSATING THE SPEED ISSUES... I have looked up the data: the larger versions of the 870 QVO have the same SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB more if there are enough free blocks. OURS ONE IS THE 8TB MODEL SO I ASSUME IT COULD HAVE BIGGER LIMITS. THE DISKS ARE MOSTLY EMPTY, REALLY.... SO... FOR INSTANCE.... ZPOOL LIST NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT ROOT_DATASET 448G 2.29G 446G - - 1% 0% 1.00X ONLINE - MAIL_DATASET 58.2T 11.8T 46.4T - - 26% 20% 1.00X ONLINE - Ok, seems you have got 10 * 8 TB in a raidz2 configuration. Only 20% of the mail dataset is in use, the situation will become much worse when the pool will fill up! >> I SUPPOSE FRAGMENTATION AFFECTS TOO.... On magnetic media fragmentation means that a file is spread out over the disk in a non-optimal way, causing access latencies due to seeks and rotational delay. That kind of fragmentation is not really relevant for SSDs, which allow for fast random access to the cells. And the FRAG value shown by the "zpool list" command is not about fragmentation of files at all, it is about the structure of free space. Anyway less relevant for SSDs than for classic hard disk drives. > But after writing those few GB at a speed of some 500 MB/s (i.e. > after 12 to 150 seconds), the drive will need several minutes to > transfer those writes to the quad-level cells, and will operate > at a fraction of the nominal performance during that time. > (QLC writes max out at 80 MB/s for the 1 TB model, 160 MB/s for the > 2 TB model.) > > WELL WE ARE IN THE 8TB MODEL. I THINK I HAVE UNDERSTOOD WHAT YOU WROTE IN PREVIOUS PARAGRAPH. YOU SAID THEY CAN BE FAST BUT NOT CONSTANTLY, BECAUSE LATER THEY HAVE TO WRITE ALL THAT TO THEIR PERPETUAL STORAGE FROM THE CACHE. AND THAT'S SLOW. AM I WRONG?. EVEN IN THE 8TB MODEL YOU THINK STEFAN?. The controller in the SSD supports a given number of channels (e.g 4), each of which can access a Flash chip independently of the others. Small SSDs often have less Flash chips than there are channels (and thus a lower throughput, especially for writes), but the larger models often have more chips than channels and thus the performance is capped. THIS IS TOTALLY LOGICAL. IF A QVO DISK WOULD OUTPERFORM BEST OR SIMILAR THAN AN INTEL WITHOUT CONSEQUENCES.... WHO WAS GOING TO BUY A EXPENSIVE INTEL ENTERPRISE?. The QVO is bandwidth limited due to the SATA data rate of 6 Mbit/s anyway, and it is optimized for reads (which are not significantly slower than offered by the TLC models). This is a viable concept for a consumer PC, but not for a server. > In the case of the 870 QVO, the controller supports 8 channels, which allows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has only 4 Flash chips and is thus limited to 80 MB/s in that situation, while the larger versions have 8, 16, or 32 chips. But due to the limited number of channels, the write rate is limited to 160 MB/s even for the 8 TB model. > > TOTALLY LOGICAL STEFAN... > > If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in this limit. > THE MAIN PROBLEM WE ARE FACING IS THAT IN SOME PEAK MOMENTS, WHEN THE MACHINE SERVES CONNECTIONS FOR ALL THE INSTANCES IT HAS, AND ONLY AS SAID IN SOME PEAK MOMENTS... LIKE THE 09AM OR THE 11AM.... IT SEEMS THE MACHINE BECOMES SLOWER... AND LIKE IF THE DISKS WEREN'T ABLE TO SERVE ALL THEY HAVE TO SERVE.... IN THESE MOMENTS, NO BIG FILES ARE MOVED... BUT AS WE HAVE 1800-2000 CONCURRENT IMAP CONNECTIONS... NORMALLY THEY ARE DOING EACH ONE... LITTLE CHANGES IN THEIR MAILBOX. DO YOU THINK PERHAPS THIS DISKS THEN ARE NOT APPROPRIATE FOR THIS KIND OF USAGE?- I'd guess that the drives get into a state in which they have to recycle lots of partially free blocks (i.e. perform kind of a garbage collection) and then three kinds of operations are competing with each other: * reads (generally prioritized) * writes (filling the SLC cache up to its maximum size) * compactions of partially filled blocks (required to make free blocks available for re-use) Writes can only proceed if there are sufficient free blocks, which on a filled SSD with partially filled erase blocks means that operations of type 3. need to be performed with priority to not stall all writes. My assumption is that this is what you are observing under peak load. IT COULD BE ALTHOUGH THE DISKS ARE NOT FILLED.... THE POOL ARE AT 20 OR 30% OF CAPACITY AND FRAGMENTATION FROM 20%-30% (AS ZPOOL LIST STATES). Yes, and that means that your issues will become much more critical over time when the free space shrinks and garbage collections will be required at an even faster rate, with the SLC cache becoming less and less effective to weed out short lived files as an additional factor that will increase write amplification. > And cheap SSDs often have no RAM cache (not checked, but I'd be > surprised if the QVO had one) and thus cannot keep bookkeeping date > in such a cache, further limiting the performance under load. > > THIS BROCHURE (HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/BROCHURE/870_SERIES_BROCHURE.PDF AND THE DATASHEET HTTPS://SEMICONDUCTOR.SAMSUNG.COM/RESOURCES/DATA-SHEET/SAMSUNG_SSD_870_QVO_DATA_SHEET_REV1.1.PDF) SAIS IF I HAVE READ PROPERLY, THE 8TB DRIVE HAS 8GB OF RAM?. I ASSUME THAT IS WHAT THEY CALL THE TURBO WRITE CACHE?. No, the turbo write cache consists of the cells used in SLC mode (which can be any cells, not only cells in a specific area of the flash chip). I SEE I SEE.... The RAM is needed for fast lookup of the position of data for reads and of free blocks for writes. OUR ONES... SEEM TO HAVE 8GB LPDDR4 OF RAM.... AS DATASHEET STATES.... Yes, and it makes sense that the RAM size is proportional to the capacity since a few bytes are required per addressable data block. If the block size was 8 KB the RAM could hold 8 bytes (e.g. a pointer and some status flags) for each logically addressable block. But there is no information about the actual internal structure of the QVO that I know of. [...] >> I SEE.... IT'S EXTREMELY MISLEADING YOU KNOW... BECAUSE... YOU CAN COPY FIVE MAILBOXES OF 50GB CONCURRENTLY FOR INSTANCE.... AND YOU FLOOD A GIGABIT INTERFACE COPYING (OBVIOUSLY BECAUSE DISKS CAN KEEP THAT THROUGHPUT)... BUT LATER.... YOU SEE... YOU ARE IN AN HOUR THAT YESTERDAY, AND EVEN 4 DAYS BEFORE YOU HAVE NOT HAD ANY ISSUES... AND THAT DAY... YOU SEE THE COMMENTED ISSUE... EVEN NOT BEING EXACTLY AT A PEAK HOUR (PERHAPS IS TWO HOURS LATER THE PEAK HOUR EVEN)... OR... BUT I WASN'T NOTICING ABOUT ALL THINGS YOU SAY IN THIS EMAIL.... >> >> I have seen advice to not use compression in a high load scenario in some other reply. >> >> I tend to disagree: Since you seem to be limited when the SLC cache is exhausted, you should get better performance if you compress your data. I have found that zstd-2 works well for me (giving a significant overall reduction of size at reasonable additional CPU load). Since ZFS allows to switch compressions algorithms at any time, you can experiment with different algorithms and levels. >> >> I SEE... YOU SAY COMPRESSION SHOULD BE ENABLED.... THE MAIN REASON BECAUSE WE HAVE NOT ENABLED IT YET, IS FOR KEEPING THE SYSTEM THE MOST NEAR POSSIBLE TO CONFIG DEFAULTS... YOU KNOW... FOR LATER BEING ABLE TO ASK IN THIS MAILING LISTS IF WE HAVE AN ISSUE... BECAUSE YOU KNOW... IT WOULD BE FAR MORE EASIER TO ASK ABOUT SOMETHING STRANGE YOU ARE SEEING WHEN THAT STRANGE THING IS NEAR TO A WELL TESTED CONFIG, LIKE THE CONFIG BY DEFAULT.... >> >> BUT NOW YOU SAY STEFAN... IF YOU SWITCH BETWEEN COMPRESSION ALGORITHMS YOU WILL END UP WITH A MIX OF DIFFERENT FILES COMPRESSED IN A DIFFERENT MANNER... THAT IS NOT A BIT DISASTER LATER?. DOESN'T AFFECT PERFORMANCE IN SOME MANNER?. The compression used is stored in the per file information, each file in a dataset could have been written with a different compression method and level. Blocks are independently compressed - a file level compression may be more effective. Large mail files will contain incompressible attachments (already compressed), but in base64 encoding. This should allow a compression ratio of ~1,3. Small files will be plain text or HTML, offering much better compression factors. >> One advantage of ZFS compression is that it applies to the ARC, too. And a compression factor of 2 should easily be achieved when storing mail (not for .docx, .pdf, .jpg files though). Having more data in the ARC will reduce the read pressure on the SSDs and will give them more cycles for garbage collections (which are performed in the background and required to always have a sufficient reserve of free flash blocks for writes). >> >> WE WOULD USE I ASSUME THE LZ4... WHICH IS THE LESS "EXPENSIVE" COMPRESSION ALGORITHM FOR THE CPU... AND I ASSUME TOO FOR AVOIDING DELAY ACCESSING DATA... DO YOU RECOMMEND ANOTHER ONE?. DO YOU ALWAYS RECOMMEND COMPRESSION THEN?. I'd prefer zstd over lz4 since it offers a much higher compression ratio. Zstd offers higher compression ratios than lz4 at similar or better decompression speed, but may be somewhat slower compressing the data. But in my opinion this is outweighed by the higher effective amount of data in the ARC/L2ARC possible with zstd. For some benchmarks of different compression algorithms available for ZFS and compared to uncompressed mode see the extensive results published by Jude Allan: https://docs.google.com/spreadsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTgnXm2yPtiUQ/edit?usp=sharing The SQL benchmarks might best resemble your use case - but remember that a significant reduction of the amount of data being written to the SSDs might be more important than the highest transaction rate, since your SSDs put a low upper limit on that when highly loaded. >> I'd give it a try - and if it reduces your storage requirements by 10% only, then keep 10% of each SSD unused (not assigned to any partition). That will greatly improve the resilience of your SSDs, reduce the write-amplification, will allow the SLC cache to stay at its large value, and may make a large difference to the effective performance under high load. >> >> BUT WHEN YOU ENABLE COMPRESSION... ONLY GETS COMPRESSED THE NEW DATA MODIFIED OR ENTERED. AM I WRONG?. Compression is per file system data block (at most 1 MB if you set the blocksize to that value). Each such block is compressed independently of all others, to not require more than 1 block to be read and decompressed when randomly reading a file. If a block does not shrink when compressed (it may contain compressed file data) the block is written to disk as-is (uncompressed). >> BY THE WAY, WE HAVE MORE OR LESS 1/4 OF EACH DISK USED (12 TB ALLOCATED IN A POLL STATED BY ZPOOL LIST, DIVIDED BETWEEN 8 DISKS OF 8TB...)... DO YOU THINK WE COULD BE SUFFERING ON WRITE AMPLIFICATION AND SO... HAVING A SO LITTLE DISK SPACE USED IN EACH DISK?. Your use case will cause a lot of garbage collections and this particular high write amplification values. >> Regards, STefan >> >> HEY MATE, YOUR MAIL IS INCREDIBLE. IT HAS HELPED AS A LOT. CAN WE INVITE YOU A CUP OF COFFEE OR A BEER THROUGH PAYPAL OR SIMILAR?. CAN I HELP YOU IN SOME MANNER?. Thanks, I'm glad to help, and I'd appreciate to hear whether you get your setup optimized for the purpose (and how well it holds up when you approach the capacity limits of your drives). I'm always interested in experience of users with different use cases than I have (just being a developer with too much archived mail and media collected over a few decades). Regards, STefan --=_fe85fe2db536d584a8585a29da09a2df Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Stefan,


Again extremely grateful. It's an absolute honor to receive your help.= =2E really....


I have read this mail now but I need to read it slower and in a more rel= axed way.... When I do that I'll answer you (during the weekend or on Monda= y at most).


Don't worry I will keep you updated with news :) :) . I promise :) :)


Cheers!

 


El 2022-04-08 13:14, Stefan Esser escribió:


ATENCION: Este correo se ha enviado = desde fuera de la organización. No pinche en los enlaces ni abra los= adjuntos a no ser que reconozca el remitente y sepa que el contenido es se= guro.

Am 07.04.22 um 14:30 schrieb egoitz@ramattack.net:
El 2022-04-06 23:49, Stefan Esser escribió:

El 2022-04-06 17:43, Stefan Esser escribió:


Am 06.04.22 um 16:36 schrieb egoitz@ramattack= =2Enet:
Hi Rainer!

Thank you so much for your help :) :)
=
Well I assume they are in a datacenter and should not be a power ou= tage....

About dataset size... yes... our ones are big... they= can be 3-4 TB easily each
dataset.....

We bought them, = because as they are for mailboxes and mailboxes grow and
grow.... for= having space for hosting them...

Which mailbox format (e.g. mbox, maildir, ...) do you use?
 
I'm running Cyrus imap so sort of = Maildir... too many little files normally..... Sometimes directories with t= ons of little files....

Assuming that many mails are much smaller than the erase block size of t= he SSD, this may cause issues. (You may know the following ...)

For example, if you have message sizes of 8 KB and an erase block size o= f 64 KB (just guessing), then 8 mails will be in an erase block. If half th= e mails are deleted, then the erase block will still occupy 64 KB, but only= hold 32 KB of useful data (and the SSD will only be aware of this fact if = TRIM has signaled which data is no longer relevant). The SSD will copy seve= ral partially filled erase blocks together in a smaller number of free bloc= ks, which then are fully utilized. Later deletions will repeat this game, a= nd your data will be copied multiple times until it has aged (and the user = is less likely to delete further messages). This leads to "write amplificat= ion" - data is internally moved around and thus written multiple times.


Stefan!! you are nice!! I think = this could explain all our problem. So, why we are having the most randomne= ss in our performance degradation and that does not necessarily has to matc= h with the most io peak hours... That I could cause that performance degrad= ation just by deleting a couple of huge (perhaps 200.000 mails) mail folder= s in a middle traffic hour time!!

Yes, if deleting large amounts of data triggers performance issues (and the= disk does not have a deficient TRIM implementation), then the issue is lik= ely to be due to internal garbage collections colliding with other operatio= ns.

The problem is that by what I kn= ow, erase block size of an SSD disk is something fixed in the disk firmware= =2E I don't really know if perhaps it could be modified with Samsung magici= an or those kind of tool of Samsung.... else I don't really see the manner = of improving it... because apart from that, you are deleting a file in raid= z-2 array... no just in a disk... I assume aligning chunk size, with record= size and with the "secret" erase size of the ssd, perhaps could be slightl= y compensated?.

The erase block size is a fixed hardware feature of each flash chip. The= re is a block size for writes (e.g. 8 KB) and many such blocks are combined= in one erase block (of e.g. 64 KB, probably larger in todays SSDs), they c= an only be returned to the free block pool all together. And if some of the= se writable blocks hold live data, they must be preserved by collecting the= m in newly allocated free blocks.

An example of what might happen, showing a simplified layout of files 1,= 2, 3 (with writable blocks 1a, 1b, ..., 2a, 2b, ... and "--" for stale dat= a of deleted files, ".." for erased/writable flash blocks) in an SSD might = be:

erase block 1: |1a|1b|--|--|2a|-= -|--|3a|

erase block 2; |--|--|--|2b|--|-= -|--|1c|

erase block 3; |2c|1d|3b|3c|--|-= -|--|--|

erase block 4; |..|..|..|..|..|= =2E.|..|..|

This is just a random example how data could be laid out on the physical= storage array. It is assumed that the 3 erase blocks once were completely = occupied

In this example, 10 of 32 writable blocks are occupied, and only one fre= e erase block exists.

This situation must not persist, since the SSD needs more empty erase bl= ocks. 10/32 of the capacity is used for data, but 3/4 of the blocks are occ= upied and not immediately available for new data.

The garbage collection might combine erase blocks 1 and 3 into a current= ly free one, e.g. erase block 4:

erase block 1; |..|..|..|..|..|..|= =2E.|..|

erase block 2; |--|--|--|2b|--|-= -|--|1c|

erase block 3; |..|..|..|..|..|= =2E.|..|..|

erase block 4: |1a|1b|2a|3a|2c|1= d|3b|3c|

Now only 2/4 of the capacity is not available for new data (which is sti= ll a lot more than 10/32, but better than before).

Now assume file 2 is deleted:

erase block 1; |..|..|..|..|..|= =2E.|..|..|

erase block 2; |--|--|--|--|--|-= -|--|1c|

erase block 3; |..|..|..|..|..|= =2E.|..|..|

erase block 4: |1a|1b|--|3a|--|1= d|3b|3c|

There is now a new sparsely used erase block 4, and it will soon need to= be garbage collected, too - in fact it could be combined with the live dat= a from erase block 2, but this may be delayed until there is demand for mor= e erased blocks (since e.g. file 1 or 3 might also have been deleted by the= n).

The garbage collection does not know which data blocks belong to which f= ile, and therefore it cannot collect the data belonging to a file into a si= ngle erase block. Blocks are allocated as data comes in (as long as enough = SLC cells are available in this area, else directly in QLC cells). Your man= y parallel updates will cause fractions of each larger file to be spread ou= t over many erase blocks.

As you can see, a single file that is deleted may affect many erase bloc= ks, and you have to take redundancy into consideration, which will multiply= the effect by a factor of up to 3 for small files (one ZFS allocation bloc= k). And remember: deleting a message in mdir format will free the data bloc= ks, but will also remove the directory entry, causing additional meta-data = writes (again multiplied by the raid redundancy).


A consumer SSD would normally see only very few parallel writes, and seq= uential writes of full files will have a high chance to put the data of eac= h file contiguously in the minimum number of erase blocks, allowing to free= multiple complete erase blocks when such a file is deleted and thus obviat= ing the need for many garbage collection copies (that occur if data from se= veral independent files is in one erase block).

Actual SSDs have many more cells than advertised. Some 10% to 20% may be= kept as a reserve for aging blocks that e.g. may have failed kind of a "re= ad-after-write test" (implemented in the write function, which adds charges= to the cells until they return the correct read-outs).

BTW: Having an ashift value that is lower than the internal write block = size may also lead to higher write amplification values, but a large ashift= may lead to more wasted capacity, which may become an issue if typical fil= e length are much smaller than the allocation granularity that results from= the ashift value.


Larger mails are less of an issue since they span multiple erase blocks,= which will be completely freed when such a message is deleted.

I see I see Stefan...

Samsung has a lot of experience and generally good strategies to deal wi= th such a situation, but SSDs specified for use in storage systems might be= much better suited for that kind of usage profile.

Yes... and the disks for our pur= pose... perhaps weren't QVOs....

You should have got (much more expensive) server grade SSDs, IMHO.

But even 4 * 2 TB QVO (or better EVO) drives per each 8 TB QVO drive wou= ld result in better performance (but would need a lot of extra SATA ports)= =2E

In fact, I'm not sure whether rotating media and a reasonable L2ARC cons= isting of a fast M.2 SSD plus a mirror of small SSDs for a LOG device would= not be a better match for your use case. Reading the L2ARC would be very f= ast, writes would be purely sequential and relatively slow, you could choos= e a suitable L2ARC strategy (caching of file data vs. meta data), and the L= OG device would support fast fsync() operations required for reliable mail = systems (which confirm data is on stable storage before acknowledging the r= eception to the sender).

We knew they had some speed issues, but those speed issues, we thou= ght (as
Samsung explains in the QVO site) they started after exceedin= g the speeding
buffer this disks have. We though that meanwhile you d= idn't exceed it's
capacity (the capacity of the speeding buffer) no s= peed problem arises. Perhaps
we were wrong?.

These drives are meant for small loads in a typical PC use case,
i.e. some installations of software in the few GB range, else only
= files of a few MB being written, perhaps an import of media files
th= at range from tens to a few hundred MB at a time, but less often
than= once a day.
 
We move, you know... lots of littl= e files... and lot's of different concurrent modifications by 1500-2000 con= current imap connections we have...

I do not expect the read load to be a problem (except possibly when the = SSD is moving data from SLC to QLC blocks, but even then reads will get pri= ority). But writes and trims might very well overwhelm the SSD, especially = when its getting full. Keeping a part of the SSD unused (excluded from the = partitions created) will lead to a large pool of unused blocks. This will r= educe the write amplification - there are many free blocks in the "unpartit= ioned part" of the SSD, and thus there is less urgency to compact partially= filled blocks. (E.g. if you include only 3/4 of the SSD capacity in a part= ition used for the ZPOOL, then 1/4 of each erase block could be free due to= deletions/TRIM without any compactions required to hold all this data.)

Keeping a significant percentage of the SSD unallocated is a good strate= gy to improve its performance and resilience.

Well, we have allocated all the = disk space... but not used... just allocated.... you know... we do a zpool = create with the whole disks.....

I think the only chance for a solution that does not require new hardwar= e is to make sure, only some 80% of the SSDs are used (i.e. allocate only 8= 0% for ZFS, leave 20% unallocated). This will significantly reduce the rate= of garbage collections and thus reduce the load they cause.

I'd use a fast encryption algorithm (zstd - choose a level that does not= overwhelm the CPU, there are benchmark results for ZFS with zstd, and I fo= und zstd-2 to be best for my use case). This will more than make up for the= space you left unallocated on the SSDs.

A different mail box format might help, too - I'm happy with dovecot's m= dbox format, which is as fast but much more efficient than mdir.

As the SSD fills, the space available for the single level write
cac= he gets smaller
 
The single level write cache is th= e cache these ssd drivers have, for compensating the speed issues they have= due to using qlc memory?. Do you refer to that?. Sorry I don't understand = well this paragraph.

Yes, the SSD is specified to hold e.g. 1 TB at 4 bits per cell. The SLC = cache has only 1 bit per cell, thus a 6 GB SLC cache needs as many cells as= 24 GB of data in QLC mode.

Ok, true.... yes....

A 100 GB SLC cache would reduce the capacity of a 1 TB SSD to 700 GB (60= 0 GB in 150 tn QLC cells plus 100 GB in 100 tn SLC cells).

Ahh! you mean that SLC capacity = for speeding up the QLC disks, is obtained from each single layer of the QL= C?.

There are no specific SLC cells. A fraction of the QLC capable cells is = only written with only 1 instead of 4 bits. This is a much simpler process,= since there are only 2 charge levels per cell that are used, while QLC use= s 16 charge levels, and you can only add charge (must not overshoot), there= fore only small increments are added until the correct value can be read ou= t).

But since SLC cells take away specified capacity (which is calculated as= suming all cells hold 4 bits each, not only 1 bit), their number is limited= and shrinks as demand for QLC cells grows.

The advantage of the SLC cache is fast writes, but also that data in it = may have become stale (trimmed) and thus will never be copied over into a Q= LC block. But as the SSD fills and the size of the SLC cache shrinks, this = capability will be mostly lost, and lots of very short lived data is stored= in QLC cells, which will quickly become partially stale and thus needing c= ompaction as explained above.

Therefore, the fraction of the cells used as an SLC cache is reduced whe= n it gets full (e.g. ~1 TB in ~250 tn QLC cells, plus 6 GB in 6 tn SLC cell= s).

Sorry I don't get this last sent= ence... don't understand it because I don't really know the meaning of tn= =2E..

but I think I'm getting the idea= if you say that each QLC layer, has it's own SLC cache obtained from the d= isk space avaiable for each QLC layer....

And with less SLC cells available for short term storage of data the pro= bability of data being copied to QLC cells before the irrelevant messages h= ave been deleted is significantly increased. And that will again lead to ma= ny more blocks with "holes" (deleted messages) in them, which then need to = be copied possibly multiple times to compact them.

If I correct above, I think I go= t the idea yes....

(on many SSDs, I have no nu= mbers for this
particular device), and thus the amount of data that can be
written = at single cell speed shrinks as the SSD gets full.
 

I have just looked up the size of the SLC cache, it is specified to be 78 GB for the empty SSD, 6 GB when it is full (for the 2 TB
= version, smaller models will have a smaller SLC cache).
 
Assuming you were talking about th= e cache for compensating speed we previously commented, I should say these = are the 870 QVO but the 8TB version. So they should have the biggest cache = for compensating the speed issues...

I have looked up the data: the larger versions of the 870 QVO have the s= ame SLC cache configuration as the 2 TB model, 6 GB minimum and up to 72 GB= more if there are enough free blocks.

Ours one is the 8TB model so I a= ssume it could have bigger limits. The disks are mostly empty, really.... s= o... for instance....

zpool list
= NAME     =         SIZE  ALLOC   FRE= E  CKPOINT  EXPANDSZ   FRAG    CAP = DEDUP  HEALTH  ALTROOT
root_dataset  448G  2.29G   446G&n= bsp;       -     &nb= sp;   -     1%     0%&nbs= p; 1.00x  ONLINE  -
mail_dataset  58.2T  11.8T  46.4T &nbs= p;      -       = ;  -    26%    20%  1.00x  ONL= INE  -

Ok, seems you have got 10 * 8 TB in a raidz2 configuration.

Only 20% of the mail dataset is in use, the situation will become much w= orse when the pool will fill up!

I suppose fragmentation affects = too....

On magnetic media fragmentation means that a file is spread out over the= disk in a non-optimal way, causing access latencies due to seeks and rotat= ional delay. That kind of fragmentation is not really relevant for SSDs, wh= ich allow for fast random access to the cells.

And the FRAG value shown by the "zpool list" command is not about fragme= ntation of files at all, it is about the structure of free space. Anyway le= ss relevant for SSDs than for classic hard disk drives.

But after writing those few GB at a speed of some 500 MB/s (i.e.
aft= er 12 to 150 seconds), the drive will need several minutes to
transfe= r those writes to the quad-level cells, and will operate
at a fractio= n of the nominal performance during that time.
(QLC writes max out at= 80 MB/s for the 1 TB model, 160 MB/s for the
2 TB model.)
 
Well we are in the 8TB model. I th= ink I have understood what you wrote in previous paragraph. You said they c= an be fast but not constantly, because later they have to write all that to= their perpetual storage from the cache. And that's slow. Am I wrong?. Even= in the 8TB model you think Stefan?.

The controller in the SSD supports a given number of channels (e.g 4), e= ach of which can access a Flash chip independently of the others. Small SSD= s often have less Flash chips than there are channels (and thus a lower thr= oughput, especially for writes), but the larger models often have more chip= s than channels and thus the performance is capped.

This is totally logical. If a QV= O disk would outperform best or similar than an Intel without consequences= =2E... who was going to buy a expensive Intel enterprise?.<= /p>

The QVO is bandwidth limited due to the SATA data rate of 6 Mbit/s anyway, = and it is optimized for reads (which are not significantly slower than offe= red by the TLC models). This is a viable concept for a consumer PC, but not= for a server.

In the case of the 870 QVO, the controller supports 8 channels, which al= lows it to write 160 MB/s into the QLC cells. The 1 TB model apparently has= only 4 Flash chips and is thus limited to 80 MB/s in that situation, while= the larger versions have 8, 16, or 32 chips. But due to the limited number= of channels, the write rate is limited to 160 MB/s even for the 8 TB model= =2E

Totally logical Stefan...=

If you had 4 * 2 TB instead, the throughput would be 4 * 160 MB/s in thi= s limit.

The main problem we are facing is = that in some peak moments, when the machine serves connections for all the = instances it has, and only as said in some peak moments... like the 09am or= the 11am.... it seems the machine becomes slower... and like if the disks = weren't able to serve all they have to serve.... In these moments, no big f= iles are moved... but as we have 1800-2000 concurrent imap connections... n= ormally they are doing each one... little changes in their mailbox. Do you = think perhaps this disks then are not appropriate for this kind of usage?-<= /strong>

I'd guess that the drives get into a state in which they have to recycle= lots of partially free blocks (i.e. perform kind of a garbage collection) = and then three kinds of operations are competing with each other:

  1. reads (generally prioritized)
  2. writes (filling the SLC cache up to its maximum size)
  3. compactions of partially filled blocks (required to make free blocks av= ailable for re-use)

Writes can only proceed if there are sufficient free blocks, which on a = filled SSD with partially filled erase blocks means that operations of type= 3. need to be performed with priority to not stall all writes.

My assumption is that this is what you are observing under peak load.

It could be although the disks a= re not filled.... the pool are at 20 or 30% of capacity and fragmentation f= rom 20%-30% (as zpool list states).

Yes, and that means that your issues will become much more critical over ti= me when the free space shrinks and garbage collections will be required at = an even faster rate, with the SLC cache becoming less and less effective to= weed out short lived files as an additional factor that will increase writ= e amplification.
And cheap SSDs often have no RAM cache (not checked, but I'd be
surp= rised if the QVO had one) and thus cannot keep bookkeeping date
in su= ch a cache, further limiting the performance under load.
 
This brochure (https://semiconductor.samsung.com/resources/brochu= re/870_Series_Brochure.pdf and the datasheet https://semiconductor.samsung.com/resources/data-sheet/Samsung_S= SD_870_QVO_Data_Sheet_Rev1.1.pdf) sais if I have read properly, the 8TB= drive has 8GB of ram?. I assume that is what they call the turbo write cac= he?.

No, the turbo write cache consists of the cells used in SLC mode (which = can be any cells, not only cells in a specific area of the flash chip).

I see I see....<= /p>

The RAM is needed for fast lookup of the position of data for reads and = of free blocks for writes.

Our ones... seem to have 8GB LPD= DR4 of ram.... as datasheet states....

Yes, and it makes sense that the RAM size is proportional to the capacit= y since a few bytes are required per addressable data block.

If the block size was 8 KB the RAM could hold 8 bytes (e.g. a pointer an= d some status flags) for each logically addressable block. But there is no = information about the actual internal structure of the QVO that I know of= =2E

[...]

I see.... It's extremely mislead= ing you know... because... you can copy five mailboxes of 50GB concurrently= for instance.... and you flood a gigabit interface copying (obviously beca= use disks can keep that throughput)... but later.... you see... you are in = an hour that yesterday, and even 4 days before you have not had any issues= =2E.. and that day... you see the commented issue... even not being exactly= at a peak hour (perhaps is two hours later the peak hour even)... or... bu= t I wasn't noticing about all things you say in this email....

I have seen advice to not use compression in a high load scenario in som= e other reply.

I tend to disagree: Since you seem to be limited when the SLC cache is e= xhausted, you should get better performance if you compress your data. I ha= ve found that zstd-2 works well for me (giving a significant overall reduct= ion of size at reasonable additional CPU load). Since ZFS allows to switch = compressions algorithms at any time, you can experiment with different algo= rithms and levels.

I see... you say compression sho= uld be enabled.... The main reason because we have not enabled it yet, is f= or keeping the system the most near possible to config defaults... you know= =2E.. for later being able to ask in this mailing lists if we have an issue= =2E.. because you know... it would be far more easier to ask about somethin= g strange you are seeing when that strange thing is near to a well tested c= onfig, like the config by default....

But now you say Stefan... if you= switch between compression algorithms you will end up with a mix of differ= ent files compressed in a different manner... that is not a bit disaster la= ter?. Doesn't affect performance in some manner?.

The compression used is stored in the per file information, each file in a = dataset could have been written with a different compression method and lev= el. Blocks are independently compressed - a file level compression may be m= ore effective. Large mail files will contain incompressible attachments (al= ready compressed), but in base64 encoding. This should allow a compression = ratio of ~1,3. Small files will be plain text or HTML, offering much better= compression factors.

One advantage of ZFS compression is that it applies to the ARC, too. And= a compression factor of 2 should easily be achieved when storing mail (not= for .docx, .pdf, .jpg files though). Having more data in the ARC will redu= ce the read pressure on the SSDs and will give them more cycles for garbage= collections (which are performed in the background and required to always = have a sufficient reserve of free flash blocks for writes).

We would use I assume the lz4.= =2E. which is the less "expensive" compression algorithm for the CPU... and= I assume too for avoiding delay accessing data... do you recommend another= one?. Do you always recommend compression then?.

I'd prefer zstd over lz4 since it offers a much higher compression ratio= =2E

Zstd offers higher compression ratios than lz4 at similar or better deco= mpression speed, but may be somewhat slower compressing the data. But in my= opinion this is outweighed by the higher effective amount of data in the A= RC/L2ARC possible with zstd.

For some benchmarks of different compression algorithms available for ZF= S and compared to uncompressed mode see the extensive results published by = Jude Allan:

htt=
ps://docs.google.com/spreadsheets/d/1TvCAIDzFsjuLuea7124q-1UtMd0C9amTgnXm2y=
PtiUQ/edit?usp=3Dsharing

The SQL benchmarks might best resemble your use case - but remember that a =
significant reduction of the amount of data being written to the SSDs might=
 be more important than the highest transaction rate, since your SSDs put a=
 low upper limit on that when highly loaded.

I'd give it a try - and if it reduces your storage requirements by 10% o= nly, then keep 10% of each SSD unused (not assigned to any partition). That= will greatly improve the resilience of your SSDs, reduce the write-amplifi= cation, will allow the SLC cache to stay at its large value, and may make a= large difference to the effective performance under high load.

But when you enable compression= =2E.. only gets compressed the new data modified or entered. Am I wrong?.

Compression is per file system data block (at most 1 MB if you set the bloc= ksize to that value). Each such block is compressed independently of all ot= hers, to not require more than 1 block to be read and decompressed when ran= domly reading a file. If a block does not shrink when compressed (it may co= ntain compressed file data) the block is written to disk as-is (uncompresse= d).


By the way, we have more or less= 1/4 of each disk used (12 TB allocated in a poll stated by zpool list, div= ided between 8 disks of 8TB...)... do you think we could be suffering on wr= ite amplification and so... having a so little disk space used in each disk= ?.

Your use case will cause a lot of garbage collections and this particular h= igh write amplification values.

Regards, STefan

Hey mate, your mail is incredibl= e. It has helped as a lot. Can we invite you a cup of coffee or a beer thro= ugh Paypal or similar?. Can I help you in some manner?.

Thanks, I'm glad to help, and I'd appreciate to hear whether you get you= r setup optimized for the purpose (and how well it holds up when you approa= ch the capacity limits of your drives).

I'm always interested in experience of users with different use cases th= an I have (just being a developer with too much archived mail and media col= lected over a few decades).

Regards, STefan

--=_fe85fe2db536d584a8585a29da09a2df-- From nobody Fri Apr 8 18:00:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C0CFE1A8C8B1; Fri, 8 Apr 2022 18:00:55 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZmJQ3VdKz3mfy; Fri, 8 Apr 2022 18:00:54 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [80.187.81.73] (helo=pureos) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncsub-0005cG-9M; Fri, 08 Apr 2022 20:00:45 +0200 Date: Fri, 8 Apr 2022 20:00:42 +0200 From: Matthias Apitz To: egoitz@ramattack.net Cc: Stefan Esser , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner Subject: Re: Re: Desperate with 870 QVO and ZFS Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: egoitz@ramattack.net, Stefan Esser , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <3d24c87110b4a155e3f14d53a9309c61@ramattack.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3d24c87110b4a155e3f14d53a9309c61@ramattack.net> X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 80.187.81.73 X-Rspamd-Queue-Id: 4KZmJQ3VdKz3mfy X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of guru@unixarea.de has no SPF policy when checking 178.254.4.101) smtp.mailfrom=guru@unixarea.de X-Spamd-Result: default: False [2.83 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; RWL_MAILSPIKE_EXCELLENT(0.00)[178.254.4.101:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; RECEIVED_SPAMHAUS_PBL(0.00)[80.187.81.73:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.54)[-0.541]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.97)[0.974]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello egoitz@ramattack.net, Please be so kind and stop sending mails in HTML and stop top posting. Thanks in advance matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Peace instead of NATO! Мир вместо НАТО! Frieden statt NATO! ¡Paz en vez de OTAN! From nobody Fri Apr 8 18:53:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5BAE01A9AADC for ; Fri, 8 Apr 2022 18:54:12 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZnTw27fyz4Qv8 for ; Fri, 8 Apr 2022 18:54:12 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649444052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6bAALpJN7J7a6H9f+fVgV5LCnDVV5PDxVSOJSzeN7cw=; b=pX/8s5NJR5XinsVBHk9k0RqncXWA5RiyhQW+yFmx9a57pF2+k36OsNkVYedk5wQ5jbA0Ah UXF9QP/5mvubl7d0XooWXgXWKaPJt7hORZXU8fOaAQBf2HbvrydwXmqmXalxX4VpkHhkyT W8YNw5cB/xCrOKxTDNruVlitzT/lvKqMYae26QgUOYxcqTmmavwc870Y7Npm1GFe1FG+CB YEbCWO0uacArMMHXP82jZ0wpNPWgwRaBCixVhnmRbgGm46HVrdLArtppkBG6Wbem6lVO6p x9i1XJPl/GMdQ9eiIrpv6h5pTgS0/TPR8FdXBWGYRY7I9fP+ymU5wnATeYrF6w== Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 293672DF06 for ; Fri, 8 Apr 2022 18:54:12 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f50.google.com with SMTP id j9so8486663lfe.9 for ; Fri, 08 Apr 2022 11:54:12 -0700 (PDT) X-Gm-Message-State: AOAM531qq0t5FNZTBCjvIDlR0cUvCXi/d7XP7zVehK4L7rSiAl9y+1/q Y52wMBm13Ku1MBQNRP7R7vniEk2lvoj2Y7zR/mM= X-Google-Smtp-Source: ABdhPJxG881icVWlsxmaDnLmv+Jqo7/uFswKTFE8ZQTnkRuWh/GnnfuwOYIQeH8GyEazR+m+oAepPNnUvAKGXN+vGWs= X-Received: by 2002:a05:6512:3402:b0:448:970:c3a5 with SMTP id i2-20020a056512340200b004480970c3a5mr13019858lfr.576.1649444050610; Fri, 08 Apr 2022 11:54:10 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 8 Apr 2022 13:53:59 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Fwd: FreeBSD Community Proposals To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649444052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6bAALpJN7J7a6H9f+fVgV5LCnDVV5PDxVSOJSzeN7cw=; b=URpzDOfrMH3bj3gvIp1KjLxnEsivEwoiI2H/TP54hgPRYwY20Fe10keSiC2rCaKgY/PLKJ 5kwvDYNC8NRFZdYMQ+wGa7jl//+LHGd5Ybj6iF9FpsZrLBtGKbmk9dmctDuWdaaCozNrhu U6/72kLvFGEm6tnBV1y+Oxqq8uRRUrvYjcRLlwRyFlKpOhG4blHTmWWra4HgmkGuZ64FCA oR+eXaxVoColTSCKDxSWE9wvYxOyYgQsTZzLzeA7wjSbQ3dNqwb1DxpJE/yC6kN227TYZF Ldm4UvH0Ub59AcJTnKt89PbGPWp1MGbbLOqUN16ByxCoxhfImxqTMREOrs7mWg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649444052; a=rsa-sha256; cv=none; b=U7rKfRkrWMKb3xcL6wN8VpA4R2yvk0WnVm+smH2UbT4+q1DUB67014AyR3w0+6jbl6ajAt HpHoRySMJjLTEW8dHwmgMKKQACwGYx/Su4dMdG+yPx+96oq7clUSMGEjtQPXbh7QBAgP/v WN7T0IPB+AuVIc6oB3nqDrMm4OsCgf+qz92x/cMfr8gzUDDWF8xpE49xRCcUDiEIupIaiZ ktibcSr51u69NozD94TMeaPA9RPj3kavCIbcbVimrfZ0PXa+1JbtAblZwQF21Hs3iaEA5M ydFvIj3vd/CHoy5p7aJvfshNyVsyjwExLz1a10DkZadehFykWvqAlnXGSw9a3w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello folks, As of today, the mailing lists associated with the FreeBSD Community Proposal ("FCP") process have been decommissioned. We were optimistic about the process, but after five years it hasn't really caught on in the community. This core team will not be attempting to hastily replace the FCP in what time we have left, but we hope that the next core will take this experience and lead the project into a solution that fills the same gap. Thanks, Kyle Evans (core@) From nobody Fri Apr 8 19:51:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7AFD11AAFA74 for ; Fri, 8 Apr 2022 19:51:35 +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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KZpm63xctz4bdc for ; Fri, 8 Apr 2022 19:51:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2c.google.com with SMTP id s13so3979461vsp.2 for ; Fri, 08 Apr 2022 12:51:34 -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=iAgogrMK5Ccsrqvbhsa8HboJXFdccsqgqa4xoEX+L1Q=; b=w6x25ZDgI19jnWTelr5IkuLEFZ/hq3b3rLm34qfgzGfFHi4FmDyJEnTUAdF87eYBPU mk4BXTIhjjv58DjTRCxKBoIPbfysmA+FiN8Zr/bVVbDw+CKEgqTyQ6c9vRuRlku5lsia 7PFTGWhO55QlbGTyyH6XhMs1AzWoC8qfGT0aY7xUWb/1AfPdPR57DXBddDXFOfPFRTFt HVB953ACIuOFFfFhB/+/xovSmGupafcDMRlopYk0i8XQpb+epOv7r0ZS2RtIGjdtHsK4 8JVvzkDgGfdz6u5HOgBt6z2G/8k02re/bcw4eNP0b4pl1WbXdS5hSdu8XMrocJRINran xxOw== 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=iAgogrMK5Ccsrqvbhsa8HboJXFdccsqgqa4xoEX+L1Q=; b=2BjI0YPA+fn1ZjFvlDoN3cFStysYyYjVxM3ojwUY9cd0i4bTdFchWvfdXev/L5G3ap qJp7xBlwmgeIHpGr8HSgxU+MK+6R+4jXG7ftX9HCB9I8+PyK8MmBXb1qmSX8deUpVoR6 /iejexw2HItDb3bCfXzx3EoyhtSHTlY/r6HytIELoKKq5lr3ot/3TJt6LSRCML/mrAaV SxIutYjHAzEd6ea+Mff6feLJpxF8snRmiXVQmPwOoxxByurN4y0Cjcw0xMbL9WKrYEh4 68CgUByDi/UdReMjqHKUZo7QxAhyxCsqdFc4Q4ThnxN911C2y/MLFAxiR+hvhhuh7ATn wZvQ== X-Gm-Message-State: AOAM531Dwi6YDS25TRFrGsN7QfZ6iR/LDmsNkpI4e37WrJ9pQNgnOuqj 2kMsshEEwUcOIaEGmZeUUggtpl4eaOSjZm4O8rILk/8cpu3FfA== X-Google-Smtp-Source: ABdhPJxOOw+z7hgj72caGCLCBbW9imZBT5YTZ7yU7xigGcStIbWEM+o7YHByao/7PTjuk21jlG0Sn8DNWucTNYe7XRA= X-Received: by 2002:a05:6102:2333:b0:325:b03e:aa4b with SMTP id b19-20020a056102233300b00325b03eaa4bmr6928110vsa.68.1649447488016; Fri, 08 Apr 2022 12:51:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 8 Apr 2022 13:51:17 -0600 Message-ID: Subject: Re: Lost GSoC Work in Perforce Repo To: Jake Freeland Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000099637a05dc29ebcd" X-Rspamd-Queue-Id: 4KZpm63xctz4bdc X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=w6x25ZDg; 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 [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[1]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2c:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --00000000000099637a05dc29ebcd Content-Type: text/plain; charset="UTF-8" Hi Jake, Thanks for your interest in this project. For many years, the project had a license to Perforce servers. However, perforce dropped FreeBSD support years ago and the old binaries have effectively expired, so the project no longer has a license. There may be ways to extract this data, hopefully in the form of a git repo. I've sent inquiries and will let you know if it comes to anything. I have a large collection of weird, obsolete memorabilia from the project, including many copies of perforce trees. I checked, and none of them have even partial data for this project. The data on the wayback machine isn't complete, so we can't scrape it from there :(. Warner On Fri, Apr 8, 2022 at 9:22 AM Jake Freeland wrote: > Hi there, > > I am trying to dig up some work from a Google Summer of Code > project back in 2008. I contacted the developer and they provided > this link to retrieve it: > > > https://web.archive.org/web/20180218121528/https://p4web.freebsd.org/@md=d&cd=//depot/projects/soc2008/&c=AN8@//depot/projects/soc2008/rfrench_mpls/?ac=83 > . > > The code appears to be nested in the > `//depot/projects/soc2008/rfrench_mpls/` > directory from the depot tree back when FreeBSD used Perforce to manage > experimental projects. I was wondering if anyone still has access to this > code? > > I plan on finishing the work that this particular developer started for the > upcoming 2022 GSoC. Having access to those files would prove helpful. > > Thank you, > Jake Freeland > --00000000000099637a05dc29ebcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jake,

Thanks for your interest in th= is project.

For many years, the project had a lice= nse to Perforce servers. However, perforce dropped FreeBSD support years ag= o and the old binaries have effectively expired, so the project no longer h= as a license.

There may be ways to extract this da= ta, hopefully in the form of a git repo. I've sent inquiries and will l= et you know if it comes to anything.

I have a larg= e collection of weird, obsolete memorabilia=C2=A0from the project, includin= g many copies of perforce trees. I checked, and none of them have even part= ial data for this project. The data on the wayback machine isn't comple= te, so we can't scrape it from there :(.

W= arner

On Fri, Apr 8, 2022 at 9:22 AM Jake Freeland <jake@technologyfriends.net> wrote:
H= i there,

I am trying to dig up some work from a Google S= ummer of Code
project back in 2008. I contacted the developer and= they provided
this link to retrieve it:

http= s://web.archive.org/web/20180218121528/https://p4web.freebsd.org/@md=3Dd&am= p;cd=3D//depot/projects/soc2008/&c=3DAN8@//depot/projects/soc2008/rfren= ch_mpls/?ac=3D83.

The code appears to be n= ested in the `//depot/projects/soc2008/rfrench_mpls/`
directory f= rom the depot tree back when FreeBSD used Perforce to manage
expe= rimental projects. I was wondering if anyone still has access to this code?=

I plan on finishing the work that this particular= developer started for the
upcoming 2022 GSoC. Having access to t= hose files would prove=C2=A0helpful.

Thank you,
Jake Freeland
--00000000000099637a05dc29ebcd-- From nobody Sat Apr 9 03:25:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7C6011A906C7; Sat, 9 Apr 2022 03:25:21 +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 4Kb0qj338lz3Jp3; Sat, 9 Apr 2022 03:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649474721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Y3yxpgZoxfflKs/ZkOzVqaw9vXhF5AjrPD0Z5Qzv9uQ=; b=Ovcwiiq9eZ28t5XY5l699kni+MoO7tCEi8o+eeA6iOCNpE+wENuVfDZSJ7yZ4+IFVqQq1r QyAhBoHLeDC81tCqFeP80OsLEn0UGBMDaxPUXbhS2wXmymquQRPN+XX+uPnXHp7OgVYZif 6EUxfhte3Zy8kfbhlohl1eXBQERFiy8c1rfDLln7MwmS9rJK4fC3TemhuvWSnIUkdkn3FN vOrhaYda95v6H8jD7q2a757gQCyq2EUdLd3Oimwn1EBX9XK/WJAU9l/K+/D0W4IG6ZibqE r1ys5H6e170iRW7NmUBR6veG8eXQhhFLwnwgSzTzXNJ0WOBVCG1/BihKZRalJA== Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 441CD20B9; Sat, 9 Apr 2022 03:25:21 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f46.google.com with SMTP id h14so12836664lfl.2; Fri, 08 Apr 2022 20:25:21 -0700 (PDT) X-Gm-Message-State: AOAM533k+6J/5u5TX/3ozgWzF+n+C4WAsJFJUNIvRtmUmoOdM2aPnOHG TF0BJ3zrVPDt4W80GhdEihkSrc8Esz53dq5hH74= X-Google-Smtp-Source: ABdhPJysOwpyBhHvkLM1vZbPZTl0uCPpZxuEyZwZdngkIYlvl9e6kt7CFeFgytu0IuaYCZeBVxVYUZ0lIKIjoFGrDgU= X-Received: by 2002:a05:6512:22d3:b0:44a:518d:c23b with SMTP id g19-20020a05651222d300b0044a518dc23bmr14598737lfu.21.1649474719782; Fri, 08 Apr 2022 20:25:19 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Fri, 8 Apr 2022 22:25:08 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: [RFC] patch's default backup behavior To: freebsd-arch@freebsd.org Cc: FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649474721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Y3yxpgZoxfflKs/ZkOzVqaw9vXhF5AjrPD0Z5Qzv9uQ=; b=cSr6bXBo77hbjorcaszsH/yMub8iNstUTzQuLlRto/fBfzL85CtNUJy1N30CyjKzy3oPwn VlwUJz1Yq2oIE3AyHduiFv2rpXCte/EpHbw4+KIfSPTotkGrNUbdSyAIq1to4WsN2jZEGY fcwAp5jpqzm1+ryI/xuyLy8k5Lrm1OTxLn2GCLHklUVTJctj/+YMSUmJTgPpCe65AAWuAf fgI8QMKJj/ue4b4bcW9cYe9znGn80UQPt9pqXLuD+pR3ewcIzLPklgG69JKN0O2tioReHO 0JCgA2Opan8s1ecFwk3xmIfZRaa636l1rKinnNhLo92mhZfbIYDPEZS5UvoZbw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649474721; a=rsa-sha256; cv=none; b=wDYoECRxRtgayJnJt8jHJrEtQp9kTTVEl27ZUXmAk+9vkPVDeErtdQWiS+0Um3yd4KYVoX bhMClXS5q48IIBCZoRanBdK/SvpiGHdMQ3majeaXx2pfAMRSMBiz1yv4VPW59nC7t2BYSZ EveAQ8WF2Pq+NW/gw+xNbFKBcEwdamHWKpMWin7VFiEiT0o2+dlJDkkwWAEmovcesEKkvA FJWQX15sJuLsO8CBzGueDIK2UUdOZO6lBDSmEK0IX02B4Rl6CMgeDg57jS7tUxWydVYmNx vxlr9NdNdWYkztbaA5sOAod/camErrnBa1AvP6oku8hvhexjvE+U9k4Enny1QA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hello! FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, where a backup is created for every file patched. I'd like to test the waters on switching this to the GNU behavior, which feels a whole lot more reasonable. Notably, they'll only create backup files if a mismatch was detected (presumably this means either a hunk needed fuzz or a hunk outright failed). This yields far fewer backup files in the ideal scenario (context entirely matches), while still leaving backup files when it's sensible (base file changed and we might want to regenerate the patch). Thoughts / comments / concerns? Cross-posted this to a couple of different lists to try and hit the largest number of stakeholders in patch(1) behavior. Thanks, Kyle Evans From nobody Sat Apr 9 03:41:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E55EC1A953AF for ; Sat, 9 Apr 2022 03:41:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kb1Bq4dlXz3NgS for ; Sat, 9 Apr 2022 03:41:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe35.google.com with SMTP id t6so8394529vsq.11 for ; Fri, 08 Apr 2022 20:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HGk+thzFTctV//nQfaFYIijxcu9GDJOv5QxpgEAtTk8=; b=Y/1zsl7WnH1cYIqq5Le4hlwYbLJ/HnRCZRiXjCxQhsugW6fuRH8yutHrOHm6061TlT RUSTKfQOJcemZSBpYNu29PXV6cdhKIX2tCBwCf9fhYFrhzrY9+Z9waAO3grLG9G+AME9 Uiy7L6MdSlwkwjrYTCZF/qUayZiG3wng2+S0TwdjOZ9pxCxEBDXkpJ4tH1/u4xOdDnlh Bh50NkcvXjKUrDIr8jRILaCEHrRe5Wo5muaWyHzOTL1z4IpQA7GbQ7Z4LAf03rO52NWt TwyUBNKpxi8A8JO39nBjcmsUtokDPd/J3rnxpd6WfXZSVfdhwcvVrD8OrDUAEA2XF98I vVug== 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=HGk+thzFTctV//nQfaFYIijxcu9GDJOv5QxpgEAtTk8=; b=Ll/N/7l7D4/ZtuOgzJkQCc7lZiIaSJswC9fqVB+pDvKsFFTove4EaB2Dsg36KUENpi z6YqkYZliu1u4hdOrAO+RpPlS5j72B6MD24vtZ87vwS0F8I6buwU1A1K2f5nMiw3nT+2 B1kZ0lTeQq8JYjJOZ1SKHpTHcWwIfv87UUDBkBUVv81S9KazEOQ5Vg0HZ1+LoWNFoNaL ENNgfA7h7tSxdtKizxNUvWglg2LsXPlGsLaSU/E/Wzadvk4xKAnwbayzNb3rSMDH3HXy suCJkwcYjDvMwPtvGRExcdzsPolss30PQ4t9IzqiJ9t68fGESPdY6QA5c14z5vnhx8p6 q4ZQ== X-Gm-Message-State: AOAM532Avgq/z9ttCb0b5J0TE/wW1hPn3nG+cVtEzR0JAlQLwGrCoUqm FeqkkakP+rkkHOFEOiDdzO+mDQePxs3tihc3XReyCQ== X-Google-Smtp-Source: ABdhPJxrZpD7rzEzckUUUuQvhRd7l/DqYqMHO2oW1CGrU2u/wBHqoydv0Sul+xsJTCKytwiLzNFXRIgVDk+furDWrLc= X-Received: by 2002:a67:cb81:0:b0:328:da1:312b with SMTP id h1-20020a67cb81000000b003280da1312bmr4497196vsl.6.1649475715041; Fri, 08 Apr 2022 20:41:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 8 Apr 2022 21:41:44 -0600 Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Kyle Evans Cc: "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Content-Type: multipart/alternative; boundary="0000000000000fa54005dc307e7e" X-Rspamd-Queue-Id: 4Kb1Bq4dlXz3NgS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="Y/1zsl7W"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e35) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e35:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000000fa54005dc307e7e Content-Type: text/plain; charset="UTF-8" On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: > Hello! > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > where a backup is created for every file patched. > > I'd like to test the waters on switching this to the GNU behavior, > which feels a whole lot more reasonable. Notably, they'll only create > backup files if a mismatch was detected (presumably this means either > a hunk needed fuzz or a hunk outright failed). This yields far fewer > backup files in the ideal scenario (context entirely matches), while > still leaving backup files when it's sensible (base file changed and > we might want to regenerate the patch). > > Thoughts / comments / concerns? Cross-posted this to a couple of > different lists to try and hit the largest number of stakeholders in > patch(1) behavior. > Could one select the old behavior? Or would it just be a change? A new -V value? I like the Idea. Warner Thanks, > > Kyle Evans > > --0000000000000fa54005dc307e7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 8, 2022, 9:26 PM Kyle Evans <kevans@fre= ebsd.org> wrote:
Hello!

FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, where a backup is created for every file patched.

I'd like to test the waters on switching this to the GNU behavior,
which feels a whole lot more reasonable. Notably, they'll only create backup files if a mismatch was detected (presumably this means either
a hunk needed fuzz or a hunk outright failed). This yields far fewer
backup files in the ideal scenario (context entirely matches), while
still leaving backup files when it's sensible (base file changed and we might want to regenerate the patch).

Thoughts / comments / concerns? Cross-posted this to a couple of
different lists to try and hit the largest number of stakeholders in
patch(1) behavior.

=
Could one select the old behavior? Or would it just be a = change? A new -V value?

= I like the Idea.=C2=A0

W= arner=C2=A0

Thanks,

Kyle Evans

--0000000000000fa54005dc307e7e-- From nobody Sat Apr 9 03:44:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E8B781A97C07; Sat, 9 Apr 2022 03:44:47 +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 4Kb1G74TCzz3Qhn; Sat, 9 Apr 2022 03:44:47 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649475887; h=from:from:reply-to:subject:subject:date:date: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=HccpfTPByUs1r/d4/HLDOSSDmQwfELQvqYaDT9Iv0h4=; b=DgSaBuMWWBA+ClhqbENhnqJ/1jgLsvMNOscT3U7E+x7k3VG4AyxlU27MvfEXxKe8tv5S3b vgzyNl/rkOk3wHwdK6VzEQmSJkb0TRMjEjSQS+iQefAxHu92xtSQ5lFRojrLSmgEc7xOJc nmBGZyo7jWN2Fc9Tbd7MRXfeGMvTl5ARyIIqS5jwq8KfOnndkzEE49igmO+vpky5nV4W8q DL19+LUgCZGxZ/Q6jX8pVtkj9r2u6T7eK1Dy8DF+1dks1VJjqGUendu2quOB1+fwxnsQHB ewzfCJyN5DuXYD6UyYFT4fSjRC1LH/veXYFmzht6VXtkQR9jxqOnlTbbjnbDDQ== Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 5FAC7271F; Sat, 9 Apr 2022 03:44:47 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f179.google.com with SMTP id b43so13710145ljr.10; Fri, 08 Apr 2022 20:44:47 -0700 (PDT) X-Gm-Message-State: AOAM531lZgrUJQwLnN8nCyOtq+0q/nFccxrzbUojXR7eq1NQ/oF/XETO Vow68q0hLwkwbiimAWzkPL0IZBzJJ0Ygsx9y9Rg= X-Google-Smtp-Source: ABdhPJzyPcKOYpvFh9ArJmbICY95A33Gktc3Upb5Zu5sNLf3KNGuZeUVG4D2ZGafAMjfxUzEIR40mqfAHi9X867/zmU= X-Received: by 2002:a2e:7c16:0:b0:246:377b:f802 with SMTP id x22-20020a2e7c16000000b00246377bf802mr13466303ljc.155.1649475885638; Fri, 08 Apr 2022 20:44:45 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 8 Apr 2022 22:44:34 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Warner Losh Cc: "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649475887; h=from:from:reply-to:subject:subject:date:date: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=HccpfTPByUs1r/d4/HLDOSSDmQwfELQvqYaDT9Iv0h4=; b=Kg/mpDa9tbUD1YPmM6owe7FdJaCyQXBZ5qtSZxCk2Ud/IjHPS8zTshWqh8dVVrAmruq3x7 ckr1DUTI8AVh0pZC1F/NCqqagpVlK79tmfa++lPFOIZl/V8zSRabr6TspnvSMz96Hq4HCw nZm6egqeOIm3a9ZPMKMyYsSkoE28rMhCh7KH3v//7r1TikB3u9rKDTpRTrFbM2HeoCQXAa 0eE4+VbzRcCao8X6G2Uw+AICiPdM8cyh9l1JZAHeprkc1SXZiWmwGC9c6TMWaAS8eZmd+m wF8L7jytTxd5KsYUI+foW22fvmOwr2zKcSro7AoxyCuiseQSCIyGDrOqVdwq0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649475887; a=rsa-sha256; cv=none; b=KhwikacqGO/22AH//0hMpXIccETK3XXZvNI385rwHlmME7pSMit0Emx67y8hDt0ZCV1MXg mGhP0+jjO+8HGQ7ZmFUFkueJwH2b7gpG618zY5iBI2pcr3LYDIvTi3WQ2MB2IQXqRUL2JG rN/1LX9DnviP+nEczYGwPU75PxT9CxsUA7ETQzvZNe8a1oODqmK+wZ1e2SAEw/lvKlaguQ GNT6lcR0v5sqczZWRUFI+qZZK7aJK2GQxPbIhZTiTC/rzFobGWs/mxNor6Jr+NrzF1ucVW fV8L34QlkzQaCro0b5uZSBlBulvQXRh5JkjOqhqJdAZxeD+CQKzStsKP36zcSA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 8, 2022 at 10:41 PM Warner Losh wrote: > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: >> >> Hello! >> >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, >> where a backup is created for every file patched. >> >> I'd like to test the waters on switching this to the GNU behavior, >> which feels a whole lot more reasonable. Notably, they'll only create >> backup files if a mismatch was detected (presumably this means either >> a hunk needed fuzz or a hunk outright failed). This yields far fewer >> backup files in the ideal scenario (context entirely matches), while >> still leaving backup files when it's sensible (base file changed and >> we might want to regenerate the patch). >> >> Thoughts / comments / concerns? Cross-posted this to a couple of >> different lists to try and hit the largest number of stakeholders in >> patch(1) behavior. > > > Could one select the old behavior? Or would it just be a change? A new -V value? > Yeah, the current behavior is actually represented by the `-b` flag. With the new behavior, we'd specifically implement `--backup-if-mismatch` (a nop from the beginning), `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` but "lighter" in that it won't override -b/-V) and we'd leave existing flags otherwise alone. > I like the Idea. > > Warner > >> Thanks, >> >> Kyle Evans >> From nobody Sat Apr 9 11:47:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD2A81A8358E; Sat, 9 Apr 2022 11:47:57 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4KbCzd01Dgz3nH4; Sat, 9 Apr 2022 11:47:56 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-fs@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 239BloSI006666; Sat, 9 Apr 2022 12:47:50 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 239BlncJ006665; Sat, 9 Apr 2022 12:47:49 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202204091147.239BlncJ006665@donotpassgo.dyslexicfish.net> Date: Sat, 09 Apr 2022 12:47:49 +0100 Organization: Dyslexic Fish To: grarpamp@gmail.com, freebsd-hackers@FreeBSD.org Cc: freebsd-questions@FreeBSD.org, freebsd-performance@FreeBSD.org, freebsd-fs@FreeBSD.org Subject: Re: List Mail Formatting Netiquette [ie: 870 QVO] References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 09 Apr 2022 12:47:50 +0100 (BST) X-Rspamd-Queue-Id: 4KbCzd01Dgz3nH4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FREEFALL_USER(0.00)[jamie]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.83)[-0.834]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance,freebsd-questions]; FREEMAIL_TO(0.00)[gmail.com,FreeBSD.org]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N grarpamp wrote: > Use the clean habit mailiquette rules to make reading > the world better for everyone :) Whilst I agree entirely, the issue has been raised before, and nothing happens. The sort of posting styles that used to get people kicked off lists are ignored. No-one cares any more. P.S. I gave up trying to decypher the "replies in blue" messages - the whole thing is in white-on-black on this terminal! P.P.S. We're probably both guilty of crossposting, but as I said, no-one cares! P.P.P.S. Maybe I should just have replied, quoting your whole message with just "me too" added to the top :-) Cheers, Jamie From nobody Sat Apr 9 13:06:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 24B5A1A9A9C3; Sat, 9 Apr 2022 13:06:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbFkP14xlz4bL0; Sat, 9 Apr 2022 13:06:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id dAixnHzbogTZYdAnUnLzjm; Sat, 09 Apr 2022 13:06:36 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id dAnSnMspFqyysdAnTnNbrL; Sat, 09 Apr 2022 13:06:36 +0000 X-Authority-Analysis: v=2.4 cv=Y6brDzSN c=1 sm=1 tr=0 ts=625184dc a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=z0gMJWrwH1QA:10 a=7Qk2ozbKAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=whenkf9jZ82PwOJKZ_8A:9 a=CjuIK1q_8ugA:10 a=HNhVPpsFFhwA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 51896115A; Sat, 9 Apr 2022 06:06:34 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 446673AD; Sat, 9 Apr 2022 06:06:33 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Kyle Evans cc: Warner Losh , "freebsd-arch@freebsd.org" , FreeBSD Hackers , ports-list freebsd Subject: Re: [RFC] patch's default backup behavior In-reply-to: References: Comments: In-reply-to Kyle Evans message dated "Fri, 08 Apr 2022 22:44:34 -0500." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Apr 2022 06:06:33 -0700 Message-Id: <20220409130633.446673AD@slippy.cwsent.com> X-CMAE-Envelope: MS4xfPlcm9V00LeZBmPaR+826IRgrXaRXST6AAYJ8Q9k5TOYzzcKJaAW7ULXXCvQQz6LnQ0BsgNnFzW3mj8hSrHAm7RywHVElykilB7Ikbn7XBbDn03AwEWh wdPNlu0+nRX3RhSz958tFK1OS80d0QB9ECyR9kY7mlu1ILCWyyeBJXl2hT/Gqnd1cgRYeJy8C22y4rrlQl4RLZf2WAMLnd8uP9EmETlFsKZwU7BZrYcZptFz n2J+T+bVigkhZJZZaOL59+NftFszBr0n7Rt48vt4sblFeZFVpDqJFG/lLnBBSES3bb07ZZRsbV9HTdKcCtGXWIaBTK0wmk9nMN12NalOlvQ= X-Rspamd-Queue-Id: 4KbFkP14xlz4bL0 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [2.11 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_TLS_LAST(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.910]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-ports,freebsd-arch]; R_SPF_NA(0.00)[no SPF record] X-ThisMailContainsUnwantedMimeParts: N In message , Kyle Evans writes: > On Fri, Apr 8, 2022 at 10:41 PM Warner Losh wrote: > > > > > > > > On Fri, Apr 8, 2022, 9:26 PM Kyle Evans wrote: > >> > >> Hello! > >> > >> FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > >> where a backup is created for every file patched. > >> > >> I'd like to test the waters on switching this to the GNU behavior, > >> which feels a whole lot more reasonable. Notably, they'll only create > >> backup files if a mismatch was detected (presumably this means either > >> a hunk needed fuzz or a hunk outright failed). This yields far fewer > >> backup files in the ideal scenario (context entirely matches), while > >> still leaving backup files when it's sensible (base file changed and > >> we might want to regenerate the patch). > >> > >> Thoughts / comments / concerns? Cross-posted this to a couple of > >> different lists to try and hit the largest number of stakeholders in > >> patch(1) behavior. > > > > > > Could one select the old behavior? Or would it just be a change? A new -V v > alue? > > > > Yeah, the current behavior is actually represented by the `-b` flag. > With the new behavior, we'd specifically implement > `--backup-if-mismatch` (a nop from the beginning), > `--no-backup-if-mismatch` (turn off backups, equivalent to `-V none` > but "lighter" in that it won't override -b/-V) and we'd leave existing > flags otherwise alone. Looks good to me. > > > I like the Idea. > > > > Warner > > > >> Thanks, > >> > >> Kyle Evans > >> > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From nobody Sat Apr 9 14:04:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 45B111A8A9F3 for ; Sat, 9 Apr 2022 14:04:51 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbH1Z3ynzz4m4c for ; Sat, 9 Apr 2022 14:04:50 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42a.google.com with SMTP id e21so289691wrc.8 for ; Sat, 09 Apr 2022 07:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=w/XrGPw49D4bwm+as0pMQrSlpO0dg9OZYORw4JJri4s=; b=i1WKV+xHii/leD6aOp9XHWHhlaRuCybREP7eQ1bPvGlVxBGWzN7ylB3/IGb21anoe+ 0bp9HyNh/DnxhljfoC/g/YNK8RMUnGS8gApOiqLvNV6TOLT2tNAn4f9ZQwfJ8jpY70AG wLFsj+nN4GyI0dNdVGT7KKsvCMd/E3HFsxp5+Nbl9pdF/HlUO/mOxxi5yXvVR0yqtWZV czgbDUDknrtqstQjLFbXA2XXWXJ38G4SKB1uneXzpskyQ/4dDo9ntxeati8bFgwfrnvl wpDUxLL24unI2t0hO/Uie3qL4ovdq3R/g0GCZqtI+j3q1h/MnLyzMahMDNLQG/FXtg33 NeZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=w/XrGPw49D4bwm+as0pMQrSlpO0dg9OZYORw4JJri4s=; b=iWn17HYgn9qoFqtljGqte+9FIqErFdYhtPf6GmF2sb4TRzfGJB10UtSveqDSYuEg1b TJvdmkkX/6QY9HrSZyfprhFj4zCoNq1bw+7RKXx3oicNwhsAbUAVUTeXZu/gHwzULotq 41GsO6O2wlLha82MfsCl+znYJhOibUJeNm2e+IC+kHjN51qZMfhGqhIj9K0x4EdOPz+x Fr4vJP0MjEuGyE6UlRSilCFsw535tLMjqJMsRI2lB0CREbqCz+q/9AtuuvT44qhnYO3+ 9lAwLI4PZqbZljP3jWTCNorNMhB88KVa+NAVY4mq5OMJabWhc2OnqwD3fP9asdU05Peg d6Zg== X-Gm-Message-State: AOAM531JKUTC7H/tD++ZDFT3KzO136EhljJEbKwBabkDjVk7W46wu+zl lxOE6K6ixIDa5ZA9UEiXKU64SSV35RI= X-Google-Smtp-Source: ABdhPJz5VdwDrS2Ej8VqAZl5leOWDgzEYQGiiWxwCPcNg0FxfoK11YAmNgVrbfv+weewFkEd7YObYw== X-Received: by 2002:a5d:5512:0:b0:1ef:5f08:29fb with SMTP id b18-20020a5d5512000000b001ef5f0829fbmr17986453wrv.653.1649513089042; Sat, 09 Apr 2022 07:04:49 -0700 (PDT) Received: from [192.168.1.10] (88-108-159-26.dynamic.dsl.as9105.com. [88.108.159.26]) by smtp.gmail.com with ESMTPSA id a7-20020adffb87000000b00207982c7f4dsm4039602wrr.67.2022.04.09.07.04.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Apr 2022 07:04:47 -0700 (PDT) Message-ID: <79a94f31-44e7-e218-3959-338c107f9520@gmail.com> Date: Sat, 9 Apr 2022 15:04:45 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: Please advice on applying GSoC Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <86a6djvw2q.fsf@phe.ftfl.ca> X-Priority: 5 (Lowest) From: Graham Perrin In-Reply-To: <86a6djvw2q.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KbH1Z3ynzz4m4c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=i1WKV+xH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42a as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[88.108.159.26:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; HAS_X_PRIO_FIVE(0.00)[5]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 21/03/2022 21:23, Joseph Mingrone wrote: > or in Japanese From nobody Sun Apr 10 01:17:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2B3671A995C5 for ; Sun, 10 Apr 2022 01:17:30 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [IPv6:2001:4b98:dc4:8::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbYxj080Nz3lZS for ; Sun, 10 Apr 2022 01:17:28 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id A334C200004 for ; Sun, 10 Apr 2022 01:17:27 +0000 (UTC) Date: Sun, 10 Apr 2022 03:17:25 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: [RFC] patch's default backup behavior Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KbYxj080Nz3lZS X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 2001:4b98:dc4:8::232) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [1.36 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.54)[-0.540]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.97)[0.972]; DMARC_NA(0.00)[bec.de]; NEURAL_SPAM_SHORT(0.13)[0.132]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::232:from] X-ThisMailContainsUnwantedMimeParts: N Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > I'd like to test the waters on switching this to the GNU behavior, > which feels a whole lot more reasonable. Notably, they'll only create > backup files if a mismatch was detected (presumably this means either > a hunk needed fuzz or a hunk outright failed). This yields far fewer > backup files in the ideal scenario (context entirely matches), while > still leaving backup files when it's sensible (base file changed and > we might want to regenerate the patch). > > Thoughts / comments / concerns? Personally, I'm more often annoyed by the GNU behavior than not. Especially when working on pkgsrc, the GNU behavior of sometimes-not-creating-backups actually breaks tooling. I also consider the rationale somewhat fishy as tools like sed have historically not operated in-place. Joerg From nobody Sun Apr 10 14:43:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E1CA51AA808B for ; Sun, 10 Apr 2022 14:43:54 +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 4KbvrB5rKLz3L1D for ; Sun, 10 Apr 2022 14:43:54 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649601834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q32kha6FdoEfJv1DIv0uH+VTQFx8hhKeL1dp7YkLSlQ=; b=L2+e41dcRfKpPX4SrT/jbmL1jN6MUYKEeiCuDqj+OZA+yR9d8XUGZ/ZKyaEYopaja4U3KZ iGK8f+rDU6ycStbRdYo+9qJpCNFJ2gMkNllBORp/S4nWMvpjlHISILl0O5cZPk7HU7ahGy gVff4qORI9CiHGMrX+wd6GsL2adWbg6OM2nnMgPZ8CaqEhubkwyJU3IOzqhmF9hvUUJUJh oHMCvCQXlwXtocQfYse3VzEamYtg+WpywBay6iq2+rclZ2xYzHG/LEZHd2bGPJ83pLWEyA HtMFQddj8h7qym7ErmKxoD6ZMa+07Bm9IQjoAJsRvePohgZmWS8Nn03lLlEO8w== Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A36892563C for ; Sun, 10 Apr 2022 14:43:54 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f175.google.com with SMTP id u19so7552987ljd.11 for ; Sun, 10 Apr 2022 07:43:54 -0700 (PDT) X-Gm-Message-State: AOAM530ZOjHw2hwkdspmD3NfX+LefydIg+XUQ0xJ51h5DDQ6j1D4KrQe OdzDKX+5iAyYGU4u+xo60e0ttUZeY4vULxJdO0g= X-Google-Smtp-Source: ABdhPJxMpKYz7UaxnKEOcfLGY1qwHMD2bLnfNPuxNh397riVkiYNOVEcA2/w4CmJ5UfHIz5O9M4duJMo1/f6J6wsEpI= X-Received: by 2002:a2e:8e96:0:b0:24a:eac4:7ffe with SMTP id z22-20020a2e8e96000000b0024aeac47ffemr17730405ljk.430.1649601833135; Sun, 10 Apr 2022 07:43:53 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Sun, 10 Apr 2022 09:43:41 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649601834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q32kha6FdoEfJv1DIv0uH+VTQFx8hhKeL1dp7YkLSlQ=; b=KYzoaMyuuEu+2DhT1Em1t1zCjzvqITKqhSrCYRtHww1VDVsVVxKEWsS8qFsqzLVBRjHDWq kVsnDEblW4tBkRqjMp81feSYcupIDhR9HSYMda0CoqG3GBolhGYIf5MMDlArkXaLTHDLHs lu24UukDzHTZ5RcTixcBO9v1OF1dTxgY6qjSKI3b9TCIgCSG0oX7o4p43VjMjA1J+41oGE dSKpwi0XDlbLSxREYFgud4flWoumbriL+blexpcDVOlHxlU2unk8sGHqD4KqCl8DCoa9Zn 35vuHEEX3B25c8ZpKc2GNNBOHhafLl22bodMIyckRBXtg4AxQOF4qCo28tAdGw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649601834; a=rsa-sha256; cv=none; b=RE/tK/bC6wZVsSB0k+oBXmgQrEuuqCn94zV0imlp87SVZRKjzk1pf+lgxRHkFC9VeSSqqt RR0Zj9eex/ANyzCh/OLeCa+SMBqUKe6JVii/7Rz57vXYekF5JFk1o2pE7/s+7N70gSF3sl qxuThip+4yc+F775vT0XJtutT6b7OnXEc40XEujr0y6WZfvCIBxXbS51aS6lyyIMnffYeY ycWKbDopmzVlXqk0MToX6/+MH89mSDcuo7PK9pjwAFcQXi9vcJrcGpa8ZfAZrf4CDvvbpU 8u88avWEoi9atTgIl19bPK+CdTIXlajL8McitZEz4Ti8FewvXPIBFU/Uh34WSg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sat, Apr 9, 2022 at 8:17 PM Joerg Sonnenberger wrote: > > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? > > Personally, I'm more often annoyed by the GNU behavior than not. > Especially when working on pkgsrc, the GNU behavior of > sometimes-not-creating-backups actually breaks tooling. I also consider > the rationale somewhat fishy as tools like sed have historically not > operated in-place. > To be clear, when you say 'tooling' here, are you referring to pkgsrc tooling or random third-party tooling being used as, e.g., build dependencies? From nobody Sun Apr 10 15:21:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C58781A802A7; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbwhK5BS1z3QT4; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; h=from:from:reply-to:subject:subject:date:date: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=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=R5Sgs0XhsfCx0GvjnwTg1SdbMhmywjLHvkpICEV20ucNf83iVE3z3xBHkfssyA0XzBInZL OvsXwm/3Z4hVBVZ0+Pfbh2gtqqxJS1IPPTaQLHYDa40udZIPv9k5Oo5Bl4EdkR1k4nAhHz PSWC27x4ageQQb2Ua98+6LmmatrV54TRnF/+E8ggDpJ6C+icqb//NnV3MgZr4I7i4MZB4g pljnkX6+fU97GWv8KIkVyARv4GXD33MvgNeXdVV9ztioZtjL37uuuNZIB5e7rMVoyPcaj8 T326cns0wfKZdvyJHPbYjT3dbyTSaWdicaft27M2rUZQk4uv3sDqVTt0OW0KSQ== Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8FE752603F; Sun, 10 Apr 2022 15:22:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id bq30so9835971lfb.3; Sun, 10 Apr 2022 08:22:09 -0700 (PDT) X-Gm-Message-State: AOAM533Ft514UNoMPEsNd1csw0SrEcVfnZ8IkSFR9kCTUMh3203nwMzd HYb9saHyUsGpSB6y2FlrxNmdnuO8x1Z08tRQOk8= X-Google-Smtp-Source: ABdhPJw81RkuwjIjEIuoMmfhAKxD0q7To/wBNmepcGP3hCF+WRSVMHLhs8DXScueQpptsVxofzop81HXCAJybeW8Xc0= X-Received: by 2002:a05:6512:39c8:b0:46b:9aed:389f with SMTP id k8-20020a05651239c800b0046b9aed389fmr3816778lfu.194.1649604128153; Sun, 10 Apr 2022 08:22:08 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> In-Reply-To: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> From: Kyle Evans Date: Sun, 10 Apr 2022 10:21:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Matthias Andree Cc: freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649604129; h=from:from:reply-to:subject:subject:date:date: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=f8pnRzvxMYr7mzzuQKb4VNfO3I5D8B4RHQLdO7cAkpM=; b=Pr68PfcZLqPB1/jcjGpnbodHtWaQqwoyuthlz5gAdq1qZw/gHhVUgZDlLhXmwEHMVI+pOP Mn1VObhmX+cY1KP6iMHEe+0q4sWRDufbsZWu/ceIIpKDq3t2IAuQbNiWXqLzynHrxlJAlG ZIPB5nm3ClncuY7FkKV6FNgJw+HDmY8lSf0QKQ187G6CwWJiu3iOlkP5rHzrI3RSyFR/Ox U97iidGP+QQ0VgK1dQ34MnfxaKXEnRgClPrReVxZCLsqd5QOXMhnoWYIZm40LxSBA1Aon7 EorUTp0CvyjS7OFHv+JLbvtHhtxyr31T+TIdMikbk0BFdP5NfU3vfiRYL39kvQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649604129; a=rsa-sha256; cv=none; b=AWS1qjVBCB1kU6FoW5rQdajzUBmPx83lH3aFdAFFCN4CPv2kWnZ6GpP7NK1VQnQvP3usJZ JMI0TJH5fsgtPep4pQqb0vR5m5FJsovCXGGEOnMT09zG351Vm+ROHHHNLkDxEYbyt+ZAfN tVpAMBIfmpLQJhKAdxBuCIZy7l5o9iWYFs9x7ooyWP4q3vHF8PUxA0Jxuc5Y/MNMybP+oq zqv09W5H72IjWO9AqiB0c44vSp+mHfyRi3xSDVwCOTljjoi/g4VOXlX4LRgtbs26GmkOWX e0YZh8k6n/Wjylil+H4ldsyKQhtlQ4U2TZJiXsoICEu8CQRaap9M/dluIA/CrA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > > [resending from hopefully subscribed address that it makes it to some of > the lists] > > Am 09.04.22 um 05:25 schrieb Kyle Evans: > > Hello! > > > > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > > where a backup is created for every file patched. > > > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? Cross-posted this to a couple of > > different lists to try and hit the largest number of stakeholders in > > patch(1) behavior. > > > > Thanks, > > > > Kyle Evans > > > > Kyle, > > you would discard the original reference for gendiff or "make makepatch" > in ports, that would make patch - edit - regenerate-patch cycles require > extra efforts, and if that extra effort is only remembering patch's -b > option, but if we do it consistently for FreeBSD 14 and announce it in > due time beforehand, fine. Certainly worthy of release notes. > Arguably, `make patch` should be using the `-b` option even today to be portable across different patch implementations. Yes, we have our own patch with our own behavior that we can rely on, but I'm personally a fan of not tying ourselves and, perhaps more importantly, others (downstreams) into one behavior when we can trivially wire it down. > I personally also dislike and advise against "magic" and if-then > behavior. It makes documentation less concise, it makes tool behavior > more complex to judge, and from people who script a test-based approach, > this bears potential for confusion, astonishment and other effects, > because behavior as to when we get .orig files gets *apparently* > inconsistent, and may send people who have not read the entire manual to > the letter on detours finding out why they sometimes get .orig, or > worse, when developing patches, and interaction with other tools might > surprise people, too. > There are certainly trade-offs -- with the GNU behavior, you can instead quickly use the presence of an .orig file to know that you may need to sanity check the result and tooling can key off the same rather than checking patch(1) output for words like 'fuzz'. fuzz has bitten people before, it will bite people again. I'm not so sure that the scenario you write about will really happen. GNU patch has done this for many years, and I haven't seen such a proliferation of confusion. If anything, I see more confusion in practice from BSD patch's default differing from both the much more common GNU behavior and also from POSIX-specified behavior. > IF we are to change policy, my vote is to ALWAYS leave the .orig files > away and not only write them if we also write .rej files. I explicitly > dislike the GNU behavior, which seems geared for interactive use rather > than scripting. > re: interactive use, I think that's an entirely separate debate, even. :-) My personal opinion is that defaults *should* be geared more for interactive use, and scripts should be (+ able to be) entirely explicit about the behavior they want. This is a general opinion, not just with patch. If you solidify script usage with flags, then we can be a bit more fluid so that tooling can adapt to the ever-changing user landscape. Obviously you can't reliably predict potential for future behavior changes, though there are some obvious candidates like this one where the difference in defaults between us and other implementations are well-known. > I checked POSIX 2018, apparently the backup files (.orig) are only > required if -b is given, so omitting them would seem fine to me, and the > rationale section suggests that for consistency with other utilities, > the default would be to NOT save .orig file, but the -b option can be > used to request them being written (but then consistently on all files > not just those without rejects - also because there is no working patch > -R for ed-style diffs.). I'd actually be OK with that, too, to an extent. Thanks, Kyle Evans From nobody Sun Apr 10 15:48:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E03711A87DBE; Sun, 10 Apr 2022 15:48:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbxGN03Sdz3lc5; Sun, 10 Apr 2022 15:48:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id s28so3668920wrb.5; Sun, 10 Apr 2022 08:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=Yewh/XlVg5+aywoADu3h0ltVxqXZcs72Sk6Dq+0qLOI=; b=njOtJs+CHcZS1s3H+H2NE/OqxQcS/JeD+J+jc95IzkdUUUh5uWZoG2XGwWMY67vLt/ tEkaWcf/90NaQI9zx7LuXZMi0p4Vo2S/FyklDSQjXtcyGZRxkH0URFA6VrpHLoXVn+Pq mF6KRJHpWuPMOlu8fJsjbQnkEXCuzdrVbktuQFFCHfAvDh6qVcwRHygrXT9vkwqCD+Z7 4BJuNgPkeNCq/d5Ck4a13HMqIo83XNwirfqMhYOfStiheYJvP+XcEer15h3614mcGIMY AP+M+K2WeZgT1Lfz89RufNpszS/UrOtOvQWgRzGxmUu1hwYyGlu0VGgkiSkoRsGNfTeh idgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=Yewh/XlVg5+aywoADu3h0ltVxqXZcs72Sk6Dq+0qLOI=; b=cpvdcEMMWxeIC1N1w55R1BSoSdJ1tMJKZN4fKYHtIpqF8gH5JuvxvFE6d6KA3LjBTv 70MwAlBbdVpu1o9A/1yFWXjv/FYSsLD6ZhpzyHTePqG7uNi8THVb66b4AfZVsVHrBSyD 2tO7C4zIbquK7+u1lXMwDQiWjcc7RgsC/UDy6LQr5MiSUziVcL6hfdB8VKymblmIRsiP PuG9WceeTKUPkpLaSrI4yUFFxWpfrPON9U6IAJyfvYxHtZzYK3PMvxSQYagyfrqhKCUi ZJEl26i+qPdKJIyThaCsgtq6nUhDxN6d7MBp6pKu85qR3MEv4GMIsfO0lnMk8JO4dl6M sV3w== X-Gm-Message-State: AOAM533TpEpN4KTraEVMxG1/GnbKqk+cyckOLqJOoY5WYFjUrMpeDH6z X1d2FPCXhrEyyliR9YxuZedR1MZqE5g= X-Google-Smtp-Source: ABdhPJyEyWJ1CzupJagxM2+oVQugaVZamO/oQc2UWJ8Wn2UYXudnrGUAXKCg2WghbyZq0qypmfWcgg== X-Received: by 2002:a5d:6d0f:0:b0:207:990e:8e6 with SMTP id e15-20020a5d6d0f000000b00207990e08e6mr9161410wrq.384.1649605690866; Sun, 10 Apr 2022 08:48:10 -0700 (PDT) Received: from ernst.home (p5b3be0d9.dip0.t-ipconnect.de. [91.59.224.217]) by smtp.gmail.com with ESMTPSA id s17-20020adfdb11000000b001f02d5fea43sm24742088wri.98.2022.04.10.08.48.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Apr 2022 08:48:10 -0700 (PDT) Date: Sun, 10 Apr 2022 17:48:06 +0200 From: Gary Jennejohn To: Kyle Evans Cc: Matthias Andree , freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Subject: Re: [RFC] patch's default backup behavior Message-ID: <20220410174806.48e53928@ernst.home> In-Reply-To: References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KbxGN03Sdz3lc5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=njOtJs+C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-0.97 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.224.217:received]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; NEURAL_SPAM_MEDIUM(0.03)[0.028]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; MLMMJ_DEST(0.00)[freebsd-arch,freebsd-hackers,freebsd-ports]; FREEMAIL_CC(0.00)[gmx.de,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 10 Apr 2022 10:21:56 -0500 Kyle Evans wrote: > On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: [big SNIP] > > I checked POSIX 2018, apparently the backup files (.orig) are only > > required if -b is given, so omitting them would seem fine to me, and the > > rationale section suggests that for consistency with other utilities, > > the default would be to NOT save .orig file, but the -b option can be > > used to request them being written (but then consistently on all files > > not just those without rejects - also because there is no working patch > > -R for ed-style diffs.). > > I'd actually be OK with that, too, to an extent. > Please do not change the behavior of the -b flag! I make patches to /usr/src/ to eliminate things I don't want compiled in when I run buildkernel and buildworld and then move the resulting .orig backups to the original file names to eliminate those changes. -- Gary Jennejohn From nobody Sun Apr 10 15:52:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CA3321A89F21; Sun, 10 Apr 2022 15:52:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KbxMh5Bc7z3nGQ; Sun, 10 Apr 2022 15:52:48 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649605968; h=from:from:reply-to:subject:subject:date:date: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=99XcnMzcRm5b8LiWj7h6PylRwjeEm10jcbTShBSSV78=; b=NvFfN86i3zSUxKTss7I68APY03TNYUB+E+5UTGFHtfWxnkXbFFApX6lKUCK+vkdAKLG0YI niU1ClkrmtRWtmiihznl6rTbzkHT3QCijKyZYWH8au7RL5iq/4QP7LBX0a4aEEnEqOGIBd fXZjvxMSa/RIb1+P4QwuLEYVQr1xkH1m//4rDdbpWn4soXhscn29hH+pzd46ZA7VS8TJXk P+eyGQhvB4iSirmt+qhRimp3vEtvzPfPsK1RDGbgyivCIu3ypIL8fMd9ZoeZmWGov5r4By ppVAj9oHnjJEi9DghBaWCEWVc65X54DtBPK1hrEfuCLlmEY1Y07f2RBzs/Vewg== Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 8A3152628F; Sun, 10 Apr 2022 15:52:48 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf1-f50.google.com with SMTP id x33so16228400lfu.1; Sun, 10 Apr 2022 08:52:48 -0700 (PDT) X-Gm-Message-State: AOAM533CmzueBuePJLlLFPmiZGKG1uis4OQ2muXDmEQX5QEe0TXUVNMx NbQCYL5iQWNSR0GwIxrjfEqQdlhwwfF5Gb8lQYM= X-Google-Smtp-Source: ABdhPJxnziySmo74fixHuIoUnxiXKbemJaTEgnKf+4h++BxcWwOICIWdkEZ95J33eUcUcH9GRVHnuneGUC8nO3Tb8RY= X-Received: by 2002:a05:6512:39c8:b0:46b:9aed:389f with SMTP id k8-20020a05651239c800b0046b9aed389fmr3883046lfu.194.1649605967183; Sun, 10 Apr 2022 08:52:47 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <9f6f6d16-8e2e-b91d-9ba1-b2cf13270020@gmx.de> <20220410174806.48e53928@ernst.home> In-Reply-To: <20220410174806.48e53928@ernst.home> From: Kyle Evans Date: Sun, 10 Apr 2022 10:52:35 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: Gary Jennejohn Cc: Matthias Andree , freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649605968; h=from:from:reply-to:subject:subject:date:date: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=99XcnMzcRm5b8LiWj7h6PylRwjeEm10jcbTShBSSV78=; b=aB2C4p1J5JUnwcVHLEhDld9ReNq1svngemBKTWnTP2nOVhnHAMwYqyM5shwP3gHRyKIrJw 3q5T5PCSMCuk9QqwLL5DbbCWaTpmOCVFGNK1l1+NfCef+soOsfoWpOkk/YId3NVdkedePq ngOgri96YHInKmhqUnbfzRyyI/MuUlZB3iwrKPlgvu9U4E0gns5YOBpKsMAVvkqY4VmsiO cIoD89gFO68kTXYY6c8iLqM3WzR0eei1odJMqjooAr4XlQV6nACWtTvDPZ/cqjfVi2Cyjt FCWkkwXhEw48PWnSbDFzYam5VHAPl0Bejkd5nZKubCOExeunBiYZ3GMbNaHmgA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649605968; a=rsa-sha256; cv=none; b=UwB61pCQZRIt+89dFGlNIlXeEgFKZ6ym4MT0Tn36kuNS8TWQ+R/dKVu/2kbUIZtWYQwXUN Espt3d6AIsdhDyT9IjXCNnjnMTZ6iqKHma1Y90//u/zvKDYhzFrrfjiaq6kTWWrka5eenj ywp0vroilsh3eQK+m3E7Eo2cPjgwaU8ewWFQRCl1lRRHGyPYC7jv3Gha+Q5pXGjTurjRwY UYn3N2JIVk496Huz1cbPebgUeiYxu5BvHEMi809+svVQgG2I0P+24nkjzAMQuZ+QXzHq66 gwEnz9Tk3I1kuZj8hFQIlaLV7SIB9FVOUJSZGdvs9RakSGc5ZzFhRuGwsp6HDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 10, 2022 at 10:48 AM Gary Jennejohn wrote: > > On Sun, 10 Apr 2022 10:21:56 -0500 > Kyle Evans wrote: > > > On Sun, Apr 10, 2022 at 5:33 AM Matthias Andree wrote: > [big SNIP] > > > I checked POSIX 2018, apparently the backup files (.orig) are only > > > required if -b is given, so omitting them would seem fine to me, and the > > > rationale section suggests that for consistency with other utilities, > > > the default would be to NOT save .orig file, but the -b option can be > > > used to request them being written (but then consistently on all files > > > not just those without rejects - also because there is no working patch > > > -R for ed-style diffs.). > > > > I'd actually be OK with that, too, to an extent. > > > > Please do not change the behavior of the -b flag! I make patches to > /usr/src/ to eliminate things I don't want compiled in when I run > buildkernel and buildworld and then move the resulting .orig backups > to the original file names to eliminate those changes. > No one has proposed changing the behavior of the -b flag (that would be silly), but rather the default behavior (sans -b flag). The -b flag is the proposed solution to maintaining the status quo across such a change if it happens. From nobody Sun Apr 10 20:47:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A6EF91A8E87E for ; Sun, 10 Apr 2022 20:47:42 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [IPv6:2001:4b98:dc4:8::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kc3vx4zjqz3PDW for ; Sun, 10 Apr 2022 20:47:41 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id 64AAF240004 for ; Sun, 10 Apr 2022 20:47:39 +0000 (UTC) Date: Sun, 10 Apr 2022 22:47:38 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: [RFC] patch's default backup behavior Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Kc3vx4zjqz3PDW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 2001:4b98:dc4:8::230) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.11 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.955]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-0.96)[-0.959]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::230:from] X-ThisMailContainsUnwantedMimeParts: N Am Sun, Apr 10, 2022 at 09:43:41AM -0500 schrieb Kyle Evans: > On Sat, Apr 9, 2022 at 8:17 PM Joerg Sonnenberger wrote: > > > > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > > > I'd like to test the waters on switching this to the GNU behavior, > > > which feels a whole lot more reasonable. Notably, they'll only create > > > backup files if a mismatch was detected (presumably this means either > > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > > backup files in the ideal scenario (context entirely matches), while > > > still leaving backup files when it's sensible (base file changed and > > > we might want to regenerate the patch). > > > > > > Thoughts / comments / concerns? > > > > Personally, I'm more often annoyed by the GNU behavior than not. > > Especially when working on pkgsrc, the GNU behavior of > > sometimes-not-creating-backups actually breaks tooling. I also consider > > the rationale somewhat fishy as tools like sed have historically not > > operated in-place. > > > > To be clear, when you say 'tooling' here, are you referring to pkgsrc > tooling or random third-party tooling being used as, e.g., build > dependencies? pkgsrc tooling, e.g. managing category/package/patches. Similar questions might exist for FreeBSD ports. Joerg From nobody Mon Apr 11 16:42:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A15978D62A6; Mon, 11 Apr 2022 16:42:25 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4KcZQS40Phz4XmC; Mon, 11 Apr 2022 16:42:24 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 75CE84C063C; Mon, 11 Apr 2022 11:42:18 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 11 Apr 2022 16:42:18 +0000 From: Pau Amma To: Kyle Evans Cc: freebsd-arch@freebsd.org, FreeBSD Hackers , ports-list freebsd Subject: Re: [RFC] patch's default backup behavior In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.8 Message-ID: X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KcZQS40Phz4XmC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; HAS_ORG_HEADER(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-arch,freebsd-hackers,freebsd-ports]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-04-09 03:25, Kyle Evans wrote: > FreeBSD's patch follows historical patch(1) behavior w.r.t. backups, > where a backup is created for every file patched. > > I'd like to test the waters on switching this to the GNU behavior, > which feels a whole lot more reasonable. Notably, they'll only create > backup files if a mismatch was detected I don't know what GNU patch does, but I had a look at SUSv4, which says -b always creates .orig files and not using -b never does. But you sound like you're actually speaking of .rej files, not .orig files. > (presumably this means either > a hunk needed fuzz or a hunk outright failed). SUSv4 says a .rej is created when applying the hunk fails completely, but not if the before context is found after fuzzing, that is either/both near where if was expected and after trimming some outer lines of it. (There's no option to control whether/when a .rej is created.) > This yields far fewer > backup files in the ideal scenario (context entirely matches), while > still leaving backup files when it's sensible (base file changed and > we might want to regenerate the patch). I feel that way about the SUSv4 version, but I'm not sure how conformant the GNU version is, or what you think should happen with respect to .rej files. > Thoughts / comments / concerns? Cross-posted this to a couple of > different lists to try and hit the largest number of stakeholders in > patch(1) behavior. I'm not sure -arch@ will accept my reply. This may or may not split the discussion. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Mon Apr 11 16:58:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B37FFCFC532 for ; Mon, 11 Apr 2022 16:59:01 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcZnc60cKz4cpt for ; Mon, 11 Apr 2022 16:59:00 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 23BGwnF7073622; Mon, 11 Apr 2022 09:58:49 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 23BGwmcC073621; Mon, 11 Apr 2022 09:58:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> Subject: Re: [RFC] patch's default backup behavior In-Reply-To: To: Joerg Sonnenberger Date: Mon, 11 Apr 2022 09:58:48 -0700 (PDT) CC: freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4KcZnc60cKz4cpt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-1.47 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.995]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.37)[-0.374]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > > I'd like to test the waters on switching this to the GNU behavior, > > which feels a whole lot more reasonable. Notably, they'll only create > > backup files if a mismatch was detected (presumably this means either > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > backup files in the ideal scenario (context entirely matches), while > > still leaving backup files when it's sensible (base file changed and > > we might want to regenerate the patch). > > > > Thoughts / comments / concerns? > > Personally, I'm more often annoyed by the GNU behavior than not. > Especially when working on pkgsrc, the GNU behavior of > sometimes-not-creating-backups actually breaks tooling. I also consider > the rationale somewhat fishy as tools like sed have historically not > operated in-place. Personally, if YOU like the behavior of gnu patch, by all means, please USE gnu patch. Please do NOT make bsd patch behave in a different manner simply because you personally like that other behavior. If you want the stuff to look like Linux/GNU by all means, go RUN linux/gnu!!!! -- Rod Grimes rgrimes@freebsd.org From nobody Mon Apr 11 17:07:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 02841CFFCF8 for ; Mon, 11 Apr 2022 17:07:18 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KcZz96gDNz4gPR for ; Mon, 11 Apr 2022 17:07:17 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649696837; h=from:from:reply-to:subject:subject:date:date: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=5HDSWKLoC9K0EzQSPt2nSmYrp8/P7EJwqhlIu9us3BE=; b=JFXRgOk+/4A2ZC4edMrZ1eKqDSxKytr81FVX9Er9UwnKuc1JEmW80PD7H43wfklgq3bXr2 c1jMfNO+GFKPS/NVDM9SoGV5SkdpptEt6hWaQC7xhu05U05Aykv0hNptAupuWad6WFvJin Re/w1nCr02hLayTbrvLtr4Pad3baTCFMhxZ9i4ek45Sf9SmOWrMGs0Qzy9pF5JUH4+xHPj vEQ4EFsBM3LCbkd2e37OhDQe5aXtIi9sv/flXUs1hqm5FcjxSDkiBRb4G10PMsG9WAAXBi 29Knink2Ojg8EFhByhyq42iNLRXB77FzjEz42q7my07aydF3hRAkeszSydzhrg== Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id BFDBA3E17 for ; Mon, 11 Apr 2022 17:07:17 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f178.google.com with SMTP id r18so5299459ljp.0 for ; Mon, 11 Apr 2022 10:07:17 -0700 (PDT) X-Gm-Message-State: AOAM530Yjly4NePiKGc+UQHr+26xqysK1oiLiTheVPB3RABvva14Kwyt IX91YgJ9+HwRcTFVzgbYeLrzPf3pYOfKc4CN+7Y= X-Google-Smtp-Source: ABdhPJwwytg6UFBUAnXSrRfTw3VHgqc3uuEBDn9QoCMTBEm2pElrUJosF2G50JrHgkxy7z5MaqfC5+DpTGg4Hi8nHOo= X-Received: by 2002:a2e:9e19:0:b0:247:deb7:cd9f with SMTP id e25-20020a2e9e19000000b00247deb7cd9fmr20257869ljk.261.1649696836252; Mon, 11 Apr 2022 10:07:16 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> In-Reply-To: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> From: Kyle Evans Date: Mon, 11 Apr 2022 12:07:04 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: "Rodney W. Grimes" Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649696837; h=from:from:reply-to:subject:subject:date:date: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=5HDSWKLoC9K0EzQSPt2nSmYrp8/P7EJwqhlIu9us3BE=; b=TRQAZrlAI38NDXKcWEuMmOr/b/S2lD1bmuwXo/Ed2a7yUMYaRHtJSMX2XII8OopnGFAU0w 4HxILuEMM5vPA1xDEiq1DbxreJWEUIuz2Ml6ILEZJyCK5i3qJPPeHhmFntKgzluIZ3IhQI sfQS+/BZQ6g56uG1BpvBSAQ/bsuNTmrLgoXy5jCPghDfS7xzR4zvsdh5z1LqBDyxl9EQ7R ZaFeB1EkA1jjX9L9GIfZCwIf4LiLY9TfOspckplAQ+Xv8qRujcPfEPs2XD11FM5dZH9fmN EvL3jSSWqyTBSSLs7370wxyNRQwdfcBdX23JC7EVMbw5ZluRC2sG7QLH4bB2ug== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649696837; a=rsa-sha256; cv=none; b=oc1HF8odJnCRKfKt8LBnd1TbzZQqTwDzrOTWWw6KYbF6XAl1QP9YLDUaZ9u1Q95z9sDXCJ CE+0XOABbUCXuC7DhPWueDopoycaQxIR+3J40xjFhzTgPt/UC9BaGNFdO3sVPMA+C3+GDt jkp+SnctOZL7Tzn8bzxg1VMv0WUzTKOOb7OUqjhOPPMHmgUxkX5wXcOvNwOeXYBm8eAaQS Dbei+u5BzVBymfWnYiDIidKRVaefL2zi2rkLwGmhTXCfHEj6nzz1knje9Qj7R9cOqB0krN Rti+pwFTp80lUWe2jTBzTJpRgbFCPd1OeC+XL1B4w84MSSQVLNyEr2XjDlQjxw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Apr 11, 2022 at 11:59 AM Rodney W. Grimes wrote: > > > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > > > I'd like to test the waters on switching this to the GNU behavior, > > > which feels a whole lot more reasonable. Notably, they'll only create > > > backup files if a mismatch was detected (presumably this means either > > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > > backup files in the ideal scenario (context entirely matches), while > > > still leaving backup files when it's sensible (base file changed and > > > we might want to regenerate the patch). > > > > > > Thoughts / comments / concerns? > > > > Personally, I'm more often annoyed by the GNU behavior than not. > > Especially when working on pkgsrc, the GNU behavior of > > sometimes-not-creating-backups actually breaks tooling. I also consider > > the rationale somewhat fishy as tools like sed have historically not > > operated in-place. > > Personally, if YOU like the behavior of gnu patch, by all means, > please USE gnu patch. Please do NOT make bsd patch behave in > a different manner simply because you personally like that > other behavior. > > If you want the stuff to look like Linux/GNU by all means, > go RUN linux/gnu!!!! > Your response is completely missing the point, and could have been omitted. Thanks, Kyle Evans From nobody Mon Apr 11 17:41:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AA198D2612 for ; Mon, 11 Apr 2022 17:41:40 +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 4Kcbkr04xJz4n7k for ; Mon, 11 Apr 2022 17:41:40 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649698900; h=from:from:reply-to:subject:subject:date:date: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=0VzzMlT6cdPSmOK4GHT4nTtFVTISf5GrPQ8SbuaOYjk=; b=QhZXcoaImOu7IFK6cmC8jMDMqx9YsfNOOqI7epiEznmnpe7skV2zi/gb4Q6qnlmZ0veUin hjCZKaT1EBeaO3IrNLUd7qXotEB8Lart4qmQW+i3+EVsYVvtYq0GH8MzGe1FK1pS9T7hAA 7K5wzrG0PAOgZy5m3q3Rob00laSwRIQBhVDUWLCJ3krrQlRzPBpzBJg55Rvx3vf8MRsy93 lspIwOGru1Sl+x6vHI/5sEOdfiM6YU1RoMMw+kODV6Ixy7451RPP2WS8mQrB59KKMtXH61 OTrW1UpbxYcxYta7Jl2sCXE2z4bin+O+SdZsVnBGpNWI8Mrj+LnPL5P9jYz/MA== Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id D257F4124 for ; Mon, 11 Apr 2022 17:41:39 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f172.google.com with SMTP id u19so11463072ljd.11 for ; Mon, 11 Apr 2022 10:41:39 -0700 (PDT) X-Gm-Message-State: AOAM533ngGGLOkrryxop8eqxKUJCqZAlfqTSb9kX8lNcoVO6FKqWuVD8 ZDvNsYmHhmnAQOwvIEvubrLN195Nik5SlgUNzcQ= X-Google-Smtp-Source: ABdhPJwVdn9DcqeyrCuGG8Vki8JqwpTJuD3z6ZU51mSdfraRvbpRBQ3rrg9p7lYztQbpdJ8Af4LQKd1fUcL2y4iXEWk= X-Received: by 2002:a2e:9e19:0:b0:247:deb7:cd9f with SMTP id e25-20020a2e9e19000000b00247deb7cd9fmr20345997ljk.261.1649698898483; Mon, 11 Apr 2022 10:41:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> In-Reply-To: From: Kyle Evans Date: Mon, 11 Apr 2022 12:41:27 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] patch's default backup behavior To: "Rodney W. Grimes" Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649698900; h=from:from:reply-to:subject:subject:date:date: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=0VzzMlT6cdPSmOK4GHT4nTtFVTISf5GrPQ8SbuaOYjk=; b=D4SZYy8/r8afak7hZZRTGKsnmsW/QnAGzfqa14l9jIt01VdluXJjXOTDOH2kmy5lBsQwv2 y3htcemRw+oAKBj6FoPkHZaUcEbuVKVxOv4BdMwkiW0lljTmE9He7Dh0UPqM3YWJ3CE9ax mFXCvrBAhIHNKlMPt+vIh7Rvf69kVkt0GhqxxJNHv1X0t6Ju9eoQjdgNYLo6nm0UgZAW+b FTHGtk3Cvr0eZ8K0kCCe/+RjKRNW0p35HUy/ZSvn5XkRNX7H5ZKeYEOJmcgYGyAERZq+nw vkjC1wjaWtjeAmFu6kTzbiBQ1ns1lxAjRmWAc+kp3eIMpMshFe5w20VUD1u8VQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649698900; a=rsa-sha256; cv=none; b=cj8JZQ7WA69OXe9VN5h6tamDwECdbJaV1y1cKUJT4RjaTmi3mUSgkqjQMwLKYDkM+G+CQJ fsn9CjByV/3KwxQRBXU1LjKJeX64krtvJ1vRSQsFnedMcLAWnQ1L8qVvcqkUKrceu2E8lG IR/Pm8ZvoGn5C9vxioYjZNu37GLCExuYZrMU6Aa9oys8RwNjs3yh9NZ264Y8Q0wdUPvucl 8j6y/G0ngbmQzlKjQyvOh5mEIo+IyktacVd7CSXvUEW3m/y204JypgQMS6dYhZfYyv6ssb HM4qGtMH7HV2SknbxIEoLXYbWr7lh7JKo/RcfJE1gNzVgnfVTzRqmYWZQojRNw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Apr 11, 2022 at 12:07 PM Kyle Evans wrote: > > On Mon, Apr 11, 2022 at 11:59 AM Rodney W. Grimes > wrote: > > > > > Am Fri, Apr 08, 2022 at 10:25:08PM -0500 schrieb Kyle Evans: > > > > I'd like to test the waters on switching this to the GNU behavior, > > > > which feels a whole lot more reasonable. Notably, they'll only create > > > > backup files if a mismatch was detected (presumably this means either > > > > a hunk needed fuzz or a hunk outright failed). This yields far fewer > > > > backup files in the ideal scenario (context entirely matches), while > > > > still leaving backup files when it's sensible (base file changed and > > > > we might want to regenerate the patch). > > > > > > > > Thoughts / comments / concerns? > > > > > > Personally, I'm more often annoyed by the GNU behavior than not. > > > Especially when working on pkgsrc, the GNU behavior of > > > sometimes-not-creating-backups actually breaks tooling. I also consider > > > the rationale somewhat fishy as tools like sed have historically not > > > operated in-place. > > > > Personally, if YOU like the behavior of gnu patch, by all means, > > please USE gnu patch. Please do NOT make bsd patch behave in > > a different manner simply because you personally like that > > other behavior. > > > > If you want the stuff to look like Linux/GNU by all means, > > go RUN linux/gnu!!!! > > > > Your response is completely missing the point, and could have been omitted. > This response was unnecessarily short. I'll expand on that, to be constructive. If you re-read the original e-mail, including the subject line, this is a 'request for comments'. I'm trying to assess the social and technical hurdles to something like this, as well as gauge the community interest. Userbases evolve, software evolves, peoples' needs evolve, all over time -- assessing this kind of stuff over time is a useful exercise. I expressed my preference and requested others' commentary. In return, I've received a mixed split of opinion, and I've received some technical issues as well. We've had a relatively healthy discussion, and as a result this change will likely not happen. What's not helpful is e-mails like the above, which simply attacked my position while adding nothing of value to the discussion. This kind of attack has no place in a healthy discussion, and I would encourage you to refrain from doing that in the future. Thanks, Kyle Evans From nobody Mon Apr 11 18:36:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7051911D8120 for ; Mon, 11 Apr 2022 18:36:41 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KccyK2mKhz56Fv for ; Mon, 11 Apr 2022 18:36:41 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649702201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=e+zOUYkOeN/1VouVnchjF6/Gqxmnk38+ovwdWo7RQ+k=; b=wRsMMw1loaVciJ1/AMFhj9LQwRtJjph4+cmOJuf2PqqUSKNQtN+FLkYh4kngKxHVqmCc8o RvtPIGfGAfHtuuWg7vk2Or0KAPatyoLjgNyDwsLp7sin99WU8kMAryahFagGhHEX/fI4o7 CIqERP9AIdnQTOj5mhLQ/PJ83Ev+rmXFtxL8cyxLSvGUfQMHghTQiEjDE/mcmpiSRGtIBA b1gZYOQJ2wqcedzk+QZc8SHQ17CnIDvbSw404l4A5dgfRsPpw0Pmlhnph7r/dsoFYo1VdE wYid4XKYM4WWZTDrB3IQYqblpYUjlAXofOkAnJ/CiFdGh+AxBXmNrOKOgaTUSQ== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 3E7D11EC2F; Mon, 11 Apr 2022 18:36:41 +0000 (UTC) Date: Mon, 11 Apr 2022 18:36:41 +0000 From: "Piotr P. Stefaniak" To: FreeBSD Hackers Subject: ping: split the visual part of -f into a new option -. Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649702201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=e+zOUYkOeN/1VouVnchjF6/Gqxmnk38+ovwdWo7RQ+k=; b=E+XEW5WWlUkeRH3FnPsxH6q1G+dC9XdV3OrmdLtcT3QFAlxnuIJAZOx1izmcMlvLfZ5WYc Pjg2IptDNs0GA8NIWdGgfYyAiVtxQRktygh4+mmtMNiNttFtN6oJzwfQ4AIcwVe5opoDQS NQuVotjvAl6wr6wQ5l+Jo6fXnh89KSWMeeU0YMNBG3nCUgdvZsMo/hx2BE6tUydGdObBu5 O0NJNFjcfjYPBHrbKRk1HWZp5IgCdsbdExOEiQolj5KIRNjjkYMeUsjoWFll7tU16KB59o kocrFbfd/07D6S/PvMmfVAk2I+j7yue+9nGDXYd+pnP7zUdxbF3o0Mtms6/9ZA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649702201; a=rsa-sha256; cv=none; b=QaGu/SEKexQQavBhXX9nZoGVUMZxJEWTMPw79VLNCXancw3b6kcLHcRID8nGaASYZw+PBz 8ewk9UwQ1DX4gbAO5HCqGzIaIv5jXdow/GiWI4lxxrbihAWwIYgn8pBxN50cj/15jNFTyZ SaIof6i2e4Bm6EgtSTW4vOfRh/pe/l3u++5ZlxGx+1HQzNwQ3DN03YMcnpDteVivq3oANL zBdwonCouUiwy1rOQvnnn/J6kECG+Gtux3sH1MuFkvsr6h4vx/Ja/fTYc94a18bGRXr0Vs KSIRyKsvbN+mPrD3E3zVjV57jc6M1uXSYyZW1cRBCX4IpHaGOStEq0DtTwqOrA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hackers, In https://reviews.freebsd.org/D34882 I propose to split ping's option -f into two options: one for flooding with ICMP (-f, no change in behavior) and one for affecting the programs output (-., a new option). That way we would be able to ping a host and not spam the terminal, and no flooding would have to be involved. I've been doing this under Linux as ping -fi1 host. PS. In D32943, D32944, D32945 I implement the base64 command. Piotr From nobody Tue Apr 12 15:10:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 179D81A985AA for ; Tue, 12 Apr 2022 15:10:49 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kd8LH6Hbqz3q9Q for ; Tue, 12 Apr 2022 15:10:47 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649776241; bh=Af8UZfpPapQrDiGu+gmRq3R2L86LpO7OXi+uBf2lEYY=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=jgwvE43S2fly/AMwnfZ5tILCWV/ci0PAFYjq5Qvd6stviKtqLoWNHg/LB/eTTJZv0cMvxvIyWY4e+SPuP3mAJ+lI8DtXys5v9sOtQdq9I9iZNIJ6L9N0cyG1qamuO6SLFTPfj9RuM8m+lTe5xwwY1fLUethyO+nEHlY6UBDLEUhIpjIbgRhbq9Bo4Rx1BVsRVDDciByCHDwnskJNhU02ZkplM/odH10pvkVCyQIq0Iuiipv64evyjaFL9F9wkyKW+OPgR6SjxplIU+htaCsyXfGKHMGcnu4Tpr19NBgKIS2mIWzdfSXuIldZztbqK5bMeTgR3lo4bF0aXAa17UcDMg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649776241; bh=qIzhkxrmRQiRC3DQWDwi+frzj+Z6NGIblsFG7cDi5KK=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Y+LxCJ52W6iqhVWpZeX0HUrbkZXLBNLLr+tlc6N6VTwrm23/w/4ef0B07ahjt7J/E9pmIODiKk6HQzsm6pJe0T4n3hy8fkW0HF2HVXMS5+2LJW2268v9zCKwy8j1a5Xz8ZfGdhCHfKAJrvpRXOFVWt+/RGkMHb+8xxeLgWNNVTemBJuyqauzbUPWTOgkkV1wzdjEStard3mOE3o+ninbLdExTDwYN2rqZuoioiSB493SUVngL+XR2SAr5IWcINVPOh3hxEIgUFeJPZHIBRaGmSJds9tFrjAMOK71Xfy31JKzfC9kK+r8fxtwF6bKHs6ApzKMIYxxz1MWjm2tqJXk7w== X-YMail-OSG: CF3PtMEVM1nhD1GqU5q2MXvFi6QR4F9sStBwQoxgTgSnRrC8YLWBTKxZ3EyouT7 v80ceR8zEFqyrgireGdd8Dnl4OdPRrxLwNri8cU3bsEfR2KycXtqF9zDT1ON8tJIjBRG9wC9LCcP ZXqc9EVTLbyUAIU35jeOcrzlEkEc507AXuG0KlrBRQY6PxZAuaMeTLiwq0bT1fB2qzzd4p2mt7D2 dKcImuJhDfPMOpDOESxmGtnu.bAMNv_e.sqCBVOekOVHZe8H5JcUCxFEpldZ5nnuVXGGvbrrM1X8 37D0X9jWFI4AdlXEM2dWN.zg3oflYb6TgqsbSWxU8M9FL_UvXDv0370M2rnWgE7xK3uEpZMSHjSh x4icLOuqjr76EKsHhmNlAifYhYXFKNQQ2o6d9SKUuaLTV.LPlDiD.ynNgy5Tpc8Wdy2u5hulJhXA _6_dO8gGMNb4_FcBTPHujZR58v3c4FLE_btftPpdtNEVThxkml4cIRQGakiADXu8W0MIhL850KHf HrWCMGQAvzMBg8Ztg2cmLX2ZHZImzACQI1gzHDr_AsXsp_3tbzTC9ltOLne_XBJyrtbdPc_gBlya keHoIbDkL3ZHoTXTTmBatMyfuhwk9mdm8dWDrsoM49NNL4TWDsU_UUNi3SqQFkf4ZzZP3HsE3rE_ vrTmAZp_3uJsio8mwArbQRj016q0VdpyxIxTO0ETVueUjBD1LPiGXMs2iPIOg8gGAzNL2MMhHAS1 KN0DrdppFDp.YFEzqFRxHRYaCXa4ppUptq1PwfVxSHKOY_tFFqXBJJ8vqCm9F5U8a1kDr3t1F4.m rGCRj2FruvyMfc7W7H_ihY0u_TJSwfn.pILmCY2C4o7MpBwOeDlDLxrUvRYNqIMQwhnS4pgwDQNt dazngVHWmRBr.1qbUtGg1DyslnQXd3l1KR1XzbCBY9C7eGn6zQMmrc9NbKiLGw414ijrwPnlH8Gv Zdagclcu.eYIJLbFe7U.x_KXNi0vDkcshCzEIz8id7FdVH2CMjLqa6gnhDDqnnu9oTVBYtglbXHs sobNx5V7M9hrW9L_XVJq4EKDKBiVCrHdtG7RVakNu6T9mXa4l77MZSoH7.E4YX56VfsQOraA0mMI nmqEFavx1bAztZgvRCDts1phnFHZhqs2RfXDA6Ke_6w334zIXPz1h91PbuUdQK2_hlyAG9tsgUcc kDQEzyACBA4Yb8.VfrdHvxrdAzlDTRosTq30pS2N.BhbJ1HimSAdElyLvZbXwTR8mRnfbID7ug_c pbpD.FkuYKxlg3xkh6FR1LG5Spo9p7B3o57WUpR3.xI8n7OKphfKkowABCqQOTRRPHQwmbPTZMb9 aMXAr6KumO2adFoDZCvXmjkqnoPNOVvpDqQknFR.XAIUUHjLGVc0m1ydoWfyrvGSFz2u9utiE151 lqRX.gwNJuVh2z2TpxACKXFzrcEr_2Fm5h.YWDsxBdFvzrhOtt8fgTixbJ8W5PZWY_z0wwrRQaAS xWUs_IODu.bN3tFb2Dwndyikj3uAsGuwsMq1aJ7ZKWQpnhirpH2S2byei9K.lxqrU8w5bNBmVw93 fPFZwWyw8cGnT.mH_xJjyS0ReNj7DbtwppCbTaK96m2PJWY0s2yv81I9oVCsEVELm4mfM7_GAAfJ UypvowIMzVDFUnsrVkgVUzWFS74n_yZVq4o78d.XBa7paUcrK040cZ4FD.qnf8p_ml9bhwTAV23R IkO4qdI.W90aRVPe3q11F5O0D2XEXeXaBhdUxg8mp7qwvsHx6swZvlNv75UyDyOBaxdr_94TLjVj 4yBh1belGcjMwOeb5n3ZxiekLFmg.LXwcUOAf3SUuqidYX8v0WWueWdtUJuuZFvV5udg1olxlQmO DEIx1RlUSbDtuA2AfOMR0ZCJuNrSjPKEX8EqUX7gOl6s28wMtyP_vKBsomKj3LiBP.mMBYfBtyjk A.q8_tb7psIikW4hOpptfl8f1EVeaCfF1xdftx_Fc_CSJ43x324d816DrjsqMsC2un_l1vlr3Qy. N01aY8kochMxQ9SlruDUAtKR6Lbz8IexUFCPkEaYifn.voOcZuWbU0ofVTwFqbOJ9ijAf58QKgMr xPwrVydT1QKZzIX4zsQCkV3oWqfZpfca5BX.EJXmcfvtrCbE.rrD74N3ubFrgOOiAGKXAP9_VrEo donyIJENHb22VteTH5LYViYOGW2CleNYCIx6wiVNLgk2xpZzmDA_Q5j_KrGNmYrWJ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 12 Apr 2022 15:10:41 +0000 Date: Tue, 12 Apr 2022 15:10:36 +0000 (UTC) From: mahesh mv To: "freebsd-hackers@freebsd.org" Message-ID: <1524993805.98701.1649776236883@mail.yahoo.com> Subject: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_98700_734778856.1649776236880" References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> X-Mailer: WebService/1.1.20001 YMailNorrin X-Rspamd-Queue-Id: 4Kd8LH6Hbqz3q9Q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=jgwvE43S; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of maheshm_v@yahoo.com designates 74.6.129.81 as permitted sender) smtp.mailfrom=maheshm_v@yahoo.com X-Spamd-Result: default: False [-3.86 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.87)[-0.870]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.99)[-0.992]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[74.6.129.81:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.129.81:from] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_98700_734778856.1649776236880 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, =C2=A0 Need you help regarding an urgent issue where we are observing an issue wit= h Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to EP and= the system experiences the READ(10) errors. The READ(10) error recovers with in couple of retries most= of the times but few cases we have observed that the read retries gets exh= austed and =C2=A0system moves to unusable state (continuous g_vfs_done() errors) . We are using Junos but= the xhci driver etc.. are all pristine stable 12 drivers no Juniper specif= ic changes. =C2=A0This issue was never observed with Linux kernel 5.4.2 on the same HW. =C2=A0Errors Seen on console =C2=A0 (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain FreeBSD/arm (Amnesiac) (ttyu0) login: I can share the USB traces taken at the USB device if required. Thanks,Mahesh ------=_Part_98700_734778856.1649776236880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi= all,

 

Need you help regarding an urgent iss= ue where we are observing an issue with Freebsd stable/12. The DATA0/DATA1 = are out of sync with respect to EP and the system experiences the

READ(10) e= rrors. The READ(10) error recovers with in couple of retries most of the ti= mes but few cases we have observed that the read retries gets exhausted and=  system moves

to unusable state (continuous g_vfs_done() errors) . We = are using Junos but the xhci driver etc.. are all pristine stable 12 driver= s no Juniper specific changes.

 This issue was never observed = with Linux kernel 5.4.2 on the same HW.

 Errors Seen on console

 =

= (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00= 00 28 cf 28 00 00 40 00

(da0:umass-sim0:0:0:0): CAM status: CCB request completed wi= th an error

(da0:umass-sim0:0:0:0= ): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00=

(da0:umass-sim0:0:0:0): CAM status: C= CB request completed with an error

(da0:umass-sim0:0:0:0): Retrying command, 2 more t= ries remain

login:


<= /div>
I can share the USB traces take= n at the USB device if required.

Thanks,
Mahesh
------=_Part_98700_734778856.1649776236880-- From nobody Tue Apr 12 16:36:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7C60611D8636 for ; Tue, 12 Apr 2022 16:36:11 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdBDp6FnPz4ddH for ; Tue, 12 Apr 2022 16:36:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649781371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n40rhCO5QfH2KpgJZs1ZFpwqiL6lZqLSE2CRIo/NawQ=; b=BiGCNuKBDNtWZ90HjF/9oNVOS0342+M2wDbXn3+3ezd0M4h+GB3niLaeAYPscMAYpuy7At xjRAoOz9Jeb8GcapHbqH4I1jlW+NEfRQIDp5AKfmpw5uI0Ma5ScuJ80IMvYQGIKrpka2kN IdSQUJIi+0i1dyazWHaukZJPbqYqCpc5Wzz3BsascBjlPcIF7lTHdl45+mrtXwc/8z+lhX vsiFCvEdd07GatMLwpvIbktm15M3pXkmdsI8hbHEX+l1sUjaXg+0TMBAND3H4moSvz99bp rmhU40tzXOdl0cVUP5xbl/4z0WA8PyyljNxqwc/sM3UaJ0o+ng4tBAF20CDNTQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id A892D207B3 for ; Tue, 12 Apr 2022 16:36:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.202] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 5F69030517 for ; Tue, 12 Apr 2022 17:36:09 +0100 (BST) Message-ID: <6c8a812f-438c-dfac-7ba8-b9ae6abf0840@FreeBSD.org> Date: Tue, 12 Apr 2022 17:36:08 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC] patch's default backup behavior Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> From: David Chisnall In-Reply-To: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649781371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=n40rhCO5QfH2KpgJZs1ZFpwqiL6lZqLSE2CRIo/NawQ=; b=x6Ov/jgaQQqOFwRTpaxJYqDYaczrz/8I/celnCoDiwCclD0FiqQ6qPPF69/rAJTt8yYj4z uNkJdpILe0FH3emjFEDaMeNr7wQGZbiDukd/bwJncaiWbiNlqUcyPPIGfRuSvauHQBunhK 2rL9QKtirf87lc66H1d0R/h3iU4rqLvp8Wlw/15lPIjWreUteHioqvtFx/iJWpeESIX78l lhd+3l1494/6lEvo7i8yHiXMZWenAyWRGNa/vERUHLONeGabNxG5afZI5CngKwQ+SK2xbz 7fCQEhr0ch+ytuHdk9YMyeNkf/XNhDOqnSSJ4e2UYlf7ITw8tXMvjXUdRKv6Vg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649781371; a=rsa-sha256; cv=none; b=A6gotdeK8uHUrs3szl1mA1A+UJ2wj6Krul7dha+8M287reHz/JhoNS1GmvVxlA25ilJ9Vl XrVIqXT6U25W/80E24eDgSxXOQ2qmTW5sKpat7TPpGquISmI62qCcvLkq3iS2bKwMrvFOF tnsl7BTaaUsdqIIdLSgIpmjgtOI9bi0f6rFJIWyzjjOd0eUAM2VSVI324X/g9mPu7HrqMd FoVglfM6rDaGPdaPi6YnignDM1jIfWPppr6D0YVzhs2TPE1bGCTGPLvGaKtCqWvCAXo6CB 0KRpXia9TcP9TMdsj/dpnlsM4uwJq9RT4wkN5FrszxpQo5fiQ7NiRMXbluDLqA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 11/04/2022 17:58, Rodney W. Grimes wrote: > Personally, if YOU like the behavior of gnu patch, by all means, > please USE gnu patch. Please do NOT make bsd patch behave in > a different manner simply because you personally like that > other behavior. > > If you want the stuff to look like Linux/GNU by all means, > go RUN linux/gnu!!!! There are two opinions that as almost invariably wrong, in any context: - Popular thing X does Y, therefore Y is good. - Popular thing X does Y, therefore Y is bad. This thread started with 'popular thing X does Y, we do Z, let's evaluate which is better'. Reducing that to 'popular thing X does Y, therefore we should do Z, if you want Y then you should run X' is unhelpful. It is also how we end up in a situation where everyone runs X and we sit around wondering where all of our users and contributors went. We should neither adopt or discard a particular behaviour in patch on the basis that GNU patch does it. We should use the fact that GNU patch does it to gather data on whether it's a desirable behaviour. We should adopt their good ideas and avoid their bad ideas. That is precisely the process that Kyle is trying to drive and the FreeBSD system will be better as a result of his work. Personally, I hate having .rej and .orig files scattered over my filesystem as a result of patch failing and I end up having to write a `find` command to delete them all. Does that mean that I want to give up kqueue, capsicum, out-of-the-box ZFS, a sane /dev/dsp, jails, clang as the system compiler, a `tar` that knows that `x` means 'extract the thing, you don't need me to duplicate the information in the file header to know what it is', and so on and run GNU/Linux? No. I take Joerg's point that GNU patch *sometimes* creating them makes tooling difficult. I would be quite happy with a solution that they are created unconditionally with a flag to disable creating them (I would then `alias patch="patch --do-not-leave-stuff-on-my-filesystem"` in my `.profile` and forget about it for interactive use) or that they are never created with a flag to enable creating them, which I would never pass except when working with bits of infrastructure that explicitly want the .orig files. David From nobody Tue Apr 12 21:26:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 503F11AF2ED7 for ; Tue, 12 Apr 2022 21:26:44 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdJh36dt7z4YjM for ; Tue, 12 Apr 2022 21:26:43 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 23CLQbI0025245; Tue, 12 Apr 2022 14:26:43 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 12 Apr 2022 14:26:36 -0700 From: Chris To: mahesh mv Cc: freebsd-hackers@freebsd.org Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 In-Reply-To: <1524993805.98701.1649776236883@mail.yahoo.com> References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> User-Agent: UDNSMS/17.0 Message-ID: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_8d1fa1456429cda9e1f83f19b150896e" X-Rspamd-Queue-Id: 4KdJh36dt7z4YjM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_8d1fa1456429cda9e1f83f19b150896e Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-04-12 08:10, mahesh mv wrote: > Hi all, > >   > > Need you help regarding an urgent issue where we are observing an issue with > Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to EP and > the > system experiences the > > READ(10) errors. The READ(10) error recovers with in couple of retries most > of the > times but few cases we have observed that the read retries gets exhausted > and >  system moves > > to unusable state (continuous g_vfs_done() errors) . We are using Junos but > the > xhci driver etc.. are all pristine stable 12 drivers no Juniper specific > changes. >  This issue was never observed with Linux kernel 5.4.2 on the same HW. >  Errors Seen on console > >   > > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain > > FreeBSD/arm (Amnesiac) (ttyu0) > > login: > > I can share the USB traces taken at the USB device if required. > Thanks,Mahesh I just replaced a drive 2 days ago that exhibited the same behavior. I haven't (yet) checked the replaced drive yet for cause. But what I chose to do was as follows. Get a new (known dependable) drive. Add it to the system and dump the data on the failing disk to the new drive. At least you'll have a safe copy of it. You didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT or ZFS? How you proceed after making a safe copy will depend on how you manage your disks. UFS/GPT?: simply remove the failing the disk, and change the entry in fdtab(5) to point to the new disk. ZFS. It should be enough to simply replace the failing disk with one at least the size of the failing one and resilver. HTH --Chris --=_8d1fa1456429cda9e1f83f19b150896e Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_8d1fa1456429cda9e1f83f19b150896e-- From nobody Tue Apr 12 21:47:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E212C1AF7953 for ; Tue, 12 Apr 2022 21:47:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdK895p0qz4dY5 for ; Tue, 12 Apr 2022 21:47:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 68C4889284; Tue, 12 Apr 2022 21:47:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 23CLlZBC014615 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Apr 2022 21:47:35 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 23CLlYjE014614; Tue, 12 Apr 2022 21:47:34 GMT (envelope-from phk) Message-Id: <202204122147.23CLlYjE014614@critter.freebsd.dk> To: mahesh mv cc: "freebsd-hackers@freebsd.org" Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 In-reply-to: <1524993805.98701.1649776236883@mail.yahoo.com> From: "Poul-Henning Kamp" References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <14612.1649800054.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2022 21:47:34 +0000 X-Rspamd-Queue-Id: 4KdK895p0qz4dY5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- mahesh mv writes: > READ(10) errors. The READ(10) error recovers with in couple of retries m= ost > of the times but few cases we have observed that the read retries gets e= xhausted and [...] About once a week I see the same general phenomena on a RockPro64 running = 13.0-RELEASE-p6. After "usbconfig -d 5.7 reset" and "zpool clear" the ZFS mirror is back in= operation. The other drive in the mirror, (-d 5.4) never does this. This server has a twin ("keith") with different USB disks, never seen it t= here either. Despite spending a fair amount of time on it, I have never been able to find any hints of hardware trouble (ie: USB drive, USB cables or the industrial-grade powered USB-hub.) Usbconfig on the system in question: ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DSAVE (0mA) ugen2.1: at usbus2, cfg=3D0 md=3DHOST spd=3DHIGH = (480Mbps) pwr=3DSAVE (0mA) ugen1.1: at usbus1, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen5.1: at usbus5, cfg=3D0 md=3DHOST spd=3DSUPE= R (5.0Gbps) pwr=3DSAVE (0mA) ugen4.1: at usbus4, cfg=3D0 md=3DHOST spd=3DSUPE= R (5.0Gbps) pwr=3DSAVE (0mA) ugen3.1: at usbus3, cfg=3D0 md=3DHOST spd=3DFULL = (12Mbps) pwr=3DSAVE (0mA) ugen5.2: at usbus5, cfg=3D0 md=3DHOST spd= =3DHIGH (480Mbps) pwr=3DSAVE (100mA) ugen5.3: at usbus5, cfg=3D0 md=3DHOST spd=3DFULL (12Mb= ps) pwr=3DON (90mA) ugen5.4: at usbus5, cfg=3D0 md=3DHOST spd=3DHIGH (480= Mbps) pwr=3DON (500mA) ugen5.5: at usbus5, cfg=3D0 md=3DHOST spd=3DFULL (= 12Mbps) pwr=3DON (300mA) ugen5.6: at usbus5, cfg=3D0 md=3DHOST spd=3DHI= GH (480Mbps) pwr=3DON (450mA) ugen5.7: at usbus5, cfg=3D0 md=3DHOST spd=3DHIGH (48= 0Mbps) pwr=3DON (500mA) Most recent event was yesterday: Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 08 42 8f 60 00 00 08 00 = Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 3 more tries remain Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 08 42 8f 60 00 00 08 00 = Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:04 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 2 more tries remain Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 08 42 8f 60 00 00 08 00 = Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 1 more tries remain Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 08 42 8f 60 00 00 08 00 = Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:05 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 0 more tries remain Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 08 42 8f 60 00 00 08 00 = Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Error 5, Retri= es exhausted Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:06 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 3 more tries remain Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 2 more tries remain Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:07 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 1 more tries remain Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 0 more tries remain Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:08 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Error 5, Retri= es exhausted Apr 11 03:01:09 <23.4> mick ZFS[48383]: vdev I/O failure, zpool=3Dmick pa= th=3D/dev/da1 offset=3D4000786423808 size=3D8192 error=3D5 Apr 11 03:01:09 <23.4> mick ZFS[48387]: vdev I/O failure, zpool=3Dmick pa= th=3D/dev/da1 offset=3D4000786685952 size=3D8192 error=3D5 Apr 11 03:01:09 <23.4> mick ZFS[48391]: vdev I/O failure, zpool=3Dmick pa= th=3D/dev/da1 offset=3D270336 size=3D8192 error=3D5 Apr 11 03:01:09 <23.3> mick ZFS[48395]: vdev probe failure, zpool=3Dmick = path=3D/dev/da1 Apr 11 03:01:09 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:09 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:09 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 3 more tries remain Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 2 more tries remain Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:10 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 1 more tries remain Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Retrying comma= nd, 0 more tries remain Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): READ(10). CDB:= 28 00 00 00 02 10 00 00 10 00 = Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): CAM status: CC= B request completed with an error Apr 11 03:01:11 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Error 5, Retri= es exhausted Apr 11 03:01:11 <23.3> mick ZFS[48399]: vdev probe failure, zpool=3Dmick = path=3D/dev/da1 Apr 11 03:01:11 <23.5> mick ZFS[48403]: vdev state changed, pool_guid=3D7= 854867548980906247 vdev_guid=3D14874313982910104056 Apr 11 03:01:16 <0.2> mick kernel: (da1:umass-sim1:1:0:0): got CAM status= 0x44 Apr 11 03:01:16 <0.2> mick kernel: (da1:umass-sim1:1:0:0): fatal error, f= ailed to attach to device Apr 11 03:01:16 <0.2> mick kernel: da1 at umass-sim1 bus 1 scbus1 target = 0 lun 0 Apr 11 03:01:16 <0.2> mick kernel: da1: s/n 00= 00NL6AE1LV detached Apr 11 03:01:16 <0.2> mick kernel: (da1:umass-sim1:1:0:0): Periph destroy= ed Poul-Henning PS: "completed with an error" without any details about the error is not v= ery helpful for debugging... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Tue Apr 12 22:56:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 382431AF83E3 for ; Tue, 12 Apr 2022 22:56:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdLgT2Df4z3Qq7 for ; Tue, 12 Apr 2022 22:56:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 23CMuCk9078747; Tue, 12 Apr 2022 15:56:13 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 23CMuCrQ078746; Tue, 12 Apr 2022 15:56:12 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202204122256.23CMuCrQ078746@gndrsh.dnsmgr.net> Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 In-Reply-To: <202204122147.23CLlYjE014614@critter.freebsd.dk> To: Poul-Henning Kamp Date: Tue, 12 Apr 2022 15:56:12 -0700 (PDT) CC: mahesh mv , "freebsd-hackers@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4KdLgT2Df4z3Qq7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-0.93 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.911]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.08)[0.084]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; FREEMAIL_CC(0.00)[yahoo.com,FreeBSD.org]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > -------- > mahesh mv writes: > > > READ(10) errors. The READ(10) error recovers with in couple of retries most > > of the times but few cases we have observed that the read retries gets exhausted and [...] > ... [ large amount of good information removed ] ... > Poul-Henning > > PS: "completed with an error" without any details about the error is not very helpful for debugging... One of the very reasons that I keep my "disk drive debugging" work all on a 5.4p8 system is that when things transitioned to CAM most of the useful low level error messages disappeared as the CAM layer doesn't output them. IIRC we no longer get the LBA when a read defect is reported, or we get it, but it is in the cryptic form of a dumped CCB. It would be wonderful to get that "funtionality" back. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -- Rod Grimes rgrimes@freebsd.org From nobody Tue Apr 12 23:04:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CD15F1AF9FE3 for ; Tue, 12 Apr 2022 23:04:23 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdLrk43myz3jDd for ; Tue, 12 Apr 2022 23:04:22 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-d6e29fb3d7so296984fac.7 for ; Tue, 12 Apr 2022 16:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNv6Wb2AKsrwylq6a3hab7/OHxdcG2B+g3JYT8Ifs84=; b=UoThEGYbz5LSMqxsq/j+bVh7pnSwBSCeVstVbZQxmVFTsDMfEfpjUz1quUgHymGzlc W5QgrDGisvSrct04My6M8dzTl2Ev2AiD0mn0lh+OGM1tfz+zrcxlxLRtbc8mNzJJm4vf xnfZTAfFfyUlATGHYc8zFxAf9OMFapDpoYuphL82pUQyOVWl7YA7Qjhb4NGV1rhvBKBv 6fPUSHgPFQQ0yiRLrehLm/AcYadfNbZSqRpTgz5tSdcFmcpHp/qrca6Km/8htGoaN0se mH7OPxFc5xPt+CAtMIOLwT7Zj/QjOlrlz37XT2Vd2IL6Tkw3998q9LFp+2/yPRKTgGje 9s/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gNv6Wb2AKsrwylq6a3hab7/OHxdcG2B+g3JYT8Ifs84=; b=XKnRhSnc5xVy+xi1s7w2tvSHwSGyvdotKEzbSR1g+CuDyD+tNKWcT9gS24qfEUilrr 8lf9xy/8geGC97uaNnklKvFJRC6dWihXtr+TxLfLPRB7lXXfCZQyJMQBrKem7BRWS+hO MRTK8w2+qunpazgsJnSnACZafnPuHRbZrR5LI4DpGT8xR7LB1f09ylY+nC6vOuVzZgWJ z+0r9RJbv2yJWTRm8lL6Ewl4CtvlyaQiAQEAnNV+XJ2kcOCpzZmdSflFNY3jGxOyvZBx aueZTc+AcLjnmJq5qyAVcpsgxS/UzKb4hBPfn+LHsa6l5pFfi2Tb+4vnSHoZuVVD3KWM K5oQ== X-Gm-Message-State: AOAM5318nI/ESntz22IeaVSnMRQhLundv686AQWPwJJEoAm+THhYOrr2 lITRmRo5fbmDw+3c8xVHUYlbxCmQYGaARA== X-Google-Smtp-Source: ABdhPJx0HPgIYa5snuZlOR/N/0HnbIFFBUfrDYT/xipT2wMOGoPCLcI9lGKr72xO/nSN5noJck83OQ== X-Received: by 2002:a05:6870:c109:b0:d9:e74e:d09a with SMTP id f9-20020a056870c10900b000d9e74ed09amr3085020oad.142.1649804661848; Tue, 12 Apr 2022 16:04:21 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id f44-20020a056871072c00b000e2b638a925sm4005864oap.49.2022.04.12.16.04.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Apr 2022 16:04:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 From: Bakul Shah In-Reply-To: <1524993805.98701.1649776236883@mail.yahoo.com> Date: Tue, 12 Apr 2022 16:04:20 -0700 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <1EA26D91-EBA0-4043-BC29-06B7578AAE05@iitbombay.org> References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> To: mahesh mv X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KdLrk43myz3jDd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=UoThEGYb; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2001:4860:4864:20::2f as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-2.96 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.958]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[iitbombay.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Apr 12, 2022, at 8:10 AM, mahesh mv wrote: > > This issue was never observed with Linux kernel 5.4.2 on the same HW. On an external SSD I have, Linux was using UAS (USB Attached SCSI), while FreeBSD used the older BOT (Bulk Only Transport) protocol. See if your disk supports both. You can try usbconfig -d genN.M dump_all_desc # N = unit, M=device index to dump all the descriptors and see what all it supports. You should see something like this: # !! | grep Protocol bDeviceProtocol = 0x0000 bInterfaceProtocol = 0x0050 -- BOT bInterfaceProtocol = 0x0062 -- UAS Likely a remote possibility but could it be that it has a bug in the disk's BOT implementation? At any rate you can check if anyone else with the exact disk model has similar issues. Alternately, see if the problem disappears with a different disk. Another thing to check is whether the disk has any updated firmware. Note: I am not a USB expert so apologies in advance if this leads you astray! My main point being that the issue may not necessarily be a FreeBSD bug. Do share the USB traces. From nobody Wed Apr 13 05:14:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F22CF1B0BDDA for ; Wed, 13 Apr 2022 05:15:07 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) Received: from sonic302-1.consmr.mail.bf2.yahoo.com (sonic302-1.consmr.mail.bf2.yahoo.com [74.6.135.40]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdW4V5V2rz3hdn for ; Wed, 13 Apr 2022 05:15:06 +0000 (UTC) (envelope-from maheshm_v@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649826900; bh=KR48Lycv5Ps+6ssQTSXtwlN5JF1TrDkoFMrbUlhw3oI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=kQZeDmyGXvzr9SnAux5yvRlqYGFXlq7dj3z1Iz85BysTGfyebEVpVvGYMZCwAmRkYIJ7zJ/oLlFp6xhwIw8qFDIFVIvNQ0z0lkq8+56LbUEkRn+trwG0Cg2O8e7n6FTpGeRanHoVRagPY3tfUmiSN5nvfBDEPljG64TGEuGSp7lFu+JnbSBtbanea9afHH4rfAf7hXH7SjXMt0aIHDP+QewnuVZKaJ11b4dlhUwVdU3vG38N7Y+GotqPEzqIqicegVNdgRvMMxnNsZN3qp7aHzAOe6Cpu6qvXNfsVvnJxg+/Qg5F7cNLuc7uIA7U0gEv8PSgoVyI5xCgEPXVQOxBjg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649826900; bh=VlU0aQ7C6gsS/4Gl8m9kVIYBr1tLTPA8YnJAq4BkNIn=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YkjRprSB6XNb+SUzDbQt8Qt0klXHdi3MjtdmLsi7ERzgBl3uNtxHJ0zCZw8BUt5UwOs607V1VXR9DdO1WmHSfnSY1ZhBL/gVPO/GnRoawO9r4SnFRjafnigwZaJrUoyDUEl5T6Zo45uFCke2ppY64U5dwpWvUu27hJTiC9wJJvd7SZCbccwPltbnMT4hxMWQoUyxV8GFuNoFqXhNvF+B5XcApNmBu3xA35ycP4CJWpnssvn/2oZn8PQCKM3++KlFL//KRc49iFYrdBnSHFdC0ZwUYHkglrdoAZw6SOQzVBuBVEaXN9rOoFKSNv3Pvn1C62iAhHi5v4Vr1yC8KN/jxw== X-YMail-OSG: Z7J2WXUVM1nwi6ctlthX7zRSQAj71W.JlvQDU7dP2Hp3P8cUgDawfm3NF1FhKXH FShZ8CAf6T.AzFOBFgJwsLsfr1p.i1sD0SWTAQ8JGuWCjvtcg48C6q9JNcxRbYkERaO2xvljVqmM 6xWAHSyDH0JivMVtv3INwWHbCWYgBhVG0Uqm9utqOBpUbSvsHjJtpN_w7c2mvqG5.5bV4QgAxAJU Q0M2oojcq.UbhrqdtSZEAgEok.C6NlqAnrVTfWfBa47emhCX9lwgsjbXajNmNaLT.1TqIPJpIOTE wpBAGaOwNuwWcYXFrvBpfss2FbRxGB2IL2Ij55Vp.FJg8EZAA7Da4YQAZfwDe7nu8bUZwGQPSuTy WoNIkMF8t7kDJfGSmOKL5EXAylT4I2AuR6bJi5JomaUuxZWuddecNIGaFZdzUTHkpZ6BblBA4oRv 0ETm8Y97aODFilLiKh6yr2s3QEmanYmHEaoVykW53w2hbdKkb3S9xvbTqfy_rVR97zitZ.Phqr65 iJFT7Q_PQ7z15Ys3YanVolWt3MP337jUgCpRSzlgA2dBycJddrJFzoUSEudDvTS1.bWX.qxL.kdj z5du7avnGqycFqBLola6_Valh7VBMWjGFY9mPuB6eEUEwxl.Y1_tE_I7jJ2a9qiO9eOLCxSlcMcc mfSRMhc7LS5FR3zjMMHJso06nfetOiP5Z6htI2M8N7i.N_fnvV6JbRWbg_TN2t2_WrsZyS8osOOV dnF1kySi2xjIYk1h4FVkkGZn4vZxhe1q9.tN3i_muzmg0rO7OW5s8w4sdbqP4UqDFdF7B9GvCd7e GI82Jf.htfKSH38Dt1yitYbkkddhPaN_voQ6u.NHVk9SM02N2LLy5z6z0ctlgZv_9gkzhQ.4zF1y WzhdqTHcp_6OaU5TirVGiKowTOshHyuL5d1UoAx1FCiKRcNuEize6FlgptqOwtZfVpldnqf7_OXx srhIp2NCyDT9Mz122qTZldt6kAlmFAhqaRyzLP_9.2akSPuvdipSIIa1zu2K892W3jdalDOqP3pl 6dm4cAP4u6BtSZQ4uassGnkVlBbnHGUQM4yfRAP.86hCRBduu2F6bN1Ku13JFETlW47aWpjXmqxK dP.dt6AKicP3V4v957mPbKiiRwPNcfIBZt6mwHEgPl6lv8Uk5wrF0ycmuYXPhXsnCe6jFUtaZV7q AkGGHzpWiAs.Df2x.DLApaLWZFaWiNRdBSKIuYoaGmAuZ84l.vxMdIxU5n1icDFtZh79c2hOPTcI Up95zyTwVWnaLNnVw8qA0MthM2MIypyTGn.hqUdgz2tdQrfb6hg.o1vxR2HK0clJe1pIKmXDyv5b ooMIKFlVMQGk2cIgEyhrBZ4xROwFShbAayz1K1Z768g.6.IAtrAaamVBQnWxBz5NPwVOufQ_v6VK nrh6oMnZjiwgDp0cXBCkVG3cUPkZtoAa0kUHnSnsbvPX9tORXl7D5lxP.UKW6Y7cLTQKkMQyGngd .0vC7hIvHOsc31W0xLtZRii0GaLgVzVTlE_BQShqUw4CzcFvEDKsn8nDux30K0naRxO5wXQO09Ev L_PGHKrlmpMBmSNTLXeg5c0uM8QdfsyDH7zCT941Rp_95_VsTbIgvBfAXhg1bofYqHFuok.VnTM3 N_9CeO1ECem1IYbFXqU.MtFcYtxdYxPV87V.HnDFEM8DlrrYlfkLB1MJ9x4bnILTV4GpYs1O1diN EPijZJIUazUUsxC.oIMC2ridqOTetjrGEG904pOPsYSAzPN85WgejAIoiZP5FbwINb89nXEL2ie5 IkPgxOPlIlwOFd.MW74OrxHCaMlnXLf68V5e.UY9dFYSkize8VNHxGK7OE2Q8Uzoqnx1UEkZQbaZ yvZbe71cTTnEw4J3_6ZT5.7gy86jKEGLRtmk3GvyXxAogH5j8ZkZ8DHjCUkPCczMVjuGlEQBjo7D SxNRyffgKTgmaxRQXa78H_Ec4zC3CdNn1Ep6FTlomZWkuU5flAyUW394jW1fKxHhn3QO0zeuvz2O DhQMOlR4QWyYj.AQxp4dAgAGfnRmvb4PObNZ1jx72UTznHHUduPf6aRMsVeBEWamgsbYRKZYKaXW LmOJuW4eS_Nmponp4m1kMydt8rBEOsO5ppnmS3289E3xSWp_2w3mJ9hONoYauIiCTO_hEQfkRz6Y TBzWFOJsSRv1CL46oxrnJUH29dlRtmM_ifoNkDOiUW81RBBQsJp_czrNQ4QMl.z97jjOdZqLH5kg dEX4zV55RBQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 Apr 2022 05:15:00 +0000 Date: Wed, 13 Apr 2022 05:14:57 +0000 (UTC) From: mahesh mv To: Chris Cc: "freebsd-hackers@freebsd.org" Message-ID: <1601830847.251013.1649826897803@mail.yahoo.com> In-Reply-To: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_251012_182260728.1649826897801" X-Mailer: WebService/1.1.20001 YMailNorrin X-Rspamd-Queue-Id: 4KdW4V5V2rz3hdn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kQZeDmyG; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of maheshm_v@yahoo.com designates 74.6.135.40 as permitted sender) smtp.mailfrom=maheshm_v@yahoo.com X-Spamd-Result: default: False [-3.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.990]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:26101, ipnet:74.6.128.0/21, country:US]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.6.135.40:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[74.6.135.40:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_251012_182260728.1649826897801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thank you for the inputs. The drive is formatted as GPT with an ESP/UFS par= titions. Thanks,Mahesh On Wednesday, 13 April 2022, 02:57:45 GMT+5:30, Chris wrote: =20 =20 On 2022-04-12 08:10, mahesh mv wrote: > Hi all, >=20 > =C2=A0 >=20 > Need you help regarding an urgent issue where we are observing an issue w= ith > Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to EP and= =20 > the > system experiences the >=20 > READ(10) errors. The READ(10) error recovers with in couple of retries mo= st=20 > of the > times but few cases we have observed that the read retries gets exhausted= =20 > and > =C2=A0system moves >=20 > to unusable state (continuous g_vfs_done() errors) . We are using Junos b= ut=20 > the > xhci driver etc.. are all pristine stable 12 drivers no Juniper specific= =20 > changes. > =C2=A0This issue was never observed with Linux kernel 5.4.2 on the same H= W. > =C2=A0Errors Seen on console >=20 > =C2=A0 >=20 > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 >=20 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >=20 > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain >=20 > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00 >=20 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error >=20 > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain >=20 > FreeBSD/arm (Amnesiac) (ttyu0) >=20 > login: >=20 > I can share the USB traces taken at the USB device if required. > Thanks,Mahesh I just replaced a drive 2 days ago that exhibited the same behavior. I=20 haven't (yet) checked the replaced drive yet for cause. But what I chose to do was as=20 follows. Get a new (known dependable) drive. Add it to the system and dump the data = on=20 the failing disk to the new drive. At least you'll have a safe copy of it. You didn't say how the drive(s) are formatted/laid out. Are you using UFS/G= PT=20 or ZFS? How you proceed after making a safe copy will depend on how you manage your= =20 disks. UFS/GPT?: simply remove the failing the disk, and change the entry in=20 fdtab(5) to point to the new disk. ZFS. It should be enough to simply replace the failing disk with one at lea= st=20 the size of the failing one and resilver. HTH --Chris =20 ------=_Part_251012_182260728.1649826897801 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank = you for the inputs. The drive is formatted as GPT with an ESP/UFS partition= s.

Thanks,
Ma= hesh


=20
=20
On Wednesday, 13 April 2022, 02:57:45 GMT+5:30, Chris &= lt;bsd-lists@bsdforge.com> wrote:


On 2022-04-12 08:10, mahesh mv wrote:=
> Hi all,
>
&= gt;  
>
> Need you help reg= arding an urgent issue where we are observing an issue with
> Freebsd stable/12. The DATA0/DATA1 are out of sync with respect to = EP and
> the
> system experience= s the
>
> READ(10) errors. The R= EAD(10) error recovers with in couple of retries most
&g= t; of the
> times but few cases we have observed that = the read retries gets exhausted
> and
>  system moves
>
> t= o unusable state (continuous g_vfs_done() errors) . We are using Junos but =
> the
> xhci driver etc.. are al= l pristine stable 12 drivers no Juniper specific
> ch= anges.
>  This issue was never observed with Linu= x kernel 5.4.2 on the same HW.
>  Errors Seen on = console
>
>  
>
> (da0:umass-sim0:0:0:0): READ(10). CDB: 28= 00 00 28 cf 28 00 00 40 00
>
> = (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
>
> (da0:umass-sim0:0:0:0): Retryin= g command, 3 more tries remain
>
&g= t; (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 28 cf 28 00 00 40 00
>
> (da0:umass-sim0:0:0:0): CAM sta= tus: CCB request completed with an error
>
> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remai= n
>
> FreeBSD/arm (Amnesiac) (tt= yu0)
>
> login:
>
> I can share the USB traces taken at the USB = device if required.
> Thanks,Mahesh
= I just replaced a drive 2 days ago that exhibited the same behavior. I
haven't (yet)
checked the replaced drive y= et for cause. But what I chose to do was as
follows.
Get a new (known dependable) drive. Add it to the system and= dump the data on
the
failing disk to = the new drive. At least you'll have a safe copy of it.
Yo= u didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT=
or
ZFS?
How you pro= ceed after making a safe copy will depend on how you manage your
disks.
UFS/GPT?: simply remove the failing the = disk, and change the entry in
fdtab(5) to
point to the new disk.
ZFS. It should be enough to si= mply replace the failing disk with one at least

the

size of the failing one and resilver.

HTH

--Chris

=
------=_Part_251012_182260728.1649826897801-- From eugen@grosbein.net Wed Apr 13 05:56:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D42831AF5734 for ; Wed, 13 Apr 2022 05:57:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdX1m754sz3p3q for ; Wed, 13 Apr 2022 05:57:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23D5vPaY039846 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Apr 2022 05:57:25 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bsd-lists@bsdforge.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23D5uw8t066852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 13 Apr 2022 12:57:23 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: xhci USB transaction error and subsequent recovery mechanism on Freebsd stable/12 To: Chris , mahesh mv References: <1524993805.98701.1649776236883.ref@mail.yahoo.com> <1524993805.98701.1649776236883@mail.yahoo.com> <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: Date: Wed, 13 Apr 2022 12:56:48 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <5fefe57150f9efab867a775722b9d71b@bsdforge.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KdX1m754sz3p3q X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.12 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.39)[-0.393]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.26)[0.259]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.89)[-0.885]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[bsdforge.com,yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 13.04.2022 4:26, Chris wrote: > I just replaced a drive 2 days ago that exhibited the same behavior. I haven't (yet) > checked the replaced drive yet for cause. But what I chose to do was as follows. > Get a new (known dependable) drive. Add it to the system and dump the data on the > failing disk to the new drive. At least you'll have a safe copy of it. > You didn't say how the drive(s) are formatted/laid out. Are you using UFS/GPT or > ZFS? > How you proceed after making a safe copy will depend on how you manage your disks. > UFS/GPT?: simply remove the failing the disk, and change the entry in fdtab(5) to > point to the new disk. > ZFS. It should be enough to simply replace the failing disk with one at least the > size of the failing one and resilver. Similar to ZFS case, it is possible to make the kernel to "resilver" non-ZFS disk by temporary creating non-persistent block-level mirror with "gmirror create" command. It will not create any "labels" on-disk but perform copying of contents similar to "dd" command but in more efficient way: no data transfer from kernel land to user land and back, also it uses MAXPHYS blocks to read/write media efficiently. Also, it would copy partition tables (and bootloaders, if any) of all kinds. From nobody Wed Apr 13 08:30:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C932B1AF50D1 for ; Wed, 13 Apr 2022 08:30:59 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KdbQV6Fjvz4h7h for ; Wed, 13 Apr 2022 08:30:58 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: by mail-ej1-f50.google.com with SMTP id k23so2436482ejd.3 for ; Wed, 13 Apr 2022 01:30:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=q+xcu24s8vM0BMAZg0ZhbV4Nc46tHPYkuZOF1D25jes=; b=jS0/pJkGPCncAu8qWnbknI9mmUnDTodrr398uJnSJG9WQC4XrPwFPoU6W3PVNACI66 nf4FMRQSj4jFHiEY1kMTZZe6QM4F4VMVs54JGmqB4FW5niM2UlZ162qK6PPy52uUvX73 HF6uSw+MvkkJpp4zpdvwblNbbq4EH2KSk7B2SJ3jNPxTcVpJhsKdj39/eoPcWl7WuhMk TZFOjO8+BoxGbV5ek34VW3gHMPXw4m0dnCjYU79X4131bhBJqNdElzEGjm3Oha/xBZKi PuBAM4Ju+cECBpxzNNdmi/Klb5ZGwV8+EWtblKQm7qIBMed0UPgZnK4mHQVkciDXVEKj rGdA== X-Gm-Message-State: AOAM532ypY76WWHfhVCteca4YpAE0iup4zQAw5hUedVxpuvA0vIdQKVf p9MdJWEt07dHkJx2WMhCMK6c8kiKhsKxoUQA X-Google-Smtp-Source: ABdhPJxB4fFBonYzU4li4fhqNOIwaljDHYoOI77U9lxH1Y/TrOBaod5m1QYX2ARZ7I/8jseZCmjdVg== X-Received: by 2002:a17:907:ea2:b0:6e8:c968:d302 with SMTP id ho34-20020a1709070ea200b006e8c968d302mr1549277ejc.666.1649838651824; Wed, 13 Apr 2022 01:30:51 -0700 (PDT) Received: from vps.markoturk.info ([109.60.124.9]) by smtp.gmail.com with ESMTPSA id m20-20020a056402431400b00419315cc3e2sm890959edc.61.2022.04.13.01.30.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 01:30:51 -0700 (PDT) Date: Wed, 13 Apr 2022 10:30:49 +0200 From: Marko Turk To: freebsd-hackers@freebsd.org Subject: Re: Inactive vs ZFS ARC memory priority Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oFSxqpjnzRx11do" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KdbQV6Fjvz4h7h X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.85.218.50 is neither permitted nor denied by domain of markoml@markoturk.info) smtp.mailfrom=markoml@markoturk.info X-Spamd-Result: default: False [-3.65 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.40)[-0.404]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.218.50:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.05)[-0.049]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[markoturk.info]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.50:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[109.60.124.9:received] X-ThisMailContainsUnwantedMimeParts: N --2oFSxqpjnzRx11do Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2022 at 02:06:55PM +0100, Marko Turk wrote: >=20 > Why is old data in Inactive higher priority than new data in ARC? >=20 I did some more tests, and I can't get ARC to push Inactive out. The only workaround I found is to start a program that allocates a lot of memory, then Inactive is pushed out and ARC is allowed to grow. Is there any other workaround that I can do? Regards, Marko --2oFSxqpjnzRx11do Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhGJv+o0FoHlUFxVJ0ArzBirlGugFAmJWijgACgkQ0ArzBirl GujDMw//VOMtqnfFR4Ygz+jxWSAXQDRnRx1wcAyvjSNFDiAY9uCaujtSVrV2wWcy JbGk+HZoPujhzqrh1M/datY2/I03xyeYzfDwyxcqzg3dG+9u80ZIcVP5gjSNHsI2 Q/qHQkz/PMPYi++bS+jkCE5YUNnl5Jni0biVW/I7EfO1AFr4pIS5RZLWPD+CCri/ ko1wjEJrUMIYvDj1dQNIzON8jupEwXxVEe7Khrb27G2J273Ux3wxxTaYtums9dr6 v9C61MGH8rtsVDl6YSsQoai1sh4NCBl1hffsWJ12pKzqX65yakBbkOl79+maz7kQ tjWtchDRS7vj8pUV9vtrYOvKfebKPHOf+721vzEsmCif6owh0eOrOtOKLcWLnIz8 5iNBocY4CGVxFiFbrGud7JaWd1Dr+tAw7K84haezfHsTcIWOuEK98yTnhm2+sz+K dFpUkJXADGpGVczPmIwvcyEqZVjnK8wDoPoAqvMpeD4oLHktN9k3hcEcmCw45jns h/hIggTdxgLIOm8KFhr6vR6IFqyo2oUGLbp4MHatz/SW6IKo7MI2KVwMdaEpHIJg J/Rk1nPaoDzNG6rn/4VaetfMkCOxBRmaQr8yxYMoW0qmB8KREWzChlMG+tlsA0vq 9jtGXY17NmDkJrGWppXsvv+/xNgFBNaa7OgRvp/uKUZ1a/eH9Jg= =dovg -----END PGP SIGNATURE----- --2oFSxqpjnzRx11do-- From nobody Thu Apr 14 07:44:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4170A1B42616 for ; Thu, 14 Apr 2022 07:44:57 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KfBLw6ZcVz4sFt; Thu, 14 Apr 2022 07:44:56 +0000 (UTC) (envelope-from markm@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649922297; h=from:from:reply-to:subject:subject:date:date: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=JsTTPnldpT9A13aRc5qO2c9EtN77guX/RLqLk3n509s=; b=syM3c3z3x03ZplHm2OCRfH9/lSzIx21PmUduP62dzcNV4jXUrzsh/2088kS30absBO0OoP WK43D0TG+wr1sSBv6EX6XHyjDerqyvZ9Kw47CjROwqPuHTSywoF21BhX2x/kVtVRp1wnBh eq3aRw08rfOiJuqmD4FXcWhgraythNWH71eBdMyi0SOcLJXj1COs+DsiAzhhVczgKk04Kt OAvOeYGuUY6anoXUyqE/SlJ/BEhLp/72mBV8AOW2L+FizQ0GT7p5vUvyNeDFN4GSk8rpyK 0Ecs4/80EqatILsUQqLN9ujdIWjQHAP4BmT5mibbYk5mjpa8G9OP0DxKAQIZNw== Received: from smtpclient.apple (unknown [IPv6:2a02:8011:300b:42:6d45:9ab7:84fc:23c3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: markm) by smtp.freebsd.org (Postfix) with ESMTPSA id B03B45E03; Thu, 14 Apr 2022 07:44:55 +0000 (UTC) (envelope-from markm@FreeBSD.org) Content-Type: multipart/signed; boundary="Apple-Mail=_6359A126-D024-4165-9FA6-475F44C3999E"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [RFC] patch's default backup behavior From: Mark Murray In-Reply-To: <6c8a812f-438c-dfac-7ba8-b9ae6abf0840@FreeBSD.org> Date: Thu, 14 Apr 2022 08:44:52 +0100 Cc: freebsd-hackers@freebsd.org Message-Id: <973282F3-3AAD-469C-BF44-169C7C9F751A@FreeBSD.org> References: <202204111658.23BGwmcC073621@gndrsh.dnsmgr.net> <6c8a812f-438c-dfac-7ba8-b9ae6abf0840@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.3696.80.82.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1649922297; h=from:from:reply-to:subject:subject:date:date: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=JsTTPnldpT9A13aRc5qO2c9EtN77guX/RLqLk3n509s=; b=DeuIuEXXZnOb58M36PNbCNlLnqlXpGVglxazMmw1WDCSQUNBRn9QuzZ9DaMvtiSynHYhSv Km41MRbmtGElH9cbLCuze9PLfGtrGhCxmNtw9oPTM4SUUhOJsVdpn6hQW3JtYb9knrGpre 6ekHxKQzH4vBtq0NDto0cSWbs5RIMrqZsN5OF04MZ552/1UaQKcEU5TwTfxePdGb3IbFjs nNlkOo8Vy+xUku3Rcn0seWP23FpUXKDAXbgTTiarx7ecqemQcT6irpYEry+xMTgn4ggY+j WNl6CiCFMnSMEXUAMyYYJg4BdYirLqwvKzLgUdrBBuX1bpzFsTeE+XCxDw/uKQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1649922297; a=rsa-sha256; cv=none; b=SpGmuzlbaWQSnKT32UGrSJfa/j4zVMMK2O+yckqs+KYwy1Cs5fOZGwpbeee5rcx68PUPrE KHFhyykKLImdqjNBPXy6HVo/2foSfLUnv6EzVYpA8dImMMl6vjlTaQOLnx4Dt2oUTna06D CeecdHmxkf/3P6GS0mSC+xu7guMZ66xKQuibnqgXjy9+RTzmiX/xAQ2dlFjr7YQNMcRL1B OcIOP4slLDnCNxPE8TmQepkEniL3LwYjEgQjBpA3mA4cl9OXabAJnFY+CXuV+b0Otjeyen 7AE/rIp9A1KvieoGhH+7Xlnjd72BfDBCn5MI1AEBWCoIi+RJtO7TiECMtFgPjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_6359A126-D024-4165-9FA6-475F44C3999E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you David. Well said! M > On 12 Apr 2022, at 17:36, David Chisnall wrote: >=20 > On 11/04/2022 17:58, Rodney W. Grimes wrote: >> Personally, if YOU like the behavior of gnu patch, by all means, >> please USE gnu patch. Please do NOT make bsd patch behave in >> a different manner simply because you personally like that >> other behavior. >> If you want the stuff to look like Linux/GNU by all means, >> go RUN linux/gnu!!!! >=20 > There are two opinions that as almost invariably wrong, in any = context: >=20 > - Popular thing X does Y, therefore Y is good. > - Popular thing X does Y, therefore Y is bad. >=20 > This thread started with 'popular thing X does Y, we do Z, let's = evaluate which is better'. Reducing that to 'popular thing X does Y, = therefore we should do Z, if you want Y then you should run X' is = unhelpful. It is also how we end up in a situation where everyone runs = X and we sit around wondering where all of our users and contributors = went. >=20 > We should neither adopt or discard a particular behaviour in patch on = the basis that GNU patch does it. We should use the fact that GNU patch = does it to gather data on whether it's a desirable behaviour. We should = adopt their good ideas and avoid their bad ideas. >=20 > That is precisely the process that Kyle is trying to drive and the = FreeBSD system will be better as a result of his work. Personally, I = hate having .rej and .orig files scattered over my filesystem as a = result of patch failing and I end up having to write a `find` command to = delete them all. Does that mean that I want to give up kqueue, = capsicum, out-of-the-box ZFS, a sane /dev/dsp, jails, clang as the = system compiler, a `tar` that knows that `x` means 'extract the thing, = you don't need me to duplicate the information in the file header to = know what it is', and so on and run GNU/Linux? No. >=20 > I take Joerg's point that GNU patch *sometimes* creating them makes = tooling difficult. I would be quite happy with a solution that they are = created unconditionally with a flag to disable creating them (I would = then `alias patch=3D"patch --do-not-leave-stuff-on-my-filesystem"` in my = `.profile` and forget about it for interactive use) or that they are = never created with a flag to enable creating them, which I would never = pass except when working with bits of infrastructure that explicitly = want the .orig files. >=20 > David >=20 -- Mark R V Murray --Apple-Mail=_6359A126-D024-4165-9FA6-475F44C3999E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 Comment: GPGTools - http://gpgtools.org iQEzBAEBCgAdFiEEyzPHvybPbOpU9MCxQlsJDh9CUqAFAmJX0PQACgkQQlsJDh9C UqBorgf+Kd7eR3zNIxyTmtmI1tYjUp6z9uTtVWBLfzjhHIXm+VvEqD8/oevkPHyS s49QX5z68z09i2H04KLb10we4EAKXWOfY5o4e8wkWTxc/FUiASEbqoU+RPMeWTaL tsSaKIDD6zGIoH2/VYTGC+aMK5eHgNNf1Uw2JJPyYIr6aKIOiIJkLEWHTO6Gy4mr HbHmdFxHnMLo3++co/PpagBpohkKbznL9XOz/70NaB9Qf7swkw9Zhg70pvgGibfI JmowuczJ7BcDUXTRxgTgC5YGEKNPK6nFrjcl5I9kCmUy+8HJUVckRQxlk2teaOpO xteAQ0LytxyH5XbkXLxZNu+auUysGg== =jzlY -----END PGP SIGNATURE----- --Apple-Mail=_6359A126-D024-4165-9FA6-475F44C3999E-- From nobody Thu Apr 14 16:36:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A3B9D1B32910 for ; Thu, 14 Apr 2022 16:36:40 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4018.proton.ch (mail-4018.proton.ch [185.70.40.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KfQ8Q3Lp7z3jgB for ; Thu, 14 Apr 2022 16:36:38 +0000 (UTC) (envelope-from jbo@insane.engineer) Date: Thu, 14 Apr 2022 16:36:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail2; t=1649954190; bh=wYdDXoOOMtZtAJLU7hA1xF2P2ZdB4vANX/SbtfmWA0o=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject: Reply-To:Feedback-ID:Message-ID; b=q1VpSu1dzyd8/B7bdFS8DCwwQIRXLiFE1Mey6dWGIwBYy1Qhuh7LZg7+HJs5qkOs1 7OCD2nXDy6u3nzbbc43hgH45x8mYUbZARjgg1zsZ6668qf/Yf0zX1RXEk3QN9ptqbJ mWO1NLg1GfPYi0u8iIdvK2KaMZ52U54JKN1a7jRvVePtmk+xDXIkpqOdoZ9R2UP3vH iwzbkHB1ekZAF/yvDiXBn2f3zOmGJ7EUItv4YnzOg+jj2HvNUmyMphSxCpslLWVTe4 otsPHljEJFqhXbBaS6YJLyQeAjSQ8r2cj+KcHyhMzVRO9zIbCrXFDPLgKgskTp59Fw eoTbBg1PtfCFw== To: "freebsd-hackers@freebsd.org" From: jbo@insane.engineer Reply-To: jbo@insane.engineer Subject: llvm & RTTI over shared libraries Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KfQ8Q3Lp7z3jgB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail2 header.b=q1VpSu1d; dmarc=pass (policy=none) header.from=insane.engineer; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.40.18 as permitted sender) smtp.mailfrom=jbo@insane.engineer X-Spamd-Result: default: False [-3.17 / 15.00]; HAS_REPLYTO(0.00)[jbo@insane.engineer]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[insane.engineer:+]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.466]; MIME_HTML_ONLY(0.20)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:~]; TO_DN_EQ_ADDR_ALL(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.18:from] X-ThisMailContainsUnwantedMimeParts: N Hello folks! I'm in the middle of moving to FreeBSD as my primary development platform (= desktop wise). As such, I am currently building various software tools I've written over t= he years on FreeBSD for the first time. Most of those were developed on eit= her Linux+GCC or on Windows+Mingw (MinGW -> GCC). Today I found myself debugging a piece of software which runs fine on FreeB= SD when compiled with gcc11 but not so much when compiling with clang14. I managed to track down the problem but I lack the deeper understanding to = resolve this properly - so here we are. The software in question is written in C++20 and consisting of: - An interface library (just a bunch of header files). - A main executable. - A bunch of plugins which the executable loads via dlopen(). The interface headers provide several types. Lets call them A, B, C and D. = where B, C and D inherit from A. The plugins use std::dynamic_pointer_cast() to cast an std::shared_ptr (= received via the plugin interface) to the derived classes such as std::shar= ed_ptr. This is where the trouble begins. If everything (the main executable and the plugins) are compiled using gcc1= 1, everything works "as I expect it". However, when compiling everything with clang14, the main executable is abl= e to load the plugins successfully but those std::dynamic_pointer_cast() ca= lls within the plugins always return nullptr. After some research I seem to understand that the way that RTTI is handled = over shared library boundaries is different between GCC and LLVM. This is where my understanding starts to get less solid. I read the manual page of dlopen(3). It would seem like the flag RTLD_GLOBA= L would be potentially interesting to me: "Symbols from this shared object = [...] of needed objects will be available for re-solving undefined referenc= es from all other shared objects." The software (which "works as intended" when compiled with GCC) was so far = only calling dlopen(..., RTLD_LAZY). I'm not even sure whether this applies to my situation. My gut feeling tell= s me that I'm heading down the wrong direction here. After all, the main ex= ecutable is able to load the plugins and to call the plugin's function whic= h receives an std::shared_ptr as parameter just fine, also when compiled= with LLVM. Is the problem I'm experiencing related to the way that the plugin (shared = library) is loaded or the way that the symbols are being exported? In the current state, the plugins do not explicitly export any symbols. Here's a heavily simplified version of my scenario: =3D=3D=3D interface.hpp =3D=3D=3D struct A {}; struct B : A {}; struct C : A {}; struct D : A {}; struct plugin { virtual void do_stuff(std::shared_ptr in); }; =3D=3D=3D plugin1 =3D=3D=3D struct plugin1 : plugin { void do_stuff(std::shared_ptr a) override { auto b =3D std::dynamic_pointer_cast(a); if (!b) return; // GCC -> success // LLVM -> b always nullptr } }; Could you guys help me out here? Best regards, ~ Joel From nobody Fri Apr 15 06:25:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 622F41B4FC37 for ; Fri, 15 Apr 2022 06:25:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KfmXc2XDJz3Pv2 for ; Fri, 15 Apr 2022 06:25:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650003913; bh=wyLEZMtOZHkxx34c7nz7QW0kbF3L5XhROZ98aLmOCkQ=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=JE7YCaRP7naFcN11NTuyx3Se1klqpunM5O/JlLPT9eMkTpxn1+5FaMgg9sNFE79/V5uQKEKzW4Eh6cdCwn3WTLVfVeptJ7mfIr1DwBhk1u37EfKvnHGLVtMGL7WvNNYN/sZ54lJNZm/6zVvfEI+nHI2F0XIOndoffy8qoplPkmCOVEqc3tzNs3CQ9fomC6hzgCUQvRE1zREqzW/3AKLJsDEVjE0jxX2pxa6WoL6mwx7+xB3shTLg3kFMq50WAEH6P/9EfD1bszHlUUaeheuF+qzt4lCnnQlqATqln8LXoeVGYxTzE0KWOi2rUll3xaHJ41kE58X0hgN5GubuGtbnIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650003913; bh=x/ZuAQ5rPOXslocncVVP+YHkJAhBCn56pgfX3gyI/JP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=b8Iq0zPmNw+MtVnvnuMObTyt6p1h1giiGMyyN0eUi6Mv2tieEV0UYKPEo1f1oc4N9ofRqUW1DG6yrb8TrSFc1+ltwGAxgYJim5vZk9ysf/hz1AJl3v9Wrvc9i2dVIF8niw0MRyJNFaDCOI0qu6VQP0PbSgW0LLFgrZH8vJ0maiLhn+NP+MGvZwISlhLwNnRobY603PKy8dz/SUANcD8DQ5Lfap05O4Ye29rKg77RzXZ6CTZM0kxjv/v/lTc+1eNJ2NVKyEC9PGlbSl6xXbK4WBTNm6w1kflOu4Dopp03GpL+5JOOC6g83UPh5/TG/bkvhu6zUQ/V3VJell+g5wHsCw== X-YMail-OSG: 9TdufQoVM1lOsQ2R6HQZAtQqtgSx32PD7HKrREr9RnETl6Gl_20vWTjrhNWbMCM 4Yb2PlPUjYhC75m88oH4jLrdcbAAK5J_dbGRwZ1RbJwYcwbWu0EAcsALyZ7zyyOMhixDUscwCaqH hxo6i.ULgkTt8pRZwWuevvL6CcgluchHkzKD8LPTROLt2.cJQWskz3G7KX8pK2pYIGSGh.RtXYgK qul457DzPV8saGnYeoshWM7kBO0m8J2DkLBow.8STDRHpwxcD7mRu5I8z0FAspq4gYbTzwjhx32U g40h3c5g5QzhHinqsmERFF2pY1nwDQVHNEEqzb0mfYvya80bvOFIVdG.jFzuHyd.g39aP.yYoBaI 3p4n02vx7Xgs91z_bG0ruKw0BXNZNZGsIFwUM_xCwxGVPsWe4x3DLR39GJXnn4Sg5fzgSyJB8jCT zWl0p8PxrXPEnZNyiA2IDDLob7aKCSf1_AGMm3c4LDJ8e9QgFXVlsUr0uQbdvTtN9yp6JmswhNw8 kD43tZtIZjwCDpLIxDy8x2Rb1KkAH7SMQ2SP0Zqfcww5NBQKafSjXFnr93w4KMkC5TtOw0UKtywZ XppSnPQO07veHmt8H_ckfcl44J7C9J1q3LR_jA90wKfNcoLemxkVUCQGqDDKgnRc_Lr3skp4traS k2EPYzTvMGWsvYZ95R3D2B8rcRG9q8DMyry4O5D2lVggCTtKV.N2FK1MaFRRq1gr4eFy4mhxarLP J7aMU4fGi8TzRfBy0lBGWV7mUOO1mkgP_Z0HiSjU_uFfIjnXOA5rf.MOY1FCL0nJuIXAI4Sv.Klk OK_6qsPHQmsnDfakcqqKqSDWLpFToAZvxT._6jbz3cWqw.gG2VxDSPinlvoVu.ceXV4.iY6UzaTH Hihn2c8zBiRYEz21zNDzei17AksqfPtooZA9qunQRdWOxXZFC.ids9t71MI0otVD0gXxFnju.R2S kkGJBo9vJekmkVKQH9KoawoxiLCfmLlzlYKzJ8SeCODrmf062Z0wm6EyVKmXa8wfGnodj.XZ41QB iJ34xr84vyXyAILMGXLcFEp1_rVXNoRM6CIE.rmXtsuKvT9WwoS9YZu4RX0.01U00J8CKYg1Sk1I dqsQ4LPZpw__WiE78dPaF_xmJAFdK.n2ibN9aJ.4tMNmlskdSEjnWzmfeWb0LUslW17DW.mVBg50 CGuzkFQz1ZnZJrjVyixoJXNZf0om5b9hKKnj9sdAQN49G3.RQ.v6fUrsL59Ycu0Q10Dpl7BFCkv. 5cYlWnxFyOeUS3_1KbmSHO3GSTMxmENC5YqAQDi4DfUXpur.tVlRlVQ35oqCBOQc3fMd.X_OiCMC cDmiEglDoD67oFyF61BM5fek.aw42OXQ97z0cMmnPAlaWPk7qvI15ZKcru4TtABs6oWZUGqfAsi. orTy1D4qT0PrFLOWEPJmbc_QHGa3M8XNU8hU1t_XPoKjbJL4AHnnzskzAlEzjG_rNtss.jUI22v_ GOUiUYvHw3cVP5xhk9sDMfhRRBumNV6Vp8PDF66UBLxjBLTYr9eleg6Eos2skAtUjbDyL9lEdm4O 7y9KbAn2S2vsxkJ1gK9USD.5yfXVKLu1Ykt0b4rDfaHdXvbnLPBCuxHcbf7vFRNj1rQ6tgPwMY1W 2g2dEXxUz0F5K211iT0WRceG_QnMzwlzwMs0BsTOjlChaZcKRFE6.nVGEt0PpmBHzaB0._lO_XI8 wZhQbn4pC01KDFAIHR5jHXcE4TRTegJdLwoSCo6SQpw7TGBqokPJ5zsYLiXa8LFPQjQVtVs5NmZ2 3choYbYPgipVCmtsN1Pb6n7fcL2yTXznlRHOQazssVuIMVkF1b1Pdj.Fr5Q5PCNd3PVG6Req4W1. WSq.mDo7msdo9oRxhOw0nqc7k3X0Z.twAJ.Y1nKLHqE5oLXdsD1e8vz3HZEDVFZxCSSa5nTC4vE3 ubIRx7ZWdivbgWqLmbAd8vrpdLqpjWUbl8HnspQPlUWRxEfbLjbwmoHD2h2SauICdSTegMz0VmRU x1L_._xi3JNISratPMUgRrc_sBiVQijsDNme4rb6bZKHYbidPRJTTnFpzBQJEDqcBfwnAhgt8LAa VDPqS4nLEGGgf3w7Hi911X3Lmn2Ft9dg0K9nEdvQWUhFLluoGmqzce9ShUULobJWCi5NiImHW1Ma T7TROpHmrAriAii8aJUn.EvjI6v1K6a9W9GnE3lg0bOwHlHIoPu10Eem8ebS4hVrOvLNJbKERBUt LAb4sdZ1rYfvRVIArTVPpcNR2AlfCu3RDhd94wBSKzli6nvWL64PvMTQp5zlOyj8YIQQx8LxwX46 zpu7uhVepEwWgqg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Apr 2022 06:25:13 +0000 Received: by hermes--canary-production-bf1-5f49dbcd6-plxjl (VZM Hermes SMTP Server) with ESMTPA ID 23988e620aa73933d54e1da5c9efc094; Fri, 15 Apr 2022 06:25:10 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Message-Id: <9ADA04B1-2A0F-4B96-8510-88A5E4E1E2C0@yahoo.com> Date: Thu, 14 Apr 2022 23:25:07 -0700 To: jbo@insane.engineer, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <9ADA04B1-2A0F-4B96-8510-88A5E4E1E2C0.ref@yahoo.com> X-Rspamd-Queue-Id: 4KfmXc2XDJz3Pv2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=JE7YCaRP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.45 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.988]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.958]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: wrote on Date: Thu, 14 Apr 2022 16:36:24 +0000 : (I've line-split the text.) > I'm in the middle of moving to FreeBSD as my primary development = platform (desktop wise). > As such, I am currently building various software tools I've written = over the years on > FreeBSD for the first time. Most of those were developed on either = Linux+GCC or on > Windows+Mingw (MinGW -> GCC). >=20 > Today I found myself debugging a piece of software which runs fine on = FreeBSD when > compiled with gcc11 but not so much when compiling with clang14. > I managed to track down the problem but I lack the deeper = understanding to resolve > this properly - so here we are. >=20 > The software in question is written in C++20 and consisting of: > - An interface library (just a bunch of header files). > - A main executable. > - A bunch of plugins which the executable loads via dlopen(). >=20 > The interface headers provide several types. Lets call them A, B, C = and D. where B, > C and D inherit from A. > The plugins use std::dynamic_pointer_cast() to cast an = std::shared_ptr (received > via the plugin interface) to the derived classes such as = std::shared_ptr. > This is where the trouble begins. >=20 > If everything (the main executable and the plugins) are compiled using = gcc11, everything > works "as I expect it". > However, when compiling everything with clang14, the main executable = is able to load the > plugins successfully but those std::dynamic_pointer_cast() calls = within the plugins > always return nullptr. >=20 > After some research I seem to understand that the way that RTTI is = handled over shared > library boundaries is different between GCC and LLVM. > This is where my understanding starts to get less solid. >=20 > I read the manual page of dlopen(3). It would seem like the flag = RTLD_GLOBAL would be > potentially interesting to me: "Symbols from this shared object [...] = of needed objects > will be available for re-solving undefined references from all other = shared objects." > The software (which "works as intended" when compiled with GCC) was so = far only calling > dlopen(..., RTLD_LAZY). > I'm not even sure whether this applies to my situation. My gut feeling = tells me that I'm > heading down the wrong direction here. After all, the main executable = is able to load > the plugins and to call the plugin's function which receives an = std::shared_ptr > asparameter just fine, also when compiled with LLVM. > Is the problem I'm experiencing related to the way that the plugin = (shared library) is > loaded or the way that the symbols are being exported? > In the current state, the plugins do not explicitly export any = symbols. >=20 > Here's a heavily simplified version of my scenario: The simplified example was not designed to compile and test. So I made guesses and made my own. The .cpp files have comments on the compile/link commands used and there are examples of c++ and g++11 compile/link/run sequences after the source code. The code is not well commented. Nor does it deal with error handling or the like. But it is fairly short overall. # more base_plugin.h #include // For its own libbase_plugin.so file, load time bound, no dlopen used = for it: struct base { virtual ~base(); }; struct base_plugin { virtual std::shared_ptr create_data_instance() = =3D 0; virtual void action(std::shared_ptr data) = =3D 0; virtual ~base_plugin(); }; extern "C" // for each derived plugin .so file: { using plugin_instance_creator=3D base_plugin* (*)(); const char plugin_instance_creator_name[] =3D = "create_plugin_instance"; // Lookup via dlsym. using plugin_instance_destroyer=3D void (*)(base_plugin*); const char plugin_instance_destroyer_name[] =3D = "destroy_plugin_instance"; // Lookup via dlsym. }; # more base_plugin.cpp // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibbase_plugin.so -shared = base_plugin.cpp // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibbase_plugin.so -shared = base_plugin.cpp #include "base_plugin.h" base::~base() {} base_plugin::~base_plugin() {} # more main_using_plugin.cpp=20 // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ // -omain_using_plugin = main_using_plugin.cpp // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ // -Wl,-rpath=3D/usr/local/lib/gcc11 -omain_using_plugin = main_using_plugin.cpp #include "base_plugin.h" #include int main() { auto dl=3D dlopen("./libsharedlib_plugin.so",RTLD_LAZY); // = hardcoded .so path for the example union { void* as_voidptr; plugin_instance_creator = as_plugin_instance_creator; } creator_plugin_func; creator_plugin_func.as_voidptr=3D = dlsym(dl,plugin_instance_creator_name); union { void* as_voidptr; plugin_instance_destroyer = as_plugin_instance_destroyer; } destroyer_plugin_func; destroyer_plugin_func.as_voidptr=3D = dlsym(dl,plugin_instance_destroyer_name); auto plugin=3D = (creator_plugin_func.as_plugin_instance_creator)(); { // Local scope for data std::shared_ptr = data{plugin->create_data_instance()}; plugin->action(data); } // Presume for the example that nothing requires the plugin = after here. (destroyer_plugin_func.as_plugin_instance_destroyer)(plugin); destroyer_plugin_func.as_voidptr=3D nullptr; dlclose(dl); } NOTE: So, other than the dlopen, the above has no direct tie to the specific dynamically loaded plugin. The base_plugin is in a .so but is load-time bound instead of using dlopen. That .so would be used by all the plugins found via dllopen. (I only made one example.) As for the .so used via dlopen/dlsym/dlclose . . . # more sharedlib_plugin.h #include "base_plugin.h" // For its own libsharedlib_plugin.so file, where dlopen is used to find = it: struct sharedlib : base { int v; }; struct sharedlib_plugin : base_plugin { std::shared_ptr create_data_instance() = override; void action(std::shared_ptr base) = override; }; # more sharedlib_plugin.cpp // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp #include "sharedlib_plugin.h" #include std::shared_ptr sharedlib_plugin::create_data_instance() { std::cout << "create_data_instance in use from dlopen'd .so\n"; return = std::static_pointer_cast(std::make_shared()); } void sharedlib_plugin::action(std::shared_ptr b) { std::cout << "action in use from dlopen'd .so class\n"; auto separate_share =3D std::dynamic_pointer_cast(b); if (separate_share->v || 1 < separate_share.use_count()) std::cout << "separate_share is not nullptr (would crash = otherwise)\n"; } extern "C" base_plugin* create_plugin_instance() { std::cout << "create_plugin_instance in use from dlopen'd = .so\n"; return new sharedlib_plugin(); } extern "C" void destroy_plugin_instance(const base_plugin* plugin) { std::cout << "destroy_plugin_instance in use from dlopen'd = .so\n"; delete plugin; } # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibbase_plugin.so -shared = base_plugin.cpp # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -L. -lbase_plugin -Wl,-rpath=3D. \ -omain_using_plugin main_using_plugin.cpp # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibsharedlib_plugin.so -shared = sharedlib_plugin.cpp # ./main_using_plugin create_plugin_instance in use from dlopen'd .so create_data_instance in use from dlopen'd .so action in use from dlopen'd .so class separate_share is not nullptr (would crash otherwise) destroy_plugin_instance in use from dlopen'd .so For reference: # ldd main_using_plugin main_using_plugin: libc++.so.1 =3D> /lib/libc++.so.1 (0x819d0000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x82735000) libbase_plugin.so =3D> ./libbase_plugin.so (0x8328d000) libm.so.5 =3D> /lib/libm.so.5 (0x83c47000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x85861000) libc.so.7 =3D> /lib/libc.so.7 (0x848f9000) # ldd ./libsharedlib_plugin.so ./libsharedlib_plugin.so: libc++.so.1 =3D> /lib/libc++.so.1 (0x3b69aeeb6000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x3b69af6f2000) libm.so.5 =3D> /lib/libm.so.5 (0x3b69afd1f000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x3b69b0303000) libc.so.7 =3D> /lib/libc.so.7 (0x3b69aafdb000) As for g++11 use . . . Testing with g++11 does involve additional/adjusted command line options: -Wl,-rpath=3D/usr/local/lib/gcc11/ ( for main_using_plugin.cpp ) -lstdc++ (for all 3 .cpp files) (FreeBSD's libgcc_s.so.1 does not cover everything needed for all architectures for g++11's code generation. I was working in a context where using /usr/local/lib/gcc11//libgcc_s.so.1 was important.) # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibbase_plugin.so -shared = base_plugin.cpp # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ -Wl,-rpath=3D/usr/local/lib/gcc11 -omain_using_plugin = main_using_plugin.cpp # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp # ./main_using_plugin create_plugin_instance in use from dlopen'd .so create_data_instance in use from dlopen'd .so action in use from dlopen'd .so class separate_share is not nullptr (would crash otherwise) destroy_plugin_instance in use from dlopen'd .so For reference: # ldd main_using_plugin main_using_plugin: libstdc++.so.6 =3D> /usr/local/lib/gcc11//libstdc++.so.6 = (0x83a00000) libbase_plugin.so =3D> ./libbase_plugin.so (0x8213d000) libm.so.5 =3D> /lib/libm.so.5 (0x82207000) libgcc_s.so.1 =3D> /usr/local/lib/gcc11//libgcc_s.so.1 = (0x82c66000) libc.so.7 =3D> /lib/libc.so.7 (0x849c4000) # ldd ./libsharedlib_plugin.so ./libsharedlib_plugin.so: libstdc++.so.6 =3D> /usr/local/lib/gcc11/libstdc++.so.6 = (0x1c2a7b800000) libm.so.5 =3D> /lib/libm.so.5 (0x1c2a7bb1c000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x1c2a7c416000) libc.so.7 =3D> /lib/libc.so.7 (0x1c2a780e8000) Overall: Looks to me like both the system clang/llvm and g++11 contexts are working. (The platform context was aarch64 main [so: 14], in case it matters.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 15 17:49:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CA4705D1BAD for ; Fri, 15 Apr 2022 17:50:01 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kg3kc5H8Wz3rJg for ; Fri, 15 Apr 2022 17:50:00 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 23FHnroN087943 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Apr 2022 13:49:54 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 23FHnrUi087942 for freebsd-hackers@freebsd.org; Fri, 15 Apr 2022 13:49:53 -0400 (EDT) (envelope-from wayne) Date: Fri, 15 Apr 2022 13:49:53 -0400 From: Michael Wayne To: FreeBSD Hackers Subject: Can not build kernel on 1GB VM Message-ID: <20220415174953.GE13678@post.wayne47.com> Mail-Followup-To: FreeBSD Hackers List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kg3kc5H8Wz3rJg X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-0.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[wayne47.com]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_SPAM_LONG(1.00)[0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 I'm trying to upgrade the machine to 12.3 and having swap failures. This machine runs bird to advertise BGP, ssh and not much else so the small amount of RAM is (usually) fine. For a long time, there was a 1 GB swap file which handled the occasional time when excess memory got used. Machine needs a custom kernel for BGP, the conf file consists of: include GENERIC ident ROUTING options TCP_SIGNATURE Today, while building the 12.3 kernel with: cd /usr/src sudo make toolchain sudo make buildkernel KERNCONF=ROUTING the machine ran out of swap. with a bunch of messages like: Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 Thinking it was a sawp space issue, I increased the swap to 4 GB and tried again with the same results. Boot gave the kern.maxswzone message, I ignored it as I had planned to change as soon as I completed the build. So I pulled up top in a console window and watched swap during the build. About 400 MB of RAM was free and about 3 MB of swap was used when the machine started linking the kernel: ctfmerge -L VERSION -g -o kernel.full ... While this command was running, I saw swap usage go to ~5MB (so just over 1%), then started seeing processes being killed due to out of swap space. So, how to proceed? From nobody Fri Apr 15 17:55:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9925C5D3625 for ; Fri, 15 Apr 2022 17:55:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Kg3s91vyGz3tKC for ; Fri, 15 Apr 2022 17:55:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650045332; bh=nmdqiROzj6hr55xzKmJ4BWJVOFvUGiayDGjzuYWR3lA=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=P+VZdr3d8Jn4HW3lJsx3fzke5vT7uHxfT6Hb+RHwUJWygUYWB6JriTWLerm/U4waEf0ShMg97Wn0989RTlGip6b0SS7EXa+/mvKwgbpC03K3ABmszBvFGZICJ/caG/A9ph6OB5Ze7Ytp0UJW8gJgmYyPzK4GOjXBminkwcXMMI61NSVAzUxXaqqWRCJIaGU/MH61ead7nDgbowd9XrZ4OeK5YFTUxrpBVJ91sC5wld9GLn/QIDsaewSs/JbCNr0igXLed15hQ0ZV0zYhIj+sNaFjp6NZt6bE+Rp0xMl/7ClzFA1zbBZh57Do8dTxEPkQr9wL2hTy33oc5SvfT83bCw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650045332; bh=unXWOnsoBL1Nu2s2UuckqCdyQ5S40oOL+kXGy4kujab=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=OoxS+1Sm7i5ioSeFcWnNElDCem1sr+na/ImHux2FRjDZzM3pLr4+Q/768eTgES3oQ5pYADwjrJpjqAbb0coyoZIGzr8ek9NXSrqac9biAE5NN4vfEtYOQygcD7MaIdkMQHl+oGLuSFoq8TNRxZkaVwKjCuaE+lPJy3cF5Ms8wT1Padk8oYC9HQkELJh51tqlnggOKTQDQKTStS3o46JNU7tz2ej1aI26ovXXl1nPsK/Mp+2y/N85j3nsrfGxtxAzB9T503ipnRHqRoFNZc2QkitTVjXKiJlrH/r8YRZ5PkvcVig9fCZa4QRY95PqCVeeM2UJdAcUqzV+PvBQNF6ThA== X-YMail-OSG: zvAN4eYVM1nEW4rJrWx7TUoYHCuh0brVcwmO.kHUwRqK1nAYkiFGpWvqJX74EhG KBI.eQ5Ctk7RB1oTzZwWXDHZKLvMyD9NQYpbL04.VUU2rh5YnRQed0bGxyn_nbd6oxm0mg.vjLle cejchiZSvbZGqADBDrdAz0h90pp6J3YLnwDo4lcOyqtFXPYeiXiSaFe.HToNOhvjYIvnpQA_Jjqf 3N.9lB0cK2gEgN51nr6qE5NqXFc_Mp4.BCvWokblSRXMDq_EtXiRo1INz1dR_BkludRHZHArCbf7 OowC0A5eGstZrLs3ARvBQ1rLJPjzve2H9jzSQWLTdp.WdzWOKZapONAo16A9784hLMo8tOvGMiCg apN4V_jobOGh2eJtt.SarEhaYUUerIfmwruKzyDNyMTx5WzhdabKGcaKPZGxFF7O1yw5j_A1rTpJ IAT8L1HDnJhgPJ2x2Ixdi.lfMgfaFXCrdXB3wvGqe8y_FWacxKSO3UmpTfHxZc0F3yGD2bVJyPQP mnwFJRN4_r5XSLMxIPYacDqSSbL2zbfiSg2Lcczyedf19lfIdk1TDnPF.xgI8UYXj.b.CzJX9dsS awjNBBwPT3s95wDD_LsPQWYv8rNvbZEQZ_LvQEpwP86i8rS60ETWtuLX4VFGeSLW4MeyqJdWddQn K6pEg8NjNk8eolVfI5Q.RSA2LzaGkxtoleAiiKiz.XZGa.jwT1ik9XC4Y2FdkK2QeUw2j3zPjo8M Ppsi.IpHRJ9EJDN9Ntli4KelX3RhpuQgJfVeQT2qt3XbC3hUG5jbw1YtogHBQsnPOWuQtWhT_RCI 2bNAx.9UPk97V._yVTo7fduLCt8OweHqiv675D8YwoETqNjM0CgxP3FdUgtHdK7iNDTSCWYlQvL. 0jgzwjWK_0MsmtZXzEQcg_g8z0f5rAPnGvDR1rMT9OB_fzybIZGSbzC9xr191txP_vwwLE7BjZjW qlbA8OXtNa5QOOmXZn7sQrVmpIYCMGxe90BCIhusRxPy8zGxYMCZhHWfFKK3KEssscbAj9O7.zV9 xvN.0sj56wVR5NryNB8JyG4ox1GYCNYGj4KWuPgKXy2JEx7A1GVPmR6BWbVttBWuiL1.ax6DNPe4 R1y_b6T4p2kdPi09JXLgZOPljuFaPRkKYjQgH2cBCSvxlN3Vt2rB17f.xMHgW73TmxGdKeADWtix 72ro1qlraboLH3AwYLwXPeHdwEexYkaSKqhLH0bBdTltwcfEx4Qfpeh2bWpZrz7a9CpKQ4940DQd c4qNfg2nYOwiKFA2xrsRQr60cxKNDlXrX5UECVSxC6p0xsxNnXo8sz10LcNZWMLhzN1MKT0uy5L6 FoowV_X4FzVi6rekbZEEQi8M83gpp0XWbbmhjg.Rs70c0suRyKSHwMJW5PFe0rWEXoiCuRhVHnxK 7oYJLHbk2t1fYp93YjeXEnNoLkH0Vv4gKsiUoijfhWWwKTieR7_LHwft.mbYjiFWGpbHDZwVXC53 e4blCUJfGuljoCJXCpoQNhRqsG5RW7soBJz1uGZm_.4nEliCjhpR2bfZqbI9LJcS9EGAtI6HwNHc DDgUrWCimwDyX05ZhGGD1T2SlEwuA6XEu_wCwoWs._m9dW09jlpwLUZxFaX7dTSK_hIbrO.HYXZS ua1mSTQuGSy6gxKQc8ngjUrkXOJT2qww5IQHt.r_EYv7VipYaF7715wda4HDJ52GMc9VB5nIADSK ghOPbKWESkdtObTmHDPx03wUOJOsM7Uf75ajFDD9XJh_.adkcvIjTEaj57fZe7.2g5TlVXB4leW2 fPGKgSSyqqGkk7q0b4nQoIkfPal3Jpcuer4mc2cIac1f_2.qrEqCjLgFreieddl_Usl3k6T2G83m 8_z0Wt25tyn9qsIJAE4hWEVBaae7fZtP5EQzVy31leU0eUstU7F9n_ogLpLeVUbD4z4hvxlaklU5 i0gfyDdwGebaKwOO8Cq.UIuKNHSeCVy_ynIG9QuxAvnRL1_PmXhL2Hxg7nvmoWsxEqxiLv_jt.qE oF.39szUWPRsEo0SSFTKaLQEcLbJD4juY.X2a9pgCqyvvAJzsAgCd.SPX0r7Ew.P6kLkSKnyUQcQ QacVh0TTPbVtIWfqqAgeKla1w58HyGC_8Ad4OR7THyheJqn4wo8U45M3eF6eOtdoWVW6aBjrPxTv pCFHuGTy8iBebS2E2LTqHgAs.8FzjFl5rETiN7a6ndwRs.7LfHHkGCg7SKxSaYgA_9N2vvpVdnf_ pxdZDLb3L6.MK3gCesXVqoYR28EKA73ef6M7tfme.zUjofftSm0k.nBisxIx4brsNT5Y4_KnX8HU SIu_cwHbANQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Apr 2022 17:55:32 +0000 Received: by hermes--canary-production-ne1-c7c4f6977-g2rrz (VZM Hermes SMTP Server) with ESMTPA ID 05999a92e1a5a9887187640452537f02; Fri, 15 Apr 2022 17:55:30 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Date: Fri, 15 Apr 2022 10:55:28 -0700 References: <9ADA04B1-2A0F-4B96-8510-88A5E4E1E2C0@yahoo.com> To: jbo@insane.engineer, FreeBSD Hackers In-Reply-To: <9ADA04B1-2A0F-4B96-8510-88A5E4E1E2C0@yahoo.com> Message-Id: <77054BF9-54C0-4325-BE6F-66A5F04474CF@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kg3s91vyGz3tKC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=P+VZdr3d; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.31:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-14, at 23:25, Mark Millard wrote: > From: wrote on > Date: Thu, 14 Apr 2022 16:36:24 +0000 : > (I've line-split the text.) >=20 >> I'm in the middle of moving to FreeBSD as my primary development = platform (desktop wise). >> As such, I am currently building various software tools I've written = over the years on >> FreeBSD for the first time. Most of those were developed on either = Linux+GCC or on >> Windows+Mingw (MinGW -> GCC). >>=20 >> Today I found myself debugging a piece of software which runs fine on = FreeBSD when >> compiled with gcc11 but not so much when compiling with clang14. >> I managed to track down the problem but I lack the deeper = understanding to resolve >> this properly - so here we are. >>=20 >> The software in question is written in C++20 and consisting of: >> - An interface library (just a bunch of header files). >> - A main executable. >> - A bunch of plugins which the executable loads via dlopen(). >>=20 >> The interface headers provide several types. Lets call them A, B, C = and D. where B, >> C and D inherit from A. >> The plugins use std::dynamic_pointer_cast() to cast an = std::shared_ptr (received >> via the plugin interface) to the derived classes such as = std::shared_ptr. >> This is where the trouble begins. >>=20 >> If everything (the main executable and the plugins) are compiled = using gcc11, everything >> works "as I expect it". >> However, when compiling everything with clang14, the main executable = is able to load the >> plugins successfully but those std::dynamic_pointer_cast() calls = within the plugins >> always return nullptr. >>=20 >> After some research I seem to understand that the way that RTTI is = handled over shared >> library boundaries is different between GCC and LLVM. >> This is where my understanding starts to get less solid. >>=20 >> I read the manual page of dlopen(3). It would seem like the flag = RTLD_GLOBAL would be >> potentially interesting to me: "Symbols from this shared object [...] = of needed objects >> will be available for re-solving undefined references from all other = shared objects." >> The software (which "works as intended" when compiled with GCC) was = so far only calling >> dlopen(..., RTLD_LAZY). >> I'm not even sure whether this applies to my situation. My gut = feeling tells me that I'm >> heading down the wrong direction here. After all, the main executable = is able to load >> the plugins and to call the plugin's function which receives an = std::shared_ptr >> asparameter just fine, also when compiled with LLVM. >> Is the problem I'm experiencing related to the way that the plugin = (shared library) is >> loaded or the way that the symbols are being exported? >> In the current state, the plugins do not explicitly export any = symbols. >>=20 >> Here's a heavily simplified version of my scenario: >=20 > The simplified example was not designed to compile and test. > So I made guesses and made my own. The .cpp files have > comments on the compile/link commands used and there are > examples of c++ and g++11 compile/link/run sequences > after the source code. The code is not well commented. Nor > does it deal with error handling or the like. But it is > fairly short overall. >=20 > # more base_plugin.h > #include >=20 > // For its own libbase_plugin.so file, load time bound, no dlopen used = for it: >=20 > struct base > { > virtual ~base(); > }; > struct base_plugin > { > virtual std::shared_ptr create_data_instance() = =3D 0; > virtual void action(std::shared_ptr = data) =3D 0; > virtual ~base_plugin(); > }; >=20 > extern "C" // for each derived plugin .so file: > { > using plugin_instance_creator=3D base_plugin* (*)(); > const char plugin_instance_creator_name[] =3D = "create_plugin_instance"; // Lookup via dlsym. >=20 > using plugin_instance_destroyer=3D void (*)(base_plugin*); > const char plugin_instance_destroyer_name[] =3D = "destroy_plugin_instance"; // Lookup via dlsym. > }; >=20 > # more base_plugin.cpp > // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibbase_plugin.so = -shared base_plugin.cpp > // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibbase_plugin.so = -shared base_plugin.cpp >=20 > #include "base_plugin.h" >=20 > base::~base() {} > base_plugin::~base_plugin() {} >=20 > # more main_using_plugin.cpp=20 > // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ > // -omain_using_plugin = main_using_plugin.cpp > // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ > // -Wl,-rpath=3D/usr/local/lib/gcc11 -omain_using_plugin = main_using_plugin.cpp >=20 > #include "base_plugin.h" > #include >=20 > int main() > { > auto dl=3D dlopen("./libsharedlib_plugin.so",RTLD_LAZY); // = hardcoded .so path for the example >=20 > union { void* as_voidptr; plugin_instance_creator = as_plugin_instance_creator; } creator_plugin_func; > creator_plugin_func.as_voidptr=3D = dlsym(dl,plugin_instance_creator_name); >=20 > union { void* as_voidptr; plugin_instance_destroyer = as_plugin_instance_destroyer; } destroyer_plugin_func; > destroyer_plugin_func.as_voidptr=3D = dlsym(dl,plugin_instance_destroyer_name); >=20 > auto plugin=3D = (creator_plugin_func.as_plugin_instance_creator)(); >=20 > { // Local scope for data > std::shared_ptr = data{plugin->create_data_instance()}; > plugin->action(data); > } // Presume for the example that nothing requires the plugin = after here. >=20 > (destroyer_plugin_func.as_plugin_instance_destroyer)(plugin); > destroyer_plugin_func.as_voidptr=3D nullptr; >=20 > dlclose(dl); > } >=20 > NOTE: So, other than the dlopen, the above has no direct tie to > the specific dynamically loaded plugin. The base_plugin is in a > .so but is load-time bound instead of using dlopen. That .so > would be used by all the plugins found via dllopen. (I only > made one example.) >=20 > As for the .so used via dlopen/dlsym/dlclose . . . >=20 > # more sharedlib_plugin.h > #include "base_plugin.h" >=20 > // For its own libsharedlib_plugin.so file, where dlopen is used to = find it: >=20 > struct sharedlib : base { int v; }; > struct sharedlib_plugin : base_plugin > { > std::shared_ptr create_data_instance() = override; > void action(std::shared_ptr base) = override; > }; >=20 > # more sharedlib_plugin.cpp > // c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp > // g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp >=20 > #include "sharedlib_plugin.h" > #include >=20 > std::shared_ptr sharedlib_plugin::create_data_instance() > { > std::cout << "create_data_instance in use from dlopen'd .so\n"; > return = std::static_pointer_cast(std::make_shared()); > } >=20 > void sharedlib_plugin::action(std::shared_ptr b) > { > std::cout << "action in use from dlopen'd .so class\n"; > auto separate_share =3D = std::dynamic_pointer_cast(b); > if (separate_share->v || 1 < separate_share.use_count()) > std::cout << "separate_share is not nullptr (would = crash otherwise)\n"; > } >=20 > extern "C" base_plugin* create_plugin_instance() > { > std::cout << "create_plugin_instance in use from dlopen'd = .so\n"; > return new sharedlib_plugin(); > } >=20 > extern "C" void destroy_plugin_instance(const base_plugin* plugin) > { > std::cout << "destroy_plugin_instance in use from dlopen'd = .so\n"; > delete plugin; > } >=20 > # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibbase_plugin.so -shared = base_plugin.cpp > # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -L. -lbase_plugin -Wl,-rpath=3D. = \ > -omain_using_plugin main_using_plugin.cpp > # c++ -std=3Dc++20 -O0 -g -fPIC -lc++ -olibsharedlib_plugin.so -shared = sharedlib_plugin.cpp > # ./main_using_plugin > create_plugin_instance in use from dlopen'd .so > create_data_instance in use from dlopen'd .so > action in use from dlopen'd .so class > separate_share is not nullptr (would crash otherwise) > destroy_plugin_instance in use from dlopen'd .so >=20 > For reference: >=20 > # ldd main_using_plugin > main_using_plugin: > libc++.so.1 =3D> /lib/libc++.so.1 (0x819d0000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x82735000) > libbase_plugin.so =3D> ./libbase_plugin.so (0x8328d000) > libm.so.5 =3D> /lib/libm.so.5 (0x83c47000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x85861000) > libc.so.7 =3D> /lib/libc.so.7 (0x848f9000) >=20 > # ldd ./libsharedlib_plugin.so > ./libsharedlib_plugin.so: > libc++.so.1 =3D> /lib/libc++.so.1 (0x3b69aeeb6000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x3b69af6f2000) > libm.so.5 =3D> /lib/libm.so.5 (0x3b69afd1f000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x3b69b0303000) > libc.so.7 =3D> /lib/libc.so.7 (0x3b69aafdb000) >=20 >=20 > As for g++11 use . . . >=20 > Testing with g++11 does involve additional/adjusted command line > options: > -Wl,-rpath=3D/usr/local/lib/gcc11/ ( for main_using_plugin.cpp ) > -lstdc++ (for all 3 .cpp files) >=20 > (FreeBSD's libgcc_s.so.1 does not cover everything needed for > all architectures for g++11's code generation. I was working > in a context where using /usr/local/lib/gcc11//libgcc_s.so.1 > was important.) >=20 >=20 > # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibbase_plugin.so -shared = base_plugin.cpp > # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -L. -lbase_plugin = -Wl,-rpath=3D. \ > -Wl,-rpath=3D/usr/local/lib/gcc11 -omain_using_plugin = main_using_plugin.cpp > # g++11 -std=3Dc++20 -O0 -g -fPIC -lstdc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp > # ./main_using_plugin > create_plugin_instance in use from dlopen'd .so > create_data_instance in use from dlopen'd .so > action in use from dlopen'd .so class > separate_share is not nullptr (would crash otherwise) > destroy_plugin_instance in use from dlopen'd .so >=20 > For reference: >=20 > # ldd main_using_plugin > main_using_plugin: > libstdc++.so.6 =3D> /usr/local/lib/gcc11//libstdc++.so.6 = (0x83a00000) > libbase_plugin.so =3D> ./libbase_plugin.so (0x8213d000) > libm.so.5 =3D> /lib/libm.so.5 (0x82207000) > libgcc_s.so.1 =3D> /usr/local/lib/gcc11//libgcc_s.so.1 = (0x82c66000) > libc.so.7 =3D> /lib/libc.so.7 (0x849c4000) >=20 > # ldd ./libsharedlib_plugin.so > ./libsharedlib_plugin.so: > libstdc++.so.6 =3D> /usr/local/lib/gcc11/libstdc++.so.6 = (0x1c2a7b800000) > libm.so.5 =3D> /lib/libm.so.5 (0x1c2a7bb1c000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x1c2a7c416000) > libc.so.7 =3D> /lib/libc.so.7 (0x1c2a780e8000) >=20 >=20 > Overall: >=20 > Looks to me like both the system clang/llvm and g++11 contexts > are working. (The platform context was aarch64 main [so: 14], > in case it matters.) It also works for clang++14 from devel/llvm14 : # clang++14 -std=3Dc++20 -O0 -g -fPIC -lc++ -olibbase_plugin.so -shared = base_plugin.cpp # clang++14 -std=3Dc++20 -O0 -g -fPIC -lc++ -L. -lbase_plugin = -Wl,-rpath=3D. -omain_using_plugin main_using_plugin.cpp # clang++14 -std=3Dc++20 -O0 -g -fPIC -lc++ -olibsharedlib_plugin.so = -shared sharedlib_plugin.cpp # ./main_using_plugin create_plugin_instance in use from dlopen'd .so create_data_instance in use from dlopen'd .so action in use from dlopen'd .so class separate_share is not nullptr (would crash otherwise) destroy_plugin_instance in use from dlopen'd .so # ldd main_using_plugin main_using_plugin: libc++.so.1 =3D> /lib/libc++.so.1 (0x81ceb000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x82a4f000) libbase_plugin.so =3D> ./libbase_plugin.so (0x833a5000) libm.so.5 =3D> /lib/libm.so.5 (0x84fcb000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x83b37000) libc.so.7 =3D> /lib/libc.so.7 (0x84739000) # ldd ./libsharedlib_plugin.so ./libsharedlib_plugin.so: libc++.so.1 =3D> /lib/libc++.so.1 (0x2a87e9ab1000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x2a87e86dc000) libm.so.5 =3D> /lib/libm.so.5 (0x2a87e9020000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x2a87eace1000) libc.so.7 =3D> /lib/libc.so.7 (0x2a87e45a9000) I've also used -O2 and lack of -g . All the combinations I tried worked. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 15 18:40:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B68977CEDA4 for ; Fri, 15 Apr 2022 18:40:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Kg4rX4M4Tz4WT1 for ; Fri, 15 Apr 2022 18:40:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650048005; bh=FyTs13evGZ/vmrZbqA28EsaQw3eJDAvrX8CZQ/88TtE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=HByoeTYzDrpVLMxg7u+BX7q4cglAecFyLGZVx85nRvrSSa6xbjDfcw79rSxBk/Ki/iSCAAldpP5npyzHuPT5qDQYG35b5ltBskn4HDAsC+OdInozqJAYvWOt9haQ3m+olGSPsZ2RsDZ5YFMhs/z+sNcU5TJF9zaWQDavGdCSKqPhyVDUBmOvZYjrCBqHqHECYqtLwNkZvKMLvSUHrLnamCMO9gOUQwQ95ZZmv77XjMcBjrgQN3k2GfmKaavu2y1plAilj8t2eHW6WUnROtTMO0Gj3rk++p05rEYxn7bsXI+KZy7TrWSV+hC48ZAIiFEops9xhOcobm73L1nCmYp2Vg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650048005; bh=SKTWUMSop/wBtgbwPc7zvgQKiliu9NghILdTVp6NnwA=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jzDNvzZgoCQ0M9pFWXyXs3hTmkPnn490rPTV2+GhqyJY7cN9oCipQziEiPLR5S9phNHo7Ln9E7GYCZjJTBGD38tjBdv6+VhNOe+Onn12LQA0bwgFQNHwgLT07HXhN62tQN0trPK6lXGSx9k1HpcetX0ACjP4y2ib8gSxGD09uDeiaTFGfDga/ZIZXffWWog0ziG/TAB5RO8LexfjT8Zkl3/R4bzDiL8avFUXBlVoKvPlGXcJGnROVWP2LNr80FY+fsEecJej9ewDRhQfUq+9D9gxPPvULRY4kJU+9YACSC43+3VtLeROyX6i7czi9O1oc+JEszdmvR6YDoBeuo+TTA== X-YMail-OSG: AGlsPGcVM1mVpS2No0BtFhh608VOXIR8WPf.wpVO5b_Fk6qsatnaMGgIr6Y5qzP HNNxG2Iot92oC1gdn15MzHCEmbvhzcxgoygPAD4IjrJ2d.LQ4n2Khc2Uj9QSGA244KFqjD3MYyxG X9u8rIDOHNrVxk2RrkQ8oJG9vcCFA2dA2dycjW7I8YFt0SWzjKt2ikJJSiyGnC3hQeappFSmGpHf vHs6M.43liVBU0kraHezmDzNabklX1ZNiO4TeSRvVjbL_x7_C0Wyb2OlCnbDVumufudQiCB_k6Jd DSQgC4hXWX3TOkw7mBW.rIQt3jnCVnBYJtKlfCiBELSlJFDBKLH7ss8xQwmZU0XP8WHu1zPGzVfC zB3AUMJyIVOKmmQFhHCqze11bl2M0CD_cEaEOaQVZmR0eFdqxhiVYIisJsYonyhmV6H.4DS65b.p nEiIxvvXZtXsVldRkWC0u5Yj89rEdsluwbBzLAOSGqSievmYbcTLvoMq3wm6NIU_Ls1BgpZusYTd IK8BPK.KJ1soeOEJ9bMPvJF9J.ifpV4B59QW3EBezMwF_nZSQTg.HTjtr3Ma4_8EdpVZSMkC3TTl _yPHDUWdQxsafWIk0fEaWpZNZ7ngAZ9qVH3nYJ5XHfS47X_AsnMj0N9Ok8IIJx1L7KWKSUL9q4pa HTz7WKKt879pnsnK3sBiB2NYn_YYAmyWkoZCPofPdR7Q07T7sMAk1lAOpUPGUPYUJ3CkMY8Fx7SR RfjPUdQD38G3fU7mEtRfn1x.wgm1rstKrn.jzRXNVoLnZmhML7RfJsCi3S4sbszuLAoo02aMdOWb .y8FCBoGpTJHBvKjLUoj9U3LsDms6zjR14Lu.16J7tOz15ER2g9P2DjW5TANWVVV.j0RVaOyWYFd BuBIO8vxQoCaRfysvezNFUJmNuu8FAN2fujmk4kQW2NNyE7WfUKZjQJH6vaacv.iVaTHdXUvoCXR QXRmswKueQBar6ddUontAOoXtEMu4UTgCTqWOaw288h5CN2j1SNkc8sWJgP1yGpua4Z9bAo8TNOD Uq4AH09p1zydV6JcD5de9gfH19Qw27QxR34QBsaAGSeCr_ZqVpStuAn4e6vI17GzEouIC.Pj8TDB 0u2W5ZloS8Aza3CweEURroVKoS_rqY1husESL4NS63nAlcDBboq7ZzAqCdV.6BM9OZihEw0KHXYF .uUItYDWK1K_.hIR3ZL2SpcRuH0K8_MlfaGjKVsdZBO4k3oGkX1eW.V720i2DgYhUZgfzM2lOuks vfHtkFjiSMyT_SF63Vgh10UlyrUeEGnXnNEp0j.MhGDbmPc1pdYvwrnN3mGNGG0.epHPSqIZTEQk xgWJAOgkpgvgbTG3JelrogACOVENmNwZly7jZKx67z3Vfc4BV81XLJX1k3YWY6Yo5hN3bSP5g74b owWLKq3DM6hLpxi09wHjooMjZg255LKEZCTfK9Cy6G.MnM6iF0YfamVKT1jw1iw_3TBPMF5ueiuv kM3uRWiQ7E8eZUL3WC75Z0k1PEO0Ya8GoLsUYESHJ.oedDhKv9imIW5gP6GrUO1nr_0_u1GreRLI YVcvkVQ9FTky9TUyxGquGkwj9lccJr4P0U2vlKCL55XsKdM2psS1Bf.qOMYOCKE8lsKQuDAYX4W. e5.mAD5lNaRfa_Gipxoy7r.01n8Dso5D4w8yvVdOXYyyaNpU5Rhx3ZBxICY73FxjPViGDAbcTA76 gCHLWNGq9InjkKcnxxEOw.3uRe5IDN.qynsKwCRKl7myDk22Qi90ZOiD2nUwI_qTHP9nyq2ZSQFp 1qJhwlq5QHY4tSzofBS2ntwvkczsA.novTnsspPlcheQV15XpZYAezxWn8Mn1s87Iz3Ug.HWQBLO Lo95Nso31Y6UeS9NVdkhoo4AaEFAtdoukYtWLOj7aFb7MnM14_5d_Kw9moSv2symoKMzOqkeQort mCh7pNeOb0LbcY7.53gStvnIMQEQjTylrtGuuFJiZczRXSXR7If1wnJeBgWxITdGGx07xj5tyIz5 tXzwsH6GNS._aiHQ8mQibBl2c7xc_CIGARdC2MIOdv_.IpDaVPeE38AidCK8c.pMbM.OS35E9Obo 4flra0VGsQSJtzNVaz.6saGYKwir3X4SZEKnR1M9O621f4pC6xWGDcpN2U2KqGEOwNLFaPiw100K JaruM3hwxqggwiXjoBZlfkEzxtGr_7i8kotXXyxl_EXEPVlkWjmrNQ825T3we6XVZVPzM1X7hFy5 MGVs4wCgPysGzOOl169Wg2d3AfRTgMiBbbAKKiAx6zLcRJUZDpTpeRHKzW_vav1Ew0oRe5sKoF09 _oSbotOJHjdA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Apr 2022 18:40:05 +0000 Received: by hermes--canary-production-gq1-665697845d-l9qwj (VZM Hermes SMTP Server) with ESMTPA ID f4ed47a04c9617a76e8115d87d9e7f06; Fri, 15 Apr 2022 18:40:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Message-Id: Date: Fri, 15 Apr 2022 11:40:02 -0700 To: freebsd07@wayne47.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Kg4rX4M4Tz4WT1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=HByoeTYz; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: Michael Wayne =20 Date: Fri, 15 Apr 2022 13:49:53 -0400 : > I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 >=20 > I'm trying to upgrade the machine to 12.3 and having swap failures. >=20 > This machine runs bird to advertise BGP, ssh and not much else so > the small amount of RAM is (usually) fine. >=20 > For a long time, there was a 1 GB swap file which handled the > occasional time when excess memory got used. >=20 > Machine needs a custom kernel for BGP, the conf file consists of: > include GENERIC > ident ROUTING > options TCP_SIGNATURE >=20 >=20 > Today, while building the 12.3 kernel with: > cd /usr/src > sudo make toolchain > sudo make buildkernel KERNCONF=3DROUTING > the machine ran out of swap. with a bunch of messages like: > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 >=20 > Thinking it was a sawp space issue, I increased the swap to 4 GB and > tried again with the same results. Boot gave the kern.maxswzone = message, > I ignored it as I had planned to change as soon as I completed the = build. >=20 > So I pulled up top in a console window and watched swap during the > build. About 400 MB of RAM was free and about 3 MB of swap was > used when the machine started linking the kernel: > ctfmerge -L VERSION -g -o kernel.full ... > While this command was running, I saw swap usage go to ~5MB (so > just over 1%), then started seeing processes being killed due to > out of swap space. The "out of swap space" message is usually a misnomer and has been replaced in main [so: 14], stable/13 , and releng/13.1 : case VM_OOM_MEM: reason =3D "failed to reclaim memory"; break; case VM_OOM_MEM_PF: reason =3D "a thread waited too long to allocate = a page"; break; (There is one more case that still has the misnomer but case VM_OOM_SWAPZ seems unlikely to actually happen.) Given that you are getting the swap_pager: indefinite wait buffer notices I can not tell which of the two above is happening. > So, how to proceed? My /boot/loader/conf has the likes of: # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults at the time): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) The vm.pageout_oom_seq=3D120 delays VM_OOM_MEM. The vm.pfault_oom_attempts=3D-1 avoids VM_OOM_MEM_PF. Note: vm.pfault_oom_attempts=3D-1 can lead to deadlock if you actually run out of swap as I understand. You could try setting both vm.pfault_oom_attempts and vm.pfault_oom_wait but I've no specific suggested values for your context. Note: I do not recommend having so much swap that you get the the kern.maxswzone message. I do not recommend adjusting kern.maxswzone as it competes with other kernel resources --unless you understand the tradeoffs in fair detail. (I do not understand them in much detail.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 15 19:17:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D304C8D09B4 for ; Fri, 15 Apr 2022 19:17:45 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kg5gs18TZz4dnd for ; Fri, 15 Apr 2022 19:17:45 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 23FJHhCl044439 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Apr 2022 15:17:44 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 23FJHhuG044438 for freebsd-hackers@freebsd.org; Fri, 15 Apr 2022 15:17:43 -0400 (EDT) (envelope-from wayne) Date: Fri, 15 Apr 2022 15:17:43 -0400 From: Michael Wayne To: FreeBSD Hackers Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220415191743.GF13678@post.wayne47.com> Mail-Followup-To: FreeBSD Hackers References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kg5gs18TZz4dnd X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-0.86 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[wayne47.com]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.96)[-0.959]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 15, 2022 at 11:40:02AM -0700, Mark Millard wrote: > From: Michael Wayne > Date: Fri, 15 Apr 2022 13:49:53 -0400 : > > > I'm trying to upgrade the machine to 12.3 and having swap failures. I reduced the swapspace back to 1 GB. It's only ever really hit during builds. I set vm.pageout_oom_seq=120 vm.pfault_oom_attempts=-1 There was no improvement. I still see processes getting killed due to no swap space despite only 7-8 MB being reported used. It sorta feels like it's not really able to use swap at all. Note that everything worked fine on 11.x, this is a new issue on 12. From nobody Fri Apr 15 20:02:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D92972DD779 for ; Fri, 15 Apr 2022 20:03:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Kg6h61Nrfz4nWC for ; Fri, 15 Apr 2022 20:03:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650052974; bh=TYxIQiplUTuMvr6pTp3DRdz1ZkZmhKRHf5cgNgz+eX4=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=NQoaXpOOiqxTIBY72Eu7gBb05OyzwsC1Wb1XrXMo5mj7xD1WXzfn4t7VbhBx3qoJ0F8KdMABlJd1i5lq03jUf/7rUTjpMFuoQcpw5K7o9e43tBwUAMYGpgfW8y9LFWxPX9HRx2s9eLYc6JnlJ5+sKfTDP9ZK/10Jj6WNNAtin17ymqFjpB0aCB2Pte8QmRw74AOi09ff5eQV39SCu+pXQX/8IzSSfV8q4Tlas6uBR/mlaa2bljdYr/OEJ6X5D1UjGyqF0sLPyqdGCuBqJ4yZe2lvs5jC4uDOSDkmmbvP6N9RRKWCTULyz5IUsYqwuVOQbQdhj8+BwdBEvgdwNW1aJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650052974; bh=VtZ/jqJWAPLuRFTm8g7hSiZ8W/ISqVwKptRE5xJkAnn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=E2rhwbzAF0W0BeaCMoqMjxJL+raohSpRwOjWHSalPON4h5E4C2IYKBGkcLWkzPucnAvwPptZddn1f89U6YJkIGzKVvQ+Vjve8RqU7xwee44aqPZs1ftCjCaNqiIgR2jCByngHmFL4SGaULz5zRVHVYcHBmFqReMRSoNBnwC+hJgCufmCE7GBhKY1J/k++bjg3qMA9rCuzs0phNyk25eI2YKcoWX+xcvxhlxYh6AHA9+1iZWF+XQzhoaYTcqvDkMQEJuEwMXeNyhBHDhbsjFPsU/PGDdOWrYTnoz2KUdZGLYhPAR7yXOxOi4Jbpz88wfCn1EEiUxcTaigh6WQ8PsKhQ== X-YMail-OSG: 1lZe2pAVM1mCmNLhzkdtA9h9mwv267P72yR3wriBlpp6vxYf6dQwNEEr7iAWIGw 4CHp2WAd5WoqE8hxLE1Id8Nesn3rvXAXR8FTSYnPc16ajMHBdKkolvPpF4cSTJa99SCCupvJKNnO mvxaydSCFKryZtVDlaTqnNAWxbnOvcdAJXFmTqWrqaIsKxpqr3xZy5lK5jAz_2luA_aZa6RRKq.O z_B6ervsJrZTtsamSqCj_9rUgavYxuiLWjw.qh8_k_4.G1HDnXrKh5_RvewIZkqTDHrrkKwGrqL2 rZq22JvYnNlRcAl5.sZeV899aeE2SPaaJnrz.fOrHoe2Jy7bT1uCW7MV7lOY03uXsaC3LjNmXBxB depXrv_HA64yWd5tXPTuai85WOsTDYUMBWAYxI9CovdigdspKdZMiWIG0NmowkzDi3jQO6MMr20Y w0iSj4sf2TGinRhtBRz3htToAVv8db08D1a10HOEmmmk2b2n5AyYVzf90DpTGfmvSi8ocNge2ihw qKLhwzhUeC1NUoy_pLOYYkpo9a8EdxwCcQWhB07pBtgLlnqVFtkKWH1wfFkTEsWwfgCKqqjThQB2 N61.uq95Z_I0Nt19fyxbgLivmOcdN8KIEOS_jp2PptwHgNVdMWPa0veGejOvM8EaP5tyH7m_4bVB z1fSFhSfVJb69FfyPwpxE1L0Dng3noG6d0q.SCeENhDmHJtuuMbGsemtHJTEBRWo94GugrFBlMQg B4Z6UvSnvVpjlre24Y24VarOVNts4j.SlQSL3ru0tRzlByRiCmi7gzeJve2mW82l0ZyW7j_QKJQT l4dMmk3EQIbrc3dDvGi3JhQQAU5an8VbiD78SmGsQ6fkGUFs3GFP4o3DHSu38qMnsteLEdPX6g2A 9W5gsxc_7oo4_IxlEQ5zl1_2LWvdIuIJVwn6c_cdcpOdMaPpEPkY5OPYjc0CKFqSTADpY8OdtQIy mAD62hclWr6Kh_ia4d5nU6LcNDgb4e6m47T0h5m9dPID1XgISGGeOrpvXRqJFfzWis_hdBXp1lCS PWmklHcd53p_HBqfOPGK4AVpkMwLc2vQkzpAWZaQCfWYFsNfx2GnD6GKClfpyRONKfWwO1_0WZME 4ECMIHc.Lmb8TTEOPHI1VyGNYrO3HmYWYc88xTvfGMiuv7lv.NPJoWkCrVWoLQ8A7Fvjz_BnpSiw UC2i8iSY1AlUpuNI6ika1ivjp7HrSpbuaD5E0z9ggbAece4u.fabkSp3NQSymR2VCH56tJhnFOhD 3XbsRxR6inLRHvJA6NEYlQw1kcB2ASr6SB5kIEvnrFmC_YfCgawfrLJElUZZkv20BBwWw6ek1CGZ PH.Jd0GSPB_SqYfwkEFUP9pIyomt_GgndmN7x4Yad52mXr1ukAd0BEST1ZnoOGOrklPaJNGWmCW5 z_u41iJc5BORpQkvMtfWAkxYuiSypzj94TW0tbIrSzl6V0yM9bYY11m7P6hqcFp.e9UgRX0BE5DV jwhHAnRvlozS6TKwVpghAvX.ZixTUpSoXVn7FRg2gT3foPiDNQG3WmyX.lmRGV9ETdfVYOaq03lq 4q6cOOuPKzQmiKonWKkq2NMN8.Ui3TLORJH17ZUtq.mg2XFzClREZibAsFtxR8Hjt9vJztFFfh60 NrCHYj.g7mYWKg7qblzOhfsYZkAgS4Uqxq9h_uzH_9Ba4B8xq4nCATJkat6N3RjysdDOaPiMidiq 6KU.sWBC6l0QNHuUmIejZpoyw9fE9Ut8EmnmNoOPTe_wdgM2n98Nlw_KRHwJfdBxCKAhnL_e.BNK OZ7di_CapEtN6pQlfZkQXbCqfzxaG418pv9nJiQ0_IAfEGKPSwDQl.ZbZJOJEGq53vIPdihHzka5 7anJOPrOEusVhWxlxzwwg.DzE2nnO69cCTuXa6AQgjNRhjM2SdyXLHaE42iDYaAREPV77CvN0hsS qKVHBsn3n.vv8Z7LNSh.CIe0stKkze.wQzS4aavKJS9GLIcznTJrgN_Eywh121uL4KPWNvxSrNIx rp_GqzbdDjEYEQHy4QgfB_8EUVzJJBYHqVWrpxTCjVM2zcDTOd26QAukGF6Rp5M8jzqWD0J6Z5.4 3yyyytyWnKILHBLRh1RmfXwmOv7slTuuWqG4aiRt2MviQzFAwqbq5JRQk1ZVhUUsRiC_3bk1NaRp .QoHDN5wiwY6pW_MSZOVCkAiLiTO2wNGOcLBdsx1xxKiIgCjczjab1x5n3bMsyN1phDvVvxA7X.m c1iFWg_c9F38AoJ1AVHE9KMR_i2Y25_Si84gcvub1TuAa2VYo1aGXvJScOcZE4rHe4OtbyddDvNJ eEmsicSY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Apr 2022 20:02:54 +0000 Received: by hermes--canary-production-ne1-c7c4f6977-rzpnl (VZM Hermes SMTP Server) with ESMTPA ID 6f334ef75a52fca1bb4d65b0dedb51a6; Fri, 15 Apr 2022 20:02:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Date: Fri, 15 Apr 2022 13:02:47 -0700 References: To: freebsd07@wayne47.com, FreeBSD Hackers In-Reply-To: Message-Id: <4A0FAE3A-BA58-450E-B8DF-F47F44B62A50@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kg6h61Nrfz4nWC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NQoaXpOO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-15, at 11:40, Mark Millard wrote: > From: Michael Wayne =20 > Date: Fri, 15 Apr 2022 13:49:53 -0400 : >=20 >> I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 >>=20 >> I'm trying to upgrade the machine to 12.3 and having swap failures. >>=20 >> This machine runs bird to advertise BGP, ssh and not much else so >> the small amount of RAM is (usually) fine. >>=20 >> For a long time, there was a 1 GB swap file which handled the >> occasional time when excess memory got used. >>=20 >> Machine needs a custom kernel for BGP, the conf file consists of: >> include GENERIC >> ident ROUTING >> options TCP_SIGNATURE >>=20 >>=20 >> Today, while building the 12.3 kernel with: >> cd /usr/src >> sudo make toolchain >> sudo make buildkernel KERNCONF=3DROUTING >> the machine ran out of swap. with a bunch of messages like: >> Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 >> Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 >> Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 >> Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 >> Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 >> Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 >>=20 >> Thinking it was a sawp space issue, I increased the swap to 4 GB and >> tried again with the same results. Boot gave the kern.maxswzone = message, >> I ignored it as I had planned to change as soon as I completed the = build. >>=20 >> So I pulled up top in a console window and watched swap during the >> build. About 400 MB of RAM was free and about 3 MB of swap was >> used when the machine started linking the kernel: >> ctfmerge -L VERSION -g -o kernel.full ... >> While this command was running, I saw swap usage go to ~5MB (so >> just over 1%), then started seeing processes being killed due to >> out of swap space. >=20 > The "out of swap space" message is usually a misnomer I should have been explicit that the misnomer messages are when it is part of a OOM kill notification message. There is a separate message about "out of swap space" that is just a notification of that status. This message is not a misnomer and need not imply that I OOM kill will or has happened. > and has > been replaced in main [so: 14], stable/13 , and releng/13.1 : >=20 > case VM_OOM_MEM: > reason =3D "failed to reclaim memory"; > break; > case VM_OOM_MEM_PF: > reason =3D "a thread waited too long to = allocate a page"; > break; >=20 > (There is one more case that still has the misnomer but > case VM_OOM_SWAPZ seems unlikely to actually happen.) >=20 > Given that you are getting the swap_pager: indefinite wait buffer > notices I can not tell which of the two above is happening. >=20 >> So, how to proceed? >=20 > My /boot/loader/conf has the likes of: >=20 > # Delay when persistent low free RAM leads to > # Out Of Memory killing of processes: > vm.pageout_oom_seq=3D120 > # > # For plunty of swap/paging space (will not > # run out), avoid pageout delays leading to > # Out Of Memory killing of processes: > vm.pfault_oom_attempts=3D-1 > # > # For possibly insufficient swap/paging space > # (might run out), increase the pageout delay > # that leads to Out Of Memory killing of > # processes (showing defaults at the time): > #vm.pfault_oom_attempts=3D 3 > #vm.pfault_oom_wait=3D 10 > # (The multiplication is the total but there > # are other potential tradoffs in the factors > # multiplied, even for nearly the same total.) >=20 > The vm.pageout_oom_seq=3D120 delays VM_OOM_MEM. > The vm.pfault_oom_attempts=3D-1 avoids VM_OOM_MEM_PF. >=20 > Note: vm.pfault_oom_attempts=3D-1 can lead to deadlock > if you actually run out of swap as I understand. >=20 > You could try setting both vm.pfault_oom_attempts and > vm.pfault_oom_wait but I've no specific suggested > values for your context. >=20 >=20 > Note: I do not recommend having so much swap that > you get the the kern.maxswzone message. I do not > recommend adjusting kern.maxswzone as it competes > with other kernel resources --unless you understand > the tradeoffs in fair detail. (I do not understand > them in much detail.) >=20 FYI: "swap_pager: indefinite wait buffer" is for a swap read taking over 20 seconds (at least in main [so: 14]): /* * Wait for the pages we want to complete. VPO_SWAPINPROG is = always * cleared on completion. If an I/O error occurs, SWAPBLK_NONE * is set in the metadata for each page in the request. */ VM_OBJECT_WLOCK(object); /* This could be implemented more efficiently with aflags */ while ((ma[0]->oflags & VPO_SWAPINPROG) !=3D 0) { ma[0]->oflags |=3D VPO_SWAPSLEEP; VM_CNT_INC(v_intrans); if (VM_OBJECT_SLEEP(object, &object->handle, PSWP, "swread", hz * 20)) { printf( "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: = %ld\n", bp->b_bufobj, (intmax_t)bp->b_blkno, = bp->b_bcount); } } VM_OBJECT_WUNLOCK(object); Also, for reference: # sysctl -d vm.pageout_oom_seq vm.pfault_oom_attempts vm.pfault_oom_wait vm.pageout_oom_seq: back-to-back calls to oom detector to start OOM vm.pfault_oom_attempts: Number of page allocation attempts in page fault = handler before it triggers OOM handling vm.pfault_oom_wait: Number of seconds to wait for free pages before = retrying the page fault handler The default for vm.pageout_oom_seq was 12 last I checked. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Apr 15 22:41:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A9C292DC6B2 for ; Fri, 15 Apr 2022 22:41:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4KgBC34TZCz3lNj for ; Fri, 15 Apr 2022 22:41:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650062488; bh=9yQABf2MIAufJRDE8hAwavmYruzmFfJQ/P8sX65VF6w=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=X3q2SRYgsdD0eXN/WJX2tsPzucWqzcg94NfJH+VEmBn25HuQxL2md96+RusPVq8A6hGlGptH0xX5jEjtYKcBV9+R3EzYyR71EIHpJ4z8uNG/MJRxhjNLnDHhYm3NdJB4uPcLuEge8v6XKpMQ6P48b6MrZfLXDBOJWL2uDrzSVcYTtEkUV/0+wzq3efUI0M1OHofdbqVWwN9O6ZAPGpi3U0JanVa7kpBzcwspcH/Wl5eza4UwfjxxeBlELRGvnX2+N38Yij9fvsrdcT+ve9vH5u0L7iN9Be3yIu7GI2wPdMTBikLRne1ge0NXj4d3yBjBKvcOBTpTuzqxSPj5buwG7Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650062488; bh=q5fNQlC8eFVIny7RupqfpxWvzUyYP6CKciSbzyJ9kgn=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kKc7mFI4bpWMeryQ5m7lRQehHJUrSk1gGCG03ihg35XkeJ4oXRcwZt/nFBZ8tQt85E2mSMju58RMBVfg1ZcbRsQlwHJAfbAmoyUHr1jZyFJhdIwyB/HLHF0sRX1B1Z9MmhMpI3VkZKWcyoqEioqpHWAtX5CvgLVHAi/vDIVHz8m+OMr7V4WrreuBFiSMsXFsHmV7uW168KGiPa4cpBB+cfdLJEhVE/E2iD7iZ89VFsJNM3SSIZ+Iy5cYM3hP8iY2z2PP6vCdKGyYA4hilYglwx7kTNuqZ6Tyt8LD/PvOn7dcyXJV1cBkrDnb/9WZY5R89kZ6lz2g10hlXmgcw1yNtA== X-YMail-OSG: lnYWTtwVM1nNtA_SBfkUp_3FXMT9dvjOfWPjKpoSc4IsZ3pYJc4pEzgLUBtHNVh WFgRMcoSGkcOH7BOxFoGmSbSQiUL83Xyc2FtnZmah2VU_G81Andge3W72Z6Zy9exP9l9xS.G8TgQ eL4F3Ayi0w8tecQAtIkxHEBP.1yz5RduPREbK7ilrJ8eCsU9gY.97tAP2FN7VbHlPtX2b5kY6Dii 24O5dFr30EHZumk89C0qMxlW0X1RWkKNTHSAheUQk..ZrCLxvjypU4LgdkUdPciAyjtFnABtTE2m ZXJf2HV2mEOHCxc27fWf8p9IKqp3VOdO5Y0t6emEBRzIz1T.vommXuj52IeDmfclkvGlPxgHAYzy yWri7MiFj8XfyFtE05AsZ8uNS1qnekrDxGnwCB5OVu.sdFBD5CgB4ziBcoAVfmeKiLKxpO87r1V4 fGV5jVsvL7ziM_EJIdWg4gAVnjj5CakfyS3djc.5m62EVc0jXjWyMDBnjMqwAn6tiCP3cZQT7i5w d5LrCNQsv5SwvIb54NRKpDm_8kxYg1KCYVvY6y2zIVYj7rzaW8sL9wOdidf52.OkrKo9xB_Z8ykO xIcL0Z_7Thn2NulP_.o1zjfmdZyamMsJOwB8W3FV3eTZv8bcK5wUCtu1xsEinLt69CKDFJbNziZw otKu_xnD5XRSabeatRlRSuoTUXH99kz_Lc3MQEP0jHMCaUemtfc5n3q.0REentFN6R4PIXvhvIVA seyrQAxw1QtRdnDGyroF74irzUmamvNrJi32vX4.ItLlh1.FExf1MMtWFtyaJ3pys9iCp716USzC TLuuegCLIL0w5Z4RGmTqmcSBb8203doWaxiiQuqcbjqJv7diIuyXejkuAvShpNkryWuLVmEGPIgi HWOkWfoGbpeZG27THaKJqzL2TT.6Fhc7bNNxnA_VOzVNQFmGwYWGoEXlP3XPTJ7YxThok8543.ax svRsJtu.U2BUDDnDS5Vaskjnn6JvX9xXrTA3qLmWC9k__pcBQj8Wy9gS27nba.sx12ZkXER4iHep cPLli6xikS6e7CflNxfbmKitd4YhYvwHsoPUHrw21GjD_Ouw2MCZqojAqPFm2fY8euqyucC0.Tff 7Y3dU897Ao8XhfvPA1l2DTKOFaeKf7eEiIpZLZhTyoCcnGDG2ZnukhYaAvL_mUnIA75IOqYmMMYv wWxH01EBQjLI89BJdtINARt3ubIdlYST3vA0SYKl9Aw3Knbke12TYmD4D1FtYETCgp.snF9vmZIN GfD40mkV3bfWWyIHPCeYv63yuLBDxMlNONuMSoykJH2GQexr_6PrjyLtBbXztbWcZXnsUfR7MNtb ciFfiYRwlMYjPBxBrMLZaYN10i2angWIbIE8bXkmS726PeJrBsjNzXmM2URUvPn4eyLarGKhSb9w HS2TAoYMC0D59EC0.ygbSjDx0HMgllF_5qsyskPc7sVS5xqfmr3PAnIybnwSsJSmzEp60GucVJrU IfwP6r37r6R8BJcyanXsgB8XQ2_11a4A.9.Nx.u_fnjBOssLx4mamGTFsEwyqQO8MdAM6bCclhAo TIJatdfP5z9D9aOelO7juYlhSCFEtwNKqHCobRmXkVxvQRX6z5DC9vykzExB77F_ub3SM0j9D5wC qPEfjEmRvs1jG1GEnGIMX1N0WGPkEjnyNYgkxFGT8Oabl.Ggqm_JdNYM5rX9Y7uaqV2.S1.AVbFs QorGAZNp5BYgGG9Y5NG5b_1KvxOSvPAz35T4pokCvifmmFsY6VYfeZUbyYC4SJ9z4vTWHOY5HreF LY05sMaXp4Fye1GDvGbddEbwLb7t7nISpe2AqW2iYOT1jysH1Exs392zYJ3wfXaxnrEbUYaXVRph 55qpvncsX5T0rNS77WuaDUOuMOrFKU7m2ZIGQM39N3CxEjItTrA4CiPgSAFmtcnRR7DypvKOhZ1Y WHjjMF_sLOzETb5WzscMaKWGiz0sjDI0gHX2Rgnd9qosJbbt_EJWkoSdz3tUPcCRa1wjELaV4dlY b5868QW1Z4TR0MAQ3DfRPn9EU.NK2dwaJGf7cOJubaSbsdxzE8foukOTB8_0BPyrTLI7y1I4qHOS .lEHhJdP_aUIR5Glzksn4Is0JjzM5u2.Ir9nd.bZKpu24yYCVIpkjNOAPQhR.cFHQtDOw11ib35j HH4EmwotbHD.YztgcIIB0i03Tz8275XrBbfqwRDnZXBZJw84ymRFEMOeJZv.pfFeWgMmoD0WJ3ox Na85u9qTmuZZZrA3rFCBpwEf5J8A6n9IvD82f1bdxcHtXJZJeeW.PYmAvISZYL4C65HMEUF4LuME NKER4RhV3oqMfa6orA4pfLdZvorOFQ32Ia14I1XjTWVHxz6aWyo_NA5RxYYxvolRV16l4AGYdHyI SfrW_Aq8F2kyU9x4- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 15 Apr 2022 22:41:28 +0000 Received: by hermes--canary-production-ne1-c7c4f6977-cwn8d (VZM Hermes SMTP Server) with ESMTPA ID 3bc377034c61a81805b69fa2f37babc5; Fri, 15 Apr 2022 22:41:27 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Message-Id: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> Date: Fri, 15 Apr 2022 15:41:25 -0700 Cc: Mark Johnston To: freebsd07@wayne47.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <64D7342D-A0FA-4E05-B883-CCEC6DA79515.ref@yahoo.com> X-Rspamd-Queue-Id: 4KgBC34TZCz3lNj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=X3q2SRYg; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.205:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: Michael Wayne =20 Date: Fri, 15 Apr 2022 15:17:43 -0400 : > On Fri, Apr 15, 2022 at 11:40:02AM -0700, Mark Millard wrote: > > From: Michael Wayne =20 > > Date: Fri, 15 Apr 2022 13:49:53 -0400 : > >=20 > > > I'm trying to upgrade the machine to 12.3 and having swap = failures. >=20 > I reduced the swapspace back to 1 GB. It's only ever really hit during=20= > builds. >=20 > I set > vm.pageout_oom_seq=3D120 > vm.pfault_oom_attempts=3D-1 >=20 > There was no improvement. I still see processes getting killed due > to no swap space despite only 7-8 MB being reported used. It sorta > feels like it's not really able to use swap at all. >=20 > Note that everything worked fine on 11.x, this is a new issue on 12. It is really unfortunate that the 3 or 4 conditions that initiate the OOM kill activity are not reported as being the specific initiator of the activity in 12.x . (Mostly fixed in sufficiently modern contexts. 2 of the conditions are very similar and tend to be treated as 1, leading to 3 instead of 4. The other 2 have detail-specific wording these days.) I went looking back in time and 12.1-RELEASE-p3 has logic for vm.pageout_oom_seq (2015) and vm.pfault_oom_attempts (2019-Sep) from what I can tell. If using vm.pageout_oom_seq=3D120 made it take longer before the OOM activity, then further increases could be appropriate. I've never had to use more than 120 but I know one person used something like 1200 on a low-end arm Small Board Computer (1 GiByte RAM, microsd card media in use for swap, as I remember). I do not know that, say, 600 would not have worked, however. That vm.pfault_oom_attempts=3D-1 did not stop the issue should eliminate "a thread waited too long to allocate a page" (modern message) as I understand from looking at the code. That is despite your report of: QUOTE Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 END QUOTE types of notices. If vm.pageout_oom_seq=3D120 made no noticable increase in how far things got (how long it ran) before the OOM activity, it is possible that you reach one of the 2 conditions that are treated as VM_OOM_SWAPZ. In such a case, either increasing the RAM space available or doing kern.maxswzone tuning may well be the only options to do the 12.3 build from the existing 12.1-RELEASE-p3 context. I've no hint to give for kern.maxswzone tuning. There is the possibility of creating a 12.3 /boot/kernel/ area from the likes of: = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= and possibly also creating/replacing the matching /usr/lib/debug/boot/kernel/ debug information (if you keep such): = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel-dbg= .txz This would avoid the kernel build. ( base.txz use is not as reasonable as it would replace configuration files with default versions and the like. ) I've CC'd Mark Johnston who has sometimes been able to help with these types of problems and how to avoid/control them. He is also the one that has improved the messaging in more modern FreeBSD versions. I include a reference to your original message for Mark J. in case he has time to look, since the content has been stripped in the message I'm replying to: = https://lists.freebsd.org/archives/freebsd-hackers/2022-April/001018.html =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 16 00:25:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 06D2C7EC154 for ; Sat, 16 Apr 2022 00:25:32 +0000 (UTC) (envelope-from peterj@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgDVz6pSfz4SGd for ; Sat, 16 Apr 2022 00:25:31 +0000 (UTC) (envelope-from peterj@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650068732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8Ntdz8JOmL/YAuVwe+SS1RDWPdGEPsE/8l+rwQX9YuA=; b=wpNMW++llNHb/W1vXxmkRekMkRtAr12ZVRRKKa4CJllObyisw3Q37k2HeimpYL0FkSuxv8 9jA84hG3sKx6QbyYDodI+wkmbp8qgbrC0CeHgkwkURwvFbhm97BbvumDhGpBmEhpe1ZSlg qMnDrP0volpiCwk1mes1GTx4O2mJDF05wgnj2+2SMIcBtOZ4+0u+8mHj0GPNUjqwJVrqmG 1crmnSUKo9zQo7nz9BvQVs4nchFM8uvwA8ofLnbttPIn+mQcTB9TkBn+AxNx56WJMz+bAd ++lKMtS9GXIVD/Tk+C13OFp+u/zEfnVQclW50HHqWfhSIv/64+ZHirapsS33xQ== Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peterj) by smtp.freebsd.org (Postfix) with ESMTPSA id 215502AEB9 for ; Sat, 16 Apr 2022 00:25:30 +0000 (UTC) (envelope-from peterj@freebsd.org) Date: Sat, 16 Apr 2022 10:25:23 +1000 From: Peter Jeremy To: FreeBSD Hackers Subject: Re: Can not build kernel on 1GB VM Message-ID: References: <20220415174953.GE13678@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OqU5eMkTv4ZFksOz" Content-Disposition: inline In-Reply-To: <20220415174953.GE13678@post.wayne47.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650068732; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8Ntdz8JOmL/YAuVwe+SS1RDWPdGEPsE/8l+rwQX9YuA=; b=UZq2FmaLeVzCKAVqqVpPpi1NBvz2KhmzaORfg8xZKRdHv719jJjR2wQCu2fx0niAxyzGSC Jp3jQU/NoXh5IfINbAyQwzxaXWi4+jo5AYlFm+fkpnZkHBlrUQ127dR8plGBbbVMWvnRQ9 4GoeZD0DPK3yNQ/9zCnosCqnjQrt1NMwx68zwVdyINm7iHWM/JEOYLrcWcakEWZpQ68HMq kcUUFXiHBpwm6ZnI0/7tAwcvGUzugpxB7qcxxqc2HgHp0z65PXLr3esVGBt4ftZs+sYbFC kGRUAcrI+6SPVzKpJbBKIjQZuLDiZBgI66UwhNdicq5/8enyo5J8wAqt7DOJwQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650068732; a=rsa-sha256; cv=none; b=rCEwuEczQnrUmYwY+kAGZg0erJ+1UzguT1O7kx+nxQ9AYyrpvebhkmS2fNilsAcWsAY5Xw jiOlkLN6DRIFh33OM+JCYVls5MSpOj/QsYXtWHJdbuS6Y6Do0G/Kr3UA0o+I4gKzi8ZHef NLVCuEJO5Cg89K7YilT9EX485orSgUAZUS2J5tR7tP/6Rm4Z0wurcukXIMg+gt9zXq7kAR UTtJX9G4GAjrM9a96JmR5xLRTcZzsw4gp8dGIjBN9cE6ePVYH1lmbLxsPvzkfiy+DN+yN+ b6ct97uzDP6FwU4DkGezctx7zi8IDfQW7ttiPxSopV9SNxueaXoXEbQ9etotzw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --OqU5eMkTv4ZFksOz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-Apr-15 13:49:53 -0400, Michael Wayne wrote: >I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > >I'm trying to upgrade the machine to 12.3 and having swap failures. Are you using ZFS or UFS and are you swapping to a raw partition or a file/zvol? >the machine ran out of swap. with a bunch of messages like: > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: = 0, blkno: 245, size: 12288 That message doesn't indicate "out of swap", in indicates that your swap device isn't responding within a "reasonable" time. If you are swapping to a local ZFS file or zvol, you may be running into a known deadlock condition and should switch to using a raw partition for swap. If you can't improve your swap device performance, adjusting the vm.pageout_oom_seq and vm.pfault_oom_attempts sysctls should resolve the problem. A true "out of swap" will appear as a message similar to swap_pager_getswapspace(nnn): failed --=20 Peter Jeremy --OqU5eMkTv4ZFksOz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmJaDOhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQ0nw//XcdDogXlcT4FVCGTCoQV6DXH+sNnKV+O9xii1qmMCaRtDjyssfgU7c9/ p5k5CZK5OpapOxDZJOXN8IXOzBDTAE4sEZ9ZnzJR+RxZFSn2e3pHYqgPBE6X2lHi GilgHz/RWp8QwWS+ydJGBX6xnWF2JlSDERSjNwgg6Bai6guquP5EjVVS5LaY3c+3 Qcctz36KYIv1WyR4FvHp7LAp/UMNCe0Psnjdsi9na3E1uibuvgrwynQIvQ5c1Kjz U1Z8mRg0lD4IMmc29x+UhE4WfUVGfzFnvz0hv5hDoUGmxs3C4unSx9IvGeWBkF8q JRGzM2oHtN8595AM+7tK9zU0sIrDhILJ9iFfYnO4CVQ+lLAptW+ik2qOCU/rWsMm pEWMrpRkSAnntFT+UkElhdpJ/uwSyBUTh/ga5LjZa3SvrsAO/n6GwxGtTjTiHrdW 2OnXaCbq2R5RjdPs4ORjbvH7PEKBi68CFk9vKsHO1+xwVsj2Xt4p6YgwlAiy1eNd Vet4oqrTxjMRrWwEv9BilQ5o2ue6ia8ufR5wUFjldMFYScXvtEf/5BGwlAvk7Wwt myHmkkJ7DIxJ9918k/a0Vr4orXTfuAjk+tEd73GiaT6rKcJGWfN6cFojNGzNN3Np 5BufiX+ZmxO8ugieXd2S04uRdvk9PHNgHiabsBtTB8QOhlhq/PQ= =RhQI -----END PGP SIGNATURE----- --OqU5eMkTv4ZFksOz-- From nobody Sat Apr 16 01:05:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 052E68D4F5A for ; Sat, 16 Apr 2022 01:05:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4KgFPB0VvWz4Xpf for ; Sat, 16 Apr 2022 01:05:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650071132; bh=CfuwSsDACFA1pMIv3brKK7XNNcktLvtF7N0z3eL66xs=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=IE+S/y3lhi4EbKSpFvhbUvzKsGtBcUggQiAV6HpITHEvdiqYgfC/jViytBqWF2nnvHxlXQgYw7M6dXei+PcWL9cEqVNprTcNlAbljc6P3+jxtpaxXs4mFxl+mLH34xOkHwDzQg34n5g++a7bVLOMYR5K0w5lgBM3p7MGsCMnIdEhwGVV0zfOonsAM1zYNG0VJcN8l3EyVjlhzObs8QooURDiENUmRK/GxSIATvYdctJN1qReFDDFyHWRaLoZO6uufh2ai1gRshbrmbAQYB9n9NvozT5BZ5vL5sOtX6sA6kjGmDlukRAbN8sn7tRVfHB5HXdjk+VarWTvK5AJRYUbIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650071132; bh=/oLDgvUNYWV/9IFXtzH7QQaV2iNxQ4dHB/zWOAap7j5=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jPYz1GAVtSRRT/qh92qroC5sno7WYAxV/zWh5voTK7RzNbN/r/MPyfP6Kz4veM+LJmQnJdDPJS2hoxPMAUdIOGkScbNUns8m2Vbewi7LO+MNfHMxpD/rlbN6yINEFYvcsrbBFlgFIuxU9J3VTlSMCDPRfCRaOVa7bFZYAIsqetfgoq2b2Z1OLbnKX3ncS1DIP4gY2nhqAR+o/ZXT/7tI6glP9uB54opWE1XqkFH5ZvRazGAkyENzQ0KootvjY1GUeVUQh9g3SdOfMxkQACzdewb9xwFm6TqowuTNAKmRMTlC/AJzPQJDQDJjGIis4tBtDHlu+lhMsHNodkgOZhVYDQ== X-YMail-OSG: iOEbbfYVM1leXsYFh6BekKDKrG4MJJfCw_sfYdSjB_Pkdb8pdd1VEYpjW0plQ9C wIf0Iet5jR99leY4IjWNqpmToo8dqomcsYEBdpdoUeWDb1NwJAOJpLp9h_92oqDterINrqWGIstt .NyaFMkJs2D4bqsVpNEd.As7PtwVJPfcg4iE_T.kifncs9tNRQSRAxlrN6S4riRwCPQ5Klaam3f2 u8353tTc593hyi55MW6GOIYiJLAC5F1TlqF.xB0x0uKKRfhIuLg4uFKfjxp.lIGLBNabdcdVYg5s MUhn2JqS6CuX6mR4yLJ2INhtH7iSUd9PyyBCtRZOAj0O5qh1KWBber1cBv1VuxPHOxMUWnZEIllT nH7u9Z2uQ83tdgginAOOCfD7kLtxjRtDpeoxc3RsEmScDtgsaQZerkU8r7kKF5RCWCI9lsG9Xrwc JvPIChLX8XvLxsH0gJq7ruMmNYDEw2P4YUsgn7usIDPoEM99ke7nvFnsiI_dzUutHph.6H9fUjDd ySyj2gHXWLdD4DJYvC.FoVA8bHs062VlPTLHwuBQQt2tlHWGxrIcTACTgFttpSpFHECDIUtp3jx0 pmkWBmK619mC2K1roaefcDqfmcg_aGO1kLVIQ6CQSP_4AF5MddZo2lEokn1M9eo39b01alCyUPUg BefiSXDkpeCi6g2kQnS7eTxl2srFT86Hoc7M8wiwx0ZXn4jAG4hQi438xSoPxfrDd1FSMCSucvOR UjHLYmbYxpgnnruvTi0X8MGL23rjAnA946bdbzavB6uV4zosSCKup5LsstO2qjE4HWqmjUSm0jVw Wdlq8TOBz_POMk_1IMMggBO6FhM70tcHdTHjAutskCmE.X00dMCbKfycBlr2Zd3jYi5bCmXUffYc cyCgWzXIsQf.P0qBmrOQU58wK1gOblRWtquLadr1GnhYFs8iiGdzjjPzxRW7qhG2bn3JEudC2rAq pAE36PwQgY4x1_ommLQtq7Y2Q4adzo2I7A91q3VLnyCmLMP9.KwK6pd8GdC68MxDM1a6Sop3xqta zWjfu7S195xpDVva3h5oCVwQjqGS81E7TreUGR4XGZMGlxO6_tgySFN_I3KIs0XPnxhXZeBDZZ9k dP8fXbuqr3QGjLN6woqDniZEQdxH3n65CDwM9Ec0Dvc2JZIrSsHGoZZLM4mXOYtmMlAibal5jhP0 GJrVHWaTVgwBRAItPLNbdZy3HS5Txdy7dnQVI0fDTks2nvlQa.QjSZ.Du2SP5K2eG_hsYj8tL_C2 BfQ0bYy4qTcDogtLHlU4vCeCap6qRyWNNfjM.ZuBjZcP1wPQ8wyTcxPgiUZmPdXg.QalYcxHci9K V790AJHc9_zOPt0bJRVA.7K6m0XZsZZnk8NuhOvkpbUTxsSfvcrDL8b4hEFyp7Z7BGTGbnzMXImq DPSSvVJagnRtVvz71LNzytCdoS6_4rOdnp44unr0N.51HCFdqL4cl5s5hGYxMXCZvsOvUb0ELfRs yQFpEDc.OIiQnzSBMsTSRHxlI7hD_jberYYckGJvxrMgsEQzuPBhMasXZi4lbvmTATArChwP3yxg Wm9VTbE8q30LhRR8Rb_oPgvKI1Gu6lsCR4wGfrmxOhoa8b6gGIOs.nfXOSBZCG4EkPiT.id.sthn 7sib.uEYbLiyCXss4.HwcdIgCFevTl9SO0r3DWpQ3Bs83k7aMrL2VxvtEIaT9ShF0Uk3cHUpIYKd 777N.2iaXIwL7fx8GdEc0Gnorh0IBl1IJ_yVIucCDrD02QjAnFU2xFJbzQOr7v7iEX_mN5SoKKgX mPzCHhy0NrTBSuINRex4UdJlI96wwKMufgyKhbltF.iapsbd0es0x9el.I.ytjFFY7FIOts7VlUo ONzEOuDcSqna09SpvOJAjnfo2KcudxtEGmCtQQvERNQO_wlybZ6EgHJyvAtaxOMC4T.6d7nWINFl els0tt5Fl3j1gQeOymNqC2HKmBMSr.R6Edg5QjmagvbeU8US53BUncgLEYoZn_0rvtz..ED6FAHs yRfZmsudumewDPkOS2gGzHxs6eg_wVSJ2JkdtKhT9x3B2M3dW4VX28MB_gskTQpSVLRdHXwRQkJG hQYXv2giNEGfjrJNMXQM_FBNcCyyod2GBINQTa7uyWd45xp8Sr.bge3h93k0Vq7R4Wnaoqn65XjQ y2cr4DnBaxDQ0ElRQKUxqEXkKUf6ofq0nJmc9lxZ3hHjIN357Hsnxkd2xPYa6Eqa3t8_J2R66A.j AXEGjTi7WODhh9xLwiB2KU3x2VExe7nJcIDSYSKVGoduI9jabRuBWrk.GaVm2xrPkC3Xuxwwv2gr GOjXzdk5HcqsT0A2KwfnFHv7z73isrFeCkLq2DMBvvPizzF2laARHDaWA6qU9nOf76Wt5dYPPtRN GFLNJufrZhWn4 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Apr 2022 01:05:32 +0000 Received: by hermes--canary-production-gq1-665697845d-jhlhx (VZM Hermes SMTP Server) with ESMTPA ID 3c364aa18fd11a98d7f5eee8fabc47c4; Sat, 16 Apr 2022 01:05:27 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Date: Fri, 15 Apr 2022 18:05:26 -0700 References: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> To: freebsd07@wayne47.com, FreeBSD Hackers In-Reply-To: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> Message-Id: <61D59FF2-D8E5-417D-BA49-6E4A91D0C7D0@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KgFPB0VvWz4Xpf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="IE+S/y3l"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [Dropped Mark J. form CC list.] On 2022-Apr-15, at 15:41, Mark Millard wrote: > From: Michael Wayne =20 > Date: Fri, 15 Apr 2022 15:17:43 -0400 : >=20 >> On Fri, Apr 15, 2022 at 11:40:02AM -0700, Mark Millard wrote: >>> From: Michael Wayne =20 >>> Date: Fri, 15 Apr 2022 13:49:53 -0400 : >>>=20 >>>> I'm trying to upgrade the machine to 12.3 and having swap failures. >>=20 >> I reduced the swapspace back to 1 GB. It's only ever really hit = during=20 >> builds. >>=20 >> I set >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >>=20 >> There was no improvement. I still see processes getting killed due >> to no swap space despite only 7-8 MB being reported used. It sorta >> feels like it's not really able to use swap at all. >>=20 >> Note that everything worked fine on 11.x, this is a new issue on 12. >=20 >=20 > It is really unfortunate that the 3 or 4 conditions that > initiate the OOM kill activity are not reported as being the > specific initiator of the activity in 12.x . (Mostly fixed > in sufficiently modern contexts. 2 of the conditions are > very similar and tend to be treated as 1, leading to > 3 instead of 4. The other 2 have detail-specific wording > these days.) >=20 > I went looking back in time and 12.1-RELEASE-p3 has logic for > vm.pageout_oom_seq (2015) and vm.pfault_oom_attempts (2019-Sep) > from what I can tell. >=20 > If using vm.pageout_oom_seq=3D120 made it take longer before > the OOM activity, then further increases could be appropriate. > I've never had to use more than 120 but I know one person > used something like 1200 on a low-end arm Small Board Computer > (1 GiByte RAM, microsd card media in use for swap, as I > remember). I do not know that, say, 600 would not have worked, > however. >=20 > That vm.pfault_oom_attempts=3D-1 did not stop the issue should > eliminate "a thread waited too long to allocate a page" (modern > message) as I understand from looking at the code. That is > despite your report of: >=20 > QUOTE > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > END QUOTE >=20 > types of notices. >=20 > If vm.pageout_oom_seq=3D120 made no noticable increase in how > far things got (how long it ran) before the OOM activity, it > is possible that you reach one of the 2 conditions that are > treated as VM_OOM_SWAPZ. In such a case, either increasing > the RAM space available or doing kern.maxswzone tuning may > well be the only options to do the 12.3 build from the > existing 12.1-RELEASE-p3 context. >=20 > I've no hint to give for kern.maxswzone tuning. >=20 > There is the possibility of creating a 12.3 /boot/kernel/ > area from the likes of: >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I'll be more expliict about my intent here, later below. > and possibly also creating/replacing the matching > /usr/lib/debug/boot/kernel/ debug information (if you keep > such): >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel-dbg= .txz >=20 > This would avoid the kernel build. >=20 > ( base.txz use is not as reasonable as it would replace > configuration files with default versions and the like. ) >=20 >=20 > I've CC'd Mark Johnston who has sometimes been able to help > with these types of problems and how to avoid/control them. > He is also the one that has improved the messaging in more > modern FreeBSD versions. >=20 > I include a reference to your original message for Mark J. > in case he has time to look, since the content has been > stripped in the message I'm replying to: >=20 > = https://lists.freebsd.org/archives/freebsd-hackers/2022-April/001018.html >=20 When I wrote about using: = http://ftp3.freebsd.org/pub/FreeBSD/releases/amd64/12.3-RELEASE/kernel.txz= I was thinking of the following sort of sequence: A) Rename /boot/kernel so that you can revert to it. B) Establish a 12.3-RELEASE kernel.txz based 12.3 /boot/kernel/ . . . C) Boot that and then try building your variant of the 12.3 kernel. This would avoid involving any variant of the 12.1-RELEASE-p3 kernel in (C). If it went well, you could install and boot your variant. Otherwise, you would be able to report that the problem still exists for 12.3's kernel and could revert to your 12.1-RELEASE-p3 kernel if you wished. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 16 01:35:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7BBAA2DC38C for ; Sat, 16 Apr 2022 01:35:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgG3y6ZsZz4cxj for ; Sat, 16 Apr 2022 01:35:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650072935; bh=rV5Kty4q97idp4GInQHRE+s+QGlTSQKtF0wwHBfgH80=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=PueqpPFPTD7QUNL7ABky/EbFU5DW7017yOD7YPoD+kqQCLF0apmPTTCfWx5ihQ2LgWyro2Vy6dwd6LgwQgnEpGM6twkjEHdvdwryDWbonewyATrJeR2R6Qx7KcbfHGxMTBhI2fE2/FZ3heGS/k1zPzg6i+d11OVaFziXt4krTSf563+g0DhVCf1D1SSR5AKDLUgtmz8s9Pw8AWBn3BczYX8imSRlTxyF4BQbodUDnDuLD0T4Fdl3a0ypyfE5N7oSboKq/kcbtkUYzcmaFWC/sAQ26uwIUR0SDdls9AMqlRgh996GNramX2shCH6QvjHZi//iQTYouWxU13oEwD1YxA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650072935; bh=8YLra8jf8VBm1QGJiymQIspQlgGyqFl57sQerhri2Jm=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=N5JXZaTupE1ciXuaXp7zI7hfh7ihTnMCMY7zWLCoZdXInojdCwu/CdQEK4DF//OQW5yqOpUU6lcqf9WaaqrBfRyZMNJYWUhdqlgWr+jk1CsXXAOs7Iuyvl7zpdEQAd/8Zudd3p/upAias1ubfaib+LkuTUM3ny/S47Gon0Zuj0HqY0oiz7IsQZyoWiv3jNpuo0NyayAoR2/EsatNxt1OIelWcLNM0BcakKyozbjuMollZ6tghataxPgtlRR7OzjKIbTuw3UWCoPWFA1bBHoBs9MUySl/Z+I+RXSD/sxRe8ztyk6MkNeQs3C98jlOI8FP/dAT7FdOCUhZXrlHOc8VTQ== X-YMail-OSG: aqt2_EAVM1nLeAO38keXVk3coLohw304SpMDVGQUDGz9D7DzrnRZMJRsKsQwFqx ZkBOVyPfREKpKWXpz0Sec16zqSz7qcmIlHaT7oluMMQ5YEz1EyXkZPjGospAV7G3WSfUWIpyCJB_ cfAqq.EGpRPuFlRnlx3.v7qke8boCq79H7cmEQp849xtGmKI6EhTd8UJlvDIb.K7YkhwiOhl4Z90 rOMrQ6YqnBiz7Y2Bx1Wosq3IjBk.0v_XpYOCuhgr9NAamQPKm3QLaQjOWSP7W2t0IExOvTdEsaht VWd4r70EVmqB4OMWwyFeX1F_5zlBXpjBGObDcktF7Qbaaro_2Hw8rr_3DoVfNla64MexyRL1ATgr lZOsQ01LMPk5Iw01MisKCMTNsVV3z7ROiTy5rglF3CRNoi2v5IS37EOnufeEYzlIEjjN2t.3FlIy ZkhnWNeQGRRXCZ1bsUj.TbOs64FZpPjxefVeODrtQBa7OB11iD1q5KYqqixkz8mekGwX4Vgqdjgh Icfxtek2notyyTeQ7rz5kQ_4WRCSDpkPoCgnx215ziIS962VMzNsPkMCt3mMTWqdTwcY.1gx.7b5 HJhpiP4.eCcrfzlisDJkRZjEg7p6Q.SKOcM_iNwxK81cLB1KwLtdDqV72RKppoF8HyWl_5ank8zf HZojpPsOIn6DBhHws2j6SxTcsZIn7f0glHFMZJ_iYsgPFkjp2yidyq37L_jfVSsvUWmWcSccGrfZ P8_AnsLwHDCFsoOmpPpoRb9PKlkC6rcH_eARa7N5m76LaVool4SNFxB1hERf7i2CYWjmIv6zZG69 Z08J0Ho8JBDoR3LIQKSoGU_HCgZbV_JW9pGSu4zTW0OIae4OtPqOQbocxEzJvHYXVHmnVfi0BNth VocXJrjbb_lJHgxwDAi49jgLqTDzboYSuwGE9U_sRVw92Ydn9egJ5z7nG2WD3MP45gBlCpYE4.Cb VhaEVZ_ZJuG3NncDC4qCdbPpSI6KcTvwn_ObS7.5tI1sTpTmrBxKPb8cLPAz5D_Benvh0WuPw6Qm QrTBRN_hK6rexedi4fwBB4pQ824BzGbltPPfQ96cltfMH3G67A8tqejxcSwgTXqbaDDnp7wuNfgP n1Hm.2zK3jXAog7P.BJHFCD8fy5bKSiN6h8gf9irrz_xJwdSMhzqs7ImvNJxOAJ40OAgov976Vvc BpO3sLs973a6_93VMe78N8suFypxfZCSK8zOlXYxpXWJlUWsf9IZBun_t_Axo5j201zYxFylmTYF bVIE0y9Y9XRzzlsehYltfOidnbpbw6_490mCI7MsKSrWxbi705F6Ddb_LRNvPVkrPXrtmveCrbHr Cb715fElvBqjy4Rta6Oq_HnpmcXG0rHt9dIavWxCLRlw_GO2vYngIJV9STwcFbgrHjTwZbfGx0lX .RBOHscIfAqu2D6FyorQ8bvvH5zQHHxmy0w_fFn8iRAuTrX9boGwfu9iDN8.KcQWSOs9X5Fjm5Ii iGcc9Dx__EqSVawjvSaGw5I6Hn3RNJwE4kbIckxzIqIpGyIWW2oqDU9uei7EKoEDCNkQ1p96YBSB da4W7ISEZXg7XKekVnVPsReGsS8SseyNFQNls9LdJS9k_clU3Z6422CLZulCoPHWRHec7b56VJQm V6zkzz2vfyVw0Zrnr2DJU0M9HylxrsQiveVguKZqL00hveQ2SW0K3dCg8PtZYX38ia.5Z2K4mirn SP2_ejOxP9.Y2fNi4wL5z0ADggIK4vOR.CRufk3xlTuWb2UbfoIFEaN4vnVPN9fcrdt1L.2IgRRU mfMbfN9t6ZST5eYp5WMD6p5jKafCKq4AAk6mL9jWhDdN8HIxTw59kYPUEdqjcaQwFx5xUr8m_lKs ryxbglMNtVveTvv36r85ST0kTgHjX._Ot4vGmE9GPNU8_EfApA1MvU759WwLSCcU55emjXdnLsnP VemUw9P4BWU4ZgP.Mtz0uVhWv13GD0VI9nMebavrZjcCdEiCdgSR3sU72IkkjfHq7xiuCsLHP71J 24ZSUtpKL2PH1DO6L1YQ4qQTe87DRirKxBZVM9Dad0Bl.CHflPcBTj9JGXhXMGoYg1LuCx8pQzVM pOwotTwdPRL4ivr4JaM6NyF5yOlHm5z523WjQ10PO3nlV8kLU16wUQRsALMD93AYtCym5JDlJ_TD QGOpN4o0GtFeHKLckeyYTwiRe4Y9_MxHX3E6I.QLRhGyuih8Ww1VwVRzDCepXAESTKs_ruZrruKd DluCxH6vL7TIWLPx8aifMWtd.iMIkXSVTGFp_bluSWW0MsYLINyvcgoUY38xTbudNaoBo9f.QjUl T9kt_s4ZlQyAq4OrJEw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 16 Apr 2022 01:35:35 +0000 Received: by hermes--canary-production-ne1-c7c4f6977-vjx2m (VZM Hermes SMTP Server) with ESMTPA ID 6d4eee4abc24ca8a8c09e409d2b285a9; Sat, 16 Apr 2022 01:35:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Message-Id: Date: Fri, 15 Apr 2022 18:35:30 -0700 Cc: FreeBSD Hackers To: freebsd07@wayne47.com, Peter Jeremy X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KgG3y6ZsZz4cxj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PueqpPFP; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N From: Peter Jeremy =20 Date: Sat, 16 Apr 2022 10:25:23 +1000: > On 2022-Apr-15 13:49:53 -0400, Michael Wayne = wrote: > >I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > > > >I'm trying to upgrade the machine to 12.3 and having swap failures. >=20 > Are you using ZFS or UFS and are you swapping to a raw partition > or a file/zvol? Gad, why did I not think to cover that issue in my earlier note to freebsd07@wayne47.com ? Good catch. In bugzilla there is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 comments #7 and #8 are related to the file/zvol issue. freebsd07@wayne47.com also indicates a VM context as well. > >the machine ran out of swap. with a bunch of messages like: > > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 > > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 240593, size: 4096 > > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 236224, size: 16384 > > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: = bufobj: 0, blkno: 245, size: 12288 >=20 > That message doesn't indicate "out of swap", I expect that the "killed due to out of swap space" message that was originally referenced (though not quoted) was of the structure: kernel: pid ???? (???), jid ??, uid ??, was killed: out of swap space That is the message type that I was reporting as being a misnomer when it is reported: the swap space available does not have to be low at all for such kills with such messages. > in indicates that your > swap device isn't responding within a "reasonable" time. If you are > swapping to a local ZFS file or zvol, you may be running into a known > deadlock condition and should switch to using a raw partition for > swap. If you can't improve your swap device performance, adjusting > the vm.pageout_oom_seq and vm.pfault_oom_attempts sysctls should > resolve the problem. freebsd07@wayne47.com later reported they did not help --but I do not know if a swap partition was what was being used or not. > A true "out of swap" will appear as a message similar to > swap_pager_getswapspace(nnn): failed Yea, there are 2 messages that are not misnomers: (Quoting from another list exchange that I had once, that in turn had copy/paste based text from an actual set of messages.) QUOTE Jan 5 21:04:31 r5601g kernel: swap_pager: out of swap space Jan 5 21:04:31 r5601g kernel: swp_pager_getswapspace(7): failed END QUOTE Neither of these messages are announcing kills. But if neither of these types messages have shown up, then any "was killed: out of swap space" message is a misnomer for the "out of swap space" part of the message. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 16 17:17:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 17C25EAE159 for ; Sat, 16 Apr 2022 17:17:20 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KgfyQ6dJcz4c26 for ; Sat, 16 Apr 2022 17:17:18 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: by mail-pg1-x529.google.com with SMTP id k62so5504181pgd.2 for ; Sat, 16 Apr 2022 10:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=fmxi2q/7oUarsiodRXjtlTLqEd9OZZKG4NJG/eQlwac=; b=qAVesoWaUs+8vsM+ybMpUcdVCSNtC95HZt9YwwOaDwQyaTweoxS0qM3XvU5HikvoMV hPuyRyRe5adW6uHBm+KtLQt8yGzRIWOY+SJgW4YDhY+IfK9tjxQA/TVKQlsHLjULaOF9 eDfEiGXzMQwWJp27g7lHjeP59GN4yMCOysv38sW0Ras2O/e5GEmEBcs+SC9qWDOEPm3M AaAUsdGlFcnvIuTkan/NTtRCTGVY/FHw6pNAk9SZKkq62MMtT2xz+V54sclQiHEJc8ox ssxCnn+ybvLUo88JtxNgUn0rxc1pm/oGfSKqVRhJz2KsHwn9WiOuCMP2XZhVOAuMIKms E5jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fmxi2q/7oUarsiodRXjtlTLqEd9OZZKG4NJG/eQlwac=; b=rHWEFQspp+kvB3hinfF01nnYSbPatts0m6rCwQdLpVEkvfvmLV09V29pHEvFWpbuk0 oTYudwPwNQb3ZlS8ijlUj6Mc5RR2Wl9UYyaWoHopd4ah/6EINJZrzhMVU1iAkwmgsH5P jJvHMvB6pX8ySS61B9xKHAHfB7/ndbLAf4c/Ul0Z5Du4KCRCkmKV/+ZGZwdD9WcHWNPw Ikn9aFpy3cOUQoJNUZcVN5GB/GTMaVHnkuWsFIoArs/8uhbyaU4gn1L9EvTqK6CkCRF/ YTBCgKBgMF+9swUCmMF6iGTZc7PT2OKpdQoDk6rro/BPvArKsKy+MP1KnDGK83uJE8uy QITA== X-Gm-Message-State: AOAM530Q0ebjQcFAwknlQ4ylgdtzDeDuerxAaEupQr561AuYjborOptG zlTTP0928prTJ2FXRzmglOHC39Ut83fTr4V9e6kGnSTrlxVYo9QrcpA= X-Google-Smtp-Source: ABdhPJx0gX2rLl+WRICIfnnzD5e6D+6FbOM/4RxR/axp+91I+9kYDUiJlZzrRwZG3f6oBZ7ED2meCN0KnUsD/5AypkQ= X-Received: by 2002:a63:b0a:0:b0:39d:4d2d:a38c with SMTP id 10-20020a630b0a000000b0039d4d2da38cmr3630961pgl.394.1650129437852; Sat, 16 Apr 2022 10:17:17 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: George Diaconu Date: Sat, 16 Apr 2022 20:17:06 +0300 Message-ID: Subject: Linux capabilities to Capsicum To: freebsd-hackers@freebsd.org Cc: Elena Mihailescu , =?UTF-8?B?yJhlbmRyZSBNaWhhaS1BbGlu?= , Darius MIHAI Content-Type: multipart/alternative; boundary="000000000000fa09b405dcc8b224" X-Rspamd-Queue-Id: 4KgfyQ6dJcz4c26 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qAVesoWa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pgngeorge@gmail.com designates 2607:f8b0:4864:20::529 as permitted sender) smtp.mailfrom=pgngeorge@gmail.com X-Spamd-Result: default: False [-2.46 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::529:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; FREEMAIL_CC(0.00)[upb.ro,gmail.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000fa09b405dcc8b224 Content-Type: text/plain; charset="UTF-8" Hello, Together with my colleagues we are trying to port OpenStack to FreeBSD. As part of the process we need to modify a python package used by OpenStack called oslo_privsep. This package uses linux capabilities to give OpenStack services the least permissions they need. Now as part of porting to FreeBSD we want to replace the linux capabilities with Capsicum. We found a list of Capsicum capabilities at [1]. So far we found that the package uses at least the following 5 capabilities described in [2]: - CAP_DAC_OVERRIDE - CAP_DAC_READ_SEARCH - CAP_NET_ADMIN - CAP_SYS_PTRACE - CAP_SYS_ADMIN What would be the respective capabilities in Capsicum? Thank you, George [1] https://www.freebsd.org/cgi/man.cgi?query=rights&sektion=4&apropos=0&manpath=FreeBSD+13.0-RELEASE+and+Ports [2] https://man7.org/linux/man-pages/man7/capabilities.7.html --000000000000fa09b405dcc8b224 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Together with my colleagues we a= re trying to port OpenStack to FreeBSD. As part of the process we need to m= odify a python package used by OpenStack called oslo_privsep. This package = uses linux capabilities to give OpenStack services the least permissions th= ey need.
Now as part of porting to FreeBSD we want to replace the= linux capabilities with Capsicum. We found a list of Capsicum capabilities= at [1]. So far we found that the package uses at least the following 5 cap= abilities described in [2]:
-=C2=A0CAP_DAC_OVERRIDE
-= =C2=A0CAP_DAC_READ_SEARCH
-=C2=A0CAP_NET_ADMIN
- CAP_SY= S_PTRACE
-=C2=A0CAP_SYS_ADMIN

What would= be the respective capabilities in Capsicum?

Thank= you,
George

 --000000000000fa09b405dcc8b224-- From nobody Sun Apr 17 15:26:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 252F411D0735 for ; Sun, 17 Apr 2022 15:26:55 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhDSb08LVz3r3n; Sun, 17 Apr 2022 15:26:55 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650209215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CtK3RB4GGcofiAgaMXVXBZQOFYy10Tf/uVnZEUuYxRQ=; b=g+ffFxLOd7w31dmp/feKVRrLOSN1yIB2EdJ6sqGZsl5hAzlinuuwg/GAb23xbgSuZL4Eb7 a/SBkyqxentVjSi2N/SMAJzzIs9rN18qmMXJNo+BQPFw2mCSYV08CYyek21BuVIMx8H9h5 cZ8jjAL6urNMzwbA+GgdjpSaCzfP+S1LbdPitAlynhXV/55nb4PXQPXdRQ//v492BYjpxX J9/dvnB4pN3d19u17VbTvQZLlj8PMEjdn6FFPaC2/35mzq0Cvld0J0B/l8SCdKpGNyVRUU jRigoQ8sV+ZZzxJ6u+2Ks4mrYU4D3+E0tFuCMkCqNbRX/L7evOXUTxJpj94aQA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id D39AE20B5C; Sun, 17 Apr 2022 15:26:54 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id 47A18305E5; Sun, 17 Apr 2022 16:26:53 +0100 (BST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Linux capabilities to Capsicum From: David Chisnall In-Reply-To: Date: Sun, 17 Apr 2022 16:26:50 +0100 Cc: freebsd-hackers@freebsd.org, Elena Mihailescu , =?utf-8?Q?=C8=98endre_Mihai-Alin?= , Darius MIHAI Content-Transfer-Encoding: quoted-printable Message-Id: References: To: George Diaconu X-Mailer: Apple Mail (2.3654.120.0.1.13) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650209215; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CtK3RB4GGcofiAgaMXVXBZQOFYy10Tf/uVnZEUuYxRQ=; b=IFy0P8dCzth6fmMkpM+N6y+Wuwww4ZeF/15rhUf07Vv0T/kpToYgLuZRakWlJ2YY/AZ5nr //LXw0jlLhd2mbZdCiml7bPKwpBhhLALG2zuoFgvR7x7iuE5nfa8EYY7IWkX7E2LDQEKtj WDmJbjbPVonydHa1kwxsiint+Eq2jtOzw5z8M55u0O2ynwYpHgLSTT5TNd68QnRQiK8HGH 74kC7H0+n9uv+3q/r7z+2az+RNSTfIe9oJCgQ03ZWwM9rh3Gcs0SUjYs3N0/WbmKv8XlsY z052SL0TUG+6AxKM+yS9pvPV/eqo62zSkDQRL3pTLjhuqSB2zuzutq90ZYaOzw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650209215; a=rsa-sha256; cv=none; b=QgyQBhF8qoSIkQCOuk1FODpcBjmvSnAyKaLSGA27OTuOjyTyuSho3UqXkISLnSFJDpXWjs sjQXvUanC6lfzrpMLRp9F1MC/RAoVugserDW/N1K8/O7HvKoLUnocrEr5USCBSsenlK5eX euiXdvAoTLgMFEj9y/J621KMznbRyFoclmRPEbf9bkrMKfwl3Hs51DTIdZtE2Ncp+gstYP l2vC8TEznbExdkWmWFGBSR1wjfK+FOYb7R8xxDa+EU2w3FL8s/kpt8ivV8cXpW2Zni+Go7 2t5sJp3z6hC45TgXDuNUP6U9mzgD/6njKdhOs2aHhSg4K/QhfWA6jeMaxLe+rA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi, I don=E2=80=99t think you=E2=80=99ll have much luck trying to map Linux = capabilities to Capsicum. Although they have similar names, they are = very different. =20 Linux capabilities, confusingly, are not a capability system. A = capability is an unforgeable token of authority that can be delegated = and must be presented to perform an action. Linux =E2=80=98capabilities=E2= =80=99 are permissions that relate to the ambient authority of a = process: simply having the permission is sufficient to perform any of = the privileged actions. There is no namable object that you are able to = present to the relevant system calls to be explicitly choose to exert = the authority. In contrast, Capsicum makes file descriptors into capabilities. Once = you enter capability mode, you have no ambient authority. You many not = access any global namespace except by presenting a capability (file = descriptor) with the relevant authority to a system call. Linux capabilities are intended to allow programs to have some subset of = root privileges. This is very difficult to do well because the = privileges that root holds on *NIX systems were never intended to be = decomposed. The set that you list add up to complete root power, in = several ways. For example: - If you have CAP_SYS_PTRACE then you can attach to init (or any other = unrestricted daemon), inject arbitrary code, and tell it to execute on = your behalf. - If you have CAP_DAC_OVERRIDE then you can (unless running with some = code-signing checks) modify bits of the filesystem that unrestricted = programs running as root will trust as containing system binaries and = have them exec code that you=E2=80=99ve injected. - If you have CAP_SYS_ADMIN, can do pretty much anything that root can = do even without additional elevation steps, including any `ioctl` on = block devices. I don=E2=80=99t think that you=E2=80=99d lose anything other than a tiny = bit of defence in depth that costs an attacker several seconds to bypass = by simply skipping the privilege separation that this kind of use of = Linux capabilities buys you. Similar restrictions could be imposed by a MAC policy[1] but that is a = lot of work to implement. It would be a nice project for someone to = look at Linux Capabilities and the Solaris equivalents and build = something that exposed this kind of functionality. The more traditional UNIX way of doing what you need is to have a = separate process that runs as root and exposes an RPC interface to the = Python code that performs these trusted actions on its behalf. That = would be a lot less effort to implement, though again the security = benefits are negligible if the set of privileged actions includes the = full set authorised by those Linux permissions since they equate to = giving the unprivileged process complete control over your system. David [1] = https://www.freebsd.org/cgi/man.cgi?query=3Dmac&sektion=3D9&apropos=3D0&ma= npath=3DFreeBSD+13.0-RELEASE+and+Ports > On 16 Apr 2022, at 18:17, George Diaconu wrote: >=20 > Hello, >=20 > Together with my colleagues we are trying to port OpenStack to = FreeBSD. As part of the process we need to modify a python package used = by OpenStack called oslo_privsep. This package uses linux capabilities = to give OpenStack services the least permissions they need. > Now as part of porting to FreeBSD we want to replace the linux = capabilities with Capsicum. We found a list of Capsicum capabilities at = [1]. So far we found that the package uses at least the following 5 = capabilities described in [2]: > - CAP_DAC_OVERRIDE > - CAP_DAC_READ_SEARCH > - CAP_NET_ADMIN > - CAP_SYS_PTRACE > - CAP_SYS_ADMIN >=20 > What would be the respective capabilities in Capsicum? >=20 > Thank you, > George >=20 > [1] = https://www.freebsd.org/cgi/man.cgi?query=3Drights&sektion=3D4&apropos=3D0= &manpath=3DFreeBSD+13.0-RELEASE+and+Ports > [2] https://man7.org/linux/man-pages/man7/capabilities.7.html From nobody Sun Apr 17 16:58:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E59E11E3B88 for ; Sun, 17 Apr 2022 16:59:00 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhGVq2fK8z4YkP; Sun, 17 Apr 2022 16:58:59 +0000 (UTC) (envelope-from pgn.george@gmail.com) Received: by mail-pg1-x52f.google.com with SMTP id k29so14830354pgm.12; Sun, 17 Apr 2022 09:58:59 -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=w+5omdbCRFkwpra6MHy07rfvAb1VLppHgjt26mi/C5U=; b=CywCP9NiH0bjwREkwShPz6c859XQq0h3NMq5YPrCPHhVbPaVtdbMLjolEH8LNFaXw9 cBYCyPx4KMAelZj2hz+ZgUsXgIyUdyDW4Iz0SKSB4yRoaI/8QpQX2LDvzxjE4kmezMV9 hWbRPsPmFykkDw3I+Bb6oa/CCyH2oI+uiKm40FYgnxbf5vVl0k6Ye4XdpzP+6JjrAWnD eHDakacNtDMRsjrAn42SNHK+F3++JKvBl0B5Fpw/qZBjafK3n3FjrW/snowA86X3UE8Y IU1yvZuWUZSlZDnbR9oHq4xcmvwcZfMq2MGjpCRB/lMB2efJj2BKhzwQJ3G7g8pgbAee TmsQ== 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=w+5omdbCRFkwpra6MHy07rfvAb1VLppHgjt26mi/C5U=; b=tpaNlGi+xI4QwF1QoVfXtK2ZuQSw1agjlbR+2UV5xMUGtJr7th+u8x17bRuBm8cfch XpxZNI8p8FshP2sP0tkbW7RLuwsRiXOyxylVwxRt/N+G8Ql38Atz06NnEig8yLOaPvaF wNyZ2ZNVSWuE2KvfUAIEcSMcze3YUIUkANmBQELRy0xqx0r5SW4ImQ3Cqidz3lPD6Jc3 PhHvsu7GuoTz+utpfj/lIgxkXrVqof28VBdM3S9XHlnA3bgH+u/SdtgAKG9XosEGns17 1yQBzD0sGT09AjP7Sh+92O/S2oRQukRYcjnXb18urvjQXOC5IvGuLlsUkeYs4w5CFGlj rgDA== X-Gm-Message-State: AOAM531kZDhhvQ3UcIFEnaTOJ1kuib0nCd+1vgTYAjnosZyRZY13eZns Oa60gurYRNvDq76moMpdHZvYxqRnFfLLieAgYrRXXQAXULnxQWiw X-Google-Smtp-Source: ABdhPJwKZ/GqRrVuvBbUjUs7S5gBulCd0LlFSWnyeAxfxs1GeUco4RK1UUSfFvX5btScDgm+ES4bqrZZehkGlmB9mOE= X-Received: by 2002:a05:6a00:b46:b0:508:2d0f:9f83 with SMTP id p6-20020a056a000b4600b005082d0f9f83mr8171754pfo.80.1650214738042; Sun, 17 Apr 2022 09:58:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: George Diaconu Date: Sun, 17 Apr 2022 19:58:46 +0300 Message-ID: Subject: Re: Linux capabilities to Capsicum To: David Chisnall Cc: freebsd-hackers@freebsd.org, Elena Mihailescu , =?UTF-8?B?yJhlbmRyZSBNaWhhaS1BbGlu?= , Darius MIHAI Content-Type: multipart/alternative; boundary="00000000000043a29505dcdc8f59" X-Rspamd-Queue-Id: 4KhGVq2fK8z4YkP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CywCP9Ni; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pgngeorge@gmail.com designates 2607:f8b0:4864:20::52f as permitted sender) smtp.mailfrom=pgngeorge@gmail.com X-Spamd-Result: default: False [-0.96 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.04)[0.039]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[freebsd.org,upb.ro,gmail.com]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000043a29505dcdc8f59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello David, Thank you for the detailed response. George On Sun, Apr 17, 2022 at 6:26 PM David Chisnall wrote= : > Hi, > > I don=E2=80=99t think you=E2=80=99ll have much luck trying to map Linux c= apabilities to > Capsicum. Although they have similar names, they are very different. > > Linux capabilities, confusingly, are not a capability system. A > capability is an unforgeable token of authority that can be delegated and > must be presented to perform an action. Linux =E2=80=98capabilities=E2= =80=99 are > permissions that relate to the ambient authority of a process: simply > having the permission is sufficient to perform any of the privileged > actions. There is no namable object that you are able to present to the > relevant system calls to be explicitly choose to exert the authority. > > In contrast, Capsicum makes file descriptors into capabilities. Once you > enter capability mode, you have no ambient authority. You many not acces= s > any global namespace except by presenting a capability (file descriptor) > with the relevant authority to a system call. > > Linux capabilities are intended to allow programs to have some subset of > root privileges. This is very difficult to do well because the privilege= s > that root holds on *NIX systems were never intended to be decomposed. Th= e > set that you list add up to complete root power, in several ways. For > example: > > - If you have CAP_SYS_PTRACE then you can attach to init (or any other > unrestricted daemon), inject arbitrary code, and tell it to execute on yo= ur > behalf. > - If you have CAP_DAC_OVERRIDE then you can (unless running with some > code-signing checks) modify bits of the filesystem that unrestricted > programs running as root will trust as containing system binaries and hav= e > them exec code that you=E2=80=99ve injected. > - If you have CAP_SYS_ADMIN, can do pretty much anything that root can d= o > even without additional elevation steps, including any `ioctl` on block > devices. > > I don=E2=80=99t think that you=E2=80=99d lose anything other than a tiny = bit of defence in > depth that costs an attacker several seconds to bypass by simply skipping > the privilege separation that this kind of use of Linux capabilities buys > you. > > Similar restrictions could be imposed by a MAC policy[1] but that is a lo= t > of work to implement. It would be a nice project for someone to look at > Linux Capabilities and the Solaris equivalents and build something that > exposed this kind of functionality. > > The more traditional UNIX way of doing what you need is to have a separat= e > process that runs as root and exposes an RPC interface to the Python code > that performs these trusted actions on its behalf. That would be a lot > less effort to implement, though again the security benefits are negligib= le > if the set of privileged actions includes the full set authorised by thos= e > Linux permissions since they equate to giving the unprivileged process > complete control over your system. > > David > > [1] > https://www.freebsd.org/cgi/man.cgi?query=3Dmac&sektion=3D9&apropos=3D0&m= anpath=3DFreeBSD+13.0-RELEASE+and+Ports > > > On 16 Apr 2022, at 18:17, George Diaconu wrote: > > > > Hello, > > > > Together with my colleagues we are trying to port OpenStack to FreeBSD. > As part of the process we need to modify a python package used by OpenSta= ck > called oslo_privsep. This package uses linux capabilities to give OpenSta= ck > services the least permissions they need. > > Now as part of porting to FreeBSD we want to replace the linux > capabilities with Capsicum. We found a list of Capsicum capabilities at > [1]. So far we found that the package uses at least the following 5 > capabilities described in [2]: > > - CAP_DAC_OVERRIDE > > - CAP_DAC_READ_SEARCH > > - CAP_NET_ADMIN > > - CAP_SYS_PTRACE > > - CAP_SYS_ADMIN > > > > What would be the respective capabilities in Capsicum? > > > > Thank you, > > George > > > > [1] > https://www.freebsd.org/cgi/man.cgi?query=3Drights&sektion=3D4&apropos=3D= 0&manpath=3DFreeBSD+13.0-RELEASE+and+Ports > > [2] https://man7.org/linux/man-pages/man7/capabilities.7.html > > --00000000000043a29505dcdc8f59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello David,

Thank you for the detailed= response.

George

On Sun, Apr 17, 2022 at 6:2= 6 PM David Chisnall <theraven@fr= eebsd.org> wrote:
Hi,

I don=E2=80=99t think you=E2=80=99ll have much luck trying to map Linux cap= abilities to Capsicum.=C2=A0 Although they have similar names, they are ver= y different.=C2=A0

Linux capabilities, confusingly, are not a capability system.=C2=A0 A capab= ility is an unforgeable token of authority that can be delegated and must b= e presented to perform an action.=C2=A0 Linux =E2=80=98capabilities=E2=80= =99 are permissions that relate to the ambient authority of a process: simp= ly having the permission is sufficient to perform any of the privileged act= ions.=C2=A0 There is no namable object that you are able to present to the = relevant system calls to be explicitly choose to exert the authority.

In contrast, Capsicum makes file descriptors into capabilities.=C2=A0 Once = you enter capability mode, you have no ambient authority.=C2=A0 You many no= t access any global namespace except by presenting a capability (file descr= iptor) with the relevant authority to a system call.

Linux capabilities are intended to allow programs to have some subset of ro= ot privileges.=C2=A0 This is very difficult to do well because the privileg= es that root holds on *NIX systems were never intended to be decomposed.=C2= =A0 The set that you list add up to complete root power, in several ways.= =C2=A0 For example:

=C2=A0- If you have CAP_SYS_PTRACE then you can attach to init (or any othe= r unrestricted daemon), inject arbitrary code, and tell it to execute on yo= ur behalf.
=C2=A0- If you have CAP_DAC_OVERRIDE then you can (unless running with some= code-signing checks) modify bits of the filesystem that unrestricted progr= ams running as root will trust as containing system binaries and have them = exec code that you=E2=80=99ve injected.
=C2=A0- If you have CAP_SYS_ADMIN, can do pretty much anything that root ca= n do even without additional elevation steps, including any `ioctl` on bloc= k devices.

I don=E2=80=99t think that you=E2=80=99d lose anything other than a tiny bi= t of defence in depth that costs an attacker several seconds to bypass by s= imply skipping the privilege separation that this kind of use of Linux capa= bilities buys you.

Similar restrictions could be imposed by a MAC policy[1] but that is a lot = of work to implement.=C2=A0 It would be a nice project for someone to look = at Linux Capabilities and the Solaris equivalents and build something that = exposed this kind of functionality.

The more traditional UNIX way of doing what you need is to have a separate = process that runs as root and exposes an RPC interface to the Python code t= hat performs these trusted actions on its behalf.=C2=A0 That would be a lot= less effort to implement, though again the security benefits are negligibl= e if the set of privileged actions includes the full set authorised by thos= e Linux permissions since they equate to giving the unprivileged process co= mplete control over your system.

David

[1] https://www.freebsd.org/cgi/man.cgi?query=3Dma= c&sektion=3D9&apropos=3D0&manpath=3DFreeBSD+13.0-RELEASE+and+Po= rts

> On 16 Apr 2022, at 18:17, George Diaconu <pgn.george@gmail.com> wrote:
>
> Hello,
>
> Together with my colleagues we are trying to port OpenStack to FreeBSD= . As part of the process we need to modify a python package used by OpenSta= ck called oslo_privsep. This package uses linux capabilities to give OpenSt= ack services the least permissions they need.
> Now as part of porting to FreeBSD we want to replace the linux capabil= ities with Capsicum. We found a list of Capsicum capabilities at [1]. So fa= r we found that the package uses at least the following 5 capabilities desc= ribed in [2]:
> - CAP_DAC_OVERRIDE
> - CAP_DAC_READ_SEARCH
> - CAP_NET_ADMIN
> - CAP_SYS_PTRACE
> - CAP_SYS_ADMIN
>
> What would be the respective capabilities in Capsicum?
>
> Thank you,
> George
>
> [1] https://www.freebsd.org/cgi/man.cgi?que= ry=3Drights&sektion=3D4&apropos=3D0&manpath=3DFreeBSD+13.0-RELE= ASE+and+Ports
> [2] https://man7.org/linux/man-pages/m= an7/capabilities.7.html

--00000000000043a29505dcdc8f59-- From nobody Mon Apr 18 02:21:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1DCF211D40A3 for ; Mon, 18 Apr 2022 02:21:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhVzn1KJ4z3P6l for ; Mon, 18 Apr 2022 02:21:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650248476; bh=hGij0/XqQMB/uGYzlnm+RZWPHv+2R1DdiO+s6Hgwf+I=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=V0HLcCO9I+C52atSF2zHr/qEt6+nAyb1oD7XuWseMHgpoP+ELNE4TrnT/f27zoYHDCmKUP3eJE0E5dElat7T0k1hMu+TeIKatFTGcsxNN4UCWgF/U557C5csqSElwXDWvw2Js7+/8/WiJWA/wA4jh/9JuI3SC1nnaTiCpSmfNciOv5x2hSaCSBz+3I+klySukr2hM0TQlz8zZYsaz3FjQDvbA5RAhJj7TTVgSuGIJSq4y2FSNhMfYz8SFbwgwlH55qAst7tEsmlRXnQRO8Hnw3hIRoAihihtqatFDneVDVGOUvtHOh8GTWIWH47LMC7/r4LYzxW/ubPn+V2TEa91Lg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650248476; bh=QIHyq2WvBa/KcqbbL679B8WKgtNpVWnegOhfv2omvAu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ImPSr5RIf50fulKsrfcxFWJUTubyb262ELMBR0TcLY0tKwrXeckj+E0atOCfXcC1lcNR5cBhqd3gVTs+gg8WlSUQLvLiCLMM8o3x9FuLLfnX+m/zfN1FDn6pkH233JI0IcrNRfAMXIRWmqE5W0d50esiL9t0jpplWLB3ZR7RoVIOb/OKFqW+v0fpfaP4QEbRsj54N4LToujVu86nQFLzD74oA6nFzjAtuySWqjWCmMTDjS+ED7jb2XePlnZ3lvvLi04D3CciC5dPO5CV0XeS9KvZt7qDw6cxEE03lpwwSqW/lmxvcQq8802T/fM2qw+nql0091eYRljG9VPmPwd3LQ== X-YMail-OSG: MP1IHOUVM1mI_gITXzxQ08bWqY6K6XH.U6YkTfTScMgt54D8fRhX4m03xRzU1KF 0jecm1Xgpi5vBXMm2che0K6LKnVJf1LprCuzzJ1rJQbSLe9f9TUcUr69FXkI92rneaXJ1D_Kq2oU f_tYP9L7KN_ACVSQKGOT5cG9AOO9wfE6iWGMREr9o5JFdDmctwT1DLTDtWkTtRt2BGbLc1HMXBlQ LT5OEYhnJI53MfKtKETYwI.h2awDiaifntPe2Ta4s9JJmbc37hv5Zlrh1cnXGsUFU_uulvke1iwQ L.A9Qlra69FxdlEe_R2tL6WccPlsACP0mrGYjzz1L7ntRoVSPwA25ySVK7GHljDjffo52IVRWSMQ LBblbzaWwe_9hb8_TzkheIYQHL2w4FBJbfNOjunoxldd0kIWd4pEbcTXrdEQd6WGIXujlq0G4toa eC.I6.WnZoox5pQJ42Ac9Svb71M3hETDEDB1qIufw00dqHscphXsIsS2yMco7Vxb97goWkfYCani kp5aBwm.qpFbZ36.csvb4t2iJhYSHgsZCoDZcC4kq7DQmI7i2Ws0HOkTYnK3dJVm5tFvA.rGbLpI nRtKgBxKK8apvSz2pD30TD59Cy5IvVFnDzSwCqcZp15BrjA9Io_TKfHTPUwirXyT7wYPCoS7gz3q W2SjJ6Fg4f5b9wM13ORrOPngWTEew9bcy9Abasp98jNCd3skYfif6uLiPrB2GztcS2LkBOWX.Zbb WTe9o.5qTGmzCEAhuIRaxeQsIYD9wLmFP1COZuJV5H5M8dpkOEv2lJiEAQEkNf0OP1DUdO_i28K5 q8c8g_Z664uQCrnMrsP6ryedWc_PdzzhPJwiasDmXNrsPxyJtg4sCGBxEpUYNcewThh11pFXSTcL qY7RrmeMCkJDkV74EmOaWhnPaudSvFGWteD0BX3OVbv9RCBmfwawNarsnDQk356PpVV06Eudg4Vv 8lEVXmr5y4jqChvPT8wUkd1rCperIop1wmDHxvPUKmiJsZabMSvCgKaJKT856RDjzw.rOaSiHRx_ 20FMgqi3FsrSDy8Lqa0m0ak1Xx8ctStWxhIwmoYq5DOcHg2B8w1IGoZjzL6M4MKVqQxqnvMs_786 jRxRk39VV1O8OHKyYoSpUszrhI.oBMK3XPOIsXYEUbUeUQJNARDIXoytlBMPgdugKcAcv77HPAaF 4yJKhPJu9Ew8qT.Mp3rreU1SpotDsp9B3hE8NCRbUpPrAQU.sO46mMpRWeCHQX9wJ5yPS.09OzwJ RY47UbTDgf9B5sy6vpRrXgkMI0rY6avoG1v2UwGlib2wen.7Bu93zF5ayI0Bipp1oFB10sINaI6X yFDl6oWSk2w8dw9rmPmwXgJN8S6EG3ilrCW_U5egRS.WV8kn3IAlORDpTxY2MOYrlZMqsM_BvzW. 1gsR9OSHbHEn5TA0.zVtSYMm52D2fPQho0oYMFTRgTsLPPdGfFf1Nmr04MtwMaEd9SDddeHWv4M6 Za_khsFHcWL4PHZRPTVhfwf0aD3zMqg9jfsS1ErkOyV0.nkr06YJZApga9bFOoa62RZcpbp8GlF8 IGNJaMhRByQxGtX93S7ND33dlORJYZ0C2P6sWKhFBVtnxRxgbkXZUELsl.8V.3iin4xfc4HWQkV8 HxuwjmaqtYLw_X2GQkouSry81izuBpbMqQUouNA563bs9Fqfnuks5L0Py9gOgNjk1uusy8_NX1hi 6i924TbpeimkdcjcG_OV6f885_BIHugkQWKNr4S6aS_3kySLV1qUX0h3_lxWSmegGxcEUykyeLvi 8CYliHi7NtdYDKieLlS_VOYPBlN_00psPm1XWIrt99X.JcdQO3ab784C5IIsVT3GX6iubN7JqD7G BSFkxKe52M_fzQOo8E6nkQ6VQ8kIwQnSLtyHIboGc0udTglO1J6P.dAa8s2_1TvwCRxjFY49CK4w ARrekNckYXikzQTSvq266VvRa.yGqGr0nExr6aE0vAx3oVv8SDYabWmqUtRDdfb3J1T6wehRuiiP uymfII_IdFmjVSTu0LvDIPUerg4Vy1m6RArfaed.z9saPYVs7xyfCI8m2ldIjx_hGnkj2rGL1bmd Y8OoXtQseToVH8Gp7RNLG1KRBBvZHZIIDJ4EW4zqqJeqv_lblHkHjwSO0E6X8ySBtQ38u8SGy7cp AtogMdxbHQzfLn8aLPJqRMjHqKvQPTUQeho7qYHumk0SbGI8r00xJI5XILLYsiSVDsriFP9kG_3N 3Cg.qI7WJtDLE7NHZn5iCfh1hsSppPTD7.phYO0VaclrFsqRFj5mpj17Zui1EOyd8xGT0e.hfgW1 3swiOBHgT6mo- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Apr 2022 02:21:16 +0000 Received: by hermes--canary-production-bf1-5f49dbcd6-7hbzw (VZM Hermes SMTP Server) with ESMTPA ID 04673f41a482f91c5a16fdc77b0558f0; Mon, 18 Apr 2022 02:21:14 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Use of lang/gcc*'s g++* via the likes of USE_GCC=11:build+ in ports when a -Wl,-rpath=/usr/local/lib/gcc* is required: How? Message-Id: <90BF482E-BE98-4783-8440-9FA0E03E3D88@yahoo.com> Date: Sun, 17 Apr 2022 19:21:11 -0700 To: freebsd-ports@freebsd.org, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <90BF482E-BE98-4783-8440-9FA0E03E3D88.ref@yahoo.com> X-Rspamd-Queue-Id: 4KhVzn1KJ4z3P6l X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=V0HLcCO9; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I'll use g++11 as an example here. By no means is the issue limited to g++11 . Also, the general issue is not limited to the specifics of the other aspects of the example I report below. EXAMPLE PROBLEM: FreeBSD's /lib/libgcc_s.so.1 is insufficient for what aarch64 g++11 code generation expects to be provided. Programs can be built but end up with notices that start with: ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by . . . not found Sometimes the ". . ." is /usr/local/lib/gcc11/libstdc++.so.6 . Other times it does not get that far because the program itself has the issue before shared libraries are bound. A simple 6 line program on aarch64 can show the issue: # more fp-binding-failure-aarch64.cpp #include volatile long double v=3DNAN; int main() { return std::isnan(v) ? 1 : 0; } # g++11 fp-binding-failure-aarch64.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by = /usr/home/root/c_tests/a.out not found The a.out has its own reference to=20 __unordtf2@GCC_4.5.0 : # nm -a a.out | grep '@GCC_[4-9]\.' | more U=20 __unordtf2@GCC_4.5.0 For reference . . . # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc11/libstdc++.so.6 = (0x83000000) libm.so.5 =3D> /lib/libm.so.5 (0x81834000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x8275a000) libc.so.7 =3D> /lib/libc.so.7 (0x845f3000) Use of -Wl,-rpath=3D/usr/local/lib/gcc11 avoids the example's failure by using gcc11's libgcc_s.so.1 instead of FreeBSD's. gcc11's libgcc_s.so.1 is more likely to accurately cover the g++11 compiler's potential range of code generation. I've no clue what all g++11 targeting aarch64 generates that also would not be found in /lib/libgcc_s.so.1 on aarch64. Similarly, I do not know what examples might exist for other FreeBSD platforms. But aarch64 is tier 1 these days, if that matters for this subject area. THE QUESTION: How does one use the likes of USE_GCC=3D11:build+ and also supply the appropriate -Wl,-rpath=3D/usr/local/lib/gcc?? to match which g++ is actually used? There is an analogous question for when using a linker command line directly instead (no -Wl, prefix). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 18 03:20:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 22CDF5D01B5; Mon, 18 Apr 2022 03:20:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhXJT0LdQz3mFJ; Mon, 18 Apr 2022 03:20:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 23I3Knlq005340 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 17 Apr 2022 20:20:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 23I3Knlv005339; Sun, 17 Apr 2022 20:20:49 -0700 (PDT) (envelope-from sgk) Date: Sun, 17 Apr 2022 20:20:49 -0700 From: Steve Kargl To: Mark Millard Cc: freebsd-ports@freebsd.org, FreeBSD Hackers Subject: Re: Use of lang/gcc*'s g++* via the likes of USE_GCC=11:build+ in ports when a -Wl,-rpath=/usr/local/lib/gcc* is required: How? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <90BF482E-BE98-4783-8440-9FA0E03E3D88.ref@yahoo.com> <90BF482E-BE98-4783-8440-9FA0E03E3D88@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90BF482E-BE98-4783-8440-9FA0E03E3D88@yahoo.com> X-Rspamd-Queue-Id: 4KhXJT0LdQz3mFJ X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [2.40 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.56)[-0.565]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.963]; MLMMJ_DEST(0.00)[freebsd-ports,freebsd-hackers]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 17, 2022 at 07:21:11PM -0700, Mark Millard wrote: > I'll use g++11 as an example here. By no means is the issue > limited to g++11 . Also, the general issue is not limited > to the specifics of the other aspects of the example I report > below. > > > EXAMPLE PROBLEM: > > FreeBSD's /lib/libgcc_s.so.1 is insufficient for what aarch64 > g++11 code generation expects to be provided. Programs can be > built but end up with notices that start with: > > ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by > . . . not found > > Sometimes the ". . ." is /usr/local/lib/gcc11/libstdc++.so.6 . > Other times it does not get that far because the program > itself has the issue before shared libraries are bound. A > simple 6 line program on aarch64 can show the issue: > You're best bet is to have small shell scripts. For gfortran testing with it built in my home directory, I have % cat ~/bin/gfcx #! /bin/sh DIR=`id -P kargl | sed 's/\:/\ /g' | awk '{print $9}'` export DIR LD_LIBRARY_PATH=$DIR/work/lib export LD_LIBRARY_PATH LD_RUN_PATH=$DIR/work/lib export LD_RUN_PATH $DIR/work/bin/gfortran -fno-backtrace $@ You'll need to figure out how to get the build to use your scripts. PS: When clang/llvm was imported into FreeBSD, /lib/libgcc_s.so.1 should have been renamed to libllvm_s_so.1. Usurping a well-known name from a well-known open-source compiler is simply stupid. -- Steve From nobody Mon Apr 18 13:44:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D17011CC3EA for ; Mon, 18 Apr 2022 13:44:38 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Khp855STVz4VCL; Mon, 18 Apr 2022 13:44:37 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 23IDi4L0002394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Apr 2022 09:44:05 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 23IDi4nH002393; Mon, 18 Apr 2022 09:44:04 -0400 (EDT) (envelope-from wayne) Date: Mon, 18 Apr 2022 09:44:04 -0400 From: Michael Wayne To: Mark Millard Cc: freebsd07@wayne47.com, FreeBSD Hackers , Mark Johnston Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220418134404.GG13678@post.wayne47.com> Mail-Followup-To: Mark Millard , freebsd07@wayne47.com, FreeBSD Hackers , Mark Johnston References: <64D7342D-A0FA-4E05-B883-CCEC6DA79515.ref@yahoo.com> <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64D7342D-A0FA-4E05-B883-CCEC6DA79515@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Khp855STVz4VCL X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [1.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.44)[-0.437]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[wayne47.com]; NEURAL_SPAM_SHORT(1.00)[0.998]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_LONG(0.83)[0.833]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[yahoo.com]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_COUNT_ONE(0.00)[1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N I figured I would make it quicker to reproduce so I did make -n > file I removed all the files before the line that caused the issue and fed it to sh. It completed without errors. I'll swap this in and try it. If THIS fails, I'll try again, using the GENERIC 12.3 kernel. If THAT fails, I will have to resort to cross compiling on another machine. Not a good situation. From nobody Mon Apr 18 17:33:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0780111E39C9 for ; Mon, 18 Apr 2022 17:33:36 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KhvDH1mylz3PJm for ; Mon, 18 Apr 2022 17:33:35 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 23IHXYVU022465 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 18 Apr 2022 13:33:34 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 23IHXXsf022464 for freebsd-hackers@freebsd.org; Mon, 18 Apr 2022 13:33:33 -0400 (EDT) (envelope-from wayne) Date: Mon, 18 Apr 2022 13:33:33 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220418173333.GC72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220415174953.GE13678@post.wayne47.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4KhvDH1mylz3PJm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.945]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[wayne47.com]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 15, 2022 at 01:49:53PM -0400, Michael Wayne wrote: > I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > > I'm trying to upgrade the machine to 12.3 and having swap failures. I tried a number of things, all of which failed. Since the offending line is: > ctfmerge -L VERSION -g -o kernel.full ... I went digging through makefiles and found: MK_CTF=no Adding this to the command line permitted the build to complete and the machine is now running on the new kernel. Hopefully this helps others. I'm still not sure why the kernel refused to use swap but this is a very easy to duplicate issue. From nobody Tue Apr 19 06:52:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3342811E709D for ; Tue, 19 Apr 2022 06:52:12 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjDxk3DBSz3mgK for ; Tue, 19 Apr 2022 06:52:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 23J6q1iM095295 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Apr 2022 08:52:01 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1650351121; bh=rVWs1OCyddY/PvEFNdvHXfugZn5ov5YON0XCfeP1kC4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UI1iFCgl4fbSl/XT4Z7aXclh9kJHWBPAZkEIfaMN0Bvo3pBz7rXoqU21vxyMmcWOW Q67iqCG4B86RE5V/goM/sx43hxJ8C5ipiLDXY493/h2iXe1hd2GuiTDwtKFN4NBZqB 1l2G0x2OqqzM/eqgS7WJpUaocp+q+2oyavYSYLJc= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 23J6q0bA050828; Tue, 19 Apr 2022 08:52:00 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 23J6q0B9050825; Tue, 19 Apr 2022 08:52:00 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Tue, 19 Apr 2022 08:52:00 +0200 (CEST) From: Wojciech Puchar To: Michael Wayne cc: FreeBSD Hackers Subject: Re: Can not build kernel on 1GB VM In-Reply-To: <20220415174953.GE13678@post.wayne47.com> Message-ID: <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> References: <20220415174953.GE13678@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4KjDxk3DBSz3mgK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=UI1iFCgl; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N try sysctl -w vm.overcommit=1 On Fri, 15 Apr 2022, Michael Wayne wrote: > I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > > I'm trying to upgrade the machine to 12.3 and having swap failures. > > This machine runs bird to advertise BGP, ssh and not much else so > the small amount of RAM is (usually) fine. > > For a long time, there was a 1 GB swap file which handled the > occasional time when excess memory got used. > > Machine needs a custom kernel for BGP, the conf file consists of: > include GENERIC > ident ROUTING > options TCP_SIGNATURE > > > Today, while building the 12.3 kernel with: > cd /usr/src > sudo make toolchain > sudo make buildkernel KERNCONF=ROUTING > the machine ran out of swap. with a bunch of messages like: > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > > Thinking it was a sawp space issue, I increased the swap to 4 GB and > tried again with the same results. Boot gave the kern.maxswzone message, > I ignored it as I had planned to change as soon as I completed the build. > > So I pulled up top in a console window and watched swap during the > build. About 400 MB of RAM was free and about 3 MB of swap was > used when the machine started linking the kernel: > ctfmerge -L VERSION -g -o kernel.full ... > While this command was running, I saw swap usage go to ~5MB (so > just over 1%), then started seeing processes being killed due to > out of swap space. > > So, how to proceed? > > From nobody Tue Apr 19 07:05:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9767D11FD274 for ; Tue, 19 Apr 2022 07:05:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjFFf3m08z3rSM for ; Tue, 19 Apr 2022 07:05:58 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: (Authenticated sender: andriy.gapon@uabsd.com) by mail.gandi.net (Postfix) with ESMTPSA id A6E8B1BF20F for ; Tue, 19 Apr 2022 07:05:50 +0000 (UTC) Message-ID: <5d3fd21f-f831-5d8e-be79-1279122adce2@FreeBSD.org> Date: Tue, 19 Apr 2022 10:05:49 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.8.0 Subject: Re: Can not build kernel on 1GB VM *Solved* Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> From: Andriy Gapon In-Reply-To: <20220418173333.GC72471@post.wayne47.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KjFFf3m08z3rSM X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 217.70.183.201 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org X-Spamd-Result: default: False [2.28 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[avg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.201:from]; DMARC_NA(0.00)[FreeBSD.org]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.98)[0.978]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-04-18 20:33, Michael Wayne wrote: > On Fri, Apr 15, 2022 at 01:49:53PM -0400, Michael Wayne wrote: >> I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 >> >> I'm trying to upgrade the machine to 12.3 and having swap failures. > > I tried a number of things, all of which failed. > > Since the offending line is: > >> ctfmerge -L VERSION -g -o kernel.full ... > > I went digging through makefiles and found: > MK_CTF=no > > Adding this to the command line permitted the build to complete and > the machine is now running on the new kernel. Hopefully this helps > others. I'm still not sure why the kernel refused to use swap but > this is a very easy to duplicate issue. I think that the canonical way of achieving this is to remove or negate makeoptions WITH_CTF=1 in the kernel configuration. -- Andriy Gapon https://standforukraine.com https://razomforukraine.org From nobody Tue Apr 19 10:35:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5906E11CB53B for ; Tue, 19 Apr 2022 10:36:20 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjKwM4vChz3GHZ for ; Tue, 19 Apr 2022 10:36:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [91.20.73.33] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nglEC-0006wV-6P for freebsd-hackers@freebsd.org; Tue, 19 Apr 2022 12:37:00 +0200 Date: Tue, 19 Apr 2022 12:35:56 +0200 From: Fabian Keil To: FreeBSD Hackers Subject: Changing kernel message colour when using vt(4) Message-ID: <20220419123556.675d881b@fabiankeil.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/xkN1e9ppUDlyhA3Wbr5o7Tm"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4KjKwM4vChz3GHZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.16) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [-4.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; RWL_MAILSPIKE_GOOD(0.00)[80.67.18.16:from]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.97)[-0.975]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.16:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.20.73.33:received] X-ThisMailContainsUnwantedMimeParts: N --Sig_/xkN1e9ppUDlyhA3Wbr5o7Tm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable After rebasing ElectroBSD from stable/12 to stable/13 kernel messages no longer appear green in the console. Reading UPDATING I've come to the conclusion that this is due to the change from sc to vt. Green kernel messages used to be enabled with the line: options SC_KERNEL_CONS_ATTR=3D(FG_GREEN|BG_BLACK) in the kernel configuration. According to vt(4) the kernel message colour is now supposed to be controlled with a line like: options TERMINAL_KERN_ATTR=3D(FG_LIGHTRED|BG_BLACK) After adding the line I still get white kernel messages, though. I also tried changing TERMINAL_KERN_ATTR in sys/sys/terminal.h: --- a/sys/sys/terminal.h +++ b/sys/sys/terminal.h @@ -136,7 +136,7 @@ typedef teken_color_t term_color_t; #ifdef SC_KERNEL_CONS_ATTR #define TERMINAL_KERN_ATTR SC_KERNEL_CONS_ATTR #else -#define TERMINAL_KERN_ATTR (FG_WHITE | BG_BLACK) +#define TERMINAL_KERN_ATTR (FG_GREEN | BG_BLACK) #endif #endif but this doesn't seem to have a noticeable affect either. Has anyone already figured out how to change the kernel message colour on stable/13 when using vt(4)? Fabian --Sig_/xkN1e9ppUDlyhA3Wbr5o7Tm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYl6QjAAKCRAFiohV/3dU nfpGAKCXQy+CRSGrr9fcfEAbw66kHBgEFQCfUxmGRKXqV12cU4JDB8wTfq2trNs= =I1KQ -----END PGP SIGNATURE----- --Sig_/xkN1e9ppUDlyhA3Wbr5o7Tm-- From nobody Tue Apr 19 10:41:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 186B911CD319 for ; Tue, 19 Apr 2022 10:41:47 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjL2f2wTxz3Hw9 for ; Tue, 19 Apr 2022 10:41:46 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ej1-x635.google.com with SMTP id lc2so31946417ejb.12 for ; Tue, 19 Apr 2022 03:41:46 -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=nxl5HX8oudWp9/BdFEhsvPEWpLF83Ty7T1XO4vFXwjk=; b=i17odBC5k8G+rEH6zOMElxLc75tNtQ72AzkmyPL2gvmavv2htF6VhjsejTV5KTFYc3 jhpNob0yaqGYTWo2VcWjx3qbA1apCdSH9KHsQZTJjpIKt68iRQ8LyseuqagjQl/pjxtj SziB4lK2SQHS6Bj9mnt+Fg5AyFS8ueZPT9+E8ooYjcmZQO9Tl/ZYfJksXIpwXzjj/53d 9XJTBUyOzZLdEvEhC0Di4PQ7bRmg8ihJOAJsXSrZhD93GF1KAGxlQ1VnsQrlxqSbD8t9 T4d7yvWfAiM7B1NCq/oHWzli258Um2e34gEaJf2KrOLtdTavnMHkmDqPT/Xp/oXw2joQ Nx/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nxl5HX8oudWp9/BdFEhsvPEWpLF83Ty7T1XO4vFXwjk=; b=DZZbGnjzZiZbSoHSaS6OF4pC5vVpLWK4hNnZSp6FDG/GwDwN0ghhZN8hdL/b6nkuPT LCW+iTFyZSYXHHJE53f5SN2DXqL8zbCLdIJrzD6q3nE/4DUKtcabKK2BiFkmQ1Nc3YCK PILeMiVkM3VtOmfffd3uftJmrcsHS7GLYqrzGH2KZDhH8ErxWW9Z58EIQ/a2rw3U/6S7 SRjQYcmO5woDeMl8JEREeeFqpnfMM2BKurcPw+reQcGtwEZcLHfSss3DqOSptcZX1orM 93C4TwxRJysjfY8junoPhP8EdE8lBSMiFvh1rToE38sLiYUbbshfyiMtXDIFWfIEbEnz MGhw== X-Gm-Message-State: AOAM530h2yNX/JRt2fzY6CreoE9CAHAQGMGKF9RhXPsfoTWnbkghVGGK lHQX256xdJ+H3fy17fgENhzmZr1+Rkrn6t8Bxkkimjud X-Google-Smtp-Source: ABdhPJwOorDrEaVcDt5XitgEl6HQh2R4kla7cDLHCXfiNEtN9sjqG3oHycqC5rNZ8H4UeBFlKeTHDO940ZHupQyAJTo= X-Received: by 2002:a17:906:9b96:b0:6e8:6e4c:8249 with SMTP id dd22-20020a1709069b9600b006e86e4c8249mr12764421ejc.281.1650364905403; Tue, 19 Apr 2022 03:41:45 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a54:2a05:0:0:0:0:0 with HTTP; Tue, 19 Apr 2022 03:41:44 -0700 (PDT) In-Reply-To: <20220419123556.675d881b@fabiankeil.de> References: <20220419123556.675d881b@fabiankeil.de> From: Stefan Blachmann Date: Tue, 19 Apr 2022 12:41:44 +0200 Message-ID: Subject: Re: Changing kernel message colour when using vt(4) To: Fabian Keil Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4KjL2f2wTxz3Hw9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=i17odBC5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::635 as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.52)[0.520]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::635:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_SPAM_LONG(1.00)[0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N This issue is because of some changes in the loader that have not been added to the documentation. Please read my bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261311 On 4/19/22, Fabian Keil wrote: > After rebasing ElectroBSD from stable/12 to stable/13 > kernel messages no longer appear green in the console. > > Reading UPDATING I've come to the conclusion > that this is due to the change from sc to vt. > > Green kernel messages used to be enabled with the line: > > options SC_KERNEL_CONS_ATTR=(FG_GREEN|BG_BLACK) > > in the kernel configuration. > > According to vt(4) the kernel message colour is now > supposed to be controlled with a line like: > > options TERMINAL_KERN_ATTR=(FG_LIGHTRED|BG_BLACK) > > After adding the line I still get white kernel messages, > though. > > I also tried changing TERMINAL_KERN_ATTR in sys/sys/terminal.h: > > --- a/sys/sys/terminal.h > +++ b/sys/sys/terminal.h > @@ -136,7 +136,7 @@ typedef teken_color_t term_color_t; > #ifdef SC_KERNEL_CONS_ATTR > #define TERMINAL_KERN_ATTR SC_KERNEL_CONS_ATTR > #else > -#define TERMINAL_KERN_ATTR (FG_WHITE | BG_BLACK) > +#define TERMINAL_KERN_ATTR (FG_GREEN | BG_BLACK) > #endif > #endif > > but this doesn't seem to have a noticeable affect either. > > Has anyone already figured out how to change the kernel > message colour on stable/13 when using vt(4)? > > Fabian > From nobody Tue Apr 19 14:48:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 443DF11DD871 for ; Tue, 19 Apr 2022 15:44:01 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjSlN1lnxz3J2p for ; Tue, 19 Apr 2022 15:44:00 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [91.20.73.33] (helo=fabiankeil.de) by smtprelay06.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ngq19-0006a8-Mx for freebsd-hackers@freebsd.org; Tue, 19 Apr 2022 17:43:51 +0200 Date: Tue, 19 Apr 2022 16:48:39 +0200 From: Fabian Keil To: freebsd-hackers@freebsd.org Subject: Re: Changing kernel message colour when using vt(4) Message-ID: <20220419164839.6a82b5f7@fabiankeil.de> In-Reply-To: References: <20220419123556.675d881b@fabiankeil.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/r/GPLM6lHA5NQct2Jq3DwvR"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Rspamd-Queue-Id: 4KjSlN1lnxz3J2p X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.29) smtp.mailfrom=freebsd-listen@fabiankeil.de X-Spamd-Result: default: False [-2.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-0.18)[-0.180]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8972, ipnet:80.67.16.0/20, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.20.73.33:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.36)[-0.364]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[fabiankeil.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.29:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.67.18.29:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Sig_/r/GPLM6lHA5NQct2Jq3DwvR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Stefan Blachmann wrote on 2022-04-19 at 12:41:44: > On 4/19/22, Fabian Keil wrote: > > After rebasing ElectroBSD from stable/12 to stable/13 > > kernel messages no longer appear green in the console. > This issue is because of some changes in the loader that have not been > added to the documentation. > Please read my bug report: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261311 Thanks a lot for the quick response. I can confirm that the patch D34509 fixes this. Fabian --Sig_/r/GPLM6lHA5NQct2Jq3DwvR Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCYl7LyAAKCRAFiohV/3dU nWJsAKCuLNszatUiOR6d1CWS7WO6BRi8zQCgt89V64AaWlcYV+nNN3KueHUO8r4= =F0wp -----END PGP SIGNATURE----- --Sig_/r/GPLM6lHA5NQct2Jq3DwvR-- From nobody Tue Apr 19 17:46:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8093611D531E for ; Tue, 19 Apr 2022 17:46:46 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from rain.hesiod.org (rain.hesiod.org [IPv6:2001:19f0:ac01:f12:5400:3ff:feec:c026]) (using TLSv1.3 with cipher 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 "rain.hesiod.org", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjWT06ymXz3v05 for ; Tue, 19 Apr 2022 17:46:44 +0000 (UTC) (envelope-from antonfb@hesiod.org) Received: from [192.168.4.36] (142-254-83-16.fiber.dynamic.sonic.net [142.254.83.16]) (authenticated bits=0) by rain.hesiod.org (8.17.1/8.17.1) with ESMTPSA id 23JHkVgm007017 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 19 Apr 2022 10:46:37 -0700 (PDT) (envelope-from antonfb@hesiod.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hesiod.org; s=Apr22; t=1650390397; bh=Pns9O+Tub/btcX/n8SytnRgrFU4szKNfRiA3exvhx6s=; h=Date:To:From:Subject; b=GS3QASfJYkRDC/vODlvaTRE8ZgslqAuWK6bXg2pYnrTSFOZ9c44h6xb7jC6LAowXm FyQchqgnyqKsUTFsmuBtt3lppVz6Fq86uR5+V6onwrPjjWi9wwt5OQIXwf5iSWySxM W//Pd3syMoN35Zn+7FFQxhhjJnWV3Op0i4te80yCBkQs5wS46STAfjbPNTZ3UqtDQe fnqRCwLPe7eioNW6SP8Lr/lxbc7ZH7v0z6Scb7cR9Ep+d06NMYBApOquHUEqRWYiXc iTqXWEXiBgtQoA9IoWvfqP1jEimmgRrEw1xYdnSjIMbVmKxh4SeS2m5DR0SlUnvbKu 1Q+y0VOG/1e+g== X-Authentication-Warning: rain.hesiod.org: Host 142-254-83-16.fiber.dynamic.sonic.net [142.254.83.16] claimed to be [192.168.4.36] Message-ID: Date: Tue, 19 Apr 2022 10:46:31 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Content-Language: en-US To: freebsd-hackers@freebsd.org From: Jeff Anton Subject: kernel crash making a vlan on a wlan Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KjWT06ymXz3v05 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hesiod.org header.s=Apr22 header.b=GS3QASfJ; dmarc=pass (policy=none) header.from=hesiod.org; spf=pass (mx1.freebsd.org: domain of antonfb@hesiod.org designates 2001:19f0:ac01:f12:5400:3ff:feec:c026 as permitted sender) smtp.mailfrom=antonfb@hesiod.org X-Spamd-Result: default: False [-3.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hesiod.org:s=Apr22]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[hesiod.org:+]; DMARC_POLICY_ALLOW(-0.50)[hesiod.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:ac00::/38, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N A few days ago I tried setting up a vlan for a wlan on a non-critical 13.0 amd64 (Atom processor) machine and it crashed hard. And because I set it up in the rc.conf it loop crashed and eventually would not boot and standalone fsck could not repair the filesystem and it would not even get past the btx loader so that machine is out of action. It was taking kernel dumps but to the same corrupt root fs. Sigh. What I can remember from the crash report was the process was ifconfig and there were calls to like wlan_ioctl and other ioctl's on the stack. I probably set something like the following in rc.conf vlans_wlan0="vlan0" create_args_vlan0="vlan 1234" ifconfig_vlan0="inet 192.168.2.3" static_routes="mcast" route_mcast="-net 224.0.0.0/4 -iface vlan0" Anyone want to risk attempting recreation while I rebuild my now dead machine? Jeff Anton From nobody Tue Apr 19 20:29:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2FFF811D3670 for ; Tue, 19 Apr 2022 20:29:59 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kjb5L0JB8z4nD0 for ; Tue, 19 Apr 2022 20:29:58 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wr1-f47.google.com with SMTP id q3so23339708wrj.7 for ; Tue, 19 Apr 2022 13:29:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qfcNJeZ39yK6OhLRzUyWAT9qVuRapcQozEE1HdnTFFI=; b=SNJe7VbTojMCH0BUulVniwTXDElnT5bcZ0I4MoYlyxtXqAm6d5cR5bCfXZty+VmWPt Lpf8gYSFHxXJM70uaKyzBzyUy0s1jNDy+isn0vANqCzKAefx9Bf60yDjtMj3idJ58nBB aXSIEMbcvtuVHHDOaPaTaTTdNruCWQf+uBiVHV5BcBpxDTttNJv39Bx0tY6Jr9AJHG2g ljDJCLZOuTHI8RTiR0yhftzLxgR+ZkQfHwuWWYkThj7rXj7jP+BDFf3x2YHB1A71YagS HShjJc2pgz5dCXn2YDhRuhy2Z6GegxxkUwOZ8kWmsj/CI7K1OWpxQRjdS0RBAm+bN2tC Fj3A== X-Gm-Message-State: AOAM531UVhYoGBTAvE6iP7nJgOe7yOh3/hTIfWSZ+Od0bAHo5FfIqX/f jBhFQBSnStgA/TBNHenvsJUqumpaGUaQVglefHZe7YRoGME= X-Google-Smtp-Source: ABdhPJxmt+hiY328FZFMYnb4807DrbApwLZgGnzmE7WQEjHJ4Qy6vsmxKc22byZZ5dAsOrf/hSKL7EBX7J/a5jRVBek= X-Received: by 2002:a5d:59a5:0:b0:20a:a735:8670 with SMTP id p5-20020a5d59a5000000b0020aa7358670mr3548030wrr.693.1650400190856; Tue, 19 Apr 2022 13:29:50 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20220419123556.675d881b@fabiankeil.de> <20220419164839.6a82b5f7@fabiankeil.de> In-Reply-To: <20220419164839.6a82b5f7@fabiankeil.de> From: Ed Maste Date: Tue, 19 Apr 2022 16:29:37 -0400 Message-ID: Subject: Re: Changing kernel message colour when using vt(4) To: Fabian Keil Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kjb5L0JB8z4nD0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.96 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.90)[0.903]; NEURAL_HAM_LONG(-0.87)[-0.865]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.47:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.47:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 19 Apr 2022 at 11:44, Fabian Keil wrote: > > Thanks a lot for the quick response. > I can confirm that the patch D34509 fixes this. Thanks for the feedback - unfortunately D34509 makes it so that setting teken.bg_color or teken.fg_color in loader.conf has no effect on the loader. The change needs to be revisited, but should be fine if you can accept the limitations. From nobody Tue Apr 19 21:49:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A2F6411E66E6 for ; Tue, 19 Apr 2022 21:49:49 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KjcsS5pHtz3Fyf for ; Tue, 19 Apr 2022 21:49:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id BB74B1BF205 for ; Tue, 19 Apr 2022 21:49:46 +0000 (UTC) Date: Tue, 19 Apr 2022 23:49:44 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: llvm & RTTI over shared libraries Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4KjcsS5pHtz3Fyf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.201) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-0.33)[-0.326]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.201:from] X-ThisMailContainsUnwantedMimeParts: N Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb jbo@insane.engineer: > After some research I seem to understand that the way that RTTI is handled over shared library boundaries is different between GCC and LLVM. I think you are running into the old problem that GCC thinks comparing types by name makes sense where as everyone else compares types by type pointer identity. GCC is glaringly wrong because types with identical names can and often are unrelated. This is especially a problem for plugins. The correct way to deal with it is making sure that every type has a key function of appropiate visibility and making sure that the interface library exports them and every plugin links against it. If you do that, dlopen without RTLD_GLOBAL or linking the main program without -rdynamic works fine. Joerg From nobody Wed Apr 20 06:03:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B53F411DB0BE for ; Wed, 20 Apr 2022 06:03:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-8.consmr.mail.gq1.yahoo.com (sonic316-8.consmr.mail.gq1.yahoo.com [98.137.69.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4KjqqP64F1z51jq for ; Wed, 20 Apr 2022 06:03:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650434618; bh=KzaKdsZyOfxGNlWqdJgsIVrzUOGJryfIrXtY9pdFE4c=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=hL867lsYQehZacshNag+M/oPcvTM5b/nHT83j2C79wZLfN9l3d5+dG8tWuOXrCZaTArRZDapWWZm0+8uvhgPA7A99kFm7hIc+qENYv+Ynu6XvBqTC/U8V1NRoc/PNhQEsFYAPTdA6/QrJpqDLruZg6TOwhBLIzedPmOBCNdd6ZUQXQ91kW9uheYOOnIg6smmt5wAZtWJ8FKJJ3kvRPQQu2mCvTNzVqQmQJvgcUReJZLvbWGNEMc7J+jH0PcZE0cruzvLymXct3+qElwnyeoCZ353L+M1Sq3P02dRQ9DwiMuDiLa+Qu2e+cHx2aNPfqZP+IaG0hWAcbNXZ/X0t7OTfw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650434618; bh=N8Hk0Rz9kPZbRKN3bfneJnkN0wcRT1RHKuOklMpIj8s=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=HSlterq8b4Q7SGA8gzRF1dgf5JvdF/C1BwX7POXbyhgXwAy4WtP44+XHThsUs2Z4iTmss2Mw87V5VoksLuEEFXZr6OGhnKuI49yleV6qCcQ6Lze4WjemUhkVchmzAhRHsR86bZ804056Hy0VGINis87aVnNELN1chW6JgTfxnCvTyjrJSy33Fiv91InOP53MagXEqp1d1kwPw8rFzE97SY1NPVAuch0gMroWR5ho0xS6LZBItIsM6c8yA3kapw1IBhcG7TFW0fOm4dBzELpZyKZUpkF6zVeiYJz/hFt3a8cbRgTsvaLs416FuUd8UHGVskbw+UiOp1PgbbbHXVL25A== X-YMail-OSG: bd8IztsVM1md9tr3pmQFl5Hu6ov8AZgQhDu2GX21StJtpKmDIr7W5zo73ratQhi LsdVjPyWVJdwNm7GKAyPdxLcDm3wC4GQzYGHcuTwY1kVdH3di9biyMAEEAQq.UqlmyvMgngopdiA DJFlR14cqDo.7ah8MA3B7wvYGBQsm1cYC.B09gIP3pBtwqmNKZTAHVow2cSuyRLAOO0Ob0AIihIC WFFr7KyNeHGm64xfyAAcdfmEfKjc2JwpyYgAUr_c9nwD39isSligjfS1I_LUU4UfujTaJH.3fFkN rgtv4vEPB3AFEy8COtSqd9ykp8FHs9OVIHZ9Boy31s1cgaxYAYmLRS.jt9GpdZOlIp7Q5YDV._LA IZ.xXGUVOImRsh9jOypVUqjDSqPWcDNqbzFB.v7bEUMoNH7.bwoBcXWSvS6QOjoudfvtw1MrXaX3 0A_peMEjf1_KaSGrwrw..Q0.FAyzt8q2c6jO4dMJYBvqQzuWFzMR9sRw8.dd.8YfZhH1.jSPfX1h YIPnBaFGJT.bcycwwbr4_v0AX5BsTIdynE6JnbCUn778FU7rAsujnHZF3x_ynOsT3dI41oggXleB yQCXDJZECJrkJNrpkU9lm_onxOo717.k.9hkq5O9LvplZHvGVQ1E9ZaV2lomq_QsR2WiaauHI8to FlqI0MRP7sry.GJwRPoYdpn.ShuIluHpEh7Bcc34VXknxQrKgCgunaVtw57LNgu4ebRfKNKhvqwM HcRzORrtPC9yc3tUoMgbPhQfVlOKEWwgWFo8QP.x687D2MJ38FZNWrt2p_WZ5PbAH2D_GKgiAkHF MwTFUiBkR8Np5PUbjupxCSmodphpERlP.0te.LBR4yFFJen0rb7rXGQpNQoibW18usySUz02TuKl rbzcmYcmL5VjqA069XPF03ar5XHvxnnEwgfsmjqmB_bFa910kqelfPaNNe9JPdrnNHxS3bhS_qYb KQxhHaUCpCCNUH40jtV.1Fg8Nr.KntXJIEx1SZTEygUYX8wbQva8A3ZUBaxldv3vd9P4_EHIHvE2 1HYppgrWbK9jBV6Fp9NxN_MhyHI7XNNYWSN3GFN.5uXJWD7TxlOgBAF8tU.IXkcuJ1Paq.2NrNp_ lJc9WS3F_hg..m9IOksjZsNSynE5CtrUMb0D2MTmfy_zsL1X4dBNUd_KVmGvH1xnZExDWxRlRPho snUwB3ToIYiWKg5tvpvjiVDm_11X008ZvKwWJcI2m.AYafa3EHAjyj0is3KuxUFU3GRVpXEhqAKT H0oczC6b4gHtOG3q6E7BVsPw.4EStuHSa4SNQYbNHhv_EucDbt1otMY11jvLc8Y912O86pNVzs4. VIuUQfPH2.JNN7z0lrEWjnSf61lfwMzDMSG2cmitMh60yTDs230hClF2a9oVQgWmt2R2VbI48lh7 X_UbLuqw5Z3.QMAmGB0UjAKQpWKTBydUNe_k_dX05H1HQWsgXaszMjs9Yo0hlqLy0W.MHQbK6W54 Lmo_QL9naZSJvvmTR9CnpuMndOprFJ6.T.n3.zvza0xvqnd3fM2KM7.foXNGHpnfx.H8RLnJdTR0 9JzoY87TJ.QDNhaoLd1M1eEB3ROD7MHp7knH9AVPCUwILbfB0_JlajOtSXN_SJIaiXIvbel9M5UG dgqHg66ImMHsExL0w68FQM09.viewTdxuOY7YUXijx0OI.NJHoIuIZozDPgOw.6pcud9As8bZ8yI lobK64DpI9j9T3wAGsOAx5_uN1lNmv56kyWWaJEQLxN_ovnVXSuJyuO.Xss5tsyv7sZ3UFXMKho9 FI190nrMp1YtKYmLjpFv4nDr.pqpLmMkqSmNkuhGERGfovm0NNHX8398CxgZNBCUidc1si.SWboj _5pdnVik7.FkMUFi_QEeJo56iibAaYEhTpE6gsEtBjH5lecG0kG6rWX_f.aloU4E1zLd0v_W6iaN 6dodXJz0OY7_RgmQRhm4f6mdkcIKzJnT1jVLyQY1W1SmdW6h3Y9WlV9h6sdcGm_YvXs5VMv7F49Z wgfCFvPkUv.4nN9fHkAEBIXi8l8lPC7R7QaG6F_QeDVycGUWWrD5YkUQxSBp3CUYvuuJs1CJKkfg IEDAvJnqlbWFPrrwIg5669HCqnW47p7jxTG2W2gvFuFmxhnONU1qzRzIOK4YClvIrIa_csmU0hUC Bjki0IBt3c10m8_hbRmq7vCM5w4Km9zZsml6M3yc8nzQvMr.CabTr9TTn8IHl32OsK9Z2KqdPUI1 OGSO4LGJlxdxo0QP_pttj2IlGhxiWdyEX60oo5nifimDqa9qiSjeCVne47Yg7iFtqdp4SvwH1sdl EGZzCQ4pqCLrCkyY6pg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 20 Apr 2022 06:03:38 +0000 Received: by hermes--canary-production-bf1-7cfdddd556-6zdns (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 7b83a2b350218e0adc689f0ebd3aae2e; Wed, 20 Apr 2022 06:03:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Message-Id: Date: Tue, 19 Apr 2022 23:03:33 -0700 Cc: jbo@insane.engineer To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4KjqqP64F1z51jq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hL867lsY; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.32:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.32:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Joerg Sonnenberger wrote on Tue, 19 Apr 2022 21:49:44 UTC : > Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb jbo@insane.engineer: >> > After some research I seem to understand that the way that RTTI is = handled over shared library boundaries is different between GCC and = LLVM. >>=20 > I think you are running into the old problem that GCC thinks comparing > types by name makes sense where as everyone else compares types by = type > pointer identity. Seems out of date for the GCC information . . . https://gcc.gnu.org/faq.html#dso reports: QUOTE The new C++ ABI in the GCC 3.0 series uses address comparisons, rather = than string compares, to determine type equality. END QUOTE > GCC is glaringly wrong because types with identical > names can and often are unrelated. This is especially a problem for > plugins. The correct way to deal with it is making sure that every = type > has a key function of appropiate visibility and making sure that the > interface library exports them and every plugin links against it. > If you do that, dlopen without RTLD_GLOBAL or linking the main program > without -rdynamic works fine. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 20 09:12:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D59B211E2F24 for ; Wed, 20 Apr 2022 09:12:32 +0000 (UTC) (envelope-from tijl@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 4Kjw1D5nV7z3qQ7; Wed, 20 Apr 2022 09:12:32 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650445952; h=from:from:reply-to:subject:subject:date:date: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=qhnRJeUo04a3/3CAcPlD1mMDd+GJUOyewjl31IaX0ss=; b=FKDmT9xB7aQ06pxxIe5OBFPyrsmoontywfafPO+IuY7K1qw6yFzqrvfVcXPXiS+Imu88uP ioCpQsQth9QvUe35U54t07aTL9nvdxC0LRLhQ3nrs6gFnrj3pw9Hc0wxLGEg7hd4sxyJhf p85WIDiNXcMR+rFKnBdxIKcL4xaPr3KYHg8wE2evXRySEy1on/4zqykhy523r2SaFTMK1r 57m1u/55CLX63q0RIs58smOqFN5CjUhlCS/dI+l9sv0E8n5jQbdKMc0d1Vhr8If+4Cg3tk 3k3ksTeoBIEyL+P/PzCA13teycpVK6xjJ+0bMg3aypDf6no2/5+MEsUwAR5Acw== Received: from localhost (unknown [IPv6:2a02:a03f:894b:4700:2027:3123:4dd2:95df]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 45D3F239B8; Wed, 20 Apr 2022 09:12:32 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Wed, 20 Apr 2022 11:12:29 +0200 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Michael Wayne Cc: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220420111229.36de494f@FreeBSD.org> In-Reply-To: <20220418173333.GC72471@post.wayne47.com> References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/=QnV_61ajZ/4x58KPu69/l8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650445952; h=from:from:reply-to:subject:subject:date:date: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=qhnRJeUo04a3/3CAcPlD1mMDd+GJUOyewjl31IaX0ss=; b=yCpYygTiy0GYSR1bsAOINuae36ucJ7Nc+w4VFZ4ScFfxDMfgfEsCEDOmWtWlnqj+Qi5eu2 fMwddLo9MicA+EH4kPk6NEJdc/c5Q117RQDPwaZCGq+OlJci+Uy1l4frhAfD+FiH4s2E70 Cz7ra+gGlrq+BHe7W6OPIy08M3uAqpMBTRyvEdY1xG+oztmzDbuLXN9YdOWa4tVbQwlvex SV5rEwBGuNDH/HVdS+dQXkK74bofmOIcePmi/SQCyrr0XErjxovZoOP6hHnBpkxVA+PmSc daGr5Y4fx0LiPPtBCQx5l0R/SdOmb27tnt+Mn1JbOla3sDmtPT/IE9SkO6Ekjg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650445952; a=rsa-sha256; cv=none; b=O0eB4KKnyNqybG1RhXskbQ0wkF+Xz/s8Qd+a1R4cnNPeWWJCC9XCknBO2kTaH6yD0dMS2a F0TpcGIzOfE9yccW8P34S++q0+DyWQHIRxvoetL6VLy5yMmVPXDr0Q5mIUMvYzAYbksl/c AUJkYgZDb24Yby1d35BRszMxSTVOJFGn05PVkZjWLUZ3k56jVx9/Gyw6BNONBchdpPxfbs 9df6VKt6PpucnGeeVgIrfSDcehdTX3SH8QDaJJQ53M6QdHJ8NnqxrVN2KcUVBrG0xpP8Zq hBH0jB3pmT7glqRRjHcfwG6PQiKrK7/Lrty4b7toxfJ6vEUHgju+nFi1AtmJ/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --MP_/=QnV_61ajZ/4x58KPu69/l8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Mon, 18 Apr 2022 13:33:33 -0400 Michael Wayne wrote: > On Fri, Apr 15, 2022 at 01:49:53PM -0400, Michael Wayne wrote: >> I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 >> >> I'm trying to upgrade the machine to 12.3 and having swap failures. > > I tried a number of things, all of which failed. > > Since the offending line is: > >> ctfmerge -L VERSION -g -o kernel.full ... > > I went digging through makefiles and found: > MK_CTF=no > > Adding this to the command line permitted the build to complete and > the machine is now running on the new kernel. Hopefully this helps > others. I'm still not sure why the kernel refused to use swap but > this is a very easy to duplicate issue. How many CPU cores does the VM have? Can you still reproduce it now that you run 12.3? If so, can you try the attached patch? It prevents background laundering when nfreed == 0, restoring some behaviour from before https://cgit.freebsd.org/src/commit/?id=c098768e4dad and https://cgit.freebsd.org/src/commit/?id=60684862588f. --MP_/=QnV_61ajZ/4x58KPu69/l8 Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=vm_pageout_worker.patch diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index 36d5f3275800..df827af3075f 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) nclean = vmd->vmd_free_count + vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt; ndirty = vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt; - if (target == 0 && ndirty * isqrt(howmany(nfreed + 1, + if (target == 0 && ndirty * isqrt(howmany(nfreed, vmd->vmd_free_target - vmd->vmd_free_min)) >= nclean) { target = vmd->vmd_background_launder_target; } --MP_/=QnV_61ajZ/4x58KPu69/l8-- From nobody Thu Apr 21 14:24:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7001B11DFEEE for ; Thu, 21 Apr 2022 14:24:26 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kkftd0pwWz4lh4 for ; Thu, 21 Apr 2022 14:24:24 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 63527376174B for ; Thu, 21 Apr 2022 16:24:18 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 4C55B376053A for ; Thu, 21 Apr 2022 16:24:18 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 work.stormshield.eu 4C55B376053A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE; t=1650551058; bh=oPIO18A6ZKyUfJvkuy5gHCM2Qasub+8mqEYzt9qXsvY=; h=From:To:Date:Message-ID:MIME-Version; b=SC4d4ANjdYY1R+nhxtHH1AtimIv8WD08ENnSeYBr+m8WmPDk13vyLKN+ifeLjXkab 56kY/dRRu8OQgkoBRcmwlWjwxlDMNeh9iHsYW9VrJl7/MwDnWBZfa4w3B55DA3h6jv hBMG7vuwBigKuGnn+pQyk0PCagx3Jz1IwSuq9RPU= Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dPfRI6T4K4tV for ; Thu, 21 Apr 2022 16:24:18 +0200 (CEST) Received: from cthulhu.stephaner.labo.int (unknown [10.2.16.1]) by work.stormshield.eu (Postfix) with ESMTPSA id 36EAF376174B for ; Thu, 21 Apr 2022 16:24:18 +0200 (CEST) Received: by cthulhu.stephaner.labo.int (Postfix, from userid 1000) id 266E11FDBB; Thu, 21 Apr 2022 16:24:18 +0200 (CEST) User-agent: mu4e 1.2.0; emacs 27.1 From: stephane rochoy To: FreeBSD Hackers Subject: vwarn: libc vs opensolaris/ctf/tools Date: Thu, 21 Apr 2022 16:24:18 +0200 Message-ID: <874k2mzf8t.fsf@stormshield.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Kkftd0pwWz4lh4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE header.b=SC4d4ANj; dmarc=pass (policy=quarantine) header.from=stormshield.eu; spf=pass (mx1.freebsd.org: domain of stephane.rochoy@stormshield.eu designates 91.212.116.1 as permitted sender) smtp.mailfrom=stephane.rochoy@stormshield.eu X-Spamd-Result: default: False [-3.76 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.1]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.86)[-0.863]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, Trying to build stable/13 [1] (for ARMv6) if encountered the following linker error when building cddl/user.bin/ctfdump. ld: error: duplicate symbol: vwarn >>> defined at utils.c >>> utils.o:(vwarn) >>> defined at err.c:148 (/usr/src/lib/libc/gen/err.c:148) >>> err.o:(.text+0x4D0) in archive /usr/lib/libc.a cc: error: linker command failed with exit code 1 (use -v to=20 see invocation) The vwarn function seems to be defined both in lib/libc/gen/err.c and in cddl/contrib/opensolaris/tools/ctf/common/utils.c. It seems to be ok to workaround the problem by enclosing OpenSolaris' implementation in #if 0. I don't see anything related in my src.conf: TARGET=3Darm TARGET_ARCH=3Darmv6 TARGET_CPUARCH=3Darm TARGET_CPUTYPE=3Darmv6softfp =20=20=20=20 DESTDIR=3D/home/stephaner/c/freebsd/dest KERNCONF=3DARMADA38X METALOG=3D/home/stephaner/c/freebsd/dest/METALOG =20=20=20=20 # Jan 1, 2030 00:00:00 BUILD_UTC=3D1893452400 DB_FROM_SRC=3D1 NO_FSCHG=3D1 NO_ROOT=3D1 NO_SHARED=3D1 NO_RTLD=3D1 =20=20=20=20 WITHOUT_BEARSSL=3D1 WITHOUT_BLUETOOTH=3D1 WITHOUT_CAPSICUM=3D1 WITHOUT_CASPER=3D1 WITHOUT_CFI=3D1 WITHOUT_CLEAN=3D1 WITHOUT_DEBUG_FILES=3D1 WITHOUT_DICT=3D1 WITHOUT_GAMES=3D1 WITHOUT_GROFF=3D1 WITHOUT_KERBEROS=3D1 WITHOUT_LIB32=3D1 WITHOUT_LLVM_TARGET_ALL=3D1 WITHOUT_LOADER_VERIEXEC=3D1 WITHOUT_MAIL=3D1 WITHOUT_NLS=3D1 WITHOUT_OFED=3D1 WITHOUT_PROFILE=3D1 WITHOUT_SAFESTACK=3D1 WITHOUT_TESTS=3D1 WITHOUT_VERIEXEC=3D1 WITHOUT_WARNS=3D1 WITHOUT_WERROR=3D1 WITHOUT_ZFS=3D1 =20=20=20=20 WITH_BIND_NOW=3D1 WITH_CLANG=3D1 WITH_INSTALL_AS_USER=3D1 WITH_PIE=3D1 WITH_REPRODUCIBLE_BUILD=3D1 WITH_RESCUE=3D1 WITH_SHLIBRANDOM=3D1 Does anyone have a hint or any thing I could investigate? [1] dd19f0e9c006370d33b56b6d1b66015d7afd00eb Regards, --=20 St=C3=A9phane Rochoy O: Stormshield From nobody Thu Apr 21 14:44:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3610013A692D for ; Thu, 21 Apr 2022 14:44:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkgKl2xCFz4qHy for ; Thu, 21 Apr 2022 14:44:27 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x831.google.com with SMTP id fu34so3368475qtb.8 for ; Thu, 21 Apr 2022 07:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=sYvy6ZVMeT1orYx/pcbubxhaXgSTdpRbD4zWgRVqnhE=; b=cVTvIVETsXtyKaM+DBJhE9+Hguxpy12AFtZ28jlq86vOiBNUZsdofIKqn05rwFBbdJ f3Uj6YOpopl5Ph6Y4iUDbiG2fSSx++CBjIBFCsTxVyV0CxnNCuZ0iAwFwfZ5klYG32se 442f45p3rny3FCwa/yv45/CvsA5gjkXpsNPQbvOJEezANRWzCXrGgVG7ZLOjAAwmbhzj QOv7QJtgFv47mK7j621vYxuDX2UXmP/BowlZTn68Y8PPrb329zX/asjpderXWvrN4IbY pqEzItxgLlGeq7K1wYDFTJ3v5iS5veH3q9NHUg/5pfYhzDfJsQvJk1boD1ROccrl1Ewm 05ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=sYvy6ZVMeT1orYx/pcbubxhaXgSTdpRbD4zWgRVqnhE=; b=xd3GfVS6TW47I+tdSQIY7NDOes1IgZUvgjokkGHhv1PvxY5C+AjSGaBWwujehGQWru qCTSesgyGFQj6ZTSbveuH2WRkfGguO1gIYkc7PnysU6HHABInRfYyQAubGvdt459bntz jqYOrVOvD1IgXjDOaJeUz/6M6tthQUzsgbDTw/J+6uxE9bE3eZ4YD8fqeYkAtmyKdBaa G/vBzsFZmASqtAkT1euwimcS4g2XNmUDYJ74rMGugFRFMklji+VP6ZCw0OF3EWAkLEJP T2Aeizrs8g7qRQ/DQQtuNBfc+YC5y1O+QpO1Kq9SUwRi2oPy4rd+mHCpB7n/7kbZUrkU 9J1w== X-Gm-Message-State: AOAM530wb1kdyPHNM+jG10rXNxAlI0oJgA3O5GgkvgmTgMoTdzm/AncW Ohqku4wXMcSJvHcfN+a/x+D4Pk3U3II= X-Google-Smtp-Source: ABdhPJx0IR5yxKNpire3Jq0Ky3X6GgrMUKXDrtAtx5UJtlaOtaDhrZ5H5fDffwhPukjPsJm15j5LEw== X-Received: by 2002:ac8:57c9:0:b0:2e2:38d3:dcf9 with SMTP id w9-20020ac857c9000000b002e238d3dcf9mr17328149qta.169.1650552261334; Thu, 21 Apr 2022 07:44:21 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id b13-20020ac85bcd000000b002e06856b04fsm3809240qtb.51.2022.04.21.07.44.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 07:44:20 -0700 (PDT) Date: Thu, 21 Apr 2022 10:44:17 -0400 From: Mark Johnston To: stephane rochoy Cc: FreeBSD Hackers Subject: Re: vwarn: libc vs opensolaris/ctf/tools Message-ID: References: <874k2mzf8t.fsf@stormshield.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <874k2mzf8t.fsf@stormshield.eu> X-Rspamd-Queue-Id: 4KkgKl2xCFz4qHy X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cVTvIVET; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::831 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [1.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.82)[-0.819]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.87)[0.867]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.68)[0.681]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 21, 2022 at 04:24:18PM +0200, stephane rochoy wrote: > Hello, > > Trying to build stable/13 [1] (for ARMv6) if encountered the > following linker error when building cddl/user.bin/ctfdump. > > ld: error: duplicate symbol: vwarn > >>> defined at utils.c > >>> utils.o:(vwarn) > >>> defined at err.c:148 (/usr/src/lib/libc/gen/err.c:148) > >>> err.o:(.text+0x4D0) in archive /usr/lib/libc.a > cc: error: linker command failed with exit code 1 (use -v to > see invocation) > > The vwarn function seems to be defined both in lib/libc/gen/err.c > and in cddl/contrib/opensolaris/tools/ctf/common/utils.c. It seems > to be ok to workaround the problem by enclosing OpenSolaris' > implementation in #if 0. I think that'd be fine. We can remove it outright. Your build is statically linking ctfdump, due to the use of NO_SHARED. I can reproduce the failure locally, but as far as I can tell the problem has been there for a long time. > I don't see anything related in my src.conf: > > TARGET=arm > TARGET_ARCH=armv6 > TARGET_CPUARCH=arm > TARGET_CPUTYPE=armv6softfp > > DESTDIR=/home/stephaner/c/freebsd/dest > KERNCONF=ARMADA38X > METALOG=/home/stephaner/c/freebsd/dest/METALOG > > # Jan 1, 2030 00:00:00 > BUILD_UTC=1893452400 > DB_FROM_SRC=1 > NO_FSCHG=1 > NO_ROOT=1 > NO_SHARED=1 > NO_RTLD=1 > > WITHOUT_BEARSSL=1 > WITHOUT_BLUETOOTH=1 > WITHOUT_CAPSICUM=1 > WITHOUT_CASPER=1 > WITHOUT_CFI=1 > WITHOUT_CLEAN=1 > WITHOUT_DEBUG_FILES=1 > WITHOUT_DICT=1 > WITHOUT_GAMES=1 > WITHOUT_GROFF=1 > WITHOUT_KERBEROS=1 > WITHOUT_LIB32=1 > WITHOUT_LLVM_TARGET_ALL=1 > WITHOUT_LOADER_VERIEXEC=1 > WITHOUT_MAIL=1 > WITHOUT_NLS=1 > WITHOUT_OFED=1 > WITHOUT_PROFILE=1 > WITHOUT_SAFESTACK=1 > WITHOUT_TESTS=1 > WITHOUT_VERIEXEC=1 > WITHOUT_WARNS=1 > WITHOUT_WERROR=1 > WITHOUT_ZFS=1 > > WITH_BIND_NOW=1 > WITH_CLANG=1 > WITH_INSTALL_AS_USER=1 > WITH_PIE=1 > WITH_REPRODUCIBLE_BUILD=1 > WITH_RESCUE=1 > WITH_SHLIBRANDOM=1 What is WITH_SHLIBRANDOM? > > Does anyone have a hint or any thing I could investigate? > > [1] dd19f0e9c006370d33b56b6d1b66015d7afd00eb > > Regards, > -- > Stéphane Rochoy > O: Stormshield > From nobody Thu Apr 21 14:57:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 51777198A029 for ; Thu, 21 Apr 2022 14:57:25 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kkgch2NS1z4sxH; Thu, 21 Apr 2022 14:57:24 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 9A49F3761080; Thu, 21 Apr 2022 16:57:23 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 82187376112B; Thu, 21 Apr 2022 16:57:23 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 work.stormshield.eu 82187376112B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE; t=1650553043; bh=TxC78kyPaiM7GFHF5wMk7luwHM8SAKiFP07Us127euU=; h=From:To:Date:Message-ID:MIME-Version; b=JN6d5Vo3McWCFIoLa9HCNflWkjiyRaA+Y3ztb/PgGZJlTPgG4YoF0W8JNI5keHiht nJ7HaW/a+uyJuFl0+zAFitCw1XmouU7FLkECusCIMB3NA7qzH9otY+YV4aKe9Esg02 Wdcp9ULgftxbYfYUB17nc6qiUcafeomxq32SMlvw= Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m1vpXwN-LmQL; Thu, 21 Apr 2022 16:57:23 +0200 (CEST) Received: from cthulhu.stephaner.labo.int (unknown [10.2.16.1]) by work.stormshield.eu (Postfix) with ESMTPSA id 6EDCA3761080; Thu, 21 Apr 2022 16:57:23 +0200 (CEST) Received: by cthulhu.stephaner.labo.int (Postfix, from userid 1000) id 6C4771FDBB; Thu, 21 Apr 2022 16:57:13 +0200 (CEST) References: <874k2mzf8t.fsf@stormshield.eu> User-agent: mu4e 1.2.0; emacs 27.1 From: stephane rochoy To: Mark Johnston Cc: stephane rochoy , FreeBSD Hackers Subject: Re: vwarn: libc vs opensolaris/ctf/tools In-reply-to: Date: Thu, 21 Apr 2022 16:57:13 +0200 Message-ID: <8735i6zdpy.fsf@stormshield.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Kkgch2NS1z4sxH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE header.b=JN6d5Vo3; dmarc=pass (policy=quarantine) header.from=stormshield.eu; spf=pass (mx1.freebsd.org: domain of stephane.rochoy@stormshield.eu designates 91.212.116.1 as permitted sender) smtp.mailfrom=stephane.rochoy@stormshield.eu X-Spamd-Result: default: False [-1.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.1:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.74)[0.738]; NEURAL_SPAM_MEDIUM(0.14)[0.140]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Mark Johnston writes: > On Thu, Apr 21, 2022 at 04:24:18PM +0200, stephane rochoy wrote: >> The vwarn function seems to be defined both in=20 >> lib/libc/gen/err.c >> and in cddl/contrib/opensolaris/tools/ctf/common/utils.c. It=20 >> seems >> to be ok to workaround the problem by enclosing OpenSolaris' >> implementation in #if 0. > > I think that'd be fine. We can remove it outright. > > Your build is statically linking ctfdump, due to the use of=20 > NO_SHARED. > I can reproduce the failure locally, but as far as I can tell=20 > the > problem has been there for a long time. Ok, got it. >> WITH_SHLIBRANDOM=3D1 > > What is WITH_SHLIBRANDOM? A feature borrowed from HardenedBSD. You would be right to suspect my src.conf need some cleanup ;) Anyway, thanks for the (lighthning fast) answer Mark! Regards, --=20 St=C3=A9phane Rochoy O: Stormshield From nobody Thu Apr 21 15:27:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2E9531994541 for ; Thu, 21 Apr 2022 15:27:24 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KkhHH3Fztz3Jg7 for ; Thu, 21 Apr 2022 15:27:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x730.google.com with SMTP id 204so3786755qkg.5 for ; Thu, 21 Apr 2022 08:27:23 -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=YENG5fKwExM2OtPoASQ0ogJh7iNWjNqNl9cmBZ4pI1o=; b=euRjtlw4BVhAwEl5XX3C/bDpMkJBIGrLOdsnS6G1HEZkaIPvqTtLj6UtyOcCmsV75D izIZywZmfkR02s5jzqX+CkcpnREOR9zB6jgmBl7UTEgqeX2fKApB4Uc1oSsRlL90S0Zv T6CqWGie61ja32DZrTArzp/Ye6dpBy6vXZBEmavQ/B1Tl72Q1Pm4OORWLzI7XLuojXEZ SQ7onyHJPV4Sx1GCE1PVcZLhKE3fVz89Q3MS2jjhHburugIL68qVUvWb5wxuQqAMoo1B H/ujlcGssxFN/vBg4SVRxHTNOmckliPggrW+BIXMr6uidsShF3o1D9aNRUUvkZ/Ow03u OQUw== 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=YENG5fKwExM2OtPoASQ0ogJh7iNWjNqNl9cmBZ4pI1o=; b=HuYMJWTf48Mq5H7EFcLQohjY2KVB+4jBstNFZ0zGhzl3JHrU7eBkmJ2cR8K8W9AzVV 5Gyr2fJ9W+wU2Q2kgqRwdvJ2ZDx2hr4TDq/WsHIAMBzhVVmZ6J/8GrIVpeXzyd2qsLRq J886ChUG2knLa+djsnADjuADS+xq3picINcZ+tjivnxaHwqg1TjL/R12J1HnGGnMl11s OPnGxDWS9sKB7z1QyyD2mWwoONDQKwxmD2k5492ceCBlKB7ST+Qw24UPFSwqh8m/zJnm zBcazmBpxsC747ceekLtUvsxJZcddY00/+xf/1Ks+JVpeGLQ/siC4fd6cbmTOwYjMX3n k05Q== X-Gm-Message-State: AOAM530kUg+XhKLgIviDvVpoSuSnM3BAM+mgaswUvUES2xU8tmyKWlF4 LNiUJR8njOAYzX9CSUUR2+jS8Hheznk= X-Google-Smtp-Source: ABdhPJxxQkP6VFBkr6MsM7N4Y1nAy8Gjk1IeHcW61hLxPydQ2xFHlVQ2z1M6Y7F8AnC1eldA6/TMQw== X-Received: by 2002:a05:620a:24ca:b0:69e:c8ac:ac16 with SMTP id m10-20020a05620a24ca00b0069ec8acac16mr7545152qkn.89.1650554842992; Thu, 21 Apr 2022 08:27:22 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id b9-20020a05620a0f8900b0069e84c5352asm2909185qkn.47.2022.04.21.08.27.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 08:27:22 -0700 (PDT) Date: Thu, 21 Apr 2022 11:27:20 -0400 From: Mark Johnston To: stephane rochoy Cc: FreeBSD Hackers Subject: Re: vwarn: libc vs opensolaris/ctf/tools Message-ID: References: <874k2mzf8t.fsf@stormshield.eu> <8735i6zdpy.fsf@stormshield.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8735i6zdpy.fsf@stormshield.eu> X-Rspamd-Queue-Id: 4KkhHH3Fztz3Jg7 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=euRjtlw4; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::730 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [0.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.992]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.80)[0.801]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.58)[0.577]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 21, 2022 at 04:57:13PM +0200, stephane rochoy wrote: > > Mark Johnston writes: > > > On Thu, Apr 21, 2022 at 04:24:18PM +0200, stephane rochoy wrote: > >> The vwarn function seems to be defined both in > >> lib/libc/gen/err.c > >> and in cddl/contrib/opensolaris/tools/ctf/common/utils.c. It > >> seems > >> to be ok to workaround the problem by enclosing OpenSolaris' > >> implementation in #if 0. > > > > I think that'd be fine. We can remove it outright. > > > > Your build is statically linking ctfdump, due to the use of > > NO_SHARED. > > I can reproduce the failure locally, but as far as I can tell > > the > > problem has been there for a long time. > > Ok, got it. Fixed in main now: https://cgit.FreeBSD.org/src/commit/?id=45dd2eaac379e5576f745380260470204c49beac From nobody Thu Apr 21 15:56:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 16DA211CC946 for ; Thu, 21 Apr 2022 15:56:33 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Kkhww1V1wz3QhL; Thu, 21 Apr 2022 15:56:31 +0000 (UTC) (envelope-from stephane.rochoy@stormshield.eu) Received: from work.stormshield.eu (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTPS id 21E6D3760EE4; Thu, 21 Apr 2022 17:56:31 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by work.stormshield.eu (Postfix) with ESMTP id 0B8C03761768; Thu, 21 Apr 2022 17:56:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.10.3 work.stormshield.eu 0B8C03761768 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE; t=1650556591; bh=U8nLUcT2oIftPeuToNfEGxcXaPMs60S/xQHKEXPxCAw=; h=From:To:Date:Message-ID:MIME-Version; b=JlYWfYUn1CmnfiA7CqC84pJ30anv51ttBWJI5h0Eu2vTHuwaCts8QolqU0qEj+bIu Au8X39JxJ8ffI0IA23Xu7Vewf2mCE7/+XAopi+lpQdGCLv6gisEP/fRvT7gJjCn1xl 26cXcrfaXuwfggAkhLkLuK0mIRxTdtBLAVFogxgE= Received: from work.stormshield.eu ([127.0.0.1]) by localhost (work.stormshield.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CtzJK2A1VAki; Thu, 21 Apr 2022 17:56:30 +0200 (CEST) Received: from cthulhu.stephaner.labo.int (unknown [10.2.16.1]) by work.stormshield.eu (Postfix) with ESMTPSA id ED53F3760EE4; Thu, 21 Apr 2022 17:56:30 +0200 (CEST) Received: by cthulhu.stephaner.labo.int (Postfix, from userid 1000) id EEAA01FDBB; Thu, 21 Apr 2022 17:56:30 +0200 (CEST) References: <874k2mzf8t.fsf@stormshield.eu> <8735i6zdpy.fsf@stormshield.eu> User-agent: mu4e 1.2.0; emacs 27.1 From: stephane rochoy To: Mark Johnston Cc: stephane rochoy , FreeBSD Hackers Subject: Re: vwarn: libc vs opensolaris/ctf/tools In-reply-to: Date: Thu, 21 Apr 2022 17:56:30 +0200 Message-ID: <871qxqzaz5.fsf@stormshield.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Kkhww1V1wz3QhL X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE header.b=JlYWfYUn; dmarc=pass (policy=quarantine) header.from=stormshield.eu; spf=pass (mx1.freebsd.org: domain of stephane.rochoy@stormshield.eu designates 91.212.116.1 as permitted sender) smtp.mailfrom=stephane.rochoy@stormshield.eu X-Spamd-Result: default: False [-0.81 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=5EC8D4C2-228B-11EC-A8BC-C05B4988C3CE]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.70)[0.698]; NEURAL_SPAM_MEDIUM(0.40)[0.396]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Mark Johnston writes: > On Thu, Apr 21, 2022 at 04:57:13PM +0200, stephane rochoy wrote: >>=20 >> Mark Johnston writes: >>=20 >> > On Thu, Apr 21, 2022 at 04:24:18PM +0200, stephane rochoy=20 >> > wrote: >> >> The vwarn function seems to be defined both in=20 >> >> lib/libc/gen/err.c >> >> and in cddl/contrib/opensolaris/tools/ctf/common/utils.c. It=20 >> >> seems >> >> to be ok to workaround the problem by enclosing OpenSolaris' >> >> implementation in #if 0. >> > >> > I think that'd be fine. We can remove it outright. >> > >> > Your build is statically linking ctfdump, due to the use of=20 >> > NO_SHARED. >> > I can reproduce the failure locally, but as far as I can tell=20 >> > the >> > problem has been there for a long time. >>=20 >> Ok, got it. > > Fixed in main now: > https://cgit.FreeBSD.org/src/commit/?id=3D45dd2eaac379e5576f7453802604702= 04c49beac I confirm it's ok for me too. Thanks again :) Regards, --=20 St=C3=A9phane Rochoy O: Stormshield From nobody Sat Apr 23 17:36:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AF9C51A8920B for ; Sat, 23 Apr 2022 17:36:25 +0000 (UTC) (envelope-from leres@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 4Klz3F4dW3z3n5y for ; Sat, 23 Apr 2022 17:36:25 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650735385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZUiNAGRfCQvPt5OhWY9iZoWNDCx4ePssEM46C5pAJ0Y=; b=UZFxKfCIB7eekypGWulvFI55d/Ecj9u4aN2GRNYWZ2HbJqn8XiW4ptLMolFPPLks4RKi3K T5Rvlnyq7RVYSPD0jGcLI3gJdrHThGvzpbZKHVoMXbFAA3OLOsODpN9qH3ExFCqKCXwwyC Rqvq2rY3Bes3vwla1D/5q6tleLSvGAEo02aTMBT2/5a+XLICgOqewVnDgzkWz1f9sgohYS aqKdv8tLk5Ca8Zzx3hKAoQXt6L6L2lZwAyleP9FYDhphPGDFrasxqUeKioi/dLmt450oeY JOt41gsxbwUm5bZLMUV29O/y4gvcF15HhKFq84rpoasR5m+VUblLJyGRXjJQOQ== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E95927390 for ; Sat, 23 Apr 2022 17:36:25 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <9af51349-745f-49a1-fada-97f0b665f7f8@freebsd.org> Date: Sat, 23 Apr 2022 10:36:24 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US From: Craig Leres To: freebsd-hackers@freebsd.org Subject: Cannot reproduce pkg-fallout failure Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650735385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ZUiNAGRfCQvPt5OhWY9iZoWNDCx4ePssEM46C5pAJ0Y=; b=BVsXwwKwoCkiaVDvD1oeDGhm9Is1qJo6A9YpYNKl0+IpGO8jhLQirdz6/gX6Ae7pEtyhch F4+jXI6lXgx+G41HSDEEjI0xZgBz/dlUH4Dwx0tO6gozElNcWvk6a0tB7dpKb7NZOQazMd CxERr4noVwwgLsII/1JgCnYvHd2ypfYRS+VK9zxJDlGAqZONa1WSzVz9BoZN+2AuPBy+fw oyi8T7egBwRZ1LtWLo8JA5MkxnAkkd+1pLR40PhTaY390bCbSaOAqNQu78ipTeo6+HVBKU TChPO3/i3YxOnkQGv4ydYNqhda1jXFDXbZbDDpCa6LcC0AWi8M7Z/VmFVthBeA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650735385; a=rsa-sha256; cv=none; b=nc73d42MaxBWitbZV4MxhUIqiEO/8Og5fjJvFvkFRgZkG7OYrpJz0ybeA9e8MCIXlO1ZLg ml+RWb4nlVEash3J1OMJbw1+5ly6ovv74/kTY4dZREoTvzNa0MccIVylngAFssz8aBJhaj 06TNODo2hpNVys4IyzXZ/jVoNejLNMhJNOO/YsouIOx+Prws5rkZqNb5KVxyl63JaUmUOL 2LRgm49QZW8oHQ82+oP0VXyFobbdxYhFgw2R+LSRiTafxIYeW9KaDZAco2OBAryOkV+T2e LKN5hqGK9KCQPIXrgKtWdxO4qc2+j5ToyXbZPfZ84eeIc5OGdqYDsHKYN+mgFg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Since early this month (about two weeks after upgrading to 10.1.0.1) pkg-fallout has been complaining about net-mgmt/check_nwc_health for 123amd64. However I cannot get the build to fail on my own 12.3-RELEASE/amd64 poudriere build server. The error comes from a subst script: /usr/bin/awk: illegal repetition expression: class ^#! ?\/.*\/[a-z]{0,2 source line number 44 source file ./subst context is /^#! ?\/.*\/[a-z]{0,2}awk/ {sub(/^#! ?\/.*\/[a-z]{0,2}awk/,"#! >>> /usr/bin/awk") <<< ;} *** Error code 2 Line 44 looks (of the /usr/bin/awk shebang script) like this: /^#! ?\/.*\/[a-z]{0,2}awk/ {sub(/^#! ?\/.*\/[a-z]{0,2}awk/,"#! /usr/bin/awk");} The port has no options. The differences between 10.0.0.2 and 10.1.0.1 are small (~100 lines) and are limited to about half version number changes and half perl code changes; nothing related to assembling the script for installation has changed. I thought maybe the regex was getting truncated but haven't been able to reproduce the error by shortening it. There are four places in "one-true-awk" that print this error and you have to do something to the bound specification like make it empty ({}), make n > m, double the comma, or include a character that's not a digit or comma. Does anyone see the problem? Craig From nobody Sat Apr 23 18:12:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 291F6199103C for ; Sat, 23 Apr 2022 18:12:54 +0000 (UTC) (envelope-from leres@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 4KlzsL0b4Cz3rgq; Sat, 23 Apr 2022 18:12:54 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650737574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3NrkFG0NojS+UXR6ROUnUlHrQ32aolBcwqIr/N5RiVQ=; b=BT6fzU279xQRNH2AXEttXgADU+D9NOLeWvWdto8C0uiJRFRbhlsUiM3BjaUpuD0rwcxSwk tYcRyzwCxg4wa/k86x2N4j+ja+hnRcqoUjr33SZ3WvTVya/adc5HuTHWHvZbqYhTYB+7dQ 1QWCAuaVuvinMFyR9wu/qw/eeZ0exQ3hQt/5aCgpSikA6jGIhsWF8QNm1lMlFSDxDX8Ebm Q862StagHB8nKtUwhFa+U92Wxwty4agfOc4sv7/CPOaQK8J3Ih9DbazzqMH61D992uglZu j330GrV58Ld3UvDMB0mUtFbUlaKm/2GQcdJA0bwpiwwXCJLNhbScTutG0bXKZg== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id A6E902785C; Sat, 23 Apr 2022 18:12:53 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> Date: Sat, 23 Apr 2022 11:12:52 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: kernel crash making a vlan on a wlan Content-Language: en-US To: Jeff Anton , freebsd-hackers@freebsd.org References: From: Craig Leres In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650737574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3NrkFG0NojS+UXR6ROUnUlHrQ32aolBcwqIr/N5RiVQ=; b=IGlwOb+snD+TvUClT33w9K68eQeATOqpRVF9Nh5Y+/7hoZIyNeGixZtBBUVo/i+RNvU9pu V+UMUVkLI26FycwYc8It3iNCmLz4lRqgjjAa2Xt7X03HAs+Pkxk0RazFOtDBfkBdOQ6muU 2CQJI3gW8KdmKzLSGBXuaxi3eF8tL8BYkqNkeYWLx8/JHTBMH5ws8/gW/o2UCGMpbjyvlQ oEI4D+nnBKlE9BllKnJ8cdTJVPSdw9WZtKEH3S0Ma0mx69tWfwTBsR8Tq1TR58z0YIUDev fWiDSO+jfwC4RDgjUye+AXY7IasoKMqcqwV40Jp8KUZ7jXLylXPNqCJKL9Yykw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650737574; a=rsa-sha256; cv=none; b=N5SbRKUtFYOCdMj+9kOZtkB1Pmb2RHXekoY3BsDYw0FHTI5QN7H0cs3tW7X1a831s0eCSx /M70/SSwuFMWtR6FtB4a3RlPwDtOa1u3QuNp5vlzNLybZiL1AW7fdl/QB3Kp40oy3zlt06 4IE6NvC2/2WXj98Zet9chWSFfAC1x2i721XGqgQXwfiWSuras4Zzk28T5YclzOswn1sGcY R0TQ6GiCTlnFb+tNTlXJxbzjbpBxm93/J2wtE2rTSiw6mZpC9eUVDGXrWrJl5HbtYXcz3Y 7u3EqseS2iKExlCkM2WJSwAPC1ijFZry7qRZgXrDW9T/GNtbRuuUfeQM7g4ZVg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 4/19/22 10:46, Jeff Anton wrote: > A few days ago I tried setting up a vlan for a wlan on a non-critical > 13.0 amd64 (Atom processor) machine and it crashed hard. And because I > set it up in the rc.conf it loop crashed and eventually would not boot > and standalone fsck could not repair the filesystem and it would not > even get past the btx loader so that machine is out of action. It was > taking kernel dumps but to the same corrupt root fs. Sigh. > > What I can remember from the crash report was the process was ifconfig > and there were calls to like wlan_ioctl and other ioctl's on the stack. > > I probably set something like the following in rc.conf > > vlans_wlan0="vlan0" > create_args_vlan0="vlan 1234" > ifconfig_vlan0="inet 192.168.2.3" > static_routes="mcast" > route_mcast="-net 224.0.0.0/4 -iface vlan0" > > Anyone want to risk attempting recreation while I rebuild my now dead > machine? I am able to reproduce the crash with 13.1-RC4. I did an install on a spare SSD and put it in a foxconn nt-510. With the appended rc.conf (and an appropriate wpa_supplicant.conf for my wifi) the system boots up and can talk to the network. All it takes to crash it is to run: ifconfig vlan0 192.168.1.1 I also appended the stack trace from /var/log/messages. Craig ============================== hostname="test.alameda.xse.com" sshd_enable="YES" dumpdev="AUTO" keymap="us.ctrl" wlans_iwn0="wlan0" ifconfig_wlan0="WPA SYNCDHCP" vlans_wlan0="vlan0" create_args_vlan0="vlan 1234" wpa_supplicant="YES" ============================== Apr 22 11:03:09 test kernel: Fatal trap 12: page fault while in kernel mode Apr 22 11:03:09 test kernel: cpuid = 0; apic id = 00 Apr 22 11:03:09 test kernel: fault virtual address = 0x0 Apr 22 11:03:09 test kernel: fault code = supervisor read instruction, page not present Apr 22 11:03:09 test kernel: instruction pointer = 0x20:0x0 Apr 22 11:03:09 test kernel: stack pointer = 0x28:0xfffffe00946589b8 Apr 22 11:03:09 test kernel: frame pointer = 0x28:0xfffffe0094658ac0 Apr 22 11:03:09 test kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Apr 22 11:03:09 test kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Apr 22 11:03:09 test kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Apr 22 11:03:09 test kernel: current process = 1404 (ifconfig) Apr 22 11:03:09 test kernel: trap number = 12 Apr 22 11:03:09 test kernel: panic: page fault Apr 22 11:03:09 test kernel: cpuid = 0 Apr 22 11:03:09 test kernel: time = 1650650520 Apr 22 11:03:09 test kernel: KDB: stack backtrace: Apr 22 11:03:09 test kernel: #0 0xffffffff80c69285 at kdb_backtrace+0x65 Apr 22 11:03:09 test kernel: #1 0xffffffff80c1b93f at vpanic+0x17f Apr 22 11:03:09 test kernel: #2 0xffffffff80c1b7b3 at panic+0x43 Apr 22 11:03:09 test kernel: #3 0xffffffff810afdf5 at trap_fatal+0x385 Apr 22 11:03:09 test kernel: #4 0xffffffff810afe4f at trap_pfault+0x4f Apr 22 11:03:09 test kernel: #5 0xffffffff81087348 at calltrap+0x8 Apr 22 11:03:09 test kernel: #6 0xffffffff80dadbfd at arp_ifinit+0x6d Apr 22 11:03:09 test kernel: #7 0xffffffff80d4192d at vlan_ioctl+0x1dd Apr 22 11:03:09 test kernel: #8 0xffffffff80db5baf at in_control+0x9bf Apr 22 11:03:09 test kernel: #9 0xffffffff80d323bd at ifioctl+0x3bd Apr 22 11:03:09 test kernel: #10 0xffffffff80c895eb at kern_ioctl+0x25b Apr 22 11:03:09 test kernel: #11 0xffffffff80c892f1 at sys_ioctl+0xf1 Apr 22 11:03:09 test kernel: #12 0xffffffff810b06ec at amd64_syscall+0x10c Apr 22 11:03:09 test kernel: #13 0xffffffff81087c5b at fast_syscall_common+0xf8 Apr 22 11:03:09 test kernel: Uptime: 11m2s Apr 22 11:03:09 test kernel: Dumping 277 out of 2005 MB:..6%..12%..24%..35%..41%..52%..64%..75%..81%..93%---<>--- From nobody Sat Apr 23 20:11:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 59F3E1A8AAD7 for ; Sat, 23 Apr 2022 20:11:47 +0000 (UTC) (envelope-from leres@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 4Km2VW26t2z4ctW; Sat, 23 Apr 2022 20:11:47 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650744707; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R9mV69P79HO5hchZEZ6W5PKClRRAl/vzPi1X0CswcR8=; b=RiW7Atx2eBW5C7/WwTNgdoWl/uFtkFS48x6vd1nVwSpDAP7UsJFP9Rs+LTLV8HHvvlhXxP HBtpB5jmWcuKTJgDraz9ce4aSRggliWsfLzO0AXrEMik9Jrwn4Uuk7z2s3avbjoiKM2ir4 szO2fdKuxN/4BNMuhztl0UFBmxqnCXv/Ev0WECn/2OZw2l4ktQOrDcvPi2bx4sCIovcZhk SubqFu2rN/8nPIGvZWzKEPqBOJt6pvqz47enW6MG8IbEDXSbvapZxXxBjkUvHVvEc+Tava omE6qJ1u4+Ig+ECEoUFRjzdGixD6ZWeIO4cFXtjt9F6XeopnUhhP9EC0fBgb9Q== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id D2DB42863A; Sat, 23 Apr 2022 20:11:46 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> Date: Sat, 23 Apr 2022 13:11:45 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: kernel crash making a vlan on a wlan Content-Language: en-US From: Craig Leres To: Jeff Anton , freebsd-hackers@freebsd.org References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> In-Reply-To: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1650744707; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R9mV69P79HO5hchZEZ6W5PKClRRAl/vzPi1X0CswcR8=; b=k/rjCHgqPSC9xVVSFcwR3WAWzFgsPGol5wmuYI+Fdx2msJtuwQTZhtqebaajwXuMkSRF3P MH30mcRVZMdF/86uKZ/HfgdlTiNq3n/fKPXpmxoLw3lMCrI5eeQUKsY8OUbv2fd2FBvX4P Fpnt59BF4zmgVTbpZMG8Ks4AsaDzbgUBXhO1E+5k92a0m0YO8mvZ9oYfVfGfsU1fSw3N2z Hkv70GDRj3oCgKuGgoyECqeyHhF/vcAkHXJw+VgBPkJKWk5kllxdP5DgbGBhjNxZhdkA+a C6/2ilvbVf2swes0rTtpKFTph6kYymijENgQQN4iDIqrax6BlUlRAU5mqmqkvA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1650744707; a=rsa-sha256; cv=none; b=d6o+2F5f84rSThPTt1dbqhdwAbrOB3cL7wbpBBMyT5eRF6j0WSXtJofp8pipOvAVRLWqvL sHQmvetYFy4i2V7fHv+aKxMid3vZM0pNxYtNOXCIyJU2/Tv70XgEsFGnZJHfaG0QpEeyDr oUTiPDwO36wHBLIsBn+djCM/IdKFDkjCqvyyG0fZYsHOgO3P5ZYMVnfadkxm6HpD5L5jZR iahQHOzzdaW/CPTD1D92Qe1F39PN6s6c3LpJXwShUKPMOc5mFMkxHIvIE/prldBs9XCv97 hGcKR41JzTzLRu55spqVOMqdVx+vSqWC8ElLCL7iHA+YCaQulcSjePh+z+N+Yg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 4/23/22 11:12, Craig Leres wrote: > I am able to reproduce the crash with 13.1-RC4. I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not able to induce a crash. Craig From nobody Sat Apr 23 20:28:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B1DD1A8E947 for ; Sat, 23 Apr 2022 20:29:12 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Km2tb0CLBz4g2P for ; Sat, 23 Apr 2022 20:29:10 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:2d11:eea2:10d5:7b3c] ([IPv6:2001:470:71:d47:2d11:eea2:10d5:7b3c]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 23NKSxJ5042260 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 23 Apr 2022 22:29:00 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1650745740; bh=SPB7YKB+all9KG21/32you2JSnG0+383XDbmfXoxdw4=; h=Date:To:References:From:Subject:In-Reply-To; b=NTUBmm6qIgMMjdWHL1gJiMXFgTTZHam/ElYBzRXEN+kBJ1kVdjxGbk6/Kls1g+9wv NvSq3Rj4d1Ot6Iqn3U8SHNiCdrbNRJtr53xfE96AZM/r1zB/Bi8K1ROn00r0huFY+d YQGW22gO2s/LbOeZkOY0tZGBn5pIUyxUutyzt9cotm0RA2en0xHLpFccYnzvIwMOzt mdHdebJHpFDERoPa7SGefaJUCzGEehtmyBiwIqkrw473YeiMjWNdEVZ4PiZS7dz5ML S2YX60OjI7n5MltjIJhfXYYP6iuCAqpFp/VmEHX1gjt7E3CWR4DvjnP5tRDGFy6cXx /xpS26Glks0RQ== Message-ID: <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> Date: Sat, 23 Apr 2022 22:28:59 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: freebsd-hackers@freebsd.org References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> From: Marek Zarychta Subject: Re: kernel crash making a vlan on a wlan In-Reply-To: <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------izD9jqaddFDYzKmqNvJc7xIX" X-Rspamd-Queue-Id: 4Km2tb0CLBz4g2P X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=NTUBmm6q; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------izD9jqaddFDYzKmqNvJc7xIX Content-Type: multipart/mixed; boundary="------------AbVircsxRZ06vqsW0Y0mr5cB"; protected-headers="v1" From: Marek Zarychta To: freebsd-hackers@freebsd.org Message-ID: <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> Subject: Re: kernel crash making a vlan on a wlan References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> In-Reply-To: <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> --------------AbVircsxRZ06vqsW0Y0mr5cB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDIzLjA0LjIwMjIgb8KgMjI6MTEsIENyYWlnIExlcmVzIHBpc3plOg0KPiANCj4g T24gNC8yMy8yMiAxMToxMiwgQ3JhaWcgTGVyZXMgd3JvdGU6DQo+PiBJIGFtIGFibGUgdG8g cmVwcm9kdWNlIHRoZSBjcmFzaCB3aXRoIDEzLjEtUkM0Lg0KPiANCj4gSSdtIGFsc28gYWJs ZSB0byByZXByb2R1Y2UgdGhlIGNyYXNoIG9uIDEyLjMtUkVMRUFTRS1wNS4gSXQgc2VlbXMg d2xhbjAgDQo+IGlzIHBhcnQgb2YgdGhlIHJlY2lwZSwgSSB0cmllZCB2bGFuc19lbTA9InZs YW4wIiBmaXJzdCBidXQgd2FzIG5vdCBhYmxlIA0KPiB0byBpbmR1Y2UgYSBjcmFzaC4NCj4g DQo+ICDCoMKgwqDCoMKgwqDCoCBDcmFpZw0KPiANCg0KSSBhbSBjdXJpb3VzIHdoYXQgaXMg dGhpcyBXaUZpIGhhcmR3YXJlIHRoYXQgc3VwcG9ydHMgODAyLjFxIHRhZ2dpbmcgDQpvdmVy IHRoZSBhaXI/IENvdWxkIHlvdSBwbGVhc2UgcmV2ZWFsIHRoaXM/DQoNClRoYXQncyByYXRo ZXIgbm90IGEgYnVnIHdoZW4geW91IGFyZSBzaG9vdGluZyB5b3Vyc2VsZiBpbiB0aGUgZm9v dC4NCg0KLS0gDQpNYXJlayBaYXJ5Y2h0YQ0K --------------AbVircsxRZ06vqsW0Y0mr5cB-- --------------izD9jqaddFDYzKmqNvJc7xIX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmJkYYsFAwAAAAAACgkQHZW8vIFppoJ+ 7wf/UWO/fbSr15g3jI6QC0HPIXZtbw4AJwOejMQNbI/+0nzXqJaLVJahaQLMyy9oB1/Sd8Q+JImF CLo1Pzq4ME5FDCzM5rn36D1btgAAaheqARq7OD+sGJRNnJqxVYDOuML3P5ux/K54U2UpQY/9DzGM JLOw+/5HoyDaCHX8ZiqVoL/BM//iIe9bOQcYxZexKBoAKryE2x4aRXFkPgadzFF5EK2Zz+mBqV2l apNmKWtPbI5Vevtppf5nGQtO6KMqmmIwJjeHnKPz5MutjkpJQv+sL3UUJlSq5Ro2snhYv3nlLdYq gtIIRzoUfkP/K3AULzXIGWYm7ZdYseo9a4lwDwnGTg== =S79a -----END PGP SIGNATURE----- --------------izD9jqaddFDYzKmqNvJc7xIX-- From eugen@grosbein.net Sat Apr 23 21:11:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2A3DA1991D1E for ; Sat, 23 Apr 2022 21:12:31 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Km3rZ0VVBz4lmM for ; Sat, 23 Apr 2022 21:12:29 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23NLCJIC054335 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 Apr 2022 21:12:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: zarychtam@plan-b.pwste.edu.pl Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23NLBoKI059343 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 24 Apr 2022 04:12:15 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: kernel crash making a vlan on a wlan To: Marek Zarychta , freebsd-hackers@freebsd.org References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> From: Eugene Grosbein Message-ID: <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> Date: Sun, 24 Apr 2022 04:11:43 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4Km3rZ0VVBz4lmM X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [2.46 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.22)[0.223]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.46)[0.463]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.87)[0.874]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 24.04.2022 3:28, Marek Zarychta wrote: > W dniu 23.04.2022 o 22:11, Craig Leres pisze: >> >> On 4/23/22 11:12, Craig Leres wrote: >>> I am able to reproduce the crash with 13.1-RC4. >> >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not able to induce a crash. >> >> Craig >> > > I am curious what is this WiFi hardware that supports 802.1q tagging over the air? Could you please reveal this? > > That's rather not a bug when you are shooting yourself in the foot. Kernel panic due to ifconfig command is always a bug. From nobody Sat Apr 23 21:33:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8D7DB1996B4C for ; Sat, 23 Apr 2022 21:33:16 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Km4JW0QyZz4qLN for ; Sat, 23 Apr 2022 21:33:14 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id 7A193E0002 for ; Sat, 23 Apr 2022 21:33:06 +0000 (UTC) Date: Sat, 23 Apr 2022 23:33:04 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: llvm & RTTI over shared libraries Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Km4JW0QyZz4qLN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 2001:4b98:dc4:8::224) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-0.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-0.63)[-0.630]; NEURAL_SPAM_LONG(0.03)[0.026]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard: > Joerg Sonnenberger wrote on > Tue, 19 Apr 2022 21:49:44 UTC : > > > Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb jbo@insane.engineer: > >> > After some research I seem to understand that the way that RTTI is handled over shared library boundaries is different between GCC and LLVM. > >> > > I think you are running into the old problem that GCC thinks comparing > > types by name makes sense where as everyone else compares types by type > > pointer identity. > > Seems out of date for the GCC information . . . > > https://gcc.gnu.org/faq.html#dso reports: > > QUOTE > The new C++ ABI in the GCC 3.0 series uses address comparisons, rather than string compares, to determine type equality. > END QUOTE Compare that with the implementation in . Joerg From nobody Sat Apr 23 22:33:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C7CE1A84717 for ; Sat, 23 Apr 2022 22:33:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Km5dv2d6Zz3Fb8 for ; Sat, 23 Apr 2022 22:33:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753196; bh=abHDq5HRcjuc0Q6GsW5iQueA7x9lJTRmYcNxUEO77o0=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=a9+4V6n8CGgS1ogdbkMRanGTBeZLNpyoPdjai1QKZfkXT6q4sdYX9YidD88h42jG+wkN+1zU8HdnMpHZI9Oum5udAM0e2qUNm1+9Vgw3RSwd2gLVy/KBKScX7/DNPD93tjr27VrvJEsFqvQh0wHzudtC4ikFjSSmHmndU8W7MX7HeQyzxiTpunimaSLJud75m5xLXHY8YMh7AVgtCLPchtivyCc/e7Hq8LxBaUPMd1jcpX/c3nU6P/9fv8L7j9o9wQNGrKN7kfphe+mI/nGZXqeGlRf8e9n7+lvmNZ4U0A+BASZfAhd8SnVlL24xnSUdsiWbrF1CuA/oVYHRVQb+1A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753196; bh=nrRQFYVZcyl5xY7c031lO3Xf+9NFh2fGEWBaKuqOPAo=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NCnIrum2b+lDqZ8GKe+QjZ/+bLEV3QAIS0J5Qv5U6V0kI8JKa7X//V4CVoAJ5gQ0vnx2Crl/foD0rYJEte9EyW9HfqYBZhpxMv3aJq6baZhBsPGjeyGFPFt177Mx4jGEMFeBJIVZu7Y+QCl27rUqa2lQmcfcScnMvQ0+K0WOv4MqjrpatOZgEmXMpoPlvj0o0c5jYI/z2lzIPf2RX3hMd5O8/8XVxNsK7v+L3iyFlrlWsKzbhA/lFKAJWZDChyfd5D8i1NITXdugJAyZkt6JyPc3rVGhVhC6WlxbVbevs7VVopQBX576IAbnOfMoN2tvdQiEGYqHTL4rsh76CC02lA== X-YMail-OSG: hsaud_oVM1nXKvZY5zD3TvTPopB.9QxYPADhVWhSAP97j3mMajtPYWKa_9GHd4Y 61FSF4_MV1kLE7mRpuy3JnXKi6gFtjpC1mkCHJI.IyzwUTAJOWbId0mXIjGDxz89pyMxxLAcY9Fi Q2G99apJL59qEPEQy4HYJjAsqodYpfDXoLPuFVaOUjjaD86OtPXrqYBnm7VbG6SddZY4yMyiwLEa z2U.6LlW932wclznDjhGKK9yfCX_Fph6KpM9K0Rt8_WTXcCT8Jy6ujXM6K6AZ_0Yl8qL.HYvfDvV Em8vdgIqeUAhBbu3tmnrwREAC4UsbHlfLiJ3TX.8m6UtlUch5Vpgm2VVusUHVxJqLezoJkLmNxsF nS92t9vHLW1XWcpj8cWzkqGONALHAHsqbvsgVXJaUCIOSVvE.RheQLKfANCDb.MGmBmg2snoQkaF TZcMVKVFH0Oj_dw6wUQ8qdMeZmMb8.TXVgPy1tQpLtCG_m0nBt2l0_dDC6QkU3Rh5VmbUzYWYoOf eVcxMkIUCNxL7pZ_wpFlCD.UDFJvToijdgtOnJqNx64Rjft.komRu6xRuEciqGVNS7u7UQUs0ALb d1JruMKB753gKL9vHHHRAoI5JJyMwPVr9MVZT8QZzni74SJZIUe7kDDTbakNgzwT8ckrsslH8Ut5 LXKGqgRbKuKWpNFXf9REkApdKHQXIIS8uJ0.r...GWcOhLQZDAgi34CFPFi4bNIOU34L9a4AhL61 EUsmslMSN1FvMEtYTqnGcTB5Bdr.mUg.g7D0nOR2xLabPWD3KjxzuLhk8c0fAsEwV9YSllY4_YZJ ERnqDaqBWc6trC7LFvZvhA1WJA94N5csveTsXhURVkbv.sP41or9jJEOkpArnwF9.WjoiHCuVL1T tTb_zAYDKguPhyzVb5rDxnq_jeh4zmEFSFs_E6mKYAZqC4X4tUuFrmsxAjyzVGRTXstNXDrHY4XQ GOdPfQqeSMhh_JR4SXpeOANe_jr9zAEysA1PN_T1Yj2.JjNUlVmIbPQgcI2LH0bhr6aoRXIT3oTs mnHpCJ4xSZYHy1A.ic9H9JCDcRhrV94rqCMZFygvtSGr7iSWfepqo5ew8u9eTQ4CyfatbC2HnADf YxasQXku9dna_SuTrU.JecgS8dKsvC85xS.CX_yBcItpWFaKbi_TddHt6P8P9vCXllwNDKA7jtoR LFU6s2bdz3XjeeK8PWjsOnFe3F1KHx7xQsOBOFtxwBRJozXjjgjpjC1ddCaMXSbu_VdAlTht74.h Bwkb5xecbaRCx2PaPfFawgsw8DTSDe24MK.mAwm1vo1Wn6ke0DLor96Kg4L4wDeMjXP1zU1a1aZ4 X.q9vOVlN5gfP8ew8Qp8nNxqpkQC8BrXblZ0h3eEuJU__oFhbZkHpPuewvtw4WWUtYZe9KaJhhuP RX4_q9yL0oKOjj_qc3KIk0HBRr_0xZZH4QCw0uAEuH0AVTvPNeeRPK1_v4t8jOGGi9x0NB_1YAyv _OZQ4wIXGeWuyf1bB4SuTBQhSzuhvWW_QjgDDIP5Ht3Ri_LabSuVJJYI4ThvEAuCR26KXYDt3NxU .X9cI_OIsIusqaWPIb0XJT.djFVcZsIgF2qPowspkc0FZYUtWcty5IicLrH.1yrNf72Xz6tR3Miz f9JeKJI4qcjuLUdO80W0aidtVsapsydp3ekVdheijizjWhW4zoi3V5ls7jAbTB2srSI7.uzZypVu xIGPWS0P2DfxL.sPl8MCJ3HAgIL.t9Pb7gE3CtKY0tyoNFtd8bd0ykMoluuuCM1K9J1mUeTugJM9 tjhYgC2833E6GQ3SfIrV6lHeWgWDhhhDladbsPR_66YDXu8zYlv3TMG3NHToJTFQH165QPtTd041 w7zTc8A1xaGykZmZz33.ziiaYxU4hhyLs6I1FVoUbxq.GLpeKiEX9jISRmhcOXpWMYZuAfhsC5Qi .8IZZOC5bFr42UoIRVHs858olT5WHhN1JLgJpSkc9xxN5gEbvO1xVCbS03hR_IEatCKvPyp3ZgxM b4vDvRTHM5nSVlAq387whVfEZAiBk0u2qR4pa5wAUflN58XP3.6a2w2r0c4FZy6F1Kq5jZ4GhXzX uV359rBBXTcWpuHDt72gTnkIfgV8QJMVDkiU.Eolfz.XPgRy101FpptOhFYP8Xtkh63Ch2yot25N 8Og1XyC3ot6LasfJ88okDwRU5JESltuKDCkGKzCb6kCPJF9DCAMAByfJtdwJ.3UrMzNVgI_RspYY S_4XLM7I6RZNDCgKnbOpr.wRvIqsJB3ng5rkPbSJUX_VYBwV.pOKDhhK2A5avOB_wR.zbL9czaHD nhWNmeeE7VpsJ.alibsTu1MI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 22:33:16 +0000 Received: by hermes--canary-production-ne1-6855c48695-pbbz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9494d0d5c406adc99c8bd6eb8f4f752d; Sat, 23 Apr 2022 22:33:15 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Message-Id: Date: Sat, 23 Apr 2022 15:33:13 -0700 Cc: jbo@insane.engineer To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Km5dv2d6Zz3Fb8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=a9+4V6n8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.95)[-0.946]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; NEURAL_HAM_SHORT(-0.99)[-0.990]; NEURAL_SPAM_LONG(1.00)[0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N =E2=80=A2 Joerg Sonnenberger wrote on =E2=80=A2 Date: Sat, 23 Apr 2022 21:33:04 UTC : > Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard: > > Joerg Sonnenberger wrote on > > Tue, 19 Apr 2022 21:49:44 UTC : > >=20 > > > Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb = jbo@insane.engineer: > > >> > After some research I seem to understand that the way that RTTI = is handled over shared library boundaries is different between GCC and = LLVM. > > >>=20 > > > I think you are running into the old problem that GCC thinks = comparing > > > types by name makes sense where as everyone else compares types by = type > > > pointer identity. > >=20 > > Seems out of date for the GCC information . . . > >=20 > > https://gcc.gnu.org/faq.html#dso reports: > >=20 > > QUOTE > > The new C++ ABI in the GCC 3.0 series uses address comparisons, = rather than string compares, to determine type equality. > > END QUOTE >=20 > Compare that with the implementation in . Looking at /usr/local/lib/gcc11/include/c++/typeinfo I see: configurable, in part based on the intent for possible handling RTLD_LOCAL (when weak symbol are available). I'll quote the comments for reference . . . // Determine whether typeinfo names for the same type are merged (in = which // case comparison can just compare pointers) or not (in which case = strings // must be compared), and whether comparison is to be implemented inline = or // not. We used to do inline pointer comparison by default if weak = symbols // are available, but even with weak symbols sometimes names are not = merged // when objects are loaded with RTLD_LOCAL, so now we always use strcmp = by // default. For ABI compatibility, we do the strcmp inline if weak = symbols // are available, and out-of-line if not. Out-of-line pointer = comparison // is used where the object files are to be portable to multiple = systems, // some of which may not be able to use pointer comparison, but the // particular system for which libstdc++ is being built can use pointer // comparison; in particular for most ARM EABI systems, where the ABI // specifies out-of-line comparison. The compiler's target = configuration // can override the defaults by defining __GXX_TYPEINFO_EQUALITY_INLINE = to // 1 or 0 to indicate whether or not comparison is inline, and // __GXX_MERGED_TYPEINFO_NAMES to 1 or 0 to indicate whether or not = pointer // comparison can be used. So, to some extent, the details are choices in the likes of lang/gcc11 instead of an always-the-same rule for handling. Below gives some more idea of what __GXX_TYPEINFO_EQUALITY_INLINE and __GXX_MERGED_TYPEINFO_NAMES do for configuration. Is there a combination that matches FreeBSD's system clang++ related behavior? If yes, should the likes of lang/gcc11 be using that combination? #if !__GXX_TYPEINFO_EQUALITY_INLINE // In old abi, or when weak symbols are not supported, there can // be multiple instances of a type_info object for one // type. Uniqueness must use the _name value, not object address. . . . #else #if !__GXX_MERGED_TYPEINFO_NAMES . . . // Even with the new abi, on systems that support dlopen // we can run into cases where type_info names aren't merged, // so we still need to do string comparison. . . . #else // On some targets we can rely on type_info's NTBS being unique, // and therefore address comparisons are sufficient. . . . #endif #endif =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Apr 23 22:42:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8BF261A86A2F for ; Sat, 23 Apr 2022 22:42:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Km5r84MdNz3HPd for ; Sat, 23 Apr 2022 22:42:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753729; bh=Hl9r3pKAwlpUzhZ83Q+F4Rnu66hWxz2FQygpClWivqk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J1imidnJ+uJM/UOcLWC3gLFuGKD8zPII1o6Mu4FLtkXuPSw9Ny7kt+s+K8gFQnZLLIaRtEdwTLiG322xp6mRJfSWNsmjhk789Kek/9GxhlFH7Dh6r4EmLaQQUQKu+2Oagbjchn18x8t8exYuzNhVhp+PdhTvfkdOjhMoVW8yJ3/o5Wn8AsnXouTmO6JyzvF3LN9bu+wg5zpD/4iws/6ijoN8D10PQhKSCWJFdmiycA3qEIBsLDfZZ5XPO6/1A6U7LS84BGCrzMRfs7Pt476zojH6maG4pBnabMtTOkxMy/gIeWjjdHwXXEJNnjONzLDnM8wJ3iyWLyFixj3A3y2Jyw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753729; bh=G/oAj0JtbNmbybRGNikJI9c4C497ToCuskCeBioJGIp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=V+wz3XDBJBduIXeSdZQs48Rgcz/66z7SsW3LFLNcGDDNwAkL6j/Gp4CGABI/PhSMqKDxvhtP++COVC7aYLifqJPTjW0p1EEnond5vwB3nafsJJ+MFDDhUANf9ggodGu+ZLs/AGEYCgsfVNqgA4kqlZIXQalpu1pZGjvVFOcEpFYb46tUBnr1mUQtz1DkjrM0LVGfV+VlWOfEUhMYHNIF7wGVLMyP4UZk2B2uoRVNx0c12HBAe6azWJgwWRvV7ltgXpoAtofflhWCjlxp6G2dAaMmvAdanEE93wz6y88aQ21/mwTzqseX6g1m/lD+HmflC10Nc9UEadvHV6sm5StOQQ== X-YMail-OSG: NJRfDs4VM1l2HBW0j3OLKj9WicL1U_s0Hx3sI69NU1HUrz.qtCvI1iqvKpAAoBQ b1RSiqv88SwPyxieMGg3xTEOyTKLagqkdMlWuMA3RMqQU.zFodKjsW97wwCsNi4UBP.4Wma.6J.8 FSLhJizu0Th6GKYqt2B1r7HnIB3kn9Us5ZzEMIAjpI3p7Swxa4J_ebdC7j.MlE00pmKuY1uff1Ub p28Us6XGZvqbzai6b3ygdX4hTSWQgJV0yQSI81mGYZMvQs98G47uH3XM.ODR9W_dcrEFIBFzIdIP alGDY4rL8A7z9Lp9P9INK9UF_AGm6LVfx50INxaen4O.tMvcl1icn33f_naPz4zmRYXANHnsQZoK T9BDb.39IpX_YWnJsmy05kKcV.TWJ3iw5FOI8c7PtCem.KJ8S6l7WYzGdaF05Z6XLTfWYbqJSrtX 4ScP_cHgQiv25J0xbS3u3kbcRh2qcD2F78.Rm8NDnUnl3.PVVHrp6Vb9_6RUuWS7PTlIQqnQ47qh JCewFnMqJC8T7XRJr7A.Es3cvGFvEELRS_JJbjCL.ToGprH6vZvZ5SqIwiBDVEZKZG7oqM2I0_Ed zYdYV4qWVQZsetB6Vhc0zOLZunlzyeRw1wMSmu6M1jd.QtYQC_BYWIVfsZQm6WDiKO2hSI94HytQ L_OPYm2j9mG55rpI_MbIZY5bL1awp6lhLy6iRmpOqu4esl_vx7ipo5nowZILjcouzqavsu2VvTaF 9hIOwgM5U.3chPjPb0eaVXPvWvkCxa656ywk6iNhqexODwITwE4t29TRH6DjxwkQJCbmNlhfM9zO Fs.VoGnMnYtA.ql.6Qyi9kfl7ISReDHOfd8lExXKuuywt11ypwBdu1vVzshyGGyPT2BieTSnoHXO K0_OcdUXcgd03dYyEkVNMSTQmbUoAIoSs2zKYOhR0nXFbmR78gsN8tHvBzECqNSGC.zUi9KZiFwE CFMjHn9Op8VzA9J988MnZwB0457pSue194HC12zQIvqA8mIjSmj_cCekK1lj4hxETPvkfHUe1zHD qo3A1ISmSm13.pIf4jUJGiuPKt.Dx3cZJqhkX0fG4lb4FuNeYsY1RBb7W2ll82TKPO4r1d_xDr8F rO.OFtVWYx9fRlYUO4DlxWn3NhNMgd5ICwdVPsCQOhy2.uD8yNd.W2PhkOSluAjf0VMHgSwV7cmh 5SyHOSdHM9C2L4CHIz2ObCCcOOjehetf_7_jQf5LlUOp2baFNGT2VThrJ_4UOds7BoYwKj7hYsMc ITGaw7aqts0qYNlXiiCnKdrOK8xqsmmn997UD72f33vHaGjhsJFYuGFpnICJqgtl3ujmx1OYYuHs QcwxoH6Z9U2qWnpqX2X3_xuw1NW7gj_74BFMMiU3PCQCYfJ0Z6ePFLp5VKixZFs58ux4109TntUX HBzXRVAQeTtyYn3Q5f9sxvfa9yDberUTR7lazWS5W11pMD2AA_kzz0lbnomz4lBJ5kmgh93tRG9h MSzELOUsFPPiDqKhDgftuLQxTBx27VJ_mIjxZTFXBdAAzhZUcjuFu_qoeoETjoCzMaZr4IFyYfts W45EJf8AA5jDU0m8MNnFQTtoNYhEsLGQM12qJSZPdcyJS8JvZXnGL22fdyN4WAyQGqd.E7qBJyRN UUqiqCaGXdv_Two_DInCGCyhsnTfe1AZCcvRmhPx3R_GmCvqldg0OB70.NR8X1k1TKhz1BMkNSB8 dXLUNSEvxWjC7IC4ErwqEQ0BSr9Oq2r1Q5NGkptBKnEL4cIkRCCZsWE9dw81p0GfCEtX85neHGyR ROMJj6eCXefECReJBfYVFNWlIIF6yP6lWqrZDu4f35Y9sRmGOyGQCuRWyfm45QX20GuiQQ6IgUOF iDOZsJ_WxoGxmfWnglkPPOOS5GZ0okbqN11ibfpU0tQer4p2UL287dD71gj.SY1J4T53PBonJehF sooObsO5QYnp_Tcj6v4O5WNDsjkSRcjwHGKVB3zLr1gdwHgf8FHlsL7lkLoBpYIDNm9tLGrOlYAX VVeYuYNo9MsMCJDKNvUGQrkIILlNtLtwTlU84uPdMeappN_w2iqTeRO3GB_cgs0hOxkNywUNXTzD zQ0sBwp5mkXMEjk.s5oi_e9BPujhakfklqEeeHdHzhD0ShKozWtVO0yG85O9kK9knEqVC8fZlMSR M3tF_bAfORAJ3nTXvIypVidnePvCz82VpckqxApxt16jFezv1L8K4re4eleHDA5IqsfUBa2VxTND KUEbHT9pc5pjx9Af7zAf1BrcL2xKlhitcHc_VlODOFr47P7ZYmFhX3W9T8wQbVV_V5dQkrd.6cGy 6oKdroiDLdIz.jaIEP2v9 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 22:42:09 +0000 Received: by hermes--canary-production-ne1-6855c48695-qqb7f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a5857a41e83f5b6ee9e86e5c01f45cfb; Sat, 23 Apr 2022 22:42:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries From: Mark Millard In-Reply-To: Date: Sat, 23 Apr 2022 15:42:02 -0700 Cc: jbo@insane.engineer Content-Transfer-Encoding: quoted-printable Message-Id: <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com> References: To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Km5r84MdNz3HPd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=J1imidnJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_SPAM_LONG(1.00)[0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-23, at 15:33, Mark Millard wrote: > =E2=80=A2 Joerg Sonnenberger wrote on > =E2=80=A2 Date: Sat, 23 Apr 2022 21:33:04 UTC : >=20 >> Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard: >>> Joerg Sonnenberger wrote on >>> Tue, 19 Apr 2022 21:49:44 UTC : >>>=20 >>>> Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb = jbo@insane.engineer: >>>>>> After some research I seem to understand that the way that RTTI = is handled over shared library boundaries is different between GCC and = LLVM. >>>>>=20 >>>> I think you are running into the old problem that GCC thinks = comparing >>>> types by name makes sense where as everyone else compares types by = type >>>> pointer identity. >>>=20 >>> Seems out of date for the GCC information . . . >>>=20 >>> https://gcc.gnu.org/faq.html#dso reports: >>>=20 >>> QUOTE >>> The new C++ ABI in the GCC 3.0 series uses address comparisons, = rather than string compares, to determine type equality. >>> END QUOTE >>=20 >> Compare that with the implementation in . >=20 > Looking at /usr/local/lib/gcc11/include/c++/typeinfo I see: > configurable, in part based on the intent for possible > handling RTLD_LOCAL (when weak symbol are available). I'll > quote the comments for reference . . . >=20 > // Determine whether typeinfo names for the same type are merged (in = which > // case comparison can just compare pointers) or not (in which case = strings > // must be compared), and whether comparison is to be implemented = inline or > // not. We used to do inline pointer comparison by default if weak = symbols > // are available, but even with weak symbols sometimes names are not = merged > // when objects are loaded with RTLD_LOCAL, so now we always use = strcmp by > // default. For ABI compatibility, we do the strcmp inline if weak = symbols > // are available, and out-of-line if not. Out-of-line pointer = comparison > // is used where the object files are to be portable to multiple = systems, > // some of which may not be able to use pointer comparison, but the > // particular system for which libstdc++ is being built can use = pointer > // comparison; in particular for most ARM EABI systems, where the ABI > // specifies out-of-line comparison. The compiler's target = configuration > // can override the defaults by defining = __GXX_TYPEINFO_EQUALITY_INLINE to > // 1 or 0 to indicate whether or not comparison is inline, and > // __GXX_MERGED_TYPEINFO_NAMES to 1 or 0 to indicate whether or not = pointer > // comparison can be used. >=20 > So, to some extent, the details are choices in the likes of lang/gcc11 > instead of an always-the-same rule for handling. Below gives some > more idea of what __GXX_TYPEINFO_EQUALITY_INLINE and > __GXX_MERGED_TYPEINFO_NAMES do for configuration. Is there a = combination > that matches FreeBSD's system clang++ related behavior? If yes, should > the likes of lang/gcc11 be using that combination? I should have quoted a little bit more that describes the defaults used: #ifndef __GXX_MERGED_TYPEINFO_NAMES // By default, typeinfo names are not merged. #define __GXX_MERGED_TYPEINFO_NAMES 0 #endif // By default follow the old inline rules to avoid ABI changes. #ifndef __GXX_TYPEINFO_EQUALITY_INLINE #if !__GXX_WEAK__ #define __GXX_TYPEINFO_EQUALITY_INLINE 0 #else #define __GXX_TYPEINFO_EQUALITY_INLINE 1 #endif #endif . . . > #if !__GXX_TYPEINFO_EQUALITY_INLINE > // In old abi, or when weak symbols are not supported, there can > // be multiple instances of a type_info object for one > // type. Uniqueness must use the _name value, not object address. > . . . > #else > #if !__GXX_MERGED_TYPEINFO_NAMES > . . . > // Even with the new abi, on systems that support dlopen > // we can run into cases where type_info names aren't merged, > // so we still need to do string comparison. > . . . > #else > // On some targets we can rely on type_info's NTBS being unique, > // and therefore address comparisons are sufficient. > . . . > #endif > #endif >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 24 03:35:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D4A5199D3F8 for ; Sun, 24 Apr 2022 03:35:19 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmDLG2VWTz4dWd for ; Sun, 24 Apr 2022 03:35:18 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 8878BFA030C for ; Sun, 24 Apr 2022 03:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1650771317; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=83aebIjM17LiKVgj7NRenbxhBk4V5p/hxGRSc504UQE=; b=svjCe22tepLl60aYGNBrQ//bIkXE94+RCMBvAx89dt6iJwb4i2b8JMGKZH3VaHVk 1Tr0DA/dUdXW0LsH4l3Gel4sWXrpyovKfwntYNDnSN15CVNoYSHth33ELA4J6HVlUXP aqU4poj6LGva4enEgTXmoL/NlL/S5DwHKPwafgMgNpJNOblL0te15DDSpWJLE8I4v9l TqN4bZ5ZHc/ozjrwr1B1CrYWRxzj7bH30QCJLgpi0K0ARVGjFWFa63YsrLJUqWLQ6OH 1fY3VT0u3FGxz35eQVtOu7yU5lydhM+YK+2wqqymjB7/djVodyoEDq6ovFwEo6vzbL2 Vc4opaHaqw== Date: Sun, 24 Apr 2022 05:35:17 +0200 (CEST) From: henrichhartzer@tuta.io To: Freebsd Hackers Message-ID: Subject: First port install fails on 13.1 RC List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KmDLG2VWTz4dWd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuta.io header.s=s1 header.b=svjCe22t; dmarc=pass (policy=quarantine) header.from=tuta.io; spf=pass (mx1.freebsd.org: domain of henrichhartzer@tuta.io designates 81.3.6.162 as permitted sender) smtp.mailfrom=henrichhartzer@tuta.io X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[tuta.io:s=s1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tuta.io:+]; DMARC_POLICY_ALLOW(-0.50)[tuta.io,quarantine]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I'm not sure if this is a bug with ports or what, but was hoping it could be looked into before 13.1 final. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263429 Thank you! -Henrich From nobody Sun Apr 24 07:01:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D6A02199EAD3 for ; Sun, 24 Apr 2022 07:02:01 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmJwm6glYz3JWM for ; Sun, 24 Apr 2022 07:02:00 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ed1-x530.google.com with SMTP id z19so1781218edx.9 for ; Sun, 24 Apr 2022 00:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W0K/uPbBqG/owECGzpYvZBmEoBvRlPKAM/GgBJskPYU=; b=V+W+biQ1EcgomhCCkdniT2JDaNjz/NR5DOBl5JBbjeEyu9y5eBwFTzPldKouS1w29B C90jhRZ1gVcvV2FoekAWxoFIGfOm+5rMRsEIdpqRvlNk0vsAqywWS5P6BS/wjJadLO8u TO1GeerYs1XacFfv3KITR0327D7l+T6HbN3PHOBZJ/y1fDzP2hmt1+LNjB0MiNkdo3iS qGcExChEzp/4mUTytGPFwqJfPAGk8pQCCoReN3Ze5fU9aq/gU0+WXYAqVw0TDhOcirZJ P6u//3YIV+BP2ti0cwHXbpn/J8308S+w9fZgXQETyhWfPIQM7Dvu0Qa4juXCFEpQeY2Y wwNA== 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=W0K/uPbBqG/owECGzpYvZBmEoBvRlPKAM/GgBJskPYU=; b=1rfxKOE24ommO8ZRS5InN9YqR9is0V0TkP6X1Rzf0jT/Ro5NEb2IMHhNhi+I1r9ooQ F0kuoFdN/WtqFqpWZZ9XydZFcWfoqg/niGrxhXdRVA238U2psnGbqp+DTseGb0drUTj0 5b0633Fvvsne1/cOmryr7Q2+bfjW0h6nAiKbxpCjCjZGlBJnkZQZV2te0/O6zh9NPbmk lkW4ypWLvl/RrBKhduk36nLsKyEpi7fADgu4+XMArRUU1eFuq9ZGt7qDXqqtJ2x4gwSI fgIdpON0GI0EWQjTW1pQ3EQ6gbf7nQ4RfTkgcj3cAbdNSzynfacDO8qVmH2bxdcdWgKm /yfQ== X-Gm-Message-State: AOAM530/x3FBwCHlW33XugCiqn2yKTErkSJPFCK88wh+9F3Vtd2CG9QZ nGOTk9bsnPanWZWQX5PyeLywAMfeQgYJDQJZHOiqXOCQ X-Google-Smtp-Source: ABdhPJzSzsGJNE9FER6qSrC3gkkF/aYVkDbJiB9tjC/m+1kPUODeF6uKPk8VG0C8iRQjLCPxrmNBBoMJ3f72Al0o6EY= X-Received: by 2002:a05:6402:3492:b0:423:dfe4:ec43 with SMTP id v18-20020a056402349200b00423dfe4ec43mr13304565edc.401.1650783719077; Sun, 24 Apr 2022 00:01:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> In-Reply-To: <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> From: Rob Wing Date: Sat, 23 Apr 2022 23:01:47 -0800 Message-ID: Subject: Re: kernel crash making a vlan on a wlan To: Eugene Grosbein Cc: Marek Zarychta , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002d3a6f05dd610919" X-Rspamd-Queue-Id: 4KmJwm6glYz3JWM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=V+W+biQ1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000002d3a6f05dd610919 Content-Type: text/plain; charset="UTF-8" >From what I can tell, the vlan driver is calling ieee80211_output() with the wrong ifnet context and dereferencing a bad pointer. It looks like the passed in if_softc is pointing to a struct ifvlan instead of the expected struct ieee80211_vap Looking at vlan_output(), I wonder if the parents ifnet context should be used when calling if_output()? something like: diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c index 2bb5284c2129..5fbd7a79dccc 100644 --- a/sys/net/if_vlan.c +++ b/sys/net/if_vlan.c @@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, const struct sockaddr *dst, ifv = p->if_softc; } while (p->if_type == IFT_L2VLAN); - return p->if_output(ifp, m, dst, ro); + return ((*p->if_output)(p, m, dst, ro)); } #ifdef ALTQ On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein wrote: > 24.04.2022 3:28, Marek Zarychta wrote: > > > W dniu 23.04.2022 o 22:11, Craig Leres pisze: > >> > >> On 4/23/22 11:12, Craig Leres wrote: > >>> I am able to reproduce the crash with 13.1-RC4. > >> > >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems wlan0 > is part of the recipe, I tried vlans_em0="vlan0" first but was not able to > induce a crash. > >> > >> Craig > >> > > > > I am curious what is this WiFi hardware that supports 802.1q tagging > over the air? Could you please reveal this? > > > > That's rather not a bug when you are shooting yourself in the foot. > > Kernel panic due to ifconfig command is always a bug. > > > > --0000000000002d3a6f05dd610919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From what I can tell, the vlan driver is calling ieee= 80211_output() with the wrong ifnet context and dereferencing a bad pointer= .

It looks like the passed in if_softc is poi= nting to a struct ifvlan instead of the expected struct ieee80211_vap
=

Looking at vlan_output(), I wonder if the parents ifnet= context should be used when calling if_output()? something like:

diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c
index= 2bb5284c2129..5fbd7a79dccc 100644
--- a/sys/net/if_vlan.c
+++ b/sys/= net/if_vlan.c
@@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struc= t mbuf *m, const struct sockaddr *dst,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ifv =3D p->if_softc;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 } while (p->if_type =3D=3D IFT_L2VLAN);

- =C2=A0 =C2=A0 = =C2=A0 return p->if_output(ifp, m, dst, ro);
+ =C2=A0 =C2=A0 =C2=A0 r= eturn ((*p->if_output)(p, m, dst, ro));
=C2=A0}

=C2=A0#ifdef A= LTQ


On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein <= ;eugen@grosbein.net= > wrote:
= 24.04.2022 3:28, Marek Zarychta wrote:

> W dniu 23.04.2022 o 22:11, Craig Leres pisze:
>>
>> On 4/23/22 11:12, Craig Leres wrote:
>>> I am able to reproduce the crash with 13.1-RC4.
>>
>> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It se= ems wlan0 is part of the recipe, I tried vlans_em0=3D"vlan0" firs= t but was not able to induce a crash.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Craig
>>
>
> I am curious what is this WiFi hardware that supports 802.1q tagging o= ver the air? Could you please reveal this?
>
> That's rather not a bug when you are shooting yourself in the foot= .

Kernel panic due to ifconfig command is always a bug.



--0000000000002d3a6f05dd610919-- From nobody Sun Apr 24 13:35:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C758F1A89B53 for ; Sun, 24 Apr 2022 13:35:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmTfd2ycGz3Dk6 for ; Sun, 24 Apr 2022 13:35:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2b.google.com with SMTP id i186so11905499vsc.9 for ; Sun, 24 Apr 2022 06:35:21 -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=Fz9HpfTcLKvFxPxaMVFida+HaxfENIXAjVomwgzkyBI=; b=QqO6kj7q7CdwIqYAYdeZBiAFVk27B1mvQqcKrkzdnjvIySjy+hSf/e63Wr4GiA5WuR FVjKA0+pyH73dEkil9Ls8mRJAvoVeSBLc/RtrTaG1GeY5M4QH4PwOaFtN5c/X/KjUbOC 84Eg12py+VOA6KdITzGgRpfmYpxS314o5OKGSPl7pkirwjChqoVPwMKQZHkIzX8UiVIw jYohQz6DfbcDSxnNLOaWbGLQU+CiupD6Ta90ShjPLrzm8aa50VkQpv323If/XpslqBtG BbV4Sk0q+67NtBCfe7a3A5Z1DUB3fCuiGcW+7Ji7ZHmLft7Yeoacyyiw6vwi+pjFjT8M GnQw== 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=Fz9HpfTcLKvFxPxaMVFida+HaxfENIXAjVomwgzkyBI=; b=IOaEk3Q0A/SRImEtKcAittUDDsAnxtHYk/pNa7Va6kTHht6YufA170gXIVBzLCY3Y0 bZoRiVT0qVtNCY1fI39hsrEKUzXen+GkkEDnZ4bmF8oqAcBDho/8dAT2PHjGtA/OC6Pb EpkNlb8yn6a2RHw2lQs6Ui3XYFOkMIBL0XsS9lVUSe9/MaXF2ApTC8JG0z/DwIvDoSxO W5ESpxuCeN4QTEPbEMv2JlZGYlaaaej2eKFrYwe0/krGztHwjZlvZGpLo2iwMd8+KyDt 3UxYPCASt3Az+3rEGrVaERkDHHBF3XtgV4znhg8qqfOhEl3VYFsYIJEYUGHHD+ME7cDH xcHg== X-Gm-Message-State: AOAM531O136irBpUxqBKazrwQhvmTlXSu13ItMr6lP4CIdRP8plFhBVj dttEywciycym5MAT0TXkFXkjcagY3wXA8E3WTieH0Q== X-Google-Smtp-Source: ABdhPJyyUfJEF+7Z+60zFoA0JpEx1lbRSNKMO9dsXrcu4Febzd3H1EkF/VjqV7KbHBuXYfZZT3HnWODhsqIPye3Z8lQ= X-Received: by 2002:a67:f646:0:b0:32c:cc77:c201 with SMTP id u6-20020a67f646000000b0032ccc77c201mr168642vso.44.1650807320629; Sun, 24 Apr 2022 06:35:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> In-Reply-To: From: Warner Losh Date: Sun, 24 Apr 2022 07:35:08 -0600 Message-ID: Subject: Re: kernel crash making a vlan on a wlan To: Rob Wing Cc: Eugene Grosbein , Marek Zarychta , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f0674e05dd66871b" X-Rspamd-Queue-Id: 4KmTfd2ycGz3Dk6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=QqO6kj7q; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2b) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2b:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000f0674e05dd66871b Content-Type: text/plain; charset="UTF-8" On Sun, Apr 24, 2022, 1:03 AM Rob Wing wrote: > From what I can tell, the vlan driver is calling ieee80211_output() with > the wrong ifnet context and dereferencing a bad pointer. > > It looks like the passed in if_softc is pointing to a struct ifvlan > instead of the expected struct ieee80211_vap > > Looking at vlan_output(), I wonder if the parents ifnet context should be > used when calling if_output()? something like: > > diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c > index 2bb5284c2129..5fbd7a79dccc 100644 > --- a/sys/net/if_vlan.c > +++ b/sys/net/if_vlan.c > @@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, const > struct sockaddr *dst, > ifv = p->if_softc; > } while (p->if_type == IFT_L2VLAN); > > - return p->if_output(ifp, m, dst, ro); > + return ((*p->if_output)(p, m, dst, ro)); > No. Those two are the same thing. Warner } > > #ifdef ALTQ > > > On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein > wrote: > >> 24.04.2022 3:28, Marek Zarychta wrote: >> >> > W dniu 23.04.2022 o 22:11, Craig Leres pisze: >> >> >> >> On 4/23/22 11:12, Craig Leres wrote: >> >>> I am able to reproduce the crash with 13.1-RC4. >> >> >> >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems >> wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not >> able to induce a crash. >> >> >> >> Craig >> >> >> > >> > I am curious what is this WiFi hardware that supports 802.1q tagging >> over the air? Could you please reveal this? >> > >> > That's rather not a bug when you are shooting yourself in the foot. >> >> Kernel panic due to ifconfig command is always a bug. >> >> >> >> --000000000000f0674e05dd66871b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 24, 2022, 1:03 AM Rob Wing <rob.fx907@gmail.com> wrote:
From what I can tell, the= vlan driver is calling ieee80211_output() with the wrong ifnet context and= dereferencing a bad pointer.

It looks like t= he passed in if_softc is pointing to a struct ifvlan instead of the expecte= d struct ieee80211_vap

Looking at vlan_output(), I= wonder if the parents ifnet context should be used when calling if_output(= )? something like:

diff --git a/sys/net/if_vlan.c = b/sys/net/if_vlan.c
index 2bb5284c2129..5fbd7a79dccc 100644
--- a/sys= /net/if_vlan.c
+++ b/sys/net/if_vlan.c
@@ -1318,7 +1318,7 @@ vlan_out= put(struct ifnet *ifp, struct mbuf *m, const struct sockaddr *dst,
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ifv =3D p->if_softc= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } while (p->if_type =3D=3D IFT_L2VLAN);=

- =C2=A0 =C2=A0 =C2=A0 return p->if_output(ifp, m, dst, ro);
= + =C2=A0 =C2=A0 =C2=A0 return ((*p->if_output)(p, m, dst, ro));

No. Those two are the same thing.

Warner=C2=A0

=C2=A0}

=C2=A0#ifdef ALTQ


On Sat, Apr 23,= 2022 at 1:12 PM Eugene Grosbein <eugen@grosbein.net> wrote:
<= /div>
24.04.2022 3:28, Mar= ek Zarychta wrote:

> W dniu 23.04.2022 o 22:11, Craig Leres pisze:
>>
>> On 4/23/22 11:12, Craig Leres wrote:
>>> I am able to reproduce the crash with 13.1-RC4.
>>
>> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It se= ems wlan0 is part of the recipe, I tried vlans_em0=3D"vlan0" firs= t but was not able to induce a crash.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Craig
>>
>
> I am curious what is this WiFi hardware that supports 802.1q tagging o= ver the air? Could you please reveal this?
>
> That's rather not a bug when you are shooting yourself in the foot= .

Kernel panic due to ifconfig command is always a bug.



--000000000000f0674e05dd66871b-- From nobody Sun Apr 24 14:30:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 206A21A9537E for ; Sun, 24 Apr 2022 14:30:54 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmVth6rBdz3L34 for ; Sun, 24 Apr 2022 14:30:52 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: by mail-ed1-x52d.google.com with SMTP id g23so8656812edy.13 for ; Sun, 24 Apr 2022 07:30:52 -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=x0AA+3pEV2qNDk4F3HiPNuGOaMKKImvePhRf0zCQL1s=; b=MOPEXqIQTrLaekym93D7leivz254BD3lZF25AtjYzfeRnosFvPGKQxukIzG/vdax4n n/mPVw63aA/f7YELdpsTVbQUXNncu7XoWkRfmZE10lnAdgOstPYQ7lRCsrxo4iOM4zpU TI+DeSOCkafA3Eh/iHNHtJ9DWnTvd34Je9A8hubXWi4ZT1OdOnXpLlVJ5k/LCly0mT5f a6hF8v8FVHhrWyoRc89VcH9vP+GFY+EEINBittLQLzYdMgfiKEEASrLiSpCNL9dBHIZa hL2Si5fyhoYN5Z+zPXlTx4/64MdV2KDyr/8HZky4D/mNQyh+iS/8DsQp5uK0TjdVIE2g IqPQ== 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=x0AA+3pEV2qNDk4F3HiPNuGOaMKKImvePhRf0zCQL1s=; b=Mj4/xwYM6NbfpkYZ0N+JS+L1S6X3uyGjncIGjuRW16zWWuY5HYNWIfYfagwwVEg8IP 163zmJUhFoDAOZRbZB97aYb/bQY7lNwQWiYahGgJT7byiRpaYOfxOxj0RzBFQsSlGEm3 YSzOT46blLzRidUFqnFqYsJzK58lVowBpD9Pc9fqOmx5tG92yj9z3VDe3ujIch+dMrHP wQlKCc9M/P6CW1Sj1QITVrhcBJRycZ79XDcisEqZgFLB+YRENcDHL0sp8lP5bfq30Nnq 1hrVVUuzdsXPcXuLlML896Pcy6hWIqBkz0mozcZJ88ObRzGGXdH90ZTDD6wMus2+p95R HHnQ== X-Gm-Message-State: AOAM531cdUGc50AvtqxRs5Uz4ghaoaL9XPVbBllJtbJpDZCCNS4z2AO/ k1Beb5GKHb+6Wqbs/DMrOs68jYObr8ikGpykVC8ViOqo X-Google-Smtp-Source: ABdhPJwru7IkfWsB1+swslDSKFFqd5OT0sobjE81QuC09XyFU/2j76gCflLRaVN7wEugsbasPAbTIQspTM+XVciI9sQ= X-Received: by 2002:aa7:cd0a:0:b0:425:bc13:4ccb with SMTP id b10-20020aa7cd0a000000b00425bc134ccbmr12911824edw.229.1650810645680; Sun, 24 Apr 2022 07:30:45 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> In-Reply-To: From: Rob Wing Date: Sun, 24 Apr 2022 06:30:34 -0800 Message-ID: Subject: Re: kernel crash making a vlan on a wlan To: Warner Losh Cc: Eugene Grosbein , Marek Zarychta , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000002094fe05dd674e87" X-Rspamd-Queue-Id: 4KmVth6rBdz3L34 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MOPEXqIQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of robfx907@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=robfx907@gmail.com X-Spamd-Result: default: False [-2.11 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.87)[0.873]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000002094fe05dd674e87 Content-Type: text/plain; charset="UTF-8" What do you mean when you say they are the same thing? On Sun, Apr 24, 2022 at 5:35 AM Warner Losh wrote: > > > On Sun, Apr 24, 2022, 1:03 AM Rob Wing wrote: > >> From what I can tell, the vlan driver is calling ieee80211_output() with >> the wrong ifnet context and dereferencing a bad pointer. >> >> It looks like the passed in if_softc is pointing to a struct ifvlan >> instead of the expected struct ieee80211_vap >> >> Looking at vlan_output(), I wonder if the parents ifnet context should be >> used when calling if_output()? something like: >> >> diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c >> index 2bb5284c2129..5fbd7a79dccc 100644 >> --- a/sys/net/if_vlan.c >> +++ b/sys/net/if_vlan.c >> @@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, >> const struct sockaddr *dst, >> ifv = p->if_softc; >> } while (p->if_type == IFT_L2VLAN); >> >> - return p->if_output(ifp, m, dst, ro); >> + return ((*p->if_output)(p, m, dst, ro)); >> > > No. Those two are the same thing. > > Warner > > } >> >> #ifdef ALTQ >> >> >> On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein >> wrote: >> >>> 24.04.2022 3:28, Marek Zarychta wrote: >>> >>> > W dniu 23.04.2022 o 22:11, Craig Leres pisze: >>> >> >>> >> On 4/23/22 11:12, Craig Leres wrote: >>> >>> I am able to reproduce the crash with 13.1-RC4. >>> >> >>> >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems >>> wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not >>> able to induce a crash. >>> >> >>> >> Craig >>> >> >>> > >>> > I am curious what is this WiFi hardware that supports 802.1q tagging >>> over the air? Could you please reveal this? >>> > >>> > That's rather not a bug when you are shooting yourself in the foot. >>> >>> Kernel panic due to ifconfig command is always a bug. >>> >>> >>> >>> --0000000000002094fe05dd674e87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What do you mean when you say they are the same thing= ?

On Sun, Apr 24, 2022 at 5:35 AM Warner Losh <imp@bsdimp.com> wrote:

On Sun, = Apr 24, 2022, 1:03 AM Rob Wing <rob.fx907@gmail.com> wrote:
From what I can t= ell, the vlan driver is calling ieee80211_output() with the wrong ifnet con= text and dereferencing a bad pointer.

It look= s like the passed in if_softc is pointing to a struct ifvlan instead of the= expected struct ieee80211_vap

Looking at vlan_out= put(), I wonder if the parents ifnet context should be used when calling if= _output()? something like:

diff --git a/sys/net/if= _vlan.c b/sys/net/if_vlan.c
index 2bb5284c2129..5fbd7a79dccc 100644
-= -- a/sys/net/if_vlan.c
+++ b/sys/net/if_vlan.c
@@ -1318,7 +1318,7 @@ = vlan_output(struct ifnet *ifp, struct mbuf *m, const struct sockaddr *dst,<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ifv =3D p->if= _softc;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } while (p->if_type =3D=3D IFT_L2= VLAN);

- =C2=A0 =C2=A0 =C2=A0 return p->if_output(ifp, m, dst, ro= );
+ =C2=A0 =C2=A0 =C2=A0 return ((*p->if_output)(p, m, dst, ro));

No. Those two are the same thing.

Warner=C2=A0

=C2=A0}

=C2=A0#ifdef ALTQ


On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein <eugen@grosb= ein.net> wrote:
24.04.2022 3:28, Marek Zarychta wrote:

> W dniu 23.04.2022 o 22:11, Craig Leres pisze:
>>
>> On 4/23/22 11:12, Craig Leres wrote:
>>> I am able to reproduce the crash with 13.1-RC4.
>>
>> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It se= ems wlan0 is part of the recipe, I tried vlans_em0=3D"vlan0" firs= t but was not able to induce a crash.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Craig
>>
>
> I am curious what is this WiFi hardware that supports 802.1q tagging o= ver the air? Could you please reveal this?
>
> That's rather not a bug when you are shooting yourself in the foot= .

Kernel panic due to ifconfig command is always a bug.



--0000000000002094fe05dd674e87-- From nobody Sun Apr 24 14:36:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7667D1A972F2 for ; Sun, 24 Apr 2022 14:36:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmW1538q5z3M9C for ; Sun, 24 Apr 2022 14:36:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id u205so4507971vsu.6 for ; Sun, 24 Apr 2022 07:36:25 -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=a5IhorgUl5BgFBd358qEcl1FCCrjAXtNvR2635KZi6k=; b=W54P6IDlsMSeYO/0FjMxiubfW2PV4gzAjCWiBQbVLP8WmsvVrq+9OSX8aHMcu/EFSs D3OoVdnU3l9Hr+1sFmjnPMKeVH887ubnaKgrN9qSPtSVncwhL1ngp2NtfIlSZQSLRUM7 7kdzCq9IZlV/mijf69Vut0dnO9f17eJmbSHinSQcKsZfk4xj/bI3dmynZcfOBFiEpUQw P4pANnjtUTUxpuKtPbn/61uUZA0uJidXfbXaR7Qb99NE6bss86u3wAEpYcdkyDUo5yQR hh8FJvUPJpobRaC0qg81XXGzuTu6KC3HXHVsiQ+iQt5+1QO/2ggfmzke9V5slJh09Wft 4Rgg== 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=a5IhorgUl5BgFBd358qEcl1FCCrjAXtNvR2635KZi6k=; b=JOJB96jnS9+AcuszZfL2CE3uZVOSoNvmbdaiPl7Ss2Ga+3D5qokmj1vYt0EZnkt8ne 4Q2mAOktUFr+f4KueeAPnl//Iyk9JrsPYo6yR6UKUfu6Y1D/C01d+XlRzKNiBn0AeK1X 1x9SZ1WpQrKckifRPwPhXGFJJNekbk9Pqetac9VxXZd1+OV9G+Hn7QMkcOVVH9U8W/Uw j1JkbB3FSWdO9m2KTZ6xbjBMUmTGBMGDC/hXqmiIVu0W5PJfyvlJ86cqBPOLObeTlLHO qARg093aj+GXK4vZfa6fAVsJbXCLUiOU6kXQBHEO10qUwp49FNRUAY2qXg0zrjFpwNj9 35dQ== X-Gm-Message-State: AOAM5300Nr7l/mlzHG6ycf3WsyxcBeOrnIylk0CILNTjickkAPXBuazu RzvyLPRlW1ijfBh2nUu+jve5bvZ++af2l24Ho0hy+w== X-Google-Smtp-Source: ABdhPJzI+YyWOfC4kSVfrLxL1zuQDBSOX7Y4Lx4MPKjvEHLvHtnyFZft6oXth+FefwvLb8snqNgOtKQzDfCysnlmLzA= X-Received: by 2002:a67:f445:0:b0:32c:c32c:c7c1 with SMTP id r5-20020a67f445000000b0032cc32cc7c1mr583705vsn.51.1650810978888; Sun, 24 Apr 2022 07:36:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> In-Reply-To: From: Warner Losh Date: Sun, 24 Apr 2022 08:36:06 -0600 Message-ID: Subject: Re: kernel crash making a vlan on a wlan To: Rob Wing Cc: Eugene Grosbein , Marek Zarychta , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000fd015a05dd6761d0" X-Rspamd-Queue-Id: 4KmW1538q5z3M9C X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=W54P6IDl; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.40 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.90)[-0.904]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e33:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000fd015a05dd6761d0 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 24, 2022, 8:30 AM Rob Wing wrote: > What do you mean when you say they are the same thing? > There is no semantic difference between the two notations. The change will have no effect. Warner On Sun, Apr 24, 2022 at 5:35 AM Warner Losh wrote: > >> >> >> On Sun, Apr 24, 2022, 1:03 AM Rob Wing wrote: >> >>> From what I can tell, the vlan driver is calling ieee80211_output() with >>> the wrong ifnet context and dereferencing a bad pointer. >>> >>> It looks like the passed in if_softc is pointing to a struct ifvlan >>> instead of the expected struct ieee80211_vap >>> >>> Looking at vlan_output(), I wonder if the parents ifnet context should >>> be used when calling if_output()? something like: >>> >>> diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c >>> index 2bb5284c2129..5fbd7a79dccc 100644 >>> --- a/sys/net/if_vlan.c >>> +++ b/sys/net/if_vlan.c >>> @@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, >>> const struct sockaddr *dst, >>> ifv = p->if_softc; >>> } while (p->if_type == IFT_L2VLAN); >>> >>> - return p->if_output(ifp, m, dst, ro); >>> + return ((*p->if_output)(p, m, dst, ro)); >>> >> >> No. Those two are the same thing. >> >> Warner >> >> } >>> >>> #ifdef ALTQ >>> >>> >>> On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein >>> wrote: >>> >>>> 24.04.2022 3:28, Marek Zarychta wrote: >>>> >>>> > W dniu 23.04.2022 o 22:11, Craig Leres pisze: >>>> >> >>>> >> On 4/23/22 11:12, Craig Leres wrote: >>>> >>> I am able to reproduce the crash with 13.1-RC4. >>>> >> >>>> >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems >>>> wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not >>>> able to induce a crash. >>>> >> >>>> >> Craig >>>> >> >>>> > >>>> > I am curious what is this WiFi hardware that supports 802.1q tagging >>>> over the air? Could you please reveal this? >>>> > >>>> > That's rather not a bug when you are shooting yourself in the foot. >>>> >>>> Kernel panic due to ifconfig command is always a bug. >>>> >>>> >>>> >>>> --000000000000fd015a05dd6761d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 24, 2022, 8:30 AM Rob Wing <rob.fx907@gmail.com> wrote:
What do you mean when you= say they are the same thing?

There is no semantic difference betwe= en the two notations. The change will have no effect.

Warner

On Sun, Apr 24= , 2022 at 5:35 AM Warner Losh <imp@bsdimp.com> wrote:

On Sun, A= pr 24, 2022, 1:03 AM Rob Wing <rob.fx907@gmail.com> wrote:
>From what I can tell, the vlan driver is calling ieee80211_output() with t= he wrong ifnet context and dereferencing a bad pointer.

=
It looks like the passed in if_softc is pointing to a struct ifv= lan instead of the expected struct ieee80211_vap

L= ooking at vlan_output(), I wonder if the parents ifnet context should be us= ed when calling if_output()? something like:

diff = --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c
index 2bb5284c2129..5fbd7a= 79dccc 100644
--- a/sys/net/if_vlan.c
+++ b/sys/net/if_vlan.c
@@ -= 1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, const stru= ct sockaddr *dst,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ifv =3D p->if_softc;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } while (p->i= f_type =3D=3D IFT_L2VLAN);

- =C2=A0 =C2=A0 =C2=A0 return p->if_ou= tput(ifp, m, dst, ro);
+ =C2=A0 =C2=A0 =C2=A0 return ((*p->if_output)= (p, m, dst, ro));

No. Those two are the same thing.

Warner=C2=A0
=
=C2=A0}

=C2=A0#i= fdef ALTQ


On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbe= in <eugen@grosbein.net> wrote:
24.04.2022 3:28, Marek Zarychta wrote:<= br>
> W dniu 23.04.2022 o 22:11, Craig Leres pisze:
>>
>> On 4/23/22 11:12, Craig Leres wrote:
>>> I am able to reproduce the crash with 13.1-RC4.
>>
>> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It se= ems wlan0 is part of the recipe, I tried vlans_em0=3D"vlan0" firs= t but was not able to induce a crash.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Craig
>>
>
> I am curious what is this WiFi hardware that supports 802.1q tagging o= ver the air? Could you please reveal this?
>
> That's rather not a bug when you are shooting yourself in the foot= .

Kernel panic due to ifconfig command is always a bug.



--000000000000fd015a05dd6761d0-- From nobody Sun Apr 24 14:37:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 188D81990BF1 for ; Sun, 24 Apr 2022 14:38:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KmW302mCNz3NMq for ; Sun, 24 Apr 2022 14:38:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe32.google.com with SMTP id j2so1255276vsp.5 for ; Sun, 24 Apr 2022 07:38:04 -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=qWrTtc0nZxtddzStvVqFgLveCdTy2cp2vH3vEFFvQPY=; b=u6hQBAxDmXibcAdYnEw/NHlkLYlOrlwP57z7BPXG50tKw1t1jJqTx79jjiCdiM+d8y u2GpuptDdTXwt68ydvA3tIMbD2yvM76NtJ5lANcBTWvJHJRVKCBOptPPy3TT3lqSurqb lh3IvspCRthXJK+lEUuzmhDhjDuhdtl5qT+gP1BODlcqjuF3cZo7ikI5UITklnnIafmH DsUO3w5FW0I20A3szPjYv1qX/Zx3NqkLwe4qgPyY3crrfh3z5P6ujtneXIfwYFoY3CpY 5v+k7kIi2B3KK5mqPBmA+2snKGsLE3ZLaw6AYy+v5eDRrVbPMn2g/dqc3so6fL0QBQyd fl5Q== 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=qWrTtc0nZxtddzStvVqFgLveCdTy2cp2vH3vEFFvQPY=; b=xkrR6jr0EnrrqFegxxenJrC7+/wkcG/2/6uxHklwG1hGpuBnmqPJnANyrsewd3yv8j Y768WNqUFsfk+9JWb8fCJIlYJn29DQvdrHMMk3iTqzloQJk/0iCcg8M+98M/uBGnFpTb zgeJLjbttVr40fNyzC65tYKwyPDxDGAWGRR1ZtQgfG8gKRpYiq3OAakmEJRKputvyf/7 SdpoPAtj4BwK/6a0C8+tneaLMCMCVH/zm4+LJ2UkgEtjT3d0emim9r60amLZG3Q0zpk3 816i8oOAAOIrwPohqlEkn9upOtK9vefX4m3ySD3oUPjXBlX2EKOxFbHK6cBlvExYrQKW 46gA== X-Gm-Message-State: AOAM533+C0zsPRE8WrR+QL4oSQ+QoyRO7tHf8+NBcCxkEtg+dVeliIzj LAlHXf7ihSzt+UKdORBsg6vTIbJGqZ4xuwXQh4mCIaJ+/uo= X-Google-Smtp-Source: ABdhPJwJMiNl6kf4cIk0H4xxMExIWEUNvIO886Ge9bGs9jBPcQg2DJ55hhQ4ysOjlXl06e3l1ZNRZHnFFJ7FhpiyJe4= X-Received: by 2002:a67:f646:0:b0:32c:cc77:c201 with SMTP id u6-20020a67f646000000b0032ccc77c201mr208489vso.44.1650811078408; Sun, 24 Apr 2022 07:37:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <421d0c0d-4109-3370-9147-85168051deed@freebsd.org> <9ea3536e-b501-3684-850e-65f95fddf2e7@freebsd.org> <28c9ea32-b913-c153-005b-a62d6a7a6f4e@plan-b.pwste.edu.pl> <113d6d4d-eb23-30b1-a9e7-5a82a46604f8@grosbein.net> In-Reply-To: From: Warner Losh Date: Sun, 24 Apr 2022 08:37:46 -0600 Message-ID: Subject: Re: kernel crash making a vlan on a wlan To: Rob Wing Cc: Eugene Grosbein , Marek Zarychta , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000eb8f2e05dd676790" X-Rspamd-Queue-Id: 4KmW302mCNz3NMq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=u6hQBAxD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e32) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.41 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.91)[-0.907]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e32:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; SUSPICIOUS_RECIPS(1.50)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000eb8f2e05dd676790 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 24, 2022, 8:36 AM Warner Losh wrote: > > > On Sun, Apr 24, 2022, 8:30 AM Rob Wing wrote: > >> What do you mean when you say they are the same thing? >> > > There is no semantic difference between the two notations. The change will > have no effect. > Oh, I missed the ifp to p change. That will have a big effect. Warner > Warner > > On Sun, Apr 24, 2022 at 5:35 AM Warner Losh wrote: >> >>> >>> >>> On Sun, Apr 24, 2022, 1:03 AM Rob Wing wrote: >>> >>>> From what I can tell, the vlan driver is calling ieee80211_output() >>>> with the wrong ifnet context and dereferencing a bad pointer. >>>> >>>> It looks like the passed in if_softc is pointing to a struct ifvlan >>>> instead of the expected struct ieee80211_vap >>>> >>>> Looking at vlan_output(), I wonder if the parents ifnet context should >>>> be used when calling if_output()? something like: >>>> >>>> diff --git a/sys/net/if_vlan.c b/sys/net/if_vlan.c >>>> index 2bb5284c2129..5fbd7a79dccc 100644 >>>> --- a/sys/net/if_vlan.c >>>> +++ b/sys/net/if_vlan.c >>>> @@ -1318,7 +1318,7 @@ vlan_output(struct ifnet *ifp, struct mbuf *m, >>>> const struct sockaddr *dst, >>>> ifv = p->if_softc; >>>> } while (p->if_type == IFT_L2VLAN); >>>> >>>> - return p->if_output(ifp, m, dst, ro); >>>> + return ((*p->if_output)(p, m, dst, ro)); >>>> >>> >>> No. Those two are the same thing. >>> >>> Warner >>> >>> } >>>> >>>> #ifdef ALTQ >>>> >>>> >>>> On Sat, Apr 23, 2022 at 1:12 PM Eugene Grosbein >>>> wrote: >>>> >>>>> 24.04.2022 3:28, Marek Zarychta wrote: >>>>> >>>>> > W dniu 23.04.2022 o 22:11, Craig Leres pisze: >>>>> >> >>>>> >> On 4/23/22 11:12, Craig Leres wrote: >>>>> >>> I am able to reproduce the crash with 13.1-RC4. >>>>> >> >>>>> >> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It seems >>>>> wlan0 is part of the recipe, I tried vlans_em0="vlan0" first but was not >>>>> able to induce a crash. >>>>> >> >>>>> >> Craig >>>>> >> >>>>> > >>>>> > I am curious what is this WiFi hardware that supports 802.1q tagging >>>>> over the air? Could you please reveal this? >>>>> > >>>>> > That's rather not a bug when you are shooting yourself in the foot. >>>>> >>>>> Kernel panic due to ifconfig command is always a bug. >>>>> >>>>> >>>>> >>>>> --000000000000eb8f2e05dd676790 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 24, 2022, 8:36 AM Warner Losh <imp@bsdimp.com> wrote:


On Sun, Apr 24, 2022, 8:30 AM Ro= b Wing <rob.fx907@gmail.com> wrote:
What do you mean when you say they are = the same thing?

<= /div>
There is no semantic difference between the two nota= tions. The change will have no effect.
=

Oh, I missed the ifp to p cha= nge. That will have a big effect.

Warner


Warner

<= /div>
On S= un, Apr 24, 2022 at 5:35 AM Warner Losh <imp@bsdimp.com> w= rote:


On Sun, Apr 24, 2022, 1:03 AM Rob Wing <rob.fx9= 07@gmail.com> wrote:
From what I can tell, the vlan driver is = calling ieee80211_output() with the wrong ifnet context and dereferencing a= bad pointer.

It looks like the passed in if_= softc is pointing to a struct ifvlan instead of the expected struct ieee802= 11_vap

Looking at vlan_output(), I wonder if the p= arents ifnet context should be used when calling if_output()? something lik= e:

diff --git a/sys/net/if_vlan.c b/sys/net/if_vla= n.c
index 2bb5284c2129..5fbd7a79dccc 100644
--- a/sys/net/if_vlan.c+++ b/sys/net/if_vlan.c
@@ -1318,7 +1318,7 @@ vlan_output(struct ifnet= *ifp, struct mbuf *m, const struct sockaddr *dst,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ifv =3D p->if_softc;
=C2=A0 =C2=A0= =C2=A0 =C2=A0 } while (p->if_type =3D=3D IFT_L2VLAN);

- =C2=A0 = =C2=A0 =C2=A0 return p->if_output(ifp, m, dst, ro);
+ =C2=A0 =C2=A0 = =C2=A0 return ((*p->if_output)(p, m, dst, ro));

No. Those two= are the same thing.

War= ner=C2=A0

=C2=A0}

=C2=A0#ifdef ALTQ


On Sat, Apr = 23, 2022 at 1:12 PM Eugene Grosbein <eugen@grosbei= n.net> wrote:
24.04.2022 3:28, Marek Zarychta wrote:

> W dniu 23.04.2022 o 22:11, Craig Leres pisze:
>>
>> On 4/23/22 11:12, Craig Leres wrote:
>>> I am able to reproduce the crash with 13.1-RC4.
>>
>> I'm also able to reproduce the crash on 12.3-RELEASE-p5. It se= ems wlan0 is part of the recipe, I tried vlans_em0=3D"vlan0" firs= t but was not able to induce a crash.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Craig
>>
>
> I am curious what is this WiFi hardware that supports 802.1q tagging o= ver the air? Could you please reveal this?
>
> That's rather not a bug when you are shooting yourself in the foot= .

Kernel panic due to ifconfig command is always a bug.



--000000000000eb8f2e05dd676790-- From nobody Mon Apr 25 13:01:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4DE8E1A921E5 for ; Mon, 25 Apr 2022 13:02:07 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kn4sn5cGjz4jS3 for ; Mon, 25 Apr 2022 13:02:05 +0000 (UTC) (envelope-from jbo@insane.engineer) Date: Mon, 25 Apr 2022 13:01:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail2; t=1650891716; bh=8yHIvPCk4E8bNztVuxYf5l4r6g/NfvdbS5/sBnW4oqE=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=X3QTl2MXcFiFTksjg1GBtEyIHvw0p5DGc0zK+AgqkrZ/386TTmLcmAMzVT0BFrwMq /8yWKstJq5MYVgdpNHrTChKARuiGlYOe+rU5/t6jQCFILqq6smtgiLfT5Gxg3+wDEp VyhQ5Hv+CnWLpoAoZinHayOE3ZCxz6ihDkEbLHNScZcWOS1AbDr4caCIU/wvZZiDCO whTp1IEK15nD1V7Qpef16tY0UQv/C/aoT8Oi1o8nX21av3hlOrABxKU4BNLesbGrCY SkXM15OfR5chJi6SNnXqHkFOcbSh9a18HG8be0mjadIRT64JmIfZruC6TdnLgz3AdM TDq41Oz+QuomA== To: FreeBSD Hackers From: jbo@insane.engineer Cc: Mark Millard , joerg@bec.de Reply-To: jbo@insane.engineer Subject: Re: llvm & RTTI over shared libraries Message-ID: In-Reply-To: <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com> References: <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com> Feedback-ID: 40997969:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_6fZ6VCZszW1kBu5na9SCxToUWtvKMDShcGjVMVxszi0" X-Rspamd-Queue-Id: 4Kn4sn5cGjz4jS3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail2 header.b=X3QTl2MX; dmarc=pass (policy=none) header.from=insane.engineer; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.43.17 as permitted sender) smtp.mailfrom=jbo@insane.engineer X-Spamd-Result: default: False [-3.55 / 15.00]; HAS_REPLYTO(0.00)[jbo@insane.engineer]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; HAS_PHPMAILER_SIG(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[insane.engineer:+]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.545]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; FREEMAIL_CC(0.00)[yahoo.com,bec.de]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --b1_6fZ6VCZszW1kBu5na9SCxToUWtvKMDShcGjVMVxszi0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello guys, Thank you for your replies. I've created a small minimal test case which reproduces the problem (attach= ed). The key points here are: - CMake based project consisting of: - The header-only interface for the plugin and the types (test-interfac= e). - The main executable that loads the plugin (test-core). - A plugin implementation (plugin-one). - Compiles out-of-the-box on FreeBSD 13/stable with both lang/gcc11 and d= evel/llvm14. - It uses the exact mechanism I use to load the plugins in my actual appl= ication. stdout output when compiling with lang/gcc11: t is type_int t is type_string done. stdout output when compiling with lang/llvm14: could not cast t could not cast t done. Unfortunately, I could not yet figure out which compiler/linker flags llvm = requires to implement the same behavior as GCC does. I understand that even= tually I'd be better of rewriting the necessary parts to eliminate that pro= blem but this is not a quick job. Could somebody lend me a hand in figuring out which compiler/linker flags a= re necessary to get this to work with llvm? Best regards, ~ Joel ------- Original Message ------- On Saturday, April 23rd, 2022 at 22:42, Mark Millard wr= ote: > > > > On 2022-Apr-23, at 15:33, Mark Millard marklmi@yahoo.com wrote: > > > =E2=80=A2 Joerg Sonnenberger wrote on > > =E2=80=A2 Date: Sat, 23 Apr 2022 21:33:04 UTC : > > > > > Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard: > > > > > > > Joerg Sonnenberger wrote on > > > > Tue, 19 Apr 2022 21:49:44 UTC : > > > > > > > > > Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb jbo@insane.engin= eer: > > > > > > > > > > > > After some research I seem to understand that the way that RT= TI is handled over shared library boundaries is different between GCC and L= LVM. > > > > > > > > > > I think you are running into the old problem that GCC thinks comp= aring > > > > > types by name makes sense where as everyone else compares types b= y type > > > > > pointer identity. > > > > > > > > Seems out of date for the GCC information . . . > > > > > > > > https://gcc.gnu.org/faq.html#dso reports: > > > > > > > > QUOTE > > > > The new C++ ABI in the GCC 3.0 series uses address comparisons, rat= her than string compares, to determine type equality. > > > > END QUOTE > > > > > > Compare that with the implementation in . > > > > Looking at /usr/local/lib/gcc11/include/c++/typeinfo I see: > > configurable, in part based on the intent for possible > > handling RTLD_LOCAL (when weak symbol are available). I'll > > quote the comments for reference . . . > > > > // Determine whether typeinfo names for the same type are merged (in wh= ich > > // case comparison can just compare pointers) or not (in which case str= ings > > // must be compared), and whether comparison is to be implemented inlin= e or > > // not. We used to do inline pointer comparison by default if weak symb= ols > > // are available, but even with weak symbols sometimes names are not me= rged > > // when objects are loaded with RTLD_LOCAL, so now we always use strcmp= by > > // default. For ABI compatibility, we do the strcmp inline if weak symb= ols > > // are available, and out-of-line if not. Out-of-line pointer compariso= n > > // is used where the object files are to be portable to multiple system= s, > > // some of which may not be able to use pointer comparison, but the > > // particular system for which libstdc++ is being built can use pointer > > // comparison; in particular for most ARM EABI systems, where the ABI > > // specifies out-of-line comparison. The compiler's target configuratio= n > > // can override the defaults by defining __GXX_TYPEINFO_EQUALITY_INLINE= to > > // 1 or 0 to indicate whether or not comparison is inline, and > > // __GXX_MERGED_TYPEINFO_NAMES to 1 or 0 to indicate whether or not poi= nter > > // comparison can be used. > > > > So, to some extent, the details are choices in the likes of lang/gcc11 > > instead of an always-the-same rule for handling. Below gives some > > more idea of what __GXX_TYPEINFO_EQUALITY_INLINE and > > __GXX_MERGED_TYPEINFO_NAMES do for configuration. Is there a combinatio= n > > that matches FreeBSD's system clang++ related behavior? If yes, should > > the likes of lang/gcc11 be using that combination? > > > I should have quoted a little bit more that describes the > defaults used: > > #ifndef __GXX_MERGED_TYPEINFO_NAMES > // By default, typeinfo names are not merged. > #define __GXX_MERGED_TYPEINFO_NAMES 0 > #endif > > // By default follow the old inline rules to avoid ABI changes. > #ifndef __GXX_TYPEINFO_EQUALITY_INLINE > #if !GXX_WEAK > #define __GXX_TYPEINFO_EQUALITY_INLINE 0 > #else > #define __GXX_TYPEINFO_EQUALITY_INLINE 1 > #endif > #endif > > . . . > > > #if !__GXX_TYPEINFO_EQUALITY_INLINE > > // In old abi, or when weak symbols are not supported, there can > > // be multiple instances of a type_info object for one > > // type. Uniqueness must use the _name value, not object address. > > . . . > > #else > > #if !__GXX_MERGED_TYPEINFO_NAMES > > . . . > > // Even with the new abi, on systems that support dlopen > > // we can run into cases where type_info names aren't merged, > > // so we still need to do string comparison. > > . . . > > #else > > // On some targets we can rely on type_info's NTBS being unique, > > // and therefore address comparisons are sufficient. > > . . . > > #endif > > #endif > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com --b1_6fZ6VCZszW1kBu5na9SCxToUWtvKMDShcGjVMVxszi0 Content-Type: application/zip; name=clang_test.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=clang_test.zip UEsDBAoAAAAAAMClk1QAAAAAAAAAAAAAAAAQABwAY2xhbmdfdGVzdF9kaXN0L1VUCQADiB9fYuMd X2J1eAsAAQTpAwAABOkDAABQSwMEFAAAAAgA4KSTVIZ8FyuFAAAAsAAAAB4AHABjbGFuZ190ZXN0 X2Rpc3QvQ01ha2VMaXN0cy50eHRVVAkAA+MdX2LjHV9idXgLAAEE6QMAAATpAwAAbYy9DsIgFEZ3 nqIjLA71CUzLQIzQ2Mb1BuHaoAUqP4NvL7su33DOyWe8fiF4F5yvHhK+q0to6Y1fZ6Fkdzz0PSN7 ik80hZpNhxUK5sIIyVjocDmdOUxqFkurQciRT7yNXGBQI++UbKG2FnK923ZsSkwfamJC9otdKJge 2vxz+1ZXFzIjX1BLAwQKAAAAAADgpJNUAAAAAAAAAAAAAAAAGAAcAGNsYW5nX3Rlc3RfZGlzdC9w bHVnaW5zL1VUCQAD4x1fYuMdX2J1eAsAAQTpAwAABOkDAABQSwMECgAAAAAA4KSTVKSNxmYdAAAA HQAAACYAHABjbGFuZ190ZXN0X2Rpc3QvcGx1Z2lucy9DTWFrZUxpc3RzLnR4dFVUCQAD4x1fYuMd X2J1eAsAAQTpAwAABOkDAABhZGRfc3ViZGlyZWN0b3J5KHBsdWdpbl9vbmUpClBLAwQKAAAAAADg pJNUAAAAAAAAAAAAAAAAIwAcAGNsYW5nX3Rlc3RfZGlzdC9wbHVnaW5zL3BsdWdpbl9vbmUvVVQJ AAPjHV9i4x1fYnV4CwABBOkDAAAE6QMAAFBLAwQUAAAACADgpJNUef00AmkBAACPAwAALQAcAGNs YW5nX3Rlc3RfZGlzdC9wbHVnaW5zL3BsdWdpbl9vbmUvcGx1Z2luLmNwcFVUCQAD4x1fYuMdX2J1 eAsAAQTpAwAABOkDAACVUttuwjAMfc9XeEWa2j3Q98J44RP2AVVIXIiWJVHjsCHUfftCsnIRjG1W VSX28fFxeybKCB0kQjGd1vFRhrDvuMDa6bBWZrpxrmBsMsLmynrqkb8tGBOaew8ZBw2DGC6stBJw ZGmaXGZ7lkvfsJQsK3gGiR0PmmYp/3ks2C32vYoDzxAJsrVKgrStp9B1pbDGE3iSTeM3vEfZOurn Z+Np57BdcY+LR6AKMn4kT4T79D5EXcMLN4p2IDYoXo951UH5EJtPyEOkocIGgvkcCgLlwQSt4/zi kEllNFLPLrp6pNCbU25g5+OX3NPFWB7IArVxofghEqXcGf6mROts2rIVseVq4XhflFTNcmv1m+6x 5yfhqD2ey4kOUGb9L0W5ZRSVb3/TlbH3pN2hiQctwViCgyq4ueHAhugt/IiCDRTL4tq9TyCi5QnL imUP5L8IBt9hxMzYcEGSfYpRvd2VNxjdyCVRIyG4RPAFUEsDBBQAAAAIAOCkk1SiGm13egAAAL4A AAAxABwAY2xhbmdfdGVzdF9kaXN0L3BsdWdpbnMvcGx1Z2luX29uZS9DTWFrZUxpc3RzLnR4dFVU CQAD4x1fYuMdX2J1eAsAAQTpAwAABOkDAAArTi3RCHEMcncNUSjIKU3PzNPNz0vV5EpMSYnPyUwq Siyq1FCphiioVQj2cAxyddHk4ipJLEpPLYlPzs8tyMxJjU9LTSwpLUot1uBSAAK4ejAvIMgzzDHE FcwGgeSKivjikpR4IwMuhEHF+aVFycTph7hSL7mgAKgfAFBLAwQKAAAAAADgpJNUAAAAAAAAAAAA AAAAFQAcAGNsYW5nX3Rlc3RfZGlzdC9jb3JlL1VUCQAD4x1fYuMdX2J1eAsAAQTpAwAABOkDAABQ SwMEFAAAAAgA4KSTVIIlFFr+AQAAzAQAAB0AHABjbGFuZ190ZXN0X2Rpc3QvY29yZS9tYWluLmNw cFVUCQAD4x1fYuMdX2J1eAsAAQTpAwAABOkDAACNk8Fu3CAQhu88BXGkynsIlqqebNeHppFaqYdK m6q9WazBa7oYEOBUVZR3LwZs4ySKymFXDDM/n2d+rpno+EQorAnvO4GGBlyvoV7qP1iTljNj0ziT xmqKxwZswYzwjmNj0KBUloQRKpiwVPe4o4Xi05mJN1PsX0WjCPCCMBS1Ixb4TDV4BGo6cdaVALr1 IBmBXGLShjSTH3z80f/OqyjgN3ceZdYwnqyEhMcy+BFG/npFKctw1uQzYZSP/60UtODsFHY3boeM zA7VXj7RjvegEV9oK0+/8ySX9TC/CueHBHxexpKy7KjWsK5h1smJEyik9V8c5VE2n/lEKgivdvWa 2kmLLfYE0r58kvJyoVQxcV7D49JIpCYztL2WwuYRLuhEDd95wozCthvyTgpjA4UZsKZuHlanvZzn 2p6woc07aJ/PyBkN5qFlsNwQDrtvUTcNka2xU9/ndmNRmj1gS4MdPEBq2/oNpDjeZruwAk8VAC4F jpgJZ6WA6Fr1PYxyMaHn2fkSqjEgqRHt/ViBReSeuh75RrgrwGoTO2+dSzyqN0jgfdE+t28W4/gi 1xFssSv98H69fB2Jz3j1dvd6l5FHgBD5H4aQmWCEwEqSfaGcS/hTak6usteoQkEC9tk9n216zuTW u53Mr+q5ucHmanj36+t9e/xxe3t3PLrJgX9QSwMEFAAAAAgA4KSTVGRd8WIABAAAIgwAACAAHABj bGFuZ190ZXN0X2Rpc3QvY29yZS9kbGNsYXNzLmhwcFVUCQAD4x1fYuMdX2J1eAsAAQTpAwAABOkD AAC1Vk2P2zYQvetXzG6AreRu7bu862bRBXrZXgJfmiAwaGlsq6VEgaSMGI7z2zv8kETJclKgqLCA teSbr8c3Q72rJduXDESVYRS9K6qMNznC067gqE5KY7kKVksshTyFK0rLotqvQtOc77JqfqC1aDGb RTCDF9hjhbLIIONMKeCC5SjntGV23+eoWcEVrA+FAvpjkInqiFWBlJQ30cJaAatOfmUnRUlQdWAS c+DFVjJ56nzqmklWwpqcdi5ONbZ+DG4RUXU1Z5pydoj1KnIvObe/0TmK6mbLiyyNgB78UtN7oe0/ HhMrnadpT1ea1kwfoBR5w3Fj3hNw1uYpN8GGMy3FEeMQnlj0ObDxNT6DM2B/o196cj8bsf1rFSdL a3KJBukRlUq3/z2A0AeUCbnKkaPG5QDbojpYJfBLhrUe4Y+F1A3j8K01dA53rOF6OQhPnmqUTAv5 PM5EHtSNPEKjPqUJ/FYI3mN/FMGaWEWaZwZ/EI+kJyDyMNMgdk4h72tYzz2mhbZyepF7Bb+ZKLLJ KCYwuW9KrDTpT+l5B3doZtAvHqGgpqToFEmBRK6P+pOCrHfXO5CoG1k58bb7ZOtTLWiFUW+0+IX9 7dVs6qhYifP53Ka8svtWPF4wtZZP6xVYKZHT2KAM2qQ81t9iAW+m9UzWTqcQFzuoEHPMkw5GS/Fd q9VfVplEk8vXrxAs5kiliFMSeG9N3dmxRosH+KSaLEOlHqFU+890hL0HOu3K91A8aKZkCXfeLBk4 N4+ns2o4p8qX3b7vFV+lCQ4u7409u2eI4/UM4lnSEpQkbj/pfYxpDVoSylPfu20NvaXP6vpc4jGN MfPhH+FT5/Ozya1Ozn2UjuC4Jjou/UCoZXEkN6nXgVET9HnCrqgYH516qyFYp6nnRM88O1TNFZUh 3mdhDPzrlMVRFDkBON8cWJXzgdcO9K1PM+7PdSifjAuFrSiSydO1HNeskE9mZjx6zt3dBaGmnAwn Z/rDYKjfyGVQTs6N63C4z13MOJlnG3qN6UA/rN9eN28vH/9MgrLbrrjr/d1U9Rl2jCt8hPsdXaNu wpi47Z2Ywj38HFZ8psRQSkHh4QKXUVhqhA+oUIOFqFF13u7a5neyCEbZ8IBa1cSTqkrIrzqVcV8r 1eJ274PjtJ7s8WSkiZnJz3LcpTQmjzbGk+Z7cvkXtNpPEF8NZbwV/JpcimpJDV1eJumyvXHNVt8y 8XRTTfLlt8eE/YCk/4ujtob/QFIXgjgyEfxwvw/NAhMzTUZp32hRI43vtZX5fiA3IWYk9+mZNeDv 5py09reH4sWNbB/wxrdleO8tJ+/2wSXUXjw+BKlvLV5FCq8C6avYfHSbu9yc3Ra7L2rj5teIEvkH UEsDBBQAAAAIAOCkk1T2OJxfrgAAAFMBAAAjABwAY2xhbmdfdGVzdF9kaXN0L2NvcmUvQ01ha2VM aXN0cy50eHRVVAkAA+MdX2LjHV9idXgLAAEE6QMAAATpAwAAjZDBCoMwDIbvfQoPO+hBGXsDDzJ2 GyK7lppGV1bb0qYgjL37qgPdZbAcQvLz/x8kASnv6vbcdBlhoBKsx4IJKTnOCJFErzE/PD+WV8EY CT8icbCTUxr5gIKix5CzLNVmXLdre7nVXbPOS8E880CSn45sBwUbPfyXn4QyFTi3CVKDFiFU96Tt RK3MI7XeC6/+A6+XK0PoBwH4hV+oyy8kOjQSDfwAOh1HZUprMCXeUEsDBAoAAAAAAOCkk1QAAAAA AAAAAAAAAAAaABwAY2xhbmdfdGVzdF9kaXN0L2ludGVyZmFjZS9VVAkAA+MdX2LjHV9idXgLAAEE 6QMAAATpAwAAUEsDBBQAAAAIAOCkk1QuTeIuiAAAACABAAAjABwAY2xhbmdfdGVzdF9kaXN0L2lu dGVyZmFjZS90eXBlcy5ocHBVVAkAA+MdX2LjHV9idXgLAAEE6QMAAATpAwAAjY/RCsIwDEXf8xWB vegvdOqvjNhmo9B1pU0FGdu321UZiAy8DyFcDiekCZGGkXDymgEa67XLhvGSJFo/3AA8jZwCaUbr hWNfNpgBsKQwWQvKM3B3p8S1nOvc8rBRMjlcd+B0xisa7ik7aSu3tL+qcgfVbjmyb5QhoWPP+4U/ VEmMUh/6W7nAC1BLAwQUAAAACADgpJNUivbHKXsAAAChAAAAKAAcAGNsYW5nX3Rlc3RfZGlzdC9p bnRlcmZhY2UvQ01ha2VMaXN0cy50eHRVVAkAA+MdX2LjHV9idXgLAAEE6QMAAATpAwAAK04t0Qhx DHJ3DVEoSS0u0c3MK0ktSktMTtXk4kpMSYnPyUwqSiyq1FCphqiqVfD0C3ENcnN0dlXw9A3wDwpx dVFw9/F3cvQB6ihJLEpPLYkvzi8tSk4t1uBSAAK4TjAPrhvMA4GCnNL0zDy9jIICuFBJZUFqMVhE kwsAUEsDBBQAAAAIAOCkk1SU7eLpvwAAAD0BAAAkABwAY2xhbmdfdGVzdF9kaXN0L2ludGVyZmFj ZS9wbHVnaW4uaHBwVVQJAAPjHV9i4x1fYnV4CwABBOkDAAAE6QMAAG2PwQrCMAyG732K4EA2D+J5 br7KiG06C1tb2lQYMp/dzskQNIcQki9//hQ+YD8iOCtJiMJYOSRFsOPJUzzevN99dZuRRhemixAW R4oeJYGxTEHnSjyEgByRQ5IMfki9se/O452XWFQV6c/wADIQMnVcVucf5u6MAkVZzk2Z+KxkcCPv JnDCAZ7rrKygzQsa08B/qFXPdZGT1qV0NnL2quo63jCQ6jyHZnumrhcb3RUjXfbAFax8C6fV6JwP zOIFUEsBAh4DCgAAAAAAwKWTVAAAAAAAAAAAAAAAABAAGAAAAAAAAAAQAO1BAAAAAGNsYW5nX3Rl c3RfZGlzdC9VVAUAA4gfX2J1eAsAAQTpAwAABOkDAABQSwECHgMUAAAACADgpJNUhnwXK4UAAACw AAAAHgAYAAAAAAABAAAApIFKAAAAY2xhbmdfdGVzdF9kaXN0L0NNYWtlTGlzdHMudHh0VVQFAAPj HV9idXgLAAEE6QMAAATpAwAAUEsBAh4DCgAAAAAA4KSTVAAAAAAAAAAAAAAAABgAGAAAAAAAAAAQ AO1BJwEAAGNsYW5nX3Rlc3RfZGlzdC9wbHVnaW5zL1VUBQAD4x1fYnV4CwABBOkDAAAE6QMAAFBL AQIeAwoAAAAAAOCkk1SkjcZmHQAAAB0AAAAmABgAAAAAAAEAAACkgXkBAABjbGFuZ190ZXN0X2Rp c3QvcGx1Z2lucy9DTWFrZUxpc3RzLnR4dFVUBQAD4x1fYnV4CwABBOkDAAAE6QMAAFBLAQIeAwoA AAAAAOCkk1QAAAAAAAAAAAAAAAAjABgAAAAAAAAAEADtQfYBAABjbGFuZ190ZXN0X2Rpc3QvcGx1 Z2lucy9wbHVnaW5fb25lL1VUBQAD4x1fYnV4CwABBOkDAAAE6QMAAFBLAQIeAxQAAAAIAOCkk1R5 /TQCaQEAAI8DAAAtABgAAAAAAAEAAACkgVMCAABjbGFuZ190ZXN0X2Rpc3QvcGx1Z2lucy9wbHVn aW5fb25lL3BsdWdpbi5jcHBVVAUAA+MdX2J1eAsAAQTpAwAABOkDAABQSwECHgMUAAAACADgpJNU ohptd3oAAAC+AAAAMQAYAAAAAAABAAAApIEjBAAAY2xhbmdfdGVzdF9kaXN0L3BsdWdpbnMvcGx1 Z2luX29uZS9DTWFrZUxpc3RzLnR4dFVUBQAD4x1fYnV4CwABBOkDAAAE6QMAAFBLAQIeAwoAAAAA AOCkk1QAAAAAAAAAAAAAAAAVABgAAAAAAAAAEADtQQgFAABjbGFuZ190ZXN0X2Rpc3QvY29yZS9V VAUAA+MdX2J1eAsAAQTpAwAABOkDAABQSwECHgMUAAAACADgpJNUgiUUWv4BAADMBAAAHQAYAAAA AAABAAAApIFXBQAAY2xhbmdfdGVzdF9kaXN0L2NvcmUvbWFpbi5jcHBVVAUAA+MdX2J1eAsAAQTp AwAABOkDAABQSwECHgMUAAAACADgpJNUZF3xYgAEAAAiDAAAIAAYAAAAAAABAAAApIGsBwAAY2xh bmdfdGVzdF9kaXN0L2NvcmUvZGxjbGFzcy5ocHBVVAUAA+MdX2J1eAsAAQTpAwAABOkDAABQSwEC HgMUAAAACADgpJNU9jicX64AAABTAQAAIwAYAAAAAAABAAAApIEGDAAAY2xhbmdfdGVzdF9kaXN0 L2NvcmUvQ01ha2VMaXN0cy50eHRVVAUAA+MdX2J1eAsAAQTpAwAABOkDAABQSwECHgMKAAAAAADg pJNUAAAAAAAAAAAAAAAAGgAYAAAAAAAAABAA7UERDQAAY2xhbmdfdGVzdF9kaXN0L2ludGVyZmFj ZS9VVAUAA+MdX2J1eAsAAQTpAwAABOkDAABQSwECHgMUAAAACADgpJNULk3iLogAAAAgAQAAIwAY AAAAAAABAAAApIFlDQAAY2xhbmdfdGVzdF9kaXN0L2ludGVyZmFjZS90eXBlcy5ocHBVVAUAA+Md X2J1eAsAAQTpAwAABOkDAABQSwECHgMUAAAACADgpJNUivbHKXsAAAChAAAAKAAYAAAAAAABAAAA pIFKDgAAY2xhbmdfdGVzdF9kaXN0L2ludGVyZmFjZS9DTWFrZUxpc3RzLnR4dFVUBQAD4x1fYnV4 CwABBOkDAAAE6QMAAFBLAQIeAxQAAAAIAOCkk1SU7eLpvwAAAD0BAAAkABgAAAAAAAEAAACkgScP AABjbGFuZ190ZXN0X2Rpc3QvaW50ZXJmYWNlL3BsdWdpbi5ocHBVVAUAA+MdX2J1eAsAAQTpAwAA BOkDAABQSwUGAAAAAA8ADwAFBgAARBAAAAAA --b1_6fZ6VCZszW1kBu5na9SCxToUWtvKMDShcGjVMVxszi0-- From nobody Mon Apr 25 13:18:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9B2341A95DF1 for ; Mon, 25 Apr 2022 13:18:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kn5Dg6mspz4m1y for ; Mon, 25 Apr 2022 13:18:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wr1-f48.google.com with SMTP id u3so20843178wrg.3 for ; Mon, 25 Apr 2022 06:18:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/GSCGhESrRoLQtcMsc2ysQY4Gha4qtyTagTRBU/4h74=; b=akzFygbgJMXQpFz8Y29HNR0R1GgInb6stIrdCLgO9SdLTMYH37x/8xJMIOXNnsG7Jy dC35XW2EEcTXqorz+CSvTKMm+9o6AdVElPdNb5ZCmZn8uJsltFGGDiIg+UseXp7kGl63 QKirTjdR9eZDOmOqDsv4C5OwQoTFS+OBv1J69Xs1pUvqVGgZSokdWsR/1XSbFlRAwNJz 51fh4Qa7S7RtVibb9QQxZKol6K7fwuZmX9UNSuYmeOatpjp08ca6Wjkymtb8x3Ai/Fmy 9N+BYdqT+80iJgShPPcX/2yliVOz74xjTgjcKyx0jJ83ewnxZPuI94S6JQVf94kZCthq SNTg== X-Gm-Message-State: AOAM531OJ+TkQW+YeCzgz21DiM9bKWF/JMCVF8/o2YQM20ZlkjaEJnZD KVRCBY7roZ4/Q+WUhH0usHQS2SJ/hsX9s1Dc+ElE43Fhm/Y= X-Google-Smtp-Source: ABdhPJyNyKg4B7yUvVjoPU+wQfs4V7I0X85AUCgFLh4zni2+aYBSZinneZuUMSeOs7svYW33Zev0g11Cj3GANxpH1Cw= X-Received: by 2002:adf:dc0f:0:b0:207:9980:5de8 with SMTP id t15-20020adfdc0f000000b0020799805de8mr14149204wri.300.1650892700415; Mon, 25 Apr 2022 06:18:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Mon, 25 Apr 2022 09:18:08 -0400 Message-ID: Subject: Retiring ssh client VersionAddendum To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Kn5Dg6mspz4m1y X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [0.84 / 15.00]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.86)[0.857]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.221.48:from]; NEURAL_SPAM_SHORT(0.98)[0.984]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.221.48:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ssh supports a VersionAddendum configuration option to specify text to append to the SSH version string. FreeBSD introduced VersionAddendum for the server as a local change in 2001 in commit 933ca70f8f88 and later extended it to the client in commit 9e2cbe04ff4f. In 2012 upstream added support for server VersionAddendum, in commit 23528816dc10. It is not supported upstream in the client. The argument for supporting this in the client is not nearly as strong as for the server, and I plan to retire this in the client to reduce the scope of our local patch set. This also avoids some cases of conflicts in ssh_config during update, as a user's configuration would typically follow the commented-out default VersionAddendum value. I have a review open to make this change, https://reviews.freebsd.org/D32930. From nobody Mon Apr 25 22:39:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E55B71A9B800 for ; Mon, 25 Apr 2022 22:40:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4KnKhg2TMWz3KLK for ; Mon, 25 Apr 2022 22:40:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650926396; bh=6spWwvjh45tedfuKsrdoNp0aE8LvYxubEiXloE5jxA0=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=gad3+/Z21UNoWJ8Ouc4MkYOypLQ5ujwEZ9T2KdCpoUJ7bbA3T+IbmXpEnMixfE02enWpSGqmgIMC6gTydfRgkL/ZSxS08cHVGgVJ8VjdHEjJn77UI5/QqfIFAQIySi9Y9miZxeXfRvT3xZ3o76UTmMQxTdcrzFaBZRqp5Q0B1j0/JB5TuiVZ/YXsptjbfXqHO5QWd4R3EHIisV4m4TUX8cmjjNeWHy74LGhYuuN1gNwysawV+K8LzBWS+8KOQqn4i8AYxWipPmAEA3oo9cvq+axNvBOdl8LR7qVwYM86/d1oNzLdRG1YWzcg/Qobn6Ft3cCtv8qERrWXxsRVkQ2cyg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650926396; bh=kc9GAgfvM4Wp9pRLaWkEwfNeo70nyHqBBVDr2oKTr82=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=p8VmTT0/ykk/B+xfyv+Gy5qvp3C/T+lgYZO7dELs3WhgGqIhQN9CmQICAh4M+BeXwNc7Z/APyfxDhO2nwp0B5KEevAcWPRAFmio6C/Z73ConUOaKEeqrlMSGZDxsBDYZz8fR9zQX4BsrZ+cKARei29AAW1jiM1UoEchb2542dk/zb6qz2uHbCFn2LoHn0bzef93WQNgr1y3s2wsFjqb3pPszwsATewlZOt6+V8KOYT09wEOElTPax+EcOr15j0ApesdDgjo0+/LMgGBuWclT9VCFXoavy1hwgv3h221/ec5f7ZsIIs6nxql4rt2zi6iGvJIUnQ2FXCdInTYZyDCMbQ== X-YMail-OSG: gPUZB8oVM1nLmX.ERYtVbJpZ_itDazhp670ExdTQsKyrx8GKihSbisQ_ZTW8Toa 4bQ.laIw2.Yh.whvkAni9MrEGwyFrzR1UejEO6ZUdnO0F56NKXe481LjzPvqtuEsDRPV75y1FL8o x75FltChpbHRc3M4xS6baxLh1jznUZDZuOPi1hwPX505AMANZg0IZYwHEnjgHuxhOkp06DGOte7E u9x40_9engubYXkc25l9yCOwoB88T9GdJkGLVvg9YgGGGg8jrc277_eMammMsV_6fwqr1I.HC057 fjOts4QdldPrWAbN0CV1Yv0GWBdrwEElB5Ycpk2h_v4YRFUszBssrbUPoShUgECtNjWOeJExyxyQ YfqYDB2aBxzYWR1O4iBFBNn75a3Jjwahe48sbPy_w472JOPofdabjXv4u2PMODpAmPW4kj4pdH6i ccEjh_wSUp8H5yutgioTOvc69Cme9hhBJtII7HXD8nTukSuonV1X7902sNyxpBV0bIrh3pzKFgFm mIdoQR06AiJNU9dZk4RE4CSkkxtXDa6FX9sBBbJeQyV.JYQeAMOCOylZ7dJLlCFpi3gWSmZHOKki dJ1uUP7MaiMObHekTDrOCjAgmM3e6vMdn0DUqTQCC_3DzHKWoFbVPwwh_g.ONWmgzz38y9ZxanZL iprBO_yZGnowQAlNl8LaRknPxjjr.AZOrOIpOl7_ghawYJr7dTvkSiTY0chh4RNVXCYVT5VGjzOF 3UzpOckcZPN904AW8IxlTOLzOJ4NX6Ae6_aKaq3Vi8tSF_sLuMSa98HDX43HEFONKJEHh10JOjmt cQqLzWYDXGUoafa_rNIkx2YmGaZ6EjikhapDx_Ulija571gSxuF4MxRP0GhSaVncaJbJCQVDxLDo bUAE0_wLUNRqQ7FJ6JhlyDUPDANjktrqiVZdrJsaPcSohgOd9rrEkiuxFEfB5xEaaKMdMiDYegmY 6wHMe7H6Ez5sFOOgVONFdP1pTCgoQCzEIra6HWh8iadY.4UXRkZdxt6vIpAy4zETOooUD3TsoPAC 67BeUjUpw01g4IfDvg3tqLjSE_GpwxDZmDGN8L7s_4E1OEEXia219_iQtZX6Z8DT3BMWZi80MYK0 JiTeUnZu57r8bF.ukuz1jaUPf198WlBJPiYnYIQdFYC.fN0rm869xtRoX.088_mkmu7isFrzuRAk twOxQCTnsP8AuHrrhJJHbu9kV7w.8CsrLcx3tB_nNrAX8wh5HyP47TLdfIrvkND7zzWpi47qSDC. BQx50EYDyE02pp5wAn.vaKcxJLUjS6Df7Ue31a6yuwJuL51BYuKoLGMeFytAfg7YGb4Kh_6wUTh1 JxUtJIEBKEwUiss_N_.EkUjhjBUg9IlUzf8rdUhRNQqU4gLqbNOlhYPsHRIT5QcPSt_AVadaTueX CvekoOth1.6xp08c8l8JxqjqiIoplcM8UoEyqZbH4km2Mk6kIQUtr9w_V2K_j8syrDl5F6aOQ.E4 E1WNGf4B0hQYc0hFjznAz40OVYHZtIXNB3zCBivN1Jt3yOHFkDK3A4g.mR062CIMMpgifFPeuC4Z oHA0jqoAYR7VwCuKgcX8doEbEHYc6hDSrQHJPBtAwb7760VZj3VTinnSbFpaNN13C..kdgJ2_q.o HQ79l6rVTG0rzWjHqeIabSvBGuZW4BY.dRX3QcMva05K_IMAGX_6AP7sQA1cLe90RUS4eOePX114 keNDOHBOqgPX4n1fdlQTrRNo7InVme4jQPqSshu0N5bQQW3A2kMbbM8NCxMlAtvZD1jLyFtX3XFc 3E2UwEO.O9fYLagJidofRlzBSJGuGVLHOsZclLEC6O.NuTY3_GjZhBH7qOx9IFs.KdivvYSNAR5e y0ZKHn4BLXXGFtelqdXdWopNCgGDpOgLlnYT.WM38NDBTeplgTn_X.EchavHZYVoVd7.C3wWrhMs 97P.cjfwaBPvFzpCE9wIQCHHn2dpWSChN50ie3pcb4scio01FthKXh8ITzW0.v5_pSf.qAR1YrUu S.veAFqjExTqsHWq2P2RDsxZq0m6pTJTumBtje6480XprdJb7g1GDIRw4h4H7UdEWy0T.hBLAu4t aAkDzKqeAgF91.RV2yZfVM2EBwl0IljvRSGL9huQLhdx.u.UtKOrCoenraR3bb3tkReaO0iMAyoA L8b31mjh5b1jNKyWHzBOvgLVIjUBKIdP09LGEN8Jwlo1wvsJyFXGMu2rrvMJuTzuzrE7oWYanGon 4iBgtL3gPVhy2n2SqyJX5._mUXm3sPYdCKFHC_VIMW_qckrSik.m.lfv7tYpkEVvme7X2v9P5CDU 8mau2wAfZjlu2hMxdefA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Mon, 25 Apr 2022 22:39:56 +0000 Received: by hermes--canary-production-bf1-7cfdddd556-gh5b7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e69192b701c5c95921ac0ecf7a1c9e77; Mon, 25 Apr 2022 22:39:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Message-Id: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F@yahoo.com> Date: Mon, 25 Apr 2022 15:39:48 -0700 Cc: joerg@bec.de To: jbo@insane.engineer, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F.ref@yahoo.com> X-Rspamd-Queue-Id: 4KnKhg2TMWz3KLK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="gad3+/Z2"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.46 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; NEURAL_HAM_SHORT(-0.96)[-0.958]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N =E2=80=A2 wrote on =E2=80=A2 Date: Mon, 25 Apr 2022 13:01:48 UTC : > I've created a small minimal test case which reproduces the problem = (attached). > The key points here are: > - CMake based project consisting of: > - The header-only interface for the plugin and the types = (test-interface). > - The main executable that loads the plugin (test-core). > - A plugin implementation (plugin-one). > - Compiles out-of-the-box on FreeBSD 13/stable with both lang/gcc11 = and devel/llvm14. > - It uses the exact mechanism I use to load the plugins in my actual = application. >=20 > stdout output when compiling with lang/gcc11: >=20 > t is type int > t is type string > done. >=20 >=20 > stdout output when compiling with lang/llvm14: >=20 > could not cast t > could not cast t > done. >=20 >=20 > Unfortunately, I could not yet figure out which compiler/linker flags = llvm requires to implement the same behavior as GCC does. I understand = that eventually I'd be better of rewriting the necessary parts to = eliminate that problem but this is not a quick job. >=20 > Could somebody lend me a hand in figuring out which compiler/linker = flags are necessary to get this to work with llvm? The GCC default behavior is technically wrong. GCC allows being = configured to do the correct thing --at the cost of ABI mismatches vs. what they = originally did. (At least that is how I understand what I read in the code.) To my knowledge LLVM does not allow clang++ being configured to do the = wrong thing: it never had the ABI messed up and so did not face the = self-compatibility question. (Bug-for-bug clang++ vs. g++ compatibility has not been the = major goal.) I have a nearly-minimalist change to your example that makes it result = in: # ./test-core t is type_int t is type_string done. under clang. I pasted a diff -ruN in the message later below but that = may lead to white space not being fully preserved. (I could send it to you = in another form if it proved needed.) Basically I avoid inline definitions of: virtual ~type_base(); virtual ~type_int(); virtual ~type_string(); Also, these are deliberately(!) the first non-inline virtual member functions in the 3 types. Where the implementations are placed controls were the type_info is put for the 3 types. (Not a language definition issue but a fairly common implementation technique.) I also make the place with the implementation be a tiny .so that both test-core and libplugin-one.so are bound to. This makes them use the same type_info definitions instead of having multiple competing ones around, sort of a form of single-definition-rule (unique addresses in the process). With the single definition rule followed, RTTI works just fine. I do warn that this is the first direct adjustment of cmake material that I've ever done. So if anything looks odd for how I did the cmake aspects, do not be surprised. I'm not cmake literate. For reference: # find clang_test_dist_m_m/ -print clang_test_dist_m_m/ clang_test_dist_m_m/plugins clang_test_dist_m_m/plugins/CMakeLists.txt clang_test_dist_m_m/plugins/plugin_one clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt clang_test_dist_m_m/plugins/plugin_one/plugin.cpp clang_test_dist_m_m/shared_types_impl clang_test_dist_m_m/shared_types_impl/CMakeLists.txt clang_test_dist_m_m/shared_types_impl/types_impl.cpp clang_test_dist_m_m/core clang_test_dist_m_m/core/dlclass.hpp clang_test_dist_m_m/core/CMakeLists.txt clang_test_dist_m_m/core/main.cpp clang_test_dist_m_m/CMakeLists.txt clang_test_dist_m_m/interface clang_test_dist_m_m/interface/plugin.hpp clang_test_dist_m_m/interface/types.hpp clang_test_dist_m_m/interface/CMakeLists.txt where the diff -ruN is . . . diff -ruN clang_test_dist/ clang_test_dist_m_m/ | more diff -ruN clang_test_dist/CMakeLists.txt = clang_test_dist_m_m/CMakeLists.txt --- clang_test_dist/CMakeLists.txt 2022-04-19 13:38:59.000000000 = -0700 +++ clang_test_dist_m_m/CMakeLists.txt 2022-04-25 12:51:03.448582000 = -0700 @@ -5,4 +5,5 @@ =20 add_subdirectory(core) add_subdirectory(interface) +add_subdirectory(shared_types_impl) add_subdirectory(plugins) diff -ruN clang_test_dist/core/CMakeLists.txt = clang_test_dist_m_m/core/CMakeLists.txt --- clang_test_dist/core/CMakeLists.txt 2022-04-19 13:38:59.000000000 = -0700 +++ clang_test_dist_m_m/core/CMakeLists.txt 2022-04-25 = 13:18:52.539921000 -0700 @@ -19,9 +19,12 @@ PRIVATE test-interface dl + PUBLIC + shared-types-impl ) =20 add_dependencies( ${TARGET} + shared-types-impl plugin-one ) diff -ruN clang_test_dist/interface/types.hpp = clang_test_dist_m_m/interface/types.hpp --- clang_test_dist/interface/types.hpp 2022-04-19 13:38:59.000000000 = -0700 +++ clang_test_dist_m_m/interface/types.hpp 2022-04-25 = 14:48:52.534159000 -0700 @@ -7,18 +7,20 @@ =20 struct type_base { - virtual ~type_base() =3D default; + virtual ~type_base(); }; =20 struct type_int : type_base { + virtual ~type_int(); int data; }; =20 struct type_string : type_base { + virtual ~type_string(); std::string data; }; =20 diff -ruN clang_test_dist/plugins/plugin_one/CMakeLists.txt = clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt --- clang_test_dist/plugins/plugin_one/CMakeLists.txt 2022-04-19 = 13:38:59.000000000 -0700 +++ clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt = 2022-04-25 13:19:20.188778000 -0700 @@ -12,3 +12,14 @@ PRIVATE plugin.cpp ) + +target_link_libraries( + ${TARGET} + PUBLIC + shared-types-impl +) + +add_dependencies( + ${TARGET} + shared-types-impl +) diff -ruN clang_test_dist/shared_types_impl/CMakeLists.txt = clang_test_dist_m_m/shared_types_impl/CMakeLists.txt --- clang_test_dist/shared_types_impl/CMakeLists.txt 1969-12-31 = 16:00:00.000000000 -0800 +++ clang_test_dist_m_m/shared_types_impl/CMakeLists.txt = 2022-04-25 12:55:29.760985000 -0700 @@ -0,0 +1,15 @@ +set(TARGET shared-types-impl) +add_library(${TARGET} SHARED) + +target_compile_features( + ${TARGET} + PRIVATE + cxx_std_20 +) + +target_sources( + ${TARGET} + PRIVATE + types_impl.cpp +) + diff -ruN clang_test_dist/shared_types_impl/types_impl.cpp = clang_test_dist_m_m/shared_types_impl/types_impl.cpp --- clang_test_dist/shared_types_impl/types_impl.cpp 1969-12-31 = 16:00:00.000000000 -0800 +++ clang_test_dist_m_m/shared_types_impl/types_impl.cpp = 2022-04-25 14:49:23.599440000 -0700 @@ -0,0 +1,5 @@ +#include "../interface/types.hpp" + +interface::type_base::~type_base() {} +interface::type_int::~type_int() {} +interface::type_string::~type_string() {} That is all there is to the changes. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 25 23:22:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B7A11994B3D for ; Mon, 25 Apr 2022 23:22:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KnLdc0s9Kz3RGC for ; Mon, 25 Apr 2022 23:22:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650928940; bh=NjFvFwCwUdgR+9WlW6j52xyAcfmGrHWRsTBPhyq78+A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FrgFyzWZTsFeE8v+EmUlU/bYg8J1p51PIQlvc3R5hWXRKGsQuoa10lpgs8jFl8/xwQY6UvDjde9rplfk7teXvlZrChDMI+VYxVuaXZRDEZpxQrbVOsAjDwYTev9PXO/exU6jJzKLW3DCv3yvH27eWSAl+6c49WhFgEGlG3+WJRX4XVzoiVLznnv2hAwBIHJ1cx8m+bI/gREOkkXwp142RUa3BHIyIhCvxiBadlOP3+eGbpgcxBcc5WrHHEQAriu9ylJdxnTpcx6oSSfe94mC0CRWFBjsyD40LEqs1zO7gJEzSgHf8s60XFVTQumpMI8uA3korFPmwJBdrpZylY/wOA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650928940; bh=n6Pm/t8iWROfUuxcubH/8gjfFdf6Het7tRzy9tKlegj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ToNMSs4LdQ6IvVcVOh6dA8LfwB1g7wAq/vIhrO97ilmYD0Jljn1NO+DAwkikn5jl47Exrr2UoHUURDZFkGxFH6uYJ9tX0qwO0C9ntxrb5Jnjb6YolxLeWkohbI8qO4zHa1wNNSZjAGW2/F4hXL5Bb667lKHl7kEX8kbz+oRl2E80epb4FBKYiB9qjYMQltSXKWQRxVzp51MmGFmRCsckmCistalFmE185Otf98xn43Rf//RteMHE5eNy1EQBMl9CPkXIsFVFXUbYgVWEkOAosjcRPC29K7gow9Bih+P+lg/X8ziBBp+LSAURU7RGzUhoRAXrn/Z17nQbfeW7swx1rg== X-YMail-OSG: oLDRER8VM1le9LnOgpMhXbfc9I2W3rqcBypw5aCblPoWRqCzvrFmmzlV8lojhtP rnbNEZTDhpPQKVTxxQPHxU9a5sgZKLQZr0agnVGohFt.ylH94nRIhaKiKmVgEx5WrqIuFRUtHnNE 38SsF3KJ.WP2R21ZMRoZOwMsCGsMioOn.d6DY8usdRe0jUwVTN1ilSFfBNJ8uAbVctb2UhPWMBLw YvSg2uiZvlgQdTUBGFwOEGWWdEPhrp72FPrW28TN.NYft7YaJbA4TbhK9ywCY16PVY3uxYeyhK6c 7dgKl99a2jjEEh7MHkvn0SOOLUI5OKJUdqiKNW4A4kyHd9urGKpDpu7BjlymM7zRYXcIJcYpIlk6 OLgWuF4nKGAXHYzYU6SqmS69KYUKeXHfuvUGv_oEq5T7mM6QO9Psr3rxqRRsUg85ATVK92G88HUX s0ZgOoQ_mLiP35TsNNFju5BBOU83BcOgx5toh2t9ZaK5m0PFX8rWZcphwwp7ky_5._lexRpJpxfo fDmtwhSbGdMFWWcueO1bI8nuZGWgyJh4L9khpJ0a_swRyvC2myYcatKzbcQrf_NYZD_7Ccm0IKn7 5OJH0.b75GKAICLVMOz5kMN2mDJ7frsSfO9gLHUqsYhS4J1j2c06tMv..ZU6PGl5WST5No8NCj1Q pQVFr4fPYMaxQqZSUBd6tk2BDYdfL9iTrpUhvShPxiSganw7K_Emaut_nJGAdHTmN7evGKhg7m.U moeuaPzTGqXBHaPI7ZoH2lh6jKX3USPJXySWJiwGqh8P4btIOt1Tj1zEv70wuKgURxjdANQVs8Zx v1et992OO0O4FrdmbDHAgQrVkfmMrR0d3dAFzcuTAGW1866HDwdExW_DYTho4LXz1V5CPlbTjzXm cm4Muw17rP3qlOEgroRKPsccjcgteI8qBi9BVj6TmJti2l8g_0Wi8X.W2xp0GZRwzBmAMDKl2TRg rBcu2byLjrIo_0xaWfSnN5NiHMlv_1mua.WUSdLjJzrJOQ7N6tClb9JdH6qfcNFklu47HlusGqJD P8rnWA6jSkFmuSU5RTAC_B68II_R.CM.z8wv414kPwaHoCULS7ZjnT.el7Mk1ZGECPVQ_kC4qalZ DhoPdzkQiqmm8ej7fdxogZ4m_qvUt.n.YqYYw7af55ds49hJbWaoai2k1Ae44SARvMcohcZ5iXiS 9ZQffA2fCgs0T3m4NB75B4429auDU8jQdbxZMs0luKb4TbWxzt4kBQctHZ99nK0ULzQVfea.45cz 3m5eepXiUI2RLFDIoDXm7pPqovBiLcRbGsafQQsNAj2Y6qMwhoxok9fCm35V92Z48SCG.dmjoi6y f_U5csDikURUC5mTd0Q.2W93dY6E3ghPyEijkDMmfLT71ug6pLJ565Uq3AHjv2gTfNHZt5o5KSsD JBxU6hmHHkBPYS6uCn8RD_rSF11UyGuevXXHfZIIuu08tRBEur_lG9nZoRbgTXZ2KIglZaeE2I_m wL5NT2vyOYw1vkkd9nofJ1DST07DCNb9JTlE_1h3l4RN.d2WUOdfFh6E5dap3uwobGq0BAJQBjIW coJJgCkpcB7771ENEwy2MjrCM.4sFMze5WlBh27K3htOJt9Hl93W1EDMU.zjTKJexZdKyxZFGm.b nMW2G0VWyHEhIP0yVcVWkYps.EJCsosQZTY8kE5MKCg_wVWWhfJdmvG97wlgxbEi0C7UmT2bVV9t iEZ65SI9t9xRx6B8QFXhvW3b0HtuE4H9OucX5.9bJwobufczIuw8MTcpekBqmhu1VcplUAv44frK h3om.s4s3uT_qznSTWEaIQuXrmpPe9DuN8mBq1coLKI7sMCbwqvPAiAoeTbTudYymzsYUMdB8HsW _UTtKVKOWy1PwqA.E1dsxQ_KXzDHjIXi_he5wvDgo6A.iIC4NDrQfVv6gWzGPs3iiAJ6zNUiPZaj SICUpMB0n75dsVJh9F97Q1J4uLJugKlSvdE1rTwy8HtzpzsgSEmEO_GArn3IQml1E5Rk9Ge8L1b7 olRDpT3fgeB37j8a_5QulwmneCyzAFL56.WjwoQ0Z57DxBpfdUf.IYoL4oik.mNpl8Z9hj2GK84p lOEmtl.iW73QyUGE_._pPTJotWOoVtykNoBo12k0CHmzmtmZiuksTMbZXwdyjyXqnIz6SwkezWVw BSRzbwKxduvIL29gIARuu.KXvIkJtlONGnszFZyJjzxDDyJ0LltILuZIMF2DRxLZte7XAL.Hpl3a pCUWE8YYrlQidgt0zzVbVXMUef8Gz.ob2GmiefdbSvTr5bpv_Mk4y._0JEGGq88A098fF3mtiuqB IOWNbsbDdNCAcSm9gfAarITNlzbK6zA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 25 Apr 2022 23:22:20 +0000 Received: by hermes--canary-production-bf1-7cfdddd556-6zdns (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5f2497e382a047bcfe300b0838d011f2; Mon, 25 Apr 2022 23:22:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries From: Mark Millard In-Reply-To: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F@yahoo.com> Date: Mon, 25 Apr 2022 16:22:12 -0700 Cc: joerg@bec.de Content-Transfer-Encoding: quoted-printable Message-Id: References: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F@yahoo.com> To: jbo@insane.engineer, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4KnLdc0s9Kz3RGC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FrgFyzWZ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.68 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.82)[0.818]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-25, at 15:39, Mark Millard wrote: > =E2=80=A2 wrote on > =E2=80=A2 Date: Mon, 25 Apr 2022 13:01:48 UTC : >=20 >> I've created a small minimal test case which reproduces the problem = (attached). >> The key points here are: >> - CMake based project consisting of: >> - The header-only interface for the plugin and the types = (test-interface). >> - The main executable that loads the plugin (test-core). >> - A plugin implementation (plugin-one). >> - Compiles out-of-the-box on FreeBSD 13/stable with both lang/gcc11 = and devel/llvm14. >> - It uses the exact mechanism I use to load the plugins in my actual = application. >>=20 >> stdout output when compiling with lang/gcc11: >>=20 >> t is type int >> t is type string >> done. >>=20 >>=20 >> stdout output when compiling with lang/llvm14: >>=20 >> could not cast t >> could not cast t >> done. >>=20 >>=20 >> Unfortunately, I could not yet figure out which compiler/linker flags = llvm requires to implement the same behavior as GCC does. I understand = that eventually I'd be better of rewriting the necessary parts to = eliminate that problem but this is not a quick job. >>=20 >> Could somebody lend me a hand in figuring out which compiler/linker = flags are necessary to get this to work with llvm? >=20 > The GCC default behavior is technically wrong. GCC allows being = configured to > do the correct thing --at the cost of ABI mismatches vs. what they = originally > did. (At least that is how I understand what I read in the code.) >=20 > To my knowledge LLVM does not allow clang++ being configured to do the = wrong > thing: it never had the ABI messed up and so did not face the = self-compatibility > question. (Bug-for-bug clang++ vs. g++ compatibility has not been the = major > goal.) Looks like I may have got that wrong, although, like gcc11, it is is more of a when-building-the-C++-library time frame operation than a when-copmiling/linking to use the C++ library time frame thing. Also, nothing says the same strings would be used by clang++ vs. g++, possibly the comparisons might not agree across toolchains when string comparisons are used. . . ./contrib/llvm-project/libcxx/include/typeinfo has the following material for !defined(_LIBCPP_ABI_MICROSOFT): // = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = // // Implementations // = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = // // = ------------------------------------------------------------------------- = // // Unique // (_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION =3D 1) // = ------------------------------------------------------------------------- = // // This implementation of type_info assumes a unique copy of the RTTI = for a // given type inside a program. This is a valid assumption when abiding = to the // Itanium ABI = (http://itanium-cxx-abi.github.io/cxx-abi/abi.html#vtable-components). // Under this assumption, we can always compare the addresses of the = type names // to implement equality-comparison of type_infos instead of having to = perform // a deep string comparison. // = --------------------------------------------------------------------------= // // NonUnique // (_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION =3D 2) // = --------------------------------------------------------------------------= // // This implementation of type_info does not assume there is always a = unique // copy of the RTTI for a given type inside a program. For various = reasons // the linker may have failed to merge every copy of a types RTTI // (For example: -Bsymbolic or llvm.org/PR37398). Under this assumption, = two // type_infos are equal if their addresses are equal or if a deep string // comparison is equal. // = --------------------------------------------------------------------------= // // NonUniqueARMRTTIBit // (_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION =3D 3) // = --------------------------------------------------------------------------= // // This implementation is specific to ARM64 on Apple platforms. // // This implementation of type_info does not assume always a unique copy = of // the RTTI for a given type inside a program. When constructing the = type_info, // the compiler packs the pointer to the type name into a uintptr_t and = reserves // the high bit of that pointer, which is assumed to be free for use = under that // ABI. If that high bit is set, that specific copy of the RTTI can't be = assumed // to be unique within the program. If the high bit is unset, then the = RTTI can // be assumed to be unique within the program. // // When comparing type_infos, if both RTTIs can be assumed to be unique, = it // suffices to compare their addresses. If both the RTTIs can't be = assumed to // be unique, we must perform a deep string comparison of the type = names. // However, if one of the RTTIs is guaranteed unique and the other one = isn't, // then both RTTIs are necessarily not to be considered equal. // // The intent of this design is to remove the need for weak symbols. = Specifically, // if a type would normally have a default-visibility RTTI emitted as a = weak // symbol, it is given hidden visibility instead and the non-unique bit = is set. // Otherwise, types declared with hidden visibility are always = considered to have // a unique RTTI: the RTTI is emitted with linkonce_odr linkage and is = assumed // to be deduplicated by the linker within the linked image. Across = linked image // boundaries, such types are thus considered different types. // This value can be overriden in the __config_site. When it's not = overriden, // we pick a default implementation based on the platform here. > I have a nearly-minimalist change to your example that makes it result = in: >=20 > # ./test-core > t is type_int > t is type_string > done. >=20 > under clang. I pasted a diff -ruN in the message later below but that = may > lead to white space not being fully preserved. (I could send it to you = in > another form if it proved needed.) >=20 > Basically I avoid inline definitions of: >=20 > virtual ~type_base(); > virtual ~type_int(); > virtual ~type_string(); >=20 > Also, these are deliberately(!) the first non-inline virtual > member functions in the 3 types. Where the implementations > are placed controls were the type_info is put for the 3 types. > (Not a language definition issue but a fairly common > implementation technique.) >=20 > I also make the place with the implementation be a tiny .so > that both test-core and libplugin-one.so are bound to. This > makes them use the same type_info definitions instead of > having multiple competing ones around, sort of a form of > single-definition-rule (unique addresses in the process). > With the single definition rule followed, RTTI works just > fine. >=20 > I do warn that this is the first direct adjustment of cmake > material that I've ever done. So if anything looks odd for > how I did the cmake aspects, do not be surprised. I'm not > cmake literate. >=20 > For reference: >=20 > # find clang_test_dist_m_m/ -print > clang_test_dist_m_m/ > clang_test_dist_m_m/plugins > clang_test_dist_m_m/plugins/CMakeLists.txt > clang_test_dist_m_m/plugins/plugin_one > clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt > clang_test_dist_m_m/plugins/plugin_one/plugin.cpp > clang_test_dist_m_m/shared_types_impl > clang_test_dist_m_m/shared_types_impl/CMakeLists.txt > clang_test_dist_m_m/shared_types_impl/types_impl.cpp > clang_test_dist_m_m/core > clang_test_dist_m_m/core/dlclass.hpp > clang_test_dist_m_m/core/CMakeLists.txt > clang_test_dist_m_m/core/main.cpp > clang_test_dist_m_m/CMakeLists.txt > clang_test_dist_m_m/interface > clang_test_dist_m_m/interface/plugin.hpp > clang_test_dist_m_m/interface/types.hpp > clang_test_dist_m_m/interface/CMakeLists.txt >=20 > where the diff -ruN is . . . >=20 > diff -ruN clang_test_dist/ clang_test_dist_m_m/ | more > diff -ruN clang_test_dist/CMakeLists.txt = clang_test_dist_m_m/CMakeLists.txt > --- clang_test_dist/CMakeLists.txt 2022-04-19 13:38:59.000000000 = -0700 > +++ clang_test_dist_m_m/CMakeLists.txt 2022-04-25 12:51:03.448582000 = -0700 > @@ -5,4 +5,5 @@ >=20 > add_subdirectory(core) > add_subdirectory(interface) > +add_subdirectory(shared_types_impl) > add_subdirectory(plugins) > diff -ruN clang_test_dist/core/CMakeLists.txt = clang_test_dist_m_m/core/CMakeLists.txt > --- clang_test_dist/core/CMakeLists.txt 2022-04-19 13:38:59.000000000 = -0700 > +++ clang_test_dist_m_m/core/CMakeLists.txt 2022-04-25 = 13:18:52.539921000 -0700 > @@ -19,9 +19,12 @@ > PRIVATE > test-interface > dl > + PUBLIC > + shared-types-impl > ) >=20 > add_dependencies( > ${TARGET} > + shared-types-impl > plugin-one > ) > diff -ruN clang_test_dist/interface/types.hpp = clang_test_dist_m_m/interface/types.hpp > --- clang_test_dist/interface/types.hpp 2022-04-19 13:38:59.000000000 = -0700 > +++ clang_test_dist_m_m/interface/types.hpp 2022-04-25 = 14:48:52.534159000 -0700 > @@ -7,18 +7,20 @@ >=20 > struct type_base > { > - virtual ~type_base() =3D default; > + virtual ~type_base(); > }; >=20 > struct type_int : > type_base > { > + virtual ~type_int(); > int data; > }; >=20 > struct type_string : > type_base > { > + virtual ~type_string(); > std::string data; > }; >=20 > diff -ruN clang_test_dist/plugins/plugin_one/CMakeLists.txt = clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt > --- clang_test_dist/plugins/plugin_one/CMakeLists.txt 2022-04-19 = 13:38:59.000000000 -0700 > +++ clang_test_dist_m_m/plugins/plugin_one/CMakeLists.txt = 2022-04-25 13:19:20.188778000 -0700 > @@ -12,3 +12,14 @@ > PRIVATE > plugin.cpp > ) > + > +target_link_libraries( > + ${TARGET} > + PUBLIC > + shared-types-impl > +) > + > +add_dependencies( > + ${TARGET} > + shared-types-impl > +) > diff -ruN clang_test_dist/shared_types_impl/CMakeLists.txt = clang_test_dist_m_m/shared_types_impl/CMakeLists.txt > --- clang_test_dist/shared_types_impl/CMakeLists.txt 1969-12-31 = 16:00:00.000000000 -0800 > +++ clang_test_dist_m_m/shared_types_impl/CMakeLists.txt = 2022-04-25 12:55:29.760985000 -0700 > @@ -0,0 +1,15 @@ > +set(TARGET shared-types-impl) > +add_library(${TARGET} SHARED) > + > +target_compile_features( > + ${TARGET} > + PRIVATE > + cxx_std_20 > +) > + > +target_sources( > + ${TARGET} > + PRIVATE > + types_impl.cpp > +) > + > diff -ruN clang_test_dist/shared_types_impl/types_impl.cpp = clang_test_dist_m_m/shared_types_impl/types_impl.cpp > --- clang_test_dist/shared_types_impl/types_impl.cpp 1969-12-31 = 16:00:00.000000000 -0800 > +++ clang_test_dist_m_m/shared_types_impl/types_impl.cpp = 2022-04-25 14:49:23.599440000 -0700 > @@ -0,0 +1,5 @@ > +#include "../interface/types.hpp" > + > +interface::type_base::~type_base() {} > +interface::type_int::~type_int() {} > +interface::type_string::~type_string() {} >=20 >=20 > That is all there is to the changes. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 26 23:47:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62DD11AB7872 for ; Tue, 26 Apr 2022 23:47:34 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Knz851Tzpz3L5h for ; Tue, 26 Apr 2022 23:47:32 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id 5D256240002 for ; Tue, 26 Apr 2022 23:47:25 +0000 (UTC) Date: Wed, 27 Apr 2022 01:47:23 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: llvm & RTTI over shared libraries Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F.ref@yahoo.com> <079B1A26-DA8B-4158-8FD4-28EE1374CF1F@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <079B1A26-DA8B-4158-8FD4-28EE1374CF1F@yahoo.com> X-Rspamd-Queue-Id: 4Knz851Tzpz3L5h X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 217.70.183.193) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-0.24 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[217.70.183.193:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.96)[0.959]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.193:from] X-ThisMailContainsUnwantedMimeParts: N Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard: > Basically I avoid inline definitions of: > > virtual ~type_base(); > virtual ~type_int(); > virtual ~type_string(); You only need to ensure that the class has one non-pure non-inline function. That's the key function and determines the translation unit (and by extension the DSO) where the virtual table and the typeinfo is placed. If there is no such function, both will be defined as weak mergable symbol and that will not result in a unique address when using RTLD_LOCAL. Joerg From nobody Wed Apr 27 00:48:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3560E199CEE7 for ; Wed, 27 Apr 2022 00:48:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-55.consmr.mail.gq1.yahoo.com (sonic316-55.consmr.mail.gq1.yahoo.com [98.137.69.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Kp0V71xX0z3kB7 for ; Wed, 27 Apr 2022 00:48:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651020488; bh=udfsdP+hnnwGz6hngaHrfcT45tlyDGaWXdYeukJTbmY=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=KhuouajN48bjeytWLxXf1ROAy0eOEsxkKG+N21bB3JhqQoLF1vpa07s778vxLLulIsnEphWOTljPpwLLm+TpKkj4Q28wAg5YHoHcdbG6TLn3uBIisV5EOLEdKqIfCviUm0CykrZfSJs5wAVuJ+0ifheSNeWwh05SdEzkf0MQO1CAi4r1ZeS+8IgwdnnrqRGm74pA2X4H769i/PslUpISQ+W0dZzoOmN4tp03DkeLD90jYHeHYuZPjwPCvO/dG+DvovrGVL2FrbxLWda/kUG/2bd3w4Z5vfUPMYZB/MQeEaSEUdfYyIvxnne2u4hGqy4ubBRsRiqBq2ZWl+HniRINeQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651020488; bh=AkayoiYSuyGiNNN8qVoEsb2E9LabjBWw8Rz4lL3g8IX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ph97gk04M3At27eoU95yVeHS9+20nzJbLQ9p9E242GciCaZiDWdVhEv/6WyXi0uO/Cc7yvoh7v1uyzWclsSA8BRQKMRodBkzAxXmVzciLXec0uMmu5dUxJjSFFuFP2czSEOXDo69YBhFpDPsH1FVaGHJz/Ff2ntzA0pG1ijy9/r5LLATzz+L2lOAtJ785+T+lh3XikAG7vGPdHB0XYaOl6A7CD/T4mAmp3H6uc4ofqbTKMbRcQUoqYghg/U0hriUAid7oTH1p/p9aTCCR1f3F7cDaKqRnKhT2TNkcrfXS3te8sFSrlWRbBUlCqKnEqsvsxJFCey6ev4I7fteLxwxEw== X-YMail-OSG: DKRtEYoVM1mO7AH6ep_UNj9yO_fLiyTap0aTrdTTjWAkuaQVnnvm.vLnVxmBwJM MaG32KRbPJFHC3db_zetW9lZPEhyJEZH4Rtb_aCuhsO.At1YnzeeViBT7ApR0FkfDbldl11fF1mb fvGc8W3AeVhAe6BNdmgJpfubvgFv0XHoYi0_qbjy3NFvRUjPub6Wnw5bWdyXw6lmwjyw9Q3a1q.y rXLUPQz0ylgiE85H1QsZguvSoBqXBZ655.pAWTA2rYsiVfmTm5pnli7kNNNGH8qGXisgEWxcHnS1 fgKO6khJUo0C4B6PbCVnZ3ENU01ba4pS0.ZvR5SjThmgEDAWaUlzgYddm9sYerWWfzD7GUIZd7fB p3hwS8EH2ovWQLsymmQzzT92ams0zn6W.d2nWXEnHuJEo7Z.mtZMvSVLOvbnERehimoRyliIwUAJ XEMHb0GYZr.VQraAt2cGlvtF7FMYW0aYbZ6eswRCVOfrtCNMdRww4d.G9rnMPcQCdChn1SL4a3Gh 65b5cNUDjil5Et2dxEWhR7BO645S77GEYlbMUGF2ATrFLonmCTVbrmrS4rskGXfML9m1xLOMo3Sa 1oxcqklHEU1zmB1Qi0f4y37fYmFSVI11STw67csGEBHWO8hC33LsdGR7xiUoD.AZs1YdvJhikuUI P9yfezSzz4NAbMB_msEEr_7R5v3l1tPm4_YcAo2HdrPhl7jX1N_ghFpGuRIn5eFv9LTHfAbMNA8h I5uQgQT6VrCsnUVAnfo3f39paXC9QtD38lKMJXFoTvx8shAvdq99jaO732vA7NdH2zaSnV_kXs3B lgfkV0FKSaGC8Ca8KJXO6Il7BcKWwUdnyXzg663pHBkUAbgXuDJ3Ive68RgZE9w8TvpsV5ChB0W4 tzjLzwjX5IH2fUQh7VdjvXY8wUMZtGAwB7608ilkB7dhg02gHaszfEaIoc4WXMMqXYM1CJQtUf8n GZC8ngJCKh6iFgUU9UEc13Y5_1MjaeRSlo6xKdn2jDnS3cjrYbZzagFk4l9x8HEOElO8MvhHXL2m r8iVA56EcPKlEofREBdbQ2J2fpmF9cMM4_RuVf6e7Lktigc1algxkAQd6GQRCSjKE1UvdduBHRes wBW5Xj.BmNjQ94rSjN7OEfhgW5BXWcayrKEyzzUDRfOmqRI5I56A3bQ05iKLzfYJ_XQe8eGRqcAM BnAtjwzduFKCYehoY5KVBP_dSxwkTdgvScorSIyiBu25Ngu76AI1exZ99RQaJUxIdA5gpndV_YQy Peu.FUVGEADO42E0CHnTJFbz2HRGJKj6T3PGtz.boWfRLlFBS7yyaUl0JNhYLvK0T16475xkdqiz x2207PUTXVhYzJ6r3fe6lqsUQKPrz3da2X3_a_ZBXbMWD4Y5Br7FxG6VtqvtmTBZq4G2s7oQeGTq r5BrnVDNeX4_mPog5nrmmOezSdSvpX2MuU_zejdAKI6CBI4bjPU89e1EexjEz8XUCWOWJYHZu5ny QJOMUrot6Rvyu98AKabe5dECB7cAI2hdxkZi5xJN6jgF4ageh4FP0uvis2qFU9FSdteK7AAffK7B ZO8M2IerqTAZXYiNJZedStQn3_9ARpoIHaE5kbLWvFe0PYu.PLzSffKRIhpM_29EMwtTdiiebDYV 7UPp5N8d0zfeHuIYfIhuAKQQBVo4F9l.6zZsUBLeI3ohZrA7WZdfNQrFrreZeQU3uLXSJebWm_7C loH7JYpO2Dfx5JfvhDt4acLykMGwbgxcMn9bkAZIYlCc0XsqINxHvYKwHu0f2eiCRFOkiXlCPn8H fkMgEe4.46Rm5xYyVuGUkG1A0rkJLSmhn8tGDLtufCYCP_2tfHKD0kHRT_9zngDJa.8rliXEFTmu oVsjM956tmFS5KMJWgt9ryirg2HcJnmG3HERz3vs3uKeGuOGDcDrwzja8oqitYp8ydGEzz9umJGC hZKUG8QgX4O_HipnQthotP0JScb.CwhidA7HlZXK8Td4VhGXK380XMCnOwnKjcDwoekaE1LKrS0v TirKydLVoq7HfPG37QUgX2YgK3a7Sph3pg3Rbm9OpA58U2218Um6NXamousG5CnQ6vONV2r6x_o2 iFXd0V50SxnM5zYHld3YUjhuQjE.FPzbIna0oIAzKyB6GXhPwLrJ67TzAabiPTgk4oWXj.fdFOMt vgf3fsyhGpUzcDwwRCBNCh38i7xXUKIrDSagPUozvmwoWBRrClWXUXm3htX2VI3anPwxKZ.Cai5f 6bwLh4fxrxF3Eg9nYdcxeFFUF35C56uZN4.fMHlQgoPXShO3sv4NvPZUglUuYtZdcxkJ_1TPuM.c I2y4Ko7VnWlxmVm95 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Apr 2022 00:48:08 +0000 Received: by hermes--canary-production-ne1-75b69fcf97-dzsj8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0cbba843aebe934c6afe125706d611d5; Wed, 27 Apr 2022 00:48:02 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries Message-Id: Date: Tue, 26 Apr 2022 17:48:00 -0700 Cc: jbo@insane.engineer To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Kp0V71xX0z3kB7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=KhuouajN; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.31:from]; NEURAL_HAM_SHORT(-0.94)[-0.936]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N =E2=80=A2 Joerg Sonnenberger wrote on =E2=80=A2 Date: Tue, 26 Apr 2022 23:47:23 UTC : > Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard: > > Basically I avoid inline definitions of: > >=20 > > virtual ~type_base(); > > virtual ~type_int(); > > virtual ~type_string(); >=20 > You only need to ensure that the class has one non-pure non-inline > function. I'm confused at what you are claiming that I did wrong or described incorrectly for the example at hand. Those are 3 separate classes each with one virtual method that is not in line (and that I showed the definitions for later in the message). No other such functions were involved explicitly in those 3 classes. The gcc class type_info in /usr/local/lib/gcc11/include/c++/typeinfo describes this implementation detail for type_info itself, as its example, via: class type_info { public: /** Destructor first. Being the first non-inline virtual function, = this * controls in which translation unit the vtable is emitted. The * compiler makes use of that information to know where to emit * the runtime-mandated type_info structures in the new-abi. */ virtual ~type_info(); . . . > That's the key function and determines the translation unit > (and by extension the DSO) where the virtual table and the typeinfo is > placed. I'm a again confused about where the above disagrees with what I wrote (in text that you did not quote). > If there is no such function, both will be defined as weak > mergable symbol and that will not result in a unique address when = using > RTLD_LOCAL. I was certainly less detailed about how multiple definitions are handled. Was that your point? Let me know if I've missed some import point --or made some stupid screwup in what I'd written. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 27 01:33:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B3721AAE075 for ; Wed, 27 Apr 2022 01:33:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange 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 4Kp1VM2tfsz3pdh for ; Wed, 27 Apr 2022 01:33:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651023203; bh=RiMCp+nX40/KjAH7Pv1ZZrrEzbx4Zqmx+A9hoL7Lxm0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X4j9a+F80N882xmmxgmKr36HOlSyUYJvVHdCJ5in8gMfqFjopNCYCU+4wYlsUgDJsUEfnR3Bdj/9VuQp/Z3B331Lp71s3Y6JfI+7ikCEvnN7A3rO3vm5280rCEre332+IQBn0yrdpeGURC8bYgIzBRp6e0senggWzlF4AY9bG/OJvpKnI+0rQns3Et5Xdu3Ide8Xpy8AqorSr8AV2d6GdJDD/GXAkXmKf74Pg0o6tg8tyqhOWvfR+f+5IvafIBHD6CnBMOWlT/eaxq1D0ghOVKOWNhHPqhI0yOAioq7CAPLJSB1eHc/Rt+1pdKZxrudhoYKtKs7S+CM1o6N8zPmxQg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651023203; bh=trYh7Z9zKKIF/GcVWhs1R0uRAI82entkiC83jXcwIuj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cCWDV24eAY3XD6focj7zYV+5dTRGON29eh5qcMVn0mItFMHJBbD/+0qP48qMYaYC0reUuKdUl3x1mnxqelNKujSgOr7fRznrBvc9wjA74VXVOF8BeHMBeZZpHVOMB0X7tLOBikhZUp4MuVEGf0KOt1Ez1DDcCOEYlgHzOp0tGttl1JYJt4SvmJuTnBjmuPgeQ8ZvkN/tc74FaU2bct3U+2nbR7oDj9Oh0Px2QycJe/9++3wzwdNn7x9Vko7jTc1yyy+JblO0nsMHxZEV8N7vpwUdEwMK0T+J4Ilbj0wkD/fnCdZZHJrBEt/epbk9M+kAhlYUvBGFG3N6ARqS84j2Sw== X-YMail-OSG: H6sTTzsVM1l9mRE2nudEGuO8Ass7fLxUNIPHiX3Cc.Df98.vgW57u6ipu_OoVoH HevksybqfgnBSrYTG2wG_AicMyTsDZWwQyl7xmgyiahBw8PZSqUg18HnE3fXmmzquO0QLMNSyQDD oDH3PR.m4kpeSsQZsWUvRKNtreAcFGIptXyVxEg2_BNgXlrotAgt86Vu3uAgqWqkEZ6v.CFy5sFD x.DGSXkeTvUVXd6POys2JeKZF4.jI49C8UXYRyg5tn4c5FBpBlZm9IEUHGYNFhhl5glPHYjHqzDz S0bs_LMszs3Cqhi3Yt7Ws.MYKIQVMEJgYIfNkTy9mKYJgvy17dVHuD8O7KGs05ruELCdwTjNFlBq lZc8EUq9UGB5fAU.z_jDT1AGypv7qJKrI_HoHAp6R6yicJF12Fg3h1VM.e0Iio5ukpON0gaOSHi_ wWrSxifSljxKnljM4iClwSosKyVmXrcQHUEW9W63cfSgUHOWkqKj0VTY5lCgGLEJTasfSZEpbiAO x.XHtGPeY3uJP69r_190GrMiRtZvOP_BBjAy2DkSZN_fqlPzR7inq89LutomkSa3LtVTbTio0188 5GNIklVLf8RPJ1RgcA34zCN4EiWfXsnmH9y3FXY7UOirrKL2PTKmTPHtUjPy7xw98T6cHDrpALdf XvOjsxzua_WAMsefO9.hm21PvRkEM1K1P6_g_nq_xxjrDt5IucnO_z_KPIK8fMamL0Uh67O4qxL_ hNRz0bJDcoCRYkrRTXEQCCfMpo7bK8Zusr2Dsre2OuhcJL4gzsheT8k.AfGNdGd1dHYgkntc8NfR ly4oHY.ddfoZ457S4Rny_4_wyUwWiyeut8NTmQMm8czQmf3nqPBOER6B5t0iYs92NL0.C1qgGPAk eDptwi.r9OdYSf8dH0frKFfMp3PrAkF7xVGhgKmEomWT8XT5E4tb4muUem8N9aMQsxbPKSIeqHJM 3e6sWpgWyloNRnBF9AIWkRbsI2sByA91AEkhg2EoYR2GdLfdRkeuVcjDehSDv7984TCsqvGYYZCg LPhvY31vV5WRahx_a1VLobKzCV37QKuWpA4sPK62KWcCWqOl9UM20z5yvapV22qVnk2zasVMkzot znM00UZv2eOjJ_MWGe4FFOz78tZa1rHdhX_O4jI.430RlpAckl0nCq_grB3rJeyjw3rR0Z0LO5gx NXyKk9E1335WVa43xCZx4MgpdmP4zSMqz36qfdsklBvsUSLKWJabjOhlhKMy_40KCddfsJB3pVup qUWCWZ4FBWHojgzfXngiZxYi00KvHHr8xI.11uGlaOvtRB49ic0.Qk8bICWpzWX79BatCf2mOjxB izYJ2NRjY5M8yLpxa.jH25T1Cs1yodwLzrRl102YbIha5WlLa1po2bQhbdTur2Pq00vVOaFTNpuT yI8P7mMdpFCRGQhPbS.MWwvKqi8XsieD2AHymtO1MgbChsaoEEKzr5wXO6WXmfEwFkLRP9SpZNwW 05EQW3weXWd2TEXrgJOo7YaNxbc8lanxj4hfqxpKqlS4b3ccfzj1RU09KIU4EQL5UMxEH8GwwE7b qLrwTCky8sJgPAjAgE_lyOw5Uet.0Hj706MvjdgN7HteibcFZfFdU_W.HrbUcK9w_6Q0IrdaKNwd aHHJdA4FljyzF7QrJSErcCh2SvvNXY79d7rjgAO9EJPaQW2U01OATxeKmV4VOiaFxqI0cSrqWru0 9CqOr4deUNu0qp8LkqThWzr1a1bJJAP1MsgvLaWheFO3yZA8EnsmvT6rAryRZPHWYWwhlFlsaeYQ zFtbCW.VK4poNnHpHMk2p1MIvWUdEAfBgCPuy1ffG9aEr2ZTegU4XSU9yzmFisNUOkHgLcgXdgBX Ei.0k59yoQ4mhTGrykaci.uBElBs3t6ZYXTFAA0jZ5jA9mOxxwp_NPgUC.qtJm3Jqy61yhkB1VSq NS_Ubg8tHKU1ZIgPHHAy5UjbpX.HZ2QvVkXa0lfZxbuL1IpyLDMim5ua4uPXXY3zL19KE4XemCDb 7Fd.BSNGoQVy8HtAoy6PkrkAdKeQtIgI6DwXNLLmz5fKXKaywZWLFjZ0QVTaI2XwrtKz9.q14Jjb m_fqHcIpEuIHlkO4mreIxGO_WuO79ujOG6URWa3lDklsO1CPGq7QKwzwd7UhIpEy_rqGzq0LOyXt SlPqnFahrIhRon3GBa8MNxKCWauBh6XJ5muCXquB5nlgBg7nZ_NjtDnLq_AUFmXL71v1CblxsT7r dbWuD0qtBXxxnS4p.0BCrjj_Jci1e81jCfTpuc6AAusU58GwTpRCj2LXrqv4OzK3N3pw9AH6ny5K eM_6U0IOBMm29T2ojqxQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Apr 2022 01:33:23 +0000 Received: by hermes--canary-production-ne1-75b69fcf97-h6f5j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 05dc40ebe77b86bded1a115a92ae61b4; Wed, 27 Apr 2022 01:33:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries From: Mark Millard In-Reply-To: Date: Tue, 26 Apr 2022 18:33:15 -0700 Cc: jbo@insane.engineer Content-Transfer-Encoding: quoted-printable Message-Id: <000ACC55-4740-4624-A0E3-24AB775929A1@yahoo.com> References: To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kp1VM2tfsz3pdh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=X4j9a+F8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-26, at 17:48, Mark Millard wrote: >=20 > =E2=80=A2 Joerg Sonnenberger wrote on > =E2=80=A2 Date: Tue, 26 Apr 2022 23:47:23 UTC : >=20 >> Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard: >>> Basically I avoid inline definitions of: >>>=20 >>> virtual ~type_base(); >>> virtual ~type_int(); >>> virtual ~type_string(); >>=20 >> You only need to ensure that the class has one non-pure non-inline >> function. >=20 > I'm confused at what you are claiming that I did wrong or > described incorrectly for the example at hand. Those are 3 > separate classes each with one virtual method that is not > in line (and that I showed the definitions for later in > the message). No other such functions were involved explicitly > in those 3 classes. >=20 > The gcc class type_info in /usr/local/lib/gcc11/include/c++/typeinfo > describes this implementation detail for type_info itself, as its > example, via: >=20 > class type_info > { > public: > /** Destructor first. Being the first non-inline virtual function, = this > * controls in which translation unit the vtable is emitted. The > * compiler makes use of that information to know where to emit > * the runtime-mandated type_info structures in the new-abi. */ > virtual ~type_info(); > . . . May be the intent is tied to what happens with a one line change, using struct type_base { ~type_base() =3D 0; }; but still having the required definition: interface::type_base::~type_base() {} (implicitly referenced so required in order to link). This makes type_base abstract (not something to potentially directly create). The original example did not have that property, so I did not make my nearly minimal change that way. But using the '=3D 0' as above does produce a working program: # ./test-core=20 t is type_int t is type_string done. >> That's the key function and determines the translation unit >> (and by extension the DSO) where the virtual table and the typeinfo = is >> placed. >=20 > I'm a again confused about where the above disagrees with > what I wrote (in text that you did not quote). >=20 >> If there is no such function, both will be defined as weak >> mergable symbol and that will not result in a unique address when = using >> RTLD_LOCAL. >=20 > I was certainly less detailed about how multiple definitions > are handled. Was that your point? >=20 > Let me know if I've missed some import point --or made some > stupid screwup in what I'd written. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Apr 27 14:30:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5AFFA199F14D for ; Wed, 27 Apr 2022 14:30:22 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpLkj6nPDz3MPZ for ; Wed, 27 Apr 2022 14:30:21 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=email1; h=Content-Transfer-Encoding:Content-Type:Subject:From:To: Mime-Version:Date:Message-Id:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+vRMdI2EcMYxmez/hKIFR1ymiEt90/ITpWzyp8LFkN0=; b=g2tzlsLZi3S6Ue5soMVwzWL4pL SwnRnkP2pYQF97y2LdOaWO3QYMNPX+Gzei8NWG5a1mmf1YF56gyks/O0c8HAF2QypqPv8sTqItww1 eJKeowKQcJoJlvIdUdK30NDt0708Ppaa2ssEQXEopCaG4/iApd7orlSlkKOzG0IyRqbd5doc7vWVN 4ygfofq1DRxBlrLQRD1COfVEw/NGZN3HRxw1HNVFVUywLs82GIMmx87toC8bqt5elXF3kAIwjsO9T 3K1Vdl6YYFT5tnJrZlSLlsHQ4Uwa8lFAgG/clgoKfY401K1UEC7vYgMuJyTBO8e5MP16kCxKUh+yy BuVLVwgw==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1njigP-0002Nc-6n for freebsd-hackers@freebsd.org; Wed, 27 Apr 2022 14:30:21 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1651069820-77982-77189/7/4; Wed, 27 Apr 2022 14:30:20 +0000 Message-Id: Date: Wed, 27 Apr 2022 16:30:20 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: de-DE To: freebsd-hackers@freebsd.org From: Axel Rau Subject: rc script to let a service wait for db available Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KpLkj6nPDz3MPZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=email1 header.b=g2tzlsLZ; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=email1]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:5::73:from]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[Chaos1.DE]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.998]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-0.90)[-0.902]; DKIM_TRACE(0.00)[chaos1.de:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[chaos1.de:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi all, I have this rc script: - - - meteoavg_wfphost=3D"dbb3" meteoavg_wfpuser=3D"meteo" meteoavg_wfpdb=3D"operations" # # . /etc/rc.subr name=3D"meteoavg" rcvar=3D${name}_enable command=3D/usr/local/bin/meteoavg load_rc_config $name : ${meteoavg_enable=3D"NO"} : ${meteoavg_flags=3D" -l syslog:daemon -s Chaos1"} : ${meteoavg_pidfile=3D"/var/run/meteoavg-Chaos1.pid"} pidfile=3D"${meteoavg_pidfile}" ##start_cmd=3D"${name}_start" stop_precmd=3D"${name}_prestop" meteoavg_start() { /usr/local/bin/wait_for_pgsql.sh ${meteoavg_wfphost} \ ${meteoavg_wfpuser} ${meteoavg_wfpdb} \ "/usr/local/bin/${name} ${meteoavg_flags} &" } meteoavg_prestop() { /bin/pkill wait_for_pgsql.sh || /usr/bin/true } - - - wait_for_pgsql.sh : - - - #!/bin/sh host=3D"$1" user=3D"$2" db=3D"$3" start_cmd=3D"$4" while ! /usr/local/bin/psql -h $host -U $user -d $db -c 'SELECT 1;'=20 >/dev/null 2>&1; do sleep 5 done $start_cmd - - - The rc ignores the '&' and waits for wait_for_pgsql.sh to complete. How can I let rc continue without waiting? Any help appreciated, Axel =2D-=20 PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius From eugen@grosbein.net Wed Apr 27 14:37:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FEF91AA9654 for ; Wed, 27 Apr 2022 14:38:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpLvd0PWMz3P9K for ; Wed, 27 Apr 2022 14:38:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23REbtf9088122 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Apr 2022 14:37:56 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Axel.Rau@Chaos1.DE Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23REbUOb095061 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 27 Apr 2022 21:37:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: rc script to let a service wait for db available To: Axel Rau , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Wed, 27 Apr 2022 21:37:19 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KpLvd0PWMz3P9K X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.36 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.67)[0.665]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.93)[-0.926]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 27.04.2022 21:30, Axel Rau wrote: > Hi all, > > I have this rc script: > - - - > meteoavg_wfphost="dbb3" > meteoavg_wfpuser="meteo" > meteoavg_wfpdb="operations" > # > # > > . /etc/rc.subr > > name="meteoavg" > rcvar=${name}_enable > command=/usr/local/bin/meteoavg > > load_rc_config $name > > : ${meteoavg_enable="NO"} > : ${meteoavg_flags=" -l syslog:daemon -s Chaos1"} > > : ${meteoavg_pidfile="/var/run/meteoavg-Chaos1.pid"} > > pidfile="${meteoavg_pidfile}" > > ##start_cmd="${name}_start" > stop_precmd="${name}_prestop" > > meteoavg_start() { > /usr/local/bin/wait_for_pgsql.sh ${meteoavg_wfphost} \ > ${meteoavg_wfpuser} ${meteoavg_wfpdb} \ > "/usr/local/bin/${name} ${meteoavg_flags} &" > } > - - - > The rc ignores the '&' and waits for wait_for_pgsql.sh to complete. > > How can I let rc continue without waiting? You need to place '&' outside of double-quotes. But better use daemon(8) command instead of '&' because daemon does better job ignoring signals etc. and that may be important if wait time extends past point when system goes to multiuser mode. From nobody Wed Apr 27 17:16:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A6238199C469; Wed, 27 Apr 2022 17:17:17 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpQRJ6zQYz4bCs; Wed, 27 Apr 2022 17:17:13 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-pf1-x432.google.com with SMTP id j17so2114892pfi.9; Wed, 27 Apr 2022 10:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1EbO0xksIr3O2ad8Y8L8CNjvNRsFg3NXO3c71KZgOWk=; b=CnEiqF8yfU3DV4aj3ew57X7kqpbN06kC0lLA0KrMzz9txql4c1SBFo/JZZcXgGuJI0 zWTQ0BKNJondHaLlTW4t4pQLiVN2PeKHni91cjtEOD/FGjeWmKG/mQnuKjQG/+PplWG6 Yeh3CBSO+PSUf3E9zoSQ4I4RbdS7egod64clXLGfTYKrXEF+cGKXfJNr5jVUhKxjFFjx jTWaUI4eIcwYGqyQrMSzkmvO/kX+rLnjdd8zd1NYN3DJasqjFHIbOZ3VcaoVSFUYNODF NUWKCZfkZ8u7QI2s8sTQgzS4Y5ul0AK/dubWUXc34WrPwa/+b4Zg+bow7rOu5oQRxzlQ bd3Q== 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=1EbO0xksIr3O2ad8Y8L8CNjvNRsFg3NXO3c71KZgOWk=; b=RVIIpVnZAKsg/diKqZB51iyfbivTREs5aQDvX6L9V1gZceJY55MdGZU2g5FgrKS/gX OweIN6tMZWWucMd2FEHUqVW7GLbwyqzuA2O2kz/I6OVyDlGW6SRpDhkxsd2jMx+eVT9S DLdViMr4E7bkzRE4AssjCqoAVkvE9I/19wfbWwTmq5JK4wFYsUkfw4Xs4no5Ihg9QhKE FVtWuuQdfNoaz6V0c5cocWhu4A4fVH5BrkdWWWA153y4xXtpsDW7OkhyBDCB/Utl+ihG TXMAwvgkA4N+v+UWkSQ74f3Pbw6q6OxgT6I+aQLcvLgh+auHqTkL2c28+JrpxYkmblmM ++Eg== X-Gm-Message-State: AOAM533X8GMoxWgFl/WRW77kSc7xsC3qxPjxM/CYAEZrj7vsEQe6WFaJ FoTyfJ5205+1mrNwQ1MDBg7zfeYaLBSDVw+niwi3PXHGQX1Sww== X-Google-Smtp-Source: ABdhPJyws+3pkLKNyaO/yxS7b1X2yjw9qj9Uj7TX4iIC95/cMq6jUn/7+WAbgP30VMfmveOq1o5HeaLzUegP0GvtkYI= X-Received: by 2002:a63:5917:0:b0:39c:c450:3143 with SMTP id n23-20020a635917000000b0039cc4503143mr24739852pgb.531.1651079827073; Wed, 27 Apr 2022 10:17:07 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Luna Jernberg Date: Wed, 27 Apr 2022 19:16:54 +0200 Message-ID: Subject: Re: FreeBSD and FreeBSD Foundation on the first FLOSS Weekly 2022 To: freebsd-women@freebsd.org, freebsd-chat@freebsd.org, freebsd-hackers@freebsd.org, Martin Jernberg Content-Type: multipart/alternative; boundary="00000000000096aeea05dda5fa35" X-Rspamd-Queue-Id: 4KpQRJ6zQYz4bCs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CnEiqF8y; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::432 as permitted sender) smtp.mailfrom=droidbittin@gmail.com X-Spamd-Result: default: False [-2.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.51)[0.512]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::432:from]; MLMMJ_DEST(0.00)[freebsd-women,freebsd-chat,freebsd-hackers]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000096aeea05dda5fa35 Content-Type: text/plain; charset="UTF-8" https://www.opensourcevoices.org/29 Deb in Open Source Voices this week On Wed, Jan 5, 2022 at 11:45 PM Luna Jernberg wrote: > https://twit.tv/shows/floss-weekly/episodes/662?autostart=false > > Deb Godkin from FreeBSD Foundation, guests the first FLOSS Weekly of this > year and talks FreeBSD and BSD > --00000000000096aeea05dda5fa35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
https://ww= w.opensourcevoices.org/29 Deb in Open Source Voices this week
=
On Wed= , Jan 5, 2022 at 11:45 PM Luna Jernberg <droidbittin@gmail.com> wrote:
http= s://twit.tv/shows/floss-weekly/episodes/662?autostart=3Dfalse=C2=A0
=

Deb Godkin from FreeBSD Foundation, guests the first FL= OSS Weekly of this year and talks FreeBSD and BSD=C2=A0
--00000000000096aeea05dda5fa35-- From nobody Wed Apr 27 22:13:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 715041992710 for ; Wed, 27 Apr 2022 22:13:49 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpY1S2ZKfz3vwR for ; Wed, 27 Apr 2022 22:13:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: (Authenticated sender: joerg@bec.de) by mail.gandi.net (Postfix) with ESMTPSA id B3068FF802 for ; Wed, 27 Apr 2022 22:13:39 +0000 (UTC) Date: Thu, 28 Apr 2022 00:13:37 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: llvm & RTTI over shared libraries Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4KpY1S2ZKfz3vwR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of joerg@bec.de has no SPF policy when checking 2001:4b98:dc4:8::229) smtp.mailfrom=joerg@bec.de X-Spamd-Result: default: False [-2.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; FREEFALL_USER(0.00)[joerg]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[bec.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::229:from] X-ThisMailContainsUnwantedMimeParts: N Am Tue, Apr 26, 2022 at 05:48:00PM -0700 schrieb Mark Millard: > • Joerg Sonnenberger wrote on > • Date: Tue, 26 Apr 2022 23:47:23 UTC : > > > Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard: > > > Basically I avoid inline definitions of: > > > > > > virtual ~type_base(); > > > virtual ~type_int(); > > > virtual ~type_string(); > > > > You only need to ensure that the class has one non-pure non-inline > > function. > > I'm confused at what you are claiming that I did wrong or > described incorrectly for the example at hand. I'm giving the exact rule to make sure the OP knows what exactly to follow. Otherwise they can test a chance, discover that in their use case an inlined dtor actually works because something else is the key function etc. I don't disagree with your example, I just want to make sure that it is understood what the critical point is. > > If there is no such function, both will be defined as weak > > mergable symbol and that will not result in a unique address when using > > RTLD_LOCAL. > > I was certainly less detailed about how multiple definitions > are handled. Was that your point? I added that note because it also tells you what symptoms to look for to diagnose the issue. E.g. it is normally a bad sign in C++ to see weak vtable and type symbols and something that should be checked. Joerg From nobody Thu Apr 28 08:55:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6C0AD1AB1219 for ; Thu, 28 Apr 2022 08:55:32 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KpqFv37cGz4q6h for ; Thu, 28 Apr 2022 08:55:31 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=email1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:Mime-Version:Date:Message-Id:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DZh141oTBQ7I7MxPOVdVY+jcgcE+LQ6beq5CGkhXHlM=; b=qzy2nnyzRe5UsDOtvdZqxVTe3T tUegPL4elUHQ8YLjTOoiuIK+ywNZLhtDv/Hj02zJLQw+4ub6Ks6cSiB1wFPWnfQPmLeHvB6CJLxcA 3VHHKkr7aXxBRHazpfcBTADL5l7e+mNhwNp99KlyYJaWwmGlEit5Oq74aTJXtMk63WluojoU0N4xa rhxkt77GxIROPc/lAgQI6T6num6IQu4pHGSbn2pkedZphj4qnrSFpNBSthe5vzm4nMN8ycnUTTsb6 PvBUeDEHY7J5giNOceWTv+tYqeSE1vGlBKsapOlSB3zgy9meivboZ0N4im9nyxMOklhu975qIScHF dGMK8bag==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1njzvu-000Oa5-81; Thu, 28 Apr 2022 08:55:30 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1651136129-83503-82811/7/4; Thu, 28 Apr 2022 08:55:29 +0000 Message-Id: Date: Thu, 28 Apr 2022 10:55:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: rc script to let a service wait for db available Content-Language: de-DE To: Eugene Grosbein , freebsd-hackers@freebsd.org References: From: Axel Rau In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KpqFv37cGz4q6h X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=email1 header.b=qzy2nnyz; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=email1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[chaos1.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[chaos1.de:dkim]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:5::73:from] X-ThisMailContainsUnwantedMimeParts: N Am 27.04.22 um 16:37 schrieb Eugene Grosbein: >=20 > You need to place '&' outside of double-quotes. > But better use daemon(8) command instead of '&' > because daemon does better job ignoring signals etc. > and that may be important if wait time extends past point when system = goes to multiuser mode. Ah - yes. Now it calls the script in the background, but there is still=20 an issue. It does not start the server, as it does while calling from the command=20 line. I will investigate daemon(8). Thanks a lot, Axel =2D-=20 PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius From eugen@grosbein.net Thu Apr 28 09:53:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C96C41ABBF88 for ; Thu, 28 Apr 2022 09:54:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KprYj0yHfz3DnX for ; Thu, 28 Apr 2022 09:54:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23S9sCUh000363 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Apr 2022 09:54:13 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Axel.Rau@chaos1.de Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23S9rlQ5005646 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 28 Apr 2022 16:54:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: rc script to let a service wait for db available To: Axel Rau , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Thu, 28 Apr 2022 16:53:42 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4KprYj0yHfz3DnX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 28.04.2022 15:55, Axel Rau wrote: > Ah - yes. Now it calls the script in the background, but there is still an issue. > It does not start the server, as it does while calling from the command line. Generally it means bugs in the startup script: it relies on calling process environment like PATH, LANG etc. It must not. It must set needed variables all by itself starting from PATH. From nobody Thu Apr 28 14:46:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D52451A11E10 for ; Thu, 28 Apr 2022 14:46:10 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kpz2V0Pr6z4SwC for ; Thu, 28 Apr 2022 14:46:10 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=email1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:Mime-Version:Date:Message-Id:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=P1kIh0CCk6s4OLEp1fKtoCAm31vynGeWwc/vOL8iOXw=; b=WlsuBVgBF5jA1yYopNIqAolFeM FQkWYjfeJXE10g7KNV4xdXqJabDIyHKYfqixLb4pxX1hInyjC6Ems7FjNBII0ePVl5YvbcFJVEV3Z r+H8IlgqE8RZcgpirFUlSUyBqQHl92NJiPq0rsV+IxfE6tjW4ruSYnNnaUJQlII84uCjW7e6X6hvB n6MQddpTua9Uo3dK/hLaAnmA5ZYyK0/JCF8t1kIoiP6/Y5wWerdqb9E+4+p5jyaZKqItQY4VNJ9jn peaQXpnF0fnb7wBSXWAmXXDJRC2aNvx9EjmSjxN4vSh/icqZykHunvLmrksU6VZXeN/tCSCeJ/FT6 ENv8J/ug==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nk5PE-0001bO-8K; Thu, 28 Apr 2022 14:46:08 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1651157167-83419-82811/7/10; Thu, 28 Apr 2022 14:46:07 +0000 Message-Id: Date: Thu, 28 Apr 2022 16:46:07 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: [RESOLVED] Re: rc script to let a service wait for db available Content-Language: de-DE To: Eugene Grosbein , freebsd-hackers@freebsd.org References: From: Axel Rau In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Kpz2V0Pr6z4SwC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=email1 header.b=WlsuBVgB; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-2.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=email1]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:5::73:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[Chaos1.DE]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[chaos1.de:dkim] X-ThisMailContainsUnwantedMimeParts: N Am 28.04.22 um 11:53 schrieb Eugene Grosbein: > 28.04.2022 15:55, Axel Rau wrote: >=20 >> Ah - yes. Now it calls the script in the background, but there is = still an issue. >> It does not start the server, as it does while calling from the = command line. >=20 > Generally it means bugs in the startup script: it relies on calling = process environment > like PATH, LANG etc. It must not. It must set needed variables all by = itself > starting from PATH. Now, after everything is in place, it works as expected. Many thanks, Axel =2D-=20 PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius From nobody Thu Apr 28 17:40:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F33B199F696 for ; Thu, 28 Apr 2022 17:40:16 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from wilbur.contactoffice.com (wilbur.contactoffice.com [212.3.242.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kq2vM54XPz4tBP for ; Thu, 28 Apr 2022 17:40:15 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from ichabod.co-bxl (ichabod.co-bxl [10.2.0.36]) by wilbur.contactoffice.com (Postfix) with ESMTP id 599831176; Thu, 28 Apr 2022 19:40:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1651167614; s=20210208-e7xh; d=mailfence.com; i=sysadmin.lists@mailfence.com; h=Date:From:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc; l=1166; bh=BSqg2qIiAA+YsuAXBDljTZoGUIJlgLktZkfsyqrqv5o=; b=qOiqkcdV2XG0cIwspFAaiKDrtXPApch2C0DNBuVAytSxU4FtBi2oJPMUVRibYP1t haeLK6H5XvEpokvk/Mb8r1YRfob/xPAGsaWwd0NzepQwTbqsgABTtGU0SENV5tgf/in XtQ0zxjpTrFAf7aBoK2mVY7sjki2vTtdjxJj73K3rEm4RpUjqnmJF9nEoeoWzmXuaR5 V8XqRVZ+tSowVkx0IPLsMUAtzm+hOUwTrvhof7/QM/3Y/tLkkRbZ73uyPkQ5hfSqK5U sFGbNbHQr2NT3Poo22YXJ89InzvBleNwyaeonrFRWXVau3OyDujdOH4cvMnF8VCn1+P oig1WcBMFw== Date: Thu, 28 Apr 2022 19:40:12 +0200 (CEST) From: Sysadmin Lists To: freebsd-hackers@freebsd.org Message-ID: <187283243.91660.1651167612801@ichabod.co-bxl> In-Reply-To: References: Subject: Re: rc script to let a service wait for db available List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Eugene Grosbein , Axel Rau X-Mailer: ContactOffice Mail X-ContactOffice-Account: com:312482426 X-Rspamd-Queue-Id: 4Kq2vM54XPz4tBP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailfence.com header.s=20210208-e7xh header.b=qOiqkcdV; dmarc=pass (policy=quarantine) header.from=mailfence.com; spf=pass (mx1.freebsd.org: domain of sysadmin.lists@mailfence.com designates 212.3.242.68 as permitted sender) smtp.mailfrom=sysadmin.lists@mailfence.com X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.3.242.64/26:c]; R_DKIM_REJECT(0.00)[mailfence.com:s=20210208-e7xh]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[mailfence.com:-]; DMARC_POLICY_ALLOW(0.00)[mailfence.com,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[212.3.242.68:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:10753, ipnet:212.3.242.64/26, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N This isn't entirely true. rc scripts have a default PATH and HOME. From service(8): ENVIRONMENT When used to run rc.d scripts the service command sets HOME to / and PATH to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at boot time. Something similar holds true for `cron' as well. I see a lot of unnecessary setting of absolute paths for binaries that reside in default PATHs. > ---------------------------------------- > From: Eugene Grosbein > Sent: Thu Apr 28 11:53:42 CEST 2022 > To: Axel Rau , > Subject: Re: rc script to let a service wait for db available > > > 28.04.2022 15:55, Axel Rau wrote: > > > Ah - yes. Now it calls the script in the background, but there is still an issue. > > It does not start the server, as it does while calling from the command line. > > Generally it means bugs in the startup script: it relies on calling process environment > like PATH, LANG etc. It must not. It must set needed variables all by itself > starting from PATH. > > > -- Sent with https://mailfence.com Secure and private email From eugen@grosbein.net Thu Apr 28 20:49:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4DA9D199EA35 for ; Thu, 28 Apr 2022 20:50:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kq76H2DTNz3sKS for ; Thu, 28 Apr 2022 20:49:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 23SKnmiC003397 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Apr 2022 20:49:49 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: sysadmin.lists@mailfence.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 23SKnMeW009750 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 Apr 2022 03:49:47 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: rc script to let a service wait for db available To: Sysadmin Lists , freebsd-hackers@freebsd.org References: <187283243.91660.1651167612801@ichabod.co-bxl> Cc: Axel Rau From: Eugene Grosbein Message-ID: <327ac19c-8617-f784-9591-5458e6c47eaa@grosbein.net> Date: Fri, 29 Apr 2022 03:49:16 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <187283243.91660.1651167612801@ichabod.co-bxl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4Kq76H2DTNz3sKS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 29.04.2022 0:40, Sysadmin Lists wrote: > This isn't entirely true. rc scripts have a default PATH and HOME. From service(8): > > ENVIRONMENT > When used to run rc.d scripts the service command sets HOME to / and PATH > to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at > boot time. > > Something similar holds true for `cron' as well. I see a lot of unnecessary setting of > absolute paths for binaries that reside in default PATHs. When default environment satisfies the service, if does not fail being started at boot time. If it runs just fine being started from logged-in user environment but not at boot time, it is environment problem, in broad meaning. From nobody Fri Apr 29 18:34:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B4D2C1994191 for ; Fri, 29 Apr 2022 18:34:13 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from wilbur.contactoffice.com (wilbur.contactoffice.com [212.3.242.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kqh386520z4qqT for ; Fri, 29 Apr 2022 18:34:12 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from ichabod.co-bxl (ichabod.co-bxl [10.2.0.36]) by wilbur.contactoffice.com (Postfix) with ESMTP id 06FC4C20; Fri, 29 Apr 2022 20:34:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1651257245; s=20210208-e7xh; d=mailfence.com; i=sysadmin.lists@mailfence.com; h=Date:From:Cc:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1281; bh=hZk6F2ZOWefJQyBoEZi3jLS8xJY5HoTu2ZvySDD1x9Q=; b=TnxUi5YmTlKllhBdQbjc7az8MTXG6y9gHH1QSYsPN0YdLLoZTb7/cKfjvCIVmkjw pwBs9Cb5/7OaWrDvMl/ul7JUduor4M6FbZgxBkifGCwlUcVPwvNm44KubHS1kNP9NjT JSbmQUys7qUYYSL1KAM5u3RR9oLsJPRT+MGetE5+F03XBv/VmysVdUlBY6k94ysYYvh fZS9ANTxEhkXwICzNShfokKxqSfwhX7PZfygpf10/0HGiEWnmpnntCtA6EKJY0jrWj1 k2VM1d3aMMPsQlPjG6ZUbnkaRMgENXxEIzLH4TJJRJXdOTcUyPHc5BviGtkFW/YkVAi 5HNTDXoghQ== Date: Fri, 29 Apr 2022 20:34:02 +0200 (CEST) From: Sysadmin Lists To: freebsd-hackers@freebsd.org, Eugene Grosbein Cc: Axel Rau Message-ID: <1022212612.357445.1651257242518@ichabod.co-bxl> In-Reply-To: <327ac19c-8617-f784-9591-5458e6c47eaa@grosbein.net> References: <187283243.91660.1651167612801@ichabod.co-bxl> <327ac19c-8617-f784-9591-5458e6c47eaa@grosbein.net> Subject: Re: rc script to let a service wait for db available List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: ContactOffice Mail X-ContactOffice-Account: com:312482426 X-Rspamd-Queue-Id: 4Kqh386520z4qqT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailfence.com header.s=20210208-e7xh header.b=TnxUi5Ym; dmarc=pass (policy=quarantine) header.from=mailfence.com; spf=pass (mx1.freebsd.org: domain of sysadmin.lists@mailfence.com designates 212.3.242.68 as permitted sender) smtp.mailfrom=sysadmin.lists@mailfence.com X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.3.242.64/26]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_REJECT(0.00)[mailfence.com:s=20210208-e7xh]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[mailfence.com:-]; DMARC_POLICY_ALLOW(0.00)[mailfence.com,quarantine]; RCVD_IN_DNSWL_NONE(0.00)[212.3.242.68:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:10753, ipnet:212.3.242.64/26, country:US]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > ---------------------------------------- > From: Eugene Grosbein > Sent: Thu Apr 28 22:49:16 CEST 2022 > To: Sysadmin Lists , > Cc: Axel Rau > Subject: Re: rc script to let a service wait for db available > > > 29.04.2022 0:40, Sysadmin Lists wrote: > > > This isn't entirely true. rc scripts have a default PATH and HOME. From service(8): > > > > ENVIRONMENT > > When used to run rc.d scripts the service command sets HOME to / and PATH > > to /sbin:/bin:/usr/sbin:/usr/bin which is how they are set in /etc/rc at > > boot time. > > > > Something similar holds true for `cron' as well. I see a lot of unnecessary setting of > > absolute paths for binaries that reside in default PATHs. > > When default environment satisfies the service, if does not fail being started at boot time. > If it runs just fine being started from logged-in user environment but not at boot time, > it is environment problem, in broad meaning. > > You're right. I misread what you were saying. You were addressing the specific failure the OP was describing, not saying PATH must always be set manually. -- Sent with https://mailfence.com Secure and private email From nobody Mon May 2 13:36:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 57E221AB0845; Mon, 2 May 2022 13:42:10 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu1208c.smtpx.saremail.com (cu1208c.smtpx.saremail.com [195.16.148.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsPQm5j8cz3pJN; Mon, 2 May 2022 13:42:08 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend02.sarenet.es (Postfix) with ESMTPA id 1365560C0D5; Mon, 2 May 2022 15:36:23 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_672a997159081f6af8e5fa01d8fde077" Date: Mon, 02 May 2022 15:36:23 +0200 From: egoitz@ramattack.net To: egoitz@ramattack.net Cc: Stefan Esser , freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, Rainer Duffner , owner-freebsd-hackers@freebsd.org Subject: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <3d24c87110b4a155e3f14d53a9309c61@ramattack.net> Message-ID: <32cb580b30636082108a070ee009fdb9@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KsPQm5j8cz3pJN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.148.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.148.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; RCPT_COUNT_SEVEN(0.00)[7]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_672a997159081f6af8e5fa01d8fde077 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Matthias, I apologize if these emails were annoying for reading or similar... due to the html, top posting etc... but... in a so large mail thread, how could one properly differ one answer from the other one.. how could you highlight some sentences for keeping attention between relevant parts and so... it's difficult.... Anyway, very very sorry for having caused some noise... Best regards, El 2022-04-08 20:00, Matthias Apitz escribió: > ATENCION > ATENCION > ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro. > > Hello egoitz@ramattack.net, > > Please be so kind and stop sending mails in HTML and stop top posting. > Thanks in advance > > matthias --=_672a997159081f6af8e5fa01d8fde077 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi Matthias,


I apologize if these emails were annoying for reading or similar... due = to the html, top posting etc... but... in a so large mail thread, how could= one properly differ one answer from the other one.. how could you highligh= t some sentences for keeping attention between relevant parts and so... it'= s difficult....


Anyway, very very sorry for having caused some noise...


Best regards,


El 2022-04-08 20:00, Matthias Apitz escribió:

= ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde f= uera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no= ser que reconozca el remitente y sepa que el contenido es seguro.

Hello egoitz@ramattack= =2Enet,

Please be so kind and stop sending mails in HTML a= nd stop top posting.
Thanks in advance

   = ; matthias
=  
--=_672a997159081f6af8e5fa01d8fde077-- From nobody Mon May 2 18:24:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8692B1AB895B; Mon, 2 May 2022 18:24:28 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsWhW36J3z3nj3; Mon, 2 May 2022 18:24:27 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:c0c4:7b61:cb80:fb4f] ([IPv6:2001:470:71:d47:c0c4:7b61:cb80:fb4f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 242IOHJb088391 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 May 2022 20:24:17 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651515858; bh=eVYGuQjYpl+dMQKz54RSlhtJMiVJmn4HHNyTRr0EaoI=; h=Date:From:To:Subject; b=A0v27+Ci0K2u/kI+zNvQS4b6JYcwLfvVmejjdZ3Qnr63oKPLx62wZ0VPDLkzimByl kGqgwC2U2T7kMB3SNDEeXv1EISM39ameBCCsrZpRDx9KQEl1wK41IsieDEFQg+uhO1 9PbVp/b46tC3n14O1n7KeEKtQ7ngkDJ7iKnA1WwxeqF+cf++7JieH8PYX65igJy/Ml OLZrdwAL/XliBeanPQPzINNTAYYHbAHpAZwyQItWPfTjA/i8y3TNrSKh59ly+fAYAt rSSmBdjXzMW3/8iZngAMLcxVxGrckMIx/Fikq4uL7bWp/x84PnpAsnZBRdteT0+DLC xV/sfKi0ZbCHw== Content-Type: multipart/alternative; boundary="------------NihIw8oFMGKyRecHWZphbckN" Message-ID: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> Date: Mon, 2 May 2022 20:24:17 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 From: Marek Zarychta Content-Language: en-US To: freeBSD Current , freebsd-hackers@freebsd.org Subject: discussion on future removal of empty $FreeBSD$ tags X-Rspamd-Queue-Id: 4KsWhW36J3z3nj3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=A0v27+Ci; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------NihIw8oFMGKyRecHWZphbckN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear subscribers, after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why. After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier). Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase. Best regards, Marek Zarychta [1] https://cgit.freebsd.org/src/commit/?id=835ee05f [2] ######################################################## # # FreeBSD Git src with worktrees and clean/smudge filters # for mergemaster(8) # ######################################################## # Preparation of the tree zfs create zroot/usr/src_head zfs create zroot/usr/src_13 ######################################################## # Making src of stable/13 mountable in /usr/src echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab mount -al ######################################################## # Cloning the repository cd /usr/src_head git clonehttps://git.freebsd.org/src.git/ ./ ######################################################## # Adding filters # Filters require lang/ruby and lang/perl installed git config filter.freebsdid.smudge expand_freebsd git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' ######################################################## # Limiting filters scope # In /usr/src_head create file .git/info/attributes with # following contents (at least): ------------cut------------ cat > .git/info/attributes << EOF etc/* filter=freebsdid etc/*/* filter=freebsdid libexec/rc/* filter=freebsdid libexec/rc/rc.d/* filter=freebsdid *.conf filter=freebsdid dot.??* filter=freebsdid lib/libc/gen/shells filter=freebsdid lib/libc/net/hosts filter=freebsdid lib/libpam/pam.d/* filter=freebsdid lib/libwrap/hosts.allow filter=freebsdid usr.sbin/services_mkdb/services filter=freebsdid usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid usr.sbin/periodic/etc/* filter=freebsdid usr.sbin/cron/cron/crontab filter=freebsdid crypto/openssh/ssh*_config filter=freebsdid EOF ------------cut------------ ######################################################## # Smudge filter setup # Create file /usr/local/bin/expand_freebsd with following # contents and make it executable. ------------cut------------ #!/usr/bin/env ruby data = STDIN.read last_info = `git log --pretty=format:"%h %ae %ad" -1` puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') ------------cut------------ chmod a+x /usr/local/bin/expand_freebsd ######################################################## # Adding worktrees # Add worktree for stable/13, filters will be applied git worktree add /usr/src_13 stable/13 # To have IDs in main (HEAD) # do checkout of filtered files again cd /usr/src_head rm etc/master.passwd etc/group rm libexec/rc/rc.d/* git checkout -f -- . ######################################################## # To find more files with $FreeBSD tags which might # be added to .git/info/attributes file issue command: find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' -- Marek Zarychta --------------NihIw8oFMGKyRecHWZphbckN Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters 
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
 
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/fstab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone https://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with 
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=freebsdid
etc/*/*                 filter=freebsdid
libexec/rc/*            filter=freebsdid
libexec/rc/rc.d/*       filter=freebsdid
*.conf                  filter=freebsdid
dot.??*                 filter=freebsdid
lib/libc/gen/shells     filter=freebsdid
lib/libc/net/hosts      filter=freebsdid
lib/libpam/pam.d/*      filter=freebsdid
lib/libwrap/hosts.allow filter=freebsdid
usr.sbin/services_mkdb/services filter=freebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid
usr.sbin/periodic/etc/* filter=freebsdid
usr.sbin/cron/cron/crontab filter=freebsdid
crypto/openssh/ssh*_config filter=freebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following 
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data = STDIN.read
last_info = `git log --pretty=format:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd 

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD) 
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group 
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command: 

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' 

-- 
Marek Zarychta
--------------NihIw8oFMGKyRecHWZphbckN-- From nobody Mon May 2 20:09:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 29B601AB26E9 for ; Mon, 2 May 2022 20:09:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsZ1y0pZ9z4gDK for ; Mon, 2 May 2022 20:09:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id e144so7072076vke.9 for ; Mon, 02 May 2022 13:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0czNl5xnHcV3Jnxk26qsimE18Iq0rxQ5O6Wwkcqwybk=; b=A0xOvPFHkkH71ehKCe/4LKG+R9pSE602MSHRuVw6d8vdCu8/WGh57DcVZwcqiiAz8O xbp1XJGJPqpufS712Z91O8/KraB+3K4cLjPiOYZ2PO8S6UJtT77j6NEPzmp1cQn8yF95 ljnizS9NNWlRzyOvoZnC8y2ddP2eqmhi61cJ3LBLcmfeunuaWESD0nTRjaA9zuB3iEyz P8dL0p5r+13Apeb489uAkjOeMe6bN20OMQ1f8qYCBotyIs4AO3th5WSsXIatYC5cbBTp Yt/++DiOVdLDDfrBRkOkRh0SkHBssDbsohZRhx0zpj1Zc9d1vkf/3o2mSNC9IoH50Oq3 fEwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0czNl5xnHcV3Jnxk26qsimE18Iq0rxQ5O6Wwkcqwybk=; b=Wd+yEui4beJFDrhfakffHFrtmzM3bz33nbPC23Hr/VeUfANo0B/ccR66JwlSnX8VCC vTUEGO4p7gZKmYyYVxO2ZrnU7318AyUyrMltAcF4wE0fV7oBhX02FPfdG+b+7ot4KJ68 /oYyDVFI5PKweugAsBMWkfMDCcMi387zzg9ZmxvjmQvDQ2jkCK+aNBqNgcq6CxlCzNsP +zEnIcpqx7Pc/nunYAS0ShekPNRc9U+WmRwH58lZVQYxSP13wiHN7xox+hzyZSzovsjb 9oSzMQmKMSpDi4/hdzeKS0Ou+itr9yQX4agjHjIJpcrWnsnjafzbVYhyoSiy9nic1A4r zFTg== X-Gm-Message-State: AOAM532lM2xCW4PPIkuVDa308phdY+e361yXLZoKpIZO+SmVHma4+dgj cX2Q93/wRJVTnbGpSWbEYphLC03w4TaoT66+zSVvQg== X-Google-Smtp-Source: ABdhPJxy95DeusrKMPmELu9DLI2QtWdFVKSWpo4ikHFIYnuIUBNIN2ihZEKZ9PVty0JHSgrJ0ba628XkqBKfCnNiSiA= X-Received: by 2002:a1f:ce46:0:b0:34e:b018:c8a4 with SMTP id e67-20020a1fce46000000b0034eb018c8a4mr2015055vkg.26.1651522181348; Mon, 02 May 2022 13:09:41 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> In-Reply-To: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> From: Warner Losh Date: Mon, 2 May 2022 14:09:30 -0600 Message-ID: Subject: Re: discussion on future removal of empty $FreeBSD$ tags To: Marek Zarychta Cc: freeBSD Current , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f552fa05de0cf892" X-Rspamd-Queue-Id: 4KsZ1y0pZ9z4gDK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=A0xOvPFH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000f552fa05de0cf892 Content-Type: text/plain; charset="UTF-8" The current plans are to keep $FreeBSD$ in main until stable/12 is out of support. no new files will have it added, unless they are to be merged to stable/12 and are installed / managed by mergemaster. We'll do a coordinated sweep of the tree removing them after stable/12 drops out of support and we'll do similar commits to stable/13 to reduce as much as possible any merge conflicts after that point. stable/13 and newer they are, of course, just noise. mergemaster doesn't require them to be non-empty, but will skip modified files if they match. Though it's been a while since I've used mergemaster... It has no maintainer and only receives emergency fixes when something breaks (and it usually takes a while for the right people to notice). Warner On Mon, May 2, 2022 at 12:25 PM Marek Zarychta < zarychtam@plan-b.pwste.edu.pl> wrote: > Dear subscribers, > > after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ > from among others, two configuration files: /etc/ssh/ssh_config and > /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in > the whole source tree when 12.x branch reaches EoL, what is surprising > news, at least for me. While indeed empty $FreeBSD$ tags after the > transition to git became useless, leaving them in config files, still might > be handy. Please let me explain why. > > After the transition to git, a lot of people complained about breakage in > mergemaster(8). Finally, they were told that this tool is outdated, cannot > do 3-way merge, has no maintainer, etc. so it's going to be deprecated > soon. Then appropriate notice was added, the handbook got updated, so > seemingly everyone was fine with this depreciation. I am not going to bring > any serious arguments against etcupdate(8), but when providing support on > IRC, a few cases of foot shooting with this tool had been reported to me > and the last one happened this year IIRC. Moreover some people, including > me, just like and are used to old sdiff(1)-way work of mergemaster(8). So > soon after the transition to git to overcome this deficiency I wrote for > myself a git primer helping with quick creation of local repository > including $FreeBSD$ recreation for mergemaster(8) relying on empty > $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone > (noncommitter) will benefit from this (if it will not get burned with fire > here earlier). > > Please don't get me wrong, I am not fighting with etcupdate(8) which works > almost flawlessly in unison with freebsd-update(8), but people who follow > STABLE/CURRENT really do appreciate the existence of mergemaster(8) and > still use it behind the scenes, including probably members of core@ team. > I am only asking for leaving these empty $FreeBSD$ IDs in config files. > This will of course add some burden to committers' work but might be > beneficial in the future. I am neither committer, nor contributor, but the > voice from the userbase. > > Best regards, > > Marek Zarychta > > [1] https://cgit.freebsd.org/src/commit/?id=835ee05f > > [2] > > ######################################################## > # > # FreeBSD Git src with worktrees and clean/smudge filters > # for mergemaster(8) > # > ######################################################## > # Preparation of the tree > > zfs create zroot/usr/src_head > zfs create zroot/usr/src_13 > > ######################################################## > # Making src of stable/13 mountable in /usr/src > > echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab > mount -al > > ######################################################## > # Cloning the repository > > cd /usr/src_head > git clone https://git.freebsd.org/src.git/ ./ > > ######################################################## > # Adding filters > # Filters require lang/ruby and lang/perl installed > > git config filter.freebsdid.smudge expand_freebsd > git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' > > ######################################################## > # Limiting filters scope > # In /usr/src_head create file .git/info/attributes with > # following contents (at least): > > ------------cut------------ > cat > .git/info/attributes << EOF > etc/* filter=freebsdid > etc/*/* filter=freebsdid > libexec/rc/* filter=freebsdid > libexec/rc/rc.d/* filter=freebsdid > *.conf filter=freebsdid > dot.??* filter=freebsdid > lib/libc/gen/shells filter=freebsdid > lib/libc/net/hosts filter=freebsdid > lib/libpam/pam.d/* filter=freebsdid > lib/libwrap/hosts.allow filter=freebsdid > usr.sbin/services_mkdb/services filter=freebsdid > usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid > usr.sbin/periodic/etc/* filter=freebsdid > usr.sbin/cron/cron/crontab filter=freebsdid > crypto/openssh/ssh*_config filter=freebsdid > EOF > ------------cut------------ > > ######################################################## > # Smudge filter setup > # Create file /usr/local/bin/expand_freebsd with following > # contents and make it executable. > > ------------cut------------ > #!/usr/bin/env ruby > data = STDIN.read > last_info = `git log --pretty=format:"%h %ae %ad" -1` > puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') > ------------cut------------ > > chmod a+x /usr/local/bin/expand_freebsd > > ######################################################## > # Adding worktrees > # Add worktree for stable/13, filters will be applied > > git worktree add /usr/src_13 stable/13 > > # To have IDs in main (HEAD) > # do checkout of filtered files again > > cd /usr/src_head > rm etc/master.passwd etc/group > rm libexec/rc/rc.d/* > git checkout -f -- . > > ######################################################## > # To find more files with $FreeBSD tags which might > # be added to .git/info/attributes file issue command: > > find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' > > -- > Marek Zarychta > > --000000000000f552fa05de0cf892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current plans are to keep $FreeBSD$ in main until stab= le/12 is out of support. no new files will have it added, unless they are t= o be merged to stable/12 and are installed / managed by mergemaster.
We'll do a coordinated sweep of the tree removing them aft= er stable/12 drops out of support and we'll do similar commits to stabl= e/13 to reduce as much as possible any merge conflicts after that point.

stable/13 and newer they are, of course, just noise.= mergemaster doesn't require them to be non-empty, but will skip modifi= ed files if they match. Though it's been a while since I've used me= rgemaster... It has no maintainer and only receives emergency fixes when so= mething breaks (and it usually takes a while for the right people to notice= ).

Warner

On Mon, May 2, 2022 at 12:25 PM Mar= ek Zarychta <zarychtam@= plan-b.pwste.edu.pl> wrote:
=20 =20 =20

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).=C2=A0 So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficia= l in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=3D835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters=20
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
=20
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/f=
stab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone ht=
tps://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*=
\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with=20
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=3Dfreebsdid
etc/*/*                 filter=3Dfreebsdid
libexec/rc/*            filter=3Dfreebsdid
libexec/rc/rc.d/*       filter=3Dfreebsdid
*.conf                  filter=3Dfreebsdid
dot.??*                 filter=3Dfreebsdid
lib/libc/gen/shells     filter=3Dfreebsdid
lib/libc/net/hosts      filter=3Dfreebsdid
lib/libpam/pam.d/*      filter=3Dfreebsdid
lib/libwrap/hosts.allow filter=3Dfreebsdid
usr.sbin/services_mkdb/services filter=3Dfreebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=3Dfreebsdid
usr.sbin/periodic/etc/* filter=3Dfreebsdid
usr.sbin/cron/cron/crontab filter=3Dfreebsdid
crypto/openssh/ssh*_config filter=3Dfreebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following=20
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data =3D STDIN.read
last_info =3D `git log --pretty=3Dformat:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s +=
 '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd=20

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD)=20
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group=20
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command:=20

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD'=
; 

--=20
Marek Zarychta
--000000000000f552fa05de0cf892-- From nobody Mon May 2 20:31:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9B6561AB95E2; Mon, 2 May 2022 20:31:43 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KsZWL05WTz4m5Z; Mon, 2 May 2022 20:31:41 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2001:470:71:d47:c0c4:7b61:cb80:fb4f] ([IPv6:2001:470:71:d47:c0c4:7b61:cb80:fb4f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 242KVZVq088798 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 2 May 2022 22:31:36 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1651523496; bh=mSZsQvdN+0bT/X0FKGoubjS3lZAWFTB9nxdkLze1B+o=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Ny3nwP5deR0xudSnE2tItmtulN8H7dKoSWzNxId9dNzRQ7kTCpzWhSC9E9aBQiw58 St40Z+JPFiYcvudqGhkaCzIzhiVnW3swXye+fwUzv4TEysR7kuKy6Igl7sO1x42zrS aF+C0llacYc2xnQSxWYZtb1PLm4+SzYDu0P9PRrYWiw64AVXkGp2t9zR07VCDMn4T4 T4KR0m1U5pfkjvi9257hshcjUvKzqBthoJuC5JDRQ3yVFPfmdaCbPyuaPSnKCA2qrZ gF/z40ZK4kbWwmKrNfw7jidXnb4+PzZd7wsQ24051sJKH+DiZYERCitv7T/Z0KtjLH 8AC5pg47k9paQ== Content-Type: multipart/alternative; boundary="------------AmnHHBLpn03nhE2I6GGre0ZE" Message-ID: <8fc7dc93-4fcb-832c-d950-05c85dcde893@plan-b.pwste.edu.pl> Date: Mon, 2 May 2022 22:31:35 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: discussion on future removal of empty $FreeBSD$ tags Content-Language: en-US To: Warner Losh Cc: freeBSD Current , FreeBSD Hackers References: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> From: Marek Zarychta In-Reply-To: X-Rspamd-Queue-Id: 4KsZWL05WTz4m5Z X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=Ny3nwP5d; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [1.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.28)[0.282]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-current]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------AmnHHBLpn03nhE2I6GGre0ZE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit W dniu 2.05.2022 o 22:09, Warner Losh pisze: > The current plans are to keep $FreeBSD$ in main until stable/12 is out > of support. no new files will have it added, unless they are to be > merged to stable/12 and are installed / managed by mergemaster. > > We'll do a coordinated sweep of the tree removing them after stable/12 > drops out of support and we'll do similar commits to stable/13 to > reduce as much as possible any merge conflicts after that point. > > stable/13 and newer they are, of course, just noise. mergemaster > doesn't require them to be non-empty, but will skip modified files if > they match. Though it's been a while since I've used mergemaster... It > has no maintainer and only receives emergency fixes when something > breaks (and it usually takes a while for the right people to notice). > > Warner Thank you for the reply and for revealing your official plans regarding $FreeBSD$ tags. Marek Zarychta > > On Mon, May 2, 2022 at 12:25 PM Marek Zarychta > wrote: > > Dear subscribers, > > after one of the recent commits[1] surprisingly we got rid of > $FreeBSD$ from among others, two configuration files: > /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs > are going to be deprecated in the whole source tree when 12.x > branch reaches EoL, what is surprising news, at least for me. > While indeed empty $FreeBSD$ tags after the transition to git > became useless, leaving them in config files, still might be > handy. Please let me explain why. > > After the transition to git, a lot of people complained about > breakage in mergemaster(8). Finally, they were told that this tool > is outdated, cannot do 3-way merge, has no maintainer, etc. so > it's going to be deprecated soon. Then appropriate notice was > added, the handbook got updated, so seemingly everyone was fine > with this depreciation. I am not going to bring any serious > arguments against etcupdate(8), but when providing support on IRC, > a few cases of foot shooting with this tool had been reported to > me and the last one happened this year IIRC. Moreover some people, > including me, just like and are used to old sdiff(1)-way work of > mergemaster(8).  So soon after the transition to git to overcome > this deficiency I wrote for myself a git primer helping with quick > creation of local repository including $FreeBSD$ recreation for > mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this > primer[2] for users here, maybe someone (noncommitter) will > benefit from this (if it will not get burned with fire here earlier). > > Please don't get me wrong, I am not fighting with etcupdate(8) > which works almost flawlessly in unison with freebsd-update(8), > but people who follow STABLE/CURRENT really do appreciate the > existence of mergemaster(8) and still use it behind the scenes, > including probably members of core@ team. I am only asking for > leaving these empty $FreeBSD$ IDs in config files. This will of > course add some burden to committers' work but might be beneficial > in the future. I am neither committer, nor contributor, but the > voice from the userbase. > > Best regards, > > Marek Zarychta > > [1] https://cgit.freebsd.org/src/commit/?id=835ee05f > > [2] > > ######################################################## > # > # FreeBSD Git src with worktrees and clean/smudge filters > # for mergemaster(8) > # > ######################################################## > # Preparation of the tree > > zfs create zroot/usr/src_head > zfs create zroot/usr/src_13 > > ######################################################## > # Making src of stable/13 mountable in /usr/src > > echo "/usr/src_13 /usr/src nullfs rw,late 0 0" >> /etc/fstab > mount -al > > ######################################################## > # Cloning the repository > > cd /usr/src_head > git clonehttps://git.freebsd.org/src.git/ ./ > > ######################################################## > # Adding filters > # Filters require lang/ruby and lang/perl installed > > git config filter.freebsdid.smudge expand_freebsd > git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"' > > ######################################################## > # Limiting filters scope > # In /usr/src_head create file .git/info/attributes with > # following contents (at least): > > ------------cut------------ > cat > .git/info/attributes << EOF > etc/* filter=freebsdid > etc/*/* filter=freebsdid > libexec/rc/* filter=freebsdid > libexec/rc/rc.d/* filter=freebsdid > *.conf filter=freebsdid > dot.??* filter=freebsdid > lib/libc/gen/shells filter=freebsdid > lib/libc/net/hosts filter=freebsdid > lib/libpam/pam.d/* filter=freebsdid > lib/libwrap/hosts.allow filter=freebsdid > usr.sbin/services_mkdb/services filter=freebsdid > usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid > usr.sbin/periodic/etc/* filter=freebsdid > usr.sbin/cron/cron/crontab filter=freebsdid > crypto/openssh/ssh*_config filter=freebsdid > EOF > ------------cut------------ > > ######################################################## > # Smudge filter setup > # Create file /usr/local/bin/expand_freebsd with following > # contents and make it executable. > > ------------cut------------ > #!/usr/bin/env ruby > data = STDIN.read > last_info = `git log --pretty=format:"%h %ae %ad" -1` > puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$') > ------------cut------------ > > chmod a+x /usr/local/bin/expand_freebsd > > ######################################################## > # Adding worktrees > # Add worktree for stable/13, filters will be applied > > git worktree add /usr/src_13 stable/13 > > # To have IDs in main (HEAD) > # do checkout of filtered files again > > cd /usr/src_head > rm etc/master.passwd etc/group > rm libexec/rc/rc.d/* > git checkout -f -- . > > ######################################################## > # To find more files with $FreeBSD tags which might > # be added to .git/info/attributes file issue command: > > find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' > > -- > Marek Zarychta > --------------AmnHHBLpn03nhE2I6GGre0ZE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
W dniu 2.05.2022 o 22:09, Warner Losh pisze:
The current plans are to keep $FreeBSD$ in main until stable/12 is out of support. no new files will have it added, unless they are to be merged to stable/12 and are installed / managed by mergemaster.

We'll do a coordinated sweep of the tree removing them after stable/12 drops out of support and we'll do similar commits to stable/13 to reduce as much as possible any merge conflicts after that point.

stable/13 and newer they are, of course, just noise. mergemaster doesn't require them to be non-empty, but will skip modified files if they match. Though it's been a while since I've used mergemaster... It has no maintainer and only receives emergency fixes when something breaks (and it usually takes a while for the right people to notice).

Warner

Thank you for the reply and for revealing your official plans regarding $FreeBSD$ tags.

Marek Zarychta


On Mon, May 2, 2022 at 12:25 PM Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> wrote:

Dear subscribers,

after one of the recent commits[1] surprisingly we got rid of $FreeBSD$ from among others, two configuration files: /etc/ssh/ssh_config and /etc/ssh/sshd_config. I was told these IDs are going to be deprecated in the whole source tree when 12.x branch reaches EoL, what is surprising news, at least for me. While indeed empty $FreeBSD$ tags after the transition to git became useless, leaving them in config files, still might be handy. Please let me explain why.

After the transition to git, a lot of people complained about breakage in mergemaster(8). Finally, they were told that this tool is outdated, cannot do 3-way merge, has no maintainer, etc. so it's going to be deprecated soon. Then appropriate notice was added, the handbook got updated, so seemingly everyone was fine with this depreciation. I am not going to bring any serious arguments against etcupdate(8), but when providing support on IRC, a few cases of foot shooting with this tool had been reported to me and the last one happened this year IIRC. Moreover some people, including me, just like and are used to old sdiff(1)-way work of mergemaster(8).  So soon after the transition to git to overcome this deficiency I wrote for myself a git primer helping with quick creation of local repository including $FreeBSD$ recreation for mergemaster(8) relying on empty $FreeBSD$ tags. I will attach this primer[2] for users here, maybe someone (noncommitter) will benefit from this (if it will not get burned with fire here earlier).

Please don't get me wrong, I am not fighting with etcupdate(8) which works almost flawlessly in unison with freebsd-update(8), but people who follow STABLE/CURRENT really do appreciate the existence of mergemaster(8) and still use it behind the scenes, including probably members of core@ team. I am only asking for leaving these empty $FreeBSD$ IDs in config files. This will of course add some burden to committers' work but might be beneficial in the future. I am neither committer, nor contributor, but the voice from the userbase.

Best regards,

Marek Zarychta

[1] https://cgit.freebsd.org/src/commit/?id=835ee05f

[2]

########################################################
#
# FreeBSD Git src with worktrees and clean/smudge filters 
# for mergemaster(8)
#
########################################################
# Preparation of the tree

zfs create zroot/usr/src_head
zfs create zroot/usr/src_13

########################################################
# Making src of stable/13 mountable in /usr/src
 
echo "/usr/src_13 	/usr/src 		nullfs rw,late 0 0" >> /etc/fstab
mount -al

########################################################
# Cloning the repository

cd /usr/src_head
git clone https://git.freebsd.org/src.git/ ./

########################################################
# Adding filters
# Filters require lang/ruby and lang/perl installed

git config filter.freebsdid.smudge expand_freebsd
git config filter.freebsdid.clean 'perl -pe "s/\\\$FreeBSD[^\\\$]*\\\$/\\\$FreeBSD\\\$/"'

########################################################
# Limiting filters scope
# In /usr/src_head create file .git/info/attributes with 
# following contents (at least):

------------cut------------
cat > .git/info/attributes << EOF
etc/* 	                filter=freebsdid
etc/*/*                 filter=freebsdid
libexec/rc/*            filter=freebsdid
libexec/rc/rc.d/*       filter=freebsdid
*.conf                  filter=freebsdid
dot.??*                 filter=freebsdid
lib/libc/gen/shells     filter=freebsdid
lib/libc/net/hosts      filter=freebsdid
lib/libpam/pam.d/*      filter=freebsdid
lib/libwrap/hosts.allow filter=freebsdid
usr.sbin/services_mkdb/services filter=freebsdid
usr.sbin/bsnmpd/bsnmpd/snmpd.config filter=freebsdid
usr.sbin/periodic/etc/* filter=freebsdid
usr.sbin/cron/cron/crontab filter=freebsdid
crypto/openssh/ssh*_config filter=freebsdid
EOF
------------cut------------

########################################################
# Smudge filter setup
# Create file /usr/local/bin/expand_freebsd with following 
# contents and make it executable.

------------cut------------
#!/usr/bin/env ruby
data = STDIN.read
last_info = `git log --pretty=format:"%h %ae %ad" -1`
puts data.gsub('$FreeBSD$', '$FreeBSD: ' + last_info.to_s + '$')
------------cut------------

chmod a+x /usr/local/bin/expand_freebsd 

########################################################
# Adding worktrees
# Add worktree for stable/13, filters will be applied

git worktree add /usr/src_13 stable/13

# To have IDs in main (HEAD) 
# do checkout of filtered files again

cd /usr/src_head
rm etc/master.passwd etc/group 
rm libexec/rc/rc.d/*
git checkout -f -- .

########################################################
# To find more files with $FreeBSD tags which might
# be added to .git/info/attributes file issue command: 

find . -type f -a -not -name '*~' | xargs grep -l '$FreeBSD' 

-- 
Marek Zarychta
--------------AmnHHBLpn03nhE2I6GGre0ZE-- From nobody Mon May 2 22:37:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2119C1AAA694; Mon, 2 May 2022 22:37:20 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4KsdJH23Twz3M2f; Mon, 2 May 2022 22:37:18 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 676B64C000B; Mon, 2 May 2022 17:37:12 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 02 May 2022 22:37:12 +0000 From: Pau Amma To: Warner Losh Cc: Marek Zarychta , freeBSD Current , FreeBSD Hackers Subject: Re: discussion on future removal of empty $FreeBSD$ tags In-Reply-To: References: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <980b2e8a16a0417b5bf11eadce03471e@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4KsdJH23Twz3M2f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-1.69 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.876]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_HAS_CURRENCY(1.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; NEURAL_SPAM_SHORT(0.09)[0.088]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-05-02 20:09, Warner Losh wrote: > The current plans are to keep $FreeBSD$ in main until stable/12 is out > of > support. no new files will have it added, unless they are to be merged > to > stable/12 and are installed / managed by mergemaster. > > We'll do a coordinated sweep of the tree removing them after stable/12 > drops out of support and we'll do similar commits to stable/13 to > reduce as > much as possible any merge conflicts after that point. Tangentially, what about things that used to be part of base but were later spun off into ports? https://github.com/freebsd/calendar-data is an example: there may be others. Do these need the $FreeBSD$ tag removed as well, and when if so? -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Tue May 3 01:53:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D31CA1AB358E for ; Tue, 3 May 2022 01:53:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ksjfv3cJFz4Wcr for ; Tue, 3 May 2022 01:53:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2b.google.com with SMTP id y27so7369381vkl.8 for ; Mon, 02 May 2022 18:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hWfoHvrcndBpi0KLugFRK4L/F6Dz6oSgIdUudH3jUvU=; b=uBfMofmATEtlQiDdVyGDOoLQaRtgN1e6ckgZmjRvpPvzq+MwGLsZLh1mPqlADOx74K W4C6Un7bSLhQBI7eHUUlYJmrFYT3Jqn75CfvoaKAR/uQ3IabzFdvAs/9My9L81/NZ777 +8dWRb2jHOzc2Tc2cF8dCRgS4h3m+2B45wXD7pKN3N2Ewqbs2NIov1Fj6749NAle/i1v guzDoA5a4aZwdpcVk4jEiNpP5/y/XE7Rc1w7ZQh4LiXUSHSyh3EYwM251h+PluxIaM1I Hgle/fulkM9SH+s2GpAVnrBexJiNi6tBJ4YQARrpoQGImH7C1zbzTRHnlUTNGLlLPU+7 vAuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hWfoHvrcndBpi0KLugFRK4L/F6Dz6oSgIdUudH3jUvU=; b=XYiNBeSSKhemXkQeHuhsJdsOrBYtmk+Ghhp2Wap/Et0szOZKO/CO08CB8rFkel6+uX LfpEaz6kc+y9V1OYN1v3+Lf63ZxSDPX25CvBpJqC1b7JEew03hDwrCWNZo+Ihos1XNIZ XTqQ7U53pLWr1bSxV6imV/FiXvl0rlD+ZWAQxzDDidGPWVsD2LPFK4LbC4iEQWJj8GrA V6Bo685SzkR1Mq9Ehr6oEipxHBDTGeHA9T4XwkbJ9Dg1+HY8kEb/yovys5Z6C1lxT9/E tXxidRKIb8naG5BTmJWgDRaaCX0muFQhIEQn/gdJlYotjH09mEosezYF5W/Vzpw3KloS 4PLQ== X-Gm-Message-State: AOAM530BKxipG+rvZgpOFVfL/uozttuOEZYO9VLSWxhOH2nYbJRfNfSa vPQC2cnfccDZCeFpP/XAsxMJUrNsSlj1c5LtrylG/A== X-Google-Smtp-Source: ABdhPJwXBoQxV0ikeQwby6JRdyrX2zwzrQ3b/ATQmItVKaA5jK9JMZ7niTQK1UypPjMRqKcjyHCGTirfWhW3h2AR+MY= X-Received: by 2002:a1f:aa11:0:b0:349:8fe5:6639 with SMTP id t17-20020a1faa11000000b003498fe56639mr4045316vke.15.1651542816630; Mon, 02 May 2022 18:53:36 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <4ba8458e-db94-6f74-a8e0-ba71692ea72a@plan-b.pwste.edu.pl> <980b2e8a16a0417b5bf11eadce03471e@gundo.com> In-Reply-To: <980b2e8a16a0417b5bf11eadce03471e@gundo.com> From: Warner Losh Date: Mon, 2 May 2022 19:53:24 -0600 Message-ID: Subject: Re: discussion on future removal of empty $FreeBSD$ tags To: Pau Amma Cc: Marek Zarychta , freeBSD Current , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000eabe6d05de11c67d" X-Rspamd-Queue-Id: 4Ksjfv3cJFz4Wcr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=uBfMofmA; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2b) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.86)[-0.864]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.77)[0.768]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; SUBJECT_HAS_CURRENCY(1.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2b:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000eabe6d05de11c67d Content-Type: text/plain; charset="UTF-8" On Mon, May 2, 2022, 4:37 PM Pau Amma wrote: > On 2022-05-02 20:09, Warner Losh wrote: > > The current plans are to keep $FreeBSD$ in main until stable/12 is out > > of > > support. no new files will have it added, unless they are to be merged > > to > > stable/12 and are installed / managed by mergemaster. > > > > We'll do a coordinated sweep of the tree removing them after stable/12 > > drops out of support and we'll do similar commits to stable/13 to > > reduce as > > much as possible any merge conflicts after that point. > > Tangentially, what about things that used to be part of base but were > later spun off into ports? https://github.com/freebsd/calendar-data is > an example: there may be others. Do these need the $FreeBSD$ tag removed > as well, and when if so? > There is no reason to keep them at all. They can be removed any time as can tags in ports or docs. Warner -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > --000000000000eabe6d05de11c67d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 2, 2022, 4:37 PM Pau Amma <pauamma@gundo.com> wrote:
On 2022-05-02 20:09, Warner Losh wrote:
> The current plans are to keep $FreeBSD$ in main until stable/12 is out=
> of
> support. no new files will have it added, unless they are to be merged=
> to
> stable/12 and are installed / managed by mergemaster.
>
> We'll do a coordinated sweep of the tree removing them after stabl= e/12
> drops out of support and we'll do similar commits to stable/13 to =
> reduce as
> much as possible any merge conflicts after that point.

Tangentially, what about things that used to be part of base but were
later spun off into ports? https://github.com/fre= ebsd/calendar-data is
an example: there may be others. Do these need the $FreeBSD$ tag removed as well, and when if so?

=
There is no reason to keep them at all. They can be= removed any time as can tags in ports or docs.

=
Warner=C2=A0

--
#BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters
#StandWithUkrainians
English: he/him/his (singular they/them/their/theirs OK)
French: il/le/lui (iel/iel and ielle/ielle OK)
Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila)
<= /div>



--000000000000eabe6d05de11c67d-- From nobody Fri May 6 12:25:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 90D091ABE1BB for ; Fri, 6 May 2022 12:25:58 +0000 (UTC) (envelope-from benjamin.bannier@corelight.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvqY13vmyz51L7 for ; Fri, 6 May 2022 12:25:57 +0000 (UTC) (envelope-from benjamin.bannier@corelight.com) Received: by mail-ej1-x62d.google.com with SMTP id i19so14134927eja.11 for ; Fri, 06 May 2022 05:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=corelight.com; s=corelight.com; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=/lwp5tx7HHnIGTgtxR/eTi2IJaQEA16y6B7aqfTD6zs=; b=cPViQJOi6Y79hF1Hq+uWZ3ABMG+njKreB9MZOvM28D72EYJWQf33lKwT9R5fI/dSCs bfwgRzIGvxWPBVUbY3DRzBYWV3UN0YIASa/2IQKi0VinQ8tcy9kIdPi3SguvOYOJpU5Q elGFsaTd7Dr0fLnDZAHDyVwBGaJsdBp/N58dmC9T/SI9lPeT7Ere8IgAYoam8WMTpnWq Ouvap5Ngq3u5HKD6a5aNvBAC/FVPr2gQ/ILWgowLGwvCyaCnVeYa3AArrHQynyjfqlwh LPxcGfOdJtQuIDUrt04G3MoFATpzQ1r9YYWlILssncXfcsWaNrgns1aagiGqlvqtkOwH 1DEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=/lwp5tx7HHnIGTgtxR/eTi2IJaQEA16y6B7aqfTD6zs=; b=5XC9nvUKtmebCYjtoAXpaZjJL//3a3P7kTPRNJpl9GMTT060gTyvwU0vqMeE3OcnOY 2lrIFEXLfLDNR1doHE/wolz8t2xMK9bBdCL+yfiDXDWUn3McSVLl+eYquntN4FwL74/+ yX6eXXP+tlFHmFMa2AoJE2Q7GB2Jf9UBCf9EGxKqvuASq3eokdVoQIDh5qcMy/PzxQIb YyTK+A0jB0ZoJ33/VpiANbmdW+p9xWWaYPBHb9S+PzWrZUKiBrNxYoCoA1eA9RvybeIg 7BrcUhvJu/7zrSbm3Uz8Zsjx/M+9WMZ46bk+YA7Yiyj5xi9uIWavRLNh8NqRAClYcPlV AlAQ== X-Gm-Message-State: AOAM530mO7lct7rSS914UUM3Qlk0J+CgizfewKgxhQnZoIxKV08RcwHd U8jY09eYzqkZo/72lWADMWq2XpxtcS/AA14sZFHEn/yluRIfoxjcRM712mYvdwnqdUXrrbhfmX8 +ITeA4Ia1V8FyZ36OfAdt5bRPkuCC0ZMQbJAU2vuZXNqvrEsPYIw1qRohmQhL0qPpknmGlpVMQQ XbA5U3QtPYdrFjEjPcAA== X-Google-Smtp-Source: ABdhPJx0FjtrKPX4BRTJTleLQEI30AuAOwJL02wV6fObHnsp4JmDGRgiZ81z+jCJx0f5yG3GHeHP+w== X-Received: by 2002:a17:907:6d24:b0:6f4:bc43:e7d1 with SMTP id sa36-20020a1709076d2400b006f4bc43e7d1mr2638743ejc.581.1651839956223; Fri, 06 May 2022 05:25:56 -0700 (PDT) Received: from flux.fritz.box (dslb-090-186-125-058.090.186.pools.vodafone-ip.de. [90.186.125.58]) by smtp.gmail.com with ESMTPSA id dq8-20020a170907734800b006f3ef214deasm1890209ejc.80.2022.05.06.05.25.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 May 2022 05:25:55 -0700 (PDT) From: Benjamin Bannier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: abi::__cxx_demangle appears to be broken on vanilla freebsd-13.0 Message-Id: Date: Fri, 6 May 2022 14:25:54 +0200 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4KvqY13vmyz51L7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=corelight.com header.s=corelight.com header.b=cPViQJOi; dmarc=none; spf=pass (mx1.freebsd.org: domain of benjamin.bannier@corelight.com designates 2a00:1450:4864:20::62d as permitted sender) smtp.mailfrom=benjamin.bannier@corelight.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[corelight.com:s=corelight.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[corelight.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; DKIM_TRACE(0.00)[corelight.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[90.186.125.58:received] X-ThisMailContainsUnwantedMimeParts: N Hi, I am trying to add support for a C++ program which makes use of = `abi::__cxx_demangle` for name unmangling. This worked well up to = freebsd-12.2, but appears to be broken on a vanilla 13.0. Example: // foo.cc #include #include #include int main() { const std::type_info &info =3D typeid(std::type_info); const char *name =3D info.name(); int status =3D 0; const char *dname =3D abi::__cxa_demangle(name, NULL, NULL, = &status); if (status !=3D 0) { std::cerr << "status=3D" << status << ' ' << name << '\n'; return 0; } std::cerr << name << ' ' << dname << '\n'; } This can be built with e.g., `make`: make foo If I run this on a vanilla freebsd-12.2 `__cxa_demangle` can demangle = the name as mangled by the system: $ ./foo St9type_info std::type_info On vanilla freebsd-13.0 OTOH `__cxa_demangle` reports `status=3D-2` = which according to = https://panthema.net/2008/0901-stacktrace-demangled/cxa_demangle.html = means: > -2: mangled_name is not a valid name under the C++ ABI mangling rules. I found a number of issues in bugzilla on broken unmangling in `c++filt` = and mentions of workaround which went in to fix that, but on a vanilla = 13.0 even `c++filt` seems unable to demangle `name`. I also found = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222563 which seems = to have staled for a long time (left a ping there). Could somebody point me to a way to fix this behavior? I cannot image = that I am the only one having this issue. Cheers, Benjamin= From nobody Fri May 6 18:13:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D45A41ABD1E9 for ; Fri, 6 May 2022 18:13:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KvzG76yv3z4jmy for ; Fri, 6 May 2022 18:13:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-wm1-f44.google.com with SMTP id p189so4898643wmp.3 for ; Fri, 06 May 2022 11:13:35 -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:content-transfer-encoding; bh=pLA75/GK1xSVIbYP5GXDCqBiCTuRICKI4omGJD/eSAM=; b=kpc2/TK1n0ZceDd5OkY4Q96cEyh4UXO08J5rKe0V/N/zcOS62pL39Lt4b+CvfYHi/5 6wHC7k/Cunfdb8JxXBCJeI+Z0hnqq6gtNgPIjB9sn9qp5anhLTjGwkyPVULM+uHn+I+E ds/sBfgci/dPYff96el/RSeeuTh1kE8oVovuJUsKIfplqz+n5HxG8XSCy/5gDifub8lo g89ZHtXJuV94o/KutpRRUU3WkYwhI37uSaFTyApDkKBZQJH2DkJIP0iMnFOT98YxV4TW 8TArL4FJeX4mXZm1T1aze23ZBMYY22GGZ/uV2D399GacdC9TYrWMWo9KNFcgPxg38hct QYvA== X-Gm-Message-State: AOAM530VsvQaW6F8lgY4tB22rpDwoDzU1fesi6KIspqK9WOMkYvBKPbf qXlI892R7fj+sVChpsNnUDWYh2ZBwJqORLy+4L/umJBc X-Google-Smtp-Source: ABdhPJy1mUwbLyIT0kM4cKcXDbWP17G0h16PbHOLGQY6Sh0jBrAG29hw6/eXEEjl9ee8pHhEQE73MLiFCgMizHyaPUQ= X-Received: by 2002:a05:600c:1151:b0:394:6816:d4f2 with SMTP id z17-20020a05600c115100b003946816d4f2mr9882344wmz.195.1651860808938; Fri, 06 May 2022 11:13:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 6 May 2022 14:13:14 -0400 Message-ID: Subject: Re: abi::__cxx_demangle appears to be broken on vanilla freebsd-13.0 To: Benjamin Bannier Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4KvzG76yv3z4jmy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.128.44 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-0.48 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.48)[-0.481]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.44:from]; NEURAL_SPAM_LONG(0.99)[0.989]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.44:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 6 May 2022 at 08:26, Benjamin Bannier wrote: > > I found a number of issues in bugzilla on broken unmangling in `c++filt` = and mentions of workaround which went in to fix that, but on a vanilla 13.0= even `c++filt` seems unable to demangle `name`. I also found https://bugs.= freebsd.org/bugzilla/show_bug.cgi?id=3D222563 which seems to have staled fo= r a long time (left a ping there). I posted a followup in that bug report -- can you try with a FreeBSD 13.1 snapshot? The main issue should be fixed, although libcxxrt's demangler still has some significant issues. From nobody Mon May 9 08:18:40 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D5CED1AD06D1 for ; Mon, 9 May 2022 08:18:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KxYwS5h6mz4fq2 for ; Mon, 9 May 2022 08:18:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=sPvVEIhAjyxSUFXuQo+EW49y077UHjR8h3GUPvcIJfY=; b=VNTEgj8x+gnnbquU4xZ/N8uZH78Yh0daahJoFJVQ3vnYD90h2Au/mhN9Z4KdTS7pLPp1gK6bfF3impuw8+4MwpRFDWQrLG0ZB53teWNLFzPrGgkpDeYzDArRY6+mi4C47nDqZeatl6B4n2FEACwQL9a7/FoMipFSF7TfRvKlZG7nR01y9okwIdCPUcozHGJi1FaVCBWBZnegJDpWCZFaqS6OvLdZqT4XKDHzpc+p7H33M/qlIgTKDx6X2LUMxWTpuBNGyrhlLxvUjr5uWoJMAEt0v2CWVFHoNWhfLdJ0pOYbktbIlM6zwyzcw6UwO2sv7Xf4GuBug50mtdS0QNVQGA==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nnybI-0004dA-RW for hackers@freebsd.org; Mon, 09 May 2022 11:18:40 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: efi/idrac blues Message-Id: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> Date: Mon, 9 May 2022 11:18:40 +0300 To: freebsd- X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4KxYwS5h6mz4fq2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=VNTEgj8x; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hi, the host is a Dell R720, at the moment booting diskless, and with either = pxeboot or loader.efi, no matter what magic I try, can=E2=80=99t get the shell output to the = SOL console. the kernel messages show up ok, and also the Login: but no rc/shell = output. any ideas? thanks, danny From eugen@grosbein.net Mon May 9 11:22:03 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E32DA1ACC2FB for ; Mon, 9 May 2022 11:22:42 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxf0f0knwz3JVF for ; Mon, 9 May 2022 11:22:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 249BMGVF001631 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 May 2022 11:22:16 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: danny@cs.huji.ac.il Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 249BMDac009612 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 9 May 2022 18:22:13 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: efi/idrac blues To: Daniel Braniss , freebsd- References: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> From: Eugene Grosbein Message-ID: Date: Mon, 9 May 2022 18:22:03 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4Kxf0f0knwz3JVF X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-0.49 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.75)[-0.746]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.918]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.28)[0.276]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 09.05.2022 15:18, Daniel Braniss wrote: > hi, > the host is a Dell R720, at the moment booting diskless, and with either pxeboot or loader.efi, > no matter what magic I try, can’t get the shell output to the SOL console. > the kernel messages show up ok, and also the Login: but no rc/shell output. > > any ideas? Add to /boot/loader.conf: console="comconsole vidconsole" #comconsole_speed=115200 From nobody Mon May 9 11:30:12 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B8961ACDDD9 for ; Mon, 9 May 2022 11:30:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxf9S1ryFz3L9c for ; Mon, 9 May 2022 11:30:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1652095813; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5KsgtN95Q2NJh7MUULLFf0L8Oj5NZtibdkreETqVO3Y=; b=Xq2Y52fsF1g31G4t1+b42c2ZSph1m7JfYwmeB0zrDvgVyGOtuQ3RVpbUDW0DbJZSu4CAt8 996JcM2F7ptKwbIkmaKULoOyvX30yRbdnR9P8RZlV2rRwLWmEk4Tj6MLljmwCFx+NTGzX8 5DLstLBAb7LT6+vXyi7/tI9gG+WLYeI= Received: from skull.home.blih.net (lfbn-idf2-1-1518-133.w92-169.abo.wanadoo.fr [92.169.82.133]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 25898e52 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 9 May 2022 11:30:13 +0000 (UTC) Date: Mon, 9 May 2022 13:30:12 +0200 From: Emmanuel Vadot To: Daniel Braniss Cc: freebsd- Subject: Re: efi/idrac blues Message-Id: <20220509133012.8a3e8abe06dd8c5899ad2400@bidouilliste.com> In-Reply-To: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> References: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Kxf9S1ryFz3L9c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=Xq2Y52fs; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, 9 May 2022 11:18:40 +0300 Daniel Braniss wrote: > hi, > the host is a Dell R720, at the moment booting diskless, and with either = pxeboot or loader.efi, > no matter what magic I try, can?t get the shell output to the SOL console. > the kernel messages show up ok, and also the Login: but no rc/shell outpu= t. >=20 > any ideas? >=20 > thanks, > danny Set boot_serial=3DYES in /boot/loader.conf If you still want video output you need also to add boot_multicons=3DYES Cheers, --=20 Emmanuel Vadot From nobody Mon May 9 16:45:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B8D81ACA8FC for ; Mon, 9 May 2022 16:45:36 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxn9C4tvMz4jYZ for ; Mon, 9 May 2022 16:45:35 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 249GjSFB002954 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 9 May 2022 12:45:28 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 249GjSG3002953 for freebsd-hackers@freebsd.org; Mon, 9 May 2022 12:45:28 -0400 (EDT) (envelope-from wayne) Date: Mon, 9 May 2022 12:45:28 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220509164528.GO72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> <20220420111229.36de494f@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220420111229.36de494f@FreeBSD.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kxn9C4tvMz4jYZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[wayne47.com]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 20, 2022 at 11:12:29AM +0200, T??l Coosemans wrote: > On Mon, 18 Apr 2022 13:33:33 -0400 Michael Wayne > wrote: > > On Fri, Apr 15, 2022 at 01:49:53PM -0400, Michael Wayne wrote: > >> I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > >> > >> I'm trying to upgrade the machine to 12.3 and having swap failures. > > > > I tried a number of things, all of which failed. > > > > Since the offending line is: > > > >> ctfmerge -L VERSION -g -o kernel.full ... > > > > I went digging through makefiles and found: > > MK_CTF=no > > > > Adding this to the command line permitted the build to complete and > > the machine is now running on the new kernel. Hopefully this helps > > others. I'm still not sure why the kernel refused to use swap but > > this is a very easy to duplicate issue. > > How many CPU cores does the VM have? I believe only 1: CPU: Intel Core Processor (Broadwell, no TSX, IBRS) (2394.51-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306d2 Family=0x6 Model=0x3d Stepping=2 Features=0x783fbff Features2=0xfffa3203 AMD Features=0x28100800 AMD Features2=0x21 Structured Extended Features=0x7a9 Structured Extended Features3=0x84000000 XSAVE Features=0x1 Hypervisor: Origin = "KVMKVMKVM" real memory = 1073741824 (1024 MB) avail memory = 1001181184 (954 MB) > Can you still reproduce it now that you run 12.3? Yes. It persists. > If so, can you try the attached patch? It prevents background Building now. > laundering when nfreed == 0, restoring some behaviour from before > https://cgit.freebsd.org/src/commit/?id=c098768e4dad and > https://cgit.freebsd.org/src/commit/?id=60684862588f. > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 36d5f3275800..df827af3075f 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) > nclean = vmd->vmd_free_count + > vmd->vmd_pagequeues[PQ_INACTIVE].pq_cnt; > ndirty = vmd->vmd_pagequeues[PQ_LAUNDRY].pq_cnt; > - if (target == 0 && ndirty * isqrt(howmany(nfreed + 1, > + if (target == 0 && ndirty * isqrt(howmany(nfreed, > vmd->vmd_free_target - vmd->vmd_free_min)) >= nclean) { > target = vmd->vmd_background_launder_target; > } From nobody Mon May 9 17:09:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C58531AD1414 for ; Mon, 9 May 2022 17:09:27 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxnhl0n46z4nwS for ; Mon, 9 May 2022 17:09:27 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 249H9QCK042659 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 9 May 2022 13:09:26 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 249H9P4t042658 for freebsd-hackers@freebsd.org; Mon, 9 May 2022 13:09:25 -0400 (EDT) (envelope-from wayne) Date: Mon, 9 May 2022 13:09:25 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220509170925.GQ72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kxnhl0n46z4nwS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.927]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.918]; DMARC_NA(0.00)[wayne47.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Apr 19, 2022 at 08:52:00AM +0200, Wojciech Puchar wrote: > try > > sysctl -w vm.overcommit=1 No improvement. > On Fri, 15 Apr 2022, Michael Wayne wrote: > > > I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > > > > I'm trying to upgrade the machine to 12.3 and having swap failures. > > > > This machine runs bird to advertise BGP, ssh and not much else so > > the small amount of RAM is (usually) fine. > > > > For a long time, there was a 1 GB swap file which handled the > > occasional time when excess memory got used. > > > > Machine needs a custom kernel for BGP, the conf file consists of: > > include GENERIC > > ident ROUTING > > options TCP_SIGNATURE > > > > > > Today, while building the 12.3 kernel with: > > cd /usr/src > > sudo make toolchain > > sudo make buildkernel KERNCONF=ROUTING > > the machine ran out of swap. with a bunch of messages like: > > Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > > Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > > Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > > Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > > Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > > Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > > > > Thinking it was a sawp space issue, I increased the swap to 4 GB and > > tried again with the same results. Boot gave the kern.maxswzone message, > > I ignored it as I had planned to change as soon as I completed the build. > > > > So I pulled up top in a console window and watched swap during the > > build. About 400 MB of RAM was free and about 3 MB of swap was > > used when the machine started linking the kernel: > > ctfmerge -L VERSION -g -o kernel.full ... > > While this command was running, I saw swap usage go to ~5MB (so > > just over 1%), then started seeing processes being killed due to > > out of swap space. > > > > So, how to proceed? From nobody Mon May 9 18:58:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 25C421ABA4FA for ; Mon, 9 May 2022 18:58:42 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kxr6n2PZ4z3kCb for ; Mon, 9 May 2022 18:58:41 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 249Iweo9006177 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 9 May 2022 14:58:40 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 249IweJi006176 for freebsd-hackers@freebsd.org; Mon, 9 May 2022 14:58:40 -0400 (EDT) (envelope-from wayne) Date: Mon, 9 May 2022 14:58:40 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220509185840.GS72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> <20220420111229.36de494f@FreeBSD.org> <20220509164528.GO72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220509164528.GO72471@post.wayne47.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kxr6n2PZ4z3kCb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[wayne47.com]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 09, 2022 at 12:45:28PM -0400, Michael Wayne wrote: > On Wed, Apr 20, 2022 at 11:12:29AM +0200, T??l Coosemans wrote: > > On Mon, 18 Apr 2022 13:33:33 -0400 Michael Wayne > > wrote: > > > On Fri, Apr 15, 2022 at 01:49:53PM -0400, Michael Wayne wrote: > > >> I have a VM with 1GB RAM running FreeBSD 12.1-RELEASE-p3 > > >> > > >> I'm trying to upgrade the machine to 12.3 and having swap failures. > > > > > > I tried a number of things, all of which failed. > > > > > > Since the offending line is: > > > > > >> ctfmerge -L VERSION -g -o kernel.full ... > > > > > > I went digging through makefiles and found: > > > MK_CTF=no > > > > > > Adding this to the command line permitted the build to complete and > > > the machine is now running on the new kernel. Hopefully this helps > > > others. I'm still not sure why the kernel refused to use swap but > > > this is a very easy to duplicate issue. > > > > If so, can you try the attached patch? It prevents background Tried the patch. Still ran out of swap. From nobody Mon May 9 20:03:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4F6001AD5388 for ; Mon, 9 May 2022 20:03:16 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KxsYJ1Vvbz4m6n; Mon, 9 May 2022 20:03:16 +0000 (UTC) (envelope-from tijl@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652126596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ilgqsmbhWVXxXwkCJMB8DQhru2E51i+Gk8kJ+QzuEsw=; b=Nzl9WDq5fPx5ppgRSb4QzkzdTNgD10rjhQuEIl64FTsZ4Lm+Ghzn3wBWsYbd2aSCQYriqI DQfnNU6G8xYy1GhvNgqbfdYIMbGgTdTsyyHynMSnUqVRfcZBYKl0Xd7kNya9APUHgI1kQw 4VWErunqEcP4Bk5LaLa2qoarVzOwBgzslriEN3Fgx85jgzSAFOWuPqrm4+Ww7Lg+L8B683 X8D25L4SIpY/9osO4kizC0TCdc9ifEPcAK4tqaDqblTgs9U2ii/dNxHiiv3w7qx9YL2tM6 iI30QFq+TlCxmWRuID0qnyMJk4ASLwlssOfukERwERpqtiBTey7/wCxujvow0Q== Received: from localhost (unknown [IPv6:2a02:a03f:894b:4700:295b:e980:8fb6:181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tijl) by smtp.freebsd.org (Postfix) with ESMTPSA id 9DA568941; Mon, 9 May 2022 20:03:15 +0000 (UTC) (envelope-from tijl@FreeBSD.org) Date: Mon, 9 May 2022 22:03:11 +0200 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Michael Wayne Cc: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220509220311.4a7a09fd@FreeBSD.org> In-Reply-To: <20220509185840.GS72471@post.wayne47.com> References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> <20220420111229.36de494f@FreeBSD.org> <20220509164528.GO72471@post.wayne47.com> <20220509185840.GS72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652126596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ilgqsmbhWVXxXwkCJMB8DQhru2E51i+Gk8kJ+QzuEsw=; b=iCjcMxpdT84yNbvS8JB1a1hYlrOuZ7OsuANO00IWIrco2wg+RCnLaqxL/yoAejoqHgyS8Q dnuqpbL9s6gJQ2GTgAwDWwHK51vE2ZHFAKpimA+rERI/m+kZG9yMaZ0v8MfwP63dwEdbkC ztTzxMFT3BR6OvCvz+BsfjwjZbff4331BHdZaXGzX05NljCWiB3SoFowocCAsmo0fI+ZeR FNUWWPEnyf1sFTpCIe2e2HC/Uoj7A1jlAFfk/XRikMqqNPePpOQob4bf452U8YnqTJCqtw g7qsfD2e5aaOrpjBCOI2wRJrz0VNBc+Yov7B2acIR0oqAPgqeJLj10yYV/7n1A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652126596; a=rsa-sha256; cv=none; b=l3P4GwxmAbzZ+lwZSF5sIEER9mTPfllW1Ka6YuUBT+n6vtQK5xlhJm68We0fbtERLN/7Hc AEJTQKda9NBRiTW6HY9lMEDPp+9TDaXgnkEJXk6HSduWt81BKSEUiDAmlcC+HIYXOXVwRq g7/mLOK9N3IgqLiDngXel2ua6pGKmXqq2gmCDHLnv5Rrg97lpjPrE9+o3uxTccKozVI8iP Hbu7Y7ycNl3ZCZ3fF4aAMxczsgsAfbHj26iuEFnKbhPfcY7CaUQvbGFQlQa+PATe2z0X8m XTPBoYuIiWnJgNTpy4LFtm8WJCTeSQPC5fEmUX9D+i8f/Hbz/QWzXBv7Hz243g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, 9 May 2022 14:58:40 -0400 Michael Wayne wrote: > On Mon, May 09, 2022 at 12:45:28PM -0400, Michael Wayne wrote: >> On Wed, Apr 20, 2022 at 11:12:29AM +0200, T??l Coosemans wrote: >>> If so, can you try the attached patch? It prevents background > > Tried the patch. Still ran out of swap. Ok, thanks for trying. Just to be clear though, you are currently running a kernel with the patch applied and then builds still fail, right? From nobody Tue May 10 05:15:14 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 80D5D1AD222A for ; Tue, 10 May 2022 05:15:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ky5pJ5m35z3NyS for ; Tue, 10 May 2022 05:15:20 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=CBwrpSZ/JPRBM9WK8RN7grruSRse8ezKf9Xa59K/ZTc=; b=OGjS4E3SZPzSW+VDW/LjHUa2RO4Gd9n6qslYKiryfNIcrhtmJRrIFcQb9oTJBde+pMhnrFQp1hf6UgvCR/Biq+SeDTjnJS2HAa0HUIHu419AizCEXUxfLMjg55vUwSX+J/tCJWkzGJbSoZE1C8Q+EaeyamfHueAqyGHxHGps3BfQKWB6DWhlJ3d6kdjHmJgXS8lws0fOMZazGiZtIBiLSIz+jWSZK4PahcGMQ497pVat3pUkBLpe354F5RL+5hddHYQNXVJxhBByjbNoKEOCCQgFEuBWGkqTqwDZQp6SmMYt3Gtd8goGy7NMC6xiTy/cD+/uXs6WUYf2LlIufgPVsw==; Received: from bach.cs.huji.ac.il ([132.65.80.20] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1noIDK-000LUL-Af; Tue, 10 May 2022 08:15:14 +0300 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: efi/idrac blues From: Daniel Braniss In-Reply-To: <20220509133012.8a3e8abe06dd8c5899ad2400@bidouilliste.com> Date: Tue, 10 May 2022 08:15:14 +0300 Cc: freebsd- Content-Transfer-Encoding: quoted-printable Message-Id: References: <43325CDF-7B7D-4203-9E02-451848B35073@cs.huji.ac.il> <20220509133012.8a3e8abe06dd8c5899ad2400@bidouilliste.com> To: Emmanuel Vadot , Eugene Grosbein X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4Ky5pJ5m35z3NyS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=OGjS4E3S; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 9 May 2022, at 14:30, Emmanuel Vadot wrote: >=20 > On Mon, 9 May 2022 11:18:40 +0300 > Daniel Braniss wrote: >=20 >> hi, >> the host is a Dell R720, at the moment booting diskless, and with = either pxeboot or loader.efi, >> no matter what magic I try, can?t get the shell output to the SOL = console. >> the kernel messages show up ok, and also the Login: but no rc/shell = output. >>=20 >> any ideas? >>=20 >> thanks, >> danny >=20 > Set boot_serial=3DYES in /boot/loader.conf > If you still want video output you need also to add boot_multicons=3DYES= >=20 > Cheers, >=20 > --=20 > Emmanuel Vadot that is too easy :-), without those lines NOTHING comes out via the = serial-over-lan the thing is that: BIOS messages OK boot and menu messages OK=20 kernel messages OK rc stuff : nothing!!! then the Login: appears. setting console=3D=E2=80=98comconsole=E2=80=9D there IS video output!! = except no boot menu but serial is all ok, go figure danny From nobody Thu May 12 16:43:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 65B5F1ADE314 for ; Thu, 12 May 2022 16:43:18 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Kzcz94hdwz3Jnd for ; Thu, 12 May 2022 16:43:17 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 24CGhApJ074183 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 May 2022 12:43:10 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 24CGhAAE074182 for freebsd-hackers@freebsd.org; Thu, 12 May 2022 12:43:10 -0400 (EDT) (envelope-from wayne) Date: Thu, 12 May 2022 12:43:09 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* Message-ID: <20220512164309.GV72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> <20220420111229.36de494f@FreeBSD.org> <20220509164528.GO72471@post.wayne47.com> <20220509185840.GS72471@post.wayne47.com> <20220509220311.4a7a09fd@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220509220311.4a7a09fd@FreeBSD.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4Kzcz94hdwz3Jnd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.981]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[wayne47.com]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 09, 2022 at 10:03:11PM +0200, T??l Coosemans wrote: > On Mon, 9 May 2022 14:58:40 -0400 Michael Wayne > wrote: > > On Mon, May 09, 2022 at 12:45:28PM -0400, Michael Wayne wrote: > >> On Wed, Apr 20, 2022 at 11:12:29AM +0200, T??l Coosemans wrote: > >>> If so, can you try the attached patch? It prevents background > > > > Tried the patch. Still ran out of swap. > > Ok, thanks for trying. Just to be clear though, you are currently > running a kernel with the patch applied and then builds still fail, > right? Correct. I did the make with MK_CTF=no, installed that, then tried the make without MK_CTF=no and had the same issues with running out of swap. From nobody Fri May 13 11:22:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B04431ACFD4E for ; Fri, 13 May 2022 11:22:54 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L05q14RJMz3mK2 for ; Fri, 13 May 2022 11:22:53 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 24DBMimo041709 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 May 2022 13:22:45 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1652440965; bh=VZOIDn/ReIpSIRzFpEuAy7W/zEPDTzJ1Ss/YGViaVPA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=POtzzShC1X8hZej2YqsZytr8qRIZ3CnQCWIrmn0o0V5rrcyM68z0TDuFKk8FxPavI s97AP618VQTMaEclIh5C8iZZCOP30RBR9ExmW+RaHdAKf7rRDZGHm3Tp9BDpJnYaDh U/PJNZXUJ1JAfx6Tr5wUyf62VsjwLE1IEaKP6qgA= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 24DBMikJ027628; Fri, 13 May 2022 13:22:44 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 24DBMhUe027625; Fri, 13 May 2022 13:22:44 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 13 May 2022 13:22:43 +0200 (CEST) From: Wojciech Puchar To: Michael Wayne cc: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM In-Reply-To: <20220509170925.GQ72471@post.wayne47.com> Message-ID: <4aa57797-bc29-9cf7-8730-6d93d430f03c@puchar.net> References: <20220415174953.GE13678@post.wayne47.com> <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> <20220509170925.GQ72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4L05q14RJMz3mK2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=POtzzShC; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Tue, Apr 19, 2022 at 08:52:00AM +0200, Wojciech Puchar wrote: >> try >> >> sysctl -w vm.overcommit=1 > > No improvement. So it's not because memory is overallocated by program. > > >> On Fri, 15 Apr 2022, Michael Wayne wrote: >>> the machine ran out of swap. with a bunch of messages like: >>> Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 >>> Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 >>> Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 >>> Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 >>> Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 >>> Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 This message is NOT about running out of space! (sorry i didn't notice it before). this is when I/O is stalled too long. From nobody Fri May 13 11:23:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BDE0E1ACFEDC for ; Fri, 13 May 2022 11:23:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L05qF0qFYz3mdN for ; Fri, 13 May 2022 11:23:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 24DBN3LV041912 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 May 2022 13:23:03 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1652440983; bh=tETXni52J5G8N+Ds5nkZe+sfNj+wPQIsqoIY4IEbaik=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O5Y+DTxw8n5zv38hX2GP4iAoK/23LjSSGJYKqWXAT+OFkYIrVv6sdDMhpdwvC8Cwn jI/Rm6uq1nSqEINbGzpNT9RW6rdYLFQOKYOWspHiMa8M7eJJLVsjViuD3N9M/qWgHA IgzS6BpsL3yi7qU3yqTE1IojUXwr/cI7SzmeXS/I= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 24DBN3aX027636; Fri, 13 May 2022 13:23:03 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 24DBN39o027633; Fri, 13 May 2022 13:23:03 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 13 May 2022 13:23:03 +0200 (CEST) From: Wojciech Puchar To: Michael Wayne cc: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM *Solved* In-Reply-To: <20220509185840.GS72471@post.wayne47.com> Message-ID: <871914e1-c9d9-58c-fe4f-3175e6ed9e82@puchar.net> References: <20220415174953.GE13678@post.wayne47.com> <20220418173333.GC72471@post.wayne47.com> <20220420111229.36de494f@FreeBSD.org> <20220509164528.GO72471@post.wayne47.com> <20220509185840.GS72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4L05qF0qFYz3mdN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=O5Y+DTxw; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>>> MK_CTF=no >>>> >>>> Adding this to the command line permitted the build to complete and >>>> the machine is now running on the new kernel. Hopefully this helps >>>> others. I'm still not sure why the kernel refused to use swap but >>>> this is a very easy to duplicate issue. >>> > >>> If so, can you try the attached patch? It prevents background > > > Tried the patch. Still ran out of swap. > > > > are you sure you are actually running out of swap? From nobody Fri May 13 11:25:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B3CA1AD1431 for ; Fri, 13 May 2022 11:25:14 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L05sj49qQz3p58 for ; Fri, 13 May 2022 11:25:13 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 24DBPB2G043560 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 May 2022 13:25:11 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1652441112; bh=LIJifXQsSbfqZBvUTXtfLel9sMJ7JDG2xNA6FfWcn2s=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AeraXfWaruN25aRER5XRcLQVIJb+tESef6rBtmCx7M3pHbzx5CP/a9nOI1XzLPr5u fQkw6jPoiT8Y7myIYtO8mC6Ql146LCWDG/s8x0XjcosvWzB4sr+b+QQINgoKT99jVM BK7FB6as35gB7wVkyrrtlG+SOcECbrPjn2ziMdVk= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 24DBPB4Y027672; Fri, 13 May 2022 13:25:11 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 24DBPBdx027669; Fri, 13 May 2022 13:25:11 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 13 May 2022 13:25:11 +0200 (CEST) From: Wojciech Puchar To: Michael Wayne cc: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM In-Reply-To: <20220509170925.GQ72471@post.wayne47.com> Message-ID: <70185630-ccea-d92b-a691-bc9cd784cbf5@puchar.net> References: <20220415174953.GE13678@post.wayne47.com> <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> <20220509170925.GQ72471@post.wayne47.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4L05sj49qQz3p58 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=AeraXfWa; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>> sudo make buildkernel KERNCONF=ROUTING >>> the machine ran out of swap. with a bunch of messages like: >>> Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 >>> Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 >>> Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 >>> Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 >>> Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 >>> Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 i was getting such message when i used crappy SSD that stalled for very long after receiving bunch of TRIM command from UFS filesystem and in the same time OS did some swapping. If you get out of swap, some processes (usually the largest) are killed. And different messages are in log. From nobody Sat May 14 11:14:12 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 841F41AE2ED4 for ; Sat, 14 May 2022 11:14:27 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0jZp5p2gz3mYT for ; Sat, 14 May 2022 11:14:26 +0000 (UTC) (envelope-from stephen.hocking@gmail.com) Received: by mail-pj1-x1032.google.com with SMTP id gj17-20020a17090b109100b001d8b390f77bso13049520pjb.1 for ; Sat, 14 May 2022 04:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=cKptj8h4OmrMMKZVoWmZnI2/JmI3WB2k/02TsQXe/ew=; b=ELXh6oKyILi9LvqcCCyH0YAyKi9yBauZfIljW7IcSSBSt2PDd8qmPQv2Vnltjorqbl ih0IFAdM+4uorAlRrzFifkBJMR7yUzCMCjvhqZxCE2LO/edYpi/IorVmfS3WX/3bBbwU 7trAgnbQz4xMfvushH3WvBh1si/pmmofTEQmnTQrP1dx8b4J8aZkG3DXY8TqpU8H7Lxr kgat6ldRXsP9qyBPazmi58bfgBxOKJnjWe+uoi8ef5Wy8m3Nm2LVOhfgUMSv16uhr8TN AgMqKZQ9JLeEIgPtamiHZWiwhWJUvzXcfzqVJkJpzWF7nCfJF0qHqbVclp1k2OXx3mw+ 2lbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cKptj8h4OmrMMKZVoWmZnI2/JmI3WB2k/02TsQXe/ew=; b=RXQA334tqkUxsqI4a4JL/kWrdERNLTnFo2JqYSD4xDjEe/YO1XR4iTFQA8en+a9Zud JkLAmr/o6tqmLz7B0P0/U6CabRL5B/nsG9thYJWCmnQLuYLnF8easkg2o9QtJVQ38OOw OUhJXZ4xiQZvJVxt3siojnCMK5wBwM36Mytaizfejr9XvDLkgpCw61n9K3SwDjMix3WQ kccheB6F11JpryfVi6OWDWPupJMBglrnDf3gsVpEVJ8BJ8ZYkZb3kippAX4BDEWPrfTl jhtokj0CQTX7ednaT9GbrwVyj9JM1/HzLUTtIF5RljGn2uERsSnPmEhGlqcZJnYWEPXx QJBg== X-Gm-Message-State: AOAM532kOyvAuHKNvra5ELS3VLB5FYrBZAiGQCN549BWDgfMrWw2msWk mZd6j+sEfpo6Lgw9CzFPJCDAhX6NKOKPrxv/hTpDFnwLBbE= X-Google-Smtp-Source: ABdhPJy0ewp0uEFaBQBaesBltDeq3cME811Vkmc0Sb1IiHPz4B5nVKrmElQ5KGJS7lTy5g5RkeTFiwi6ZSoTXmW2g5A= X-Received: by 2002:a17:90b:164a:b0:1dc:981d:f197 with SMTP id il10-20020a17090b164a00b001dc981df197mr20753184pjb.228.1652526865058; Sat, 14 May 2022 04:14:25 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Stephen Hocking Date: Sat, 14 May 2022 21:14:12 +1000 Message-ID: Subject: EasyRSA's pkitool has the use of sha1 to sign certs hardcoded all over the place. To: hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c60e7005def6e46f" X-Rspamd-Queue-Id: 4L0jZp5p2gz3mYT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ELXh6oKy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of stephenhocking@gmail.com designates 2607:f8b0:4864:20::1032 as permitted sender) smtp.mailfrom=stephenhocking@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1032:from]; MLMMJ_DEST(0.00)[hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000c60e7005def6e46f Content-Type: text/plain; charset="UTF-8" Hi all, After coming across the recent issue that OpenVPN clients using new versions of openssl wouldn't accept ca certs I'd generated a while ago, complaining that the signature was signed with a suitably strong hash I went hunting. Turns out the openssl.cnf entry of what the message digest is supposed to be is over-ridden by the explicit invocation of -sha1 on the command line for a few of the commands. -- "I and the public know what all schoolchildren learn Those to whom evil is done Do evil in return" W.H. Auden, "September 1, 1939" --000000000000c60e7005def6e46f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi all,

After coming across the recent issue that OpenVPN clients using new v= ersions of openssl wouldn't accept ca certs I'd generated a while a= go, complaining that the signature was signed with a suitably strong hash I= went hunting. Turns out the openssl.cnf entry of what the message digest i= s supposed to be=C2=A0is over-ridden=C2=A0by the explicit=C2=A0 invocation = of -sha1 on the command line for a few of the commands.
-- 
  "I and the public know
  what all schoolchildren learn
  Those to whom evil is done
  Do evil in return"		W.H. Auden, "September 1, 1939"
--000000000000c60e7005def6e46f-- From nobody Sat May 14 13:20:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A21C21AE04B3 for ; Sat, 14 May 2022 13:20:47 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0mNZ4SKZz4dRG for ; Sat, 14 May 2022 13:20:46 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 24EDKdf0071729 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 14 May 2022 09:20:39 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 24EDKdEP071728 for freebsd-hackers@freebsd.org; Sat, 14 May 2022 09:20:39 -0400 (EDT) (envelope-from wayne) Date: Sat, 14 May 2022 09:20:39 -0400 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220514132039.GX72471@post.wayne47.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20220415174953.GE13678@post.wayne47.com> <5db061cf-1e23-7cfb-fea-4573f379ae5d@puchar.net> <20220509170925.GQ72471@post.wayne47.com> <70185630-ccea-d92b-a691-bc9cd784cbf5@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70185630-ccea-d92b-a691-bc9cd784cbf5@puchar.net> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4L0mNZ4SKZz4dRG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-2.63 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.75)[-0.749]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983]; DMARC_NA(0.00)[wayne47.com]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, May 13, 2022 at 01:25:11PM +0200, Wojciech Puchar wrote: > >>> sudo make buildkernel KERNCONF=ROUTING > >>> the machine ran out of swap. with a bunch of messages like: > >>> Apr 15 12:11:26 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > >>> Apr 15 12:11:35 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > >>> Apr 15 12:11:37 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > >>> Apr 15 12:11:46 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 240593, size: 4096 > >>> Apr 15 12:11:55 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 236224, size: 16384 > >>> Apr 15 12:11:57 g1 kernel: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 245, size: 12288 > > i was getting such message when i used crappy SSD that stalled for very > long after receiving bunch of TRIM command from UFS filesystem and in the > same time OS did some swapping. I had the provider check the SSD and got this back: We see no issues present on the host at this time. I suspect you may be experiencing the effects of a noisy neighbor or swap is coming into play. > If you get out of swap, some processes (usually the largest) are killed. > And different messages are in log. Those messsages are on the screen. The machine >thinks< it's running out of swap: May 9 13:05:57 g1 kernel: pid 9507 (ctfmerge), jid 0, uid 0, was killed: out of swap space May 9 13:05:58 g1 kernel: pid 4969 (make), jid 0, uid 0, was killed: out of swap space May 9 13:06:00 g1 kernel: pid 828 (openvpn), jid 0, uid 301, was killed: out of swap space May 9 13:06:00 g1 kernel: tun0: link state changed to DOWN May 9 13:06:01 g1 kernel: pid 889 (sendmail), jid 0, uid 0, was killed: out of swap space May 9 13:06:03 g1 kernel: pid 909 (tcsh), jid 0, uid 5147, was killed: out of swap space May 9 13:06:05 g1 kernel: pid 1091 (tcsh), jid 0, uid 5147, was killed: out of swap space May 9 13:06:06 g1 kernel: pid 892 (sendmail), jid 0, uid 25, was killed: out of swap space May 9 13:06:08 g1 kernel: pid 814 (ntpd), jid 0, uid 0, was killed: out of swap space May 9 13:06:09 g1 kernel: pid 881 (bird), jid 0, uid 0, was killed: out of swap space May 9 13:06:10 g1 kernel: pid 532 (devd), jid 0, uid 0, was killed: out of swap space May 9 13:06:11 g1 kernel: pid 526 (dhclient), jid 0, uid 65, was killed: out of swap space May 9 13:06:12 g1 kernel: pid 474 (dhclient), jid 0, uid 0, was killed: out of swap space May 9 13:06:14 g1 kernel: pid 903 (getty), jid 0, uid 0, was killed: out of swap space From nobody Sat May 14 15:02:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CEFB11ACA797 for ; Sat, 14 May 2022 15:02:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-55.consmr.mail.gq1.yahoo.com (sonic307-55.consmr.mail.gq1.yahoo.com [98.137.64.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0pfC09Mtz4rg0 for ; Sat, 14 May 2022 15:02:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652540556; bh=JfqrSoJpmRfU0wr3XkcwF3eiFqp3DeWk5zT+a6OLOMc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Rln6Eboe0Znm2/KlFrU3giQaLRTDO3uulZUlRgjPFMg4HL0LGBhgagrYz4WoRmwx8T2KINT3S69DXjfAoTFa39jPDFq7v3o+nt3DxFs2nNmHUxZu9O0A06xoJueSDncg5IXS8PQmsBRDGiXy1QB/1Qdz6VdH4etbuAUbYXkz3SsCr0nbCZd6xEVUuOVCgvpkLANU9K2p/Po7MWHeS6oQib7gM275c9MBJDZGqzmaurqvHraKnMe+5scuolxQXMjQgq/jZxPQ//wQuXwcLpVvr4Cyz8WFmmfnoGXF2wWUEXqjgIgpgohwQNhpI7euBZTgGGSv9s1dO2j1/E2q5azopA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652540556; bh=AZyE5Ny93gd+YDiEyssMSCR6LB4zgPVbPbKqLquJo6o=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JPkuUIJT+4MGGYJwM6MZQbHZtV1lOa7fCDq/AHcJtgbRmYnRoHpazFDwxcpbdoEii1Uezs7BU9LCdaJJCPljPxOgERUN0Soq4Qi9ATNYFz4XVLhrgU9DfUU8gtNN1T8V1CeU4AO0oYx7RU6TADQkujyTD/au47SVAWuTy3Kwy2AFl41SDD1fy/4SdSyrYS9laynR4954jstDnD0vuG0FMvIJ+ZaceJzLj+1cvE5+D0h3ATjgcafwPA2o3Nbcvlryh0fiw055eZaWyFMGiJwwKF3EVualBRmrZlEkarGDtZqC1i00Qehw3YjJQQgRtgXVguEsMYbzs4fS5dVqmr1ZPw== X-YMail-OSG: pj2In9MVM1lhs.MfdWcpBb1FEZ9s1L6XwZYAQdUfV8gSdqTzZr0_KU2g1dYeme9 0tXSJiU34SBWoIM_eC37dFdc5OOFUMBBkFPTuZfhxIuVWs2RhvKr29oT9.fssq2UUOS7xsMFnlOY hftVVL76hsZqFIMvQGNKwK_TwSF.dCfpAf3KWkoUfcKl.q5g2xgNYguL1UfNE8GTtP69hjRi_GnE GdVILQ00uQ1TH7aIpSz2bQhMwMAj57jROpZvYMG_PXju7.cf.a2tj4fV1jeEfrSt5F27m7uwnLMU JZnlYcrrxY3Vj02s0TZK6AHHelbW46_60xOVs8Kl21g0iaKhEJ4PwnFY24TAxQ4l14LO6tFf7Elh sbe7ruHy76Cj3HKquf31cbF7asF7Eszk6Sqw3vAWra07t7kvXERtTzzcPR6Ltd5.7do_PHDUBO61 mWxXjRdPtvlXEaYZMjnhx5HZvhaHyskY7eSwNc8DuhTRkIhFfh59INkPm6Uc8vlxaBy6GMqSXuPF e.f26eFciyhs0.Y0rrmQlM09lCNzWH9ow1yJs96W7bbKJ4em4y6unUNxEQHEUivSJhf_CNhGun9C wFNPVNmTswWHXtozpl5p1lhCtACQj.sxZ7zg29OSC9bd4DDf2L4zsMptPpJU1oCnE64E5AdHximT UnfLdpT7sGn2dLWmXYxi80D_e.kgKE8xur0Ms1r1.5zwcCcfsQQ28aZatYSz0EeOPHRgzU2Jkm_4 Q0vEj4zgkiHquoT3ERSi6IrILVo08EmG.Wt1ZUsEx.bvZDjt1y8Vbaxm72uMUTvIB05xaRFivNeQ TiH77kJhiLAy6OnEYYzgSF6LN6ZUiFKJENV8aWCWkRJvGmM9ePIJW06gyvCydrdMW4xbzQOuvs7o oY37pQRhwXki2qZPkVQQoCvHWggzJiKSwQromlx2mFQNoRthjTrmy57n3iR6cQTjr1UXeOYruLe4 2MCHDRWOzH1zgwZbvnnaKDghyTMePRLPmpTYAwGU56wxB5pQ994JSPZfVzNrGzrHAi90dvC9yKDT OiMkuAo5Ni6Sg7G4L4lyuAJcvZKLigB2u7MqgBQJiS1oI5oHaqGUNSbuliLS7AFqQrpJkfsKdQEu q_agTIyyWujodAPOEtRDygRtwol4i4.bSn3jyMZYkzfr2D9VOgIx6Fpyy2qvLLJNIO0A46nH5j0x ir9jn30XZbU6CsvdU2ShJ2qXKE78XpQrS38SiINQASH3KzVnp_PAY2TOPE2bnOFdrs7HpomAoCOG va8ki2CICr6GGAhPVP0u.nNpoLgLBUeu3QVOlLaRNFgYnv5G0PUCX0niTmRLjyFEo9b3pvioq3nH 2QiQtawh2aD.5ORstSoTdIRiC54.h4RK4xKb1D8jBGDkxForqDbmlTgkQoznTW7wA5sRm0fkOCF5 HHKs_C469HJGCUHCbrOXEQvcnfyPQ6.yiOkjUdWGNvbPxbMJj6OjEvXRCGDClppek079dhZEWjY8 qaEUSWC7sXiPmyyAZKJSj5jrmkqxnRBUQ9hVABhkR2WVdXRdcQ1TDeBIn5tgfs88PGCr.V4sqXif idzcbOgONQGfqJlAcunZegUjvAO2mMoGFUezU3XOfglfIbdKD6QYtWBFPXL40TEjQK1ZJaRTt8oI 04n1ng0n1b0HxtVMnKpP3T.4OuGSjwd.4CtFG_w.472yqxDpenJPXs7Z72BWfJyN8jm5SVw2NE1G SmUMXftESdpr7pd4ZFrtP1uBbc7NcndFqTNJqI.5sEKjE4aKrPV29g8qRSCGXosXr8x6wBO0EE0q 0aRxVe2SgaKKCpE5cxc0YhPGkzuOgj6qQqBAxgCVnIcUGpcgxKjydGvPf0nP_vCpzxbHOlseiFGs SM0YIyzmHUKYhBD8vxgIas8ji0JTu44FMjOvMVWyIaGP0WKDFRJib6tHh9T87o4G5ZAd3RhFEkze 7Nl7AFjsB1JZ259nK0rAHQhFwcFNqMc6sUmUcVgpu96RemzRoEG.MozW6hilbsrpumRZas9DdBNP lnkkvncEwoSpPhgSwULa1b9PlXl58uhiXKNTU9RHLfVhGUn1dVez_5y3kQkXD_jMsxMc.gimwqrr 30o32PAuS1FZQPbDxpDmM6OWRe2pyRnavUl0l8mU.nIoelNzga9iQ0eT7g6XCH8CUPGNIDYSbQe6 V_fv1gvw9NgkyrLAQmhpF.WUlNRq7MSRdaxTYuk4n9yMuZN0qS_9TT.bUtsqyFfW0qLf5BrGcB23 _h2bSzcf6ppCRnuZxqUBE.O4B4c5XnAfVHoQQUILgFRpXwLE68ipmS53qx21KEKZrJyDZytVnUUJ yyfheHCOzrhM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 14 May 2022 15:02:36 +0000 Received: by hermes--canary-production-ne1-8676f67b88-z8zfq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 203c3143062722a53bca15f210488b7f; Sat, 14 May 2022 15:02:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM Message-Id: <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> Date: Sat, 14 May 2022 08:02:29 -0700 To: freebsd07@wayne47.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> X-Rspamd-Queue-Id: 4L0pfC09Mtz4rg0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Rln6Eboe; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N =E2=80=A2 Michael Wayne wrote on =E2=80=A2 Date: Sat, 14 May 2022 13:20:39 UTC : > The machine >thinks< it's running out of swap: >=20 > May 9 13:05:57 g1 kernel: pid 9507 (ctfmerge), jid 0, uid 0, was = killed: out of swap space > May 9 13:05:58 g1 kernel: pid 4969 (make), jid 0, uid 0, was killed: = out of swap space > May 9 13:06:00 g1 kernel: pid 828 (openvpn), jid 0, uid 301, was = killed: out of swap space . . . I've reported before the following (in a different wording): The wording of those messages was changes in main [so: 14], stable/13 , and releng/13.1 recently because the historical wording in 13.0 and before was normally a misleading misnomer that lead people to false conclusions much of the time. There are now 3 distinct messages, one still being a misnomer but 2 being accurate to the condition that causes the OOM kill: pid . . .(. . .), jid . . ., uid . . ., was killed: failed to reclaim = memory pid . . .(. . .), jid . . ., uid . . ., was killed: a thread waited too = long to allocate a page pid . . .(. . .), jid . . ., uid . . ., was killed: out of swap space Unfortunately, even for the updated messaging, that last, the out-of-space message, is not about the swap partition content itself. It is actually for one or both of a couple of related kernel data structures for managing the swap space: swblk or swpctrie zone exhausted. The way to know if out of swap might actually be involved in the context are some other messages that do not of themselves announce kills: swap_pager: out of swap space swp_pager_getswapspace(. . .): failed If you are getting either of those 2, then you are actually running out of swap space. Otherwise you are not. If you are not the real reason is one of 4: failed to reclaim memory a thread waited too long to allocate a page swblk zone exhausted swpctrie zone exhausted FYI: kernel: swap_pager: indefinite wait buffer: bufobj: . . ., blkno: . . ., = size: . . . is for a swap read taking over 20 seconds (including time when queued but waiting in the queue to start the transfer). A backlog of slow I/O for swap activity can lead to OOM kill activity so those messages may be suggestive, even though they do not directly report OOM kill activity. /boot/loader.conf can use the likes of: # Delay when persistent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=3D120 # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=3D-1 # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes (showing defaults, need to explore # alternative pairs of settings): #vm.pfault_oom_attempts=3D 3 #vm.pfault_oom_wait=3D 10 # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I do not know if you have tried any of these. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat May 14 19:45:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 863101ADAB18 for ; Sat, 14 May 2022 19:45:36 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0wwb6TBLz4SBL for ; Sat, 14 May 2022 19:45:35 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id d5so15587560wrb.6 for ; Sat, 14 May 2022 12:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=sThllVnUSz0WI33ViM3VYB7LHitfZC//XYfl4yzE1t0=; b=gNddXaWA58w+9KXGJzPrUVQc6TuSqpsr6tEkiER07iZ4BfHIPVzzXisqb+uoO6uVxS gEABFqcCVSfOOZN7FXd0pJDhLXCe/vqGQgmYbwaWAejHBj688M2a+RuSI59IrYMe8btU yfqsKWknTxkCUTbdP0RdtkNrOP0eLeSQ/XvzzzerbN7u8FOQwrH4pW3sDhrjM/c1GdOv jeeZDY9LK6qUM7YVQynQYsjYJs2dtb9PHW2WezRuQauQzsMlVmrIlvY+qVGSdPw5pbMo PPkqyveRorrzRzdNUkL+9VpFijAkwNv9PEmZYIackJ2mMw8uJC5TIhurjBpPF9aGnS7+ 4aHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=sThllVnUSz0WI33ViM3VYB7LHitfZC//XYfl4yzE1t0=; b=6dh9I5xerWrrFzMfOtfpp38EuFB/hzPqf4FimFMR4WZ8wpIM+fNZ1tKUG5oYpMICzm 2YnxyVKFc/bnHKoeSOfdu43P7mzTSj3YwpnwOa7D3IHqL9bqaLtBGJuQ3FY2a+kJUGor ffaCMvR5Df5YU/EOrVoDHWqDJaRs8raGDNkqZw4g+bHSb4aBrBl/MI1+15iXCxBGdQuQ sl9QXU+cZmRz/v3kEPNtzcuTBpT7tA3Yj7MG120wILHJqIscKFtcP4GXwnwprPk3AzOh MOcNzzJV2elBQWL+8P4oa8ugIAE+2j/qqYXifXkkmVq7M80/ipXvfLlmKClkZklN9KHG qYTA== X-Gm-Message-State: AOAM530y/JRVYbw6duL553OetXgUFdNDt2RdHdQ7PcOvecwcwBtIJZOY eljsOIkjXLKkDIFBbHr86aIEcVVerfI= X-Google-Smtp-Source: ABdhPJweJRzcNgYcKY//ua4aQ7vKsUoh/kHWjBeoR6QjschD5Q63QjqdQ+aw9xlbB+YSsP0XeasQMg== X-Received: by 2002:adf:f3cb:0:b0:20c:8afd:9572 with SMTP id g11-20020adff3cb000000b0020c8afd9572mr8497425wrp.179.1652557528875; Sat, 14 May 2022 12:45:28 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id w22-20020a7bc116000000b003945f955b51sm8809680wmi.3.2022.05.14.12.45.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 May 2022 12:45:28 -0700 (PDT) Message-ID: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> Date: Sat, 14 May 2022 21:45:26 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: freebsd-hackers@freebsd.org Content-Language: en-US From: Paul Floyd Subject: fcntl F_KINFO for Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L0wwb6TBLz4SBL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=gNddXaWA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi I'm working on updating Valgrind for FreeBSD 13.1. I've been trying to rewrite some of the code (used in tracking file descriptors, --track-fds=yes) to use fcntl and F_KINFO. The old code was IMO ugly, using KERN_PROC_FILEDESC to get info on all open files and then do a linear search for the fd. The new code is a lot shorter, but it doesn't quite work correctly. The Valgrind regression test system redirects stdout and stderr, which it then filters and compares to reference files. fcntl / F_KINFO doesn't seem to work correctly with fd 1 (or at least, that seems to be the problem the most often). Here is a small reproducer #include #include #include #include #include #include #include int main(void) { struct kinfo_file kf; kf.kf_structsize = KINFO_FILE_SIZE; if (0 == fcntl( 1, F_KINFO, &kf )) { printf("fcntl succeeded %s\n", kf.kf_path); } else { printf("fcntl failed\n"); } } Compiled with clang -g -o fcntl fcntl.c Then run it. For the first run $ ./fcntl > foo $ cat foo fcntl succeeded There's an empty string for kf_path there. Now that foo exists $ ./fcntl > foo $ cat foo fcntl succeeded /usr/home/paulf/foo Am I doing something wrong here or is this a bug / misfeature in the implementation of gcntl / K_INFO? A+ Paul From nobody Sat May 14 19:53:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8A26A1ADC60D for ; Sat, 14 May 2022 19:53:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0x5P6Lq7z4TKy for ; Sat, 14 May 2022 19:53:13 +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 24EJr7UP027208 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 14 May 2022 22:53:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 24EJr7UP027208 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 24EJr6Af027207; Sat, 14 May 2022 22:53:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 14 May 2022 22:53:06 +0300 From: Konstantin Belousov To: Paul Floyd Cc: freebsd-hackers@freebsd.org Subject: Re: fcntl F_KINFO for Message-ID: References: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> 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: 4L0x5P6Lq7z4TKy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.54 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.551]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sat, May 14, 2022 at 09:45:26PM +0200, Paul Floyd wrote: > Hi > > I'm working on updating Valgrind for FreeBSD 13.1. > > I've been trying to rewrite some of the code (used in tracking file > descriptors, --track-fds=yes) to use fcntl and F_KINFO. The old code was IMO > ugly, using KERN_PROC_FILEDESC to get info on all open files and then do a > linear search for the fd. > > The new code is a lot shorter, but it doesn't quite work correctly. The > Valgrind regression test system redirects stdout and stderr, which it then > filters and compares to reference files. fcntl / F_KINFO doesn't seem to > work correctly with fd 1 (or at least, that seems to be the problem the most > often). > > Here is a small reproducer > > #include #include #include #include > #include #include #include > int main(void) { struct kinfo_file kf; kf.kf_structsize = KINFO_FILE_SIZE; > if (0 == fcntl( 1, F_KINFO, &kf )) { printf("fcntl succeeded %s\n", > kf.kf_path); } else { printf("fcntl failed\n"); } } > > Compiled with > > clang -g -o fcntl fcntl.c > > Then run it. > > For the first run > > $ ./fcntl > foo $ cat foo fcntl succeeded > > There's an empty string for kf_path there. > > Now that foo exists > > $ ./fcntl > foo $ cat foo fcntl succeeded /usr/home/paulf/foo > > Am I doing something wrong here or is this a bug / misfeature in the > implementation of gcntl / K_INFO? When open(2) creates a new file, the vnode name is not entered into the name cache. I believe this is done to smoother the case like untarring large set of files, which would replace existing cached entries with probably not too useful new entries. F_KINFO uses name cache to reconstruct the last element of the path, on most real file systems like UFS. If this last element is not cached, F_KINFO is unable to return the path. From nobody Sat May 14 20:08:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1540D1AE0A85 for ; Sat, 14 May 2022 20:09:02 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L0xRc628Xz4Xmj for ; Sat, 14 May 2022 20:09:00 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32f.google.com with SMTP id m2-20020a1ca302000000b003943bc63f98so6547220wme.4 for ; Sat, 14 May 2022 13:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=twagS8zAUe7O7sNKO0BHCGdYAJxjApiPdrJzaE4HkLU=; b=Sqyfql7vc21rAjJRZeyFNDkGK5+3KVVn950Pr0MPnj7iDAY/33tYJy1zACo4AAF6/1 GXFlPY6bG1CelmAPwynvGB6MdXrwpZjv8ME04WmNuvP+cL8scZmg96QPHhSQ/0MuCD5s K4EvX3NhPxjtBJdr+8n7oSVG9yaKO3OL30hLmsa36FQ9pHY6Gs+sPI8inXe+bJk1td+B COq3ymY88LpabW3UeeGvmHzZ6RTG7PDs410SMQ+cOcOlHdb6rR+gK6MJ/lBMADjqGnHH LtzH4ATwq8cql7NJVW+hCYWLrY5vAFCBaAMflMewGj/FzwrIxIUDndN71Wsp+Zmlk5cH N4xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=twagS8zAUe7O7sNKO0BHCGdYAJxjApiPdrJzaE4HkLU=; b=IF9nL+01FGKMGT2Po01h8/JuQZRZa7CGPt5slErhd5lAP8m7rZHbIOuPwTLoJQlBdn 4WyJ0xFxsZZy93bEjKy7ZdeRne0PJ+W1J+lSbbb7ZFSVCuMrsQVxzfY8Dlk/wYAoZys5 EVy6rbsOwQpkv5y90+GZyVGPAoy63QD4xbLbXRMD95Bzo05SDvGDG+Kr9RjA57ULDhNq 9Ikg9O57x+f9sOff3T3CD6xKXWFA+thQNoCuOkCHJEdGZitn3QwLd0ZPsANWxC3hBHRC 8bgXBAlTV6gXl4ZTJfIHB5mZGy8N/Lx5HKcNChmuQo/vGq4ESJ92P6/nuLTU/mJ38O1D R9DQ== X-Gm-Message-State: AOAM532UijUdET3RmiM4ws2cYO64DVcwvOWDKEVETKfZOdD7hs2cxa7S kJxw/ICoU+kOnrX4pDfu88pVp5YoiaA= X-Google-Smtp-Source: ABdhPJyQe51BBMK8XZOyFe002qFTk7qZ99T9JD4pT4smOceoJvaE/8Qrj9usF3yJ1xoENAkm4bxiEQ== X-Received: by 2002:a05:600c:3b99:b0:394:70a0:12e3 with SMTP id n25-20020a05600c3b9900b0039470a012e3mr10142717wms.120.1652558933723; Sat, 14 May 2022 13:08:53 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id n14-20020a05600c500e00b00394708a3d7dsm9077230wmr.15.2022.05.14.13.08.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 May 2022 13:08:53 -0700 (PDT) Message-ID: Date: Sat, 14 May 2022 22:08:51 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: freebsd-hackers@freebsd.org Content-Language: en-US From: Paul Floyd Subject: Changes to stat ABI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L0xRc628Xz4Xmj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Sqyfql7v; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32f as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Has anything changed in the way that the libc functions in the stat family are compiled on FreeBSD 13.1 amd64 with clang 13? I'm getting a few Valgrind regression test failures related to this: FreeBSD 13 / clang 11 ==84746== Syscall param fstatat(flag) contains uninitialised byte(s) ==84746==    at 0x49942EA: ??? (in /lib/libc.so.7) ==84746==    by 0x499018B: fstatat (in /lib/libc.so.7) ==84746==    by 0x201E7D: main (stat.c:67) FreeBSD 13.1 / clang 13 ==57383== Syscall param fstatat(flag) contains uninitialised byte(s) ==57383==    at 0x499239A: ??? (in /lib/libc.so.7) ==57383==    by 0x201E57: main (stat.c:67) A+ Paul From nobody Sun May 15 17:30:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 629EE1ADF30F for ; Sun, 15 May 2022 17:30:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L1Tt63Qtdz3mNd for ; Sun, 15 May 2022 17:30:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa30.google.com with SMTP id o132so6465990vko.11 for ; Sun, 15 May 2022 10:30:22 -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=yDq4IIQnDxrH6FST8xs69XJzCRVzJ2pl0euDQHHv/Bg=; b=h6zlQ1T9Yt2Y+BlJUODXEHp6xV2z/Pjb1K55Qjkpz/C9DPpaLX5iF+UI3HjZjWdKEQ EFa8FDW8f8DY3iYXW5kbwavfYxMgpZzc+GvSqgHsE+Ox6t+iugX4Om/JJ6VGuT+K4o9V z/k4faIJPlOTC30xsF/4M340D5mjpFhe3sHCwupupyopaqN5poeDbMWeSTPdUtwd1VPS +mshPQqyDv/IBX7lWpWnakk2lGpQfpA7Ydt8dxx4PfnLpi6HZ8PUiTSk92H4DnfH0bM5 rpgbT6BqOCCmV8brj9yXFKx2O1atpeKnRj/haamTmX1lPUf9iuN9eZP2Dn9y00xOOGfT AJTQ== 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=yDq4IIQnDxrH6FST8xs69XJzCRVzJ2pl0euDQHHv/Bg=; b=YiQBTCLqIz/5g+0COf5IEKuUyBzV32p9gxjnqog2M9R2DJ62C2OqRPPbhetjVzJWfL 8TP/OlZ5niLDYmTLUDL7mrqoUjbYKxJec0NkOVXpwoTICN/Zwhc2ve+RzwmDWjtl69ri qPSzBMYwYAVD30rcxYw4KG557Z5YdqqmqKBIuR2oxS00+HgGlzo0Oyw8c6ERogWkWoGw +unq2zKq3jE/8KfkVKKZc4TJSsbBlkced22bU3IRrAhbjwHbYKsdzYQ1kVgHm8wRFo7R g3lALm95HqSq18/lD+bO3IOBCbJI5qhsb/nFoeaU8X3qnA+92FublBqEhEyuaHJUWIJt aKig== X-Gm-Message-State: AOAM5323+PaoaKZQkaxrgEgUqLr4RLtM/b2fwz9QSj+t9DBlDpVnk6Vl 0smLg4L8CQ0jesjTmrdYUmRWYJ8X3LQI6lA07k5ceg== X-Google-Smtp-Source: ABdhPJw5y68/tiHzVTz2qANBmEXMBOZun+QC6H491sk9GVHuS8hCY3sMGCRdcWFW0URS3nh24vIZ1lhJigB3JEimYig= X-Received: by 2002:a05:6122:2229:b0:32d:1642:b58b with SMTP id bb41-20020a056122222900b0032d1642b58bmr4583867vkb.27.1652635816454; Sun, 15 May 2022 10:30:16 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 15 May 2022 11:30:05 -0600 Message-ID: Subject: Re: Changes to stat ABI To: Paul Floyd Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000c884d705df10426c" X-Rspamd-Queue-Id: 4L1Tt63Qtdz3mNd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=h6zlQ1T9; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a30) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-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-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a30:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000c884d705df10426c Content-Type: text/plain; charset="UTF-8" ino64 has gone into the tree. The stat structure layout changed. 69921123490b99c2588b0c743bc4af32bbe6601c went into the tree a while ago, but maybe recently enough to mess this up. Author: Konstantin Belousov Date: Tue May 23 09:29:05 2017 +0000 Commit the 64-bit inode project. Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify struct dirent layout to add d_off, increase the size of d_fileno to 64-bits, increase the size of d_namlen to 16-bits, and change the required alignment. Increase struct statfs f_mntfromname[] and f_mntonname[] array length MNAMELEN to 1024. On Sat, May 14, 2022 at 2:10 PM Paul Floyd wrote: > Hi > > > Has anything changed in the way that the libc functions in the stat > family are compiled on FreeBSD 13.1 amd64 with clang 13? > > > I'm getting a few Valgrind regression test failures related to this: > > FreeBSD 13 / clang 11 > > ==84746== Syscall param fstatat(flag) contains uninitialised byte(s) > ==84746== at 0x49942EA: ??? (in /lib/libc.so.7) > ==84746== by 0x499018B: fstatat (in /lib/libc.so.7) > ==84746== by 0x201E7D: main (stat.c:67) > > FreeBSD 13.1 / clang 13 > > ==57383== Syscall param fstatat(flag) contains uninitialised byte(s) > ==57383== at 0x499239A: ??? (in /lib/libc.so.7) > ==57383== by 0x201E57: main (stat.c:67) > > A+ > > Paul > > > > --000000000000c884d705df10426c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ino64 has gone into the tree. The stat structure layout ch= anged.=C2=A069921123490b99c2588b0c743bc4af32bbe6601c went into the tree a w= hile ago, but maybe recently enough to mess this up.

Aut= hor: Konstantin Belousov <kib@FreeBSD.org>
Date: =C2=A0 Tue May 23= 09:29:05 2017 +0000

=C2=A0 =C2=A0 Commit the 64-bit inode project.<= br>
=C2=A0 =C2=A0 Extend the ino_t, dev_t, nlink_t types to 64-bit ints.= =C2=A0 Modify
=C2=A0 =C2=A0 struct dirent layout to add d_off, increase = the size of d_fileno
=C2=A0 =C2=A0 to 64-bits, increase the size of d_na= mlen to 16-bits, and change
=C2=A0 =C2=A0 the required alignment.=C2=A0 = Increase struct statfs f_mntfromname[] and
=C2=A0 =C2=A0 f_mntonname[] a= rray length MNAMELEN to 1024.

On Sat, May 14, 2022 at 2:10 PM Paul= Floyd <paulf2718@gmail.com&g= t; wrote:
Hi


Has anything changed in the way that the libc functions in the stat
family are compiled on FreeBSD 13.1 amd64 with clang 13?


I'm getting a few Valgrind regression test failures related to this:
FreeBSD 13 / clang 11

=3D=3D84746=3D=3D Syscall param fstatat(flag) contains uninitialised byte(s= )
=3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 at 0x49942EA: ??? (in /lib/libc.so.7) =3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 by 0x499018B: fstatat (in /lib/libc.so.= 7)
=3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 by 0x201E7D: main (stat.c:67)

FreeBSD 13.1 / clang 13

=3D=3D57383=3D=3D Syscall param fstatat(flag) contains uninitialised byte(s= )
=3D=3D57383=3D=3D=C2=A0=C2=A0=C2=A0 at 0x499239A: ??? (in /lib/libc.so.7) =3D=3D57383=3D=3D=C2=A0=C2=A0=C2=A0 by 0x201E57: main (stat.c:67)

A+

Paul



--000000000000c884d705df10426c-- From nobody Sun May 15 17:31:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7A9141AE070D for ; Sun, 15 May 2022 17:31:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L1Tvw3Smwz3nNS for ; Sun, 15 May 2022 17:31:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe30.google.com with SMTP id v139so13389547vsv.0 for ; Sun, 15 May 2022 10:31:56 -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=lnXwgwdT630XeTbo7M43ilF7/ZaDkX0WhmmwjM+tcU0=; b=Wh7A6Bhh9+ppyq0JX+01wDN10o6+sgefavmRuu2Bxa+u9FIMN1RTIQZECrJTKjX9TL j3ib5m7r9iX+b/GCuQx1rgTxHPHhunsNU+JttPrKN5jZYqejae8sGOMLG81XhM0A6YdC HsIOdQ+1UJMbhBWSIN4T7eFXmhqnN9ALoP+FMKhyTJ8dgr/R/GY6MwTqg5Hy6y9BMRus ML9QGxdCkB6CtW9+narEK3U8C/4Sk9SI7VDJJzPi0HOI+V84Rz6vVuWrOduFUyIEM/L9 LxdzESvmXam7Km7J5QSU3WFNr/pmE6z3FDM9t3zxUKZXVpsR8qE+TRZNz6hKSQvPhxoM prTw== 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=lnXwgwdT630XeTbo7M43ilF7/ZaDkX0WhmmwjM+tcU0=; b=dWng00299ArWPJvFKo3fkf/J8sxsYgZ060PwPVvhNz22hCzhLeXX655bJPnj6lGdCc X1tt1ND1RqA4YS7WTJvjpWGX5z5EMgdB/UrupXGcGqNpI0iVHoU/YpoP7lDfBQKZCFjN Na0Ohi+WOcftPAxvRtPiguhesh9e/uMN5RMGCTOCqiY0c+ZsgAYW8alL+aynY7nQeAqL pUct1uFmiTYGUFdTWttiKKkgr0qt9QV0DxnCHC4AETuyCw3a9qRNl9p8WY6CV6na7AzH t+VCQ4bSv+3iVkRNq5vsIFAK157MUPfQsXovv8ehulVoZE9XJAhePsKOHW3wi9OYZ1q+ CESg== X-Gm-Message-State: AOAM533Uf/IeefiA97I4tCIQ3XI+dbDwyf0ykGURYWY0ZMqM5Fo+3CE1 aKA7uTMt8WYS1+y8iMGz5xtSpfiJtc5bxXW/UgySAQ== X-Google-Smtp-Source: ABdhPJyS+oKvqBC7PR9ty7w19JLs59k3yVuAk06S+la9w4kSVNnnw3PR+lk17a07vRdWLLErN1Heccl6fJ9U1B6R+Cc= X-Received: by 2002:a67:f445:0:b0:32c:c32c:c7c1 with SMTP id r5-20020a67f445000000b0032cc32cc7c1mr4771460vsn.51.1652635910371; Sun, 15 May 2022 10:31:50 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 15 May 2022 11:31:39 -0600 Message-ID: Subject: Re: Changes to stat ABI To: Paul Floyd Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000618e7505df104873" X-Rspamd-Queue-Id: 4L1Tvw3Smwz3nNS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Wh7A6Bhh; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e30) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000618e7505df104873 Content-Type: text/plain; charset="UTF-8" Scratch that, this is a clang 11 vs clang13 issue. Most likely clang 13 is more aggressively optimizing, so fstat is not actually on the stack... Because of LTO, you'll need to check the disassembled binary to know for sure. Warner On Sun, May 15, 2022 at 11:30 AM Warner Losh wrote: > ino64 has gone into the tree. The stat structure layout > changed. 69921123490b99c2588b0c743bc4af32bbe6601c went into the tree a > while ago, but maybe recently enough to mess this up. > > Author: Konstantin Belousov > Date: Tue May 23 09:29:05 2017 +0000 > > Commit the 64-bit inode project. > > Extend the ino_t, dev_t, nlink_t types to 64-bit ints. Modify > struct dirent layout to add d_off, increase the size of d_fileno > to 64-bits, increase the size of d_namlen to 16-bits, and change > the required alignment. Increase struct statfs f_mntfromname[] and > f_mntonname[] array length MNAMELEN to 1024. > > On Sat, May 14, 2022 at 2:10 PM Paul Floyd wrote: > >> Hi >> >> >> Has anything changed in the way that the libc functions in the stat >> family are compiled on FreeBSD 13.1 amd64 with clang 13? >> >> >> I'm getting a few Valgrind regression test failures related to this: >> >> FreeBSD 13 / clang 11 >> >> ==84746== Syscall param fstatat(flag) contains uninitialised byte(s) >> ==84746== at 0x49942EA: ??? (in /lib/libc.so.7) >> ==84746== by 0x499018B: fstatat (in /lib/libc.so.7) >> ==84746== by 0x201E7D: main (stat.c:67) >> >> FreeBSD 13.1 / clang 13 >> >> ==57383== Syscall param fstatat(flag) contains uninitialised byte(s) >> ==57383== at 0x499239A: ??? (in /lib/libc.so.7) >> ==57383== by 0x201E57: main (stat.c:67) >> >> A+ >> >> Paul >> >> >> >> --000000000000618e7505df104873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scratch that, this is a clang 11 vs clang13 issue.
Most likely clang 13 is more aggressively=C2=A0optimizing, so f= stat is not actually on the stack... Because
of LTO, you'll n= eed to check the disassembled binary to know for sure.

=
Warner

On Sun, May 15, 2022 at 11:30 AM Warner Losh <imp@bsdimp.com> wrote:
ino64 has gone in= to the tree. The stat structure layout changed.=C2=A069921123490b99c2588b0c= 743bc4af32bbe6601c went into the tree a while ago, but maybe recently enoug= h to mess this up.

Author: Konstantin Belousov <kib@F= reeBSD.org>
Date: =C2=A0 Tue May 23 09:29:05 2017 +0000

=C2=A0= =C2=A0 Commit the 64-bit inode project.

=C2=A0 =C2=A0 Extend the in= o_t, dev_t, nlink_t types to 64-bit ints.=C2=A0 Modify
=C2=A0 =C2=A0 str= uct dirent layout to add d_off, increase the size of d_fileno
=C2=A0 =C2= =A0 to 64-bits, increase the size of d_namlen to 16-bits, and change
=C2= =A0 =C2=A0 the required alignment.=C2=A0 Increase struct statfs f_mntfromna= me[] and
=C2=A0 =C2=A0 f_mntonname[] array length MNAMELEN to 1024.
<= /div>

On Sat, May 14, 2022 at 2:10 PM Paul Floyd <paulf2718@gmail.com> wrote:
Hi


Has anything changed in the way that the libc functions in the stat
family are compiled on FreeBSD 13.1 amd64 with clang 13?


I'm getting a few Valgrind regression test failures related to this:
FreeBSD 13 / clang 11

=3D=3D84746=3D=3D Syscall param fstatat(flag) contains uninitialised byte(s= )
=3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 at 0x49942EA: ??? (in /lib/libc.so.7) =3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 by 0x499018B: fstatat (in /lib/libc.so.= 7)
=3D=3D84746=3D=3D=C2=A0=C2=A0=C2=A0 by 0x201E7D: main (stat.c:67)

FreeBSD 13.1 / clang 13

=3D=3D57383=3D=3D Syscall param fstatat(flag) contains uninitialised byte(s= )
=3D=3D57383=3D=3D=C2=A0=C2=A0=C2=A0 at 0x499239A: ??? (in /lib/libc.so.7) =3D=3D57383=3D=3D=C2=A0=C2=A0=C2=A0 by 0x201E57: main (stat.c:67)

A+

Paul



--000000000000618e7505df104873-- From nobody Mon May 16 07:59:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 71C641B35F01 for ; Mon, 16 May 2022 07:59:37 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L1s9426vdz3Nj7 for ; Mon, 16 May 2022 07:59:36 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id m1so19309874wrb.8 for ; Mon, 16 May 2022 00:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=ErHvUIB2DD6Drku3EUGuPuvcY5dvDIcadt4kLVdRKdY=; b=KeoSr6xE/8wiJOYPeaG/P0JFRQcBy7/rvZwkdfNmG1cUjDYkTB5VUCxp4hoCk139/b gsA7ecGQnFERoXl5146tpfYOAliEC/y1nrV+aYxVmswZGOuUFIrwTYjBZZgY9hRMoz5T x6K2xjNH+/GvzrSmxxUmeOTr++0slZQSZYnvMSFK/3pmQAFran3IAVTiJpvOxDZJ5eW7 ExdItfSCpu/T13LTpH0pzhSxQckDznMu7VYycZfixrYT6ZASKPZvegL++kvzmoqklYL9 bGkUcesrdxxJ1yd27bOlLie8va7vgoBuiT+G3lbxH3YFgtxkQcQhiUkc+VyqwURcggxL 2agA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=ErHvUIB2DD6Drku3EUGuPuvcY5dvDIcadt4kLVdRKdY=; b=zM4DS/Ee1FiHjc9kCHhslcQDN717RHbnPCC2oQFku/vJE3o+f01S18jTbw5yMbCInO gRHC+g4ND7gaIa7E+DavTc1UYrbztw04C0k0FO27MQjcPgmvTf9X42gzMCdHykuXybqc WrnsQ+LPg+baEZzk+HpsAWCOXI6XzWW3gAlsTDw4eEk3h91SsHbU3sady2w8Esy1Klnm nelCMr6XvOxmGrGEb/vsQ8UiHeqN9VEBCIs79eu1LQp3OKifaRYWzmusUSgmx/0W9ylg Orw5jr/YUk8OEZ2MgH9P+NlmYxaD50cYY2X/A7SAAMI8bugTFFMPXHCa06mcBX1nCBIb veLw== X-Gm-Message-State: AOAM531VvA/qVgkPbUtMHoT0OsWE0e06DHW+iY083YcgKIcVMYUgKFRU 2/mN7MbBoKjJBEQXXCvluLwsExRN6meuZw== X-Google-Smtp-Source: ABdhPJzO/+rbMFMUGObsaurK55lgS9SDCWr5sgzML/aqe4rGSibEuUxVImY3Fa/PhKNzipHZwY+kcA== X-Received: by 2002:adf:fd10:0:b0:20d:c38:d43a with SMTP id e16-20020adffd10000000b0020d0c38d43amr1501988wrr.84.1652687975080; Mon, 16 May 2022 00:59:35 -0700 (PDT) Received: from [137.202.243.61] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id z12-20020a7bc7cc000000b003942a244f39sm14551781wmk.18.2022.05.16.00.59.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 00:59:34 -0700 (PDT) Message-ID: <8771f132-7388-29b6-313b-62b92869002d@gmail.com> Date: Mon, 16 May 2022 09:59:29 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Changes to stat ABI To: FreeBSD Hackers References: From: "Floyd, Paul" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L1s9426vdz3Nj7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KeoSr6xE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; 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)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-05-15 19:31, Warner Losh wrote: > Scratch that, this is a clang 11 vs clang13 issue. > > Most likely clang 13 is more aggressively optimizing, so fstat is not > actually on the stack... Because > of LTO, you'll need to check the disassembled binary to know for sure. > Hi Warner I'll do some tests on varions combinations of FreeBSD 13 / 13.1 and clang 11 / 13. I don't understand why optimization would affect stat family syscalls but not any other syscalls though. One issue is whether system calls use a function prolog or not. Prior to FreeBSD 13.0, Valgrind assumed no prolog and looked directly for a return address at the top of the stack rather than saved RBP then the return address. This changed in FreeBSD 13.0. Actually I didn't see exactly what had changed in FreeBSD, but disabling the syscall-with-no-prolog check fixed a lot of test failures. It's also possible that the code that looks for CFI didn't work prior to FreeBSD 13.0. I'll also do some tests on Valgrind so see if the no-prolog code is causing this. A+ Paul From nobody Mon May 16 14:37:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 055E31AD8F4B for ; Mon, 16 May 2022 14:38:02 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L220n1ZZlz3Q52 for ; Mon, 16 May 2022 14:38:01 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 24GEbraB007931 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 May 2022 10:37:54 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 24GEbr84007930; Mon, 16 May 2022 10:37:53 -0400 (EDT) (envelope-from wayne) Date: Mon, 16 May 2022 10:37:53 -0400 From: Michael Wayne To: FreeBSD Hackers Cc: Mark Millard Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220516143753.GY72471@post.wayne47.com> Mail-Followup-To: FreeBSD Hackers , Mark Millard References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4L220n1ZZlz3Q52 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [-0.69 / 15.00]; ONCE_RECEIVED(0.10)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; NEURAL_HAM_LONG(-0.77)[-0.770]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[wayne47.com]; NEURAL_SPAM_MEDIUM(0.97)[0.973]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[yahoo.com] X-ThisMailContainsUnwantedMimeParts: N More info. I am running UFS so the ZFS should not be an issue % pstat -s Device 1K-blocks Used Avail Capacity /dev/md99 1048576 0 1048576 0% % df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ufs/rootfs 25388500 17630840 5726580 75% / devfs 1 1 0 100% /dev On Sat, May 14, 2022 at 08:02:29AM -0700, Mark Millard wrote: > The way to know if out of swap might actually be involved > in the context are some other messages that do not of > themselves announce kills: > > swap_pager: out of swap space > swp_pager_getswapspace(. . .): failed > > If you are getting either of those 2, then you are actually > running out of swap space. Otherwise you are not. I am not getting either of those. Watching swap as ctfmerge runs up confirms that I am likely not running out of swap. Note also that I continue to run a kernel built with the suggested patch to /sys/vm/vm_pageout.c > If you are not the real reason is one of 4: Likely the swap device isn't responding within a "reasonable" time. (from another mail in this chain) > FYI: > > kernel: swap_pager: indefinite wait buffer: bufobj: . . ., blkno: . . ., size: . . . > > is for a swap read taking over 20 seconds (including > time when queued but waiting in the queue to start > the transfer). I got this message on 12.1. I am not getting it on 12.3 > /boot/loader.conf can use the likes of: > > vm.pageout_oom_seq=120 > vm.pfault_oom_attempts=-1 > #vm.pfault_oom_attempts= 3 > #vm.pfault_oom_wait= 10 > > I do not know if you have tried any of these. Quoting one of my old emails: On 12.1 I used sysctl to set > vm.pageout_oom_seq=120 > vm.pfault_oom_attempts=-1 > > There was no improvement. I still see processes getting killed due > to no swap space despite only 7-8 MB being reported used. It sorta > feels like it's not really able to use swap at all. > > Note that everything worked fine on 11.x, this is a new issue on 12. I have not tried this on 12.3, nor have I tried the other two. Will do. From nobody Mon May 16 19:07:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3692F1AEECF3 for ; Mon, 16 May 2022 19:07:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.gq1.yahoo.com (sonic312-24.consmr.mail.gq1.yahoo.com [98.137.69.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L27zl0rckz4pwm for ; Mon, 16 May 2022 19:07:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652728043; bh=oJ3e0q80t23pIqoMh+cjeu3M8iRCF+Lua27pt+e5w78=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mTOItqBTjfwCbG4IQefZhlnt5kMMZ2GWYiYaJO/u3vQWPTEx88p9PMUXa2O/5/nuzaUxbXIDadJ4qEA2KOESAshpLL3hg/i8xrVukXS0xH9DEHxHOVjMM8x/yFY+4KrcrjsCrTm0uK+wbmKtqAEL9EirnO/xIqFka2rkSezvpwFypkBpGpZopEJPRf7bCahkHXhNgEbiXlnTSMR3jvlLwsCY/xxuSuA8/IY908B8p3rWEBin0mThTx2OHA6Aj3WbNY4nrF5IH5B8u7o5Xxkfgj/TtJmlr8UycmIeT5cl/RVX0YsxwQk1T55fBCc5cTPS6RIyN6bRxUQzVIGdeHKzEA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652728043; bh=RLAt3Us1OLbA6UqnWX3XxiqZbNs252Wo0Nba6C47Xro=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OlAsblIeix2P/2WHQWuuaUkUaQnuIfkgGu6LSmB2hMdMbZmKnyrPVyVGxQ6SRA/ffYkpYZlY9xO2pkTdoL/jTTBEA6SQ8PkVSqe42Q5AxE2X+vNkJ3F/oxClTbTC2AatxrIE8E6V2PwiLc7iONxSO7xpFZfnAUQn9zjzlSerGWYRYo9s6fU84fRQmJmUvZAuZTVxukmPDeqSJvB6yjLJ8Q5GpxivSGOzeMWFtgt1dZP2lEuhq/iKSUdeVXk+LWLUUzIBqmYXvmxIqry8W+/HlZ/Lost5m2nQDO5qlmzLiQHZ9c6x5Q4DqPOgiPrPPZ5Pp81e9SQbvoEwEFI6bBTaNA== X-YMail-OSG: RbKv4cwVM1l4FIqW1Pc_syMt_2sCa_ZFCgDl1nPclp6kcb4xoelxNx3QxFLnlcU w6CPtLGOG24zVMgYpTZXDIpXQ2_IXYwrPKZ7HoD8LBZdBUScq4OOJF7kyq9R3Mr7dWD4dpCfDXUV 0DzUdTI2jqKek.mYNNur262WhJUc6ePKM6N5f0TrAaEkY6Mvt.rSKcEt9Lv3QPTETP.inYTRBq0e fxvEdw7vaVZOJHnBZWVfFqAkOZQVnRTuMqhpQ.IalfBa0kaiqbUwnOSqQYU1oB3iyQXZjAErvka2 Azu675ObCoOwWsePCP63Ttd8U0NmA3t.uyUeYrYxDFSXoGI7eKdwS_jOx1MBzkAFQzcLyA9NHqxg _M1.bMDaRF_uOREFFi9Aoh4FNYTeDCpswaMQlFzTJGUY2nI8nypJcuEsN7SRQArfmMHOgNyiW6yL si3iiTWXo4GY1iVEbOuBEfFwjtLdppBo1Szlrc3xNRodFof2zU3McaqvlI0D2lEuUwHeHpLsSDf3 F_067L8wpIDn0WmvITrX_5Cbxe8utGdvYnqznGTBGulFB.PsF_pM.TV4.kem7EOaX_ARbmUDkmaw Z1injhz5rrQS9o.f0nkjVrTCpgBIeb1JEejYYC7WSt20lMBASGziOEw3QgTCEAYoJI2KfQaaWmc4 xoLGtvCP_aCJQyEUDowzn.ph_3w0fI.H74G55sxqxWxUBWNJYT9W8dyGPjjaI1E3xevKQS.jDnjc 3RvV5p2LDksvyvQDr8p0NoRgepHWAYtQn3rdwRVbW3duO2y9Rjn6z84gwxON4QmlYQA391lNYN6z 2hotkj.2YtBxIasG5r9Jhb_k4JX_z77.Pp7sUWyH_rh9mDw7fyWnUwGAbExGTR9Yna1YtYWz3mad FO5yEfv1zrY1zkAMpxN_ixf4X7rPwfdxjg3RDT2GR8KUewJg5G380vhulGcz5G484LAgwh4F7A27 sxwrWfRlAwSqxAuhzZ_yWGgTuJWJoiLT_lWiYnU0AOMkF9zOgrnp5awmNnBGvBymM9Pdea0K5318 .s9lHVi57nh.SDXssr5tpEswXgLTSqMXfRHl7Nx33a1N5j6_jxlDrk8KhdJRTzKNnUKmo6SDSkLI yqzP.eU8uzQvtXyZCfXYwhFPs_iNQEleO_pCQYgRu3XHbFmD4Ncs18xaE2CVq41e4TKEeOD2rJ4g N5c.KifXVRihCmHGJv0sDXfKAzEUCMugEusiQppN3.yKEp3mEX0hfIMrTZuKiOMKYyb4CSJ1_cD0 jqkAvtBxd7YNacGbUyd9bBf5tS3Oq_8xUrXTfyWaG3pFqaQIXaaS66KVyiiMQ3AqgLS7fFngci0w H.PXpcuaDbXdKluX2aIMhhmyEO4cAY8j89xKdQfUlvEHRNMI90hgNTx2yDavOOX4VUK72zrtdXi0 Et8e5cTbc9ca3DVB4PWaf2Qfk5511O3o4L3eSdIDZX5rRTFnJxJuAJVVLUbcyMZ5fhn.Uzn.OK2F uJQ4VkO9K5OlNDwevbppucSG3orOZhvJiZTamQCmL9AvmUQB0KWyS0kHZng4XdEgwe4tFgQXvXgo .5BiOkMT7evohG9ZDEk5ard20lD.CDXrzoyd7XpTM3cXkj_wg2KSqHYAp7f_7wA7kdgG1G5NP24n jBvvzcpDpoG2skbvf32BqLQbHqy7tOJBbcRSyAd08mOYJtYSW3iuJjhi3ZqR.wn19TZZBs_C_tn. btSwbj3YIX9Qk0AFpmrMIg8tq2m7oaKzOP4kerxFAzZ0yAojEktfgYz1zaJoTOdlCrb0WAFoYBwl aln796L.x0lTwlui_BYUncNlZuWDr.C1lhVedjVKyCeLMXFSA0ur_ogcfPO0nxTt8yQxRiKMhdbT sbeWPvE5SOPMPOlwTzsr7eNVZc_g1ReebdFN9r_0iM4lZS6Ov.O2PpLrbm5ZNt1sHRROwHkKbuD_ X6vCayJyFX3CUTOccEUSSjBJwm1slAWRiAEjFcl0OGqfO74X70c7fCggneLOb5TSTsnZ9W1gbVkK 6DPok36Qv5DnCrpdPwC094N11N6g7CR.rKYkUxWg3jB8tS2vg2y0WSl9JiC.O05p0Yf2jX0wf0BF Leu5JBaoNFJ1Jtbvhi69yFpUSdWvQYlvqw_EVjj69fjjE90kA5iDaWLmcHrtoMYyxrkMdW.uQviA eNDe07lJ103dPk2X1rpTIjMlyNm3WwRanocm.0wEnSGiAicjGKfPBxIL8vlOu.2o8rM416_mTQJd Y5TEQ1fMy83o1I9LmxWLozv5RwKMIYWdKxYLmZUW5rr9kVMrkical9B_YHMjdVKInnWJtPWXgOHO H3Tg_gfGpM9Si X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 16 May 2022 19:07:23 +0000 Received: by hermes--canary-production-ne1-8676f67b88-z8zfq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1dbc3656ab8f8fa531c43a2a50d4a9ec; Mon, 16 May 2022 19:07:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM From: Mark Millard In-Reply-To: <20220516143753.GY72471@post.wayne47.com> Date: Mon, 16 May 2022 12:07:18 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> To: Michael Wayne X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4L27zl0rckz4pwm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mTOItqBT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.44 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.205:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-16, at 07:37, Michael Wayne wrote: > More info. I am running UFS so the ZFS should not be an issue >=20 > % pstat -s > Device 1K-blocks Used Avail Capacity > /dev/md99 1048576 0 1048576 0% That may well explain some (or all?) of what is going on: file-system/vnode backed swap spaces are subject to deadlocks. On 2017-Feb-13, at 7:20 PM, Konstantin Belousov = wrote on the freebsd-arm list: QUOTE . . . swapfile write requires the write request to come through the filesystem write path, which might require the filesystem to allocate more memory and read some data. E.g. it is known that any ZFS write request allocates memory, and that write request on large UFS file might require allocating and reading an indirect block buffer to find the block number of the written block, if the indirect block was not yet read. As result, swapfile swapping is more prone to the trivial and = unavoidable deadlocks where the pagedaemon thread, which produces free memory, needs more free memory to make a progress. Swap write on the raw partition = over simple partitioning scheme directly over HBA are usually safe, while = e.g. zfs over geli over umass is the worst construction. END QUOTE I only use swap partitions for swap space --in order to avoid the deadlocks in parts of the kernel operation that I ran into otherwise. > % df > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ufs/rootfs 25388500 17630840 5726580 75% / > devfs 1 1 0 100% /dev >=20 > On Sat, May 14, 2022 at 08:02:29AM -0700, Mark Millard wrote: >> The way to know if out of swap might actually be involved >> in the context are some other messages that do not of >> themselves announce kills: >>=20 >> swap_pager: out of swap space >> swp_pager_getswapspace(. . .): failed >>=20 >> If you are getting either of those 2, then you are actually >> running out of swap space. Otherwise you are not. >=20 > I am not getting either of those. Watching swap as ctfmerge runs up=20 > confirms that I am likely not running out of swap. >=20 > Note also that I continue to run a kernel built with the suggested = patch to=20 > /sys/vm/vm_pageout.c (The oldest code I cover for extra messaging relative to OOM kills and and the like is releng/13.0 code these days. As I remember, the code has been moved around between files some since 12.x . So the below may read odd for your context.) Which suggested patch(s)? Any patches for . . . sys/vm/swap_pager.c ? swp_pager_meta_build: swap blk uma zone exhausted swp_pager_meta_build: swap pctrie uma zone exhausted sys/vm/vm_fault.c ? vm_fault_allocate_oom: proc %d (%s) failed to alloc page on fault, = starting OOM sys/vm/vm_page.c ? thread %d waiting for memory For sys/vm/vm_pageout.c I have messages: vm_pageout_mightbe_oom: kill context: v_free_count: %u, v_inactive_count: %u, v_laundry_count: %u, v_active_count: %u (The 2 forming one line of output.) failed to reclaim memory a thread waited too long to allocate a page (The 2 above are now the standard messages in releng/13.1 , stable/13 , and main .) swblk or swpctrie zone exhausted (In releng/13.1 , stable/13 , and main this is still shown as the mismoner "out of swap space".) >> If you are not the real reason is one of 4: >=20 > Likely the swap device isn't responding within a "reasonable" time. = (from another mail in this chain) >=20 >> FYI: >>=20 >> kernel: swap_pager: indefinite wait buffer: bufobj: . . ., blkno: . . = ., size: . . . >>=20 >> is for a swap read taking over 20 seconds (including >> time when queued but waiting in the queue to start >> the transfer). >=20 > I got this message on 12.1. I am not getting it on 12.3 >=20 >=20 >> /boot/loader.conf can use the likes of: >>=20 >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >> #vm.pfault_oom_attempts=3D 3 >> #vm.pfault_oom_wait=3D 10 >>=20 >> I do not know if you have tried any of these. >=20 > Quoting one of my old emails: > On 12.1 I used sysctl to set >> vm.pageout_oom_seq=3D120 >> vm.pfault_oom_attempts=3D-1 >>=20 >> There was no improvement. I still see processes getting killed due >> to no swap space despite only 7-8 MB being reported used. It sorta >> feels like it's not really able to use swap at all. >>=20 >> Note that everything worked fine on 11.x, this is a new issue on 12. >=20 > I have not tried this on 12.3, nor have I tried the other two. Will = do. >=20 Can you switch to using a swap partition instead of file-system/vnode backed swap space? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon May 16 19:44:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C4BD81B35B04 for ; Mon, 16 May 2022 19:44:31 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L28pQ6pxXz4typ for ; Mon, 16 May 2022 19:44:30 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32d.google.com with SMTP id c190-20020a1c35c7000000b0038e37907b5bso216221wma.0 for ; Mon, 16 May 2022 12:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=PkL50bRqUixDHjUY5xyRKQR1M0WkuDQjZn/7qZcViW4=; b=BHZnEWk3lpbQ7RfHwejTWtJvJeRgb2d2nW0j4hYITQKdII4Rz3xgNLOk/2WQkJy0SY 5wNIfhs5wlegv6ek5rOVzpOwsf4U+r3XVcB67KWzyArVP/0dqRirbyqBC671HacMuMbT I64UxK1vn3Afmv7C7pZ8itZTbi+2ob/xpbYVojQk4w6Gmg1t+oGcieHuVWvq48VrxNX2 3hj2+t9U8EAg8kFuisE9xKPrC4KYYSUj/cKeCB4yjilDpSRFZFfm0jgw/9EpWYz8yZpS 4rB0T/05Ok2p9OZjvO+jbvMvcMypIUEGzdC+R26+AW3eBzWHVC3MlAjDqJSIADbMLLkJ k0mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=PkL50bRqUixDHjUY5xyRKQR1M0WkuDQjZn/7qZcViW4=; b=exWeGOcqzpFlCcLztP0KUz3t9+ipJyoUIjHP4DIomLA3GbTAuC4BaZxP733WKF/faw /8ehGbUoNKhgN7N/b0T46VaS//bbfhyDnbrpcr3nNhFkaiHQW0RhooZ2ZyvWc4NPLGYW FBAlAmpwfIDabsE5rFgD9VGk4ByU+WI/BJn0oQAR7vmyz99FntXCiad6hkhNTPz4Bw8n 61LbtwQvozPOHwFQJgnOz5eWPADx7/OYXL46Wz1SjfUaLyd1jSeXbelRnEH0aiVAUjaT Tp9YnHb0uoIp7JW2EwvzuAAKxg9VcLzqGb6m05BwjAipHAcgN4VCsK+H5yEMmCa12zuO KDkg== X-Gm-Message-State: AOAM532V7Y3hBzaRAsFEmkl6fNN8Jc/UOZv9HrTY/yFzihtIPmcbfkA7 /qojXttjTXUpTP7q1/VSNP6jK2tEEjQsCA== X-Google-Smtp-Source: ABdhPJxLyvU9DWTwyIUZ6xPJsGuV1TUlywPWrjkyu9PnXupvgANmkufBGh0MKcAKlq1qWaNQ0om3RQ== X-Received: by 2002:a05:600c:a08:b0:392:a561:9542 with SMTP id z8-20020a05600c0a0800b00392a5619542mr18105816wmp.62.1652730269966; Mon, 16 May 2022 12:44:29 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id i13-20020adfb64d000000b0020ce1c1cf31sm10166546wre.21.2022.05.16.12.44.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 12:44:29 -0700 (PDT) Message-ID: <3e009edb-727e-3160-2d67-500a263ece55@gmail.com> Date: Mon, 16 May 2022 21:44:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Changes to stat ABI Content-Language: en-US To: FreeBSD Hackers References: From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L28pQ6pxXz4typ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BHZnEWk3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32d as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/15/22 17:31, Warner Losh wrote: > Scratch that, this is a clang 11 vs clang13 issue. > > Most likely clang 13 is more aggressively optimizing, so fstat is not > actually on the stack... Because > of LTO, you'll need to check the disassembled binary to know for sure. > It makes no difference which compiler I use, same results either way. The disassembler is slightly different clang 11 / FreeBSD 13   201ba1:       8b bd b4 f6 ff ff       mov    -0x94c(%rbp),%edi   201ba7:       48 8d b5 d0 f6 ff ff    lea    -0x930(%rbp),%rsi   201bae:       89 85 a4 f6 ff ff       mov    %eax,-0x95c(%rbp)   201bb4:       e8 f7 00 00 00          call   201cb0 clang 13 / FreeBSD 13.1   201b8d:       8b bd b4 f6 ff ff       mov    -0x94c(%rbp),%edi   201b93:       48 8d b5 d0 f6 ff ff    lea    -0x930(%rbp),%rsi clang 13 hasn't bothered emitting the mov %eax, which is passing an uninitialized local to deliberately generate a memcheck error. Looking at libc, I see for FreeBSD 13   1372c4:       e8 87 89 f5 ff          call   8fc50 <__getosreldate>   1372c9:       3d 9f 4f 12 00          cmp    $0x124f9f,%eax   1372ce:       7c 10                   jl     1372e0 <_fstatfs+0x40> HERE1   1372d0:       44 89 f7                mov    %r14d,%edi   1372d3:       48 89 de                mov    %rbx,%rsi   1372d6:       e8 85 d1 09 00          call   1d4460 <__sys_fstatfs@plt>   1372db:       e9 22 01 00 00          jmp    137402 <_fstatfs+0x162> TO EXIT SEQUENCE HERE1:   1372e0:       48 8d 95 08 fe ff ff    lea    -0x1f8(%rbp),%rdx   1372e7:       bf 8d 01 00 00          mov    $0x18d,%edi   1372ec:       44 89 f6                mov    %r14d,%esi   1372ef:       31 c0                   xor    %eax,%eax   1372f1:       e8 8a c5 09 00          call   1d3880   1372f6:       85 c0                   test   %eax,%eax   1372f8:       0f 85 04 01 00 00       jne    137402 <_fstatfs+0x162> and 13.1 2b4:       e8 a7 c1 f5 ff          call   90460 <__getosreldate>   1342b9:       3d 9f 4f 12 00          cmp    $0x124f9f,%eax   1342be:       7c 25                   jl     1342e5 <_fstatfs+0x55> HERE1   1342c0:       49 8b 07                mov    (%r15),%rax   1342c3:       48 3b 45 e0             cmp    -0x20(%rbp),%rax   1342c7:       0f 85 51 01 00 00       jne    13441e <_fstatfs+0x18e>   1342cd:       44 89 f7                mov    %r14d,%edi   1342d0:       48 89 de                mov    %rbx,%rsi   1342d3:       48 81 c4 e8 01 00 00    add    $0x1e8,%rsp   1342da:       5b                      pop    %rbx   1342db:       41 5e                   pop    %r14   1342dd:       41 5f                   pop    %r15   1342df:       5d                      pop    %rbp BINGO! TAIL CALL OPTIMIZATION   1342e0:       e9 bb a0 09 00          jmp    1ce3a0 <__sys_fstatfs@plt> HERE1   1342e5:       48 8d 95 08 fe ff ff    lea    -0x1f8(%rbp),%rdx   1342ec:       bf 8d 01 00 00          mov    $0x18d,%edi   1342f1:       44 89 f6                mov    %r14d,%esi   1342f4:       31 c0                   xor    %eax,%eax   1342f6:       e8 d5 94 09 00          call   1cd7d0   1342fb:       85 c0                   test   %eax,%eax   1342fd:       0f 85 04 01 00 00       jne    134407 <_fstatfs+0x177> I don't think that there is much that I can do about that in Valgrind. The stat family callstacks will be a little less clear, but still usable. And equally I don't suppose there's any chance that libc will get changed just for Valgrind. A+ Paul From nobody Tue May 17 13:56:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CF60A1ADB772 for ; Tue, 17 May 2022 13:56:18 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "post.wayne47.com", Issuer "post.wayne47.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2d2B0YHZz4XlC for ; Tue, 17 May 2022 13:56:18 +0000 (UTC) (envelope-from wayne@post.wayne47.com) Received: from post.wayne47.com (post.wayne47.com [198.11.56.11]) by post.wayne47.com (8.15.2/8.15.2) with ESMTPS id 24HDuGq9062091 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 May 2022 09:56:17 -0400 (EDT) (envelope-from wayne@post.wayne47.com) Received: (from wayne@localhost) by post.wayne47.com (8.15.2/8.15.2/Submit) id 24HDuG2b062090; Tue, 17 May 2022 09:56:16 -0400 (EDT) (envelope-from wayne) Date: Tue, 17 May 2022 09:56:16 -0400 From: Michael Wayne To: FreeBSD Hackers Cc: Mark Millard Subject: Re: Can not build kernel on 1GB VM Message-ID: <20220517135616.GA72471@post.wayne47.com> Mail-Followup-To: FreeBSD Hackers , Mark Millard References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 4L2d2B0YHZz4XlC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of wayne@post.wayne47.com designates 198.11.56.11 as permitted sender) smtp.mailfrom=wayne@post.wayne47.com X-Spamd-Result: default: False [0.11 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[yahoo.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:198.11.56.11]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[wayne47.com]; NEURAL_SPAM_MEDIUM(0.71)[0.708]; NEURAL_SPAM_SHORT(0.30)[0.303]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FORGED_SENDER(0.30)[freebsd07@wayne47.com,wayne@post.wayne47.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2015, ipnet:198.11.56.0/24, country:US]; FROM_NEQ_ENVFROM(0.00)[freebsd07@wayne47.com,wayne@post.wayne47.com]; RCVD_TLS_ALL(0.00)[]; ONCE_RECEIVED(0.10)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 16, 2022 at 12:07:18PM -0700, Mark Millard wrote: > On 2022-May-16, at 07:37, Michael Wayne wrote: > > > More info. I am running UFS so the ZFS should not be an issue > > > > % pstat -s > > Device 1K-blocks Used Avail Capacity > > /dev/md99 1048576 0 1048576 0% > > That may well explain some (or all?) of what is going on: > file-system/vnode backed swap spaces are subject to deadlocks. > Which suggested patch(s)? Any patches for . . . This one line change (patch reduced to only relevant info) that was posted earlier on the list. --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) - if (target == 0 && ndirty * isqrt(howmany(nfreed + 1, + if (target == 0 && ndirty * isqrt(howmany(nfreed, > Can you switch to using a swap partition instead of > file-system/vnode backed swap space? AFAICT, this would require a reinstall as there's no easy way to shrink the existing image. Summary of events to date: - This was installed as a lightweight machine. It will never hit swap in "normal" operation. - The only reason I added a swap file was that someplace in 11.x building the kernel ran out of memory. - I only build a custom kernel to get options TCP_SIGNATURE for bird. - The swap file worked correctly for all of 11.x until I tried to build 12.x. - There likely out to be a FAQ or handbook page about how to lay out lightweight machines. Having used it since 4.x, 1 GB "seems" like a pretty big machine, yet these issues arose. From nobody Tue May 17 15:27:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BEAE71AEDB53 for ; Tue, 17 May 2022 15:27:34 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2g3T6bfjz4qMh for ; Tue, 17 May 2022 15:27:33 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 24HFRJG1088777 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 17 May 2022 11:27:26 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Tue, 17 May 2022 11:27:18 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Shy scroll bars Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4L2g3T6bfjz4qMh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-1.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.859]; NEURAL_SPAM_LONG(0.57)[0.570]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Among the "features" that have appeared in Firefox 100 is my least favorite from Linux's so-called Unity interface: in the name of maximizing non-wasted screen space, scroll bars shrink to maybe two or three pixels in width whenever the cursor is not in their vicinity. Sure, this does give a tiny bit more space to other uses, but it means you can't see at a glance where you have scrolled to in a large image or document. (At least, it's hard for my aged eyes.) Is there some way to persuade Firefox not to do this? Thanks for your attention. -- George From nobody Tue May 17 16:10:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F6D91B352CC for ; Tue, 17 May 2022 16:11:05 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2h1h0yBmz3Bvy for ; Tue, 17 May 2022 16:11:04 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4L2h1X6ZzXz6drK; Tue, 17 May 2022 18:10:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1652803855; x= 1654618256; bh=ts7dphyUVFdfd8Py/EXXAqFCNE77kiNt4CmLo/BSgPo=; b=y VX7H0PiO//ze1J79JRC1NW378u4WMaD/HmlOZ5L+dRAmnAEchLCbSTo/M2uEvCKv lYXCP5TRPN07yT5m0lG7p5axHFSSiyMmtHEqiB11RVFffdWt4V0HfnMjf1ia9jG8 +0av/pmqsny+Jf1teKruSkt7wsVbgWVSIyABjkQ/mQu8onKS3fa06pFSZFikXBhM QEiwHWn6CMkvcf0ShEJrv0m8Zpb/U2FjppWUbRw8oSlUYwujOyI4Z3/+8ny4doy1 gu0+e619L7G1nrxIPUKSgv7Dz6FCVpYC/+H1/UJkMvFXw9Qh5tiCpOUAj+0jLZ07 MfwKVvqYb8DVwbKXLjUvg== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id IouFCtVVAgKr; Tue, 17 May 2022 18:10:55 +0200 (CEST) Message-ID: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> Date: Tue, 17 May 2022 18:10:54 +0200 Subject: Re: Shy scroll bars Content-Language: en-US To: George Mitchell , FreeBSD Hackers References: From: Guido Falsi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L2h1h0yBmz3Bvy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="y VX7H0P"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 17/05/22 17:27, George Mitchell wrote: > Among the "features" that have appeared in Firefox 100 is my least > favorite from Linux's so-called Unity interface: in the name of > maximizing non-wasted screen space, scroll bars shrink to maybe two > or three pixels in width whenever the cursor is not in their vicinity. > Sure, this does give a tiny bit more space to other uses, but it means > you can't see at a glance where you have scrolled to in a large image > or document.  (At least, it's hard for my aged eyes.)  Is there some > way to persuade Firefox not to do this?  Thanks for your attention. > -- George > Try switching "widget.gtk.overlay-scrollbars.enabled" to false in about:config. A quick test I made shows it should be what you're looking for. And does not even require a restart. -- Guido Falsi From nobody Tue May 17 16:14:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9A2AF1B371A8 for ; Tue, 17 May 2022 16:14:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2h5Y1k7pz3DHv for ; Tue, 17 May 2022 16:14:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 24HGEIwM068574; Tue, 17 May 2022 09:14:24 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 17 May 2022 09:14:17 -0700 From: Chris To: George Mitchell Cc: FreeBSD Hackers Subject: Re: Shy scroll bars In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_f5fff7808ea35dd2f530195fd5a7db00" X-Rspamd-Queue-Id: 4L2h5Y1k7pz3DHv X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_f5fff7808ea35dd2f530195fd5a7db00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-05-17 08:27, George Mitchell wrote: > Among the "features" that have appeared in Firefox 100 is my least > favorite from Linux's so-called Unity interface: in the name of > maximizing non-wasted screen space, scroll bars shrink to maybe two > or three pixels in width whenever the cursor is not in their vicinity. > Sure, this does give a tiny bit more space to other uses, but it means > you can't see at a glance where you have scrolled to in a large image > or document. (At least, it's hard for my aged eyes.) Is there some > way to persuade Firefox not to do this? Thanks for your attention. > -- George It's not just FF. The Gnome 3+ DE's do the same thing. Makes everything slower and harder to accomplish. I'm only answering here, as I looked (unsuccessfully) for a solution on the Gnome DE. --=_f5fff7808ea35dd2f530195fd5a7db00 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_f5fff7808ea35dd2f530195fd5a7db00-- From nobody Tue May 17 16:21:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F30301B395C3 for ; Tue, 17 May 2022 16:22:12 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2hGW4rzzz3Fyq for ; Tue, 17 May 2022 16:22:11 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-il1-x12e.google.com with SMTP id s12so10337121iln.11 for ; Tue, 17 May 2022 09:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hJt02XTQPweks5zyssyFQGU6pst38EDYnc3EfU2laVU=; b=XO4StrjlyQEDET4D0z9UlTQ0JVEsPa0Af5fKyG0mr2dJFzKozi/rNJrcoHKIBFrUKV PnC5g/yx7MxSg844ZLsZcwCO8LWoNREC+MnxKnOYZfTBuproJfMyRcFUR/kv24+C9TTO 4leJWKVY9DuyK/BGAsm5F3Yzoc4fygrShzNriGou43TjwEHogNAul5udNiPJ16rRMDNL 499krGXdz3mz8Zs1VfADKyz0JM4Hh5TonSGbQ9rxGWI5s1+u8JxFQNX+TWFG99xo5o7k TUrfhI9LgQF/eW5bRnq6cc3gc4sqpN+K4Bvd878DGhtuOTXvVxhmVmeDexCrKG2UfnnV UOBQ== 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=hJt02XTQPweks5zyssyFQGU6pst38EDYnc3EfU2laVU=; b=GiWDztuXHViKQ98qqyEkHPy7nFyWcbkKyKz/kpw3+/7UWj9pzQxIjYFdkegPqKRgtV +QRAP9pOOdb+bwrfNprJcbIpl15tdgpz1hO/MVUGD3GlTteNymc1K6llgkHzafWTy1fI ibMJ+PTLgauxu/YAAPhjqFJTehBwh6dNg07ufq1iQ7/m3dJoK+qwgjRq0Ecl4Iz7fmG8 MpanJJdTe5DVEln49MedMeAAezJTpaPNYZPucT7AdCeC4R11UjAEL2xQNCRvPFp1lm/W jX8HDCHxdSLukBvRPI/VZoTF+DiRkg4y6qDLI2SfrZQfjWlrhaQQaIunBaa2n34L+qiL T6aw== X-Gm-Message-State: AOAM531AjvMD2ZukU5AIFE/NF1L201IYFPqm7jvb1wHWTAU6O7ryt4OV bc72c+y0+lE7oCKYnI1JdYbB4/DIUOhhdFhj0aQHfbogCKcr7w== X-Google-Smtp-Source: ABdhPJy7LKzDKTQ7kBhtqN09rctii+kyKBzfy9I/7u7rGdOOQBb2jzr7wHszKEYdQNYVxMt9mbl8+SXJhk/HDQjJP4s= X-Received: by 2002:a92:ca07:0:b0:2cf:95c4:9e9d with SMTP id j7-20020a92ca07000000b002cf95c49e9dmr12310699ils.99.1652804524976; Tue, 17 May 2022 09:22:04 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Tue, 17 May 2022 18:21:52 +0200 Message-ID: Subject: Re: Shy scroll bars To: Chris Cc: George Mitchell , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000982f8a05df378a2a" X-Rspamd-Queue-Id: 4L2hGW4rzzz3Fyq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=XO4Strjl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::12e as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-1.55 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.55)[-0.552]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12e:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000982f8a05df378a2a Content-Type: text/plain; charset="UTF-8" On Tue, May 17, 2022, 18:15 Chris wrote: > On 2022-05-17 08:27, George Mitchell wrote: > > Among the "features" that have appeared in Firefox 100 is my least > > favorite from Linux's so-called Unity interface: in the name of > > maximizing non-wasted screen space, scroll bars shrink to maybe two > > or three pixels in width whenever the cursor is not in their vicinity. > > Sure, this does give a tiny bit more space to other uses, but it means > > you can't see at a glance where you have scrolled to in a large image > > or document. (At least, it's hard for my aged eyes.) Is there some > > way to persuade Firefox not to do this? Thanks for your attention. > > -- George > It's not just FF. The Gnome 3+ DE's do the same thing. Makes everything > slower and harder to accomplish. I'm only answering here, as I looked > (unsuccessfully) for a solution on the Gnome DE. I'm repeating what I sent OP in private: look for a way to disable client side decorations - what you're reporting sounds a lot like that... idea. HTH, let us know how you fare. Michael --000000000000982f8a05df378a2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, = May 17, 2022, 18:15 Chris <bsd= -lists@bsdforge.com> wrote:
= On 2022-05-17 08:27, George Mitchell wrote:
> Among the "features" that have appeared in Firefox 100 is my= least
> favorite from Linux's so-called Unity interface: in the name of > maximizing non-wasted screen space, scroll bars shrink to maybe two > or three pixels in width whenever the cursor is not in their vicinity.=
> Sure, this does give a tiny bit more space to other uses, but it means=
> you can't see at a glance where you have scrolled to in a large im= age
> or document.=C2=A0 (At least, it's hard for my aged eyes.)=C2=A0 I= s there some
> way to persuade Firefox not to do this?=C2=A0 Thanks for your attentio= n.
> -- George
It's not just FF. The Gnome 3+ DE's do the same thing. Makes everyt= hing
slower and harder to accomplish. I'm only answering here, as I looked (unsuccessfully) for a solution on the Gnome DE.

I'm repeating what I sent O= P in private: look for a way to disable client side decorations - what you&= #39;re reporting sounds a lot like that... idea.=C2=A0

HTH, let us know how you fare.=C2=A0
Michael=C2=A0

--000000000000982f8a05df378a2a-- From nobody Tue May 17 17:59:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6317C1AE3F74 for ; Tue, 17 May 2022 17:59:19 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2kQZ6JKFz3kTy for ; Tue, 17 May 2022 17:59:18 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 24HHxAf7089355 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 17 May 2022 13:59:17 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Tue, 17 May 2022 13:59:10 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Shy scroll bars Content-Language: en-US To: freebsd-hackers@freebsd.org References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> From: George Mitchell In-Reply-To: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4L2kQZ6JKFz3kTy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.19 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N T24gNS8xNy8yMiAxMjoxMCwgR3VpZG8gRmFsc2kgd3JvdGU6DQo+IE9uIDE3LzA1LzIyIDE3 OjI3LCBHZW9yZ2UgTWl0Y2hlbGwgd3JvdGU6DQo+PiBBbW9uZyB0aGUgImZlYXR1cmVzIiB0 aGF0IGhhdmUgYXBwZWFyZWQgaW4gRmlyZWZveCAxMDAgaXMgbXkgbGVhc3QNCj4+IGZhdm9y aXRlIGZyb20gTGludXgncyBzby1jYWxsZWQgVW5pdHkgaW50ZXJmYWNlOiBpbiB0aGUgbmFt ZSBvZg0KPj4gbWF4aW1pemluZyBub24td2FzdGVkIHNjcmVlbiBzcGFjZSwgc2Nyb2xsIGJh cnMgc2hyaW5rIHRvIG1heWJlIHR3bw0KPj4gb3IgdGhyZWUgcGl4ZWxzIGluIHdpZHRoIHdo ZW5ldmVyIHRoZSBjdXJzb3IgaXMgbm90IGluIHRoZWlyIHZpY2luaXR5Lg0KPj4gU3VyZSwg dGhpcyBkb2VzIGdpdmUgYSB0aW55IGJpdCBtb3JlIHNwYWNlIHRvIG90aGVyIHVzZXMsIGJ1 dCBpdCBtZWFucw0KPj4geW91IGNhbid0IHNlZSBhdCBhIGdsYW5jZSB3aGVyZSB5b3UgaGF2 ZSBzY3JvbGxlZCB0byBpbiBhIGxhcmdlIGltYWdlDQo+PiBvciBkb2N1bWVudC7CoCAoQXQg bGVhc3QsIGl0J3MgaGFyZCBmb3IgbXkgYWdlZCBleWVzLinCoCBJcyB0aGVyZSBzb21lDQo+ PiB3YXkgdG8gcGVyc3VhZGUgRmlyZWZveCBub3QgdG8gZG8gdGhpcz/CoCBUaGFua3MgZm9y IHlvdXIgYXR0ZW50aW9uLg0KPj4gLS0gR2VvcmdlDQo+Pg0KPiANCj4gVHJ5IHN3aXRjaGlu ZyAid2lkZ2V0Lmd0ay5vdmVybGF5LXNjcm9sbGJhcnMuZW5hYmxlZCIgdG8gZmFsc2UgaW4g DQo+IGFib3V0OmNvbmZpZy4NCj4gDQo+IEEgcXVpY2sgdGVzdCBJIG1hZGUgc2hvd3MgaXQg c2hvdWxkIGJlIHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yLiBBbmQgZG9lcyANCj4gbm90IGV2 ZW4gcmVxdWlyZSBhIHJlc3RhcnQuDQoNCkluZGVlZCEgIFRoaXMgZml4ZXMgdGhlIHByb2Js ZW0uDQoNCk9uIDUvMTcvMjIgMTI6MjEsIE1pY2hhZWwgU2NodXN0ZXIgd3JvdGU6DQogPiBJ J20gcmVwZWF0aW5nIHdoYXQgSSBzZW50IE9QIGluIHByaXZhdGU6IGxvb2sgZm9yIGEgd2F5 IHRvIGRpc2FibGUNCiA+IGNsaWVudCBzaWRlIGRlY29yYXRpb25zIC0gd2hhdCB5b3UncmUg cmVwb3J0aW5nIHNvdW5kcyBhIGxvdCBsaWtlDQogPiB0aGF0Li4uIGlkZWEuDQoNCkkgY291 bGRuJ3QgZmlndXJlIG91dCBob3cgdG8gZG8gdGhpcywgYnV0IEd1aWRvIEZhbHNpJ3Mgc3Vn Z2VzdGlvbg0Kd29ya2VkIHBlcmZlY3RseSwgc28gSSdtIGhhcHB5LiAgVGhhbmtzIHRvIGFs bCBmb3IgbGlzdGVuaW5nIQ0KLS0gR2VvcmdlDQo= From nobody Tue May 17 19:40:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4BD221AD8A95 for ; Tue, 17 May 2022 19:40:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2mgd2BFbz4Smt for ; Tue, 17 May 2022 19:40:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652816437; bh=4jNYqonb0Vc1JpEnXtfOuC2lQSyk5zsKNQmZcTOO/M4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=NPP5sYXTNJLU2VSHfzBKALy6femzj6vaLfHW7WcguzX5ElyjSb2ivVy32wsKQG9bgNKpITN/MWlyBxXBhvGLztBazYiUeE+1edaRQbfbdlPTZubZZRPvkguMB50/hHDOZtL7YLoVVEmQNPocMH+DviVnEBJR44iCktI52YJ4WviiXtHittMBSO7G0aRh077v/RAj8eFknJbxCTItXGAQRLBNGk2zp2+L9ly1IZwgzTYjDJEwacrT7S9vNPFjh3vRIc273JumQINYe9SjZwhjJ9rnZn3MfkM7o9YKaWSAYmcUoL0YEueRjW5/EQU24esPbdKCJGuX4Sao5mhMjtrDbQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652816437; bh=T9kect9lEfRqKHzoEp5FRUd43WmqmDITYpvX6bPsZQZ=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pmNBntomv1L6ngu1B1Vgb9D7y5s2yuC52zrMLe27skqC7s8oowMG/1ksOaNuvKf1J/NekR75AoNwozgavt+NAiM1q0IrO4Y63eC4FkukCrBqZs9/2pxCKoPglk2hPdQpdiOpBLywz0WVwHuY0ibhONLCsyDD4C27M6FiflY6xM9QclDadXH+/URVrk5R85GlTATjekIm+7tq0L/iZatWcROGd9T5nqmwiAjP9+LYh2tmUmXKID90rEHKmo6UigSeZPzkwHHJi0sin7hA76QyywLkGMaX5EdpE3mSLRAbmlGCAvu/qGlpdHVnGdnXSxu12FqlYdXWVNtp+GAOgmqTYA== X-YMail-OSG: Yn5Zev4VM1nt9xNKbWozbDZkT0S_t_9tZR0WP6261EgsHv.NI1QSMZPnraF510O AGnTBI2BnufWszpFWVKYKLZ.PcSDCidIL21zMqQoEBJaXEqf1JMyUMmSpcBLuudUeT3jI1ZW5WTm NMcYsQZRjsFdsFRZs2cWQUsumHedfjde5bMNxYrYpaF5ixL.O0oxBgNFnbZ3UBt6gkVCNO_rJ.mm IiSyaC7WhmYxSA706RVQYpraMcTH5Dwb3Uk4GWHhObN55ycUkH0_vHKRHaaEMdmPt57JfLrnwiq8 SocVk32PErsaozyfkRZNPqp86SLwSeE_zRCOgBsttk5XgI.8vpBVE8mPMyMdSRhjfWPQQ5RYmJvv x_5zwI4nORZEV1VzWgt42EJSEl3i5tbrXeZsRMDJFVdUMwzSjpA8NTEkaHvYB6J30ba9ebiA3Vcy NuJYUtSL3WyMbYQrb9W6EB7qk2ThMN3ybJoRIAdxYEJ.eZqLZWYPxg24krEIpa1C3JCiQXIN0LV8 .gnTJjsxH4S2q.0SQUdlIc_Z9vnwssAVMbS0vbbpU_U3Xg81m4EOSMwhlsVWwZhyJ4m1ZoHWz3Fg 5sH0CqwFM5bCSjYdMjGJgK36rJcwObkLO0U2P8yebNelAVDvHN75NvQCbpD.V14NHvH4QLDpDquQ jnglNPvl.yhYBlGm2078Dmn1rNJ70MzMkfuO1PfaOKZS9BmGpdeXJKNd49Qz__k1ugKTvS7Fd_j_ l2Nv3tbI6orPCpbPESrH529b9Chn3YkeMHEOQEkqdtzja1059cotERuaZ.l1IuMfXJT7o71AaylM srqu8IEGtrA52nA9MLnAXUWHej21NhVFetzPiFBrRAqzhfgfW9Ek4KHOgXrUI7Q7Shz1x6zp.Eh3 LhoppeNfdKxeeskAgrSJlZ_EnfhqefysL0.TT.4UrQvIwBvX4KOo7ZdK9goh8lpnXI6PE1wNZ0yA AC4l_47BmNjk1Hl6yuVLO.ZcCPNiaUybyE9cLatNZH8O7YR7Pltl_FoprMq5P7jFUcqDWcJvmIeJ nRD3KKW2xCEqm3hA6iTVmotyktZ7s2CRaCKrE8n.kjbz62oSWbfH6Ni5v8FUjrriFLyQnZCtRWNx Yq20jFdqveFYY3BCe.d2nKz_IObSVUMszYgrmcL2tJZrKR7uLmwIzprhE4M8TjM6HVgLbVmNw2_i T1aMuxG72LushEQ.xfEqqhlAax5V.8BlZEiGufSeGP8KlVeF2wAEbLQRHPzyD2zu80_kZn5cJ8SD B_z8pub0g2b3a_bg6_KrIFbfcs4XJe6zZDIrMhfjoch9Q5wyWZrARlUTXg0pP.KdiECR0EizIQ9J GULz_HBlkNosfLom_Mb1Qu6aFqncBclXCDYyt04H7MGs_wXaXEPc.kG2vcaoY1g4kSsY8J9bY1Cs G4HJP1SjWSjSqQEljr.ctsyqx_btaamhRFzzc_laKjhl4EVq7t8vrpigYbGqoqvz.ABVm3IDaGwX q65UloAJpuSYG1ulSQzrBDBkhJ9RyQR2PWmBOYP_S4wJ7jwqYZqSZSUbF_kwpfp1bAP0UuKfh_mG ipY0TFuvcEJotwNESg9hpUsDgCDUZNNY1IOEyF9_P8p8rDDk5xynkyyClBoSy6UFyuAyxF23e2k5 ZWpbAX9vofjSFBjPrfgA.0f.G49lfctfxJidfFVhehS5.IpSa.cLLLsy1CAoS3RRxCqoaU6VBds5 y2KwHpY.yNLWAdsNdDCX.QXDJr2d2ppsfQpdfv_fS9NkkrbG9GlosDcsiIrstqXutcM5gJ60zKMo hus7KLpbKWto07QIZRQN3a6Iz8EpVvvBeDCaVmyP_JNiNhVRxGE_415jd.E8HFvtwTWrMDvKqAbd XZkS55vjJ4wxGQbF7EOPeb1JAsRsiolYobJht7tpBX2.qOnzeH_Zdg2VPKYTHqymq2dyCzK.3AfU 45Wp31QlY1DPsNKYXErKma0u4WzK1uUrpF2megvSz7ZdvAaKgWmJA9Vg24kZxXWe8RGVZiBXiLp1 ZOZLVPy7CPOizSOnwq1VBxEhl1K9m49l4tqqXQaiS2c6V5eMJ7bMo3dxIZBV0H.X1CoPdFY4lsxv 3QCKxkWwRfrs1l3Xu8CiCiSBXFmFUMFWYqsnQ7iwD96o18LToMrDqe57fPfA0DUU66Xq6L3.Ee4N M956UmAbRdifRokUYStryHuKXTyaR3nLj61nUUNoEvBCbz3_foRd_M.1MyYgDAxR2EcCWuyjlIMd 1.PbOSGqw8QM_ZJnn6niax9dhbCY2Glv6.Ax6EGcPLU4GMwZ88FmyhVHF4CX2Pa7veHDCXPnhLXe .i8oxD5G1Fg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Tue, 17 May 2022 19:40:37 +0000 Received: by hermes--canary-production-gq1-555f44848f-4dqql (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 184b8f71ff04371989f8cfbc67d84514; Tue, 17 May 2022 19:40:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM From: Mark Millard In-Reply-To: <20220517135616.GA72471@post.wayne47.com> Date: Tue, 17 May 2022 12:40:32 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com> References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> <20220517135616.GA72471@post.wayne47.com> To: Michael Wayne X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4L2mgd2BFbz4Smt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NPP5sYXT; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-17, at 06:56, Michael Wayne wrote: > On Mon, May 16, 2022 at 12:07:18PM -0700, Mark Millard wrote: >> On 2022-May-16, at 07:37, Michael Wayne = wrote: >>=20 >>> More info. I am running UFS so the ZFS should not be an issue >>>=20 >>> % pstat -s >>> Device 1K-blocks Used Avail Capacity >>> /dev/md99 1048576 0 1048576 0% >>=20 >> That may well explain some (or all?) of what is going on: >> file-system/vnode backed swap spaces are subject to deadlocks. >=20 >=20 >> Which suggested patch(s)? Any patches for . . . >=20 > This one line change (patch reduced to only relevant info) that > was posted earlier on the list. > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) > - if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed = + 1, > + if (target =3D=3D 0 && ndirty * = isqrt(howmany(nfreed, Why my brain was stuck on "patches for messaging better" I do not know. Seems obvious now that you show it. Sorry for the noise. >> Can you switch to using a swap partition instead of >> file-system/vnode backed swap space? >=20 > AFAICT, this would require a reinstall as there's no easy way to=20 > shrink the existing image.=20 You may ultimately have a requirement that the image containing the UFS file system and swap space be no more than some specific size), implying that the UFS file system would need to shrink to make room. But, for testing, could a copy of the image file for the VM be made and then be grown larger and then a freebsd-swap partition added in it for use as a swap space? Then: switch to using the partition to see what happens? At least we might learn if the issue by itself is sufficient to avoid the problem you are having. 18.3 "Resizing and Growing Disks" in: https://docs.freebsd.org/en/books/handbook/disks/ has notes some notes about doing such growing and mentions virtual machines --but uses an ada0 example. It includes adding a swap partition. It may be best for such a test to have a larger than intended swap space as an initial test and then, if things work, to change the swap partition to be smaller and see if it still works, possibly bisecting to find what an approximate minimum size is and then judging what to use from that. (Either way, relative to avoid the existing problem that you are having, based on my experiences, I would never recommend file-system/vnode based swap spaces be used.) > Summary of events to date: > - This was installed as a lightweight machine. It will never hit swap = in > "normal" operation. The toolchain's memory use has been growing as the versions progress. Fixed RAM+SWAP sizes over long periods of time are not realistic as stands --unless room was provided for growth up front. Because of kernel data structure tradeoffs, SWAP sizing is effectively constrained by RAM size. For 64-bit contexts, something like 3.8*RAM avoids notices of mistuning when the swap is added. (An unfortunate property of the mistuning-message is it makes a suggestion that involves other tradeoffs for other kernel resources as I understand --without giving any hint that such a tradeoff is involved.) > - The only reason I added a swap file was that someplace in 11.x = building > the kernel ran out of memory. Toolchain again, yep. > - I only build a custom kernel to get options TCP_SIGNATURE for bird. Any chance that you could build the kernel outside the specific VM (in a less constrained context) and somehow transfer it into the VM? > - The swap file worked correctly for all of 11.x until I tried to = build 12.x. file-system/vnode backed swap spaces do not fail on every use but are unreliable. Back when I was isolating the failures that I was seeing, I found notes from a wide range of time frames from folks having problems, as I remember. (Not that I could point you at them any more.) The problem did not seem to be new, predating 11 for sure. The toolchain memory usage growth over time has probably lead to reaching failure for file-system backed swap spaces ever more often over time for ever less constrained contexts. > - There likely out to be a FAQ or handbook page about how to lay > out lightweight machines. Having used it since 4.x, 1 GB "seems" like > a pretty big machine, yet these issues arose. If partition based swap spaces prove insufficient, it may require adding messaging to the kernel that reports on just which of the 4 conditions is leading to the kills --and possibly related information for the one that is happening. That context might be required to make progress. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 17 21:10:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DBB181AE9BD8 for ; Tue, 17 May 2022 21:10:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2pg25X44z4d7c for ; Tue, 17 May 2022 21:10:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652821815; bh=HyTxK26SL1H2o/R1INvY62GqxgMzyxnaPrUd+YV54XQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=IwDJir2mVs4zyGDTVGPl/oCWJlIlr0WDPBMkFwBosnS/THSY+zHLYXpA5kk5kYwCGMTlx5BJcM5eIS847tVsqStJVzhlr8Q/+7hEPFCOoL1gwwnydHsYlVku5vzlYuS9Q54akNbS/+w4N8F2/3hT71lZbXpJVkIWTftYm+/rZF7UsRk+p5dCvlijMduPeaZDCPlARjdcfAvbwZ8lCrN6MHE7PbV8xwanjfR0nHDQGqxWlO7HKnie6Q2Vi+XnVOCk+VRIjGeojjjPROdTqtFVxM3TZVUkULja/WOVsTYnjgEWDkbglShqm76wIqPWkUXxd8dmCVzRoHZ7zRWUR7aOjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1652821815; bh=YNtPYl4ehTvczz12FCRN+y6X6pyTgssGrUb4IW6a+gi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZKax2KUc7W+RYoGnK5PUsxYgx5/4imcq0erc0wiflzRWSyMqJTO+xyx8/c97FCZl26oW9d0+sGkZIF2NvssNlhthcJyRSw77Dsdlh0vpX1UnNfT+y14hORGCzzdIsd6ecgp5nqIqynr9PleQm4R2oq3DhXPmrxzDDoiMuZnSGM5E06+XpruQiSXtqBNgDw4+ki7lRV06IkLU8Xvr1drR2zYx82ybU0YFnQ3BvbivofR2cPgtS9Q+2KSqT4gmtxT1NzpT+HBOFpxU3qUMDBnwi+y7qJ4eTNJKLlXmxfgW+pw4sckxdI6r9lZHjc7BcdgOaSysuuRqMF01xW9sJnPqDw== X-YMail-OSG: gXGrx7cVM1m5ADX6.ldBjjTeIKaf9IUDtwUZhXu.MQX5O4HS7FKDwjF8Nr_YEeE jvAP4qEfHoVBH3nFqEKqY3O5mhkHORPdfcrqnfOuV_.IZehS2DK7ls7gQ7lFSqYGvd7BswmXAWqz 8huCzaVbjWGcAGW2qmuz0lmFOQCYXvnV2UkQrMLyiALE46OX22EUjpkMVa3ZyR.GTDS86yIKC_DV ZgkEFeluIbbDfndEGMzZlNzy1yVW2SI5RolsfBymK87SSybdypVkREWcfWmzYvxNpKmgH6IjQG7U rDd3EH6oY4RBbEpfsmBqVO7xp_af1HE7767JLg3YqquojI9WP3q9iz1JL.PY8zAsb71aH_I9icqH dH.VnTzZtPn_sd8tzZTuPCMb17Tn0uxPMfwTrrkU9sSpv9hwS1zh6AgYdfU7E5manY2zTfpJF8IC fviGr_yBQspbCZ5u1nySn19aO2StwzRtDfFJ_BJoTqCAXrLYRhc0CFAV_vBjkGWpsaauwXRej3KC 2HBseW8B6FyYJReuaL1KgrqhAH7K2GuBYwpjKpROPCf.pN..195wAPWgsseDlJeL3tBlIRPncqIc .3OKi8KvIW5iDIbNZ00aV7csUXDicAmzbmN63wu0oCgr016zEm4L5v4hrLo4bknsivLzaZD6_EY1 z97ZnLddpHtu1c0u4MxrAsrWnQeIymCSUF_Q1mXkkXcfausvUJaBNGKCHDabj4HlHP3fyNvG5GaY BSGVVas8QjA7s5IDkXfJa3M.4bpeXdEWjh1om1zRMdcJwzGeRuEs_uVWqRpZ3TXt_bsbebjYoHun tyg1a7yq9uYq0oq.jQnHZUt51C6B403.pivUFXPahhxIviVv6mK7IbFkW8UlRIq_Wf0B6WkvNRsV mUmi.itH_vy_FV0SeBx2a.x_u_Sa0fsgNiUcxmEJNXe90RItQxgbN9IKOlZn_G8fb9L6k_EgM22W oNUPa6_Vn1aSQGuanrIpL.QLec5krHUSY5EDNFlwlYj8Ycf_FHb8hfFo90J_mvVOiZJNA.Qi6eie ULP94Y4PwHk4hGK9fcMo6SUT783iYpRgboPtxT0XVL7SCetwfgULaiOxMeL90BD0PSpIYOwOXFc2 clB6NVwxmPT.qXFIUYnykxSntClXYR.jE3c1gyB0fvqf2k4MC1bMQKEggwFT6ZH_Dlw2oedZVqze udkuHSDMHcSyLHxqKBnObGROTPbHs2uwevCTB2aJqU3giguGgtg91w.lKAw_mBBRmDdW5n4hcoQG 7Wq4eJSdtPT_3oXJGk9YRqG5Q2schHnwX.ge6PKasaZyIz5_fHl6yikgcrEL9nRczfJtmUTdZCHL ytm5oE6Qx.1sX97.zAw5lpeJvDb9nM9te2sGYuOrB87VyIiMLmngpTipVaCJ3FoHl2m7OSaxfIr4 sF2oFMXV89EoWcqvU9ebHqCfOG.9.NteKHOvmwZlPAb195dWtcwbUWAxy78N.Qtakhi7bW3dAxuP CZv6NMeHRPamhIu_EfUwS6ZwoWQM8ujwTiip4OKP8e5WZHj.smDZAfy3N7dsJ5hNZ9V63BpB9kWW UrgVKsQuhsi8ad75t2i8kMihCMuEF23BLA9tIfbIAU0GtfeK_2uGc3v5sU61XiDsYuA.9utxWJtG EaDyOIXvSPK5BnXuXFSJMi5SMnJaY4efeLf._zXlftahc110R8ZLJx6NMy9v2sg8EGolcEssxEg2 KduUjiuIbkrNjx.bx1tkdeGHI2FOKy5nyri0Uz_zvSbDvdT9ov4gLCYEGf.bTbK0F4.uww6QUzmz N4DHal41x6d_0IYgLXH9dwPa4SoKi67JQBpAMQPeIkxRkVglO6A2S7UzaJ17yzxWH_s8GGEIPeIh aaJXGSZRXHJ3f8gN3oay.yPiv2Sqtwn8Tslw60lX4dsjoP3fFbBfFj6AiXVYc6PtBfzDmFXk1LpR mg6bpiIkcSGeMeraAKS9.xROmvSGKkGZo0WJhsLxAm4S7PMafcJPl2XqRnpVhdK3S2aeHAvPDjyE hzlUXy9RGYzA4u2eP0XLAzDPYRxC3N.scT6SOlD.k0_XtBs8MO1jXssIYiGQYZLRUM8T9ojv6d8M nLhvYvzOgYEUwvtuwI1Lb_o8ClNffV20GqVKT0sNHRllnyZWGoCUpmyvLV5Ikm6NAcD6638MelzJ 9zYireLHgLsvrl4vx.ePSJWFsPo51WkTZJR2Fwx0L7q3PnKy7.pm7XQd6xHoUitqmdDgbf7WeDxh 6Xe0RRQuf44sJlQ4aN.wjIIDCFgGlpa.MVtKhXyvKj.464QLiiSiAmd3bcRS5r9jUJb1z1HTrwAW tRsB07.VOaNN9uv0t_8vzFhCgzc.JWLhdgJnAi4EnmBNXsuZtMHn.YY3lXbgo X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 17 May 2022 21:10:15 +0000 Received: by hermes--canary-production-ne1-5bcb78874-tzl4b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2c16a81d28186a600bac54bf2c89f351; Tue, 17 May 2022 21:10:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Can not build kernel on 1GB VM From: Mark Millard In-Reply-To: <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com> Date: Tue, 17 May 2022 14:10:06 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <84F2341A-C7AF-41F3-8A69-70FB9D7271CF@yahoo.com> References: <27171A11-13B1-48A8-AF46-605091E1093F.ref@yahoo.com> <27171A11-13B1-48A8-AF46-605091E1093F@yahoo.com> <20220516143753.GY72471@post.wayne47.com> <934C3159-4B1A-4A2F-9C21-93DC7CC90A72@yahoo.com> <20220517135616.GA72471@post.wayne47.com> <2892AE2A-E453-460F-A243-0E98E5DF3C8C@yahoo.com> To: Michael Wayne X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4L2pg25X44z4d7c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=IwDJir2m; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-May-17, at 12:40, Mark Millard wrote: > On 2022-May-17, at 06:56, Michael Wayne wrote: >=20 >> On Mon, May 16, 2022 at 12:07:18PM -0700, Mark Millard wrote: >>> On 2022-May-16, at 07:37, Michael Wayne = wrote: >>>=20 >>>> More info. I am running UFS so the ZFS should not be an issue >>>>=20 >>>> % pstat -s >>>> Device 1K-blocks Used Avail Capacity >>>> /dev/md99 1048576 0 1048576 0% >>>=20 >>> That may well explain some (or all?) of what is going on: >>> file-system/vnode backed swap spaces are subject to deadlocks. >>=20 >>=20 >>> Which suggested patch(s)? Any patches for . . . >>=20 >> This one line change (patch reduced to only relevant info) that >> was posted earlier on the list. >> --- a/sys/vm/vm_pageout.c >> +++ b/sys/vm/vm_pageout.c >> @@ -1069,7 +1069,7 @@ vm_pageout_laundry_worker(void *arg) >> - if (target =3D=3D 0 && ndirty * isqrt(howmany(nfreed = + 1, >> + if (target =3D=3D 0 && ndirty * = isqrt(howmany(nfreed, >=20 > Why my brain was stuck on "patches for messaging better" > I do not know. Seems obvious now that you show it. > Sorry for the noise. >=20 >>> Can you switch to using a swap partition instead of >>> file-system/vnode backed swap space? >>=20 >> AFAICT, this would require a reinstall as there's no easy way to=20 >> shrink the existing image.=20 >=20 > You may ultimately have a requirement that the image > containing the UFS file system and swap space be no > more than some specific size), implying that the UFS > file system would need to shrink to make room. >=20 > But, for testing, could a copy of the image file for > the VM be made and then be grown larger and then a > freebsd-swap partition added in it for use as a swap > space? Then: switch to using the partition to see what > happens? At least we might learn if the issue by > itself is sufficient to avoid the problem you are > having. >=20 > 18.3 "Resizing and Growing Disks" in: >=20 > https://docs.freebsd.org/en/books/handbook/disks/ >=20 > has notes some notes about doing such growing and > mentions virtual machines --but uses an ada0 > example. It includes adding a swap partition. >=20 > It may be best for such a test to have a larger > than intended swap space as an initial test and > then, if things work, to change the swap partition > to be smaller and see if it still works, possibly > bisecting to find what an approximate minimum > size is and then judging what to use from that. >=20 > (Either way, relative to avoid the existing problem > that you are having, based on my experiences, I would > never recommend file-system/vnode based swap spaces > be used.) >=20 >> Summary of events to date: >> - This was installed as a lightweight machine. It will never hit swap = in >> "normal" operation. >=20 > The toolchain's memory use has been growing as the > versions progress. Fixed RAM+SWAP sizes over long > periods of time are not realistic as stands --unless > room was provided for growth up front. Because of > kernel data structure tradeoffs, SWAP sizing is > effectively constrained by RAM size. For 64-bit > contexts, something like 3.8*RAM avoids notices > of mistuning when the swap is added. >=20 > (An unfortunate property of the mistuning-message > is it makes a suggestion that involves other > tradeoffs for other kernel resources as I understand > --without giving any hint that such a tradeoff is > involved.) >=20 >> - The only reason I added a swap file was that someplace in 11.x = building >> the kernel ran out of memory. >=20 > Toolchain again, yep. >=20 >> - I only build a custom kernel to get options TCP_SIGNATURE for bird. >=20 > Any chance that you could build the kernel outside the > specific VM (in a less constrained context) and somehow > transfer it into the VM? >=20 >> - The swap file worked correctly for all of 11.x until I tried to = build 12.x. >=20 > file-system/vnode backed swap spaces do not fail on > every use but are unreliable. Back when I was isolating > the failures that I was seeing, I found notes from > a wide range of time frames from folks having problems, > as I remember. (Not that I could point you at them any > more.) The problem did not seem to be new, predating 11 > for sure. >=20 > The toolchain memory usage growth over time has probably > lead to reaching failure for file-system backed swap > spaces ever more often over time for ever less > constrained contexts. >=20 >> - There likely out to be a FAQ or handbook page about how to lay >> out lightweight machines. Having used it since 4.x, 1 GB "seems" like >> a pretty big machine, yet these issues arose. >=20 > If partition based swap spaces prove insufficient, > it may require adding messaging to the kernel that > reports on just which of the 4 conditions is > leading to the kills --and possibly related > information for the one that is happening. That > context might be required to make progress. >=20 >=20 I'll note an old buzilla about OOM kills: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241048 started on 2910-Oct-04. [12.1-RELEASE was released on 2019-Nov-04 --and ended support on 2021-Jan-31.] The bugzilla was resolved as fixed on 2020-07-11, but the criteria is a little indirect and your case might well have prevented such a classification if it was known back then. (Too late now for 12.1-RELEASE-p* .) If you still can, may be it is better to skip having 12.1-RELEASE involved in the upgrade sequence? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue May 17 21:51:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 48BB41B32277 for ; Tue, 17 May 2022 21:51:31 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2qZV3Htqz4kTh for ; Tue, 17 May 2022 21:51:30 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 7390DFBF568; Tue, 17 May 2022 21:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1652824283; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=Iy1YKxoO1CtAEBBeb8rDNRi3RCg6qpNKWyIjgGZ/k5I=; b=jxJLbHhjKUy2R5VzkMKpfp9DMIW7zO9pgb0+Acog0OBgtb1vHh3UqneMOL0DIY7v RvaTQmZGeyf45Iyd5GI5f7PtYDX5fNaz3Z48wSbvYf1POxNEAwK2VYq4Q/EBlWocNHk 3GFm687Vsy4jjQIVnSpnO6rEeFXtIhQQw6IH3on23D8cvy30Sy/W6jOnpRPwDEVWPtv crf1UV3EjMVuh6y9zInIBUYmUgRdAYgmf3w3JI2VxUGVVyK4Nbm4MixZmL19/jg8UTo Ea167AX1cqElbtwNPC3z/XZrmvsVQtndtg2oMsUifBbiKnWP/BAN8Aqy8FbjOxTBTeR EcAZE6KDDw== Date: Tue, 17 May 2022 23:51:23 +0200 (CEST) From: henrichhartzer@tuta.io To: George Mitchell Cc: FreeBSD Hackers Message-ID: In-Reply-To: References: Subject: Re: Shy scroll bars List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L2qZV3Htqz4kTh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuta.io header.s=s1 header.b=jxJLbHhj; dmarc=pass (policy=quarantine) header.from=tuta.io; spf=pass (mx1.freebsd.org: domain of henrichhartzer@tuta.io designates 81.3.6.162 as permitted sender) smtp.mailfrom=henrichhartzer@tuta.io X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[tuta.io:s=s1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tuta.io:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[tuta.io,quarantine]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N One option that may not last forever, is using firefox-lts. -Henrich May 17, 2022, 15:27 by george+freebsd@m5p.com: > Among the "features" that have appeared in Firefox 100 is my least > favorite from Linux's so-called Unity interface: in the name of > maximizing non-wasted screen space, scroll bars shrink to maybe two > or three pixels in width whenever the cursor is not in their vicinity. > Sure, this does give a tiny bit more space to other uses, but it means > you can't see at a glance where you have scrolled to in a large image > or document. (At least, it's hard for my aged eyes.) Is there some > way to persuade Firefox not to do this? Thanks for your attention. > -- George > From nobody Tue May 17 22:22:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 570DC1B38EA4 for ; Tue, 17 May 2022 22:22:48 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2rGb4Fgfz4pcs for ; Tue, 17 May 2022 22:22:47 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 24HMMb7u090468 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 17 May 2022 18:22:44 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Tue, 17 May 2022 18:22:37 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Shy scroll bars Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4L2rGb4Fgfz4pcs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 5/17/22 17:51, henrichhartzer@tuta.io wrote: > One option that may not last forever, is using firefox-lts. > > -Henrich > [...] Indeed, and it may come to that sooner or later. Fortunately, Guido Falsi came up with a working fix earlier, but thanks anyway! -- George From nobody Wed May 18 06:52:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 64EBA1AE6563 for ; Wed, 18 May 2022 06:52:52 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L33b742cvz4lqr for ; Wed, 18 May 2022 06:52:51 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4L33b61LGtz6dr1; Wed, 18 May 2022 08:52:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1652856768; x= 1654671169; bh=K+Cbig01Vy/toyfJw/MtuwmLC52Bj2W6wn0fUy4M+9g=; b=g vAXbwsY+iGhxQHzNU6ok2OCtbuB0GHd9JLMP3UC/LqVi7wPjObYA4lhY9QGOqVND XQfAGidxdfE0EI8r7yvhULjD72jd0/G0bw4eXHj+Iv1oxflMEXvFUIJ4JC8nDIL+ svkmMMeNpl7XOWAzbYTcWqSfcdY/W8F7+DUDNeMCV1w2v1YIvcopkwQO7zBXwe+t VJ8g8oigHR2BljHhxMfyHs0BOpugXXiohv3cowIZPCAdlDJsUk+gHLmfXtfn3GcB agineSGvx8sDgxu9Mt0olG3/zRcwYEcr6nVMtxpwKhuNWMg+t5VWw4gZNsS4mKjw UpSmoQicnHjzUgsVo3ijw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id 1GHJN0HvQ02R; Wed, 18 May 2022 08:52:48 +0200 (CEST) Message-ID: <192d767e-a644-405e-b2b4-bb31a71a4af1@madpilot.net> Date: Wed, 18 May 2022 08:52:46 +0200 Subject: Re: Shy scroll bars Content-Language: en-US To: George Mitchell , freebsd-hackers@freebsd.org References: From: Guido Falsi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L33b742cvz4lqr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="g vAXbws"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-0.53)[-0.527]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 18/05/22 00:22, George Mitchell wrote: > On 5/17/22 17:51, henrichhartzer@tuta.io wrote: >> One option that may not last forever, is using firefox-lts. >> >> -Henrich >> [...] > > Indeed, and it may come to that sooner or later.  Fortunately, Guido > Falsi came up with a working fix earlier, but thanks anyway! The problem with my fix is that the knob I identified could one day disappear. But you should be ok for the near future at least :) -- Guido Falsi From nobody Wed May 18 18:29:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C77291B3C5AC for ; Wed, 18 May 2022 18:30:06 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3M3f0MDwz3QfT for ; Wed, 18 May 2022 18:30:05 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 24IIToxl096003 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 18 May 2022 14:29:57 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <37d165ec-cc47-2940-3c05-159640849f1f@m5p.com> Date: Wed, 18 May 2022 14:29:50 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Shy scroll bars Content-Language: en-US To: freebsd-hackers@freebsd.org References: <192d767e-a644-405e-b2b4-bb31a71a4af1@madpilot.net> From: George Mitchell In-Reply-To: <192d767e-a644-405e-b2b4-bb31a71a4af1@madpilot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4L3M3f0MDwz3QfT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_FROM(0.00)[freebsd] X-ThisMailContainsUnwantedMimeParts: N On 5/18/22 02:52, Guido Falsi wrote: > [...] > The problem with my fix is that the knob I identified could one day > disappear. But you should be ok for the near future at least :) > That'll give me an excuse to write about shy configuration knobs! -- George From nobody Wed May 18 19:03:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9F8B41812C7C for ; Wed, 18 May 2022 19:03:23 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3Mp26s4yz3l8b for ; Wed, 18 May 2022 19:03:22 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x129.google.com with SMTP id d3so2148097ilr.10 for ; Wed, 18 May 2022 12:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:subject:message-id:mime-version :content-disposition; bh=/kvk9RXAZULNgzeXpI8wniZe6WmI1vHEMsLcFfmJazA=; b=fT3eMZSfjX6yUTNdUJ+veRDCumUnv1rdWP/mhFU59hlq0EeZtOWI8NBBOpwupvJro1 M21RaMwkFK/JrKpow12zryvtQvj4Bngei8ED3I036Z3HRcsRKoU7cy8Nh8gm24/nS651 7Mutdkjk91zwCgb7sm3i3qRugyst0r0WChiwzp2Hto4zJ0yju0BE14j0PwrDVhH+tjQW Ip2O8/60y2BUPrxCjeCCq6r67KvwLqSRi7r/WWiXThhTKV2c6tE83EUvM7fpSAfGOPQl c4SCTDH7uta9kjcRlCKYi5mQk03EySKr7LrQVdosyR6egdzztpy/NScTY86HJ5968vdH +Jag== 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:subject:message-id :mime-version:content-disposition; bh=/kvk9RXAZULNgzeXpI8wniZe6WmI1vHEMsLcFfmJazA=; b=JLOtxwliqFpZGPFDFt3RlS6mztXyedqSvaJ4qN1L235fDwjsPrGMEJj+mwRn9XgKO3 ZYxSS+aV1LT2xg+5aOqd7TvbHPSE+Bit2RF0/uIxmjSshII7ZbDXpe7p9LeytKqhQpfD qV9amDzS29Jr1HGdUMqTvFCLP0n42SGvoOvv9tOowi2yb1zYOdhelG4aqLUadiXR53aK LDdl1PDvhA+bvNBDS3b6c90hVUnUaR2Lore9jxXbLTdifookwNqAnnPf+eFhYRLRXvXO hg2eWfVpLrbmFoeIC+2U40pxzk55xyQ54yYD/8VEmPv7pxoZkD6o2VZCERtqArQOd7Rn GS7g== X-Gm-Message-State: AOAM530tuzXr+sR9KEk+fDRx65qEuH/zUfsMkVC9D3lfaNd7JALDeZpZ jGoShxzzGMhn2fq8aMdUbzaK/Z7zR3A= X-Google-Smtp-Source: ABdhPJy47pyNuY7ROZFxGuBRn+/7IBrXzNhUPcRtYN77YoyfkY1Aa9T0MYX7rX/W1PlB2zH0lGN0pQ== X-Received: by 2002:a92:cd4f:0:b0:2d1:26d:be58 with SMTP id v15-20020a92cd4f000000b002d1026dbe58mr628356ilq.223.1652900601635; Wed, 18 May 2022 12:03:21 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id t11-20020a5edd0b000000b0065a47e16f63sm36459iop.53.2022.05.18.12.03.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 12:03:20 -0700 (PDT) Date: Wed, 18 May 2022 15:03:17 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Subject: zfs support in makefs Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4L3Mp26s4yz3l8b X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fT3eMZSf; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::129:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, For the past little while I've been working on ZFS support in makefs(8). At this point I'm able to create a bootable FreeBSD VM image, using the standard FreeBSD ZFS layout, and run through the regression test suite in bhyve. I've also been able to create and boot an EC2 AMI. Some background is below for anyone interested, and I would greatly appreciate feedback on the interface, described further below. The initial diff is here: https://reviews.freebsd.org/D35248 Comments here or in the review are welcome. === Background === The goal is to enable creation of ZFS-based VM images, in particular by release(7). Currently one can implement this by creating a pool on a file-backed memory disk and populating it with "make installworld", but this has a few drawbacks: 1. The resulting images are not reproducible. That is, if one creates two ZFS images with identical contents, the images themselves will not be byte-identical. For instance, each pool gets a randomly generated GUID, as does each vdev, and there are other sources of non-determinism besides. 2. Creating a zpool requires root privileges by default and can't be done at all in a jail. 3. Populating the image is a resource-intensive operation, the kernel will cache the output files until the pool is exported, etc. For UFS images we use makefs to solve these problems, so I wanted to try and take the same approach for ZFS. I assume that the appeal of using ZFS as the root filesystem for VMs is obvious. I initially implemented ZFS support in makefs using libzpool.so, which is effectively a copy of the OpenZFS kernel code compiled for userspace. It is mostly used for testing and debugging. This worked and was relatively simple to implement, but it only solved problem 2. Bending libzpool to satisfy my requirements seemed difficult, and the result would require continuous maintenance as OpenZFS evolves and its internal interfaces change. I spent some time hacking libzpool to limit its memory and CPU usage and gave up; while it was functional, the result was painfully slow. I then looked at the bits used by the loader to load files off of a boot volume, and implemented the creation of ZFS images from scratch, i.e., without reusing OpenZFS code. This required more effort but I believe it'll be easier to maintain in the long run, and it solves all three problems above. The implementation is mostly derived from an old ZFS on-disk format specification (http://www.giis.co.in/Zfs_ondiskformat.pdf), various blog posts, and lots of time spent staring at zdb output. I reused some code from the boot loader: the nvlist implementation, since the one in sys/contrib doesn't have some required features, and zfsimpl.h, which contains C structs describing various on-disk data structures. ZFS in general is pretty complex so this effort required some specialization to the problem at hand. In particular, makefs - always creates a pool with a single disk vdev with all data written in a single transaction group; there's no snapshots, no RAID-Z/dRAID, no redundant block copies, no ZIL, no encryption, no gang blocks, no zvol, etc. - does not implement compression, - doesn't preserve holes in files, - always creates pools at version 5000, i.e., all feature flags are off and have to be enabled separately, - does not try to do any clever metaslab placement or sizing, on the basis that the pool will likely be expanded upon first boot anyway, - doesn't use spill blocks and is not particularly clever when it comes to choosing block sizes, creating some avoidable internal fragmentation (though it doesn't seem too bad relative to OpenZFS without compression, maybe 10% overhead in some unscientific tests) Some of these can be addressed (especially compression and sparse file support), but I wanted to get some feedback before spending more time on this. Really this thing is just intended to do the minimum necessary to provide ZFS-based VM images. === Interface === Creating a pool with a single dataset is easy: $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input Upon importing such a pool, you'll get a dataset named "test" mounted at /test containing everything under /path/to/input. It's possible to set properties on the root dataset: $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input It's also possible to create additional datasets: $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input The parameter syntax is "-o fs=[:=[:=[:...]]]". Only a few properties are supported, at least for now. Dataset mountpoints behave the same as they would if created with the standard ZFS tools. So by default the root dataset's mountpoint is /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides its default mountpoint, its children inherit that mountpoint. makefs builds the output filesystem using a single input directory tree. Thus, makefs -t zfs requires that at least one of the dataset's mountpoints map to /path/to/input; that is, there is a "root" mount point. The -o rootpath parameter defines this root mount point. By default it's "/". All datasets in the pool must have their mountpoints under this path, and one dataset's mountpoint must be equal to this path. To build bootable images, one sets -o rootpath=/. Putting it all together, one can build a image using the standard layout with an invocation like this: makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ -o fs=zroot:canmount=off:mountpoint=none \ -o fs=zroot/ROOT:mountpoint=none \ -o fs=zroot/ROOT/default:mountpoint=/ \ -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ -o fs=zroot/usr:mountpoint=/usr:canmount=off \ -o fs=zroot/usr/home \ -o fs=zroot/usr/ports:setuid=off \ -o fs=zroot/usr/src \ -o fs=zroot/usr/obj \ -o fs=zroot/var:mountpoint=/var:canmount=off \ -o fs=zroot/var/audit:setuid=off:exec=off \ -o fs=zroot/var/crash:setuid=off:exec=off \ -o fs=zroot/var/log:setuid=off:exec=off \ -o fs=zroot/var/mail:atime=on \ -o fs=zroot/var/tmp:setuid=off \ ${HOME}/tmp/zfs.img ${HOME}/tmp/world I'll admit this is somewhat clunky, but it doesn't seem worse than what we have to do otherwise, see poudriere-image for example: https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 What do folks think of this interface? Is there anything missing, or anything that doesn't make sense? From nobody Wed May 18 22:31:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AF111ADDA37 for ; Wed, 18 May 2022 22:31:45 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3SQS2Xkrz4jJX for ; Wed, 18 May 2022 22:31:44 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 10B952A447 for ; Wed, 18 May 2022 22:31:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 10B952A447 Message-ID: <4da73ba8-ce99-7922-a14a-8e2f2d5390f0@freebsd.org> Date: Wed, 18 May 2022 18:31:36 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: zfs support in makefs Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: Allan Jude In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L3SQS2Xkrz4jJX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:470:1:474::25 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-3.02 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.98)[-0.984]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/18/2022 3:03 PM, Mark Johnston wrote: > Hi, > > For the past little while I've been working on ZFS support in makefs(8). > At this point I'm able to create a bootable FreeBSD VM image, using the > standard FreeBSD ZFS layout, and run through the regression test suite > in bhyve. I've also been able to create and boot an EC2 AMI. > > Some background is below for anyone interested, and I would greatly > appreciate feedback on the interface, described further below. > > The initial diff is here: https://reviews.freebsd.org/D35248 > > Comments here or in the review are welcome. > > === Background === > > The goal is to enable creation of ZFS-based VM images, in particular by > release(7). Currently one can implement this by creating a pool on a > file-backed memory disk and populating it with "make installworld", but > this has a few drawbacks: > > 1. The resulting images are not reproducible. That is, if one creates > two ZFS images with identical contents, the images themselves will not > be byte-identical. For instance, each pool gets a randomly generated > GUID, as does each vdev, and there are other sources of > non-determinism besides. > 2. Creating a zpool requires root privileges by default and can't be done > at all in a jail. > 3. Populating the image is a resource-intensive operation, the kernel > will cache the output files until the pool is exported, etc. > > For UFS images we use makefs to solve these problems, so I wanted to try > and take the same approach for ZFS. I assume that the appeal of using > ZFS as the root filesystem for VMs is obvious. > > I initially implemented ZFS support in makefs using libzpool.so, which > is effectively a copy of the OpenZFS kernel code compiled for userspace. > It is mostly used for testing and debugging. This worked and was > relatively simple to implement, but it only solved problem 2. Bending > libzpool to satisfy my requirements seemed difficult, and the result > would require continuous maintenance as OpenZFS evolves and its internal > interfaces change. I spent some time hacking libzpool to limit its > memory and CPU usage and gave up; while it was functional, the result > was painfully slow. > > I then looked at the bits used by the loader to load files off of a boot > volume, and implemented the creation of ZFS images from scratch, i.e., > without reusing OpenZFS code. This required more effort but I believe > it'll be easier to maintain in the long run, and it solves all three > problems above. > > The implementation is mostly derived from an old ZFS on-disk format > specification (http://www.giis.co.in/Zfs_ondiskformat.pdf), various blog > posts, and lots of time spent staring at zdb output. I reused some code > from the boot loader: the nvlist implementation, since the one in > sys/contrib doesn't have some required features, and zfsimpl.h, which > contains C structs describing various on-disk data structures. > > ZFS in general is pretty complex so this effort required some > specialization to the problem at hand. In particular, makefs > - always creates a pool with a single disk vdev with all data written in > a single transaction group; there's no snapshots, no RAID-Z/dRAID, no > redundant block copies, no ZIL, no encryption, no gang blocks, no > zvol, etc. > - does not implement compression, > - doesn't preserve holes in files, > - always creates pools at version 5000, i.e., all feature flags are off > and have to be enabled separately, > - does not try to do any clever metaslab placement or sizing, on the > basis that the pool will likely be expanded upon first boot anyway, > - doesn't use spill blocks and is not particularly clever when it comes > to choosing block sizes, creating some avoidable internal > fragmentation (though it doesn't seem too bad relative to OpenZFS > without compression, maybe 10% overhead in some unscientific tests) > > Some of these can be addressed (especially compression and sparse file > support), but I wanted to get some feedback before spending more time on > this. Really this thing is just intended to do the minimum necessary to > provide ZFS-based VM images. > > === Interface === > > Creating a pool with a single dataset is easy: > > $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input > > Upon importing such a pool, you'll get a dataset named "test" mounted at > /test containing everything under /path/to/input. > > It's possible to set properties on the root dataset: > > $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input > > It's also possible to create additional datasets: > > $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input > > The parameter syntax is > "-o fs=[:=[:=[:...]]]". Only a > few properties are supported, at least for now. > > Dataset mountpoints behave the same as they would if created with the > standard ZFS tools. So by default the root dataset's mountpoint is > /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > its default mountpoint, its children inherit that mountpoint. > > makefs builds the output filesystem using a single input directory tree. > Thus, makefs -t zfs requires that at least one of the dataset's > mountpoints map to /path/to/input; that is, there is a "root" mount > point. > > The -o rootpath parameter defines this root mount point. By default it's > "/". All datasets in the pool must have their mountpoints > under this path, and one dataset's mountpoint must be equal to this > path. To build bootable images, one sets -o rootpath=/. > > Putting it all together, one can build a image using the standard layout > with an invocation like this: > > makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ > -o fs=zroot:canmount=off:mountpoint=none \ > -o fs=zroot/ROOT:mountpoint=none \ > -o fs=zroot/ROOT/default:mountpoint=/ \ > -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ > -o fs=zroot/usr:mountpoint=/usr:canmount=off \ > -o fs=zroot/usr/home \ > -o fs=zroot/usr/ports:setuid=off \ > -o fs=zroot/usr/src \ > -o fs=zroot/usr/obj \ > -o fs=zroot/var:mountpoint=/var:canmount=off \ > -o fs=zroot/var/audit:setuid=off:exec=off \ > -o fs=zroot/var/crash:setuid=off:exec=off \ > -o fs=zroot/var/log:setuid=off:exec=off \ > -o fs=zroot/var/mail:atime=on \ > -o fs=zroot/var/tmp:setuid=off \ > ${HOME}/tmp/zfs.img ${HOME}/tmp/world > > I'll admit this is somewhat clunky, but it doesn't seem worse than what > we have to do otherwise, see poudriere-image for example: > https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 > > What do folks think of this interface? Is there anything missing, or > anything that doesn't make sense? > Really nice work on this. It sounds like you've covered everything. Only thing that jumps out at me is specifically because it is designed to be resized upwards, we may want to look at being a bit clever with the metaslabs. Specifically, the normal thing is to create ~200 of them, but if the image is only 10g, it is likely to create really small metaslabs, but all metaslabs are the same size, so if the pool is grown to a few TB, it will have a lot of tiny metaslabs, and it might make more sense to set a floor for the size, or offer the user some control when creating the pool. There is a sysctl that controls this in the normal code paths, maybe we can easily allow setting that like zdb does with its -o flag. -- Allan Jude From nobody Wed May 18 23:04:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C03A91AE390C for ; Wed, 18 May 2022 23:04:34 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3T8K4c3Sz4m31; Wed, 18 May 2022 23:04:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 940BD3C0199; Wed, 18 May 2022 23:04:27 +0000 (UTC) Date: Wed, 18 May 2022 23:04:27 +0000 From: Brooks Davis To: Mark Johnston Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: <20220518230427.GI15201@spindle.one-eyed-alien.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Encpt1P6Mxii2VuT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4L3T8K4c3Sz4m31 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-1.10 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.18)[0.175]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.62)[0.615]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --Encpt1P6Mxii2VuT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > Hi, >=20 > For the past little while I've been working on ZFS support in makefs(8). > At this point I'm able to create a bootable FreeBSD VM image, using the > standard FreeBSD ZFS layout, and run through the regression test suite > in bhyve. I've also been able to create and boot an EC2 AMI. Very cool! > =3D=3D=3D Interface =3D=3D=3D >=20 > Creating a pool with a single dataset is easy: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest ./zfs.img /path/to/input >=20 > Upon importing such a pool, you'll get a dataset named "test" mounted at > /test containing everything under /path/to/input. >=20 > It's possible to set properties on the root dataset: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest:setuid=3Doff:atime= =3Don ./zfs.img /path/to/input >=20 > It's also possible to create additional datasets: >=20 > $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest/ds1:mountpoint=3D/= test/dir1 ./zfs.img /path/to/input >=20 > The parameter syntax is > "-o fs=3D[:=3D[:=3D[:...]]]". On= ly a > few properties are supported, at least for now. >=20 > Dataset mountpoints behave the same as they would if created with the > standard ZFS tools. So by default the root dataset's mountpoint is > /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > its default mountpoint, its children inherit that mountpoint. >=20 > makefs builds the output filesystem using a single input directory tree. > Thus, makefs -t zfs requires that at least one of the dataset's > mountpoints map to /path/to/input; that is, there is a "root" mount > point. >=20 > The -o rootpath parameter defines this root mount point. By default it's > "/". All datasets in the pool must have their mountpoints > under this path, and one dataset's mountpoint must be equal to this > path. To build bootable images, one sets -o rootpath=3D/. >=20 > Putting it all together, one can build a image using the standard layout > with an invocation like this: >=20 > makefs -t zfs -o poolname=3Dzroot -s 20g -o rootpath=3D/ -o bootfs=3Dzroo= t/ROOT/default \ > -o fs=3Dzroot:canmount=3Doff:mountpoint=3Dnone \ > -o fs=3Dzroot/ROOT:mountpoint=3Dnone \ > -o fs=3Dzroot/ROOT/default:mountpoint=3D/ \ > -o fs=3Dzroot/tmp:mountpoint=3D/tmp:exec=3Don:setuid=3Doff \ > -o fs=3Dzroot/usr:mountpoint=3D/usr:canmount=3Doff \ > -o fs=3Dzroot/usr/home \ > -o fs=3Dzroot/usr/ports:setuid=3Doff \ > -o fs=3Dzroot/usr/src \ > -o fs=3Dzroot/usr/obj \ > -o fs=3Dzroot/var:mountpoint=3D/var:canmount=3Doff \ > -o fs=3Dzroot/var/audit:setuid=3Doff:exec=3Doff \ > -o fs=3Dzroot/var/crash:setuid=3Doff:exec=3Doff \ > -o fs=3Dzroot/var/log:setuid=3Doff:exec=3Doff \ > -o fs=3Dzroot/var/mail:atime=3Don \ > -o fs=3Dzroot/var/tmp:setuid=3Doff \ > ${HOME}/tmp/zfs.img ${HOME}/tmp/world >=20 > I'll admit this is somewhat clunky, but it doesn't seem worse than what > we have to do otherwise, see poudriere-image for example: > https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/imag= e_zfs.sh#L79 >=20 > What do folks think of this interface? Is there anything missing, or > anything that doesn't make sense? I find it slightly confusing that -o options have a default namespace of pool options unless they have an fs=3D*: prefix, but making users type "pool:" for other options doesn't seem to make sense so this is probably the best solution. The density of data in the filesystem specification does suggest that someone might want to create a UCL config file format eventually, but what's here already seems entirely workable. -- Brooks --Encpt1P6Mxii2VuT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJihXt6AAoJEKzQXbSebgfAN3cH+QE2L7vE4W7FBudP6U7KtYKd 34EqGrZO41PyzuBWYzNnUgNSZ5DaQKaOsX7e/gejoe4y8MJvAwkq3UzhKZJJzx5f sKCWPKdYsL547hlH73keb6DivOt0KUl5JQ8yacNtQC/VSptwSxGx3QZ42R0Ni68y fWTrbc3HopgSykRrOPIfRgC28peFU9Yx2/lPL1tmr0lqfdANIEbb4ec8uNXYQ4Al QlQmeb9FTLS08b5wkDmdnkCUbiaDS3ndfFsjXg5N2UqDiLyzj98tBXaY7hGDF3M/ IZQpa9fC1RxVGJrf2Z14ie6YmT6xRUbjFjTsSOSMqjTn8PCbT8g5tjqw0FbWlIw= =orTB -----END PGP SIGNATURE----- --Encpt1P6Mxii2VuT-- From nobody Thu May 19 16:24:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 434F61B46580 for ; Thu, 19 May 2022 16:25:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3wDr1Mcjz4vP9 for ; Thu, 19 May 2022 16:25:00 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652977500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=enkuR+57DmmRMtE67ErVn9ivJZF38L56e07BuZXEW/U=; b=ffeXgLB4Bbv5UTewda2V+7jt2ieDBqbsL4Xp3mY3IL67pnQd7TJ1IwABIOwTe8Vhdf9Vi5 03GntnfWVQN3MFbJP5K3d7gvFRomsLrvgqDHxUooydGVmDCU+oiBbSsPL/tjc8AEsfKPPp lOZCoCpRjCa0FBvuxeXETlbVbZz1gPaTtNm3XILQ2RA15h/j2SLSX+nVgo/JFAXMBQlLDG KAJOAzNH8tSRZEDO9DnGyG0rdZL6fp2QO1NuHiAHeKMDgPqz2n9LOeKDFcvNw1lukSj4Cz 7YgmPFrnxaZqsUQrXcyKIZjoXQlD75i26EkUXEDZsVaLxAtg+JnP1dstYAoV7Q== Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 0B3154D7 for ; Thu, 19 May 2022 16:25:00 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-edeb6c3642so7402020fac.3 for ; Thu, 19 May 2022 09:25:00 -0700 (PDT) X-Gm-Message-State: AOAM530d5y4vBGMH49N2wb8biMlO4fvI3lY8FH7lcQN/XGRio3t062YN 4hl+J38FDi8WdImkWjqFJZLceHfkoEYlYUqVjw4= X-Google-Smtp-Source: ABdhPJyQ+1SUmEUhAkPmo5QEbpJmuG5RAJCSw6egyPhHeAFezTF9JvGBL80rGfyuhinLxuYaMuSv4oWPYWw7qEkglVM= X-Received: by 2002:a05:6870:e248:b0:f1:eb1f:945b with SMTP id d8-20020a056870e24800b000f1eb1f945bmr3012212oac.292.1652977499322; Thu, 19 May 2022 09:24:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Thu, 19 May 2022 09:24:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: iconv changes To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1652977500; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=enkuR+57DmmRMtE67ErVn9ivJZF38L56e07BuZXEW/U=; b=QDwqBY0UJRdUWHlK/rIJw+qbdVXp/WBtnimgoYh+9RDljx9f0SoGHUG/xG0MJUZFfDSgem ToJodKPjTo+8NvZm4xKv2yXryUGGw6XmUoMyOC3yAD+dCORaVYYbjstjx0gQ+aeoE5SogT hywBX2tW9l4zvfq1vKp3bzUNpDsO5iKfYtiV0pArw85sOPJf0t547w2+ajHjjqcL0x7hZu PEXT6CsPGbMKK1yoSK0EBDsDbhVspRRjYRu9RVOwqZH6jO09kQ3xjtsnWQ7MBYJN0N1CRM H6/LYNyCWHU+RMUYI0rlEM3cJprCCBbG+SmuaHF3ZAB1Nh3zTnxL0T/Yxe3hLg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1652977500; a=rsa-sha256; cv=none; b=Ge8YKf3lGvMlCEVQEcrey8ONgwki8Q5ybeC8nK9vfQG1LwFha5fiDeKnoGKIVJ7mzLSkxi yNKN13jBM4S9ku3tu7y0FUXRo8vGRimHdR+w9wroWKWQLUsOYugUnqmv/s6VXIZBGkYhj0 xgztXO1qSNbfwAKjaV+kKsg16QDGev8+t4WeQQxtAwCo03TGGE5WjhutJzkSLhOHPBoO+D ++CmWEO5FmT1dadiL6xedMGyoZiaBWoYU0p97bq1rJpWsUl0Z3OMnPEv83mi3gPgjNxIPn OjStO2D63+ZOziyY+0rGq2F6x/cpHWQSEkdClb2HcHdUOYvDtWhhd2IFlunZdw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, Feb 22, 2022 at 10:34 AM Kyle Evans wrote: > > Hello! > > Results of `git log` were somewhat inconclusive, so I'm casting a bit > of a wider net here; I've got four changes just posted to Phabricator > for iconv and iconv modules that could use some third party review. > These largely pertain to //IGNORE support: > > - https://reviews.freebsd.org/D34342 ("iconv: only conditionally use > ICONV_SET_DISCARD_ILSEQ") > - https://reviews.freebsd.org/D34343 ("libc: iconv: push option > ignore into citrus_iconv_open()") > - https://reviews.freebsd.org/D34344 ("libc: iconv: add mb_cur_min > for encoder traits") > - https://reviews.freebsd.org/D34345 ("iconv_std: complete the > //IGNORE support") > > The short version is that //IGNORE is only partially implemented at > the moment if you consider the behavior it was trying to model: GNU > libiconv. With GNU libiconv, you can use it to, e.g., sanitize a UTF-8 > string by removing illegal sequences rather than truncating. > > These reviews aim to fix it so that it works the same for our > libiconv, which would previously only ignore EILSEQ that arise as a > result of csmapper failures and not those that arise in initial > mbrtowc. > 3-month ping: any takers? From nobody Thu May 19 16:32:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 810541B47F24 for ; Thu, 19 May 2022 16:32:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3wPT43v3z3D0m; Thu, 19 May 2022 16:32:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id x7so1965201qta.6; Thu, 19 May 2022 09:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Kuqogi4m9X8C3HLnaNxO+vYrErV/8K7afchiDSdiQ44=; b=cnI78/u45SI++CSIxoHNNOkcz0MdqDkRCGSFoFAMNfHLEel6YiM7h2Aiq+zwXeX5lC 1AAfLBOAawKjY2hH5D/LyPeQUhid4ifndQvMdcXBBY3AIi/xqYUpZlEVNxRrnxPLrRmC /NeKui5SPBB7GbiS9DzJUGBu9ol95Vc1+P5yq0uY7z2xFd0iSCEWAYbMJMRuyicIEDcJ R4O3B+gNJi9UGeqEJggcBy97CEuWih85VeWpKvQMPW94ZU2OJHzh/CNhPPXUZoBathZ7 fSagKfvMPXMV4Tru0J1Pq0TuDLc6BC+oab7Y+capUC9vVbOpUGd9rmeNmjQDS2X0cLiY hOeQ== 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=Kuqogi4m9X8C3HLnaNxO+vYrErV/8K7afchiDSdiQ44=; b=h0ANQQpiZsQZEhJFwjc7/y8zVqBUDiK3KZv6V88U4253iwvGuBceiNDsaVTjKJgA3C RkWZYmRcmne2IHhUncobw8r+Un3Rg8mqpQHhTy+wpAOPRSLKUaCTwZd/nwf5ME4PKdNl YQU2SNVKcRI8T89GYaJ2YY8qESq3AZ5y7VL5Za9oZO8gtzWF9CO0D+JNjjW135WTRcUJ fK+a3LllqGslW7JYFKohKdetHg9dZb2/PQZlaiL30cbmDLt5G9jRGJCYq/GkbSv+0Xmo 6+u/Cc0xqs3RPMnH82VrlSOccxO2g5BpmGUzL0qcHLArpE0xE2Uk06kVVZVqIhPwfZzc tCJw== X-Gm-Message-State: AOAM532FXPDJWa/AcBHD1IvNqhTn7g02GRKKnGiFOhiRmGBjrwpIoJbU o7suWF3pKTthRD+NRXSefor0Z+0pHFo= X-Google-Smtp-Source: ABdhPJz3xkDaPTknBj/WqLRSgejkIdcuhQ69fx78HJpopH+XxRM/haFbj6WYf5B/a9s9pvoCPiL0cg== X-Received: by 2002:a05:622a:1a15:b0:2f7:3b31:7d86 with SMTP id f21-20020a05622a1a1500b002f73b317d86mr4550937qtb.1.1652977948405; Thu, 19 May 2022 09:32:28 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id d14-20020ac847ce000000b002f90a33c78csm1478567qtr.67.2022.05.19.09.32.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 May 2022 09:32:27 -0700 (PDT) Date: Thu, 19 May 2022 12:32:25 -0400 From: Mark Johnston To: Brooks Davis Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: References: <20220518230427.GI15201@spindle.one-eyed-alien.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220518230427.GI15201@spindle.one-eyed-alien.net> X-Rspamd-Queue-Id: 4L3wPT43v3z3D0m X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="cnI78/u4"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.52 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.88)[-0.876]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; NEURAL_HAM_SHORT(-0.99)[-0.985]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Wed, May 18, 2022 at 11:04:27PM +0000, Brooks Davis wrote: > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > > Hi, > > > > For the past little while I've been working on ZFS support in makefs(8). > > At this point I'm able to create a bootable FreeBSD VM image, using the > > standard FreeBSD ZFS layout, and run through the regression test suite > > in bhyve. I've also been able to create and boot an EC2 AMI. > > Very cool! > > > === Interface === > > > > Creating a pool with a single dataset is easy: > > > > $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input > > > > Upon importing such a pool, you'll get a dataset named "test" mounted at > > /test containing everything under /path/to/input. > > > > It's possible to set properties on the root dataset: > > > > $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input > > > > It's also possible to create additional datasets: > > > > $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input > > > > The parameter syntax is > > "-o fs=[:=[:=[:...]]]". Only a > > few properties are supported, at least for now. > > > > Dataset mountpoints behave the same as they would if created with the > > standard ZFS tools. So by default the root dataset's mountpoint is > > /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > > its default mountpoint, its children inherit that mountpoint. > > > > makefs builds the output filesystem using a single input directory tree. > > Thus, makefs -t zfs requires that at least one of the dataset's > > mountpoints map to /path/to/input; that is, there is a "root" mount > > point. > > > > The -o rootpath parameter defines this root mount point. By default it's > > "/". All datasets in the pool must have their mountpoints > > under this path, and one dataset's mountpoint must be equal to this > > path. To build bootable images, one sets -o rootpath=/. > > > > Putting it all together, one can build a image using the standard layout > > with an invocation like this: > > > > makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ > > -o fs=zroot:canmount=off:mountpoint=none \ > > -o fs=zroot/ROOT:mountpoint=none \ > > -o fs=zroot/ROOT/default:mountpoint=/ \ > > -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ > > -o fs=zroot/usr:mountpoint=/usr:canmount=off \ > > -o fs=zroot/usr/home \ > > -o fs=zroot/usr/ports:setuid=off \ > > -o fs=zroot/usr/src \ > > -o fs=zroot/usr/obj \ > > -o fs=zroot/var:mountpoint=/var:canmount=off \ > > -o fs=zroot/var/audit:setuid=off:exec=off \ > > -o fs=zroot/var/crash:setuid=off:exec=off \ > > -o fs=zroot/var/log:setuid=off:exec=off \ > > -o fs=zroot/var/mail:atime=on \ > > -o fs=zroot/var/tmp:setuid=off \ > > ${HOME}/tmp/zfs.img ${HOME}/tmp/world > > > > I'll admit this is somewhat clunky, but it doesn't seem worse than what > > we have to do otherwise, see poudriere-image for example: > > https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 > > > > What do folks think of this interface? Is there anything missing, or > > anything that doesn't make sense? > > I find it slightly confusing that -o options have a default namespace of > pool options unless they have an fs=*: prefix, but making users type > "pool:" for other options doesn't seem to make sense so this is probably > the best solution. Yeah, this was exactly my reasoning for the current syntax. It might be worth revisiting if we end up adding many more options, but I would like to try and keep makefs as simple as possible. > The density of data in the filesystem specification does suggest that > someone might want to create a UCL config file format eventually, but > what's here already seems entirely workable. I thought about this too. We have several definitions of the standard FreeBSD ZFS dataset layout scattered around, in bsdinstall, poudriere, and probably elsewhere. release(7) would get yet another instance; see D23334 and D34426. So, it'd be nice to have a single definition (and perhaps some alternative layouts) defined somewhere central, ideally in a format that can also be consumed by OpenZFS tools. OpenZFS might already have something like this, I don't know. From nobody Thu May 19 17:36:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4664D1AE8DFC for ; Thu, 19 May 2022 17:36:28 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3xqG6QPRz3RJs for ; Thu, 19 May 2022 17:36:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 595842DB7E for ; Thu, 19 May 2022 17:36:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 595842DB7E Message-ID: Date: Thu, 19 May 2022 13:36:25 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: zfs support in makefs Content-Language: en-US To: freebsd-hackers@freebsd.org References: <20220518230427.GI15201@spindle.one-eyed-alien.net> From: Allan Jude In-Reply-To: <20220518230427.GI15201@spindle.one-eyed-alien.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L3xqG6QPRz3RJs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-2.57 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_SHORT(-0.50)[-0.504]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/18/2022 7:04 PM, Brooks Davis wrote: > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: >> Hi, >> >> For the past little while I've been working on ZFS support in makefs(8). >> At this point I'm able to create a bootable FreeBSD VM image, using the >> standard FreeBSD ZFS layout, and run through the regression test suite >> in bhyve. I've also been able to create and boot an EC2 AMI. > > Very cool! > >> === Interface === >> >> Creating a pool with a single dataset is easy: >> >> $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input >> >> Upon importing such a pool, you'll get a dataset named "test" mounted at >> /test containing everything under /path/to/input. >> >> It's possible to set properties on the root dataset: >> >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input >> >> It's also possible to create additional datasets: >> >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input >> >> The parameter syntax is >> "-o fs=[:=[:=[:...]]]". Only a >> few properties are supported, at least for now. >> >> Dataset mountpoints behave the same as they would if created with the >> standard ZFS tools. So by default the root dataset's mountpoint is >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides >> its default mountpoint, its children inherit that mountpoint. >> >> makefs builds the output filesystem using a single input directory tree. >> Thus, makefs -t zfs requires that at least one of the dataset's >> mountpoints map to /path/to/input; that is, there is a "root" mount >> point. >> >> The -o rootpath parameter defines this root mount point. By default it's >> "/". All datasets in the pool must have their mountpoints >> under this path, and one dataset's mountpoint must be equal to this >> path. To build bootable images, one sets -o rootpath=/. >> >> Putting it all together, one can build a image using the standard layout >> with an invocation like this: >> >> makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ >> -o fs=zroot:canmount=off:mountpoint=none \ >> -o fs=zroot/ROOT:mountpoint=none \ >> -o fs=zroot/ROOT/default:mountpoint=/ \ >> -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ >> -o fs=zroot/usr:mountpoint=/usr:canmount=off \ >> -o fs=zroot/usr/home \ >> -o fs=zroot/usr/ports:setuid=off \ >> -o fs=zroot/usr/src \ >> -o fs=zroot/usr/obj \ >> -o fs=zroot/var:mountpoint=/var:canmount=off \ >> -o fs=zroot/var/audit:setuid=off:exec=off \ >> -o fs=zroot/var/crash:setuid=off:exec=off \ >> -o fs=zroot/var/log:setuid=off:exec=off \ >> -o fs=zroot/var/mail:atime=on \ >> -o fs=zroot/var/tmp:setuid=off \ >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world >> >> I'll admit this is somewhat clunky, but it doesn't seem worse than what >> we have to do otherwise, see poudriere-image for example: >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 >> >> What do folks think of this interface? Is there anything missing, or >> anything that doesn't make sense? > > I find it slightly confusing that -o options have a default namespace of > pool options unless they have an fs=*: prefix, but making users type > "pool:" for other options doesn't seem to make sense so this is probably > the best solution. > > The density of data in the filesystem specification does suggest that > someone might want to create a UCL config file format eventually, but > what's here already seems entirely workable. > > -- Brooks In normal `zpool create` they use -o for pool properties, and -O for dataset properties for the root dataset. I wonder if we might also want -o poolprop=value and -O zroot/var:mountpoint=/var:canmount=off just to avoid the conceptual collision of those 2 different items. One other possible issue: dataset properties can have a : in them, for user-defined properties. Do we maybe want to use a , to separate them instead? Although values can contain ,'s (the sharenfs property often does), so that probably doesn't work either. -- Allan Jude From nobody Thu May 19 18:25:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FC2F1B376D9 for ; Thu, 19 May 2022 18:25:34 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L3yvx17fpz3vXJ; Thu, 19 May 2022 18:25:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 6C1503C0199; Thu, 19 May 2022 18:25:32 +0000 (UTC) Date: Thu, 19 May 2022 18:25:32 +0000 From: Brooks Davis To: Allan Jude Cc: freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: <20220519182532.GJ15201@spindle.one-eyed-alien.net> References: <20220518230427.GI15201@spindle.one-eyed-alien.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ed/6oDxOLijJh8b0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4L3yvx17fpz3vXJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-2.79 / 15.00]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[brooks]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.78)[-0.781]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-0.11)[-0.112]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; SIGNED_PGP(-2.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net] X-ThisMailContainsUnwantedMimeParts: N --ed/6oDxOLijJh8b0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 19, 2022 at 01:36:25PM -0400, Allan Jude wrote: > On 5/18/2022 7:04 PM, Brooks Davis wrote: > > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > >> Hi, > >> > >> For the past little while I've been working on ZFS support in makefs(8= ). > >> At this point I'm able to create a bootable FreeBSD VM image, using the > >> standard FreeBSD ZFS layout, and run through the regression test suite > >> in bhyve. I've also been able to create and boot an EC2 AMI. > >=20 > > Very cool! > >=20 > >> =3D=3D=3D Interface =3D=3D=3D > >> > >> Creating a pool with a single dataset is easy: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest ./zfs.img /path/to/input > >> > >> Upon importing such a pool, you'll get a dataset named "test" mounted = at > >> /test containing everything under /path/to/input. > >> > >> It's possible to set properties on the root dataset: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest:setuid=3Doff:at= ime=3Don ./zfs.img /path/to/input > >> > >> It's also possible to create additional datasets: > >> > >> $ makefs -t zfs -s 10g -o poolname=3Dtest -o fs=3Dtest/ds1:mountpoint= =3D/test/dir1 ./zfs.img /path/to/input > >> > >> The parameter syntax is > >> "-o fs=3D[:=3D[:=3D[:...]]]". = Only a > >> few properties are supported, at least for now. > >> > >> Dataset mountpoints behave the same as they would if created with the > >> standard ZFS tools. So by default the root dataset's mountpoint is > >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrid= es > >> its default mountpoint, its children inherit that mountpoint. > >> > >> makefs builds the output filesystem using a single input directory tre= e. > >> Thus, makefs -t zfs requires that at least one of the dataset's > >> mountpoints map to /path/to/input; that is, there is a "root" mount > >> point. > >> > >> The -o rootpath parameter defines this root mount point. By default i= t's > >> "/". All datasets in the pool must have their mountpoints > >> under this path, and one dataset's mountpoint must be equal to this > >> path. To build bootable images, one sets -o rootpath=3D/. > >> > >> Putting it all together, one can build a image using the standard layo= ut > >> with an invocation like this: > >> > >> makefs -t zfs -o poolname=3Dzroot -s 20g -o rootpath=3D/ -o bootfs=3Dz= root/ROOT/default \ > >> -o fs=3Dzroot:canmount=3Doff:mountpoint=3Dnone \ > >> -o fs=3Dzroot/ROOT:mountpoint=3Dnone \ > >> -o fs=3Dzroot/ROOT/default:mountpoint=3D/ \ > >> -o fs=3Dzroot/tmp:mountpoint=3D/tmp:exec=3Don:setuid=3Doff \ > >> -o fs=3Dzroot/usr:mountpoint=3D/usr:canmount=3Doff \ > >> -o fs=3Dzroot/usr/home \ > >> -o fs=3Dzroot/usr/ports:setuid=3Doff \ > >> -o fs=3Dzroot/usr/src \ > >> -o fs=3Dzroot/usr/obj \ > >> -o fs=3Dzroot/var:mountpoint=3D/var:canmount=3Doff \ > >> -o fs=3Dzroot/var/audit:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/crash:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/log:setuid=3Doff:exec=3Doff \ > >> -o fs=3Dzroot/var/mail:atime=3Don \ > >> -o fs=3Dzroot/var/tmp:setuid=3Doff \ > >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world > >> > >> I'll admit this is somewhat clunky, but it doesn't seem worse than what > >> we have to do otherwise, see poudriere-image for example: > >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/i= mage_zfs.sh#L79 > >> > >> What do folks think of this interface? Is there anything missing, or > >> anything that doesn't make sense? > >=20 > > I find it slightly confusing that -o options have a default namespace of > > pool options unless they have an fs=3D*: prefix, but making users type > > "pool:" for other options doesn't seem to make sense so this is probably > > the best solution. > >=20 > > The density of data in the filesystem specification does suggest that > > someone might want to create a UCL config file format eventually, but > > what's here already seems entirely workable. > >=20 > > -- Brooks >=20 > In normal `zpool create` they use -o for pool properties, and -O for=20 > dataset properties for the root dataset. I wonder if we might also want= =20 > -o poolprop=3Dvalue and -O zroot/var:mountpoint=3D/var:canmount=3Doff >=20 > just to avoid the conceptual collision of those 2 different items. Sadly -O is taken in makefs. > One other possible issue: dataset properties can have a : in them, for=20 > user-defined properties. Do we maybe want to use a , to separate them=20 > instead? Although values can contain ,'s (the sharenfs property often=20 > does), so that probably doesn't work either. One solution would be to allow the same fs=3Dfoo: to be specified multiple times (I've not checked if the current code allows this) to add options instead of having a separator. That does make the command line even more clunky though. -- Brooks --ed/6oDxOLijJh8b0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJihoubAAoJEKzQXbSebgfAZKUIAIth64pe7VjTgkOPXoakQ9VL D+oZRbZe78wL9hLiqSYLdGWMyZUO4lcw6QkQXdGKDit+ohT2JxqRTh8eUfjggbCx B7uuc2zh99LxNgGc1XLlXctM6/2bBGzHiciBdmQ9aDk6jnXc+EMn8Eux5F/kVaRo qZif3neBVmWtnTpmy8R08OdVLW5ZFMj0JVD9jNd3sAtp1Kf9BK7RSymbbYj/ZCxl zHOvWULi2tSo/pqV+9cJlFgWxm7cvjYvmcAmSUmel1ZtduGNU+krAy4751jbGPk0 h7k/fwi0pJrGL1A3352x7eMTrVqggyotPAubzkHtFTdGPZcM+qR4U/TdPWc2gzk= =n4bd -----END PGP SIGNATURE----- --ed/6oDxOLijJh8b0-- From nobody Fri May 20 12:37:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 09CF91B3D486 for ; Fri, 20 May 2022 12:37:14 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4R7X6Jf6z4sdk; Fri, 20 May 2022 12:37:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-111-80.area1b.commufa.jp [123.1.111.80]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 24KCb2DT073432; Fri, 20 May 2022 21:37:02 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 20 May 2022 21:37:01 +0900 From: Tomoaki AOKI To: Brooks Davis Cc: Allan Jude , Mark Johnston , freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-Id: <20220520213701.73a826e711b58a1799006825@dec.sakura.ne.jp> In-Reply-To: <20220519182532.GJ15201@spindle.one-eyed-alien.net> References: <20220518230427.GI15201@spindle.one-eyed-alien.net> <20220519182532.GJ15201@spindle.one-eyed-alien.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L4R7X6Jf6z4sdk X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-0.37 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.35)[-0.355]; NEURAL_HAM_SHORT(-0.41)[-0.412]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.111.80:received] X-ThisMailContainsUnwantedMimeParts: N On Thu, 19 May 2022 18:25:32 +0000 Brooks Davis wrote: > On Thu, May 19, 2022 at 01:36:25PM -0400, Allan Jude wrote: > > On 5/18/2022 7:04 PM, Brooks Davis wrote: > > > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > > >> Hi, > > >> > > >> For the past little while I've been working on ZFS support in makefs(8). > > >> At this point I'm able to create a bootable FreeBSD VM image, using the > > >> standard FreeBSD ZFS layout, and run through the regression test suite > > >> in bhyve. I've also been able to create and boot an EC2 AMI. > > > > > > Very cool! > > > > > >> === Interface === > > >> > > >> Creating a pool with a single dataset is easy: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input > > >> > > >> Upon importing such a pool, you'll get a dataset named "test" mounted at > > >> /test containing everything under /path/to/input. > > >> > > >> It's possible to set properties on the root dataset: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input > > >> > > >> It's also possible to create additional datasets: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input > > >> > > >> The parameter syntax is > > >> "-o fs=[:=[:=[:...]]]". Only a > > >> few properties are supported, at least for now. > > >> > > >> Dataset mountpoints behave the same as they would if created with the > > >> standard ZFS tools. So by default the root dataset's mountpoint is > > >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > > >> its default mountpoint, its children inherit that mountpoint. > > >> > > >> makefs builds the output filesystem using a single input directory tree. > > >> Thus, makefs -t zfs requires that at least one of the dataset's > > >> mountpoints map to /path/to/input; that is, there is a "root" mount > > >> point. > > >> > > >> The -o rootpath parameter defines this root mount point. By default it's > > >> "/". All datasets in the pool must have their mountpoints > > >> under this path, and one dataset's mountpoint must be equal to this > > >> path. To build bootable images, one sets -o rootpath=/. > > >> > > >> Putting it all together, one can build a image using the standard layout > > >> with an invocation like this: > > >> > > >> makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ > > >> -o fs=zroot:canmount=off:mountpoint=none \ > > >> -o fs=zroot/ROOT:mountpoint=none \ > > >> -o fs=zroot/ROOT/default:mountpoint=/ \ > > >> -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ > > >> -o fs=zroot/usr:mountpoint=/usr:canmount=off \ > > >> -o fs=zroot/usr/home \ > > >> -o fs=zroot/usr/ports:setuid=off \ > > >> -o fs=zroot/usr/src \ > > >> -o fs=zroot/usr/obj \ > > >> -o fs=zroot/var:mountpoint=/var:canmount=off \ > > >> -o fs=zroot/var/audit:setuid=off:exec=off \ > > >> -o fs=zroot/var/crash:setuid=off:exec=off \ > > >> -o fs=zroot/var/log:setuid=off:exec=off \ > > >> -o fs=zroot/var/mail:atime=on \ > > >> -o fs=zroot/var/tmp:setuid=off \ > > >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world > > >> > > >> I'll admit this is somewhat clunky, but it doesn't seem worse than what > > >> we have to do otherwise, see poudriere-image for example: > > >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 > > >> > > >> What do folks think of this interface? Is there anything missing, or > > >> anything that doesn't make sense? > > > > > > I find it slightly confusing that -o options have a default namespace of > > > pool options unless they have an fs=*: prefix, but making users type > > > "pool:" for other options doesn't seem to make sense so this is probably > > > the best solution. > > > > > > The density of data in the filesystem specification does suggest that > > > someone might want to create a UCL config file format eventually, but > > > what's here already seems entirely workable. > > > > > > -- Brooks > > > > In normal `zpool create` they use -o for pool properties, and -O for > > dataset properties for the root dataset. I wonder if we might also want > > -o poolprop=value and -O zroot/var:mountpoint=/var:canmount=off > > > > just to avoid the conceptual collision of those 2 different items. > > Sadly -O is taken in makefs. > > > One other possible issue: dataset properties can have a : in them, for > > user-defined properties. Do we maybe want to use a , to separate them > > instead? Although values can contain ,'s (the sharenfs property often > > does), so that probably doesn't work either. > > One solution would be to allow the same fs=foo: to be specified multiple > times (I've not checked if the current code allows this) to add options > instead of having a separator. That does make the command line even more > clunky though. > > -- Brooks Just an idea, what about moving partitioning (create pool) functionality to sbin/gpart, keeping relatively common functionality for datasets on /usr/sbin/makefs as primary proposal, and create, for example, /usr/sbin/makefs_zfs for complicated, ZFS-only functionalities. It would look like gpart / mount / mount_* on other supported fs. And keeps common makefs simper. IIRC, some fs-specific mount_* have extended functionality, that `mount -t (fstype)` does not support. -- Tomoaki AOKI From nobody Fri May 20 16:35:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 269841AE7870 for ; Fri, 20 May 2022 16:35:37 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4XQc0zxlz4Twc; Fri, 20 May 2022 16:35:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x730.google.com with SMTP id v11so7312041qkf.1; Fri, 20 May 2022 09:35:36 -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=xYwmouT0CmVvLHmTVnU4uDnlJZVK6IlxKIiS7jvaFEQ=; b=eBWFK757nZE2oZtQ2Xwxu7kxmOC+76ModpkFpU74En998oTSUmKKXR98RJS8FNVN7n ZQZfIFCU0GvvniTsaCCNv44AyAdcvfH+VF8EDaHrkW07t6sZfHBeZ/jNvLXl3uyDV2iQ e9nHuhrmvlCaJBGQaP5tpHkuxaeWQIU5SZj/jLt0jnrmLAj2CnF/lz3syKPBEfEUOyOn SUzYl7opwzbmzdKwAzsqjhr1tvEKAzVW10wDHM4QX3w/XV5IAKJo6UKEJQ9BCtsGUb42 o8pT0LfLC02JnW1/VUoJm3dWdiMMSioXDwO88OwmoRFxLIWePcLni8KXjAhe6EXdQBmJ k1Vw== 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=xYwmouT0CmVvLHmTVnU4uDnlJZVK6IlxKIiS7jvaFEQ=; b=dUdwOwmgyZxfZm5AdLLUZV1sQT/CII5FuHskFIwyHUvrz7DgDFUd6mSFni+QBY+2DD q1baLd0qzYCmCnJGk6Gpx3gOYDc4koumEikGswykn0kb77R4ZbMLFHmsPRh2XnWU8ncm gkpaZOeoWQo7sZaZ7Rv/GKE34G8Hdj884Mba3EntiqNCX/DRvNaR9g5gihv2rjtS9ol5 pLGSbfn0QhzQU7Ze7edp9/yCuprKzHkCMHgAzqYyv46ntlzAxBkF2peZeAmwZmN8F4EZ aeE7/n3vAT055UlsegdTmQEXbfAZ4nQmrojk35/Yy11rgUe1Ya0k/iN86fWpJzwSvYS2 gY5g== X-Gm-Message-State: AOAM5304ApXzclPGIrgj1QT6vgkQVq+5Vdr6Z1CGhHSQTlvlW32rCNhK xjjc5m0DvY/mewM9GF1upatxU8oB30c= X-Google-Smtp-Source: ABdhPJw3i+eQNofw+Dfv/jYHzpFr0bXGtskmxUC9dJX2ycEqv8Agvcg6Zs/XZBtFg11c+TGskaBlXQ== X-Received: by 2002:ae9:e842:0:b0:69f:c3ea:8233 with SMTP id a63-20020ae9e842000000b0069fc3ea8233mr6769919qkg.320.1653064529095; Fri, 20 May 2022 09:35:29 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id h127-20020a376c85000000b006a10aa7908dsm2365954qkc.38.2022.05.20.09.35.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 09:35:28 -0700 (PDT) Date: Fri, 20 May 2022 12:35:25 -0400 From: Mark Johnston To: Brooks Davis Cc: Allan Jude , freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: References: <20220518230427.GI15201@spindle.one-eyed-alien.net> <20220519182532.GJ15201@spindle.one-eyed-alien.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220519182532.GJ15201@spindle.one-eyed-alien.net> X-Rspamd-Queue-Id: 4L4XQc0zxlz4Twc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=eBWFK757; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::730 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Thu, May 19, 2022 at 06:25:32PM +0000, Brooks Davis wrote: > On Thu, May 19, 2022 at 01:36:25PM -0400, Allan Jude wrote: > > On 5/18/2022 7:04 PM, Brooks Davis wrote: > > > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > > >> Hi, > > >> > > >> For the past little while I've been working on ZFS support in makefs(8). > > >> At this point I'm able to create a bootable FreeBSD VM image, using the > > >> standard FreeBSD ZFS layout, and run through the regression test suite > > >> in bhyve. I've also been able to create and boot an EC2 AMI. > > > > > > Very cool! > > > > > >> === Interface === > > >> > > >> Creating a pool with a single dataset is easy: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input > > >> > > >> Upon importing such a pool, you'll get a dataset named "test" mounted at > > >> /test containing everything under /path/to/input. > > >> > > >> It's possible to set properties on the root dataset: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input > > >> > > >> It's also possible to create additional datasets: > > >> > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input > > >> > > >> The parameter syntax is > > >> "-o fs=[:=[:=[:...]]]". Only a > > >> few properties are supported, at least for now. > > >> > > >> Dataset mountpoints behave the same as they would if created with the > > >> standard ZFS tools. So by default the root dataset's mountpoint is > > >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > > >> its default mountpoint, its children inherit that mountpoint. > > >> > > >> makefs builds the output filesystem using a single input directory tree. > > >> Thus, makefs -t zfs requires that at least one of the dataset's > > >> mountpoints map to /path/to/input; that is, there is a "root" mount > > >> point. > > >> > > >> The -o rootpath parameter defines this root mount point. By default it's > > >> "/". All datasets in the pool must have their mountpoints > > >> under this path, and one dataset's mountpoint must be equal to this > > >> path. To build bootable images, one sets -o rootpath=/. > > >> > > >> Putting it all together, one can build a image using the standard layout > > >> with an invocation like this: > > >> > > >> makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ > > >> -o fs=zroot:canmount=off:mountpoint=none \ > > >> -o fs=zroot/ROOT:mountpoint=none \ > > >> -o fs=zroot/ROOT/default:mountpoint=/ \ > > >> -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ > > >> -o fs=zroot/usr:mountpoint=/usr:canmount=off \ > > >> -o fs=zroot/usr/home \ > > >> -o fs=zroot/usr/ports:setuid=off \ > > >> -o fs=zroot/usr/src \ > > >> -o fs=zroot/usr/obj \ > > >> -o fs=zroot/var:mountpoint=/var:canmount=off \ > > >> -o fs=zroot/var/audit:setuid=off:exec=off \ > > >> -o fs=zroot/var/crash:setuid=off:exec=off \ > > >> -o fs=zroot/var/log:setuid=off:exec=off \ > > >> -o fs=zroot/var/mail:atime=on \ > > >> -o fs=zroot/var/tmp:setuid=off \ > > >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world > > >> > > >> I'll admit this is somewhat clunky, but it doesn't seem worse than what > > >> we have to do otherwise, see poudriere-image for example: > > >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 > > >> > > >> What do folks think of this interface? Is there anything missing, or > > >> anything that doesn't make sense? > > > > > > I find it slightly confusing that -o options have a default namespace of > > > pool options unless they have an fs=*: prefix, but making users type > > > "pool:" for other options doesn't seem to make sense so this is probably > > > the best solution. > > > > > > The density of data in the filesystem specification does suggest that > > > someone might want to create a UCL config file format eventually, but > > > what's here already seems entirely workable. > > > > > > -- Brooks > > > > In normal `zpool create` they use -o for pool properties, and -O for > > dataset properties for the root dataset. I wonder if we might also want > > -o poolprop=value and -O zroot/var:mountpoint=/var:canmount=off > > > > just to avoid the conceptual collision of those 2 different items. > > Sadly -O is taken in makefs. Though, -O is already not supported for all filesystem types (cd9660 in particular). I'm not sure whether -O is at all useful anymore now that we have mkimg(1): I presume that -O is useful when you already have a partitioned disk image and want to fill in one of the partitions with a filesystem. There's a suggestion in the thread of having multiple hardlinks of makefs; we could add a makefs_zfs which handles -O as Allan suggests. > > One other possible issue: dataset properties can have a : in them, for > > user-defined properties. Do we maybe want to use a , to separate them > > instead? Although values can contain ,'s (the sharenfs property often > > does), so that probably doesn't work either. > > One solution would be to allow the same fs=foo: to be specified multiple > times (I've not checked if the current code allows this) to add options > instead of having a separator. That does make the command line even more > clunky though. The current code won't allow this, but it would be easy to add of course. Maybe we should support both modes. Or maybe the real solution is to introduce a UCL configuration format and keep the command-line interface simple. I didn't think about this much yet since makefs currently doesn't support setting arbitrary properties, just those few that I need to build FreeBSD images. I guess I'd want to see some specific use-cases for specifying additional dataset/pool properties before deciding what to do. From nobody Fri May 20 17:35:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 30DD61B3C201 for ; Fri, 20 May 2022 17:36:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L4YmQ2tRtz4qJG; Fri, 20 May 2022 17:36:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id l82so2697109qke.3; Fri, 20 May 2022 10:36:06 -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=GL5dkYnqsD9PNpwvU+s5rO8isuwbJ+6+IXQtSCkTd60=; b=X6Bj76WHNy6KQh6G9u3Rpplm6zjsqR8HXnou5TbBZeelQ150YeYzBWQzrxOJRFJuf6 JGg6X5jXmb6pDwRRBdPk6Q8TFoZWQCoAgSLetU6TTE6ADMekS9ajkxzzsqA6G2K0eJ9P kOT96K1HznZpght8N8RmC5FVMa/k/QVTz49YVANklFEBt7ZvZycsQ+k7WLyeXN5YZQiq WZgSbzPFR6U4vsmcgRi3SMO6jvHYq8J70zqHWSvEEPSedO6oTVzXJQsu2gUhZNesXsfO FqMxkE0mE4IalUph7C825NoJhjI/aI8gMHGS8WqOi1BplsAWaJ7pBHZ5PSSnYKx9Ju/n vrjQ== 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=GL5dkYnqsD9PNpwvU+s5rO8isuwbJ+6+IXQtSCkTd60=; b=BnC0cAVQ3Af1NBMnypkgQn3FSkqZKO7TZdfR0LPXfGZDi20eZGPbNpknP4f9IP0F+s VMdRrHRhgCt0AfhF8igt7emfmCuZ5JVduzbJ3Y5wZm6vJHAECIuaukBaUjb3QRqBHD9S duRZBa7YvLG70XQJVLXoXs66esTAbRVhsmPW4yEo0vZoCznRU+s3cMK+n9LoSRWYeBn7 IkLM04pP7FQmeA0VgXFVOJXCS8OBRUcOyy+MTT5+U/WOR17LV1GHvU5T58457bcLNtrc 7pTeaLxcMX2TrJeUG/GgwQ8avHp2f0fqlMqmlx1wMEjNUDfDUE+T2PQyFuY3NY31qkrd ci1g== X-Gm-Message-State: AOAM530kZ+stP3MxMk1EymkdbDXhY+thbMYm/ZxqInFIZpbBUItOATMp MvNr7ZF0REAFi1/JMkn+GfyFH0xu+q0= X-Google-Smtp-Source: ABdhPJws6TpVPWnQ4LIM3NZFySsjdHlhsLGP9B/Er0VKMFE7L3rjke9DRx4Hq//WxxmhcylPp8uMog== X-Received: by 2002:a05:620a:472a:b0:6a0:23f0:6a64 with SMTP id bs42-20020a05620a472a00b006a023f06a64mr7010889qkb.534.1653068159645; Fri, 20 May 2022 10:35:59 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id d202-20020a379bd3000000b0069fc13ce1fcsm44697qke.45.2022.05.20.10.35.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 10:35:58 -0700 (PDT) Date: Fri, 20 May 2022 13:35:56 -0400 From: Mark Johnston To: Tomoaki AOKI Cc: Brooks Davis , Allan Jude , freebsd-hackers@freebsd.org Subject: Re: zfs support in makefs Message-ID: References: <20220518230427.GI15201@spindle.one-eyed-alien.net> <20220519182532.GJ15201@spindle.one-eyed-alien.net> <20220520213701.73a826e711b58a1799006825@dec.sakura.ne.jp> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220520213701.73a826e711b58a1799006825@dec.sakura.ne.jp> X-Rspamd-Queue-Id: 4L4YmQ2tRtz4qJG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=X6Bj76WH; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::731 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Fri, May 20, 2022 at 09:37:01PM +0900, Tomoaki AOKI wrote: > On Thu, 19 May 2022 18:25:32 +0000 > Brooks Davis wrote: > > > On Thu, May 19, 2022 at 01:36:25PM -0400, Allan Jude wrote: > > > On 5/18/2022 7:04 PM, Brooks Davis wrote: > > > > On Wed, May 18, 2022 at 03:03:17PM -0400, Mark Johnston wrote: > > > >> Hi, > > > >> > > > >> For the past little while I've been working on ZFS support in makefs(8). > > > >> At this point I'm able to create a bootable FreeBSD VM image, using the > > > >> standard FreeBSD ZFS layout, and run through the regression test suite > > > >> in bhyve. I've also been able to create and boot an EC2 AMI. > > > > > > > > Very cool! > > > > > > > >> === Interface === > > > >> > > > >> Creating a pool with a single dataset is easy: > > > >> > > > >> $ makefs -t zfs -s 10g -o poolname=test ./zfs.img /path/to/input > > > >> > > > >> Upon importing such a pool, you'll get a dataset named "test" mounted at > > > >> /test containing everything under /path/to/input. > > > >> > > > >> It's possible to set properties on the root dataset: > > > >> > > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test:setuid=off:atime=on ./zfs.img /path/to/input > > > >> > > > >> It's also possible to create additional datasets: > > > >> > > > >> $ makefs -t zfs -s 10g -o poolname=test -o fs=test/ds1:mountpoint=/test/dir1 ./zfs.img /path/to/input > > > >> > > > >> The parameter syntax is > > > >> "-o fs=[:=[:=[:...]]]". Only a > > > >> few properties are supported, at least for now. > > > >> > > > >> Dataset mountpoints behave the same as they would if created with the > > > >> standard ZFS tools. So by default the root dataset's mountpoint is > > > >> /test, test/ds1's mountpoint is /test/ds1, etc.. If a dataset overrides > > > >> its default mountpoint, its children inherit that mountpoint. > > > >> > > > >> makefs builds the output filesystem using a single input directory tree. > > > >> Thus, makefs -t zfs requires that at least one of the dataset's > > > >> mountpoints map to /path/to/input; that is, there is a "root" mount > > > >> point. > > > >> > > > >> The -o rootpath parameter defines this root mount point. By default it's > > > >> "/". All datasets in the pool must have their mountpoints > > > >> under this path, and one dataset's mountpoint must be equal to this > > > >> path. To build bootable images, one sets -o rootpath=/. > > > >> > > > >> Putting it all together, one can build a image using the standard layout > > > >> with an invocation like this: > > > >> > > > >> makefs -t zfs -o poolname=zroot -s 20g -o rootpath=/ -o bootfs=zroot/ROOT/default \ > > > >> -o fs=zroot:canmount=off:mountpoint=none \ > > > >> -o fs=zroot/ROOT:mountpoint=none \ > > > >> -o fs=zroot/ROOT/default:mountpoint=/ \ > > > >> -o fs=zroot/tmp:mountpoint=/tmp:exec=on:setuid=off \ > > > >> -o fs=zroot/usr:mountpoint=/usr:canmount=off \ > > > >> -o fs=zroot/usr/home \ > > > >> -o fs=zroot/usr/ports:setuid=off \ > > > >> -o fs=zroot/usr/src \ > > > >> -o fs=zroot/usr/obj \ > > > >> -o fs=zroot/var:mountpoint=/var:canmount=off \ > > > >> -o fs=zroot/var/audit:setuid=off:exec=off \ > > > >> -o fs=zroot/var/crash:setuid=off:exec=off \ > > > >> -o fs=zroot/var/log:setuid=off:exec=off \ > > > >> -o fs=zroot/var/mail:atime=on \ > > > >> -o fs=zroot/var/tmp:setuid=off \ > > > >> ${HOME}/tmp/zfs.img ${HOME}/tmp/world > > > >> > > > >> I'll admit this is somewhat clunky, but it doesn't seem worse than what > > > >> we have to do otherwise, see poudriere-image for example: > > > >> https://github.com/freebsd/poudriere/blob/master/src/share/poudriere/image_zfs.sh#L79 > > > >> > > > >> What do folks think of this interface? Is there anything missing, or > > > >> anything that doesn't make sense? > > > > > > > > I find it slightly confusing that -o options have a default namespace of > > > > pool options unless they have an fs=*: prefix, but making users type > > > > "pool:" for other options doesn't seem to make sense so this is probably > > > > the best solution. > > > > > > > > The density of data in the filesystem specification does suggest that > > > > someone might want to create a UCL config file format eventually, but > > > > what's here already seems entirely workable. > > > > > > > > -- Brooks > > > > > > In normal `zpool create` they use -o for pool properties, and -O for > > > dataset properties for the root dataset. I wonder if we might also want > > > -o poolprop=value and -O zroot/var:mountpoint=/var:canmount=off > > > > > > just to avoid the conceptual collision of those 2 different items. > > > > Sadly -O is taken in makefs. > > > > > One other possible issue: dataset properties can have a : in them, for > > > user-defined properties. Do we maybe want to use a , to separate them > > > instead? Although values can contain ,'s (the sharenfs property often > > > does), so that probably doesn't work either. > > > > One solution would be to allow the same fs=foo: to be specified multiple > > times (I've not checked if the current code allows this) to add options > > instead of having a separator. That does make the command line even more > > clunky though. > > > > -- Brooks > > Just an idea, what about moving partitioning (create pool) > functionality to sbin/gpart, keeping relatively common functionality > for datasets on /usr/sbin/makefs as primary proposal, and create, > for example, /usr/sbin/makefs_zfs for complicated, ZFS-only > functionalities. I think splitting ZFS pool creation into a separate tool would introduce some challenges; makefs would have to learn to read pool/vdev metadata and respect whatever properties that are set. Putting everything in one tool is simpler. gpart also doesn't seem like the right place, since one would typically use mkimg(1) to build a GPT. > It would look like gpart / mount / mount_* on other supported fs. > And keeps common makefs simper. > > IIRC, some fs-specific mount_* have extended functionality, that > `mount -t (fstype)` does not support. I like the idea of having a makefs_zfs since that would give us a new option namespace. From eugen@grosbein.net Sat May 21 10:33:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 08DCE1B45922 for ; Sat, 21 May 2022 10:33:46 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L50Lc6bv1z4rWB for ; Sat, 21 May 2022 10:33:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 24LAXZAk010980 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 21 May 2022 10:33:35 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 24LAXYsg037481 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 21 May 2022 17:33:34 +0700 (+07) (envelope-from eugen@grosbein.net) To: Freebsd hackers list From: Eugene Grosbein Subject: kernel stack abuse Message-ID: <759b17ce-b2a1-4f95-f33e-6af546552831@grosbein.net> Date: Sat, 21 May 2022 17:33:12 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4L50Lc6bv1z4rWB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [0.43 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.35)[-0.346]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[grosbein.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.88)[0.878]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! Nearly five years ago I performed small examination of binary code produced building 32 bits FreeBSD i386 kernel and found some functions that abused stack with large structures: https://lists.freebsd.org/pipermail/svn-src-head/2017-December/107294.html Now I updated old script for llvm-objdump and ran it for 13.1-STABLE/amd64 GENERIC kernel and found it went much worse. The script: #!/bin/sh dir=/usr/obj/usr/src/amd64.amd64/sys/GENERIC objdump=llvm-objdump set -e cd $dir for o in *.o do $objdump -d $o | awk -vn=$o ' /subq?.*, ?%[er]sp/ { split ($(NF-1),a,/[,$]/); printf "%u %s %s\n", a[2], a[2], n }' done | sort -rn > top.sub head -50 top.sub | while read d h o do $objdump -d $o | egrep -B8 "subq?.*$h, ?%[er]sp" |\ awk -vo=$o -vd=$d '/>:$/ {print d, o, $2}' done > top2.sub EOF Results: 33296 fse_decompress.o : 21024 fse_decompress.o : 18456 huf_decompress.o : 18456 huf_decompress.o : 18456 huf_decompress.o : 18456 huf_decompress.o : 14352 fse_compress.o : 14352 fse_compress.o : 14352 fse_compress.o : 14352 fse_compress.o : 10264 huf_decompress.o : 10264 huf_decompress.o : 10264 huf_decompress.o : 10264 huf_decompress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 6400 huf_compress.o : 4632 in6_proto.o : 4352 huf_compress.o : 4168 ixl_pf_main.o : 4136 ck_rhs.o : 4112 fse_compress.o : 4104 hist.o : 4096 hist.o : 3320 in6_proto.o : 2264 md_ddf.o : 2200 ip6_output.o : 2120 ar9300_eeprom.o : 2104 rt2860.o : 2088 rt2860.o : 2064 huf_decompress.o : 2064 huf_decompress.o : 2064 huf_decompress.o : 2064 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2056 huf_decompress.o : 2048 huf_decompress.o : 2048 huf_decompress.o : 2048 huf_decompress.o : 2048 huf_decompress.o : 1880 kern_proc.o : 1816 blkback.o : 1672 zstd_compress.o : 1576 fse_compress.o : 1496 scsi_sa.o : 1496 nfs_nfsdserv.o : 1480 uipc_shm.o : 1448 ar9300_paprd.o : 1432 scsi_enc_ses.o : 1416 xgbe-sysctl.o : 1352 fortuna.o : First column shows stack usage in bytes (decimal), then come module name and function name in question. For example, sys/contrib/zstd/lib/common/fse_decompress.c, function FSE_buildDTable() allocates over 32KB on stack. I wonder how it is supposed to run with default kern.kstack_pages=4 that should be 16KB? From nobody Sat May 21 11:58:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 111D81B35F7D for ; Sat, 21 May 2022 11:58:40 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L52DZ5c2yz3J8r for ; Sat, 21 May 2022 11:58:38 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=email1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version: Content-Type:Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CqydEIo9kcjUbw0rTTffo0U+ypagDetiWWb+VgMEmTs=; b=LSC4NhOZisBydCGG9619R7Am5z BSzOIhir5b74SA1bja5bK7oXvaRYeAlvZjSI0mpu0jpuDR2r7gTmPN56Viilp4iAYiKCVNrb5h6Lg Xk9roklOLu+DtPMsyCn1NrOm0eCtFCAHjC+7xBS7637uw1Y0ydMciIqQcGDrRXVBkZUUaY7o7Cct6 imYi17HrBJReY9pFehNHttvoPTwTBU5BYoIMLIYlckVTt0Z+ItGFYPKszA9sdce+9eW0aMG76NBH+ 5i2wlaFH/msK66+Dt9X0IeYujhjJT8Bgtyb44/darIFJmLwUyV43PUOnhWQToNmmVs8kONlD3oyFu HqK6lwJw==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1nsNkb-0005DN-8x; Sat, 21 May 2022 11:58:29 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1653134308-64998-63502/7/2; Sat, 21 May 2022 11:58:28 +0000 From: Axel Rau Message-Id: <772ECD57-2322-4FF9-B5A4-D10D8795D32E@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_BE46956C-9762-4CE3-B0E1-8591837FAA66" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: rc script to let a service wait for db available Date: Sat, 21 May 2022 13:58:27 +0200 In-Reply-To: Cc: Eugene Grosbein To: freebsd-hackers@freebsd.org References: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4L52DZ5c2yz3J8r X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=email1 header.b=LSC4NhOZ; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=email1]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[chaos1.de]; NEURAL_SPAM_SHORT(0.41)[0.410]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; RCPT_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[chaos1.de:dkim]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:5::73:from] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_BE46956C-9762-4CE3-B0E1-8591837FAA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Changing this to: - - - meteoavg_start() { /usr/local/bin/wait_for_pgsql.sh ${meteoavg_wfphost} ${meteoavg_wfpus= er} ${meteoavg_wfpdb} "/usr/local/bin/${name} ${meteoavg_flags}" & } - - - does not solve the issue.=20 On system boot this script still blocks rc and prevents any other = services from being started, including the the jail with the pgsql server, where wait_for_pgsql.sh = tries to connect. > Am 27.04.2022 um 16:37 schrieb Eugene Grosbein : >=20 > 27.04.2022 21:30, Axel Rau wrote: >> Hi all, >>=20 >> I have this rc script: >> - - - >> meteoavg_wfphost=3D"dbb3" >> meteoavg_wfpuser=3D"meteo" >> meteoavg_wfpdb=3D"operations" >> # >> # >>=20 >> . /etc/rc.subr >>=20 >> name=3D"meteoavg" >> rcvar=3D${name}_enable >> command=3D/usr/local/bin/meteoavg >>=20 >> load_rc_config $name >>=20 >> : ${meteoavg_enable=3D"NO"} >> : ${meteoavg_flags=3D" -l syslog:daemon -s Chaos1"} >>=20 >> : ${meteoavg_pidfile=3D"/var/run/meteoavg-Chaos1.pid"} >>=20 >> pidfile=3D"${meteoavg_pidfile}" >>=20 >> ##start_cmd=3D"${name}_start" >> stop_precmd=3D"${name}_prestop" >>=20 >> meteoavg_start() { >> /usr/local/bin/wait_for_pgsql.sh ${meteoavg_wfphost} \ >> ${meteoavg_wfpuser} ${meteoavg_wfpdb} \ >> "/usr/local/bin/${name} ${meteoavg_flags} &" >> } >=20 >> - - - >> The rc ignores the '&' and waits for wait_for_pgsql.sh to complete. >>=20 >> How can I let rc continue without waiting? >=20 > You need to place '&' outside of double-quotes. > But better use daemon(8) command instead of '&' > because daemon does better job ignoring signals etc. > and that may be important if wait time extends past point when system = goes to multiuser mode. >=20 Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_BE46956C-9762-4CE3-B0E1-8591837FAA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Changing this = to:
- - -
meteoavg_st= art() {
    /usr/local/bin/wait_for_pgsql.= sh ${meteoavg_wfphost} ${meteoavg_wfpuser} ${meteoavg_wfpdb} "/usr/local/= bin/${name} ${meteoavg_flags}" &
}
- - -
does not solve the issue. 
On system boot this script still blocks rc and = prevents any other services from being started,
incl= uding the the jail with the pgsql server, where wait_for_pgsql.sh tries = to connect.



Am 27.04.2022 um 16:37 schrieb Eugene = Grosbein <eugen@grosb= ein.net>:

27.04.2022 21:30, Axel Rau wrote:
Hi all,

I have this rc script:
- - -
meteo= avg_wfphost=3D"dbb3"
meteoavg_wfpuser=3D"meteo"
meteoavg_wfpdb=3D"operations"
#
#<= br class=3D"">
. /etc/rc.subr

= name=3D"meteoavg"
rcvar=3D${name}_enable
comm= and=3D/usr/local/bin/meteoavg

load_rc_config= $name

: ${meteoavg_enable=3D"NO"}
: ${meteoavg_flags=3D" -l syslog:daemon -s Chaos1"}

: ${meteoavg_pidfile=3D"/var/run/meteoavg-Chaos= 1.pid"}

pidfile=3D"${meteoavg_pidfile}"

##start_cmd=3D"${name}_start"
sto= p_precmd=3D"${name}_prestop"

meteoavg_start(= ) {
   /usr/local/bin/wait_for_pgsql.sh = ${meteoavg_wfphost} \
    ${meteoavg_w= fpuser} ${meteoavg_wfpdb} \
   "/usr/local/= bin/${name} ${meteoavg_flags} &"
}

- - -
The rc ignores the '&' and waits for wait_for_pgsql.sh to = complete.

How can I let rc continue without = waiting?

You need to place = '&' outside of double-quotes.
But better use daemon(8) = command instead of '&'
because daemon does better job = ignoring signals etc.
and that may be important if wait = time extends past point when system goes to multiuser mode.


Axel
---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_BE46956C-9762-4CE3-B0E1-8591837FAA66-- From nobody Sun May 22 11:18:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3A87B1AEFBD4 for ; Sun, 22 May 2022 11:20:06 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5dKd1N8Kz3kHH for ; Sun, 22 May 2022 11:20:05 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id k30so17158577wrd.5 for ; Sun, 22 May 2022 04:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=AWPHMfWFBtkoxjIz42MOmtd0uaSI6uFTPRlkc4asCcI=; b=Noxp4ceimh13teRexfedEfAaGbUS/bvOSKn6LtUg4ijLqbpU8H3pOh78hEfVXXeYMO m7EU2hSKtXlxtToTvG1hDXMLt/aC8qcDdHTohuTJh3kVsxvYzSaAxrjb5wKo4vN6zxB9 IssW+ptnytD37e0o04BnlFw1Ohbis9YY4rygJBIch8O8z5pFr4IKiRjWd/GUaUJBmhmf BTLoRl9QbejGjD0ubJ/M7bviLBIHWD/R4mdrNrhOVvPOyvBwNX4LU4z53gpSuEMLJg63 rAOjyCl0kbcLZeTzLdBxQmkGk9hWYsSdfmu7D0YU5Qel889kzdONwUV1m2nNJbn/GptW x8HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=AWPHMfWFBtkoxjIz42MOmtd0uaSI6uFTPRlkc4asCcI=; b=6mAD43VoE9fXnoMXhaUQel5wxW3u/isnv21dfw6ynFCTSQt+20FwW2QXU3kxPSYg5j X6FsDt4UKn4fPkrO5O4c5nTfAO6ALbkFIxjHU07I15iK4eCsLp6QtfdKrQFzLm2Bj5wI nSaHWTNdCZ0QAo3z0lh8dU/Xv6fwiUShg6RsS/1LfS3PM9baK8LR+7V9s1H+3/eyknCa m0T5VJJubDV5izBQvf+7e7RP3HG/cvQGdGDYb5GNGYzNrHDPsDsOXsVNfVr3eboo+pJH wef++ykxc5wXk1MScek+Vjwo3hAe0XCONKWYF/LukEcNgq8oFSNzCmjoFLUX9bcOit2y sBeQ== X-Gm-Message-State: AOAM533FnOVbexV4gpI7PrL2skK+slNeTEZNkhStO5x4QXZD8XKJZ/up PKhmrHKQWd00mF89mC+gMNWxL8NqEOU= X-Google-Smtp-Source: ABdhPJwAqYeeBQChcQGXemfDu6IZA82SgoUr8bgIBtCK9+G3kX0FspNl6weZiawEPA4MwtORWtJvVw== X-Received: by 2002:a05:6000:788:b0:20d:130d:ba20 with SMTP id bu8-20020a056000078800b0020d130dba20mr14730890wrb.135.1653218403862; Sun, 22 May 2022 04:20:03 -0700 (PDT) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id e7-20020adfc847000000b0020e58b3e064sm7455208wrh.74.2022.05.22.04.20.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 May 2022 04:20:03 -0700 (PDT) Message-ID: Date: Sun, 22 May 2022 12:18:34 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Handsome scroll bars and devilish numbers Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> From: Graham Perrin In-Reply-To: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L5dKd1N8Kz3kHH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Noxp4cei; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.979]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.95)[-0.948]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 17/05/2022 17:10, Guido Falsi wrote: > widget.gtk.overlay-scrollbars.enabled Love the scrollbars. A raised eyebrow at the number of tabs that coincided with me opening about:config From nobody Sun May 22 12:24:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 637D01B3D298 for ; Sun, 22 May 2022 12:24:47 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5fmG3bWhz3tBr for ; Sun, 22 May 2022 12:24:46 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4L5fm73XcTz6dpL; Sun, 22 May 2022 14:24:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1653222277; x= 1655036678; bh=jJwvYbIuhHb3kYl5CkDY6u/9vU7iWur2AMAi6ME6ppc=; b=K n9BB5ohjF8gbOYFhFJbccfMHqe5qnbRImy9BrkoDmZ6rhkUwFmA7FHShiKhtujvH C4QLaRpqDnaHKriPcdY0gZlwFN7XhNENpHI00oZCbWLu/oDgWeZp/yEemyniMpOo T+tv0GkMywfwXi78TXPGl8HahbArci2L2MejBf177ENxdkP+PiloHelx50RA1MP0 x6WCmXClnkEhee7e7CA+D9574Drrv6pP78WB8qEZ0CkcW7mr+5iyZeb1KeVULUes O7aFtprkKj3yZ1QRGq2AQZ6hdsJe+MxfZ/yGthcPPeZu9x+cwNKB+zJw1K5BAw26 CleuFRBl/svZYTKwtnvWA== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id UGEpn0Wr2CrD; Sun, 22 May 2022 14:24:37 +0200 (CEST) Message-ID: Date: Sun, 22 May 2022 14:24:36 +0200 Subject: Re: Handsome scroll bars and devilish numbers Content-Language: en-US To: Graham Perrin , freebsd-hackers@freebsd.org References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> From: Guido Falsi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L5fmG3bWhz3tBr X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="K n9BB5o"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 22/05/22 13:18, Graham Perrin wrote: > On 17/05/2022 17:10, Guido Falsi wrote: >> widget.gtk.overlay-scrollbars.enabled > > Love the scrollbars. > > A raised eyebrow at the number of tabs that coincided with me opening > about:config > > > Pardon me, maybe it's some language barrier(I'm not native English speaker), but I don't understand what you mean. -- Guido Falsi From nobody Sun May 22 15:00:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1B28A1B39978 for ; Sun, 22 May 2022 14:59:51 +0000 (UTC) (envelope-from pj@smo.de) Received: from mail.adebahr.de (mail.adebahr.de [185.66.179.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.adebahr.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L5kCB0xXMz4f83 for ; Sun, 22 May 2022 14:59:49 +0000 (UTC) (envelope-from pj@smo.de) Received: from [192.168.153.212] (pd9515aca.dip0.t-ipconnect.de [217.81.90.202]) by mail.adebahr.de (Postfix) with ESMTPSA id B99C661BAB for ; Sun, 22 May 2022 16:59:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smo.de; s=mail; t=1653231578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Rc/WG4BXwUzefxogDgyKdPY2MyK//ZiYqo4p0ArJq6M=; b=NSC6esrtBFCOX9stPuNA3cCsdF0wDH5QVhuFoLecNqL4rUOpvZdJENyUug3MPNthsGtntE cYKUt4nGIPQPdCVBMFx6I64NFhH963x+pEhqJPR8mIABeIC2xNxS9GbWOk9Clw2ttyo4+6 cbzRcQuSTGJmB/sRjg8fu+OQFKOz6Gc= Message-ID: Date: Sun, 22 May 2022 17:00:25 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Handsome scroll bars and devilish numbers Content-Language: en-US To: freebsd-hackers@freebsd.org References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> From: Philipp Ost In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L5kCB0xXMz4f83 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smo.de header.s=mail header.b=NSC6esrt; dmarc=pass (policy=reject) header.from=smo.de; spf=pass (mx1.freebsd.org: domain of pj@smo.de designates 185.66.179.123 as permitted sender) smtp.mailfrom=pj@smo.de X-Spamd-Result: default: False [-3.95 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[smo.de:s=mail]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.66.179.96/27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.95)[-0.953]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[smo.de:+]; DMARC_POLICY_ALLOW(-0.50)[smo.de,reject]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198930, ipnet:185.66.176.0/22, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[217.81.90.202:received] X-ThisMailContainsUnwantedMimeParts: N On 5/22/22 14:24, Guido Falsi wrote: > On 22/05/22 13:18, Graham Perrin wrote: >> On 17/05/2022 17:10, Guido Falsi wrote: >>> widget.gtk.overlay-scrollbars.enabled >> >> Love the scrollbars. >> >> A raised eyebrow at the number of tabs that coincided with me opening >> about:config >> >> >> > > Pardon me, maybe it's some language barrier(I'm not native English > speaker), but I don't understand what you mean. > I think he's alluding to the 666 immediatly to the left of the loupe search icon. From nobody Mon May 23 04:00:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F47D1B40FAE for ; Mon, 23 May 2022 04:01:02 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L63XY5427z3lZy for ; Mon, 23 May 2022 04:01:01 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 24N40lqT074905; Sun, 22 May 2022 21:00:54 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 22 May 2022 21:00:47 -0700 From: Chris To: Guido Falsi Cc: Graham Perrin , freebsd-hackers@freebsd.org Subject: Re: Handsome scroll bars and devilish numbers In-Reply-To: References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> User-Agent: UDNSMS/17.0 Message-ID: <9930884f80c47409a68840562a498471@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_59d4bdd931e8fed60dc0d5d1e19ec2f1" X-Rspamd-Queue-Id: 4L63XY5427z3lZy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_59d4bdd931e8fed60dc0d5d1e19ec2f1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-05-22 05:24, Guido Falsi wrote: > On 22/05/22 13:18, Graham Perrin wrote: >> On 17/05/2022 17:10, Guido Falsi wrote: >>> widget.gtk.overlay-scrollbars.enabled >> >> Love the scrollbars. >> >> A raised eyebrow at the number of tabs that coincided with me opening >> about:config >> >> >> > > Pardon me, maybe it's some language barrier(I'm not native English speaker), > but I > don't understand what you mean. I took it as the number of them (666) and the evil connotation associated with that number. :-) --=_59d4bdd931e8fed60dc0d5d1e19ec2f1 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_59d4bdd931e8fed60dc0d5d1e19ec2f1-- From nobody Mon May 23 07:19:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 357C51B330F8 for ; Mon, 23 May 2022 07:19:56 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L67y25RYpz4Zl5 for ; Mon, 23 May 2022 07:19:54 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4L67y14K5Hz6dpL; Mon, 23 May 2022 09:19:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1653290391; x= 1655104792; bh=DM5Mpb0hNJDLZId+AaJViAbL1ny7pC5+evEdUFA/JFM=; b=Y YfGRHnpXri5WpEbMUmkpLw4IRZNk6m2lPGY0GQuqrouM4MBtwNVPHWQSt/lPAdxX wn2fXWvhGRQkBFSQyMW8pJhlZ/Cyewlrn4kOxJsZ+CjSSTcNuiTyrvaHdKTzpsMd T17WrMNZwlcKzmIYfSPWKaez9Qguox+llahksliUJBI+eWqtL2p1XsghkqesKfvJ UkKoaN/8ze4o9cboX97q6U/qXKhdpcbAmsCWsvS2R5FFKjkIqjFGtIEtfS6FKo3i Tw1ndhxj1XeqLu1AWUE5+VLhuKYkkubgCNlLKhrMx3w+BI5tvi8AwUT87tRNS6Yk oi9JBAumGDrSfQ+rMyV3w== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id 9br8Ca4uVOL9; Mon, 23 May 2022 09:19:51 +0200 (CEST) Message-ID: <5ffa9060-d175-1758-adff-f30ade25b313@madpilot.net> Date: Mon, 23 May 2022 09:19:50 +0200 Subject: Re: Handsome scroll bars and devilish numbers Content-Language: en-US To: Chris Cc: Graham Perrin , freebsd-hackers@freebsd.org References: <3433c3f3-86da-7f0e-8a84-2ad80946302d@madpilot.net> <9930884f80c47409a68840562a498471@bsdforge.com> From: Guido Falsi In-Reply-To: <9930884f80c47409a68840562a498471@bsdforge.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L67y25RYpz4Zl5 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="Y YfGRHn"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.77 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MISSING_MIME_VERSION(2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-0.77)[-0.770]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 23/05/22 06:00, Chris wrote: > On 2022-05-22 05:24, Guido Falsi wrote: >> On 22/05/22 13:18, Graham Perrin wrote: >>> On 17/05/2022 17:10, Guido Falsi wrote: >>>> widget.gtk.overlay-scrollbars.enabled >>> >>> Love the scrollbars. >>> >>> A raised eyebrow at the number of tabs that coincided with me opening >>> about:config >>> >>> >>> >> >> Pardon me, maybe it's some language barrier(I'm not native English >> speaker), but I >> don't understand what you mean. > I took it as the number of them (666) and the evil connotation > associated with that number. :-) > Thanks to everyone who took their time to explain this. I am aware of the number 666 implications, but for some reasons that did not connect in my brain yesterday! -- Guido Falsi From nobody Mon May 23 20:16:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 000E41B4C0BA for ; Mon, 23 May 2022 20:16:37 +0000 (UTC) (envelope-from kfv@kfv.io) Received: from mail.kfv.io (mail.kfv.io [95.217.128.176]) (using TLSv1.3 with cipher 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 "kfv.io", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6TBD3T7gz4TN2 for ; Mon, 23 May 2022 20:16:36 +0000 (UTC) (envelope-from kfv@kfv.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kfv.io; s=dkim; t=1653336987; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=gfVfB2XvGcQQXcUHsRtsOOJrCf/TQWZw/AE+itNlLc8=; b=reu4eJLbDygpycwLLW50wUEEDB6+mVRpTcjWGiHL7j37K+Y0dEHNjX3eMJOcEv8iBVEJGJ 1zyuTMqBgUXBkcZyphlD3K88u0TAUPZjm5v8AVMz5WHrkk1zX6XMRsVvXkVoK4Vyl/Vljm I+we+TgXV4l4A2HTtF1OVFKcnT5EjUJSpOk7AhzkunhfQNZGW0j6CaVqXeFg7+Ys7Kyh7t vRHHQe9ChJGPj97MTwIjB7cjXX6IQO5+GeuCfLD2CGnRaaVCvqsqbTOLCI6mL86JXhtDzP Lqf09TperXJgopkMKswouV9hFKvng4Onx23c5ug6N0q0ilaOKtfB6IPSUYhqJg== Received: from x1 ( [195.250.72.137]) by srv.kfv.io (OpenSMTPD) with ESMTPSA id bce67033 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 23 May 2022 20:16:27 +0000 (UTC) Date: Mon, 23 May 2022 20:16:22 +0000 From: Faraz Vahedi To: freebsd-hackers@FreeBSD.org Subject: poudriere-image(8): Cannot boot from a zrawdisk image type Message-ID: <20220523201622.itmywaq7a63hmxb6@x1> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="slwsrnjzab4k3nyn" Content-Disposition: inline X-Rspamd-Queue-Id: 4L6TBD3T7gz4TN2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kfv.io header.s=dkim header.b=reu4eJLb; dmarc=pass (policy=reject) header.from=kfv.io; spf=pass (mx1.freebsd.org: domain of kfv@kfv.io designates 95.217.128.176 as permitted sender) smtp.mailfrom=kfv@kfv.io X-Spamd-Result: default: False [-5.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[kfv.io:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.217.128.176]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[kfv.io:+]; DMARC_POLICY_ALLOW(-0.50)[kfv.io,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[195.250.72.137:received] X-ThisMailContainsUnwantedMimeParts: N --slwsrnjzab4k3nyn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Greetings hackers, I am trying to boot from an image produced the following way: poudriere image -j dev -h test -n test -w 4g -s 20g -t zrawdisk But I am getting into: Trying to mount root from zfs:testroot/ROOT/default []... Mounting from zfs:testroot/ROOT/default failed with error 45; retrying for 3 more seconds Mounting from zfs:testroot/ROOT/default failed with error 45. Loader variables: vfs.root.mountfrom=zfs:testroot/ROOT/default Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> Any idea? I appreciate any help. Cheers, Faraz --slwsrnjzab4k3nyn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEER72OR2ke+5+zBDNGxovV64RZlvEFAmKL65YACgkQxovV64RZ lvE7Bwf9FJ1uxopzfqJ5F2WcFcX1y0jW2xA8wLAu67C/K2MHmD6H65SAd9+CaygC t23Dax17Agtcn8QiY/up32rmU3ZP7vfrDE+LkKCvbP+azms0attA5Z1s7Gpxp+n+ hcOY94s6I79kbk+xnfRarHEqfrAeT60UzpsDLJwtu1Zdgk5CdxEDQqbbHmzAK6LY xvfISI3+e5zKSuHmMzIdyv0b+YhgFn14Pnfcd+LdhMkkyLcSidccxNCnt3eSHhLt P+p7vPxHPnSyEDQDSNmrbKfEMn8+91ThBXqxnwCLfLq6MzcrNPmCDspBogq1G+FX br3Fim1e/BRIcVLUC9lmTKY6VHBs7w== =ubVZ -----END PGP SIGNATURE----- --slwsrnjzab4k3nyn-- From nobody Tue May 24 07:25:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 770D61B3115B for ; Tue, 24 May 2022 07:25:10 +0000 (UTC) (envelope-from bofh@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 4L6m1f2rPGz4k6S; Tue, 24 May 2022 07:25:10 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653377110; h=from:from:reply-to:subject:subject:date:date: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=n0mPepo9Ruid9gyACnZGiy/YGsyr9RZmTE4RTvLIZ+s=; b=ySZ0pn/+2/s0D5njSCgzPR5ESjfeGO2tFhK5xS+WnYRjRxB46zOiK2T7PZRQuTXdZvDny3 697pNG1v+uuWXRzxylLvIqkpHvrfXDwZvs6KVUaE3kp5nh0/fT74dZQ8UbpNbC+TnnDy70 s79iux6qGSzptyBKe68xZsuB08iJnQb5O6htmKNk7TwEyDq43vXL9mzTr3vVnDo5eWUh/V yDriKeI8djg5TlfW9I6ExQW044JfiC6F/N6U9q6ZzS66WBNmIQkc9iPT47z+GT2C+3v0J+ 6u6gTpFVJX3zW7AKidUEBl8j0cm8Vm9MdYqMMLjMl+6IXbio9XSz6ztgv0FWjQ== Received: from mx.bofh.network (mx.bofh.network [IPv6:2a0d:2787:2::28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.bofh.network", Issuer "R3" (verified OK)) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E8E042CA0B; Tue, 24 May 2022 07:25:09 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple (ip-217-105-29-47.ip.prioritytelecom.net [217.105.29.47]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id 2fcc8810 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Tue, 24 May 2022 07:25:08 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_64296E6A-27E2-49BB-BB31-92565C4F5763"; protocol="application/pgp-signature"; micalg=pgp-sha512 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: poudriere-image(8): Cannot boot from a zrawdisk image type From: Muhammad Moinur Rahman In-Reply-To: <20220523201622.itmywaq7a63hmxb6@x1> Date: Tue, 24 May 2022 09:25:08 +0200 Cc: "freebsd-hackers@freebsd.org" Message-Id: <35700179-51B0-49C4-8225-7BA0B3CAF1A0@freebsd.org> References: <20220523201622.itmywaq7a63hmxb6@x1> To: Faraz Vahedi X-Mailer: Apple Mail (2.3696.80.82.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653377110; h=from:from:reply-to:subject:subject:date:date: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=n0mPepo9Ruid9gyACnZGiy/YGsyr9RZmTE4RTvLIZ+s=; b=FNRNKeCzTGWsctdN/8DKAEFHPDCF9zlGG1CaAHxJNoBH+wu5jAObZFC0wJDTePxgFwOAft BRsjL2GJYvv5JrKCjfs8hPPDqGjIih7SzvUGApILUe7Iy1o71d/LdfEQIultlZqFh4R4G5 j+pmDwBwDaU6y6bkLkQmJYMOk+GROxxYHMM8KchqZ2E6mPieNiWVlA1tfoJvq8VTaummeG 6tsvupaDb7zDIQ0NPTAEp8nzYc+6+gnrPBbJGdYcg5yRRrFe7fHVOCeAeOphl2WWvx+7xT sS10OctaEk0SF/7I2+fqL5S4K96In8t5RL/x5LDwFdjqk1c1UR3RtuW1iy4C6w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653377110; a=rsa-sha256; cv=none; b=tB/o4oEphr++MlMQTReUONZsQDALxR/XvbQwXGJvt3rtZyGNqRpFQ2bR4yvDeACvgs0X8N R3x8OhsCgJaUm5seuTUYf8llCZ0s7uF5AOkx9Q3TOSUy7bIehdV/O5RKh2FuOwRvd0QtZI HA5Fq3bAjADUxLLGeYBXvqAu2q9CxbBRgO5WM2XwVcsNwgSEjjlPzBKkdgrLnHn7XqJzJG PCTzc6FnEGA9IB6MNK8pLH7gADpXGfJ1Y3Nmd/Igax2ZSN+ZvQNyEcKNFiF5GXHb6KVyWN fGfIfcXXCFw8oauaUHASf0bGEiv67miQ6ZT6SG40i4k3YAriGYvk68Z+B15lww== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_64296E6A-27E2-49BB-BB31-92565C4F5763 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttps://cgit.freebsd.org/src/commit/stand/libsa/zfs/zfs.c?id=3D1309bed8397f= 547fb94c529ff071a28b675c86a6 :D Kind Regards, Moin (bofh) > On 23 May 2022, at 22:16, Faraz Vahedi wrote: >=20 > Greetings hackers, >=20 > I am trying to boot from an image produced the following way: >=20 > poudriere image -j dev -h test -n test -w 4g -s 20g -t zrawdisk >=20 > But I am getting into: >=20 > Trying to mount root from zfs:testroot/ROOT/default []... > Mounting from zfs:testroot/ROOT/default failed with error 45; = retrying for 3 more seconds > Mounting from zfs:testroot/ROOT/default failed with error 45. >=20 > Loader variables: > vfs.root.mountfrom=3Dzfs:testroot/ROOT/default >=20 > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. >=20 > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 = /) >=20 > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input >=20 > mountroot> >=20 > Any idea? I appreciate any help. >=20 > Cheers, > Faraz --Apple-Mail=_64296E6A-27E2-49BB-BB31-92565C4F5763 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----- iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmKMiFRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJFK0g/9F5GS/eMh2qbiS0Dmt/ItjPjw+cEyY7mPW6piH96QaYS3CESn6dw3zYn5 6nX7l8YMOdXvyt6cELaa/0lL5Fy2LeNq4TPQm/v67uNtbLDqXeYbr/iGR5wsKk/Q JgGubjIzjPzWx4247pBVeDHybChHBtWkoNyUbIRJYohCdJTr+nSvAskG7kENAMf8 YKfIdsv71K3XH+g3jkWoiYq9VS86GP/4nKTz8LK/YaaKF6BAuhBhK0Y1twbPGi9Y sklaK049VqUjY/4OBs+xYe2KIbrkZF103b7zoDikUFX5VfM1uNvBTBv4yr8F25zX 4JI1NPpaeX3ihJG6VW+dVT1gF/VCJiB6zHwNz8jEOSsWd39a8zczIBuQtmgNyWY8 7gsoPrTq0LVWIcKzlQxuQYZxYI5dB0EA07DCMMmiggWEtOq48rc8pV3zxw6m56mL 2ZmjO3HUhX2/gJQMCecronQ7gkpEDed3HFeog6HrHYGoESv8TPYCThWhiY0SI/F+ t2zy2wvpv5eCnlCk0aKNWg7bx7N88alN3lyKashiHNC7wb/nHbD3HcdC2OfotnJ2 pOrgm586vvUDGa0THUlauExLqEsxiiUI+UOEVeNMdPEg50SFItspLPYXBsFCeLvQ qSnJOHV1RIKK250BLsMG1kOa09iobTxTq1hnrXnqnGu1wr4y0gU= =Je5/ -----END PGP SIGNATURE----- --Apple-Mail=_64296E6A-27E2-49BB-BB31-92565C4F5763-- From nobody Tue May 24 12:29:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C3AE1B4E313; Tue, 24 May 2022 12:29:17 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2104.outbound.protection.outlook.com [40.107.117.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6tmW5cRBz3s9c; Tue, 24 May 2022 12:29:15 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oo9Q6nKJ6g0lZQcyg4w+g8M/USAj2O3phIrH5U7EH2XlCAvPLBclnUZ8S850S46HCCjV/Zt4MBoY4vflQi30bwKabUhkXDpbf3p2XIr4DwS/78fj2W+xMvOGqXG6hBNMqz0llUpXsfWs6N4Ri7DfSJmh2u3wVAV+IviTBWW4QPxi35usGhd6Ky2V1nT03nIKglDv+dErD4CMjumMVrB53YjQKc97SRyggviZ3Y6xoYXrkNlIxZh+TbQwTR/dqum13BFIFq78hm6ggRg1HNlKfocTPV5odgpORu1RvH3OgxO06VYbik8bToB5e9sH54dZSDuAsDtwPVjElsAGRXBRyQ== 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=E2ZBueQyt/XxGsfgfYPu2+acvdnLcdgCh4EiqdFfvDE=; b=KQhtINMtqgNON5r3ftIJYZ0DPqJ1w2oi8JwNAWoOMqjUIutXx+zXkZ+Jb73OJwPsNmZobjz/5/jaTLDJ1n8IqTm173uATxB/K4c1XZmlZ4CMyYWpn2zdqENWznwthne8+zVowPzhyrenVH45ekJOK3lpoIT45TXRBe+Wahxd4v2vk4+K12aT+/HobyhNHU9hHcl/TaE8c9AuFfcco6kOcN8jiynTCkCQKFpa2ecl9OxktVkNvritat3z0VMlMu4QWP5eLaXVD2+k8OR91N7QGdykbfFDRR4EEpVmfLAXyJld872Jylxk7ldNkzLtdJVi7pRN6eu0V2NM8M3EQLlc/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E2ZBueQyt/XxGsfgfYPu2+acvdnLcdgCh4EiqdFfvDE=; b=B/9eDCl6ipXcvXWH2Cijgb6vfCaZrKvwyexmqFzq2H1PQVENSGcteteWApdSN1lR8zc7s6tBlCsA5JmcOhi2j6PqgUe1KEB1QaRFtqT5eMePrGC2G41LKSJE6GK76ynOW4UBRG8fEaf402vzFotiGQqeKUzaVM60/QlfRaid/Vc= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by TYZP153MB0479.APCP153.PROD.OUTLOOK.COM (2603:1096:400:54::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.1; Tue, 24 May 2022 12:29:05 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::6146:9fc6:62ef:9cfd]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::6146:9fc6:62ef:9cfd%6]) with mapi id 15.20.5314.005; Tue, 24 May 2022 12:29:05 +0000 From: Souradeep Chakrabarti To: "freebsd-arm@FreeBSD.org" , "freebsd-hackers@FreeBSD.org" CC: Wei Hu Subject: RE: unable to get virtual serial console for EFI Thread-Topic: unable to get virtual serial console for EFI Thread-Index: AdhuioZ1RmwGFkAIQSSs+orr/q96BgA3sRNwAAAabeA= Date: Tue, 24 May 2022 12:29:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5770f6ef-1257-45a3-91d5-831d3060b3cf;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-05-23T09:48:53Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: acef6bbc-9b3a-4678-ac1a-08da3d80fe10 x-ms-traffictypediagnostic: TYZP153MB0479:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1uQtU/rzgaS2u/Y947SDtL6Hdcck8X++3lMi+3TjgVtWok/1L3GmAkFXVlu1v997G2kh82DZT9KRsZWTVsZY57GPIqQEuqrF0oKukf/7XvS2ceYxiTqV6aR/daGw/3GshSUD4Zg4Xy+G4GxrUZ1AkwB9SYF1eHGwsmfs6VI2z9bUtX6oOwwqx6yRSQSw/0NEqnpfE/PGry2hTOtC0MpfbN4RywRDVJpe42JC/5O+JoWlg6hazy5BCzug4HZuWDRvLTHxSUZFU0hH4Eioa0KKH/f/4yfLPci7Qhs059fSqDxTpr9x5ITpDJ4R+Vft90dl1onC/i5QJNby91dfUHFVO59cPervt5Qelre+i5VixWNIWMKjORhMizcFX3ZxlEUVH9KDsvDXy4MIr5527Mx47spOEE6kZibDJHwuIseT39ZqMlaqstM7el+bjRnyaUJhgv7wTmpB8EL+oN/P4uTCbqvz41G4cx0xHm2FIctG9zgsdlF/VDK8PkbAQ3DxnUH4LBHjwO1e5tEbd+Oc8teYVn0wcdjUd6zw0C8EpcbbIz2DzH+/ixDrihE9VqBMYxLAJNcYi+GULL/mVP+PyY6iPdma1wkZq/Rv3pQhpP2EGYUX7ZIXVPxnAq1stC/0JXjZU9VQ7lOKBesY7lRh6xybEjtu4nE7kVr6dFpPSx1XjpoiL2HBYJ8k/zjE2cJ8GI7wISJ/VWdPs/4MPfn3MjcZpd0wxIDJlYXMtt7z+QeT+i2onbYqrkI6n9VJEr/PMGWAEXYTV/wa5pJnWnlq5lmjJBOBV+1o9+0TFgGmrFtyXQM= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230001)(4636009)(366004)(451199009)(508600001)(8990500004)(316002)(2940100002)(86362001)(55016003)(71200400001)(33656002)(83380400001)(107886003)(2906002)(66946007)(4326008)(8676002)(5660300002)(450100002)(66446008)(66476007)(66556008)(64756008)(82960400001)(82950400001)(4744005)(76116006)(9326002)(110136005)(186003)(6506007)(7696005)(9686003)(52536014)(26005)(10290500003)(38070700005)(122000001)(8936002)(38100700002)(460985005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fJwinjyBSH8B+rP7q7q6+xz8bhbu6+6Nn3Is+PfmfbrKWSyCURXqnP168ek/?= =?us-ascii?Q?mNGrOXDjgS5ASGhZEmBDCsN4UrPrKKIhj8DyUmGIWIYw2v1vJOJWNQYp9QRD?= =?us-ascii?Q?DdtZilcBDBVoMRIu8IY428b7VhCnEEvFIWKqSnnUA49e8AsiJSH2QjB5RUjm?= =?us-ascii?Q?NBdDF0ZC3/vqMN5mHuppwBHkSNauVzA4nWpV3mh8iEQQA/4T4OVlQPO+nWLH?= =?us-ascii?Q?N2GOaEcaesPvltwz3BDjMzXE/ZJnaEnq3fnD6qDk8Rvar+HNMvN0SzuKK3ZF?= =?us-ascii?Q?k4wZmYqPo+aJqiPAKsF2qroAItoUy6U0EYgE6YyYqor92SIQzeLWNiCVMJKV?= =?us-ascii?Q?eY8R6p7YQYOW7vz7v/5DTV2gxhVOYF9jTGHOLUO70xB6D8PPoK3EPUW0NpCn?= =?us-ascii?Q?Q/GPglfdyEiEk/fN/ygb4stJV/CVd+fX0Pt9PEz10uOqL/I/SG9jqzf2jNx/?= =?us-ascii?Q?BjvMd2nrBPMUmUR5nrIDpY7fB97CzlYv5VhkdsU2b9NIZWorIldHM+B8+G9q?= =?us-ascii?Q?ZNuy90lJSQUsY0cg9WPPhxyeEdHScKsVOwrSxt5LZix+bbj+GVdRhjwSIhKI?= =?us-ascii?Q?sgUI3fV9f/I0u8JFv3On/Se6D0sJlXtNF8lGAmYWtdM4bWXYeoKaX44NomFX?= =?us-ascii?Q?yX8oAixS1mq2oInsEEoJAiG4EsahPuotK8x3oclXOC7SEXUISoOEUWWE+SwF?= =?us-ascii?Q?MfV7H2S/WQq1ocuh8q0DkNZaaZdmXZq3UEuCtGe+ZEyz3ZeKitqLIwRm18XE?= =?us-ascii?Q?b/IG/aZOkdXU7TamhYTcnMQTdtWBJbdOr2ANZMNUrJDo2MNbktRyTY1RZwkL?= =?us-ascii?Q?IOyv1fforcYHBNFnA80I+X/4WGdb4v9XMppeKQ4eF1X3Iv95el7a/cQ0ex3/?= =?us-ascii?Q?lxsvrKC9iDYXGljC1SNaiUybglJEked6IeCnt8blV1j/sxWu+64+ng1qY+6X?= =?us-ascii?Q?gEKe50jikQ6xRuFK9Lr8IPk+MQ3hF2DQbJmaPK9aYFyJiQMwv4kuCGzOOaqb?= =?us-ascii?Q?q6w8cmAb0v3opx9DC2j5o2LxRj0bD0MzflM/7cgJOgfUiDJuDGyOTyXE6b9M?= =?us-ascii?Q?+2etOpStq2DbZd4x2Mx1if1/GyNh9uJnPrnURdiACxIacprBjCWO/D/irHHi?= =?us-ascii?Q?DLGBkq6kj8gvzakIwOioCJw5fQhf8btr5JKzKbU8z7hiqYDPjTGDhK27Xz3N?= =?us-ascii?Q?aDkqgBFb92GR2vznyVtgD+dcUNaD1pp8aSfBbAr+BSTU4q19BDoazqJST1wc?= =?us-ascii?Q?XMTd+izevbrekvjInOt6mMWo4WsOvDbA8M7RFhMvQMnQLCH9LZn73ewnLcUs?= =?us-ascii?Q?r5qwZvltZS/1hq7AD7PpJRySjbkZ3AYoLLv2zkVQiP90ka8ogb5f0J3v/Caw?= =?us-ascii?Q?efDhIcbWRaHCY8sjSF1kAsYawGf4okfP+GScsBULA7H2yYmR6vYh2SHyOjPC?= =?us-ascii?Q?4ldDgnZi9eLjuM3G+Rape1IJVBBMGsRoIiaMMPHbrDV2KEvHWKbXeMEONdT5?= =?us-ascii?Q?fDVbYsw8VAmsmaw4AEzxsC5jPNmzFKFHDMtw4k5cAvja+2po9/PNknV8cVa6?= =?us-ascii?Q?z+gG4f0fgBs5Y+obTomtzETBAna+pO9xnEW4K/AQ0+Tn9WdW1+4Q2xBPOrJa?= =?us-ascii?Q?1gER+siMq6ncaUZl0VkSA1hRzRnNkVhq76uba0BgDbJXpTtVc1Aid7qjIAiV?= =?us-ascii?Q?OLYXWupFVSozkfnifF1impTpOE4=3D?= Content-Type: multipart/alternative; boundary="_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: acef6bbc-9b3a-4678-ac1a-08da3d80fe10 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2022 12:29:05.3492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N9cVrlxEB/cxsYyqbs+ToGrAtodiYas57WoUa7wUDFyhhcLvnIqTQMjfgyNRZzBXWn1oeBKexQll2tfYf8UkPZEzr2rQP0UDMfotQ6OZa8w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0479 X-Rspamd-Queue-Id: 4L6tmW5cRBz3s9c X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b="B/9eDCl6"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.117.104 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-9.96 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[40.107.117.104:from]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; MLMMJ_DEST(0.00)[freebsd-arm,freebsd-hackers]; NEURAL_HAM_SHORT(-0.96)[-0.957]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.117.104:from] X-ThisMailContainsUnwantedMimeParts: N --_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am trying to get the virtual serial console to access via putty while boo= ting FreeBSD 13 arm64 bootonly on Hyper-V. Setting console=3D"efi" is not helping to have the virtual serial console a= ccess using putty for ARM64. It is before any kernel module loaded. I can get the loader output in vmconnect.exe but not in the putty. Though I can see VM is getting connected to Hyper-V virtual COM1 console. B= ut no output is coming to putty. I have following question : Any specific support from EFI firmware, is required for virtual serial to w= ork in EFI loader in this phase of loading? I can see FreeBSD EFI loader is able to read the ConInDev and ConOutDev var= iables. With set console=3D"efi" or set console=3D"comconsole,efi" or set console= =3D"efi" , nothing in getting redirected in putty in arm64. But in X86 that is not the problem. Without this debugging the bring up of FreeBSD on arm64 Hyper-V is quite di= fficult. Any help or pointers are really appreciated. Regards, Souradeep --_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am trying to get the virtual serial console to acc= ess via putty while booting FreeBSD 13 arm64 bootonly on Hyper-V.

 

Setting console=3D"efi" is not helping = to have the virtual serial console access using putty for ARM64. It is befo= re any kernel module loaded.

I can get the loader output in vmconnect.exe but = not in the putty.

 

Though I can see VM is getting connected to Hyper= -V virtual COM1 console. But no output is coming to putty.

 

I have following question :

Any specific support from EFI firmware, is requir= ed for virtual serial to work in EFI loader in this phase of loading?<= /o:p>

 

I can see FreeBSD EFI loader is able to read the = ConInDev and ConOutDev variables.

 

With set console=3D"efi" or set console= =3D"comconsole,efi"  or set console=3D"efi" , noth= ing in getting redirected in putty in arm64.

But in X86 that is not the problem.

 

Without this debugging the bring up of FreeBSD on= arm64 Hyper-V is quite difficult. Any help or pointers are really apprecia= ted.

 

Regards,

Souradeep

 

 

--_000_PSAP153MB0536ABA1A82461F1474A3389CCD79PSAP153MB0536APCP_-- From nobody Tue May 24 13:35:30 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E0C71AEB2C1 for ; Tue, 24 May 2022 13:35:48 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6wFH21tgz4Vrd for ; Tue, 24 May 2022 13:35:47 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 2A216B18 for ; Tue, 24 May 2022 15:35:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1653399335; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=FfI0zWZucSG0SDAyVkuHffysgGXRw1LqOB+Px1SpuHA=; b=3CehujQI1KE63tF8LVgN/q4p+tPP7Ha5hcobi+8Fkt1usuCnf14sfHpGSjH2uzJ9vjOcVm e/v6a38YHrzSdlqJygEMqETPpInRBNBUnLtlXCUZHl11YVwHfaaFkpSz/4jhYb+GLyEy23 OkeTGbyKRsyAcWzU2b2r6I6S3Sex5McqC+vMNVmLv5I2Xc9Akn4H7/V80JMtx0aebejN8l MrLUctf9yxSw5eTQy5FgCZtD1ouq7JHNKLzKdNZXQFmPa/y7OCvonF5JtytZqbt+KO5QZC gKmjvloy7TQSIpzxrTy0rfT5Ul4RWM/H4y7/aT/zEjSnNCP6bFYqXMp5MqL/MA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 038373C45 for ; Tue, 24 May 2022 15:35:31 +0200 (CEST) Date: Tue, 24 May 2022 15:35:30 +0200 Message-ID: <20220524153530.Horde.3SgRQ1hkvfU55TIxzt23N7R@webmail.leidinger.net> From: Alexander Leidinger To: hackers@freebsd.org Subject: FreeBSD kernel module in rust... Accept-Language: de,en Content-Type: multipart/signed; boundary="=_JLmMYFZYDEzEtNdQWAy8CvS"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4L6wFH21tgz4Vrd X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=3CehujQI; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[91.22.85.98:received] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_JLmMYFZYDEzEtNdQWAy8CvS Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, just stumbled over it, in case someone is interested, the first basic=20=20 /=20"Hello World!" FreeBSD kernel module in rust: https://github.com/johalun/echo Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_JLmMYFZYDEzEtNdQWAy8CvS Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmKM3yEACgkQEg2wmwP4 2IZg1g/7BqNzJ2YjD3s0XIlT+8BTwLCf5BWcOgbIu28Chcg5SzmxNwEiLn7IsWBi f0cvwNqFtxfnRcWDdShN3TaZY1evu2Gv4JNukKRtIwM28FQCY2r/enj1bEdGOF4n vkZ8LpLbhxJmq0y1pWyiHRb2c8hx0YLhccAXC9uDKfpOFda4RKjYXSJW8eTyRDMH Rl12oTDsy8fgmj3DP36sVxndxDh2MBuG4srGhj3F56IgIpt3gucG0XbCNk83hVsE UJidg0uZDeOgeKpj9GmvLLA0KY6DsHuCdi54eZPT1RQRlh1bXJ5h7+R1ncZyNgQi iHI1QgNjyzsCnCjDjNPOMwCHj+cbJJ0o8K79NSIXr4CSDv04GejS1do/QfqKZDgd TN9McSRQoRJFWUZTO3456EDiCt/4qdt9dD9fgC9UM2iQI7uWv5NCmcRshNLvcaXb 7KKl7M1MhETADN+4o8Y3CRBHyANv+UoS6JkwjzbLGJ2tnXd6OQoJTZLJ1GOQjHyM +588KnnpB/UN9cvwks3aVBJT+YGLSr611eWM+4lEM0GN9f7wdNW/MySW1v//eKZ2 SX7GTinJjDENJOj0a22zzhCLjICfXayq8r1G7Hb57GE2g64yxEGCc07kHYM4I4uj qJyp/K/khbD5JipcHWQ/92S8VbAm70r3VBWDG3wv+W2QU6dZhS4= =Bn20 -----END PGP SIGNATURE----- --=_JLmMYFZYDEzEtNdQWAy8CvS-- From nobody Tue May 24 14:23:56 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9C51C1B3F491 for ; Tue, 24 May 2022 14:24:10 +0000 (UTC) (envelope-from jbo@insane.engineer) Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L6xK44Gw8z4fnk for ; Tue, 24 May 2022 14:24:08 +0000 (UTC) (envelope-from jbo@insane.engineer) Date: Tue, 24 May 2022 14:23:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=insane.engineer; s=protonmail2; t=1653402240; x=1653661440; bh=pthfAgqwDe1oSNry2aXGyGAUZ6bpR0/kUV/OMWpe6Ms=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=Xgt5ksPxFvRfeUDCHDAkEzBGRvrLInWK6ohkaD5r8WwE/rF/CPYLxvtVtQx7H4dWg RnMY4s5WS0pz1ZL90Ba6WqxaBfojWX8tQRWo25539dCAzlG9F84k0zWjRjrvaj+kA3 6OS5ct2JICoZtecjbWodkUpgsYJhtTGWWoVmfOwtEDtWdb9fxWmMQ4HBdxQDg+B8pG Kh19X3GLd0XgOgJ9DVE93Bw4Uh6nzpYigJzLa4ZSVmLAvoKzvLv/2P85bs+dILc+Bt 7nyakbRMf1TQipZdiByGwJgF6gsqf5srzc8n0JmqWYUM4McnTUf7fL9JhGJppWC+FA YZ2mX1RtUoWaA== To: hackers@freebsd.org From: jbo@insane.engineer Reply-To: jbo@insane.engineer Subject: Re: FreeBSD kernel module in rust... Message-ID: In-Reply-To: <20220524153530.Horde.3SgRQ1hkvfU55TIxzt23N7R@webmail.leidinger.net> References: <20220524153530.Horde.3SgRQ1hkvfU55TIxzt23N7R@webmail.leidinger.net> Feedback-ID: 40997969:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4L6xK44Gw8z4fnk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=insane.engineer header.s=protonmail2 header.b=Xgt5ksPx; dmarc=pass (policy=none) header.from=insane.engineer; spf=pass (mx1.freebsd.org: domain of jbo@insane.engineer designates 185.70.43.17 as permitted sender) smtp.mailfrom=jbo@insane.engineer X-Spamd-Result: default: False [-4.00 / 15.00]; HAS_REPLYTO(0.00)[jbo@insane.engineer]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[insane.engineer:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[insane.engineer:+]; DMARC_POLICY_ALLOW(-0.50)[insane.engineer,none]; FROM_NO_DN(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N For those interested, that link showed up in this forum discussion already:= https://forums.freebsd.org/threads/what-we-can-do-with-rust-is-beyond-what= -we-can-imagine.84759/ ~ jbo ------- Original Message ------- On Tuesday, May 24th, 2022 at 13:35, Alexander Leidinger wrote: > > > Hi, > > just stumbled over it, in case someone is interested, the first basic / "= Hello World!" FreeBSD kernel module in rust: > https://github.com/johalun/echo > > Bye, > Alexander. > -- > http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF From nobody Thu May 26 14:01:34 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DB9361B445AF; Thu, 26 May 2022 14:01:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L88kJ6ZwQz3hKy; Thu, 26 May 2022 14:01:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Cc:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=iQWjqt/foHq9rycLawM36rcVAzH+qIF7bzA74gmqTW4=; b=sc29yZsIx81uIh5GVT3FxGnZwzTxUfJqmMS4Y6h7AiWU2UTdnHtc7Afs5jvOFw96ZLbhK6KjpOn8+y0ycDXHygaqudGVmAA157Ngw5BBQBiGm61zSAxBbtC+NHdb5Yln7swABDT9sAp1PuIJrkthoNEMMl46UGWNsHhOGX9tm3UNmr2TUjPaPbGc7PFX24WlzVrMhbnQlw6dJLUePBlv67NO1hOPOsffdZlT5N7vmR2L61XUjdcjpCcnlvat9QYvg0FPiMBu9SJz8Dl1j3gxZWUGP6x3sJHTjcgDrWlylUemx/iMtaMr0nV9zXp0SE3cTkZ/YzQJQzGnE1j7pqgcpQ==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nuE3S-0006nC-UU; Thu, 26 May 2022 17:01:34 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: unknown flavor py37 Message-Id: <7F7A8235-8171-4037-80D4-92DB11BC366F@cs.huji.ac.il> Date: Thu, 26 May 2022 17:01:34 +0300 Cc: freebsd-ports To: freebsd-hackers X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4L88kJ6ZwQz3hKy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=sc29yZsI; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-1.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.62)[0.621]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MLMMJ_DEST(0.00)[hackers,ports]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N im using postmaster. after a resent update to /usr/ports, the default python became 3.8, fine = by me, but I still want to keep 3,7. some Makefiles require 3,8+, again no problem. but some have 3.6+, and make FLAVOR=3D37 failes with unknown flavor =E2=80= =A6 any work around? cheers, danny From nobody Fri May 27 14:17:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EA981B54BC6 for ; Fri, 27 May 2022 14:17:25 +0000 (UTC) (envelope-from email@jeremyself.com) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L8n1w09Dqz3LTf for ; Fri, 27 May 2022 14:17:24 +0000 (UTC) (envelope-from email@jeremyself.com) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E8A825C0103 for ; Fri, 27 May 2022 10:17:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 27 May 2022 10:17:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeremyself.com; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1653661043; x= 1653747443; bh=eSnLm2HgmYdBxTZ5w3kU4MOavc+/ufZeER0h8qEBnus=; b=k 2bihYKLQ0fA4IFAM9xZSBEzePy+ComT19ebi/y+RCE3/oJGMECHYx3hVwGTx1e1z 2OYPpqkVkb2kU0PAdmGCdgpxb8FhjN6ow4oEEZzyMVSijQ1mRKu68xK3Wo7+jBsq 99A+FYqKwcEPGRWML36q9XL56UEgLNvx8Mf/VgejRRyYXw3GbgMcdxCufhL4PULr Ea2N8mO829ihf0O8uFs0gxeFLjuxKLcRHWLEz+lx1B9sCOibP+dZlITNe+TACvjy ZTH0VDtWyjQxGsXvf5aPnRWFdkxm2pvOdh2Q+h+cioGLxYAtxZhcpcoO35ByNU8h T6KAplA9/C/wnO1010dMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1653661043; x=1653747443; bh=e SnLm2HgmYdBxTZ5w3kU4MOavc+/ufZeER0h8qEBnus=; b=dn4Sr8dDEEaDG6dTU iPgNDBIHd7zm8BUvIeJBJ2lp8id0ZAFommZtWF+WhWBrfH0vZdeNlrwXrY/588Ys DmXamrgu66mRgGhrzz5FArOi9o5fY4wR63f3LH1Ea4CyR5SiK5o2dw2sBN/nEtSe 63msZ5AeJAHNhrzHLOK1+rIfop0d6+b9fQiWi04FuNOJ5njDQiV0NX2jYedQsNBM YaCAZD2afFbwxyQrJ8mNuOrO+c6LRmLdFyqEB7VwBXZ2zE1kBHT+WUvJ05FjbqcI RgJxE5JA7Tog9IAVGR8OCCjMZs0b60ghSrz2HDvHzbmiGY9NJdNqhT1WhUGYB0/X GfTMg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrjeelgdejhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffhvfhfjggtgfesthejre dttdefjeenucfhrhhomheplfgvrhgvmhihucfuvghlfhcuoegvmhgrihhlsehjvghrvghm hihsvghlfhdrtghomheqnecuggftrfgrthhtvghrnhepudeggedtkeffheeiteduvdefff duveefueefkeejgeelfeefhedtjeeigeeiueegnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepvghmrghilhesjhgvrhgvmhihshgvlhhfrdgtoh hm X-ME-Proxy: Feedback-ID: if1a446dc:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 27 May 2022 10:17:23 -0400 (EDT) Message-ID: <377b54a1-4560-cdc9-1888-82cd5bc82990@jeremyself.com> Date: Fri, 27 May 2022 09:17:23 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: /etc/login.access bug? Content-Language: en-US From: Jeremy Self To: freebsd-hackers@freebsd.org References: <2e73872c-b539-167e-1fca-e3db60ef1d66@jeremyself.com> In-Reply-To: <2e73872c-b539-167e-1fca-e3db60ef1d66@jeremyself.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L8n1w09Dqz3LTf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=jeremyself.com header.s=fm1 header.b="k 2bihYK"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=dn4Sr8dD; dmarc=none; spf=pass (mx1.freebsd.org: domain of email@jeremyself.com designates 66.111.4.25 as permitted sender) smtp.mailfrom=email@jeremyself.com X-Spamd-Result: default: False [-3.54 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.25:from]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25:c]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[jeremyself.com:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-0.94)[-0.944]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[jeremyself.com:s=fm1,messagingengine.com:s=fm1]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[jeremyself.com]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N In my new install of FreeBSD 13.1, I added these new lines to the end of the default /etc/login.access file: -:ALL EXCEPT wheel:ALL -:ALL:ALL When trying to sign on, I got this error: jeremy is not allowed to log in from [client_ip] Connection closed by [server_ip] port 22 My ID is in the wheel group. jeremy@webhost:~ % groups jeremy wheel If I modified the file to instead have these lines, it works: +:wheel:ALL -:ALL EXCEPT wheel:ALL -:ALL:ALL Thanks, Jeremy Self From nobody Fri May 27 18:25:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A91951B40A0A for ; Fri, 27 May 2022 18:25:56 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L8tXh0VTlz4g8Y for ; Fri, 27 May 2022 18:25:56 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id n22so3462700eda.5 for ; Fri, 27 May 2022 11:25:56 -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=70uUJxp3yTypKtUaVd8QIdoug9CH7aS73eNy0Es0F1o=; b=am+VKfhhwhnXer1L5ffacsyXbtnGqc+N311LvoPBLo/9UhzVfWGItIZqqfcruSFSSu 4S2q7baZpk7cdPoAUUl0iq/R7OqadlUfaGEWf1b/sZ0zeGADaGBbI4pEmQ8LeK2DKKc0 FUux6tRukAqeK+xxXlY9g13tKCN8Sd2ISMNOYKNxTdySlohK/ihG3Xosk3JcC+SgsZjx S5I9ba065ame8O9VBUo7fOP4S21MzZlyuqW1+oTSZTl+U0JCNOwhsi72qybp175hjKlE muH8+cGG1iZo0TKZ5/4HEU1WkpdXv2NorDOKAsUbZ7xs3pCVxXJcJxtcTBcOkEj7Yzyh UNYQ== 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=70uUJxp3yTypKtUaVd8QIdoug9CH7aS73eNy0Es0F1o=; b=PKWY/RygRlljZEbK1SQkmLh7BmzMA+FI1VbhDVNhx8sBoTvpmTF5MUHPKQEcd8/uWR j+jfv+/528Vma1ykguanNxpS183Z3BUUsl8mS47B4lSBRLcfVwpSKpA8jR2u7VgLYNgm QPvg5zXp9Fsv+eo4mSWInA+OVvqz1dusEcc6Y+Bb1DuQ2EWytSX3BUJzS0QmXETKb2FO 71AStU3B+EB61pWVnNAZXTdJkY1fKuOwobj0VQcS32Wf1nOp877Z0cGQePWpU42yt2ve sgyfRo/3/RcHDjJpGBYrSZiPFDH2jJJDYQGHRDzjA7hcstLts3ZYgr32jIvXulTqTySs ZuUQ== X-Gm-Message-State: AOAM533SU4GMHNbrZEtJCs3cwliyjocUsaie1hpH2HN1T2CrID5NgHQi MPm7a4oNWmRX3EN7wZVFbpslXTNlsnYDkHHSfA8b5XqQBoUpjN3K X-Google-Smtp-Source: ABdhPJxQuNiBuk92ChJQ3hbj/8LAtOfMl4bigHWIqHO5NMk3a9fNrwLAJdnUKHDUnGZkuD5HzQ6oMYFbl7ILdgybBHU= X-Received: by 2002:a05:6402:3298:b0:42a:a91d:905b with SMTP id f24-20020a056402329800b0042aa91d905bmr45603027eda.373.1653675949092; Fri, 27 May 2022 11:25:49 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a50:2891:0:0:0:0:0 with HTTP; Fri, 27 May 2022 11:25:48 -0700 (PDT) In-Reply-To: <377b54a1-4560-cdc9-1888-82cd5bc82990@jeremyself.com> References: <2e73872c-b539-167e-1fca-e3db60ef1d66@jeremyself.com> <377b54a1-4560-cdc9-1888-82cd5bc82990@jeremyself.com> From: grarpamp Date: Fri, 27 May 2022 14:25:48 -0400 Message-ID: Subject: Re: /etc/login.access bug? To: Jeremy Self Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4L8tXh0VTlz4g8Y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=am+VKfhh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > the default /etc/login.access file: > -:ALL EXCEPT wheel:ALL > -:ALL:ALL This doesn't + anyone, it just - some NOT's, and then - all. You need to + someone before you - all. > If I modified the file to instead have these lines, it works: > +:wheel:ALL > -:ALL EXCEPT wheel:ALL > -:ALL:ALL The third line is pretty, but actually does nothing due to combined logic of the first two. The cleaner practice is to remove the second line. From nobody Fri May 27 21:40:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2BE481B4227D for ; Fri, 27 May 2022 21:40:56 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L8ysg38ljz3hPT for ; Fri, 27 May 2022 21:40:55 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id j25so7475415wrb.6 for ; Fri, 27 May 2022 14:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=uYb5vdqwqMOyDak4rMwbAOWk3XT8oC0O0aO95c+TW4E=; b=qoa1ds1BtjTUxbs41F9lUFekH2+RlvOlDOv1LxVGaIfnZagWptonJTfs4jvAZfTtHY JiPxoPor4doYbNQq4+wV95l5OolJd7yhY8se7Wu65Gvq2AuAToWqAPD324nctVuSnE/R 80WamPWVs9XgYnG4p2n+WSTeMtFF0JU5Ykn9Sqv0g1476+WylkNhClEyjPF7Nbg/bSbQ 5hOByEn8qhXXuRJXTm8qfn7qmoCyYvRsRgI/OMn9F1KAKPZMQIf13I9BJ6CvT7HA4sHw hjLm6DJuZycVOipY66dtjRAa+g81Kktoy7Lw8F/BYHtKr8ws3SV9O0wAB8ObcBucNQiA Juiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=uYb5vdqwqMOyDak4rMwbAOWk3XT8oC0O0aO95c+TW4E=; b=hXzhrGSMT5hDWSNDQE4PgtRrqJJG041UTrwkWvHdVTlUjhzqbdd/M6CKvwZaWYzwTW ysltVMmyZlFJanCsCxetMyF1t1NIF/pkKv47NtjUaa5MNL3Ml0RcTZPJsbbSTdFyrG6Y in9WZtjgUWJcUF5ZjKdlnu4NLmeq5q1GUcDzU1YavpQ+dgnJbjBLGnku56GA4Bqu5Oas EtTjng44TRGsjjMz0u17yIfg4DorErQZluZmjhOsQ+fcbFAea5l7RPesPdud7kMlVCFt L4HMTzCchuBwtbemfQSmpSPvycbopMNEgJ8FNTqVYHiz083x0Id4v40jlJLe6KRXOYWL 4mjw== X-Gm-Message-State: AOAM532zArAYNx0XIRppWCUL6Ld9L7cpGzgX2xDkrkzLGqvS/TCfTmMn 64cgz0EpP/WSfbCh4lcuIWTcn31FnmY= X-Google-Smtp-Source: ABdhPJxsK9K6HZrY1xYHTk9vS0pdVWTuw31KJ2XyMtY2FMcLx/6L1SrKYqw6xcEA1rE4mz2h054kbA== X-Received: by 2002:a05:6000:168a:b0:20f:d6e8:a5b with SMTP id y10-20020a056000168a00b0020fd6e80a5bmr23042872wrd.41.1653687654285; Fri, 27 May 2022 14:40:54 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id l13-20020a5d6d8d000000b0020d0c37b350sm3226314wrs.27.2022.05.27.14.40.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 14:40:53 -0700 (PDT) Message-ID: <1095d74e-f90f-049f-2cff-ee284c197a4a@gmail.com> Date: Fri, 27 May 2022 23:40:45 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: fcntl F_KINFO for Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L8ysg38ljz3hPT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qoa1ds1B; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.40)[-0.401]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Konstantin > When open(2) creates a new file, the vnode name is not entered into > the name cache. I believe this is done to smoother the case like > untarring large set of files, which would replace existing cached > entries with probably not too useful new entries. > > F_KINFO uses name cache to reconstruct the last element of the path, > on most real file systems like UFS. If this last element is not cached, > F_KINFO is unable to return the path. OK, thanks. I'll keep the old KERN_PROC_FILEDESC code then, which seems to work better (though I do have one issue since FrereBSD 13 in code that does a fork()). A+ Paul From nobody Fri May 27 22:13:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EB4831B495D6 for ; Fri, 27 May 2022 22:14:02 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L8zbt2pz8z3mqR for ; Fri, 27 May 2022 22:14:02 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42d.google.com with SMTP id l30so7536357wrb.8 for ; Fri, 27 May 2022 15:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject; bh=jmuJkAPX0ZC9EcusUHMu9ppp4z/uyg+Qoq4s1K+2yXg=; b=kpFxElhW5oqPOFjTFkjRG4CUBlOCKHdcLqrJeft5STFMgozHo/c78tUK+afJXyIF4a P+/cYd4tjshXSMBdtTd2uoI0up4iJjy56cCL48DjE9eD/GKDdtUZuw1VXca4ADcTVXXW xkotxzSW9Dq5dzjmEDw3fqOW2vLm9TbdXDkkOrcFxRvWYI66qjY2Zp2d+BK+S8AwpDzx z6h6FLRV1dZs9AovL9iaQrySqBzpAPwVQoSrCXf9P1wGjDH1Qw7rtTNw5I+P/emqY7WV m3nqXFsCjhNfEdYQ4NyfaWqBKv8WwxWALsMhDZsT8K7jyn6bG5W3bAEfevFrWbFT0DVo cqGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject; bh=jmuJkAPX0ZC9EcusUHMu9ppp4z/uyg+Qoq4s1K+2yXg=; b=rDppTi+VUXMLx2fbqaw85s3sI4IzBRVjXGRr11I+BbuZtiVf5GfaFJGyFDsWT+xThb uy1/R1sp+RO1iuOFLswwmvBzO/xPKmwi0UYa421GVfX4YkJj3WCAu4a+lQ1akHqkswZx 5RwCvRiSS8nmr2gS2fuZsrO/7JwqzGGP95uiKaSrEuwHlhehitEDxlo+BfqprZgXDD3K hAc/ZXxZlYw996/u8yayN2nc0QlvqiZssEyjF1cFK3N7lHdqiiQVbr2dhsFuVhLoQk3I qRmwO0LMU4mleaaGPRroU9ekOn7CpHAslBeXs3s64f9E+R2nDvgsStdDvEUPDUz0fYcS htdw== X-Gm-Message-State: AOAM533OSx9G6WnCHXBq9ymSgTPlMyHeTP50CCwaMTvtqkOlNFrFdqzh yDdE9evQW8amorUgBQxFFhdvfDuct00= X-Google-Smtp-Source: ABdhPJwxGPLTGXBLR9EF5KlqRxyFIP3QrYHno2RxzJiSHaHQ0tM4qJ9Ln15fKq8rhIepeq3cYXJRlA== X-Received: by 2002:a05:6000:1634:b0:210:1dee:4bc0 with SMTP id v20-20020a056000163400b002101dee4bc0mr560391wrb.537.1653689641372; Fri, 27 May 2022 15:14:01 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id k32-20020a05600c1ca000b003975c7058bfsm3181045wms.12.2022.05.27.15.14.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 May 2022 15:14:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------5XxUQTN4h6fYAxHzJ5NA3cZn" Message-ID: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> Date: Sat, 28 May 2022 00:13:52 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 To: FreeBSD Hackers Content-Language: en-US From: Paul Floyd Subject: Hang ast / pipelk / piperd X-Rspamd-Queue-Id: 4L8zbt2pz8z3mqR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kpFxElhW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42d as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.20)[-0.197]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-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-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------5XxUQTN4h6fYAxHzJ5NA3cZn Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi I'm debugging two issues with Valgrind on FreeBSD 13.1 and 14, one on amd64 and one on i386. The 1st testcase, on i386, creates 10 threads that all just then call pause(). Then there is a fork(), the parent does a pause() and the child kills the parent(). The error is reproducible. The second testcase, on amd64, runs a loop for 7 tests, each one creating 2 threads. The thread function writes either to a global variable or various types of TLS, using a nanosleep as a way to yeild between the threads. This hang is intermittent. The above detail is probably not that relevant. In both examples Valgrind is hanging with 100% CPU use. In ktrace where things seem to go wrong there is |9340 none-amd64-freebsd GIO fd 28503 read 1 byte "X" 9340 none-amd64-freebsd RET read 1 9340 none-amd64-freebsd CSW stop user "ast" 9340 none-amd64-freebsd CSW resume kernel "pipelk" 9340 none-amd64-freebsd CSW stop kernel "piperd" 9340 none-amd64-freebsd CSW resume kernel "pipelk" 9340 none-amd64-freebsd CSW stop kernel "piperd" ... repeat until killed That read is a pipe used for the Valgrind scheduler lock. The scheduler runs single threaded, and the read above means that one thread has acquired the lock and should be able to run. Instead it looks like there is an ast that gets the kernel stuck in context switches to pipe read and pipe lock states. kill -9 is the only way out. This all worked OK from FreeBSD 11.3 to 13.0. It's quite difficult to trace this within Valgrind. Both hangs seem quite sensitive to timing - in both cases adding or changing nanosleep times seem to make them no longer hang. Adding debug statements to Valgrind can also change the behaviour (and is also unsafe when not holding the scheduler lock). Does this look like a kernel bug? A+ Paul | --------------5XxUQTN4h6fYAxHzJ5NA3cZn Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi

I'm debugging two issues with Valgrind on FreeBSD 13.1 and 14, one on amd64 and one on i386.

The 1st testcase, on i386, creates 10 threads that all just then call pause(). Then there is a fork(), the parent does a pause() and the child kills the parent(). The error is reproducible.

The second testcase, on amd64, runs a loop for 7 tests, each one creating 2 threads. The thread function writes either to a global variable or various types of TLS, using a nanosleep as a way to yeild between the threads. This hang is intermittent.

The above detail is probably not that relevant.

In both examples Valgrind is hanging with 100% CPU use.

In ktrace where things seem to go wrong there is


  9340 none-amd64-freebsd GIO   fd 28503 read 1 byte
       "X"
  9340 none-amd64-freebsd RET   read 1
  9340 none-amd64-freebsd CSW   stop user "ast"
  9340 none-amd64-freebsd CSW   resume kernel "pipelk"
  9340 none-amd64-freebsd CSW   stop kernel "piperd"
  9340 none-amd64-freebsd CSW   resume kernel "pipelk"
  9340 none-amd64-freebsd CSW   stop kernel "piperd"
... repeat until killed


That read is a pipe used for the Valgrind scheduler lock. The scheduler runs single threaded, and the read above means that one thread has acquired the lock and should be able to run.

Instead it looks like there is an ast that gets the kernel stuck in context switches to pipe read and pipe lock states. kill -9 is the only way out.

This all worked OK from FreeBSD 11.3 to 13.0.


It's quite difficult to trace this within Valgrind. Both hangs seem quite sensitive to timing - in both cases adding or changing nanosleep times seem to make them no longer hang.
Adding debug statements to Valgrind can also change the behaviour (and is also unsafe when not holding the scheduler lock).

Does this look like a kernel bug?

A+
Paul
--------------5XxUQTN4h6fYAxHzJ5NA3cZn-- From nobody Sat May 28 07:02:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 690091B3AE28 for ; Sat, 28 May 2022 07:02:26 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9CKY6Cbcz3lvx for ; Sat, 28 May 2022 07:02:25 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id f23-20020a7bcc17000000b003972dda143eso5684593wmh.3 for ; Sat, 28 May 2022 00:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:references:in-reply-to:content-transfer-encoding; bh=D+abtwZqkQFZ9VTdUudpj9V1NEzEX1qFOhwmCQ98XnE=; b=LlmFNngwTZoqMP6bukzkXnBCyDNTszjxGSbAutDRDGj/+uvfFzXCj590esltda/DLL hXSfuqu8xqGVQd4TNUIHXnv2Dh7MBMZXOTcXe0tst0RQZboMRXue9pOjdEfOC7GQC3rQ R0R7vjJvdBbhcvVmFIY7aYhvP0JUIeybv50du/w8UE1KrJudWcqMrSJJNpX5n1/sWQ5X qcwY1yYR4NKP8HTCEkJyIUjcIBkNFEhayYFJQWmq3nga/PJYt0sEcwSlPRA8tpZr/TvC pD6FdPhIpUHcolz3l4n0jEK1KWwDXLlwHM3DnYCN9Q/Epx5VxNDytUL7zSaVznmXEFSI NgCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:references:in-reply-to :content-transfer-encoding; bh=D+abtwZqkQFZ9VTdUudpj9V1NEzEX1qFOhwmCQ98XnE=; b=ZvjwYVITFZqiO9sxvTDKBfnksqlIHukyilAxxWTMG+wt6tutB+SzNG07gL3qearw9o 4VdSOzl3KJIxMUyp1iPqv+AMvQDTvB0YWeK49L9X5NdECxBK25ZglaSyyI5IxLTN37Mf h+t1Ix80vzmqyA8lcp4Qk3dLVUtss8nh1hgSaQntncn2ol7PFiN8/0epJ5udMD65Snt5 uSWtiSLABlVoNTM0YcJ9P+ghTCc6lgJSFx3qBlMdhmw6vHbbyP7R7PtZrG62cjOz6LTI vBWOS7dirLdeQArD7wJbZ8RQuNOg+t963XvKorusF896d/TLnQ2egSGACCs6K09mRKoS 5A+w== X-Gm-Message-State: AOAM531d/8JOnyPA0jcmvUUAB+lTy+fBBe5qY9VpayvgA8tXDovdxvVT k9mUxC53Y/mI/nGEkYFrYDSxYTIcmJE= X-Google-Smtp-Source: ABdhPJxpRmsb3qiYrf8xV7RCPAPABJ9bjGpQPm6LZ5StH4V6SPhQJw/Ss7afl9lMYAZVFi9wNgwZ6A== X-Received: by 2002:a05:600c:3549:b0:397:8f09:1abe with SMTP id i9-20020a05600c354900b003978f091abemr4559152wmq.107.1653721344777; Sat, 28 May 2022 00:02:24 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id o11-20020a1c750b000000b00397550b387bsm4695134wmc.23.2022.05.28.00.02.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 28 May 2022 00:02:24 -0700 (PDT) Message-ID: Date: Sat, 28 May 2022 09:02:23 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Hang ast / pipelk / piperd Content-Language: en-US From: Paul Floyd To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> In-Reply-To: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4L9CKY6Cbcz3lvx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LlmFNngw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.62 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.977]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.36)[0.360]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/27/22 22:13, Paul Floyd wrote: > > Hi > > I'm debugging two issues with Valgrind on FreeBSD 13.1 and 14, one on > amd64 and one on i386. > ... > |Both hangs seem quite sensitive to timing - in both cases adding or > changing nanosleep times seem to make them no longer hang. | > |Adding debug statements to Valgrind can also change the behaviour > (and is also unsafe when not holding the scheduler lock). Does this > look like a kernel bug? | |One important detail I missed out. Why is Valgrind releasing the scheduler lock?| | | |To make a client syscall. This needs to be done in "client-like" circumstances - specifically, with the client signal mask (rather than the Valgrind mask, which is to mask all signals so that Valgrind has full control).| |Two things can happen with a client syscall.| |1/ it succeeds, and Valgrind will re-acquire the lock and continue.| |2/ it gets interrupted, Valgrind re-acquires the lock, does a load of stuff to fixup the guest state and take the appropriate action (restart, return EINTR, save carry etc).| | | |I did think that 2/ might be prone to get into an infinite loop, especially with restart. But I don't see anything like that in the Valgrind logs.| PJF thread 14 making a client nanosleep syscall |SYSCALL[5379,14](240) sys_nanosleep ( 0x200890, 0x0 ) --> [async] ... | |PJF -thread 14 releases the scheduler lock --5379--   SCHED[14]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys | |PJF thread 2 acquires the scheduler lock --5379--   SCHED[2]:  acquired lock (VG_(client_syscall)[async]) || | |PJF thread 2 return from nanosleep SYSCALL[5379,2](240) ... [async] --> Success(0x0) PJF thread 2 making a client write syscall SYSCALL[5379,2](  4) sys_write ( 1, 0x4ea9000, 48 ) --> [async] ... PJF thread 2 releases the scheduler lock --5379--   SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys PJF this is the thread 2 printf from syscall write tls_ptr: case "race" has mismatch: *ip=8 here=4 PJF thread 2 acquires the scheduler lock --5379--   SCHED[2]:  acquired lock (VG_(client_syscall)[async]) PJF thread 2 return from write (30 bytes written) SYSCALL[5379,2](  4) ... [async] --> Success(0x30) PJF thread 2 making a client nanosleep syscall SYSCALL[5379,2](240) sys_nanosleep ( 0x200890, 0x0 ) --> [async] ... PJF thread 2 releases the scheduler lock --5379--   SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys | |And that's it, it hangs making the client nanosleep syscall.| | | |A+| |Paul | || From nobody Sun May 29 00:10:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1290E1B472F4 for ; Sun, 29 May 2022 00:10:45 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [209.51.186.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9f842jvCz3jJ9 for ; Sun, 29 May 2022 00:10:44 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.3] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 137577ACD for ; Sun, 29 May 2022 00:10:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 137577ACD Message-ID: Date: Sat, 28 May 2022 20:10:36 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: fcntl F_KINFO for Content-Language: en-US To: freebsd-hackers@freebsd.org References: <5e7863b6-4c57-16a2-0b54-655defefb347@gmail.com> From: Allan Jude In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4L9f842jvCz3jJ9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 209.51.186.6 is neither permitted nor denied by domain of allanjude@freebsd.org) smtp.mailfrom=allanjude@freebsd.org X-Spamd-Result: default: False [-0.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[allanjude]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.07)[0.066]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:209.51.160.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/14/2022 3:53 PM, Konstantin Belousov wrote: > > When open(2) creates a new file, the vnode name is not entered into > the name cache. I believe this is done to smoother the case like > untarring large set of files, which would replace existing cached > entries with probably not too useful new entries. > > F_KINFO uses name cache to reconstruct the last element of the path, > on most real file systems like UFS. If this last element is not cached, > F_KINFO is unable to return the path. > Now that caches are bigger, might it make sense to have open() w/ O_CREAT create these namecache entries? Maybe we could purposely insert them in the middle of the list or something to avoid them pushing out other new entries or something. Specifically, having a more reliable way to get the path from an FD would be very useful, and maybe we need to reconsider some of the classic tradeoffs. -- Allan Jude From nobody Sun May 29 13:54:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B15831B3FAF6 for ; Sun, 29 May 2022 13:55:05 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LB0RD5HrJz3hML for ; Sun, 29 May 2022 13:55:04 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: by mail-pl1-x629.google.com with SMTP id q4so8105166plr.11 for ; Sun, 29 May 2022 06:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=MiB/UM5318Jaf0qbjelbdNO6oKvHj28fIbXvrhWervQ=; b=jXkw9LjqulvIsQdTARZImUt/qto7UaLoxkKHaOhGPqUoKviBbM3mrAGCH0X89bRw4Q Parv6PKX2v4fXIW7gGnQ0Utvz54JULXHJWY55UnbulQGSFbJEZPEtwVa4HVordqGqoG7 AzlnbvH/8tB6N0foUZ5Je16MR0G9miKRlri+b5UFhIS4/eyWqYIbAFFZjA+vm2IKRjQ6 YOggdzoQy9gzZtl7FV8wCfX0IL8roLaXsXTRH+2kkFbJgL6JSZJDYYEt7qPTd8Vb6ZOf KpE3OMFOuz0yurrli4vfumfHJjcWVxtwgt9jvkQmgQoqE5Xkk25jFpoadFuB9whmNlqF Q51A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=MiB/UM5318Jaf0qbjelbdNO6oKvHj28fIbXvrhWervQ=; b=tS43V6SrqnS6onC5CCCxX6Q9Y+FLsiPJAnyLBMq3b1nt8WrERVnJI84Uw6bXlSKOHV rZs6mdqXMDTRUID3O69WBzf00FzkrQvwfSu7ahJMG4G65DUmy93OvmRZjXYk2vLyFgG/ fRBc6fn14FM57pAALLwrotx5xftkASB9MwePIeRtr2kzYHRCalwFNgFy9jkMgjkzj1vg Aw16xYZ2tN0FV83mM8z0EMjcZGRSF5MeGHYxCKbggJyo4NSA5YRvqmZqTr6QZyr0JLWG 4U1PAHvnHtKgpuIMFK53ZvYpWxH38ddviX77Lb3tQX1AM36iqJYAxiz2HN3IffnOk4bA fN/g== X-Gm-Message-State: AOAM530Xevqbk5OVbH+zOGWheYmNDOoGvsj3Ln1sDp83eyTK3JMhBVMi 3wdICeG5GokZIIh49PE6ALJgOlP5ft7SJmN9 X-Google-Smtp-Source: ABdhPJxCHUvSSJ3G6bAY5bHHdx6WHAWjHZlVe5B/ozkroWLYhnaJRjWRD2XwYfsWgtw0t4uzxfog5w== X-Received: by 2002:a17:902:ee54:b0:163:bdf4:1112 with SMTP id 20-20020a170902ee5400b00163bdf41112mr5555846plo.89.1653832497929; Sun, 29 May 2022 06:54:57 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:5430:10b1:2c4c:3814:f89d:eb4f]) by smtp.gmail.com with ESMTPSA id 13-20020a170902e9cd00b0015f309f14d0sm1117807plk.56.2022.05.29.06.54.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 May 2022 06:54:57 -0700 (PDT) From: Christopher Bowman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: putchar in boot1.c adds extra blank lines on Xilinx ZYNQ board with U-boot 2020.04 Message-Id: <3D090089-F20B-4B5D-A589-391E6536A875@chrisbowman.com> Date: Sun, 29 May 2022 06:54:56 -0700 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 4LB0RD5HrJz3hML X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chrisbowman-com.20210112.gappssmtp.com header.s=20210112 header.b=jXkw9Ljq; dmarc=none; spf=none (mx1.freebsd.org: domain of crb@chrisbowman.com has no SPF policy when checking 2607:f8b0:4864:20::629) smtp.mailfrom=crb@chrisbowman.com X-Spamd-Result: default: False [-1.66 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[chrisbowman-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[chrisbowman.com]; NEURAL_SPAM_SHORT(0.14)[0.143]; DKIM_TRACE(0.00)[chrisbowman-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::629:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Looking at /usr/src/stand/efi/boot1/boot1.c The bottom of the file has: void putchar(int c) { CHAR16 buf[2]; if (c =3D=3D '\n') { buf[0] =3D '\r'; buf[1] =3D 0; ST->ConOut->OutputString(ST->ConOut, buf); } buf[0] =3D c; buf[1] =3D 0; ST->ConOut->OutputString(ST->ConOut, buf); } On my platform this results in an extra blank line after each new line. I=E2=80=99m running on a Xilinx ZYNQ board with U-boot 2020.04. Does this blank line show on other platforms too? If so is this the = desired functionality? Perhaps it=E2=80=99s needed for serial consoles = to work right? I=E2=80=99m running locally with the if statement completely removed and = that fixes the extraneous blank lines I see. Regards, Christopher= From nobody Sun May 29 15:03:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9884C1B5561B for ; Sun, 29 May 2022 15:04:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LB1yw2S32z3pkN for ; Sun, 29 May 2022 15:04:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa32.google.com with SMTP id n20so289160vkl.9 for ; Sun, 29 May 2022 08:04:08 -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=+LqHnVeiWVOS6i23b2SKpHm2xuc+so9woATIN6xxnAE=; b=JL1t+p27wybgGtNrwBKALY8GIGyJ5IKKTfeTtqjzPG3m1HwtjZUTQfDnA7ByUI95XI glyeAiVX1JJZ9tZ1cWm+W24xXyzPpQ785/Yrd4boRQx/NlZkd1v/7ocBQP5lJYlnQMQh SnsZYsZyZgxyULQIPivQjF/aYXTPB2bSHcCzUXvCJIKj8ZD2wJdsO/Z70GDRUnvhRMmF Gihg5i5+KikbT5+4p4p734g0AYpFJNHstj8gxtQnT195WYCV87FWSC8RJJkZ0IwHnbu+ aorXHQgqNglqAFnMVqCvvbIr/yZLA0aW104nUWMLyPgJYE9dj8eqb9YQi3Hb7ybTmCxX ZW8Q== 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=+LqHnVeiWVOS6i23b2SKpHm2xuc+so9woATIN6xxnAE=; b=kKcecQvEeqfnPgj3K7kN0JFkrZC1LpRrpFK/9w2CPxwRJExeLm3jHjjeel36cG2lwQ jZzH9rlXL1SnFinaTnyigRi40LfVbS0/2IQLsb0q1XyQPP9rvOMXfhQ1x4HSMaZ8ndnT 9otSag67AsKqimtZfrf0pfndKNPR6vIE2kxsJgNNwmHIy7uDkJloWKH7pmdovA1kYwjd sAVcVY03nOjtXLgdhfItv05hPvVe2oVxNCh3S3bk5AKUytCyB3xM02Vl6HVNjs/17R91 uIcSkVAMTaBaMULibsSapi3S5cw4WjURPFVKZXH8DuapShVPTqlrEtzpOYz09NQ6uJlu jPYQ== X-Gm-Message-State: AOAM531vGZLVuY6P4raPJGXe49VO+jRmj2Ak8sWoIni6QvY4fjHh5Yrw ipMUutjXSGRfVpFcnCpzIMXMEWUL9yE3YgqnE+dzOHsQZ3E= X-Google-Smtp-Source: ABdhPJw2Ka9It76bH8JEMXDisEhOs8RRa27mvuzUS/0IXMWUKd89jrOiojw3ty0nLR9CNUipn/d9MYSXEc0ZJm4K2KE= X-Received: by 2002:a1f:5981:0:b0:358:4f47:b321 with SMTP id n123-20020a1f5981000000b003584f47b321mr7748035vkb.3.1653836647733; Sun, 29 May 2022 08:04:07 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <3D090089-F20B-4B5D-A589-391E6536A875@chrisbowman.com> In-Reply-To: <3D090089-F20B-4B5D-A589-391E6536A875@chrisbowman.com> From: Warner Losh Date: Sun, 29 May 2022 09:03:56 -0600 Message-ID: Subject: Re: putchar in boot1.c adds extra blank lines on Xilinx ZYNQ board with U-boot 2020.04 To: Christopher Bowman Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e7b02205e027d901" X-Rspamd-Queue-Id: 4LB1yw2S32z3pkN X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=JL1t+p27; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a32) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [0.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.971]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.961]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a32:from]; NEURAL_SPAM_LONG(1.00)[0.995]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000e7b02205e027d901 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 29, 2022, 7:56 AM Christopher Bowman wrote: > Looking at /usr/src/stand/efi/boot1/boot1.c > > The bottom of the file has: > void > putchar(int c) > { > CHAR16 buf[2]; > > if (c =3D=3D '\n') { > buf[0] =3D '\r'; > buf[1] =3D 0; > ST->ConOut->OutputString(ST->ConOut, buf); > } > buf[0] =3D c; > buf[1] =3D 0; > ST->ConOut->OutputString(ST->ConOut, buf); > } > > On my platform this results in an extra blank line after each new line. > > I=E2=80=99m running on a Xilinx ZYNQ board with U-boot 2020.04. > > Does this blank line show on other platforms too? If so is this the > desired functionality? Perhaps it=E2=80=99s needed for serial consoles t= o work > right? > I=E2=80=99m running locally with the if statement completely removed and = that > fixes the extraneous blank lines I see. > No other platform does that... in fact, no carriage return would mess up other platforms. It's needed everywhere for all kinds of consoles. Warner Warner > Regards, > Christopher > --000000000000e7b02205e027d901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 29, 2022, 7:56 AM Christopher Bowman <<= a href=3D"mailto:crb@chrisbowman.com">crb@chrisbowman.com> wrote:
Looking at /usr/src/stand/efi/boot1/b= oot1.c

The bottom of the file has:
void
putchar(int c)
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 CHAR16 buf[2];

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (c =3D=3D '\n') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 buf[0] =3D '\r&= #39;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 buf[1] =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ST->ConOut->O= utputString(ST->ConOut, buf);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 buf[0] =3D c;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 buf[1] =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ST->ConOut->OutputString(ST->ConOut, b= uf);
}

On my platform this results in an extra blank line after each new line.

I=E2=80=99m running on a Xilinx ZYNQ board with U-boot 2020.04.

Does this blank line show on other platforms too?=C2=A0 If so is this the d= esired functionality?=C2=A0 Perhaps it=E2=80=99s needed for serial consoles= to work right?
I=E2=80=99m running locally with the if statement completely removed and th= at fixes the extraneous blank lines I see.

No other platform does that... in= fact, no carriage return would mess up other platforms. It's needed ev= erywhere for all kinds of consoles.=C2=A0

=
Warner=C2=A0

Warner
Regards,
Christopher
--000000000000e7b02205e027d901-- From nobody Sun May 29 22:19:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A38921B5B1A6 for ; Sun, 29 May 2022 22:19:19 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBCd24g1Zz3kfM for ; Sun, 29 May 2022 22:19:18 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id h62-20020a1c2141000000b0039aa4d054e2so1370594wmh.1 for ; Sun, 29 May 2022 15:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=+SOACLx5Sq7mJBzu5aNqtkgiAOzzRYs0rp5ucWGRMa8=; b=ebdCMYcg5cgdWDmSO8rzrQEB51d9mR18HGJ15xLOwD5GIh3/ORR6KzdOqdpwXIYTtz KUhaJ6Qoq7BB82ZUFZI6zpuSZhsuk5qlOLgVd1lAjIuL+yRHhdo6PBfjQHmkb8CJ4KZj yMwo55Go35qpbkiqz0fz+RGnX13cOu3MG6i3p0VwqGjm8rjRYuJmfJ8dDNrZ/9fZAzx4 f86iSzr2WMc/CMLxDB1S5Et9034Dc5uZDNGmFT7yixLsj1ioYIUEV3GI/iE6cVb8gUqW 0x6snuL94q4N6GKElHLqws4OJbRyfWAKu1k99OdG8UPxodrPocvhr/G10nuF1OOjLTIJ KTtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=+SOACLx5Sq7mJBzu5aNqtkgiAOzzRYs0rp5ucWGRMa8=; b=wsyZZ11VyemTJgL81g9EmANsXC2Oyrxp4VOo6jb9LAWhzLrLQYd+Jp7bRIGi1qwgse MWqBEfqEEkhQOD6gbAxjAKvnYKdXMlY2OlGdW+mejmIqFya1A5RSwYhNnLNL/U7ko4WE QlR9WIXXdTAjp12b4PR9ePlrowJdJN7EsgiEvXOYtDpbGj8NMrXWX1NXNnzi+wvH4lkJ y54cZY8jPetDrtNJ+T0kN+TGpZwmJ55ihRX2r02OVv4D8m9p+BKZ2xgzhluhi10iylXF Db1fWnsRRS9uag2wMN/omGY0a1S1mDn3Goj44QAPLVOOED9C65EwDeVsjrG8aqsOttMv 00Fw== X-Gm-Message-State: AOAM532WsiL5W/14vvqKJo2AJ9Hmkbr11DJl2O210OUF8Oor/YjT8Vts zffwDKJeeerGim1uYseHnY1BZ0MkHgY= X-Google-Smtp-Source: ABdhPJxv3uCJ6uru+OkiN5mmxgGBPxBXSFgFWxadoWP7kiBBdu+UgmB4Hvh2WLPvUPbF0tKHUNnhew== X-Received: by 2002:a05:600c:acf:b0:397:345f:fe10 with SMTP id c15-20020a05600c0acf00b00397345ffe10mr16739510wmr.15.1653862757414; Sun, 29 May 2022 15:19:17 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id e15-20020a056000178f00b002102f2fac37sm2706054wrg.51.2022.05.29.15.19.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 May 2022 15:19:17 -0700 (PDT) Message-ID: Date: Mon, 30 May 2022 00:19:15 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 From: Paul Floyd Subject: Re: Hang ast / pipelk / piperd To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> Content-Language: en-US In-Reply-To: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LBCd24g1Zz3kfM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ebdCMYcg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::330 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.97)[0.966]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::330:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/27/22 22:13, Paul Floyd wrote: > > Hi > > I'm debugging two issues with Valgrind on FreeBSD 13.1 and 14, one on > amd64 and one on i386. > ... > |Both hangs seem quite sensitive to timing - in both cases adding or > changing nanosleep times seem to make them no longer hang. | > |Adding debug statements to Valgrind can also change the behaviour > (and is also unsafe when not holding the scheduler lock). Does this > look like a kernel bug? | thunderbird munged the formatting when I switched to plain text so I'm sending again. One important detail I missed out. Why is Valgrind releasing the scheduler lock?| To make a client syscall. This needs to be done in "client-like" circumstances - specifically, with the client signal mask (rather than the Valgrind mask, which is to mask all signals so that Valgrind has full control).| Two things can happen with a client syscall.| 1/ it succeeds, and Valgrind will re-acquire the lock and continue.| 2/ it gets interrupted, Valgrind re-acquires the lock, does a load of stuff to fixup the guest state and take the appropriate action (restart, return EINTR, save carry etc).| I did think that 2/ might be prone to get into an infinite loop, especially with restart. But I don't see anything like that in the Valgrind logs.| PJF thread 14 making a client nanosleep syscall |SYSCALL[5379,14](240) sys_nanosleep ( 0x200890, 0x0 ) --> [async] ... PJF -thread 14 releases the scheduler lock --5379--   SCHED[14]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys PJF thread 2 acquires the scheduler lock --5379--   SCHED[2]:  acquired lock (VG_(client_syscall)[async]) PJF thread 2 return from nanosleep SYSCALL[5379,2](240) ... [async] --> Success(0x0) PJF thread 2 making a client write syscall SYSCALL[5379,2](  4) sys_write ( 1, 0x4ea9000, 48 ) --> [async] ... PJF thread 2 releases the scheduler lock --5379--   SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys PJF this is the thread 2 printf from syscall write tls_ptr: case "race" has mismatch: *ip=8 here=4 PJF thread 2 acquires the scheduler lock --5379--   SCHED[2]:  acquired lock (VG_(client_syscall)[async]) PJF thread 2 return from write (30 bytes written) SYSCALL[5379,2](  4) ... [async] --> Success(0x30) PJF thread 2 making a client nanosleep syscall SYSCALL[5379,2](240) sys_nanosleep ( 0x200890, 0x0 ) --> [async] ... PJF thread 2 releases the scheduler lock --5379--   SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys And that's it, it hangs making the client nanosleep syscall. Under gdb I see (and this is quite variable) (gdb) info thread Id Target Id Frame * 1 LWP 100073 of process 861 vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-amd64-freebsd.S:135 2 LWP 100215 of process 861 vgModuleLocal_do_syscall_for_client_WRK () at m_syswrap/syscall-amd64-freebsd.S:135 3 LWP 100216 of process 861 0x00000000380bffac in do_syscall_WRK () 4 LWP 100217 of process 861 0x00000000380bffac in do_syscall_WRK () 5 LWP 100218 of process 861 0x00000000380bffac in do_syscall_WRK () 6 LWP 100219 of process 861 0x00000000380bffac in do_syscall_WRK () 7 LWP 100220 of process 861 0x00000000380bffac in do_syscall_WRK () 8 LWP 100221 of process 861 0x00000000380bffac in do_syscall_WRK () 9 LWP 100222 of process 861 0x00000000380bffac in do_syscall_WRK () 10 LWP 100223 of process 861 0x00000000380bffac in do_syscall_WRK () 11 LWP 100224 of process 861 0x00000000380bffac in do_syscall_WRK () 12 LWP 100225 of process 861 0x00000000380bffac in do_syscall_WRK () 13 LWP 100226 of process 861 0x00000000380bffac in do_syscall_WRK () 14 LWP 100227 of process 861 0x00000000380bffac in do_syscall_WRK () 15 LWP 100228 of process 861 0x00000000380bffac in do_syscall_WRK () do_syscall_WRK is the syscall interface for the Valgrind host, and that will be the threads waiting for the lock. Thread 1 and 2 are in do_syscall_for_client, the interface for guest syscalls. Thread 1 is doing a _umtx_op syscall, for the pthread_join. Thrread 2 is doing a nanosleep. These are blocking syscalls so they release the lock before making the syscall to allow other threads to execute. I think that in the snapshot above, the lock is released and one of threads 3 to 15 should be obtaining the lock and running. That's where the kernel context switch / AST seems to be going wrong. I don't see anything particularly wrong on the Valgrind side. Any ideas what I can do to see why the context switch is hanging? A+ Paul From nobody Mon May 30 14:15:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EF2EA1B57543 for ; Mon, 30 May 2022 14:15:57 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBcrp2H51z3qWD for ; Mon, 30 May 2022 14:15:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72f.google.com with SMTP id 199so1092506qkk.0 for ; Mon, 30 May 2022 07:15:54 -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=VAMEilGBr2FIFaqLB3vQWkQ0EyDvcftYN86dYIJmVFs=; b=qRTZUqjOZf4uQ/yT3sp0v/x94wY4v8zbSp9CdtFbX0viWfjDjfqXJ2cAE2A18qSw4c nJcBl6YbKjqOUxfDM+72xyNI3LLzrcL+PBG5eifcqjag8zUqdBbJGbe3jTsRiENAqGj1 sGrck6jKqO3rselqB7acsZpVdcmUAUwq3S23++K//6sEkAfwOE2DfgTYrX7x8XUK2hG1 lvNfO7K77yKpCzxnGDupT0mYfq+tp7GpGSmNFexZ9wGOpNO+yKYwhoFlMc2DI/erYD2r Ari1yW0q20dlNEHbK6hFpn5wW7xH3CsEfJYwOoIsFUkofkuiEMTyAx/2AnKyCzaCH8pR CGiA== 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=VAMEilGBr2FIFaqLB3vQWkQ0EyDvcftYN86dYIJmVFs=; b=6TxcvErfLGi+WuU+ulzXiW0vVtjU5JXHEGAgV3RHCk8FIdp7mqMgAboqjkbBHj+9ci Ly42poUJDiJzy2Jq0H6kIvjE96jqs3uzKEtlB02p8NfSAjv4UOtHBUJ6hMXTl1oVbGvo YIrfmnIXG8RQZc71DUBzRZ9DYj3pImTv01N7SejmBwlPPwPbybzty2/h0XtBEfPh67UG OD7JFH3kkcRhet5hN/zimg91fkpu0El0nChRFu6SeNBTVZmZnf1aMD4sCDuTsMpPFM/N FhGEiG3Ena3r8sne5y3FLTwW8ahh7tvIiWr0dy1m7Y6tGhAYBZ/gL/C91SM2onL9tPjz E80Q== X-Gm-Message-State: AOAM532S9wjIhnS0qDiOZjzqPkMtwZSe1Gzu3UaQbUrjudCz/rtgDaLh /vjkK+Vk4s3lYfsZPqhBmn5tfUWgpQY= X-Google-Smtp-Source: ABdhPJziHBgSbazJwoZNMwJCzMpid7j48fs5H7sViPlxjikhoI8ofmYoKHMYOYwUnKZztOqQtGGnbQ== X-Received: by 2002:a37:a1d0:0:b0:6a3:647a:675e with SMTP id k199-20020a37a1d0000000b006a3647a675emr29766980qke.399.1653920147594; Mon, 30 May 2022 07:15:47 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id k10-20020a05620a142a00b0069fc13ce235sm7612147qkj.102.2022.05.30.07.15.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 May 2022 07:15:46 -0700 (PDT) Date: Mon, 30 May 2022 10:15:43 -0400 From: Mark Johnston To: Paul Floyd Cc: FreeBSD Hackers Subject: Re: Hang ast / pipelk / piperd Message-ID: References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LBcrp2H51z3qWD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qRTZUqjO; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.69 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.99)[-0.994]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 30, 2022 at 12:19:15AM +0200, Paul Floyd wrote: > > On 5/27/22 22:13, Paul Floyd wrote: > > > > Hi > > > > I'm debugging two issues with Valgrind on FreeBSD 13.1 and 14, one on > > amd64 and one on i386. > > > ... > > |Both hangs seem quite sensitive to timing - in both cases adding or > > changing nanosleep times seem to make them no longer hang. | > > |Adding debug statements to Valgrind can also change the behaviour > > (and is also unsafe when not holding the scheduler lock). Does this > > look like a kernel bug? | > > [...] > > Under gdb I see (and this is quite variable) > > (gdb) info thread > Id Target Id Frame > * 1 LWP 100073 of process 861 vgModuleLocal_do_syscall_for_client_WRK > () at m_syswrap/syscall-amd64-freebsd.S:135 > 2 LWP 100215 of process 861 > vgModuleLocal_do_syscall_for_client_WRK () at > m_syswrap/syscall-amd64-freebsd.S:135 > 3 LWP 100216 of process 861 0x00000000380bffac in do_syscall_WRK () > 4 LWP 100217 of process 861 0x00000000380bffac in do_syscall_WRK () > 5 LWP 100218 of process 861 0x00000000380bffac in do_syscall_WRK () > 6 LWP 100219 of process 861 0x00000000380bffac in do_syscall_WRK () > 7 LWP 100220 of process 861 0x00000000380bffac in do_syscall_WRK () > 8 LWP 100221 of process 861 0x00000000380bffac in do_syscall_WRK () > 9 LWP 100222 of process 861 0x00000000380bffac in do_syscall_WRK () > 10 LWP 100223 of process 861 0x00000000380bffac in do_syscall_WRK () > 11 LWP 100224 of process 861 0x00000000380bffac in do_syscall_WRK () > 12 LWP 100225 of process 861 0x00000000380bffac in do_syscall_WRK () > 13 LWP 100226 of process 861 0x00000000380bffac in do_syscall_WRK () > 14 LWP 100227 of process 861 0x00000000380bffac in do_syscall_WRK () > 15 LWP 100228 of process 861 0x00000000380bffac in do_syscall_WRK () > > do_syscall_WRK is the syscall interface for the Valgrind host, and that > will be the threads waiting for the lock. > > Thread 1 and 2 are in do_syscall_for_client, the interface for guest > syscalls. Thread 1 is doing a _umtx_op syscall, for the pthread_join. > Thrread 2 is doing a nanosleep. These are blocking syscalls so they > release the lock before making the syscall to allow other threads to > execute. > > I think that in the snapshot above, the lock is released and one > of threads 3 to 15 should be obtaining the lock and running. > > That's where the kernel context switch / AST seems to be going wrong. > > I don't see anything particularly wrong on the Valgrind side. > > Any ideas what I can do to see why the context switch is hanging? "procstat -kk " might help to reveal what's going on, since it sounds like the hand/livelock is happening somewhere in the kernel. From nobody Mon May 30 16:16:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0389B1B58F5F for ; Mon, 30 May 2022 16:16:20 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBgWl1zbHz4fjj for ; Mon, 30 May 2022 16:16:19 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id p10so15291167wrg.12 for ; Mon, 30 May 2022 09:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=W89a8YKF3MtouVBt3PTGEenWKvRsvufvFY9tkNhNy6o=; b=R+FxFrQHWffdy6icIM4Qfk4YYcXB8REgLaz6Eb8kTuhETLNLMslRtgedbftAVxGmpI qP7Iq3BuSSoLgLcjVn7/ydd9VcoevJFNtIgI0NXA45hozuZgJYyrluThWNfs8b0DHvF+ z+A9Yhcy3pg0XkBJMZmrnGRFuwS2Zh8NXM3Lv4fP1Y53QF471Iiyrzo848UYAknVMQV1 LSMY2SiSOKgc5OEql3F4N4Of971N/cIxdCEoMjtVujYfkZFxWhqfpWad+q/dHZNiecyR eNT7ZUxVYoL/U35Z06BSCzdSiYcTJyDTAGoK1C4Fp2emBJE6YlBG9vbtqcDlbU3Be6Xb egbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=W89a8YKF3MtouVBt3PTGEenWKvRsvufvFY9tkNhNy6o=; b=BNN6F7YMCZIbDd9+/5Tyv9JlHlGPuUjwm5SdDZD4+vzA9CHYhUlju4knPefvDyWzB5 pKVXBkd6ZUOM2FmfiOKvK5Pn4rZmfUuANPwQrR9Kusg7M2NR6DJZMx1oX55f5yRQ/KZ+ mRy7F8F0hsugZJdJjzf3WGTsRxVwHXI/B7qhKnlIka06RM2yNN8AM+hHpUJS+eT1WNNV nIZTpH5UTCttI0WBcQgxqelFeqz4u8gqRiyhX1qCtkpxBV6cgJ0Ogsh6GiULntsdUZos aJRyqcidOYCGqmfJQPv1Ilo4PnyTTy3GPl1fkUBPXHKjmWszfYjdxee8t+RoDg1Km7jl VA6A== X-Gm-Message-State: AOAM530YSjHwLVtu+36CFUk4ZUg3D2rUnOqv5Y7vKkMn4g8nopoG9Yhx k5whwasZLGV7ZIVOREML/f0lyQZy3G372w== X-Google-Smtp-Source: ABdhPJybSilsk8+oaN4kl8P8xbmqst00Qw5/io/VJcj0wfKUtP55PTkGkEGxwGbyslvwweIoyIvYtQ== X-Received: by 2002:adf:ee8d:0:b0:210:1873:c3d9 with SMTP id b13-20020adfee8d000000b002101873c3d9mr14351568wro.696.1653927378269; Mon, 30 May 2022 09:16:18 -0700 (PDT) Received: from [137.202.243.61] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id v1-20020a5d4b01000000b0020d0435c97bsm9405098wrq.92.2022.05.30.09.16.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 09:16:17 -0700 (PDT) Message-ID: Date: Mon, 30 May 2022 18:16:16 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: Hang ast / pipelk / piperd To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> From: "Floyd, Paul" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LBgWl1zbHz4fjj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=R+FxFrQH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=paulf2718@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]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(1.00)[0.999]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Mark > "procstat -kk " might help to reveal what's going on, > since it sounds like the hand/livelock is happening somewhere in the > kernel. I'll have a go tonight and see what that does. A+ Paul From nobody Mon May 30 18:00:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B656E1B43E4E for ; Mon, 30 May 2022 18:00:43 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBjrB6PN7z4tnH for ; Mon, 30 May 2022 18:00:42 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id s24so8340928wrb.10 for ; Mon, 30 May 2022 11:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=qyD0UWlBXJhNQCaLQJ+8ti9CK7DdukrlJrnLj+DIuCs=; b=ZxsMhw/EXS31HEZse5Jaxyar+eM/cBjbMizcO5Wu18J8wSXD+1Z8EyGbiB32jzEZcF QnKZ9TFzO9/5TKNIrCNMJIXpu4JOkVvwi/veZgL0NKWeeZH2RAualCF3PfcTAnoHhCEb aWBXhEhx6W8VH4hoKHN2jCmtpVNySKaagk4AxM3lngBBxnUafYjggEALw2H+I4KZ8NYE 6EGLwRAezYR+uefIazanMKXfj30uFHgNY+alpeDlQ/avDejfRVJvYFKpyJqXC8xGmNBY k2esAR2JHHtCYEKT+XyNv9akxuGY7tnAY45fhho8YDA1f4tvLndtuT8Y70/LbY9Lu/i5 IFCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=qyD0UWlBXJhNQCaLQJ+8ti9CK7DdukrlJrnLj+DIuCs=; b=tGApLbN/CVyyOXZSjCPTIsS5hfbC158dVx/TE+ifXh7DQbovGsEtv6bv8UrtwtSlAV sB6JXrMrXj+EigiHf6Zz+xy1mJ0oDo9OZ8wB7cn7qXcVJQkPr4+W6u6o2nxAkWqdbIzv 8rtEB16NuJ5DV/zQI9zt7etTOLuufDWDmJFouFWzVTOyYOzUd7XEAGvvRnq0fZJIhhvz 3U5cODVtgkWFeYXsfUinuNRdD41p/r0XCLkp2PcilgBuxMV9OlZ+Lt6/UvNl7GNksF/b +IbDzZmIpFh/lDCzURld8X0/7HCXQtdB0M99hTTT5ANpFLSVJcVjjV5aclz8cwP5HD1N LcOA== X-Gm-Message-State: AOAM530QU4Ja+GQ+jAnZiztGcEO0qjPRaMsvmQ41wSyaFmFo2+DR8C2i 3zjdYLAVJO/6vcJ/6+T8XPVGnOsxzHcnyQ== X-Google-Smtp-Source: ABdhPJyZ90/Dkrzw2i3Zsjqn9UXcqeM/C+yy8itNFYIQNzg5ONSLrSf5FCHsp61gOjsRHKVRMDSMPA== X-Received: by 2002:adf:f2cb:0:b0:20f:d291:7064 with SMTP id d11-20020adff2cb000000b0020fd2917064mr35068436wrp.319.1653933641815; Mon, 30 May 2022 11:00:41 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id n64-20020a1ca443000000b003973b9d0447sm12901243wme.36.2022.05.30.11.00.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 11:00:41 -0700 (PDT) Message-ID: <0eb6bf73-475e-ace9-3df8-e96a6bb2cb96@gmail.com> Date: Mon, 30 May 2022 20:00:40 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Hang ast / pipelk / piperd Content-Language: en-US To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LBjrB6PN7z4tnH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ZxsMhw/E"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.68)[-0.675]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > "procstat -kk " might help to reveal what's going on, > since it sounds like the hand/livelock is happening somewhere in the > kernel. Hi Here is the output paulf@freebsd:~ $ procstat -kk 864 PID TID COMM TDNAME KSTACK 864 100075 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 umtxq_sleep+0x143 do_wait+0x3e5 __umtx_op_wait+0x53 sys__umtx_op+0x7e amd64_syscall+0x10c fast_syscall_common+0xf8 864 100175 none-amd64-freebsd - mi_switch+0xc2 intr_event_handle+0x167 intr_execute_handlers+0x4b Xapic_isr1+0xdc setrunnable+0x31 wakeup_one+0x1f pipe_read+0x38f dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100176 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100177 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100178 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100179 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100180 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100181 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100182 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100183 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100184 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100185 none-amd64-freebsd - mi_switch+0xc2 ast+0x1e6 doreti_ast+0x1f 864 100186 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100187 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 864 100188 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 It doesn't seem to be totally hung. If I repeatedly sample I do see activity changing between the threads other than main (in _umtx_op) and 12 (stuck in ast / doreti_ast. But it looks like none of the calls to read is completing, meaning the Valgrind scheduler is blocked. A+ Paul From nobody Mon May 30 19:35:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 917CE1B5843E for ; Mon, 30 May 2022 19:35:09 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBlx80jhVz3R50 for ; Mon, 30 May 2022 19:35:08 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id s24so8593599wrb.10 for ; Mon, 30 May 2022 12:35:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=eduKHTRinjJbMkZtff7ymtnji7OwqftWsKQJODyOsbI=; b=FZt3GEI/TpBeqRVQIYuvegUzNnwY7Wvesqsd1HmFDRkh4JR+cVOmgvhKKdAhSdodo4 wzMxZm/DpG3ZrddTKVokLVRTalysxLzzLJ8gMk9lZyaMS8TAAqDDtV/4rUDhcjiUT7Un h1P7AR2gOgLkSUqiFjq61R9NC8bOiJeW/advtq1pLML0a6GmCEvaHrOB5S/LayFLiBLr S5NdJpr5FCnNfDXv3iR2/WF1vmbo3szsblAEtyaKCnppgHslRBI6gIvC/yb/ffVjAMUV spdpRdf00AakVhYoiKOknok7b0Oj2gL7iDgpurBeOfUtQUqj5wz4htteAavmC/WNrwv5 H9EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=eduKHTRinjJbMkZtff7ymtnji7OwqftWsKQJODyOsbI=; b=qwtxr62S7jvOUZ0WMToZGNzCVd5Ho6nH24hw6Mrdy5ZBLrOmkhHijWC0yv3xCSqgAL mXGIM+zSwJcGR0iq5C6LNcjmT63TO39UAGv0yXHbFoGpC7e31rfNBGAeploePQyMV4mp 2VyRFLldthdVqImZl4tcmILWBYstJW9GRH+v58cuv4ty5WcmM9NLZLXGnbD6NNWrCNbC Ocr1aDmPulwaS7DOO68zilVxeYWGk5+kNXr6+KvL9bjW2Ixzknw8PF78D+/tv1r1PwAw mzjlvAwh3fcQKcanzS9BAR8ZQ4GqZ0pRrZZysytVdCxtSSrBE1AjoDzwnFUZX5VmIR4N DGBg== X-Gm-Message-State: AOAM533aGFCTf4IrEe2rchXIUsWECx2jvYVpd9ss9gsSph7mLnw6C/B8 RM22X/cU22OszGcqic6KVjoqA2z1fsfYZg== X-Google-Smtp-Source: ABdhPJyQpXe7z8wZdsx6Fh6t4zBjHn/Gukchkzg0zMf34soGigAo/er5fsD4J1jrJwXNnleXindacw== X-Received: by 2002:a5d:64c2:0:b0:20f:dc21:e658 with SMTP id f2-20020a5d64c2000000b0020fdc21e658mr34197194wri.508.1653939306990; Mon, 30 May 2022 12:35:06 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id n4-20020a1ca404000000b003973b9d0447sm175451wme.36.2022.05.30.12.35.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 12:35:06 -0700 (PDT) Message-ID: Date: Mon, 30 May 2022 21:35:05 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Hang ast / pipelk / piperd Content-Language: en-US To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LBlx80jhVz3R50 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="FZt3GEI/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.59)[0.591]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 5/30/22 14:15, Mark Johnston wrote: > "procstat -kk " might help to reveal what's going on, > since it sounds like the hand/livelock is happening somewhere in the > kernel. Not knowing much about the kernel, my guess is that this is related to commit 4808bab7fa6c3ec49b49476b8326d7a0250a03fa Author: Alexander Motin Date: Tue Sep 21 18:14:22 2021 -0400 sched_ule(4): Improve long-term load balancer. and this bit of ast code doreti_ast: /* * Check for ASTs atomically with returning. Disabling CPU * interrupts provides sufficient locking even in the SMP case, * since we will be informed of any new ASTs by an IPI. */ cli movq PCPU(CURTHREAD),%rax testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) je doreti_exit sti movq %rsp,%rdi /* pass a pointer to the trapframe */ call ast jmp doreti_ast The above commit seems to be migrating loaded threads to another CPU. My test system is a VirtualBox amd64 FreeBSD 13.1 with one CPU running on a 13.0 host. I just tried restarting the VM with 2 CPUs and the testcase seems to be a lot better - it's been running in a loop for 10 minutes whereas previously it would hang at least 1 in 5 times. A+ Paul From nobody Wed Jun 1 00:00:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 04DB41B469EE; Wed, 1 Jun 2022 00:00:02 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCTmK6fnZz4c0R; Wed, 1 Jun 2022 00:00:01 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654041601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=y2Ru8rmZ+Xewk1J4k4j9By6OK7kzf1sSHr+10OWuBz500Pk29f8O7qk4MeNOhrKgsbtTfw JdRkY6NttquCja0Zs4k71ZZiTC0TFjojqduK0HJNABbg1Bc0OWMwXqmezDnYzyjFhbggLt slyAlxCTU3QN+ZPBg2UQLvOEHa9Wzf+4+z9w+cM+f8/ggp2jwYVJiye7Sy0Vn71AV708MC mj+693DjYeLxJBLzQdujc+zIjZoa3G5/w0tIrHE6/9jxIiRl0rq2ymV2jRjgrRTfXcZcQ0 hp8lAYrZKi1+ER/fASYV9lbbfZNGcIU8NaO/tqUU2pxWffa7lBYOyg2UHAmrsw== Received: by freefall.freebsd.org (Postfix, from userid 1472) id C1B4710D73; Wed, 1 Jun 2022 00:00:01 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: Call for 2022Q2 quarterly status reports Cc: martymac@FreeBSD.org,probono@puredarwin.org,mk@semihalf.com,freebsd-current@FreeBSD.org,freebsd-accessibility@freebsd.org,soc-mentors@FreeBSD.org,deb@FreeBSDFoundation.org,portmgr-secretary@FreeBSD.org,doceng@FreeBSD.org,jenkins-admin@FreeBSD.org,info@bsdcan.org,dsl@mcusim.org,freebsd-hackers@FreeBSD.org,kde@FreeBSD.org,cperciva@FreeBSD.org,grembo@freebsd.org,fluffy@FreeBSD.org,pauamma@gundo.com,gerald@pfeifer.com,soc-students@FreeBSD.org,mckusick@mckusick.com,bz@FreeBSD.ORG,pizzamig@freebsd.org,clusteradm@FreeBSD.org,asiciliano@FreeBSD.org,dgr@semihalf.com,portmgr@FreeBSD.org,sl@honeyguide.eu,office@FreeBSD.org,lwhsu@FreeBSD.org,pali.gabor@gmail.com,carlavilla@FreeBSD.org,re@FreeBSD.org,bz@FreeBSD.org,mw@semihalf.com,bapt@FreeBSD.org Message-Id: <20220601000001.C1B4710D73@freefall.freebsd.org> Date: Wed, 1 Jun 2022 00:00:01 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654041601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=ifgJOYuCGNMEpiea5DAreRjiZUhnE6QUzt+hk1nYWfw2JHCcVl1RqXw7Z/6STzb9lizzf1 VQskIeGqGcaKCDESvuwYaYegC5ZoNrrdbQUJGjRfZqNojjSjWZydZPsN0v+RjI461Cp+wX Fqgg2/MtzlmoNmedTxygLzfhOLqXA80kMwRdcWX5YiSeTrX/5pc+LgO7RbdhyMDgjzGrEE ILTMcxbWBdaHTUhkO/WZ5mmjVH6FAVaND7UCe5NEfmOAhw/wL3NdYBxSxCe90GD6TER93k 8fZbOGJmeXvhk1nYsecHaVNY22gyEFwsfX8MAnw8nKPqRyYwCBSeME29h6Onww== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654041601; a=rsa-sha256; cv=none; b=IcoVGjI+cdEKpVBGFd9UvG9jy77Q5M/LNkJRWnfhzNN6sE9qh+DxbmUs04QyT4AftILIug IQqbg2uFerXwD43gKwLAwJc+J17W8t8cE+DOtaXBNJHFP7rW9bg2rPklZWwxIiXTY7JZYc iChkVwDduk/OSFABUjYYNArCf0CgFlVGGBle71xZXOI40pVCfv/hR+cIycZTYH7FG9wING OMCZ+i536NDB1Yiv7iiXHRTo1JqAzdU/Q7ri8qooVHNA8qsIv8S1yM3BVaht6eEuuIzCGS afWx9t1ShjTO/QAUiawZ1cpW6h+/JII6LDXVXqIBdVhrNhT5gtKdsL/qlCtR3Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is June, 30th 2022 for work done since the last round of Quarterly Reports: April 2022 - June 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q2 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Wed Jun 1 07:08:13 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F71E1B46A1E for ; Wed, 1 Jun 2022 07:08:25 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCgGb5FLlz3HnH for ; Wed, 1 Jun 2022 07:08:23 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy06.your-server.de ([78.46.172.3]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nwISm-000Pud-8C for hackers@freebsd.org; Wed, 01 Jun 2022 09:08:16 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwISm-000R8P-5G for hackers@freebsd.org; Wed, 01 Jun 2022 09:08:16 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id CA97E4800EA for ; Wed, 1 Jun 2022 09:08:15 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5ggYJShMKI8c for ; Wed, 1 Jun 2022 09:08:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 69F30480149 for ; Wed, 1 Jun 2022 09:08:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D-eMrDxHZU1C for ; Wed, 1 Jun 2022 09:08:15 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id CFDD04800EA for ; Wed, 1 Jun 2022 09:08:14 +0200 (CEST) Message-ID: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> Date: Wed, 1 Jun 2022 09:08:13 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 To: hackers@freebsd.org Content-Language: en-US From: Sebastian Huber Subject: pps_capture() and pps_fetch() Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26558/Tue May 31 10:05:17 2022) X-Rspamd-Queue-Id: 4LCgGb5FLlz3HnH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-3.29 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_NA(0.00)[embedded-brains.de]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I try to understand how the PPS synchronization works in FreeBSD. It=20 seems that pps_capture() starts a transaction and pps_event() completes=20 the transaction if nothing interfered in the meantime. void pps_capture(struct pps_state *pps) { struct timehands *th; KASSERT(pps !=3D NULL, ("NULL pps pointer in pps_capture")); th =3D timehands; pps->capgen =3D atomic_load_acq_int(&th->th_generation); pps->capth =3D th; #ifdef FFCLOCK pps->capffth =3D fftimehands; #endif pps->capcount =3D th->th_counter->tc_get_timecount(th->th_counter); atomic_thread_fence_acq(); if (pps->capgen !=3D th->th_generation) pps->capgen =3D 0; } This function uses the current timehand to capture the time measured by=20 the timecounter of the timehand. The timehand generation is used to=20 ensure a consistent transaction. We have void pps_event(struct pps_state *pps, int event) { [...] /* If the timecounter was wound up underneath us, bail out. */ if (pps->capgen =3D=3D 0 || pps->capgen !=3D atomic_load_acq_int(&pps->capth->th_generation)) return; [...] /* * If the timecounter changed, we cannot compare the count values, so * we have to drop the rest of the PPS-stuff until the next event. */ if (pps->ppstc !=3D pps->capth->th_counter) { pps->ppstc =3D pps->capth->th_counter; *pcount =3D pps->capcount; pps->ppscount[2] =3D pps->capcount; return; } /* Convert the count to a timespec. */ tcount =3D pps->capcount - pps->capth->th_offset_count; tcount &=3D pps->capth->th_counter->tc_counter_mask; bt =3D pps->capth->th_bintime; bintime_addx(&bt, pps->capth->th_scale * tcount); bintime2timespec(&bt, &ts); /* If the timecounter was wound up underneath us, bail out. */ atomic_thread_fence_acq(); if (pps->capgen !=3D pps->capth->th_generation) return; [...] } Why do we need the atomic_thread_fence_acq(); if (pps->capgen !=3D th->th_generation) pps->capgen =3D 0; in pps_capture()? Why do we need the early /* If the timecounter was wound up underneath us, bail out. */ if (pps->capgen =3D=3D 0 || pps->capgen !=3D atomic_load_acq_int(&pps->capth->th_generation)) return; in pps_event()? Shouldn't a single if (pps->capgen =3D=3D 0 || pps->capgen !=3D atomic_load_acq_int(&pps->capth->th_generation)) return; after the bintime_addx(&bt, pps->capth->th_scale * tcount); in=20 pps_event() be sufficient? The capture timehand may change anytime, so=20 why is the generation checked multiple times? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Wed Jun 1 07:25:14 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E3A2D1B4A722 for ; Wed, 1 Jun 2022 07:25:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCgfD6rvgz3LK8 for ; Wed, 1 Jun 2022 07:25:24 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B994789298; Wed, 1 Jun 2022 07:25:16 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2517PGfq036704 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 1 Jun 2022 07:25:16 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2517PEfF036703; Wed, 1 Jun 2022 07:25:14 GMT (envelope-from phk) Message-Id: <202206010725.2517PEfF036703@critter.freebsd.dk> To: Sebastian Huber cc: hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <36701.1654068314.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Jun 2022 07:25:14 +0000 X-Rspamd-Queue-Id: 4LCgfD6rvgz3LK8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N -------- Sebastian Huber writes: > I try to understand how the PPS synchronization works in FreeBSD. It = > seems that pps_capture() starts a transaction and pps_event() completes = > the transaction if nothing interfered in the meantime. The answer to most of your questions are in ./i386/i386/elan-mmcr.c The PPS capture in the Soekris 4501 used two hardware counters, counting a= t the same rate. The first of the two were the timecounter, the other was started by the ha= rdware signal. Sometime later the hardware signals interrupt processing would happen. By reading read both counters as close to instantaneously as possible, and= compensated for the interrupt latency by subtracting the event-started co= unter from the timecounter. (See also: http://phk.freebsd.dk/soekris/pps/) -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Wed Jun 1 11:03:19 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 246421B6054A for ; Wed, 1 Jun 2022 11:03:25 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCmTm1g2Kz4Ts1 for ; Wed, 1 Jun 2022 11:03:24 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy06.your-server.de ([78.46.172.3]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nwM8I-0008Ti-7e; Wed, 01 Jun 2022 13:03:22 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nwM8I-000P6l-5F; Wed, 01 Jun 2022 13:03:22 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id D071448014F; Wed, 1 Jun 2022 13:03:21 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ezn2eU_v6akE; Wed, 1 Jun 2022 13:03:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 671D74800F0; Wed, 1 Jun 2022 13:03:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2Xemg1JbI1At; Wed, 1 Jun 2022 13:03:21 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 3A87F4800AA; Wed, 1 Jun 2022 13:03:21 +0200 (CEST) Message-ID: Date: Wed, 1 Jun 2022 13:03:19 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: pps_capture() and pps_fetch() Content-Language: en-US To: Poul-Henning Kamp Cc: hackers@freebsd.org References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> From: Sebastian Huber In-Reply-To: <202206010725.2517PEfF036703@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26559/Wed Jun 1 10:06:04 2022) X-Rspamd-Queue-Id: 4LCmTm1g2Kz4Ts1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-2.71 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[embedded-brains.de]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.51)[-0.506]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-0.90)[-0.904]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Poul-Henning, On 01/06/2022 09:25, Poul-Henning Kamp wrote: > Sebastian Huber writes: >=20 >> I try to understand how the PPS synchronization works in FreeBSD. It >> seems that pps_capture() starts a transaction and pps_event() complete= s >> the transaction if nothing interfered in the meantime. > The answer to most of your questions are in ./i386/i386/elan-mmcr.c >=20 > The PPS capture in the Soekris 4501 used two hardware counters, countin= g at the same rate. >=20 > The first of the two were the timecounter, the other was started by the= hardware signal. >=20 > Sometime later the hardware signals interrupt processing would happen. >=20 > By reading read both counters as close to instantaneously as possible, = and compensated for the interrupt latency by subtracting the event-starte= d counter from the timecounter. >=20 > (See also:http://phk.freebsd.dk/soekris/pps/) thanks for the background information. What I don't understand is why the th_generation is checked three times=20 (pps_capture(): 1, pps_event(): 2) and not only once in pps_event()=20 right before we use the captured time. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Wed Jun 1 13:04:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62B0A1B72EB0 for ; Wed, 1 Jun 2022 13:04:12 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCq9600lTz4h8l for ; Wed, 1 Jun 2022 13:04:09 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] ([185.91.121.2]) (authenticated bits=0) by smtp.krpservers.com (8.16.1/8.15.2) with ESMTPSA id 251D40Hi099771 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jun 2022 14:04:02 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tdx.co.uk; s=krpdkim; t=1654088642; bh=RBWauIgOkHhbAkHvZ2ty1MtB4IT727lhFGEZL7q7b2I=; h=Date:From:To:Subject; b=l9KYY/iggb3CUy7HGAgH+W1YB2SzumqW31obHOCA0yP3pmjE/ip6XO7g4K4b6kMxe 1qNSYKJ0V3dzWsu9pTG1CqAGacYNd7kFpFcK2VSgvRgYGxIeo0Eb+qswi7l5vFI2QY RT2iqM9g8o9cz/ixGqJtLgEGIYvwK5N5sA4dGiWb3LQ++1DiexCcmu3fXE74Gsm4O2 qT1THEAzUa2EEuIeEPUH67UbiCJOfR+9BtKSmitK7LkQWOO+dz/NMMlUPPT4+heNHB G3Pk0tf6qFBUgEJ0U2IhIAuHUAXaHGO7OOX1HEF24gWZfAPLHAE0JgfBNpmY2hElJV kYwfWbxQ5of9Q== Date: Wed, 01 Jun 2022 14:04:00 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: Ice Lake / C621A supported, or anyone actually running on it? Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Rspamd-Queue-Id: 4LCq9600lTz4h8l X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tdx.co.uk header.s=krpdkim header.b="l9KYY/ig"; dmarc=pass (policy=none) header.from=tdx.co.uk; spf=pass (mx1.freebsd.org: domain of kpielorz_lst@tdx.co.uk designates 62.13.128.145 as permitted sender) smtp.mailfrom=kpielorz_lst@tdx.co.uk X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tdx.co.uk:s=krpdkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.krpservers.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_IP_LITERAL(0.50)[]; DKIM_TRACE(0.00)[tdx.co.uk:+]; DMARC_POLICY_ALLOW(-0.50)[tdx.co.uk,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:60969, ipnet:62.13.128.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, We're looking at some new kit which is Intel Ice Lake (Xeon Scaleable 3rd Gen) - apparently based on C621A chipset. I can't find anyone (e.g. via search engine) running FBSD on this - so just wondered what the chances are it would boot /work? Or if anyone actually has it running on this kit? NIC's don't seem too outlandish (Intel i350) - but it has 'flexible' bays which can apparently host SATA3 or nvme drives - which looks concerning - support wise... Cheers, -Karl From nobody Wed Jun 1 14:16:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 198661B49CEB for ; Wed, 1 Jun 2022 14:16:57 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCrn42dB4z4sxD for ; Wed, 1 Jun 2022 14:16:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x736.google.com with SMTP id b200so1380028qkc.7 for ; Wed, 01 Jun 2022 07:16: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=Ed3h7g+uRUwC/nyBa5EIQITDA6WFIsgl3vp1oPJKskI=; b=FLgfqQDHpUeNWEf4B+P0USIpHrxZbg9TFiHYUclONixi1VAS9iVdYJSzBPmdwjGx1q SVx50o0tE2j+M0UVFFfeY4cva7s+Spbr2MIB7KgidoBTPIyM+P8zKxe9vWVwVvzfMv0c uguLxPvN4frLr7ad4Ugr1mHVYo+/ufr1c1Or1bRoS7+LJrZtbbnwQ39cIYqUWVcWDr5Z PpIU9UJlaH0t2io4212yR1RkYTir8ntDmi3NLnzqGRiBjC/Ul/SGcrYpcEWyyC7mr7tX YU12DFZMhbQzAiRO0BeiPJ8IaR+mcpewPdexC4IjS30qkQ90f48mpi32iLNm3QUsgfn1 lnqg== 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=Ed3h7g+uRUwC/nyBa5EIQITDA6WFIsgl3vp1oPJKskI=; b=XdZ027HNoBdpb+l8EFhJa9xiHP2TUmRgP/FtEB5ns1jMxZE9Fg5gdO2wmjIZYj24n7 pcB7m1nGohYGMGaF7QDMzELHOOqsFlDXO9Ta3NOqADkvwM6c9xz0Fk28a48snWS452I2 ExUFL/ziE7IAcgO2E6sB/tifnjZ485ntKlgv1prFOuTRQftDRymGoE2Bp4PWpqDPCXJA E1F9WXnOAlPJMpgyfogRjcx1a/wccj3z2peO898JaBRF8BTBvtsFAB3vrL2ke2ppF3uG yAllD8PwW1p5iL2TVJk6dwyCMvtzG7zX8kEmaeRGqx6olhii+SOtEzyQ7xud51k5IVst VCHw== X-Gm-Message-State: AOAM532ce7xTKlM7DiOfa7VXgCy0WHfJ3iR8VHK9zuLFyOiPsDkQHdGc mTiZWfLYr5KrHYKkeIFAZNL4juLrcqA= X-Google-Smtp-Source: ABdhPJyavqvlrV5+ozChssB7asmY7QuZMKNueXjZUeplW/FgOJiJ/4E/5VStNNcd2s+bdlxou9NZcA== X-Received: by 2002:a05:620a:44c6:b0:6a6:49cb:4633 with SMTP id y6-20020a05620a44c600b006a649cb4633mr195584qkp.370.1654093009770; Wed, 01 Jun 2022 07:16:49 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id l2-20020a37bb02000000b006a2e2dde144sm1263097qkf.88.2022.06.01.07.16.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 07:16:48 -0700 (PDT) Date: Wed, 1 Jun 2022 10:16:46 -0400 From: Mark Johnston To: Paul Floyd Cc: FreeBSD Hackers Subject: Re: Hang ast / pipelk / piperd Message-ID: References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LCrn42dB4z4sxD X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FLgfqQDH; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::736 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.88)[0.878]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, May 30, 2022 at 09:35:05PM +0200, Paul Floyd wrote: > > > On 5/30/22 14:15, Mark Johnston wrote: > > > "procstat -kk " might help to reveal what's going on, > > since it sounds like the hand/livelock is happening somewhere in the > > kernel. > > Not knowing much about the kernel, my guess is that this is related to > > commit 4808bab7fa6c3ec49b49476b8326d7a0250a03fa > Author: Alexander Motin > Date: Tue Sep 21 18:14:22 2021 -0400 > > sched_ule(4): Improve long-term load balancer. > > and this bit of ast code > > doreti_ast: > /* > * Check for ASTs atomically with returning. Disabling CPU > * interrupts provides sufficient locking even in the SMP case, > * since we will be informed of any new ASTs by an IPI. > */ > cli > movq PCPU(CURTHREAD),%rax > testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) > je doreti_exit > sti > movq %rsp,%rdi /* pass a pointer to the trapframe */ > call ast > jmp doreti_ast > > > The above commit seems to be migrating loaded threads to another CPU. How did you infer that? The long-term load balancer should be running fairly infrequently. As a side note, I think we are missing ktrcsw() calls in some places, e.g., in turnstile_wait(). > My test system is a VirtualBox amd64 FreeBSD 13.1 with one CPU running > on a 13.0 host. > > I just tried restarting the VM with 2 CPUs and the testcase seems to be > a lot better - it's been running in a loop for 10 minutes whereas > previously it would hang at least 1 in 5 times. Hmm. Could you, please, show the ktrace output with -H -T passed to kdump(1), together with fresh "procstat -kk" output? The fact that the problem apparently only occurs with 1 CPU suggests a scheduler bug, indeed. From nobody Wed Jun 1 14:38:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 106F01B4E151 for ; Wed, 1 Jun 2022 14:38:53 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCsGN122Fz3CJt for ; Wed, 1 Jun 2022 14:38:52 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt1-x82a.google.com with SMTP id v1so1289295qtx.5 for ; Wed, 01 Jun 2022 07:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=SfCq7F0WnXMj/yHSP3923P06rVawHkG4pUZ4hcE4ces=; b=CZrLDG/r6tpHvQaz3HRPfqtX57B4pMlfrp0knrNytUPlRbPKqNE63jJj1UYcQYt61f LotadPG35XIBPSEGipEmbUnePoqIYW5pF0XQDCViuILHr8xFQ5vGAGkIW1PMUWZyG5kU lDDDHIDJ95HuwY8/SuSAxdjzA6DL2QX9+vqAQAczK3t5Ik//Y+6lCGiwjpxxITZSXdoA iUeWtYCBhsLRtn1aaDOLVWO0KCMWCyNQiD6tzKdSpaNP4+ZPQHE8qoWQDQQNdRkw5HYU 9B+SluFByiTkFw6H646udfpDEMt3rrfk3zQPRg/BoBvo2OxC7aOFxQmncn9TGyAR0tvr LFdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=SfCq7F0WnXMj/yHSP3923P06rVawHkG4pUZ4hcE4ces=; b=LmXIOc+lF7iiYnnxUp5W3I3Ygo05YRvBXQCNjjKn1m9X+5VWPdCotf625dJXiSbBng TkrYGJ0TddpIwRkIE6xj1NYyHiiFgfkQzu+3vRQHJ711Wyw28o8DYoBcWnZ7dbNNB94e uiKKvilNOlzOv1OW028/oH5SW6PPQ5LS1tnonhuD4qSdIxnU0VaB0t9aYfQ1y4WxSeM1 1KcNPia5kJcQ/yy1AxGeRGurG9Av0t+hwISND43Bk0IGrE8cp+bupAY6w2RsLdsOEuro Bf+yf2b3dxgmYYZBX3YnsliHAh0zsncRItJrjyN5HA7OZKqcsY1W0KyigOlHsJs0q05F Wo8Q== X-Gm-Message-State: AOAM533L3TlUEV0PmGhpuH7MzuG4ModoDXnXdyyaRDgR1T+snLjhSPB7 SLLz0KzzTdkVu2pkhMo7MI351tSNC1fJFF1f X-Google-Smtp-Source: ABdhPJx6WFN/ki++KZAZC7cr+/RpMKyQ18xwB2LEyy6EuBLBfq/9eqhtYp3mGb6h2yF5hlQw+JHUKw== X-Received: by 2002:a05:622a:610:b0:302:eca8:6376 with SMTP id z16-20020a05622a061000b00302eca86376mr182865qta.18.1654094331421; Wed, 01 Jun 2022 07:38:51 -0700 (PDT) Received: from smtpclient.apple ([2600:1017:b41e:4a1d:d5c3:5960:4d7a:767c]) by smtp.gmail.com with ESMTPSA id y184-20020a37afc1000000b0069fc13ce225sm1300720qke.86.2022.06.01.07.38.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 07:38:50 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9F4CA311-04BB-4923-A285-894F2AA54BC5 Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Ice Lake / C621A supported, or anyone actually running on it? From: Mark Saad In-Reply-To: Cc: freebsd-hackers@freebsd.org Date: Wed, 1 Jun 2022 10:38:49 -0400 Message-Id: <70CE1105-E54E-4CD7-A871-6BD31FA3A53D@longcount.org> References: To: Karl Pielorz X-Mailer: iPhone Mail (19F77) X-Rspamd-Queue-Id: 4LCsGN122Fz3CJt X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount.org header.s=google header.b="CZrLDG/r"; dmarc=none; spf=pass (mx1.freebsd.org: domain of nonesuch@longcount.org designates 2607:f8b0:4864:20::82a as permitted sender) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-1.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[longcount.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[longcount.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from]; NEURAL_HAM_SHORT(-0.87)[-0.868]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-9F4CA311-04BB-4923-A285-894F2AA54BC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Karl I don=E2=80=99t know anyone off hand but check https://dmesgd.nycbug.org/i= ndex.cgi .=20 -- Mark Saad | nonesuch@longcount.org > On Jun 1, 2022, at 9:05 AM, Karl Pielorz wrote: > =EF=BB=BF > Hi, >=20 > We're looking at some new kit which is Intel Ice Lake (Xeon Scaleable 3rd G= en) - apparently based on C621A chipset. >=20 > I can't find anyone (e.g. via search engine) running FBSD on this - so jus= t wondered what the chances are it would boot /work? Or if anyone actually h= as it running on this kit? NIC's don't seem too outlandish (Intel i350) - bu= t it has 'flexible' bays which can apparently host SATA3 or nvme drives - wh= ich looks concerning - support wise... >=20 > Cheers, >=20 > -Karl --Apple-Mail-9F4CA311-04BB-4923-A285-894F2AA54BC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Karl
  I don=E2=80=99= t know anyone off hand but check https://dmesgd.nycbug.org/index.cgi . 
--
Mark Saad | nonesuch@longcount.org
=
On Jun 1, 2022, at 9:05 AM, Karl Pielorz <k= pielorz_lst@tdx.co.uk> wrote:

=EF=BB=BF
Hi,
=
We're looking at some new kit which is Intel Ice Lake (Xeon= Scaleable 3rd Gen) - apparently based on C621A chipset.

I can't find anyone (e.g. via search engine) running FBSD on t= his - so just wondered what the chances are it would boot /work? Or if anyon= e actually has it running on this kit? NIC's don't seem too outlandish (Inte= l i350) - but it has 'flexible' bays which can apparently host SATA3 or nvme= drives - which looks concerning - support wise...
Cheers,

-Karl

= --Apple-Mail-9F4CA311-04BB-4923-A285-894F2AA54BC5-- From nobody Wed Jun 1 15:07:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3AE911B5B46D for ; Wed, 1 Jun 2022 15:07:29 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LCsvM3KzWz3GRX for ; Wed, 1 Jun 2022 15:07:27 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] ([185.91.121.2]) (authenticated bits=0) by smtp.krpservers.com (8.16.1/8.15.2) with ESMTPSA id 251F7OIx029728 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2022 16:07:25 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tdx.co.uk; s=krpdkim; t=1654096045; bh=2sRSeWE4rLTZuRF+unDDamIl+fCXq8W3jDwo3kMD7B8=; h=Date:From:To:Subject; b=VPescN1HmwRnCYtM00FYWR48JOvvewAOsFul2KW/g56HrJ5l4fsLl6GQ+lBIdoUrB SYWXuSCm8DGzTWOQc5iAskaBq7Mw10HD6VqFTyQHkCEYHszeXnMgtJ/joGD4ZTePc7 wJJa/Ko1XooZA1eH94l09e5QIfoSakb6V9Pxr9ipzCjYw9C42tJ7xCEAxi8p0PNSSV xbgJ2/rs8dPA6GGdfNeI1ZOi152roWmjggb9k93seoiOOOZj9/J59KoiL1QRfDrlnP XsWTVWR+anv8agK6tQqsEuD3qWGntW9HnLW8ywvhTPktbFNQmgssVY88hWnhSba7Ih /U/Tr+DCmkbkg== Date: Wed, 01 Jun 2022 16:07:24 +0100 From: Karl Pielorz To: Mark Saad cc: freebsd-hackers@freebsd.org Subject: Re: Ice Lake / C621A supported, or anyone actually running on it? Message-ID: <109AEA2314757828889EAA10@[10.12.30.106]> In-Reply-To: <70CE1105-E54E-4CD7-A871-6BD31FA3A53D@longcount.org> References: <70CE1105-E54E-4CD7-A871-6BD31FA3A53D@longcount.org> X-Mailer: Mulberry/4.0.8 (Win32) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Rspamd-Queue-Id: 4LCsvM3KzWz3GRX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tdx.co.uk header.s=krpdkim header.b=VPescN1H; dmarc=pass (policy=none) header.from=tdx.co.uk; spf=pass (mx1.freebsd.org: domain of kpielorz_lst@tdx.co.uk designates 62.13.128.145 as permitted sender) smtp.mailfrom=kpielorz_lst@tdx.co.uk X-Spamd-Result: default: False [-2.42 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[tdx.co.uk:s=krpdkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.krpservers.com:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_IP_LITERAL(0.50)[]; DKIM_TRACE(0.00)[tdx.co.uk:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[tdx.co.uk,none]; NEURAL_HAM_SHORT(-0.92)[-0.917]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:60969, ipnet:62.13.128.0/24, country:GB]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --On 01 June 2022 10:38 -0400 Mark Saad wrote: > Karl > I don't know anyone off hand but check > https://dmesgd.nycbug.org/index.cgi . -- > Mark Saad | nonesuch@longcount.org I couldn't remember where that site was - thanks! - Sadly, there's nothing close listed that I can see at first glance. At least now I know where the site is I can probably submit some dmesg's from work etc. -Kp From nobody Wed Jun 1 21:27:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1CD5B1B4F89D for ; Wed, 1 Jun 2022 21:27:56 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LD2LM28wlz4m3Q for ; Wed, 1 Jun 2022 21:27:55 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42e.google.com with SMTP id s24so3982036wrb.10 for ; Wed, 01 Jun 2022 14:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=cvR8z3hbNs2n5Qtvrb1p/v6EWjXpkm1tUwLI+gEHK80=; b=jU6zzDSQLpxlxNhSkbsQTCU/2BKV1ErZbiWE3B5BaqYhHG8Lnr5ptdtArM6smLCVLI nfOkBpFeIi8mujYu9J/+aZ1pYIjlLsi5habXGXD/Mwk7kujZbP9Mqv0IXN3pWmnQ0nPy eGPwueo9ScliNsuz6HgAkFghLHJZ1tup8oWbAFMkduBNLqZ24maaxbN7BlxnL8GQJ9dG YhXk002g0dhnoGgoNiE6LE6cWutFo9w5sV6UqB1Z/DCpsoEUgGdIbAU5PmSu2mYhVjZL yts3IMM71qCrMDoTZB2BFxAVhDQwyGi8L10s4xVtUms3uWUZ3NKtzEWv1tyh5Ktq8DQo klQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=cvR8z3hbNs2n5Qtvrb1p/v6EWjXpkm1tUwLI+gEHK80=; b=Quq4jo+8994xnrBQV1VlTfNnrLVNu0vjKWGzxRpPdjt6T6eA99UG0hW2wm72WgtnkX sXZl4IgV6uAH6j/HFqc1Obm0DlP1a1k2Rhfc7jKJLWgtZWYD4Esf7unRvc8mrZ4w3Jee sN2GNVULZ/hc/Tgv0yBfJjGBpEVxBLnrdXvMG0XKSF739LwIP7K55mV+qHPv2traKdPJ 8wgAFcUIINbFUQ6iwiL+yFy2+DmA8CUMYz+CXMITVHj9R+0iiI4US/cAcrJYsZ9o4cms GtM7YMQlqtbfuTBLCYW9MS2OybDKYnXsB7Z9L10hbThfK7ygxMEOTw8CZjpa7bj0Qs6J UinA== X-Gm-Message-State: AOAM533LSB7Vd0gz+M7ZCgzrlilSbXUh8j7MAJ8HWAnopREDnXw24RNt RzanSoBc3EgH4heRh5bvXyTgjGxklYgDWg== X-Google-Smtp-Source: ABdhPJyborXVy8gH5eyT5vj8jct7Pt7a/3bC4ZYSQhaHkdnvbVNoq7aQurF7SPjs++wxXEU8dwodEg== X-Received: by 2002:a5d:64ac:0:b0:211:7f3b:a0d4 with SMTP id m12-20020a5d64ac000000b002117f3ba0d4mr1104341wrp.490.1654118874141; Wed, 01 Jun 2022 14:27:54 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-398-93.w2-7.abo.wanadoo.fr. [2.7.225.93]) by smtp.gmail.com with ESMTPSA id t14-20020a5d49ce000000b0020d0cdbf7eesm2577996wrs.111.2022.06.01.14.27.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jun 2022 14:27:53 -0700 (PDT) Message-ID: Date: Wed, 1 Jun 2022 23:27:52 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Hang ast / pipelk / piperd Content-Language: en-US To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LD2LM28wlz4m3Q X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jU6zzDSQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42e as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-1.27 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.225.93:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.25)[-0.251]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.98)[0.982]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42e:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 6/1/22 14:16, Mark Johnston wrote: > On Mon, May 30, 2022 at 09:35:05PM +0200, Paul Floyd wrote: >> >> >> On 5/30/22 14:15, Mark Johnston wrote: >> >>> "procstat -kk " might help to reveal what's going on, >>> since it sounds like the hand/livelock is happening somewhere in the >>> kernel. >> >> Not knowing much about the kernel, my guess is that this is related to >> >> commit 4808bab7fa6c3ec49b49476b8326d7a0250a03fa >> Author: Alexander Motin >> Date: Tue Sep 21 18:14:22 2021 -0400 >> >> sched_ule(4): Improve long-term load balancer. >> >> and this bit of ast code >> >> doreti_ast: >> /* >> * Check for ASTs atomically with returning. Disabling CPU >> * interrupts provides sufficient locking even in the SMP case, >> * since we will be informed of any new ASTs by an IPI. >> */ >> cli >> movq PCPU(CURTHREAD),%rax >> testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) >> je doreti_exit >> sti >> movq %rsp,%rdi /* pass a pointer to the trapframe */ >> call ast >> jmp doreti_ast >> >> >> The above commit seems to be migrating loaded threads to another CPU. > > How did you infer that? The long-term load balancer should be running > fairly infrequently. > Well one thread is hung in mi_switch+0xc2 ast+0x1e6 doreti_ast+0x1f I found the above code referring to doreti_ast with grep and thought that if the test always fails then it will loop forever. So I looked for git commits containing TDF_ASTPENDING and TDF_NEEDRESCHED and found a couple of commits mentioning these flags, scheduling and found the above and the followup commit 11f14b33629e552a451fdbfe653ebb0addd27700 Author: Alexander Motin Date: Sun Sep 26 12:03:05 2021 -0400 sched_ule(4): Fix hang with steal_thresh < 2. e745d729be60 caused infinite loop with interrupts disabled in load stealing code if steal_thresh set below 2. Such configuration should not generally be used, but appeared some people are using it to workaround some problems. and I guessed they might be related. > As a side note, I think we are missing ktrcsw() calls in some places, > e.g., in turnstile_wait(). > >> My test system is a VirtualBox amd64 FreeBSD 13.1 with one CPU running >> on a 13.0 host. >> >> I just tried restarting the VM with 2 CPUs and the testcase seems to be >> a lot better - it's been running in a loop for 10 minutes whereas >> previously it would hang at least 1 in 5 times. > > Hmm. Could you, please, show the ktrace output with -H -T passed to > kdump(1), together with fresh "procstat -kk" output? > > The fact that the problem apparently only occurs with 1 CPU suggests a > scheduler bug, indeed. Here is the fresh procstat output paulf@freebsd:~ $ procstat -kk 12339 PID TID COMM TDNAME KSTACK 12339 100089 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 umtxq_sleep+0x143 do_wait+0x3e5 __umtx_op_wait+0x53 sys__umtx_op+0x7e amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100582 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x1d1 kern_clock_nanosleep+0x1c1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100583 none-amd64-freebsd - mi_switch+0xc2 ast+0x1e6 doreti_ast+0x1f 12339 100584 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100585 none-amd64-freebsd - mi_switch+0xc2 intr_event_handle+0x167 intr_execute_handlers+0x4b Xapic_isr1+0xdc sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100586 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100587 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100588 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100589 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100590 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100591 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100592 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100593 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100594 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 12339 100595 none-amd64-freebsd - mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 pipe_read+0xb3 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8 And the ktrace 12339 100591 none-amd64-freebsd 1654117859.896834 RET nanosleep 0 12339 100591 none-amd64-freebsd 1654117859.896839 CALL sigprocmask(SIG_SETMASK,0x404563db0,0) 12339 100591 none-amd64-freebsd 1654117859.896840 RET sigprocmask 0 12339 100591 none-amd64-freebsd 1654117859.896842 CALL thr_self(0x404563ca8) 12339 100591 none-amd64-freebsd 1654117859.896844 RET thr_self 0 12339 100591 none-amd64-freebsd 1654117859.896845 CALL read(0x6f57,0x404563cfe,0x1) 12339 100591 none-amd64-freebsd 1654117859.896847 CSW stop kernel "pipelk" 12339 100583 none-amd64-freebsd 1654117859.896849 GIO fd 28503 read 1 byte "T" 12339 100583 none-amd64-freebsd 1654117859.896852 RET read 1 12339 100583 none-amd64-freebsd 1654117859.896853 CSW stop user "ast" 12339 100590 none-amd64-freebsd 1654117859.896854 CSW resume kernel "pipelk" 12339 100590 none-amd64-freebsd 1654117859.896854 CSW stop kernel "piperd" 12339 100589 none-amd64-freebsd 1654117859.896855 CSW resume kernel "pipelk" 12339 100589 none-amd64-freebsd 1654117859.896855 CSW stop kernel "piperd" 12339 100588 none-amd64-freebsd 1654117859.896856 CSW resume kernel "pipelk" 12339 100588 none-amd64-freebsd 1654117859.896856 CSW stop kernel "piperd" [REPEATS, TRIMMMED] 12339 100590 none-amd64-freebsd 1654117859.896896 CSW resume kernel "piperd" 12339 100590 none-amd64-freebsd 1654117859.896897 CSW stop kernel "piperd" 12339 100089 none-amd64-freebsd Events dropped. 12339 100089 none-amd64-freebsd 1654118042.172196 CALL thr_self(0x40268d7f8) 12339 100089 none-amd64-freebsd 1654118042.172198 RET thr_self 0 12339 100089 none-amd64-freebsd 1654118042.172202 CALL thr_self(0x40268d788) 12339 100089 none-amd64-freebsd 1654118042.172204 RET thr_self 0 12339 100089 none-amd64-freebsd 1654118042.172206 CALL read(0x6f57,0x40268d7de,0x1) 12339 100584 none-amd64-freebsd 1654118042.172217 CSW stop kernel "piperd" 12339 100089 none-amd64-freebsd 1654118042.172221 CSW stop kernel "piperd" 12339 100584 none-amd64-freebsd 1654118042.172222 CSW resume kernel "piperd" 12339 100584 none-amd64-freebsd 1654118042.172222 CSW stop kernel "piperd" [REPEATS, TRIMMMED] 12339 100089 none-amd64-freebsd 1654118042.172259 CSW stop kernel "piperd" 12339 100584 none-amd64-freebsd 1654118042.172260 CSW resume kernel "piperd" 12339 100089 none-amd64-freebsd Events dropped. 12337 100093 sh 1654117857.635559 CSW stop kernel "wait" 12337 100093 sh 1654118057.965243 CSW resume kernel "wait" 12337 100093 sh 1654118057.965258 RET wait4 12339/0x3033 12337 100093 sh 1654118057.965356 CALL fstatat(AT_FDCWD,0x7fffffffe0c0,0x7fffffffe4c0,0) 12337 100093 sh 1654118057.965359 NAMI "/usr/share/nls/C.UTF-8/libc.cat" 12337 100093 sh 1654118057.965363 RET fstatat -1 errno 2 No such file or directory 12337 100093 sh 1654118057.965367 CALL fstatat(AT_FDCWD,0x7fffffffe0c0,0x7fffffffe4c0,0) 12337 100093 sh 1654118057.965369 NAMI "/usr/share/nls/libc/C.UTF-8" 12337 100093 sh 1654118057.965371 RET fstatat -1 errno 2 No such file or directory 12337 100093 sh 1654118057.965373 CALL fstatat(AT_FDCWD,0x7fffffffe0c0,0x7fffffffe4c0,0) 12337 100093 sh 1654118057.965375 NAMI "/usr/local/share/nls/C.UTF-8/libc.cat" 12337 100093 sh 1654118057.965377 RET fstatat -1 errno 2 No such file or directory 12337 100093 sh 1654118057.965380 CALL fstatat(AT_FDCWD,0x7fffffffe0c0,0x7fffffffe4c0,0) 12337 100093 sh 1654118057.965381 NAMI "/usr/local/share/nls/libc/C.UTF-8" 12337 100093 sh 1654118057.965383 RET fstatat -1 errno 2 No such file or directory 12337 100093 sh 1654118057.965410 CALL write(0x2,0x80184c000,0x7) 12337 100093 sh 1654118057.965417 GIO fd 2 wrote 7 bytes "Killed " A+ Paul From nobody Wed Jun 1 22:47:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8C9841B67F51 for ; Wed, 1 Jun 2022 22:48:08 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail2.ambrisko.com (mail2.ambrisko.com [70.91.206.91]) by mx1.freebsd.org (Postfix) with ESMTP id 4LD46v53grz3Gn5 for ; Wed, 1 Jun 2022 22:48:07 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) IronPort-SDR: 90JHtKqKL/L4eznzBaDIxrg83nLhFDcKO38YJzmWCFsnxmVQPMNsjbmgMrqA9Bse4IPdUUWQRC /OxRtS8L9kU7FfGBVlwtd715NWBO5dNSw= X-Ambrisko-Me: Yes IronPort-Data: A9a23:tftcL610Rp4x2B2o9vbD5atxkn2cJEfYwER7XKvMYLTBsI5bpzUAm GocW26GOPqOZ2f2e9FyaIzgox4GucfQytUyGgY9+CA2RRqmiyZl6fd1j6vUF3nPRiH7oc4OA /w2MrEsFuhtJpPhjkzF3obJ/CAUOZ6gFuKU5N7sYkiddCc8IMsToUsLd90R3uaEteOE7zal4 rselSF/1GiNgFaYOkpMg06KRYgGUP7a4Fv0tXRmDRxHUcO3e9D40fsiya+Nw3vQGuG4H8a7Q frO1rew+iXQ+h03C8imlfDwdUhirrz6ZFnUzCMIC+77xEIqSi8ais7XMNIVbE1Nii6KmPh4z d9XtIezTkEiOaikdOE1DkMGTXEjVUFB0PqdSZSliuSQ10zLd3z20cJqF10eIYEIvO1wR3xNn dQWMj0AZAuPwuK/y7G2UPJEiN4uIcPwMMUYoH4I8N1zJZ7KWrjYTr/U6MUCmj41jNpPBvXZI cEebFJSgN37S0UnEj8q5FgWxY9EX1HzLG9Vrky7v60y7zSBxQB9yuK0YtPQcMaLXsZStk+dr HjH5Gf+RBodMYXHmzaC93utgM7JnD/6CN9KTezkrqYyjQ3B3HEXBT0XSUC//auzhHmhVo8NM EcT4Ccv8/Q/rRT5UtnnUhSki3eYpRpACcFIGug35VjVmKrZ6gqUHEYeSTtFZIB0vcM6X2Zzh FaMlcnoHj9omLSQQ2ic7bST6zi1PHFNf2MFYCYFSyoD4sXi8Nxr10OTFo47Hffs3NPvGDz2z zSblwQEhu0e3ZwRyqG23VHbmDbw9JLHeRE4u1fMVWW/4wInOIP8P9606ULW5OprJZqCSgXTp 2ANnsWT4bxcDZyJkyDREuwBEKvzvqSENiHRm1hmG98o8j63+mWgesZb5zQnfBVlNcMNeDnIZ k7PuFMMvMYCYCPyNaInMZisD8kKzLT7EYW3X//ZWdNCf5xteVLV5yppf0ORgzjgnRR+i605I pvHI8+gAWxAUfZ8wSCoSv1Hl7YuzDo/3mDUA5v8yk3/g7aZYXeUT5YDMUePPr1htfLY+F2N/ oYNLdaOxjVeTPb6M3ve/oMkJFwXKWQ2WMLtoMtNe+/fegdrFQnN0RMKLW/Nr2C9o5loqw== IronPort-HdrOrdr: A9a23:+TQcbK15kOdyAqG/5dbE7wqjBLIkLtp133Aq2lEZdPWaSK2lfu SV7ZMmPH7P+VIssR4b9exoVJPufZqYz+8S3WBzB8bGYOCFghrKEGgK1+KLqFDd8m/Fh4xgPM xbE5SWZuefMbBL5/yR3DWF Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 01 Jun 2022 14:42:13 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.17.1/8.17.1) with ESMTPS id 251MlxWU084346 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 1 Jun 2022 15:47:59 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) X-Authentication-Warning: internal.ambrisko.com: Host localhost [127.0.0.1] claimed to be ambrisko.com Received: (from ambrisko@localhost) by ambrisko.com (8.17.1/8.17.1/Submit) id 251MlwvU084345; Wed, 1 Jun 2022 15:47:58 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 1 Jun 2022 15:47:58 -0700 From: Doug Ambrisko To: Karl Pielorz Cc: freebsd-hackers@freebsd.org Subject: Re: Ice Lake / C621A supported, or anyone actually running on it? Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LD46v53grz3Gn5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ambrisko@ambrisko.com has no SPF policy when checking 70.91.206.91) smtp.mailfrom=ambrisko@ambrisko.com X-Spamd-Result: default: False [-0.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.792]; FREEFALL_USER(0.00)[ambrisko]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[ambrisko.com]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.948]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:70.88.0.0/14, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 01, 2022 at 02:04:00PM +0100, Karl Pielorz wrote: | We're looking at some new kit which is Intel Ice Lake (Xeon Scaleable 3rd | Gen) - apparently based on C621A chipset. | | I can't find anyone (e.g. via search engine) running FBSD on this - so just | wondered what the chances are it would boot /work? Or if anyone actually | has it running on this kit? NIC's don't seem too outlandish (Intel i350) - | but it has 'flexible' bays which can apparently host SATA3 or nvme drives - | which looks concerning - support wise... FreeBSD current seems to run on Ice Lake, Rome & Milan that $work makes ... Finally got a VIC driver limping along to UEFI PXE boot our blade or rack servers. Some systems support SATA/SAS and NVME u.2 but not in tri-mode. Some systems have the u.2 NVME routed to the CPU directly or through a switch. I bounce them between Linux and FreeBSD as needed. Doug A. From nobody Thu Jun 2 03:15:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E7E919C7728 for ; Thu, 2 Jun 2022 03:15:46 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDB3j4HmSz4Ybv for ; Thu, 2 Jun 2022 03:15:45 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f45.google.com with SMTP id l9-20020a056830268900b006054381dd35so2593534otu.4 for ; Wed, 01 Jun 2022 20:15:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TbA6f8Ur/+eIN8UnL9nNqAH8UZWARl3Od6wmFNMXki8=; b=yyDym6pESgW3VCEh6xmR4ZCLezlaxo9Qz93nfJCOwjuoETHTkLYY9JV3thdFKg1tjv RcisXuhI91OVQsUtmUuqZQfrSJUUU2qik3OTAY4fdpq8v+IL049c5BEkNXAVzyCVPdUl 7es/spwZSsdqZXDGQOXOw18JUTH8zcwTyewU9YSKxnH8KvWY5iPaVt2TYcUJDOS7g/ZV gmDVKCSiUCcxCoOlnXtbPOZKotqo0iythIzLQMcDXqc7Xr5wHFn/+H/jemmBtolsw99w R7QBRLq1GQbEZ9Ei5daiEoBPGw2DilgLAmM+c0pC2mrrhxzfRQkVgGSR2JEetygq56Hf xr4Q== X-Gm-Message-State: AOAM531UhIbwU16huHOICdAA+wUWkED4s5fHnTT7xjYrLE9SBadad3BZ FvNih1MQg4qteuKktYusU2QX6ZxOKP7fqrEy0SguyNqO+zg= X-Google-Smtp-Source: ABdhPJxI+P7Zr+pxPbR7PqotB/hYFQOhE+lggZ4nt542KOPvPHRVBiWPlDZ/ptoEfoEA86lz+iMnE9g+5drb66iCnYE= X-Received: by 2002:a05:6830:4c3:b0:60b:2c2a:7d4b with SMTP id s3-20020a05683004c300b0060b2c2a7d4bmr1254426otd.371.1654139738869; Wed, 01 Jun 2022 20:15:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Wed, 1 Jun 2022 21:15:28 -0600 Message-ID: Subject: Dtrace, Rust, and LLVM13 To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LDB3j4HmSz4Ybv 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.45 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.02 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.45:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.98)[0.976]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.993]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.45:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; 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]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The best way to profile a Rust program on FreeBSD is with Brendan Gregg's Flamegraph[1]. This is based on dtrace's ustack() function. It used to work great. However, Rust v1.56.0 is based on LLVM13[2] and now dtrace can't print user stacks anymore. For example, With Rust 1.55.0 libc.so.7`__je_malloc_mutex_prefork+0x124 libc.so.7`__je_arena_prefork7+0x73 libc.so.7`_malloc_prefork+0x15b libthr.so.3`0x392e4a8c4686 libthr.so.3`_fork+0x18 test-dad15ed382b075cf`nix::unistd::fork::h358225d652a86eab+0xe test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::hb93c7cdf2b79d680+0x36 test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::_$u7b$$u7b$closure$u7d$$u7d$::h329a121974ff9291+0x11 test-dad15ed382b075cf`core::ops::function::FnOnce::call_once::h2261827bcba63036+0x11 test-dad15ed382b075cf`test::__rust_begin_short_backtrace::hefb7644d11da2ff9+0xa test-dad15ed382b075cf`test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hdaa0fb71aac8d97e+0x2f3 test-dad15ed382b075cf`std::sys_common::backtrace::__rust_begin_short_backtrace::h8bcc057a546c1087+0xce test-dad15ed382b075cf`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf7d978d08be459d0+0x6a test-dad15ed382b075cf`std::sys::unix::thread::Thread::new::thread_start::h6b52ca0eca213387+0x2b libthr.so.3`0x392e4a8c3a7a With Rust 1.56.0 libc.so.7`__je_malloc_mutex_prefork+0x124 libc.so.7`__je_arena_prefork7+0x73 libc.so.7`_malloc_prefork+0x15b libthr.so.3`0x1106cebc6686 libthr.so.3`_fork+0x18 test-b377ad62cc9e0624`nix::unistd::fork::hbf1ed55b658aa870+0xa 0x8 0xcccccccccccccccc See? dtrace still prints the C part of the stack, but it only prints one or sometimes two frames of the Rust stack. I'm not a compiler guy, so I don't know how to fix it. I don't even know if the problem lies in Rust or dtrace. Would any of you smart people be able to help here? This is a pretty important feature for Rust development. -Alan [1] https://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html [2] https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1560-2021-10-21 From nobody Thu Jun 2 04:59:00 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 98F7B1B63780 for ; Thu, 2 Jun 2022 04:59: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 4LDDMD1dZtz4lvc for ; Thu, 2 Jun 2022 04:59:20 +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 2524x1WC013382 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 2 Jun 2022 07:59:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 2524x0cY013381; Thu, 2 Jun 2022 07:59:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Jun 2022 07:59:00 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: Poul-Henning Kamp , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() Message-ID: References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4LDDMD1dZtz4lvc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.65 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_MEDIUM(0.98)[0.981]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.959]; NEURAL_SPAM_LONG(0.63)[0.632]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 01, 2022 at 01:03:19PM +0200, Sebastian Huber wrote: > Hello Poul-Henning, > > On 01/06/2022 09:25, Poul-Henning Kamp wrote: > > Sebastian Huber writes: > > > > > I try to understand how the PPS synchronization works in FreeBSD. It > > > seems that pps_capture() starts a transaction and pps_event() completes > > > the transaction if nothing interfered in the meantime. > > The answer to most of your questions are in ./i386/i386/elan-mmcr.c > > > > The PPS capture in the Soekris 4501 used two hardware counters, counting at the same rate. > > > > The first of the two were the timecounter, the other was started by the hardware signal. > > > > Sometime later the hardware signals interrupt processing would happen. > > > > By reading read both counters as close to instantaneously as possible, and compensated for the interrupt latency by subtracting the event-started counter from the timecounter. > > > > (See also:http://phk.freebsd.dk/soekris/pps/) > > thanks for the background information. > > What I don't understand is why the th_generation is checked three times > (pps_capture(): 1, pps_event(): 2) and not only once in pps_event() right > before we use the captured time. I am not sure about supposed use of the pps(9) API, but for me it looks like generation rechecks cut potentially CPU-consuming computation in the interrupt handler context. For instance, pps_event() seems to be used _some_ time after pps_capture(), and needs to do a lot. So there is a chance that the data from pps_capture() is already not relevant due to timecounter advance. On the other hand, single read of the generation should be quite cheap, the cache line should be hot and we spent it to avoid larger waste. In other words, doing it probably slighly improves system latency. Note that I did not wrote the code and speculataion above is a speculation. From nobody Thu Jun 2 10:49:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7B871B5CEC1 for ; Thu, 2 Jun 2022 10:50:04 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4LDN7t6QRwz3q9n for ; Thu, 2 Jun 2022 10:50:02 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 17693 invoked by uid 907); 2 Jun 2022 10:49:52 -0000 Received: from i5E86447F.versanet.de (HELO smtpclient.apple) (94.134.68.127) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Thu, 02 Jun 2022 20:49:52 +1000 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Hang ast / pipelk / piperd From: Jan Mikkelsen In-Reply-To: Date: Thu, 2 Jun 2022 12:49:45 +0200 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <6DBE2C6F-7F8B-457A-AB10-1912965C3376@transactionware.com> References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> To: Paul Floyd X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LDN7t6QRwz3q9n X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of janm@transactionware.com has no SPF policy when checking 203.14.245.7) smtp.mailfrom=janm@transactionware.com X-Spamd-Result: default: False [1.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.882]; FROM_HAS_DN(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[transactionware.com]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.47)[-0.466]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(1.00)[0.996]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 1 Jun 2022, at 23:27, Paul Floyd wrote: >=20 >=20 >=20 > On 6/1/22 14:16, Mark Johnston wrote: >> On Mon, May 30, 2022 at 09:35:05PM +0200, Paul Floyd wrote: >>>=20 >>>=20 >>> On 5/30/22 14:15, Mark Johnston wrote: >>>=20 >>>> "procstat -kk " might help to reveal what's going on, >>>> since it sounds like the hand/livelock is happening somewhere in = the >>>> kernel. >>>=20 >>> Not knowing much about the kernel, my guess is that this is related = to >>>=20 >>> commit 4808bab7fa6c3ec49b49476b8326d7a0250a03fa >>> Author: Alexander Motin >>> Date: Tue Sep 21 18:14:22 2021 -0400 >>>=20 >>> sched_ule(4): Improve long-term load balancer. >>>=20 >>> and this bit of ast code >>>=20 >>> doreti_ast: >>> /* >>> * Check for ASTs atomically with returning. Disabling CPU >>> * interrupts provides sufficient locking even in the SMP case, >>> * since we will be informed of any new ASTs by an IPI. >>> */ >>> cli >>> movq PCPU(CURTHREAD),%rax >>> testl $TDF_ASTPENDING | TDF_NEEDRESCHED,TD_FLAGS(%rax) >>> je doreti_exit >>> sti >>> movq %rsp,%rdi /* pass a pointer to the trapframe */ >>> call ast >>> jmp doreti_ast >>>=20 >>>=20 >>> The above commit seems to be migrating loaded threads to another = CPU. >> How did you infer that? The long-term load balancer should be = running >> fairly infrequently. >=20 >=20 > Well one thread is hung in > mi_switch+0xc2 ast+0x1e6 doreti_ast+0x1f >=20 > I found the above code referring to doreti_ast with grep and thought = that if the test always fails then it will loop forever. So I looked for = git commits containing TDF_ASTPENDING and TDF_NEEDRESCHED and found a = couple of commits mentioning these flags, scheduling and found the above = and the followup >=20 > commit 11f14b33629e552a451fdbfe653ebb0addd27700 > Author: Alexander Motin > Date: Sun Sep 26 12:03:05 2021 -0400 >=20 > sched_ule(4): Fix hang with steal_thresh < 2. >=20 > e745d729be60 caused infinite loop with interrupts disabled in load > stealing code if steal_thresh set below 2. Such configuration = should > not generally be used, but appeared some people are using it to > workaround some problems. >=20 > and I guessed they might be related. >=20 >> As a side note, I think we are missing ktrcsw() calls in some places, >> e.g., in turnstile_wait(). >>> My test system is a VirtualBox amd64 FreeBSD 13.1 with one CPU = running >>> on a 13.0 host. >>>=20 >>> I just tried restarting the VM with 2 CPUs and the testcase seems to = be >>> a lot better - it's been running in a loop for 10 minutes whereas >>> previously it would hang at least 1 in 5 times. >> Hmm. Could you, please, show the ktrace output with -H -T passed to >> kdump(1), together with fresh "procstat -kk" output? >> The fact that the problem apparently only occurs with 1 CPU suggests = a >> scheduler bug, indeed. >=20 >=20 > Here is the fresh procstat output >=20 > paulf@freebsd:~ $ procstat -kk 12339 > PID TID COMM TDNAME KSTACK=20 > 12339 100089 none-amd64-freebsd - mi_switch+0xc2 = sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 = umtxq_sleep+0x143 do_wait+0x3e5 __umtx_op_wait+0x53 sys__umtx_op+0x7e = amd64_syscall+0x10c fast_syscall_common+0xf8 >=20 > 12339 100582 none-amd64-freebsd - mi_switch+0xc2 = sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x1d1 = kern_clock_nanosleep+0x1c1 sys_nanosleep+0x3b amd64_syscall+0x10c = fast_syscall_common+0xf8 >=20 > 12339 100583 none-amd64-freebsd - mi_switch+0xc2 = ast+0x1e6 doreti_ast+0x1f >=20 > 12339 100584 none-amd64-freebsd - mi_switch+0xc2 = sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 = pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c = fast_syscall_common+0xf8 >=20 > 12339 100585 none-amd64-freebsd - mi_switch+0xc2 = intr_event_handle+0x167 intr_execute_handlers+0x4b Xapic_isr1+0xdc = sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1f2 = pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c = fast_syscall_common+0xf8 > [ =E2=80=A6 ] All these mi_switch+0xc2 hangs reminded me of something I saw once on = 13.1-RC2 back in April. The machine was running five concurrent =E2=80=9Cm= ake -j32 installword=E2=80=9D processes. The machine hung, disk activity stopped. Results of ^T on various = running commands: ^T on a =E2=80=9Ctail -F=E2=80=9D command: load: 1.93 cmd: tail 27541 [zfs teardown inactive] 393.65r 0.06u 0.10s = 0% 2548k mi_switch+0xc2 _sleep+0x1fc rms_rlock_fallback+0x90 = zfs_freebsd_reclaim+0x26 VOP_RECLAIM_APV+0x1f vgonel+0x342 = vnlru_free_impl+0x2f7 vn_alloc_hard+0xc8 getnewvnode_reserve+0x93 = zfs_zget+0x22 zfs_dirent_lookup+0x16b zfs_dirlook+0x7a zfs_lookup+0x3d0 = zfs_cache_lookup+0xa9 VOP_LOOKUP+0x30 cache_fplookup_noentry+0x1a3 = cache_fplookup+0x366 namei+0x12a=20 ^T on a zsh doing a cd to a UFS directory: load: 0.48 cmd: zsh 86937 [zfs teardown inactive] 84663.01r 0.06u 0.01s = 0% 6412k mi_switch+0xc2 _sleep+0x1fc rms_rlock_fallback+0x90 = zfs_freebsd_reclaim+0x26 VOP_RECLAIM_APV+0x1f vgonel+0x342 = vnlru_free_impl+0x2f7 vn_alloc_hard+0xc8 getnewvnode_reserve+0x93 = zfs_zget+0x22 zfs_dirent_lookup+0x16b zfs_dirlook+0x7a zfs_lookup+0x3d0 = zfs_cache_lookup+0xa9 lookup+0x45c namei+0x259 kern_statat+0xf3 = sys_fstatat+0x2f=20 ^T on an attempt to start gstat load: 0.17 cmd: gstat 63307 [ufs] 298.29r 0.00u 0.00s 0% 228k mi_switch+0xc2 sleeplk+0xf6 lockmgr_slock_hard+0x3e7 ffs_lock+0x6c = _vn_lock+0x48 vget_finish+0x21 cache_lookup+0x26c vfs_cache_lookup+0x7b = lookup+0x45c namei+0x259 vn_open_cred+0x533 kern_openat+0x283 = amd64_syscall+0x10c fast_syscall_common+0xf8=20 A short press of the system power button did nothing. The installworld target directories were on a ZFS filesystem with a = single mirror of two SATA SSDs. Unsure if it=E2=80=99s related because the rest of the stack traces are = different. However, the mi_switch+0xc2 triggered a memory. Regards, Jan M. From nobody Thu Jun 2 17:46:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1EE001957D09 for ; Thu, 2 Jun 2022 17:46:07 +0000 (UTC) (envelope-from mandree@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 4LDYMz0PDJz3QBH for ; Thu, 2 Jun 2022 17:46:07 +0000 (UTC) (envelope-from mandree@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654191967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=l6froxnHScbbifZt3cZ52fd5cbgD3z0TjiXSO4hvTrQ=; b=sANEdhwE164k0ItujuXdGUmfRnygWJEYcE9vTT8k4U42gsks6t7LqiXzoq7qJW09ZqPWJH z0uK3rEEj71CsqwmAKFsfDod+e6VxQwy0FC+rA2ycqKAAz9oMiwoxl5Eufn+eh9umVCv1C hiZZmNYP5m0eVCHLj7+SBAYKEcaHeEdjV2/njTRMTYrS1ywYpsy9L0S6bNDtx7Nf2QfSeM JFJMFw3nXsbP/DnoxEyKyWBZiyi+opknSG1hnlKD1g+XCUUw1ZUaZw8p6NJmpt44fUIzuA X4M91CLcmJ/Zsu76q4yH9+kG265Fvl78w4rr3WBdKuiCsuzKOkFpHybriG0VPQ== Received: from mandree.no-ip.org (pd9e070b0.dip0.t-ipconnect.de [217.224.112.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mandree/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id C26232734E for ; Thu, 2 Jun 2022 17:46:06 +0000 (UTC) (envelope-from mandree@FreeBSD.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by ryzen.an3e.de (Postfix) with ESMTP id 6EB97604E32 for ; Thu, 2 Jun 2022 19:46:04 +0200 (CEST) Message-ID: Date: Thu, 2 Jun 2022 19:46:04 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: FreeBSD Hackers From: Matthias Andree Subject: Looking for GSSAPI expertise, particularly GSSAPI_HEIMDAL porting of newer security/PuTTY 0.77 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654191967; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=l6froxnHScbbifZt3cZ52fd5cbgD3z0TjiXSO4hvTrQ=; b=vRTooo7t/dT7b+SUmjSDM/ydVjBVsdeazA6/usrXshXBTqUvR3IwwOA67jBJLQ9Bd9PzfM VctkqpviFmXpBc8QeDVxhbZo65CkwOrPN2o1UyGczSToTnFLHpeoWjXTI9Wi3sqVzH7ahn H7VGQAL8BVtdcp+Eps/P7Tc9hQKRdjLqZYc16uImm2Bzsz6L19Chume/W5OmoR86BMs7NI 9eQArzoyJ4fPcGsAV+O7pz7DB4FdD7VA8tG4vlYhf96oamUXcqfXkWLVvvY7rDmO6VPM6R M3zzhzpMLjUAZSByU33yXl964SGJJ4h0iAk9NMyoeLYnjEWfb5+LNCw8o0OICQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654191967; a=rsa-sha256; cv=none; b=Vr8HsNwBA8dDUlH3UTKKK5bmJePj4V5fL8pWR2N8kDTm/rIcIe7NwK/U/aIjJZPW9yvpRH MGwsqrq7qGA84Ilpnn6H1gxEdYGY9ggfYdpI97YBmuVTERfz2Lg7JPwVSiu7bwgGnyz2GE PUhKwQ7H9dCRIxmJBB32aNj0Y2bjAhXqzPYqEkZkaxBbTOH58piq6c/F40aUFNWqb3YoRO kVDuqhPZe1HecS4ZqwffUJ+QhAgxdoLzezOruwhJWoK0L/ck6sg8uVQ0V8hql9+x0RqcZm nvBA0iO+3EPzjt0UHAcTcimVXMFaXU9Ps7kg7oWNLWxdSdsFIRjeKZSaMZvOYg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N DQpHcmVldGluZ3MsDQoNCkkgYW0gdGhlIG1haW50YWluZXIgb2YgdGhlIHNlY3VyaXR5L3B1 dHR5IGFuZCBwdXR0eS1ub2d0ayBwb3J0cywgYW5kIHRoZSANCnVwc3RyZWFtIG1haW50YWlu ZXIgcmVjZW50bHkgKGJldHdlZW4gMC43NiBhbmQgMC43Nykgc3dpdGNoZWQgYnVpbGQgDQpz eXN0ZW0gZnJvbSBhdXRvY29uZiB0byBjbWFrZSwgYW5kIG5vdyB3ZSdyZSBhIGJpdCB0cnlp bmcgdG8gZml4IHVwIHRoZSANCmJyb2tlbiBiaXRzIGFuZCBwaWVjZXMgKGFrYSBmYWxsb3V0 KSB0aGF0IGNhdXNlZCBtZSB0byBkaXNhYmxlIA0KR1NTQVBJX0JBU0UgYW5kIEdTU0FQSV9I RUlNREFMIGZvciBub3cuDQoNClNwZWNpZmljYWxseSwgaXMgdGhlcmUgc29tZW9uZSB3aG8g aGFzIHNvbWUgdGltZSBhdCBoYW5kcyB0byBwb2ludCBtZSB0byANCmdvb2QgR1NTQVBJIHBy YWN0aWNhbCBjb2RpbmcgZ3VpZGVzLCBvciBoYXMgZXZlbiBtb3JlIHRpbWUgc28gd2UgY2Fu IGdvIA0Kb3ZlciBwYXJ0aWN1bGFyIGlzc3VlcyBoYW5kcy1vbiwgd2l0aCBJUkMgb3Igc29t ZSBvdGhlciBjaGF0IHNvZnR3YXJlPw0KDQpJc3N1ZXMgSSBhbSBjdXJyZW50bHkgZmFjaW5n Og0KDQoxLiBHU1NBUElfQkFTRSAtIHdlIGhhdmUgYW4gdXBzdHJlYW0gcGF0Y2ggdGhhdCBt aWdodCBtYWtlIHRoaW5ncyB3b3JrLCANCmJ1dCBleGVjdXRhYmxlcyBvbmx5IGVuZCB1cCB3 aXRoIGxpYmdzc2FwaS5zbyBpbiBhZGRpdGlvbiB0byBvdGhlciBsaWJzLCANCmJ1dCBubyBn c3NhcGlfa3JiNSwgcm9rZW4sIGNyeXB0bywgLi4uIChpbiBzdGFyayBjb250cmFzdCB0byB3 aGF0IEkgYW0gDQpnZXR0aW5nIHdpdGggdGhlIHNlY3VyaXR5L2tyYjUgcG9ydCBiYXNlZCBi dWlsZCB3aXRoIEdTU0FQSV9NSVQpLg0KDQoyLiB0ZXN0IHN5c3RlbSB3aGVyZSBJIGNhbiBv YnRhaW4gYSBLZXJiZXJvcyB0aWNrZXQgd2l0aCBraW5pdCBhbmQgbG9nIA0KaW4gdG8gYW4g dW5wcml2aWxlZ2VkIFNTSCBhY2NvdW50IGFuZCBwb3NzaWJseSB0ZXN0IEdTU0FQSSBjcmVk ZW50aWFsIA0KZGVsZWdhdGlvbi4NCg0KMy4gR1NTQVBJX0hFSU1EQUwgLSBhcHBhcmVudGx5 IHdlIG5vdyBnZXQgY2xhc2hlcyBiZXR3ZWVuIA0KYXBwbGljYXRpb24tbG9jYWwgaGVhZGVy cyBhbmQgSGVpbWRhbCBsaWJyYXJ5IGhlYWRlcnM6DQoNCj4gRkFJTEVEOiBzc2gvQ01ha2VG aWxlcy9zc2hjb21tb24uZGlyL3Bnc3NhcGkuYy5vIC91c3IvbG9jYWwvbGliZXhlYy9jY2Fj aGUvY2MgLURIQVZFX0NNQUtFX0ggLUkvdXNyL3BvcnRzL3NlY3VyaXR5L3B1dHR5L3dvcmsv cHV0dHktMC43Ny9jaGFyc2V0IC1JL3Vzci9sb2NhbC9pbmNsdWRlL2d0ay0zLjAgLUkvdXNy L2xvY2FsL2luY2x1ZGUvcGFuZ28tMS4wIC1JL3Vzci9sb2NhbC9pbmNsdWRlIC1JL3Vzci9s b2NhbC9pbmNsdWRlL2dsaWItMi4wIC1JL3Vzci9sb2NhbC9saWIvZ2xpYi0yLjAvaW5jbHVk ZSAtSS91c3IvbG9jYWwvaW5jbHVkZS9oYXJmYnV6eiAtSS91c3IvbG9jYWwvaW5jbHVkZS9m cmVldHlwZTIgLUkvdXNyL2xvY2FsL2luY2x1ZGUvbGlicG5nMTYgLUkvdXNyL2xvY2FsL2lu Y2x1ZGUvZnJpYmlkaSAtSS91c3IvbG9jYWwvaW5jbHVkZS9jYWlybyAtSS91c3IvbG9jYWwv aW5jbHVkZS9waXhtYW4tMSAtSS91c3IvbG9jYWwvaW5jbHVkZS9nZGstcGl4YnVmLTIuMCAt SS91c3IvbG9jYWwvaW5jbHVkZS9naW8tdW5peC0yLjAgLUkvdXNyL2xvY2FsL2luY2x1ZGUv bGliZXBvbGwtc2hpbSAtSS91c3IvbG9jYWwvaW5jbHVkZS9hdGstMS4wIC1JL3Vzci9sb2Nh bC9pbmNsdWRlL2F0LXNwaTItYXRrLzIuMCAtSS91c3IvbG9jYWwvaW5jbHVkZS9kYnVzLTEu MCAtSS91c3IvbG9jYWwvbGliL2RidXMtMS4wL2luY2x1ZGUgLUkvdXNyL2xvY2FsL2luY2x1 ZGUvYXQtc3BpLTIuMCAtSS91c3IvbG9jYWwvaW5jbHVkZS9oZWltZGFsIC1JL3Vzci9wb3J0 cy9zZWN1cml0eS9wdXR0eS93b3JrL3B1dHR5LTAuNzcgLUkvdXNyL3BvcnRzL3NlY3VyaXR5 L3B1dHR5L3dvcmsvLmJ1aWxkL0NNYWtlRmlsZXMgLUkvdXNyL3BvcnRzL3NlY3VyaXR5L3B1 dHR5L3dvcmsvcHV0dHktMC43Ny91bml4IC1JL3Vzci9wb3J0cy9zZWN1cml0eS9wdXR0eS93 b3JrL3B1dHR5LTAuNzcvdGVybWluYWwgLU8yIC1waXBlICAtZnN0YWNrLXByb3RlY3Rvci1z dHJvbmcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLU8yIC1waXBlICAtZnN0YWNrLXByb3RlY3Rv ci1zdHJvbmcgLWZuby1zdHJpY3QtYWxpYXNpbmcgLUkvdXNyL2xvY2FsL2luY2x1ZGUvaGVp bWRhbCAtTUQgLU1UIHNzaC9DTWFrZUZpbGVzL3NzaGNvbW1vbi5kaXIvcGdzc2FwaS5jLm8g LU1GIHNzaC9DTWFrZUZpbGVzL3NzaGNvbW1vbi5kaXIvcGdzc2FwaS5jLm8uZCAtbyBzc2gv Q01ha2VGaWxlcy9zc2hjb21tb24uZGlyL3Bnc3NhcGkuYy5vIC1jIC91c3IvcG9ydHMvc2Vj dXJpdHkvcHV0dHkvd29yay9wdXR0eS0wLjc3L3NzaC9wZ3NzYXBpLmMNCj4gL3Vzci9wb3J0 cy9zZWN1cml0eS9wdXR0eS93b3JrL3B1dHR5LTAuNzcvc3NoL3Bnc3NhcGkuYzo5MDoxNTog ZXJyb3I6IGV4cGVjdGVkIGlkZW50aWZpZXIgb3IgJygnDQo+IGNvbnN0X2dzc19PSUQgR1NT X0NfTlRfVVNFUl9OQU1FICAgICAgICAgICA9IG9pZHMrMDsNCj4gICAgICAgICAgICAgICBe DQo+IC91c3IvbG9jYWwvaW5jbHVkZS9oZWltZGFsL2dzc2FwaS9nc3NhcGkuaDoyOTE6Mjk6 IG5vdGU6IGV4cGFuZGVkIGZyb20gbWFjcm8gJ0dTU19DX05UX1VTRVJfTkFNRScNCj4gI2Rl ZmluZSBHU1NfQ19OVF9VU0VSX05BTUUgKCZfX2dzc19jX250X3VzZXJfbmFtZV9vaWRfZGVz YykNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4NCj4gL3Vzci9wb3J0cy9zZWN1 cml0eS9wdXR0eS93b3JrL3B1dHR5LTAuNzcvc3NoL3Bnc3NhcGkuYzo5MDoxNTogZXJyb3I6 IGV4cGVjdGVkICcpJw0KPiAvdXNyL2xvY2FsL2luY2x1ZGUvaGVpbWRhbC9nc3NhcGkvZ3Nz YXBpLmg6MjkxOjI5OiBub3RlOiBleHBhbmRlZCBmcm9tIG1hY3JvICdHU1NfQ19OVF9VU0VS X05BTUUnDQo+ICNkZWZpbmUgR1NTX0NfTlRfVVNFUl9OQU1FICgmX19nc3NfY19udF91c2Vy X25hbWVfb2lkX2Rlc2MpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQo+IC91 c3IvcG9ydHMvc2VjdXJpdHkvcHV0dHkvd29yay9wdXR0eS0wLjc3L3NzaC9wZ3NzYXBpLmM6 OTA6MTU6IG5vdGU6IHRvIG1hdGNoIHRoaXMgJygnDQo+IC91c3IvbG9jYWwvaW5jbHVkZS9o ZWltZGFsL2dzc2FwaS9nc3NhcGkuaDoyOTE6Mjg6IG5vdGU6IGV4cGFuZGVkIGZyb20gbWFj cm8gJ0dTU19DX05UX1VTRVJfTkFNRScNCj4gI2RlZmluZSBHU1NfQ19OVF9VU0VSX05BTUUg KCZfX2dzc19jX250X3VzZXJfbmFtZV9vaWRfZGVzYykNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgXg0KPiAvdXNyL3BvcnRzL3NlY3VyaXR5L3B1dHR5L3dvcmsvcHV0dHktMC43 Ny9zc2gvcGdzc2FwaS5jOjkxOjE1OiBlcnJvcjogZXhwZWN0ZWQgaWRlbnRpZmllciBvciAn KCcNCj4gY29uc3RfZ3NzX09JRCBHU1NfQ19OVF9NQUNISU5FX1VJRF9OQU1FICAgID0gb2lk cysxOw0KPiAgICAgICAgICAgICAgIF4gDQoNCg0KVElBLg0KDQpSZWdhcmRzLA0KTWF0dGhp YXMNCg== From nobody Thu Jun 2 20:55:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BD9AC1B5E6CE for ; Thu, 2 Jun 2022 20:55:15 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDdZC0X2Mz4c5r; Thu, 2 Jun 2022 20:55:15 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72b.google.com with SMTP id c144so2081375qkg.11; Thu, 02 Jun 2022 13:55:15 -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=niDxoMOEs2hwUkqQVVLEAV0MGA6gs+ZqeNxIKtHjQgI=; b=cjVXNgZHk5tvkrFLzGN9UNoXSGp4GSRIxkIxPTpczXOHupFTFXK0d528Qs3gAXow2/ EG199XETKNYbLic5XoMFuDMIpmF0DMWo752DPPgoA+x+HnrulgXqgjcvb5vSRpPtglcF iAJ/L/FaEYferZGy53iiSCWqUGReFoMQZ9nVtJhAHTao/5spB6guAMf4KtsCFuwpuJj/ CK3PonsXdPqubWiWVAd+p5909txcM9YtTaT0nbZbiQP2dFDeqF/2zYtqhjePR8xeAZ94 6oyNljdz3cKqLH5ZGLgZtoIs35T1fDDkp0p5LEcrOwgNNZ9qwyQnmiiYjXTaTcynpWPu lnwg== 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=niDxoMOEs2hwUkqQVVLEAV0MGA6gs+ZqeNxIKtHjQgI=; b=qlcil3owmDtjplYl8P+iPzZmFNUF0nG10jULeQLnkHQewHowpniZ9we23/EEwj471J b0G+rrYiEzjUD4q8yehG6+C9gobe3JTlIsQoXju5O28PtjANTOcpgdFL+awqJRoYhRmP gLTCIKqWUxis6zdDjxe661DL16pSbKCSjY0ufbEJPPnvAJlm7L7L9DaZnqxqEPRUmqtU PMbCZLCF+7UgRu/x4KYvkXLkcWdnvdIFf0z9bk5vhvG6nPyUO5VwNXTxAzK+g0gMj48K hSy1ZBttREj2YB+tWw+oNM+0peRr8PQFUaydvF2YCUvRLQS3ldRE//SHDRijz1vligdc J3Ow== X-Gm-Message-State: AOAM530X4z8jGCixFuoWs0vVoJrgAxJgLD5CPQWXRoO0HGqVSVfjBUcr fQX7urgkossfmzBvMG7iNKmKt71Rz1Y= X-Google-Smtp-Source: ABdhPJyG0VwyAAqfAKFo+fOdbxiAvshlUjElrVP6g1NbkedarKr+lyFZwAkf3fbIeCH5WPhttrk7LA== X-Received: by 2002:a05:620a:b89:b0:6a3:4c5d:375d with SMTP id k9-20020a05620a0b8900b006a34c5d375dmr4478054qkh.249.1654203314137; Thu, 02 Jun 2022 13:55:14 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id o17-20020a05622a139100b002f90517bc25sm3691123qtk.41.2022.06.02.13.55.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 13:55:13 -0700 (PDT) Date: Thu, 2 Jun 2022 16:55:10 -0400 From: Mark Johnston To: Alan Somers Cc: FreeBSD Hackers Subject: Re: Dtrace, Rust, and LLVM13 Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LDdZC0X2Mz4c5r X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cjVXNgZH; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72b as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.45 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.25)[0.252]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72b:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 01, 2022 at 09:15:28PM -0600, Alan Somers wrote: > The best way to profile a Rust program on FreeBSD is with Brendan > Gregg's Flamegraph[1]. This is based on dtrace's ustack() function. > It used to work great. However, Rust v1.56.0 is based on LLVM13[2] > and now dtrace can't print user stacks anymore. For example, > > With Rust 1.55.0 > libc.so.7`__je_malloc_mutex_prefork+0x124 > libc.so.7`__je_arena_prefork7+0x73 > libc.so.7`_malloc_prefork+0x15b > libthr.so.3`0x392e4a8c4686 > libthr.so.3`_fork+0x18 > test-dad15ed382b075cf`nix::unistd::fork::h358225d652a86eab+0xe > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::hb93c7cdf2b79d680+0x36 > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::_$u7b$$u7b$closure$u7d$$u7d$::h329a121974ff9291+0x11 > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once::h2261827bcba63036+0x11 > test-dad15ed382b075cf`test::__rust_begin_short_backtrace::hefb7644d11da2ff9+0xa > test-dad15ed382b075cf`test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hdaa0fb71aac8d97e+0x2f3 > test-dad15ed382b075cf`std::sys_common::backtrace::__rust_begin_short_backtrace::h8bcc057a546c1087+0xce > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf7d978d08be459d0+0x6a > test-dad15ed382b075cf`std::sys::unix::thread::Thread::new::thread_start::h6b52ca0eca213387+0x2b What are the identifiers at the end of each function? > libthr.so.3`0x392e4a8c3a7a > > With Rust 1.56.0 > libc.so.7`__je_malloc_mutex_prefork+0x124 > libc.so.7`__je_arena_prefork7+0x73 > libc.so.7`_malloc_prefork+0x15b > libthr.so.3`0x1106cebc6686 > libthr.so.3`_fork+0x18 > test-b377ad62cc9e0624`nix::unistd::fork::hbf1ed55b658aa870+0xa > 0x8 > 0xcccccccccccccccc > > See? dtrace still prints the C part of the stack, but it only prints > one or sometimes two frames of the Rust stack. ustack() unwinds the stack using the frame pointer saved in each stack frame. It'll fail to unwind code compiled without a frame pointer, e.g., if -fomit-frame-pointer is specified to a C/C++ compiler. For this and similar reasons, we compile the base system with -fno-omit-frame-pointer by default. > I'm not a compiler guy, so I don't know how to fix it. I don't even > know if the problem lies in Rust or dtrace. Would any of you smart > people be able to help here? This is a pretty important feature for > Rust development. I'd guess that Rust started omitting use of the frame pointer in generated code. This commit seems to indicate that that's the case: https://github.com/rust-lang/rust/pull/48786/commits/5b800c231f45fcd823a3e958bb942cd620ceb3e0 Though, it's rather old. I'm not sure why the problem appeared only now. So maybe the problem is elsewhere, but the commit log also mentions a -Cforce-frame-pointers flag that you could try. While it's possible to unwind the stack without using a frame pointer, a frame pointer makes doing so dead simple. ustack() does the unwinding in the kernel, in DTrace probe context, and text addresses are resolved to symbol names in userspace. So it's generally desirable to keep the implementation simple. From nobody Thu Jun 2 21:27:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B3B01B66BBC for ; Thu, 2 Jun 2022 21:28:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oa1-f50.google.com (mail-oa1-f50.google.com [209.85.160.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDfJ63HGpz4jgw; Thu, 2 Jun 2022 21:28:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-d39f741ba0so8339598fac.13; Thu, 02 Jun 2022 14:28:06 -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=mGcdg+Fzmvs+82dakUUKCOsbML853D+OtgftCPAyywM=; b=HwP6qdlKaPGmVqtEPehPhZtHIdbVDz+SALJnIACRwfOgUza0f07ptKbH0ZKdfwxeL0 vWExf99xqrLRJE/UCM6M+sT6673BSAjSDkgp90z0vk6IL/vzHJMAYpiisi+hVfgbrRfE Rf5z16qsoM/Pq60rY3pEa4WpXzdHT3HbYaTPg7ppfUC/RY2swOEg/yqhDZ6iXYhh49qF 0x62IUBYSzyaUZlq4oL8p1C+tpc3Nsl2ODnezCS/RV60GXoRIdF0nX80wH4jL1bVnwEO r07xSprpm3o4OG4dCsTdT7d0s0a8M3FAcf1+T2D/V87f9l4/dK/8ABgKqCdc2y9RBgEL 4veQ== X-Gm-Message-State: AOAM532VqNY+tgZvQ+c3g12rcMyLM6eIablOwoC1QdD0WitOVUnDnPa5 +ODDOX4hIHAzUPvP9jCPegULGIL51MJoZcNA0R9+Kzmt X-Google-Smtp-Source: ABdhPJxHdUIvFmh3b2vlXrPl0mA1FIh/e4xIdlwNg4s/SjuWdC1icAUeWxuaWrZV2naq9sVeRtj10QazdS6TBi9eVU4= X-Received: by 2002:a05:6870:1787:b0:f2:b7a9:4ea7 with SMTP id r7-20020a056870178700b000f2b7a94ea7mr20464651oae.222.1654205279457; Thu, 02 Jun 2022 14:27:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 2 Jun 2022 15:27:48 -0600 Message-ID: Subject: Re: Dtrace, Rust, and LLVM13 To: Mark Johnston Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LDfJ63HGpz4jgw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.50 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.50:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.50:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 2, 2022 at 2:55 PM Mark Johnston wrote: > > On Wed, Jun 01, 2022 at 09:15:28PM -0600, Alan Somers wrote: > > The best way to profile a Rust program on FreeBSD is with Brendan > > Gregg's Flamegraph[1]. This is based on dtrace's ustack() function. > > It used to work great. However, Rust v1.56.0 is based on LLVM13[2] > > and now dtrace can't print user stacks anymore. For example, > > > > With Rust 1.55.0 > > libc.so.7`__je_malloc_mutex_prefork+0x124 > > libc.so.7`__je_arena_prefork7+0x73 > > libc.so.7`_malloc_prefork+0x15b > > libthr.so.3`0x392e4a8c4686 > > libthr.so.3`_fork+0x18 > > test-dad15ed382b075cf`nix::unistd::fork::h358225d652a86eab+0xe > > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::hb93c7cdf2b79d680+0x36 > > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::_$u7b$$u7b$closure$u7d$$u7d$::h329a121974ff9291+0x11 > > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once::h2261827bcba63036+0x11 > > test-dad15ed382b075cf`test::__rust_begin_short_backtrace::hefb7644d11da2ff9+0xa > > test-dad15ed382b075cf`test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hdaa0fb71aac8d97e+0x2f3 > > test-dad15ed382b075cf`std::sys_common::backtrace::__rust_begin_short_backtrace::h8bcc057a546c1087+0xce > > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf7d978d08be459d0+0x6a > > test-dad15ed382b075cf`std::sys::unix::thread::Thread::new::thread_start::h6b52ca0eca213387+0x2b > > What are the identifiers at the end of each function? You mean the hex number that comes before the offset? I think the Rust compiler uses those to disambiguate closures, which would otherwise have the same name. However, not all of these functions are closures. Maybe Rust always generates that identifier anyway? > > > libthr.so.3`0x392e4a8c3a7a > > > > With Rust 1.56.0 > > libc.so.7`__je_malloc_mutex_prefork+0x124 > > libc.so.7`__je_arena_prefork7+0x73 > > libc.so.7`_malloc_prefork+0x15b > > libthr.so.3`0x1106cebc6686 > > libthr.so.3`_fork+0x18 > > test-b377ad62cc9e0624`nix::unistd::fork::hbf1ed55b658aa870+0xa > > 0x8 > > 0xcccccccccccccccc > > > > See? dtrace still prints the C part of the stack, but it only prints > > one or sometimes two frames of the Rust stack. > > ustack() unwinds the stack using the frame pointer saved in each stack > frame. It'll fail to unwind code compiled without a frame pointer, > e.g., if -fomit-frame-pointer is specified to a C/C++ compiler. For > this and similar reasons, we compile the base system with > -fno-omit-frame-pointer by default. > > > I'm not a compiler guy, so I don't know how to fix it. I don't even > > know if the problem lies in Rust or dtrace. Would any of you smart > > people be able to help here? This is a pretty important feature for > > Rust development. > > I'd guess that Rust started omitting use of the frame pointer in > generated code. This commit seems to indicate that that's the case: > https://github.com/rust-lang/rust/pull/48786/commits/5b800c231f45fcd823a3e958bb942cd620ceb3e0 > Though, it's rather old. I'm not sure why the problem appeared only > now. So maybe the problem is elsewhere, but the commit log also > mentions a -Cforce-frame-pointers flag that you could try. > > While it's possible to unwind the stack without using a frame pointer, a > frame pointer makes doing so dead simple. ustack() does the unwinding > in the kernel, in DTrace probe context, and text addresses are resolved > to symbol names in userspace. So it's generally desirable to keep the > implementation simple. That works! Setting RUSTFLAGS="-C force-frame-pointers" allows dtrace to unwind the stacks in the resulting binaries. However, it still doesn't work when I build a Rust shared library. Any idea why that might be? From nobody Fri Jun 3 08:01:38 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 62FAC1B62799 for ; Fri, 3 Jun 2022 08:01:48 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDwMH2lw2z4sHG for ; Fri, 3 Jun 2022 08:01:47 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy05.your-server.de ([78.46.172.2]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nx2FX-000Mo6-TD; Fri, 03 Jun 2022 10:01:40 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nx2FX-000K89-QN; Fri, 03 Jun 2022 10:01:39 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 8149F4800DB; Fri, 3 Jun 2022 10:01:39 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id F0ov73lQhNMl; Fri, 3 Jun 2022 10:01:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1A8B148013B; Fri, 3 Jun 2022 10:01:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zs5Hw2LPwF7O; Fri, 3 Jun 2022 10:01:39 +0200 (CEST) Received: from [192.168.96.159] (unknown [192.168.96.159]) by mail.embedded-brains.de (Postfix) with ESMTPSA id F12394800DB; Fri, 3 Jun 2022 10:01:38 +0200 (CEST) Message-ID: Date: Fri, 3 Jun 2022 10:01:38 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: pps_capture() and pps_fetch() Content-Language: en-US To: Konstantin Belousov Cc: hackers@freebsd.org References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26560/Thu Jun 2 10:06:31 2022) X-Rspamd-Queue-Id: 4LDwMH2lw2z4sHG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[embedded-brains.de]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 02.06.22 06:59, Konstantin Belousov wrote: > On Wed, Jun 01, 2022 at 01:03:19PM +0200, Sebastian Huber wrote: >> Hello Poul-Henning, >> >> On 01/06/2022 09:25, Poul-Henning Kamp wrote: >>> Sebastian Huber writes: >>> >>>> I try to understand how the PPS synchronization works in FreeBSD. It >>>> seems that pps_capture() starts a transaction and pps_event() comple= tes >>>> the transaction if nothing interfered in the meantime. >>> The answer to most of your questions are in ./i386/i386/elan-mmcr.c >>> >>> The PPS capture in the Soekris 4501 used two hardware counters, count= ing at the same rate. >>> >>> The first of the two were the timecounter, the other was started by t= he hardware signal. >>> >>> Sometime later the hardware signals interrupt processing would happen= . >>> >>> By reading read both counters as close to instantaneously as possible= , and compensated for the interrupt latency by subtracting the event-star= ted counter from the timecounter. >>> >>> (See also:http://phk.freebsd.dk/soekris/pps/) >> >> thanks for the background information. >> >> What I don't understand is why the th_generation is checked three time= s >> (pps_capture(): 1, pps_event(): 2) and not only once in pps_event() ri= ght >> before we use the captured time. >=20 > I am not sure about supposed use of the pps(9) API, but for me it looks > like generation rechecks cut potentially CPU-consuming computation in t= he > interrupt handler context. For instance, pps_event() seems to be used = _some_ > time after pps_capture(), and needs to do a lot. So there is a chance > that the data from pps_capture() is already not relevant due to timecou= nter > advance. >=20 > On the other hand, single read of the generation should be quite cheap, > the cache line should be hot and we spent it to avoid larger waste. In > other words, doing it probably slighly improves system latency. >=20 > Note that I did not wrote the code and speculataion above is a speculat= ion. I just ask because we may want to use this code in a spacecraft and=20 every "if" increases the time to specify and test the implementation. The expensive part in pps_event() is after the th_generation checks. I=20 think from a performance point of view, the checks can be reduced to=20 just one th_generation check. I am more concerned if this would=20 introduce a subtle functional change. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Fri Jun 3 08:28:38 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 973F21B66DA7 for ; Fri, 3 Jun 2022 08:28:46 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LDwyP57cjz3Bs6 for ; Fri, 3 Jun 2022 08:28:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id CD5E389298; Fri, 3 Jun 2022 08:28:37 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2538ScMi080177 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jun 2022 08:28:38 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2538ScDg080165; Fri, 3 Jun 2022 08:28:38 GMT (envelope-from phk) Message-Id: <202206030828.2538ScDg080165@critter.freebsd.dk> To: Sebastian Huber cc: Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80163.1654244918.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Jun 2022 08:28:38 +0000 X-Rspamd-Queue-Id: 4LDwyP57cjz3Bs6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- Sebastian Huber writes: > On 02.06.22 06:59, Konstantin Belousov wrote: > > I am not sure about supposed use of the pps(9) API, but for me it look= s > > like generation rechecks cut potentially CPU-consuming computation in = the > > interrupt handler context. For instance, pps_event() seems to be used= _some_ > > time after pps_capture(), and needs to do a lot. So there is a chance > > that the data from pps_capture() is already not relevant due to timeco= unter > > advance. > > = > > On the other hand, single read of the generation should be quite cheap= , > > the cache line should be hot and we spent it to avoid larger waste. I= n > > other words, doing it probably slighly improves system latency. > > = > > Note that I did not wrote the code and speculataion above is a specula= tion. I would have to dig out 20 year old notes, which I am not even sure I know= where are, to find the definitive answer. I think the general thrust of Kontantin's theory above is not wrong, but am pretty sure that fast timecounter roll-over had a lot to do with it too. A 16 bit counter running at 10-20 MHz rolled over ~5 milliseconds. A lot of stuff have happened since then, modern timecounters last longer, our scheduling has become much better and the code has been improved in various ways (Konstantin's use of atomics for instance). > I just ask because we may want to use this code in a spacecraft and = > every "if" increases the time to specify and test the implementation. Weee... CODE in SPAAAAAAAACEEEEEeeeee! :-) > The expensive part in pps_event() is after the th_generation checks. I = > think from a performance point of view, the checks can be reduced to = > just one th_generation check. I am more concerned if this would = > introduce a subtle functional change. Assuming that your timecounter hardware does not roll over fast enough to open any races, I think that is correct. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Jun 3 13:10:10 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3049E1B51107 for ; Fri, 3 Jun 2022 13:10:23 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LF3CK4cjlz4qvb for ; Fri, 3 Jun 2022 13:10:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy05.your-server.de ([78.46.172.2]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nx747-0006ue-MA; Fri, 03 Jun 2022 15:10:11 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nx747-000WYp-J2; Fri, 03 Jun 2022 15:10:11 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 469C14800D4; Fri, 3 Jun 2022 15:10:11 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id OZMAKrYFFWWC; Fri, 3 Jun 2022 15:10:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ED597480135; Fri, 3 Jun 2022 15:10:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tELSReMR-vak; Fri, 3 Jun 2022 15:10:10 +0200 (CEST) Received: from [192.168.96.159] (unknown [192.168.96.159]) by mail.embedded-brains.de (Postfix) with ESMTPSA id CCDB94800D4; Fri, 3 Jun 2022 15:10:10 +0200 (CEST) Message-ID: <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> Date: Fri, 3 Jun 2022 15:10:10 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: pps_capture() and pps_fetch() Content-Language: en-US To: Poul-Henning Kamp Cc: Konstantin Belousov , hackers@freebsd.org References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> From: Sebastian Huber In-Reply-To: <202206030828.2538ScDg080165@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26561/Fri Jun 3 10:05:55 2022) X-Rspamd-Queue-Id: 4LF3CK4cjlz4qvb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_COUNT_SEVEN(0.00)[8]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 03.06.22 10:28, Poul-Henning Kamp wrote: >> The expensive part in pps_event() is after the th_generation checks. I >> think from a performance point of view, the checks can be reduced to >> just one th_generation check. I am more concerned if this would >> introduce a subtle functional change. > Assuming that your timecounter hardware does not roll over fast enough > to open any races, I think that is correct. Would a timecounter overflow within a time interval from th_generation=20 to th_generation + 1 not be a bug in general? static __inline void bintime_off(struct bintime *bt, u_int off) { struct timehands *th; struct bintime *btp; uint64_t scale; u_int delta, gen, large_delta; do { th =3D timehands; gen =3D atomic_load_acq_int(&th->th_generation); For example, if the thread gets interrupted here and the timecounter=20 overflows, then the measurement below would be wrong if th_generation=20 didn't change. btp =3D (struct bintime *)((vm_offset_t)th + off); *bt =3D *btp; scale =3D th->th_scale; delta =3D tc_delta(th); large_delta =3D th->th_large_delta; atomic_thread_fence_acq(); } while (gen =3D=3D 0 || gen !=3D th->th_generation); bintime_add_tc_delta(bt, scale, large_delta, delta); } --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Fri Jun 3 17:09:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 57A6D1BD9617 for ; Fri, 3 Jun 2022 17:09:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LF8Wg1dqVz4TT9; Fri, 3 Jun 2022 17:09:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x835.google.com with SMTP id hf10so6070092qtb.7; Fri, 03 Jun 2022 10:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=E/tyT0+6SyyulEL1AOQSsWHW3cEPk3QF49NIGDS8CcI=; b=Nj2CtAgbgCz6wL2QC1xponXfVvjEY+RGfi6P+slmx1YmasXbxq+gXZcx7SxKnjpQuN SdZnM3MCe7KrAn61ADaOBT6ZcSUCyO4GISRXNcOG8ozJTe3QpK8tpjn3eu08OlXNM9+A xN3eomIlyhAEsuignIzpektWabazNocfBMcGiHyVNep4jhRXy5nE2/77gT1CqqhBXK3/ mQYaS421B4ZjYXtaHymmM2AT7DZwArxS8yL60c5M2nA/JP1/p54O6mrqGKU+w938oD19 pYV9z+72V4vSquUfqbOfHNT5hWs4mF5bcHhWNNTPdeKDW5RYgC8B1dGg0nAfp/nb3tN5 Ncww== 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=E/tyT0+6SyyulEL1AOQSsWHW3cEPk3QF49NIGDS8CcI=; b=mcRO4BquBX2eL5zA0iRSWIkq4v/6hCngets2gSviFrH0z5YYFHKve1ZVEc2uuBzx0P LQAqjpBwm5CndzZC1IcuomgbCoY+RtKsW3+WPNIxumNA86uOIg03awBmkpVib8UXD+r/ FzgFRxgVU22z9CpdBURbdjgt3YiIE+quf5i7BA/sZcusY1g4Wt1mL3LpaMOsxYljTYKh x/U75EuuS1TDBzECAxsYo4AJjvQNKUipMnUPqb56FyxUWzwHBQ31AaFmfdRMgBHPvxSq nRgl+fc7y5BrA/l2VUr+Lke5JHfBoKksT1On/hx76TgQSY7Cx1ioQvjNUwYJtE/uy4pQ KA8Q== X-Gm-Message-State: AOAM530CD/y//vJI/YoEvh/8ZNRJ+omNRAMxyMjbdclk90Y9g/59z27Y a4R9u4rbiXe/ifuf0rDYQz7qmYIfcK8= X-Google-Smtp-Source: ABdhPJy7iMOKjLAh9Qr0iY2mxp6mJ2FbTWTeaKBtoAY9I8upzcufdcSMWtMdjs3o9SkELb6LsMJ0HA== X-Received: by 2002:ac8:5982:0:b0:2f3:b838:cdda with SMTP id e2-20020ac85982000000b002f3b838cddamr8500492qte.119.1654276183899; Fri, 03 Jun 2022 10:09:43 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id f6-20020a05622a104600b002f39b99f6a3sm5461899qte.61.2022.06.03.10.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jun 2022 10:09:43 -0700 (PDT) Date: Fri, 3 Jun 2022 13:09:40 -0400 From: Mark Johnston To: Alan Somers Cc: FreeBSD Hackers Subject: Re: Dtrace, Rust, and LLVM13 Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LF8Wg1dqVz4TT9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Nj2CtAgb; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from]; NEURAL_HAM_SHORT(-0.80)[-0.802]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 02, 2022 at 03:27:48PM -0600, Alan Somers wrote: > On Thu, Jun 2, 2022 at 2:55 PM Mark Johnston wrote: > > > > On Wed, Jun 01, 2022 at 09:15:28PM -0600, Alan Somers wrote: > > > The best way to profile a Rust program on FreeBSD is with Brendan > > > Gregg's Flamegraph[1]. This is based on dtrace's ustack() function. > > > It used to work great. However, Rust v1.56.0 is based on LLVM13[2] > > > and now dtrace can't print user stacks anymore. For example, > > > > > > With Rust 1.55.0 > > > libc.so.7`__je_malloc_mutex_prefork+0x124 > > > libc.so.7`__je_arena_prefork7+0x73 > > > libc.so.7`_malloc_prefork+0x15b > > > libthr.so.3`0x392e4a8c4686 > > > libthr.so.3`_fork+0x18 > > > test-dad15ed382b075cf`nix::unistd::fork::h358225d652a86eab+0xe > > > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::hb93c7cdf2b79d680+0x36 > > > test-dad15ed382b075cf`test::test_unistd::test_fork_and_waitpid::_$u7b$$u7b$closure$u7d$$u7d$::h329a121974ff9291+0x11 > > > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once::h2261827bcba63036+0x11 > > > test-dad15ed382b075cf`test::__rust_begin_short_backtrace::hefb7644d11da2ff9+0xa > > > test-dad15ed382b075cf`test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hdaa0fb71aac8d97e+0x2f3 > > > test-dad15ed382b075cf`std::sys_common::backtrace::__rust_begin_short_backtrace::h8bcc057a546c1087+0xce > > > test-dad15ed382b075cf`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hf7d978d08be459d0+0x6a > > > test-dad15ed382b075cf`std::sys::unix::thread::Thread::new::thread_start::h6b52ca0eca213387+0x2b > > > > What are the identifiers at the end of each function? > > You mean the hex number that comes before the offset? I think the > Rust compiler uses those to disambiguate closures, which would > otherwise have the same name. However, not all of these functions are > closures. Maybe Rust always generates that identifier anyway? Ok. Was just curious to know if there's something there that we should be demangling, but it seems not. > > > libthr.so.3`0x392e4a8c3a7a > > > > > > With Rust 1.56.0 > > > libc.so.7`__je_malloc_mutex_prefork+0x124 > > > libc.so.7`__je_arena_prefork7+0x73 > > > libc.so.7`_malloc_prefork+0x15b > > > libthr.so.3`0x1106cebc6686 > > > libthr.so.3`_fork+0x18 > > > test-b377ad62cc9e0624`nix::unistd::fork::hbf1ed55b658aa870+0xa > > > 0x8 > > > 0xcccccccccccccccc > > > > > > See? dtrace still prints the C part of the stack, but it only prints > > > one or sometimes two frames of the Rust stack. > > > > ustack() unwinds the stack using the frame pointer saved in each stack > > frame. It'll fail to unwind code compiled without a frame pointer, > > e.g., if -fomit-frame-pointer is specified to a C/C++ compiler. For > > this and similar reasons, we compile the base system with > > -fno-omit-frame-pointer by default. > > > > > I'm not a compiler guy, so I don't know how to fix it. I don't even > > > know if the problem lies in Rust or dtrace. Would any of you smart > > > people be able to help here? This is a pretty important feature for > > > Rust development. > > > > I'd guess that Rust started omitting use of the frame pointer in > > generated code. This commit seems to indicate that that's the case: > > https://github.com/rust-lang/rust/pull/48786/commits/5b800c231f45fcd823a3e958bb942cd620ceb3e0 > > Though, it's rather old. I'm not sure why the problem appeared only > > now. So maybe the problem is elsewhere, but the commit log also > > mentions a -Cforce-frame-pointers flag that you could try. > > > > While it's possible to unwind the stack without using a frame pointer, a > > frame pointer makes doing so dead simple. ustack() does the unwinding > > in the kernel, in DTrace probe context, and text addresses are resolved > > to symbol names in userspace. So it's generally desirable to keep the > > implementation simple. > > That works! Setting RUSTFLAGS="-C force-frame-pointers" allows dtrace > to unwind the stacks in the resulting binaries. However, it still > doesn't work when I build a Rust shared library. Any idea why that > might be? Doesn't work as in, the trace stops early like in your earlier example? Or names don't get resolved as you'd expect? I don't have any ideas offhand, you could try looking at disassembly of the generated code to see if a frame pointer is indeed maintained (generally I'd expect there to be a "push %rbp" as the first instruction of a function symbol, and "pop %rbp" before returning). For instance: https://rust.godbolt.org/z/WM7xP83WK From nobody Fri Jun 3 18:47:06 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 858E11B55A56 for ; Fri, 3 Jun 2022 18:47:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LFBgw3KFYz4jHL for ; Fri, 3 Jun 2022 18:47:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id B2E7F89298; Fri, 3 Jun 2022 18:47:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 253Il7St082106 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jun 2022 18:47:07 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 253Il6Y2082105; Fri, 3 Jun 2022 18:47:06 GMT (envelope-from phk) Message-Id: <202206031847.253Il6Y2082105@critter.freebsd.dk> To: Sebastian Huber cc: Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82103.1654282026.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Jun 2022 18:47:06 +0000 X-Rspamd-Queue-Id: 4LFBgw3KFYz4jHL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- Sebastian Huber writes: > On 03.06.22 10:28, Poul-Henning Kamp wrote: > >> The expensive part in pps_event() is after the th_generation checks. = I > >> think from a performance point of view, the checks can be reduced to > >> just one th_generation check. I am more concerned if this would > >> introduce a subtle functional change. > > Assuming that your timecounter hardware does not roll over fast enough > > to open any races, I think that is correct. > > Would a timecounter overflow within a time interval from th_generation=3D= 20 > to th_generation + 1 not be a bug in general? No, that is precisely the problem timecounter/timehands were made to solve= . We keep a ring of "timehands"[1] and they are all remain valid until they get reused (at which point their th_generation get incremented). pps_capture() latches both the (current) timehand, and that timehand's gen= eration. Even if the timehand is advanced 15 times before pps_event() finally gets = called, the latched timehand can still be used to calculate the time of the event. If the frequency is adjusted between pps_capture() and pps_event() that introduces an error in the resulting timestamp, but since they are supposed to be called "as fast as possible after each other", and since stable-state frequency adjustments are supposed to be tiny, that error can be ignored until you get well into Cesium territory. So as long as your timecounter does not overflow faster than timehands are updated, and you call pps_event() fast enough after pps_capture(), you're fine. Poul-Henning [1] Originally the ring was ten timehands, based on some handwaving about interrupt service times on PC hardware back then. Thesedays the size of the ring is set with a sysctl, defaulting to just two. You may want to increase that a bit for pps-capture. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Fri Jun 3 19:32:37 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D652C1BD2EC7 for ; Fri, 3 Jun 2022 19:32:42 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LFChQ3dK2z4mm1 for ; Fri, 3 Jun 2022 19:32:38 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id EDA8B89298; Fri, 3 Jun 2022 19:32:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 253JWcaK082988 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Jun 2022 19:32:38 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 253JWcG1082987; Fri, 3 Jun 2022 19:32:38 GMT (envelope-from phk) Message-Id: <202206031932.253JWcG1082987@critter.freebsd.dk> cc: Sebastian Huber , Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: <202206031847.253Il6Y2082105@critter.freebsd.dk> From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> <202206031847.253Il6Y2082105@critter.freebsd.dk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82985.1654284757.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 03 Jun 2022 19:32:37 +0000 X-Rspamd-Queue-Id: 4LFChQ3dK2z4mm1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; BLOCKLISTDE_FAIL(0.00)[130.225.244.222:server fail]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MISSING_TO(2.00)[]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[embedded-brains.de,gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- Poul-Henning Kamp writes: > -------- > Even if the timehand is advanced 15 times before pps_event() finally get= s called, For "15" read "${kern.timecounter.timehands_count} - 1" -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From nobody Sat Jun 4 20:05:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 620591BD33F0 for ; Sat, 4 Jun 2022 20:06:06 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]) (using TLSv1.3 with cipher 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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LFrNS2TZFz4ZMg for ; Sat, 4 Jun 2022 20:06:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 254K5qC2013999 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 4 Jun 2022 16:05:58 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sat, 4 Jun 2022 16:05:52 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Dumb pf.conf question Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4LFrNS2TZFz4ZMg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 2001:470:1f07:15ff::f7 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Due to an execss (to put it politely) of packets originating from IPv4-address-that-shall-not-be-mentioned, I decided to fix up my pf.conf file, which in very general terms looks like this: (a bunch of macro definitions: ext_if = external interface, int_if = internal interface, internal_ipv6 = 2001:xxxx:yyyy:zzzz::/120, internal_net = 10.0.0.0/8) (a couple of table definitions) (no options, traffic normalization, or queueing) scrub in all nat on $ext_if from $internal_net to any -> ($ext_if) (a bunch of rdr statements, none of which contain "quick") block all pass quick on lo0 pass quick on $int_if pass quick from $internal_ipv6 pass quick to $internal_ipv6 #nuisance ssh logins block quick on $ext_if from (nasty address) (lots more packet filtering rules that work) But that next-to-last line is not stopping packets from nasty address. What did I do wrong? From nobody Sat Jun 4 21:35:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EEB7B1BDFAA0 for ; Sat, 4 Jun 2022 21:35:47 +0000 (UTC) (envelope-from leres@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 4LFtN354lKz4jTW; Sat, 4 Jun 2022 21:35:47 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654378547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w8amf3mpAlYUhPSNp+UYPOJ/DgCP7uieVfEmdJouJno=; b=k36Asou3UFdvvM89udduTARh2DFuRAWqSlw+0PRKo2QzMELh9bb8K07xfIt0ksQcd/Cnkx mfQEUqSI7Vnw8xt9mc+2YdSMBjIiIYQdq/MDChGZGbVPmK0YDdLKG3//W/+MGH+AJwIz5c d9o07Hzy2fjfqo3NojGLkTB0ABvnYMpEVQaUFWMco0D0X3EioVZ+9Pn/g/d5B37ybZH5Se 0YBFJjdex7O7WJ2aKwfgvwzcs9eSAnvzxhGmFyfrOyiB21dpJYAYug9P99/8dFxF1EIfZo EGA8tX/bQEBHXyA6oZfVicjTOzFkCQn0Vvx2OkyjUel5oaU9+XGXosPkTDAuag== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe0b:a065]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 3BFD623BFA; Sat, 4 Jun 2022 21:35:46 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: Date: Sat, 4 Jun 2022 14:35:45 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Dumb pf.conf question Content-Language: en-US To: George Mitchell , FreeBSD Hackers References: From: Craig Leres In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654378547; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=w8amf3mpAlYUhPSNp+UYPOJ/DgCP7uieVfEmdJouJno=; b=NxEV5BKfkWlChyriAZZqtTp6pIJB4LP55bxqlRaTOT0W2e+nzcKVsam32q3OSlZHUqIvp8 T5DJohau5h5ri53590yGZqj7EX2c/zFQqSBVaXEVMI7LQvT4KPRvG7r7JnBTsCAEqFJGhW rnba/bSp08JxsRaHah9QUX9UPimzDVHPtXaqvuLktmK+C4wGd1f047UByDCi2C9reIsLcW Y8/xnXdKaxYMm0hOF6EZDNhEFKqo0TljHnW+6CFZHImk3bFh5rfccVB2Wazi8d0NX43BX5 06zPRo6yXUS1mIXf5jc2wkpjg5gL9F1y52+4wyZpoC0Xk1wGjIXgC9zuGPPEOw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654378547; a=rsa-sha256; cv=none; b=JmKRAXPPOo6eHaBuQeF6he7sxSEsIBKhWfI+64KJRCshjDz0zwFjSSclOZJ6jxOVrFZr1V JsycdhG9Di2vP4EGt8+AJetfl1bAftIYWg0Wl9kznFZBNRCSDCOvTzRwqFcVmsg2MXqQtU LOdIUN0qPja0gnRFMDXUmVOU3ZVCSU72uz/CcekbAuX50CnYBPw8KS8BcStImbAsyt75Tt Q09VJ4d6aginP7RIjlW7GRUGHgQOg6pun3wgVKtvulwY3P3KRSME64quRnqzckCIq03II0 R7cnYPWLYOKv+1woddy1AhLaDcYu/4dl3cPiSzDmzh0j20Mrs4rW9XyLwt+Arg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 6/4/22 13:05, George Mitchell wrote: > Due to an execss (to put it politely) of packets originating from > IPv4-address-that-shall-not-be-mentioned, I decided to fix up my > pf.conf file, which in very general terms looks like this: > > (a bunch of macro definitions: ext_if = external interface, >  int_if = internal interface, internal_ipv6 = 2001:xxxx:yyyy:zzzz::/120, >  internal_net = 10.0.0.0/8) > (a couple of table definitions) > (no options, traffic normalization, or queueing) > > scrub in all > nat on $ext_if from $internal_net to any -> ($ext_if) > > (a bunch of rdr statements, none of which contain "quick") > > block all > pass quick on lo0 > pass quick on $int_if > > pass quick from $internal_ipv6 > pass quick to $internal_ipv6 > > #nuisance ssh logins > block quick on $ext_if from (nasty address) > > (lots more packet filtering rules that work) > > But that next-to-last line is not stopping packets from nasty address. > What did I do wrong? I don't have a solution but let me suggest a strategy; normally I add "log" too all block rules so I can use tcpdump to to tell me what I'm blocking, e.g: tcpdump -ent -i pflog0 -e is particuarlly cool because it reports details such as rule number and interface. Bit if instead you add "log" to all of your "pass" rules, you might be able to identify the rule that's passing the undesired packets, e.g: tcpdump -ent -i pflog0 host badguy Craig From nobody Sun Jun 5 08:26:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 983B41BD072C for ; Sun, 5 Jun 2022 08:27:03 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LG8qS12rmz4q9C for ; Sun, 5 Jun 2022 08:26:59 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 79CC65C00B0 for ; Sun, 5 Jun 2022 04:26:59 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Sun, 05 Jun 2022 04:26:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myuji.xyz; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t= 1654417619; x=1654504019; bh=1h3UmYbXKFTcNFQb3AT2oqnoTzH3a1RGggW jYxgYtPc=; b=apZIRIVE8sZuRtkgg4RYEdyxJt5FOzjYPBRa3Sqd86NTRoc4tUs AqxJ0m82kamq2O3gJlljhLB/DDlOHKeV05QAjPVlKeoTkjWYb1Zu9+b69ifHSJ3Q pR0wTN/0bE5Ib3dKsYkELPMb0ERCVfjdESXC1ErFBT3YKRUanrF0cGMnTRI3+Ywc RCcZWs5acjEQs08Rqi4WZ5BiBIQ9qxjjBtqkat5ucDYyAE2HQDMjOrK4lThBZdZB mSjGPh1mR466zQTqgVpaQeTOZ98Db5XL8jeC9bdqvh8wPzeRAjo0SwWG2P62iA9S bW0bk4M/2Jz/CY7tHr0wsheufWOy/kEE8yw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1654417619; x= 1654504019; bh=1h3UmYbXKFTcNFQb3AT2oqnoTzH3a1RGggWjYxgYtPc=; b=i 5xlLjz5kMY0JfGjei6mu+I+YnqcI3aH/rSOL8hQTcLWD276SAsqXyMnx2/4tRtvP tQL8gUqtCr92Cx5Z/Acsadg2XYM5wfBMlCdBs5OiVp0NmS9M0RAjwTazdhH+jn0Z IL+65fZJtK+T33sMzAT2FGwJowXwsDuC0lBUmYcrPeyTMoyOD+/3veonw1AluVqs dfC2NvEJdwjVxgf/WIqszFWyG1R705oa8doNx3TeLTg+/4Cj0SZmdjt9ADzv4ryy PpKa2y2x5nAjlgp4rYZq33BD1kw6YsTV1uiucShBnIRzBXmMp8hYuLslqCH3rXYx laaqnZldKtqOS6Lb4qgJA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddttddgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlfeehmdenucfjughrpefofg ggkfffhffvufgtsegrtderreerreejnecuhfhrohhmpedfofhitghhrggvlhcujggrnhcu mfgrucevhhhiuhdfuceonhihrghnsehmhihujhhirdighiiiqeenucggtffrrghtthgvrh hnpeelieeigfelhedvudeivefhvdfgfeekhffgtdeuhfefuedvuedvgfevfeelieekheen ucffohhmrghinhepghhithhhuhgsrdgtohhmpdhrvggtohhrugdrrhhsnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhihrghnsehmhihujhhi rdighiii X-ME-Proxy: Feedback-ID: i9dd946d0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A3702720072; Sun, 5 Jun 2022 04:26:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: Date: Sun, 05 Jun 2022 16:26:37 +0800 From: "Michael Yan Ka Chiu" To: freebsd-hackers@FreeBSD.org Subject: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Content-Type: multipart/alternative; boundary=85fc6e84595f46b0831dedca9d529307 X-Rspamd-Queue-Id: 4LG8qS12rmz4q9C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=myuji.xyz header.s=fm1 header.b=apZIRIVE; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="i 5xlLjz"; dmarc=none; spf=pass (mx1.freebsd.org: domain of nyan@myuji.xyz designates 66.111.4.27 as permitted sender) smtp.mailfrom=nyan@myuji.xyz X-Spamd-Result: default: False [-3.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[myuji.xyz:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[myuji.xyz:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[nyan]; 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-hackers@freebsd.org]; DMARC_NA(0.00)[myuji.xyz]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N --85fc6e84595f46b0831dedca9d529307 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I=E2=80=99m working on a PR to get the Rust Usdt crate working on FreeBS= D. This crate basically allow adding DTrace probes to rust sources by compiling the pr= obe during macro invocation and embed to a custom section (set_dtrace_probe) using = inline=20 assembly. The problem I am encountering is that the linker will optimize the compi= led probes out in the custom section, the only workaround I have found is to force = the linker to link all the dead code by invoking `-C link-dead-code=3Dyes`. On Illumos= , the workaround is to reference another section such that the Illumos linker will not th= row the probes=20 away; however the same workaround does not work on FreeBSD. I wonder if there're any tricks similar to the Illumos fix, by putting s= ome inline asm there to trick the linker and not throw out the probes. Thanks In advance, Michael References: The PR: https://github.com/oxidecomputer/usdt/pull/63 The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0fe5f03c3= fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 =20 --85fc6e84595f46b0831dedca9d529307 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi everyon= e,

I=E2=80=99m working on a PR to get the R= ust Usdt crate working on FreeBSD. This crate
basically al= low adding DTrace probes to rust sources by compiling the probe during
macro invocation and embed to a custom section (set_dtrace_= probe) using inline
assembly.

The problem I am encountering is that the linker will optimize the com= piled probes
out in the custom section, the only workaroun= d I have found is to force the linker to
link all the dead= code by invoking `-C link-dead-code=3Dyes`. On Illumos, the workaround<= br>
is to reference another section such that the Illumos link= er will not throw the probes
away; however the same worka= round does not work on FreeBSD.

I wonder if= there're any tricks similar to the Illumos fix, by putting some inline = asm there
to trick the linker and not throw out the probes= .

Thanks In advance,
Michael


--85fc6e84595f46b0831dedca9d529307-- From nobody Sun Jun 5 14:51:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9FBE01BEA2C5 for ; Sun, 5 Jun 2022 14:51:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGKMC0L3gz4VKP for ; Sun, 5 Jun 2022 14:51:34 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 255EpLtN076462; Sun, 5 Jun 2022 07:51:27 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 05 Jun 2022 07:51:20 -0700 From: Chris To: George Mitchell Cc: FreeBSD Hackers Subject: Re: Dumb pf.conf question In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <1306cb3a30bbf8a5430f5b548cc5f281@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_ae91059f3bd83f46f824019ba1fd532c" X-Rspamd-Queue-Id: 4LGKMC0L3gz4VKP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_ae91059f3bd83f46f824019ba1fd532c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-06-04 13:05, George Mitchell wrote: > Due to an execss (to put it politely) of packets originating from > IPv4-address-that-shall-not-be-mentioned, I decided to fix up my > pf.conf file, which in very general terms looks like this: > > (a bunch of macro definitions: ext_if = external interface, > int_if = internal interface, internal_ipv6 = 2001:xxxx:yyyy:zzzz::/120, > internal_net = 10.0.0.0/8) > (a couple of table definitions) > (no options, traffic normalization, or queueing) > > scrub in all > nat on $ext_if from $internal_net to any -> ($ext_if) > > (a bunch of rdr statements, none of which contain "quick") > > block all > pass quick on lo0 > pass quick on $int_if > > pass quick from $internal_ipv6 > pass quick to $internal_ipv6 > > #nuisance ssh logins > block quick on $ext_if from (nasty address) > > (lots more packet filtering rules that work) > > But that next-to-last line is not stopping packets from nasty address. > What did I do wrong? Unknown. BUT as (pf) policy goes; block all should get it. Wherein only those FOLLOWING that PASS should get through. I can't see your pf.conf(5) to evaluate it. But if you follow the rules and order as explained in pf.conf(5) && pf(4) my above assertion should hold true. What's your block-policy? Judging by the (overall) order you indicate above. I think your "STATEMENT ORDER" is wrong, leading to your problem. Check man 5 pf.conf, paying close attention to the order of: STATEMENT ORDER HTH Chris --=_ae91059f3bd83f46f824019ba1fd532c Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_ae91059f3bd83f46f824019ba1fd532c-- From nobody Sun Jun 5 19:01:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6BF161BF1FF2 for ; Sun, 5 Jun 2022 19:01:33 +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 4LGQvX59vdz3Jyb for ; Sun, 5 Jun 2022 19:01:28 +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 255J1LuW010326 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 5 Jun 2022 22:01:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 255J1L3Z010325; Sun, 5 Jun 2022 22:01:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Jun 2022 22:01:21 +0300 From: Konstantin Belousov To: Michael Yan Ka Chiu Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4LGQvX59vdz3Jyb X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.84 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:470:d5e7:1::1:server fail]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.88)[-0.876]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrote: > Hi everyone, > > I’m working on a PR to get the Rust Usdt crate working on FreeBSD. This crate > basically allow adding DTrace probes to rust sources by compiling the probe during > macro invocation and embed to a custom section (set_dtrace_probe) using inline > assembly. > > The problem I am encountering is that the linker will optimize the compiled probes > out in the custom section, the only workaround I have found is to force the linker to > link all the dead code by invoking `-C link-dead-code=yes`. On Illumos, the workaround > is to reference another section such that the Illumos linker will not throw the probes > away; however the same workaround does not work on FreeBSD. > > I wonder if there're any tricks similar to the Illumos fix, by putting some inline asm there > to trick the linker and not throw out the probes. > > Thanks In advance, > Michael > > References: > The PR: https://github.com/oxidecomputer/usdt/pull/63 > The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0fe5f03c3fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 > > GNU as seems to gain support for the "R" flag for sections, which should prevent them from linker GC. Not sure if llvm toolchain has this, it requires both as and lld to recognize the flag. Anyway, try it? See GNU as documentation for the .section directive, ELF type flags. From nobody Sun Jun 5 19:42:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3229B1BF7C1B for ; Sun, 5 Jun 2022 19:42:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGRq10KxJz3NK3 for ; Sun, 5 Jun 2022 19:42:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654458148; bh=y26jBWeKE5yPp+M0qovyqLfny16Z7cDlKDRfQyybqPc=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=dhw0T0CxDult/14eOgf3AqpVFkHBQSHyCx4Z9TDQpXxsOZSyE6SJtXJTK8QYCfn6UvcIlnUX3itSZfNL685MNBOyz8X8H3AVyDRouyA0eJ/jv5P4t7YN8tlzidUyasSeI6i9+Y/k8rx5y9XMEbNCZn5BIdlta3QeGXq4eR7rfMXw+1n8+ztSEWxHLgBNHX7PN3XRmTj5TnRrsUSnwfnvte65z+C9Z3UXGaDlrGjn5U/Cy2he5h/SlGxPwggez75ZyyzHPr08j4dVdHGsikvaVfBy6EJRdIKVtdGYy2MZJCrtFWrJmciDsGOUOO8Sg2WnFmSLjhlmZ1Zav+V1LnlKWA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654458148; bh=CCuUfJ5qsIUv2vD6pZCbneM8Tx9dp+R40gFDWIOJeb1=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=WdIRPREWHJ0jzW2jmnXRdSF48M7WseOtWucSSxSiysf2sE4H2aaQctuqaalATsZL48+B1pCfcy/da3y+9+Bq0rF+G0CgEs2uvBSc8xWYXW2D4GBr9p7bDaKCuZkUqBVesvzQ3/AxpUhq6uZwuD8YEkQix1nFCTNky/pihDmIyIvTQxhsU9Y/abZGjc0clQBMwLNuqiRAXaTr/hR8lelBJG+FwAA3IAV0sq6jL/K4PtsreAFwv9UCcGgHjkgQoBHE/ohTnfXBvKULJ65ocCTmKF8f9Qst8AOUVaQOtHc8ipCjOsPyaL8MBg7KT0B2FlEAuixyXRx/PnWKSPKuuJbNiw== X-YMail-OSG: Ddl4KAUVM1nWsZdkULpKAC2fHFxT.EXrxoQil3Sg84e5pSPcVt9kOvjwxlYTgLk vivvxKaM4VCLHbZWKGsrCmf0z7cr72MDhywjHPzUxrfO0mW3YTBQohwjwoaO8RrTAyNhNlnC2CTU 07Q.EE0xzU6HPMSe0dWAPw6MxbjFuB9hO.ew29iKUWCaQKrm8iAlKqWXc5jevfxzIt80UPstTwwx _EpN8oU87VAELtfuAssNmZfOYvR2DFmrfXseInL6g35muYjlWr1SLl7Sj.Qxp2rig5CE4FBzySsy AoVrMNCZNKotejVxSGUxYtlYnLuOmsKmKC7l59yVxaETYVfcgnD4cg2N3MEKfJewHphyMwDlIIq9 ._oCz7enpob03XXd30PQPLvZTFj6QrTjdLLMcs7ksGD6Oxy24tCvmyTjaxfx446ZjqjQYusGL_Gm xlmKduQHqcDtrM_XaZz1RwJUYCmXS747MjPW_YVyug3GQUE_bZVb5qc8lRwqGIp2rtvx0SZBfUDU GzDjVYQpfXmR0bgAwJEgWMm_.wNajAXkez5HjxZGnF0TwC5vpGVt64WGGpp.AdoKGjom7K4OkEx2 jdazEaWxG9lkYJV_x2h9QOZB9pdw2z9nW.5nuUVQPkMqWTbhQgV.UDYW9F77Z5bKoYkTl1C3Fhxa VHhC9yLBrMI.34IWh0V.r4JSkwU0WqN5Up6xCyzASTnix9ac7K01iZ844Cn2BtLsPEaBvt_LaKtf P63T65L1KtgxUMtP5ya_c3DtJ5JzPphJKx8NGpvhNtiNuEiIpFy_3U3UTU3gWqGi7y9HVeCnO8FJ NoaXU1SLZkxuoAsNJR5F1maf209Qd2_EXHQs7prYiUH8JswfngWclw4ubeRD9lt9Wcs34iDWXbxG joFtn0KeyjQ9qybockmUfcUCPApNRuVdwLBmYsm0dOFxQKAOHfJbGJfqGnqEX6dxCARHFyFx4OmL ctUkcAIkKofCa_ds0UzZGTmAX0wqE0GP0I09ql5tT8.Zcm4_K7Dy5ASFKy2gpFi1AyqfkmX_qQ2I bcC8hq7tsyWPVBRTZp8YCu2SHq4Z9c3sYNsPymW1y72iw8nK3rnIrnzmfKUyvQjTPYNoHRKVVdjx EZAkYhuPsC_4idGZz88YFUispm1.Xda0s9OPPogUXo9Egd4Duvw55j1DlMZgVLf_Hk0.jev9IogR VXSIrXqr2K8TueIu0qaMd3ceynOp.7IksgD3fD1O5GqPIKEqdVWBGHMnfEUTDIT4gsvLi3BUObYd pqmT.iUx70GvaNcd_gzpge_FkgBR0A6S81BADKkYHPUMWFq0r9HATFnF7OdLp7eOhZtsfdwj3T3F ObraGHQTUAKqr5jMPof6tjQnBA.uhHkzJIis5_4c3CX7ORcKHysRdLOBfvc9DIzbcMC59DkD8dW8 ZeSse06U_UGeVSoN.LhIJybp8cH7UAVFUfKJgneywpA7fpgi5_.aGkRFwPHjayXjXRFjt5hRJOO6 2Ju8PLiAYkM36HNQxhwpvSt2X.cI5E2huF6o3TsvZpQfGS3Ck20zthvO0xr103bzCd5s8oJW08iL qov3n5B7AeSoz5ThpXx.XqEhnkS3FUS5Q_xNMkZB05V1JEsfFnL9p9ku4CLJj6tlzzLjIRgBXcNh Y3t.se48u9RrrUR0fNGZrv4F71n8OErLZcxyWnUzHJyT27a0HSGXuqqzpQVaIx38hF1NP4dJGl6F E02E_eF4Dj6qjwumC8NKyu3dqBMUIPv66aQmC.eCoD.P.BnYjtJp2Vw7n6ON1k16gwFFQKz0UqeP AqkurjzX1yH4yZVbHH4kZ7GNBuAc0gzXIyKOW6acsI6nsI176bc9dRzco7OZGd5_GQJQ5EoRKDFV ykusUExNA0EueAjlM1mUHckwU6HyAwTq4OQDLjyc48x82Ys.MvyCwdE_RVpiDSHzVZ.ByVBwiTvC ClXamP.Su.lVdgRk35p1ft3yKmNmYkBucsWi5Q39c7rz_2oppAj8W6n9N_y26KNMMJppy6aJNJPL otgYQ8Mk6WQ_oFH20dMdphXCLF6GwG5Puqrfx6XywO9MiVRjUiuGtCYel0m1ZnbJ5.Qr68mJZmzS VAiMBIIW9VsRC304jpXmst5yQyxqbTjtgrkoHNHTbcKXUP423hBAkyrZD.DGYQ9Fx2CfZ9ONz4V9 6Dyd4GP1HC2wspctHIctHWwL8aviQZ5OedxYgN4nngyNBVWTDXf8oO5Z5Fyqj5_PUl4ASZSqR0CF Vxc53oqBkOBTlD2YK.LqcsFolpJcnt_OtNDwLkm2l63xpYl_iTMxv63JmRfDpHmVJu1TH0eOZXw- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Jun 2022 19:42:28 +0000 Received: by hermes--canary-production-ne1-799d7bd497-7lvgk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 84b87229faa40357f4ac8221cea7e301; Sun, 05 Jun 2022 19:42:25 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) Message-Id: Date: Sun, 5 Jun 2022 12:42:23 -0700 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4LGRq10KxJz3NK3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=dhw0T0Cx; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.33 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.84)[-0.845]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.983]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.146:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I have a poudriere bulk -a -c going on a 8 Gibyte aarch64 system. top has been showing an occasionally increasing swap usage but never any sizable decreases. Over 5800 ports have built so far. The context is UFS only. The system is running a non-debug build of main. Part of the context is ( in /etc/sysctl.conf ): vm.swap_enabled=0 vm.swap_idle_enabled=0 Also ( in /usr/local/etc/poudriere.conf ): USE_TMPFS="data" poudriere's TMPFS reports normally total under 128 KiBytes across the 4 builders. For reference, example figures . . . A top variant shows: Swap: 30720Mi Total, 306816Ki Used vmstat -s shows: 78152 swap pager pages paged out Note: (78152*4096)/1024 == 312608Ki So nearly all of the "swap pager pages paged out" pages are still sitting out in the used swap/paging space. Thus, the usage is not held by user processes or is held via very long running processes or is not directly tied to user processes --or some mix. The variant of top reports never having observed more than: 6658Mi MaxObs(Act+Wir+Lndry). ("MaxObs" is short for "Maximum Observed".) Such high usage is for a bounded time, long past at this point. (Until some combination of port builds ends up active that uses such.) So I'm curious: What can I learn about the data that is staying paged out (and is gradually growing)? How can I learn it? Other notes: The poudriere jail being built is: # poudriere jail -jmain-CA7-bulk_a -i Jail name: main-CA7-bulk_a Jail version: 14.0-CURRENT Jail arch: arm.armv7 Jail method: null Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a Jail fs: Jail updated: 2022-05-23 02:21:24 Jail pkgbase: disabled (Just in case the armv7 jail usage or the null method or such is important to the issue.) === Mark Millard marklmi at yahoo.com From nobody Sun Jun 5 19:44:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 380ED1BD0D22 for ; Sun, 5 Jun 2022 19:45:00 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGRsl2MR9z3PCF for ; Sun, 5 Jun 2022 19:44:59 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F02DA5C00C8; Sun, 5 Jun 2022 15:44:53 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Sun, 05 Jun 2022 15:44:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myuji.xyz; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1654458293; x=1654544693; bh=w14mcqoWVz 0y+8nN4xr/UavskqYEQ8FtlnW1cCnaAp8=; b=9LJhfFf91CLi7CFRvEq1fIXMoL kRv2Ny7pkKm7YhDv1Xb/7GKRYsGNb2zicK/EF0+7yySTrAzHIskegV0lw8DgV96f Lkp27PMmW9G3forg5ZioMUxjv/9ZJw7SnzsW5tt4wELlO0XIygC4fscBpLGhfrg7 jR6ypCU2Q3Gsfp8612El5967QocitFlFaJ5iy2YDjJ7tzr5M5fHRETFxVqBDavdx 1JstwPttflkmeoW6mEh0r7xRDY6UCGOJJUVchXAR7urIOUcpU9zQBr0paQoN0OEA +CElXTlbk3gkzc8ne/xWxflzzTiTHVfIaxZf/ESRAAO/oMXA2d7GbeodzAYA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1654458293; x=1654544693; bh=w14mcqoWVz0y+8nN4xr/UavskqYE Q8FtlnW1cCnaAp8=; b=tzbZCuAAYl3SffR16qPtmccDEExp5bHsk/qXBUSF/lp0 zpraJ8y2OAnMLCiisWHMchoGrANVv8Y7nmqcZC+tgk3KqFOHE9Mov0yf7vow3Wg1 Wx+4HDjwgq0wkU5IvlkoseiiQdlfm0mRTLt0/jgYlTJAOEfYq0rer1En7voTX7IN Mccvghgar3KvQ8nFt3AlMQ6AdFQAm1sx3S5ShSQtJ7lWsSrzKl7i08kHuu2lv/3T 91Y/88McFV5HwLC3km6oG15f2pplocav6HYlNOUHDP0kWx+w77XvmCWuSOIZvuwN Eaz9fhJhZdbHTf4acz2iyUOxRlRzW9WsUUr3Rztmvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddttddgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdefhedmnecujfgurhepof gfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedfofhitghhrggvlhcu jggrnhcumfgrucevhhhiuhdfuceonhihrghnsehmhihujhhirdighiiiqeenucggtffrrg htthgvrhhnpedutdektdegtdeujedtlefhhfeitddutdekleeggfeuvddtgffhveffieeu udffjeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhrvggtohhrugdrrhhsnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhihrghnsehm hihujhhirdighiii X-ME-Proxy: Feedback-ID: i9dd946d0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id AB4E52720074; Sun, 5 Jun 2022 15:44:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <51c74c5b-731a-445f-be96-0baf6cd0ebe2@www.fastmail.com> In-Reply-To: References: Date: Mon, 06 Jun 2022 03:44:32 +0800 From: "Michael Yan Ka Chiu" To: "Konstantin Belousov" Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Content-Type: multipart/alternative; boundary=10660d8e775940ae9e59aa67b16a4e69 X-Rspamd-Queue-Id: 4LGRsl2MR9z3PCF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=myuji.xyz header.s=fm1 header.b=9LJhfFf9; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=tzbZCuAA; dmarc=none; spf=pass (mx1.freebsd.org: domain of nyan@myuji.xyz designates 66.111.4.29 as permitted sender) smtp.mailfrom=nyan@myuji.xyz X-Spamd-Result: default: False [-3.57 / 15.00]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[myuji.xyz:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.980]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[myuji.xyz:s=fm1,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[nyan]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[myuji.xyz]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N --10660d8e775940ae9e59aa67b16a4e69 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 6, 2022, at 3:01 AM, Konstantin Belousov wrote: > On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrote: > > Hi everyone, > >=20 > > I=E2=80=99m working on a PR to get the Rust Usdt crate working on Fr= eeBSD. This crate > > basically allow adding DTrace probes to rust sources by compiling th= e probe during > > macro invocation and embed to a custom section (set_dtrace_probe) us= ing inline=20 > > assembly. > >=20 > > The problem I am encountering is that the linker will optimize the c= ompiled probes > > out in the custom section, the only workaround I have found is to fo= rce the linker to > > link all the dead code by invoking `-C link-dead-code=3Dyes`. On Ill= umos, the workaround > > is to reference another section such that the Illumos linker will no= t throw the probes=20 > > away; however the same workaround does not work on FreeBSD. > >=20 > > I wonder if there're any tricks similar to the Illumos fix, by putti= ng some inline asm there > > to trick the linker and not throw out the probes. > >=20 > > Thanks In advance, > > Michael > >=20 > > References: > > The PR: https://github.com/oxidecomputer/usdt/pull/63 > > The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0fe5f= 03c3fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 > >=20 > > =20 >=20 > GNU as seems to gain support for the "R" flag for sections, which shou= ld > prevent them from linker GC. Not sure if llvm toolchain has this, it > requires both as and lld to recognize the flag. >=20 > Anyway, try it? See GNU as documentation for the .section directive, > ELF type flags. Thanks! This seems to solve a big part of the issue. If i pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80=9D and =E2=80=9C= cargo:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D it does prevent = the linker from removing the probes. I am still looking for solutions that does not involve explicit involvem= ent of the flags by the crate consumer, and maybe something not turning = gc off entirely but this is a great progress. --10660d8e775940ae9e59aa67b16a4e69 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 6, = 2022, at 3:01 AM, Konstantin Belousov wrote:
On Sun, Jun 05, 2022 at 04:26:37PM +080= 0, Michael Yan Ka Chiu wrote:
> Hi everyone,
<= div>> 
> I=E2=80=99m working on a PR to get the= Rust Usdt crate working on FreeBSD. This crate
> basic= ally allow adding DTrace probes to rust sources by compiling the probe d= uring
> macro invocation and embed to a custom section = (set_dtrace_probe) using inline 
> assembly.
> 
> The problem I am encountering is = that the linker will optimize the compiled probes
> out= in the custom section, the only workaround I have found is to force the= linker to
> link all the dead code by invoking `-C lin= k-dead-code=3Dyes`. On Illumos, the workaround
> is to = reference another section such that the Illumos linker will not throw th= e probes 
> away; however the same workaround does= not work on FreeBSD.
> 
> I wond= er if there're any tricks similar to the Illumos fix, by putting some in= line asm there
> to trick the linker and not throw out = the probes.
> 
> Thanks In advanc= e,
> Michael
> 
>= ; References:
> 
>  

GNU as seems to gain support for the "R" flag for sect= ions, which should
prevent them from linker GC.  Not = sure if llvm toolchain has this, it
requires both as and l= ld to recognize the flag.

Anyway, try it?&n= bsp; See GNU as documentation for the .section directive,
= ELF type flags.

Thanks! This s= eems to solve a big part of the issue.

If i= pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80=9D and =E2=80=9Ccar= go:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D it does prevent the= linker from removing the probes.

I am stil= l looking for solutions that does not involve explicit involvement of th= e flags by the crate consumer, and maybe something not turning gc off en= tirely but this is a great progress.

--10660d8e775940ae9e59aa67b16a4e69-- From nobody Sun Jun 5 22:04:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9CEB91BE9830 for ; Sun, 5 Jun 2022 22:04:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGVyq2mwbz4WcW for ; Sun, 5 Jun 2022 22:04:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654466668; bh=5M7GVTBRX89tW/6d5rIaxLDlb2Yt4pPmAYemEz+Y03s=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=ChlTWnFw1oy/4U1ArH7i5Uq4ynj3xyYMIxDdL4WwD3crhZIdx9Y8CaVx7TRGO3tmPLvlBKeo6Sfr8uFAK7GM2+O3+KJjTThdI5kihuBG7J2pEXXNyH7a0ruYGKiJo8cWLo2rlz26cthT0xerzTiud7IdnMLjBZ1XSPZVd9wnu0h3M0G3cJ9aZ4PayyoDbqjK8gc802pyMh5XsdNO6FRbXb9a2H+wPvdRZlgGFKqH5IYVNwsOnLSBRYM4Dhc0zAGiiEC+LYWIBnKk8UT8VQcZblSonrQJTuS3tWjjpFi5qlW/gH9QSQGgkhNYKqu4O6JvkxqcRmpNZwbOICENc5w9Cw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654466668; bh=lISBFzY0mQg4zZvkU+rMiT7a4eoZvV875m1UODoZI14=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jAX4ZnO8qk1T5n6bv2I0qvD+GqDMmYGTD7H0OLnM0YZ0TlxAngTEdXOrdVAlzQVvUZmDungKOAdJI9vrUDTt1yvtHwkDvK6M/e+EfdJEeHnEi1wEBW7A2L03JjqQ1h/N9Qt96/SgfPYqonzYQgP1q967l8Hf5EZbyGajf7orQt253MwnnFR8evmoCeq16je+fHTmnPE3Dg+Ux6vBxrN06CJMaRad3pSgyboDmi5FYoFyE1KTnnccc81x7/9cKOjy44jhrpi8qlLxBpRGbfzvqqyoAwL+U2PnIadbsYkQRBXeYWi7pIVWBprkrPxWqM21iJxKUjnSS4FRbeNL90/Ffw== X-YMail-OSG: vNDOuv0VM1lHuLIBi5f30gsvSXu3EHTIexvGKPJHfCQ._iJUu5xpSoR14imjrsE OMYyfLKD3hPjp06MqakVkDQel37dCB2l4.Ziyc7WtEYthQKYB48hytjjKsj2fomMb_ZWjACJ12DC qDJYk1hgd9X7TIIFHaRWtnadKApRJDtnejoD1kCVeTRaQSWH3OJ4l7FemjogbNgdizCqk4LnWrrL x8VSTlh5K2yC3ZUunP9ty3gWHbGV3Oqs6CA8b7pKyfKDTInpyijMimDr_GrXwI07a9WIirIEqPuL Y9gVE2sdG0MZCCeJDwfDNZnKtrc52vTm3CwFeEgwYv7NixLh95ZK5cUcaaIKbWt_6j8OpRZBbHRT PpI5wcCYcq239ue.S1Qw2w.u4r2i41NfuCIRo4ow3RRAQxny9hg3cuZr5AuYpN0AlLK5NS6pq4so CsgBDhHPEPBJze5NfyX14Q3.YSOYAg4.ECJDSaLfTJNs28bUGJPcPSIuqvhn9ayK9j1Yh7slQJA7 FN4EJJCvElNQpPnlEf1v3V.hrZRaaS6wZxInANHYF3spsT7cu5Hw0I8PpXZ4NWNiWOpI4Henasa0 d98RJOTI1_h_LAw4rAKOl8ypBgkWib.jE_3Mryg3WGkwojPDN6uPeQ7hN8swssqGKaPBKC_Sd_lv J3r44MINHo5OZnz0avrFtMFC5V1NNNKaS58wtjg3csR5UntcADlH3uX60nfNentT9vID29MDcgmA poc0ncb9mbVOd1F9t8nHGyEpEinWgfUSNDJCMoKpS9ym._VFI076MPd.thfuGrpc3qEyYdxvMlYZ _GRJ.LtMGrGtf37BjkUt_m0ebfjeOHblKqahhNrzyan1.R.JutduxlQSUTcJx3IePzJNyaBnmKRm HgRnYsZsywjTnfgdXi4gEm3Iu7FCG2tjyzNJFVgV18NOqTVeRKJVsJt.PtbNNN.HH0ncwHwHZWZB ROUh6.Nzr6r_USrG.NJ9zM7Rtz4eW4_u4Z2_xsxOiddUVpUrIsPbKBXHjoz.mma7.Mp2IcbZk6mu E0LQeMgpKG9vq0PunI6GepKiMTupf5k7UGfIsmoNT52cOz0Ivep8YIzQlOoA1nZBiZQ_gn_dpAev 1.9wxWrSqrSuIDzwzlMxtVH56rvKp22xiuT7.5a94nKZTA202cdKZbzYR.a0_gXcmZBQfnKSf1by filE9oQEZxnJXvIBe51..GLUp1QEKWMQ5vYc6f6ioJQhSClVLh7LkpxM0LYoTP4i0Wswaxmxw0ES 1SLlBoLs._K3cLmOKmZIgFfdZggBzugPFlzsESJudW_7pQWB4jEkYx2BINxuicNKlliguLcLMl0O iGjB_yZGwAIcNQPdgrM3RAVAjvk1vB8n0s9yq4RZCVcDEHvSTshQcAs3TP9nscTJB0dFMQZfv.gt 6Jp9wplX9eg8DRyO4M2z.bamNMH5MqYhVSOgVd1AGTBrR4ZuwUPGQWBYgG3m2g4o2KDFf_5iY4l4 jOBLf.wCX31M7bkrp68yET.tDjZrEj9qmI5RGRhiBS7n0_x282UsMxmVXS2Uiky02GhkXXDfXpmL 9826hIYqbewS0rQuGlLIYVvelZsvGJ6HEQZTGJhdAFfe7YGS1jz3I5QdXamT80lbR7iz0WLQR6q. KPArwU.xEvs5ayPhuNqGb_s8sGe_Dmm1zhVXMpMpvVrsCOxswNnVilVdkF.zXLYxvlvj34T044sB y84sfiSYpNn2sNAH69qVdFTe40e0agfcs_U0DHdXIxt9G2iapx.qHqVuHHSm8Q8FK.skb6y3gkxj 4kGx3a0EfWN5CyAPO4p8H33x2eeookoF9STPDqSmVoTDXnjfmtxDbjAAhrP7v6xGsAzx3EHH_3K3 YD9xVlEnzttgZJT_EqANWQDM801wMYcEL7B1Jd1fYXwhudL6Uv7Y4ZRy_q8V1ACq5eIwMKpwgJUa 6jTbE6BXNSffTmMbPmzN7C_QK24HMJFTqxJpvFs0nWXbob.6xH5XZwDWmAWZXBvfZAzfZ_ISEuvH uVkPCE7e82.JHplYZ3r1gjDVyJ1J6QMOlPHqTQt6Dh0CjhCj0zXiWWVNjpryLs1a5gzX_naxo33E 46qqQbUehKc.M8PtYquEpeuAcOL9ItVYO2bZpF0XXpE.XvxCUJkHoLjL2JJ7R8lbYxYf4PUDedq6 JviNUmkbJLJ013EC.nR4HIKudfcfo4VMZnnKl6VTgNUeX7WXGrqVp4Ekq7s_nYEWhjPmTwV54Zkh fg9LVtCyznk6mvIUmCYeDUTjYp5jRuBRVmyhIjDpxbv29yBpSpBM7w9G0TmDpOqhD30D3poC8 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Jun 2022 22:04:28 +0000 Received: by hermes--canary-production-ne1-799d7bd497-7lvgk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 53d7fcdb84f2d78da636cabe054bfa0a; Sun, 05 Jun 2022 22:04:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) Date: Sun, 5 Jun 2022 15:04:22 -0700 References: To: FreeBSD Hackers In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LGVyq2mwbz4WcW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ChlTWnFw; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.53 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.19)[-0.186]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.15)[0.150]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-5, at 12:42, Mark Millard wrote: > I have a poudriere bulk -a -c going on a 8 Gibyte > aarch64 system. top has been showing an occasionally > increasing swap usage but never any sizable decreases. > Over 5800 ports have built so far. The context is UFS > only. The system is running a non-debug build of main. >=20 > Part of the context is ( in /etc/sysctl.conf ): >=20 > vm.swap_enabled=3D0 > vm.swap_idle_enabled=3D0 >=20 > Also ( in /usr/local/etc/poudriere.conf ): >=20 > USE_TMPFS=3D"data" >=20 > poudriere's TMPFS reports normally total under 128 > KiBytes across the 4 builders. >=20 > For reference, example figures . . . >=20 > A top variant shows: >=20 > Swap: 30720Mi Total, 306816Ki Used >=20 > vmstat -s shows: >=20 > 78152 swap pager pages paged out >=20 > Note: (78152*4096)/1024 =3D=3D 312608Ki >=20 > So nearly all of the "swap pager pages paged out" > pages are still sitting out in the used swap/paging > space. Thus, the usage is not held by user processes > or is held via very long running processes or is > not directly tied to user processes --or some mix. >=20 > The variant of top reports never having observed > more than: 6658Mi MaxObs(Act+Wir+Lndry). > ("MaxObs" is short for "Maximum Observed".) > Such high usage is for a bounded time, long past > at this point. (Until some combination of port > builds ends up active that uses such.) >=20 > So I'm curious: >=20 > What can I learn about the data that is staying > paged out (and is gradually growing)? How can I > learn it? >=20 >=20 > Other notes: >=20 > The poudriere jail being built is: >=20 > # poudriere jail -jmain-CA7-bulk_a -i > Jail name: main-CA7-bulk_a > Jail version: 14.0-CURRENT > Jail arch: arm.armv7 > Jail method: null > Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a > Jail fs: =20 > Jail updated: 2022-05-23 02:21:24 > Jail pkgbase: disabled >=20 > (Just in case the armv7 jail usage or the null method > or such is important to the issue.) Hmm. systat -swap reports a toal for the Devices/Paths Used that is somewhat less than the total for what reports for the Pid . . . Total figures (not the Pid Swap figures!): # systat -swap /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 Load Average |||||||| =20 Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| gpt/CA72USBswp14 14G 150M gpt/CA72USBswp16 16G 150M Total 30G 300M Pid Username Command Swap/Total Per-Process Per-System 1453 root nfsd 1M / 15M 9% 0% 1451 root mountd 1M / 15M 7% 0% 1481 root sshd 912K / 20M 4% 0% 1406 root ntpd 740K / 27M 2% 0% 1513 root login 724K / 14M 5% 0% 1514 root sh 656K / 13M 4% 0% 342 _dhcp dhclient 516K / 13M 3% 0% 1363 root rpcbind 448K / 13M 3% 0% 1454 root nfsd 400K / 12M 3% 0% 341 root dhclient 380K / 13M 2% 0% 1341 root syslogd 324K / 12M 2% 0% 1505 root getty 292K / 12M 2% 0% 1510 root getty 292K / 12M 2% 0% 1511 root getty 292K / 12M 2% 0% 1512 root getty 292K / 12M 2% 0% 1509 root getty 292K / 12M 2% 0% 1508 root getty 292K / 12M 2% 0% 1507 root getty 292K / 12M 2% 0% 1506 root getty 288K / 12M 2% 0% 1135 root devd 272K / 11M 2% 0% 338 root dhclient 264K / 13M 2% 0% 1 root init 244K / 11M 2% 0% 1486 root cron 188K / 13M 1% 0% I'm, Still looking for a clear indication of what most of the 300 MiBytes or so of swap/paging space is in use for. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jun 5 22:45:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 81F131BD0CBA for ; Sun, 5 Jun 2022 22:46:11 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGWtk4tQMz4dBZ for ; Sun, 5 Jun 2022 22:46:05 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from smtpclient.apple (234.sub-174-215-219.myvzw.com [174.215.219.234]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 255Mjnm0074326 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 5 Jun 2022 22:45:50 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host 234.sub-174-215-219.myvzw.com [174.215.219.234] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) Date: Sun, 5 Jun 2022 18:45:43 -0400 Message-Id: <27DD20B8-E19B-444B-BAE7-A09CD5390D2F@crossfamilyweb.com> References: Cc: FreeBSD Hackers In-Reply-To: To: Mark Millard X-Mailer: iPhone Mail (19F77) X-Rspamd-Queue-Id: 4LGWtk4tQMz4dBZ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [-2.35 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_XAW(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.55)[-0.552]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[174.215.219.234:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[crossfamilyweb.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[24.97.5.250:server fail,174.215.219.234:server fail]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Jun 5, 2022, at 6:06 PM, Mark Millard wrote: >=20 > =EF=BB=BFOn 2022-Jun-5, at 12:42, Mark Millard wrote: >=20 >> I have a poudriere bulk -a -c going on a 8 Gibyte >> aarch64 system. top has been showing an occasionally >> increasing swap usage but never any sizable decreases. >> Over 5800 ports have built so far. The context is UFS >> only. The system is running a non-debug build of main. >>=20 >> Part of the context is ( in /etc/sysctl.conf ): >>=20 >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >>=20 >> Also ( in /usr/local/etc/poudriere.conf ): >>=20 >> USE_TMPFS=3D"data" >>=20 >> poudriere's TMPFS reports normally total under 128 >> KiBytes across the 4 builders. >>=20 >> For reference, example figures . . . >>=20 >> A top variant shows: >>=20 >> Swap: 30720Mi Total, 306816Ki Used >>=20 >> vmstat -s shows: >>=20 >> 78152 swap pager pages paged out >>=20 >> Note: (78152*4096)/1024 =3D=3D 312608Ki >>=20 >> So nearly all of the "swap pager pages paged out" >> pages are still sitting out in the used swap/paging >> space. Thus, the usage is not held by user processes >> or is held via very long running processes or is >> not directly tied to user processes --or some mix. >>=20 >> The variant of top reports never having observed >> more than: 6658Mi MaxObs(Act+Wir+Lndry). >> ("MaxObs" is short for "Maximum Observed".) >> Such high usage is for a bounded time, long past >> at this point. (Until some combination of port >> builds ends up active that uses such.) >>=20 >> So I'm curious: >>=20 >> What can I learn about the data that is staying >> paged out (and is gradually growing)? How can I >> learn it? >>=20 >>=20 >> Other notes: >>=20 >> The poudriere jail being built is: >>=20 >> # poudriere jail -jmain-CA7-bulk_a -i >> Jail name: main-CA7-bulk_a >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a >> Jail fs: =20 >> Jail updated: 2022-05-23 02:21:24 >> Jail pkgbase: disabled >>=20 >> (Just in case the armv7 jail usage or the null method >> or such is important to the issue.) >=20 > Hmm. systat -swap reports a toal for the Devices/Paths Used > that is somewhat less than the total for what reports for the > Pid . . . Total figures (not the Pid Swap figures!): >=20 > # systat -swap > /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 > Load Average |||||||| =20 >=20 > Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ 90\= 100| > gpt/CA72USBswp14 14G 150M > gpt/CA72USBswp16 16G 150M > Total 30G 300M >=20 > Pid Username Command Swap/Total Per-Process Per-System > 1453 root nfsd 1M / 15M 9% 0% > 1451 root mountd 1M / 15M 7% 0% > 1481 root sshd 912K / 20M 4% 0% > 1406 root ntpd 740K / 27M 2% 0% > 1513 root login 724K / 14M 5% 0% > 1514 root sh 656K / 13M 4% 0% > 342 _dhcp dhclient 516K / 13M 3% 0% > 1363 root rpcbind 448K / 13M 3% 0% > 1454 root nfsd 400K / 12M 3% 0% > 341 root dhclient 380K / 13M 2% 0% > 1341 root syslogd 324K / 12M 2% 0% > 1505 root getty 292K / 12M 2% 0% > 1510 root getty 292K / 12M 2% 0% > 1511 root getty 292K / 12M 2% 0% > 1512 root getty 292K / 12M 2% 0% > 1509 root getty 292K / 12M 2% 0% > 1508 root getty 292K / 12M 2% 0% > 1507 root getty 292K / 12M 2% 0% > 1506 root getty 288K / 12M 2% 0% > 1135 root devd 272K / 11M 2% 0% > 338 root dhclient 264K / 13M 2% 0% > 1 root init 244K / 11M 2% 0% > 1486 root cron 188K / 13M 1% 0% >=20 > I'm, Still looking for a clear indication of what > most of the 300 MiBytes or so of swap/paging space > is in use for. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com My guess is that this is swapped out buffer cache (files).=20= From nobody Sun Jun 5 22:55:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 86A991BD2A38 for ; Sun, 5 Jun 2022 22:55:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGX5c1K4Pz4g1v for ; Sun, 5 Jun 2022 22:55:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654469724; bh=sasb86wspff5FDuGGe72NhziR5vKps1jeCRImm7RdLI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=i+7wnONexTMGDjT3xUrzx4sLrN1G/33Vt050nUOwTgxgYNJWyl24EIvhFTChOLnYughF8iQKtjDcUZ3GLNvuaQHqPDkRTenoMnJRM3Z4Ep5o0wP0FE3DgGy+5SyEhtCpYoPlzId1QL7IXGeFK699pgb2cP/rf8kyUUihOVNLnWhYwFuIYI8Ak7CCQgR0RVSQAgOQ9WDWIv8FNn5pYrEpeZjClnf3K+Q8Sfq2eBn2XF7CBavhI+Xk5HROjr2ek4enQZKO/UkTqJUAhkIOevloqnuG+qmgzZO18D8dfXKbLSTFxf6pMKXtPzc8j6b/qjA4ZYC4vrDfEupEg4ISoNEQrA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654469724; bh=NB6yj4cnya+zzYMiDomCh5TGWnoZU5xNNobQTncpqbR=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iABdtjqyusgMCYmII5EhtTiU8S8oVu7ArkNW/ky0gG9CNzE+FTHogD6XWfljBE731VzS3MSsZ8POo5WAUCMpisdMSxWGBIr4lFNnzjM4UJGMegtefhsxqpgXYnJMpTmjf7Kp/PqK/Ph8pOD8v348vCLMQ4It6El3eQQAAwmDjpbLGPBrhVMlpyeR/IbklZLUMrXhwYFjPwjdQrRiCwKf4kpFq0Ds1226BtLzrU0FecvEuZhn5bIovohWuF2DCUMT5t+2hIan+GqzCswDztojyulp2ZLKog7coII3OVsCqF6olrW+8bdFQj8isywHqTD3756Obqqau19zgPrs34bKNQ== X-YMail-OSG: EUK.e.IVM1kMCpj75EqrNIPCS5VW6j5hlhbkpmkKUnUsPP_mEIT7sjt04xhXkgS jyvYMhnQvoreZ36PYN0z3TZe77kCaWAOx_VDNpQO78cgQ3WQcWWXf9BJymbzSa8JMQLUEhWg1Xx1 m8j6J95zMpPY9QNsPVIKKIkaHIdBWiu_sF0WYiayG5PYSFReDDfE0XALp8im0VipH8zYb5SlZ7t3 pynOZbm3QW1v2UGGozmV4m.jHzsILGADmD2yVxRzhP6bSPP09QRKnSIsZXHJkwhtKkulzJPaUEHP .CVgSQC9W78NvS.IEde_ANIUiz0YEO_Gs.0xDOrTr_FEp7gLunqhRVEHT.v1t.JJLCNOgeqhjN9C oitql1ScsNubwuuwxxcwCwG6l.ImAfKGl7BTlZRs1eZ8aRf0j8ob12yBKwtRQM7zFqvwnwQbqNGx k5pUuZAKHhI6nJxAbpXSoRvc2geUwBJREVTyrPGmCPlb5OU2yHXTPn7kEYyBSFOkuYtilWZV_Phf kZPM9maJDBkDTDMTymiJu9w5iCzzSpxLfnSEjjMPhKeIV.eC1R4xV.zyru8CaXF9iyWTSdhJkkX_ ZHXQhPTJuJZ23t4w9ij.1UGY.0nb_IaoY2FknUnrrf8HKDXj55SKFS8v0ylQMHEA593Mw8m1LBNU CW_V6DFPchViiXlE5QuqubUlbazMH1zjsjRrTXJIWQ7Huu_lJVzVAfBJGkMCdI1FADmc_GumUx_h N.JxAaiCzbsp1.NmJVQZjzxHUapIjF6fQkn.uRhvWtAV_ze7ufGPuAqnjT80CIya5YnOXTEsid7R ysy3JKOTJNBefdJWT4mRe4GuimrzD7_2gIVcIwLss1PoJijOy6DyWPXfFqDFYXxnpCLgaBvqeEwx m8Gd5Kb9hhQN0.LzmXySceU69lEvTTcWf2Jv09zkXuF89Q_kG3E79Yr9R7Eyc0eXTEWMShyvC7NO evAB5l2hitM_nnLNl9676rCL9gbph3pgw_tTxZ.bEkR00LnTZOjuvktU0iJAshppcEZ2jzZRr3d2 _DuDHRZjF60erAAHoroiBFeBaQvqVIpUpYhxsJT9wqjrI5GIRhlxzHo6Qr9Dcqd5HKn6.osmzQBu O0suwHNxKS4tdUFxbYZogQSbNBxVplhBe55br1Li_2720JWWMhRpz7mnUXvNgXGNWL7oiVqbxW6r mDVigFO4bx89y.tejoc8QEVO28UHnwo3K1t3fqMgcgoc9N0ihbFTtRRUvv94u3cogezPL924JOtm iwcovL2rRH_s5usnYTdsDTxD.lXnsuVz.kc9XvMzz3OFwvrPSO9ofYw4s_ynu00whh6DtjPFrFLA of6dJISLBTox0PDxzko93R4mDnrZgKXmtlHaupNPmzxPlZj78xCDW9uGNULKb84b3rsLVp1FHa9d qOahWmX4ucUK8FD.X4wLVB1B1CUht_3kjL7zTqIN0PHkZ1o6Ps72jVGszP4yPBEReSrvkqXhy4rR qZkVZvxPXtgFzy7ZRlfKTSZuRMzqm0HQOv1p5Q_10JIIoID4Oe9a4AHimSIEgDkRynEQPsIa50NG .XpC33IEenmDPCsExtb_.lXw2p9ZTp064KpmWgRbyNKWu4k_b9uH5wD.yKV1CsBdjY1vmlv9cnaG FPijN.TGFe.UoBiIFBteSqlWjI6d8JN1l6RcUwzGZX_zmQrqo1D12KvW_b2H5gsh6cS3UhdZhMMV 5urG0cwc8NTR6XHNjHpkIusMcUQK6rEcMNqq.wnPQjjnUWWeeAf3c7GOUMxlIrTm1mIR0q8rOMbh 7rixccyHRf5B14C1on7YY_yFU1eRLhkgdi5hbtv9.99dv8DyAbsVt5Pz2Eox9UB5tYZy79zptrgY k5_tqS2wuW1_qb6MkUUOhYwDJXrA18tt.B17h9U5BlUDhlLYPzz7SC8DckZ50RFfNNWqK7bzDpal 0pDO2TR7W30_PQiSOPJ4b7M3t9chfoHUP4aoIYW3D0Z5KHMuJF_hee8uOm88EWEkZ_j.F9SR.0px TWXrrGNPazKT6_WCn4rwayYxT_zyKVyPTHU.dwllIO87cnd0eax7AMIkYKyYRYLCY5ytLQX5w0N2 DEjiy9.tuC.ohdmBYwFjB110OdPlgyE4uPZKof8uEb2FDvpG66pu7zxIOwSabk_G8kKr3AbskV2z x7MJDqjmXyyhAfjgdnfE0Zxv8JWy4ZipZbJ_kjG2ym1QUt3Mj_Ejw0aIyfjkqIz5K8UK.jrvme4f xkX6EDh8dSowYalOP2OOiZn_C3LHNpyfSbPBxnC9KK8Biqu7Dhq.kAgaN0wWROvBcZxkluMkYEsV dpCgQ8ZQV4Cuo X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 5 Jun 2022 22:55:24 +0000 Received: by hermes--canary-production-ne1-799d7bd497-d2s2t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5427057928de86ed1763723dbffe0b59; Sun, 05 Jun 2022 22:55:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) From: Mark Millard In-Reply-To: <27DD20B8-E19B-444B-BAE7-A09CD5390D2F@crossfamilyweb.com> Date: Sun, 5 Jun 2022 15:55:21 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <50163894-DCEB-4033-B555-698523E4D100@yahoo.com> References: <27DD20B8-E19B-444B-BAE7-A09CD5390D2F@crossfamilyweb.com> To: David Cross X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LGX5c1K4Pz4g1v X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=i+7wnONe; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-5, at 15:45, David Cross wrote: > On Jun 5, 2022, at 6:06 PM, Mark Millard wrote: >>=20 >> =EF=BB=BFOn 2022-Jun-5, at 12:42, Mark Millard = wrote: >>=20 >>> I have a poudriere bulk -a -c going on a 8 Gibyte >>> aarch64 system. top has been showing an occasionally >>> increasing swap usage but never any sizable decreases. >>> Over 5800 ports have built so far. The context is UFS >>> only. The system is running a non-debug build of main. >>>=20 >>> Part of the context is ( in /etc/sysctl.conf ): >>>=20 >>> vm.swap_enabled=3D0 >>> vm.swap_idle_enabled=3D0 >>>=20 >>> Also ( in /usr/local/etc/poudriere.conf ): >>>=20 >>> USE_TMPFS=3D"data" >>>=20 >>> poudriere's TMPFS reports normally total under 128 >>> KiBytes across the 4 builders. >>>=20 >>> For reference, example figures . . . >>>=20 >>> A top variant shows: >>>=20 >>> Swap: 30720Mi Total, 306816Ki Used >>>=20 >>> vmstat -s shows: >>>=20 >>> 78152 swap pager pages paged out >>>=20 >>> Note: (78152*4096)/1024 =3D=3D 312608Ki >>>=20 >>> So nearly all of the "swap pager pages paged out" >>> pages are still sitting out in the used swap/paging >>> space. Thus, the usage is not held by user processes >>> or is held via very long running processes or is >>> not directly tied to user processes --or some mix. >>>=20 >>> The variant of top reports never having observed >>> more than: 6658Mi MaxObs(Act+Wir+Lndry). >>> ("MaxObs" is short for "Maximum Observed".) >>> Such high usage is for a bounded time, long past >>> at this point. (Until some combination of port >>> builds ends up active that uses such.) >>>=20 >>> So I'm curious: >>>=20 >>> What can I learn about the data that is staying >>> paged out (and is gradually growing)? How can I >>> learn it? >>>=20 >>>=20 >>> Other notes: >>>=20 >>> The poudriere jail being built is: >>>=20 >>> # poudriere jail -jmain-CA7-bulk_a -i >>> Jail name: main-CA7-bulk_a >>> Jail version: 14.0-CURRENT >>> Jail arch: arm.armv7 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a >>> Jail fs: =20 >>> Jail updated: 2022-05-23 02:21:24 >>> Jail pkgbase: disabled >>>=20 >>> (Just in case the armv7 jail usage or the null method >>> or such is important to the issue.) >>=20 >> Hmm. systat -swap reports a toal for the Devices/Paths Used >> that is somewhat less than the total for what reports for the >> Pid . . . Total figures (not the Pid Swap figures!): >>=20 >> # systat -swap >> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 >> Load Average |||||||| =20 >>=20 >> Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| >> gpt/CA72USBswp14 14G 150M >> gpt/CA72USBswp16 16G 150M >> Total 30G 300M >>=20 >> Pid Username Command Swap/Total Per-Process Per-System >> 1453 root nfsd 1M / 15M 9% 0% >> 1451 root mountd 1M / 15M 7% 0% >> 1481 root sshd 912K / 20M 4% 0% >> 1406 root ntpd 740K / 27M 2% 0% >> 1513 root login 724K / 14M 5% 0% >> 1514 root sh 656K / 13M 4% 0% >> 342 _dhcp dhclient 516K / 13M 3% 0% >> 1363 root rpcbind 448K / 13M 3% 0% >> 1454 root nfsd 400K / 12M 3% 0% >> 341 root dhclient 380K / 13M 2% 0% >> 1341 root syslogd 324K / 12M 2% 0% >> 1505 root getty 292K / 12M 2% 0% >> 1510 root getty 292K / 12M 2% 0% >> 1511 root getty 292K / 12M 2% 0% >> 1512 root getty 292K / 12M 2% 0% >> 1509 root getty 292K / 12M 2% 0% >> 1508 root getty 292K / 12M 2% 0% >> 1507 root getty 292K / 12M 2% 0% >> 1506 root getty 288K / 12M 2% 0% >> 1135 root devd 272K / 11M 2% 0% >> 338 root dhclient 264K / 13M 2% 0% >> 1 root init 244K / 11M 2% 0% >> 1486 root cron 188K / 13M 1% 0% >>=20 >> I'm, Still looking for a clear indication of what >> most of the 300 MiBytes or so of swap/paging space >> is in use for. >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >=20 > My guess is that this is swapped out buffer cache (files).=20 >=20 Thanks for the idea. Know how I could find an approximation to the amount of paged out buffer cache to see about how much of the ~300 MiBytes it might explain? Mark =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jun 6 12:49:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B61A1BE9307 for ; Mon, 6 Jun 2022 12:49:40 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGtc36XLjz3NTZ for ; Mon, 6 Jun 2022 12:49:39 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654519779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=paGPQ3+Fb9rGv5zgNzclDqtt6dW5+mFG5PUTOShzUto=; b=RFVmmW7IGxMQ8ZJyFbmnsezpRXmYXBJpK6X48/+KOBbWN4knGX+nHbrDqRxHAq2K2UOnjv u1B0ods/3JHG33JeET3LnlKYTk8/KpXYvetGyOwoFW1niz7bvr9ARIuy+zUbCSt4zsAPo7 bhVhliBN/KIl8p5/9eTJYwYZYWsjMxihtNteWBYZTjlsRpcZpj6iGCEdy1Asj7fKbBcokF S1zmy456aK3ZgR9Z5a2CbeixVYv2fpFXWLFsZ5UlVBm0HxfppCnVtUR0U8aFlm4pt9tYTL aa1I36POPmsGGcgx3Q8sejtrj5L5BsCklLBmC9/5zUQ7Gh3fTBjc1kF79jqxzw== Received: by freefall.freebsd.org (Postfix, from userid 1471) id C9194BAFF; Mon, 6 Jun 2022 12:49:39 +0000 (UTC) Date: Mon, 6 Jun 2022 14:49:37 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) Message-ID: <20220606124937.exjit7znetcx6t6z@geroi.local> References: <27DD20B8-E19B-444B-BAE7-A09CD5390D2F@crossfamilyweb.com> <50163894-DCEB-4033-B555-698523E4D100@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wedjdybktmzss6rh" Content-Disposition: inline In-Reply-To: <50163894-DCEB-4033-B555-698523E4D100@yahoo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654519779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=paGPQ3+Fb9rGv5zgNzclDqtt6dW5+mFG5PUTOShzUto=; b=AhdWOiNtNNYV3gZB21SMzkIf96JjixnpBSDlXBAvH4ZiE0bLNEtDm6k5Hq03g7vQkIe62h sxU7DKAoaU43efpireh9L580W42QjGZ60y7GUhR/G4gjHwnsKca1FAwhCA0xqX2poqYJ51 Krj3D1Zsl/BTLW/RO+GIeD5mg/mDCv6fCOSeMmQRrP4CinF2O5D3lpAeCn35Nno4ZaB/Uq Y1s5bZ4RHZz/T4TAWqSv/Nw2GR4cDYnMvH7mA6QlMzyvSl/JsGs5oJ5Ww4uQRRPstGrTY8 dFdY+K2vZEG1cUyCANh8Q4Q5R8Yb7f5apmYGcmujMUNE0WCMyPwm0f4nifrsZg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654519779; a=rsa-sha256; cv=none; b=HNidQ4PyHKrr2N5jbAk4QTXlLcenMcOK5z/Hk3K72vDu+GvvnMfbyWeiW4bU+MFELi0xH0 7svEKL/dddp9/SkY163Lj9stAvQ0bE2Yl/Cfoxmos8NJovttvl+k48e2q+kXbu6jkexw8y d3RscEE6ps6oK6+L6FtGFXhOlBtDlaYS3qABXb25P1ribZ9nR1Rdj9i/Alrk6/zYYuNVJP OLo+iskkeHA/HE7haIzXpa7xyhVT0io+/OHdOEylfuuC1ndR4rpCLlB321CK95VSxQolN+ 53iE9z7q0syN8qwYrbaIwKwRomHBpsUEqjEakVtUQUT1Ey5LvAbUU9xqE7oINg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --wedjdybktmzss6rh Content-Type: multipart/mixed; boundary="x3jibatkpmiijy2n" Content-Disposition: inline --x3jibatkpmiijy2n Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Sun, Jun 05, 2022 at 03:55:21PM -0700, Mark Millard wrote: >Thanks for the idea. Know how I could find an approximation >to the amount of paged out buffer cache to see about how much >of the ~300 MiBytes it might explain? > >Mark > >=== >Mark Millard >marklmi at yahoo.com > > Hi folks, I believe what you're looking for is: vmstat -o | awk '$7 == "sw" { print $0 }' The definition of the 7th column is escaping me right now; I'm pretty sure I've seen it in a manual page somewhere, but can't for the life of me remember it - so if anyone knows, do tell and I'll figure out a way to get it added to vmstat. ;) If a lot of lines in vmstat -o are blank, it's usually a good idea to have a look at `pstat -f` because it'll either be shared memory objects, sockets, pipes, or things like that. There's also vmstat -m or vmstat -z which can be useful in breaking down types of VM objects by allocator. I've also taken the liberty of including `zones.pl` which has been floating around FreeBSD circles for ages, and which uses the vmstat -z flag mentioned above plus a bit of perl to sum everything up nicely. This is just what I've picked up over the course of sysadmining, I'm by no means a VM expert - as evidenced by the fact that I didn't know about sytat -swap, despite using systat regularly, and wishing it had a `systat -sensors` page which detailed the temperature values that can be found via acpi(4), coretemp(4) and occationally others, as well as fan-speed as reported by acpi_ibm(4) and others of its kind in /boot/kernel/acpi_*. Yours, Daniel Ebdrup Jensen --x3jibatkpmiijy2n Content-Type: text/x-perl; charset=us-ascii Content-Disposition: attachment; filename="zones.pl" #!/usr/bin/env perl open STDIN, "vmstat -z |" or die "Failed to run vmstat program"; open STDOUT, "| sort -n @ARGV -k 2" or die "Failed to pipe through sort"; $fmt="%-30s %8.3f %8.3f %8.3f %6.1f%%\n"; while () { ($n, $s, undef, $u, $c) = split /[:,] */; next unless $s > 0; $n =~ s/ /_/g; $s /= 1024 * 1024; $u *= $s; $c *= $s; $t = $u + $c; next unless $t > 0; printf $fmt, $n, $t, $u, $c, 100 * $c / $t; $cache += $c; $used += $u; $total += $t; } printf $fmt, TOTAL, $total, $used, $cache, 100 * $cached / $total; close STDOUT; --x3jibatkpmiijy2n-- --wedjdybktmzss6rh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmKd9+FfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87py4Af/b+AcDo6iLCpI4y/PvBN3wkH91bxOgNrjhBTsV/cKOe4mY01DwFuYlCwb k+rssETbOLt8dwo6HVMz9Apb5kImCfM1RwWfL0fmhEYX/iaaYu81+JtF0lk45Q9z 0TFD2YGrcCkig6Gs8z5WC7PO0JjmOO8EGVucB7/gZAJV95TamfNZs8+LPsJAazUk rkz/TojFNB/fUMP3InUYe4Xv8n1JBIUq2pcOm09BVTCMOBy8UPmy9FpAWSnueQb7 y7XDWFeiuPqfeK9erverat5lO6ofZLsUEs0dwcrLCiVijbiR3A1xtP6RITRFVr0G bzEmH8HlS3Xv/XHJRZvCDNJ6rtyLmA== =9fK8 -----END PGP SIGNATURE----- --wedjdybktmzss6rh-- From nobody Mon Jun 6 14:52:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B0AE1BDBBDB for ; Mon, 6 Jun 2022 14:53:06 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]) (using TLSv1.3 with cipher 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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LGxLT51BBz3sZF for ; Mon, 6 Jun 2022 14:53:05 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 256Eqq3O027132 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 6 Jun 2022 10:52:57 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Mon, 6 Jun 2022 10:52:52 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: Dumb pf.conf question Content-Language: en-US To: freebsd-hackers@freebsd.org References: <1306cb3a30bbf8a5430f5b548cc5f281@bsdforge.com> From: George Mitchell In-Reply-To: <1306cb3a30bbf8a5430f5b548cc5f281@bsdforge.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4LGxLT51BBz3sZF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 2001:470:1f07:15ff::f7 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_FROM(0.00)[freebsd] X-ThisMailContainsUnwantedMimeParts: N On 6/4/22 17:35, Craig Leres wrote: > [...] On 6/5/22 10:51, Chris wrote: > [...] Thanks to both for your comments. -- George From nobody Mon Jun 6 18:17:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6E0791BE1BF9 for ; Mon, 6 Jun 2022 18:17:31 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LH1tL1qpLz4tvp for ; Mon, 6 Jun 2022 18:17:30 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf31.google.com with SMTP id h18so10732305qvj.11 for ; Mon, 06 Jun 2022 11:17:30 -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=9Ti1L5WFEVnwoHjyrP1/vAvbF14JAmeFGx41XPpHFOQ=; b=CymjQVZ7mekwyvjCpihDj12lL3BFPVjvE9RWvoKyYcl68mcguJ93gPkLwl7i7pMdx6 rEdQK3mPq7dRG/8jBEWv0D7bk0BI5xI5JaSif/HzMHFUG8xvSelq9rGm2nUQ9c+dP36s X0qQ9r8NyfsBFHbennPRZCIiapTSlconplWF2w2nQN6o5kk/xdnfkGudkRHAxBCGNvu8 MjKtIWlWpPCZZuOcxeqRWB03Cse41Cca00kVchDvJ6eaRq1QFB7Y3mlx4ALiq/tioyAW m7MY7Ly1FAJMgfdb8gfAsAUpuNV182CGiF4UFRs5Wakg/C0U52WTL2QpdtTPzO6bRAG7 6TXA== 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=9Ti1L5WFEVnwoHjyrP1/vAvbF14JAmeFGx41XPpHFOQ=; b=aMZZmfmKNA7YcZshcSxZ4qSjase+eluTbBvgnSDfYSuSEd7xM7KyJeQMMbuPHK8E5Y oooHJ4cRSu9THngAPGCe/9RKpqD8rMQFqoOG2ro4fUxxFKLwAl7eduBoSZa3LA4C0FpF rMuWeWd3ax7zXFICOZ6QVNoKOwdxvyiG3Sa1ksfqy0r2TM9HmARpY0l4ouRtDvHn/dzz SwiIWHc9uvv9rPYH9c72lqZ2ix9qUBXPOgVk42DAaAG2+PHTtzUzPtu3apD/Au8S4RAw WcPUQpwMwZ7v+SBwEh9Bk0CgBS5Cb1hTXc62vInJrLvueXvGUDnOErDhRz1IlXiUz56v G8Iw== X-Gm-Message-State: AOAM531JZNQn8gcz5/2IRKz1xqAMZJaLARn6bzTeBwwT9+Qa+30wlpUj s73uGRcMcsEiu5p00GM/eZ0= X-Google-Smtp-Source: ABdhPJy7SP9YcrTJSLdz6fzWw59sFC6MX8ZiJOGUJ+hLGh9LQ3N4hux/3MHzqp7cniYF9jjnbWwOyQ== X-Received: by 2002:ad4:5c4a:0:b0:464:5920:7c1a with SMTP id a10-20020ad45c4a000000b0046459207c1amr29029895qva.58.1654539449785; Mon, 06 Jun 2022 11:17:29 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id y19-20020a05620a44d300b006a6a4b43c01sm7996827qkp.38.2022.06.06.11.17.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 11:17:28 -0700 (PDT) Date: Mon, 6 Jun 2022 14:17:26 -0400 From: Mark Johnston To: Paul Floyd Cc: FreeBSD Hackers Subject: Re: Hang ast / pipelk / piperd Message-ID: References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LH1tL1qpLz4tvp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CymjQVZ7; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f31 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.47 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.23)[0.234]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f31:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 01, 2022 at 11:27:52PM +0200, Paul Floyd wrote: > On 6/1/22 14:16, Mark Johnston wrote: > > The fact that the problem apparently only occurs with 1 CPU suggests a > > scheduler bug, indeed. > > Here is the fresh procstat output I was able to reproduce the problem locally and narrow down the bug somewhat. If you can test a kernel patch, please try this one: https://reviews.freebsd.org/D35415 . I verified that it solves the hang in my test setup, but I didn't go any further than that yet. From nobody Mon Jun 6 18:22:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B94661BE323D for ; Mon, 6 Jun 2022 18:22:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LH2045j8Zz4w8g for ; Mon, 6 Jun 2022 18:22:28 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf36.google.com with SMTP id ca19so3717339qvb.10 for ; Mon, 06 Jun 2022 11:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=0SvY54UVQWo3ZGhA66ipwoS9bP6dtefSbwj7BpB6D2M=; b=gpVPsEhpxd/blqDtt9L6Fo3AL/bSMRYWVnc0LKo97Imw3/HnMD17L/OAdJ9U3bS3NO x3Ml73SQDKSJ50O+CafFYXO32Stfs8jypTRECLCj3OMRCSg8dz6PqfoLdLosf8xj9Xkj 2ERLLt8fFdifr3FPLx067NDxlfRnI0E50+bQgLGnPY7t2v+cyrVvcVEMLZS5eg7SP1YS vbpQFWfo5LiVb8Bbw3+TcSK6d6/b5EYihqAs+YrLC4fsfPzxMIeBxctos9QKNA7b6Ucg C/HvA2kdBBbHJfk8kmrVmK15CywVJlLY66I4vsNT6egDWMXHvSw9cwvfZXMEd9+FVIip U/Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=0SvY54UVQWo3ZGhA66ipwoS9bP6dtefSbwj7BpB6D2M=; b=WK/SkGEU0a4Qo1Vlra3Mgz+bzscs66s6XCskTP7gIyxs68/hpnQcch0Fy7w57Zaqd/ hH3pPK5pIKWXjbV6pvs9piwntmFB0mTa+gcIjhLugqWvhAJhMxVBN0sKEovNaRvheKh/ TzXR5/LxRgGd0mIo//JoRsgyZY9jgy2BJ0ylL15Io8Ideb1diixw70rb4RA0u8qs+QQK gJtqCmyl7LhpvN9qfYRt4uT8UZsUBq1EDF0kEUynecOuUnTBc2Q03ArzZmxyRQsQ6wDB VqvKartYghzzLNk7nVUBELs19MuFes3pEZSqtrKm1HD/IMd478mbvqGLeUvI+VNzS3fx zA4A== X-Gm-Message-State: AOAM5312/RgOpR307MWOly2otUMy1n4kFiW//jvhrbWDs6FWBwIQXaki IOm2joIERv5CxLOVbmaUMns= X-Google-Smtp-Source: ABdhPJw6SS65X0jEoA5WQnJmBYtFYzYIaGGdZeCAnEU4hJYWYt1Kco9rYM3Sk+aKXAhHxkg96GMizw== X-Received: by 2002:a05:6214:1948:b0:464:4c88:dafa with SMTP id q8-20020a056214194800b004644c88dafamr32998569qvk.12.1654539748143; Mon, 06 Jun 2022 11:22:28 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id f15-20020ac86ecf000000b00304edcfa109sm2033207qtv.33.2022.06.06.11.22.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 11:22:27 -0700 (PDT) Date: Mon, 6 Jun 2022 14:22:25 -0400 From: Mark Johnston To: Jan Mikkelsen Cc: Paul Floyd , FreeBSD Hackers Subject: Re: Hang ast / pipelk / piperd Message-ID: References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> <6DBE2C6F-7F8B-457A-AB10-1912965C3376@transactionware.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6DBE2C6F-7F8B-457A-AB10-1912965C3376@transactionware.com> X-Rspamd-Queue-Id: 4LH2045j8Zz4w8g X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=gpVPsEhp; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.12)[-0.122]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f36:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 02, 2022 at 12:49:45PM +0200, Jan Mikkelsen wrote: > All these mi_switch+0xc2 hangs reminded me of something I saw once on 13.1-RC2 back in April. The machine was running five concurrent “make -j32 installword” processes. > > The machine hung, disk activity stopped. Results of ^T on various running commands: > > ^T on a “tail -F” command: > > load: 1.93 cmd: tail 27541 [zfs teardown inactive] 393.65r 0.06u 0.10s 0% 2548k > mi_switch+0xc2 _sleep+0x1fc rms_rlock_fallback+0x90 zfs_freebsd_reclaim+0x26 VOP_RECLAIM_APV+0x1f vgonel+0x342 vnlru_free_impl+0x2f7 vn_alloc_hard+0xc8 getnewvnode_reserve+0x93 zfs_zget+0x22 zfs_dirent_lookup+0x16b zfs_dirlook+0x7a zfs_lookup+0x3d0 zfs_cache_lookup+0xa9 VOP_LOOKUP+0x30 cache_fplookup_noentry+0x1a3 cache_fplookup+0x366 namei+0x12a > > ^T on a zsh doing a cd to a UFS directory: > > load: 0.48 cmd: zsh 86937 [zfs teardown inactive] 84663.01r 0.06u 0.01s 0% 6412k > mi_switch+0xc2 _sleep+0x1fc rms_rlock_fallback+0x90 zfs_freebsd_reclaim+0x26 VOP_RECLAIM_APV+0x1f vgonel+0x342 vnlru_free_impl+0x2f7 vn_alloc_hard+0xc8 getnewvnode_reserve+0x93 zfs_zget+0x22 zfs_dirent_lookup+0x16b zfs_dirlook+0x7a zfs_lookup+0x3d0 zfs_cache_lookup+0xa9 lookup+0x45c namei+0x259 kern_statat+0xf3 sys_fstatat+0x2f This looks very similar to the problem described here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261448 Though, in my case I did not see any deadlocks. In other words, the hang always ended after some time (typically a few seconds). > ^T on an attempt to start gstat > > load: 0.17 cmd: gstat 63307 [ufs] 298.29r 0.00u 0.00s 0% 228k > mi_switch+0xc2 sleeplk+0xf6 lockmgr_slock_hard+0x3e7 ffs_lock+0x6c _vn_lock+0x48 vget_finish+0x21 cache_lookup+0x26c vfs_cache_lookup+0x7b lookup+0x45c namei+0x259 vn_open_cred+0x533 kern_openat+0x283 amd64_syscall+0x10c fast_syscall_common+0xf8 > > A short press of the system power button did nothing. > > The installworld target directories were on a ZFS filesystem with a single mirror of two SATA SSDs. > > Unsure if it’s related because the rest of the stack traces are different. However, the mi_switch+0xc2 triggered a memory. mi_switch() is main entry point into the CPU scheduler, so pretty much any thread which isn't on a CPU will have mi_switch() appear in its backtrace. From nobody Mon Jun 6 19:40:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 006A41BD03F0 for ; Mon, 6 Jun 2022 19:40:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LH3jn0YlWz54QS for ; Mon, 6 Jun 2022 19:40:12 +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 256Je6NN075538 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 6 Jun 2022 22:40:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 256Je5Xk075510; Mon, 6 Jun 2022 22:40:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 6 Jun 2022 22:40:05 +0300 From: Konstantin Belousov To: Michael Yan Ka Chiu Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Message-ID: References: <51c74c5b-731a-445f-be96-0baf6cd0ebe2@www.fastmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51c74c5b-731a-445f-be96-0baf6cd0ebe2@www.fastmail.com> 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: 4LH3jn0YlWz54QS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [0.36 / 15.00]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_MEDIUM(0.81)[0.813]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.54)[0.544]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 06, 2022 at 03:44:32AM +0800, Michael Yan Ka Chiu wrote: > On Mon, Jun 6, 2022, at 3:01 AM, Konstantin Belousov wrote: > > On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrote: > > > Hi everyone, > > > > > > I’m working on a PR to get the Rust Usdt crate working on FreeBSD. This crate > > > basically allow adding DTrace probes to rust sources by compiling the probe during > > > macro invocation and embed to a custom section (set_dtrace_probe) using inline > > > assembly. > > > > > > The problem I am encountering is that the linker will optimize the compiled probes > > > out in the custom section, the only workaround I have found is to force the linker to > > > link all the dead code by invoking `-C link-dead-code=yes`. On Illumos, the workaround > > > is to reference another section such that the Illumos linker will not throw the probes > > > away; however the same workaround does not work on FreeBSD. > > > > > > I wonder if there're any tricks similar to the Illumos fix, by putting some inline asm there > > > to trick the linker and not throw out the probes. > > > > > > Thanks In advance, > > > Michael > > > > > > References: > > > The PR: https://github.com/oxidecomputer/usdt/pull/63 > > > The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0fe5f03c3fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 > > > > > > > > > > GNU as seems to gain support for the "R" flag for sections, which should > > prevent them from linker GC. Not sure if llvm toolchain has this, it > > requires both as and lld to recognize the flag. > > > > Anyway, try it? See GNU as documentation for the .section directive, > > ELF type flags. > > Thanks! This seems to solve a big part of the issue. > > If i pass “cargo:rustc-link-arg=-Xlinker” and “cargo:rustc-link-arg=—no-gc-sections” it does prevent the linker from removing the probes. > > I am still looking for solutions that does not involve explicit involvement of the flags by the crate consumer, and maybe something not turning gc off entirely but this is a great progress. Did you tried the "R" section flag, as I noted above? From nobody Tue Jun 7 00:52:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C772E1BE4513 for ; Tue, 7 Jun 2022 00:53:23 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LHBg40xzyz4gn5 for ; Tue, 7 Jun 2022 00:53:19 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9E2EE5C0174; Mon, 6 Jun 2022 20:53:13 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Mon, 06 Jun 2022 20:53:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myuji.xyz; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1654563193; x=1654649593; bh=IZnhLyOZuP m/AZth2QTYlblLeQgW86ivAyCSxZYY9K8=; b=IkIqgx10n7YQm30fzq1uVZVe5C PAUcRqVUR7mBSGzrnoM+8gqIFkdutT0EXRqOOdK2Js8uxZw7SMXMzrd+BhT6V73j XeJfOxCf5JwlczC6k8B9YtMbp+WjVAhMoc/4176cJYO2A/IKigtL4RNn8ZPGVUWb /AXMhzvofG/wXLR9C2s7O6iiMSYHQyEIiN8H0mSH7CzFbbJqe7NyWSNVRA1EHIbD BUtLlFD5+tpYKXqSYdGOg5YkB1eQFLlzwJlWBcosprp6ekkcBWjZvtsuFJ7SJZav dOmZUNmCqJRcZH3DXxRNMG1eEaai6DbrY9vNCgwI4AkJliUOYw5qZbb5bvSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1654563193; x=1654649593; bh=IZnhLyOZuPm/AZth2QTYlblLeQgW 86ivAyCSxZYY9K8=; b=SISlPVfB+lxJbk6XXA+QfaN+HF5YmbNVqwVHRHYnk216 8WUAX1DRjUd/Inc5reCxCKI1B5rWuXKlyFnpCTDOgMoiEV0hQURntLD0MkHdkaz7 rgpEeWwC2qKiE42FeFZ3S74EIuJFAF8TcVTtjBSZVOl3LBRBxpsq8WMbzK8NBx5m DW5iRUjcaOeHA7s9Du1GpW9ubuNUO5nwRRPL90oeyNiAFW8GXHV1Hp0vYr2fgnoF B3MQoJDOHtCk2seZOxZF+XJHjiXRh5c32d89SJ6lGG+yvdM/uQXHM+UVBXjyIoE9 HnYBk0QQc+iLfeB6LtdCqY/Nk0khWJG1MOyNNjnBPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddtgedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlfeehmdenucfjughrpefofg ggkfgjfhffhffvvefutgesrgdtreerreerjeenucfhrhhomhepfdfoihgthhgrvghlucgj rghnucfmrgcuvehhihhufdcuoehnhigrnhesmhihuhhjihdrgiihiieqnecuggftrfgrth htvghrnhepuddtkedtgedtueejtdelhffhiedtuddtkeelgefguedvtdfghfevffeiuedu ffejnecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhgvtghorhgurdhrshenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnhigrnhesmhih uhhjihdrgiihii X-ME-Proxy: Feedback-ID: i9dd946d0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5058C2720072; Mon, 6 Jun 2022 20:53:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-592-g7095c13f5a-fm-20220603.004-g7095c13f List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <717e9669-425a-4aae-9178-99d031d606f2@www.fastmail.com> In-Reply-To: References: <51c74c5b-731a-445f-be96-0baf6cd0ebe2@www.fastmail.com> Date: Tue, 07 Jun 2022 08:52:40 +0800 From: "Michael Yan Ka Chiu" To: "Konstantin Belousov" Cc: freebsd-hackers@freebsd.org Subject: Re: Help needed to get Rust dtrace USDT working on/with FreeBSD linker Content-Type: multipart/alternative; boundary=852b2e739d824269a0a618ba8ae1a5db X-Rspamd-Queue-Id: 4LHBg40xzyz4gn5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=myuji.xyz header.s=fm2 header.b=IkIqgx10; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=SISlPVfB; dmarc=none; spf=pass (mx1.freebsd.org: domain of nyan@myuji.xyz designates 66.111.4.26 as permitted sender) smtp.mailfrom=nyan@myuji.xyz X-Spamd-Result: default: False [-3.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; RWL_MAILSPIKE_GOOD(0.00)[66.111.4.26:from]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[myuji.xyz:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[myuji.xyz:s=fm2,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[nyan]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[myuji.xyz]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N --852b2e739d824269a0a618ba8ae1a5db Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 7, 2022, at 3:40 AM, Konstantin Belousov wrote: > On Mon, Jun 06, 2022 at 03:44:32AM +0800, Michael Yan Ka Chiu wrote: > > On Mon, Jun 6, 2022, at 3:01 AM, Konstantin Belousov wrote: > > > On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrot= e: > > > > Hi everyone, > > > >=20 > > > > I=E2=80=99m working on a PR to get the Rust Usdt crate working o= n FreeBSD. This crate > > > > basically allow adding DTrace probes to rust sources by compilin= g the probe during > > > > macro invocation and embed to a custom section (set_dtrace_probe= ) using inline=20 > > > > assembly. > > > >=20 > > > > The problem I am encountering is that the linker will optimize t= he compiled probes > > > > out in the custom section, the only workaround I have found is t= o force the linker to > > > > link all the dead code by invoking `-C link-dead-code=3Dyes`. On= Illumos, the workaround > > > > is to reference another section such that the Illumos linker wil= l not throw the probes=20 > > > > away; however the same workaround does not work on FreeBSD. > > > >=20 > > > > I wonder if there're any tricks similar to the Illumos fix, by p= utting some inline asm there > > > > to trick the linker and not throw out the probes. > > > >=20 > > > > Thanks In advance, > > > > Michael > > > >=20 > > > > References: > > > > The PR: https://github.com/oxidecomputer/usdt/pull/63 > > > > The illumos fix: https://github.com/oxidecomputer/usdt/blob/eac0= fe5f03c3fbf23468ead5cb140f62d51ac3f3/usdt-impl/src/record.rs#L251 > > > >=20 > > > > =20 > > >=20 > > > GNU as seems to gain support for the "R" flag for sections, which = should > > > prevent them from linker GC. Not sure if llvm toolchain has this,= it > > > requires both as and lld to recognize the flag. > > >=20 > > > Anyway, try it? See GNU as documentation for the .section directi= ve, > > > ELF type flags. > >=20 > > Thanks! This seems to solve a big part of the issue. > >=20 > > If i pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80=9D and =E2=80= =9Ccargo:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D it does preve= nt the linker from removing the probes. > >=20 > > I am still looking for solutions that does not involve explicit invo= lvement of the flags by the crate consumer, and maybe something not turn= ing gc off entirely but this is a great progress. >=20 > Did you tried the "R" section flag, as I noted above? Yes sir, I am using the =E2=80=9CR=E2=80=9D flag and it works amazingly = well. Sorry I misread your email the first time. --852b2e739d824269a0a618ba8ae1a5db Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jun 7, 2022, at 3:40 AM, Konstantin Belousov wrote:
On Mon, Jun 06, 2022 at= 03:44:32AM +0800, Michael Yan Ka Chiu wrote:
> On Mon,= Jun 6, 2022, at 3:01 AM, Konstantin Belousov wrote:
> = > On Sun, Jun 05, 2022 at 04:26:37PM +0800, Michael Yan Ka Chiu wrote= :
> > > Hi everyone,
> > >=  
> > > I=E2=80=99m working on a PR to get t= he Rust Usdt crate working on FreeBSD. This crate
> >= ; > basically allow adding DTrace probes to rust sources by compiling= the probe during
> > > macro invocation and embe= d to a custom section (set_dtrace_probe) using inline 
> > > assembly.
> > > 
<= div>> > > The problem I am encountering is that the linker will= optimize the compiled probes
> > > out in the cu= stom section, the only workaround I have found is to force the linker to=
> > > link all the dead code by invoking `-C lin= k-dead-code=3Dyes`. On Illumos, the workaround
> > &= gt; is to reference another section such that the Illumos linker will no= t throw the probes 
> > > away; however the = same workaround does not work on FreeBSD.
> > >&n= bsp;
> > > I wonder if there're any tricks simila= r to the Illumos fix, by putting some inline asm there
>= ; > > to trick the linker and not throw out the probes.
<= div>> > > 
> > > Thanks In advance,=
> > > Michael
> > > =
> > > References:
> = > > 
> > >  
&= gt; > 
> > GNU as seems to gain support for = the "R" flag for sections, which should
> > prevent = them from linker GC.  Not sure if llvm toolchain has this, it
> > requires both as and lld to recognize the flag.
> > 
> > Anyway, try it?  S= ee GNU as documentation for the .section directive,
> &= gt; ELF type flags.
> 
> Thanks! = This seems to solve a big part of the issue.
> 
> If i pass =E2=80=9Ccargo:rustc-link-arg=3D-Xlinker=E2=80= =9D and =E2=80=9Ccargo:rustc-link-arg=3D=E2=80=94no-gc-sections=E2=80=9D= it does prevent the linker from removing the probes.
>=  
> I am still looking for solutions that does not= involve explicit involvement of the flags by the crate consumer, and ma= ybe something not turning gc off entirely but this is a great progress.<= br>

Did you tried the "R" section flag, as I no= ted above?

Yes sir, I am using= the =E2=80=9CR=E2=80=9D flag and it works amazingly well. Sorry I misre= ad your email the first time.
--852b2e739d824269a0a618ba8ae1a5db-- From nobody Tue Jun 7 05:05:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 669CB1BE90E7 for ; Tue, 7 Jun 2022 05:05:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LHJFs2Sf0z3Mqp for ; Tue, 7 Jun 2022 05:05:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654578313; bh=HAX21P2l0l5xL3BYi0xi/eDB5m2w1CIsHAhqA9GjNoI=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=Pmhzcuxz7tJNc4b7XmbyWy3JmNxNJF83AYy4Ztnli/MGYiX4nhxmgjewmj5sbZIOJqCWMflSUk81nPqhpwXXv3LFva1hB2A88DcYugZu5wvG3EECgAes+DTUD6el4TfY4TXgH4SFrrxS8gfrEcY0+8/wPn7m3mVeLVNjNjC7EWg8qrdiGLWMBW0exVxbY980UgoZcjggfCSeTotyBZb17BFuOBpdYwpWh6JlMubxyZO9X2Nj3YnsS8on6Nw2r3arG3f68iyAm+5SFKEAUBNBV8qZTtIgdA0yOlUtuzmBYYlLMQCexxIkhDjY0YsylW36xWMj/dC6KNTa9P6nPGiafA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654578313; bh=qqKnvw7Asl4CL7WE1B7mEN1gOgF59T9OnUbr8gqwsWM=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TT05PXatgrEPZI3fj2eHsBCLFeYNZ04RzXT7y6jK5Y7/fAwNp3wDUcVKLZQjZEllNQ+lJyXcqkOULnTx134Bsjr47DK5zAm4dsk4N+E1MG2S6xeYQ2JvucKJ8+HImJDFMZYDW+aiXQXPPJPitjhbC8Or7VroSnDfsgj+HSt1lJ7rYaAZe4SecJWT35Ms1X+lhiZOVnyZUeoBiwIEdRyQXh4PmfutuZKR3IvIZGAbLCa9WGfXauvWKpvATEDXPvubMnZTrLwKBuSxD1YVLR1aPyAE0ibSbhQfHTlDWsQjdjhdha05s8JGU/HPbcuv/SewD6KIgenapgHQd6BEsYHOFg== X-YMail-OSG: 6BMaunsVM1lZ_LjDcHW51bwHpQCHzmAYnjy.paLQZOQ0KPB.DIv88lvWMzmRXLg yc35Y0JaCEZY4llnKhMYB1nZa25g0lCISSNuDQa0dugC2DYkiBHxRpFzrkQW6sfuNOEQn6Jh54Nv 1.0JyMpUMYVlTPHubkqQ7T8KaKmpFdoU1GY7FRdfSsFPZsknTzGyfkw3gTXcl_Nc5wflLi.qfNaD GX4zefzG2dFzzFlup41f2mz4m0BNrmmid65ZcLNLzjfSJZy1ZDy2Ro.SPQZC_8.vJgUGULyOehe2 X4MzeqQupG2J4pkoqTSqXZ.d.fHEt1fIrKAUIq.f53czCpd8YdKc.heBhOQcYsFG9Y7iCdOlk17B E1wfo4id95ztc23x_H22xhVoQXbo8tzvsy8k_fZHiU2qLWtiAGOGhW2AJHsuojxMTH_f8QWZAA8N K6oRKsXoYPQuKmNuMz4mcFUmfFCLy8079.lvWjnhUh5y_Etpq1LJJyWUgOEUojS9CH2P4frUfKB7 sNgEOF8OuK4YlC.jpb_jE8LAbm4ECe7PNOx7RWVDnxKASHZKaP9o8uqSijhmznqjFiJOjq6DqF1o Z606zJeGnkYXVS3kBZlJiWwWCXZFZxy6YFcFpkJRzYq1NxI7aAxPkmfffSg5.IaJGvZaxPnMIEve afi4ESEXladkhqu8lUDzJOupMZkYk_vxrEKG5EREHn_lv8eXTIlsMDskGEQ04XGkFy6bJVsdBruL Kl_FNqzJ1BqOCRCnZF.AxrjoufcCf_MRHvlyG1QgzH30Elom6j1b9Gaa5.UQGkcHpfKfeAekAngW 4kqHz0b6NDma59CR2znIaz1T6ESNhwFvWvq9YuByvh.9gt2ToZEAC3Sy1fRCcdeGMCue_NXeJG0w TosZPt8CsmI2qApFBAWkmIG3ZTe26K..7yVb1w7x1oAb3EUltJ.xCGyzr6GDxWVVUlZSp65Zl16x 2KBBTz24YgiYhc_knsSggvlvg88glSZGgUaosYZ_zn_e8Z8asi4fGcAV.DlqEkElIDKl7k7YheSh x.i5QlEosq5dF7Sub92i2XqrsMCQAN6sNSk9glVjPmASqFVXb4uF.emvkYP566MlIV06MO8JilS4 RTZeXe7vgwz86TP.jPDDT6jkMqdT6EwG2seNNbQ7UdBRDk8UH4pxduw6wn3mumaDOr18lXdY4Uwm xtT8pCQk0XaOSMJz5O6jr3ATUDlPdrwJKTQottodlhxgwmB937f7n4RLj9KALLsD2OmRRL4MZ4G3 6WCWPRKOYojCsVKi7SkoP_PxOwqsbuFeDgyGDJ2JLHdk4Ow8WROT24C80liSlxMPumodHb6hPk5f tOsnJptZvRrBA5XzZ.Ee7m4ttzlSzQRvf2A8el8vrB7kv.q8Sy4mtpc3PmeZfnZoaEuWBpyIHfXt DuWaIdOBQb_2_PQ_gCSq81gcgsPM_F1.aZ_zQRpwfbYz8piI0PZWUOM3saQgK5U96BywQ_sxd5fZ F2n1NNRIytGvPfaIGYnb49nh_1Ranklwk8ePQGN73dnhw3U9wmxmKWgxxjkqSWMQKt9ri_G22KKi hzomtccmJEYF3h1Zxg1xxwX.BpA3ujSDzvLynKzjHoO4E6xwOYKjiSh9_78ZKhuNELwKeDwX04n9 nQq82im0d2xWpWDMb1CgK4wjWLBTikDmBolTyVbufIVmtJxe4X9gh7ZR8KR1dZwLjx1TAgszg6lU PRHJzAjz7UEUpaCuTR5NvxpaONl6QzElBy6LxefV_URI5yyMmkXDKmJq3pt48hgVOBbewK35rxGj jRhhnguKluVFrk8_PORZQjUm1O45LF5vck2cEFaTOkDGaH5CgJXUs7XKuH81gYNFui5mq_E0Uc7U rHPjeZFNcIAdo3oM5R5MUpYNhGQHtRn8UUU6wdDElDOYCikjTaqpHGm1l1ea4T7peHXljns2IHHU BhOaPEOzXjt7OIVaElhYBZJm5JusgyxsRK9aU.K_aTmXrZm8hwixXqRKwKmByEY9vUwFj.YQ44fQ NatiDxs_w6826svug8I3Ot6bLrU4WwPs7pDnUXhuCVOhOET8MPPu4dJ_T5dsjCOtWz6xMgDrwJg8 r7wai3M2c9TT2kStutF6PlHVnI1d41Quzzr8a7RBT.0DSlVp55NNOpGadMDD6Ri89RNhBM9wFmpB 7GAf7r97uQf9XTSLfUmyvWNrk5lwnQuqKqQZT9eO1B9pIjq1c5wyHppMuxSmOM_2981WbXzCFRgc hGnqcz_7mTLAQvi_.ezMVTyVpGh4CxWQuKMOZlQJ0ACrOEQTwmqynkNiKbMK1Gqgm3U8hHMsJ16E axfEK.s.wib1i X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Tue, 7 Jun 2022 05:05:13 +0000 Received: by hermes--canary-production-ne1-799d7bd497-2pzdr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e813f1e4d71cb56de8e0377b54d6777c; Tue, 07 Jun 2022 05:05:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) Message-Id: <46C25461-FFC0-406D-A2AB-9269E3948751@yahoo.com> Date: Mon, 6 Jun 2022 22:05:08 -0700 To: Daniel Ebdrup Jensen , FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <46C25461-FFC0-406D-A2AB-9269E3948751.ref@yahoo.com> X-Rspamd-Queue-Id: 4LHJFs2Sf0z3Mqp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=Pmhzcuxz; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Daniel Ebdrup Jensen wrote on Date: Mon, 06 Jun 2022 12:49:37 UTC : > On Sun, Jun 05, 2022 at 03:55:21PM -0700, Mark Millard wrote: > >Thanks for the idea. Know how I could find an approximation > >to the amount of paged out buffer cache to see about how much > >of the ~300 MiBytes it might explain? > > > . . . >=20 > I believe what you're looking for is: > vmstat -o | awk '$7 =3D=3D "sw" { print $0 }' >=20 > The definition of the 7th column is escaping me right now; I'm > pretty sure I've seen it in a manual page somewhere, but can't = for > the life of me remember it - so if anyone knows, do tell and = I'll > figure out a way to get it added to vmstat. ;) >=20 > If a lot of lines in vmstat -o are blank, it's usually a good = idea > to have a look at `pstat -f` because it'll either be shared = memory > objects, sockets, pipes, or things like that. >=20 > There's also vmstat -m or vmstat -z which can be useful in = breaking > down types of VM objects by allocator. >=20 > I've also taken the liberty of including `zones.pl` which has = been > floating around FreeBSD circles for ages, and which uses the = vmstat > -z flag mentioned above plus a bit of perl to sum everything up > nicely. >=20 > This is just what I've picked up over the course of sysadmining, > I'm by no means a VM expert - as evidenced by the fact that I > didn't know about sytat -swap, despite using systat regularly, = and > wishing it had a `systat -sensors` page which detailed the > temperature values that can be found via acpi(4), coretemp(4) = and > occationally others, as well as fan-speed as reported by > acpi_ibm(4) and others of its kind in /boot/kernel/acpi_*. >=20 Thanks. It was an interesting exploration. # vmstat -o | more RES ACT INACT REF SHD CM TP PATH 1 0 1 0 0 WB vn = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/01/usr/local/share/do= c/gettext/examples/hello-objc-gnustep/po/ro.po 33 4 29 29 17 WB vn /lib/libtinfow.so.9 0 0 0 1 0 WB sw=20 . . . "TP" is probably TyPe and "sw" is probably for swap-backed. ("vn" for vnode-backed.) RES, ACT, INACT, REF, and SHD seem to give no clue about how much is paged out into swap space, just what is in RAM. Nor does there seem to be any specific information about the content, even when at least one of the size figures is non-zero. I do not see how to identify tmpfs material vs. non-tmpfs material in the output, for example. # pstat -f | more 460/256959 open files LOC TYPE FLG CNT MSG DATA OFFSET ffffa0009e78f550 pipe RW 1 0 ffffa00076cbc2e8 0 ffffa000136bf910 inode RW 13 0 ffffa001c24f7400 8c4a4d . . . ffffa0009e78f910 fifo RW 30 0 ffffa000080845d0 0 . . . This seems to not have information about swap-backed. But even if it did, I've not identified how I could put the output to use. I expect that the inode ones are vnode-backed instead of swap backed. (Although, tmpfs might be an odd fit for that claim. But I do not see how to identify tmpfs material vs. non-tmpfs material in the output.) # vmstat -m | more Type InUse MemUse Requests Size(s) CAM I/O Scheduler 1 1K 1 128 evdev 2 2K 2 1024 . . . I do not see any way to identify any mounts paged out to swap space here. There is some material about tmpfs overhead: tmpfs mount 6 1K 8 128 tmpfs name 122014 5917K 989436 16,32,64,128 tmpfs dir 122020 7627K 989458 64 but I've not identified anything for the space in tmpfs file systems. # vmstat -z | more ITEM SIZE LIMIT USED FREE REQ = FAILSLEEP XDOMAIN kstack_cache: 16384, 0, 590, 12, 820664, 0, = 0, 0 buf free cache: 432, 0, 42016, 5737,431716208, 0, = 0, 0 vm pgcache: 4096, 0, 1704016, 176,10384187744, 944, = 0, 0 vm pgcache: 4096, 0, 157200, 346,851328618, 286, = 0, 0 . . . I do not see any way to identify any mounts paged out to swap space here. (The two lines with the same name "vm pgcache" is an interesting oddity/ambiguity.) # ~/zones.pl KMAP_ENTRY 0.004 0.000 0.003 92.5% . . . TMPFS_node 85.698 26.124 59.574 69.5% VNODE 88.432 48.078 40.354 45.6% VM_OBJECT 165.794 50.435 115.360 69.6% vm_pgcache 626.609 624.301 2.309 0.4% vm_pgcache 5608.180 5606.609 1.570 0.0% TOTAL 6858.561 6511.032 347.529 0.0% This being a transformation of the vmstat -z data, the same points apply. It is also not clear how much of the used swap space has exactly matching memory data vs. how much would have to be read back in if swapoff was used to turn off all the swap space. I've not figured out a good way to get evidence from such an experiment and it would mess up learning how big a swap space would be put to use for as long as I let the bulk -a -c continue. Note: I do wonder about a tmpfs related leak being involved: # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 103 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 68 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ but: # df -m /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p Filesystem 1M-blocks Used Avail Capacity Mounted on tmpfs 1024 405 618 40% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 405 MiBytes is big enough to supply sufficient material to the (now) 330988Ki-used swap space. But why the huge difference vs. the du totaling? cpdup and copy-on-write to 4 builders or some such and where the usage is accounted for? But I've not found a way to check if the 330988Ki-used swap space is mostly filled with tmpfs content or not. It is not obvious to me that such a large tmpfs "Used" should exist at all for the USE_TMPFS=3D"data" style and only 4 poudriere-devel builders. For reference: 7122 ports built in about 235 hours with builders running so far: Swap: 30720Mi Total, 330988Ki Used, 30397Mi Free, 1% Inuse I'll note that poudriere only reports small tmpfs use figures, such as in: [main-CA7-bulk_a-default] [2022-05-28_01h56m38s] [parallel_build:] = Queued: 32034 Built: 7120 Failed: 32 Skipped: 1774 Ignored: 1413 = Fetched: 0 Tobuild: 21695 Time: 234:41:54 ID TOTAL ORIGIN PKGNAME = PHASE PHASE TMPFS CPU% MEM% [01] 00:19:33 finance/aqbanking | aqbanking-6.4.1 = build 00:00:48 40.00 KiB 0.1% 0.8% [02] 00:13:10 www/py-django-treebeard@py38 | py38-django-treebeard-4.5.1 = build-depends 00:12:07 56.00 KiB 0.6% 0.3% [03] 07:41:31 devel/llvm90 | llvm90-9.0.1_6 = build 07:28:53 4.00 KiB 258.6% 9.6% [04] 13:06:10 emulators/mame | mame-0.226_1 = build 12:59:46 4.00 KiB 12.1% 1.2% So if tmpfs is really using much of the 330988Ki Used swap space, poudriere is far from counting all the tmpfs use in its reporting. One thing about using a RPi4B for this kind of experiment: it gives time to observe the behavior. (But I'll not be able to let it run for the 5+wk or whatever it would take for the "bulk -a -c" to actually finish for how I've set things up.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jun 8 08:15:55 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B0A6083754D for ; Wed, 8 Jun 2022 08:16:06 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJ0RT5WWPz4d5Y for ; Wed, 8 Jun 2022 08:16:05 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nyqr7-0008gJ-I6; Wed, 08 Jun 2022 10:15:57 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nyqr7-000AhP-F6; Wed, 08 Jun 2022 10:15:57 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 229A3480050; Wed, 8 Jun 2022 10:15:57 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QcybpDcP1PNV; Wed, 8 Jun 2022 10:15:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id C4BCB48013F; Wed, 8 Jun 2022 10:15:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k0KdR_L2v9H7; Wed, 8 Jun 2022 10:15:56 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 77962480050; Wed, 8 Jun 2022 10:15:56 +0200 (CEST) Message-ID: <8ced022c-518a-4a77-135f-37d58cde27e7@embedded-brains.de> Date: Wed, 8 Jun 2022 10:15:55 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: pps_capture() and pps_fetch() Content-Language: en-US To: Poul-Henning Kamp Cc: Konstantin Belousov , hackers@freebsd.org References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> <202206031847.253Il6Y2082105@critter.freebsd.dk> From: Sebastian Huber In-Reply-To: <202206031847.253Il6Y2082105@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26565/Tue Jun 7 10:08:27 2022) X-Rspamd-Queue-Id: 4LJ0RT5WWPz4d5Y X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-1.33 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[embedded-brains.de]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.963]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_COUNT_SEVEN(0.00)[8]; HAS_X_AS(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 03/06/2022 20:47, Poul-Henning Kamp wrote: > -------- > Sebastian Huber writes: >> On 03.06.22 10:28, Poul-Henning Kamp wrote: >>>> The expensive part in pps_event() is after the th_generation checks.= I >>>> think from a performance point of view, the checks can be reduced to >>>> just one th_generation check. I am more concerned if this would >>>> introduce a subtle functional change. >>> Assuming that your timecounter hardware does not roll over fast enoug= h >>> to open any races, I think that is correct. >> >> Would a timecounter overflow within a time interval from th_generation= =3D20 >> to th_generation + 1 not be a bug in general? >=20 > No, that is precisely the problem timecounter/timehands were made to so= lve. >=20 > We keep a ring of "timehands"[1] and they are all remain valid until > they get reused (at which point their th_generation get incremented). >=20 > pps_capture() latches both the (current) timehand, and that timehand's = generation. >=20 > Even if the timehand is advanced 15 times before pps_event() finally ge= ts called, > the latched timehand can still be used to calculate the time of the eve= nt. I think this is how I understood how it works. >=20 > If the frequency is adjusted between pps_capture() and pps_event() > that introduces an error in the resulting timestamp, but since they are > supposed to be called "as fast as possible after each other", and since > stable-state frequency adjustments are supposed to be tiny, that error > can be ignored until you get well into Cesium territory. Ok. >=20 > So as long as your timecounter does not overflow faster than timehands > are updated, and you call pps_event() fast enough after pps_capture(), > you're fine. This is what I tried to clarify. I think the requirement that the=20 timercounter does not overflow faster than an associated timehand gets=20 updated is applicable also to the functions getting the time, for=20 example using bintime_off(). This is probably related to the tc_min_ticktock_freq =3D max(1, tc->tc_frequency / (((uint64_t)tc->tc_counter_mask + 1) / 3)); code in tc_windup(). I don't understand the value "3" here, I guess it=20 should depend on timehands_count? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Wed Jun 8 08:25:49 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AEC5C839092 for ; Wed, 8 Jun 2022 08:25:56 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJ0fq6g1Cz4fWW for ; Wed, 8 Jun 2022 08:25:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 98D9A8928B; Wed, 8 Jun 2022 08:25:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2588Pnhv065320 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 8 Jun 2022 08:25:49 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2588PnVl065319; Wed, 8 Jun 2022 08:25:49 GMT (envelope-from phk) Message-Id: <202206080825.2588PnVl065319@critter.freebsd.dk> To: Sebastian Huber cc: Konstantin Belousov , hackers@freebsd.org Subject: Re: pps_capture() and pps_fetch() In-reply-to: <8ced022c-518a-4a77-135f-37d58cde27e7@embedded-brains.de> From: "Poul-Henning Kamp" References: <5b8310db-c94b-709f-8c57-bec2d413a80f@embedded-brains.de> <202206010725.2517PEfF036703@critter.freebsd.dk> <202206030828.2538ScDg080165@critter.freebsd.dk> <35d4d55c-ff62-cff7-cdbf-ea2549dee86c@embedded-brains.de> <202206031847.253Il6Y2082105@critter.freebsd.dk> <8ced022c-518a-4a77-135f-37d58cde27e7@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <65317.1654676749.1@critter.freebsd.dk> Date: Wed, 08 Jun 2022 08:25:49 +0000 X-Rspamd-Queue-Id: 4LJ0fq6g1Cz4fWW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[phk]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N -------- Sebastian Huber writes: > tc_min_ticktock_freq =3D max(1, tc->tc_frequency / > (((uint64_t)tc->tc_counter_mask + 1) / 3)); > > code in tc_windup(). I don't understand the value "3" here, I guess it > should depend on timehands_count? Not really. The divide by three is holding a good distance to the half-way mark, so that we "wind" to the next hand before the roll-over introduces s ambiguity. The number of timehands relate to how bad latency (interrupt and scheduling) can be for kernel threads. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Wed Jun 8 19:54:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 00CCB850DA2 for ; Wed, 8 Jun 2022 19:54:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJHxD6lX7z3QvJ for ; Wed, 8 Jun 2022 19:54:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654718056; bh=mryQtJjuclJFuyOgeGVGHL8Q4OyJ9Mr3ErPyWHKc+x8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=M2i1AAcSmvcRQO0SSooMWXpeGfsa2z//tvFX0gtUM67FAwSxmjIrgf8sJSNT17oGHhbAm1Qv4mHhVkFDfGaV1Jd+sHczCP24Dobmo/0pQbk/GaU+71o/sJKmqEuVeTBVPIPFzCOFovTPIdxzt2WAIt6KlwRFmGSU88h+WmN+okcStVwJbBjqwfBkf3gwPRG3jJXi1BfYd6U0mRFIZusdZSuY1OqgH7n2wO4iCEJ0c9nmvv5lmNLsg1QfhdDXDOkf7atKNNIim4oI1uCL+xCKDjCJ9rItUrrXGi4xPb6e7AZdxOQDG6+ihNXPKrElQzNYRoXfdFymgsADk0HilxL+0A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654718056; bh=InaEPmEOXkcGs9pPF1SXfxgtVRYqeRa2PGBZ7pzaUZb=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=eYC1MtHfSvlIcdLKARszdHfBu8xMAmtP7oAgYxEcPNwC6sa0ykV07ckpK2DxMDOLgq2FIovhlbRIW63UhO+5/RefgGqrwuBcXyWPwBMqbTQdd+2DLXPUAGWS+4h/Eiz5FMoa5HXevu9z7/eh8vHIEMFlbW69weiX2bTdoEgigloQsG9luBWN4V8ESgBQzhYZX4B9R5id12ILFcTiAzaDgktdKwuZUT5Gov6LhJscLj690QEAf5w1XFpDDxoWX54hTg2TJz1DbT25d9rSu6V+L/aJymo6yz+nrbVbnObe6TII14JGSe7QaKIn5sy26F7Gr3OcdaVbxl/VAk+N4e8RZg== X-YMail-OSG: upFVlDkVM1na7_A0VyOv3VT7_10dsfP1HgX0SkubIGaN_gvPzSqlqj0CvDac_OB khXZPNTAszPzU9p.ZJwR2zJhniRXPEPwV1vbcpdfEzcOdSKIH6r1JwcOnvm.CoOP57kooRZgEnlo mA56D4oGlKsy5sTA3tCoTcMRMEwXdWU2GcvMtqVVkFinUztb7AGec47hnWszTrNNh5682LeHUuum ldBVI2_Y_ZCr51NbRouX24vkLVOxMWHLlCUGgYZa00jYLVxScSG2TJHAmLUgCM2vHChwIk7pJHCM iv01oDSGGxjXCp2.rQrHG.lDINiyc.uf0wXS13uYiFvg3lH9dhfXaKklknbaSumQgseWhgP4ibjB HmDCEjBfQgN3WyGr_GfYQz8Bp8WBACxNsFCC0yvXfRsadssy7A2r2Q2J4L2cqi4ivyMpwDlTCPL8 _vfnie5sispl85Jxw6YoAk5nj9FrFOtdYCuw9YzGYvlU.TJbGjpa35JmIt3j8bOdPzeUYRIYxupC Kf7hUZ9wBpRHQq0H.q7St8axBYVSvYFNPweVZkDfL_Z1Yp37tNVYvXY8VOqbsCe_0yN9wBHw_2N. bXEZz4PMVlgUPc1j3Ip0G.24RhtDbjLzBfS42F_iJY9VWTd1z0LqYTZmiy6IMpbsTkakUrsZmZf1 7Q.RXoelP1KCXAcoTlGbHvuh5m5VfCQ7povA0DN__E.xZ.HyMotaagm4d8oUUk7W5QtGpgK1XMyd nVya_dND.miat.emLLl7MxuQEmP85M36dUHTQM9kcuLsSyRt.SbkYQ2MdvyeSn15xXo_K.UjTiid XIltoolcdbvMK5.ATLxqhoEIBNpSGiFyrh_3bbNWMxVj.XFb.9.lC963Fo5MAyehJex5u5HhlstY rv1ZwpW9HdAsBerQmfTk3z.TFHpgAk78FjlIv3nBazA7c7Mw2K1An2gUwsC__Dx9iS62VPPDV98f OYjO.5haZt6QtWgnjakIyQqzZ.egYtsRtVpDNaHkt8MOr4B0SKIigv_xjJSUNmDWq1fQLnJsKZ3b 57l0kea0xAGBJXLysVAZA8oJdBt8uxC.gcDCDMdt8rWQNGpJJYGQkzTGVvIuwXZbLNVk3f4XhC_K .0au9KHdQ8lBybuMPz22SqmIITIRe.xhYVNi7dEIcEX3khNi_nPAoyayOefupvdCKD9UHlhAMMQT Gc9OXToEZtMAlYI61wCqiO_2dVSQZ0hGNolno4IUtNO0SIFw4PZfslpJUZgduHA9OPe23PD38bEO Ek2fPGRTLS6Rc3J7s0vVaKrGfyufvxwrZofeI5fmrJDFSfU8gGrfFFMmCFaxGcoUKFHpP.jJosSD Z9A0obC2wQb0fqScTi_n.XEw2RmpOuBzoptDLdGLdlD4jUdM_RD3X8PKM2wfRCPf9cifGFnD1yfL dNfaJDSjg3vJBAQAjrCR_5hk.lpNyuA75evB4vYgg0Lp0T3.rXijMky7.2qucRfgOPGcQnHDV1vt 4jfi9REHMd9sYfcMcESJNhhsKuG2zhCdBzSbmkAIupjEdmBGATVPoqXKY90PgK6c0V3LxMu8QgjQ Pn3CLmtTS7x5WcRM0HqNyeLJn5AcXeheA0ILx.mWsfFzNvI1skU5f7K5Xwnuj0qxb043K4zzajWZ fJgYTFJjpNEpPDEre4me06Ka5ticvqwIPVOS__v5QLMR9DEkhsfxj7ojdCRjT1N5WJEiGxzSBjgk WmbaIrAkMuj3tCGNj97Vmo0Cpt1fPptTsi7SCyniTZCENztGlLtFsMdyJJqQhX6oMuuy9uwquClK mn2ByFw81u0lSRCEho1uKHqG3.TmcPbi.PPHb6hqsIy5hSDqTpCAHogLDG62aJwaa1PtBsBfO7kS vlRlZ_nsYd2I4qECJyZQ5S.VBZAY3UagvuXlC6.0RHRRanLxCCvboErYhfD6mtMTMHzgQV7oqdQP LDK7JmZytQzOp06OSRgJZBPrLCPek_3pgp.25.MLghtD9W3AWLQD9.g.Vv6vj2vIW6AzucMzdYMx HJSznPde4l_csPeF_QDTlxvx24my_InH3tTADLHOC4tMsT5tqjtwLJs4HAbDo8nMePAfD7QEwu0i ArIskkZg5XvYPsuc0zoyJZLI951ooYRKtArFuX_YsL0m37uI3pFET06lvuw4xiFzhtDwF_7jn.29 tR94HxyWP2.x72U.Ot2iAg5.RQ_.lwhPwdandR3scLYpM7ChQRMEHPiMwlrcCX5kqYwVPnP0BMTM OARa7E3d._.OGRzuGREvrNIvmIPQp7B3Vxbtuntss_o58SYKBP8Snd.yVD8anAbh_SK3m_hE- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 8 Jun 2022 19:54:16 +0000 Received: by hermes--canary-production-ne1-799d7bd497-d2s2t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 51c1af683ff18023b5c53309c4e08d9c; Wed, 08 Jun 2022 19:54:12 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? Message-Id: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> Date: Wed, 8 Jun 2022 12:54:10 -0700 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> X-Rspamd-Queue-Id: 4LJHxD6lX7z3QvJ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=M2i1AAcS; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N # df -m | egrep "(^Filesystem|^tmpfs)" Filesystem = 1M-blocks Used Avail Capacity Mounted on tmpfs = 1024 403 620 39% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p tmpfs = 30849 0 30849 0% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/var/db/ports tmpfs = 1024 0 1023 0% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/01/.p tmpfs = 1024 0 1023 0% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/02/.p tmpfs = 1024 0 1023 0% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/03/.p tmpfs = 1024 0 1023 0% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/04/.p So the comparison is with the line that lists Used as 403 (MiBytes): # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 68 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p Why 403 vs. 101 ? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Jun 8 23:35:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 65FE6845D30 for ; Wed, 8 Jun 2022 23:35:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJNqy2RJPz4gDM for ; Wed, 8 Jun 2022 23:35:10 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 258NZ8Eh033542 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 8 Jun 2022 16:35:08 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 258NZ8sh033541 for freebsd-hackers@freebsd.org; Wed, 8 Jun 2022 16:35:08 -0700 (PDT) (envelope-from sgk) Date: Wed, 8 Jun 2022 16:35:08 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4LJNqy2RJPz4gDM X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.82 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.96)[0.963]; NEURAL_HAM_MEDIUM(-0.79)[-0.788]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N All, mandoc and mdoc(7) are a convenient system for writing documentation, but it has a drawback. The volume title is hardcoded to a FreeBSD manual page. For my personal projects, I would like to change the volume title. For example. % mandoc tier.1 | head -1 TIER(1) FreeBSD General Commands Manual TIER(1) I have hacked up mandoc to accept a -V option, which allows e.g., % mandoc -V "Steve's Menagerie" tier.1 | head -1 TIER(1) Steve's Menagerie TIER(1) I have created a bug report and attached the diff to it if anyone is interested. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264560 -- Steve From nobody Thu Jun 9 03:21:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4B1B3840CE0 for ; Thu, 9 Jun 2022 03:22:14 +0000 (UTC) (envelope-from nc@FreeBSD.org) Received: from thunderstorm.neelc.org (thunderstorm.neelc.org [IPv6:2001:19f0:8001:174b:5400:3ff:febf:260b]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJTsw5Xnxz3Jrl for ; Thu, 9 Jun 2022 03:22:12 +0000 (UTC) (envelope-from nc@FreeBSD.org) Received: from mail.neelc.org (thunderstorm.neelc.org [IPv6:2001:19f0:8001:174b:5400:3ff:febf:260b]) by thunderstorm.neelc.org (Postfix) with ESMTPSA id 238EB2FAF13 for ; Wed, 8 Jun 2022 20:21:49 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Wed, 08 Jun 2022 20:21:48 -0700 From: Neel Chauhan To: freebsd-hackers@freebsd.org Subject: Potential USB bug with read() (while updating android-tools-adb) Message-ID: <9b3dbdddb02e65c5ff4b3dc0f117c3c6@neelc.org> X-Sender: nc@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LJTsw5Xnxz3Jrl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:19f0:8001:174b:5400:3ff:febf:260b is neither permitted nor denied by domain of nc@FreeBSD.org) smtp.mailfrom=nc@FreeBSD.org X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ONCE_RECEIVED(0.10)[]; FREEFALL_USER(0.00)[nc]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; DMARC_NA(0.00)[FreeBSD.org]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi hackers@, While attempting to update android-tools-(fastboot/adb) to a newer version, I noticed a potential bug with the FreeBSD USB subsystem. After two reads from a particular function in a USB device, read() reads 0 bytes even with it should read 8 bytes and returns 0 respectively instead of 8. The branch is: https://github.com/neelchauhan/freebsd-android-tools/tree/fbsd-31.0.3p1 The offending lines are: vendor/adb/client/commandline.cpp:928 (ReadFdExactly call) vendor/adb/adb_io.cpp:83 (adb_read call) vendor/adb/sysdeps.h:526 (adb_read definition, this calls read()) This happens when I attempt to flash LineageOS 19.1 (Android Custom ROM) to a Google Pixel 3 smartphone via the so-called "recovery", which is the "test" device used to test if this port works (my main device, a Google Pixel 6 Pro while rooted can't be used since I'm not willing to live without a phone). On Android, recoveries are used to update, root, or replace an Android installation. The `adb sideload` in the recovery causes read() to fail prematurely, whereas `adb push` in a recovery works perfectly. However, LineageOS requires the "sideload" function to install on many devices, and I don't want a broken port in the Ports tree either. On FreeBSD, this exact adb_read() routine works fine on other `adb` calls. On Linux (or macOS when I had a M1 Mac Mini before donating it to kevans@), `adb sideload` works perfectly, period. I doubt most of you are rooted Android users, so if you need help understanding how Android flashing works feel free to ping me, I'm no "expert" either but have been doing this for 8+ years. This error also happens with the Ports version, which is why I initially wanted to update. Is there anything FreeBSD does in its USB implementation that's funky, or even in libusb? Especially in the last 2-3 year? Or is it more adb issues. I am using an AMD Ryzen 5800X-based HP Omen 30L running FreeBSD 14.0-CURRENT with Git revision 0817c8dc2a4 (May 14), but this also happens on other Intel-based and AMD-based systems, with both USB-A and USB-C Ports. I'm not *really* a kernel person, and not at all a USB hacker. I'll probably update my CURRENT but this issue has been happening for 2 or so years now and rebooting into Linux USBs isn't exactly fun to flash my Android. -Neel (nc@) From nobody Thu Jun 9 07:17:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A6A1083D234 for ; Thu, 9 Jun 2022 07:17:04 +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 4LJb4w4JsLz4TF5; Thu, 9 Jun 2022 07:17:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654759024; h=from:from:reply-to:subject:subject:date:date: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=VvOPiY2zP6mxXhMGLyt/llKbij/uh61McIPSVnPMLrQ=; b=ipcmVNaryF+pcitqi24yAIvjAycnwuc6vw8qiIR4BoWmTCdpKvnXpkr59aieC8MgBUO/pw lyPiJQj6x8vID3pkBzgnOQ7DGIiFboX6rO1FBXB+PogQcVxPQDs43Z1jUl9kUT4s2VLyfu XWGq6+C7ETeiARvQkwlOvIxYQuaRhQD5RfIOkXg8PE9Zw51krYQ3T9oj0urk7dVG0W0R70 AbhdL52FLslUIrYHbmSWhVfSqE/r8L4594EjqdX4KBaVBRlFDu+ExJnQS20u+Qe5bHYlwa czNqb/Ua/7SG9AaOFDCj2txLja9Q9Jn+uSoBLkBvYOfkBKAcj9Ru8937aQbIzQ== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 5AB35D2CB; Thu, 9 Jun 2022 07:17:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 4E9C6FE967; Thu, 9 Jun 2022 09:17:02 +0200 (CEST) Date: Thu, 9 Jun 2022 09:17:02 +0200 From: Baptiste Daroussin To: Steve Kargl Cc: freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654759024; h=from:from:reply-to:subject:subject:date:date: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=VvOPiY2zP6mxXhMGLyt/llKbij/uh61McIPSVnPMLrQ=; b=ZWR8487IIRH0V3KVPjznNxzLKs8Vb3mOZMWALwi2rTXsYOjvmRT3iHRVqifd/QQdVZF37j 95B0TxlpitJkNwhYDB/xSnGEmGgw+FoDTU3OtJx/Ko2e/acquEltT9AnZ+SexSaiaxzX/8 gq2yjmnYEbL0hrBKgU08e4jr4sv9RR018RmYh5QTnKvjSWDhAUxa+gRjxJcArf/7jvYMRX aGiylpuoPmUeFAEqPv0+Z01DPrzLiNnMzx1wkKlEKGYqBPo7ZfHmLw8EFYxvwnuZS7qgnR ZOUy/Wh5uQqaGcnxP50ItoCxIkC+Y94UaG6mlo1ajwupTTgncRR+TkY7IbFXrA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654759024; a=rsa-sha256; cv=none; b=U3WURizr9TFFKjef4UyjKr6Iu/X0hlbZlxieFnDm6suOss0sSs9Mw7sOLrIs8RGEyVMtC1 Xu0CI99v+h28JhIMcSu97FOi4HLnT7W3f+y+7CbXEwMVN1F7C8b5G8hi6Cs3t9JXkjJE+B i+hzRdnu7ueMVC5GP3tfp1GGMo2hVjYEf58WP79Az1K1adUe3wBn2YOrok9AxGE4hl333O gmzc6Dw1xT1JRUPdAJoyY+ozeUCyifumrhjof1i+bZ37JiO3lNQ6URppgQyGBfori4E8Y3 3tRuH7iFVW+JkiN9rwdzXW5cjUZmezL27wgEPrWUGjojvq9i/HY+A0GpXvHOQQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: > All, > > mandoc and mdoc(7) are a convenient system for writing > documentation, but it has a drawback. The volume > title is hardcoded to a FreeBSD manual page. For my > personal projects, I would like to change the volume > title. For example. > > % mandoc tier.1 | head -1 > TIER(1) FreeBSD General Commands Manual TIER(1) > > I have hacked up mandoc to accept a -V option, which allows e.g., > > % mandoc -V "Steve's Menagerie" tier.1 | head -1 > TIER(1) Steve's Menagerie TIER(1) > > I have created a bug report and attached the diff to it > if anyone is interested. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264560 Hello Steve, Regarding mandoc, I would like to keep it with as little custom patches as possible, regarding your patch, it sounds like a useful feature, have you considered talking directly to upstream about it to see if they are willing to integrate it directly? https://mandoc.bsd.lv/contact.html ? They are friendly and usually reactive. Best regards, Bapt From nobody Thu Jun 9 08:23:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D6F46844612 for ; Thu, 9 Jun 2022 08:23:04 +0000 (UTC) (envelope-from se@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJcY45Vqtz4Zlm; Thu, 9 Jun 2022 08:23:04 +0000 (UTC) (envelope-from se@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654762984; h=from:from:reply-to:subject:subject:date:date: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=yoZs6aZBlTZprWF9Bkpb3YXNGNjkpOBx4db8+qhLIlQ=; b=EOZCdC8C01UWWRdXH2WGIekv3/Gx/xKojVumga1zFRaZHLOiV00tSF3VgyFqTH7KitWPPU tQvkEZfvJ7Uhnlz0nBsHPry8QSCksKmqnds+ODIZxTGie4nT2UmqBOMbWHXGbfPLXkq6jd I4umsmUMt38l1AChxE/FBwozYTSOG49sLD/L1FmLLCyk20O1MB4zjQ3tZXmOWpm0YJEyOL eGxiEiNGTxRQ81/DyK1RX93KTuHeK++wnSCgZJJ2ZZsJYN58tcUNggP/l/WLJaWK6OJYMK xbI+poexPExywiYDU9dXl0ZE0dPOCawyp7YfyEh5A5sBQrCR2YDxGu5NDzoKUg== Received: from [IPV6:2003:cd:5f17:8800:7c28:a844:b85e:7f82] (p200300cd5f1788007c28a844b85e7f82.dip0.t-ipconnect.de [IPv6:2003:cd:5f17:8800:7c28:a844:b85e:7f82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2F4BEDD36; Thu, 9 Jun 2022 08:23:03 +0000 (UTC) (envelope-from se@FreeBSD.org) Message-ID: <24c79e23-a715-6222-452f-24a9186dce89@FreeBSD.org> Date: Thu, 9 Jun 2022 10:23:00 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? Content-Language: en-US To: Mark Millard References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> From: Stefan Esser Cc: FreeBSD Hackers In-Reply-To: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------zwlWQj06LewrfD4iZ0BQH2h4" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654762984; h=from:from:reply-to:subject:subject:date:date: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=yoZs6aZBlTZprWF9Bkpb3YXNGNjkpOBx4db8+qhLIlQ=; b=gMzL8aqMP7nmBVLZmKxDu4ARLrCOBI/OMlHDgc5kmfNugiz3hJNB7/iDkmkswlw2p5Pm+w aNSPY9rTrFdRYMsQtvJvDEBSMh18/3yb12I9WItzdDTb6JD3CctdNcoGlqCxeGuoYvn6Vw U8GgOZHj/qUF5hctTB5FolwLFNs6NtzI3t7deQaweB7CKkoMK3TyGSDEQLOcyGzUeF8Us+ t+Cx5YdP8mOSLGBvX7PIUwukP6jwozMboAJwbIEYUgMkx9kxIyVimY/jQoH0wGvVizSnYC nJrW4gTUoAd+o009VsAhtblLPE1zbxz8wMJAqxK3wKGaAjZen/nF8eG7Pmy0Ig== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654762984; a=rsa-sha256; cv=none; b=nhZNBPbknwL2J10agcV0nLACD7SiN6xmJvsAYM3bdbod0hC38yaDPWGDKKFJHQst+o7A5b bVnR2oeStwz9GXTr5WgfwyFVuV7q20PJUPOy9TKilh2sMvNLY4Uxz0FFI+kJxFHBnLsBwY sBzkWmFw5JP+tqriI37/AKd497ZrNhju7rBEytubm9BsW6OT1G3xbnbcpwOrr3hiBQjyaC 2WLKRJz7GF3WHMemvXuKnjWTnB2up/S3tP17E4EcySLcc811l2Nmb3AcRXguDDiXlLPHPQ 1P16UD52VEam7Qj5qrqY+5vaz70UiLdcLRO0gl5uIAzLtJewyl9j0p/1nK0OZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------zwlWQj06LewrfD4iZ0BQH2h4 Content-Type: multipart/mixed; boundary="------------YGsBCTzS0SSPbzwlEvB9UgVy"; protected-headers="v1" From: Stefan Esser To: Mark Millard Cc: FreeBSD Hackers Message-ID: <24c79e23-a715-6222-452f-24a9186dce89@FreeBSD.org> Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> In-Reply-To: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> --------------YGsBCTzS0SSPbzwlEvB9UgVy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 08.06.22 um 21:54 schrieb Mark Millard: > # df -m | egrep "(^Filesystem|^tmpfs)" > Filesystem 1M-blocks Used Avail Capacity Mounted on=20 > tmpfs 1024 403 620 39% /usr/local/poudriere/dat= a/.m/main-CA7-bulk_a-default > So the comparison is with the line that lists Used as 403 (MiBytes): > # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p > 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p > # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p > 68 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p > Why 403 vs. 101 ? Hi Mark, have you checked for unlinked but still open files on that tmpfs? My quick test with /tmp on tmpfs did not show any anomalies: # du -xsm /tmp 730 /tmp # df -m /tmp Filesystem 1M-blocks Used Avail Capacity Mounted on tmpfs 16384 733 15650 4% /tmp I do not know of a simple way to check for blocks allocated by files that are open but have been unlinked, though. (I did not get any usable results from lsof, fstat, and pstat - may be I have missed a tool that grabs that information from the kernel.) The best I could get is this pstat output: se sleep 89643 text / 25349 -r-xr-xr-x 8592 r se sleep 89643 ctty /dev 157 crw--w---- pts/0 rw se sleep 89643 wd /tmp 2 drwxrwxrwt 51584 r se sleep 89643 root / 4 drwxr-xr-x 47 r se sleep 89643 0 /dev 67 crw-rw-rw- null r se sleep 89643 1 - 137245 -rw-r--r-- 5 w se sleep 89643 2 /dev 157 crw--w---- pts/0 rw This is for a sleep with stdout redirected to a file on tmpfs and the file then deleted while the sleep command has it open. As long as it had not been deleted, pstat showed that it resided in /tmp: se sleep 89643 1 /tmp 137245 -rw-r--r-- 5 w But you can compare the number of inodes reported by "df -i ." and the number of files found by "find . | wc". Run these commands as root in order to not miss files that are not accessible to a non-privileged user ... Regards, STefan --------------YGsBCTzS0SSPbzwlEvB9UgVy-- --------------zwlWQj06LewrfD4iZ0BQH2h4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmKhreQFAwAAAAAACgkQR+u171r99UTQ 3gf+OXnslrRsBkxAngHlTZ89OUNcyWEkvC+fCFvZgq2k8rgOaFbpOkCaohtsgrzB9yWAt0Mgy3IE VhLe5ASIcWAVNKSCuwcY21dKwrmKrcMP2E8Gt795wQmzYSxMwdxfBdWawMea8JI56xbx0ZzIS97a 6EGOQkwH22TqdQx2OfY6Xpr3lhoKEHGrKLJoO7nwqF7OZkBisWN4x1bZKFyBbLHuHINSYyFuR0bm j7xRO8Zsa539yw4Sex/NcODI+pw/aMlQJhnCkUAvDfEhZHo8XH/2p4umG2EASVlKNBzG9UjyRPWB 6KBy4mXpzWCyu6gTgOS10q49c+bCz+2zE/eGJruTFw== =MoN8 -----END PGP SIGNATURE----- --------------zwlWQj06LewrfD4iZ0BQH2h4-- From nobody Thu Jun 9 10:03:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 40146858D6D for ; Thu, 9 Jun 2022 10:03:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-19.consmr.mail.gq1.yahoo.com (sonic314-19.consmr.mail.gq1.yahoo.com [98.137.69.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJfmv2Khtz4nFX for ; Thu, 9 Jun 2022 10:03:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654769000; bh=DalK6uhalXRyigHFXrD5NHYKKceECkxzHrzFhTUkSck=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=tjgBOtQfX9jYBNorp0umsLsqoogfD08vGVtJy9gt+lFOYHguSjp+2od7+rzzyPsXxPJVZ1WX/ZlvYCTceCCR4YARogJ2YxxMJGgyJUhxi14zQCEqVvm0VhzXThW96dpSLnl/2POUQLfTEQjaxUI6Fd57l72DYtWB/dbCib2/hNlTQQil3fysAbBggqxtRsJ/z0oGQiWm5Ismzh3rW77rfyjrAYHBTGiPirstPJJUyRuzhsoNMWQM+nxcBk4J/Wbk/5SXIed6AsBdkPnz9Io9RFKfY9DIGSOKZVUekAU/UdDyVV01ThzjCJ6vNit1yLY5duNpveYONZ+pnrLw4itjZg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654769000; bh=UmjRfgEoSbar0EqSmuLnvMOlHaq+K4LGl+H8dHzzOpA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=mEEXbhtsCrCm0EohLHP5qG5taxqfqB91jLRMVMHha0n4JRYlABNLVjvHX2jlsYhu+hkP4SxUMuV3DesV8dEHgiztAUm7c/fgkfXIiYtRgcaxDuJUnDL5MZgoNL0QGHyuwyfqpK4+V4d5L1iFU+pwzcCtjrgg/VFOdSt3XOxDB/tb9O0O9fcx0FmK1sDXGmiiG6zxfREMq7Wn0vYoDoQw2yt0Utf4hiEbxoOu3yI2EASNW7HZLjqKnRSvVjhJR9U7/U9hufm+NQUGbQLb/E5F8RBYaANfvpMXtKom7TVQEhykcuWgDWEvcX2KgEF0KaXLLwKrfgBluFQcloYy7C6vzQ== X-YMail-OSG: Lr4dpJAVM1mn7UP_NtCZOuk2BF44Uat58SXfBMqdcFX7EFbk4awFgiM2ozMfWXI c3A0l.t3slPDooAyFS0.qd9A1nUE2.iU.NWxY9FLAdcOYiB_g4t5h7.KMwIg4BR6FZa3dEVeqqp3 eD0kV.HXjQaOCq9LsLKd83dmmA7rYTnbbKIyOFDCQrsZWhBkzFg9rjtHgvAId6LFhacLhV1Kpnff g7ounB5WWY0cksZ74R372Nj.yDUGt78I88v_AOkwfMKegguXR7cJVFK2s.HstK7LAdaEIVYnBbPW nSxjHBtyf2ZYGkB3jYxPX1OEygZciKHk88bdOscg.Excp4BvIwiLhQh7CPJxdKr61Z7qPG9w9pAD 6PtHRGSZj0U08N_agq1oqjXP5w2_FaH_glik_9CSE5c6r2Fs4OKAv71QcejJmACbTR6LTcLs7l7S .z0.93LDXBQ.E5QpT5es2itUNGtV_e7JtUvSnqLlh3JycSsOFzpODPVXIJI7dMmbfNI2D3egZtV6 80BT1Wycutvzyk38UfPuVw0kLqYlUqHc9Mcp2g1_avtFXY_zsn7gNzFCEmx0IUipoNqS7XbyTcWh FbO3Hd6ciC1q.6TTrqvOQoASb6EEZDCRXijdRdvoWuDJOL_eaWKZL7umguSEKjRjMhoIKodsD589 tRC.CQ_7Kkl8a9YtafeLNV7YkG_5lDyl3uyl4HOSKO_ewqEEE_n1WcWxysqVsAhqTIcclj.2GuW8 0tqXkRIQ5CT1gYZb4ccYFj9Hg29Fs6qtM4xpS3l_wocIaBatrY2BRbruXlEFRD6egzDaAEUXErRI dCJXALszNNuOm4bZtsaqpIhemXpQs5iERcUK8BMjnlzsdtu5tBmT9IcoOBDbKdXkrzm3jNgRcLRH Ujw5cLS5I7uLXPBTofDSy9S3LEQ8z2aMU7g8gpSMoxWpPGFCcV3keVcuIhjaEe3J3.5GHoRM4zhu DWv1yfPqBvMANEeC1PYN6JY.5Awm7LO4VsDAbZmCH1BKWmLKATsv._wn87Ef2AF2meQIcwFcwGMs xKaWhxk2ePoLveWUPEzPLSXEF2KB3SXA1bzHEOIx1bPUWPBgnKlp38GWGSgfzIhEo7hmRhJDNTcn lHrI5IshXjJtJl0E6iqjkcmEVKVSQbc8u2kV5A.jlL8Nw2kFPsn4c4KG6ifwoVAQ7IBZwbiIc1aD ELW5sIeunkOvy5Qn4rZ5.cYS8jUDEWiI9StbG2Lyr928Ha8VlVjF7b3axjot.utex3ta52Ai7LGT UNixwcaqXZbyKztmysneTDOMUe2LqWG3bPvXWB7G9fvDz.5.T1fmqWo1zGxC.iNZWobllra69g3t BXgqvx_vsqbolLs_ZdphJOqgDbMlCWqnQo6cJSgf4r2ufrzR36DuaAx4dNWgUOk9oIf5M6Futncb 1qTtmDDFs2dtfZHo93E1iJn2bJp4AS8Wj.V7NQNoxJPFBlPRknw6rQndJJ33QqvRULYtKv7x1z0d YqqwsxL076dS.rCKPGhx3B2D_C7.qIA9KDVKW0UMiZE1m.bsI8_FNiiMRXCE66wx0U6xuuD1q50K if6EOV4nkcPAspcc_vxUaNjH_ThcNsay8tgns.e13zGO7CSx6cXsW2bBLe.yj9U8EihTdxQ4BRy7 nbwCdBRxUN83VQqNLiUaEz46htJ5EOOX8WqgVo9nFzoAMzTaE54E14QXL1ngwluqStVM2H8zVShu B_B66CuyZlBrkiX9ZjhNVNlnjmp3XHbt82n2.3LKT6PjBcqwJ6MX_ngOJKPRxVUBxPLAfoztRXYB lo7opVKAn9DxAZMlFWtuEQOb0huearvJ7ZDKsp8bzehIR0iPwert22JJZSERw4S1mPCQjxGRrpGy 9yrUBmbBZEZ9gZXNJOJaexscGWmT1w0T9rymWt6pDlPQ7Hdlr85aucmgjwtJDcodTKkBT_0PPq37 gthADo2xN_KpOaWa_JaQZKPOmHLFmaNUvuh8XkUsnvGff1GG9Qz6OK8wBVTHoI4QY02EUF0D1zHq 2e9P9HB0nbqCgN9tuL7Zr.YSTj7Z_jYLQg9ySdfeBs7LlpDcE2KbxkXewJcDK_5fgLsVz5TSvPTs gpt75kyIGh6G06DjjWAURqus3dIUKgpP1mQdiAUaJ9YdWsvFSt8XNAGPZpQv8vVQbf8ajT4N6_QS daklvzNYF.0kJENPTzTyg.cMJNuF.t9USe1JMeedo6IfEANmR9wLmSjm6sb.I2q8uWBKvFAo4zj. 6Bz256QmZ.yy7Y.1lZ95QoMjgFmZjng8VFABCgONOP.eJsxCBkUsi9.mOCGQ5hRlUUfUGNptpJqA dDiOUw8yyTCiF X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Jun 2022 10:03:20 +0000 Received: by hermes--canary-production-ne1-799d7bd497-8kdwl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ab44f6b7a7275ea520d1c210047b7844; Thu, 09 Jun 2022 10:03:18 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? From: Mark Millard In-Reply-To: <24c79e23-a715-6222-452f-24a9186dce89@FreeBSD.org> Date: Thu, 9 Jun 2022 03:03:16 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <604FD980-1492-4202-9F1C-4408D0A726AD@yahoo.com> References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> <24c79e23-a715-6222-452f-24a9186dce89@FreeBSD.org> To: Stefan Esser X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LJfmv2Khtz4nFX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=tjgBOtQf; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.48 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.98)[-0.984]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.82:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-9, at 01:23, Stefan Esser wrote: > Am 08.06.22 um 21:54 schrieb Mark Millard: >> # df -m | egrep "(^Filesystem|^tmpfs)" >> Filesystem 1M-blocks Used Avail Capacity Mounted on=20 >> tmpfs 1024 403 620 39% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default >=20 >> So the comparison is with the line that lists Used as 403 (MiBytes): >=20 >> # du -xsAm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p >> 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p >=20 >> # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p >> 68 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p >=20 >> Why 403 vs. 101 ? >=20 > Hi Mark, Hello. > have you checked for unlinked but still open files on that tmpfs? >=20 > My quick test with /tmp on tmpfs did not show any anomalies: >=20 > # du -xsm /tmp > 730 /tmp >=20 > # df -m /tmp > Filesystem 1M-blocks Used Avail Capacity Mounted on > tmpfs 16384 733 15650 4% /tmp >=20 > I do not know of a simple way to check for blocks allocated by files > that are open but have been unlinked, though. (I did not get any = usable > results from lsof, fstat, and pstat - may be I have missed a tool = that > grabs that information from the kernel.) >=20 > The best I could get is this pstat output: >=20 > se sleep 89643 text / 25349 -r-xr-xr-x 8592 r > se sleep 89643 ctty /dev 157 crw--w---- pts/0 rw > se sleep 89643 wd /tmp 2 drwxrwxrwt 51584 r > se sleep 89643 root / 4 drwxr-xr-x 47 r > se sleep 89643 0 /dev 67 crw-rw-rw- null r > se sleep 89643 1 - 137245 -rw-r--r-- 5 w > se sleep 89643 2 /dev 157 crw--w---- pts/0 rw >=20 > This is for a sleep with stdout redirected to a file on tmpfs and the > file then deleted while the sleep command has it open. As long as it > had not been deleted, pstat showed that it resided in /tmp: >=20 > se sleep 89643 1 /tmp 137245 -rw-r--r-- 5 w >=20 >=20 > But you can compare the number of inodes reported by "df -i ." and > the number of files found by "find . | wc". Run these commands as root > in order to not miss files that are not accessible to a non-privileged > user ... >=20 More interesting explorations. Cool. # df -im /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted = on tmpfs 1024 403 620 39% 113645 3818515 3% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p # find /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p | wc 113644 113644 12097639 So 113645 vs. 113644. # fstat -f /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p | = more fstat: kinfo_getfile(): No such process USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sh 71776 6 - 609904 prw-r--r-- 0 rw root sh 50336 6 - 609904 prw-r--r-- 0 rw root pkg-static 73152 6 - 609904 prw-r--r-- 0 rw root c++ 73472 6 - 609904 prw-r--r-- 0 rw root make 50337 6 - 609904 prw-r--r-- 0 rw root sh 71553 6 - 609904 prw-r--r-- 0 rw root sh 73730 6 - 609904 prw-r--r-- 0 rw root pkg-static 73156 6 - 609904 prw-r--r-- 0 rw root c++ 73318 6 - 609904 prw-r--r-- 0 rw root make 74247 6 - 609904 prw-r--r-- 0 rw root sh 96552 wd = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 8 = drwxr-xr-x 3328 r root sh 96552 0 - 609904 prw-r--r-- 0 rw root sh 96552 6 - 609904 prw-r--r-- 0 rw root make 72584 6 - 609904 prw-r--r-- 0 rw root sh 72585 6 - 609904 prw-r--r-- 0 rw root make 74194 6 - 609904 prw-r--r-- 0 rw root sh 26643 6 - 609904 prw-r--r-- 0 rw root sh 74195 6 - 609904 prw-r--r-- 0 rw root bsdtar 74260 6 - 609904 prw-r--r-- 0 rw root sh 74166 6 - 609904 prw-r--r-- 0 rw root make 74168 6 - 609904 prw-r--r-- 0 rw root sh 50361 6 - 609904 prw-r--r-- 0 rw root ninja 50362 6 - 609904 prw-r--r-- 0 rw root c++ 73723 6 - 609904 prw-r--r-- 0 rw root c++ 73885 6 - 609904 prw-r--r-- 0 rw root sh 41277 wd = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 2 = drwxr-xr-x 960 r root sh 41277 0 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 609903 = prw-r--r-- 0 rw root sh 41277 6 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 609903 = prw-r--r-- 0 rw Looks like using -f does restrict it to the same file system, even when it is displaying "-" instead of the mount point's path for the file system. # df -m /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p Filesystem 1M-blocks Used Avail Capacity Mounted on tmpfs 1024 403 620 39% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ Unfortunately, I still do not see anything for the size difference in df vs. du. Thanks for the suggestions, Mark =3D=3D=3D Mark Millard marklmi at yahoo.com From eugen@grosbein.net Thu Jun 9 10:45:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 405EF85EDEA for ; Thu, 9 Jun 2022 10:46:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJgkJ1f7sz4tpM for ; Thu, 9 Jun 2022 10:46:16 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@[62.231.161.221]) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 259Ak6mi013425 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Jun 2022 10:46:07 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: marklmi@yahoo.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 259Ak5xo046639 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 9 Jun 2022 17:46:05 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? To: Mark Millard , FreeBSD Hackers References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> From: Eugene Grosbein Message-ID: <82ffa6bb-5826-62b6-2b82-a735b183272f@grosbein.net> Date: Thu, 9 Jun 2022 17:45:58 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LJgkJ1f7sz4tpM X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.15 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_MEDIUM(-0.76)[-0.759]; NEURAL_SPAM_SHORT(1.00)[0.999]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[yahoo.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 09.06.2022 2:54, Mark Millard wrote: > Why 403 vs. 101 ? lsof +aL1 $mountpoint From nobody Thu Jun 9 12:30:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1428842C3B for ; Thu, 9 Jun 2022 12:30:34 +0000 (UTC) (envelope-from fbsdouille@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJk2f0jCsz3L7h for ; Thu, 9 Jun 2022 12:30:34 +0000 (UTC) (envelope-from fbsdouille@free.fr) Received: from zimbra22-e3.priv.proxad.net (unknown [172.20.243.172]) by smtp4-g21.free.fr (Postfix) with ESMTP id 99C5919F4F3 for ; Thu, 9 Jun 2022 14:30:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1654777827; bh=haB9pujlHpPnM9/InPSpL5UA3HnFHLGk8iHWI0QkV8w=; h=Date:From:To:In-Reply-To:Subject:From; b=nMUkZxisygsOC1l3dZDhZe1gqp/ix5JVCnJylLggiYoCBod+izyFNeJ2eM7JddRya /s5m5CllPsRFdbK/EJjxeSqZZZoOmkUc4SiJIwzV/hYer8edfFIbR1bXtseNNgf2qM qpQHuYJ5GPZIxUuy8rAtbT6p1RMx4t0gn3xNEf7zNy6AD/oVBga5XN5FyH9zdb6TgI 28LFuRa4M+vJqc7I5AODjbGiSqJqQIX8Bib3yfpRLIvppsVqTbcJdB+WrY23eNmU88 RFc4vm38lCfTEI0pBQWcE6b+KhmXC12zfXbPWj0s2rQ3xWd3ShqsjBk1z1Jq3UelpL jRcBLB8ArXZZA== Date: Thu, 9 Jun 2022 14:30:27 +0200 (CEST) From: fbsdouille@free.fr To: freebsd-hackers@freebsd.org Message-ID: <2030441297.395752042.1654777827327.JavaMail.root@zimbra22-e3.priv.proxad.net> In-Reply-To: <2085930562.395710471.1654777169210.JavaMail.root@zimbra22-e3.priv.proxad.net> Subject: need information about unix pic . List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [176.159.147.2] X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Win)/7.2.0-GA2598) X-Authenticated-User: fbsdouille@free.fr X-Rspamd-Queue-Id: 4LJk2f0jCsz3L7h X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=nMUkZxis; dmarc=pass (policy=none) header.from=free.fr; spf=pass (mx1.freebsd.org: domain of fbsdouille@free.fr designates 212.27.42.4 as permitted sender) smtp.mailfrom=fbsdouille@free.fr X-Spamd-Result: default: False [-4.00 / 15.00]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[212.27.42.4:from]; FREEMAIL_FROM(0.00)[free.fr]; R_SPF_ALLOW(-0.20)[+ip4:212.27.42.4]; TO_DN_NONE(0.00)[]; HAS_WP_URI(0.00)[]; DKIM_TRACE(0.00)[free.fr:+]; DMARC_POLICY_ALLOW(-0.50)[free.fr,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[free.fr]; ASN(0.00)[asn:12322, ipnet:212.27.32.0/19, country:FR]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.27.42.4:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi guys, I come to you because I am looking for information about the Phil Foglio image made in 1976 ? I'm sure that old Unix veteran will be able to help me :) if you have explanations or anecdotes of this image you very very are welcome sources . https://minnie.tuhs.org/Seminars/Saving_Unix/ https://geekfault.org/wp-content/uploads/2010/05/4daemons.jpg From nobody Thu Jun 9 13:18:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2C303851104 for ; Thu, 9 Jun 2022 13:18:58 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJl6T31Y3z3h6d for ; Thu, 9 Jun 2022 13:18:57 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qt1-x832.google.com with SMTP id x18so14210549qtj.3 for ; Thu, 09 Jun 2022 06:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:message-id:date :cc:to; bh=Zn4v51AutZaobbET5M0A3Gu6GP9Ysb1qiCPb272a3GA=; b=cjeXNuXNPLmkBsptHtaC697x2HTdBJlLY8dyvkoA78u1bFVdkoAaAgr/q1/HxX/mRO 9+WoKqoLwrNmVA9Rw29krfFitRGlguqyRF7m4aeAwYyNht5hbGlanrKi3rug8jrgEX0D 2kLq+4NW9us6qKy26Q5nRrtfWCLd+bjV/FFT3jBca8zmTmYFIH3ixykjqa1YQVcnovEi pbjvRWCyqEXjAEquzDtaYYINCHAP5t2YD9JJQg3yUiGuywWxBICtxzA2jW2N/C4JYrPG jtr3V0DTKuT3Fe0a5fTI5MExcqkTMvbXnn4A0PLY1KTz3jOuw1NhaYNS1Acs1dXxa34v wanw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:cc:to; bh=Zn4v51AutZaobbET5M0A3Gu6GP9Ysb1qiCPb272a3GA=; b=6iybzgaE1TjGKCpvdu+IlSB1xp8cgm/++ypBsKYl838c4s+NGshmhAD5iZtw1RL9Fz 9fb2QtR+ML0cKEcuFdMExFQORzk1/ZqHYbgZKaO1OJUQYcH/5YJJ89/CyT5G5audv/7/ RGiTA+/Ff3Koz40MiVcTBzcjQfFwtsHL97YYi3ngzKk4NTa0kCPmhBnOVFpFgjCxpWY5 mXoeYYpK+QG+TbnQzER/oqTxlmYBAoAnV9ZVA3amgoO3aSFFJTw4ZMWI4Jod3Jz4+H/U L3dLuF5iNJYwtwKAEFHmNF/OlsuhdMmNC7hjopTQEcXnkXSR8Au6/wLsoY4ELWYWh6Pb FGLg== X-Gm-Message-State: AOAM532wbtEGQK0Q/cG1CUna2XJZtjNU6im3LVR67QfLY5Ae6iYdmrw4 f9REyJFfITO24VJ1EpsbmMS6e6puLseRQRJo X-Google-Smtp-Source: ABdhPJx5PMqKlJhsykl+4WSUMfeeSIzOy35MuWtltjLchgTUAHaAdxW8szIyS2YfMev9misPQQnDnA== X-Received: by 2002:ac8:5893:0:b0:304:c7d2:f8bd with SMTP id t19-20020ac85893000000b00304c7d2f8bdmr30971531qta.627.1654780730616; Thu, 09 Jun 2022 06:18:50 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id cc17-20020a05622a411100b00304ef50af9fsm7726687qtb.2.2022.06.09.06.18.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jun 2022 06:18:50 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C7CE2F61-B9B0-4842-AA79-B0C7D144AF36 Content-Transfer-Encoding: 7bit From: Bakul Shah List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: need information about unix pic . Message-Id: Date: Thu, 9 Jun 2022 06:18:46 -0700 Cc: freebsd-hackers@freebsd.org To: fbsdouille@free.fr X-Mailer: iPad Mail (19F77) X-Rspamd-Queue-Id: 4LJl6T31Y3z3h6d X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=cjeXNuXN; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::832 as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_NONE(0.00)[]; HAS_WP_URI(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[free.fr]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; FREEFALL_USER(0.00)[bakul]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[iitbombay.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::832:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-C7CE2F61-B9B0-4842-AA79-B0C7D144AF36 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jun 9, 2022, at 5:31 AM, fbsdouille@free.fr wrote: > =EF=BB=BFHi guys, >=20 > I come to you because I am looking for information about the Phil Foglio i= mage made in 1976 ? > I'm sure that old Unix veteran will be able to help me :)=20 > if you have explanations or anecdotes of this image you very very are wel= come >=20 >=20 >=20 > sources . > https://minnie.tuhs.org/Seminars/Saving_Unix/ > https://geekfault.org/wp-content/uploads/2010/05/4daemons.jpg Story here (link found in the first source!):=20 https://www.mckusick.com/beastie/shirts/usenix.html= --Apple-Mail-C7CE2F61-B9B0-4842-AA79-B0C7D144AF36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jun 9, 2022, at 5:31 AM, fbsdouille@free.fr wrote:
=EF=BB=BFHi guys,

I come to you because I am looking for information about the Ph= il Foglio image made in 1976 ?
I'm sure that old Unix vetera= n will be able to help me :)
if you have explanations or an= ecdotes of this image you very very  are welcome



sources .
https= ://minnie.tuhs.org/Seminars/Saving_Unix/
https://geekfault.o= rg/wp-content/uploads/2010/05/4daemons.jpg

=
Story here (link found in the first s= ource!): 
= --Apple-Mail-C7CE2F61-B9B0-4842-AA79-B0C7D144AF36-- From nobody Thu Jun 9 13:50:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C21A985575C for ; Thu, 9 Jun 2022 13:50:17 +0000 (UTC) (envelope-from fbsdouille@free.fr) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJlpc669pz3mLp for ; Thu, 9 Jun 2022 13:50:16 +0000 (UTC) (envelope-from fbsdouille@free.fr) Received: from zimbra22-e3.priv.proxad.net (unknown [172.20.243.172]) by smtp5-g21.free.fr (Postfix) with ESMTP id 07E825FFAD; Thu, 9 Jun 2022 15:50:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1654782609; bh=XN8ogz/FPstYBcEzA7ZFmMZCTeYszjZPQmrpJm2VjJw=; h=Date:From:To:Cc:In-Reply-To:Subject:From; b=DRhPqvjAyPEj8Q9pCtslRijA0NG8gQsGlEFBWlgSWrHvDtdT69TUgvWnvFocyFecP Pajb4I861TDOCvc4RXPW+UINYWqverci3nAtbioyrS+RNyVIRE3UenrrBJQFOCvX0Q Ve+CLLXMRIcarJMtWxMbfo0k7XjH8uLgK5sqbkKnRrhFSIi/H1OPiwgEA0F9LG/cyK cLzXYnc4y7MY+1nLB6//bnGNPrVzhJ2ptA96+WuO7qgbs7lpkF6CvFPj5lNmfzfudv hL4XYgGkko83K0lMuUBeDMwhtT93jGu95yvh57UdVgpo3gyLnupbek5uh0aeothAp2 kE7VV4MQZ2dNQ== Date: Thu, 9 Jun 2022 15:50:08 +0200 (CEST) From: fbsdouille@free.fr To: Bakul Shah Cc: freebsd-hackers@freebsd.org Message-ID: <927534145.396070553.1654782608840.JavaMail.root@zimbra22-e3.priv.proxad.net> In-Reply-To: Subject: Re: need information about unix pic . List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [176.159.147.2] X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Win)/7.2.0-GA2598) X-Authenticated-User: fbsdouille@free.fr X-Rspamd-Queue-Id: 4LJlpc669pz3mLp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=free.fr header.s=smtp-20201208 header.b=DRhPqvjA; dmarc=pass (policy=none) header.from=free.fr; spf=pass (mx1.freebsd.org: domain of fbsdouille@free.fr designates 2a01:e0c:1:1599::14 as permitted sender) smtp.mailfrom=fbsdouille@free.fr X-Spamd-Result: default: False [-3.96 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[free.fr:s=smtp-20201208]; HAS_XOIP(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[free.fr]; R_SPF_ALLOW(-0.20)[+ip6:2a01:e0c:1:1599::14]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[free.fr:+]; RCPT_COUNT_TWO(0.00)[2]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a01:e0c:1:1599::14:from]; DMARC_POLICY_ALLOW(-0.50)[free.fr,none]; MLMMJ_DEST(0.00)[freebsd-hackers]; NEURAL_HAM_SHORT(-0.96)[-0.962]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[free.fr]; ASN(0.00)[asn:12322, ipnet:2a01:e00::/26, country:FR]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N >Story here (link found in the first source!): > >https://www.mckusick.com/beastie/shirts/usenix.html hi again, Thanks for the link, I already know it. what I'm looking for exactly are the anecdotes hidden in the image the pipes ? the bucket ? deamon falls ? the manometer ? the shower ? the whistle ? thx ;) From nobody Thu Jun 9 14:32:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E17818333DD for ; Thu, 9 Jun 2022 14:32:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJmls3h3gz3rqs; Thu, 9 Jun 2022 14:32:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 259EWt8Z036359 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Jun 2022 07:32:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 259EWtmO036358; Thu, 9 Jun 2022 07:32:55 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Jun 2022 07:32:55 -0700 From: Steve Kargl To: Baptiste Daroussin Cc: freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> X-Rspamd-Queue-Id: 4LJmls3h3gz3rqs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.40 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(0.12)[0.121]; NEURAL_HAM_SHORT(-0.52)[-0.517]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: > On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: > > All, > > > > mandoc and mdoc(7) are a convenient system for writing > > documentation, but it has a drawback. The volume > > title is hardcoded to a FreeBSD manual page. For my > > personal projects, I would like to change the volume > > title. For example. > > > > % mandoc tier.1 | head -1 > > TIER(1) FreeBSD General Commands Manual TIER(1) > > > > I have hacked up mandoc to accept a -V option, which allows e.g., > > > > % mandoc -V "Steve's Menagerie" tier.1 | head -1 > > TIER(1) Steve's Menagerie TIER(1) > > > > I have created a bug report and attached the diff to it > > if anyone is interested. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264560 > > Hello Steve, > > Regarding mandoc, I would like to keep it with as little custom patches > as possible, regarding your patch, it sounds like a useful feature, have > you considered talking directly to upstream about it to see if they are > willing to integrate it directly? > > https://mandoc.bsd.lv/contact.html ? > > They are friendly and usually reactive. > I was pointed to upstream in the bug report. While a -V option would work for me with single files, I think adding a .Vl macro would be better. The top of a file would look like .Vl Volume Title .Dd June 8, 2022 .Dt TIER 1 This would allow a specific volume title on each file such as % mandoc -T pdf manual.1 appendx.1 > manaul.pdf MANUAL(1) Project X Tech Specs MANUAL(1) ... APPENDEX(1) Support Library APPENDIX(1) I'll try talking to upstream. -- Steve From nobody Thu Jun 9 15:29:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8E35683A0CE for ; Thu, 9 Jun 2022 15:29:14 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJp0n53fDz4SHP; Thu, 9 Jun 2022 15:29:13 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 623471605A; Thu, 9 Jun 2022 17:29:06 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id DCBE989B7A; Thu, 9 Jun 2022 17:29:04 +0200 (CEST) Date: Thu, 09 Jun 2022 17:29:04 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Steve Kargl Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: <20220609152904.gc9ue%steffen@sdaoden.eu> In-Reply-To: References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> User-Agent: s-nail v14.9.24-254-g443e374be3 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4LJp0n53fDz4SHP X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-0.78 / 15.00]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.52)[0.518]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Steve Kargl wrote in : |On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: |> On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: ... |>> mandoc and mdoc(7) are a convenient system for writing |>> documentation, but it has a drawback. The volume |>> title is hardcoded to a FreeBSD manual page. For my |>> personal projects, I would like to change the volume |>> title. For example. |>> |>> % mandoc tier.1 | head -1 |>> TIER(1) FreeBSD General Commands Manual TIER(1) |>> |>> I have hacked up mandoc to accept a -V option, which allows e.g., |>> |>> % mandoc -V "Steve's Menagerie" tier.1 | head -1 |>> TIER(1) Steve's Menagerie TIER(1) Note .Dt has optional parameters. And mandoc honours the third parameter for this purpose. (Of course it extends the general thing, as in .Dt \*(XX 8 several_upstreams_exist ending up as S-POSTGRAY(8) System Manager's Manual (several_upstreams_exist) S-POSTGRAY(8) ) but that it is! If i were you i would simply assign something to the string volume-ds-8, as early as possible in the document (before the mdoc(7) preamble), as in: .Dd June 7, 2022 .\" .. .ds volume-ds-8 in_fear_of_fear . .Dt \*(XX 8 several_upstreams_exist .Os .Mx -enable This then gives S-POSTGRAY(8) BSD in_fear_of_fear S-POSTGRAY(8) for regular *roff upstreams, unfortunately not for mandoc which cooks its own soup, so to say. But that still handles the optional argument. That is to say, your "regular upstream" should simply honour the strings in the regular BSD mdoc package instead, then assigning values to those strings would do the right thing (tm). Ciao. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Jun 9 16:39:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE0B0841A30 for ; Thu, 9 Jun 2022 16:39:13 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJqYW5m83z4ZPG; Thu, 9 Jun 2022 16:39:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 259GdAjE036743 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Jun 2022 09:39:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 259Gd9a9036742; Thu, 9 Jun 2022 09:39:09 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Jun 2022 09:39:09 -0700 From: Steve Kargl To: Steffen Nurpmeso Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220609152904.gc9ue%steffen@sdaoden.eu> X-Rspamd-Queue-Id: 4LJqYW5m83z4ZPG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.74 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-0.91)[-0.910]; NEURAL_SPAM_MEDIUM(0.97)[0.970]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.80)[-0.799]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 09, 2022 at 05:29:04PM +0200, Steffen Nurpmeso wrote: > Steve Kargl wrote in > : > |On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: > |> On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: > ... > |>> mandoc and mdoc(7) are a convenient system for writing > |>> documentation, but it has a drawback. The volume > |>> title is hardcoded to a FreeBSD manual page. For my > |>> personal projects, I would like to change the volume > |>> title. For example. > |>> > |>> % mandoc tier.1 | head -1 > |>> TIER(1) FreeBSD General Commands Manual TIER(1) > |>> > |>> I have hacked up mandoc to accept a -V option, which allows e.g., > |>> > |>> % mandoc -V "Steve's Menagerie" tier.1 | head -1 > |>> TIER(1) Steve's Menagerie TIER(1) > > Note .Dt has optional parameters. > And mandoc honours the third parameter for this purpose. > (Of course it extends the general thing, as in > > .Dt \*(XX 8 several_upstreams_exist > > ending up as > > S-POSTGRAY(8) System Manager's Manual (several_upstreams_exist) S-POSTGRAY(8) So, I changed my local manpage to Dd June 8, 2022 .Dt TDI \*(XX 1 "Steve's Menagerie" .Sh NAME On FreeBSD, it produces TDI(1) FreeBSD General Commands Manual (steve's menagerie) TDI(1) That is not what I'm after. First, I want to completely replace the "FreeBSD General ..." volume title. Second, the optional third parameter is in lower case. If mdoc had a .Vl macro, I could do .Vl Steve's Menagerie .Dd June 8, 2022 .Dt TDI \*(XX 1 "Steve's Menagerie" .Sh NAME TDI(1) Steve's Menagerie TDI(1) > > ) but that it is! If i were you i would simply assign something > to the string volume-ds-8, as early as possible in the document > (before the mdoc(7) preamble), as in: > > .Dd June 7, 2022 > .\" .. > .ds volume-ds-8 in_fear_of_fear > . > .Dt \*(XX 8 several_upstreams_exist > .Os > .Mx -enable > > This then gives > > S-POSTGRAY(8) BSD in_fear_of_fear S-POSTGRAY(8) Where does the BSD come from? Seems a bit odd to randomly appear. -- Steve From nobody Thu Jun 9 16:55:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7551E843BE2 for ; Thu, 9 Jun 2022 16:55:42 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJqwY2qbgz4cBZ; Thu, 9 Jun 2022 16:55:41 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 220681605A; Thu, 9 Jun 2022 18:55:39 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id EB5478A753; Thu, 9 Jun 2022 18:55:36 +0200 (CEST) Date: Thu, 09 Jun 2022 18:55:36 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Steve Kargl Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: <20220609165536.A5vGK%steffen@sdaoden.eu> In-Reply-To: References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> User-Agent: s-nail v14.9.24-254-g443e374be3 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4LJqwY2qbgz4cBZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-0.68 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+a:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(0.38)[0.376]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.75)[-0.753]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Steve Kargl wrote in : |On Thu, Jun 09, 2022 at 05:29:04PM +0200, Steffen Nurpmeso wrote: |> Steve Kargl wrote in |> : |>|On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: |>|> On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: |> ... |>|>> mandoc and mdoc(7) are a convenient system for writing |>|>> documentation, but it has a drawback. The volume |>|>> title is hardcoded to a FreeBSD manual page. For my |>|>> personal projects, I would like to change the volume |>|>> title. For example. |>|>> |>|>> % mandoc tier.1 | head -1 |>|>> TIER(1) FreeBSD General Commands Manual TIER(1) |>|>> |>|>> I have hacked up mandoc to accept a -V option, which allows e.g., |>|>> |>|>> % mandoc -V "Steve's Menagerie" tier.1 | head -1 |>|>> TIER(1) Steve's Menagerie TIER(1) |> |> Note .Dt has optional parameters. ... |So, I changed my local manpage to | |Dd June 8, 2022 |.Dt TDI \*(XX 1 "Steve's Menagerie" |.Sh NAME | |On FreeBSD, it produces | |TDI(1) FreeBSD General Commands Manual (steve's menagerie) \ | TDI(1) | |That is not what I'm after. First, I want to completely replace the |"FreeBSD General ..." volume title. Second, the optional third |parameter is in lower case. | |If mdoc had a .Vl macro, I could do | |.Vl Steve's Menagerie |.Dd June 8, 2022 |.Dt TDI \*(XX 1 "Steve's Menagerie" |.Sh NAME | |TDI(1) Steve's Menagerie TDI(1) | |> ) but that it is! If i were you i would simply assign something |> to the string volume-ds-8, as early as possible in the document |> (before the mdoc(7) preamble), as in: ... |> S-POSTGRAY(8) BSD in_fear_of_fear S-POSTGRAY(8) | |Where does the BSD come from? Seems a bit odd to randomly appear. These are all strings from the doc-common mdoc(7) (g)roff file which are then picked up by mdoc(7) as required by the context. (g)roff can give you what you want like this: .ds volume-operating-system steve .ds volume-ds-8 kargl (before the [.Dd,].Dt,.Os preamble), and i get then S-POSTGRAY(8) steve kargl S-POSTGRAY(8) Ingo Schwarze just currently has a run on mandoc in the OpenBSD source tree since a couple of days, maybe if a FreeBSD folk would point him to doc-common strings (or at least the volume-ds-* ones), you would be fine out with the next release of mandoc. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Jun 9 19:31:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 571F7839458 for ; Thu, 9 Jun 2022 19:31:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJvNM4Gj8z3Fh9 for ; Thu, 9 Jun 2022 19:31:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654803083; bh=pgJpOaX472g0po3mNcmPLa2H7unr3UfW+y5JaS+vfn4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DLnZwx9BkC59VCfdU662D/mZsGtiyhM4ey4NQhi8QxbldFJzPGm29SrL6XyWDabeQBWjcucS6bU6SdvaVYqJ9iljAlmywAQ/Cq4h3c32l+hvWtdW/w4orDRdWA+k0WGZ+9C26YE4anFsHTyPKRBScrrXdzFsyoslsSKy2UQMExBKjA5z3wZcXs7audKU5Yh25Hldqfvi2cF3m41J6wP9C/s5GxUnua4w1vh1g3r2o9Ky6082fP1vTGmVqrRg+iLZWo5nhftQLOF3sC8ChAM/InH8FTnaqP4pbJWVcm+02hUXNm7NW1EMwSDZHxanCJcyPspuC5vFwvhucJ80xlOO1A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654803083; bh=SSme2vaguQ/OesCJpcrQdWwSuUPHLT08vdebA0QD11v=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YpcqXqFuv2taGoxJ11WfkA4BoAPj+jH8GgT4Nzn9C7yW/jIuWDoqW8zouWK7ywlrjTMmm5Qd8My13DMv7pXH4VYb/JS5zvf5SKqG4Vf4ILrmCPbm9J/xV2H0eCiXoMFJ2CZR9T2ril0lBbOF2DouS2JPDvRBgvVzF9OONIDqzUXMt4RaE/UZCkDSP8J20GBrsq2EmhArWxOM80gA3aj4ctK+NCm/3KjGrN6A/1PTnTndHmNwuz/7Z589CW2c5uhofwFOhTITQKwguC7i85co1iKJrbumEDgGJLnsj/A/QFULcgW2NSfsbIAFTfmyJIev5hJHHNTjlfrYOymIP0MEVA== X-YMail-OSG: __GZzdIVM1kewT9988RI6UhW0IAmv0cnH6c_ax3WYPm5gyOV2licXGOEHkV0vz4 ROb1JVrEGS4AC8j5NQ_RNN6lGENP2o4lrW9oRQdDng5NzO54_noHoGsvY0ImKp9BNNg5a_T6DRMz MBO8gfu7Y9PX2o2IqzoctgiVaq3SLzarIJ7un8Wmbb1T2yVDTKD9lkdePclzRnZ2K.EMqpiliAq8 aqKAJfhMrsBYZVMLSgxm0I8hN_MHZ7zNr6pO3EfY_F6K65ZSHk28.ofN9Ya715F_W5latCA4Dgft uw.rNy6TDV1PSUJjzj2kQzgTW.xKFQEKCCpNXsD1YA4wqwld4nMY6L2j3rBsXI35Xfvf7w4dLGBM zDlN2WXhX92i17TzwjT17D8UVZwzAVui5g1LSzcng1CrwVSfGEgcIu1UxbgQzJxvPSzfOf2MA_Iy 55e.SoSeXtLg34BYbE0WIgGpd8HxOqHL5WjAgy5e3KYaBmWYiNavDct09aYn71lC.1LEuJojZbV1 Vutdq73_uJQJQlIm4DBexfS3ABVMReNM308H.GLYIWZM9QLDmJ1cimD0F_aedQgf80GcVqrXSW.k sqvI6fF1w70UPPh8wdJqOuNLSsA3NSxisEVGUfsgqjiwwh0YNLTyBVVve89j41PQvBoHqxfYC4P4 D9NArJWqNWIvlU8M9T8W_c63OgZl8JS_9H.D1jwheNLlAtl71hq4Kfp5G3UjpipwVsPBADnamDlG eyYUvaghYhQMoQILhpn0zTZX8xauVODRFPQVegKWO3TkSthq3YuQ5qIWELwxX7FpeOCVUaXew0IF LhY5FsM3Kdo4p.P2Zn7uFfm973rP9q4JANE8QfVGCJomF3hDmAvRlv6UyvDKFXKaUeNQcv06C6fq U.j6Y92Ww9_AwJP7yFCPnvhqD7cz0IVlnXFohy.pU4s1hbCkG.K1HECO_BOlEYme3zVi5Z.N9Pu5 UB9TRCL0_wfkXCvmb7Tf4D97BUnmiAI9L6t4ymcHRAV4T54_ET6Ln1ivYtFWA9oYFZR._LtWDcDA GF2KjkoqS.hiOA5U00h6fIItn5XfJAcO4WEDwOrLDrE6Hn5DMqTotNn0tNFWuGbMhBBN0i2oqkAp hC7AfmBOkvmcDToILbTYmSM0SPsJsnpGztok_w0kHlYUnWjnncN8mlr4cO0gi8aOoV5i77xoLZVi Hl4iloMywszVw0oDCLYaUWKY0UEWdF8woM.f6J9w_Dpz_qwOTtmyf_v3dRC5YeQxk0Z.YLF51e_8 zgy8LH.wqYCAwieRPBRZFakVqHAwXovudIxa78on7Je3yEnawQf3VuEsy8AcuceDlN_i7ihA2A2b QZ6taeFlPM0iTelSmfV.T1WGE4yz_hTeyQv7uVyl_.02pdMHbe8ZzwQFbMOtw2Fw9NuN2qb2aFck qLIzavf1NiRCLd1_bjBFV_FXNwoVL7k3PDQXBBGYzaRsPJJYvtVWdt6w.pGo0NudhJ_ROWVDAktQ .QwNx0NHXK.wQ4JzHd6wExlsfUh87Jmwrk1dKdgVRuGvw8cY_q_M39puqUYtc5ufacdD61EquxeY SynoRfJK17e07QsRH9hOVymV.7cqH..LhZsWMrGveYARFXxsARHLx4tTkYKNeEsaubQYM3QvZ53r JJ2.8..t64NUtFgQoWAOcgnpOpKBK3GR_1FiFmbIAYRaLje_Nc.Kj0dIESB6.gTgPGAJ8a6Vywlu 3oy5ZfBPAwqKbFfCA0D3m6lhQwuy7qVvFm_pfeDS0Vvgds7P6ADu7tTt6uytHt15sKGKwamWES7N 2adpGEmueTiDBnOSXCVGDueDF6vTxIVPh0rGMofa8DiS_XwbbXFCUzVYFuYUdSBL.yw.5fU.x.Qe 4sU7iOZYq.0CDwFGpkyXuq5LN2k9LkBb_huXJQcw6ijVwBnfgbY3vLBfZBzq_C4hNzhcHSPJYTty 5DescL46iP.JfNOP61ToFEef6VvzAzyFmwAxHPknt61.z9Nk7vXs.kxPx3ieD9EPTi0npbHWjj15 wojgx_2fxy.6aFD4mZ0KdSyClF6m3gbm_jaMI.WgqplNw_n.j5_0DQwBleoD38HpCkPCSH_1lAf3 AkUrGyF3JurzqqrYK9UcAjrS7t64UZjdfnxbbRlRr_OWIBW6v8RChhA7u9y4_CYqRgD9C_4VIvkv EWhe6.Bv7xT7rlo.v7n2y__Q4uskvcp6gKgOtXrORp4kRLwNuDyOQUtmcLDwc3CmOQGfyeQVTqkV .D15jtopw4pR3zJhgBEzjoxWmRE89EqdRyieSq8YIvEycPlAQlRtlQ.9YKxQC2iJHWxX41L1vJBf GegQuzk2vxQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 9 Jun 2022 19:31:23 +0000 Received: by hermes--canary-production-bf1-856dbf94db-4lmbr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9626a9373ab1fa87731cd0d083b11cd7; Thu, 09 Jun 2022 19:31:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? From: Mark Millard In-Reply-To: <82ffa6bb-5826-62b6-2b82-a735b183272f@grosbein.net> Date: Thu, 9 Jun 2022 12:31:17 -0700 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2F1A9EE0-FB9E-4BBF-AF76-4E5AD372FCC1@yahoo.com> References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> <82ffa6bb-5826-62b6-2b82-a735b183272f@grosbein.net> To: Eugene Grosbein X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LJvNM4Gj8z3Fh9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=DLnZwx9B; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.49 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.83:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-9, at 03:45, Eugene Grosbein wrote: > 09.06.2022 2:54, Mark Millard wrote: >=20 >> Why 403 vs. 101 ? >=20 > lsof +aL1 $mountpoint >=20 Thanks for the explicit alternative to explore. It turns out that the result is a list of all FIFO types: # lsof +aL1 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ = | more lsof: WARNING: access /usr/home/root/.lsof_CA72_UFS: No such file or = directory lsof: WARNING: created device cache file: /usr/home/root/.lsof_CA72_UFS COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK = NODE NAME sh 187 root 6u FIFO 4294967295,2264989460 0 0 = 609904 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p = (tmpfs) sh 2447 root 6u FIFO 4294967295,2264989460 0 0 = 609904 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p = (tmpfs) . . . sh 96552 root 6u FIFO 4294967295,2264989460 0 0 = 609904 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p = (tmpfs) sh 98284 root 6u FIFO 4294967295,2264989460 0 0 = 609904 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p = (tmpfs) But there is still the likes of 402 (df) vs 101 (du): # df -m /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p Filesystem 1M-blocks Used Avail Capacity Mounted on tmpfs 1024 402 621 39% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ So I'm still looking to figure out what leads to the about factor of 4 between the df and du results. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Jun 9 21:13:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 27DBB852BD1 for ; Thu, 9 Jun 2022 21:13:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJxfN1hPcz3r81; Thu, 9 Jun 2022 21:13:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 259LDfTS037627 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Jun 2022 14:13:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 259LDebo037626; Thu, 9 Jun 2022 14:13:40 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Jun 2022 14:13:40 -0700 From: Steve Kargl To: Steffen Nurpmeso Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> <20220609165536.A5vGK%steffen@sdaoden.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220609165536.A5vGK%steffen@sdaoden.eu> X-Rspamd-Queue-Id: 4LJxfN1hPcz3r81 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.70 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.926]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.43)[-0.430]; NEURAL_SPAM_SHORT(0.66)[0.661]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 09, 2022 at 06:55:36PM +0200, Steffen Nurpmeso wrote: > Steve Kargl wrote in > : > |On Thu, Jun 09, 2022 at 05:29:04PM +0200, Steffen Nurpmeso wrote: > |> Steve Kargl wrote in > |> : > |>|On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: > |>|> On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: > |> ... > |>|>> mandoc and mdoc(7) are a convenient system for writing > |>|>> documentation, but it has a drawback. The volume > |>|>> title is hardcoded to a FreeBSD manual page. For my > |>|>> personal projects, I would like to change the volume > |>|>> title. For example. > |>|>> > |>|>> % mandoc tier.1 | head -1 > |>|>> TIER(1) FreeBSD General Commands Manual TIER(1) > |>|>> > |>|>> I have hacked up mandoc to accept a -V option, which allows e.g., > |>|>> > |>|>> % mandoc -V "Steve's Menagerie" tier.1 | head -1 > |>|>> TIER(1) Steve's Menagerie TIER(1) > |> > |> Note .Dt has optional parameters. > ... > |So, I changed my local manpage to > | > |Dd June 8, 2022 > |.Dt TDI \*(XX 1 "Steve's Menagerie" > |.Sh NAME > | > |On FreeBSD, it produces > | > |TDI(1) FreeBSD General Commands Manual (steve's menagerie) \ > | TDI(1) > | > |That is not what I'm after. First, I want to completely replace the > |"FreeBSD General ..." volume title. Second, the optional third > |parameter is in lower case. > | > |If mdoc had a .Vl macro, I could do > | > |.Vl Steve's Menagerie > |.Dd June 8, 2022 > |.Dt TDI \*(XX 1 "Steve's Menagerie" > |.Sh NAME > | > |TDI(1) Steve's Menagerie TDI(1) > | > |> ) but that it is! If i were you i would simply assign something > |> to the string volume-ds-8, as early as possible in the document > |> (before the mdoc(7) preamble), as in: > ... > |> S-POSTGRAY(8) BSD in_fear_of_fear S-POSTGRAY(8) > | > |Where does the BSD come from? Seems a bit odd to randomly appear. > > These are all strings from the doc-common mdoc(7) (g)roff file > which are then picked up by mdoc(7) as required by the context. > (g)roff can give you what you want like this: > > .ds volume-operating-system steve > .ds volume-ds-8 kargl > > (before the [.Dd,].Dt,.Os preamble), and i get then > > S-POSTGRAY(8) steve kargl S-POSTGRAY(8) > > Ingo Schwarze just currently has a run on mandoc in the OpenBSD > source tree since a couple of days, maybe if a FreeBSD folk would > point him to doc-common strings (or at least the volume-ds-* > ones), you would be fine out with the next release of mandoc. > The first 6 lives of my file are .ds volume-operating-system steve .ds volume-ds-8 kargl .Dd June 8, 2022 .Dt TDI 1 .Sh NAME .Nm tdi % mandoc tdi.1 | head -1 TDI(1) FreeBSD General Commands Manual TDI(1) I cannot find mention of .ds in mandoc(1) nor mdoc(7) man pages. Depending groff documentation, which might not be installed as it is a port, seems to be a bit dubious. % groff -T ascii -mdoc tdi.1 | head -1 TDI(1) FreeBSD General Commands Manual TDI(1) It appears to no work? -- Steve From nobody Thu Jun 9 21:41:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4FAFD8568DB for ; Thu, 9 Jun 2022 21:42:05 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJyH02qnZz3vH4; Thu, 9 Jun 2022 21:42:04 +0000 (UTC) (envelope-from sysadmin.lists@mailfence.com) Received: from ichabod.co-bxl (ichabod.co-bxl [10.2.0.36]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 4770D1ED8; Thu, 9 Jun 2022 23:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1654810916; s=20210208-e7xh; d=mailfence.com; i=sysadmin.lists@mailfence.com; h=Date:From:Message-ID:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Cc; l=3158; bh=ESTTd+ziwekVsSkzRWPPzNWFYTPrM8O7rWmxAB4wkx0=; b=lrXRHSmtXaHfTrP77/P+idaMpjm+lMKVSg+cxsAHQYZdz//PE7AeHZq3G1w/1Ozq mT7i6LADcT364Q1/q1sJexK+xAd9EfOrFyYiQ8QLEa/9QL7qRVeXi7Fayws7U7I2DVV 2WMEMeZyC50Ui6QSwgCmeJ1V0cgl9R5zLzBf3KS+WUWfJYd2mIcmF0SGtfrVyhnsrX3 0V6J5vbUUZbGcw/dZSBRjGHlDnwPahqT1RazlO0cR9/E7KQp51ThA1jWxjCljtz67nQ I6JuY085bB8RiwWaBvVJO8HiSoINj5BEL+mpN5tC5ZCZtyTsvzsuT4xYNU7PSN3Jzas RGz87emm3A== Date: Thu, 9 Jun 2022 23:41:53 +0200 (CEST) From: Sysadmin Lists To: freebsd-hackers@freebsd.org Message-ID: <1550558622.134608.1654810913427@ichabod.co-bxl> In-Reply-To: <9b3dbdddb02e65c5ff4b3dc0f117c3c6@neelc.org> References: <9b3dbdddb02e65c5ff4b3dc0f117c3c6@neelc.org> Subject: Re: Potential USB bug with read() (while updating android-tools-adb) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Neel Chauhan X-Mailer: ContactOffice Mail X-ContactOffice-Account: com:312482426 X-Rspamd-Queue-Id: 4LJyH02qnZz3vH4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=fail ("body hash did not verify") header.d=mailfence.com header.s=20210208-e7xh header.b=lrXRHSmt; dmarc=pass (policy=quarantine) header.from=mailfence.com; spf=pass (mx1.freebsd.org: domain of sysadmin.lists@mailfence.com designates 212.3.242.97 as permitted sender) smtp.mailfrom=sysadmin.lists@mailfence.com X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.3.242.64/26]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_REJECT(0.00)[mailfence.com:s=20210208-e7xh]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[mailfence.com:-]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[mailfence.com,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:10753, ipnet:212.3.242.64/26, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_LOW(-0.10)[212.3.242.97:from] X-ThisMailContainsUnwantedMimeParts: N > ---------------------------------------- > From: Neel Chauhan > Sent: Thu Jun 09 05:21:48 CEST 2022 > To: > Subject: Potential USB bug with read() (while updating android-tools-adb) > > > Hi hackers@, > > While attempting to update android-tools-(fastboot/adb) to a newer > version, I noticed a potential bug with the FreeBSD USB subsystem. > > After two reads from a particular function in a USB device, read() reads > 0 bytes even with it should read 8 bytes and returns 0 respectively > instead of 8. > > The branch is: > https://github.com/neelchauhan/freebsd-android-tools/tree/fbsd-31.0.3p1 > > The offending lines are: > vendor/adb/client/commandline.cpp:928 (ReadFdExactly call) > vendor/adb/adb_io.cpp:83 (adb_read call) > vendor/adb/sysdeps.h:526 (adb_read definition, this calls read()) > > This happens when I attempt to flash LineageOS 19.1 (Android Custom ROM) > to a Google Pixel 3 smartphone via the so-called "recovery", which is > the "test" device used to test if this port works (my main device, a > Google Pixel 6 Pro while rooted can't be used since I'm not willing to > live without a phone). > > On Android, recoveries are used to update, root, or replace an Android > installation. The `adb sideload` in the recovery causes read() to fail > prematurely, whereas `adb push` in a recovery works perfectly. > > However, LineageOS requires the "sideload" function to install on many > devices, and I don't want a broken port in the Ports tree either. > > On FreeBSD, this exact adb_read() routine works fine on other `adb` > calls. On Linux (or macOS when I had a M1 Mac Mini before donating it to > kevans@), `adb sideload` works perfectly, period. > > I doubt most of you are rooted Android users, so if you need help > understanding how Android flashing works feel free to ping me, I'm no > "expert" either but have been doing this for 8+ years. > > This error also happens with the Ports version, which is why I initially > wanted to update. > > Is there anything FreeBSD does in its USB implementation that's funky, > or even in libusb? Especially in the last 2-3 year? Or is it more adb > issues. > > I am using an AMD Ryzen 5800X-based HP Omen 30L running FreeBSD > 14.0-CURRENT with Git revision 0817c8dc2a4 (May 14), but this also > happens on other Intel-based and AMD-based systems, with both USB-A and > USB-C Ports. > > I'm not *really* a kernel person, and not at all a USB hacker. I'll > probably update my CURRENT but this issue has been happening for 2 or so > years now and rebooting into Linux USBs isn't exactly fun to flash my > Android. > > -Neel (nc@) > I don't know if this adds a useful datapoint, but devel/android-tools-adb has been broken for "adb push" on some devices for awhile. The device disconnects immediately on any files larger than 0B (empty file). The solution posted online was to downgrade the ports tree to the version that still worked (dated Dec 11, 2017 IIRC). So, it's been broken on FreeBSD for awhile. -- Sent with https://mailfence.com Secure and private email From nobody Thu Jun 9 21:49:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E18B1857B15 for ; Thu, 9 Jun 2022 21:49:11 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJyRB4rc5z3wHT; Thu, 9 Jun 2022 21:49:10 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 86B701605A; Thu, 9 Jun 2022 23:49:08 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 74B228AB09; Thu, 9 Jun 2022 23:49:06 +0200 (CEST) Date: Thu, 09 Jun 2022 23:49:06 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Steve Kargl Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: <20220609214906.6--d0%steffen@sdaoden.eu> In-Reply-To: References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> <20220609165536.A5vGK%steffen@sdaoden.eu> User-Agent: s-nail v14.9.24-254-g443e374be3 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4LJyRB4rc5z3wHT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-1.86 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.56)[-0.563]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Steve Kargl wrote in : |On Thu, Jun 09, 2022 at 06:55:36PM +0200, Steffen Nurpmeso wrote: |> Steve Kargl wrote in |> : |>|On Thu, Jun 09, 2022 at 05:29:04PM +0200, Steffen Nurpmeso wrote: |>|> Steve Kargl wrote in |>|> : |>|>|On Thu, Jun 09, 2022 at 09:17:02AM +0200, Baptiste Daroussin wrote: |>|>|> On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: ... |> These are all strings from the doc-common mdoc(7) (g)roff file |> which are then picked up by mdoc(7) as required by the context. |> (g)roff can give you what you want like this: |> |> .ds volume-operating-system steve |> .ds volume-ds-8 kargl |> |> (before the [.Dd,].Dt,.Os preamble), and i get then |> |> S-POSTGRAY(8) steve kargl S-POSTGRAY(8) |> |> Ingo Schwarze just currently has a run on mandoc in the OpenBSD |> source tree since a couple of days, maybe if a FreeBSD folk would |> point him to doc-common strings (or at least the volume-ds-* |> ones), you would be fine out with the next release of mandoc. | |The first 6 lives of my file are | |.ds volume-operating-system steve |.ds volume-ds-8 kargl If you use ".Dt TDI 1", you must set volume-ds-1. |.Dd June 8, 2022 |.Dt TDI 1 |.Sh NAME |.Nm tdi | |% mandoc tdi.1 | head -1 This is mandoc Mr. Kargl. mandoc parses man(7) and mdoc(7) documents into a tree of what it knows, and then interprets it so that it matches what roff would generate. (On the terminal; after way over a decade of work it "can" other formats much better than roff.) There was a time when Ingo Schwarze as mandoc maintainer posted mails stating how many percent (to the tenths iirc) of all OpenBSD manuals come out equal. But it still is not at hundred percent. ... |I cannot find mention of .ds in mandoc(1) nor mdoc(7) man pages. Because it is a scut. Not a roff interpreter. (Having said that: it is also a good thing, as it is very fast and can some things good; but it is not a roff interpreter, which as a Unix lover makes me sad.) But i _think_ at least rudimentary .ds support comes with the next release, i seem to recall to have read something about .ds. |Depending groff documentation, which might not be installed as it |is a port, seems to be a bit dubious. Quite vice versa. mdoc is thirty years old, and could be implemented because roff that is even older is such a powerful system. |% groff -T ascii -mdoc tdi.1 | head -1 |TDI(1) FreeBSD General Commands Manual \ | TDI(1) | |It appears to no work? Now that is overly interesting! Yes. Long story short (i _hate_ the way groff is maintained). Please use a doc- prefix for your pleasure: #?0|kent:$ cat steve.4 .Dd June 8, 2022 .ds doc-volume-operating-system Steve .ds doc-volume-ds-4 Kargl .Dt TDI 4 .Sh NAME .Nm tdi Hi. #?0|kent:nail.git$ groff -mdoc -Tutf8 steve.4 TDI(4) Steve Kargl TDI(4) NAME tdi Hi. June 8, 2022 --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Thu Jun 9 22:33:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2AE9F835DD6 for ; Thu, 9 Jun 2022 22:34:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LJzQt75XMz4Wdf; Thu, 9 Jun 2022 22:33:58 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 259MXv7I037963 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 9 Jun 2022 15:33:57 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 259MXu9c037962; Thu, 9 Jun 2022 15:33:56 -0700 (PDT) (envelope-from sgk) Date: Thu, 9 Jun 2022 15:33:56 -0700 From: Steve Kargl To: Steffen Nurpmeso Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> <20220609165536.A5vGK%steffen@sdaoden.eu> <20220609214906.6--d0%steffen@sdaoden.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220609214906.6--d0%steffen@sdaoden.eu> X-Rspamd-Queue-Id: 4LJzQt75XMz4Wdf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.24 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.92)[-0.922]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.44)[-0.439]; NEURAL_SPAM_SHORT(0.12)[0.118]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 09, 2022 at 11:49:06PM +0200, Steffen Nurpmeso wrote: > Steve Kargl wrote in > | > |The first 6 lives of my file are > | > |.ds volume-operating-system steve > |.ds volume-ds-8 kargl > > If you use ".Dt TDI 1", you must set volume-ds-1. > > |.Dd June 8, 2022 > |.Dt TDI 1 > |.Sh NAME > |.Nm tdi > | > |% mandoc tdi.1 | head -1 > > This is mandoc Mr. Kargl. Well, yes, that's what I've been talking about. The .ds stuff you mention is not documented in mandoc(1) nor the mdoc(7) manpages. Adding .ds doc-volume-operating-system Steve .ds doc-volume-ds-4 Kargl to a file does not override the volume title when using mandoc. % cat steve.4 .Dd June 8, 2022 .ds doc-volume-operating-system Steve .ds doc-volume-ds-4 Kargl .Dt TDI 4 .Sh NAME .Nm tdi Hi. % mandoc steve.4 TDI(4) FreeBSD Kernel Interfaces Manual TDI(4) NAME tdi Hi. June 8, 2022 I gave mandoc a -V option to do the override. % mandoc -V "Steve Kargl" steve.4 TDI(4) Steve Kargl TDI(4) NAME tdi Hi. June 8, 2022 Having to install groff and adding undocumented .ds magic isn't the solution for a FreeBSD base system functionality. In fact, I think it would be better to have the mdoc(7) package grow a .Vl macro to allow the volume title to be easily overridden. -- Steve From nobody Fri Jun 10 02:48:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3B8C48348D8; Fri, 10 Jun 2022 02:48:47 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LK54t1rSmz3k8X; Fri, 10 Jun 2022 02:48:46 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id t25so40732453lfg.7; Thu, 09 Jun 2022 19:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=VIGW8Q1Ig0/BJxtpkGQabx3p5IjYUsynPFpEvJKiT/8=; b=mJqDLJB+36POwEC+WhR2oh0dm1Vqrk3wNa4zLGTyuMU6cCC2ogQz4RYl2UwNnUl9rG jMiAiuPwsvT6LbAiVWMYZxmYF0nP0hBfshRtDHFFDRhuLq/KNMudY0kIiib1c23P/JsT PuI4Ybq/faPcp8pcD4Hucdad32vulqgOqRwKni+YCuU+Oq/o0WBc+RZJOyUTlsBsrjTJ SjSZPzARUnL59xi7eDdmukvCpw5bMKeTzIN5qQafs2Uyz9V37/jTilgkBziqbuj8NrsT +AIojOE+JguiuCUTW5DwflGe55IknX2AwB5Pno5eqSdKZWRdIoJUzUupW22biys3U4+O kNBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=VIGW8Q1Ig0/BJxtpkGQabx3p5IjYUsynPFpEvJKiT/8=; b=BucpiAkmJ/SbOJ95j9x0F4087WYHThcxGlxPIHZW5Qn9YkFd5gCYVDI3KJml2FCVHM ViEz4x2pvlF5/Ys0iESj91HmRcjxFu9teSaZs88MrEOcF7dvzz5G75DRB4vy7SSTL6Js n8aYWmAeJYRDY8RvB9QYVDryJXpMSe++NKQzhd7ZyU/oiq3/jyFltxnGWSFSI4+8p7+g WNYEf2Tl9OhZNm48dgX6uykJhcQJ89kinxjJT7D0OowTIJZW2nkWBkfCwHcZJJucO2Nf 8YowFsPm9M9XWL/bATNt+0Ot5k9grgN5qdbeNWYdDkgN47vazCrdr92TCGfrif2WU/oy OOqg== X-Gm-Message-State: AOAM530gh9u4bHMGfuPbWdi49jpK0liLgpdn+iJqAmrQZkwcil6Il7Pp w6LcmFfG6wtxxtnzvv/q2lGABVWWZic= X-Google-Smtp-Source: ABdhPJyoRBySw3WU+BW9+2SnRRZlSmdJHPP4KcP6gHvgf/rNNRAUlVweJcu9WZt7+7ZoGbV1y4fFAQ== X-Received: by 2002:ac2:5e76:0:b0:478:f72e:7531 with SMTP id a22-20020ac25e76000000b00478f72e7531mr32052774lfr.187.1654829322451; Thu, 09 Jun 2022 19:48:42 -0700 (PDT) Received: from rimwks.local ([2001:470:1f15:3d8:9554:7133:29d0:f593]) by smtp.gmail.com with ESMTPSA id j22-20020a056512109600b0047255d210e7sm4506747lfg.22.2022.06.09.19.48.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 19:48:41 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Fri, 10 Jun 2022 05:48:39 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Rozhuk Ivan Subject: exec(btxld) failed (No such file or directory) and obj via nullfs Message-ID: <20220610025556.2896c5fc@rimwks.local> X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LK54t1rSmz3k8X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mJqDLJB+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::12f as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12f:from]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! I found a way to fix error during install: exec(btxld) failed (No such file or directory) in case obj is nullfs mounted. Use option: -o nocache mount_nullfs -o rw -o nocache -o noatime "${MAKEOBJDIRPREFIX_TMP}" "${MAKEOBJDIRPREFIX}" This helps for me, hope it will be usfull for community. PS: this works even without https://reviews.freebsd.org/D23411 patch. I do not dig inside this and have no idea why this option undocumented. Probably this some kernel/nullfs bug that must be investigated, or just remove option and make it always enabled. From nobody Fri Jun 10 03:34:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C2EB83C0E4; Fri, 10 Jun 2022 03:34:51 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LK66252tpz3s7g; Fri, 10 Jun 2022 03:34:50 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm1-x335.google.com with SMTP id z17so8450377wmi.1; Thu, 09 Jun 2022 20:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:subject:message-id:mime-version; bh=maDiKSMR6Ns4OlvXx+ONmTL/nkRWb1DzTq+VV6jPmIM=; b=ieTqFmXF7hiZVJ/NycIdvLetvfXfsc52XaTdqer1EAYMw1S6e2w5x1CW5GwYOXEgdO Xs3+aKYzmwlAy2WNl80kstBzT62hkpWDb+ep5yVrFc1/ZlFw31VLAEBpsZktNWaD/3nr AK9cwI5w5dUaeOmHSU+4/PaIvmwzQa1FiAKWIyEDBJkYuL8Qn2rX1vW+91NxMVNUJrpU dq30oIuLO2EDzS1qEF5bVa1LS2w+RISh1w4WyafQHrurF1x36b7PA2+sDT7AjRwZh5DL /z2KMb8NQ3tVkqkMF/q3F4NSZWp7GUVFsjU+mTFSmoyJxYCrS4hsWRnPHxQSTYtvP4WI kQoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:subject:message-id:mime-version; bh=maDiKSMR6Ns4OlvXx+ONmTL/nkRWb1DzTq+VV6jPmIM=; b=8CO4rFhnWGTuoNpUbqJR8dfzoa/uUdRHducsfT3w0GqIsx7uMjtHj94vpRlcdtyTYU w9GerCFIb3+2Nb6DW6B7PpSxVLG1ziiskdwU3FWq3+qduLCubnnGH9WGZOhEPfBlS6BB 6pvQnhEBR/jjI0rSSKNU+8Fw4NglUUMT9BjafyuhBwPeGuwj8j4VC9KNsuRSi4QXjKXh zT12BDAzf4qx1QDjAQ49lZQGM8ZqHMpOx/uDmePXjfNJ/DFigwzzMmk/vJ488ZKG1qHr M+m72SEu1QQEZI6/vtoDc3t9qvgnJf1E9Fu3KDIkN/pofH2d9dyZCqXbK6Hav0wnmkM7 qtjw== X-Gm-Message-State: AOAM5324N0kRAt/WQS1r7WaX1fc/1ke8CScZT760aKjsfuvZGSqSaj8s /TRzvfxASDj66ypgOCYRp7IFxFiuPA4= X-Google-Smtp-Source: ABdhPJyU5q0D6+6n8vTO7/HrQyloRGB0H0ZMGMNsH1cW/TOrR1gUFkFhZs4a3Dqr9WqWwQcS3HGDJA== X-Received: by 2002:a05:600c:3d18:b0:39c:474c:eb with SMTP id bh24-20020a05600c3d1800b0039c474c00ebmr6368824wmb.87.1654832089637; Thu, 09 Jun 2022 20:34:49 -0700 (PDT) Received: from rimwks.local ([2001:470:1f15:3d8:9554:7133:29d0:f593]) by smtp.gmail.com with ESMTPSA id v187-20020a1cacc4000000b0039749256d74sm1317452wme.2.2022.06.09.20.34.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 20:34:49 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Fri, 10 Jun 2022 06:34:47 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, Rozhuk Ivan Subject: ccache during system build Message-ID: <20220610063447.10ff8004@rimwks.local> X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.1) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/EaWb/ZuBLx5HcyfQ9sZFz/p" X-Rspamd-Queue-Id: 4LK66252tpz3s7g X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ieTqFmXF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-2.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.987]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~,3:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; MIME_UNKNOWN(0.10)[application/x-shellscript]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BAD_ATTACHMENT(1.60)[sh]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --MP_/EaWb/ZuBLx5HcyfQ9sZFz/p Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! Just few tips. 1. bsd.compiler.mk set COMPILERCHECK env var: ============================================================================ # Handle bootstrapped compiler changes properly by hashing their content # rather than checking mtime. For external compilers it should be safe # to use the more optimal mtime check. # XXX: CCACHE_COMPILERCHECK= string: .if ${CC:N${CCACHE_BIN}:[1]:M/*} == "" CCACHE_COMPILERCHECK?= content .else CCACHE_COMPILERCHECK?= mtime .endif ============================================================================ this overrides ccache.conf setting and increase build time. CCACHE_COMPILERCHECK='%compiler% -dumpversion' makes first build and second system rebuild faster. 2. To allow ccache hit in case with different src and obj location a) obj must be placed inside src b) OBJTOP env var must be set to new obj location without this obj path will contain src path and not hit to ccache. c) CCACHE_BASEDIR must be set to src d) CCACHE_NOHASHDIR=yes e) CCACHE_COMPILERCHECK='%compiler% -dumpversion' f) MAKEOBJDIRPREFIX='' g) -o nocache must be used with mount_nullfs to avoid error during install: exec(btxld) failed (No such file or directory) and obj via nullfs As example, attached scripts build kernel and world using obj stored inside /tmp, after build files from temp obj moved to /usr/obj dir. Using simular technic for build FreeBSD inside other src and obj locations I got ccache hit and reduce build time. I got ccache miss only for kernel build in case different KERNCONF, because it is mapped to obj dir path. Probably overwriting OBJROOT will fix it. --MP_/EaWb/ZuBLx5HcyfQ9sZFz/p Content-Type: application/x-shellscript Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=fbsd_build_kernel.sh IyEvYmluL3NoCiMjIyBSb3podWsgSXZhbiAyMDE5LTIwMjIKIyMjIGZic2RfYnVpbGRfa2VybmVs CiMjIyAKCgojIEV4aXQgb24gZXJyb3IuCnNldCAtZQoKCiMgSW5pdCBjb25zdGFucy4KOiAke1NS Q19ESVI9L3Vzci9zcmN9CkFVVE9fVEhSRUFEUz1gZ2V0Y29uZiBOUFJPQ0VTU09SU19PTkxOIHwg dHIgLWNkICdbOnByaW50Ol0nYApNQUtFT0JKRElSX09SSUc9YG1ha2UgLUMgJHtTUkNfRElSfSAt ViBNQUtFT0JKRElSYApPQkpESVJfU1JDPSIke1NSQ19ESVJ9L29ial90bXAiCk9CSkRJUl9UTVA9 YG1rdGVtcCAtZCAtcSAvdG1wL29iai5YWFhYWFhYWGAKaWYgWyAkez99IC1uZSAwIF07IHRoZW4K CWVjaG8gIiR7MH06IENhbid0IGNyZWF0ZSB0ZW1wIGRpciwgZXhpdGluZy4uLiIKCWV4aXQgMQpm aQpleHBvcnQgQ0NBQ0hFX0JBU0VESVI9IiR7U1JDX0RJUn0iCmV4cG9ydCBDQ0FDSEVfTk9IQVNI RElSPSd5ZXMnCmV4cG9ydCBDQ0FDSEVfQ09NUElMRVJDSEVDSz0nJWNvbXBpbGVyJSAtZHVtcHZl cnNpb24nCmV4cG9ydCBNQUtFT0JKRElSUFJFRklYPScnCmV4cG9ydCBPQkpUT1A9IiR7T0JKRElS X1NSQ30iCmlmIFsgISAtZCAiJHtPQkpESVJfU1JDfSIgXTsgdGhlbgoJcm0gLXJmICIke09CSkRJ Ul9TUkN9IgoJbWtkaXIgLXAgIiR7T0JKRElSX1NSQ30iCmZpCgoKIyBDbGVhbiBhbGwgcHJldiBk YXRhLgpmb3IgX19NTlRfUE9JTlQgaW4gYG1vdW50IHwgZ3JlcCAiIG9uICR7T0JKRElSX1NSQ30i IHwgYXdrICd7cHJpbnQgJDE7fSdgIDsgZG8KCXJtIC1yZiAiJHtfX01OVF9QT0lOVH0iID4vZGV2 L251bGwgMj4mMQoJdW1vdW50IC1mICIke09CSkRJUl9TUkN9IiA+L2Rldi9udWxsIDI+JjEKZG9u ZQoKCiMgLW8gbm9jYWNoZSB0byBmaXggZXJyb3I6IGV4ZWMoYnR4bGQpIGZhaWxlZCAoTm8gc3Vj aCBmaWxlIG9yIGRpcmVjdG9yeSkKbW91bnRfbnVsbGZzIC1vIHJ3IC1vIG5vY2FjaGUgLW8gbm9h dGltZSAtbyBub2V4ZWMgLW8gbm9zdWlkICIke09CSkRJUl9UTVB9IiAiJHtPQkpESVJfU1JDfSIK CgojIEJ1aWxkLgovdXNyL2Jpbi9uaWNlIC1uIDE1IFwKCS91c3IvYmluL3RpbWUgLWggXAoJbWFr ZQktaiIke0FVVE9fVEhSRUFEU30iIFwKCQktQyAiJHtTUkNfRElSfSIgXAoJCS1zIFwKCQktREFM V0FZU19DSEVDS19NQUtFIFwKCQktRE5PX0NMRUFOIFwKCQlidWlsZGtlcm5lbAojIEZvcmNlIHNl dCBmaWxlcyB0aW1lcy4KZmluZCAiJHtPQkpESVJfVE1QfSIgLXR5cGUgZiAtZXhlYyB0b3VjaCB7 fSArCgoKIyBDb3B5IGJhY2sgdG8gL3Vzci9vYmoKX19TUkNfRElSPSIke09CSkRJUl9UTVB9L3N5 cyIKX19EU1RfRElSPSIke01BS0VPQkpESVJfT1JJR30vc3lzIgplY2hvICJTYXZpbmc6ICR7X19T UkNfRElSfSAtPiAke19fRFNUX0RJUn0iCnJtIC1yZiAiJHtfX0RTVF9ESVJ9Igpta2RpciAtcCAi JHtfX0RTVF9ESVJ9IgpjaG1vZCBhK3JYICIke19fRFNUX0RJUn0iCmNobW9kIGErclggIiR7TUFL RU9CSkRJUl9PUklHfSIKY2htb2QgLVIgYStyWCAiJHtfX1NSQ19ESVJ9IgpjcCAtYWYgIiR7X19T UkNfRElSfS8iICIke19fRFNUX0RJUn0iCgoKIyBDbGVhbnVwLgp1bW91bnQgIiR7T0JKRElSX1NS Q30iCnJtIC1yZiAiJHtPQkpESVJfVE1QfSIKc3luYwoKCmV4aXQgMAo= --MP_/EaWb/ZuBLx5HcyfQ9sZFz/p Content-Type: application/x-shellscript Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=fbsd_build_world.sh IyEvYmluL3NoCiMjIyBSb3podWsgSXZhbiAyMDE5LTIwMjIKIyMjIGZic2RfYnVpbGRfd29ybGQK IyMjIAoKCiMgRXhpdCBvbiBlcnJvci4Kc2V0IC1lCgoKIyBJbml0IGNvbnN0YW5zLgo6ICR7U1JD X0RJUj0vdXNyL3NyY30KQVVUT19USFJFQURTPWBnZXRjb25mIE5QUk9DRVNTT1JTX09OTE4gfCB0 ciAtY2QgJ1s6cHJpbnQ6XSdgCk1BS0VPQkpESVJfT1JJRz1gbWFrZSAtQyAke1NSQ19ESVJ9IC1W IE1BS0VPQkpESVJgCk9CSkRJUl9TUkM9IiR7U1JDX0RJUn0vb2JqX3RtcCIKT0JKRElSX1RNUD1g bWt0ZW1wIC1kIC1xIC90bXAvb2JqLlhYWFhYWFhYYAppZiBbICR7P30gLW5lIDAgXTsgdGhlbgoJ ZWNobyAiJHswfTogQ2FuJ3QgY3JlYXRlIHRlbXAgZGlyLCBleGl0aW5nLi4uIgoJZXhpdCAxCmZp CmV4cG9ydCBDQ0FDSEVfQkFTRURJUj0iJHtTUkNfRElSfSIKZXhwb3J0IENDQUNIRV9OT0hBU0hE SVI9J3llcycKZXhwb3J0IENDQUNIRV9DT01QSUxFUkNIRUNLPSclY29tcGlsZXIlIC1kdW1wdmVy c2lvbicKZXhwb3J0IE1BS0VPQkpESVJQUkVGSVg9JycKZXhwb3J0IE9CSlRPUD0iJHtPQkpESVJf U1JDfSIKaWYgWyAhIC1kICIke09CSkRJUl9TUkN9IiBdOyB0aGVuCglybSAtcmYgIiR7T0JKRElS X1NSQ30iCglta2RpciAtcCAiJHtPQkpESVJfU1JDfSIKZmkKCgojIENsZWFuIGFsbCBwcmV2IGRh dGEuCmZvciBfX01OVF9QT0lOVCBpbiBgbW91bnQgfCBncmVwICIgb24gJHtPQkpESVJfU1JDfSIg fCBhd2sgJ3twcmludCAkMTt9J2AgOyBkbwoJcm0gLXJmICIke19fTU5UX1BPSU5UfSIgPi9kZXYv bnVsbCAyPiYxCgl1bW91bnQgLWYgIiR7T0JKRElSX1NSQ30iID4vZGV2L251bGwgMj4mMQpkb25l CgoKIyAtbyBub2NhY2hlIHRvIGZpeCBlcnJvcjogZXhlYyhidHhsZCkgZmFpbGVkIChObyBzdWNo IGZpbGUgb3IgZGlyZWN0b3J5KQptb3VudF9udWxsZnMgLW8gcncgLW8gbm9jYWNoZSAtbyBub2F0 aW1lICIke09CSkRJUl9UTVB9IiAiJHtPQkpESVJfU1JDfSIKCgojIEJ1aWxkLgovdXNyL2Jpbi9u aWNlIC1uIDE1IFwKCS91c3IvYmluL3RpbWUgLWggXAoJbWFrZQktaiIke0FVVE9fVEhSRUFEU30i IFwKCQktQyAiJHtTUkNfRElSfSIgXAoJCS1zIFwKCQktREFMV0FZU19DSEVDS19NQUtFIFwKCQkt RE5PX0NMRUFOIFwKCQlidWlsZHdvcmxkCiMgRm9yY2Ugc2V0IGZpbGVzIHRpbWVzLgpmaW5kICIk e09CSkRJUl9UTVB9IiAtdHlwZSBmIC1leGVjIHRvdWNoIHt9ICsKCgojIENvcHkgYmFjayB0byAv dXNyL29iagpfX1NSQ19ESVI9IiR7T0JKRElSX1RNUH0iCl9fRFNUX0RJUj0iJHtNQUtFT0JKRElS X09SSUd9IgplY2hvICJTYXZpbmc6ICR7X19TUkNfRElSfSAtPiAke19fRFNUX0RJUn0iCm1rZGly IC1wICIke19fRFNUX0RJUn0iCmNobW9kIGErclggIiR7X19EU1RfRElSfSIKY2htb2QgLVIgYSty WCAiJHtfX1NSQ19ESVJ9IgpybSAtcmYgIiR7X19TUkNfRElSfS9zeXMiCmZvciBfX0RTVF9TVUJf RElSIGluIGBmaW5kICIke19fRFNUX0RJUn0vIiAtbWF4ZGVwdGggMSAtbm90IC1uYW1lICcnYDsg ZG8KCVsgIiR7X19EU1RfU1VCX0RJUn0iID09ICIke19fRFNUX0RJUn0vc3lzIiBdICYmIGNvbnRp bnVlCglybSAtcmYgIiR7X19EU1RfU1VCX0RJUn0iCmRvbmUKY3AgLWFmICIke19fU1JDX0RJUn0v IiAiJHtfX0RTVF9ESVJ9IgoKCiMgQ2xlYW51cC4KdW1vdW50ICIke09CSkRJUl9TUkN9IgpybSAt cmYgIiR7T0JKRElSX1RNUH0iCnN5bmMKCgpleGl0IDAK --MP_/EaWb/ZuBLx5HcyfQ9sZFz/p-- From nobody Fri Jun 10 12:31:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DF40184096E for ; Fri, 10 Jun 2022 12:31:30 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKL1F63Nfz3tH2; Fri, 10 Jun 2022 12:31:29 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id CF25316059; Fri, 10 Jun 2022 14:31:27 +0200 (CEST) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id 2EDF78AB1C; Fri, 10 Jun 2022 14:31:26 +0200 (CEST) Date: Fri, 10 Jun 2022 14:31:26 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Steve Kargl Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: <20220610123126.oXt_A%steffen@sdaoden.eu> In-Reply-To: References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> <20220609165536.A5vGK%steffen@sdaoden.eu> <20220609214906.6--d0%steffen@sdaoden.eu> User-Agent: s-nail v14.9.24-254-g443e374be3 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4LKL1F63Nfz3tH2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu X-Spamd-Result: default: False [-2.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.963]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-0.99)[-0.986]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.983]; MID_CONTAINS_FROM(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[192.0.2.2:received] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Steve Kargl wrote in : |On Thu, Jun 09, 2022 at 11:49:06PM +0200, Steffen Nurpmeso wrote: |> Steve Kargl wrote in ... |>|.ds volume-operating-system steve |>|.ds volume-ds-8 kargl |> |> If you use ".Dt TDI 1", you must set volume-ds-1. |> |>|.Dd June 8, 2022 |>|.Dt TDI 1 |>|.Sh NAME |>|.Nm tdi |>| |>|% mandoc tdi.1 | head -1 |> |> This is mandoc Mr. Kargl. ... |% cat steve.4 |.Dd June 8, 2022 |.ds doc-volume-operating-system Steve |.ds doc-volume-ds-4 Kargl |.Dt TDI 4 |.Sh NAME |.Nm tdi |Hi. |% mandoc steve.4 Well you can ignore totally what i say. And you can mess up software in the FreeBSD base system and introduce incompatible islands whenever you want to. I pointed out that the mandoc maintainer is currently having a run, i think i saw .ds request fly by, and from that to introducing up-upstream compatible handling of 20+ years old mdoc(7) macros would only be a small step. ... |Having to install groff and adding undocumented .ds magic isn't the ... This is not magic but decade old stuff, whether you like it or not. #?0|kent:free-src.git$ git grep -i doc-volume-ds release/5.5.0~50784 | wc -l 31 (I do not track anything before 5.5.0.) |solution for a FreeBSD base system functionality. In fact, I think |it would be better to have the mdoc(7) package grow a .Vl macro to |allow the volume title to be easily overridden. You can think whatever you want, and fill the remaining two letter combinations until they are all gone. Have a nice day. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Fri Jun 10 14:20:15 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4313583928A for ; Fri, 10 Jun 2022 14:20:26 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKNQw5W48z3R94 for ; Fri, 10 Jun 2022 14:20:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=aOqcmRMXNDkEPIfPyrbeoPcXOvm1T+hCpH+L+eb4mbU=; b=h8SX8e8URJu1HxeG33jweSajysNXx9MIaWhw0XxvLAoxpkMnZmLM8Ljnv3aAmAiKWuW/Ad2FRGEthGOdMwFoWuPQ78QpWpH10+on9dJ4mKNvtZ5kigiuIHuBGL4LUxL0pW+yddtsC8p67U/gzT36J3yQAS2beChV5A4CRLhDv2PEHXD6XLALevAGIsRNgz9K4uwSD28GJ0i4Qfn4QVDIDM3nKRhUUO8cTKCHjQEWharnZs9Svp3iUP0QEBjZAonNlwITZIXFdDiqlfaC90CSQjNWi9jmdJEHtJjlSt3+/wkYIkZx5X6oqA6o8dlgAYqXxmL/SqJo6MH9POPtA9+L5A==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1nzfUl-0006N9-CY for hackers@freebsd.org; Fri, 10 Jun 2022 17:20:15 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: h3/allwinner temperature Message-Id: <6228302A-B95F-42C0-8780-6E002D9D65AF@cs.huji.ac.il> Date: Fri, 10 Jun 2022 17:20:15 +0300 To: freebsd-hackers X-Mailer: Apple Mail (2.3696.100.31) X-Rspamd-Queue-Id: 4LKNQw5W48z3R94 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=h8SX8e8U; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-2.80 / 15.00]; ARC_NA(0.00)[]; SUBJECT_ENDS_SPACES(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FREEFALL_USER(0.00)[danny]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hi any chance of getting it working on this little SBC?, I remember - long = time ago, it worked but it was a hack if I remember correctly. i=E2=80=99m asking, because I just installed 13.1, and trying to compile = pkg from ports, and it just hangs, no panic, nada, just power cycle works. danny From nobody Fri Jun 10 16:20:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B81818525FC for ; Fri, 10 Jun 2022 16:20:06 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKR5155qwz4SMp; Fri, 10 Jun 2022 16:20:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 25AGK3VJ042413 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 10 Jun 2022 09:20:03 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 25AGK3eC042412; Fri, 10 Jun 2022 09:20:03 -0700 (PDT) (envelope-from sgk) Date: Fri, 10 Jun 2022 09:20:03 -0700 From: Steve Kargl To: Steffen Nurpmeso Cc: Baptiste Daroussin , freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20220609071702.umix3bbub3qxunlq@aniel.nours.eu> <20220609152904.gc9ue%steffen@sdaoden.eu> <20220609165536.A5vGK%steffen@sdaoden.eu> <20220609214906.6--d0%steffen@sdaoden.eu> <20220610123126.oXt_A%steffen@sdaoden.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220610123126.oXt_A%steffen@sdaoden.eu> X-Rspamd-Queue-Id: 4LKR5155qwz4SMp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-1.55 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.696]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.958]; NEURAL_SPAM_LONG(0.10)[0.100]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Fri, Jun 10, 2022 at 02:31:26PM +0200, Steffen Nurpmeso wrote: > Steve Kargl wrote in > : > |On Thu, Jun 09, 2022 at 11:49:06PM +0200, Steffen Nurpmeso wrote: > |> Steve Kargl wrote in > ... > |>|.ds volume-operating-system steve > |>|.ds volume-ds-8 kargl > |> > |> If you use ".Dt TDI 1", you must set volume-ds-1. > |> > |>|.Dd June 8, 2022 > |>|.Dt TDI 1 > |>|.Sh NAME > |>|.Nm tdi > |>| > |>|% mandoc tdi.1 | head -1 > |> > |> This is mandoc Mr. Kargl. > ... > |% cat steve.4 > |.Dd June 8, 2022 > |.ds doc-volume-operating-system Steve > |.ds doc-volume-ds-4 Kargl > |.Dt TDI 4 > |.Sh NAME > |.Nm tdi > |Hi. > |% mandoc steve.4 > > Well you can ignore totally what i say. And you can mess up > software in the FreeBSD base system and introduce incompatible > islands whenever you want to. I don't see how a discussion on an idea that may make FreeBSD more useful for its user is "messing up software". But, you have made it clear that such discussion are unwelcomed here. > ... > |Having to install groff and adding undocumented .ds magic isn't the > ... > > This is not magic but decade old stuff, whether you like it or > not. It is magic to the extent that doc-volume-* is undocumented in mandoc(1) and mdoc(7). It is magic to doc-volume-* to work with mandoc(1) as well mandoc does not recognize doc-volume-* > #?0|kent:free-src.git$ git grep -i doc-volume-ds release/5.5.0~50784 | > wc -l > 31 > > (I do not track anything before 5.5.0.) I have no idea what the above is meant to demonstrate. But, if your're tracking 5.5.0, groff lived in src/contrib, so yes, you'll like find doc-volumen-ds in the treele:kargl[216] cat a.c % foreach i (1 2 3 4 5 6 7 8 9) foreach? find /usr/src -name \*.$i -type f | xargs grep doc-volume | wc -l foreach? end 0 0 0 0 0 0 0 0 0 > > |solution for a FreeBSD base system functionality. In fact, I think > |it would be better to have the mdoc(7) package grow a .Vl macro to > |allow the volume title to be easily overridden. > > You can think whatever you want, and fill the remaining two letter > combinations until they are all gone. Thanks for granting me permission to try to improve FreeBSD. -- Steve From nobody Fri Jun 10 16:52:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E619B856E28 for ; Fri, 10 Jun 2022 16:52:02 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKRnt0msfz4YFc for ; Fri, 10 Jun 2022 16:52:01 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 25AGq0Ml042581 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 10 Jun 2022 09:52:00 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 25AGq0Vb042580 for freebsd-hackers@freebsd.org; Fri, 10 Jun 2022 09:52:00 -0700 (PDT) (envelope-from sgk) Date: Fri, 10 Jun 2022 09:52:00 -0700 From: Steve Kargl To: freebsd-hackers@freebsd.org Subject: Re: mandoc and volume titles Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LKRnt0msfz4YFc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-2.66 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.67)[-0.671]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Wed, Jun 08, 2022 at 04:35:08PM -0700, Steve Kargl wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264560 > I have closed this PR as, based on the discussion here, it's a bad idea to give users the flexibility to change the volume title. -- Steve From nobody Sat Jun 11 04:27:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6234E840C5B for ; Sat, 11 Jun 2022 04:27:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKlD62ZrBz4tGc for ; Sat, 11 Jun 2022 04:27:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654921630; bh=mfCZKSWNc+bjNEvnUJSdVyeshl1538IXlEgA4/voheQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=PgH6hZlJGb/VxIhdgMIah/p8PZWfYOlE/wd2ONtpqK0cSuWQhtkyBQu+vEf3YEJ6L4Owl/fH4H6cUfTfQLwf+SVEm3+04Eqd2G7FY1XdftSJV5iw7RQrvGWk/dzVY06Xmc0ups1bEWwXDLzF6AnYve5mL0CeF0Imo5Ol3DVGiU5dC1b2e1Hx4l+QJyv9XI/aXVM+sRzfrxc5Erk+vRR7c22vYdVHdqyAdkSDGWY6LoGZT9iYD1aFIQaKEbH41RrlFkqgcglt7dO07xFzvdC8rs5ZytUgTxah9MoF+YDDErq2jf4ce5AEphDpI4W882ym2BKcJ66RbrFfp6qRD5z4OQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654921630; bh=5bPLXkNCQXSokxRF13Wf6Zl9K8lYxkQZ0yVzPcUoJV+=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=tjSDC0VXw/9LIlAu5aDL7Fd+bIlwoh8DjzqnV480vY+/bvhYcSSVZ2shg1a55JRMG+C1wHsAtEbne3uNGyHALtPABRspoz/zCFtTRJ5/99G9OK/FhFrlEXcBj1QOLVOgEgIuhcJmrhRPEgh7efe4/gBJpM/Zv9djaJktrn6ndPiQIEkV+g7ajSiM6VSXekNEZla0lj97cOmiyw4SH3EO+ApTXa8tQ1SnZ4Bo1Hidw9Gi13+Do62Ox2JuD1UPU/8reaqxUTgQjfNoG535YF5XSxWJj+CCiYCcYlEWRLuKpGHM0wqy49YcjTHkBlhcFBEz8ZMfvuyHzw3JpWNwWrnJSg== X-YMail-OSG: 657RueoVM1msEygxQudmUNGSoKgYW.9cic43ffcg8g2sMDBNZFLjnkDPNbN..vi qD6oNKBr0B6lZblNNrUQxeqL_cCTTm_R5xOsCBwib07qNBK63sfn3pgrW5T01e.lsszfQb6H2Evp _OrfPsofy3aSxXsOoyKfCgbCJ1oP0KO0GvBDVRsJFcRhbPSYWor4tFzA.WHYema3FiKMz13DE7Ft GALC6laFfcbrLF6Zw4aG.luOtH6sZ4No_EoyOQgIJIL9h.p64KvTPZmEEU24EQgYWRValE0L5F8p KCgENQMVuH7hgyY_duk2OpmYgHpZsQm4Dx0M53YYz0B4esgvJCyKY6cHl6LARPI2W4GAbPGv5MGT IMWpCL4GJcpYtHWqPcXVD95LDpi4az1B6UHC_p6inkQ5KHMf8MQHY9qXjkrxW8Ji7xk20byfhFLO jHzA9YVSlB0uSRgsQ9Ha3QfON5vl8UYtqp9cdm7v5.fsIhEHbChnfB9TpTW.F09e1z2najahGGdo xwyw3nWIfYYf.JhErchDXIKavfYIU5FneiJK.CoTdvwj_e0Wfu7zAoofOz4O5GKS7klKpudq.uAp BgTOKBVxFub_QBwe0WM43Z4080z9.EjUuCuF2Ij7diGoEqJt7r4gHx4GQm3saCUO2h6jUe.e8PT2 VlfwQaNCU0PrbtYmHz2xESypZKjVBN5.O5MiXnDwz90T5MRncXT31orp2jr4NsNkqbo3Vh7DcXFq vxDiyb6Ao0GWBPYu_cEUzONmH1N1coA2.y.CbVIzYq7oeZsCVTgDhkm2sp3Tq0bnXdi4Z5yKh2wx fzcckJxrpjPN3FA0tETa.D6yKobV0i4uDVCpTjGvfmAJ6jpubDuRhlIwzNlDJ3R9vXrXP25ha5YV ragdhdYvnE1iB7z0gIsuxsKfH9WZXqyGG3tfcfPDfKyvcpK5KOWhqw0Z.crMXEetVvO4nmG5Tl6Z z9pYV.0fYWG7CelC9wMvJz4yCmDBwPuflWi6OlpFhzT_1_UIhMtHGNVAcsZRJbh6vauP61ef7VFI Wnwnf.Cw0pOWehyIXWH7sAT_ouVaRQnkypjSyj6DzmK7fAOIP.oC48HIGjPgJHuE7oXpvv9fh7Mt yvPoF651yyF4pVxmAajpL3PYwL6kxJyraW4b7EWP1im_j8LDy43tgP_KVuM_EmT53BHhw_PEGLA. KMJLa7BmbjjKPRQQEFLTsDsqQe5Gfq2mhu_baUCTojTMAzqYEWXrDWFUqwjn_jbqKicyWirgLJwm Z69qMNvvUdZnrwuSHFLNvCIBnCJe51Go_.rz0_KqB22HO4iXyQfLVIpkGgmdcBu6XTClQgGH7fcb Pf697.Nny7r2IErmZc6jU7TRD1H7DWgHVZlRQPjNtN3RdFAxtOIVqfdal5fDwZKvb4oxGkwLZiDg 0WJr30.c46TdR9vmNmmudsSYpadU0eEpIdys0Vy_.LQ_eqiVBVYG06iK_wnlUCfTJjgccmWmiBtZ QenKm88XI8sJOB6YHDDcqvWdaJulAmiz7Kkl9bDhjuRvxYN9vbV6ykFD1nl6J6yYRvEhIn8Ycnz3 8mF36UW9XvcsKTMoOARVhnvbkKOmP_SwiVdW0dPINhqm6vzEBLJgTaedjV9I6rSptRhkerfeZ8M9 ZQypeXROxCMZ3X3sOdZbh_5I9Q6djhyYIwB3h2zZHg4xLoo9d7qebmYYpXSP037RlAVog1yQEqUn Os.P72gTFdw4X9Kfg4qJ6KFfWFj2JtaL.QooZQLhQB8KROMaWiHJ7wLIEvK9RGDIiBiW1CnF84ba oGKeZwgGi1XHLdCw2ZjCXuSraxIeaLQZl.3t.d1.WEmQ2969wUwTV.55TcRqTQyWs1TC_HsxCbj3 5j._xDWM.a9VuVll_bbZr2oB5uLDbu1oc314Ze3qizWdlgyhh4GVUtOiRiJQWPyAhX43YeVkQ3Hf IPS0PbjqnAS2htqzVZd_1gSzxwHzRf95LPktblg2So3orz6oBsKK.BPOlN6H6ZI_GpWMScGc_XO1 1ATBkSLbj1nDq3VVwGv7g4pUNwb_cGlua_k1OQFEtgAxoYf0SCsNZJcc5nmO._KLWRPD014i2w2m UN3ZX16t2OOm1DOxpgJJ89uPPlP47ODtVGZGrU3.XW7LNjNgMBv.1yTU5QUmpibm.2lpwlDxmT2A 64as_08bGbrxANIyPRmx31iZAl4n4CpHRdp1QKqZle8fOX.rzihW.gMKbTUfjAQa3GY6fNRu7zCo h8P_gmKVs8fNue6og_3RhKcAxRFCEk13ASR6OalZHiHP_Q6k9bs2gVbpr3jEY3ge6wMMQsE0JAYH k9NwXBRbKbYcpDA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jun 2022 04:27:10 +0000 Received: by hermes--canary-production-gq1-54945cc758-mg5mc (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ca8ecba5a9699aca1b3259997d56ec3c; Sat, 11 Jun 2022 04:27:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) From: Mark Millard In-Reply-To: Date: Fri, 10 Jun 2022 21:27:06 -0700 Cc: Daniel Ebdrup Jensen , David Cross , Robert Clausecker Content-Transfer-Encoding: quoted-printable Message-Id: <573B8B0C-5209-459D-98AD-EE92DDA4DF83@yahoo.com> References: To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LKlD62ZrBz4tGc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=PgH6hZlJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-5, at 15:04, Mark Millard wrote: > On 2022-Jun-5, at 12:42, Mark Millard wrote: >=20 >> I have a poudriere bulk -a -c going on a 8 Gibyte >> aarch64 system. top has been showing an occasionally >> increasing swap usage but never any sizable decreases. >> Over 5800 ports have built so far. The context is UFS >> only. The system is running a non-debug build of main. >>=20 >> Part of the context is ( in /etc/sysctl.conf ): >>=20 >> vm.swap_enabled=3D0 >> vm.swap_idle_enabled=3D0 >>=20 >> Also ( in /usr/local/etc/poudriere.conf ): >>=20 >> USE_TMPFS=3D"data" >>=20 >> poudriere's TMPFS reports normally total under 128 >> KiBytes across the 4 builders. >>=20 >> For reference, example figures . . . >>=20 >> A top variant shows: >>=20 >> Swap: 30720Mi Total, 306816Ki Used >>=20 >> vmstat -s shows: >>=20 >> 78152 swap pager pages paged out >>=20 >> Note: (78152*4096)/1024 =3D=3D 312608Ki >>=20 >> So nearly all of the "swap pager pages paged out" >> pages are still sitting out in the used swap/paging >> space. Thus, the usage is not held by user processes >> or is held via very long running processes or is >> not directly tied to user processes --or some mix. >>=20 >> The variant of top reports never having observed >> more than: 6658Mi MaxObs(Act+Wir+Lndry). >> ("MaxObs" is short for "Maximum Observed".) >> Such high usage is for a bounded time, long past >> at this point. (Until some combination of port >> builds ends up active that uses such.) >>=20 >> So I'm curious: >>=20 >> What can I learn about the data that is staying >> paged out (and is gradually growing)? How can I >> learn it? >>=20 >>=20 >> Other notes: >>=20 >> The poudriere jail being built is: >>=20 >> # poudriere jail -jmain-CA7-bulk_a -i >> Jail name: main-CA7-bulk_a >> Jail version: 14.0-CURRENT >> Jail arch: arm.armv7 >> Jail method: null >> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a >> Jail fs: =20 >> Jail updated: 2022-05-23 02:21:24 >> Jail pkgbase: disabled >>=20 >> (Just in case the armv7 jail usage or the null method >> or such is important to the issue.) >=20 > Hmm. systat -swap reports a toal for the Devices/Paths Used > that is somewhat less than the total for what reports for the > Pid . . . Total figures (not the Pid Swap figures!): >=20 > # systat -swap > /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 > Load Average |||||||| =20 >=20 > Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| > gpt/CA72USBswp14 14G 150M > gpt/CA72USBswp16 16G 150M > Total 30G 300M >=20 > Pid Username Command Swap/Total Per-Process Per-System > 1453 root nfsd 1M / 15M 9% 0% > 1451 root mountd 1M / 15M 7% 0% > 1481 root sshd 912K / 20M 4% 0% > 1406 root ntpd 740K / 27M 2% 0% > 1513 root login 724K / 14M 5% 0% > 1514 root sh 656K / 13M 4% 0% > 342 _dhcp dhclient 516K / 13M 3% 0% > 1363 root rpcbind 448K / 13M 3% 0% > 1454 root nfsd 400K / 12M 3% 0% > 341 root dhclient 380K / 13M 2% 0% > 1341 root syslogd 324K / 12M 2% 0% > 1505 root getty 292K / 12M 2% 0% > 1510 root getty 292K / 12M 2% 0% > 1511 root getty 292K / 12M 2% 0% > 1512 root getty 292K / 12M 2% 0% > 1509 root getty 292K / 12M 2% 0% > 1508 root getty 292K / 12M 2% 0% > 1507 root getty 292K / 12M 2% 0% > 1506 root getty 288K / 12M 2% 0% > 1135 root devd 272K / 11M 2% 0% > 338 root dhclient 264K / 13M 2% 0% > 1 root init 244K / 11M 2% 0% > 1486 root cron 188K / 13M 1% 0% >=20 > I'm, Still looking for a clear indication of what > most of the 300 MiBytes or so of swap/paging space > is in use for. I finally gave up and checked if a swapoff would actually bring in all the pages from swap space that were needed (if any) and then un-configure the swap space. It did. (The bulk -a was still ongoing. It was not doing memory-hog builder activity at the time.) So such an activity may be a workaround for long running things like bulk -a to avoid a swap space accumulation that seems to be happening. I do not know how much was brought in to RAM vs. simply deallocated from swap space (pages not changed and still in RAM). If I do such a test again, it would be good to figure out how to monitor what the swapoff does for bringing in pages vs. just discarding them --if possible. After a while 12136Ki Used showed up after the swapon that reconfigured the swap space, which is about the size of the increments that I'd observed for its sustained increases. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jun 11 04:32:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2E581842012 for ; Sat, 11 Jun 2022 04:32:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LKlKw1yqPz4vtk for ; Sat, 11 Jun 2022 04:32:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654921933; bh=qc+dZL8iIWIuAUpe5BUAcPef9mOFb81gpbx/+vWxyzo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kmR1vXfv9R9zRJgAonZtpyBw2XWzdufFcsrdUyJ+Fhl/be+jxhW+cd18PjgQu2r/v8Y+662VTlM4omlaGzQ15yW73WKqcIVGit4PtIJB7ZkrYdhaBx6vWaJn04yA62rZtnGbOmN0ky5MAAIRRbnqgZAq7dLJU03QgDWnJpqUZ0+0PD/pgmJX3R62uSO2hE/qZqSVVCyhbBx2i0pjhev6qj1sVOJz7fmhp5J+/tTteyI2p3uzPnsfiCVHuHnGURhPakOfkYkHdhhQdb4FRJZPqrNK4xJOFhdDjefbYMj5Qg+pSaWP73Y2BtuxKt7nZtRBk0KYMVtOMjXxrbBoA64TJQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654921933; bh=oZQIH27p6bg/smX1Mys6nk5VHgRpLZ7OZvM77KyVCA1=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=HbzDwUkug5eio1h9KM52oCTxJP7lu5lZzxWeKGuZkUI6pZLiKC9tiW5z44Y9YOwmCJ/lMXFk6bRgh//ZbuvNIMDuZW23fyOB7I49RY1l8qkKLs76o3ShJ+2jWJiS3CAkSQp6+u/8fP2ApIh1jVPZ3IgV9EJMr+ufXmxOCcQEWi02ZJDuZLiis38919CseKn3IEUXlOz+3Zz6zncPquN/Gr7FY0YM+uqKx3FTzctGPSnFAimkKmO3O9JejT7rFPdPUtAYxP+8/n8J3eVw+xwIdxz7hT6EL/q1DoD0Wmteu85HQzb08h7hRgEhBnHeXVY4Ibuz68EvTVMbiL/29UP68g== X-YMail-OSG: G6T8pQEVM1m_ueolD9e74CmOp_uKYKWvjhIuWsAxV0PF3Ih1pwwYQHwDJJFomIq fg8bkbSgKAXau0WDBrrQyB.QP6N3UgaVZaQb82DBRbpOay2chD_sFkPFa3rwEIQLKF..cwsulYo7 yGZsPtTmI4KfUXduJqNltuUq23VSoNfWELSPJXeBFGG5Y5z6.drju5sZjwBW74NYAbYXF1c2JsF7 K8YLYp5cTd8EdQVFNSZ85Gt4KHZJug5VUioG3.9s5b3VlaUsb9ckbh9cr_oLRwEjWbbvgpUNnJu9 h4FNOhMqZnA32KeFGgLVRsz6i4iFjgkUF6kRc6ad8t8zA95Uj6S1c3ClTU_rm1W1krL0ikLloaig CrnmF2.NKYMJNs8jGd8Bl2mxzYZ9EQ09FZ01jRPIJk8i9lS6HWdGoAagIMhaNP6DwHbMYlFlWIaJ .oToTTuoglvm6l1JZI.9dM8b_vgjj8lOdyi.wtWMmW7840scMr.s21M9SM67SOTlYQORDJ.J8NHa hudoxeu4_GJxdQQ1VVTx3qjmkZlfngyqrk4z2pHjiCuog7B5Czyf8fuqFom91PH91keUSHI0OKlh gXK6V5XEb3NQxo.TZRJS61Cq_Ybz7iTIJ26aBU5UJ914eMA16sjstXxyCAfjB8CfbsIQHZzHtGXK Ciptfy3S0g5bbudzbj89UCDA2nFENJDVqLNHviYpQ5OWnoQc366FumYet5e0FoVKpO1d4R1waPs. .YDvDBv7_moPK65NxHclQhF3RSyZriRS1VOzu_ttDmSgKQAc4QtJyNyWu_LdqJ5JiTeupiXjsX44 UXPPgo.f.8MARCyGRcyF4Kk1yJCZ1xGSy_pU9Njd38UhP3eGwE1BJydlWZCBhtRIlC6qLf7uO.gY 8Kn2wqo4kBpECFE9CSvTO3qGM.nCdTBSkC3HX0EUBeoOcYpYKsuUHf_lwGw7qlQpQVSH2NsXEsPc _TEThhXoZZHyeLozib4Oo_iTARR2da.DUUzdnY4YCfZ99SQRLZgk6GAyDxVsjYUieZYbTBiUqKXc aR_y.70bZ0LZI0.Gkjp0GBE2zMSYpGcgqbVJJCrKBBrvQmDDzQuJMadiiRwdiXXc84JVDz9LX9if v5HtpTZgcJ51VVrOeb1iEHAOQWfm3a31odn5VIFG5BgRrJapj7eXUS1W05STgr8NISC9vPLGZgOS vzvCJze7V_ZQgq0nmN9tY4Y5T8Bx6CzTXRuiBNkNQhNAITQWRg7ywh7_YAugDVrxpIaVnWIKn3.6 32gDJW_8wqLYXdmdhA9zP3pEvSYxTjolW6I3OX8B5ZCFhgi1yrJ_k7OyPxliVAtUNFvoFN08m5Yf F1FboL_Xd740FZG3MuUYfIUnGNqzXUWS.qtr3CAUBV71noccQo0OwL26RY8qokTS_7B68rKahGJO WEptmOVDDFhv5hldhiHbppUi557mu6DghY4Un8IXl5OjLCt68iLugk5OaqmyslfRZXNlGEgq1gKS ZgAhI65Ok1QYiy8uWHU8Y0zzYGO51HvHRoCNts16WqITay47MyL1pzGiVneerXRXOr0mZOHZD8sv FdPDYOP7Kv9m4dzEWWAQeY6Nkxm0LSBze_NeMAsVt42dsuicsObCOaU2fZMKSfiV4Hl.ZVNQA8V4 qGGcRp6FoxpJdQWsoqsUd5fxysdIDQ_nRN67goZRxGnsEBx.IguEE_da3.IU5wSddm5eNe1faC9x Yrlmzan1.85GxjAZTcA5wzPBEQY4JEkk7sZQ9GppgO9ZkjuQwMLlgpTP7j2GmMfiVsyRBTFpaNSN I0..qFwtRR_8wXK0B8uWomhAig547.ciVBSNk6lXk321DSv6j9SOrXX3y5P9s0PncUdFbSoBemgu dWA6Ta40cgtJaaUQLBeyVvUMthJEbBUXumgZ0Puw4hF21JXpshVZCLX_qtvwArer1UOMFOuPG8Ic Qgi3Ct7o0Jh4DYZ_soQ1qYCSBLFt.ldYUCc6yXnwt9iiM3ZScKFKHnIn7akfzZH3p25FJnTTPIjx .89IR7q_HlvpKtN2rhcm9jGQg2TN6Wj8TmKXP.iqek2pTC7yOfssdqgNQcMXck0hJReOu0XJJk_Q 4AWrksDyk73ES5uPLucQsELbqmGrU8Ls8GAPigjR1EDiAvrQJ7lGp7ZUdo9aLJ6WqIbiEWuc5qna kJL3A9XOh4qLkXqIEzCPIwxfIAh7w8C3f9z3uSs6orL5z4.Ud_gcGlSvjNN9DAk6OkGOlmLmdQ3i N0DpvY6Pivgv_zAXk4LHrj1rh_n6hqWkeEuwZoXTRxN9hewOoEdlQ74IxDWuRwuvHjCIvdKrZ61f Ebu_D61LBU8Gq X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jun 2022 04:32:13 +0000 Received: by hermes--canary-production-gq1-54945cc758-fkbwk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID db8054295ef0d028d7d9735dcdfb8b81; Sat, 11 Jun 2022 04:32:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) From: Mark Millard In-Reply-To: <573B8B0C-5209-459D-98AD-EE92DDA4DF83@yahoo.com> Date: Fri, 10 Jun 2022 21:32:10 -0700 Cc: Daniel Ebdrup Jensen , David Cross , Robert Clausecker Content-Transfer-Encoding: quoted-printable Message-Id: <6EA27152-3355-4356-B246-A083F31452F2@yahoo.com> References: <573B8B0C-5209-459D-98AD-EE92DDA4DF83@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LKlKw1yqPz4vtk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kmR1vXfv; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-10, at 21:27, Mark Millard wrote: > On 2022-Jun-5, at 15:04, Mark Millard wrote: >=20 >> On 2022-Jun-5, at 12:42, Mark Millard wrote: >>=20 >>> I have a poudriere bulk -a -c going on a 8 Gibyte >>> aarch64 system. top has been showing an occasionally >>> increasing swap usage but never any sizable decreases. >>> Over 5800 ports have built so far. The context is UFS >>> only. The system is running a non-debug build of main. >>>=20 >>> Part of the context is ( in /etc/sysctl.conf ): >>>=20 >>> vm.swap_enabled=3D0 >>> vm.swap_idle_enabled=3D0 >>>=20 >>> Also ( in /usr/local/etc/poudriere.conf ): >>>=20 >>> USE_TMPFS=3D"data" >>>=20 >>> poudriere's TMPFS reports normally total under 128 >>> KiBytes across the 4 builders. >>>=20 >>> For reference, example figures . . . >>>=20 >>> A top variant shows: >>>=20 >>> Swap: 30720Mi Total, 306816Ki Used >>>=20 >>> vmstat -s shows: >>>=20 >>> 78152 swap pager pages paged out >>>=20 >>> Note: (78152*4096)/1024 =3D=3D 312608Ki >>>=20 >>> So nearly all of the "swap pager pages paged out" >>> pages are still sitting out in the used swap/paging >>> space. Thus, the usage is not held by user processes >>> or is held via very long running processes or is >>> not directly tied to user processes --or some mix. >>>=20 >>> The variant of top reports never having observed >>> more than: 6658Mi MaxObs(Act+Wir+Lndry). >>> ("MaxObs" is short for "Maximum Observed".) >>> Such high usage is for a bounded time, long past >>> at this point. (Until some combination of port >>> builds ends up active that uses such.) >>>=20 >>> So I'm curious: >>>=20 >>> What can I learn about the data that is staying >>> paged out (and is gradually growing)? How can I >>> learn it? >>>=20 >>>=20 >>> Other notes: >>>=20 >>> The poudriere jail being built is: >>>=20 >>> # poudriere jail -jmain-CA7-bulk_a -i >>> Jail name: main-CA7-bulk_a >>> Jail version: 14.0-CURRENT >>> Jail arch: arm.armv7 >>> Jail method: null >>> Jail mount: /usr/obj/DESTDIRs/main-CA7-poud-bulk_a >>> Jail fs: =20 >>> Jail updated: 2022-05-23 02:21:24 >>> Jail pkgbase: disabled >>>=20 >>> (Just in case the armv7 jail usage or the null method >>> or such is important to the issue.) >>=20 >> Hmm. systat -swap reports a toal for the Devices/Paths Used >> that is somewhat less than the total for what reports for the >> Pid . . . Total figures (not the Pid Swap figures!): >>=20 >> # systat -swap >> /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 >> Load Average |||||||| =20 >>=20 >> Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| >> gpt/CA72USBswp14 14G 150M >> gpt/CA72USBswp16 16G 150M >> Total 30G 300M >>=20 >> Pid Username Command Swap/Total Per-Process Per-System >> 1453 root nfsd 1M / 15M 9% 0% >> 1451 root mountd 1M / 15M 7% 0% >> 1481 root sshd 912K / 20M 4% 0% >> 1406 root ntpd 740K / 27M 2% 0% >> 1513 root login 724K / 14M 5% 0% >> 1514 root sh 656K / 13M 4% 0% >> 342 _dhcp dhclient 516K / 13M 3% 0% >> 1363 root rpcbind 448K / 13M 3% 0% >> 1454 root nfsd 400K / 12M 3% 0% >> 341 root dhclient 380K / 13M 2% 0% >> 1341 root syslogd 324K / 12M 2% 0% >> 1505 root getty 292K / 12M 2% 0% >> 1510 root getty 292K / 12M 2% 0% >> 1511 root getty 292K / 12M 2% 0% >> 1512 root getty 292K / 12M 2% 0% >> 1509 root getty 292K / 12M 2% 0% >> 1508 root getty 292K / 12M 2% 0% >> 1507 root getty 292K / 12M 2% 0% >> 1506 root getty 288K / 12M 2% 0% >> 1135 root devd 272K / 11M 2% 0% >> 338 root dhclient 264K / 13M 2% 0% >> 1 root init 244K / 11M 2% 0% >> 1486 root cron 188K / 13M 1% 0% >>=20 >> I'm, Still looking for a clear indication of what >> most of the 300 MiBytes or so of swap/paging space >> is in use for. >=20 > I finally gave up and checked if a swapoff would > actually bring in all the pages from swap space > that were needed (if any) and then un-configure > the swap space. It did. (The bulk -a was still > ongoing. It was not doing memory-hog builder > activity at the time.) >=20 > So such an activity may be a workaround for long > running things like bulk -a to avoid a swap space > accumulation that seems to be happening. >=20 > I do not know how much was brought in to RAM vs. > simply deallocated from swap space (pages not > changed and still in RAM). If I do such a test > again, it would be good to figure out how to > monitor what the swapoff does for bringing in > pages vs. just discarding them --if possible. >=20 > After a while 12136Ki Used showed up after the > swapon that reconfigured the swap space, which is > about the size of the increments that I'd observed > for its sustained increases. >=20 An interesting point for "systat -swap" now: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 = /10 Load Average ||||||||||||||||||||||||||||| Device/Path Size Used |0% /10 /20 /30 /40 / 60\ 70\ 80\ = 90\ 100| gpt/CA72USBswp14 14G 6108K gpt/CA72USBswp16 16G 6028K Total 30G 12M Pid Username Command Swap/Total Per-Process Per-System No process is listed as using swap but the 12M shows as used! That should be a hint, not that it is directly useful for me figuring out what the usage is from/for. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jun 11 18:01:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D7A4844C80; Sat, 11 Jun 2022 18:01:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LL5HL1q5Gz4SbS; Sat, 11 Jun 2022 18:01:18 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654970478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=vS03l+AbRVT1Dq6P76jUioSN7ZcE6alq+/M5Ba4O0Z8=; b=DlPbK5uY4Vr2JLjRC/wJiI++Pop3DxmjjMkl2yG5RoCwfI7MaAg8eQEa/FjTXBUFp9ekL+ 3/HGKB0wzsnmQSRV9zyeiowkg/auFn1B1PeFj54MNlwP3F+4WfAwWPqzY1Pusk0kXjlcHR GkZJsArJisSA5BGu1BCK12oE6TEDfRcgawCaqzXykKUY25OOMdKEH4nSdoLfRg2RRjflwl ZwCtBfczNVt31cYzSAx8zvnIEqla5G5Y/hOuuiqYUyjMiKgluDShmoj3ipcp54tYovl2YM ZJjlrKAq+SJ8734Bh9mZQruAq7X/Y0QCO6PYzuhh+C1hOXR3egQMtdmFSk0sng== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 05AC74C5E; Sat, 11 Jun 2022 18:01:17 +0000 (UTC) Date: Sat, 11 Jun 2022 18:01:17 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report First Quarter 2022 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654970478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=vS03l+AbRVT1Dq6P76jUioSN7ZcE6alq+/M5Ba4O0Z8=; b=HCRDGtoRlETa/lXhXCvny1/ke2zySoZY6rbWoV/wNE8+FSvvi7Hr6Glk7svV5FgMhfZIVA Tees65l2EgP/kDULsfXD4V44Dcpf+4quj3GlZqRuNYyu+Da8eSlKl+RANgaUJzsM9iDrrK gnB++SNZHMvBbMtcGBllPBOJt4oWVtLXQCY+D0ae0ySOWJrGCdTTEKPCwlfLBs8zXrYg21 GjpFhsAeRjynUVHbTbOct3DyKomfa053tcivPGCZz6gp5oO42iS1XKLSMIu2nl4rH/jsVi 00VCD5dkzegZk8PpWBnuW2ja7k/JZJ9XOmgLoY/HTKhbu6DIFJvF0335VQ4ySA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654970478; a=rsa-sha256; cv=none; b=hUbNFnVWW2iWXfNQXFaf9izIFs+cGOEZka1AJfCz22551+jftTH0spZwGBGaJHIw4llpgH G3BMCEXm5RwNOoiEgVO9+B46vqXQEugErLU7BjtQP/6gmxMqFTHpDeWZpYQirbNMBnTlWU MR0f773CR/w04uYiEbT2Te/HzuGgQ7qn7nwzbDYI7ntC0KUHFg7Fla7QtySMUrGbLvBvoW KDr0b698XH8XmEZPuwlwduLU9p45m6odLROv7rb0HYuOwluVpSY10Bsyi5ujqMUvs65tSH SGloN0rAgBuKOK0tgn1/biZ+pDetyDmwJZLQBb7v/OUEM4bnbJ0nqipkWLBvkw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N FreeBSD Quarterly Status Report First Quarter 2022 As things are yet again settling into a new normal, it’s once again time for a status report for the FreeBSD Project. You may have noticed that this report is also a little on the late side, and it’s with regret that it’s taken this long to get to it - however, thanks to a few kind souls who’ve stepped up to the plate, in addition to the folks on the team who do things quietly in the background, future reports should hopefully be more on time. So let’s get some introductions in order, as yours truly is delighted to accept a hand from Pau Amma who already has been helping with reviews for a while, Lorenzo Salvadore who is stepping up to get some tooling in place to make it less of a chore to make the reports, as well as Sergio Carlavilla who is stepping up to help with all the work that can’t be easily automated. This report covers a very diverse set of topics including but not limited to accessibility, system boot speed-up, an implementation of GEOM union, changes to the WiFi situation, and many other things. We hope you’ll enjoy reading it! Daniel Ebdrup Jensen, on behalf of the status report team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2022-01-2022-03/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection • Projects □ FreeBSD Accessibility □ Boot Performance Improvements • Kernel □ ENA FreeBSD Driver Update □ A New GEOM Facility, gunion □ Realtek Wireless driver support □ Intel Wireless driver support and LinuxKPI 802.11 compatibility layer □ Kernel Crypto changes to support WireGuard • Documentation □ Documentation Engineering Team • Ports □ KDE on FreeBSD □ Elsewhere □ FreeBSD Office Team □ lang/gcc* ports need some love and attention □ PortConfig □ Wifibox: Use Linux to drive your wireless card on FreeBSD • Third Party Projects □ helloSystem □ Containers and FreeBSD: Pot, Potluck and Potman □ Fpart and fpsync ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.FreeBSDFoundation.org Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/ Donate URL: https://www.FreeBSDFoundation.org/donate/ Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/ FreeBSD-foundation-partnership-program FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/ Foundation News and Events URL: https://www.FreeBSDFoundation.org/ news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights from the Foundation for the first quarter of 2022. Fundraising Efforts As promised, we updated our fundraising meter for 2022. So far, we’ve raised over $84,000 towards our 2022 goal of $1,400,000. We’d like to thank our individual and corporate donors for supporting our efforts this year. We’d also like to give a big shout out to our Gold Sponsor, Facebook, Silver Sponsors, VMware and Tarsnap, and the companies that provide free hosting for the Project: Bytemark, 365 Data Centers, NYI, NextArray, Sentex Data Communications, and the Computer Science Department at NCTU. You can find out how we spent your donations by reading about what we supported in Q1, in this report, and our Spring Newsletter. If you haven’t made a donation this year, please consider making a donation now at https://freebsdfoundation.org/donate/. We also have a Partnership Program for larger commercial donors. You can find out more at https://freebsdfoundation.org/our-donors/ freebsd-foundation-partnership-program/ OS Improvements During the first quarter of 2022, 372 src, 41 ports, and 16 doc tree commits were made that identified The FreeBSD Foundation as a sponsor. # This represents 16, 0.4, and 5% of the total number of commits in each repository. You can read about Foundation-sponsored projects in individual quarterly report entries: • Crypto changes for WireGuard • Intel Wireless driver support Here is a small sample of other base system improvements from Foundation developers this quarter that do not have separate report entries. riscv: Add support for enabling SV48 mode SV48 is intended for systems for which a 39-bit virtual address space is insufficient. This change increases the size of the user map from 256GB to 128TB. The kernel map is left unchanged for now. For now SV48 mode is left disabled by default, but can be enabled with a tunable. Note that extant hardware does not implement SV48, but QEMU does. • In pmap_bootstrap(), allocate a L0 page and attempt to enable SV48 mode. If the write to SATP doesn’t take, the kernel continues to run in SV39 mode. • Define VM_MAX_USER_ADDRESS to refer to the SV48 limit. In SV39 mode, the region [VM_MAX_USER_ADDRESS_SV39, VM_MAX_USER_ADDRESS_SV48] is not mappable. Add v3 support to CTF tools CTF, the Compact C Type Format, is a representation of type information most often contained within ELF binaries. This type information is helpful for probing tools like DTrace. Recent work by Mark Johnston allows different Dtrace providers like the FBT (Function Boundary Tracing) provider to work with version 3 of CTF. FreeBSD on the Framework Laptop Two Foundation staff members, Ed Maste and Mark Johnston, as well as a few developers and community members now each have access to Framework laptops, which are designed to make hardware upgrades, repairs, and customizations straightforward for the average user. The goal of this work is to ensure that the experience running FreeBSD on the laptops matches the stability that FreeBSD users expect. Recent improvements and fixes include: • Making audio switch appropriately between speakers and the headphone jack when headphones are plugged in or unplugged • Fixing bug 259230, which would cause a Framework laptop to reboot or power off when the touchpad was used. • Adding the Tempo Semiconductor 92HD95B HDA codec ID • Temporarily fixing stalled usb enumeration, bluetooth, and S3 resume. The temporary fix is to avoid attaching to several newer Intel controllers, which require firmware to be loaded, which is different from that implemented by ng_ubt_intel and iwmbtfw, so they are not usable yet. • Avoiding a 16 second boot delay, by probing the TSC frequency earlier. This lets us use the TSC to implement early DELAY, limiting the use of the sometimes-unreliable 8254 PIT. You can follow news about FreeBSD work on the Framework laptop at: https:// wiki.freebsd.org/Laptops/Framework_Laptop. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. Supporting FreeBSD Infrastructure The Foundation provides hardware and support for the Project. At the time of writing, the server that will become the new Australian mirror has arrived in Australia, has a fresh FreeBSD install and will shortly join the cluster. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are continuing to attend virtual events and began planning the June 2022 Developer Summit. Check out some of the advocacy and education work we did last quarter: • Committed to hosting a FreeBSD Workshop at SCALE 19x and serve as a Media Sponsor - July 28-31, 2022 in Los Angeles, CA • Participated in the FLOSS Weekly Podcast - January 5, 2022 https://twit.tv/ shows/floss-weekly/episodes/662 • Sent out the 2021 Impact Report showcasing how we supported the Project last year. https://freebsdfoundation.org/blog/ 2021-freebsd-foundation-impact-report/ • Hosted a stand at FOSDEM 2022 - Videos from the stand can be found at: https://youtube.com/playlist?list=PLugwS7L7NMXxwqIRg1PlhgzhNRi1eVdRQ • Participated in the Open Source Voices Podcast - Episode to be aired in late April [note from status report team: the episode has indeed be aired and is now available at https://www.opensourcevoices.org/29; unfortunately, there is and will be no transcript.] • Began planning the June 2022 FreeBSD Developers Summit taking place virtually, June 16-17, 2022 https://wiki.freebsd.org/DevSummit/202206 • Held a new FreeBSD Friday - How to Track FreeBSD Using Git Pt. 2 https:// youtu.be/Fe-dJrDMK_0 • Presented at the St. Louis Unix User Group on March 9, 2022 https://ow.ly/ 1QXn50Ivj75 • Served as Admins and were accepted as a mentoring organization for the 2022 Google Summer of Code • Held an Office Hours session on Google Summer of Code. https://youtu.be/ x-4U1xurmBE • Hosted a booth at the virtual Open Source 101 conference on March 29, 2022 • New blog posts: □ RAID-Z Expansion Feature for ZFS In the Home Stretch □ What’s Ahead for FreeBSD and the Foundation in 2022 □ Work with FreeBSD in Google Summer of Code • New How-To Guide: An Introduction to FreeBSD Jails • New FreeBSD Journal Article: Contributing to FreeBSD ports with Git We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https:// www.FreeBSDfoundation.org/journal/ You can find out more about events we attended and upcoming events at https:// www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.FreeBSDFoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.1-RELEASE schedule URL: https://www.freebsd.org/releases/13.1R/ schedule/ FreeBSD 13.1 Release Information URL: https://www.freebsd.org/releases/13.1R/ [link added by status report team as this quarterly status report is being published after 13.1-RELEASE has been released] FreeBSD releases URL: https://download.freebsd.org/ftp/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the first quarter of 2022, the Release Engineering Team completed work on, and submitted to the developers the 13.1-RELEASE schedule. This will be the second point release from the stable/13 branch. As of this writing, three BETA builds have been run, with at least two RC builds before the final release, currently scheduled for April 21, 2022. We look forward to another consistently stable release at the end of this cycle, as well as many more to come for other branches moving forward. Additionally throughout the quarter, several development snapshots builds were released for the main, stable/13, and stable/12 branches. Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration /#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: • Improved web service performance and security □ Moved some critical services to newer machines □ Swept all services to ensure the support of TLS v1.2 and v1.3 and disable v1 and v1.1 □ Enabled dual-stack certificates for the primary FreeBSD web services. ECDSA and RSA certificates, preferring ECDSA, discussed with secteam@, benefit the project in favor of security and performance matter. • Infrastructure improvements at primary site □ Evicted some very old hardware □ Moved cluster internal services to newer hardware ☆ Build host ☆ Parts of LDAP, kerberos, DNS and NTP • Installed an additional aarch64 package builder □ ampere3.nyi.freebsd.org □ Identical specs to ampere[12].nyi.freebsd.org • Moved ftp0.nyi.freebsd.org to an aarch64 machine. • Main distributed mirror site, download.freebsd.org, enhancements □ Updated offline documentation (PDF and HTML) in the mirrors. The old directory /doc is now on ftp-archive; it contains files prior to the Hugo/Asciidoctor migration. □ Moved ports INDEX files to distributed mirror, download.freebsd.org □ Removed /ftp from the canonical URLs of files on download.freebsd.org. Old URLs are still valid. • Cleanup of Handbook/Mirrors section Much stale information; now there is more info about the official mirrors and locations. Former official mirrors are now named 'Community mirrors'. • Ongoing day to day cluster administration □ Cluster refresh □ Replacing failed disks □ Babysitting pkgsync Work in progress: • Improve the package building infrastructure • Review the service jails and service administrators operation • Set up powerpc pkgbuilder/ref/universal machines • Search for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror • Work with doceng@ to improve https://www.freebsd.org and https:// docs.freebsd.org • Improve the web service architecture • Improve the cluster backup plan • Improve the log analysis system • Set up Australia mirror • Hardware refresh ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. During the first quarter of 2022, we continued working with the contributors and developers in the project to fulfil their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important changes: • DTrace tests are running with KASAN now. • Fixed and resumed the powerpc64le test jobs. Retired jobs: • The jobs of main branch on mips* were removed. Work in progress and open tasks: • Designing and implementing pre-commit CI building and testing (to support the workflow working group) • Designing and implementing use of CI cluster to build release artifacts as release engineering does • Collecting and sorting CI tasks and ideas here • Testing and merging pull requests in the FreeBSD-ci repo • Reducing the procedures of CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Setting up public network access for the VM guest running tests • Implementing using bare metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Adding more external toolchain related jobs • Improving maturity of the hardware lab and adding more hardware under test • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don’t hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/# ports-contributing FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. Before we start with the usual statistics, portmgr is happy to announce it has successfully restarted its lurker program. The first two lurkers are pizzamig@ and se@; they will learn about the inner workings of portmgr and bring in new ideas. Portmgr also started having bi-weekly meetings, some public results are: * restarting the lurker program * fixes to ports going backwards in version * dropping DragonFlyBSD version checks in bsd.port.mk * dropping deprecation notes from ports transitively using Python 2.7 Currently we have over 46,800 ports in the Ports Tree. There are currently 2,700 open ports PRs of which 680 are unassigned. The last quarter saw 9,403 commits to the main branch by 157 committers and 683 commits to the 2022Q1 branch by 63 committers. Compared to last quarter, this means a slight drop in activity to the main branch and a slight increase in the number of open PRs. No new committers joined during the last quarter, portmgr took koobs@' commit bit in for safekeeping because of a lack of recent commits. The cluster administration team has provided portmgr with a third aarch64 builder; it is being used for package builds. Things that happened in git: * Two new USES were introduced: elfctl to change an ELF binary’s feature control note minizip to get the correct library dependency on minizip * Two keywords got removed: fcfontsdir (now handled by USES=fonts) glib-schemas, it has been replaced by a trigger * Default versions that changed: Lazarus switched to 2.2.0 PHP switched to 8.0 * Some upgrades to major ports: Chromium 100.0.4896.60 Electron 13.6.9 Firefox 99.0 Firefox ESR 91.8.0 Gnome 41 KDE Frameworks 5.92.0 ** KDE Plasma 5.24.4 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD Accessibility Links: Accessibility wiki page URL: https://wiki.freebsd.org/Accessibility List introduction, goals, audience, and ground rules URL: link:https:// lists.freebsd.org/archives/freebsd-accessibility/2021-October/000000.html Contact: Pau Amma Contact: FreeBSD accessibility discussions Over the past several months, I’ve started putting together tools and resources to help make the FreeBSD ecosystem (more) accessible to people with disabilities: • a mailing list • a set of wiki pages including resources and a categorized wish list • tooling including a searchable accessibility Bugzilla keyword and an accessibility Phabricator group I need all the help I can get with: • specifying, designing, implementing, and testing the items on the wishlist • adding to the wishlist in areas were have little or no experience or for things I missed • moving beyond software and documentation to processes and culture ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Boot Performance Improvements Links: Wiki page URL: https://wiki.freebsd.org/BootTime OS boot time comparison URL: https://www.daemonology.net/blog/ 2021-08-12-EC2-boot-time-benchmarking.html Contact: Colin Percival Colin Percival is coordinating an effort to speed up the FreeBSD boot process. For benchmarking purposes, he is primarily using an EC2 c5.xlarge instance as a reference platform and is measuring the time between when the virtual machine enters the EC2 "running" state and when it is possible to SSH into the instance. This work started in 2017, and as of the end of December 2021 the FreeBSD boot time was reduced from approximately 30 seconds to approximately 10 seconds. During 2022Q1, further improvements have shaved more time off the boot process, taking it down to roughly 8 seconds Two major issues remain outstanding: 1. The first time an EC2 instance boots, dhclient takes about 2 seconds longer than normal to get an IPv4 address. The cause of this is unknown and requires investigation. 2. IPv6 configuration includes two one-second-long sleep(1) invocations, one from /etc/rc.d/netif and the other from /etc/rc.d/rtsold. It might be possible to simply remove these; but care is needed to avoid progressing too far in the boot process before IPv6 addresses are configured. Input from IPv6 experts is required here. Issues are listed on the wiki page as they are identified; the wiki page also has instructions for performing profiling. Users are encouraged to profile the boot process on their own systems, in case they experience delays which don’t show up on the system Colin is using for testing. This work is supported by Colin’s FreeBSD/EC2 Patreon. Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ENA FreeBSD Driver Update Links: ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ ena/README Contact: Michal Krawczyk Contact: Dawid Gorecki Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: • Add IPv6 layer 4 checksum offload support to the driver • Add NUMA awareness to the driver when the RSS kernel option is enabled • Rework validation of the Tx request ID • Change lifetime of the driver’s timer service • Avoid reset triggering when the device is unresponsive Work in progress: • Prototype the driver port to the iflib framework • Tests of the incoming ENA driver release (v2.5.0) Sponsor: Amazon.com Inc ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A New GEOM Facility, gunion Contact: Marshall Kirk McKusick The gunion facility is used to track changes to a read-only disk on a writable disk. Logically, a writable disk is placed over a read-only disk. Write requests are intercepted and stored on the writable disk. Read requests are first checked to see if they have been written on the top (writable disk) and if found are returned. If they have not been written on the top disk, then they are read from the lower disk. The gunion facility can be especially useful if you have a large disk with a corrupted filesystem that you are unsure of how to repair. You can use gunion to place another disk over the corrupted disk and then attempt to repair the filesystem. If the repair fails, you can revert all the changes in the upper disk and be back to the unchanged state of the lower disk thus allowing you to try another approach to repairing it. If the repair is successful you can commit all the writes recorded on the top disk to the lower disk. Another use of the gunion facility is to try out upgrades to your system. Place the upper disk over the disk holding your filesystem that is to be upgraded and then run the upgrade on it. If it works, commit it; if it fails, revert the upgrade. The gunion(8) utility is used to create and manage an instance of a gunion. Further details and usage examples can be found in the gunion(8) manual page. At this time, gunion(8) is available only in 14.0. Sponsor: Netflix ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Realtek Wireless driver support Links: rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88 rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89 Contact: Bjoern A. Zeeb While the Intel Wireless driver update project is the main driver behind the work to bring support for newer chipsets and eventually newer IEEE 802.11 standards support, there is also an ongoing effort to support more drivers. The next two drivers in the (already longer) queue are Realtek’s rtw88 and rtw89. While the initial driver porting efforts for rtw88 and rtw89 happened on personal time, the LinuxKPI integration has to be done more and more along the Intel wireless driver work and so thanks are also due to The FreeBSD Foundation. The rtw88 driver has started to work on some machines with less than 4GB of main memory and was committed to the FreeBSD git repository for broader testing. While our version of the driver is aware of these limitations, the problem is currently assumed to be outside the driver in the interactions with LinuxKPI and busdma. The rtw89 driver has happily started to send packets and has problems receiving frames at this point. Further investigation will happen as soon as rtw88 is sorted out and it is expected that rtw89 will then also timely follow into FreeBSD’s git repository. The currently known requirements to compile both drivers have mostly gone into stable/13 and releng/13.1 already. For the latest state of the development, please check the referenced wiki pages and follow the freebsd-wireless mailing list. Sponsor: The FreeBSD Foundation (partly) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Intel Wireless driver support and LinuxKPI 802.11 compatibility layer Links: iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi Contact: Bjoern A. Zeeb The Intel Wireless driver update project aims to bring support for newer chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel driver code was ported in the past for the iwm(4) native driver; using the LinuxKPI compat framework allows us to use the driver directly and gives support to all the latest chipsets, with only minor local modifications. Some of the changes made while porting the driver to FreeBSD were kindly incorporated into the upstream Linux driver already. During the first quarter work continued with about 70 commits. Updating the driver and firmware reduced differences to the Linux version and gave us bugfixes and improvements. Changes to the LinuxKPI 802.11 compatibility layer were made to avoid firmware crashes and possible panics for users along with other improvements. Auto-loading support for LinuxKPI PCI drivers was comitted. This means that iwlwifi(4) will now load automatically during boot if a supported card is detected without any user interactions. Considering the current state of the driver and the next release a decision was made that iwm(4) supported chipsets will continue to attach to iwm(4) for now and only newer and otherwise unsupported chipsets will use the iwlwifi(4) driver. This is likely going to change in CURRENT as soon as iwlwifi(4) provides better support than iwm(4). The code was merged to the stable/13 branch and the current state will be shipped with the upcoming 13.1-RELEASE. In addition to The FreeBSD Foundation thanks need to go to all users who have been testing and reporting back or are patiently waiting for the next update. For the latest state of the development, please follow the freebsd-wireless mailing list. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Crypto changes to support WireGuard Contact: John Baldwin During the last quarter, I continued my work to improve the FreeBSD WireGuard driver. On the FreeBSD side, I added support for the XChaCha20-Poly1305 AEAD cipher. I also added a dedicated API to support [X]ChaCha20-Poly1035 on small, flat buffers. Finally, I added an API wrapper for the curve25519 implementation from libsodium. For the WireGuard driver, I wrote a series of patches which updates the driver to use crypto APIs such as those mentioned above in place of internal cipher implementations. The series also includes a fix to avoid scheduling excessive crypto tasks as well as a few other small fixes. This series is pending review. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, man-pages, or new external books/ documents. Documentation Engineering Team Link: FreeBSD Documentation Project Link: FreeBSD Documentation Project Primer for New Contributors Link: Documentation Engineering Team Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. No new documentation commit bit was granted during the last quarter, and only one commit bit was safe kept. Several tasks were completed related to the doc tree during the last quarter: • Fix some issues in the translation workflow with PO files and Weblate related to the po4a program. More info here. • Update offline documentation (PDF and HTML). The old directory /doc is now on ftp-archive; it contains files prior to the Hugo/Asciidoctor migration. • Remove Google Analytics from documentation and website. • Add last modified information to the documentation and website pages. • Tag FreeBSD docset for 13.1-RELEASE. • Add the first Indonesian translation to the doc tree. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate Link: FreeBSD Weblate Instance The translation workflow with Weblate is more mature at this point. Several issues were fixed between PO files and po4a program. We welcome everyone to try our Weblate instance to translate a few documents. The first Indonesian translation was added to the FreeBSD project. We thank Azrael JD for the contribution, and we are looking forward to seeing more Indonesian translations. Q1 2022 Status • 12 languages (1 new language) • 142 registered users Languages • Chinese (Simplified) (zh-cn) • Chinese (Traditional) (zh-tw) • Dutch (nl) • French (fr) • German (de) • Indonesian (id) - Added • Italian (it) • Norwegian (nb-no) • Persian (fa-ir) • Portuguese (pt-br) • Spanish (es) • Turkish (tr) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Work in progress) 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Work in progress) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Not started) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software from the KDE Community, along with dependencies and related software, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@ as well, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. KDE Qt Patch Collection The Qt Company did not release Qt 5.15 updates under Open Source licenses in 2021, leaving the Open Source 5.15 version lagging behind the proprietary release. Qt 6 is released under an Open Source license, but for the world of Open Source software that requires Qt 5, there is still a need for updates. The KDE Community fills that need by maintaining a curated set of patches — generally backported from Qt6 — to maintain the Open Source version of Qt 5. FreeBSD ports now use this KDE Qt Patch Collection, rather than the outdated last Qt 5.15.2 release from the Qt Company. This landed both in main and the last quarterly branch for 2021, since it brings important bugfixes. KDE Stack • KDE Plasma Desktop (all the /plasma5- ports) was updated to 5.23.5 at the start of the year. Since this happened very shortly after quarterly was branched, this was MFH’ed. The long-term-support release 5.24 landed mid-february. The FreeBSD ports do not stick to LTS releases, and will follow the regular release schedule. 5.24.3 landed on schedule in March. • KDE Gear (the collection of KDE libraries and applicatious outside of the Frameworks and Plasma Desktop groups) was updated to 21.12.1 and MFH’ed. Monthy releases landed as well: 21.12.2 in February. • KDE Frameworks have a monthly release cadence, so 5.90 landed in January, 5.91 in February and 5.92 in March. • KDE PIM currently does not support Contacts stored in a Google account because Google has changed the available REST API. • astro/kstars received its regularly scheduled updates. • deskutils/kalendar was updated. It has now reached the 1.0 stage. • deskutils/kodaskanna was added to the ports tree. It is a simple QR-code scanner for the desktop. • deskutils/latte-dock is an alternative launcher for use in KDE Plasma Desktop and other environments. It was updated to 0.10.7 as part of its monthly releases. • devel/okteta, an editor and viewer for binary data, was updated to 0.26.7, a regular bugfix release. • graphics/digikam, the digital photography manager, was updated to 7.6.0. (Thanks Dima Panov) • graphics/kf5-kimageformats has a new option enabling libheif and HEIC support. • graphics/kontrast was added to the 'accessibility' category. This is a tool for checking color-combinations (e.g. for a website) for sufficient contrast and readability. • graphics/krita was updated to the next big release, Krita 5. (Thanks Max Brazhnikov) • lang/kross-interpreters was fixed for Ruby 3. (Thanks Yasuhiro Kimura) • sysutils/plasma5-discover was updated to resolve some denial-of-service bugs in KDE infrastructure. • www/falkon was updated. After a two-year wait, a new release of the KDE web browser built on Qt WebEngine (itself a wrapper around Chromium internals) arrived upstream and in ports. • x11/plasma5-plasma-workspace now can properly edit login and account information. Related Applications • devel/qtcreator was updated to version 6. A new versioning model has been introduced by upstream, so this will now jump by major release number regularly. (Thanks to Florian Walpen) • irc/quassel was updated. Quassel is a distributed IRC client (think of it as your own personal IRC bouncer). • misc/tellico was updated. Tellico is a "collection manager", for instance collections of books, music, stamps, or FreeBSD releases. • net-im/nheko was updated. This is one of a dozen Matrix clients available in the ports tree. Elsewhere • archivers/7-zip is the preferred tool for dealing with 7zip files; this affacts KDE applications that work with archives (like archivers/ark). We would like to thank makc@ for stewarding that update. • devel/libphonenumber has bi-weekly updates to chase the exciting world of telephony details. • graphics/poppler was updated to version 22.01. This version requires C17, which pushes a number of consumers to the newer C standard as well. Most consumers were fixed in advance. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Office Team Links: The FreeBSD Office project URL: https://wiki.freebsd.org/Office The FreeBSD Office mailing list URL: https://lists.freebsd.org/subscription/ freebsd-office Contact: FreeBSD Office team ML Contact: Dima Panov Contact: Li-Wen Hsu The FreeBSD Office team works on a number of office-related software suites and tools such as OpenOffice and LibreOffice. Work during this quarter was focused on providing the latest stable release of LibreOffice suite and companion apps to all FreeBSD users. During the 2022Q1 period we pushed maintenance patches for the LibreOffice 7.2 port to the quarterly branch and brought the latest, 7.3, releases and all companion libraries such as MDDS, libIxion and more to the ports tree. Also we are still working on the Boost WIP repository to bring the latest Boost library to the ports. We are looking for people to help with the open tasks: • The open bugs list contains all filed issues which need some attention • Upstream local patches in ports Patches, comments and objections are always welcome in the mailing list and Bugzilla. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ lang/gcc* ports need some love and attention Links: GCC Project URL: https://gcc.gnu.org GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ Contact: toolchain@FreeBSD.org Contact: Gerald Pfeifer After about two decades of maintaining FreeBSD’s lang/gcc* ports, the time came to hand over the baton and mostly step back. Alas the baton essentially dropped to the floor, despite multiple calls for help. Here are a few specific tasks looking for help: • Upgrade GCC_DEFAULT in Mk/bsd.default-versions.mk from 10 to 11, including fixing the (luckily minor) fall out of an -exp run: https:// bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378 • Three changes to work through with upstream GCC (requires src expertise, not ports): □ upstreaming lang/gcc11/patch-gets-no-more □ upstreaming lang/gcc11/patch-arm-unwind-cxx-support □ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874 • We have removed the unmaintained lang/gcc9-devel and lang/gcc10-devel ports, alas kept lang/gcc11-devel and lang/gcc12-devel which would be good to see if not weekly, then somewhat regular updates. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ PortConfig Links: Repository portconfig URL: https://gitlab.com/alfix/portconfig/ Contact: Alfonso Sabato Siciliano (upstream) Contact: Baptiste Daroussin (port) FreeBSD provides the Ports Collection to give users and administrators a simple way to install applications. It is possible to configure a port before the building and installation. PortConfig is an utility for setting the port options via a Text User Interface. As each terminal has different properties PortConfig can be customized via environment variables to set up the User Interface, for example: menu size, theme, borders, and so on; each feature is documented inside the manual. Further, if a port has a specific 'pkg-help' file, PortConfig will show a Help button to open a "popup" with help information. FreeBSD provides thousands of ports therefore it is not feasible to test PortConfig for each use; please report any problem. Alfonso would like to thank Baptiste Daroussin for the port, suggestions, help, and testing for this utility and its library. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wifibox: Use Linux to drive your wireless card on FreeBSD Links: Project GitHub Page net/wifibox port Contact: PÁLI Gábor János Wifibox is an experimental project for exploring the ways of deploying a virtualized Linux guest to drive wireless networking cards on the FreeBSD host system. There have been guides on the Internet to suggest the use of such techniques to improve the wireless networking experience, of which Wifibox aims to implement as a single easy-to-use software package. • bhyve(8) is utilized to run the embedded Linux system. This helps to achieve low resource footprint. It requires an x64 CPU with I/O MMU (AMD-Vi, Intel VT-d), ~150 MB physical memory, and some disk space available for the guest virtual disk image, which can be even ~30 MB only in certain cases. It works with FreeBSD 12 and later, some cards may require a recent 13-STABLE though. • The guest is constructed using Alpine Linux, a security-oriented, lightweight distribution based on musl libc and BusyBox. • Configuration files are shared with the host system. The guest uses wpa_supplicant(8) so it is possible to import the host’s wpa_supplicant.conf(8) file without any changes. • When configured, wpa_supplicant(8) control sockets could be exposed by the guest, which enables use of related utilities directly from the host, such as wpa_cli(8) or wpa_gui(8) from the net/wpa_supplicant_gui port/package. • Everything is shipped in a single package that can be easily installed and removed. This comes with an rc(8) system service that automatically launches the guest on boot and stops it on shutdown. • A workaround is supplied for laptops to support suspend/resume. Wifibox has been mainly tested with Intel chipsets so far, and it has shown great performance and stability. Therefore it might serve as an interim solution until the Intel Wireless support becomes mature enough. It was confirmed that Wifibox works with Atheros chipsets too, and feedback is more than welcome about others. Support for Broadcom chipsets is not yet complete, that is currently a work in progress. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. helloSystem Links: Documentation URL: https://hellosystem.github.io/ Contact: Simon Peter Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.org on Matrix What is helloSystem? helloSystem is FreeBSD preconfigured as a desktop operating system with a focus on simplicity, elegance, and usability. Its design follows the “Less, but better” philosophy. Q1 2022 Status • Version 0.8.0 of helloSystem is under development and test □ helloSystem 0.8.0 will be based on FreeBSD 13.1-RELEASE □ Experimental Live ISOs using FreeBSD 13.1-BETA3 are available □ Initial support for running Linux AppImage files using an optional Debian runtime □ Initial support for the AppImage format in the user interface □ Improved reliability and performance of mounted archives by using fuse-archive □ Various bugfixes Installable experimental Live ISO images are available at https://github.com/ helloSystem/ISO/releases/tag/experimental-13.1. Contributing The project appreciates contributions in various areas. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on github URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. As a result of production testing in a real-world cluster deployment, pot and related projects received stability improvements for controlling the pot lifecycle (i.e., pot prepare/start/stop). Various attributes and commands have been developed to improve support of nomad orchestration and batch jobs (e.g., change dns config during clone, ability to disable tmpfs, new last-run-stats command). A new pot release will follow soon. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a repository of pot flavours and complete container images for usage with pot and in many cases nomad. Many of the core images like Nomad, Consul and Vault that can be used to build a private cloud and orchestration platform, but also e.g. Prometheus or PostgreSQL Patroni, have reached a stable status over the last quarter and are in production use now. To make navigating the evolving pot ecosystem easier, most project resources have been centralized in a dedicated github project: https://github.com/bsdpot There, we plan to release ansible playbooks that allow easily creating a FreeBSD based orchestration environment from scratch based on all these tools. As always, feedback and patches are welcome. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Fpart and fpsync Links: Project site and documentation URL: https://www.fpart.org Development URL: https://github.com/martymac/fpart Port URL: https://www.freshports.org/sysutils/fpart Contact: Ganael Laplanche What is fpart ? Fpart is a filesystem partitioner. It helps you sort file trees and pack them into bags ("partitions"). It uses FreeBSD’s fts(3) implementation (GNU/Linux builds can also use it as an option), which makes it crawl filesystems very fast. A hook facility is provided to trigger actions on the partitions produced. What is fpsync ? Fpsync is a companion script that uses fpart under the hood to parallelize rsync(1) or cpio(1) jobs, making it a simple but powerful data migration tool. Those jobs can be run either locally or remotely (using SSH). Fpsync is often used by researchers and cloud providers where lots of data need to be moved and clusters are available to speed up transfers. Q1 2022 Status Both tools continued to evolve and saw several bugs fixed; see the changelog. Also, a user reported a major bug regarding our fts(3) implementation, which ignores readdir(3) errors. I have reported the bug in our Bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262038 It should be merged soon (hopefully). Last but not least, fpart has been referenced in the French Government’s 'SILL' . Contributing If you are interested in contributing, have a look at the TODO list. Any contribution is welcome, more especially in the field of unit testing. From nobody Sat Jun 11 19:37:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D41B485EF93; Sat, 11 Jun 2022 19:37:21 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LL7Q90K0jz4lj9; Sat, 11 Jun 2022 19:37:21 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Date: Sat, 11 Jun 2022 19:37:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail3; t=1654976233; x=1655235433; bh=TiAlbD/e9tmk3zY9lWJZCbi1UQxXEX+UQ+QP1gfi6Ug=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=OPOB4PfPlqe27KlUSCckjVWGTMb2NsFIP+Z4aD3uvr3LhAo6W0A8UtpwA6bpRswd/ Zf6X2FbhrQQ+wQJFHCNN7KfUxJOSVuouunkHrGTchTJ8AEP+fwEn9Bc1rZkPaJMyd0 EDYNaKrGA8I3IrSQmBJR7B02vjvFL1qxJ0oZRnvuwWje/OM756gfTowgZu2MuMAeKy LeAEs58TJOM9DjtzuYOa5r6sd7vqtrgflWdlGi5nCCz0Zh8cOZnhpk8ejFQkOLj/ic pBsgwcf4St6p6lIKltjwWKPJMPFFN4VMTCg39W0ciCTrCnmK7TgiO/2xIwA1F/fHKT WuhwWTct3dchw== To: Dmitry Salychev From: Lorenzo Salvadore Cc: Lorenzo Salvadore , freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Reply-To: Lorenzo Salvadore Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022 Message-ID: In-Reply-To: References: Feedback-ID: 8540510:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LL7Q90K0jz4lj9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=OPOB4PfP; dmarc=pass (policy=quarantine) header.from=protonmail.ch; spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.40.133 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch X-Spamd-Result: default: False [-3.25 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch]; R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.29)[-0.289]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[protonmail.ch:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine]; NEURAL_HAM_SHORT(-0.96)[-0.962]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Saturday, June 11th, 2022 at 21:04, Dmitry Salychev wro= te: > > > Hi, > > So, you didn't like initial DPAA2 support :( > Of course we like it, but unfortunately, this quarter has been very difficu= lt for the quarterly team and we had many errors. In that case, I made a typo in the new automatic tools and the Architectures section disappeared. I counte= d reports, but another typo in another report made me count it twice so I did= not notice that yours was missing. I am fixing the issue and your report will soon appear on the website. I am very sorry. Lorenzo Salvadore From nobody Sat Jun 11 20:30:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3627683ABF1; Sat, 11 Jun 2022 20:30:50 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LL8bs4PRVz4yCn; Sat, 11 Jun 2022 20:30:49 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Date: Sat, 11 Jun 2022 20:30:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail3; t=1654979447; x=1655238647; bh=ivPv3DcTASkmxOo/7fEWn+GVM/tuDu/uTdrloGYzYMg=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=LeVyvD73FNkNlSz6KXxAvBuIxwQgOmRlrvgl/WNqsVO/PWr6WajyMBS/dPc4cHtY4 BEWIUG39ul8zPQFNXKk46h6Sdm0i3j1DTu9ax9girIU4wp/lLCWbx+paZTgUyduK33 kTRKiprqEFvT4uwTHpvvwPUh2HjsvQx2hwKLX5NMx4ekKcO/obG9H7w/GFvvE26Zuw 8g8xt4uf+jaiSBhIqHFmj/ZnFt/kBWR8RrMr/si1M3S3IgmFbUBYzsWyt1kU9k74LZ nCr01SXOnLnHHLGwYCJITD9GDX6kauO57Itmf3MsEO8QSTy1zFoFChV5Tf+D4xHyKG r+SzdoufAWZng== To: Dmitry Salychev From: Lorenzo Salvadore Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Reply-To: Lorenzo Salvadore Subject: Re: FreeBSD Quarterly Status Report First Quarter 2022 Message-ID: In-Reply-To: References: Feedback-ID: 8540510:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LL8bs4PRVz4yCn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=LeVyvD73; dmarc=pass (policy=quarantine) header.from=protonmail.ch; spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.40.131 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch X-Spamd-Result: default: False [-3.48 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch]; R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-0.49)[-0.491]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[protonmail.ch:+]; DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine]; NEURAL_HAM_SHORT(-0.99)[-0.993]; MLMMJ_DEST(0.00)[freebsd-current,freebsd-hackers,freebsd-stable]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Saturday, June 11th, 2022 at 21:37, Lorenzo Salvadore wrote: > > > ------- Original Message ------- > On Saturday, June 11th, 2022 at 21:04, Dmitry Salychev dsl@mcusim.org wro= te: > > > > > Hi, > > > > So, you didn't like initial DPAA2 support :( > > > Of course we like it, but unfortunately, this quarter has been very diffi= cult for > the quarterly team and we had many errors. In that case, I made a typo in > the new automatic tools and the Architectures section disappeared. I coun= ted > reports, but another typo in another report made me count it twice so I d= id not > notice that yours was missing. > > I am fixing the issue and your report will soon appear on the website. > > I am very sorry. Your report is now online: https://www.freebsd.org/status/report-2022-01-2022-03/#_nxp_dpaa2_support Sorry again for the mistake, Lorenzo Salvadore From nobody Sat Jun 11 20:50:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C1A584469E for ; Sat, 11 Jun 2022 21:02:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LL9Hx2hZgz58ft for ; Sat, 11 Jun 2022 21:02:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654981318; bh=sLgKvcdjJqYKOlHZJGuJI7WSsFxPMclg6E92QN6TeMU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=AOveNrKoRJxVsTgv0Fp0pbg6vEqbUFzXyTdlLZHS1IyUe6XTzdBbucwUArJNCbPEH6yNmMuqZEzVO3gtRMDpDjwgqgCF99gBvtWRgfPA7Amqvx+L6v8lpPPuK4deS+FwZd+7gFFMYYn3a2wQisdd9oYyJM8/CtoHcYcO/Xbg+aro9qKqo1VKjJtr0+tpJ1OXgdBnxdKyemxKnepKFycIhFEZv4Y3rCHyC90riNXpCJnKIzkHEddVpMM1mN+6KO4vibtPIgqOaM/mkWSWoFscodv5QEzbnh1gq5fWKa/yadjlMcArTZhpPfkpkwCZ1JJQwFDLTNUI5QQSD5CUEKhatg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654981318; bh=mlVPX7D4XMl+dWiFFHMaPCq7e6FY9vbvwUzFMbYQwy2=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kB9EkwevSwUOn6v+M9e/awwbFhIm3wBH61wR8zUwVAdazjpLw2ILx8Axx9EnnuyF6JDt4tpueePBwkO5pGyW21FRVQguflDJ3m3gsAwYjREVzCJ7/xpMuNY6lqd09j68ajlCNef0c70YdwwJPu17nA0qH3cCrJ7ZwxgQQrYN5MneIw/eMahzTsIrnd64oHW1NYN99wQQ/mSXFawsh46fMJzv53kQ3//bf7iEqr0HpqeT/UUh+A8gdLfhQqOEn1r0f0mqo/hacp+mBSMuK+lqXD2aQKjxtFl2Qqxqt3XeNKghmMERAS3IDNoQORhE0W4I22wMsx8PoAJSyccpjvYd3A== X-YMail-OSG: roaru7oVM1n7ccCjCsYRZrB9EM4CfcNw4BJJubA2o1G_lyfBGzVQjhvSvTRUFM4 v8mB.EMfL93hZrEBa6LEGnGa1_LudvRuXx6ALsEPJn3NlgIVY7uT.GFTegeB0An1S.8_gOls6xxu T0r4ub9dnawju7V70Qv.o0yDS0hhsjWzSrdqNtYcyblqrr7yJhL8w27WravENyyiGhxFsgKlLVjV A6j4mNoLPdsxW8MFrszMSRc9qcrfTwPiai1oIiwglL1osuC3PG0zHVgXF3_EgFq_OI.IwBBsaxPb MPVh.j._ofOthI6fpksxndlCAHJyDHSI0T3B.glSwK.RloaXaKL8M08mkYp19PbtuZ88AQpBDu_K 1AfRgf6_kA0zZ5a8nOavUlE9l8wBuuSJm5QQyL2UGBLTeKONFhF4y2fMlitzSvPvgLDUbhtqrsx6 2uf3GKIhA08_A6HE5_OLzw00fVn6KvqnptMH7Et_SnUmXugOXoqEGbRmMrm2Qqzoe.N2gR4vk8nt 2jrvC4Z8.4DM6YqOle1cSAxdqjdf0.QSoFAwoAiIG4056cgBH0Gr9i37cRwh12c8c6cn6W7N7gYW rK_GYLmRh0WaGDY5YTOPY1SX_VEeX7aTFvQ0zf11B0VlU3DDURlaHgbleXH1VRa1vCz5_ickbyZw _HnyIWhUNLjSJiGiBXa04B0V7LlbnWJj3gqmqeJgmygouyb1AyiIWx4jPXt.5BGauZG23RQ_ZzOt 5cj99qMxsDBDdJW1qeDzc1zD6xUGCU6ulZsLhC8NcjPKWVSoEvDIKtFUi8lxvCmqPlJ3WJ2M5T0H KVQqOOrmKO4u6wCfL1FwLalK_H11_tRS8cBFRkU_wH.RLZB0H4pwXEd_eJVL23QdrI35zgC5WtqP 83VuiHUapxuktvacr9KBps8xoGOpflPY17Nag4j5JqFmdogOOtBpcLIXw8esnwxAgoWj7gQdA4l. Za4fX.AN0HqY2CtfTnKdY_6hacVkfubxxBzP0gHiwft6Feo_Kd1EdhKs_aJAaSkl34I6j0I67.d0 .GxPRp0v2Tn44ldtyWTzOTcpRympSv7NaIkQRsI0Z_4gEtCEaH5J6STDKIF7w68iSME27Cc.HxvZ w0C4beClbhSkiu1EaTm1oF2ul36K9RiEWcfvcdEV55VaWSlRl04f4_1CtJrwUY8yiZTOipAC2ad0 TIpZa.jqBXzgzBbBE36AwlLMtmAPmsviDIbnyKB09G.xAqsL4f38WJ2sfBFQxQx_9S7zSvSbWx0p PnFSg.2wyrcFMSW0rFBs75pwWmpvDf4bWAqgNjiWWubdHWx51RfPLQjBK._BP0mmA9pmA0JX6rLA k5y84S3bA35lovpSRvEtHX8B65frEfCzqOax_Dmv0YnW2dmdz0mA4i3aGKyQbs8r6pjug1pgFMaS w6GV0vk9HRXqOP1HsiSvROLLK83B6_ulDuIjEduwTXz.0QDRQFUrxF4HFi110ACbWhJSKFiZ1gf_ puR.gNhMJ4.d0VRhb7tJmfORfgXZZo0..KtbtWUAprWUm8e3FYMZFdtE8xte0IEhdLmXnjPOqrXM 7HJnqZdY086MV5hsuzC.oELvqoPo98ULIJwMbFDal_.JBI_X52RH9hyhFodaJnqlIrGhaLbIRf7L Kijo3cMqgW0PNlOEAxW.E7hgK0hnuwZ7ibb1Cu97F1z7O0nRm48wHaD7hd9piSKivy0yuFI0wqwJ Hhz6HAXD_osmJHUevhPjCnV3YB_rvdQQWAkmCaVzzpakvJMYe00u7bFt72RAH89WLy8mWPDhoe1n 0Z.5SJ.J7V3aDvZvzb_MZJlSW1vFuORPO_o0qudhj2ptJCAu_QLX6WnHeNGsR4KVHMBvDA9fkbcJ zI5uXr0MVBZrSY6xcWHCOn_sJU2TD78UNONxrjiOvxUCSs1kX7MiWVSpBIZWUwH3ONl9ifl13yBP LSOvPu.tv7TesQW.DHjDFayk5ndioY8lnUIqcq0sgyDul2Kz8QgeqAAzzrEfGrMfQBRxMWK14uhd CA1xN1yxETVpkr5aaKeLfZc1.itS3YKBh2az7CnwnFJ9xThvrJoR5mv.GLK.7ID8INTs81mzNdnY lHoOFvkasLB305A4khH0J2GJsQ9hG8ltXWbOVH_o7utWburzzMn5dDy4rF2IPpmLNEEMh.hk9At6 fmHBj9hjdM38pL4aFI6FAxDGJsY6TWI9BDAT8fWMBniPdorRGStgUUDtXOF2Pkv03SHbaP1.2LtI CgPl2nKftW4vhtetGOdXU.0OVpCPw8.CA8A2jtW_W9RdTbAhqSDl.NYUPyeu1xy4loAjE1aKOpCn tyNmJZ5w1eDSwhw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jun 2022 21:01:58 +0000 Received: by hermes--canary-production-bf1-856dbf94db-ld7kl (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a5c9608f4c757d9064632a83eabd0cdb; Sat, 11 Jun 2022 20:50:53 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Any clue why "df -m" vs. "du -xsAm" get such different results for the tmpfs in question (403 MiBytes vs. 101 MiBytes)? Date: Sat, 11 Jun 2022 13:50:50 -0700 References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> <82ffa6bb-5826-62b6-2b82-a735b183272f@grosbein.net> <2F1A9EE0-FB9E-4BBF-AF76-4E5AD372FCC1@yahoo.com> To: Eugene Grosbein , Stefan Esser , Robert Clausecker , Bryan Drewery , FreeBSD Hackers In-Reply-To: <2F1A9EE0-FB9E-4BBF-AF76-4E5AD372FCC1@yahoo.com> Message-Id: <69FDC72E-F1DB-449F-A9C1-25827895E6B3@yahoo.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LL9Hx2hZgz58ft X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=AOveNrKo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.35 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.86)[-0.856]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N [I've deleted prior parts of the exchange.] I finally have a hypothesis with some evidence about what primarily contributes to the 400 or so "1M-blocks Used" in: # df -mi /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted = on tmpfs 1024 400 623 39% 103659 3828501 3% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p --where the poudriere-devel is using USE_TMPFS=3D"data" for a "bulk -a -c" (that has been running for a little over 2 weeks now and is past 1/3 done). Taking a quick estimate of the file count in . . ./ref/.p/var/cache/ I get: # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = wc 82146 821452 7942485 Taking 82146*4096 I get: 336,470,016 Taking 336,470,016 / 1024 / 1024 I get around: 320 Mi By contrast: # du -xsAm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ 46 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ But: # du -xsm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ 295 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ and: # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 319 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ This is all after having done a swapoff for the 2 swap partitions and a swap on for both and then waiting a while with the "bulk -a -c" still running throughout and after. (So under 82 MiBytes is in use in swap space at this point.) poudriere's tmpfs usage reporting does not seem to cover this area's tmpfs usage. But, at least for "bulk -a -c" kinds of activity, it ends up being the majority of the tmpfs usage for USE_TMPFS=3D"data" types of configuration. For reference: # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = more total 301234 drwxr-xr-x 2 root wheel 5257152 May 28 02:31:26 2022 . drwxr-xr-x 4 root wheel 128 May 28 01:56:42 2022 .. -rw-r--r-- 1 root wheel 2 May 28 02:26:40 2022 = builder_active%01 -rw-r--r-- 1 root wheel 2 May 28 02:31:24 2022 = builder_active%02 -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%03 -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%04 -rw-r--r-- 1 root wheel 18 May 28 01:56:51 2022 = originspec-pkgname%accessibility_accerciser -rw-r--r-- 1 root wheel 19 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-atk -rw-r--r-- 1 root wheel 20 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-core -rw-r--r-- 1 root wheel 11 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atk -rw-r--r-- 1 root wheel 13 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atkmm -rw-r--r-- 1 root wheel 17 May 28 01:56:51 2022 = originspec-pkgname%accessibility_caribou . . . -rw-r--r-- 1 root wheel 17 May 28 01:56:55 2022 = pkgname-originspec%zutils-1.11 -rw-r--r-- 1 root wheel 15 May 28 02:03:32 2022 = pkgname-originspec%zxfer-1.1.7 -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zxid-1.42_1 -rw-r--r-- 1 root wheel 19 May 28 02:04:03 2022 = pkgname-originspec%zxing-cpp-1.3.0 -rw-r--r-- 1 root wheel 12 May 28 01:59:41 2022 = pkgname-originspec%zydis-3.1.0 -rw-r--r-- 1 root wheel 18 May 28 01:57:13 2022 = pkgname-originspec%zynaddsubfx-3.0.6,2 -rw-r--r-- 1 root wheel 9 May 28 02:02:07 2022 = pkgname-originspec%zyre-2.0.1 -rw-r--r-- 1 root wheel 14 May 28 01:59:41 2022 = pkgname-originspec%zziplib-0.13.72_1 -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zzuf-0.13_1 -rw-r--r-- 1 root wheel 13 May 28 01:56:45 2022 = ports_metadata%top_git_hash -rw-r--r-- 1 root wheel 4 May 28 01:56:49 2022 = ports_metadata%top_unclean =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jun 11 22:03:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 88074857CF1 for ; Sat, 11 Jun 2022 22:03:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LLBfx62Nzz3MBl for ; Sat, 11 Jun 2022 22:03:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654985010; bh=gHSNcZ1bzQxC1C5xhvLBmw49ce4c6R3aLyrDB/c2Vjg=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=ComyDIIOS0Jt+O/deI/f6+6rZRI+YIYGD8oo5QHC/I+m2+BIBxaGZh10C6FrkzrD7kzR2jLOm5zkXUGVAZbV2cuGN36rJ/xTVOJwAhpIlgiXj4Cken9qVgxB5ynNHhHt0gumBpOZdj9NaM0WoWTO3IP33fHmRN0OjS3l5P7kjU7d6ISRgqkFXHYNAoefhoCCR+bZHZGBHXGZLSCU08SxZVeOqeHBzIQKfykmb+3pt5vkh9Yj0Wuj8o+weaA6qP+5rInXShmyMfLG0yCIypR6GlBQZxQ1SaJlGpkY70Vokh4kaBnoF2JOc2gtneLUZrI6f9pBfApu9GhZ6OxpE2OdnA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654985010; bh=s+IN+ldFmTQMvInWV9+v+a0L6RW9iVGapoTj+bZWINP=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ei7fdICkvxH+7HA4a4HD7nqQmDmfdXb8Nk9Jd7+e1O32JhWqLkMeXc/rDdwS6MQvJXJnGKE6qqa5XFHE3xaeICwy/7xjxfn0piO2b9oPP3FqedYsVuMjuWC5lh2GeWrPZo/Eozh+984qDkPC3YqkWZc6MCrmLXETCSe8tEhpfsma74IfXMN22XCw4YZi5SlbKktZyKkx3l/fX+yXNUDJGnkRK+sHnWtw4Wz9T9kBtXKL6nzpVxpcdn7/+dpiG0mT2KrAFtssLOEiPfTeD9smSr38tAGrX/nUcE+11a/4It72bqBErQEyk3gr3Qe0zlV189eTYsEl0Z+MK1bCJkwNjg== X-YMail-OSG: JKkhpVAVM1m_UAmtdsWXjb4I4u0QBBhUYfgR6fhcmE4Aoj67JUWkXFTWsICU3VZ S6mwji.iyz274nN1Fk0qciz.nuqzIkSS4ZBp1rf6k3jnuFvuqHB6.8lrvk8ldcvgz3_qxC2IwEcf 8cprCvBPC.2JZFlm1DjkLhQv4xGAl9Sx9aGnxdLLZQ.4BaXI5xu52__IBhRhGt.QcVaYDALROcNC l8A218EhNyj64E07Sb0q9Ig8ssYw.3P9zNHjg_nb15jdi5OeT1T5PWf1SZddLYvx1dz93BsI2AP0 Tr6L7L7blyfoRLSy4IKXMy3bZrW.omFoXailHPzvjvVFPJkXCv4A_a.hXtDazxo7COy0m8F_N2wk _onXnPLu7uM_bR1as16bEcMTe0Ow8A3ejkaUrnZJgAUSfB0rt8BQTnOud2wFx98Ilj7.PkKyek9o Ppcj5yrx1UbJ0SPXDxjJLBzvjRmOEOnFf4XDUZWeUGUr3QIEI76WjHpffEKhXy2new0RQdcgbiLX 7yklRT5x7mAcVWaBdGj9vD.mUlZ.i68lNA2r1gR6UGLzmlfBKNkDufq7Qfe_uce0gcAhzcrkaOSl ZsT1nSDHBl_5DfUiFT7ktF6CxYHKonUhwNm3MoD9T7DP0T6nMnBoRHYGp9eE49kfBay_qiuy5VGW nze5jD8xV_D58VsErgDwlYsKm2sD6lGGj8PJBAv.ycGFUSMcR.k_ERIUqpq2ztsw5P5dH8QNgAG4 gOpHR7Z5fUVwI0Z88UaJCCxj5iQz1rHTFkGCHEY.FhPmzbOHb4B6TIAjaOMFiZQMAld4RGnoHo4L dNLRGJZnZeYrQB1grhH.MbvoRzR6sE2pWpcIjO84.PVL18kNY6zkJ4vZrTrLB2iRDKbb5ClTJgmR hwMT1H3g7ufHrC6pEgeqDPPxOe5JJ07mdWdb6WBC.7vKuRJ1aKf43wxs9EsE5GQepFSSr2rBu93U nJ7SjQfxaHKb9..sKL.P4RZIvibz3.qVcUDNQQhzI4737AxEcUjsstls2kdUpbdC4QOeq3fGNLjp gzta_iOOSpeJVvEAXR3c.wZ_vAhNXewTG8SklV1DBLYgqHUx4upAo710YMBy8r8NNK8o6kzcys5y vVHkpQAq0NkObVNGmIgwiLghLCxnyTXjamLNhfS0EN6VrjGRYn7s_SGd7ePU_2_ljgR9Lk6ORE44 6cdpXsB3IyOLeqQUC5xSTmYTsCWEtl5wI.HxXHBReoUtd8TpZwSnmr3Nf7SjeZiT6.qKTQGJFLxS 9sVJ30se6KBHruf8.62WblD.AbLwmT4Q4cDTBV8.k4lUQsN4EdZMmaFDhLK5N2cLPOnaSxuDHLdm .ldvN2_KYtLoht7wAnfMD1I12n6PVB_dI4CW0Lptlif0guBF.Hx5j5y1PoUMfZ0.MaeEKge3XL2n Fx6HQCqoLgoFfT5SQHgYllLCY9bmT3NsdR9bfnACKC8QPbnlX3TtJivgbrd0LE527kTppEGeA690 QEx8THAGDtvtpM3Vz2nbTeAN_CP18qhad8p1ykdK8t0wkBxcvCVE2xZjPmBpIvJdsiAx2t9nNc7Y f055NkCqnsulV43j4y3FGno2tA5h_.7LzPNn1TIoF2k1e0LVChuRyJLcG1tCOg7a3khMPjHWfYk3 Ct38EOjxRZqbv57_oMJayCr_92fkLXOSu0LQSouSluOZzrX1Jm.TcXNIFlQihbevjJ0A_LzQ9Bxy 3FLnmI3YG7QIvb8jzyOsrxazX_p2Be5AEUVLb6yOmiZFxwKDRMvvCh1xIk1_T5k0LcNdkiwjioKH JDIdqRFtO3rzLijVKjLJV0uF7H16m1rfWhnfKNNCxO3YFW4lR_UFZNx_1zzKGYOg043EzlR4TZce G9pm_p0H0A2xtGQSHWId0CYoebvKgcCzBYOm5dn.0bFufcoBUGTjxAB5EzT4239wOIQIMuIC_IPB SI9r0kSpSKTCg1bDP8ZgTDumlK8AE_Bw6mXj5mzxKptWqiFAVWHoblp0JnJ7CXfJ_YI6t9OuVLxi tcrKaYpLXT5blqMpWFThEa_0.jjWOAj6NHd0W9BR.HhWYrK5NpwQ9Tb3oinAfvc4GLw25FSpvFcG TEv5zXEm38wTSMRsS8S6v_gllLDJoNlzV0lwtpgAHAE15IHuCrqGJR5n1C14oCiNfYdG3sz8KfX9 OGF3XtN3utSJxOolc2Y5Q2UgDYznh2BQMaOkkIZ.cKE4aUD8Jq3meAdSsZJx1aVfb1v4Ztur03qA 8VAKvsgHO6.k4eQgwbCPFeTXzGfuMe8fg7pOUBfhUDafm7w7WqVhfjWOX3qTWWEhw_0q2caOMeCl 9_sAK3hQkPjwr X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jun 2022 22:03:30 +0000 Received: by hermes--canary-production-ne1-799d7bd497-d2s2t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 76c2580bb58dc5f20940b8590d31106f; Sat, 11 Jun 2022 22:03:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: (Retitled!) /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p (example) USE_TMPFS="data" tmpfs usage for poudriere Date: Sat, 11 Jun 2022 15:03:26 -0700 References: <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325.ref@yahoo.com> <4997AB05-8CD4-4A2C-AAB3-34F6DB2CE325@yahoo.com> <82ffa6bb-5826-62b6-2b82-a735b183272f@grosbein.net> <2F1A9EE0-FB9E-4BBF-AF76-4E5AD372FCC1@yahoo.com> <69FDC72E-F1DB-449F-A9C1-25827895E6B3@yahoo.com> To: Bryan Drewery , FreeBSD Hackers In-Reply-To: <69FDC72E-F1DB-449F-A9C1-25827895E6B3@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LLBfx62Nzz3MBl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ComyDIIO; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.31 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.54 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; SUBJECT_HAS_EXCLAIM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.93)[0.935]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.31:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 2022-Jun-11, at 13:50, Mark Millard wrote: > [I've deleted prior parts of the exchange.] >=20 > I finally have a hypothesis with some evidence about what > primarily contributes to the 400 or so "1M-blocks Used" in: >=20 > # df -mi /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ > Filesystem 1M-blocks Used Avail Capacity iused ifree %iused Mounted = on > tmpfs 1024 400 623 39% 103659 3828501 3% = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p >=20 > --where the poudriere-devel is using USE_TMPFS=3D"data" for a > "bulk -a -c" (that has been running for a little over 2 weeks > now and is past 1/3 done). >=20 > Taking a quick estimate of the file count in . . ./ref/.p/var/cache/ > I get: >=20 > # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = wc > 82146 821452 7942485 >=20 > Taking 82146*4096 I get: 336,470,016 > Taking 336,470,016 / 1024 / 1024 I get around: 320 Mi >=20 > By contrast: >=20 > # du -xsAm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ > 46 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ >=20 > But: >=20 > # du -xsm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ > 295 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ >=20 > and: >=20 > # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ > 319 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ I see that a little relevant material you have not been able to see because of what I omitted from earlier messages --messages not sent to you at the time. In my earlier messages I'd shown: # du -xsAm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 101 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p 68 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p so -xsm resulsts were smaller than -xsAm results and way smaller than the "df -m" results. The 101-ish -xsAm result for .p/ has stayed fairly consistent. It appears that the swapoff activity mentioned below changed the -xsm results by forcing tmpfs material back into RAM. This ends up explaining the original 403 MiBytes vs. 101 MiBytes question that was mentioned in the original message subject. I mention this as it would appear to be important to trying to replicate or otherwise test the issue: Context matters for interpreting "du -xsm" results for tmpfs from what I can tell. > This is all after having done a swapoff for the 2 swap partitions > and a swap on for both and then waiting a while with the "bulk -a -c" > still running throughout and after. (So under 82 MiBytes is in > use in swap space at this point.) The above seems to be what lead to my "du -xsm" result being fairly close to the "df -m" result. > poudriere's tmpfs usage reporting does not seem to cover this > area's tmpfs usage. But, at least for "bulk -a -c" kinds of > activity, it ends up being the majority of the tmpfs usage for > USE_TMPFS=3D"data" types of configuration. >=20 > For reference: >=20 > # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = more > total 301234 > drwxr-xr-x 2 root wheel 5257152 May 28 02:31:26 2022 . > drwxr-xr-x 4 root wheel 128 May 28 01:56:42 2022 .. > -rw-r--r-- 1 root wheel 2 May 28 02:26:40 2022 = builder_active%01 > -rw-r--r-- 1 root wheel 2 May 28 02:31:24 2022 = builder_active%02 > -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%03 > -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%04 > -rw-r--r-- 1 root wheel 18 May 28 01:56:51 2022 = originspec-pkgname%accessibility_accerciser > -rw-r--r-- 1 root wheel 19 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-atk > -rw-r--r-- 1 root wheel 20 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-core > -rw-r--r-- 1 root wheel 11 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atk > -rw-r--r-- 1 root wheel 13 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atkmm > -rw-r--r-- 1 root wheel 17 May 28 01:56:51 2022 = originspec-pkgname%accessibility_caribou > . . . > -rw-r--r-- 1 root wheel 17 May 28 01:56:55 2022 = pkgname-originspec%zutils-1.11 > -rw-r--r-- 1 root wheel 15 May 28 02:03:32 2022 = pkgname-originspec%zxfer-1.1.7 > -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zxid-1.42_1 > -rw-r--r-- 1 root wheel 19 May 28 02:04:03 2022 = pkgname-originspec%zxing-cpp-1.3.0 > -rw-r--r-- 1 root wheel 12 May 28 01:59:41 2022 = pkgname-originspec%zydis-3.1.0 > -rw-r--r-- 1 root wheel 18 May 28 01:57:13 2022 = pkgname-originspec%zynaddsubfx-3.0.6,2 > -rw-r--r-- 1 root wheel 9 May 28 02:02:07 2022 = pkgname-originspec%zyre-2.0.1 > -rw-r--r-- 1 root wheel 14 May 28 01:59:41 2022 = pkgname-originspec%zziplib-0.13.72_1 > -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zzuf-0.13_1 > -rw-r--r-- 1 root wheel 13 May 28 01:56:45 2022 = ports_metadata%top_git_hash > -rw-r--r-- 1 root wheel 4 May 28 01:56:49 2022 = ports_metadata%top_unclean =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Jun 11 22:42:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6329283AA87 for ; Sat, 11 Jun 2022 22:53:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LLCmf3HMWz3mLG for ; Sat, 11 Jun 2022 22:53:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654988010; bh=enaBz31ilzw1rNd9WPuRuQtWH0f+Ms7H8tg3udok9k0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hG0CH07wGj18GnVC5gtlbhL7o8Qid1NCJGGxPSjnzYwYC7SABiqo+V7d6WxaArUoRtUERYl7f0Ij6Y8wsCHaiUYr1g8yMlDk7qsXdo6XbCaQ9ToytvBVdkwshdNat5oj5/CJQ+sFaWxsb1Kd982+aZc3IdbytiPk+M2Oy++CPX9YgXBNtSM8IBptka07JAWWt23CvrkYoMGxZAToM7YNG/5om75oUqrHVay/NIaNi1wGbyXYqP4FkHjU8e/2/vc0q4wzUF3Xyfi/t0GMGszz9FkHqkaMDdwjnWfVGLt+9g2suGghOSzPG/3Gv0B0Ox5jVdudC6pY/GRYUbrCuflZJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654988010; bh=qSFq+RSYnTxEdHlGsEKnInBhLWhhyMK8p0LRCE9wSUv=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=aSi9ytXHUCfkL5+CsGkX1CnwQMsb4Pr3WwUrmsH0hDAhoAvLnfu0NTbqdqA1zmgeYfSKJLwbMcE4/fHNL71Xglp8QLEoQJ5Id0WF6MYS22RA89FgYE0x8xKpLhySFrgHJEMEXkRSWUpnaFP/H5ZSMlw+Quplybkm9fFGT+O6ohlGwGXdfhhTaRD88LuBkxfIXDhQVYIhjVWdlPC+BBg62Z5J4BWQzlmKl16xrM71bV3hP5DfLWpFsfgYsRpUzqOuj6uyIAlHe9zXwn48biwIazFyp7+k9MEbbjqdPST+FHYVTBVs35AWo6WhukCwA7lhOujXpEAr3K1nJDS/8U/OKw== X-YMail-OSG: mfsRxTwVM1k6hPv7EbfAAYaIVdFh8.TlWzF0_8oJ2Y2ng4KuEv14EjAHWpY1E8F NmKYm89z7F.vSpQ2bH9SDudzKbB8okNZRCsmk3fpZdhIKml5jdVF0DkGIvwNTOn70HRWuwjP7I2m w_BJzB3rpMASKaVlI4P7ZN4_x35MUqRCUqTKuok37a45S80dqoMLvYJBbI_K5nCTwg9EnAdG2CTG Gwaz0JAfeBRN0OvE3s0BAM7KFnC3NcqsGWHB3D1F1IqvsBv.z4Ug3NZ_k6Crcx4quZvVBYflxLx7 GxffHj3z.hJ7R9rl_HdSz9wtWbrSCdAYPdGH7dD9Ujkg3aITtGpnVIr4dk0qi10qUueKgmRx0JSe ETulACPAZqkFqZKohDxsYm9ItI644sSDBO0u1s5712W4UYgXiAp1Kqx7Mqyx4.O81E3mmgLjh1au FpwHZmxHWad_trpnLs.B0nmgxFfo5VKB4eusXSHHCHHSR2KEY1JbUNwBVhUxzc8B4K4gXQ4gOA1U fnv6vLEPJ0oithtPwnwqopxclpR0SCTkpZV0IvwXtGbnbRzHsNUHC87FeEIf7KurlGjaNC3CCBn6 j172xFEa_cANbaabQ0jVVG3W9j8I9VKXvEwGgo_RLSZltcB0_pR8SLt8XGZeZVjmq3ud6UVc9MiZ WKUAAeZywgiSxndsX7R4wE3_dduxunq1.03IDVzYrfjkrWCzfyV9by3ekf7LLfEqBDmH73ad6cU4 Eo6bhUIzxt.el1KKw2BpOm8FbbjxT7_Nfc8Lq7h.LDFuOnrlcOrZrZdjgrEHeD_8KH3PFS0qx79n lOwX889mg_CCkcqrPV8qBkWwQiOsFBAerX9Lo8dK1uvHG.6m9xn0vjYxemu1kEc50IdgKq8cTq_M JIRtKsvt7I0GRGxejSL16JSksrd6QRvHvn9dx5.qgkIPfU1IjSKHD.XO2DNe.Pv4KkGXIHiVCaEA 7l2OCdkfIKiZVslxdSnCV8zqvt4ldWHw4B0Sche.xdsLV2xL4561w_BR68tYrYBZijeSFEuSKpKX qOL0bXKdgF1zDAqv8qcc7pCUSg25dDsPmcIiJvckJe5wt_lwiZgy33dQpiV5PDxoaHX8WzcRqyM6 Sn285HyL1gHB.gwU.VRMecLTgRhLiX2aRXIcDhry1LKK89DI2z.ykyWPunA2Ca7vEpF.sCkJJbaN ZXQs5_Z2LYUgH.zIxVLy4vluH_z0r69QtlY7U5iQmmUaSBn2osULbq24EljebPsoj2LXXr4.QCM8 pYOxsRYcuV_1grFD9dMeTpeRbNC2SI1ASx8.SMy1jeR_fzTNzgzmzAfOlah11pc6V5qb_jV9sIwL zvUNnEXXu6GNMW31d5Qe63A7eQQ.XZ19FuBiTG6MoyyaNOpc7RgJ.bBjQHRE9NuvvHYuS0imNYYg QrccOvNMdpwc090nsfpRSixOtytYG0n7aQSJfCk04dO4V3aVyEDpbHR2ubFfmuL3xDu5AAti3qoR RS82wStRYvR670IxRVD65liJC9wKx7aGdE4I8gIz9GZ.6Fe1qH2shCfX_AxUMUn5Qwv0sikFw2ZU nD3TigrS5EHgp1UnW43uXz5YdEFVwRmRErJp1EFI5PwjuAcqrmFHM2CRRYLcwrYFhDeCBxWMCp3R 0SQCKf3SrkMO.C1NC.WqCpJCKwIPSzxFy_EuwbDdtOMpSV7J4KOeSOzBjVIgqufi8JGxs.1SWUrK vmbTQQM4umvooPV.OwMUWpnY300oEisjI.Igwgi3hIj5eEVCUa_3ppUKShEGHk5zRAfi7tnBq3t8 ZjeKSScVDUcv0O4P0T8dx0cbHeebFIgeO.fTvhecnX_CPYIWQ_orSGHPNaX56ol04RyoxiIrkdqb T1FQ0qF0wp2Yyt8DusPePzmE3gxT5vTCkcL9jWvSOHrPJg3CEXiVywaTYIy8X.cmXeNUXbPHo2Gy a1gP12ICThRTHXH_x8iowFDdll1DWx_VjnlbQBBJFk1Asjd5Y.hT8dmd0P127yQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 11 Jun 2022 22:53:30 +0000 Received: by hermes--canary-production-ne1-799d7bd497-px24v (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9a685699436fd6f479267466fadaf335; Sat, 11 Jun 2022 22:42:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: What can I learn about data that is staying paged out? (There is a more specific poudriere bulk related context given.) From: Mark Millard In-Reply-To: <6EA27152-3355-4356-B246-A083F31452F2@yahoo.com> Date: Sat, 11 Jun 2022 15:42:24 -0700 Cc: Daniel Ebdrup Jensen , David Cross Content-Transfer-Encoding: quoted-printable Message-Id: <840FA150-5623-4BE7-A289-015E7C14436C@yahoo.com> References: <573B8B0C-5209-459D-98AD-EE92DDA4DF83@yahoo.com> <6EA27152-3355-4356-B246-A083F31452F2@yahoo.com> To: FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LLCmf3HMWz3mLG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=hG0CH07w; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I got evidence finally. An example is the sequence: # swapoff /dev/gpt/CA72USBswp14 /dev/gpt/CA72USBswp16 # swapon /dev/gpt/CA72USBswp14 /dev/gpt/CA72USBswp16 (Wait for a time letting some "staying paged out" space accumulate.) # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 319 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ (Wait for a time letting some more "staying paged out" space accumulate.) # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 307 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ (The size decreases seem to roughly track the sustained Swap Used increases. [There is some other paging activity but it is not a lot.]) # swapoff /dev/gpt/CA72USBswp14 /dev/gpt/CA72USBswp16 # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 379 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ (Apparently, du -xsm does not count the paged out pages for tmpfs but the pages show up when forced back into RAM.) # swapon /dev/gpt/CA72USBswp14 /dev/gpt/CA72USBswp16 # du -xsm /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ 379 /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/ (I expect that when I see the swap usage grow in a staying paged out manor, I'll find that this -xsm figure will also have decreased on the retry in the new context.) The primary space in question is actually in a subdirectory: Taking a quick estimate of the file count in . . ./ref/.p/var/cache/ I get: # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = wc 82146 821452 7942485 So something like 82144 files ( ignoring . and .. ). # ls -Tla = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ | = more total 301234 drwxr-xr-x 2 root wheel 5257152 May 28 02:31:26 2022 . drwxr-xr-x 4 root wheel 128 May 28 01:56:42 2022 .. -rw-r--r-- 1 root wheel 2 May 28 02:26:40 2022 = builder_active%01 -rw-r--r-- 1 root wheel 2 May 28 02:31:24 2022 = builder_active%02 -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%03 -rw-r--r-- 1 root wheel 2 May 28 02:31:26 2022 = builder_active%04 -rw-r--r-- 1 root wheel 18 May 28 01:56:51 2022 = originspec-pkgname%accessibility_accerciser -rw-r--r-- 1 root wheel 19 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-atk -rw-r--r-- 1 root wheel 20 May 28 01:56:51 2022 = originspec-pkgname%accessibility_at-spi2-core -rw-r--r-- 1 root wheel 11 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atk -rw-r--r-- 1 root wheel 13 May 28 01:56:51 2022 = originspec-pkgname%accessibility_atkmm -rw-r--r-- 1 root wheel 17 May 28 01:56:51 2022 = originspec-pkgname%accessibility_caribou . . . -rw-r--r-- 1 root wheel 17 May 28 01:56:55 2022 = pkgname-originspec%zutils-1.11 -rw-r--r-- 1 root wheel 15 May 28 02:03:32 2022 = pkgname-originspec%zxfer-1.1.7 -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zxid-1.42_1 -rw-r--r-- 1 root wheel 19 May 28 02:04:03 2022 = pkgname-originspec%zxing-cpp-1.3.0 -rw-r--r-- 1 root wheel 12 May 28 01:59:41 2022 = pkgname-originspec%zydis-3.1.0 -rw-r--r-- 1 root wheel 18 May 28 01:57:13 2022 = pkgname-originspec%zynaddsubfx-3.0.6,2 -rw-r--r-- 1 root wheel 9 May 28 02:02:07 2022 = pkgname-originspec%zyre-2.0.1 -rw-r--r-- 1 root wheel 14 May 28 01:59:41 2022 = pkgname-originspec%zziplib-0.13.72_1 -rw-r--r-- 1 root wheel 14 May 28 02:03:00 2022 = pkgname-originspec%zzuf-0.13_1 -rw-r--r-- 1 root wheel 13 May 28 01:56:45 2022 = ports_metadata%top_git_hash -rw-r--r-- 1 root wheel 4 May 28 01:56:49 2022 = ports_metadata%top_unclean Each file seems to have a 4096 Byte page used, making for something around 320 MiBytes. Much of it not being heavily used, some of it is gradually paged out to make room for other things. # du -xsm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ 326 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ (Still no reported swap usage.) For reference: # du -xsAm = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ 46 = /usr/local/poudriere/data/.m/main-CA7-bulk_a-default/ref/.p/var/cache/ =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Jun 13 17:51:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E01E783B946 for ; Mon, 13 Jun 2022 17:52:06 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LMJzn3YWTz3KC3 for ; Mon, 13 Jun 2022 17:52:05 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x72c.google.com with SMTP id 15so4595736qki.6 for ; Mon, 13 Jun 2022 10:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=4ryLraAAIoWKNPns9+eDdEKbgwd0ICdKolYvNH8bhKM=; b=Yca3f46J8o+gDmBCl6AoGqQaLWvNfFy8QoBxo6n8IPq7X39V7AAN6KW7DpIfSAdouK GjS/nWM0uFTuaPazIFXJrSNKrL0MCQMXzKx6PAo04/sSXYJCX17iSgdYW1vY8GxVw4hG 4GB8taOlMBHWqB5RJR1JDox0quBgLGbL/oPH2v5k1c2BvPJejpOIs2x0BL0t1VPMhdLf d6rB3QN/RcI1z21edo2BgBwaa3knearZFil8x4zjPLcc3tkyRKG2hgPbf8wP3TBTRUMK C0ToMuQD5LTj9vHhqdHNYfiMSwFVX7wU4024kaB1/DCExxyqnN9+PLCwF0qWRGAJweZC /TBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4ryLraAAIoWKNPns9+eDdEKbgwd0ICdKolYvNH8bhKM=; b=fRLMW2hPJWrHYTVW2KM1OOuetywPjqwiG7ho9N4bQINAhmfC22lkpHiWPTTdoImWW0 wY8U5GEL+3B2Wp/XQ3/QR4AONstK81Ji1bUgv9tycRUwRRpT5Sxfun1AyhUvMXI+flWP DSVGcCa6Z0eDOJol6IdHDvCnRj7RVa0YuFsphqE4+v+ToGwjV/2OsIRfXPo95iJrqW0u ZA8zPUhFKli/jchmMqzOHcp1WKcwShdCfARCawFRGflLQwojsyQQI3dkKO57yPkVcdRT 9GG9haVKMCx9V42AB1dpV+/t4XOdSmxOT0KfTWIdnKFC6dWqpVwnmWWqch1Jj34Pnt9B EcVQ== X-Gm-Message-State: AOAM533VTDG5rX/r5yohhhnxO+RgUbxh6siEFtFhIZDe6RQDBuQKc+a6 CI0FutrBywq1WAethBc3cC4KvMg867mI+b0k2tinC20JSfjKfQ== X-Google-Smtp-Source: ABdhPJyy0cHc+2MC2vnoE/swyH3VcOruigfPKnBv6xcQZ1tAptKRnFQaFHeO2TlpIa+heLKqTueB5+QmShYgdMa7JB8= X-Received: by 2002:a05:620a:4552:b0:6a7:35ac:ed24 with SMTP id u18-20020a05620a455200b006a735aced24mr960743qkp.416.1655142719149; Mon, 13 Jun 2022 10:51:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Jake Freeland Date: Mon, 13 Jun 2022 12:51:48 -0500 Message-ID: Subject: Absent Linux Libraries To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d3eb1805e157f12e" X-Rspamd-Queue-Id: 4LMJzn3YWTz3KC3 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=Yca3f46J; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::72c) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-1.93 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.20)[-0.201]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.63)[-0.630]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[technologyfriends.net]; DKIM_TRACE(0.00)[technologyfriends.net:~]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000d3eb1805e157f12e Content-Type: text/plain; charset="UTF-8" Hi there, I'm in the process of porting Intel's DRM driver testing suite, igt-gpu-tools, to FreeBSD and I'm not finding some Linux-specific runtime libraries in the ports tree. The two that I'm having difficulty with are * libkmod * libprocps I've tried querying the pkg database using the pkg-provides pkg plugin: `pkg provides libkmod` returns nothing `pkg provides libprocps` returns nothing I have tried different naming variations and none yield results. I don't want to rely on the Linux compatibility layer for these libraries. Am I out of luck or am I missing something in plain sight? Thank you, Jake Freeland --000000000000d3eb1805e157f12e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I'm in the process of por= ting Intel's DRM driver testing suite, igt-gpu-tools,
to Free= BSD and I'm not finding some Linux-specific runtime libraries in the
ports tree.

The two that I'm having di= fficulty with are
* libkmod
* libprocps

<= /div>
I've tried querying the pkg database using the pkg-provides p= kg plugin:
`pkg provides libkmod` returns nothing
`= pkg provides libprocps` returns nothing
I have tried different na= ming variations and none yield=C2=A0results.

I= don't want to rely on the Linux=C2=A0compatibility=C2=A0layer for thes= e libraries.
Am I out of luck or am I missing something in plain = sight?

Thank you,
Jake Freeland
--000000000000d3eb1805e157f12e-- From nobody Mon Jun 13 19:18:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA074851E84 for ; Mon, 13 Jun 2022 19:18:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LMLvs03WMz3mSH for ; Mon, 13 Jun 2022 19:18:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id j8so4573819qtn.13 for ; Mon, 13 Jun 2022 12:18:48 -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=QrkOgcoNNDTbzdfy3WawJZ0Uegy0qkSEKLQeOlyPzAg=; b=pzZP+DDY/CJDQTMZVLoiOal571xpqDd6WC8ssMr6MQJ1JS+iLjqiE0+F8LYlhDqTnt Az0jyhtXFnwjHmWvGM1L1E/IJjmUqcxb/bBg9vZGrSlzmIxrAWs3yER0Whxij+j4UBzb InDGqBpff5cgWxzeEMSfrdVsvB3wn5VT+yTOgoSYyr4wDKbc9p6qS1HXvhinFP9n7beN 67DvQghWosZ1VC1tP+55FmaPbsi74HqqLcnn7NxdFFnr3rhbf50G0+ojd8jHzX6q9LQE jzaEXZFugU2oTe7rdu0EwJ6Z2g6DTJOPn59zk3me5Id8lzsOH075OeU5fEC9F16PbLPd s//Q== 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=QrkOgcoNNDTbzdfy3WawJZ0Uegy0qkSEKLQeOlyPzAg=; b=er1Wat3o1920SprfXk2O+Bkm0JvqsAGQNhVwFrXXTWFW/njpmKZmkMhl2eryUf/deu RNVE648Ez8VDtz0UROUs436uKusogJ7iZ/UWDvvMO/9dXg4PAIMBMoARmukxrp/6x8re xXup9cl/DlpoaW6rP4DtSRwWU7397fTwMVyNZUnygyolPExF4mJhTz3ao3I3JcplfK2v Cgk5Zdb89/j9ud9ijazqGA/h8jIcnJUZH4y7DaT4LYJMGJPLjAM/Us/TleQXhUQwchgN E4z6cMy+wjlQ6kcBU9KwGxNNIDCV3us7iV27c24CmK/pEnxGAPJ8sIz+FcBFUGTvW/UE qlIQ== X-Gm-Message-State: AOAM5304+7etlNkBWmRv7Zowa8hNYStdveGhxdlCz04cTwkLxToPq0Rw WcINVpoNcnSiB3qR7Kb/jASNuTRVt/c= X-Google-Smtp-Source: ABdhPJxyiMX5R2ghc7Eb8VV3WweOjfjOzVoOy0A9E8qAbmM4BJMw6SiUgGfvqeylNq2g4Gp5yBA15g== X-Received: by 2002:a05:622a:508:b0:2f9:1cc0:2d50 with SMTP id l8-20020a05622a050800b002f91cc02d50mr1204144qtx.66.1655147928526; Mon, 13 Jun 2022 12:18:48 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id a23-20020ac81097000000b00304fa21762csm5468117qtj.53.2022.06.13.12.18.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jun 2022 12:18:47 -0700 (PDT) Date: Mon, 13 Jun 2022 15:18:45 -0400 From: Mark Johnston To: Jake Freeland Cc: freebsd-hackers@freebsd.org Subject: Re: Absent Linux Libraries Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LMLvs03WMz3mSH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pzZP+DDY; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.971]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 13, 2022 at 12:51:48PM -0500, Jake Freeland wrote: > Hi there, > > I'm in the process of porting Intel's DRM driver testing suite, > igt-gpu-tools, > to FreeBSD and I'm not finding some Linux-specific runtime libraries in the > ports tree. > > The two that I'm having difficulty with are > * libkmod > * libprocps > > I've tried querying the pkg database using the pkg-provides pkg plugin: > `pkg provides libkmod` returns nothing > `pkg provides libprocps` returns nothing > I have tried different naming variations and none yield results. > > I don't want to rely on the Linux compatibility layer for these libraries. > Am I out of luck or am I missing something in plain sight? As far as I know, those libraries are Linux-specific. A long time ago I did a very rough port of that test suite while trying to track down some bugs in i915kms, and I remember being able to simply stub out references to those two libraries. That might be harder to do today, or not. It might be possible to port those libraries to FreeBSD and make use of linprocfs since they both use (Linux's) /proc extensively. But I'm not sure how much work this would be. I don't think the Linux compatibility layer would help here unless you're planning on running everything under the Linux compatibility layer. From nobody Mon Jun 13 23:25:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BEA55851D6B for ; Mon, 13 Jun 2022 23:25:27 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LMSNR0NvLz4rxb for ; Mon, 13 Jun 2022 23:25:27 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qt1-x834.google.com with SMTP id w13so4160110qts.6 for ; Mon, 13 Jun 2022 16:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsPbg3QZDIXKOHr2cs4Sq5qwu4WI4+8ZZJgw68o+IPE=; b=d/qTr0ZXu35OqDZwF3ZAKlhZpC+O3uQTlRa+99i8k9hT886qpQ6wYdQtXlzagPyQn4 J0KAiqRJj5s9hl8GYGXSVq1eUscl+kscZr+on8ED6XHNaXUhHqS+Ye4dwuJhtvff9Bct JDWrIS6LQXx17Bw08Oi4zRoAuagr0TXmfg3FlobKphd4jPRKhRN30Th54X1XWq49lTQM frzpuI6A30iO0SLluANiKBF83kvtQxik7vVfoPwVTwQO0O9LseGZ4YEE5MGXhuvhgiqt BXzurEUDJfvDMFBw2Ny3Ozj6pRVZt8vA4ju1j2UXzBZZh7MuCv4t70Pxj9+i8aF2VMM1 DgKg== 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=WsPbg3QZDIXKOHr2cs4Sq5qwu4WI4+8ZZJgw68o+IPE=; b=ml+cOegRVBFcKzb3JTmyOerUgv/5JYdG6NVVVHk0lxLixdKy4cBedybPUwxi7+kmgz dJtweNLCitm6VxiJfCB47ex7CRWPz71D/q6zVCJVhzISPRQRKvcqkXCewCygVKZOagBX 5HvFGnRDRyuiS7WNE8LWnitBTGW1Kxt9+G0BwYW5n2wIm4OxNUm4SrEWQD+LeF0hxjHq HqC0dWPhkX6x65TtWmqgdTX56RJ+Mfmf6OnT/d+jZy8GQzHEqRYU/xOpZ2r+NKIIRxnS rhdI680kB8UJOZUtzDPIA3+kQU6CU10xBV/r7FLqpjEvO57QCz4l7+dl2e0qOnAVlsR6 lL9A== X-Gm-Message-State: AOAM531JWukLc5+QKP632oqIqEFtCAwbuCeSkvv3rz5bZpSYmvDUZdek Vk3hOqZTu8s+6O3tEfQTrGIWkhWQiaUhXivNXzsNHndk98Y= X-Google-Smtp-Source: ABdhPJwcwiW2cdwJ4P5CDZeoDd3Dkz2JNnatH6dHkF9wwpfDvVSPYnhByiPSJRpNDYRGbhZP6GwbL9ywGc5t0BSyk+M= X-Received: by 2002:a05:622a:1990:b0:305:76b:8f8 with SMTP id u16-20020a05622a199000b00305076b08f8mr1933367qtc.619.1655162726443; Mon, 13 Jun 2022 16:25:26 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Mon, 13 Jun 2022 18:25:15 -0500 Message-ID: Subject: Re: Absent Linux Libraries To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005b009405e15c9a9d" X-Rspamd-Queue-Id: 4LMSNR0NvLz4rxb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b="d/qTr0ZX"; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.09 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[technologyfriends.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::834:from]; NEURAL_HAM_SHORT(-0.99)[-0.987]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000005b009405e15c9a9d Content-Type: text/plain; charset="UTF-8" Hi Mark, It looks like igt-gpu-tools has changed quite a bit since your modifications were made. I found the remnants of your work on Github before starting my port. I am going to try to work around those libraries for now, but I'll probably end up porting procps and using linprocfs as you suggested. I appreciate the pointers and am thankful to have your old port for direction. Jake Freeland On Mon, Jun 13, 2022 at 2:18 PM Mark Johnston wrote: > On Mon, Jun 13, 2022 at 12:51:48PM -0500, Jake Freeland wrote: > > Hi there, > > > > I'm in the process of porting Intel's DRM driver testing suite, > > igt-gpu-tools, > > to FreeBSD and I'm not finding some Linux-specific runtime libraries in > the > > ports tree. > > > > The two that I'm having difficulty with are > > * libkmod > > * libprocps > > > > I've tried querying the pkg database using the pkg-provides pkg plugin: > > `pkg provides libkmod` returns nothing > > `pkg provides libprocps` returns nothing > > I have tried different naming variations and none yield results. > > > > I don't want to rely on the Linux compatibility layer for these > libraries. > > Am I out of luck or am I missing something in plain sight? > > As far as I know, those libraries are Linux-specific. A long time ago I > did a very rough port of that test suite while trying to track down some > bugs in i915kms, and I remember being able to simply stub out references > to those two libraries. That might be harder to do today, or not. > > It might be possible to port those libraries to FreeBSD and make use of > linprocfs since they both use (Linux's) /proc extensively. But I'm not > sure how much work this would be. I don't think the Linux compatibility > layer would help here unless you're planning on running everything under > the Linux compatibility layer. > --0000000000005b009405e15c9a9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

It looks like igt-gpu-tools ha= s changed quite a bit since your modifications were made.
I found= the remnants of your work on Github before starting=C2=A0my port. I am goi= ng to try
to work around=C2=A0those libraries for now, but I'= ll probably end up porting procps and using
linprocfs as you sugg= ested.

I appreciate the pointers and am thankful t= o have your old port for direction.

Jake Freeland<= /div>

On Mon, Jun 13, 2022 at 2:18 PM Mark Johnston <markj@freebsd.org> wrote:
On Mon, Jun 13, 2022 at 12:51:48PM -0500,= Jake Freeland wrote:
> Hi there,
>
> I'm in the process of porting Intel's DRM driver testing suite= ,
> igt-gpu-tools,
> to FreeBSD and I'm not finding some Linux-specific runtime librari= es in the
> ports tree.
>
> The two that I'm having difficulty with are
> * libkmod
> * libprocps
>
> I've tried querying the pkg database using the pkg-provides pkg pl= ugin:
> `pkg provides libkmod` returns nothing
> `pkg provides libprocps` returns nothing
> I have tried different naming variations and none yield results.
>
> I don't want to rely on the Linux compatibility layer for these li= braries.
> Am I out of luck or am I missing something in plain sight?

As far as I know, those libraries are Linux-specific.=C2=A0 A long time ago= I
did a very rough port of that test suite while trying to track down some bugs in i915kms, and I remember being able to simply stub out references to those two libraries.=C2=A0 That might be harder to do today, or not.

It might be possible to port those libraries to FreeBSD and make use of
linprocfs since they both use (Linux's) /proc extensively.=C2=A0 But I&= #39;m not
sure how much work this would be.=C2=A0 I don't think the Linux compati= bility
layer would help here unless you're planning on running everything unde= r
the Linux compatibility layer.
--0000000000005b009405e15c9a9d-- From nobody Wed Jun 15 00:00:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 106BC8366A4; Wed, 15 Jun 2022 00:00:01 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LN55s02DMz3HpT; Wed, 15 Jun 2022 00:00:01 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655251201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=ejO+weJS70fWeZfurX8uei/rMDQlMf6m9uDrBoVNnlOSzZujJkDkZKau39tDYmomZGQf7C pLoCHQ8hVEO9W1Dbdlzr0IwZjXmwqXgftgEdHZTmfRjBsWTxOyAf0xDIbF2Nfq2jIZGrUs CY6h9SzSoeC0f8nK6mHRInRFI0mNurNMZm/L29KfoPvhoUjCmnF6sF7BfGJuQRP3XjsuPj ysqc47K50zdIFPBFKmpgwa1BQtzksXKqSYiTcEZX4LXLxFVcMZdqRAzQpANcX2Bz0Wt7pu gkWO5KbJHz8tpYoxyu+EymhmbU9qEaNbCx15T8u0K7DyZgDiYPp1sGOeZEp7zg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id D3097112F7; Wed, 15 Jun 2022 00:00:00 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q2 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,info@bsdcan.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20220615000000.D3097112F7@freefall.freebsd.org> Date: Wed, 15 Jun 2022 00:00:00 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655251201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=LRgX6svqIssrrbjtXEGT4EaI5MYY6+HnWzEfhLag0K3Df9rgYPwfgN5Z+04QBBNqYnFhqW RvWoe/1i0G+LfONmnKMBtgmnFQ4qpVlaOlaCfnmyhp6p9zusxUVyM1nATVydMwQm8zhr4w Ns6p2McUu66NPoVtOfwLGy0Lqe2F4tTX5Qd0iPpNJT4MGfaYa/IeV3YHHq7o4To7fxBUPK +Y9AOyLGy9SRnZZVrXKS/bHSoelBsFEcBKkxcl1wMV2gyFTZRo4yWVYaAF6ExzuNeLbnb1 EXHEx8XIiuhj+FwC8lOSAKSQIlkwwHVrbp1ZRR2Dcm/qPr8zx9c2Uo6De5J/RQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655251201; a=rsa-sha256; cv=none; b=sd/cK95pWT5oTFAi9z0jRRtrVRZrF8PuxcCibrAKLuEfQkU3Tx8kMp3Sv41IStHeYQu6k6 +/FgQJCAm+AU3+vq546QiMswXTCR2atg9s+hYQ8C4oqdTcFI0GsdM40t9dyB1yU+Gmp6S1 Do0EnL1/nSTpvzjzgizWNe/8dly0y2TnvSFuc2CjaAR8t47NJfPFgMdnH4LPz5kc6IiVch LTtfkc+MyC564oaYSYXZbJa19MYE7xssqKpxxQMIk6+FFkFpPQb2dmNDfVPNgRFJmEovC6 MPdKVmfxlM93wFEnGFotXVsAmAeeoBIFhWFopIjRXlRDAK7oe+8+93576bKLPQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is June, 30th 2022 for work done since the last round of Quarterly Reports: April 2022 - June 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q2 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Thu Jun 16 06:28:52 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8A647845C4F for ; Thu, 16 Jun 2022 06:29:12 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LNshR4Vvxz4q5j for ; Thu, 16 Jun 2022 06:29:11 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-ed1-x533.google.com with SMTP id c2so783588edf.5 for ; Wed, 15 Jun 2022 23:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=9Zr8SnBVEWO40EnAlXG6hOINjP8M3QV3Zt8YVkLxzU8=; b=ivmchoP81YFLANYTZwdjerejYHVMSEtycVrNsuV6ffUp06c8Pd2cvKYSM0WaIahBg+ qoHElLxPMmFIABPBAWBLxgLlwQnHGMtd3Bk9I9eQitWHtF1W75h54y17VLb+CW5OB3Wl N/3kzUZkzA1VixY73REfw3gZKuQOCnaohlmekU0RP2kvNZ+DP8vd04Egtzr7RxI9LnDc TDycNMrkxY39McTfCKiSlTFPRxuDOFz2PBiesQFuii80ndHNXqTU+5UizP1OzMBMHraR XGfm+FmocRWWVjc6P+7e31w/013Y8PMRtZT71Po3piZ6L2pZSXxhRn9sG1m7MJ3Ga0NE 0Onw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9Zr8SnBVEWO40EnAlXG6hOINjP8M3QV3Zt8YVkLxzU8=; b=QWuFnCacjZGtdobFzvnOfAHefsUMhNrHSKwioKaphhk3MB3xejV0f450U8mWAnd8Xy UwhRFFGZELFE7Dpi70PEcn16DgfvZa59qsddhyKbUhz3PDrUQhMCVgxH2icSKkewStgr P0M1Bbp9Gl+urUG8G1TQnrSwDf43zNHUaUnsPzwOEjEiVmYcMKpE2tlAi4b2cOxZaKOC DS2T/LO26QtlPhGKI95WXRMKW9yEy5GSK8SnyHDMoGOXhmuUjcAMvzpCdCfhhVnAgI0B 5W1AHGKjKuaAND1zrIYC33WDyU7jhfPX15XrFlAVgQD8mqvi2YUhGdClkPD42CWeju0o 3yFg== X-Gm-Message-State: AJIora8B/7PVtBMqRqV1Bm/qQTr5IHTilZmrhBOtLZ4R9dnYlGB0O7Ms 0mCgCTjSXorl5tfST40biC4Ycx8sgOpMAG+Ajr7IKAN2huQ= X-Google-Smtp-Source: AGRyM1u+jj5JwPJ/CfSLfAzeyWPhK/khL26R4blet+SpapzM52ojOBw+SeIVpRZ0XtM5YfvwurSX3cIUmf6GgK09S30= X-Received: by 2002:a05:6402:540c:b0:434:d965:f8a with SMTP id ev12-20020a056402540c00b00434d9650f8amr4451649edb.30.1655360943858; Wed, 15 Jun 2022 23:29:03 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Andrey Fesenko Date: Thu, 16 Jun 2022 09:28:52 +0300 Message-ID: Subject: FreeBSD Turbo Boost To: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LNshR4Vvxz4q5j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ivmchoP8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of f0andrey@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=f0andrey@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hello, may be a dummy question, but FreeBSD support Turbo Boost? In BIOS option enabled, but freq_settings display only base speed +1, and i'm not find a test or utills show processor uses turbo boost mode. From nobody Thu Jun 16 12:12:41 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EF7FC85F722 for ; Thu, 16 Jun 2022 12:12:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP1Jv0pW8z4dyp for ; Thu, 16 Jun 2022 12:12:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.16.1/8.16.1) with ESMTPS id 25GCCeRV000749 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Jun 2022 08:12:40 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:9892:26d8:42eb:c840] ([IPv6:2607:f3e0:0:4:9892:26d8:42eb:c840]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 25GCCeD0001898 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 16 Jun 2022 08:12:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <88986e25-956d-d9ba-8d01-f7ecf4aa3b54@sentex.net> Date: Thu, 16 Jun 2022 08:12:41 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: FreeBSD Turbo Boost Content-Language: en-US To: Andrey Fesenko , hackers@freebsd.org References: From: mike tancsa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 64.7.153.18 X-Rspamd-Queue-Id: 4LP1Jv0pW8z4dyp X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:1::12 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [-3.39 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.990]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sentex.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.212.134.19:received] X-ThisMailContainsUnwantedMimeParts: N On 6/16/2022 2:28 AM, Andrey Fesenko wrote: > Hello, > > may be a dummy question, but FreeBSD support Turbo Boost? In BIOS > option enabled, but freq_settings display only base speed +1, and i'm > not find a test or utills show processor uses turbo boost mode. IIRC, thats where its displayed sysctl -a dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 3701/72000 3700/72000 3500/66145 3300/61191 3100/55753 2900/51165 2700/46108 2500/41884 2200/35542 2000/31731 1800/27498 1600/24008 1400/20131 1200/16957 1000/13929 800/10547 sysctl -a dev.cpu.0.freq dev.cpu.0.freq: 3700 set that to dev.cpu.0.freq to 3701 and I think that sets it to Turbo, or if if you do it in the BIOS, like you said, it will already display that value.     ---Mike From nobody Thu Jun 16 12:16:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1E83583108F for ; Thu, 16 Jun 2022 12:16:49 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP1PW5zsrz4frR for ; Thu, 16 Jun 2022 12:16:47 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x32c.google.com with SMTP id o37-20020a05600c512500b0039c4ba4c64dso2727110wms.2 for ; Thu, 16 Jun 2022 05:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:to:references:from :in-reply-to:content-transfer-encoding; bh=y6ZZj12n3+YQmxMSPIISVHhPO/p7+BJ1SrLA8WXF4DU=; b=ID/DAMekdV+rWdJ+TzhGITVlx0MMzk+6IA++svkZqq7mALUtOi70b+5Vct4NBW8DSx CrPnEdV5YH/6iLdBp13HH0ZlwW64LH5VOlfj9EhtGU7ajmhbaAI8TEAo20FQqhYtvdf/ Vx4lYimg79b5IN/NEmcyPEQShrtavEzZuB+g2cVE8j9I67UtDJ4nZWuyEbwAgbq9qAh0 AftOT63NndNYBRlOVxeeG6o+E1ud0UlEJP7W1nRRf88LkUp2oqK33c7mOuTn+UmAwvFj 7LdIAOIQhuwlLUWpa8zqDdU4SDvVMLFGsbycCkjJt3sqdQF/rCp1xPZyF/UxzMHYrOWD Grmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:from:in-reply-to:content-transfer-encoding; bh=y6ZZj12n3+YQmxMSPIISVHhPO/p7+BJ1SrLA8WXF4DU=; b=sLB0O1Ttcp1eZtWCogGBb4oSRp8S1Qbra3muH82Z5EhHlLki+9zDi9urQXlPH/AkEN MrxkfBSHcleHc9qMkB/L7IC1jmZ/Hw3Xv6N5pvD1+d8KdJ4w5vmq1v3h0poiQm2MamjA pVLBWqNIpm2Xpye/eP+ckC8X4uvaC+4s11CqTSc3uzZRUlZHe9DUa6qgeIanfyxwkw8t PfBZNirm8whsqv7fLOIbzWm3W2M/ZdDOnV29yOXMePz8vetXYFclUW3GFSN5K+y87MU3 EjkCp2ca5+/HnjbAkyjGU+yAxVGIQ3gvtABd+DJNqAzr5RpiPa9pZGwGe6hS3XGGGcza 0sYw== X-Gm-Message-State: AJIora9gluYL2BPzWrHhgs9Dx8f7pWdqhgLvxKghTqQDhYLtJb161Ceg snFZ8+h3HW/6i0QE1XlZWNM/nHkA16om9g== X-Google-Smtp-Source: AGRyM1vs+Ei4IWIJLP3vPkrmr+l9OlVkU6VcEKa/v3Nab41H+PQjpRuhcuKFHxTfOvQ3JDaiuMde3w== X-Received: by 2002:a05:600c:4e0e:b0:39c:8d11:58eb with SMTP id b14-20020a05600c4e0e00b0039c8d1158ebmr4791785wmq.190.1655381801257; Thu, 16 Jun 2022 05:16:41 -0700 (PDT) Received: from [137.202.243.61] (nat-ies.mentorg.com. [192.94.31.2]) by smtp.gmail.com with ESMTPSA id p124-20020a1c2982000000b0039c7dbafa7asm5869729wmp.19.2022.06.16.05.16.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jun 2022 05:16:40 -0700 (PDT) Message-ID: <9e5f9da7-e640-857d-5103-f5e61f69a758@gmail.com> Date: Thu, 16 Jun 2022 14:16:38 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Hang ast / pipelk / piperd To: FreeBSD Hackers References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> From: "Floyd, Paul" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LP1PW5zsrz4frR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ID/DAMek"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::32c as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-2.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.32)[0.319]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-06-06 20:17, Mark Johnston wrote: > On Wed, Jun 01, 2022 at 11:27:52PM +0200, Paul Floyd wrote: >> On 6/1/22 14:16, Mark Johnston wrote: >>> The fact that the problem apparently only occurs with 1 CPU suggests a >>> scheduler bug, indeed. >> >> Here is the fresh procstat output > > I was able to reproduce the problem locally and narrow down the bug > somewhat. If you can test a kernel patch, please try this one: > https://reviews.freebsd.org/D35415 . I verified that it solves the hang > in my test setup, but I didn't go any further than that yet. Hi Mark What would be best for testing? The latest 14.0-CURRENT with a build from git master? A+ Paul From nobody Thu Jun 16 15:03:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C311A833644 for ; Thu, 16 Jun 2022 15:03:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP56H60MJz4T80 for ; Thu, 16 Jun 2022 15:03:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf29.google.com with SMTP id o43so2472945qvo.4 for ; Thu, 16 Jun 2022 08:03:51 -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=82P1gjR1wNE613HOyBB/wXUOigP32yPPpP763UPMQmQ=; b=FpWnRlKVq0SKNYhMBYOl9/2oIEl1svR8ZL/eLieKKneaX1uiiudCV5Fg6Nyc8Gvvkk uVnq9lN/pj5ZIdr6LbH0XRCcN2ylAASDg6gcdcgrkEa1sR2x8Gy0wqoRzG0MYStxNyCg IVSNvedv7Vvr9tx01ee7vpCd0XCSk+5DXMPqr6VQZCFj8IQWPAN+MrmkRSceUO2+/zQ6 5kjo1mciI1zLmROznEvaYmpn2+O0rUfHRVXqL9iAcD2TaZwoh1UPufQ7Ha6FZh6fj6kU oXLX4CtxeVAZ4tnCONPDDI/5OYJiM0cbxK5ajZrUaJ6FAF7eDstpspqSauyGRLLcV9NF PyYw== 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=82P1gjR1wNE613HOyBB/wXUOigP32yPPpP763UPMQmQ=; b=PSkU2isnQ4OEtsHRII4U0c/9zwqLE7eJmkpGQ0qAO2Vwu/DURnAJCfmJ3qzYpzuQ5+ Y1tni8uj74WGLi2G+7+XTE2WPqYjO0Q3m++d1h5T2pIf1BuXlM8mlIw1FmqtI1qIJJ3g kCRzQ8vgUTQE2rN/l5L3fKq4QfqUEV46Tb4yivLmhEEeCjaW0nXXlvFOi10Ll48DWCfz eMAoqkSFXQ9F8weweQ/oa5OOguQsRyr8NK5FMpsgCOywRzEEQYZDEAhvRGqlQx/nYjWE ldToxCaPAZqH+OJT1T+NSguUF+LRZBdbBFIBcWB6n4FwjZTKQSeS0ns2MKscVRuBrFc2 2g2w== X-Gm-Message-State: AJIora/hZeMNc2j6mj0xR3LTqlBA0XsQADnKviTWgAM0UUVq1rfXbogT IQdtYDC4ZGcYaVmnCvQ0BrU= X-Google-Smtp-Source: AGRyM1uhhl57ZoqEik+NDUdLJ9zjNGb9HMAWoY0swe8ljKEBQ4TQRCmZImniUDrDuxJhPMNanD39PA== X-Received: by 2002:ad4:5de2:0:b0:464:5609:6640 with SMTP id jn2-20020ad45de2000000b0046456096640mr4546386qvb.115.1655391831317; Thu, 16 Jun 2022 08:03:51 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id g10-20020a05620a40ca00b006a6bb044740sm1946260qko.66.2022.06.16.08.03.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 08:03:49 -0700 (PDT) Date: Thu, 16 Jun 2022 11:03:47 -0400 From: Mark Johnston To: "Floyd, Paul" Cc: FreeBSD Hackers Subject: Re: Hang ast / pipelk / piperd Message-ID: References: <84015bf9-8504-1c3c-0ba5-58d0d7824843@gmail.com> <9e5f9da7-e640-857d-5103-f5e61f69a758@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9e5f9da7-e640-857d-5103-f5e61f69a758@gmail.com> X-Rspamd-Queue-Id: 4LP56H60MJz4T80 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FpWnRlKV; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.83)[0.831]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Jun 16, 2022 at 02:16:38PM +0200, Floyd, Paul wrote: > > > On 2022-06-06 20:17, Mark Johnston wrote: > > On Wed, Jun 01, 2022 at 11:27:52PM +0200, Paul Floyd wrote: > >> On 6/1/22 14:16, Mark Johnston wrote: > >>> The fact that the problem apparently only occurs with 1 CPU suggests a > >>> scheduler bug, indeed. > >> > >> Here is the fresh procstat output > > > > I was able to reproduce the problem locally and narrow down the bug > > somewhat. If you can test a kernel patch, please try this one: > > https://reviews.freebsd.org/D35415 . I verified that it solves the hang > > in my test setup, but I didn't go any further than that yet. > > Hi Mark > > What would be best for testing? The latest 14.0-CURRENT with a build > from git master? Yes, that would work - I've since committed the patch. It'll be merged to 13-STABLE within a few weeks. From nobody Thu Jun 16 16:51:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 778B6846FA1 for ; Thu, 16 Jun 2022 16:51:31 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4LP7VV1KQ9z4kDh for ; Thu, 16 Jun 2022 16:51:30 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id DA8E54C1286 for ; Thu, 16 Jun 2022 11:51:22 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Thu, 16 Jun 2022 16:51:22 +0000 From: Pau Amma To: FreeBSD Hackers Subject: RFD: MFC hold time guidelines User-Agent: Roundcube Webmail/1.4.8 Message-ID: <83c320038e43abe1d8bd59b9364a225e@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LP7VV1KQ9z4kDh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N https://reviews.freebsd.org/D35405 brought to light the lack of documented MFC hold time guidelines for src (only repo that uses that) beyond: barring critical fixes authorized by release engineering or the security officer, 3 days is the minimum. I'd like to have general guidelines hashed out and added to the committer's guide. To get things started, here's what Ed Maste reported using: instant MFC: security or critical build fixes, or other critical changes, with coordination/approval of re@ or so@ 3 days: straightforward bug fixes or minor improvements where there is a (presumed) very low probability of introducing a regression. e.g. typo fixes, man page updates 1 week: default timeout for most changes with low-medium presumed probability of introducing regressions e.g. adding to a driver's supported devices list, general bug fixes and new features 2 weeks, 3 weeks, 1 month: longer timeouts for changes with increasing likelihood of environment-dependent bugs or unique or rare corner cases e.g. major updates to contrib software, significant rework to kernel subsystems Looking at my commit history over the last several years "1 week" is most common. I used "3 days" and "2 weeks" each about 1/3 as frequently as "1 week." "1 month" and "3 weeks" each about 1/10. Sometimes the MFC timeout will be longer or shorter than I would otherwise choose in order to exclude or include the change from an upcoming stable/ branch. For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb | uniq -ci | sort -bf -k 1nr 19169 MFC after: 1 Week 11807 MFC after: 3 Days 10941 MFC after: 2 Weeks 4002 MFC after: 1 Month 1919 MFC after: 3 Weeks 838 MFC after: 5 days 643 MFC after: 2 Days 621 MFC after: 1 day 407 MFC after: 4 weeks 346 MFC after: 2 months 322 MFC after: 7 days 282 MFC after: 4 days 281 MFC after: 10 daysbnb 222 MFC after: 3 Months (cutting off at <1% of the most common hold time) for all committers is similar to Ed Maste's. So what do others think? If and when consensus emerges, I'll write it up for possible inclusion in the committer's guide. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Thu Jun 16 17:04:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9B7988520A0 for ; Thu, 16 Jun 2022 17:04:30 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP7nT1RpKz4mmg for ; Thu, 16 Jun 2022 17:04:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25GH4Jbn075778; Fri, 17 Jun 2022 02:04:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 17 Jun 2022 02:04:19 +0900 From: Tomoaki AOKI To: Pau Amma Cc: FreeBSD Hackers Subject: Re: RFD: MFC hold time guidelines Message-Id: <20220617020419.22cfad1c3cce01054ec6528a@dec.sakura.ne.jp> In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LP7nT1RpKz4mmg X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [2.31 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.980]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.93)[0.934]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received] X-ThisMailContainsUnwantedMimeParts: N On Thu, 16 Jun 2022 16:51:22 +0000 Pau Amma wrote: > https://reviews.freebsd.org/D35405 brought to light the lack of > documented MFC hold time guidelines for src (only repo that uses that) > beyond: barring critical fixes authorized by release engineering or the > security officer, 3 days is the minimum. I'd like to have general > guidelines hashed out and added to the committer's guide. To get things > started, here's what Ed Maste reported using: > > instant MFC: security or critical build fixes, or other critical > changes, with coordination/approval of re@ or so@ > 3 days: straightforward bug fixes or minor improvements where there is a > (presumed) very low probability of introducing a regression. e.g. typo > fixes, man page updates > 1 week: default timeout for most changes with low-medium presumed > probability of introducing regressions e.g. adding to a driver's > supported devices list, general bug fixes and new features > 2 weeks, 3 weeks, 1 month: longer timeouts for changes with increasing > likelihood of environment-dependent bugs or unique or rare corner cases > e.g. major updates to contrib software, significant rework to kernel > subsystems > Looking at my commit history over the last several years "1 week" is > most common. I used "3 days" and "2 weeks" each about 1/3 as frequently > as "1 week." "1 month" and "3 weeks" each about 1/10. Sometimes the MFC > timeout will be longer or shorter than I would otherwise choose in order > to exclude or include the change from an upcoming stable/ branch. > > For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ > *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb | > uniq -ci | sort -bf -k 1nr > 19169 MFC after: 1 Week > 11807 MFC after: 3 Days > 10941 MFC after: 2 Weeks > 4002 MFC after: 1 Month > 1919 MFC after: 3 Weeks > 838 MFC after: 5 days > 643 MFC after: 2 Days > 621 MFC after: 1 day > 407 MFC after: 4 weeks > 346 MFC after: 2 months > 322 MFC after: 7 days > 282 MFC after: 4 days > 281 MFC after: 10 daysbnb > 222 MFC after: 3 Months > (cutting off at <1% of the most common hold time) for all committers is > similar to Ed Maste's. > > So what do others think? If and when consensus emerges, I'll write it up > for possible inclusion in the committer's guide. > > -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > > Ed's guideline looks reasonable to me. -- Tomoaki AOKI From nobody Thu Jun 16 18:00:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3F40F834F8B for ; Thu, 16 Jun 2022 18:00:18 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]) (using TLSv1.3 with cipher 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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LP91s2dg0z4wXX for ; Thu, 16 Jun 2022 18:00:17 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 25GI086j008987 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 16 Jun 2022 14:00:14 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> Date: Thu, 16 Jun 2022 14:00:08 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: RFD: MFC hold time guidelines Content-Language: en-US To: freebsd-hackers@freebsd.org References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> From: George Mitchell In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4LP91s2dg0z4wXX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 2001:470:1f07:15ff::f7 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-2.30 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.59)[-0.585]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_SHORT(-0.63)[-0.627]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_MEDIUM(-0.79)[-0.791]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TAGGED_FROM(0.00)[freebsd] X-ThisMailContainsUnwantedMimeParts: N On 6/16/22 12:51, Pau Amma wrote: > [...] > For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ > *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb | > uniq -ci | sort -bf -k 1nr > [...] A command line I'm sure you dashed off without a moment's hesitation! -- George From nobody Sat Jun 18 07:42:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1D84283C0A1 for ; Sat, 18 Jun 2022 07:45:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQ7H60LDtz3qwc; Sat, 18 Jun 2022 07:45:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655538306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yrwvIe+YbD3dtM8Sg+m5cieknsxYe0+lel+7ZvOXJJg=; b=RL8pf2L8drR96d4XnRBYi2PrUA6q5L0rsbLs9ejN0jXD1Uv7KuIaXN/1vbm27AgY0ZyHI8 O9f1NF+nM74H2srvsnJSR6HXhB+34ojqk/1CO7xRxVQDcrzfZXSmJKVIzJbfokas/wp/Jc q1YgvcNmytD82lch59eRKUz4q4XNV7LK0TUHHl/z52Pc7NLcWlmfBvfSI5KtnB87/8ajJP bEVtENKMBnQgldiuCNUn+5IWvG4z/OTSvwn6oTXsX4zRrP1bGlVtH0IKMIG88WX3et7LQ6 F+AMBXyq97pu2x6IeaNrZEeLmRLKIXJ32jzCvTNgzGoLeB0w30UrRt3wRGbapQ== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id C6A7B2A488; Sat, 18 Jun 2022 07:45:05 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id F208231399; Sat, 18 Jun 2022 09:45:03 +0200 (CEST) From: Kristof Provost To: Pau Amma Cc: FreeBSD Hackers Subject: Re: RFD: MFC hold time guidelines Date: Sat, 18 Jun 2022 09:42:48 +0200 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: <83c320038e43abe1d8bd59b9364a225e@gundo.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655538306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yrwvIe+YbD3dtM8Sg+m5cieknsxYe0+lel+7ZvOXJJg=; b=lRjzGS8ZsoL0qf5YFzP+WyjPllG0QDEyvGyoamrujjkLHXHPBMo5wfk4uDKM69V/RFUM2T 80t9SdonnCdaMOw61aHhJAPXeXbu9zn6oGzUf7XpehFcbpz29gh/8vtQS22F1n1K8ehAEC qxIwc7cdr21bDCy1/W/KQEbNZSDmOQ6ZAUyjSjMMGruKdo1tlYSyeEpivKXGwAM72yd6Ff U478JwfSNAYWYYN0j8bZaLdBd5ZkUr6X9n1d90HqQBSklzCiNVzW4CnouXUhbzOrC1eE6E eNHDEPkcTjxjxHIWYbgisD+/vFi90TO6k9gQr/li951HHjK7F2na7cK1XIONcg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655538306; a=rsa-sha256; cv=none; b=p0pn7xHlxU69w8NDY223IQ2EB/DdqNmafZrW4OLbyLjH9cIwFdw/GVgzqlYkJxnwg95JVY LEch/F2dKb4t223C8M59Gbotz+Lk7orsg+1W+26C++Q3VQJgm8eJStgFejCM0YzMKNP7w2 j6TvmKCDXiHhL7DyLylvjvBHryV/HzRhTTG764ECyp1ycbyh0+GYFWdn9e0ddc98CrK0FC Ej7InBz7gRKSsOjYDqtCUbFqfQqmRh6qjpVhZuYYTYaKuXYlu3SB9T0rUeXB0AtiB+VOO3 3mKghkjKfoXmmUTw3ZWs0zmBiqd1TZh19xGl+jiuYCbLmnIU2UaOiXaC3ARoRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 16 Jun 2022, at 18:51, Pau Amma wrote: > https://reviews.freebsd.org/D35405 brought to light the lack of documen= ted MFC hold time guidelines for src (only repo that uses that) beyond: b= arring critical fixes authorized by release engineering or the security o= fficer, 3 days is the minimum. I'd like to have general guidelines hashed= out and added to the committer's guide. To get things started, here's wh= at Ed Maste reported using: > > instant MFC: security or critical build fixes, or other critical change= s, with coordination/approval of re@ or so@ > 3 days: straightforward bug fixes or minor improvements where there is = a (presumed) very low probability of introducing a regression. e.g. typo = fixes, man page updates > 1 week: default timeout for most changes with low-medium presumed proba= bility of introducing regressions e.g. adding to a driver's supported dev= ices list, general bug fixes and new features > 2 weeks, 3 weeks, 1 month: longer timeouts for changes with increasing = likelihood of environment-dependent bugs or unique or rare corner cases e= =2Eg. major updates to contrib software, significant rework to kernel sub= systems > My own approach is very similar to Ed=E2=80=99s. The risk estimation is very much a gut feeling thing, and I sometime use = longer timeouts because I know I won=E2=80=99t be available when the =E2=80= =98normal=E2=80=99 timeout would hit. (That is, more risk implies a longe= r timeout, but a longer timeout might not be due to increased risk.) Kristof From nobody Sat Jun 18 12:35:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8E126847AA2 for ; Sat, 18 Jun 2022 12:35:52 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4LQFkb0njPz3HLq for ; Sat, 18 Jun 2022 12:35:51 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id BB9F34C2367 for ; Sat, 18 Jun 2022 07:35:43 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 18 Jun 2022 12:35:43 +0000 From: Pau Amma To: freebsd-hackers@freebsd.org Subject: Re: RFD: MFC hold time guidelines In-Reply-To: <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LQFkb0njPz3HLq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-06-16 18:00, George Mitchell wrote: > On 6/16/22 12:51, Pau Amma wrote: >> [...] >> For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ >> *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb >> | uniq -ci | sort -bf -k 1nr >> [...] > > A command line I'm sure you dashed off without a moment's hesitation! I'm confused. If you're wondering what this command does or how I came up with it, why not ask that? Either way, I'm still looking for feedback or answers on the actual point of my email. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Sat Jun 18 13:47:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 45898865B25 for ; Sat, 18 Jun 2022 13:47:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQHKp16zTz3lsw for ; Sat, 18 Jun 2022 13:47:58 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655560078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mQ3iZenCU1gUDqB9R27qrtx729j4JC0Pox1YZTqNLfI=; b=qGF0II05L4zp25u/6lsP7EWu5yUX1UOfb47tUkYyAoYtF05mQTqst/ooOrLTpYIEbPMOts wE4eNHvl011MQEBzx12MIE1lzpH3GFmvO75LlDrBdhcvc4fO0NMjBW1JUVxesKiMIRwm8R Y2u+4swnXOH0/yBypEJFu7iWrI9M2zX6ALQ/3kMtFb4cEtQGe/fMc3QD7TbVKNjZnQAnO8 UQNuP9fe9oz49p0AON8emIcIV8CGRcHwu/nWuUVWfA7iFFo5YcQN0RgutMxTx/XHf4R4Y2 uwfmNV9L9W2Mh4PN3XDVaJq/Xt5Z8evAtff8RI5be/I1DpYtVcMxpRh2Wgor/w== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 115BD57D0; Sat, 18 Jun 2022 13:47:58 +0000 (UTC) Date: Sat, 18 Jun 2022 15:47:55 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: RFD: MFC hold time guidelines Message-ID: <20220618134755.jpyicxonlgtacyaq@geroi.local> References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bmta6rpbneqsslor" Content-Disposition: inline In-Reply-To: <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1655560078; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mQ3iZenCU1gUDqB9R27qrtx729j4JC0Pox1YZTqNLfI=; b=PKvrPIAdO08ejaDfv9NR6UHvBQxzXBo4lbOGIqeQiGBXp5YOa1BkKbU2XGh4MpDCH43IDk NnHOw1g7SRU8/uM6gWbjCeb8/nuzQBdu8XtZBUV9IKcSthFqK3HIpudP0yYB2q7stk9dfZ RIZFrgKxbIQ9w32VEYYCTonGEZkubU8Lf12eYaqawQiL1AnXTgF69xV6/P2H1vFoLKz97D hlw63T9knmREJ3t9yHZI4T4gWAI6jmJhJ0m+yUOADMgIS30cG46NurFnOmboP8SCTpsNcG PX8i4mDjqb+MQo/kCzFTVKq3QIkkAbTIPWR06Ux/MRrf2BqDmou4HX5aYn6Jzg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1655560078; a=rsa-sha256; cv=none; b=smMHUZFd4hHiD7qArnaP2VCfHmyVbL8y7RJhZEzp0/dAgbS6wYeSZmWFogYOV79CFfEOqN tKrx2BfA2tkpEVUwAsp1N4LEfF341EyzJEIrtpEVKpGkV35Goie+BcEihxDfUfvObLG4xw EIsEISyZewcmTO9IbMeSPOUgLlUvnaoc6JZ20gGiijHZ2Jgr2KwUXgBe1VQK5luVYx6teD 0Zjp1fjfuh4sGdXxzgfl3gghhMbE0VeaHh24CqcnPCbn1z/YKndy60FKOfCeefdUkT9BxV Ax/Omqp/wt5PvPcfsKgS6vzFDJokFNcPrIUHPCFBKhwbC/GphQl3liPLDy/gxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --bmta6rpbneqsslor Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2022 at 12:35:43PM +0000, Pau Amma wrote: >On 2022-06-16 18:00, George Mitchell wrote: >>On 6/16/22 12:51, Pau Amma wrote: >>>[...] >>>For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^=20 >>>*(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort=20 >>>-fb | uniq -ci | sort -bf -k 1nr >>>[...] >> >>A command line I'm sure you dashed off without a moment's hesitation! > >I'm confused. If you're wondering what this command does or how I came=20 >up with it, why not ask that? > >Either way, I'm still looking for feedback or answers on the actual=20 >point of my email. > >--=20 >#BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters=20 >#StandWithUkrainians >English: he/him/his (singular they/them/their/theirs OK) >French: il/le/lui (iel/iel and ielle/ielle OK) >Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > > Hi folks, I think The Way Of Ed matches what I consider to be prudent, so barring anyone with a paintbrush and a shed, I think we might go with that? I also think Kristof is onto something, with the whole bumping one or more levels, if you happen to know that a specific timing won't work out particularly well. Incidentally, it's a cute usage of pipes and standard I/O :) Yours, Daniel Ebdrup Jensen --bmta6rpbneqsslor Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmKt14tfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oVpgf+Ow45IJvqHpeFWZrBTstzd3FgvHM0VDvnN17kP+rSGxj6BJMTHtlH2asC n8IYey46ZtcT9DC+EssVl32TMWBNWZ1BYXl99gWhy4v1uokwuW1xdCP4IjYEFPgd 0BeF1vHW6G4N9X/OApx86fhm5kQ6Z5aK8yhsYDskOL7hllpSOuBBKOMlSTH3tFu+ qgo9uul4PzZSDg7oDH9W0vieEsV8jjoNqeVEb7tledAhEfwe2IyI/r9IKF082nHO rtGmVsieNTB3nEZajsnOqNhbt7r0StlV/wnt00vPv3JvSYL3WplTHNzemlG+G+tK N2bZoVmVGTVGyUNr9VlEg4Uz5aj3iw== =PVmZ -----END PGP SIGNATURE----- --bmta6rpbneqsslor-- From nobody Sat Jun 18 17:33:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 329AD86274A for ; Sat, 18 Jun 2022 17:33:42 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]) (using TLSv1.3 with cipher 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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQNLF3dK9z4lsc for ; Sat, 18 Jun 2022 17:33:41 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 25IHXPNW029898 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 18 Jun 2022 13:33:32 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sat, 18 Jun 2022 13:33:25 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: RFD: MFC hold time guidelines Content-Language: en-US To: freebsd-hackers@freebsd.org References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> From: George Mitchell In-Reply-To: <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4LQNLF3dK9z4lsc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 2001:470:1f07:15ff::f7 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-3.28 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.984]; ARC_NA(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; TAGGED_FROM(0.00)[freebsd] X-ThisMailContainsUnwantedMimeParts: N On 6/18/22 08:35, Pau Amma wrote: > On 2022-06-16 18:00, George Mitchell wrote: >> On 6/16/22 12:51, Pau Amma wrote: >>> [...] >>> For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ >>> *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort -fb >>> | uniq -ci | sort -bf -k 1nr >>> [...] >> >> A command line I'm sure you dashed off without a moment's hesitation! > > I'm confused. If you're wondering what this command does or how I came > up with it, why not ask that? > [...] I was merely expressing (poorly, it seems) my admiration that you were able to come up with that string of commands, apparently on the spur of the moment, to accomplish what you wanted. No offense was intended. -- George From nobody Sun Jun 19 05:02:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76610842CE2 for ; Sun, 19 Jun 2022 05:03:13 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQgdr1V0yz4kXw for ; Sun, 19 Jun 2022 05:03:11 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.12.130] (d130.office.dcrosstech.com [10.1.12.130]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 25J52s7h010647 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sun, 19 Jun 2022 05:02:55 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d130.office.dcrosstech.com [10.1.12.130] claimed to be [10.1.12.130] Message-ID: <40d5a14d-0166-ed3b-911e-dedb945eea7e@crossfamilyweb.com> Date: Sun, 19 Jun 2022 01:02:54 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: freebsd-hackers@freebsd.org From: "David E. Cross" Subject: Weird loader.efi issue on fresh 13.1 upgrade Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LQgdr1V0yz4kXw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.90)[-0.904]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_NA(0.00)[crossfamilyweb.com]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N So I just hit a weird issue with loader.efi on a fresh upgrade from 13.0 to 13.1.  The system comes up, asks me for my GELI password, accepts it, displays an error about Boot19 having only one DP, then iterates through all of the partitions on the disk... and then displays an error message about not being able to find a boot partition and displays a reboot counter. If I then interrupt the countdown at this point, get to a loader prompt and set rootdev and curdev to disk0p3: (the right value, and actually one of the values that it looped through!) I can then load /boot/kernel/kernel and boot everything successfully (including having the root disk unencrypted). This worked before the 13.0 upgrade.  This worked with the 13.1 kernel running against 13.0 loader.  It only stopped working with 13.1 loader with 13.1 kernel. Getting an *EXACT* copy of the error messages is a bit of a challenge given where this is in the boot sequence. I think I am about to start code diving about what makes loader give up on a partition. From nobody Sun Jun 19 06:25:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2836F85F7AD for ; Sun, 19 Jun 2022 06:25:31 +0000 (UTC) (envelope-from agh@riseup.net) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.riseup.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQjSn4HGbz4t6J for ; Sun, 19 Jun 2022 06:25:29 +0000 (UTC) (envelope-from agh@riseup.net) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4LQjSd5w5rzDqDx; Sun, 19 Jun 2022 06:25:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1655619921; bh=6pPanYQdSd/WFExZt1cME3aDg7gklLWhGusw5YvEwro=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pW6C6jxHjbTDvGG600KDoXLPx2k7IVOfpevLS+aQbCP8jRpBXYCDsdWitgalYtaYO zMAvMDlxDTgWTqXAqH1Y/6/S4GDHCSWRQg8IwX3njNusRBLKnxUYkfrgv76/3X8rAH n+A+lj8gw7Jp7OkQJpXLxAJVzxWGssGnP9dPYVTQ= X-Riseup-User-ID: 21D619EB10992FD1A0A7DF1C6BC071BE7ADA9B81A1E7CF737A1037DD5B4176D2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4LQjSd440Kz1yXB; Sun, 19 Jun 2022 06:25:20 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 19 Jun 2022 06:25:20 +0000 From: Alastair Hogge To: "David E. Cross" Cc: freebsd-hackers@freebsd.org Subject: Re: Weird loader.efi issue on fresh 13.1 upgrade In-Reply-To: <40d5a14d-0166-ed3b-911e-dedb945eea7e@crossfamilyweb.com> References: <40d5a14d-0166-ed3b-911e-dedb945eea7e@crossfamilyweb.com> Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LQjSn4HGbz4t6J X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=riseup.net header.s=squak header.b=pW6C6jxH; dmarc=pass (policy=none) header.from=riseup.net; spf=pass (mx1.freebsd.org: domain of agh@riseup.net designates 198.252.153.129 as permitted sender) smtp.mailfrom=agh@riseup.net X-Spamd-Result: default: False [-4.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[riseup.net:s=squak]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[riseup.net:dkim]; RWL_MAILSPIKE_GOOD(0.00)[198.252.153.129:from]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[riseup.net:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[riseup.net,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16652, ipnet:198.252.153.0/24, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[198.252.153.129:from] X-ThisMailContainsUnwantedMimeParts: N On 2022-06-19 13:02, David E. Cross wrote: > So I just hit a weird issue with loader.efi on a fresh upgrade from > 13.0 to 13.1.  The system comes up, asks me for my GELI password, > accepts it, displays an error about Boot19 having only one DP, then > iterates through all of the partitions on the disk... and then > displays an error message about not being able to find a boot > partition and displays a reboot counter. > > > If I then interrupt the countdown at this point, get to a loader > prompt and set rootdev and curdev to disk0p3: (the right value, and > actually one of the values that it looped through!) I can then load > /boot/kernel/kernel and boot everything successfully (including having > the root disk unencrypted). > > > This worked before the 13.0 upgrade.  This worked with the 13.1 kernel > running against 13.0 loader.  It only stopped working with 13.1 loader > with 13.1 kernel. > > > Getting an *EXACT* copy of the error messages is a bit of a challenge > given where this is in the boot sequence. > > > I think I am about to start code diving about what makes loader give > up on a partition. Some investigation has already been explored at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 From nobody Sun Jun 19 09:02:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EDE75863569 for ; Sun, 19 Jun 2022 09:02:56 +0000 (UTC) (envelope-from kfv@kfv.io) Received: from mail.kfv.io (mail.kfv.io [95.217.128.176]) (using TLSv1.3 with cipher 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 "kfv.io", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LQmyR58jsz3Pfl for ; Sun, 19 Jun 2022 09:02:55 +0000 (UTC) (envelope-from kfv@kfv.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kfv.io; s=dkim; t=1655629366; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Ga4iCMz3YmsHOxohfsUn/xQ8ZDnYzibYnJzanmxeJcQ=; b=IjJp0CgASMOKc0j0FOcS5IHUB2Box3fwP0er6d4CJ/MNIQBa/uJRsBnitbbdwNnB5EtODa RnoPxJJH6wGfe68FtCXyciRJVfzGk94K+YzbRjS0AOyK9lnrgzYX/7ul8PpFJvNhVtZmOq P+yr6VasjWG6XEIEn8VPLqiQTQPPeyjgnEtB6Wyo+LAxBb+QrakJZbPmfgfa8IaLNXVbma 0bgQ5F3gjlflBNBwAIbbv2DuHVxiruUk7ZYIgpacRLkhjwC4gNPkW5eabEzmq0ZaYPJymq GmI/InY4Dwwj5dONsUlf4IREQnimXX5pkfimW7vpn6EzgbtekcCh+fVNF6RUjg== Received: from x1 ( [195.250.72.137]) by srv.kfv.io (OpenSMTPD) with ESMTPSA id 2ccbae3d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Sun, 19 Jun 2022 09:02:46 +0000 (UTC) Date: Sun, 19 Jun 2022 09:02:43 +0000 From: Faraz Vahedi To: freebsd-hackers@FreeBSD.org Subject: poudriere-testport(8): Cannot build ports-mgmt/pkg on a 13.1-RELEASE arm64.aarch64 jail Message-ID: <20220619090243.fb42eww4mqyly2e2@x1> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7o32fpvqyz6ff5ef" Content-Disposition: inline X-Rspamd-Queue-Id: 4LQmyR58jsz3Pfl X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kfv.io header.s=dkim header.b=IjJp0CgA; dmarc=pass (policy=reject) header.from=kfv.io; spf=pass (mx1.freebsd.org: domain of kfv@kfv.io designates 95.217.128.176 as permitted sender) smtp.mailfrom=kfv@kfv.io X-Spamd-Result: default: False [-5.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[kfv.io:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.217.128.176]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[kfv.io:+]; DMARC_POLICY_ALLOW(-0.50)[kfv.io,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[195.250.72.137:received] X-ThisMailContainsUnwantedMimeParts: N --7o32fpvqyz6ff5ef Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings everyone, I hope you're having a wonderful weekend. The following is what I get on an arm64 jail - my host is an amd64 running 14.0-CURRENT from commit 2ff6e4ee976: ... =3D=3D=3D> Configuring for pkg-1.17.5_1 No installed jimsh or tclsh, building local bootstrap jimsh0 No working C compiler found. Tried /nxb-bin/usr/bin/cc and gcc. =3D=3D=3D> Script "configure" failed unexpectedly. Please report the problem to pkg@FreeBSD.org [maintainer] and attach the "/wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.17.5/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.17.5/src/pkg-static info -g -Ea). *** Error code 1 =20 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg *** Error code 1 =20 Stop. make: stopped in /usr/ports/ports-mgmt/pkg =3D>> Cleaning up wrkdir =3D=3D=3D> Cleaning for pkg-1.17.5_1 ... For full log, check this out please: http://poudriere.kfv.io/data/r131_arm64-default/2022-06-18_16h09m30s/lo= gs/errors/pkg-1.17.5_1.log This is only happening on 13.1-RELEASE arm64. I have no issue with 12.3-RELEASE and 14.0-CURRENT jails of the same arm64 architecture. I would appreciate any help. Cheers, Faraz --7o32fpvqyz6ff5ef Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEER72OR2ke+5+zBDNGxovV64RZlvEFAmKu5jMACgkQxovV64RZ lvH9Fgf9GY7uHdHlqa5sHLQjkbJFLm94ggHcdnQCTCOzuME2IjQa6jqHUppBtrpB RLq2AjKqeKuK70gnzv+m28n5DChQ1QQVTeVmuEx4Tt3UOYEb5X01pFSj3nVIjuQE B0u5eKe5S4gne4ahhuUTJydof6artm7Z8ETtibWB9m0z9iZtk7ByKbP+SuOdcby/ 7BXcQiCbqfJ6ICEJBbd/lMInLwgRgtgecliPBgXomgZq8VMdd+EPzw8VZTxGYVPF uteFu37NQYfg3iwJTprao9zxtkU5yR+oS9R7C5GLFWg5POrPLTEuclm7ka0+PYs2 cC3jIsFYqtaD1wHUJnfhB/Q61Sfb/g== =ZKOf -----END PGP SIGNATURE----- --7o32fpvqyz6ff5ef-- From nobody Sun Jun 19 13:55:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5E99786AF7C for ; Sun, 19 Jun 2022 13:55:11 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4LQvRf3rv6z4jxl for ; Sun, 19 Jun 2022 13:55:10 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 734674C12BF for ; Sun, 19 Jun 2022 08:55:04 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 19 Jun 2022 13:55:04 +0000 From: Pau Amma To: freebsd-hackers@freebsd.org Subject: Re: RFD: MFC hold time guidelines In-Reply-To: References: <83c320038e43abe1d8bd59b9364a225e@gundo.com> <3452c9c1-dd46-fe42-8100-b99ee51389f5@m5p.com> <3be500954ea9ffe0aff60d913e3bd24c@gundo.com> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <3def981b148772b7e8d43e0f30c9d6d6@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LQvRf3rv6z4jxl X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[pauamma]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[75.145.166.65:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-06-18 17:33, George Mitchell wrote: > On 6/18/22 08:35, Pau Amma wrote: >> On 2022-06-16 18:00, George Mitchell wrote: >>> On 6/16/22 12:51, Pau Amma wrote: >>>> [...] >>>> For context: git log | grep -i -E 'MFC.*after.*:' | sed -E -e 's/^ >>>> *(X-?)?//i' -e 's/^MFC[a-z0-9]*[- ]after: */MFC after: /i' | sort >>>> -fb | uniq -ci | sort -bf -k 1nr >>>> [...] >>> >>> A command line I'm sure you dashed off without a moment's hesitation! >> >> I'm confused. If you're wondering what this command does or how I came >> up with it, why not ask that? >> [...] > > I was merely expressing (poorly, it seems) my admiration that you were > able to come up with that string of commands, apparently on the spur of > the moment, to accomplish what you wanted. No offense was intended. Thanks for the clarification. For the record, it went like this: - OK, git then grep, obviously. - Bleh. Do I have to put together some awk or perl to collapse and count the lines with identical delays? I dunwanna, but if I gotta, I gotta. - Wait, doesn't uniq have an option for counting duplicates? *checks uniq(1)* - Sweeeeeet, it does. So sort to get the lines with the same delay together, then uniq -c - Hmm. Sadly but predictably, there are variations on the MFC format, but a sed stage can help with that. (That one went through 3 or 4 revisions as I experimented, I think.) - So far so good. Now how do I get them in the right order? *digs through sort(1)* - Hmm, -k 1nr is all it takes? Could be much, much worse. I'm looking at you, DFSORT and IRRCO00. - Do I want to make sed handle more variants? Naaah, diminishing returns. That's a wrap. Total time was 20-25 minutes IIRC. Not that long considering, but still nowhere near "dashed off without a moment's hesitation" :-) -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Tue Jun 21 02:09:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E1A0F85EE51 for ; Tue, 21 Jun 2022 02:10:01 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LRqj505G8z3jb0 for ; Tue, 21 Jun 2022 02:10:01 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: by mail-yb1-xb2d.google.com with SMTP id t1so22074401ybd.2 for ; Mon, 20 Jun 2022 19:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=fsOsZlVVFcPRgC0Hd3hQsN6Jc2PBdwmCVEI5sCrZYwE=; b=cObw/D9g6Dn6UgWBAJqyGHDWu+LE4j4JnFIKmV9BOe4cw6iy9dwO9wvgtH0b19XhUC qXXOcLX838hBOKHuZkjLih5wmdlSlSZPIMaWPRyZr3VStJJEtdeDSDYsVGWdQO6t1u+Z vThPtr+k9T3ngbfpaSpm3dKNxbtBIQ6UFkmkBoSNvb25fNZUyHjte4RBaoFMaDeZfG5b zKIoY5LoCcHvXjrl/q5H/GJnkkCVf06Q46NrZQ7KFqPAlDZ6934cIAVt80ClX0NXGhHP VA/HSFcf4ZMa59c5Rc0EPzzHoHMpeTp+CmL/M5S06kduK1wxXCl562uegv5+TWEK7d4Q ubQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fsOsZlVVFcPRgC0Hd3hQsN6Jc2PBdwmCVEI5sCrZYwE=; b=5to4FqfkSt6FFS3hv3WToODufBZq1alXIYBw1yGfek74NZ5a0nDxlActf3qg4YcWQ+ 6Xll6Oi6vTCpZtQ0/iYR7624dfQqBvfC7jRONVzuhMjkOrhUijv7hhhDXoseXbvmjRED 0nTYxt2aF20KRP09+VdoK367gZm5z+t3o7YIMYD066qWyHX2kQeF/akWPJ2FA0wUar59 Xb56IxWHIqEaRRQ+3olKhvWKSqKRSJdroRSY0yChDN99kgGI2XAVWZlypvJo8bUwLLLQ mnsfYYyp1VFCy2MhUrjyvEyfUwhHn7tJptlpn7eAxK6Fi9kvUByraMNU6cayOxQ9XTkP ckPA== X-Gm-Message-State: AJIora8HF2hgVgJwBdzPH5q6Kz7EQgCeYwPC6+47yUscUu9ROz/FwZft gMPA9d/7vn3mQ0OjzRWCpykVxkVZ1sPm2TlsGZYUlVTLdHw= X-Google-Smtp-Source: AGRyM1t5pMok/I9h6M3h/oTbs1mpoxRudvV9L9v8QvyahTYrThGXEQdy2utD3TNenCeiQ6KHYOGMfiv/z9IJm7vkVa4= X-Received: by 2002:a05:6902:102c:b0:668:e7a3:1cdb with SMTP id x12-20020a056902102c00b00668e7a31cdbmr14298480ybt.122.1655777400332; Mon, 20 Jun 2022 19:10:00 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Harris Snyder Date: Mon, 20 Jun 2022 22:09:49 -0400 Message-ID: Subject: Sanity check on a change to module load order To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LRqj505G8z3jb0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="cObw/D9g"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of harrissnyder@gmail.com designates 2607:f8b0:4864:20::b2d as permitted sender) smtp.mailfrom=harrissnyder@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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)[-0.999]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2d:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I've been trying to get the iSCSI boot module to work ("isboot" in the ports collection) with a PCIe Mellanox NIC, and I noticed that isboot is declared as part of the SI_SUB_PROTO_END subsystem, whereas the mellanox driver module is SI_SUB_ROOT_CONF-2 (via a linux kpi #define), which comes later. So the iSCSI boot failed, because it couldn't find the Mellanox NIC as the driver wasn''t loaded yet. I am brand new to the FreeBSD kernel, but I was going to propose that the port maintainer simply move isboot down to SI_SUB_ROOT_CONF-1. Is this a bad idea for some reason that I'm not aware of? I tried the proposed modification on my own system. iSCSI boot is still failing, but for what I think is an unrelated reason. Even if I do get it working, are there any obvious undesirable side effects that I'm simply not aware of? Thanks, Harris Snyder From nobody Tue Jun 21 18:19:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB99586558D for ; Tue, 21 Jun 2022 18:19:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSFCr43L4z3tTL for ; Tue, 21 Jun 2022 18:19:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655835568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=spf73J6O/AvWdnDkc4N1wvenL6oAzAUFXhy332aCVOA=; b=qufaY5Cl/ued2ohaHxb0XGPOQ6wy4hAFcZz5uLjf3EDZUtYT2ilVFPxAm37ee8Lil1Bm9D 34cSDYTzURgi50SQDHdhnSc5djd6as2ireNNECQcDjTDBbp7wOyZar7QvFt/+j4tlX1PCJ xiyhqYce4tD1q3D7x6NLhSNENThRVjw= Received: from skull.home.blih.net (lfbn-idf2-1-899-227.w86-238.abo.wanadoo.fr [86.238.130.227]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 53056a60 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Tue, 21 Jun 2022 18:19:28 +0000 (UTC) Date: Tue, 21 Jun 2022 20:19:24 +0200 From: Emmanuel Vadot To: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> In-Reply-To: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LSFCr43L4z3tTL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=qufaY5Cl; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; DKIM_TRACE(0.00)[bidouilliste.com:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, On Fri, 26 Nov 2021 16:04:54 +0100 Emmanuel Vadot wrote: > > Hello all, > > I'm currently re-implementing the framebuffer code in linuxkpi for > drm-kmod and this made me look at sc(4), vt(4) and friends. > > So I looked at what sc could do and vt couldn't and vice-versa. > > What sc(4) can't do : > > - Work with EFI firmware. > - Support UTF-8 > - Maybe other things but everything here is EFI-based so let me know. > > What vt(4) can't do : > > - You can't get the modes or adapter info with vidcontrol. > vidcontrol -i mode is really made for anything vesa based as it > iterates on all the modes and display them if present. > In the modern world (EFI), we don't have that, EFI GOP doesn't > support changing resolution after ExitBootService was called so there > is only one "mode". I could possibly hack some patch so vidcontrol -i > mode/adapter would work and display the current framebuffer info if > people wants (but I honestly doubt that vidcontrol is useful at all in > an EFI world). > - "Blanking" screen doesn't do what you think it does. For some reason > in vt(4) we just write black colors on the screen and ignore the blank > mode passed in the ioctl. > Now again, blanking/dpms/blah isn't possible with efi_fb but it make > sense to fix vt(4) and drm-kmod so it calls the drm module blanking > function, I'll work on that next week. > - There is no screensaver, again see notes above for dpms but do > people still use sc(4) just for the screensaver ?? > - Maybe other things, please let me know. > > For libvgl it probably made sense back in the 90s but does it now ?? > > Based on my small list I don't see any good reason to keep sc(4) but > maybe I've missed something bigger so please let me know. > > P.S.: I'm really not interested by people saying stuff like > "I've always used sc(4), it works for me don't touch it" > without some technical argument. > > Cheers, > > -- > Emmanuel Vadot > I've put up in phab removing sc(4) from GENERIC and MINIMAL : https://reviews.freebsd.org/D35538 https://reviews.freebsd.org/D35539 If you have any good reason that sc(4) should be included in those kernel config for amd64 (no other arches was touched) please provide some argument on the reviews. Cheers, -- Emmanuel Vadot From nobody Tue Jun 21 18:36:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B56808698E4 for ; Tue, 21 Jun 2022 18:36:39 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSFbV56m3z4TpG for ; Tue, 21 Jun 2022 18:36:38 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2a02:22e0:cf00:1ff:cd4c:3200:7d9e:558f] (mzar@[IPv6:2a02:22e0:cf00:1ff:cd4c:3200:7d9e:558f]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 25LIaQIZ041762 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 21 Jun 2022 20:36:27 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1655836588; bh=5atfAyZabxMShuCpFejQLOojtwGf//fIRaaWSRe9mx8=; h=Date:Subject:To:References:From:In-Reply-To; b=CbtgqlQ2B5s9k0An+AE8G7dOokMlnYt9PY7tESY3Af3QENToUnLA9kqJNRYefsFGv x+dB+cL0uCY8SPeFG6UM2gxIL3VJn1nN8tR52DF1YuQWV6NqJxaZu3jD18694TZI2L rl6JY3eVpydAXiqClz5t7DYrN9QPIRpmgIDpn050F+O0wVuaZMiGpyVRvbgd235Fsi SujxNrUkcKW8DWH4WarYSLmm0CLCFGsLqShEG4DqjKzMnTfA+O5WJDtML/3e/PHJ9m mNTcZX2D6j+hRODqHJP4soHYejBTYFC7zI9acGhoi7XYtgAsOKTC97iyeSk50hqcO+ ADNctlQU3lUIw== Message-ID: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> Date: Tue, 21 Jun 2022 20:36:25 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Reasons for keeping sc(4) and libvgl ? Content-Language: en-US To: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> From: Marek Zarychta In-Reply-To: <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LSFbV56m3z4TpG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=CbtgqlQ2; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-2.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N W dniu 21.06.2022 o 20:19, Emmanuel Vadot pisze: > Hello, > > On Fri, 26 Nov 2021 16:04:54 +0100 > Emmanuel Vadot wrote: > >> Hello all, >> >> I'm currently re-implementing the framebuffer code in linuxkpi for >> drm-kmod and this made me look at sc(4), vt(4) and friends. >> >> So I looked at what sc could do and vt couldn't and vice-versa. >> >> What sc(4) can't do : >> >> - Work with EFI firmware. >> - Support UTF-8 >> - Maybe other things but everything here is EFI-based so let me know. >> >> What vt(4) can't do : >> >> - You can't get the modes or adapter info with vidcontrol. >> vidcontrol -i mode is really made for anything vesa based as it >> iterates on all the modes and display them if present. >> In the modern world (EFI), we don't have that, EFI GOP doesn't >> support changing resolution after ExitBootService was called so there >> is only one "mode". I could possibly hack some patch so vidcontrol -i >> mode/adapter would work and display the current framebuffer info if >> people wants (but I honestly doubt that vidcontrol is useful at all in >> an EFI world). >> - "Blanking" screen doesn't do what you think it does. For some reason >> in vt(4) we just write black colors on the screen and ignore the blank >> mode passed in the ioctl. >> Now again, blanking/dpms/blah isn't possible with efi_fb but it make >> sense to fix vt(4) and drm-kmod so it calls the drm module blanking >> function, I'll work on that next week. >> - There is no screensaver, again see notes above for dpms but do >> people still use sc(4) just for the screensaver ?? >> - Maybe other things, please let me know. >> >> For libvgl it probably made sense back in the 90s but does it now ?? >> >> Based on my small list I don't see any good reason to keep sc(4) but >> maybe I've missed something bigger so please let me know. >> >> P.S.: I'm really not interested by people saying stuff like >> "I've always used sc(4), it works for me don't touch it" >> without some technical argument. >> >> Cheers, >> >> -- >> Emmanuel Vadot >> > I've put up in phab removing sc(4) from GENERIC and MINIMAL : > > https://reviews.freebsd.org/D35538 > https://reviews.freebsd.org/D35539 > > If you have any good reason that sc(4) should be included in those > kernel config for amd64 (no other arches was touched) please provide > some argument on the reviews. > > Cheers, > Thanks for heads up. Unfortunately, it will be a great loss. The waste of power resources might increase since vt(4) still doesn't support VESA Display Power Management Signaling which some of the servers are heavily relying on. It's a step backward in terms of green computing and amidst the power crisis, we are heading in Europe. -- Marek Zarychta From nobody Tue Jun 21 19:01:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4DDA786DAF8 for ; Tue, 21 Jun 2022 19:02:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSG8v024pz4Yxd for ; Tue, 21 Jun 2022 19:02:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id E0ED88928B; Tue, 21 Jun 2022 19:01:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 25LJ1wg5067377 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Jun 2022 19:01:58 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 25LJ1uBd067376; Tue, 21 Jun 2022 19:01:56 GMT (envelope-from phk) Message-Id: <202206211901.25LJ1uBd067376@critter.freebsd.dk> To: Marek Zarychta cc: Emmanuel Vadot , freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? In-reply-to: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> From: "Poul-Henning Kamp" References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <67374.1655838116.1@critter.freebsd.dk> Date: Tue, 21 Jun 2022 19:01:56 +0000 X-Rspamd-Queue-Id: 4LSG8v024pz4Yxd X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [1.97 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; NEURAL_SPAM_SHORT(1.00)[0.997]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.955]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N -------- Marek Zarychta writes: > Thanks for heads up. Unfortunately, it will be a great loss. The waste > of power resources might increase since vt(4) still doesn't support VESA > Display Power Management Signaling [...] But the operative word there is "still", isn't it ? There is nothing which prevents vt(4) from doing the right thing is there ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Tue Jun 21 20:51:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 05E5B86201E for ; Tue, 21 Jun 2022 20:51:33 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSJb844FBz4v55 for ; Tue, 21 Jun 2022 20:51:32 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 25LKpIbW045866; Tue, 21 Jun 2022 13:51:24 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 21 Jun 2022 13:51:17 -0700 From: Chris To: Marek Zarychta Cc: Emmanuel Vadot , freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? In-Reply-To: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> User-Agent: UDNSMS/17.0 Message-ID: <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_2e34baeb8c4f81241cf1013cf6555c5f" X-Rspamd-Queue-Id: 4LSJb844FBz4v55 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_2e34baeb8c4f81241cf1013cf6555c5f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-06-21 11:36, Marek Zarychta wrote: > W dniu 21.06.2022 o 20:19, Emmanuel Vadot pisze: >> Hello, >> >> On Fri, 26 Nov 2021 16:04:54 +0100 >> Emmanuel Vadot wrote: >> >>> Hello all, >>> >>> I'm currently re-implementing the framebuffer code in linuxkpi for >>> drm-kmod and this made me look at sc(4), vt(4) and friends. >>> >>> So I looked at what sc could do and vt couldn't and vice-versa. >>> >>> What sc(4) can't do : >>> >>> - Work with EFI firmware. >>> - Support UTF-8 >>> - Maybe other things but everything here is EFI-based so let me know. >>> >>> What vt(4) can't do : >>> >>> - You can't get the modes or adapter info with vidcontrol. >>> vidcontrol -i mode is really made for anything vesa based as it >>> iterates on all the modes and display them if present. >>> In the modern world (EFI), we don't have that, EFI GOP doesn't >>> support changing resolution after ExitBootService was called so there >>> is only one "mode". I could possibly hack some patch so vidcontrol -i >>> mode/adapter would work and display the current framebuffer info if >>> people wants (but I honestly doubt that vidcontrol is useful at all in >>> an EFI world). >>> - "Blanking" screen doesn't do what you think it does. For some reason >>> in vt(4) we just write black colors on the screen and ignore the blank >>> mode passed in the ioctl. >>> Now again, blanking/dpms/blah isn't possible with efi_fb but it make >>> sense to fix vt(4) and drm-kmod so it calls the drm module blanking >>> function, I'll work on that next week. >>> - There is no screensaver, again see notes above for dpms but do >>> people still use sc(4) just for the screensaver ?? >>> - Maybe other things, please let me know. >>> >>> For libvgl it probably made sense back in the 90s but does it now ?? >>> >>> Based on my small list I don't see any good reason to keep sc(4) but >>> maybe I've missed something bigger so please let me know. >>> >>> P.S.: I'm really not interested by people saying stuff like >>> "I've always used sc(4), it works for me don't touch it" >>> without some technical argument. >>> >>> Cheers, >>> >>> -- Emmanuel Vadot >>> >> I've put up in phab removing sc(4) from GENERIC and MINIMAL : >> >> https://reviews.freebsd.org/D35538 >> https://reviews.freebsd.org/D35539 >> >> If you have any good reason that sc(4) should be included in those >> kernel config for amd64 (no other arches was touched) please provide >> some argument on the reviews. >> >> Cheers, >> > Thanks for heads up. Unfortunately, it will be a great loss. The waste of > power > resources might increase since vt(4) still doesn't support VESA Display > Power > Management Signaling which some of the servers are heavily relying on. It's > a step > backward in terms of green computing and amidst the power crisis, we are > heading > in Europe. My only objection is that I can NOT get textmode or very stable X on any of the NVIDIA cards I use unless I build against sc. Does sc(4) use so much space that current kernels become too big with it's presence? I vote against it's removal. Chris --=_2e34baeb8c4f81241cf1013cf6555c5f Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_2e34baeb8c4f81241cf1013cf6555c5f-- From nobody Wed Jun 22 01:23:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1FF74862755 for ; Wed, 22 Jun 2022 01:24:03 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSQdZ2949z4bQ8 for ; Wed, 22 Jun 2022 01:24:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f43.google.com with SMTP id o7so31041028eja.1 for ; Tue, 21 Jun 2022 18:24:02 -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=A+Zk99c/9aFK+ATc4KkguL7bXx9J8qXG52jqrjMqWII=; b=BPAYH+3xSi/jhpjB/R1Lo1UzVQwzBVV3+KHMzfpgEvOopoPdqrCQlFkDNjoSeiKl5o JhumwbqASHrnogtqfVcJq6s1Uo/kK0bPIM0vLF1wZ2FkV8NU4+qtn7F2PwyU7T4CesoZ 5hAT5ZhCnAjj0RHM4IiPT2HTP55L3uLkM6Wlv3ZCeqYMWoCIgAuzd0EjWBboxL0vojtw DAv9KiCe/Vn1DGAlM4vjfQbgngI5G5nRObHNkKlm4o65+gdqnE9vCfYwXRu1zUwNSWlA uQJ3Qk8bud3oVtd2Q0FEzShCHFLib1Xypm9HdxWoQeKaQyiI+q8+Lz/nBD9+bSbJW+LP W2aw== X-Gm-Message-State: AJIora9oXN1xP7wyEmniARCQCTvZ3raNte6GLJTnWp+lx/tSfkGseruq vUG/RSTz9cbLv2mBz4vziuRPhZAkAO35WHF4nA8= X-Google-Smtp-Source: AGRyM1sZmORDyo50PC37ReZ6v2h0LimBPZMXz5Qu0Nn5ZPx7hukhzvn0kY/27FPo6sslqME60sbIr+b2BxGLHgT1Buo= X-Received: by 2002:a17:906:b795:b0:722:e662:cffe with SMTP id dt21-20020a170906b79500b00722e662cffemr767125ejb.121.1655861034655; Tue, 21 Jun 2022 18:23:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> In-Reply-To: <202206211901.25LJ1uBd067376@critter.freebsd.dk> From: Ed Maste Date: Tue, 21 Jun 2022 21:23:42 -0400 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Poul-Henning Kamp Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LSQdZ2949z4bQ8 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [1.72 / 15.00]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(0.72)[0.715]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.43:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.43:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp wrote: > > But the operative word there is "still", isn't it ? > > There is nothing which prevents vt(4) from doing the right thing is there ? Just a simple matter of programming. We should indeed add dpms support to vt. From nobody Wed Jun 22 02:46:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F3B486D2BA for ; Wed, 22 Jun 2022 02:46:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSSSV3fVDz4kC2 for ; Wed, 22 Jun 2022 02:46:18 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655865976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1GgEbW130KcXylUO+bsFTkVmYMjFpALf3aq68p/Gwcs=; b=ZRuHkZYfr5BYAwK907b6jDDVClM1YHzakNXZVdrdgmhDrk/M6jq9Baur7SA04d3aspCjSm X5+OaAQyWsgRVXpomsKixlMYsSuryDh/3KmMZf/CWIpma2+VAKFT/fFZRJMdTVfjYqSTmk KMG6fi4CQFgtkQqtIXSDTMLMBIUXpoc= Received: from amy (lfbn-idf2-1-1159-38.w90-92.abo.wanadoo.fr [90.92.219.38]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 1efe6e79 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 22 Jun 2022 02:46:16 +0000 (UTC) Date: Wed, 22 Jun 2022 04:46:16 +0200 From: Emmanuel Vadot To: Marek Zarychta Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220622044616.b44bf8bed156940a3a67f05d@bidouilliste.com> In-Reply-To: <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LSSSV3fVDz4kC2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=ZRuHkZYf; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.75)[-0.751]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 21 Jun 2022 20:36:25 +0200 Marek Zarychta wrote: > W dniu 21.06.2022 o=A020:19, Emmanuel Vadot pisze: > > Hello, > > > > On Fri, 26 Nov 2021 16:04:54 +0100 > > Emmanuel Vadot wrote: > > > >> Hello all, > >> > >> I'm currently re-implementing the framebuffer code in linuxkpi for > >> drm-kmod and this made me look at sc(4), vt(4) and friends. > >> > >> So I looked at what sc could do and vt couldn't and vice-versa. > >> > >> What sc(4) can't do : > >> > >> - Work with EFI firmware. > >> - Support UTF-8 > >> - Maybe other things but everything here is EFI-based so let me know. > >> > >> What vt(4) can't do : > >> > >> - You can't get the modes or adapter info with vidcontrol. > >> vidcontrol -i mode is really made for anything vesa based as it > >> iterates on all the modes and display them if present. > >> In the modern world (EFI), we don't have that, EFI GOP doesn't > >> support changing resolution after ExitBootService was called so there > >> is only one "mode". I could possibly hack some patch so vidcontrol -i > >> mode/adapter would work and display the current framebuffer info if > >> people wants (but I honestly doubt that vidcontrol is useful at all in > >> an EFI world). > >> - "Blanking" screen doesn't do what you think it does. For some reas= on > >> in vt(4) we just write black colors on the screen and ignore the blank > >> mode passed in the ioctl. > >> Now again, blanking/dpms/blah isn't possible with efi_fb but it ma= ke > >> sense to fix vt(4) and drm-kmod so it calls the drm module blanking > >> function, I'll work on that next week. > >> - There is no screensaver, again see notes above for dpms but do > >> people still use sc(4) just for the screensaver ?? > >> - Maybe other things, please let me know. > >> > >> For libvgl it probably made sense back in the 90s but does it now ?? > >> > >> Based on my small list I don't see any good reason to keep sc(4) but > >> maybe I've missed something bigger so please let me know. > >> > >> P.S.: I'm really not interested by people saying stuff like > >> "I've always used sc(4), it works for me don't touch it" > >> without some technical argument. > >> > >> Cheers, > >> > >> --=20 > >> Emmanuel Vadot > >> > > I've put up in phab removing sc(4) from GENERIC and MINIMAL : > > > > https://reviews.freebsd.org/D35538 > > https://reviews.freebsd.org/D35539 > > > > If you have any good reason that sc(4) should be included in those > > kernel config for amd64 (no other arches was touched) please provide > > some argument on the reviews. > > > > Cheers, > > > Thanks for heads up. Unfortunately, it will be a great loss. The waste=20 > of power resources might increase since vt(4) still doesn't support VESA= =20 > Display Power Management Signaling which some of the servers are heavily= =20 > relying on. It's a step backward in terms of green computing and amidst=20 > the power crisis, we are heading in Europe. >=20 > --=20 > Marek Zarychta >=20 Does that make sense nowadays ? You don't plug screen into servers, you have BMCs and even if I guess that some BMC "support" DPMS I'm not sure if it actually saves power. --=20 Emmanuel Vadot From nobody Wed Jun 22 02:47:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9618E86DB45 for ; Wed, 22 Jun 2022 02:47:16 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSSTb3rK2z4l6y for ; Wed, 22 Jun 2022 02:47:15 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655866034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1r0HkLggGafeVSvs3t9Hu2FInQE5HRTKKox7u1xR9cg=; b=HTb6ysGX3Tqm5HCGHt7wuvEpu5C+UYQ8Ym9Z7HLmv6iInuWhsPolzIsjmGs4G5V/OPHqez h/KQh13pRtjI0hllFhWGBqZQ5xRfW4PHVtDJnw1PenH/W2BO0CL5cF1zdmNcX/B/vnuHWx /gCPiDbWPCuaWCtvpPFPFEAm9ZhWpFw= Received: from amy (lfbn-idf2-1-1159-38.w90-92.abo.wanadoo.fr [90.92.219.38]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 22284139 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 22 Jun 2022 02:47:14 +0000 (UTC) Date: Wed, 22 Jun 2022 04:47:14 +0200 From: Emmanuel Vadot To: Chris Cc: Marek Zarychta , freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220622044714.c1cf644ae8f34d6ea4b863cb@bidouilliste.com> In-Reply-To: <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LSSTb3rK2z4l6y X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=HTb6ysGX; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-2.24 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.77)[-0.771]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 21 Jun 2022 13:51:17 -0700 Chris wrote: > On 2022-06-21 11:36, Marek Zarychta wrote: > > W dniu 21.06.2022 o=A020:19, Emmanuel Vadot pisze: > >> Hello, > >>=20 > >> On Fri, 26 Nov 2021 16:04:54 +0100 > >> Emmanuel Vadot wrote: > >>=20 > >>> Hello all, > >>>=20 > >>> I'm currently re-implementing the framebuffer code in linuxkpi for > >>> drm-kmod and this made me look at sc(4), vt(4) and friends. > >>>=20 > >>> So I looked at what sc could do and vt couldn't and vice-versa. > >>>=20 > >>> What sc(4) can't do : > >>>=20 > >>> - Work with EFI firmware. > >>> - Support UTF-8 > >>> - Maybe other things but everything here is EFI-based so let me kno= w. > >>>=20 > >>> What vt(4) can't do : > >>>=20 > >>> - You can't get the modes or adapter info with vidcontrol. > >>> vidcontrol -i mode is really made for anything vesa based as it > >>> iterates on all the modes and display them if present. > >>> In the modern world (EFI), we don't have that, EFI GOP doesn't > >>> support changing resolution after ExitBootService was called so there > >>> is only one "mode". I could possibly hack some patch so vidcontrol -i > >>> mode/adapter would work and display the current framebuffer info if > >>> people wants (but I honestly doubt that vidcontrol is useful at all in > >>> an EFI world). > >>> - "Blanking" screen doesn't do what you think it does. For some rea= son > >>> in vt(4) we just write black colors on the screen and ignore the blank > >>> mode passed in the ioctl. > >>> Now again, blanking/dpms/blah isn't possible with efi_fb but it m= ake > >>> sense to fix vt(4) and drm-kmod so it calls the drm module blanking > >>> function, I'll work on that next week. > >>> - There is no screensaver, again see notes above for dpms but do > >>> people still use sc(4) just for the screensaver ?? > >>> - Maybe other things, please let me know. > >>>=20 > >>> For libvgl it probably made sense back in the 90s but does it now ?? > >>>=20 > >>> Based on my small list I don't see any good reason to keep sc(4) but > >>> maybe I've missed something bigger so please let me know. > >>>=20 > >>> P.S.: I'm really not interested by people saying stuff like > >>> "I've always used sc(4), it works for me don't touch it" > >>> without some technical argument. > >>>=20 > >>> Cheers, > >>>=20 > >>> -- Emmanuel Vadot > >>>=20 > >> I've put up in phab removing sc(4) from GENERIC and MINIMAL : > >>=20 > >> https://reviews.freebsd.org/D35538 > >> https://reviews.freebsd.org/D35539 > >>=20 > >> If you have any good reason that sc(4) should be included in those > >> kernel config for amd64 (no other arches was touched) please provide > >> some argument on the reviews. > >>=20 > >> Cheers, > >>=20 > > Thanks for heads up. Unfortunately, it will be a great loss. The waste = of=20 > > power > > resources might increase since vt(4) still doesn't support VESA Display= =20 > > Power > > Management Signaling which some of the servers are heavily relying on. = It's=20 > > a step > > backward in terms of green computing and amidst the power crisis, we ar= e=20 > > heading > > in Europe. > My only objection is that I can NOT get textmode or very stable X on any = of=20 > the NVIDIA > cards I use unless I build against sc. Does sc(4) use so much space that= =20 > current kernels > become too big with it's presence? I vote against it's removal. >=20 > Chris I'm sure that other people uses nvidia cards with vt(4), did you opened a PR about this ? --=20 Emmanuel Vadot From nobody Wed Jun 22 02:49:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E580786E9E7 for ; Wed, 22 Jun 2022 02:49:25 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSSX45kLMz4mKT; Wed, 22 Jun 2022 02:49:24 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655866163; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tx8cJCdDWRUBn/JNYturoX33/i0TvRqrMKoDJ2GERhc=; b=lNM1WAwG5R6c2kicgstqGc60fzuyRNKzjlra2iGrmxCzTjzOxw7mwx3/6JY5CnoG4IHl9J hcd/ITZAUwkAlkSQLSBLJdS1q7gTM5ij6f0OR17LOET4WiHu3F5NWd9GL8BkmjMK3wzF4H TrX+szwfZAIGBAPBj88QkMP+eaOMV2A= Received: from amy (lfbn-idf2-1-1159-38.w90-92.abo.wanadoo.fr [90.92.219.38]) by mx.blih.net (OpenSMTPD) with ESMTPSA id bbd780d0 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 22 Jun 2022 02:49:23 +0000 (UTC) Date: Wed, 22 Jun 2022 04:49:23 +0200 From: Emmanuel Vadot To: Ed Maste Cc: Poul-Henning Kamp , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LSSX45kLMz4mKT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=lNM1WAwG; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.29 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32:c]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-0.24)[-0.237]; NEURAL_HAM_MEDIUM(-0.55)[-0.552]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 21 Jun 2022 21:23:42 -0400 Ed Maste wrote: > On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp wrote: > > > > But the operative word there is "still", isn't it ? > > > > There is nothing which prevents vt(4) from doing the right thing is there ? > > Just a simple matter of programming. We should indeed add dpms support to vt. > I don't think so. 1/ It's useless when you boot with uefi which 100% of the machines produced in the last 5 (10?) years do 2/ If you really want to save power, use drm with the appropriate driver. Even without runtime power management just loading the driver will reduce power consumption on most machines. -- Emmanuel Vadot From nobody Wed Jun 22 03:45:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 25DA08765B9 for ; Wed, 22 Jun 2022 03:46:06 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSTnT2cHdz4t8t; Wed, 22 Jun 2022 03:46:05 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id h23so31408255ejj.12; Tue, 21 Jun 2022 20:46:05 -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=WGO9LJ7euslT6gXYM+/01cRfRTG5KF5vMTo5T7jOH/o=; b=LXR+Eug0mpG0NdAol4ZGf45vZPAfMY9v+90vX6/LJUPiO76Yi0ZmF4Z3yL6WmFzI/x qrTzZCTqs8WF0xjtanWvJcAHxPC8xsM180yoF2ortpWHHzeZBTEEh/oBcRB1VbGVpibS sEIq7zBhqrFDqT7FEsJe7EO4wys5bwdO3LBpWos7dmKGmn+m6pCOZV2Blm2v+0lZHj6i XarbjAihPMIbr7Qh7eZQzsEA932+IqMGI1lmjEnjKgg1a422rdfblUgKPbrQ0AFElR4+ JomWlrKaH3JSRiDes6j/frq0Q4CCq9p41DgpdFMGpkTxJFzS15/+FuIH5FBnYyz6G6S2 z0oA== 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=WGO9LJ7euslT6gXYM+/01cRfRTG5KF5vMTo5T7jOH/o=; b=C0DQvT8ozPljP07BufJE129S81DD9wWKqJRaLiitRUZ6VKvg8OJYPyEWvLx0NolHfj bI3P5GR5UHm8M4OIcsvgLEStdQZptXQOJ9Gf/JDlQj3IxOzrGGlBMSiLkMKhSubSOXxt DF26buFBiT8hNhoJHu/kmk44DIPkw7uCFGqLl/Uun6zRoC3gcXn3xpzED7abZD2mSWix xS6/AUfiqlIoYTydZsk+nlq4hyH4GSEVKukL0f5ILnNFoMkJoHcRwlWNPUhpR2+0TYDR i4e7kuy2OFrz+g0gxmKHVZw736bE6BPl5HttrDHDXXHEVofpJgi8oaQ3rQVKZ7iWbJtM z32Q== X-Gm-Message-State: AJIora/9RMnpl6ycVlMfBaH6q4Io9kC4+9Lg/pAfUoVRwWa109kbWtU+ +z02kxc+In80tER/5wzB/35NqSUgUNirRDpFnXc= X-Google-Smtp-Source: AGRyM1uQXiH8SXwy52sShLZd0RnpLMd/joayqR/958y9e/3TfyKf142DuA4XRJJDE0SQ+i4W7V4vyI0SgUGebWPYFWg= X-Received: by 2002:a17:906:f51:b0:6fe:cf1c:cdbf with SMTP id h17-20020a1709060f5100b006fecf1ccdbfmr1142130ejj.695.1655869563339; Tue, 21 Jun 2022 20:46:03 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> In-Reply-To: <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> From: Stefan Blachmann Date: Wed, 22 Jun 2022 05:45:33 +0200 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Emmanuel Vadot Cc: Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000001e06cb05e2012dd5" X-Rspamd-Queue-Id: 4LSTnT2cHdz4t8t X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=LXR+Eug0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sblachmann@gmail.com designates 2a00:1450:4864:20::62f as permitted sender) smtp.mailfrom=sblachmann@gmail.com X-Spamd-Result: default: False [-1.05 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.91)[0.913]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; NEURAL_HAM_SHORT(-0.97)[-0.965]; 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)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000001e06cb05e2012dd5 Content-Type: text/plain; charset="UTF-8" I would kindly ask to stop pushing for removal of sc. At least these long-running vt issues should be solved before removal of sc should be considered at all: 1. Currently vt BREAKS suspend/resume on nvidia and many other video cards, which just work fine with sc 2. vt does not support DPMS 3. plenty other lesser bugs Both things are valid reasons why many people - including me - reject using vt on nvidia cards, because using it would factually downgrade the computers' capabilities and energy efficiency. On Wed, Jun 22, 2022 at 4:50 AM Emmanuel Vadot wrote: > On Tue, 21 Jun 2022 21:23:42 -0400 > Ed Maste wrote: > > > On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp > wrote: > > > > > > But the operative word there is "still", isn't it ? > > > > > > There is nothing which prevents vt(4) from doing the right thing is > there ? > > > > Just a simple matter of programming. We should indeed add dpms support > to vt. > > > > I don't think so. > 1/ It's useless when you boot with uefi which 100% of the machines > produced in the last 5 (10?) years do > 2/ If you really want to save power, use drm with the appropriate > driver. Even without runtime power management just loading the driver > will reduce power consumption on most machines. > > -- > Emmanuel Vadot > > --0000000000001e06cb05e2012dd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would kindly ask to stop pushing for removal of sc.=
At least these long-running vt issues should be solved before re= moval of sc should be considered at all:
1. Currently vt BREA= KS suspend/resume on nvidia and many other video cards, which just work fin= e with sc
2. vt does not support DPMS
3. plenty oth= er lesser bugs
Both things are valid reasons why many people = - including me - reject using vt on nvidia cards, because using it would fa= ctually downgrade the computers' capabilities and energy efficiency.

On Wed, Jun 22, 2022 at 4:50 AM Emmanuel Vadot <manu@bidouilliste.com> wrote:
On Tue, 21 Jun 2022 21:23:42 -= 0400
Ed Maste <emaste= @freebsd.org> wrote:

> On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> >
> > But the operative word there is "still", isn't it ?=
> >
> > There is nothing which prevents vt(4) from doing the right thing = is there ?
>
> Just a simple matter of programming. We should indeed add dpms support= to vt.
>

=C2=A0I don't think so.
=C2=A01/ It's useless when you boot with uefi which 100% of the machine= s
produced in the last 5 (10?) years do
=C2=A02/ If you really want to save power, use drm with the appropriate
driver. Even without runtime power management just loading the driver
will reduce power consumption on most machines.

--
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>

--0000000000001e06cb05e2012dd5-- From nobody Wed Jun 22 04:05:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3338D8599A2 for ; Wed, 22 Jun 2022 04:06:08 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "plan-b.pwste.edu.pl", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSVDb0wJxz3CMb for ; Wed, 22 Jun 2022 04:06:06 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from [IPV6:2a02:22e0:cf00:1ff:cb2:f3ef:cfba:7034] (mzar@[IPv6:2a02:22e0:cf00:1ff:cb2:f3ef:cfba:7034]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.17.1/8.17.1) with ESMTPSA id 25M45qEJ044615 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 22 Jun 2022 06:05:54 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1655870754; bh=2vJyG/2DTxtq9pAl793/KJQSa/t6Pgb1LF6I4lzHAcI=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=RHXE/cRWHGOmTE0DXpsvMz5+S8gmoGlsbyeBGcRK7hHbfrjVFSCwx+fzW0YHrZm1+ 3fVB03TFIVCY0e7CGOUgTkcIuZ7vLKwvD6nCacp3paifbqb3m2P8IaT+UQ77APBCIU jwQdgceli+BPlko20jEN1eugGo7YSTwQs+vn7GDA4H6c+XWn3KgqPc0acyus2ZDl/3 W0o17XWq1ITVfwjTj7d/jPIpJdMsTuKxvqe9w5HTcirfRzfraiMwrwi2x08/A9fJ5V ujVMOZf+qiL/3fTxTZY7YMVjj8g6qXl3dgaDun1qqfOb7DfoRF7ep4txlFlXGaifiB dkCqnNOUK7hpw== Message-ID: <1794df26-1cc4-f6f9-0a41-6c86b4202ae1@plan-b.pwste.edu.pl> Date: Wed, 22 Jun 2022 06:05:50 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: Reasons for keeping sc(4) and libvgl ? Content-Language: en-US To: Tomoaki AOKI Cc: Emmanuel Vadot , freebsd-hackers@freebsd.org References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <20220622063428.65f922414aa8a778c0feb38d@dec.sakura.ne.jp> From: Marek Zarychta In-Reply-To: <20220622063428.65f922414aa8a778c0feb38d@dec.sakura.ne.jp> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------q15KEoYyrBl8ZQsJl5OSkkUI" X-Rspamd-Queue-Id: 4LSVDb0wJxz3CMb X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b="RHXE/cRW"; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-1.01 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; R_SPF_NA(0.00)[no SPF record]; NEURAL_SPAM_MEDIUM(0.79)[0.785]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; MLMMJ_DEST(0.00)[freebsd-hackers]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------q15KEoYyrBl8ZQsJl5OSkkUI Content-Type: multipart/mixed; boundary="------------t4Au7uAs2hPn3NozWJGJYRl6"; protected-headers="v1" From: Marek Zarychta To: Tomoaki AOKI Cc: Emmanuel Vadot , freebsd-hackers@freebsd.org Message-ID: <1794df26-1cc4-f6f9-0a41-6c86b4202ae1@plan-b.pwste.edu.pl> Subject: Re: Reasons for keeping sc(4) and libvgl ? References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <20220622063428.65f922414aa8a778c0feb38d@dec.sakura.ne.jp> In-Reply-To: <20220622063428.65f922414aa8a778c0feb38d@dec.sakura.ne.jp> --------------t4Au7uAs2hPn3NozWJGJYRl6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VyBkbml1IDIxLjA2LjIwMjIgb8KgMjM6MzQsIFRvbW9ha2kgQU9LSSBwaXN6ZToNCj4gT24g VHVlLCAyMSBKdW4gMjAyMiAyMDozNjoyNSArMDIwMA0KPiBNYXJlayBaYXJ5Y2h0YSA8emFy eWNodGFtQHBsYW4tYi5wd3N0ZS5lZHUucGw+IHdyb3RlOg0KPiANCj4+IFcgZG5pdSAyMS4w Ni4yMDIyIG/jgJMyMDoxOSwgRW1tYW51ZWwgVmFkb3QgcGlzemU6DQo+Pj4gICAgSGVsbG8s DQo+Pj4NCj4+PiBPbiBGcmksIDI2IE5vdiAyMDIxIDE2OjA0OjU0ICswMTAwDQo+Pj4gRW1t YW51ZWwgVmFkb3QgPG1hbnVAYmlkb3VpbGxpc3RlLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4g ICAgSGVsbG8gYWxsLA0KPj4+Pg0KPj4+PiAgICBJJ20gY3VycmVudGx5IHJlLWltcGxlbWVu dGluZyB0aGUgZnJhbWVidWZmZXIgY29kZSBpbiBsaW51eGtwaSBmb3INCj4+Pj4gZHJtLWtt b2QgYW5kIHRoaXMgbWFkZSBtZSBsb29rIGF0IHNjKDQpLCB2dCg0KSBhbmQgZnJpZW5kcy4N Cj4+Pj4NCj4+Pj4gICAgU28gSSBsb29rZWQgYXQgd2hhdCBzYyBjb3VsZCBkbyBhbmQgdnQg Y291bGRuJ3QgYW5kIHZpY2UtdmVyc2EuDQo+Pj4+DQo+Pj4+ICAgIFdoYXQgc2MoNCkgY2Fu J3QgZG8gOg0KPj4+Pg0KPj4+PiAgICAtIFdvcmsgd2l0aCBFRkkgZmlybXdhcmUuDQo+Pj4+ ICAgIC0gU3VwcG9ydCBVVEYtOA0KPj4+PiAgICAtIE1heWJlIG90aGVyIHRoaW5ncyBidXQg ZXZlcnl0aGluZyBoZXJlIGlzIEVGSS1iYXNlZCBzbyBsZXQgbWUga25vdy4NCj4+Pj4NCj4+ Pj4gICAgV2hhdCB2dCg0KSBjYW4ndCBkbyA6DQo+Pj4+DQo+Pj4+ICAgIC0gWW91IGNhbid0 IGdldCB0aGUgbW9kZXMgb3IgYWRhcHRlciBpbmZvIHdpdGggdmlkY29udHJvbC4NCj4+Pj4g ICAgICB2aWRjb250cm9sIC1pIG1vZGUgaXMgcmVhbGx5IG1hZGUgZm9yIGFueXRoaW5nIHZl c2EgYmFzZWQgYXMgaXQNCj4+Pj4gaXRlcmF0ZXMgb24gYWxsIHRoZSBtb2RlcyBhbmQgZGlz cGxheSB0aGVtIGlmIHByZXNlbnQuDQo+Pj4+ICAgICAgSW4gdGhlIG1vZGVybiB3b3JsZCAo RUZJKSwgd2UgZG9uJ3QgaGF2ZSB0aGF0LCBFRkkgR09QIGRvZXNuJ3QNCj4+Pj4gc3VwcG9y dCBjaGFuZ2luZyByZXNvbHV0aW9uIGFmdGVyIEV4aXRCb290U2VydmljZSB3YXMgY2FsbGVk IHNvIHRoZXJlDQo+Pj4+IGlzIG9ubHkgb25lICJtb2RlIi4gSSBjb3VsZCBwb3NzaWJseSBo YWNrIHNvbWUgcGF0Y2ggc28gdmlkY29udHJvbCAtaQ0KPj4+PiBtb2RlL2FkYXB0ZXIgd291 bGQgd29yayBhbmQgZGlzcGxheSB0aGUgY3VycmVudCBmcmFtZWJ1ZmZlciBpbmZvIGlmDQo+ Pj4+IHBlb3BsZSB3YW50cyAoYnV0IEkgaG9uZXN0bHkgZG91YnQgdGhhdCB2aWRjb250cm9s IGlzIHVzZWZ1bCBhdCBhbGwgaW4NCj4+Pj4gYW4gRUZJIHdvcmxkKS4NCj4+Pj4gICAgLSAi QmxhbmtpbmciIHNjcmVlbiBkb2Vzbid0IGRvIHdoYXQgeW91IHRoaW5rIGl0IGRvZXMuIEZv ciBzb21lIHJlYXNvbg0KPj4+PiBpbiB2dCg0KSB3ZSBqdXN0IHdyaXRlIGJsYWNrIGNvbG9y cyBvbiB0aGUgc2NyZWVuIGFuZCBpZ25vcmUgdGhlIGJsYW5rDQo+Pj4+IG1vZGUgcGFzc2Vk IGluIHRoZSBpb2N0bC4NCj4+Pj4gICAgICBOb3cgYWdhaW4sIGJsYW5raW5nL2RwbXMvYmxh aCBpc24ndCBwb3NzaWJsZSB3aXRoIGVmaV9mYiBidXQgaXQgbWFrZQ0KPj4+PiBzZW5zZSB0 byBmaXggdnQoNCkgYW5kIGRybS1rbW9kIHNvIGl0IGNhbGxzIHRoZSBkcm0gbW9kdWxlIGJs YW5raW5nDQo+Pj4+IGZ1bmN0aW9uLCBJJ2xsIHdvcmsgb24gdGhhdCBuZXh0IHdlZWsuDQo+ Pj4+ICAgICAtIFRoZXJlIGlzIG5vIHNjcmVlbnNhdmVyLCBhZ2FpbiBzZWUgbm90ZXMgYWJv dmUgZm9yIGRwbXMgYnV0IGRvDQo+Pj4+IHBlb3BsZSBzdGlsbCB1c2Ugc2MoNCkganVzdCBm b3IgdGhlIHNjcmVlbnNhdmVyID8/DQo+Pj4+ICAgICAtIE1heWJlIG90aGVyIHRoaW5ncywg cGxlYXNlIGxldCBtZSBrbm93Lg0KPj4+Pg0KPj4+PiAgICBGb3IgbGlidmdsIGl0IHByb2Jh Ymx5IG1hZGUgc2Vuc2UgYmFjayBpbiB0aGUgOTBzIGJ1dCBkb2VzIGl0IG5vdyA/Pw0KPj4+ Pg0KPj4+PiAgICBCYXNlZCBvbiBteSBzbWFsbCBsaXN0IEkgZG9uJ3Qgc2VlIGFueSBnb29k IHJlYXNvbiB0byBrZWVwIHNjKDQpIGJ1dA0KPj4+PiBtYXliZSBJJ3ZlIG1pc3NlZCBzb21l dGhpbmcgYmlnZ2VyIHNvIHBsZWFzZSBsZXQgbWUga25vdy4NCj4+Pj4NCj4+Pj4gICAgUC5T LjogSSdtIHJlYWxseSBub3QgaW50ZXJlc3RlZCBieSBwZW9wbGUgc2F5aW5nIHN0dWZmIGxp a2UNCj4+Pj4gICAgIkkndmUgYWx3YXlzIHVzZWQgc2MoNCksIGl0IHdvcmtzIGZvciBtZSBk b24ndCB0b3VjaCBpdCINCj4+Pj4gICAgd2l0aG91dCBzb21lIHRlY2huaWNhbCBhcmd1bWVu dC4NCj4+Pj4NCj4+Pj4gICAgQ2hlZXJzLA0KPj4+Pg0KPj4+PiAtLSANCj4+Pj4gRW1tYW51 ZWwgVmFkb3QgPG1hbnVAYmlkb3VpbGxpc3RlLmNvbT4gPG1hbnVAZnJlZWJzZC5vcmc+DQo+ Pj4+DQo+Pj4gICAgSSd2ZSBwdXQgdXAgaW4gcGhhYiByZW1vdmluZyBzYyg0KSBmcm9tIEdF TkVSSUMgYW5kIE1JTklNQUwgOg0KPj4+DQo+Pj4gICAgaHR0cHM6Ly9yZXZpZXdzLmZyZWVi c2Qub3JnL0QzNTUzOA0KPj4+ICAgIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9yZy9EMzU1 MzkNCj4+Pg0KPj4+ICAgIElmIHlvdSBoYXZlIGFueSBnb29kIHJlYXNvbiB0aGF0IHNjKDQp IHNob3VsZCBiZSBpbmNsdWRlZCBpbiB0aG9zZQ0KPj4+IGtlcm5lbCBjb25maWcgZm9yIGFt ZDY0IChubyBvdGhlciBhcmNoZXMgd2FzIHRvdWNoZWQpIHBsZWFzZSBwcm92aWRlDQo+Pj4g c29tZSBhcmd1bWVudCBvbiB0aGUgcmV2aWV3cy4NCj4+Pg0KPj4+ICAgIENoZWVycywNCj4+ Pg0KPj4gVGhhbmtzIGZvciBoZWFkcyB1cC4gVW5mb3J0dW5hdGVseSwgaXQgd2lsbCBiZSBh IGdyZWF0IGxvc3MuIFRoZSB3YXN0ZQ0KPj4gb2YgcG93ZXIgcmVzb3VyY2VzIG1pZ2h0IGlu Y3JlYXNlIHNpbmNlIHZ0KDQpIHN0aWxsIGRvZXNuJ3Qgc3VwcG9ydCBWRVNBDQo+PiBEaXNw bGF5IFBvd2VyIE1hbmFnZW1lbnQgU2lnbmFsaW5nIHdoaWNoIHNvbWUgb2YgdGhlIHNlcnZl cnMgYXJlIGhlYXZpbHkNCj4+IHJlbHlpbmcgb24uIEl0J3MgYSBzdGVwIGJhY2t3YXJkIGlu IHRlcm1zIG9mIGdyZWVuIGNvbXB1dGluZyBhbmQgYW1pZHN0DQo+PiB0aGUgcG93ZXIgY3Jp c2lzLCB3ZSBhcmUgaGVhZGluZyBpbiBFdXJvcGUuDQo+Pg0KPj4gLS0gDQo+PiBNYXJlayBa YXJ5Y2h0YQ0KPiANCj4gQW5kIElJVUMsIHNjIGRvZXNuJ3QgYnVpbHQgYXMgbW9kdWxlIGF0 IGxlYXN0IGJ5IGRlZmF1bHQuDQo+IA0KPiBJZiBzb21ldGhpbmcgbGlrZSBzYy5rbyAoaW5j b3Jwb3JhdGluZyBsaWJ2Z2w/KSBpcyBidWlsdCBhcyBtb2R1bGUgQlkNCj4gREVGQVVMVCBh bmQgc2FuZWx5IGxvYWRhYmxlIHZpYSAvYm9vdC9sb2Rlci5jb25mIChob3BlZnVsbHkga2xk bG9hZCdhYmxlDQo+IGFuZCBzdXBlcmNlZGVzIHZ0IGluIHN1Y2ggY2FzZXMpIGFuZCBydW5z IE9LLCBJIGhhdmUgbm8gb2JqZWN0aW9uLg0KPiBVc2VycyB3aG8gbmVlZCBzYyBsaWtlIE1h cmVrIGNhbiBsb2FkIGl0IGluIHN1Y2ggc2l0dWF0aW9uLg0KPiANCj4gTWF5YmUsIHRvIGRv IHNvLCB2dCB3b3VsZCBiZSBiZXR0ZXIgYnVpbGRhYmxlIC8gbG9hZGFibGUgYXMNCj4gbW9k dWxlLCB0b28uIChXb3VsZCBub3QgYmUgbWFuZGF0b3J5LCBhcyBrZXJuLnZ0eT1zYw0KPiBp biAvYm9vdC9sb2FkZXIuY29uZiB3b3VsZCBkaXNhYmxlIHZ0LiBQcmVmZXJyYWJseSwga2Vy bi52dHk9W3NjfHZ0XQ0KPiBpbnZva2VzIGF1dG8tbG9hZGluZyBvZiAobm93IG5vbmV4aXN0 ZW50KSBjb3JyZXNwb25kaW5nIC5rbyBpZiBub3QNCj4gbG9hZGVkIG5vciBidWlsdCBpbiBr ZXJuZWwuDQo+IA0KPiBPbmUgdGhpbmcgdG8gYWRkLg0KPiB2dCBkb2Vzbid0IHN1cHBvcnQg Y29uc29sZSBzY3JlZW4gc2F2ZXJzIHlldC4NCj4gDQoNCkdvb2QgcG9pbnQuIEtlcm5lbCBs b2FkYWJsZSBtb2R1bGUgb2Ygc2MoNCkgd291bGQgYmUgcHJvYmFibHkgdGhlIGJlc3QgDQp0 ZW1wb3Jhcnkgc29sdXRpb24sIGF0IGxlYXN0IHVudGlsIHZ0KDQpIGdhaW5zIERNUFMgc3Vw cG9ydCBhbmQgY29uZmxpY3QgDQp3aXRoIE52aWRpYSBkcml2ZXJzIGdldHMgcmVzb2x2ZWQu DQoNCi0tIA0KTWFyZWsgWmFyeWNodGENCg== --------------t4Au7uAs2hPn3NozWJGJYRl6-- --------------q15KEoYyrBl8ZQsJl5OSkkUI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEnjwyTmqn2oNX6C8qHZW8vIFppoIFAmKylR4FAwAAAAAACgkQHZW8vIFppoJY pwgAxUqQEtCFEGjpsbLx252Yomt0Jy7tM+4NzdpjRep5lY5q6WM4AdsV051JYXRQ3gBmr/KMef8h teA4ttk52gFq2XKya73HldlEMGXuccRWq4NyP/2NUF5oyKsPI5TrW7tl0FKBECsbmj3NRPwV0gTT tjlIy6e55aONvY8xKvrPBoBIO1poOLnxHwWTgEHyVwagEhR+XURT6NLQuHUbYqcuaa8EC4Fst60r 6+Js9FKKrHz1JEjAKyJO6K3bS8T1sEyVSh76vRkAodTCF/QUVjH3GMuULbT2x/AlrAaQNFYenPPl N/Q8Eys6X1hdeYQ5lhYlh+fc7zs4jkASFvsYuQAS4w== =WljC -----END PGP SIGNATURE----- --------------q15KEoYyrBl8ZQsJl5OSkkUI-- From nobody Wed Jun 22 04:36:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F2A9085E584 for ; Wed, 22 Jun 2022 04:36:52 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSVw40BBQz3GXs; Wed, 22 Jun 2022 04:36:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1655872609; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Min1H7mKfm/k/m2o8JkNoJmIRyo43ZBK2vnvtdAgqY=; b=dUsemaHXVrphFnswU3CzZb+GXqhcm6JDgawjUGWCwDvoTwq1EhsbsjNd35Ljqy7aS0TZDn 97sDElg4yr7YtfVaix16lm8eQMKQ/pfEUFoN5NVQzBrccSY9pAU6lCnJGcF9LCw4zMpRHX o2w/VMniWNDLScuHC+F7hHvSSmx+8nQ= Received: from amy (lfbn-idf2-1-1159-38.w90-92.abo.wanadoo.fr [90.92.219.38]) by mx.blih.net (OpenSMTPD) with ESMTPSA id aaebeba5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 22 Jun 2022 04:36:49 +0000 (UTC) Date: Wed, 22 Jun 2022 06:36:49 +0200 From: Emmanuel Vadot To: Stefan Blachmann Cc: Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220622063649.9954cfc96102bbcd0e8201f4@bidouilliste.com> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LSVw40BBQz3GXs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=dUsemaHX; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; FREEFALL_USER(0.00)[manu]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:212.83.155.74/32]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(0.02)[0.023]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, 22 Jun 2022 05:45:33 +0200 Stefan Blachmann wrote: > I would kindly ask to stop pushing for removal of sc. > At least these long-running vt issues should be solved before removal of sc > should be considered at all: > 1. Currently vt BREAKS suspend/resume on nvidia and many other video cards, > which just work fine with sc I have no idea about nvidia as I don't have this hardware but what other video cards are you talking about ? I have no problems with amdgpu and i915kms here on multiple machines. > 2. vt does not support DPMS See my other mail for this reason. > 3. plenty other lesser bugs Which ones ? > Both things are valid reasons why many people - including me - reject using > vt on nvidia cards, because using it would factually downgrade the > computers' capabilities and energy efficiency. > > On Wed, Jun 22, 2022 at 4:50 AM Emmanuel Vadot > wrote: > > > On Tue, 21 Jun 2022 21:23:42 -0400 > > Ed Maste wrote: > > > > > On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp > > wrote: > > > > > > > > But the operative word there is "still", isn't it ? > > > > > > > > There is nothing which prevents vt(4) from doing the right thing is > > there ? > > > > > > Just a simple matter of programming. We should indeed add dpms support > > to vt. > > > > > > > I don't think so. > > 1/ It's useless when you boot with uefi which 100% of the machines > > produced in the last 5 (10?) years do > > 2/ If you really want to save power, use drm with the appropriate > > driver. Even without runtime power management just loading the driver > > will reduce power consumption on most machines. > > > > -- > > Emmanuel Vadot > > > > -- Emmanuel Vadot From nobody Wed Jun 22 04:55:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76D4C860C5B for ; Wed, 22 Jun 2022 04:55:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSWKF2XJQz3J8v for ; Wed, 22 Jun 2022 04:55:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id t127so332437vsb.8 for ; Tue, 21 Jun 2022 21:55:13 -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=/AbK7Hw3sNMxH0vblxrmL5xHK5XdEVJoAoaa8M8NNO8=; b=C7czEUqIeimcX+mconZUOKppk05qpYqqe6t1W1dDymMDuVnKcmjJJPRV+wEFjHDcgl dZUzm3kxibY2J3dXW4Cl0X/6UzGgS2fQDd5RX77Vl+vQ/F+VzK44uzbDGYnyHyiCj75A 6PBXqhKWl31MqafkQ8FtsUZRf6o1H6KBX29SJXqXxqeddZFYI5/IgD851It8DIIkvmrW IGqSeH0woac33NEpab5YjKiM2UMxBYunwRNoPFbTrxjNnQAmStZhM8V2V0wM/UFgsfHx c5nNUHKNQSpdWqUfcqYBw8Ul/icQ1vyGCYYWaBMmHcOqhf5xhGdO5drS/hWNaNVF1VxA B9lA== 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=/AbK7Hw3sNMxH0vblxrmL5xHK5XdEVJoAoaa8M8NNO8=; b=ULTVk0g9ggl69tWPtUmgfh5JzIImMXNMq1pyJ4ucZP1iBRji9MfqgG++KBru9B+827 0MPEoQK1cOlsz47xUsCWaO/jJwxYttWCi6gDsVTzuxPtvkpTMEeaQFRB6WB6jiec7rzv knBuEa4/xR2cD2QofY9iTCb3lQLINpzustsK01R0YnmsAW9EbzQBgD7kPl6I8ZIDj2vJ dSTefn7tGvQ6MX5QDJoT6AMvvrAtlVmgrmHGyQIGGOKv6WDAFDOkOSSTGbtWHV6cUsAz CaQNXi3D7qsNgYVn50y5JHVeHWDcPj+wVIZ9EcuUEqvBxYL2BJLkXf3nAhda65cYYZHx Jp7Q== X-Gm-Message-State: AJIora+wP3KRcJDeUphpgLWNjFFe52Gp2jyNmvGmvoOaI+m+EEnwyJHY qylelt+8+pTljR94b6JkNXicW/Jva9k6URx1g/DVrQ== X-Google-Smtp-Source: AGRyM1ug5320S1kwsx3KE6/khnhkGduitZsu7csfAHfHzBWy0NMkT8ykX6KuqZ44l3McddIOBx6fMSHbTAI7EIx38X0= X-Received: by 2002:a67:cd90:0:b0:354:5028:f253 with SMTP id r16-20020a67cd90000000b003545028f253mr2793577vsl.6.1655873712805; Tue, 21 Jun 2022 21:55:12 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Tue, 21 Jun 2022 22:55:01 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Stefan Blachmann Cc: Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000071ecd805e202242c" X-Rspamd-Queue-Id: 4LSWKF2XJQz3J8v X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=C7czEUqI; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.31 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.31)[-0.308]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@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::e2a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000071ecd805e202242c Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann wrote: > I would kindly ask to stop pushing for removal of sc. > It will die soon enough if it doesn't become giant locked soon... Warner At least these long-running vt issues should be solved before removal of sc > should be considered at all: > 1. Currently vt BREAKS suspend/resume on nvidia and many other video > cards, which just work fine with sc > 2. vt does not support DPMS > 3. plenty other lesser bugs > Both things are valid reasons why many people - including me - reject > using vt on nvidia cards, because using it would factually downgrade the > computers' capabilities and energy efficiency. > > On Wed, Jun 22, 2022 at 4:50 AM Emmanuel Vadot > wrote: > >> On Tue, 21 Jun 2022 21:23:42 -0400 >> Ed Maste wrote: >> >> > On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp >> wrote: >> > > >> > > But the operative word there is "still", isn't it ? >> > > >> > > There is nothing which prevents vt(4) from doing the right thing is >> there ? >> > >> > Just a simple matter of programming. We should indeed add dpms support >> to vt. >> > >> >> I don't think so. >> 1/ It's useless when you boot with uefi which 100% of the machines >> produced in the last 5 (10?) years do >> 2/ If you really want to save power, use drm with the appropriate >> driver. Even without runtime power management just loading the driver >> will reduce power consumption on most machines. >> >> -- >> Emmanuel Vadot >> >> --00000000000071ecd805e202242c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann <sblachmann@gmail.com> wrote:
I would kindly = ask to stop pushing for removal of sc.
=

It will die soon enough if it= doesn't become giant locked soon...

<= div dir=3D"auto">Warner=C2=A0

At least these long-running vt issues should be solved before re= moval of sc should be considered at all:
1. Currently vt BREA= KS suspend/resume on nvidia and many other video cards, which just work fin= e with sc
2. vt does not support DPMS
3. plenty oth= er lesser bugs
Both things are valid reasons why many people = - including me - reject using vt on nvidia cards, because using it would fa= ctually downgrade the computers' capabilities and energy efficiency.

On Wed, Jun 22, 2022 at 4:50 AM Emmanuel Vadot <manu@bidouilli= ste.com> wrote:
On Tue, 21 Jun 2022 21:23:42 -0400
Ed Maste <emaste@freebsd.org> wrote:

> On Tue, 21 Jun 2022 at 15:02, Poul-Henning Kamp <phk@phk.freebsd.dk= > wrote:
> >
> > But the operative word there is "still", isn't it ?=
> >
> > There is nothing which prevents vt(4) from doing the right thing = is there ?
>
> Just a simple matter of programming. We should indeed add dpms support= to vt.
>

=C2=A0I don't think so.
=C2=A01/ It's useless when you boot with uefi which 100% of the machine= s
produced in the last 5 (10?) years do
=C2=A02/ If you really want to save power, use drm with the appropriate
driver. Even without runtime power management just loading the driver
will reduce power consumption on most machines.

--
Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>= ;

--00000000000071ecd805e202242c-- From nobody Wed Jun 22 04:59:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6B213861B59 for ; Wed, 22 Jun 2022 04:59:20 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSWPy5xW2z3KMt; Wed, 22 Jun 2022 04:59:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 25M4x1JR043860 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 21 Jun 2022 21:59:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 25M4x1bL043859; Tue, 21 Jun 2022 21:59:01 -0700 (PDT) (envelope-from sgk) Date: Tue, 21 Jun 2022 21:59:01 -0700 From: Steve Kargl To: Warner Losh Cc: Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LSWPy5xW2z3KMt X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [1.09 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.02)[0.024]; NEURAL_HAM_LONG(-0.94)[-0.937]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[6]; SUBJECT_ENDS_QUESTION(1.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; FREEMAIL_CC(0.00)[gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Losh wrote: > On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann wrote: > > > I would kindly ask to stop pushing for removal of sc. > > > > It will die soon enough if it doesn't become giant locked soon... > > Warner > Are you deleting vt, too? % grep -i giant /var/run/dmesg.boot atkbd0: [GIANT-LOCKED] WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. lock order reversal: (Giant after non-sleepable) 2nd 0xffffffff80c02840 Giant (Giant, sleep mutex) @ /usr/src/sys/kern/kern_synch.c:232 lock order Giant -> vtdev established at: lock order vtdev -> Giant attempted at: -- Steve From nobody Wed Jun 22 05:34:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A321C8668EF for ; Wed, 22 Jun 2022 05:34:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSXBd5ggsz3PCs for ; Wed, 22 Jun 2022 05:34:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa30.google.com with SMTP id h26so716457vkc.2 for ; Tue, 21 Jun 2022 22:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZghGAV70MAETfA8ua9pAPGOeyTQ3ZlN4VRymh82VSEw=; b=hRHZIkx8IHqUYXnQR5EfXU8FnNLLDP4ucuSmjnWE+PqXXPci1reKKys0aQ3mxRXgub 0vzt10/f5Wiy6UDYID2k/0oastrmzQQAnX33x3ltDvYoIJU+JI8fYFzur3jENomsddaP d+Z7p7XYab/6bWk62K+QZmffVb7VLNCcU3VZ1BTVohCvZ4qtzWebUs84cp4fyOKGQCmb DE3UPDloRwC0WOL1vcICLc3me/t8SkvxaicOQ+VarBu8aJ/K300FXtuPmKwjRhtbty/N ZNiao+NkFTjKjQzZmUF++wPUWff3JX2uiJf6pU4EC7FnnylF3SJD9ZOQebQbikMKZtXN uY8w== 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=ZghGAV70MAETfA8ua9pAPGOeyTQ3ZlN4VRymh82VSEw=; b=wwIr2G3z22YfVcWFubO1VrGiKkInOyfpPeSgcwKpmf4mkKVLbe0XpwffsA1SEJmq5s eE8bc1K4A/RZeGjhBrte7KUx4ypo3lhheIepjdkzi0vrdihZff40eyzezqIDJmCQBxr7 otz3mKanq0AwO2EG3zF/KRjYcYuaG1P1P+uBzE2tffJKe32oSGHqctGTCuUojMeZyRwT 0PKgM9F4aVelSvWgdCjKqndYbTHHcqdtu/oP8CdMtCScmwL8HI9XZmUwZEUHiavAVWjH y3FGMcs5Fy/78JUMfdoqGQQ+XWONyqoZShtXKPDrTNvUUxx6FW5bWUq9X8lvtg2mcg6r TBsg== X-Gm-Message-State: AJIora+AWtl4EAprYBrKRhvvGonmbJrNZi8gjoucy9ytUjOQMrqTHeE8 r9v2pW43rQ8f3vqUgZTBZ8xLAW1/4odlGcpzxcJDeQ== X-Google-Smtp-Source: AGRyM1tCarrrIc95qUhb18cpeeNKAz2Gfb3CZRhFr75vxrjac2/xTBBaEP299pBI6xI+XJe946Kvm3ULcHAislYBNGY= X-Received: by 2002:a05:6122:18a9:b0:36c:5257:4f04 with SMTP id bi41-20020a05612218a900b0036c52574f04mr4109300vkb.32.1655876073052; Tue, 21 Jun 2022 22:34:33 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Tue, 21 Jun 2022 23:34:21 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Steve Kargl Cc: Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000002072b205e202b156" X-Rspamd-Queue-Id: 4LSXBd5ggsz3PCs X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hRHZIkx8; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a30) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [0.11 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.20)[-0.198]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.31)[0.307]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a30:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N --0000000000002072b205e202b156 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022, 10:59 PM Steve Kargl wrote: > On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Losh wrote: > > On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann > wrote: > > > > > I would kindly ask to stop pushing for removal of sc. > > > > > > > It will die soon enough if it doesn't become giant locked soon... > > > > Warner > > > > Are you deleting vt, too? > The project likely has resources to remove giant from only one console driver. That will almost certainly be vt. Warner > % grep -i giant /var/run/dmesg.boot > atkbd0: [GIANT-LOCKED] > WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD > 14.0. > lock order reversal: (Giant after non-sleepable) > 2nd 0xffffffff80c02840 Giant (Giant, sleep mutex) @ > /usr/src/sys/kern/kern_synch.c:232 > lock order Giant -> vtdev established at: > lock order vtdev -> Giant attempted at: > > -- > Steve > --0000000000002072b205e202b156 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 21, 2022, 10:59 PM Steve Kargl <sgk@troutmask.apl.washington.e= du> wrote:
On Tue, Jun 21, 2= 022 at 10:55:01PM -0600, Warner Losh wrote:
> On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann <sblachmann@gmail.= com> wrote:
>
> > I would kindly ask to stop pushing for removal of sc.
> >
>
> It will die soon enough if it doesn't become giant locked soon...<= br> >
> Warner
>

Are you deleting vt, too?
The project likely has resources to remove giant f= rom only one console driver. That will almost certainly be vt.

Warner=C2=A0
=

% grep -i giant /var/run/dmesg.boot
atkbd0: [GIANT-LOCKED]
WARNING: Device "fb" is Giant locked and may be deleted before Fr= eeBSD 14.0.
lock order reversal: (Giant after non-sleepable)
=C2=A02nd 0xffffffff80c02840 Giant (Giant, sleep mutex) @ /usr/src/sys/kern= /kern_synch.c:232
lock order Giant -> vtdev established at:
lock order vtdev -> Giant attempted at:

--
Steve
--0000000000002072b205e202b156-- From eugen@grosbein.net Wed Jun 22 05:45:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9FFE88687AF for ; Wed, 22 Jun 2022 05:45:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LSXRb1m1Pz3R2f for ; Wed, 22 Jun 2022 05:45:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 25M5jXQZ003898 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jun 2022 05:45:34 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: imp@bsdimp.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 25M5jXHh076516 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 22 Jun 2022 12:45:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Warner Losh , Steve Kargl References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> Cc: Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers From: Eugene Grosbein Message-ID: <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> Date: Wed, 22 Jun 2022 12:45:27 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LSXRb1m1Pz3R2f X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [2.89 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[0.999]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_MEDIUM(0.99)[0.993]; NEURAL_HAM_LONG(-1.00)[-0.999]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FREEMAIL_CC(0.00)[gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 22.06.2022 12:34, Warner Losh wrote: > On Tue, Jun 21, 2022, 10:59 PM Steve Kargl > wrote: > > On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Losh wrote: > > On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann > wrote: > > > > > I would kindly ask to stop pushing for removal of sc. > > > > > > > It will die soon enough if it doesn't become giant locked soon... > > > > Warner > > > > Are you deleting vt, too? > > > The project likely has resources to remove giant from only one console driver. That will almost certainly be vt. Then sc(4) should stay giant-locked until vt(4) implements all features called-for sc. After all, sc is not network nor I/O "hot path". From nobody Thu Jun 23 07:43:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1AD45877CB7 for ; Thu, 23 Jun 2022 07:43:24 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (kazi.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (using TLSv1.3 with cipher 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 "kazi.fit.vutbr.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTC0q0Nhkz4lJy for ; Thu, 23 Jun 2022 07:43:22 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (8.17.1.9/8.17.1) with ESMTPS id 25N7hC5I033417 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 23 Jun 2022 09:43:12 +0200 (CEST) (envelope-from cejkar@fit.vutbr.cz) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fit.vutbr.cz; s=mx1; t=1655970192; bh=NdMyovcifJXqSJH909j/AqxJLYQ0CokGujx8Ku3j5k4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=djXJ4l6dAa7rsT7hi6YuK/HyGGNeiTE6bIeGY5/XGH5CrW3hHWb9w0HijzL3s4LR4 MQj6ze8rWkiKNu5GaQG9KAPyTMl2XI/ElddSZMdIefRCRu0ygwER4ST9hpL4d5X/iz N24/WmdhaTWYeLHzHWUERDZEs2mePjZf3rHCKEI0= Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.17.1.9/8.17.1/Submit) id 25N7h877033405; Thu, 23 Jun 2022 09:43:08 +0200 (CEST) (envelope-from cejkar@fit.vutbr.cz) X-Authentication-Warning: kazi.fit.vutbr.cz: cejkar set sender to cejkar@fit.vutbr.cz using -f Date: Thu, 23 Jun 2022 09:43:08 +0200 From: Cejka Rudolf To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LTC0q0Nhkz4lJy X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fit.vutbr.cz header.s=mx1 header.b=djXJ4l6d; dmarc=pass (policy=none) header.from=fit.vutbr.cz; spf=pass (mx1.freebsd.org: domain of cejkar@fit.vutbr.cz designates 2001:67c:1220:808::93e5:80c as permitted sender) smtp.mailfrom=cejkar@fit.vutbr.cz X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[fit.vutbr.cz:s=mx1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:kazi.fit.vutbr.cz]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[fit.vutbr.cz:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[fit.vutbr.cz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:197451, ipnet:2001:67c:1220::/46, country:CZ]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, so is there any solution for problem below now? Cejka Rudolf wrote (2021/11/29): > Hello, > I have one problem or two with VT in FreeBSD 12. I wrote a question in > freebsd-stable what to do, but without response, so I still have to > use SC. Please, could you look at it? There is not configured device > /dev/console without monitor after upgrade from 11 to 12 and device > /dev/kbdmux0 is busy using VT but not with SC. > > Subject: Unable to grab keyboard with VT on a headless node in stable/12 > > Hello, > I have a headless node without monitor and without keyboard. There > is just network and USB card reader in keyboard mode. > > In stable/11, there was no problem to disconnect USB card reader > from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open > /dev/ukbd0 in a program. > > However, under stable/12 it works just with connected monitor. > > Without monitor, there is an error: > > # kbdcontrol < /dev/console > -bash: /dev/console: Device not configured > > Furthermore with default VT, it is also impossible to use /dev/kbdmux0: > > # kbdcontrol < /dev/kbdmux0 > -bash: /dev/kbdmux0: Device busy > > I have found a workaround using SC, where it is possible to atleast > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but why > keyboard operation is now dependend on connected monitor? And why VT > does not allow to open /dev/kbdmux0? > > Thank you. -- Rudolf Cejka https://www.fit.vut.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 1/2, 612 00 Brno, Czech Republic From nobody Thu Jun 23 15:26:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C81F87E928 for ; Thu, 23 Jun 2022 15:27:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPHn3625z4p7T for ; Thu, 23 Jun 2022 15:27:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2c.google.com with SMTP id b4so6561176vkh.6 for ; Thu, 23 Jun 2022 08:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qxFxv8IvLG+ov6ZRo0DoGnhRxmG3ZMd9j093J1e69fI=; b=njM8QFzMRbV5AAzG+krrWcjh+zEBvwtgEPTk7yERpaozVb4TlkHY+Y3nkHzLS45T48 81kLaG1AOb83/NoedOhdtWhJ+exlGdvfhUTKwNj70Q9b8kuUUiFQU0TnsGSja/8Omn4g v0Usx1xndNT4Qf+jevF61jxqf0LRuGcWyhoEs3FOwWszge7vQTZQYK0kPU8KkUrpzh3v QD6+wH2LqNgMKoxBeUYc206hx9jGdXUMtElTgfMNF8xg9bUrizTNKOEdMd6IyaJWagJx cKDc1P3DI/6Qq6M7BWGh7nkdlNbNqR+9Ojwj0CjGEDOmaWbi58MUVRIyYwr41spHlBF6 fhqQ== 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=qxFxv8IvLG+ov6ZRo0DoGnhRxmG3ZMd9j093J1e69fI=; b=7YrQipxGU+gqJnqvL5qJ04vJfqGGYOx+dRG8FDpAah1Un0mMMHdIR8pG367xUeK+7/ Jupw2NdYHHFpM6RchvvbZbGt7P5Gn31T6T0mKF9599206tJpwaeNSzOCJg0Nm4OS7anB ty/8L0HMSRflIlug6vQ3AJcLlyMei8xHSN7leT9YxKqe7UGn15xASCzasm7Vx4OSCoWd tfWzV3JHASNsxPQaQ177fwwxtVBD2uAxl8Ym7IIIPLK30EOoeuHGmIs3uH2Zqxq8sbQ6 qJnBQPsnvOF36VZbdrS48AbYW4GveUhhHLcSbKgPBp9LLkst9tY+Hmy1SyoyyQUZZhcR F2Cw== X-Gm-Message-State: AJIora8CnZ62nOSsblU6KRY5gdGlr604cHGjRps4G9GkLHe7TSdmd8Nd PPBR3jvyI4n1OEqgigsOW5jJBIZmOE7m8YygydIQ3w== X-Google-Smtp-Source: AGRyM1vGJutcCJ/L2UukbX6VUAa2dLLN39ITwYe0K03FvbnemA5Pjhyxctn142N+bTEZJrbsBj+FnKWuRLJcokDGC/0= X-Received: by 2002:a05:6122:143a:b0:36c:177c:4f97 with SMTP id o26-20020a056122143a00b0036c177c4f97mr10799953vkp.23.1655998015079; Thu, 23 Jun 2022 08:26:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> In-Reply-To: <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> From: Warner Losh Date: Thu, 23 Jun 2022 09:26:43 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Eugene Grosbein Cc: Steve Kargl , Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000701be205e21f1552" X-Rspamd-Queue-Id: 4LTPHn3625z4p7T X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=njM8QFzM; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[troutmask.apl.washington.edu,gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N --000000000000701be205e21f1552 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 21, 2022 at 11:46 PM Eugene Grosbein wrote: > 22.06.2022 12:34, Warner Losh wrote: > > > On Tue, Jun 21, 2022, 10:59 PM Steve Kargl < > sgk@troutmask.apl.washington.edu > > wrote: > > > > On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Losh wrote: > > > On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann < > sblachmann@gmail.com > wrote: > > > > > > > I would kindly ask to stop pushing for removal of sc. > > > > > > > > > > It will die soon enough if it doesn't become giant locked soon... > > > > > > Warner > > > > > > > Are you deleting vt, too? > > > > > > The project likely has resources to remove giant from only one console > driver. That will almost certainly be vt. > > Then sc(4) should stay giant-locked until vt(4) implements all features > called-for sc. > After all, sc is not network nor I/O "hot path". > Giant is being removed entirely, and with it all straggler drivers that aren't converted by the removal date. There's no fixed date for this, at the present time, but I'm about to commit changes that make it impossible for new code to reference Giant. Having Giant, at all, causes slow downs elsewhere in the system, which is why we're pushing to remove it entirely. sc(4) has lots of giant use, and is intertwingled with atkbdc, atkbd and ms in ways that are tricky to unwind (though some work to unwind ms has been committed). "All" features won't be a gating factor, unfortunately, unless somebody steps up and (a) does them or (b) actively funds the work. vt(4) is complete enough that straggler issues won't gate a future sc(4) removal when Giant goes away. Especially since many of the issues are on hard to obtain platforms and/or cards that aren't entirely mainstream. In an ideal world, we'd not have to make such choices, but the project must and it's better to be honest about it than to give people false hope. Warner --000000000000701be205e21f1552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jun 21, 2022 at 11:46 PM Euge= ne Grosbein <eugen@grosbein.net> wrote:
22.= 06.2022 12:34, Warner Losh wrote:

> On Tue, Jun 21, 2022, 10:59 PM Steve Kargl <sgk@troutmask.apl.washington= .edu <mailto:sgk@troutmask.apl.washington.edu>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Lo= sh wrote:
>=C2=A0 =C2=A0 =C2=A0> On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann= <sblachmann@g= mail.com <mailto:sblachmann@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> > I would kindly ask to stop pushing for re= moval of sc.
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> It will die soon enough if it doesn't beco= me giant locked soon...
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Warner
>=C2=A0 =C2=A0 =C2=A0>
>
>=C2=A0 =C2=A0 =C2=A0Are you deleting vt, too?
>
>
> The project likely has resources to remove giant from only one console= driver. That will almost certainly be vt.

Then sc(4) should stay giant-locked until vt(4) implements all features cal= led-for sc.
After all, sc is not network nor I/O "hot path".
=

Giant is being removed entirely, and with it all stragg= ler drivers that aren't converted by the removal date.
There&= #39;s no fixed date for this, at the present time, but I'm about to com= mit changes that make it impossible
for new code to reference Gia= nt. Having Giant, at all, causes slow downs elsewhere in the system, which<= /div>
is why we're pushing to remove it entirely. sc(4) has lots of= giant use, and is intertwingled with atkbdc, atkbd
and ms in way= s that are tricky to unwind (though some work to unwind ms has been committ= ed).

"All" features won't be a gatin= g factor, unfortunately, unless somebody steps up and (a) does them
or (b) actively funds the work. vt(4) is complete enough that straggler = issues won't gate a future sc(4)
removal when Giant goes away= . Especially since many of the issues are on hard to obtain platforms
=
and/or cards that aren't entirely mainstream. In an ideal world, w= e'd not have to make such choices,
but the project must and i= t's better to be honest about it than to give people false hope.
<= div>
Warner
--000000000000701be205e21f1552-- From eugen@grosbein.net Thu Jun 23 15:36:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AF90D85851D for ; Thu, 23 Jun 2022 15:36:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPVs2Zntz4qsm for ; Thu, 23 Jun 2022 15:36:37 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 25NFaQxf018502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Jun 2022 15:36:26 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: imp@bsdimp.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 25NFaOTI089073 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 23 Jun 2022 22:36:24 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Warner Losh References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> Cc: Steve Kargl , Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers From: Eugene Grosbein Message-ID: <8d6ae56e-9265-6b2e-c966-1c51f00f6c88@grosbein.net> Date: Thu, 23 Jun 2022 22:36:17 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LTPVs2Zntz4qsm X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [1.56 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all:c]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SUBJECT_ENDS_QUESTION(1.00)[]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.89)[0.894]; NEURAL_HAM_LONG(-0.27)[-0.271]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FREEMAIL_CC(0.00)[troutmask.apl.washington.edu,gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 23.06.2022 22:26, Warner Losh wrote: > Giant is being removed entirely, and with it all straggler drivers that aren't converted by the removal date. > There's no fixed date for this, at the present time, but I'm about to commit changes that make it impossible > for new code to reference Giant. Having Giant, at all, causes slow downs elsewhere in the system, which > is why we're pushing to remove it entirely. Why is it better to lose working code then to keep it "slow"? From nobody Thu Jun 23 15:37:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23950859043 for ; Thu, 23 Jun 2022 15:38:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPXZ5qqgz4rXK for ; Thu, 23 Jun 2022 15:38:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id 15so6397293vko.13 for ; Thu, 23 Jun 2022 08:38: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=Ckf9tQevqFFrAdlBRTL12RlFvNu7hyDVT3T0Ol44zGw=; b=r9nS8WwHTQfeLkrDdbwWe4fx6lEgjadgGdJ9RfT5fiWLc1xXQHCERSKObWJ0hqBZTK AUwR9XVwK3o0zfoYVyxz7rOxvV6dHHoMfalz/DudIH4eAg3pt80IznZTHQnwiZjMuvcR uXQAB2RK65phINBgGCGhO0lxarbNtRx5WFAJeiBuf5Papke+vhjEi9DR4yoXqgatd83k xIhzajCzDIYIItSr2c0VbfmgfgTc0YL5831zvCNP1rkq7sAyA0W5O4YT1dF28wV8h29K iLXKnikEhuQ2nuMx6e03BNqa6PaPpd/sptHw8CWnB42nDVM/KTL/Jz6RgRFgv+mgMgSl W1SA== 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=Ckf9tQevqFFrAdlBRTL12RlFvNu7hyDVT3T0Ol44zGw=; b=VrJ6XBX8C+9dEiUdrrBRgJ6bYm14S1wxC8KD6AGZsDHT6FNnXcKS7fvHGbORV5T6HT iGZ1ZwoGmTj5btwjfXnLsldOeleqFkmL17w4akV0T78gxsrSX9R7uPGSvpRV47sGw5jo /8S1nXxL6cLWfmM3Tk+SUaqZOjiqgsRYHlpsBEBQocUY/34C5XyUtV6pDdXjSg7AYjpY K1bGXZtSVwueo0VomPwheJaXbpEFZ2dKKncJYLg3fw9TePYidyoFFGrCwyGwaj1KyZbK 9lprhhHoZ1WOqoFXxaiY2Y5jv+mku6/L9F45kVqwETL2/iw5Yxdl+W7DOQAdhhArxo4N Y4aw== X-Gm-Message-State: AJIora98blQv/rS4Ihx6Eo8Q4l+aKLI8qRWRW7Z0/bP1Ldy+3OcR67sa 01Fe2hOrWwxRrWktUAFjLBBQl8wRUxte4kvweIAPdPgPe8A= X-Google-Smtp-Source: AGRyM1tpANkfa7xQZ1k+WEDQ7aRJjCDjyy4/kQYqrp7e1HWkqH2cXBsNq1wS5tABbKfc99wf0UjRHlA7BaMZmi78dTk= X-Received: by 2002:a05:6122:10d6:b0:36c:17a4:28b with SMTP id l22-20020a05612210d600b0036c17a4028bmr10963446vko.23.1655998686182; Thu, 23 Jun 2022 08:38:06 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> In-Reply-To: From: Warner Losh Date: Thu, 23 Jun 2022 09:37:55 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Cejka Rudolf Cc: Emmanuel Vadot , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000070543505e21f3d4d" X-Rspamd-Queue-Id: 4LTPXZ5qqgz4rXK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=r9nS8WwH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.89 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.907]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000070543505e21f3d4d Content-Type: text/plain; charset="UTF-8" On Thu, Jun 23, 2022 at 1:44 AM Cejka Rudolf wrote: > Hello, > so is there any solution for problem below now? > > Cejka Rudolf wrote (2021/11/29): > > Hello, > > I have one problem or two with VT in FreeBSD 12. I wrote a question in > > freebsd-stable what to do, but without response, so I still have to > > use SC. Please, could you look at it? There is not configured device > > /dev/console without monitor after upgrade from 11 to 12 and device > > /dev/kbdmux0 is busy using VT but not with SC. > > > > Subject: Unable to grab keyboard with VT on a headless node in stable/12 > > > > Hello, > > I have a headless node without monitor and without keyboard. There > > is just network and USB card reader in keyboard mode. > > > > In stable/11, there was no problem to disconnect USB card reader > > from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open > > /dev/ukbd0 in a program. > > > > However, under stable/12 it works just with connected monitor. > > > > Without monitor, there is an error: > > > > # kbdcontrol < /dev/console > > -bash: /dev/console: Device not configured > > > > Furthermore with default VT, it is also impossible to use /dev/kbdmux0: > > > > # kbdcontrol < /dev/kbdmux0 > > -bash: /dev/kbdmux0: Device busy > > > > I have found a workaround using SC, where it is possible to atleast > > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but why > > keyboard operation is now dependend on connected monitor? And why VT > > does not allow to open /dev/kbdmux0? > > > > Thank you. > Have you filed a bug for this? This looks like a legit bug and one that should be easy(ish) to reproduce. Or at least it looks that way on the surface, there might be a pilot error as well that just happened to work before and needs a slightly different workaround to what you are doing... And it's an actual monitor connected that's the only difference? Or is this some KVM switch that's connected, so there's an atkbd in the mix somewhere? What's the difference in dmesg between these two boots? Is this with EFI or legacy BIOS boot? 'Not conifgured' is ENXIO which is returned when /dev/console isn't there (eg, no /dev/console), which seems weird in the extreme. And it's 'bash' that's giving the message, which means kbdcontrol isn't even getting invoked. A dmesg with bootverbose would be most enligtening. And I'm also a little confused, detach ukbd0 from a usb card reader? That's an interesting setup. While it won't affect whether or not this is a bug, I'd be interested to know more details there... Warner --00000000000070543505e21f3d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 23, 2022 at 1:44 AM Cejka= Rudolf <cejkar@fit.vutbr.cz&= gt; wrote:
Hello= ,
=C2=A0 so is there any solution for problem below now?

Cejka Rudolf wrote (2021/11/29):
> Hello,
>=C2=A0 =C2=A0I have one problem or two with VT in FreeBSD 12. I wrote a= question in
> freebsd-stable what to do, but without response, so I still have to > use SC. Please, could you look at it? There is not configured device > /dev/console without monitor after upgrade from 11 to 12 and device > /dev/kbdmux0 is busy using VT but not with SC.
>
> Subject: Unable to grab keyboard with VT on a headless node in stable/= 12
>
> Hello,
>=C2=A0 =C2=A0I have a headless node without monitor and without keyboar= d. There
> is just network and USB card reader in keyboard mode.
>
> In stable/11, there was no problem to disconnect USB card reader
> from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open
> /dev/ukbd0 in a program.
>
> However, under stable/12 it works just with connected monitor.
>
> Without monitor, there is an error:
>
> # kbdcontrol < /dev/console
> -bash: /dev/console: Device not configured
>
> Furthermore with default VT, it is also impossible to use /dev/kbdmux0= :
>
> # kbdcontrol < /dev/kbdmux0
> -bash: /dev/kbdmux0: Device busy
>
> I have found a workaround using SC, where it is possible to atleast > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but w= hy
> keyboard operation is now dependend on connected monitor? And why VT > does not allow to open /dev/kbdmux0?
>
> Thank you.

Have you filed a bug fo= r this? This looks like a legit bug and one that should be easy(ish) to rep= roduce.
Or at least it looks that way on the surface, there might= be a pilot error as well that just happened to
work before and n= eeds a slightly different workaround to what you are doing...
And it's an actual monitor connected that's the only di= fference? Or is this some KVM switch that's
connected, so the= re's an atkbd in the mix somewhere? What's the difference in dmesg = between
these two boots? Is this with EFI or legacy BIOS boot?

'Not conifgured' is ENXIO which is returned = when /dev/console isn't there (eg, no /dev/console), which
se= ems weird in the extreme. And it's 'bash' that's giving the= message, which means kbdcontrol isn't
even getting invoked. = A dmesg with bootverbose=C2=A0would be most enligtening.

And I'm also a little confused, detach ukbd0 from a usb card rea= der? That's an interesting setup. While
it won't affect w= hether or not this is a bug, I'd be interested to know more details the= re...

Warner

--00000000000070543505e21f3d4d-- From nobody Thu Jun 23 15:44:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A28EC85B895 for ; Thu, 23 Jun 2022 15:44:41 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPh84HqTz4vJn for ; Thu, 23 Jun 2022 15:44:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe31.google.com with SMTP id o13so8478111vsn.4 for ; Thu, 23 Jun 2022 08:44: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=0NAhNfggj+TGn/63CD98L2uSpLVerOlBcGzeQQFoayY=; b=hKjz56iR4x8b9EU/NtRobVpTQnVn4pnLF8gmN/DQMkSZKwu5Jctw2NPpeem8V9LiGj Nfg3dKWkPh+hADu5Plba92/JEcc6iDKu8Bt5f33uvapWbCJgzIsJA71PdUZQROkkRR8h OuHRuQV0uvZkFDcn7wqlmDXnkYZKt7ryeYcuO/T2PaI5aNtMxhKFmPoQ8rJSJwt6lQmJ JxNr7y5Ja2vdDlUHQvQ1BPChvDycsndOSQ0PMGiXNj0QNltjImpirkb2rHq7k6tflw2R zmfzWtZe7SD0CgNxd8VLdfIrFffdxtK1Xraznuj1/FkTiqn7a42DjMVIUboeGtdjRBJZ NmTQ== 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=0NAhNfggj+TGn/63CD98L2uSpLVerOlBcGzeQQFoayY=; b=4BFnmmIVqMoJcSbnVihp0jZ5cDLVfSDNIfdnFLqMWCUTg0Uu5MuqeOMbKQNPzsCfmX ADbPADemp7OuaH2FpZvCD1bQhX27aBjnY36DBQr4giCFNP3qMz0bR3/oU6WHPjXrJjls sii4S+S4M+9ejMtDi12xZ3Zmvajl1JRPEaQT6DBnsIFfVR28VASsuY303cXf0clh0HD/ aRMzlvyeTO+5kw0xDsxIGu3P3sxmGCuZnYF+9bQo1LSQtPr4eTVUta05a7AJRzjYtVfu R7vr4Qudn+I9bKMxWFjzqzvWHUwWDMd5PlnEp5ePGm6nldQNBL/wNNhJwesSa6oB2hDs 4D5A== X-Gm-Message-State: AJIora+sodaoCOGeRXkbfyZEeA0BrLbhJzIQiCxZfZpD/LD9fjOJnMqC mbK7E2Dg0412NDoWU7yh6cOuQVcOKXa68Oaf+NRdgA== X-Google-Smtp-Source: AGRyM1vA3TtaV1tGsuXfWLFI5RK9zm0oWotpI5eddLe/Zx7WxWGJvJPLVQd3Vry+4/RC6u/tLSukUeBZvezgTD9kBAc= X-Received: by 2002:a67:fbd3:0:b0:354:2f5b:6477 with SMTP id o19-20020a67fbd3000000b003542f5b6477mr10724480vsr.76.1655999079879; Thu, 23 Jun 2022 08:44:39 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> <8d6ae56e-9265-6b2e-c966-1c51f00f6c88@grosbein.net> In-Reply-To: <8d6ae56e-9265-6b2e-c966-1c51f00f6c88@grosbein.net> From: Warner Losh Date: Thu, 23 Jun 2022 09:44:28 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Eugene Grosbein Cc: Steve Kargl , Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000e7a8dc05e21f54df" X-Rspamd-Queue-Id: 4LTPh84HqTz4vJn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=hKjz56iR; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.998]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e31:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[troutmask.apl.washington.edu,gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N --000000000000e7a8dc05e21f54df Content-Type: text/plain; charset="UTF-8" On Thu, Jun 23, 2022 at 9:37 AM Eugene Grosbein wrote: > 23.06.2022 22:26, Warner Losh wrote: > > > Giant is being removed entirely, and with it all straggler drivers that > aren't converted by the removal date. > > There's no fixed date for this, at the present time, but I'm about to > commit changes that make it impossible > > for new code to reference Giant. Having Giant, at all, causes slow downs > elsewhere in the system, which > > is why we're pushing to remove it entirely. > > Why is it better to lose working code then to keep it "slow"? > Supporting Giant, at all, means creating extra taskqueues, processes, etc. It means extra checks in all the code paths since Giant is so 'special'. To do this just to support an obsolete console seems to many to be an unwise tradeoff once everything else is in order. Especially since there have been years for people that care about the problems to arrange solutions. We are still some time away from everything else eliminating Giant, so there's still time to get things fixed. However, the increasingly obscure nature of the problems and/or their diminished relevancy to the project means that absent code showing up (either from the hobbyist community or from funded work), the problems will remain because the limited resources of those working on the project aren't ample enough for them to be solved. If they are important to you, and nobody else is working on them, now is your chance. Ideally, there'd be enough time and people to solve all the problems, but there is not. Warner --000000000000e7a8dc05e21f54df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 23, 2022 at 9:37 AM Eugen= e Grosbein <eugen@grosbein.net= > wrote:
23.0= 6.2022 22:26, Warner Losh wrote:

> Giant is being removed entirely, and with it all straggler drivers tha= t aren't converted by the removal date.
> There's no fixed date for this, at the present time, but I'm a= bout to commit changes that make it impossible
> for new code to reference Giant. Having Giant, at all, causes slow dow= ns elsewhere in the system, which
> is why we're pushing to remove it entirely.

Why is it better to lose working code then to keep it "slow"?
=

Supporting Giant, at all, means creating e= xtra taskqueues, processes, etc. It means extra checks in
all the= code paths since Giant is so 'special'. To do this just to support= an obsolete console seems to
many to be an unwise tradeoff once = everything else is in order. Especially since there have been years
for people that care about the problems to arrange solutions.
=
We are still some time away from everything else eliminating= Giant, so there's still time to get things
fixed. However, t= he increasingly obscure nature of the problems and/or their diminished rele= vancy
to the project means that absent code showing up (either fr= om the hobbyist community or from
funded work), the problems will= remain because the limited resources of those working on the
pro= ject aren't ample enough for them to be solved. If they are important t= o you, and nobody
else is working on them, now is your chance. Id= eally, there'd be enough time and people to
solve all the pro= blems, but there is not.

Warner
--000000000000e7a8dc05e21f54df-- From nobody Thu Jun 23 15:57:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 289C685ED3E for ; Thu, 23 Jun 2022 15:57:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTPzQ3GQ3z4yQT for ; Thu, 23 Jun 2022 15:57:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe35.google.com with SMTP id o190so3484309vsc.5 for ; Thu, 23 Jun 2022 08:57:54 -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=rSslDPh1hbihlteNfne7IJC+Fjmo7aklm2pa9UfXkRg=; b=CDsNEgXEwT9ih1tpwL/VXdRntOXaIYLHdHk4V/USLJ2yCLf3a0TFXjMIpndl7zvRqD 2oAT7DolChiiTv5OFnpWYfR5xFyERUR7mZ6Sa87KIyit8c4xwU1vQ/m4fCdFb2ZK6hr9 +67OmlmNolkxMAfpyzya+huHmYsK1bVBTS9sDaTmtwdoFRVbGCnezZm13fkifb1Um9qj 7rKAg2xIRY/h2Venhw7ffR+hXaPEYuq/ZwaewuMMUquphxiKn68W8MalU1NbZV2iOSku kOd9v0YVHl+4Dsubn3pEzEUSnSbqfjFB4IMb7h0eI+qpdgG1G9EiL14AaOqm4Ix2KIOc BEtA== 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=rSslDPh1hbihlteNfne7IJC+Fjmo7aklm2pa9UfXkRg=; b=0XD+IvquD7uQn/TnHvp+npIb9A+/DFd+B6rWT+pGnnUWbOAKPM4s74EceMS9Aa5g1a gt/Mf29Sd9p2SEgx0Q+3iB7+3hrvciBk+GVRpE9u8SPqBnmG/rrGAjlVO1JZBdGOykI9 wDY10vKHsdphLvaowyOkGSQ1e80w6wzlWB3Fl/rJ2kSfL6hO71KJx2XoPv/5AvRgTjcz W9bjym+zIMAH4L+XAOzxoukZyKjsKX2W8zp/v0AJ7EwE0tvKseGZFRkW/f/FDfCCQDRX +cT4e6Bt3VQT3oSMGU+JaNHdLz/cTLt7QV2gI6iMORbBm8Mi+9QYK3gpazdzh++YE0lz HlXw== X-Gm-Message-State: AJIora/Z4RgGHfmpDWRwJKyhKvWqkvuE9ZUPouwe6BXD+a70+j3gTLDl X7XURXx6zZTuookwyZz8itFgCcw8sahb8/Ms8KJTMRqJCio= X-Google-Smtp-Source: AGRyM1vu/LIypzXpk4Ugi+8bMYz0bqjdm7whtmpluDH4j+v1jPXVwEqrWuk+bbHPm6T0ndLFl9jcFYWEJr+fp8f0uCU= X-Received: by 2002:a05:6102:3d85:b0:34c:102b:560 with SMTP id h5-20020a0561023d8500b0034c102b0560mr17532839vsv.40.1655999873946; Thu, 23 Jun 2022 08:57:53 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 23 Jun 2022 09:57:42 -0600 Message-ID: Subject: Re: Sanity check on a change to module load order To: Harris Snyder Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000003c270f05e21f8420" X-Rspamd-Queue-Id: 4LTPzQ3GQ3z4yQT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=CDsNEgXE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e35) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-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)[-0.998]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e35:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000003c270f05e21f8420 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 20, 2022 at 8:11 PM Harris Snyder wrote: > Hello, > > I've been trying to get the iSCSI boot module to work ("isboot" in the > ports collection) with a PCIe Mellanox NIC, and I noticed that isboot > is declared as part of the SI_SUB_PROTO_END subsystem, whereas the > mellanox driver module is SI_SUB_ROOT_CONF-2 (via a linux kpi > #define), which comes later. So the iSCSI boot failed, because it > couldn't find the Mellanox NIC as the driver wasn''t loaded yet. I am > brand new to the FreeBSD kernel, but I was going to propose that the > port maintainer simply move isboot down to SI_SUB_ROOT_CONF-1. Is this > a bad idea for some reason that I'm not aware of? I tried the proposed > modification on my own system. iSCSI boot is still failing, but for > what I think is an unrelated reason. Even if I do get it working, are > there any obvious undesirable side effects that I'm simply not aware > of? > In general, moving things later in the boot process to satisfy a prereq like this is fine (unless you move it past something else that depends on this having already started). I'm not super familiar with this code, but I took a quick look. I'm not seeing anything that I would flag as an issue. Warner --0000000000003c270f05e21f8420 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 20, 2022 at 8:11 PM Harri= s Snyder <harris.snyder@gmail= .com> wrote:
Hello,

I've been trying to get the iSCSI boot module to work ("isboot&quo= t; in the
ports collection) with a PCIe Mellanox NIC, and I noticed that isboot
is declared as part of the SI_SUB_PROTO_END subsystem, whereas the
mellanox driver module is SI_SUB_ROOT_CONF-2 (via a linux kpi
#define), which comes later. So the iSCSI boot failed, because it
couldn't find the Mellanox NIC as the driver wasn''t loaded yet= . I am
brand new to the FreeBSD kernel, but I was going to propose that the
port maintainer simply move isboot down to SI_SUB_ROOT_CONF-1. Is this
a bad idea for some reason that I'm not aware of? I tried the proposed<= br> modification on my own system. iSCSI boot is still failing, but for
what I think is an unrelated reason. Even if I do get it working, are
there any obvious undesirable side effects that I'm simply not aware of?

In general, moving things later in = the boot process to satisfy a prereq
like this is fine (unless yo= u move it past something else that depends
on this having already= started).

I'm not super familiar with this co= de, but I took a quick look. I'm not
seeing anything that I w= ould flag as an issue.

Warner
--0000000000003c270f05e21f8420-- From nobody Thu Jun 23 16:15:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 919EE862F71 for ; Thu, 23 Jun 2022 16:15:30 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTQMj3V23z53CC; Thu, 23 Jun 2022 16:15:29 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-85-147.area1b.commufa.jp [123.1.85.147]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 25NGF4n3081926; Fri, 24 Jun 2022 01:15:05 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Fri, 24 Jun 2022 01:15:04 +0900 From: Tomoaki AOKI To: Warner Losh Cc: Eugene Grosbein , Steve Kargl , Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-Id: <20220624011504.ab5591564ee40d5f0310bebd@dec.sakura.ne.jp> In-Reply-To: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> <8d6ae56e-9265-6b2e-c966-1c51f00f6c88@grosbein.net> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LTQMj3V23z53CC X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [1.41 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; RCPT_COUNT_SEVEN(0.00)[8]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.85.147:received]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.99)[0.987]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[grosbein.net,troutmask.apl.washington.edu,gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 23 Jun 2022 09:44:28 -0600 Warner Losh wrote: > On Thu, Jun 23, 2022 at 9:37 AM Eugene Grosbein wrote: > > > 23.06.2022 22:26, Warner Losh wrote: > > > > > Giant is being removed entirely, and with it all straggler drivers that > > aren't converted by the removal date. > > > There's no fixed date for this, at the present time, but I'm about to > > commit changes that make it impossible > > > for new code to reference Giant. Having Giant, at all, causes slow downs > > elsewhere in the system, which > > > is why we're pushing to remove it entirely. > > > > Why is it better to lose working code then to keep it "slow"? > > > > Supporting Giant, at all, means creating extra taskqueues, processes, etc. > It means extra checks in > all the code paths since Giant is so 'special'. To do this just to support > an obsolete console seems to > many to be an unwise tradeoff once everything else is in order. Especially > since there have been years > for people that care about the problems to arrange solutions. > > We are still some time away from everything else eliminating Giant, so > there's still time to get things > fixed. However, the increasingly obscure nature of the problems and/or > their diminished relevancy > to the project means that absent code showing up (either from the hobbyist > community or from > funded work), the problems will remain because the limited resources of > those working on the > project aren't ample enough for them to be solved. If they are important to > you, and nobody > else is working on them, now is your chance. Ideally, there'd be enough > time and people to > solve all the problems, but there is not. > > Warner Is it possible / planned to make atkbd and psm GIANT-free? They shouldn't go away, as at least some notebooks implements their keyboards / pointing devices attached with them, not USB. They're clearly show-stoppers, I think. -- Tomoaki AOKI From nobody Thu Jun 23 16:52:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 13EE0868953 for ; Thu, 23 Jun 2022 16:53:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTRC50811z57D6 for ; Thu, 23 Jun 2022 16:53:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe34.google.com with SMTP id h7so689763vsr.11 for ; Thu, 23 Jun 2022 09:53: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=iA6rCX9PNNM0cGhdz/yiuLMXWgq+blguLSBr0nZNAiQ=; b=DtbK1wkKpIiIR8HK865UqYjOSUKHAttv1RAECT0OGm0Pa7MVW4mGEejMKrDuVEDAKq QAL2DBqH9CxuqQbazwn0eM+OW10k4vCUJhjmjesI0a31QKJm+cOfBXneiTsSDM/ee1Wc BcCztTla5/EUIrI8wFdsqlHQHBK5BuyxzHcA7jxvjpBtwFgoajSMnPSin+G1fSDndJUB C7MXig9S+SkyA5V7Lu33j54XEY+h89bQOWGesOQPjyUJR23KJdJRONVd9ssz5Rkf13lr zLfmPapww/44Boa6Ltux6ZfOkhBLgbcvWptfig/brTZN7GLnUunHf66MfJq9QqYmthvi MrZw== 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=iA6rCX9PNNM0cGhdz/yiuLMXWgq+blguLSBr0nZNAiQ=; b=0Fu29JY/s/XFEDiusZHc8mAfrGdjRgHbDS/NBK02BcKqhA5//WuI/XszpDe906qXX1 4ssL1gJPbQL8fd+Ly+ls8xbG1y8qael1T6uX2FjQ40K1RjMuPYu58A7SnvpJ2yEVLm+e WFmV5/6EueySLka2Tf80FL12mMK5AI0HjzBZvbnhhH1HI5J3mDyLMLTf5IZFPyjXlRZn TYdKTtTeJVFSEf6SPmUORDAyBYMdJ6um8hA4jvrtqrCuUTh9yWpLBSzQPUX9bw8MprE9 HQI90L1yXZjtCm8Z8k+8XqQESxqkPpt5J1FnsYuQ26O3wdlXhzeS66kl4Jcua3qBjrez 4Fow== X-Gm-Message-State: AJIora9xAqTqbBFJ/suZCWmWmvbFN4cH8HtHI+8lUSvNWXWnOAG8mE2z ULJW9V+vjcRI7pC0W6xDuQiaQUsIAK8DRkAmmYOnCj4Dszg= X-Google-Smtp-Source: AGRyM1u8gN852P0ZURCdhC0VRYOYJjTUviPUBqKsLBPffFwBWxXsGdbkBE3WiYk4jhTaAYblckvMbHQIl3487U/ABAE= X-Received: by 2002:a05:6102:c4f:b0:351:938d:6863 with SMTP id y15-20020a0561020c4f00b00351938d6863mr17138224vss.12.1656003184427; Thu, 23 Jun 2022 09:53:04 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> <8d6ae56e-9265-6b2e-c966-1c51f00f6c88@grosbein.net> <20220624011504.ab5591564ee40d5f0310bebd@dec.sakura.ne.jp> In-Reply-To: <20220624011504.ab5591564ee40d5f0310bebd@dec.sakura.ne.jp> From: Warner Losh Date: Thu, 23 Jun 2022 10:52:53 -0600 Message-ID: Subject: Re: Reasons for keeping sc(4) and libvgl ? To: Tomoaki AOKI Cc: Eugene Grosbein , Steve Kargl , Stefan Blachmann , Emmanuel Vadot , Ed Maste , Poul-Henning Kamp , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000008e1f6305e220495a" X-Rspamd-Queue-Id: 4LTRC50811z57D6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=DtbK1wkK; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e34) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.95 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.99)[-0.988]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.960]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCPT_COUNT_SEVEN(0.00)[8]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e34:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[grosbein.net,troutmask.apl.washington.edu,gmail.com,bidouilliste.com,freebsd.org,phk.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N --0000000000008e1f6305e220495a Content-Type: text/plain; charset="UTF-8" On Thu, Jun 23, 2022 at 10:15 AM Tomoaki AOKI wrote: > On Thu, 23 Jun 2022 09:44:28 -0600 > Warner Losh wrote: > > > On Thu, Jun 23, 2022 at 9:37 AM Eugene Grosbein > wrote: > > > > > 23.06.2022 22:26, Warner Losh wrote: > > > > > > > Giant is being removed entirely, and with it all straggler drivers > that > > > aren't converted by the removal date. > > > > There's no fixed date for this, at the present time, but I'm about to > > > commit changes that make it impossible > > > > for new code to reference Giant. Having Giant, at all, causes slow > downs > > > elsewhere in the system, which > > > > is why we're pushing to remove it entirely. > > > > > > Why is it better to lose working code then to keep it "slow"? > > > > > > > Supporting Giant, at all, means creating extra taskqueues, processes, > etc. > > It means extra checks in > > all the code paths since Giant is so 'special'. To do this just to > support > > an obsolete console seems to > > many to be an unwise tradeoff once everything else is in order. > Especially > > since there have been years > > for people that care about the problems to arrange solutions. > > > > We are still some time away from everything else eliminating Giant, so > > there's still time to get things > > fixed. However, the increasingly obscure nature of the problems and/or > > their diminished relevancy > > to the project means that absent code showing up (either from the > hobbyist > > community or from > > funded work), the problems will remain because the limited resources of > > those working on the > > project aren't ample enough for them to be solved. If they are important > to > > you, and nobody > > else is working on them, now is your chance. Ideally, there'd be enough > > time and people to > > solve all the problems, but there is not. > > > > Warner > > Is it possible / planned to make atkbd and psm GIANT-free? > They shouldn't go away, as at least some notebooks implements their > keyboards / pointing devices attached with them, not USB. > They're clearly show-stoppers, I think. > I agree. These truly are show-stoppers because we can't boot w/o them on a lot of hardware. Warner --0000000000008e1f6305e220495a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 23, 2022 at 10:15 AM Tomo= aki AOKI <junchoon@dec.saku= ra.ne.jp> wrote:
On Thu, 23 Jun 2022 09:44:28 -0600
Warner Losh <imp@bsd= imp.com> wrote:

> On Thu, Jun 23, 2022 at 9:37 AM Eugene Grosbein <eugen@grosbein.net> wrote:
>
> > 23.06.2022 22:26, Warner Losh wrote:
> >
> > > Giant is being removed entirely, and with it all straggler d= rivers that
> > aren't converted by the removal date.
> > > There's no fixed date for this, at the present time, but= I'm about to
> > commit changes that make it impossible
> > > for new code to reference Giant. Having Giant, at all, cause= s slow downs
> > elsewhere in the system, which
> > > is why we're pushing to remove it entirely.
> >
> > Why is it better to lose working code then to keep it "slow&= quot;?
> >
>
> Supporting Giant, at all, means creating extra taskqueues, processes, = etc.
> It means extra checks in
> all the code paths since Giant is so 'special'. To do this jus= t to support
> an obsolete console seems to
> many to be an unwise tradeoff once everything else is in order. Especi= ally
> since there have been years
> for people that care about the problems to arrange solutions.
>
> We are still some time away from everything else eliminating Giant, so=
> there's still time to get things
> fixed. However, the increasingly obscure nature of the problems and/or=
> their diminished relevancy
> to the project means that absent code showing up (either from the hobb= yist
> community or from
> funded work), the problems will remain because the limited resources o= f
> those working on the
> project aren't ample enough for them to be solved. If they are imp= ortant to
> you, and nobody
> else is working on them, now is your chance. Ideally, there'd be e= nough
> time and people to
> solve all the problems, but there is not.
>
> Warner

Is it possible / planned to make atkbd and psm GIANT-free?
They shouldn't go away, as at least some notebooks implements their
keyboards / pointing devices attached with them, not USB.
They're clearly show-stoppers, I think.

=
I agree. These truly are show-stoppers because we can't boot w/o t= hem
on a lot of hardware.

Warner=C2=A0
--0000000000008e1f6305e220495a-- From nobody Fri Jun 24 00:00:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 84218867495; Fri, 24 Jun 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LTcgm33Q7z3KZV; Fri, 24 Jun 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656028804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=nKWiAIfwqbrJsPYkTEWdPpstLUtmPm7mDsxyKGUUCTdX6Yphge4OWD0dm+u7apfGc8XoMw FCyB8qBk5+8dMdgCcaRvaY1r4qbB1g083TcUklsyBGX9aawXoS7PJQAhxv7e+Ox/9fQ3Wv 4XA6YNOM51vdrklc2uj5A4CvZCITog0/B4zIyAmiyJpVI2C0Wuj05oVLSXFbmmpp668h19 XgnSuvm1w4zGP01A7QYjj0mIfSaY7ejgRniroDvopR8qM0aIdaBqd8qzllbQaQK0luX6sq iNs33LJJTsUBM4M8g9q6d49DtepixVnlRLLDOewoSwcXmLZRVNPdpFLDZmPTaQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 29E751D7F3; Fri, 24 Jun 2022 00:00:04 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2022Q2 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,info@bsdcan.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20220624000004.29E751D7F3@freefall.freebsd.org> Date: Fri, 24 Jun 2022 00:00:04 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656028804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=LfrAuRjrUA7Wdy8b9wzbHJ/w3pOGN3X407PkCYVclEg=; b=XpXvaTczxaUg4UKV8eBg/b2UrXxDWN+FjYPuCdpDuqJ25zk0CKVh4+CDIGn7eYVkbzaS8c jAQlTDxUKiDSVuKVNEdWWYtbbvx4ZxZDCEC/fS0T7M4pZDp4dIUGuQKuk1Ckrsqg5KLCB4 ThKiQb3eq8fQCma+k+oNWFlXjZ9Yn/DrGI0s8xEQATsC+A1z3sT0BtGH07VPJOFcM1eLmJ dNDxU3X4k8f8vqtWXKmZ2JZCtGVDtL24g02DvcWyzkh+f+fqlYdDjOq6BENhvv/QMfAZNr qC1Cp4YCey8I3A6LiepMK5OQtYCwoxn9oHFiUWVISq05TEUJQMPKPVMr3UMa8A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656028804; a=rsa-sha256; cv=none; b=VbLDKjBzS3huT1u1W1YmuTsj1eD8w57D5v4iFJujysRRrQt73suFR/rl8xxMgUsxu6NTJ8 JBd8cy+ZJ9atVTYzqyNvZdXeoJhxxtIF6y8GPH1XvOB2rfDhPDn1cScgz1Pvi+mRChfxLj X36Lg3mtBWktjW1OhVmMkjMCJmZyHQo5hNrqtZG5NEQH8upUukdpyjP+1c7enPfdt3LexV rRcGS46mkg2+J4Fhd+QpeNIWfz65XGnhdpmAfI61cBD3lF2KQVYiOUlhfQEElMzjfjcZhD 3hvK39pOXEmtHhoh3wh81VFGYYPHuEUX0WikvumfOQOQwVQOdztdyOxUHIUHxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is June, 30th 2022 for work done since the last round of Quarterly Reports: April 2022 - June 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q2 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Fri Jun 24 15:04:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DE51C87C0D8 for ; Fri, 24 Jun 2022 15:04:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LV0lM28s7z4tb5 for ; Fri, 24 Jun 2022 15:04:31 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 25OF466c091715; Fri, 24 Jun 2022 08:04:17 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 24 Jun 2022 08:04:05 -0700 From: Chris To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org, Marek Zarychta Subject: Re: Reasons for keeping sc(4) and libvgl ? In-Reply-To: <20220622044714.c1cf644ae8f34d6ea4b863cb@bidouilliste.com> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <5812d9bb3a577fdd76fd58d2dd61a9cd@bsdforge.com> <20220622044714.c1cf644ae8f34d6ea4b863cb@bidouilliste.com> User-Agent: UDNSMS/17.0 Message-ID: <7625cebc70853cb9bb950c704e675df0@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_f47d59e793a49f8a3b28d058fdfae6fb" X-Rspamd-Queue-Id: 4LV0lM28s7z4tb5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_f47d59e793a49f8a3b28d058fdfae6fb Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-06-21 19:47, Emmanuel Vadot wrote: > On Tue, 21 Jun 2022 13:51:17 -0700 > Chris wrote: > >> On 2022-06-21 11:36, Marek Zarychta wrote: >> > W dniu 21.06.2022 o 20:19, Emmanuel Vadot pisze: >> >> Hello, >> >> >> >> On Fri, 26 Nov 2021 16:04:54 +0100 >> >> Emmanuel Vadot wrote: >> >> >> >>> Hello all, >> >>> >> >>> I'm currently re-implementing the framebuffer code in linuxkpi for >> >>> drm-kmod and this made me look at sc(4), vt(4) and friends. >> >>> >> >>> So I looked at what sc could do and vt couldn't and vice-versa. >> >>> >> >>> What sc(4) can't do : >> >>> >> >>> - Work with EFI firmware. >> >>> - Support UTF-8 >> >>> - Maybe other things but everything here is EFI-based so let me know. >> >>> >> >>> What vt(4) can't do : >> >>> >> >>> - You can't get the modes or adapter info with vidcontrol. >> >>> vidcontrol -i mode is really made for anything vesa based as it >> >>> iterates on all the modes and display them if present. >> >>> In the modern world (EFI), we don't have that, EFI GOP doesn't >> >>> support changing resolution after ExitBootService was called so there >> >>> is only one "mode". I could possibly hack some patch so vidcontrol -i >> >>> mode/adapter would work and display the current framebuffer info if >> >>> people wants (but I honestly doubt that vidcontrol is useful at all in >> >>> an EFI world). >> >>> - "Blanking" screen doesn't do what you think it does. For some reason >> >>> in vt(4) we just write black colors on the screen and ignore the blank >> >>> mode passed in the ioctl. >> >>> Now again, blanking/dpms/blah isn't possible with efi_fb but it make >> >>> sense to fix vt(4) and drm-kmod so it calls the drm module blanking >> >>> function, I'll work on that next week. >> >>> - There is no screensaver, again see notes above for dpms but do >> >>> people still use sc(4) just for the screensaver ?? >> >>> - Maybe other things, please let me know. >> >>> >> >>> For libvgl it probably made sense back in the 90s but does it now ?? >> >>> >> >>> Based on my small list I don't see any good reason to keep sc(4) but >> >>> maybe I've missed something bigger so please let me know. >> >>> >> >>> P.S.: I'm really not interested by people saying stuff like >> >>> "I've always used sc(4), it works for me don't touch it" >> >>> without some technical argument. >> >>> >> >>> Cheers, >> >>> >> >>> -- Emmanuel Vadot >> >>> >> >> I've put up in phab removing sc(4) from GENERIC and MINIMAL : >> >> >> >> https://reviews.freebsd.org/D35538 >> >> https://reviews.freebsd.org/D35539 >> >> >> >> If you have any good reason that sc(4) should be included in those >> >> kernel config for amd64 (no other arches was touched) please provide >> >> some argument on the reviews. >> >> >> >> Cheers, >> >> >> > Thanks for heads up. Unfortunately, it will be a great loss. The waste of >> > power >> > resources might increase since vt(4) still doesn't support VESA Display >> > Power >> > Management Signaling which some of the servers are heavily relying on. It's >> > a step >> > backward in terms of green computing and amidst the power crisis, we are >> > heading >> > in Europe. >> My only objection is that I can NOT get textmode or very stable X on any of >> the NVIDIA >> cards I use unless I build against sc. Does sc(4) use so much space that >> current kernels >> become too big with it's presence? I vote against it's removal. >> >> Chris > > I'm sure that other people uses nvidia cards with vt(4), I'm *know* they do. I've assisted others by responding to threads on the mailing lists, pr(1)'s && the FreeBSD forums, in fact I've also talked with Toomas on the OpenIndiana mailing lists regarding this on OI. Not a huge deal. But another obstacle/hurdle in order to obtain reasonable graphics. > did you opened a PR about this ? See above. Thanks for taking the time to respond. Chris --=_f47d59e793a49f8a3b28d058fdfae6fb Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_f47d59e793a49f8a3b28d058fdfae6fb-- From nobody Sun Jun 26 13:43:53 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 336A5875479; Sun, 26 Jun 2022 13:44:31 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWBt645H4z3DTy; Sun, 26 Jun 2022 13:44:30 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-31772f8495fso63445167b3.4; Sun, 26 Jun 2022 06:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Djto04qaQcoQPH7k1Pddpe97hXN5eqekfP9zqnaJ3gg=; b=hitADatZaVgdggDC9CRuyA06CuDi2tFgM7IMLedTwRbvMTlFBUJaIgbnzimqK56jUf /qwRUHnzYkc/WrJr35QU4DcvzZ3vcUL04YrB8jBLD+EZb72Pt3CovHXQ1LtMl74p2skp gUAfaYL2FhteBF9K9PHUjpQHu5tb8vNTUgbprrKYIiRaARmtt+TC33fEoqrLpuweQupq xYMwiYiLUH+kU86F8nG8HBAGnkk6seeAPQ0xoump5cmW5ACFblsfn1jLWysUHdBlkk+2 W3QhkZp0b/oAvNoeRyrEAeU6B3LLlLMS/g4o/VPgAFFKkTNRQ+WZhoTNBFiAMCKZsAhg CfPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Djto04qaQcoQPH7k1Pddpe97hXN5eqekfP9zqnaJ3gg=; b=Rd7bJ8m3aKITLrpXDXlEZyyIcL5VnPW/+kCZTyFVPTfGxCXz4EYXB9m9U1aI1QJWBJ pDo8VURF87Zew7Y8cGwU2RyuNHn5GTgwk3xPwxqHApAIreHb1Qp8CDyBsgnpJzrNP8gh qDVDeD/eapq0wCUQq0sAw3bc+xcDWYquCW8Qgk3YVcmcsYrf3ZdIWf57mtn7OSD/Gi6O KFQC5bFq0Wu0zQmu+ffIqBAPt08g4YFeJRsS4JD1qCShv6NjQtV2EbYm9u+9Hib7S0tP 2hPZ0bAsCQ7wOSsIpUbIpZLlAANYknz6YIvcZuouquj/zFIiVCgGIkUL7FTWKnXDPu+L R1SA== X-Gm-Message-State: AJIora+/J0feS5i1AUVy4gdn++S4ruBLKkjlr3TZCeXEoT9xsPrKNulo Re1V6aCqoqaXvVmAR4JeJ9sc315vr4NJz/AYbLmAda7BxeNaLw== X-Google-Smtp-Source: AGRyM1u1wnyjdgPGiv94CGjPRewaPUBnk90gVOpV/lp2PJ4a5zO2tlnGvAyu6TxlZXRSEsgAzvwojSJVZwKg0nWTISY= X-Received: by 2002:a81:110d:0:b0:317:bb2f:baa6 with SMTP id 13-20020a81110d000000b00317bb2fbaa6mr9201406ywr.397.1656251069417; Sun, 26 Jun 2022 06:44:29 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Sun, 26 Jun 2022 15:43:53 +0200 Message-ID: Subject: how to run bhyve and virtualbox at the same time To: =?UTF-8?Q?Corvin_K=C3=B6hne?= , FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/related; boundary="000000000000a71a3505e25a007c" X-Rspamd-Queue-Id: 4LWBt645H4z3DTy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hitADatZ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-0.999]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1133:from]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000a71a3505e25a007c Content-Type: multipart/alternative; boundary="000000000000a71a3305e25a007b" --000000000000a71a3305e25a007b Content-Type: text/plain; charset="UTF-8" Hello to everyone. Just for educational purposes I've virtualized MacOS Monterey with Virtualbox in FreeBSD : [image: Screenshot_2022-06-26_15-32-51.jpg] Now,the problem is that Virtualbox supports only USB 1.0 speed devices because it does not support the USB 3.0/3.1 plugin/addon and since I use a lot of USB disks and I transfer data between them,I can't have a low level speed like that. So,I've thought of some ideas to overcome the problem. My idea is to use a tool called USB over IP,sharing the USB disks I have from an OS that can mount them to the MacOS that / which can't. At the beginning my idea was to install the server part on a bhyve virtual machine,let's say for example Linux or Windows. ----> But I've soon realized that I can't run both bhyve and VirtualBOX at the same time. So,I'm here to ask you if you know some patch,tricks,wrapper and so on,to be able to do that. If that can't be done,I'm forced to install the USB-IP server on FreeBSD itself and the client on MacOS,but this makes the task more complicated to accomplish. Even though there is no known USB over IP tool which can run natively on FreeBSD. For example I tried this one : www.virtualhere.com I tried to install it with the linuxulator and natively and I've got the same output. Surprisingly it started,but unfortunately it reported another error,telling that it can't find an IP protocol to communicate with the client : mario@marietto:/home/mario# ./vhusbdx86_64 VirtualHere USB Server is running...press CTRL-C to stop setsockopt - IP_PKTINFO: Protocol not available I wanted to explore what could be done to fix this bug and I've opened a bug report here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264835 Later,I've got an email that pointed me here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264865 as you can read,someone replied,telling : Here is an example of use: https://github.com/jacktrip/jacktrip/blob/main/src/UdpDataProtocol.cpp#L297 I don't understand if he is talking about the "bug" that we are talking about at the beginning. I mean this : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264835 because I'm not a programmer so I don't see which correlation there is between the two bug reports. Furthermore I don't have any *UdpDataProtocol.cpp file *on my* FreeBSD 13.1-RELEASE *system. So,I don't know what to do now. -- Mario. --000000000000a71a3305e25a007b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to everyone.

Just for educational purposes I've virtualized MacOS Monterey with Virt= ualbox in=20 FreeBSD :

3D"Scr=

Now,the problem is that Virtualbox supports only USB 1.0 s= peed devices because it does not support the USB 3.0/3.1=20 plugin/addon and since I use a lot of USB disks and I transfer data between= them,I can't have a low level speed like that. So,I've thought of = some ideas to overcome the problem.

My=20 idea is to use a tool called USB over IP,sharing the USB disks I have=20 from an OS that can mount them to the MacOS that / which can't. At the= =20 beginning my idea was to install the server part on a bhyve virtual=20 machine,let's say for example Linux or Windows.

----> But I've soon realized=20 that I can't run both bhyve and VirtualBOX at the same time.
=

So,I'm here to ask you if you know some patch,trick= s,wrapper and so on,to be able to do that.

If= that can't be done,I'm forced to install the USB-IP server on Free= BSD itself and the client on MacOS,but this makes the task more complicated= to accomplish. Even though there is no known USB over IP tool which can ru= n natively on FreeBSD. For example I tried this one :

www.virtualhere.com

I=C2=A0 tried to install it with the linuxulator and natively and I'= ;ve got the same output. Surprisingly it=20 started,but unfortunately it reported another error,telling that it=20 can't find an IP protocol to communicate with the client :

mario@marietto:/home/ma=
rio# ./vhusbdx86_64

VirtualHere USB Server is running...press CTRL-C to stop
setsockopt - IP_PKTINFO: Protocol not available

I wanted to explore what could be done to fix this bug and I've opened = a bug report here :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264835

Later,I've got an email that pointed me here :


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264865

as you can read,someone replied,telling :

=09
=09
Here is an example of use:

https:/= /github.com/jacktrip/jacktrip/blob/main/src/UdpDataProtocol.cpp#L297
=09

I don't understand if he is talking about the "bug" that we a= re talking about at the beginning. I mean this :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264835
because I'm not a programmer so I don't see which correlation there= is=20 between the two bug reports.

Furthermore I do= n't have any UdpDataProtocol.cpp file on my FreeBSD 13.1-RELE= ASE system. So,I don't know what to do now.

--
Mari= o.
--000000000000a71a3305e25a007b-- --000000000000a71a3505e25a007c Content-Type: image/jpeg; name="Screenshot_2022-06-26_15-32-51.jpg" Content-Disposition: inline; filename="Screenshot_2022-06-26_15-32-51.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_l4vcpu6t0 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAQ4B4ADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0CprR FlvII3GVaRVI9QTWDr897B/Zf2OS7TzNQiSb7NaifMZzuD5I2J0y45HpzVjwRPe3OmaXNqEl2900 vztd2otpT+8IG6MEheMY55GD3oA3pJ7RJGT7BGdpIz5j/wCNN+1Wn/QPj/7+P/jVef8A4+Jf98/z rkNV8aSaV4ttdGl0W6NrPJDF9u3ALvl3BMLjkZRhnI+6/B28gHb/AGq0/wCgfH/38f8Axo+1Wn/Q Pj/7+P8A41TrhfE/xO0/wzr50qSzluGRUaWRHACbucY78YP40AejfarT/oHx/wDfx/8AGj7Vaf8A QPj/AO/j/wCNUBNEYll8xfLYAhs8EHpSCeEyiISp5hG4JuGSPXFAGh9qtP8AoHx/9/H/AMaPtVp/ 0D4/+/j/AONUTLGH2F1DYztzzUEt5GtjNdQskyxozfK2QSBnGRQBq/arT/oHx/8Afx/8aPtVp/0D 4/8Av4/+NedaX47v9Y8Gza3ZaIJbmO58gWqz9RhSW3Ee/TFdhaXLS6bBdXKC3d4leRGbiMkAkZ9u lAGr9qtP+gfH/wB/H/xo+1Wn/QPj/wC/j/41QimimTfFKkif3lYEUyO6t5pCkVxE7jqquCRQBpfa rT/oHx/9/H/xo+1Wn/QPj/7+P/jXJ694v0/w9qmmWF1HM8uoSeWhi2kIcqMtkjA+YfrTvEet3+lW 1tLpemDUjLJscLME2DHXPOaAOq+1Wn/QPj/7+P8A40farT/oHx/9/H/xqhLNFAm+WRI0/vOwApVd HQOjKyEZDA5BoAvfarT/AKB8f/fx/wDGj7Vaf9A+P/v4/wDjWc11bqgdp4gpO0EuME+lPeRIkLyO qIOrMcAUAXvtVp/0D4/+/j/41z2k6jNqF/rgkCrHbagYIUUcIgiiOM9TyzHJ9fTArRininXdDKki +qMCP0rC8OOsd34ld2CouqMWZjgAeRDyaAOntEWW8gjcZVpFUj1BNWJJ7RJGT7BGdpIz5j/41U0q 4gub22e3mjlQTKC0bBhnI44qnq99JZ3DCK2M7He5UPggKRkgdT17dgaaVxN2NX7Vaf8AQPj/AO/j /wCNH2q0/wCgfH/38f8AxrnDq179ljul0mUwuGYPuOMDGD93oc/ocZq5ZXUt1vMlv5QXj7+fmycr 0HIwM4yMnHUGhq3X8UCaZr/arT/oHx/9/H/xo+1Wn/QPj/7+P/jWZeXcVhZT3c2fKhQu+0ZOAMms qDxVYSy26Sw3lqLghYZLi3ZEcnoA3TmkM6j7Vaf9A+P/AL+P/jR9qtP+gfH/AN/H/wAap0UAXPtV p/0D4/8Av4/+NH2q0/6B8f8A38f/ABrNu7qGxtJbq4bZDEpd2wTgD2FSRussayIcqwDA+xoAvfar T/oHx/8Afx/8aPtVp/0D4/8Av4/+NU6hu5za2ks4hkmMalvLiXLNjsB3NAGl9qtP+gfH/wB/H/xo +1Wn/QPj/wC/j/41RjfzI1fay7gDtYcj2NOoAufarT/oHx/9/H/xo+1Wn/QPj/7+P/jVOigC59qt P+gfH/38f/Gj7Vaf9A+P/v4/+NU6RjtUtgnAzgdTQBd+1Wn/AED4/wDv4/8AjR9qtP8AoHx/9/H/ AMazLO4N3ZxXBglgMi7vKlXa6+xHrU9AFz7Vaf8AQPj/AO/j/wCNH2q0/wCgfH/38f8AxqnRQBc+ 1Wn/AED4/wDv4/8AjR9qtP8AoHx/9/H/AMap0UAXPtVp/wBA+P8A7+P/AI1ieHr6TVdc1WKdVEMO qC3ijXgLH5cRxnqeWY5J7+mAL9Y/gv8A5D2tf9hsf+ioaAOmkntEkZPsEZ2kjPmP/jTftVp/0D4/ +/j/AONVLuRIppWdlVQxJLMFA59T9arfb7T/AJ+rb/v+n+NAGp9qtP8AoHx/9/H/AMaPtVp/0D4/ +/j/AONUI5ElUMjKykZBVgwP4j6U+gC59qtP+gfH/wB/H/xo+1Wn/QPj/wC/j/41TooAufarT/oH x/8Afx/8aPtVp/0D4/8Av4/+NZd9eR6fYzXkyuY4VLuEGTgdeKlhmjngjnjYNHIodW9QRkGgC/8A arT/AKB8f/fx/wDGj7Vaf9A+P/v4/wDjWBY63DqRt2tbe4eCcOVnKYQbTjk+/OPXFadAFz7Vaf8A QPj/AO/j/wCNH2q0/wCgfH/38f8AxrLs723v4nktn3okjRk4IwynBHPvVigC59qtP+gfH/38f/Gj 7Vaf9A+P/v4/+NU6rahepp2n3F7KrMkEZkYL1IA7UAav2q0/6B8f/fx/8aPtVp/0D4/+/j/41zt7 4gtrFrRGgupZbtC8ccEW9sAAngfWpdO1u01OaWCITRXEQDPBPEY3APQ4PagDd+1Wn/QPj/7+P/jR 9qtP+gfH/wB/H/xqnRQBc+1Wn/QPj/7+P/jR9qtP+gfH/wB/H/xqnRQBc+1Wn/QPj/7+P/jR9qtP +gfH/wB/H/xqnRQBc+1Wn/QPj/7+P/jR9qtP+gfH/wB/H/xqnRQBQ8PX0mq65qsU6qIYdUFvFGvA WPy4jjPU8sxyT39MAbsk9okjJ9gjO0kZ8x/8a5nwX/yHta/7DY/9FQ1s3cmy5cBSzM5AA/Gmk27I TaSuy39qtP8AoHx/9/H/AMaPtVp/0D4/+/j/AONZvnN/zzH/AH8X/GnxybywKlWU4INVKnKKu0JT i3ZF/wC1Wn/QPj/7+P8A40farT/oHx/9/H/xqkzKiM7sFVRkknAArBPi2xKNOltfyWak5u0tmMWB 1OepHvioKOr+1Wn/AED4/wDv4/8AjR9qtP8AoHx/9/H/AMaz4ZormBJoZFkikUMrqcgg96koAufa rT/oHx/9/H/xo+1Wn/QPj/7+P/jVOigC59qtP+gfH/38f/Gj7Vaf9A+P/v4/+NY6ajE+rzaaEfzY oVmLcbSGJGPrxVygC59qtP8AoHx/9/H/AMaPtVp/0D4/+/j/AONUZH8uJ32s20E4UZJ+lQaffwan YQ3tsxaGVdykjB/GgDV+1Wn/AED4/wDv4/8AjR9qtP8AoHx/9/H/AMa5ufxLYW9le3bea0NnP5Ej KmcvkDA9eSKuDU7U6R/agk/0XyfO3f7OM/n7UAbH2q0/6B8f/fx/8aPtVp/0D4/+/j/41jaVqlvr Fgl5a7/KYlRvXByDg8U5NRgfVZdN+YXEcQlwRwyk4yPXnigDX+1Wn/QPj/7+P/jR9qtP+gfH/wB/ H/xrHu9Tgs7u1tXDtPclvLRFyTtGST7VLZ3Bu7OK4MEsBkXd5Uq7XX2I9aANP7Vaf9A+P/v4/wDj R9qtP+gfH/38f/Gsu5vbe0lt45n2vcSeXEME7mwTj24BqxQBc+1Wn/QPj/7+P/jR9qtP+gfH/wB/ H/xqnRQBc+1Wn/QPj/7+P/jXGXet3jaT4xu4mWF9PkmW0CqCIgtujDrnPzEnnPX0wK6euHn/AORb +IH/AF1uf/SWOgDprPwrq11Z29wfGmpIZY1faNPtjjIBx9znr6c8f3lzMPB2qnH/ABW2pc46afbH 09F56/yx95c6UF/9h0nS1ZE2yW6As7FQOEH90jo5PP6gnflS+M7garDaQ6VHPBKpZrkXJCoB97IK H1Yc9Se+W3ADx4O1U4/4rbUucdNPtj6ei89f5Y+8uQeDtVOP+K21LnHTT7Y+novPX+WPvLm/oHiN ddur238hI5LURl9kvmA793HIz2PY/e7kkPo6rqVvpGk3WpXZY29tE0sm0ZO0DJ9c9ff73fP7wA58 eDtVOP8AittS5x00+2Pp6Lz1/lj7y5B4O1U4/wCK21LnHTT7Y+novPX+WPvLnHi+NXg+Rl8yS+ij c482S1O38cZPc+vU9ed/QeIPGNpomnWF8llealBfMBGbJBJwRkMcnod3v97uCTIAVx4O1U4/4rbU ucdNPtj6ei89f5Y+8uQeDtVOP+K21LnHTT7Y+novPX+WPvLnrOvvn8c5/PPX3+933fvGsyhSzEbc ZJJ4x+vr79e+794AcqPB2qnH/Fbalzjpp9sfT0Xnr/LH3lyDwdqpx/xW2pc46afbH09F56/yx95c 49x8aPCcVzLEn2+4jjOGuIrfMffuTnHPoep687+606/t9W022v7Vme3uo1ljLKQSrDIyDk/xdOfv d8/vADnR4O1U4/4rbUucdNPtj6ei89f5Y+8uQeDtVOP+K21LnHTT7Y+novPX+WPvLnrOvvn8c5/P PX3+933fvDr75/HOfzz19/vd937wA5MeDtVOP+K21LnHTT7Y+novPX+WPvLkHg7VTj/ittS5x00+ 2Pp6Lz1/lj7y56zr75/HOfzz19/vd937zkfEPxI8P+Gdbj0nU5J0nkRX3LHuQKxIBJyff14JPzZO 8AcPB2qnH/Fbalzjpp9sfT0Xnr/LH3lyDwdqpx/xW2pc46afbH09F56/yx95c3vFHi7SfCOnRXuq yP5U0nloI13sxIJ6Z5GOp5+93z+8u6FrVp4j0a31Wx8w21zuKeYuGOGKnI5759evfP7wAxB4O1U4 /wCK21LnHTT7Y+novPX+WPvLkHg7VTj/AIrbUucdNPtj6ei89f5Y+8ues6++fxzn889ff73fd+8O vvn8c5/PPX3+933fvADkx4O1U4/4rbUucdNPtj6ei89f5Y+8uQeDtVOP+K21LnHTT7Y+novPX+WP vLnq2YBSx5GMnvn+eevvnd33fvMjw94n0nxXZSXmj3LXECSGJ2aJk+bAOMMMn749epHJJ8wAyx4O 1U4/4rbUucdNPtj6ei89f5Y+8uQeDtVOP+K21LnHTT7Y+novPX+WPvLnrOvvn8c5/PPX3+933fvD r75/HOfzz19/vd937wA5MeDtVOP+K21LnHTT7Y+novPX+WPvLkHg7VTj/ittS5x00+2Pp6Lz1/lj 7y56zr75/HOfzz19/vd937w6++fxzn889ff73fd+8AMJrFtPtbWB7uW7k8rc9xKEDSHc3OEAUcYH HYd+pZWhqxzLAc5zF1znPzN7n+Z+tZ9ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRSOyojOxwqjJPtQAtFVDqVoIEmMp8txlTs b+WKmguYbqPfBIrr6g9KfK7XsJST0TJaKKKQwopGZURnc4VRkmsqbWJA2IgiDtkBj+tdFDDTrax2 MKuIhS0e5rUVlnVmttQks70IDHIY2kTgAg4/KtTpU1qEqTXN1KpVY1FoFFFFYmoUVXvrv7FZS3At 57gxoWENum+STAJIVe5wCfwqWGaO4hjmhkSSKRQ6OjAqykZBBHUGgB9FFFAFe6L7oESRo98m0soB ONrHuD6Cj7PL/wA/s/5J/wDE0XH+vtP+up/9AasKbxReT6neWei6JLqK2T+VcTG4SFBJjJVd33iM 80Abv2eX/n9n/JP/AImj7PL/AM/s/wCSf/E0ywu5bqwiuLq0eylYkNBKykqQSOoODnGRj1q0WUEA kAnoCetAEH2eX/n9n/JP/iaPs8v/AD+z/kn/AMTUklxDEpaSaNADglmAwfSpOtAFf7PL/wA/s/5J /wDE0fZ5f+f2f8k/+Jqjq2qajZzxwadok2oOy7mcTJFGnsWbv7AUzQfEC6ybyCW0lsr6ycR3NtKQ xQkZUhhwQR0NAGj9nl/5/Z/yT/4mj7PL/wA/s/5J/wDE1z8Piu+1Fmn0fw/PfacrlBd/aEi8zBwS ityw9+M11FAFf7PL/wA/s/5J/wDE0fZ5f+f2f8k/+Jqnp+tx6hq+raesLI2nPGjOW4fcu7I9K0t6 bN+5dmM7s8UAQ/Z5f+f2f8k/+Jo+zy/8/s/5J/8AE1M0iL951HGeT29aSOWOZA8Tq6HoynINAEX2 eX/n9n/JP/iaPs8v/P7P+Sf/ABNWKx9f1ufRLZZYdJur/wCV3cwlVWNVAJLFiMdeOvQ0AaH2eX/n 9n/JP/iaPs8v/P7P+Sf/ABNR6TqC6to9nqKRmNbqFJghOSoYZx+tc/o3izVtbtrW8tvC8/2K4IxO byLhc4J25zxzxQB0n2eX/n9n/JP/AImj7PL/AM/s/wCSf/E1YrB1HWNbtbuZLPw1Ld28X/LYXcaF +Mnap5PpzigDW+zy/wDP7P8Akn/xNH2eX/n9n/JP/iay4fEi3/hu31jStPur37QcR267VcHJB3En AwQQTmobDxNcPrUOk6tpEum3VwjSWxMyypKF+8Ay9CBzigDpniEVvbfMzs0ZZmbGSd7Dtx0AqOrF x/qLT/rkf/Q2qszBVLMQAOpNAC0UwTRNKYllQyAZKBhkD1xRHNFKWEciOUOGCsDg+hoAfRUZuIRM ITNGJT0TcN35U5pET7zqOM8nHFADqKoteTtqVrFBBHLZSxuz3ImHykYwAvU555HTFWnnhSVY3lRZ H+6pYAn6CgCSis251u0tdctdKl3Ca4ieVXyNqhcZB5zk54pI9es5Ncn0kMRNDAk5ckbCGJAAOevF AGnRUck8MJUSyohY4UMwGT7VJQAUUVQ1i/n07TZLi1tBd3AZEjt/M2eYzMABuwcdT2xwScAEiZTj FXk7AX6KRSSOVKsCQynqpHBB9weKWqAKKx/FM97beHLubT5LtLpdmxrS1FzKPnUHbGSA3Gc88DJ7 UaBPez/2p9sku38vUJUh+0WogxGMbQmCd6dcOeT6cUAU/F/kf8SHz/sn/IYt/L+0+b9/5sbPL/j9 N3y+tWPhn5H/AAjejfZvsnk+a237J5vlf65s7fN+fr1z3zjjFSa/Bez/ANl/Y0u38vUInm+zXQgx GM7i+Qd6dMoOT61Y8EQXttpmlw6gl2l0svzrd3QuZR+8JG6RQA3GMccDA7UAXtSuPskV5c+TLN5I eTyoV3O+MnCjuT0ArKv9Gj1f4ODxBfxwRazHZDWori1UgJLGjSRcMTn5SFIOQefYjYu41kuWJz8k hYY/Ef1rNurHUbsIj65eC3ilMsVoqRrBkZ2hwF3uATkgvgkZGMDHPKVXnaUE0ldO/Xttp6miUbLX X9CnoHiOLVfBttr9wPJQ27ST8YClMhyBk/LlTjnpivD4NSttWtPEt3qGnajPfaoc20sEAdIiG3AF sg4yFHAPAr6Dv9OtdT0+awvIzJbTLtkQOV3D0ypBpul6XZaLp0Vhp8AgtYs7EDFsZJJ5JJPJNbQc nFOSsyHa+h47e63/AGx8DFSRsz2VxHbSZ64U/Kf++SB+Bqn4k0rSNI8E+Hde0u7cazIYi0wnLMx2 EnjPG0gDjp0Nd14t8AwHwvf2vhrTgt3eTxySp55AbaxOfnbA6npir2kfDvw/BHp19daTGNRhhi80 byU80KMkqDtJyP61Qji9ctrbVvi/pttq7mGG4s0E6iQx7iY2OzI5AJ4/HFO0GKHRfiN4j0bRpGbS vsUjNGHLqjBFPX1DEr+OK6HWPBlzrPxPj1C909LjRGtTFKzSL12MBxnd1I5FdPo3hDQ9AguIdOsR ELhdsrF2ZmHpknIH0oA8ctf+SF3v/YUH8krU15hqOteCtE1O4eHRZNOt3cb9quxUjk/go9s+9elr 4J8PJoT6Kun4055fOaHzpOX453bs9h3qfUvCmiavplvp99YJLb2yBIAWYNGAAAAwOegHfnHNAHO6 rpnhfwb4T1yS1sy9tNFGtxaxXDEtklV5JJXO48+3FeX6/C+m6VpGuWOj2ejmZxJbPb3jySsMZ5BP 0598Gva9O8E+HtL0y706208fZbwAXCSSM+/HTqeMZ7Yqinwx8ILbmA6QGQuHy08m7Iz33ZxyeKAO M+KGk6c3i7w5dTRbf7RmCXbFyAyKY19eMAnkYo+Jek6ZovhjRLPSUCWgvmYASF+SOeSTXpus+HNI 8QW0VvqtklzHEcx5ZlK/Qgg1Sk8D+HJdJtdLfTs2drIZIY/Pk+VjyTndk9e5oA4TVba38SfGaXSd fdm0+3gH2a3aQorHYp4wR1JY8emO1M8Gt/Z/ijxbounTPJo0NvK8a79yo4IAAP0LD3216Hr3hDQ/ ErI+qWKzSxjasqsUYD0yCMj2NTaT4Z0fQ7CWy06ySCGYYlwSWfjHLE57nvxQB4roXhmw1D4V6xrF z5r3VrK/2f8AeELHgIThehJzzn0Fb0+k6r4p+H3hJ7d4ruSAuZLGefy/tKq20c5GcBcdf4q9ItfC eiWWh3Gi29ls0+4JMsPmudxIAPzE5HQdDVe78C+HL3SbTTJ9PzaWe77OomcGPccnndk5PrmgDlfh /caba+K9Q0r/AIR06NqqW4MqJcmaNlBU9ycH5h0JrqfD7bLjxO29I9upud7/AHV/cRcnkcfjVjQf COh+Gnkk0uyEUso2vIzs7EdcZJOB9Ki8M/8AH94k/wCwq3/omGgDf0Ofz7q3b7Vb3OJ1G+AYUcjj 7x5/HvVDWTbjXbH7RJLGnmvho8DDZGCTkYGe4/rWxYf8hC2/66r/ADFUdRs/tN+shfaI2foDu5I+ 6c/KeMZ68nGDzTTte3Z/kJq5jbtrQXRW8NwhmlmiWFVaQAKrsRuwDlUOFJPGR1GNHSuLIRDeUhdo lZ1CkhWI6ZPAxjnk45FJJpMMk0LBnSOINhEdlOTjowPAG0YAx0HbirMNslu8hjJVHO7y/wCFT3I9 M9cdP1rnpwlF6/1/wPyKKHib/kV9U/69ZP8A0E1hrZaxruk6ZZzWdvaWaeTI83n+Y7qoBG0BRgn6 11N9Zx6hYXFnKWWOeMxsUOCARjin28C21rFboSUiQIpbrgDHNbiOasrIeIb3Vp725ugLe7e1gjhn aMRBAPmAUjJOc85qjHLqmqaFp0sgubyCCaWK7S2l8uScKSqtnIz05Gea37nw8kl5Pc2t/eWTXOPP W3ZQHOMZ5BwcdxT20KOKztbWwvLqxS2UqggYYbOM7gwIJzz+JoAwbz+zrnwbrMVob6MwIzSQXMkg eJtuQDuOcHrjJBq9Lb2Gk+Ho9zX5+1eUgSK5dpHc9FUlvlzznBHFaNvoFrDa3sM0k1y18MXMszfM 4xtxwABgdMVCfDULWH2SXUL+VVZHhd5F3QMnQqQo/XNAGTpzXOneKLK1W0u7S2u4pd0NxdCcEqAQ w+YkHseec1u+JJHi8NalJG7I627lWU4IOOxqK38OxRanb6lPe3dzdwhlDysuCGGMYAAGOenrzmtG /s49RsLizmZljnQxsUOCAfTNAHOXcc19reiWpu7iKCSyd5likKmTG3jI/n16+tWtERrHxBqmmJNK 9rHHFNEsshcxlsggE844rTGlQC+tLvfJ5lrC0KDIwVOOvHXgU+LToYdUuNQVnM08aRsCRtAXOMce 9AFbX7i3t9MIuDc4lkSJEtWKySMTwoIIxn6jjNYWnNc6d4osrVbS7tLa7il3Q3F0JwSoBDD5iQex 55zXSappkOq2ggmeSMq6yRyRNhkcdGB9ap2/h2KLU7fUp727ubuEMoeVlwQwxjAAAxz09ec0AZOh 2LXlneX93d3UskV1P5C+ewWMKx7A8/jnjFS+GbAtoFpqlzdXU941uSGeZiqgg4AXOOnfrmt2y0uC ws5bWJpCksjyMWIzlyScce9OsdPisNLi0+JnMUUflqWI3Y9+KAOWtrq4tfD/AId1h7iVo4ysd1uc kMkny7m9cHBq899PJqmt6jE7Nb6ZbNDFHk7XlC72JHqPlFaiaJaLoH9jEyPa+SYcsRux65xjP4U/ TNIttK037DEXljJZnaYhmkLHJLHHPWgDl57OS08Ipr8eoXR1MQpctM07FXzglCmdu3nGMV2kT+bC kmMblDY9M1hL4SthGlq97eyacjhlsmcGPg5AJxuKg9ia6CgAoqlBpqQRXsYublhdSPIS75Me4Ywn HAHao30hJNLgsDd3YWEoRKJP3jbT3OOc96ANGsfwX/yHta/7DY/9FQ1sVj+C/wDkPa1/2Gx/6Kho AseJTi2uP97/ANnWuWvZI5cTI0aE4BiXO4e54A/L1ruL23SeeQOARubggEHn0IPpVT+y7T/njF/3 5j/+JoAreHznS4v90/8AobVevLk2lq84gmn24/dwruc5OOBkU6G3SAEIAB6AAAfgAB3qWgCrYXhv rcym1ubbDFdlwgVvrgE8UXFrLNe2k6XUkUcJYvEvSXIwM/TrVqqtxYrcXtpdGaZDbFiERsK+4Y+Y d8dqALEkaSxPHIoZHBVge4PWuHW/n0/wxeaCrE38Nx/Z8GerLJ9xv++Cf++a7qsqbw9YzeIItabz PtMSbQoI2E4IDEY6gE96AKKw/wBneIdE06B3FvHZyrsBwG27ACR6/wCNVvDum/2jFcXl7dXcrJeT LCnnuqoocjoDz36+1dDLp0M2qW+oMziWCN41AI2kNjOePajTtOh0y3eGFnZXleUlyCcscnoOnNAH M+G9Ngi0q+u0e4E0c9yq/wCkOV4LD7ucE++M0+4upx8LxcieQT/YkPm7zuzxznrmtq10KGyvpbiC 6ulildpHtS4MRZupwRn361nv4NtZLF9PfUL82BzstxIu2PnPB25OOwORQAutyW9xc2libe+vLkxG X7PbXBiXbkDc53L34HPrWOtxcjw/4p0+cTKlrH+7SeUSugaPO3cCcj0+tdPfaIl3dw3cN3cWl1FG YhLCVyyE52kEEHnmoIfC9lDbalAJ7pxqChZ3dwWzgjIOOpyTQBk6gLw674bFi0Cz/ZJcGdSy42rn gEGp9O+1QeM5Bqxie9ns8QSW+RGI1bJXaeQcnOcmtO+8PQ3stlKLy8tpbNGjjeB1BwQAc5U+lO0/ QbewvXvWuLq7u2Ty/OuZNzKuc4GAAB+FAGBYWb6z4cm1ue+u0vpPNkidJ2VYNpIChQcY45yPWpLz U7mPQNJ8RrK32rYiyW2Ttud3VQo/izyDitKXwrA/nxRX17BZ3DF5bWJwEYnqBkZAPcA1e/sa1N9a 3R34tI/Lt4cjy4+24DGc4460AVfDPmT6YNSmuvtE16fNbaxKRjsijtjoffNbVUrHS4NOmunt3kWO 4k8wwkjYjdyoxkZ780++sVvlgDTTxeTMsw8p9u4r/CfVT3FAFqiqrWKtqcd9504ZIjH5Qf8AdnJz kj196LWxW1uLqZZp5DcOHKyPlU4xhR2FAFqiiigDH8F/8h7Wv+w2P/RUNat8QL0EjI3yZH/ATWV4 L/5D2tf9hsf+ioa172LzbhiHKMshIIwfUd6unJRldkzTcbIz/Os4YvJIBEq7g552bvX6YX9atQY8 2UAggbeR3+UU37K//Pb/AMhJ/hUsUXlbiXLsxyScDtjtXRVqxlGyZjTpyUrsxfGhlXwfqRhzu8sA 4/u7hu/TNa9qsAsYUgC/Z/LUIB0244/SpZI0mieORQ6OCrKwyCD1BrBHhSNITaxapqMViePsyyja B/dDEbgPbNch0HPQSTx+AsWc7wr/AGjstpEPRDNgY9utdDf2tjo2lSK8uoSG5kSP5Lh2llcngAk8 Z74wMVoXGi2c+mQ6eqtDbwsjIsRAxsIIHOfSn6ppkOq2ggmeSMq6yRyRNhkcdGB9aAOb05rnTvFF laraXdpbXcUu6G4uhOCVAIYfMSD2PPOal0PT18Q6YNWv7m7NxcO5QRXDxiABioVQpA7d607fw7FF qdvqU97d3N3CGUPKy4IYYxgAAY56evOaafDixzTNZalfWUMzl5IYGXbuPUrlSVz7UAUri4ay8Tax cou5oNKWQA9ypc/0rGhS/uNHivre11t9WkjWVbozL5TMecbfMxs7Y29K7RdMgGpzX5LtJNCsDqxB XaCT0x15NZ8fhkW6eRa6tqNvaZOII5Fwg9FYqWA/GgDaiZ3hRnXa5UFl9D6VyMeojwwNes2+7D/p dmvqJDjaPYPx+NdiBgYrK1Pw9Y6tqFne3PmebaNlQhAD8ggNxyMigDB1TTjpXw/htX5mEkLzE9S7 SKW/U1GyMLw+Etp8przz+nH2X/WEf99fLXV6ppsOrWJtJ2kWMsr5jIByrAjqD6Va2J5nmbV34xux zj0zQBgeDP8AkAH/AK+Zv/RhpPEX/Ev1DTNcXhYJfs9yf+mUnGT9GwfxrW0zTYdKs/s0DSMm9pMu QTliSegHrUl/ZQ6jYT2dwCYpkKNjqM9x70AYNmTqXiLVtT6xWcZsrc/7Q+aQ/XOBmsxZLu60DwrG t7cRPcShZZUkO5hsbPPrXVaZpNvpWlrp9uZDEobLOQWYkkkk4681DFoFrDbaZAskxXTm3REsMscE fNxz17YoAxNb0Szhu9DhRrnY94VObmQnlGJ53ZB4611VrbR2lukERcomcb3Lnrnkkkmq+p6XDqsM SSySxPDIJYpYW2ujDIyDz6mmrpWJLGR768ke0LkFnH73cMfOAADjt0oA0KKqxWKxajPeiadmmVVM bPlFx3Udie9FhYrp8DxLNPMGkaTdM+4jJzge3pQBarh5/wDkW/iB/wBdbn/0ljruK4ef/kW/iB/1 1uf/AEljoAk8f6nqGlaT4aksL65s2e2dXa3laMkbYjgkY9c/jnHO5uZ1PxHfpYw2808st8Is3U0j s7ZzwCSc5C7QfevSdU8JDxNpugy/axbtZwZVWg8wOWVcZGQeCFOO+ehJBfBi+ELreG4bxAZS+Qyt aZDhuoOH75HTPXjPy7n0ERfBlzKNbZmLMxhLZ5yf3g/rjp3xzna3YfEA/wDFvtfOf+XKQ5z7fX39 e/U5zJW8E+CF8HC+C6gbwXZQ8xbNu3djuwOQ4/PuCA+/q+lwa3o93ply8iwXcRidomw2G9Dzz83v 97vn94mM+dY7PxXcfBbzEl04+HIpC7R8/aOJeeSMD5m7HPP+1hui8Ya0Y/hd4Mn0K5vLO3dxDhZi rHapVgxXGec9u/QZy3Vx/BLw8LdLZtW12W1BB+ztdJ5ZPXoE9+397jPy79/W/h3oeu6Lpmkv9otb PTmDW6WrqPwO4Nnr78tnkkGQA4jW5NQ8YfGeXwxPq99p+m2cAkVLOYxvKSitnPOSS55+bjONxOWj 8DSX1x8R/Fmialrl3qFpFaSwmSWYnjeq7scgNhiCR1JP3s4bT+JGi6fdeJbW8l8N+I7qbyAft2hn LMdxGxhg9iPm6neOvVq3ww8F3kOq65q9/pkum2V/Cba3tJGJk8tiMk5ywOMdeTu75AYAzItO8ffC zR7ptPOmanoMTNO5ZRkKQAWIyD0I4BYc9w3zHjnxbPqngfwhq+mvNpkd1cukkNvKVA2nay5HUZ3d ex5HJLdLJ8FdGkjFsuta4tiSCbQXKmP2AG0+vv8Ae4z8u/oNZ+Huha14VtPDzRywWdoVNu0DfOhH uc5zuOev3sjJILgHLeOtTu4Pi34Psre+nSKVkM0EcpCuDIR8yjIOeeoOcn72ctiQ2mseKfi94k0V fEOo2WnoheRYJmJK5QBU6hcl+ozkEj5t3PY2Pwk0O01bTtUN/qtxe2ThxLNOr+aQQRuyp47YHqOv G/b0zwZp2l+LtR8SQTXT3moIUlSRlaMAlT8oC57DqWzu/iyN4Bgz+KtV8MXcPh628Ka1rFvaRxQr qKIzLNlFyxIQgn58HkjJ75O7jPH+iR+JPjZZ6RIwH2rTWVGPOH8uVkPXn5gD3z/tZyfdOvvn8c5/ PPX3+933fvOcuPBmnXfje18WPPd/b7eIxJGrr5TAqy8jaSeJD3Ocj72R5gB4VNJqnjLRbuTVoysX hXS2gIJ+/OWKgn3wBn3XuW56O48R6h4d/Z90J9MmaGe6me3My/eRS8rHB7E4x9GPTOW9i1fQrPWt HvdMmDRQ3q7ZngwrtnvnB5568/e75/eZkfgTRf8AhCovCk6zXOnRj5GlceYCWLBgVGAQX4wO/fP7 wA8t8T2up/DeHw/rmneItTvZbtx9qguZ/MSf5Qxwvodx65+8OcEFtTxN/auq/HC10O21u/sbW4tB 5n2eYj5djk7RkjLDIzgn5sjceW6PTPhFollqNnd3d/qeqLZY+ywXkweOPkEYUDpnBwOORw3y796T wZp03jeHxY010b+OIxLGHXyiCpXkbSScN6nOR97I8wA828JWt/J4p8X+CZ9c1OWxjh3xXHnnzkw6 8q3IBYPg4654znDV/gh4aXULB9YOp6jCbW+K/ZYZsQS/Iv31wd33sd+o46BvUdM8F6dpni3UfEkE 1095qClJUkZWjAJU/KAuew6ls7v4sjfmaJ8MNG8P66up6Ze6pCokMn2NbgG3YkYwV2kkYbjJPUfe 43gHWrqFlLHLIl5bukX+tYSqQnX7xycdT1z175/eI+pWK2y3L3tsIJCVWUyrtY85AOSD39ep65/e czp3w40fTtM1ywhub94taObgtIpZc5+4QvH3z13dR1yPMiu/hhot74M0/wALSXWofYbKYzRSJKnm MxLHk7SMfvDjA7jGcjzADtAdwyPmB/HOfzz973zu77v3i9ffP45z+eevv97vu/eMjQJGqDJAAAzz n+eevv8Ae77v3j+vvn8c5/PPX3+933fvADP1Y5lgOc5i65zn5m9z/M/Ws+tDVjmWA5zmLrnOfmb3 P8z9az6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACmyKrRsrfdIIP0p1FHoBzsEjwFILqBpoY2YpLsyCOvOazrHQ3/teHVb+ZFRr jbFEp2Kr4JCgd8cf1612MkaSxtG6gowwRVKTTnub62uLu7edLUfuI2UDB/vMR95uBz7Cs5yrKSce u/b8Xp8upxSoTTiou6RfooorQ7Slq7+Xp+edvmLux6c//WqldzTGLU2ZkNsEBgwQRt8xcbfbHX9a 1p4UuIHhkGUcYNctcaFqtt9ojtBHcRTpsJ3BTjcG6EjByo9a9TB1YcnI3Zo8/FUpc/MldM09euZT LrjXUsTWZY/ZMOpBfzBjZjvt3Z/HNalmWNjbF/vmJN312iuX0zwpN9oWbUSgjU58pTuLfXtiuurL GThyqnB3sa4aEruclYKKKK4DrKun+JtJsL6/N/LNahVESzXVpNFCCNxY+aybApO0A7vmIGM/Kay9 Fv45tZ1eGKC9SCWYXUDS2U0MYDIgdRvVcN5gdyO/mZyx3Y3qK5oYWMa8q93dqxXNpYKKKK6SSvcf 6+0/66n/ANAauduvCt7FqV3qPh7XZNOkun8yeB4VmheQcE4PKk45wa6K4/19p/11P/oDVj3fgvRL y6muWhuI5J2LTeRdyxrIT1yFYCgDmL7XLjW/BMFxfJElxa6zDbztET5bFJlBZc9jxW54kkQeMvCM e4bzcXDBe+BCef1FbP8Awj+kjQzoosYhpxXaYBkDGc9euc85655qpZeENFsbu3u47aR7q3JMU81x JI65BXGWY8YJ46c0AYOkaBpmr+KfFMupWkV3tu0REmXcqZiXJAPAJ4568CtP4fs3/CJQws7MtvPP AhY5IRZGCj8BgfhW9a6daWVxd3FvFslu5BJO24newAGeTxwB0o0/TrTS7Y21lF5URdpNu4t8zEsT kk9yaAKmva7Bodojsjz3U7eXa2sf3539B7ep7CsvT9CvrPRdZu7uRZNa1SNpJjH91CEKpGvso4z3 rR1fwto+u3cN1qFq8s8KlI3SeSMqD1HysKl0nQNO0Pzv7Pilj87bv8y4klzjOPvscdT0oA870uzu 7P4XQeILfX76K6tbYyRRrLi3AQ4EZj6HOMEnnJ/CvT7GdrrT7a4dNjyxK7J/dJAOKx5PBPh+W8a4 eyJDS+c0HnP5LP13GPO0n8K27h5YrWV4IfOlVCUi3bd7AcLntk8ZoA47SgT4g8dADJLRYH/bCs68 ljX4EIxdQDp0aA575Ax+ddJ4X0u/tbjVtT1SOKG71KdZDBE+8RIqhVBbAyaa3gLw26yxvYM0EhJ8 g3EnloT1Kruwp9xigDN1rTbbVfHXh+3vI/NtxYzu0R+6+CmAw7jODj2FWPDtpBpXjfX9PsYlgszB bziCMYRHIYEqOgzgdPSukbTLR9Qgv2hzdW8bRRPuPyq2MjGcHoOtINNt4r651CCMJe3EaxvKSSCF zt4zjjJ6UAWkdJFDIysp7qciqOvf8i7qf/XpL/6AaZ4e0aLw/oVrpkTmQQr80hGN7Eks2O2SScUu saDp2vRRxajDJKkedoSd4+vXOxhn8aAK3g7/AJErRP8Arxh/9AFctrehN4F8M/2lo+t6kpsSm22u Z98MoLAFNmMAnJ6V1ml+F9H0a3ngsbZ44p0EciNPJICoBGBuY46npiqlv4F8P29zDOLWWUwMGhSe 5klSMjoQrMRQBpXNhbXmoabezSSRz2pdoYxJgMWXBBHfAqDXtL1LU4Quna5NpmFYN5cKPuJ6Ek8j HsR1q5c6XZ3l/Z308O+5si5t33EbCww3AODkeuay73wVol/dTTzw3Aadi0yR3cqJIT1yobFAFLwd q1jb+ALe8mSCxtLQSJIVYmP5XILAnk7jz3OT3p2j213r+txeJr+F7a3hjaPTbVxhwrfelf0ZgAAO wrWvfDWj3+jR6RcWSnT4ipSCNmjC46fdINQaf4Q0XS76O8tLedZ487S95M4GQQflZyDwT1FAHSXH +otP+uR/9DauY8cf8iPrX/XpJ/KunuP9Raf9cj/6G1Z99ZW+pWM9ldx+ZbzoUkTcRuU9Rkc0Aef6 54b06x0jw5NZwm3vJr62glu4iVmkWUbX3P1OQf8ACtQ6XY6D8QNFTS7WK0jvLS4jnSFdquE2FSQO pyTz1rqLrSrK8htYbiHfHayxzQjcw2un3Twece9Om060uNRtr+WLddWqusL7iNofG7jODnA60AeZ arbxat4X1TXrHQNHtLQ+dNHeSysLsurN84KrwSw4G72rWubSHxB4l8J/2kvnRy6XJNLGfuyHEZww 7jJzj2rfk8D+H5XnMlk7RTFmeD7RIItzdWCbtoPPUDjqK049GsIbmzuI4MS2cBt4G3t8kZxkdefu jk88UAYFxa29l4+8P21rBHBAlldBI41CqvKHgDpXK6Fpd34h0K4vLnw5p1/eXcsolvLi+KzRuGIA A8smPbgYAPYHvXp0mnWk2pQahJFm6gRo45Nx+VWxuGM4OcDrWXdeDtFu7ya6ME8Ms53TfZrmSFZT 6sEYAn3oA5gaFHN4p8NW+v2lpd3h02ZblnQSCV02AEkjkgfzNWoPD2iy/EbULeXSbF4k06B0jaBS oO5hkDHoAPwFdJeeGNHv7W0trizzHZrttykro0YwBgMpDdAO/am3nhXRr57eS4tXMtvEIY5UuJEf YOillYFh9SaAOe0TR9N8Ran4luNatIby5TUJLVROu7yYVA2bc/dzknIxWl8Pria58H2xlleZY5JY opXOS8auwU578DH4Vd1Hwlo+qXkl3cQSrNKoSZoJ3i85R0DhSN341rWtrBZWsVtbRJFBEoVI0GAo HYUALcO8dtK8cbSyKhKomMsccAZIGT7kCsnWtUOp2Hhx/DS7NRTXtqw3KGMxyeROV85X+YJtIJ43 FD8uCQTtVka1ojajtuLK8aw1GPb5d0i7sbTuXcuRuweRzwcjlWdW5a+H9pOFRPWL/r5/16UnZWNF 8/2rdkLGcXE4LFzuUea/Rcd8dc9vapqYkSrySWfLEu3LEscsc+55p9dRJzfj3yP+EK1D7T9k8n93 u+1+b5X+sXG7yvn69Md8Z4zR4Q8j/ifeR9k/5DFx5n2bzfv/AC53+Z/H67fl9KueKYL258OXcOnp dvdNs2LaXQtpT86k7ZCCF4znjkZHejQIL2D+1PtiXaeZqErw/aboT5jONpTAGxOuEPI9eaANinR3 H2WRbgRSTeUQ/lx43PjnA3EDJ6ckD3FfHtFAH1FJr2tvIz/8IjfDcScfa7b/AOOU3+3Nb/6FK+/8 C7b/AOOV8v0UAfUH9ua3/wBClff+Bdt/8co/tzW/+hSvv/Au2/8AjlfL9FAH1B/bmt/9Clff+Bdt /wDHKP7c1v8A6FK+/wDAu2/+OV8v0UAfUH9ua3/0KV9/4F23/wAco/tzW/8AoUr7/wAC7b/45Xy/ RQB9Qf25rf8A0KV9/wCBdt/8co/tzW/+hSvv/Au2/wDjlfL9FAH1B/bmt/8AQpX3/gXbf/HKP7c1 v/oUr7/wLtv/AI5Xy/RQB9Qf25rf/QpX3/gXbf8Axyj+3Nb/AOhSvv8AwLtv/jlfL9FAH1B/bmt/ 9Clff+Bdt/8AHKP7c1v/AKFK+/8AAu2/+OV8v0UAfUH9ua3/ANClff8AgXbf/HKP7c1v/oUr7/wL tv8A45Xy/RQB9Qf25rf/AEKV9/4F23/xyneGLe9i/ta4vrKSza7vzOkUjozBfKjXkoSOqnvXy7RQ B9hR3H2WRbgRSTeUQ/lx43PjnA3EDJ6ckD3Fc/Jr2tvIz/8ACI3w3EnH2u2/+OV8u0UAfUH9ua3/ ANClff8AgXbf/HKP7c1v/oUr7/wLtv8A45Xy/RQB9Qf25rf/AEKV9/4F23/xyj+3Nb/6FK+/8C7b /wCOV8v0UAfUH9ua3/0KV9/4F23/AMco/tzW/wDoUr7/AMC7b/45Xy/RQB9Qf25rf/QpX3/gXbf/ AByj+3Nb/wChSvv/AALtv/jlfL9FAH1B/bmt/wDQpX3/AIF23/xyj+3Nb/6FK+/8C7b/AOOV8v0U AfUH9ua3/wBClff+Bdt/8co/tzW/+hSvv/Au2/8AjlfL9FAH1B/bmt/9Clff+Bdt/wDHKP7c1v8A 6FK+/wDAu2/+OV8v0UAfUH9ua3/0KV9/4F23/wAco/tzW/8AoUr7/wAC7b/45Xy/RQB9Qf25rf8A 0KV9/wCBdt/8co/tzW/+hSvv/Au2/wDjlfL9FAH1B/bmt/8AQpX3/gXbf/HKP7c1v/oUr7/wLtv/ AI5Xy/RQB9Qf25rf/QpX3/gXbf8Axyj+3Nb/AOhSvv8AwLtv/jlfL9FAH1B/bmt/9Clff+Bdt/8A HKk8Ki9sJNU1G902eF5tQN1HbeZG0jKI4xgENtyShAyR74r5booA+opNe1t5Gf8A4RG+G4k4+123 /wAcpv8Abmt/9Clff+Bdt/8AHK+X6KAPqD+3Nb/6FK+/8C7b/wCOUf25rf8A0KV9/wCBdt/8cr5f ooA+oP7c1v8A6FK+/wDAu2/+OUf25rf/AEKV9/4F23/xyvl+igD6g/tzW/8AoUr7/wAC7b/45R/b mt/9Clff+Bdt/wDHK+X6KAPqD+3Nb/6FK+/8C7b/AOOUf25rf/QpX3/gXbf/AByvl+igD6g/tzW/ +hSvv/Au2/8AjlH9ua3/ANClff8AgXbf/HK+X6KAPqD+3Nb/AOhSvv8AwLtv/jlH9ua3/wBClff+ Bdt/8cr5fooA+oP7c1v/AKFK+/8AAu2/+OUf25rf/QpX3/gXbf8Axyvl+igD6g/tzW/+hSvv/Au2 /wDjlH9ua3/0KV9/4F23/wAcr5fooA+oP7c1v/oUr7/wLtv/AI5R/bmt/wDQpX3/AIF23/xyvl+i gD6g/tzW/wDoUr7/AMC7b/45R/bmt/8AQpX3/gXbf/HK+X6KAPqD+3Nb/wChSvv/AALtv/jlH9ua 3/0KV9/4F23/AMcr5fooA+pPCovbCTVNRvdNnhebUDdR23mRtIyiOMYBDbckoQMke+KbJr2tvIz/ APCI3w3EnH2u2/8AjlfLtFAH1B/bmt/9Clff+Bdt/wDHKP7c1v8A6FK+/wDAu2/+OV8v0UAfUH9u a3/0KV9/4F23/wAco/tzW/8AoUr7/wAC7b/45Xy/RQB9Qf25rf8A0KV9/wCBdt/8co/tzW/+hSvv /Au2/wDjlfL9FAH1B/bmt/8AQpX3/gXbf/HKP7c1v/oUr7/wLtv/AI5Xy/RQB9Qf25rf/QpX3/gX bf8Axyj+3Nb/AOhSvv8AwLtv/jlfL9FAH1B/bmt/9Clff+Bdt/8AHKP7c1v/AKFK+/8AAu2/+OV8 v0UAfUH9ua3/ANClff8AgXbf/HKP7c1v/oUr7/wLtv8A45Xy/RQB9Qf25rf/AEKV9/4F23/xyj+3 Nb/6FK+/8C7b/wCOV8v0UAfUH9ua3/0KV9/4F23/AMco/tzW/wDoUr7/AMC7b/45Xy/RQB9Qf25r f/QpX3/gXbf/AByj+3Nb/wChSvv/AALtv/jlfL9FAH1B/bmt/wDQpX3/AIF23/xyj+3Nb/6FK+/8 C7b/AOOV8v0UAfUH9ua3/wBClff+Bdt/8cqnZaTqN/oXie3uLX7BPqss3krcSKwUPAkYLGMtxuB6 ZOB0r5rooA+1rRrO1s4Lb7ZGwijWPPlsM4GOm3/e/Pvlt032m0PW6jPr8r/j1Hu3X15zlt3xHRQB 9ufabQ9bqM+vyv8Aj1Hu3X15zltx9ptD1uoz6/K/49R7t19ec5bd8R0UAfbn2m0PW6jPr8r/AI9R 7t19ec5bcfabQ9bqM+vyv+PUe7dfXnOW3fEdFAH259ptD1uoz6/K/wCPUe7dfXnOW3H2m0PW6jPr 8r/j1Hu3X15zlt3xHRQB9ufabQ9bqM+vyv8Aj1Hu3X15zltx9ptD1uoz6/K/49R7t19ec5bd8R0U Afbn2m0PW6jPr8r/AI9R7t19ec5bcfabQ9bqM+vyv+PUe7dfXnOW3fEdFAH259ptD1uoz6/K/wCP Ue7dfXnOW3H2m0PW6jPr8r/j1Hu3X15zlt3xHRQB9ufabQ9bqM+vyv8Aj1Hu3X15zltx9ptD1uoz 6/K/49R7t19ec5bd8R0UAfbn2m0PW6jPr8r/AI9R7t19ec5bcfabQ9bqM+vyv+PUe7dfXnOW3fEd FAH259ptD1uoz6/K/wCPUe7dfXnOW3H2m0PW6jPr8r/j1Hu3X15zlt3xHRQB9ufabQ9bqM+vyv8A j1Hu3X15zltx9ptD1uoz6/K/49R7t19ec5bd8R0UAfbn2m0PW6jPr8r/AI9R7t19ec5bcfabQ9bq M+vyv+PUe7dfXnOW3fEdFAH2bqU0c0sRjkEm2PDMAeu4nvz3qlXx/RQB9gUV8f0UAfYFFfH9FAH2 BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYF FfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV 8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx /RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH2BRXx/RQB9gUV8f0UAfYFFfH9 FAH2BRXx/RQB9gUV8f0UAfYFFfH9FAH18bfz5oSZY4xG5cl88/KRgYB9atfZ4v8An8g/J/8A4mvj eigD7I+zxf8AP5B+T/8AxNH2eL/n8g/J/wD4mvjeigD7I+zxf8/kH5P/APE0fZ4v+fyD8n/+Jr43 ooA+yPs8X/P5B+T/APxNH2eL/n8g/J//AImvjeigD7I+zxf8/kH5P/8AE0fZ4v8An8g/J/8A4mvj eigD7I+zxf8AP5B+T/8AxNH2eL/n8g/J/wD4mvjeigD7I+zxf8/kH5P/APE0fZ4v+fyD8n/+Jr43 ooA+yPs8X/P5B+T/APxNH2eL/n8g/J//AImvjeigD7I+zxf8/kH5P/8AE0fZ4v8An8g/J/8A4mvj eigD7I+zxf8AP5B+T/8AxNH2eL/n8g/J/wD4mvjeigD7I+zxf8/kH5P/APE0fZ4v+fyD8n/+Jr43 ooA+yLoptgRJFk2R7SVBAzuY9wPUVXr4/ooA+wKK+P6KAPsCivj+igD7Aor4/ooA+wKK+P6KAPsC ivj+igD7Aor4/ooA+wKK+P6KAPsCivj+igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigC7pukX2ryyR2Nu8xjXe5HRV9TUrQ6Xan5rprxsZXyVKp9G3AH8q774MRpLqeoo6hlKxgg/ SSvTtU8CeGdXST7To8HmmIxxyRFojH1+YBSATk5+YHp0oA+doNYjgk2x2FmkJHzK0CykE/xAvk/h nH5121lp/h/xLatm1tILqFCcWwMYcZHzLjGR04PI74JAOpr/AMGEUtJoNzPtWPiG6dZGd8n+MBAB jH8J78+nGTeG/E/hNprm60q6FrBtL3cSFoomOMfOPlz8wBB659cEAG1qHwj1JLY3WmXMN1AITJnf gsRn5RkDnjvXFX+g6rpjst3Yyx7V3FgNyge5GRXsfg/xb9oMKpB87oDLDHn94M4DoCfwx6jb15rv XtNN1m1EskEU8cq/eK8kemetAHydRX0Lrvwp0fWpQ9pFNBMWyRCSSQBjAGD9a8Z8T+Gl8OTQxG9j neUFxGuMqueCcH2P5UAYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQB2/wALLiaLxfHHHK6JIF3qpwG+ZRz+BP519DSyxwxtJK6o i9WY4Ar5f8H3lxZeJ7OS3k2MzYJwDx17+4Fe2ePE1DyVf7QgsgRiJchieOT68moqT5IuVr2M61T2 cHO17HR3WtrbI8osL2aFRuMsSqVx+LA/pViz1axvoDcWt2pjRhlwxQqe3oRVLw5f3N1pVvFd2c8M 8S7Hd0Kh+pVhxjGMDj056jPDzvPZ6/IsFtPbWd3cJ8k0JTI3hhgEDHSs51uRKXRmU6/IlPdM7jUf Denatdi9mVvtRkWU3KEeYxAA+/1IIAB56cVA8KeHoi0d7cO8zMRAYlK8Ec792QcHrt56ds10Fcdr E4n1OYqSVQ7OfUcH9c1udJHc6ld3JkDXEoifAaMNhSAcjIGAce9eN+Pb2O88SFY1cG3iEL7gOWBJ 49vmFepXtyLOxuLoqWEMTSFQcZwM4/SvCp5mnnkldmZnYkljk0AR0UUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAE9lNJb30EsTlHV xhh2r6R8SWUt94TSVGZ5IoUcjBYt93Jz+BNfM4JBBBwR0Ir6U8A6zb33hyygfUEnvFhj3q0u5wdg 6+/BqZRUouL6kzipxcX1Oh065hubCB4XDqYxyPy/mDRvtNQil2MrhNyGQL9098EiqN1o06Q3K6Xd /ZDLhlQD5VfuRjpkbc8fwj0FcdpMPiK4+06GjmCKIlrknbuUFsdepySBx6+maiVTkai1uZTq+zai 03fsdloWo/arLDk4iLxmRmBzsbGeg7Y9eh5545fzGmJlf78hLt9Tyf51001vBomg+RHGDlDFkdSW ySSep5z+g4AAHM1pG9lfc1jflXNuc742vVtPDFygmMc0+2OMDq3zDcP++c15DXe/Em8bz7Ox2jYF 87d3zkjH6VwVMoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAK9h8JfDHwlqfw/0/xHruq6jZtcGUSGOWJIk2yFBy68 Z479a8er28/8mx2X+/L/AOlYrSjD2lSMH1aQnohP+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX /CtyHxJouswLpkCTh3j5jls4kUgKMgOJM8BSR8uTz3Ncxqup2GnaZHpWnRI7gENMygkknls/kB9B T9zs/v8A+ABb/wCFd/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K5H4beFLHxh4iudPv2uxFF ZSXCi1ZVdmUqAMlW659K19T8B2Wnf8IhdLaXtvNq96IZtH1SbbIAJAvLqisqsD125G4YzXqSy+hG fI5u/wDT/QjnZr/8K7+FP/Q33n/gda/4Uf8ACu/hT/0N95/4HWv+FcrqPga5uNe8SmBLHStN0eXE 7y3EkkUOThUVtm9yT0+WpbT4a3EfjPw/oWq6laRR6xALlJ7Zy4VCGIGSANx24GMjJHWj+z8Pa7m9 r/hf8g532Ol/4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wrkfGfhVPDcQVtD1vT5fPKLLe TRzQyqAfusiKA3Q4yeM064+Ges22v6voz3VgbnSrA6hOyyPsaMAHCnZkt8w6gD3prLqDSfP+Qc77 HWf8K7+FP/Q33n/gda/4Uf8ACu/hT/0N95/4HWv+FcNqvgm70bSdO1C81HTx/aVql1aW6NI0sgbH y4CYB5HUgehNWvC3ge7v/G+k6J4hsNS02C+Z+XhMLsFQtld646gdj1pvLaCi5c7sr/gHOzr/APhX fwp/6G+8/wDA61/wo/4V38Kf+hvvP/A61/wqXT/g5pk/jG4huL+7Hhto4zZXSMolmkkJAjyVxkFX zxxgdM1xUngO5aTUroXlrY6Tbai+nxXV/Iw8yQMcKNikk4GScAdfQ1nDA4aTspvp07/qHM+x2H/C u/hT/wBDfef+B1r/AIUf8K7+FP8A0N95/wCB1r/hXIp8NdcWfXoruWysm0NY3uzcStgq+SrIVU7h gZ9ewBPFbXh/4WJP4hfT9c1OJIZNKOo2ktm7ETIejAmM/KO4IB5GM1UsBh4pv2gcz7Gp/wAK7+FP /Q33n/gda/4Uf8K7+FP/AEN95/4HWv8AhXEWvge5u7KXUV1bTI9LW5W1jv5WlSOaVhnagMe/juSo HB5wM1PB8N9bebXorqWysX0MRtefaZWA2vkhlKqcjAz68jGTxVPLaC3qBzvsdh/wrv4U/wDQ33n/ AIHWv+FH/Cu/hT/0N95/4HWv+FcNY+Crq+sJdSGpadBpa3QtI72dpFjnlIyFQbN/TuVAHfoafd+A NasrTXZrgW6S6I8a3dtvJkCv911AGCvOc5/Cj+zKF7e0DnfY7b/hXfwp/wChvvP/AAOtf8KP+Fd/ Cn/ob7z/AMDrX/CvOfEvhm88K6hBY6hLbtcyW6XDRwsSYtwyFfIGGx1AyORzW9qulaVp/wAKfD2p xaZC2palLcJNdvJLuURyYXaocJ04OVP580PLKVotSb5vT+ugc7Oo/wCFd/Cn/ob7z/wOtf8ACj/h Xfwp/wChvvP/AAOtf8KXUvhf4di1nU9GtZ9Uhns9H/tMXk88bxE/3GURqR9d3rxxXC2/gbU7mw8O XiT2gj1+5a2tQXbKMr7CX+XgZ9M8VEMBh5q/O/6Vw5mdz/wrv4U/9Dfef+B1r/hR/wAK7+FP/Q33 n/gda/4VyTfDjUorPUry51LS7a207UTps8kskmPMGOQAhJXke/tgZpz/AAx1uC7163urnT7Y6GkU l08srbSkgJVkIU54GccHtgniq/s7D/8APz+v6aDnfY6v/hXfwp/6G+8/8DrX/Cj/AIV38Kf+hvvP /A61/wAKxdI+H1xZ6zd2mo2dhqkcmhyalbSLeSxRlONsilU3Fhz8jAA55PSsnTPh3qOp6To2pDUd Mt4dXna3tFnkcO0gYrtICHGSOD06ZIzS/s/D/wA7/r/hg532Ow/4V38Kf+hvvP8AwOtf8KP+Fd/C n/ob7z/wOtf8K4tfh/q6Wt9c3s9lYQ2l6dPL3MpAluB/Am1Tn6nA9+tael+EF0L4p2nhXxDaWWoi aWKKXZLKFUPhtylSh3YOOcjk8U3l1BJ2m3bUOdnQ/wDCu/hT/wBDfef+B1r/AIUf8K7+FP8A0N95 /wCB1r/hXmniGyis/FWq2NpEVhhvZoYYwSxChyFHPJ4AqHUtF1XRmjXVNMvLFpASguoGiLAdcbgM 1osppO3vvUXtGeo/8K7+FP8A0N95/wCB1r/hR/wrv4U/9Dfef+B1r/hXI6P4V08eBrrxbrUt01qt 0LS3tbRlR5ZMZJLsrBQBn+E9DWjP8NP7Tl8NS+HbzNrr6S+SL84aCSMEurMi8jg4IXt0FZPL6Cdn N/d2Vx87N3/hXfwp/wChvvP/AAOtf8KP+Fd/Cn/ob7z/AMDrX/CvOp9At7XVGsLjX9LjZA3mS4nd EcHGwlYiSe+VBXjrWi3w81x9a0rTbMW96dVh8+0nt5D5UkYyS2WAIxjkEA1byuit5tBzs7T/AIV3 8Kf+hvvP/A61/wAKP+Fd/Cn/AKG+8/8AA61/wrm/BfhLTbv4kaTo+oXdjq1lcNMswtJpAMpGxwTh W6gHI4PYnms238FXd9Bd6l9pstO0tL42cU95IwV5MnCLtVieO5GPfg1P9m0E7Ob6dO9/8g52dt/w rv4U/wDQ33n/AIHWv+FH/Cu/hT/0N95/4HWv+FeX61o194e1i50rUofKu7dtrrnI5GQQe4IIP413 Mvw3tb7XPCCaJNdSaXr8IkaSVlZ4WXmZchQPlHTjrmnLLaEUm5uz/wCHDnZr/wDCu/hT/wBDfef+ B1r/AIUf8K7+FP8A0N95/wCB1r/hTNJ+GXhvxBpviCfTtQv1lttQksdMMsqFJ3WMFd/yD7zZxjHB Hfrnar8NrHR/he+u3dxdrr0XkvNa7lEcSyt8qsNu7dtwSM8E9KyWCw7fLzu90tu4czNT/hXfwp/6 G+8/8DrX/Cj/AIV38Kf+hvvP/A61/wAK43wH4YsPF17qOlzzTxaj9jebThGyhJJVGdjAgk5HPBHQ 1paP4LsF8L6Jq2pLNJqGq6xHaWdk03lRSRBwrlyFLAZyuV5GQcGtJ5dRg3Fyd/8AP/hg52dB/wAK 7+FP/Q33n/gda/4Uf8K7+FP/AEN95/4HWv8AhXM3ngG6vtb8VGzOnaZaaJKPPikuZHWNWJACOUy+ Np6gE9gTxUlh4G0e68AajrsniG3W4tr1bdJQJvICnH3l8nfk9RgY5GcHNL+z6Fr876dO4c7Oi/4V 38Kf+hvvP/A61/wo/wCFd/Cn/ob7z/wOtf8ACuRtvhtrF1rOg6XHc2An1qxF9bM0j7UjKF8P8uQ2 AegI96oaH4SbxBcRWdnrOmLqMrMsdlL5yyMRnjd5eznGR81V/ZtC1+d/1/wwc77He/8ACu/hT/0N 95/4HWv+FH/Cu/hT/wBDfef+B1r/AIVy6eHLGL4Tajq9xZldYttaFn5hdsomwErtzt655xmux1T4 RaNa3eoW0S61b29rpZvl1W4kRrcyD/lmQI1578Nn2rOWBw8XZyf4dLf5hzMrf8K7+FP/AEN95/4H Wv8AhR/wrv4U/wDQ33n/AIHWv+FcVpfgDVNSsNNu2urCzGqSNFp8d1IyvdMpwdoVSBzgZYgZI9RU ulfDXX9Z+0x2YtmvLS8FndWZkIlgJOPMYYxsyDyCenStHluHV71Ng532Ow/4V38Kf+hvvP8AwOtf 8KP+Fd/Cn/ob7z/wOtf8K8r1OxGm6ncWQure68hyhmtmLRuR12kgEj3xVStFk9Nq6kxe0Z6//wAK 7+FP/Q33n/gda/4Uf8K7+FP/AEN95/4HWv8AhXkFFP8AsaH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI KKP7Gh/Mw9oz1/8A4V38Kf8Aob7z/wADrX/Cj/hXfwp/6G+8/wDA61/wryCij+xofzMPaM9f/wCF d/Cn/ob7z/wOtf8ACj/hXfwp/wChvvP/AAOtf8K8goo/saH8zD2jPX/+Fd/Cn/ob7z/wOtf8KP8A hXfwp/6G+8/8DrX/AAryCij+xofzMPaM9f8A+Fd/Cn/ob7z/AMDrX/Cj/hXfwp/6G+8/8DrX/CvI K9b+C2m6bfWXiKW/0yxvWha1Ef2u2SXZu83ONwOM4HT0FY4jLKdCm6jk3Yam27En/Cu/hT/0N95/ 4HWv+FH/AArv4U/9Dfef+B1r/hXpH9jaB/0LOg/+C2H/AOJrm7i00myuPGl+vh7Q5G07TLaa3hk0 6IxK2Lhj8oA6lRk9Tgc8CvM/cef4F6nN/wDCu/hT/wBDfef+B1r/AIUf8K7+FP8A0N95/wCB1r/h V/UbTxLpmmXd/N4X+HLRW0LzOE0xixVVJOMjrxUJ03TLj4+aXYtpOnLYmycm1S0jWJiIZmyUAwTk A5IJ4HoKunChN212b6dFcTuVv+Fd/Cn/AKG+8/8AA61/wo/4V38Kf+hvvP8AwOtf8K6fWNR8P6Bf mLUvBOki2lUCynttLjmNxL/zxKhPkkP8OSQwzyMEVyHxRghj8J6PL/wj+laPdy3OZorKGMFfkbCm RVUn3A4z64BopwoVJqCvq7dAd0cL8RPDemeFvE403SpLuS3+zpIXumUuWJOfugADgev9BydegfGP /keR/wBekf8ANq8/rlKCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKntby4sZ1mtpmjkXOCv0xSQWtxc7vs9vLLt+95 aFsfXFS/2VqP/Phdf9+W/wAKdmQ6kE7Nno3h34w3djDHbaraLcIv/LVGIbAUADBz3Gc/pXqmi6xo +vyNfae4eXaYmYcEqCpwcHB5CmvmX+ytR/58Lr/vy3+FT2lvrVjN5trb30LkYJSNxkdcHHbgUcr7 C9rT7o+jPE058y3t1fszso/AA/8AoVc5cXMNpbvPcSLHEgyzscAVwf8Awmvid7TZcabcT3IQoLh4 myOSQcY5xnvXL6h/b2qTeZewX0pBJUNG21c9cDGB0HSjlfYPaw/mX3kvi3VU1bX55YZTJbpiOIkc YA5x7E5P41h1b/srUf8Anwuv+/Lf4Uf2VqP/AD4XX/flv8KOV9g9rD+ZfeVKKKKRoFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAV7ef+TY7L/fl/wDSsV4hX018N7G21L4SeHLO8gjnt5ZbhXjkQMp/fnseOvNaUZ+zqRm+jTE9 UeXQXA0+ye5Vv9ImDRx46onRm+p+6Pbd7VQusoltcKSwkGGB6qw6g/ofx+tfRv8Awrzwr/0BbH/w Fi/+Jo/4V54V/wCgLY/+AsX/AMTT9y97v7v+CGp82+BvFq+DdZuL97A3qz2klqYxN5RAYjnO1vT0 71pH4gQwaboGl2GkSR2GkaiuoAXF35ssrBs7d4RQo5PRfQ17xD4L8E3DRLDp+kytKjSRhIYWLqpA ZhheQCQCe2R61Y/4V54V/wCgLY/+AsX/AMTXqyzKhKXM4O/qRyM8NsfGLa7eeK7aeytBY69Is8lt PqK2zRsrblKTOu04OMgjnjHel+IPiHQrvxJoUcMUeo2WmaXHaTJbTsiFwG4STBJCkqQcHOK9x/4V 54V/6Atj/wCAsX/xNH/CvPCv/QFsf/AWL/4mpWYUVPmUX9/lb8g5GfPGuePH1PwjF4atre7WzW5+ 0mS+vftUuQMBFbYoVR1xitm4+K8NzqGranJ4f/4mGqaW2nXEovPkGVA3quzjoMgk9ByOc+3f8K88 K/8AQFsf/AWL/wCJo/4V54V/6Atj/wCAsX/xNN4/DWt7N/f3/wCGDlfc+avEvitvENroMK2htW0m wjsw4l3GQr/H0G36c/WptC8d6rpvizTde1S5vNYawLlIrq7YnDKVIDNu29c9O1fRc3gPwfbhDNpW mxh3CKXt4RuY8ADK8k+lEvgPwfB5fnaVpsfmOETfbwjcx6AZXk8dKv8AtOhy8nJpr+O4cj7nz7pf xG1Ww1jT55i9xpljfSXsOnlwoVn3Z+fbn+M9c9TxzT/+E9gvNMvNK1fRzd6dNqbanDHHdeU8UjE5 UttIZcEjoDyeR2+g/wDhXnhX/oC2P/gLF/8AE0f8K88K/wDQFsf/AAFi/wDial5jh27+zf3hyPue B3/xOu9UXxWbzT42k16OCIGOXatssWcADB3ZB9RU9t8Umt9W0e8/scNHYaMNIkiNzzMuMFw235T0 4wa91/4V54V/6Atj/wCAsX/xNH/CvPCv/QFsf/AWL/4mp+v4a1vZv7/K35ByvueAaT8RG0jQ7jQr W31ODTTc/abdrXUzBcxNtwVMqx4dT1xsH8qrx+PZRp/ie1mtZrhtcigi86e8eR4RHnBJYEuTn1GO 3HA+g5/Afg+2j8yfStNij3Ku6S3hUZJAAyV6kkAe5qT/AIV54V/6Atj/AOAsX/xNV/aOHu3yPXzD kfc+evD3xCu9E8MyaA63otTcfaYptPvmtJ0bGCu8KwZT6EdfwxtfD7xN5vj+71TVruCPSbi2aC/G o33mM8Wz5QPMO6RsqOAD1PABr2v/AIV54V/6Atj/AOAsX/xNH/CvPCv/AEBbH/wFi/8AiameYUJK VoNXDkZ8v+K9ck8SeKtS1h8/6VOzID1VBwg/BQB+Fb+q6rpWofCnw9pkWpwrqWmy3DzWjxy7mEkm V2sEKdOTlh+fFfQP/CvPCv8A0BbH/wABYv8A4mj/AIV54V/6Atj/AOAsX/xNW8zpWilFrl227WDk Z4refGO51DW5ZbzSmuNEuLIWk+kS3ZaNiP8AlorbflbODkL2+hGZpPxDttP0vQbK50Nrr+wr17qz cXezhn3lXGw5OehGOg4PQ++/8K88K/8AQFsf/AWL/wCJo/4V54V/6Atj/wCAsX/xNQsdhkrKm/vD lfc+e9Y8f/2toOs6Z/Znlf2lrDap5nn7vLyAPLxtGen3sj6Vf1r4pf2vL4qf+xvK/t6C3hx9q3eR 5QPP3Buzn2x717r/AMK88K/9AWx/8BYv/iaP+FeeFf8AoC2P/gLF/wDE0/7Qw/8Az7f3+n+SDkfc 8Lh+KXlT2sn9jZ8jw9/YmPtX3un737nHT7v61m2njz7LpPhOw/s3d/wj9815v8/Hn5k37cbfl9M8 /Svob/hXnhX/AKAtj/4Cxf8AxNH/AArzwr/0BbH/AMBYv/iaFmGHX/Lt/f6/5sOR9zxe28WJ4tt9 RsdQtNPSyn1f+0o0udUW2a2ZuDksv71ME5C4br04qXVPE+hal8dR4i/tWGDSrWaFxPJHK3mhFVSE CIxznOM4GB1r2P8A4V54V/6Atj/4Cxf/ABNMm8BeELeCSefSdOihjUu8j20SqqgZJJK8ACo+vUU2 1FrRr77f5D5WfL3iG9ivPFWq31pKWhmvZpoZACpKlyVPPI4IqHUta1XWWjbVNTvL5owQhup2lKg9 cbicV9Ur8PfCjKGXRrAgjIItYuf/AB2l/wCFeeFf+gLY/wDgLF/8TXQs2pK3uPQn2bPm7R/F62fh e78Nanp5v9KnmFwqpN5MsMowNyPtYcgdCprZtPie9jr3h25t9JVNL0FJEtrAXB3MXQqzPJt5Yk5+ 7j25r3j/AIV54V/6Atj/AOAsX/xNH/CvPCv/AEBbH/wFi/8AiazlmOHle8Hr599B8j7nzh4X8Yjw 5rOpagdPE/26GSIFJvLlg3nO6OTadrD1xW/P8Xb46v4e1G2sGE2kQyQMbq6ac3SvgHcxAOcDrzz7 cV7h/wAK88K/9AWx/wDAWL/4mj/hXnhX/oC2P/gLF/8AE0pZhh5S5pU3f1+Qcj7nzponi3TPDnjK w17S9CkSO1aRmtpL3eXLoVwH2DCjPHyk+pPa3pHxIu9N0S60d471LWW8a8ik0+/a1njZuq7wpDKf Qjrz6Y98m8B+D7cIZtK02MO4RS9vCNzE4AGV5JPapP8AhXnhX/oC2P8A4Cxf/E05Zjh5fFBv59v+ HDkfc+VtZ1SXWdVmvpmmZ5MDM87zPgAAZdiSTx/gAOK7Dwv8Ubrw14PudCXTluJj5ps7wzbWtPMX B2jac85PUcmvef8AhXnhX/oC2P8A4Cxf/E0f8K88K/8AQFsf/AWL/wCJpzzOhOKhKDsg5Gup84aX 41n0nwXNoNrbslw+ox38d6suDGyBcDbt55XOc/hU9x8QL7UPDGuaXqUTXd5q11FcyXpkC7Sm0AbA uOigcEY9K+iP+FeeFf8AoC2P/gLF/wDE0f8ACvPCv/QFsf8AwFi/+Jo/tKhe/s9b3/r7g5H3Plnw /rVx4d8QWOr2wzLaTLIFzjeB1Un0IyPxrqfEnxIbX/FuiaxHpS2dppMiSRWKTZBIk3sd20YLYA6d u9e+/wDCvPCv/QFsf/AWL/4mj/hXnhX/AKAtj/4Cxf8AxNEszoSlzuDvsHI+58+z/ELzh4xH9l4/ 4SRkb/j4z9n2sW/u/P19qo6P4rt7HwhqPhq/06S6tLydLgSQXIheN1HqUYEcDjFfSH/CvPCv/QFs f/AWL/4mj/hXnhX/AKAtj/4Cxf8AxNL+0qCVuR9Ovbb8g5H3PD9J+KkOn33h7ULjQPtN9otkbGOR bzy1ePaVB27DhgD1yRyeOmDw/wDFdtCstIt00mUf2dJI7C2vjBHdBzn96oQ7iOxJx7V7h/wrzwr/ ANAWx/8AAWL/AOJo/wCFeeFf+gLY/wDgLF/8TUPHYZ7039/r/mw5X3PnS/8AG/23wtq2if2ds/tD V21PzvOz5eRjZt28/XI+ldHP8XLdvET+Ibfw/LHqZsfsS+bfh4AvqYxECT7FsV7R/wAK88K/9AWx /wDAWL/4mj/hXnhX/oC2P/gLF/8AE1Tx+Ge9N/f3/wCGDlfc+ftM+IMdvp+gW+paOL2bQJml0+VL kxYJYNiQbTuAIB4K9B75saP8UrnRrnUNRh0qCTVtSvPPvbqR8q8OcmBU2/KD65J/Svef+FeeFf8A oC2P/gLF/wDE0f8ACvPCv/QFsf8AwFi/+JoeYYd3vTevn8/zDlfc+U9VubO71W5uLCyNlayuWjtj L5nlA/whsDI9OOnr1qnX1x/wrzwr/wBAWx/8BYv/AImj/hXnhX/oC2P/AICxf/E1ss4ppW5WL2bP keivrj/hXnhX/oC2P/gLF/8AE0f8K88K/wDQFsf/AAFi/wDiaf8AbMP5WHs2fI9FfXH/AArzwr/0 BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeF f+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bM P5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArz wr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+ FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wAT R/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/ AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8A iaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX /wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9F fXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wF i/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/ +AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2 fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBb H/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+ gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5 WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/ AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+Fe eFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/ bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/Cv PCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/ia P+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/ 8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfX H/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8AgLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBY v/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI9FfXH/CvPCv/AEBbH/wFi/8AiaP+FeeFf+gLY/8A gLF/8TR/bMP5WHs2fI9FfXH/AArzwr/0BbH/AMBYv/iaP+FeeFf+gLY/+AsX/wATR/bMP5WHs2fI 9ej/AAw8YaN4V07XI9Vnkje7e28lUiZ8hPN3HgYGNy/n9a9x/wCFeeFf+gLY/wDgLF/8TR/wrzwr /wBAWx/8BYv/AImscRmdOvTdNxauNQadzx7SvHsVpqUU+oeNrm/tVzvtv7EWLfkED5hyMHB/Crc3 j3wxdr4rikv54o9Wsre1hcWrsQQJw5IwOm9e/Ofrj1b/AIV54V/6Atj/AOAsX/xNH/CvPCv/AEBb H/wFi/8Aia8z9x5/gXqeQ6j8QbPU9Mu7CbxDarFcwvC5TRJgwVlIOMzdeaqReNtDHxgsfEZuZBps No6O5hfcGMUqgbcZOSyj05+te0/8K88K/wDQFsf/AAFi/wDiaP8AhXnhX/oC2P8A4Cxf/E1dOdCD vrs106qwnc8n1DxZ4A1e/mutVmu74PD5EcM9uxjt1P3jGABtZuCWyW4GCBxXOeOPE2kav4c0vTtP 1G9vpbSbLS3kZEjLtYAltoBPQZ6nvk5Ne9/8K88K/wDQFsf/AAFi/wDiaZP8P/C0VvJIuiWGVUsM 2sXYf7tFOdCnNTV9HfoDuz57+Mf/ACPI/wCvSP8Am1ef16B8Y/8AkeR/16R/zavP65SgooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKAOt8Ef8v3/bP/2au6/sjU/+gdd/9+G/wrhfBH/L9/2z/wDZq9i8Ma5q09jr7TapeyNF pzPGXuHJRty8jJ4PvXbTbVNNHzWMhGeMlGXl+Rx89rcWrBbiCWFiMgSIVz+dRV122yn8M2ut67ca lf3BuXgSE3PUAA/eYEqBk9OuRVbRNMtdQimlj0DU78CUgGGcIkacYGdpy35dq05tNTjdC8kk9/66 HNUqqWYKoJJOAB3rs/8AhD7WPxW+nubloDZfbIbfKrNIcZEWem7OfyrI1CG0g1C0ji0m+02cSjfH dSb8jIwRlVI70KaewpYeUVeXexjT281rO8FxE8UsZ2ujjBU+hFR16FqlhoOqePL3SZEvPtlzOwF2 sgCRyEZA2Y5HYnNefupR2RuqnBojK4q1H2b3urtfceR0UUV5x9mFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV9RfCn/kmH hf8A673H/o818u19QfC10i+FnhmSRgqLLcszHoAJzzQB6fXn50pNQ+I+sSv4f0nUViNpm4vHAkgG 08oDG2T36ryB9a7H+3NL/wCf+3/7+Cok1PRI55Z47mzWWXHmSKVDPjgZPfFBXJLscMNcvba1sNaE a3F5D4e1KZVCBQzLNBjhcccdq6Tw1da3Lfsl8bqayktllSe7+yht+eQggY5Qg5GeRjqc1pRXWgQN GYXsIzEjRxlAo2IxBZRjoCQCR3wPSorE+GdMeV9Pj0y0eX/WNbxpGX+uAM0ByS7G5XIfESwGqaPp 1iZDGZ9ShRZF6ox3YYe4OD+FdD/bOm/8/wBB/wB9ioptS0a42edcWknluJE3kHaw6MM9CPWgOSXY 4Wwurq+8b6V4g1W3ls3+y3Fv5UikbFijQyMB7yNIM9wimnr4u1ew+1uGvryN9En1O2+3xW6klCm0 qITuCESZw43fLweuO3fUdFknjmkuLRpYgwjdiCyA9cHtnAzVW0/4Rewl82zi0u2k2su6GNEOGwWG QOh2rn1wPSgOSXYxNdtb0aRpw/t+S+ln1KzaOd4osR5f7yBFGQeo3bunU0q6pqUF2dPnvTdNa69D afaJYow8kTwLLhgqhQQXIyoHAHvWzbJ4UsgwtYNJgDSLKwiiRcuvIY4HUdj1qc3nh8yNKZLAyNKJ ixC5MgUKHz/eCgDPXAAoDkl2Ob0zV9ZSLRb+51GS7XUL+5tXtfJjVQqrOyFSFDbv3Kg5JByeKXwl rPiHVJNLvrlLl7O/gaScS/ZlihbbuURbHMhwcqQ4J7nbgiujW88PokKLJYKsDmSIAKBG5BBZfQkM 3I/vH1qGBvC9rfyX1umlw3kmfMuI40WRs9csBk0ByS7G7WN4q06bU/D1zHaAfbYdtzaH0mjIdPzK gH2Jqz/bmlf9BC3/AO/go/tzSv8AoIW//fwUByS7HDSa3/bxuPFFiwFtbmysbUugbBlmhefgjGcN GnsUPerqa34iu9cvGtYrow2mpraG3/0ZYPK3KGZizCXeVJZcDH3Rg9a6KO58NRWn2SNtNS23+Z5K qgTfu3btvTO75s+vNNc+GLzUor2SPTJ79MeXO0aNKuOmGxkYoBwkuhxd1441fTZ53nnEkGkmeC/X ylzLIxm+zngcHEUfAxnzh7V6Pp6XMem2qXsvnXawoJpMAb3wNxwOBk56VTkj0KUTiWCycXDrJNui U+a642s3HJG1cE9MD0q3/aNn/wA/CfnTsyS1Xntvc30M0lvYXjWhvPFE0Esixq58vyXYgbgQDlBg 47dxkHuP7Rs/+fhPzquG0ZXDBLQMJjOCIxkSEEF+n3sEjPXBoswOT/tnVn1DTtKfWWg3arc2Ul15 UXmSokZdOq7Q3QZC4OOnNW9D1+/utZ0+1uLtZbcjUYmm2KBcGGaJY34HB2l87cAkE44GL+paXomp 3lnLMbMwQyySzW7wKy3DOm3LZ4z0OSD0q7LB4fntIbSa1sJLaDHlQvCpSPHA2qRgfhRZgcjos95r niHw1qMmrXCvLpV45MKRbZQtxDxyh4IIzjB+UYI5z6LWO9v4eljto5LXT3S1ffbq0CkRNnOUGPlO e4q9/aVl/wA/Mf50WYEGv/8AIuap/wBekv8A6Aa4eDTtL0a28Gz6Nb29nql1LbpLHaqENxEY8yl1 X7wA+bJHBA55rvZL7T5Y2jkmieNwVZW5DA9QR6VQ06y8NaQ7Ppljptk7DDNbW6Rkj32gUWYHNaJr HibWZLa5H2uKG7lmhlDi18q2ADhTHhjIXVlUEODn5uBimf8ACU6nqWiajLHKsUml6JO1+vlqw+2j cu3BHRTFIcdw654rq0g8PR6kdSS109b9s5uhColORj7+M9PepF/sNY7qNYrIJdktcqI1xMSMEuMf NkcHPaiwGRp95f6rrt7E2rPZQ6e1uq20UcX78NGjlnLKTtJYoNpX7p5rO0zXPEWoap9pSK5+zLqU trNA32ZYI4ldkznd53mcBuRg5wFxg10txD4fu7qC5ubawmuLfHkyyQqzxY6bSRkfhSNB4efUhqLW untfDpcmFTKO33sZ/WiwGV4X1HUm1I2Ot3V22oPbef5bLAbZlDAF4WjG7blgMSHPP1rrax7CHw9p TSNp1tp9m0v+sNvCsZf67QM1d/tOy/5+Y/zoswMHxw06WmjtaxRyzjVrcpHJIUVjk8FgDj64Nc9q Os6zpes+JNQmsre3vk0/T40WCfz1VXuJkLkusYyNzHBwPl5OM47ua60u48vz3t5fLcSJvAbaw6MM 9CPWmtPpLyyyt9maSaMRSuVBLoM4UnuBubg+p9aLAcfcT6w4gg1NLowJqlg9vLeG385t0h3AiAlc DAIOATuI5xmn2uu6mHa8bV/Px4gk037D5UYXyvOKAZC7t6r8+c4wvIPJrpLW18N2MXlWlnptvH5i y7IoEQbxyGwB1HY1U0nTND0y4lu2NlNfPczzLdGBRIiyyM+wNycDdjrz6UrAdLRVT+07L/n5j/Oj +07L/n5j/OiwFuiqn9p2X/PzH+dH9p2X/PzH+dFgLdFVP7Tsv+fmP86P7Tsv+fmP86LAW6Kqf2nZ f8/Mf50f2nZf8/Mf50WAt0VU/tOx/wCfmP8AOj+1LH/n6j/OiwFuiqn9qWP/AD9R/nR/alj/AM/U f50WAt0VU/tSx/5+o/zo/tSx/wCfqP8AOiwFuiqn9qWP/P1H+dH9qWP/AD9R/nRYC3RVT+1LH/n6 j/Oj+1LH/n6j/OiwFuiqn9qWP/P1H+dH9qWP/P1H+dFgLdFVP7Usf+fqP86P7Usf+fqP86LAW6Kq f2pY/wDP1H+dH9qWP/P1H+dFgLdFVP7Usf8An6j/ADo/tSx/5+o/zosBboqp/alj/wA/Uf50f2pY /wDP1H+dFgLdFVP7Usf+fqP86P7Usf8An6j/ADoAt0VU/tSx/wCfqP8AOj+1LH/n6j/OgC3RVT+1 LH/n6j/Oj+07H/n6j/OgC3RVT+07H/n6j/Oj+07H/n6j/OgC3RVT+07H/n6j/Oj+07H/AJ+Y/wA6 ALdFVP7Tsf8An5j/ADo/tOx/5+Y/zoAt0VU/tOy/5+Y/zo/tOy/5+Y/zoAt0VU/tOy/5+Y/zo/tO y/5+Y/zoAt0VU/tOy/5+Y/zo/tOy/wCfmP8AOgC3RVT+07L/AJ+Y/wA6P7Tsv+fmP86ALdFVP7Ts v+fmP86P7Tsv+fmP86ALdFVP7Tsv+fmP86P7Tsv+fmP86ALdFVP7Tsv+fmP86P7Tsv8An5j/ADoA t0VU/tOy/wCfmP8AOj+07L/n5j/OgC3RVT+07L/n5j/Ol/tKy/5+Y/zoAtUVV/tKy/5+Y/zo/tKy /wCfmP8AOgC1RVX+0rL/AJ+Y/wA6P7Ssv+fmP86ALVFVf7Ssv+fmP86P7Ssv+fmP86ALVFVf7Ss/ +fhPzo/tKz/5+E/OgC1RVX+0rP8A5+E/OkOp2Q63MY+posBboqn/AGrYf8/UX/fVH9q2H/P3F/31 RYdmXKKp/wBq2H/P3F/31R/a2n/8/cX/AH1RYLMuUVT/ALW0/wD5+4v++qP7W0//AJ+4v++qLBZl yiqf9raf/wA/cX/fVH9raf8A8/cX/fVFgsy5RVP+1rD/AJ+4v++qP7VsP+fuL/vqnYLMuUVT/tWw /wCfuL/vqj+1bD/n7i/76osFmXKKp/2rYf8AP3F/31R/ath/z9xf99UWCzLlFU/7VsP+fuL/AL6o /tWw/wCfuL/vqiwWZcoqn/ath/z9xf8AfVH9q2H/AD9xf99UWCzLlFU/7WsP+fuL/vqj+1rD/n7i /wC+qLBZlyiqR1fTlGWvIQPdqb/bWmf8/wBB/wB9iizDlfYv1Dd/8ec//XNv5VX/ALa0z/n+g/77 FR3GrafJbSxpeQs7IQoDjJJFFmHK+x8xfGP/AJHkf9ekf82rz+vQPjH/AMjyP+vSP+bV5/SEFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQB1vgn/AJfv+2f/ALNXouiarBptrq0UySM15Ztbx7ACAxIOTk9OK868E/8AL9/2 z/8AZq62u6kr00fLZhJxxcmvL8jWn1OGXwvZ6YqyefDcyTMxA2kMFAxznPHpV2DU9IvPDtnpmpSX 1u1lJI6/ZkV1mDkHnJGGGMA88VzlFacqORVpJ38rHUapq+h6xqtrJIl/aWkFjHbx+UFZ0denUjK4 zzwaTVdftJtMsNOhnvb0W1yZzc3YAcDAGxRk4XjPJ61zFFLkRTxEnfzOkHiC0Hj/APt7y5vsv2rz tm0b9v0zjP41z0ziSeRxnDMSM/WmUU0kiJVJS373+88looorzT7UKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr6V8Af8kX 0b/dvP8A0a1fNVfSvgD/AJIto3+7ef8Ao1qCofEitTqYDThTsfQkqNng0/NQA1KrZ4PWqTIaH0Ul FMkOwpDS5o9qkYmBTcU6kpWGmNIpu2pKTFSUmRYpCtSEU0ikVcjIpMVIRTCMUDuW4NUuoDgv5i+j 8/r1rVttXt5uHPlN6MePz/xrnsUlUptHNVwdKp0s/I7EEEAjkGiuVtb6e0P7tsqeqtyDW5aalDdY X/Vyf3Cev0NaxmmeVXwVSlqtUXaSjNFaHIFJRRQAlLSUGgAopKKQBmikooCwUUUZoAKWkpKAFzRR SUgFzSUUUAFFFFAC0hNFNpALmikzSUwFzSUUUAFFFFABRSUUALmkoooAKKKKACiiigAopKM0ALRS UtABS02lpDFopKWgBaSikpDFopKKAHUUlFAxaKTNLmgApaSloGFJRRQAUtJS0DCikopDFzRSUUDF pc03NLQAtJSUuaAFzRSUUDFooooAKXNJRQAtLmkooAdRSUZwKBCk4pM03PNKDTHawtOzTaWgB1FI KWgTFqrI+58547VNK21D6niqtNGlNdRc00mlJphpmgE0wtVzTAG1ezVgCDOgIPf5hWjc2lpPa2sa Qy+fLdSIWj25PIz6Z46c8c0rkt2MAtSbsV00OmW9pdQT27MVdJ0ZWkV8ERnuvHfpVcadHc+TJdPP JElpEQQ8cYXOeNzYGPTqaVxcyMLdRuran0jT7A3TXclw6RXCxL5RUEhl3ZORTpNHsrOUpdSXD+Zc NBF5WOAMctn6jii4cyMQN70/d7VdtYWs9ZniD5eBJwHHqqNgj05Ga1Ee/kBKXN0Rkj/j4f8A+Kqr g2c/uo3VtXMsz2d4k00sgWLOJJC2CJEGRkn1P51h0JjTuOLUm6rWlgNq9kCMgzoCD/vCtPz21FNT huY42ECM8cojClCG4GQO9DYmzC3Um6tuTR7Pzp7WOSf7RbbTIzY2MCQDj068dadLpukxecS14Vhu Ps7DK/MTnkcexo5g5jC3Ubqmu4VstSlgP7xIpSvPG4A1sTSRXF7okxgjiRuWSNOMCQ8Y78Ci4XMD d7015VjXcx4rfvi1ykVyk3223W5EZhEAiYk8gDHJyMj+lVtKvv8ATltnjisIXuTnzoS5kGQPKyRx j8OtFxx11OakmaZ9zfgPSmg10+lzS299cwJbQ2trBctJdyyKGAjzgR9PYgAdSa5ydo3uZWiXbGXJ RfQZ4FNM64PoIKntf+PuH/rov86gFT2v/H3D/wBdF/nQ9i5bM8k+Mf8AyPI/69I/5tXn9egfGP8A 5Hkf9ekf82rz+uc8gKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AK+lPAf/ACRPR/8AcvP/AEa1fNdfSfgP/kiekf7l7/6NahF0/jRmh2HQmniZh1wfwqGlzWzR9LZF gXA7j8qkWZT0ODVOjNTyicEaauGHvTs1nJIyHg8VcimWQcde4poylCxLS9qbmlzSaIFpKKKkApDS 9qKQxpFJinYpCKmw7jCMU0in0lIq5GRxSEU/FIRSGmR49qTFPxTSKLjuallq7J+7uiWXs+OR9fWt kMGUMpBB5BHQ1yOKs2d/LZscfMh6oT/nFawqW0Z5+JwKl71PRnTUVDBcRXMYeNsjuO49jUtbHjtO LswzSUUUxBSUUUAFFFJQMKKDSUhBS5pKKBi0UmaKQhaSiigAozSE0lAC5pKKTNAC0UlGaACijNFA wopM0UCFzSUUUAFFFFABRRRmgAopKKAFopKKAFozSUUDFzRSUZpDFopKWkAtJRRQAUtJS5oGGaXN JmigBc0UlFADqSkozQMXNGaTNFIY6kpKM0DHZopM0UALRSUZoGLRRSUALRSUtAwpc0lFAC0ZpKWg BaKSloAKWkooAWmk806mUxoXNLTaUUDHUtNFLQIdSg02kd9q+9ArXI5m3Nj0qI9aXNBqjdKysNNN PNPNNNAxI5XgmSWNtrowZTjOCORUyapewpsSfA8zzR8oyG9QccVARTSKLE2LUutahKU3TgbN20LG oA3DB6DuKbFq9/AMJOMbFjwyKRhenBHbPXrVQrRtpWCyJrjULq6WQTy7hJIJH+UDLAYB4HpViPW9 RjkkcXPzSPvbKKfm9RxwfpVHbRtp2DlRLFcSxXHnq583JJYjOc9c565zVj+0rj+5a/8AgJF/8TVQ CnAU7BYsyX88sTRnylRsbhHCiZ78lQKrUuKUCgdhYpXgmSaNtrowZTjoRVi51S+u4jFLNmMnJVUV QT74AzVbFG2iwrFqTV7+WJYnuCVG3+EZOOmTjJx71C97cSCQNISJJfOf5Ry/PP6mosUbaLBYJ5Xu JnmlbdI7FmOMZJp/2u4/cYkI+z/6ogYK85/nTNvFV7mXYNi4yevtRYcY3dh+pa1eXxRHm+RG3jYo QbvXjHPvUVprOoWSNHBcYUvv+dFfDf3huBwfcVT2mjbTsjqUIpWsaFtrmo20Lwxzgo8hkYPEj7mP U5YGqTu0srSPjc7FjgAcn2HSkC04CixSilsAqe1/4+4f99f51D0otpN19bgfd81fx5pPYbV0zyr4 x/8AI8j/AK9I/wCbV5/XoHxj/wCR5H/XpH/Nq8/rnPHCiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACvpPwJ/yRPSP9y9/9GNXzZX0l4GOPgfpRHaO9/wDRjU1uXT+N GTmlzVZbj+8PyqVZFboefSuqUGj6exLmjNNzRn2qLAOBpwbB4OKjzS5qbAXIrns559asA5HWszNS RzsnuPSgylDsaGaXNQxyq44PPpUmaVjNofmim5ozipaJFpD60uaKmwDTSY4p1JxSsO40ikxTiKSp KuMxTTUlNI9KQ7keOKQ0/FIRQO4sE8ltKJIzgj8iPQ10VpeRXce5Dhh95T1Fc1ilSR4pA8bFWHII q4Tsc2Jw0ayv1OsNJVSxvkvI+yyqPmX+o9qt10J31R4c4ShLlluFFFJTICiikoAKKKKQwopKKAFo pKTNAhaM0lFABRSUUAFFJRQMKKTNFIQuaSiimMWkoooAKKKSkAuaKSigBaKKKQBRRSZoELRSZooA WikooGLmikooGLRmkozSAXNGaTNFModRTQadSEFFFFABRRRQMWikopALSUUUFC0ZpKKAFooooGGa WkooAWkzRmigYtFJmlzQMWikpc0AFFFFABmlptKDQA7NFJRQIU9KbSt0puaCkhaWkooAcKKSloEL UDvub27U6VsDaO/Wou9UjSEeotLSUUywpMUvWigBpFIRTqSgBuKNtOoFAWG7fSgLT8AUd6YDcUuK Wl4oAQCgClo700AUYopaAExRjNOpCVRSScAd6AIppBEhPBJ6Cs48kk9TzUsshkcsfwFMpnTCHKhm KMU7GKjaUDgc0GiTY/FNMir3yfaoWdm6nim0rmip9xzyF+OgqWz/AOP63/66r/MVBU9n/wAftv8A 9dV/nSZclaLPLfjH/wAjyP8Ar0j/AJtXn9egfGP/AJHkf9ekf82rz+uc+fCiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvpHwP/wAkO0r/AK53v/oxq+bq+kfA/wDy Q7Sv+ud7/wCjGpx3RdP416nN0UlLXq2PqiRZWXvke9SrOD14qtS5qHBMVi4DnkGlqmCR0OKkWZh1 waydN9BWLGaXNRCVT7fWngg9CDWbjYVh4Yip0uSOG596rUZqbCaTNJJFcfKc0/NZgYqcg4qdLo5w 4z7ipsZSh2Luc0ZzUSSK/wB0j6U8GpaM2h1HekzmjNS0IXFNNLzRmpsMSm4pxpKVh3G000+mkVIx hpKfimkc0FXER3ikDoxVgeDXQ2V/HdoAcLKOq+vuK50ikyVYMpIYcgjtVRm4mFfDxrLXc62isuy1 USfu7kqrdn6A/X0rTrpUk9jxKtKVKXLJBRmkzRTMhaSiikAUUlITQApNJSUUALRSUZoAWkpM0UAF FFJQAtFNpaACiiigAoozSUgFopKXNABRSZooAXNFJRmgBaKSigAozRRQAtFJmjNAwooozSAKKSig YtJRSUDFpwNMzS0gH0ZpM0ZoAXNFJRSAdSUUlAxaXNJmigYtFJRQAuaKKKBhS0maKQwopKKYxc0U UUALmlptLQAuaKSigBaKKKAFBpaSgnAoAQnmim0opFDqKSlFAhaM45pKbK2Fx600CV2RE7iTRSUV RsLS/jTaWmAtFFJQAtJS0lABSUUZpjFopBS0AApeKbSjrTAWlpKM8UCFopKWmAtU7qXc2xTwOv1q W4mCLtB+Y/pVFmAGScUG1OHUU4pjyKnufQVG8xPC8e9Q9TSudcYdx7OzdenpTKKKk0SCiiimUFTW f/H9b/8AXVf51DU1n/x/W/8A11X+YoZM/hZ5d8Y/+R5H/XpH/Nq8/r0D4x/8jyP+vSP+bV5/XOfP BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFdl4d+G+r+IdP+2RkQRkBk3gfMv8Ae5I4p3w48NW/iLWJjc5ZLYK/l4GG znqewGK96+zFZpQt7hBEFRgwG4BeFxngY4/TpzXFicRKN4w3RSR40Pg3rB2Yu4T5hwn3fm7cfNzW B4n8B6p4Yt1uZh51vkK8iDiMnoDgnGcGvoEW7CO2zdgYY7huH7v6c81DeWcVxaXsFzeRvHMdu1pF xNz3yfx5/pXMsTXWu69PP0/r0K5UfLVFema98I9Qj1Rjo9xbS2kihwJJNpQnqvfOCOvuKy/+FUeI /Wy/7/f/AFq7o4mnJX/RkWZw9Fdx/wAKo8R+tl/3+P8AhWVr3gfWvDtmt3eRwtAW2l4pN20+9XGt CTsmFmc5RRRWogooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACvpHwP8A8kO0r/rne/8Aoxq+bq+kPBP/ACQ3S/8Arle/+jGq o/Ei6fxr1ObzRUQcj3FSAgjivXaPqh1FJRSsMWikpaVgFopKWpsIWjNJRSsAuaKSjNTYQ4Eg5BIP rUy3c68CQn681XzRUOKE0mX01Jx96NT9OKnTUYjjcGU/TNZWaM1m6aIdNG2lzDJ92Rcnt0NS1z+a liuJIiNrHH909KzdLsQ6XY2qDVOG/R8CQbG9e1Wgcjg1k4tbmbTW4tJiloqGgGmmkU6kNSMYaaae RSGgYyr9jqbwERzEtFjAPdf/AK1UTTaak1sTUpxqR5ZI6tHWRQ6MGU9CKdXO2N61pLgkmJj8w9Pc V0IIZQwOQRkEV0RlzI8PEYeVGVnsLSUUhNUc4E0lFFAwopKKADNFFITQAUUUlMBc0lJRmgBaSijN IAozSUZoAdSZpM0UALRSZopALmikooAWikpaACikooAWikpaQBRRRQAUUmaM0DDNGaTNJmgY7NJm kzRmgYuaXNNzS0gHA0tR08HIoYMWiiikIWikpaBhRRRQMKM0UUDFopKM0DFzRSUZoAWiiigYUtJR QAtFJS0gAmjNJRTGLTqbS0CHU1jk0E8UlA0gpaSikMWlpKKAHCoZDlz7cVLnAqDOTTRUFqFFJRVG gtFFFMBaO1JRQAuaKSimAUUlJ1oAXNGeKSgZoGOooopiFFFJQzBQWJwKYDqhmuViGOrfyqtPffwp x/OqDOzHk0jop0G9ZE8lwSxI5J7moCxY5JzSZopXOuMUtgNFFFIoKKKSmAtJRRQMKnsv+P63/wCu i/zqCp7P/j+t/wDrqv8AOh7Ez+Fnl3xj/wCR5H/XpH/Nq8/r0D4x/wDI8j/r0j/m1ef1znzwUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU+GGS4njgiXdJIwRFHck4AoAWCCW5mSGCNpJXOFRRk k1of8I3rX/QLu/8Av0a9t+GvgvTvDduup386Pqj42gA4iHUEH1z/ACFel/21H/z/AMn/AH8b/P8A n14rhrYyUJuMacn52KUb9T5Em0HVreF5ptOuUjQbmZoyAB61nV9j3GpW11A8E920kTjDKzsQRXgH jj4by2N/9p0Lbc2srkeUpCsnf6f5GPbTD4l1W1KDj6oHGx5vRW5/wh+v/wDQNk/77X/Gj/hD9f8A +gbJ/wB9r/jXUSYdFbn/AAh+v/8AQNk/77X/ABrFdGjkZHGGUkEehoAbRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFAHpvwdz9s1fAyfKj4/E161cyXK3s0KWsPnvEfkABCLjJb2479Pw4ryT4PYN3q+c48q PoPc16xZNZDXZ3lMxgQLtyNx7E7h/EOCeo9favO9jGti+WW3/ARniasqVBzjuDaVNBYWVzeW8Tia Q+Xvb5n4HO0nAHoQPrkEVjarpMOqWl1FLZxxBJN4aF2QxNyBjB5Az0OR654rc1/VIdV1SOfbKsaf u1G0DCA5GPfmso+Rtnx5uc/J/wDXr6CNOPLyuK9D5StWmqrcJt263MnQNT1TTfFEGgakIrnzIy9p PMoTzQcnb2DEc9OeneuqxL9gz5Mezzvv98+n0/yO9cJ4yWGObRrq38xLhLqJPMJwQCwDAe2K7OIw tYISZTKWB56Yx/P/AD9fm8woRo17R2dvkfT5diJV6ClLdaF9luPtdyDawBvK+ZRjCjHUf5/SuR+I QkHgVy0MaoQ21x1bg9f8/piunP2Tz5sefs2fJ659/b/9ftXKfEDyf+EKm2eZ5mDu3fd6Hp/n/wCt xQXvR07HceCUUUV9EYhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfSHgn/AJIbpf8A1yvf/RjV8319IeCf+SGaX/1yvf8A 0Y1VH4kXT+NHKUuec0lFe2fUEivnrT6gpyuV9xUtFJktFAII4oqRhmlpKKVgFozSZopWELmikozU tALRSUtJoQuaKSjNQ0KwtFJmipaAdmnrNIgAV2A9M1FmlqWhWLsd/Iv3wH/Srkc8cw+U8+h61jUq sVOQSCO4rKVNPYhwTNyg1Rhvx0lHPqKtpIrrlGBHtWEotbmTTQppDS0hqAGmkPNOxTetIY0itPSb vafs0hGCcoSe/pWbikBKkMCQRyCO1OLs7kVaaqwcWdZmm1BZ3P2q2WQ/e6MPep66k7nz0ouMnFhS UUGgQUlFFAAaSkJopgFGaTNFABRmkzRQAtFJSZpALRRRQAUUUmaAFopKM0ALRmkooAdmkpKM0gHU ZptLQAZpc0lGaAFpKTNFIBaSg0lA0FFJRQMWjNNpaCh1JSUUAOoB5puaXNIdiQHNLmow2DT80EtC 0UlFIYtGaTNFADqSkpc0hhRRRQMKKKKYC0UlLQMWikooAWkJoopAFLSUtMYUucUnSkzmkCQpopM0 UF2FpaQUUCFpaSigQjnCH8qhFPlPIFMBqkaRWgtFJmlplBRmikpgLS0naigA6UhNKTSUwCik70tA w70UlFMBRS0lRTzrCn+0egoBJt2Q+SVYk3MfoKzZ7lpW/lUcszSsSzZqOk2dtOko6vcM85opKKRs LS03vS0DFoopKBhRRRTAKKKKYBU9l/x/W/8A10X+YqCp7P8A4/rf/rov86T2Jn8LPLvjH/yPI/69 I/5tXn9egfGP/keR/wBekf8ANq8/rnPngooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArQ0H/kY dM/6+4v/AEMVn1oaD/yMOmf9fcX/AKGKAPry2JNtEScnaOfp/n/HtUuPb/PT/wCt/wDXqG1/49Y/ 931/z/n9Jv8AP+f8+3vXxtaclUlr1Z0LYMZ7f5/z/nOaOv8An/P+fbNH+f8AP+f8aP8AP+f8/wCF Zc8u/wDwB2D/AD/X/wCv/wDWoxj/AD/n/PXtR/n/AD/n39qP8/5/z/8AWOeXcAx7f56f/W/+vXyZ 41ijh8ZapHEiogm4VRgDgdq+s/8AP+f8+3vXyd45/wCR11X/AK7f0FerlEm67u+n6oipsc/RRRX0 RiFFFFABRRRQAUUUUAFFFFABRRRQB6Z8Hv8Aj81fBA/dR9cep9a9VuriWx1K5uJLuMLLGEllUZUn jBPHTgDPUHB6ivKvg9/x96vkZ/dR8fia9ckijee4RtPbaY8eUSfk7ZP+fbrzXlVazo4n2i6f8AKl NVabg+pn+c8q2jpcRFS3yYx8vPfFIzSiO7zPFjd8/T5vpWPd+GdQjnin0a8lg+0HDRXCebH2x5YG COc5yTnPbFVZfC2vX0cseoaoBAhy32SExtnngkk8Yzx+PavXWZ0HG7ep868mr89k1buU9Ruk8R+N dK0Y3sAtrciR2dgis68qoPqMD6/Tmu8HmrpwUTR+WJfuH72fX6f5PauU8Q+H9EsfDCy6fps0L20W +WBWLSLIBnzQxycHg85AHYjFUvBnjOLVbX+zNQhVNRRwVlDYEq+mPX/GuLHYWvVgsYleGiv0R7mE hTox9jF6rc9AZrj7Zck3UJcxfM3Zh6D3/wA9a5H4hGX/AIQVw00bJtbag6rwev8An+tdUyp9pnH2 BwBHxHk5Q+v+fp15rk/iCF/4QiQi3ZDhsyHo/Brx6aXNH1XY7GeBUUUV9GYhRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFf SHgn/khml/8AXK+/9GNXzfX0h4K/5IZpn/XK+/8ARjVUPiRdP40clmlzSUV7h9QOoptOpAKCQcip VcN9ahopWGmWKSmK+eDT6hoYUUUUgEozmg0lIB1FNpc0rALRmkopWELRmkzRmpaAXNFJRUtCFzS0 maM1LQC09HaNtykg+1R9KXNQ0I0IL4NhZeD0z2NW6xKsQXTQ4U/Mn8qxnS6ozcOxpU00qurrlSCD RXPYzG0hpxpDSGW9MuPJudh+7J8v49v8+9btcrXRWdx9otVc/eHDfWtqcuh5mPpaqovmWDSUUVqe aFNJoJpKYBQTQTTaAFpM0lFAC0UUUAFFJmigBaKTOaSgBaM0maKAFzRSUUgFzRSUUALRRRQAtFJm jNIBaKTNFAC0UlJmkMUmkzSZpM0xi0UlFIoKWm5ozQOwtLTc0uaQC5pc02loAWlBptFAEuaM0wGn UgFooooAWikzRQMWikpaAFopKKAFopKM+tAxaTcKYTk0Ui1HuO357UZNJiii47Iduo3Gm0tFwshc 5paSigBaWkooAWlpKKQDqSjNMkbC49aYrXIyckmjNJmgVZqOFANJRQMWikopiFo980lFNALSZpM0 UDFoFJmigBaKSmyyiKMue3QZ60DSu9Bs86wpngsegrLeRpHLOck0SStK5ZjyaZmg7adNRXmFFJRS NRaKSloGFKKSimAtFFFAwooopgFFFFABU1l/x/W//XVf51DU9n/x/W//AF1X+YpPYmfws8u+Mf8A yPI/69I/5tXn9egfGP8A5Hkf9ekf82rz+uc+eCiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtD Qf8AkYdM/wCvuL/0MVn1oaD/AMjDpn/X3F/6GKAPru1/49Y/90f5/wA/h3qb/P8An/P6VDa/8esf H8Iqb/P+f8/pxXxdb+JL1Z0LYP8AP+f8/pij/P8An/P64oorIYf5/wA/5/Wj/P8An/P070f5/wA/ 5/Xmj/P+f8/1oAP8/wCf8/pXyd45/wCR11X/AK7f0FfWP+f8/wCf04r5O8c/8jrqv/Xb+gr1cn/j v0/VEVNjn6KKK+kMQooooAKKKKACiiigAooooAKKKKAOs8D+K7bwrLfSTxTSNcIir5QHGCc5yR61 2R+MFoZHf7Pe5ZdpOFyRjH97p/TivIaK5qmEp1JOT3Y1Jo9c/wCFvWYWMfZrzEZyvC8fT5qD8XrM iUfZr394ctkLzz3+bmvI6Kj6jS8x8zPRtZ+IdlqNzbahbR3kGpWi4hmKqcjOdjfN905PHuaqXlna +ILE61oY8m4hO66tF4aJuzpjqp59x+NcJV7StWu9Gvku7OUxyL+II9CO4r3MqxawidGesH0e2v6f k9UcGKw0pyVak7TX3Ndn+nb8H6PYfFaS0tVj1KO6lugnlvKmDvGMDJJFUfEfxHtNc0GTTlgulJB2 bgu0Ej/e4rkdf1Sx1W6NxaWQtC4DSRq2V3/xFfQe3asauDHZdhKeIvh3eO68vL5HVRqznBOas+wU UUUiwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACvpDwT/yQzS/+uV9/6Mavm+vpDwT/AMkM0v8A65X3/oxqqHxIun8aOSoo or3D6gM0UYooAdRSUUgFp6v2NR0UgLFFRo+ODUlQ0UJRRRSASilNJQAUtJSUgFozSUtKwgoooNKw BmikzS1LQhc0UmaM1LQh1KKbQDUNATQzNC+RyO49a00kWVAynisjNPhlaF9w5HcetYzp31REo3NW kNIkiyIGU5Bpa5mjIaau6XP5V1sJ+WTg/Xt/h+NU6QMVYEEgg8EUk7O5NSCnBxfU6jNFRW8vn26S dCw5+ven5rqR89KLTswooptMQUUhooAKKKSgYtGaSigAozSUUCFpKKKACikpaQBRmkooAWjNJRQA 7NJSZozQAtGabRmgY7NFNozQA7NFNopDFozSUUDDNJmik70hoXNGaSigodmjNNpaQC0tNpaAFzRm kzRQA6nA0ylFAEmaKaDS0hC0tJRmkMWiiigAopKM4pgKTgc0wnJpCcmkpGqVhw6UtNFLSKFpaSig QtLSUUALRRRQIWlptLTAdRSCloAKgZtzZ7U+RsLjuaipouK6ig0UlFUUOozzTaWgBaM0lFMYtFJm jNMAopO9FAC0tJmigAJwMnGKzLmbzpcj7o4FWL2bA8pTyfvH29KoUHVRhb3mBpKKSg6ApaKSkAva iiigYUtJSg0wFopBS5oAKKKKYwooooAKnsv+P63/AOuq/wAxUFT2X/H9b/8AXRf50nsTP4WeXfGP /keR/wBekf8ANq8/r0D4x/8AI8j/AK9I/wCbV5/XOfPBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABWhoP/Iw6Z/19xf8AoYrPpUdo3V0Yq6nKspwQfUUAfYlpd2xtIiLiIgr2cf41N9qt/wDn4i/7 7H1/z+fXivj8arqKgBb+6AHQCZv8aX+1tS/6CF3/AN/m/wAa8GeUVJScuda+RqqiPr/7Vb/8/EX/ AH2KPtVv/wA94v8AvsV8gf2tqX/QQu/+/wA3+NH9ral/0ELv/v8AN/jU/wBjVP519we0R9f/AGq3 /wCe8X/fY+n+fy6c0farc/8ALeL/AL7FfIH9ral/0ELv/v8AN/jR/a2pf9BC7/7/ADf40f2NU/nX 3B7RH1/9qt/+fiL/AL7H1/z+fXivlTxwQfGuqkHIM3X8BWX/AGtqX/QQu/8Av83+NVpZZJpDJLI0 jt1Zjkn8a7MDl8sNUc3K+liZTuhlFFFeoQFFFFABRRRQAUUUUAFFFFABXT+D7W3uftv2i3il27Nv mIGx97pmuYrrfBH/AC/f9s//AGataPxo4sxbWGk15fmjov7K07/nwtf+/K/4Uf2Vp3/Pha/9+V/w r0PQ9Ts9StdXlm8PaMGs7Np49kDAFgQOfm6c1FozReIoNZX+ztMs3jscq0abET94uXJYnGBnkdq6 rrqjwFCbtae9+/Q4H+ytO/58LX/vyv8AhR/ZWnf8+Fr/AN+V/wAK6PUtB+x6ZHqNrf299aNL5LSQ hlKPjOCGAPI6H2qG90Wex1aDTpJI2kmWJgy5wN4BH86pcrMX7Zbt/f3ML+ytO/58LX/vyv8AhR/Z Wnf8+Fr/AN+V/wAK6m38K3dzqeqWK3Fsj6aGM0kjFUwrbSc46d6h1LQfsemR6ja39vfWjS+S0kIZ Sj4zghgDyOh9qPdG1XSvd/ec5/ZWnf8APha/9+V/wo/srTv+fC1/78r/AIV1Vl4bgv8AyYYNcsDf TKDHbHzBkkZC79u3d2xnrUWm+G7jULK8u3ube0hs5Fjna4JGzOeeAc8jGBzkij3RpV3azf3nNf2V p3/Pha/9+V/wrzCvYbyGK3upIoblLmNT8sqKQG/A8149XPiEtLHrZRKTc1J32/UKKKK5j2gooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAK+kPBX/JDNM/65X3/oxq+b6+kPBX/JC9M/65X3/oxqqHxIun8aORzS0ylzXuH046ikBpaBi0 lFFABS0lLSAKejdjTKKT1EmT0lNRs8GnkVm9C9xKKKKAA0lFFAhKWkopALRSUUALRSUUrALRSUVL Qh3Sim5pQaloQ7NLmmilzUNCJoJjC+eqnqK0QwZQVOQelZIqWGdoj6qeorCpTvqiZRuaVNIpEkWR dynI/lS1zNWMzR0q42yNAejfMv1/z/KtauYVijh16qciuhgnW4hWRe/UehranK6seVjqNpc66klB opK0OCwUUUlABRRSUxhRRSUALRSUmaQhc0UlFAxaKSjNAhc0lJRQAtGaSikAtFJRQAUUmaM0DFoz SUUALmjNJRSGLSUUUhgabQaKBi0tNzRSGOpKKKAFzS02gUAOzS02igB1KDTc0tAD6AaaDS5oAfmi mg0ZpWAdS0zdRuosFh9MZweBTGYt9KSkaxj1Y6lpuaWkULSikooAdRmkooAdmikooAdmikozTEOo pM0tAC0uabTZXwuB1NMErkbNuYmkpKKZpYWiiimMKWkoJoAXNGaTNJTGOpPxpM0GmA6k5pM0fjQF hc4pJJVjjLnt+tGao3ku99g6L/OguEeZ2K7MWYsxyT1ptFJSO1C0lFFAwooooGFLSUUwFooooAWi ikFMYtLSUtIAooxRTAKns/8Aj+t/+uq/zFQVPZf8f1v/ANdF/nSexM/hZ5d8Y/8AkeR/16R/zavP 69A+Mf8AyPI/69I/5tXn9c588FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFd34d0+yn0K2klt LeRzuyzxgk/Me+K4SvSvBscUuladHPJ5cLyFXf8AuqZDk/lW9C3M7nmZs2qK5XbX9GS/2Vp3/Pha /wDflf8ACj+ytO/58LX/AL8r/hXo+vCbQr6aBfCNi2lRttjneB3MidmMoPU9fauatYJm8LajOsdq YUnhV2dCZQTuxtPYdc/hXSmmr2PEnGpCXLzO+vfoc7/ZWnf8+Fr/AN+V/wAKP7K07/nwtf8Avyv+ FdzrWhSX+uRRWccNvbx2FvLPMw2RxAxjLMR6n8TWDd6S9tpcGoLPHLBPNJChUEE7Mc4I6HNNcrJm q0W9XoYn9lad/wA+Fr/35X/Cj+ytO/58LX/vyv8AhXYaNoxtPEvh0XXlTRXzRzBMZG0uRhgR7VDL bS/2PrUscVp9njvUViyfvVJL4CHoBxyPpS93sO1W13J9fyucr/ZWnf8APha/9+V/wo/srTv+fC1/ 78r/AIV1K+E76W+s4YJIZbe6h89LsEiJUH3ixI429CP8axJVVJnRJBIqsQHAIDD1Gaa5XsZydaPx N/eeRUUUV5x9mFFFFABRRRQAUUUUAFFFFABXW+Cf+X7/ALZ/+zVyVdb4J/5fv+2f/s1a0fjRw5l/ usvl+aPTvDNzBb2OvrNNHG0unMkYdwC7bl4Gep9qZ4fuIYNK19JZo43lsgkYZgC58xeB6nGawaK7 eU+aVVq2m1/xN63uIV8C31uZoxO19E6xFhuKhGyQOuOlbd3a22q6xpetLqdjFZCK387zJ1EkbIAG XZ1J447fhXDUUnEqNeys1fb8L/5nZy31qdT8aOLqHbcJIIWEgxLmYH5fXjnisq3uIV8C31uZoxO1 9E6xFhuKhGyQOuOlYNFHKJ123e3f8T0y1uIrbW9PmsNR0a08PqYSP9V5p4G4Nkb9xOcnsOciufvb y2bRPEkaXMRebVEeNQ4y6ZfkDuORzXJ0UlCxcsU5K1u/4q2nkFeS161XktY4noenkv2/l+oUUUVy nuBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAV9IeCv8Akhemf9cr7/0Y1fN9fSHgr/khemf9cr7/ANGNVQ+JF0/jRyFFJmivdPph aM0UlAx2aKbS5pCHUUgNLmkO4tFJRSEOqRW3D3qLNKDg5FJq407E1J2oBDDIoNZliUUUlMApaSig QUlLSUgClpKKACgmikpCFozSUUmA4GlpuaWoaEOpabSioaESI7RtuU4NXIrpZOGwrVQozWcqakS1 c1TV3Tbjy5fLY/K/T2NYcdw8fBO5fQ1bjmST7pwfQ9a53CUHcxq0ueLizqKKgtZ/Pt1c/eHDfWpq 2Wp8/KLi2mLRRSUxBRRSGgApKWkpAFJRRQAUUZpKYC0UmaKQhaKSkpDFzRSUZoAWkopM0ALRmkzR QAtFJmjNIB1JmkooGLmkJopCaQwzRmkzRmgoXNGaTNGaQDs0ZptLQMWikooAdS5ptFADqWm0ZoAd mlzTM0UAOzRmm5pc0DsLSZ7UhNJmky4rqOopKWkWLS5ptLQA6img0tAh1FJRQA4GlpuaM0AOzRSU ZoAdRmkooAXNQs25s092wMVFmmiooWlptLmmULmikopjsLRSUUALRnmkNJnimMWlzTc0ZoAWjmkp KBjZ5PKiLd+g+tZmec1PdS+ZJgdF4qvQdVONkLSGikoNBaKSloKEpaSimAtFFFAC0UlKKBhRRRTA WgUCikAtFFFMYVPZ/wDH9b/9dV/nUFT2f/H9b/8AXVf50nsRP4WeXfGP/keR/wBekf8ANq8/r0D4 x/8AI8j/AK9I/wCbV5/XOfPBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXo/hKMS6LYxtIsau zKXbooLnk+1ecV6H4Z/5F61/4H/6Ga3w/wAR5Wb/AMBev6M9V8Ow6loeowSz+I7AaRGczKt8siSJ 3UR5ySR7ZrGF3ZN4Y16OF44xNfRPBCWAbYC/QewIrmqK6uTqeI8Roopaa9e6seg6tq+navHDoM93 FBEbeB4LyN/kWURgFZcdR2z1X6VlpZLqXhWHTIr2xS8sLyVnSW5RVdGC/MrE4YZHY1yVFJQtsOWJ 523Jb6fI7ua5sLfxP4REeoW00NpBCk0yyDYpEjE5J6fjjjFZRubc+G9fhE8Xmy38TRpvGXUF8kDu ORz71zNFPkE8Q307/irHe2moaZYaSPCMl+Cl4ha4vo5cxwzNgqoI4KDADHvn2rhp4jBPJCzIxRip aNgynHcEcEe9R0U4xsRVq+0STW23oeS0UUV5p9mFFFFABRRRQAUUUUAFFFFABVux1O807zPsk3l+ Zjd8oOcZx1HuaqUU02tUTKMZrlkro1v+Em1j/n8/8hJ/hR/wk2sf8/n/AJCT/Csminzy7mX1Wh/I vuRrf8JNrH/P5/5CT/Cj/hJtY/5/P/ISf4Vk0Uc8u4fVaH8i+5Gt/wAJNrH/AD+f+Qk/wo/4SbWP +fz/AMhJ/hWTRRzy7h9VofyL7ka3/CTax/z+f+Qk/wAKP+Em1j/n8/8AISf4Vk0Uc8u4fVaH8i+5 Gt/wk2sf8/n/AJCT/Csmiik5N7suFKFP4IpeiCiiikaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV9IeCv+SF6Z/wBcr7/0Y1fN 9fR/gv8A5IXpn/XG+/8ARjVUPiRcPiRx+aM0maK96x9KOBozTaXNAC5opKWkAU4Gm0tIY6ikozSA WikopCJEbB9qkqvUqNkYPUVMkVFj6TFLRUFDaKWkoAKSiigAooopAIaKKQ0CCiiigBc0A0lFIQ4G nZqOlDVLQEgpabnilqGhC0tJ3opCL9jqctm5yPMQ9Qev51v2uoW92P3T/N/cbg1yNKCQcgkEdKnl RyV8HCrrszt6K5y01uaHCTjzU9f4h/j/AJ5rdguYrmPfC4Ze/qPrUtWPJrYapS+JaEtFFJUmAUlL SGgBKKM4pKYC0maCaSkAtFJRmgBaSiigAopM0UABNFJRSAWiiigYtJRRSAXNJSE0hNAxaSkzRSHY WikooGLRSUUDFopKKQDqM0lLQMXNFJRQAuaM0maKAHUU2lFAC0hOKCcDNR5ycmguMbj85oFN70ua RoPopM0tIQtLTaXNAC0uaTNFADqXNNozQA6ikzS0ALRSUUwHZpM0maRzgUBYYxyc0maTNFNGguaW m0tMBc0ZpCaSgY7NFNzS5oGLSZpKM0wsLmjPFJRmgYtRXEvlxEj7x4FSfWqNzJvkIHReKC4RuyGk NFJQdQZopKWgYUUlFAwpaSlpgFKKSigBaKKKBi0UCimAtFJS0gFooopgFT2X/H9b/wDXVf51BU1l /wAf1v8A9dV/nSexM/hZ5f8AGP8A5Hkf9ekf82rz+vQPjH/yPI/69I/5tXn9c588FFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFaNrrupWdulvb3OyJM7V2KcZOe496zqKabWxE6cJq01f1Nb/AISb WP8An8/8hJ/hR/wk2sf8/n/kJP8ACsminzy7mf1Wh/IvuRrf8JNrH/P5/wCQk/wo/wCEm1j/AJ/P /ISf4Vk0Uc8u4fVaH8i+5Gt/wk2sf8/n/kJP8KP+Em1j/n8/8hJ/hWTRRzy7h9VofyL7ka3/AAk2 sf8AP5/5CT/Cj/hJtY/5/P8AyEn+FZNFHPLuH1Wh/IvuQUUUVJuFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfR/gv/khWmf9cb7/ANGNXzhX0f4L/wCS Fab/ANcb7/0Y1VD4kVD4kcbRSZpa+gPpAzS0lFIYtLmm5pc0gFzRmkpKVguPzS5pmaXNILjqKTNF ILi0oJBzmkopDJ1bcPenVXDYORUwORkVm0UncWiikpFBSUuaKBCGkpaSgApKU0lABRSUUgFpKKKB BRRmigBQ2KeD6VFSgkGpaAmBpajVgafUNCFpcUgpakQVJBcS20okibaw/WozSUCaTVmdTp+oJex4 OFmA+Zf6j2q5XGxyPFIsiMVZTkEV0un6gl7Hg4WVR8y/1HtUSjY8bF4T2fvw2/Iu0lLSZqDhEoNF JQAUlFFMAoopM0h2F6UmaKOlAWCikopALRmkooAWjNJmigBc0lGaQnNIYpNJmkooGGaWkozSGLTa M0UDFopKKAFzS5pKKBi5pabRQAtLmkooAWikpaAFo7UlMkb+EfjQUldgzbj7UCmUopG1rDxxTs0z PFLSAeDRTQaWgQ6l702loEOozSUUDHUUgNFADqKbmigB+aM0zNL1oCw7NRFsk0rN2pgplJDqKSjN BQuaM0n40UwFopuaAaBimikooGLRTc0uaAF6GjNNzRQMbNJ5cZbv0FZ9TXD7nCg8LUJpnRTjZCZp O9Bo7UGgUUUlAxaSlpKYxetLSCigBaKKKAFooFFMYd6WkpaQBS0lApgL7UtJS0AFTWX/AB/W/wD1 1X+dQ1NZ/wDH9b/9dF/nSexM/hZ5f8Y/+R5H/XpH/Nq8/r0D4x/8jyP+vSP+bV5/XOfPBRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX0f4L/5IVpv/XG+/wDRjV84 V9H+C/8AkhWm/wDXG+/9GNVQ+JFQ+JHF0tJRX0J9GLRSUtILhS0lGaQ7i0UlFAC0UmaKTAdmlzTc 0tSA7NFNzRmkA7NOVtpplGaVguWAcjIoqEMR0qVWBrNqxaYtFFJSKFpKKKBCUUUUAJRRRQAUUUlA BRRRSAKKM0UCEpQ5FJSUgJlkB68VIDnpVWlBI6GpcOwizRUAlI6jNSLIp74+tS4tAPp0cjwyCSNt rKcgim0VImr6M6iw1BL2PHCzKPmX+o9quVxscjxSLJGxV1OQa6HT9UW7HlyYSYfk30rOUTx8Vg3D 34bfkaFJRRUnAFNpTSUwCiikzSKCikopALRmkpKAFzRSUUALRmkpCaAsLmkzSUUihc0UlFAC0Gkp KBi/jRSUUDFzS03NHUUAOopM0UDFopM0uaQC0UlLQIXNLTaKBik4BJqHOST3p0jcYqOg1gtLjqUU 3NLSKH55paaKUGgBwNLTc8UuaQDs0uabRQKw8UZpveloCwtLmm5pe9Axc0E03NGaYC5ozjmkzTWP OKBpATkk0ZpuaAexoLHZ7UUmeaKYC5ozSUZoGLmikpCaAHZpAaSjPNAxc80UhNJmgBc4pHfYhY9q QmoLl+i/jQVGN2VySSST1pDQaSmdSFopO1FAwNFFJQMWiiimAClpKWgBaKBRTAKWkpaQBS0lAoGL RRRTAWgUUopAFT2f/H9b/wDXRf5ioKms/wDj+t/+uq/zoZM/hZ5f8Y/+R5H/AF6R/wA2rz+vQPjH /wAjyP8Ar0j/AJtXn9c588FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUV1/g6Hw+mk6rf69pMmpCKe2hhRJ2jKmTzM ngjP3B1rqdat/BmgXws9Q8CXMc5XdtXUmbjjuH9xV06c6klCCu30QN23PJ6K9H/tP4ff9CRd/wDg wf8A+LrpIPCuhXMNvLD8OLpkuLN76M/2uBuhXaGb/W8feXjrz0rargsTRt7SnKN+6aJUk9meKUV7 W3hXQkgeZvhxdCNLD+0WP9rji3wTv/1vseOvtXN/2n8Pv+hIu/8AwYP/APF0UsFiat/Z05O3ZNg5 Jbs84or1h7fwWnh4a63gW5Gnliu/+0nzkNtPG/PU1pL4d8JreWdtc+CZbc3kRmhZ9TdgVAB/hc46 1ztNOzKPFaKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFfR/gz/AJITpv8A1xvv/RjV84V9H+DP+SE6b/1xvv8A0Y1V D4kVD4kcVRSUV9GfQ3Fpc02jNKwx1FJmjNKwC5ozRSUrDFopM0tIBaKSlpALmim0tIBc0oNIKKkB aXJBptGaQEyyetOqClDEfSpcexakT0hpocH2pc1NikxaKSikAUUUUAFJQaKACkpaSgQUUUUgENFH ekoAWikooADRSUUxDg7L0JqRZ+fmH5VDSUOKYFsEN90g06qQJByKlScj73IrN030A3bLWHjxHc5d eAH7j6+tbMc0cyB4nDKe4rj1YOODUkUskLh43KMO4rFxOCvgYT1hozr6Q1j22tdEuV/4Go/mP8Py rVR0kQOjBlPQioaseZUozpP3kONJSmkpGYUlFIaAFopKKQwoozSUAGaKKTNA7C0UlFAwozRSUgFz SZpKSmULRSUZoGLml9qTJozQAtLTc4opAOzS02jNADs80UmaKAHUZpKaWwCaASuxjHLUCmA04Umb jqUelNFLSAdRSZpc0AKDS02lzQIdmlzTaWgB1LTaM0AOozTaXNAC5ozTc0ZoGLnio805jximUy0h 1FJRQMXtS02jPNADqSk6UZoGLmgH1pKQmkApNBPNNJpM0x2HZ4ozTc0E0DsLmqcjb3JqeViEPvxV WhGtNdRaTNFJTNgpaSigBaSiigYtFJS0wCgUUUALS0lFMBaWkoFIBaO9FHFAxaKKKYC0UgpaQC1N Zf8AH9b/APXVf51BU9n/AMf9v/10X+Ypkz+Fnl/xj/5Hkf8AXpH/ADavP69A+Mf/ACPI/wCvSP8A m1ef1zHzwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFeu/DL4Ym+aPWtct/9FDfubeT jzCOuR1x0Hbqe/T1j/hDPC3/AELmnf8AfL//ABXr/h1rhrZhQpTcJPVFKDZ8lUV9XXvgPwveWUtu uhWUJkUr5kavuX6fN/n6186+L/B1/wCEtRaG4jdrZmxFNjKt6c9On9fStMPjKVdtQeoOLRzdFFFd RIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAdDprFfA2uMDgi9siD/wABnrLvNXv9QkR7q6kl ZBtUnsK09P8A+RE13/r9sv8A0Geqfh7TY9W1Y28rFUS2uLk4H3vKheXb7Z2Yz2zmqjKUHzRdmBn/ AGib/nq351IL+8AAF1MMDaPnPA9KsX13p91CPs2mrZSqf+WcjuHHvuJxjtj1NWLTT7S60nUFjlje /hSK5jO9hujztkiVSPmfLo3HAWNzmtni8Q95v72LlXYz/t95jH2qbG3b989PT6VH9om/56t+dR0U LF4hbTf3sOVdi7/a1/8A2c2n/an+yMctF2PO7+fNdb4D1W+1DxTbRXdy8scUMmxW6LwP8BXC113w 3/5G6P8A64v/ACrBtt3YzkaKKKQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfR/gz/khOm/8AXG+/9GNXzhX0f4M/5ITp v/XG+/8ARjVUPiRUPiRw+aXNNzRmvpD6AdmjNNzS0gHUU0GlBoGLRmkzRmkAtLTc0ualjFozRRSA WikzRmkMXNLmm0tS0A6koopCFozTe9GaAuOzShsdDTaOlKw7kgkPeneYvvUNGaXKh8zJwQehpagp wkI681LiPmJKKQOD7UtSygpKWkpAFIaWkoAKSiimAUUUUAFJQaKBCUGiimAUlBoppgKGKnIODViO YNgHg1WopSipAXalt7qW1fdE2M9QehqnHNjhjx61NXO4taMmUVJWZ09pfRXinZkOPvKe1WK5SGd7 eZZYz8w9eh9q6W2uVurdZV4zwRnofSspRseNisN7J80diak7UUGoOUSiiigBaQmg0lAwzRSUUDCj tRSUALmkopM0FBR3pKSgYuRRSUZ5oAXNGaTNLxQAuRRSUmaAHZ96XPWm5o/CgB1LTaXOKAFJpkh+ XFLUbnLfSkaRQClptLSNBwpc0ylBoAfSg03NLSAWlptLmgQ4GlFNpaAHUDpSCigB1JSZozQAtGab mgnFA7CMeaSkzzQDQXYXNANJmjtxTGOoz9abRQA7tQD2puf0pM0hi5oNNOKM8Uxi5pM0maTv1pDH ZopP50jMApNIdiGZstj0qLNKTkk96SqOhKyDvRSUGgYtFJSimAUUd6KAClpKBTGLRSUUAOopKUUA FKKKSgB1FJS0xiiikFFACilpKKQC1PZf8f1v/wBdV/nUAqey/wCP63/66L/On0Jn8LPL/jH/AMjy P+vSP+bV5/XoHxj/AOR5H/XpH/Nq8/rmPngooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAq/oQB 8QaaCMg3UWQf98VQrQ0H/kYdM/6+4v8A0MUAfWNpp1oLWLbEVG0cK7AcfjU39nW39x/T77fT1/z0 96ktf+PWP/dH+f8AP4d6m/z/AJ/z+lfJ1cXXVSSUnuzdRVir/Z1seNr/APfbf41Dc6Jp14oW4t/M AOQGdjg/nWh/n/P+f0xR/n/P+f1xWf1zEfzsfKjG/wCEV0T/AJ8E/wC+m/x/z19qP+EV0T/nwT/v pv8AGtn/AD/n/P60f5/z/n6d6f13EfzsOVGN/wAIron/AD4J/wB9N/j/AJ6e9fL/AIqsYtN8Uaja QbvLjlO3ccnnn+tfXP8An/P+f0r5O8c/8jrqv/Xb+gr0crxFWpWcZyurfqiJpJHP0UUV7xkFFFFA BRRRQAUUUUAFFFFABRRRQB0Gn/8AIia7/wBftl/6DPWdo2qPo+o/akjWQNDNA6k4yksbRvg9jtc4 PIBxkHpWjp//ACImu/8AX7Zf+gz16J4K0jwmPhhb6jrFjph1C61F7SK6v5GSOMY3bmwRuCjPHGSQ MigDzDUrnQ3hWPSdMvLdicvJeXizn2C7Y4wO+chu2Mc5q294LK9huLVZEKKA4ZwS2RhsHAwCCeOc Z6mvYPFGkeCz4A8TPpUGj3Go6cbd4b3TpGw0ckyrypY7WHIPJ6g8ZxXilAG9DeeFCjNc6Lq5lZ3b FvqkaIqliVADQMeBgZLHJGeM4qO9ufC72ci2OlaxDckfu5J9SikRTnuogUnj3FYtFABXXfDf/kbo /wDri/8AKuRrrvhv/wAjdH/1xf8AlQByNFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfR3g3/khGnf9cb7/wBGNXzj X0d4O/5IPp3/AFwvv/Rj1dP40VD4kcLuozTKTNfTWPeuSZFG6mZozSsFyTcKN1R5ozRYdyTd70u4 VFmjNLlC5NuHrRketQ0c0uUdyfNLmoM0u8560nALk1FReZ604OCOtS4sY/NLTaM1DQx+aKbmilYQ 7NFNpaQC0pptKaQBRRRQMM0uaSjNIBacHK/SmZpaQXJQwb606q9PV+xNS49i1LuSGkpe1JUFCUUU UwEoopM0CCjNJRQIXNJRRTAKKKSgYtFJW74d8J6n4lnxaRbLdTiS4k4Rf8T7D9KHJRV2RKagryeh hV0eieENf1cK1vYOtu3Sab5F+ozyR9Aa9X8P+AdG0IJIYheXY6zzjOD/ALK9B/P3rqa46mKT0ijz quYdKaPM7H4UEgNqGp4PdIEz/wCPH/Cuisfh9otipVTdS56+ZL/gBXVUVzOpJ9ThqYipUVpMxB4R 0QD/AI8yffzX/wAaik8GaO4+WKWP/dkP9c10FFTdmJx9z4CgIJtr2RD2Eihv1GKwr3wlq1kCwhFw g/ihOT+XX9K9NopqbHc8WYFWKsCGHBB7U2vW9S0Ww1VCLqAF+0i8OPx/xrhNa8J3elhpoc3FqOSy j5l+o/r/ACrRTTKUkc/SZozSZqixc0maTNJmgaQtGaTNJQMU0lGaTNMYtBpKKAFopKM0ALRSZooH YdRSZozQFh2eKTNNzSg0hpDgfWos5NPY4U1CzpGheRgqKMlmOABSLiPqO4uoLWMy3EyRIP4nbArk dY8bpGWg0tQ7dDO44H0Hf6muMury5vpjLdTvK/qxzj6elQ5GcqyWx6Be+OdNtyVt0luWHdRtX8zz +lYlx4+v34gtbeIf7WWP9P5VydFTzMxdWTN9/GeuN926VPZYl/qKRfGWug5N4G+sSf4Vg0Ursnnl 3Opg8earGR5sdvKO+VIP6Gtiz+IFpIQt3aywn+8hDj+h/nXn1FHMylVkup7PYatY6km60uo5eOVB ww+oPIq6DXhqSPE4eN2R15DKcEV1ejeObu1ZYtRBuYenmD76/wCP+eapSNY1k9z0fNLVWxv7bUbZ bi0mWWM+nUexHarINUbC0Z5pM0E0DDNNc8YzS1EzZJplpC5pQe2KZmlzxSKHZopufrRmgB2aAfSm 0tACnsaDTc0Z4oGOzxTT7UE0maBoKCaQmigqwuajmbChc9afmq7tlj6UkXFaiUlJRVGoUtJRQAtF AopgLRRSUwFopKKBi0tJ3ooAUUtIKKAFooFFAC0d6O1FMYo60UgpaAFopKWgBRU9l/x/W/8A11X+ dV6sWX/H9b/9dF/nR0Jn8LPL/jH/AMjyP+vSP+bV5/XoHxj/AOR5H/XpH/Nq8/rmPngooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigArQ0H/AJGHTP8Ar7i/9DFZ9aGg/wDIw6Z/19xf+higD67tf+PW Pj+EVN/n/P8An9OKhtf+PWP/AHam/wA/5/z+vFfF1v4kvVnQtgooorIYf5/z/n9eaP8AP+f8/wBa P8/5/wA/pzR/n/P+f6UAH+f8/wCf04r5O8c/8jrqv/Xb+gr6x/z/AJ/z+vFfJ/jn/kddV/67f0Fe rk/8d+n6oipsc9RRRX0hiFFFFABRRRQAUUUUAFFFFABRRRQB0Gn/APIia7/1+2X/AKDPWjHr+iXf w7svDd9LqFvcW1/Jd+bBapKjKy7QOZFOawNO1qbTrK5sxbW08Fy8cjpOhblAwXGCP75qX+3U/wCg Npf/AH5b/wCKoA1bXVtB0vwp4h0y0udSubnVIoI4zLZpEibJlkJJErHoCOlcnWv/AG6n/QG0v/vy 3/xVH9up/wBAbS/+/Lf/ABVAFPS7RdQ1aysmYotxOkRYdQGYDP616Hrnw00bS9S1rS4NZvbi90uw kvHcW6eQdq7thYOSG9iK4228SfZbqG4j0jTBJE6upETAgg5H8Vdle/GvVLvR9X01dD0qGLVfMNwy K+SzqFZvvdeO/wDKgDzGuu+G/wDyN0f/AFxf+VZH9up/0BtL/wC/Lf8AxVWLHxZPptyLiz03TYZg CN6wtnB/4FQBgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV9HeDv+SD6d/wBcL7/0Y9fONfR3g7/kg2n/APXC+/8A Rj1dP40VD4kcBmjNJRX1B7ouaKTNGaBDqKbRSAWjPNJmigY7NGabS5pBcdSUmaKB3FpabS5pDHBi KesgPWoqSk4pjuWaKhVyv0qUNkcVlKNh3FpaSkqLAPopuaWkwHUU3NGaQxaKTNGaBC0tNBpc0hi0 lFJmgCRXxwelSVBT0btUSXUpMfRRSVJQlJSmkpiCikzRTAKKKKACikrsvAXg8+Ir43d2pGm27fP2 81v7o9vX/wCvUzkoq7JqVI04uUifwR4Ck10rqGohotOB+VejTfT0X3/L1r2a2toLO3jt7aJIoYxt REGABT0RIo1jjVURQFVVGAAOwpk8ywx7jj0GTjmvNqVJVGeDWrTrS1+4lqNpo1YKXXcegzXJ6hr5 WUjzwCuVIB49QcfmPyrBvPEDGRbkE7ogcHOfbIH9fStoYSUtzqpZbUqHpQnjYgB1JOSBmnCRWIAY ZPQV5G3iC6llVIbmU7QVLE4LHdxn04zTv7Zu/tzotxK6gmKPa7ZUZwMk/n+FW8E11Ol5NUW8j1yi vMNN8XajZPtvLoS5JyjD7vHHJHrn8jWknxCi83y5ImUg4YEHPX/P6VlLCzRhPKcTF2ir+h3tFc9p /i/TL91WK4VmbBx0wD0rfR1kXcpyKwlCUd0cNWjUpO01YdRRRUmRx3iTwisqve6YgWUcvAvRvdff 2rgmyCQRg+npXt1cX4x8OB0fVLNMOOZ0A6j+8Pf1/OtIS6MuMujOEzSUUma1NQJoopKBi0hNJRQM M0ufem0UAOyaKTNFAC5opKKAFzRmkpKBodmlFNBpJJUgieWVwkaAszHoB3pDIb68gsbZp7iQJGgy Sf8APWvNNd8R3OsyGMZitVPyxg9fdvU0niPXZNaviVLLaxnESHv/ALR96xqylK5hOpfRbBRRRUGQ UUUUAFFFFABRRRQAUUUUAXdL1W70i7FxaybT0ZTyrj0Ir1HQ9dttbtPMiOyZf9bETyp/qPevIas6 ff3GmXsd1bPtkQ/gw7g+1NOxpTqOL8j2rNFUNJ1WDWNPS6gOM8OndG7ir2eK0O1a6oRjhTUWaVzy BTM0GiQ4UfjSZozxQMdRnimg0UAOyetFJRmgBaMjmk70ZoGGaSkooGhaKTNJmkUDNhTVepJDyBUZ NNGsUFFJS0ygooooAKKKKYC0UUUxhnmikpaAF/GjtSCloAKXODSUUDFpaT9aBTAUUtIOtLQAUuaS l96AClFJR3oAXvViy/4/rf8A66r/ADFV6sWf/H9b/wDXVf5ih7Ez+Fnl/wAY/wDkeR/16R/zavP6 9A+Mf/I8j/r0j/m1ef1zHzwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVoaD/AMjDpn/X3F/6 GKz6ltbh7O8huYseZDIsi7hxkHIzQB9jWv8Ax6x/7v8An/P59qm/z/n/AD+tfM0XxZ8VwxLGt3GQ owCUJP8AOnf8Ld8Wf8/UP/fB/wAa+aqZZiZTcklq+5spo+l/8/5/z+uaP8/5/wA/pmvmn/hbviz/ AJ+of++D/jR/wt3xZ/z9Q/8AfB/xqf7KxPZfeHOj6W/z/n/P6Uf5/wA/5+vavmn/AIW74t/5+of+ +D/jR/wt3xZ/z9Q/98H/ABo/srE9l94c6Ppb/P8An/P618n+Of8AkddV/wCu39BWz/wt3xZ/z9Q/ 98H/ABrj9S1CfVdRmvrnb50x3PtGBnGK7svwNahVc57W/wAiZyTWhVooor2TMKKKKACiiigAoooo AKKKKACuxsvCdhc2FvO8tyGkiVyAy4yQD6Vx1eu+EbFNTfRLGR2RLgQxMy9QCAMit6MYtu55mZVa kIxVN2bZzX/CG6d/z2uv++l/+Jo/4Q3Tv+e11/30v/xNeiQeG4kkvrvUbh7bSrWZ4ll2gyTsCQFQ dzxyegrPtNC1TVEkn07Tbqe3ViAyoW/DIHJ+lb8lPseQ8Ri1b3mcX/whunf89rr/AL6X/wCJo/4Q 3Tv+e11/30v/AMTXVwafe3MkscFrNI8X+sVUJK845H1IFS6ho+paT5f9oWM9t5gyhkQgN9Kfs6fY n63irX5nY4//AIQ3Tv8Antdf99L/APE0f8Ibp3/Pa6/76X/4mu2Xw3rTWP20aXdm227/ADPKONvr 9PeodP0fUtWLjT7Ge52feMaEhfqaOSn2H9axd0rvU4//AIQ3Tv8Antdf99L/APE0f8Ibp3/Pa6/7 6X/4mu90TRBd65Jp2oRzQNHDK7IRtZWVCwzkewqjp+kajqzuun2U9yU+95aEhfqe1HJT7B9axdla T1/Q5D/hDdO/57XX/fS//E1yusWUen6rNaxM7Im3Bc5PKg/1r1G5tZ7O4e3uoZIZkOGjkUqw/A15 t4m/5GG6/wCAf+gCsq0IqN0jvyzEVqlZxqSvp+qMmiiiuU9wKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvo3wf/AMkG0/8A64X3 /ob185V9G+D/APkg2n/9cL7/ANDerp/GvUqHxI8/ozSUV9Se2LRmkopALRSUtAC0maKSgYuaKSik A6jNJRQAtLmm5ozSHcdRSUZoGFOVtpptFKwE4YMOKWoAxByKlDBqzlGxSY6lzSZorOwx2aKbS0rA LRSUUgFozRWgp0ldIsIruT7Lf315cRQXUj4i/dpCRG+eFyZDh+gPXg5WJzUFdkTqRgryKFFOmhlt p5IJ42jljYq6OMFSOoIplUWLmjNJSUWGTq2R70tQq2DntUuazkrFJgaSlNIaQxKSiiqAKKQ0ZoAv 6PpdxrerW2n2w/eTPjdjhR3Y+wHNfRWl6bbaPpkFhaJthhXaPU+pPuTzXA/CbQxDYz63Mn7ycmKE nsgPzH8Tx/wGvSHJEbEDJArzsTU5pcq6HjY2tzz5FsvzIrrzDbs0TEOvIGM5x2rz678SllkhuJlR sEEMcEZ5B/z7V1Fpf3NveTS31xFHY4O0yPg7vbKjI69zWL4w1Hwjny9QtRdXsqgj7OMSjjjLDBH0 P5VVFqnK0o39DowFO1XklByv26HKXl3bylwbgbmAGE5G4Hnj35/HHpWZMpeaWKO4WSBcDK/KDn+S 8gH69qnXRre40uW90i4lltCWSZJ1Aa1bB27m7qeQTxjIzTLEXF5BE0FqWE8rxuduMgCM7QfXgjPv XoOpde6fUQUIJ8r20d9Lf8HT9SNY7h4i0axKyL8zMxyvXHH+eQfXmxdM0MxjkdleAOZCEEZZQPlx znljzUt3pNwgu7NInH2uJWt1Hznh9+C+Ou3dwT0/WtewTLca2giERjjSXa2Tty8eVHvkn9c1zyqW 1aCEo1JLVf8AD2X5t/cQTvGjGKSf94PmkUrhWOCTk5wcccd+fWmXNo+xVRv3m/G1gQT8xCqf9onJ Iz0P0rQixDpsPiZ7dHtbYC2ghGQWnUna7g9cDnr2ArPsrWbcWmuFO6ISTMSfLiLLlQxPc8dOR29a z9pGTaNYz0bvt+fVfLT5uyKUUohvpFgeRmVvvZC56bmA45/kK9R8D6vLNM1nMzMCmVyc4I6jn8Pf nJwTiuRs1SdMGLPlhiodsMpICmR85+UHCgDOcD0zW5oFzaWWpQSqUFtkIZ5AMs3ouBwBnPqc5Jqe V8rjujzszkq9Jx5dUj0yiq8F7bXIzDOj844Ptn+o/OrFcTVj45prRhQQCMEZBoooEeV+K9F/sjUy YlxbT5eP0U91/D+RrBr1vxLpY1XRZolXM0Y8yL/eHb8RkfjXkdbwd0bwd0LSUZpKssCaKTNJQOw6 jNJRQAtFJRQA6kpM0E0AKTSU3PrS0irDhXE+N9aJYaVA/Aw05B6+i/1/Kut1C9TT9Pnu35ESZx6n sPzxXkM80lzPJPK26SRizH1JrOb6GVWVlYjooorI5wopyI0kioilmY4AHc11dh4at4ow13mWQ9VB wo/xoA5Kiu3m0DTpkIEPlt2ZCciuV1LTZdNuNjncjco4HUf40AUqKKmtLZru7it06u2M+g7mgCSz 0+5v3KwRlgOrHgD8a1P+EVutufPh3enOPzxXT21vFawJDCu1FH5+9S0AcBe6bdWDATx4U9HHIP41 Ur0aeCO5haKVQyMMEGuBvrVrK9lt2Odh4PqO1AFeiiigDb8Ma02j6mvmMfssxCyjsPRvw/lmvVcg gEcg968Pr0zwhqpvtE8qQ5mtv3ZPqP4T/T8KuL6HTh568pvMcuTTabmlzVndYcKM03tS5oCwppab mlzSCwuaWm0v40DDNFFJmgBc0nagnikzSKQufUUmaQU1zhcUikiNjk5pKKKs0DtRRRQMKKKKBi0U UUxB2ozRRTGHalpKKAF70ZoooGFLSUtMBaKKKAFpabS0ALRSUtAC0CiloAKsWX/H9b/9dV/nVcVY sv8Aj+t/+uq/zoexM/hZ5f8AGP8A5Hkf9ekf82rz+vQPjH/yPI/69I/5tXn9cx88FFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFdx/whunf89rr/vpf/ia4evcfDOkwa3rsVjcyvFCyO7PGASNqlu/ 0rejGLTcjysyq1YSpxpOzd/0OG/4Q3Tv+e11/wB9L/8AE0f8Ibp3/Pa6/wC+l/8Aia9APht/+EwG hiXMZl4m/wCmWN2//vjmjXfD32LxH/Zeli4vN8aPGAmXYMoboK35KfY8t4jGJN8z0dvmef8A/CG6 d/z2uv8Avpf/AImj/hDdO/57XX/fS/8AxNdhqOi6npOw6hYz2wf7pkQgH6GpbTw7rN/a/arTTLqa Ds6REg/T1/CnyU97E/WsXfl5nc4r/hDdO/57XX/fS/8AxNH/AAhunf8APa6/76X/AOJr0DTdEtP7 IbWNYuJoLPzfJhigUGWZwMnGeAB6mnXei6fc6NPquiXFxJHbMq3NvcqBJGG4DArwy549qXJT7FfW MXa/P5+djz3/AIQ3Tv8Antdf99L/APE0f8Ibp3/Pa6/76X/4mvRzo+jaZptjPrE98897F56R2iph EJIGS3UnHQVh362aXkgsJZZLXgo0yBX6DIIBI4OR+FNQg+gp4rFQWszyrWLKPT9VmtYmdkTbgucn lQf61RrW8Tf8jDdf8A/9AFZNcU1aTR9Jh5OVGEnu0vyCiiipNgooooAKKKKACiiigAr2f4f/APIX 8Nf9dLf/ANlrxivUtFmlt9N0+aGR45UhjZHRiGUhRggjoa6KCvdHkZtLlUJdmeja+F8YyzpaHy9V 05pI/sQPyTxhj80Y7P6jvVDxDHevYeGf7PSc2wskEQhB4uNx8zp/FnFcqlzcR3QuUnkW4DbxKHIf d656596uQa/rFr5vkapeR+cxaTbOw3MepPPX3roUGtjyHiIzu5LV9jutQuHtta8VzQSBLpdMjEzx nGJTsD4x35P41zMMjy/Dq8WRiwi1KJkyc7SUbOPrXPpdXEYmCTyqJhiXDkeYM5w3rzzzSC4mW3a3 E0ggZg7RhjtLDoSOmeaFCwTxPM727/idu8MHivU5RPb6lpms+QdzHmD5E7ggMgIGO45rOvVnk+H2 jCyV2hFxP9rEY/5a5Gzdj/Z6VjTeINZuLU2s+q3skBGDG87EEeh55FQ2Oq6hpjO1he3FsX+95UhX d9cUKLCVeDvfru/uf6fM9ATePEGjrdZ+3jQ5Bcbvvf6t9u7/AGtuOvNZkQsW+Hum+ZbahPCtxN9q FlKqBZMjbvyrZ+XGPxrjxfXgunuhdTi4fIaXzDvbIwcnqcin2Op3+mSM9jeT2zMMMYpCufrjrS5C vrSu9N7/AKf5amp4n1Bb86cFsru38i28pXu23PKoY4OdozjkdO1eOeJv+Rhuv+Af+gCvS7u+u9Qn 868uZriXGN8rljj0ya808Tf8jDdf8A/9AFZ11aCR2ZXPnxMpeX+Rk0UUVyH0AUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfRvg/ /kg2n/8AXC+/9DevnKvo3wf/AMkG0/8A64X/AP6G9XT+NepUfiR59RSUV9Qe0L3opKM0AFLSUUAL RSUUDFooopAFGaKSgBaKKKBhS0lFAC5opKM0DuLRnmiikMkWT1p4IPSoKKhxHcsZpc1AHI704S+o qXBjuS0ZpgcH2pQc1DiA7NLrPhnUPEnhrSY7JUAiv7wF5G2hpGjttkY9XYggAc8E9ASG0FpCiKJZ AsbF0AY4RjjLD0Pyrz7D0rCtS9pHlMq9L2seU0IHtP8AhD9N+0395fX7QIbec2ioEQEq8MjeYSxQ ghTtBAwOhXbQqxd3zXnH2S1tlM0k7rbqwDyPt3sQzHGdo4XCjnAGTVelRg4QSYYeDhTUZBS0lFam wtPVsHBPFMBopNXGTUhpqt2/KnVnaxQlJS00mmAE06KN55UijXdI7BVA7k9KZXQ+BbMX3jXS4mGV SXzT/wAABYfqBRJ8sWyJy5YuXY960rT49K0m0sIvu28Sx59SByfxPNWLhS1tIFGWKnA9akoNeNfW 587d3ueQ6lcTm7O7cVVgUUn92AOQWPoMHAHGR0rEuY4HtJbqQs1y7gtKwG5j3JzyAM9B6813HinS Ik1VFht/9YjOiq20EjkjGDk57ehrgnl2XBCA+ejMykj51J6nvnH9O1etG0oqSPtsBNVKalDQuWmr z+GdVhmtSFtLlB51vNyJVHBJHUZ7EivWtIttJubb7XYrDJBLJ5sewfKjbdpwOx47V4W8YRne/uJJ S5H7mJstJ3+Zvz9/oOa9D8C+JQt/FoiQJFb7HZIooT+6A53M+45B55PcjmuGq27vYxznBudH2tP4 lu+6X4trv/wx6B9htt0R8oYh5jXspxjOPXFY+veFbXVbO/EAEV5cxCPzGJ28MG5HuRyetdACCMjp S1gpyTumfJ069SnJTg7Nf8OcB4k8MzQeDNN0O1YfZ4ZA1xcEfcwCWf8AMk/kK8/N1bvdXVxNDMqR sGgiAYBkwFXp0GAuT1b1Hf3LV7AanpdxaEgGRCASMjNcTHpTzTy2ptZLcJGo854QqunTYOmGGSAf p6A1tCSav1Pey7MuWnJVNXdvtu1d/M4iO9sBBGJpJVTKu7kYM23ICxEY8tRyMnP6VqWyKvlXUuVP ysBGuNhONrlc88kf75z0wSXajarLG2wASeWrhGP7uyjJOC5xu3g7sAcnPfNZ8LpJax2yLst44t8t 3KhBdM7RKeeSCCqKOnXryFzWeh67casbx07/ANf1fS2ljcSURw71up47z5mXKhVYE8qem0g9u2ee cV03hnxN9pijguNyzZI2vwQuf1+tcJcXVvEiiZJpbUFQTvLxBscSBeA7juMYGPfNO0+/NjdM8hDt G2AXfKuVAIBYdiMAAcDAzT5lLRnHWwSq0mmteh7UrBlDA5Bpay9CvlvrAOoI2nBBIOOPatSsJKzs fJzg4ScX0CvIfEtiNP1+7hUYQv5ifRuf06fhXr1effES32Xtlcgf6yNkJ/3Tn/2arpvUdN6nGUma M001udAuaTijNFAwpabmloAWik5ozSEOppPNBOAabmhjQuaUUgpako5Lx3elLS3slPMrF3+g6fqf 0rhK6DxlcGfxDImciFFQfln+tc/WMndnJUd5MKKKKkg2/DECyai8jDPlJkfU8f4119cd4auVg1Mx scCVdo+vUV2NABWV4hgWXSJGI+aMhlP44/rWrWP4kuVh0tos/PMQoHsDk/596AONrX8NAHV1z1CN isirOn3X2K/huOyn5h7Hg0Aeg0U1HWSNXRgysMgjuKdQAVx/icAaquOpiGfzNdezKilmICgZJPYV wOp3f27UJZx90nC/QdKAKlFFFABXQeD702utrEThLhSh+vUf4fjXP1Nazm2vIZ16xur/AJHNNFQl yyTPYO9HakByoI6HpRWp6w7NFIOaWgApabSigB1FJR3pDFpCaM02gaFzxSdqKBSY0LULnLU9mwKi NCNIoWkooqigpaSigApaSigYtLSUUxBRRRTGFLSUUDFpaSlpoQUtJS0DCloooAKWkpaADtS0UDrQ AuOaKBRTAWrFl/x/W/8A10X+dV/wqxZf8f1v/wBdV/mKT2Jn8LPL/jH/AMjyP+vSP+bV5/XoHxj/ AOR5H/XpH/Nq8/rmPngooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr3/wH/wAjVF/1wn/9FNXg Fev29zPayiW3mkhkAIDxsVOCMEZHtXTQV1JHjZrPknSk+jf6HWLrVh/wi/2wzf8AE6FodNEeOfLz /rM/7mUq/qWmpqXjWVZJJ1SDS0nZLc4klCxL8i+5z+Wa8/qyNRvheJeC8uPtKABZvMO9QBgYOc9O K35Ox5SxN0lNdvwv+J2LLBN8O9Xkg0y5s7dbiAxefcGUM24glcqMcHBI659qqeNI72TxHC1mk7WR gh/s8xAlfL2D7uPfNc7daxqd8JBdahdTCQKHEkrEMByMjPYk4+tPtdd1aytjbWup3cEB/wCWcczK o/AHihRadxzrwlHld+nbpfp8zcuYJdW+H+mGzRpX0yeZLmNBllEhDK5HpxjNGiwS6X4U12+vI2hi uoVtbdZBgyuWySoPXAGc1zdpfXdhP59nczW8vTfE5U/mKdfalfalKJL67nuXAwDLIWwPbPSjle3Q j20fjtra3lta/wBxv2Os61ZWFrZXekRahZEbreO7tS/ytz8jDn+dVvGWm2ul66IrSIwJLBHM9uW3 GBmGSmfb+tUbXxBrNjAILXVbyGIDARJ2AH0GeKoSyyTStLK7SSMcs7nJJ9SaajZ3FOqpU+Xd+fQ8 48Tf8jDdf8A/9AFZNa3ib/kYbr/gH/oArJrgn8TPqsL/AAIei/IKKKKk3CiiigAooooAKKKKACun tfGH2azgt/sO7yo1Td52M4GM/drmKKqM3HYxrYenXSVRXsdb/wAJt/1D/wDyN/8AY0f8Jt/1D/8A yN/9jXJUVftp9zn/ALNwv8v4v/M63/hNv+of/wCRv/saP+E2/wCof/5G/wDsa5Kij20+4f2bhf5f xf8Amdb/AMJt/wBQ/wD8jf8A2NH/AAm3/UP/API3/wBjXJUUe2n3D+zcL/L+L/zOt/4Tb/qH/wDk b/7Gj/hNv+of/wCRv/sa5Kij20+4f2bhf5fxf+Z1v/Cbf9Q//wAjf/Y1zup339o6jLd+X5fmY+Xd nGAB1/CqlFTKpKSs2a0cJRoy5qcbP5hRRRUHSFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX0b4Q4+Atgf8Aphf/APob185V9GeE f+SCWH/Xvf8A/ob1dP416lR+JHnYcHrTqgpyvivq3HseupEtLTQwNLUMq4tFJRQMWkpaSgApaSig BaKSikAtLTc0tAwoNFFAwpaSigBaWkopDFopKXPFABRSUUALQDSUUhjw5FPEg71FRmpcUwuT5B6G lzVfODT1k9fzqHAdyWikBpaixQoNGaTrRmpsApp4fjBplGaTQyTPGaaabnFLnIpWHcXNdx8J4hJ4 xdj1jtXYfmo/rXC5rvvhEwHi64HrZOP/AB9Kyr/w2YYn+FI9roooryDwSlqdkL21IA/eoC0Tf3Wx XjHiGO7s9XnxI0KPxMcFsY7H1z717pXCePtCe5thdW6n7wabAJBAB5I79q68LUV+SWzPayXFqjX5 J7M86SYXNswj/cKcrLKRkqD/AAhQfvNj8cdgKbLujtIVRG0/T2UlVVyst0Rxkk5yMj0x1AFZq4aa MJvlibJkiztwccnJ+nX0rXh0ya/uBDHI0jeUF8xzjGCO5+4o4z3x1IqqtNyZ9jUjCk7t2W/9ef8A S6s9H8C69PPGui3yyC5toQyPIMGRO3HXgYrtq8G0bxJH4f1R7m0t1kkzsmkd8l1GPlj4xgkZzjNe 5Wdyt5aRTqAN6glcg7T3Bx3Fcktz43OcFKhW9olaMvz66E9RzQpOmyQZXOcZqSipPG2OW8RabKuZ bOxS5Ihf906bldjgEkkjD7cYY54yOK80exli8vTopneSFl3NGRIGfqsSYGGIyfbJJOAK9zIDAggE Hgg1554z0PSdEgOrmGUQEiL7JalYlZmPLMepzgA45x+NaRqW3PdyrGtS9i93t6nGW7KbdbSdZb+6 PG+GQs1sQSSqdQe+7+E49snP3yQ/JFMWQMqDgMAR90E/ngDjPetC6sNTvZ0u7WE2kEsKjzpWEEWw DnC/eK4x6knnvUdzk3KLLOt1JkbLhQd0irjkAAgcc8/NxzjpTik3Y+mpyje6d76tdn+X5Hovw9lL WlypEmcqQzYAxzgD/EknpzXbV514DmeK7a2LKFMe5QFC555JGSa9Fp11aZ8ZmkeXFSfcK474hxg6 VaSd1n2/mp/wrsa5L4hH/iR269zcg/8AjrVnD4kcMPiR5sTSUUhrpOoKSiigYZpc02igQ4UU2lzQ AE0lJnmikXYdS02lFSB5VrzmTXr5j2mZfyOP6VnVe1kY1y/B/wCfiQ/+PGqNYPc4XuFFFFIQoJUg gkEcgiulsPE6iMR3qNuHHmIOv1FYNrY3N62LeFnx1PQD8a1ovCtywzLPEnsMtQBpT+JrKNCYhJK3 YYwPzNcxfX02oXBmmPPRVHRR6CtlvCkoHy3SE+6EVnXeh31oCzReYg6tGc//AF6AM6iipYLaa5fZ BE0jeijOKAL2m61cacPLwJIf7jHp9D2rY/4Sq22Z+zzbvTjH51nQ+GL6QAyNFF7Fsn9Ksf8ACJy4 /wCPtM/7hoAo6lrlxqCmMARQ/wBwHJP1NZdbU3hi+jBMbRS+wOD+tZU9tPavsnieNv8AaHWgCKii igAooooA9b05zJplrIerQo35gVaB5qlpI26NYg9reP8A9BFXM1sj2I7IWlptLQMWlpvalBoGLmjI pM+1BoAM0UlFIYUZpKQnApFIaxyabRSUy0LRRSUIYuaKSimAtFJS0xgKKKTvQAuaWm0tMBaKSlFA xaO9H40UxC0UlKKBjqKQUtABS80lLQAtApKUUwFopKWgBansv+P+3/66r/Oq9WLL/j+t/wDrqv8A Ok9iZ/CzzD4x/wDI8j/r0j/m1ef16B8Y/wDkeR/16R/zavP65j54KKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAK63/AITb/qH/APkb/wCxrkqKqM5R2MK2GpV7e0V7HW/8Jt/1D/8AyN/9jR/wm3/U P/8AI3/2NclRV+2n3MP7Nwv8v4v/ADOt/wCE2/6h/wD5G/8AsaP+E2/6h/8A5G/+xrkqKPbT7h/Z uF/l/F/5nW/8Jt/1D/8AyN/9jR/wm3/UP/8AI3/2NclRR7afcP7Nwv8AL+L/AMzrf+E2/wCof/5G /wDsaP8AhNv+of8A+Rv/ALGuSoo9tPuH9m4X+X8X/mW9Tvv7R1GW78vy/Mx8u7OMADr+FVKKKzbu 7s7IxUIqMdkFFFFIoKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAr6M8I/8AJBLD/r3v/wD0N6+c6+jPCP8AyQSw/wCve/8A/Q3q6fxr1Kj8SPNqSlor649UOlPV /WmUlJq47k+c0tQKxFSqwNZtWKTHZopKKQwpaSigYtFJS0AFGaSigB1FJRmkAtFJRQMWiiikMWik paACikopDFoopKAFooooGFFFFIQ5XK/SpQcjIqClVipqZRuUmT5opAQRkUVk0ULmlzTaKVgFzRSU UWAWux+F90LfxxbITgTxyR/+O7v/AGWuNrQ0LUP7K16wvySFgnR2x/dzyPyzWdSPNBoirHmg0fTl FICGAIOQeQRS14h8+FMmiSeJo3GVYYIp9FAHkfjnwwuk3iX1lGDHcPtMYAPOOf8AP/1q543EUNqb SDEwfDSAcNP369lXHQ+vPI49x1Owi1GxktpQCrgjOMleMZH5mvEtb0eXw9qk1vIAtphWlm27tqk8 L2444HcjnpXX7bmhd7o+vynHLEwVKq/ejt5/8N0IrxBqUMlrp1rHcXgizcTnGyKMHICFj0GeXPJ+ leleA3/s3w9aW896kkDkrCzqULOTyqAjLL3De57VwlisLi3e5iZdPLecbYHD3D4yqt6jjcx4Cr0A zzv3GvJdx22rSxf8TUIHgsy5PlRsNu9F/vEcjI4ByawnBc1yswjKtTVBL3b3+fT+lol3PT9wzjIz 6UteJaXr76Pqs11JqE09vbMvny7siRwH/dISMkEkHnoAfau1034hwGKEatElvcTMSIo23GOPszDr znOPQZrJNNaHiYjJ69LWHvL+nsdxVXUY0azkdrNbx4wXjhKqdzAcY3cA1OsqOcK6k4zgHnFOPSme Unyu54Lq7PdeIp7nV742Mch3KoKyzRjkbflwMg8ewrOEWngtJY3LvGoBf7SQGZ84+UAY6f8A662t UtNL0zVr6eOyvpYTO0fkKWURt1yHGeM59D05qksu6WM21pBBFKMIZAC7ADOQxIb6H8M1dOL59d0f odGpemnG6Vl2S9Lav8zpPCTmLxFaO8p8twUXLjqR7E9/THWvW68c8NxquqwS48ySFgzIUYc8HOR/ nivYkYOgYdCMit8UtUz5XO1++i/IWuH+I0wEFhBnlmdyPoAP613FeYePLv7R4g8lTlbeNUP1PJ/m PyrCmryPIpq8jljSGlpD0roOoKSikoAWkzQaSgB1IxwKM0xj81A0FOFNBpc0ihwPvThTO/alzgE1 IWPMfE0Xk+Irwdiwb8wDWTXT+NbbZqEFyBxKm0/UH/AiuYrCW5xVFaTQVtaJov24/aJ8i3B4H98/ 4VlW0JubmKFersFz6V6FDEkEKRRjCIMAUiBY40ijCRoFReAAMAU6iigAqrqF9Fp9qZpOT0Ve7H0q 1XK3u7WPES2uT5MR2nHYD7x/p+VADbDS5NYuXvbkCOFmzhBjd9Pb3rqIIIraIRwxqiDsBTkRY0VE UKqjAA7CnUAFFFFABUc0MVxGY5o1dD1DCpKKAOP1jQjZA3FvloO4PVP/AK1YteksqupVgCpGCD3F cHqtl9g1CSEfc+8n0NAFKlAJIAGSelJWhodqbvWrSLGR5gZvoOT/ACoHFXdj0+3jENvFF/cQL+Qq SgUVsewhaXtTaWgYtHakooAXNFJRQMXPFJSUZpMYU1jk+1KTjmmd6SKQUlFFMsKKKSmgFo70lFAB S0lLTGFFJS0wDvS0lLQAUueKSimMXPFFJ3paAFpRSUUAOFLSZoFAC0tNpc0ALS0lFMBaKKKAFFWL L/j+t/8Arqv8xVerFl/x/wBv/wBdV/mKT2Jn8LPMPjH/AMjyP+vSP+bV5/XoHxj/AOR5H/XpH/Nq 8/rmPngooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr6M8I/wDJ BLD/AK97/wD9DevnOvozwj/yQSw/697/AP8AQ3q6fxr1Kj8SPNqKKK+uPWCkpaSgQlLnFJRQBIsn rUlV6crkVDj2GpEtLTQwNLUFi0UlFAC0UUUDCiiikAUtJRQAtFJS0hi0A0lFAC0UlFIYtFFFAwoo opALRSUtABRRSUAOVsGpc5qGlU4PtUtXKTJc0tNozWYxaWkzRQAveikopDPoX4f6yNZ8I2jM2Z7Y fZ5eecr0P4rg11FeD/DTxINE8Qi1nfbaX2I2J6K/8LfqR+PtXvFeNiKfs6j7M8TE0vZ1H2YUUUVg c4Vnaxo9rrGnyWtzErq3IyOh7GtGimnbVFQnKElKLs0eH6r4Yv8AQb+UQFriPaVVJB8rjOdg54AA LMeOOD1rOjupPtTMl5IkzoWnu8YklDZGyMHsef5nivddR06DUoBFOuVByP8APp7VwfibwHuD3dii lsZlQAgy/l+vtW0eSXkz6nBZzCraGI37/wCf9f8AA4Z42TS1meNFtYWf7JFGwCtLgAyHu+OAPUg9 himBGjlOpHNzFGwlt94G+4kwAcgdUBBJ7dsnJqDULO8W/D3ttKCjAMFyASP4F7dscdOatQrNcQvc NGWZzgIvCWqbTx1znAOB2Hu1TKhrse7ooc107/r0/wA3+rQuj6tf23iUXUV5LJFIPPld3JKRDlyw 7HuB6kCvS9N8dLPCLq5jUW7IZjsOTFH2ZvxDD8vWvNW06e0i+ytIyvclUuXzzHF94KffA3MPYDrV /TPL06zItbNZ3u8goThmgB6fUkAf8BNFPDzWjODH4WhiUpW10S6aev5enmHjfSjb63Pd200n2G/U 3UMsakxscZZcDvxnmsu0VpWEKwsjD5pApAA6EE8YznHtXZ6Hbi40258K3kJjmuFd7YMBILU7flzn vjk4/rXFWq3enXMkFxJ9nmtpPLkhXqxGc8+n+NdNCKVS1tTbC1XKm6Ld3C1vNdHp93rqdZpEh+Zd sYAI4aJevH8S9q9XiJMSFvvFRmvJ/Dtqt1dSTIhVdwKqgK8k9+xr1pRgAVOMSTSPmM4sqiS/rYju biO0tZbiU4jiQux9hXil5cveXs11J9+Vy5/E13fj3WBHbppcLfPJh5sdl7D8Tz+HvXnxrKkrK551 JaXG4pKWkrU2EpD1pTTc0DCiijNILATgVHQxyaT8aCkhckUo60lFIY8UjnC49aQU1uTSGtzG8TWR vdFkKjMkJ8xfw6/pmvOq9dOCMEcV5rrumnTNTeMD9y/zxn2Pb8Kymupz4iH2iDS547fU7eWU4RW5 Pp2zXeI6SKGRlZT0KnIrzeiszlPSqK81ooA9KrktKnjtPENx9pYJuLpuboDu/wDrVhUUAekqysMq QR6g0tea0UAelUV5rRQB6VRXmtFAHpJYKMsQB6muO8R3MNzqCeS4fYm1mXkZyax6KACuv8E2PzT3 7jgfuk/mf6VylvBJc3EcES7pJGCqPevU9Ps00+whtY+iLgn1Pc/nVRWp04WHNLm7FugUlL2rQ9EW ikpaAFpKM0UDCikzRmgYtIaKQ0ikIxptBNJQULSUmaKYxc+9BpKKAClpKKYxaKSlpgFFFFAxaKKK YhaKSgUDF70ZoopiFpe1JS0gFopO2aXvTGLxRR0ozQAtFJS0DFozSUtMBasWX/H9bf8AXVf51Xqx Y/8AH/bf9dV/mKT2Jn8LPMfjH/yPI/69I/5tXn9egfGP/keR/wBekf8ANq8/rlPnQooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKK7L4d+BpvGutGN2aLT7fDXEo/RR7mu0+LPw0ttJ0+31fQbXy7aBBHcxJy QB0f/GuKpj6MK6w7er/r8S1Tk48x4zRRRXaQFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfRnhH/kglh/173/AP6G 9fOdfRnhH/kglh/173//AKG9XT+NepUd0ebUUUV9cesFJS0lAgpKWkoAKSlpKBACQalVwetRd6KT Vxp2LFFQq5XrUgYNWbi0WncdRSUUhi0UlLSC4tFJRQMWikzS0ALRSZpaQwooooAKWkopDFopKWgA ooopDCiiigAo70UUAPVuxp1RVIrZqGikx1FJRUjFoNJS0gCvd/hz4vGv6WLC7k/4mVqoByeZU6Bv r2P5968Iqzp+oXWlX8N7ZymK4hbcjD+vt7VjXoqrG3Uxr0VVjbqfUtFc14P8YWfiqwDKVivox+/t 89P9pfVf5V0teNKLi7M8WUXF2YUUUVJIUEA9aKKAK01hbThhLCrBgQQRnIPWst/CmnCUy26tAxYO Qh4JGSDj1yc/gK3aKpTktmaQrVIfCzirnwq8dm0EkS3MTu0kuCd0hwccnpngH6CsGS1jjklljbEa 4BtWU/Lhdsa+u3k/99eor1Oqd1plvdA7l2Of404J9j69TW8MRr7yO+jmM46T1PMJJ49M1iG9aQm6 ecNM6tuZY0AZlABwNx7e4qLxzpZh8QpqsUL+RfRJNnABDjAI+uMfma2/FXh+e1he7VfNt9rLKqj5 trNkgf57VtvpNt4p8KwW0s3+k2w8tbjy8bJVG1iBxxWvtIxkp9D1IY2FJ08QnprF+nT7tDL+H9qs sVxKVKBSF2+nt9O9dVr2uWnh/TGvLt1HISNScb3PQf1PoAayNNNt4L8PTPqkscaxH5mSPb5p7bR1 Yn6/lXjfivxRd+KdVNzNmO3TKwQA8Iv9Se5oVJ16rf2Tza0PreJlNfD3OhvLqW+u5bmdt0srbmNQ Gs7Rr0XNr5TtmWPjk8kdj/StEilKLi+VnPKDg+VjT1ptONNNIENNJ3pT603vQUBpCSKM00nikNIb 3ooooKFopKWkA6mHk0ueKbSY0L7Vma5pS6tYGMACZPmib39Poa0qWk1cbipKzPJJI3hlaORSrqcM p6g02u88R+HxqCm7tQBdKOV/56D/ABrhGVkYqwKsDggjBBrBqx59Sm4OzEooopGYUUUUAFFFFABR RRQAUUUUAFFFdN4b8OtdMl7eIRAOUQ/x+59v500rlwg5uyNHwlopt4/7QuExK4xEp/hU9/x/l9a6 mkHFFapWPVhBQjyodmgUlLTLFopKM0ALmim5pc0DCikozSGkGaRjRmmk0FIKSikzQMWg0gooGLSU UUDFpKKKoBaKSigYtLSUCmAtFFGaLAFKKSlpgL3opKUUALS0lFAC5opKWmAtLTaWiwC0tJRTAcKB SUooGLU9l/x/23/XVf5iq9WLH/j/ALb/AK6r/OhrQmfws8y+Mf8AyPI/69I/5tXn9egfGP8A5Hkf 9ekf82rz+uM+dCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAorsvAfgK68YahmQvBp8ZH mzBcnHoPf/P09P8A+FFeHf8AoKaj/wB+U/8Aiq56mKo05cs5JMai2fP1Fe9XvwL0YWUpstTvTc7T 5YkiXbntn5q8R1PTLvSL6SzvIjHKhII9aulXp1b+zd7A01uU6KKK1EFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABW94U8MXHibUxApMdsnM0uPuj0HvWDXuvgnTU0nw9bRqv72VRJIe5J/8ArVwZ hiZUKN4bvY9DLcH9Zq2lstWcNf8Aw/nvPGtxpelxmGxhWMmeTJVQVHfuSc8Vx2pWYstVubONmkEM hjDY5bBxmvpyBJANxiJH0rn7rwhZxXk19YWyCaVi8gIy2fauHKczhWrRo4mfKrWu+/n6nbiMrj9h 9TU+E9hBo/geyUbRPdZuJvXLdM/RQK7yYRXMLxSorxupVlYZBB7GvICkkEvV4nU9RkEV3vh+4vXs 1M08d1Dj5ZlPI9mFHEHD8sGvrSq8yk+1vueqf9WB0IxikmeMeOvhbdaZ4gzo6b7G73NAhPKuBkx5 9+cevSvMnRo3ZHUqynBUjBBr7IuoYr6ARydQwdW7qwOQRXz38ZNAj0jxf9rt0CQ3yebgDgP0b/Gl lWZSrNUam9t/Q83EYfk95HnVFFFe8cgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX0Z4R/5IJYf9e9/wD+hvXznX0Z4R/5 IJYf9e9//wChvV0/jXqOO6PNqKKK+uPWCkoooASilpKACkoooEFFFJQAUm4g0GkoESrL61ICD0qr ShiDxUuJSkWqKhWb1qQMD0NQ00UmmOoooNIoWikopALmlptLQMWikopAOpKM0UDFopKWkAUtJRQM WikpaQBSUUUDClBxSUUCJAcinVEDg08HI4qGi0x1FJmlqRhRRRQBYsb+60y8iu7Kd4biI5V0PI/x +le0+EfiZY6ysdnqpSzv+AHJxHKfY/wn2P4HtXhtFY1qEaq13Ma1CNVa7n1hRXz34d+IWt+HlSES i7s148ick7R/st1H6j2r07Rvil4f1MKl1I+nznqs4ymfZxxj64rzKmFqQ6XR5lTC1IdLo7aioba7 t7yETWtxFPEejxOGB/EVNXMcwUUUUAFFIzKilnYKo5JJwBXMav8AEHw3o6sJNQS4lH/LK1/eEn0y OB+JFVGEpO0VcqMZSdoo6cgEYIBrlvEPivRPB1uUZg90SXS0hPzMT3b0HufwzXnHiH4tarqIeDSo hp8B48zO6Uj69F/Dn3rz+SV5ZGkldnkY5ZmOST6k130cDJ61NF2O2jg5fbenY3PEPifUPE999pvZ MIuRFCvCRj2Hr79ax6iVsH2qWvRUVFWR6kEoqyJ7O6azuUmXnHDDPUeldgrrJGsiHKsAQfauIrb0 G8+9aOevzR/1H9fzrnxFO65l0OfE0+Zcy6G4etNNONMNcJxIYeaQ040w0FCZppNONM70FIKKKKRQ UUUUgsB4pBQetJSGkL3peMUlFIYtYut+HoNUBljxFdD+PHDex/xrZoqWrilFSVmeWXthc6fOYrmI o3Y9m9we9Vq9XuLaC7iMVxEsiHswrmNQ8GKSXsJtv/TOXp+BrNxOOphpLWOpx9FXbvSNQsifPtZA o/iA3L+YqlUnO01uFFFFAgooqe2srq7bFvbyS+6qSB+NA0m9iCnxxSTSLHEjO7HAVRkmujsfB1zK Q15KsK90X5m/wH611VhpVnpqbbaIKx6ueWP41Si2dFPDTlvojB0TwoIitzqIDN1WHqB/vev0rrAA AB6Un40ua0Ssd8KcYK0QpaSj1pli96WkzSZoGOzRmkooAKM0UZ5oGLTc5ozSGgpATSUmaKBhmikp CaQxaWk7UZpjCiikpgLRSZpe1MYZpaSinYBc0Ckpc07ALRSUZosAtLmkzzQKBi0optLTAdnmikpa LALS02lp2CwtLTaUdaLAOopKM0AOopKKdgFzVix/5CFt/wBdV/mKrZqxYn/iYW3/AF1X+Yoa0FP4 WeafGP8A5Hkf9ekf82rz+vQPjH/yPI/69I/5tXn9cJ84FFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFW9KgjutYsbeUZjluI0cA4yCwBqpWhoP/Iw6Z/19xf8AoYoA+qdH0o6XpUFnZTpFbqNwRYAA CRyeD7Cr3k3n/P2n/foen1/z9Kktf+PWPj+EVN/n/P8An9OK+UrYqXtJaJ69kbqOhV8m8/5+0/79 D/H/AD9MVzviXwHYeKSjagyGVGyJFi2se2CQc/8A6hntXWUVMMbUg7wST9EHKmeZf8KT0D/no/8A 49/8V/n60f8ACk9A/wCej/8Aj3/xVem/5/z/AJ/Xmj/P+f8AP9a1/tTE9/wDkR5l/wAKT0D/AJ6P /wCPf/Ff5+leFa3praRrd3YMysYJCuVJIx1HWvsL/P8An/P6cV8neOf+R11X/rt/QV35dja1eq41 Hpb9UROKS0Ofooor2TMKKKKACiiigAooooAKKKKACiiigB8ODNHnpuH86+gLSURxx7DgKBivn0HB B9K9m0DUVvdJt5Q2TsAP1rgx9H2kE+x9Pw5yt1IPfT9Tu7bWEjgkluMKkSbiw71nf8JlLK5MFvEq 9i4yazxIskTxPykilW+hrnJVmsJSjglf4W7EU+Hsry+pUmsRDml0T2t6BnVOtQalTXus3Lq6a4le aVtzuck1reC9QdL+5tt37tl349DXFtelhgZJrp/DEL2iyXEgxLLgAegr6XiWpQjlk6LSV7JL5rb0 OLARqVtDvY583GwHvXlXx4KPbaM4+/5kq/hha9Et7hYlZyfmPJNeM/GDV1vNXs7FGz9njLv7M3/1 gK/PMrpN4qMlsv8AI2zCmo0m2ebUUUV9YfPhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfRnhH/kgdh/173/8A6G9fOdfR nhH/AJIHYf8AXvf/APob1dP416jjujzakoor649YKKKKAEpKWkoAKKKKBBSUUUxCUlFBoASig0lA BRkiikNAiRZmHvUizKevFV6Slypj5mi4GB6EUuapZpwkcd6lwKUy5miqwuGHUCnC4HcGp5GUposU VEJkPenh1PQg1LTKTQ6ikzRU2GLRSUUAOozTc0ZpAOpabmjNAx1JRmjNIdxaKSloAWgHBpKWkMdm lzTM07NTYdx1LTM0tKwxaSlpKACiikNAEtvdXFpKJLaeSGT+9G5U/mK27bxx4ntABFrV2QP+ejeZ /wChZrn6KmUIy3VyXGMt0dYPiV4uAx/a5/8AAeL/AOJqCb4geKp1IfWZwD/cVU/9BArms0VPsaf8 q+4n2VP+VfcWrzVNQ1A5vb65uT1/fSs/8zVSiitEkti1ZbCUhNBpKoBc1KjZGO4qGnK2DkUWGmT0 qO0ciupwykEH3FNByM0uaRodhZ3S3dqkwxkjDD0PepDxXP6Hd+VcmBz8kvTPZv8A6/8AhXQnpXl1 YckrHm1IckrDDTDTzTDWZKGmkNKaSkUhKKDxSdKRQUUfjSUBYKKKKRQUUUYpDFpM0UUhgKWk70UA LVebTrK4OZrWGQnuyDP51YopA0nuZjeG9Hc82S/8BZh/I0g8M6OpyLIfjIx/rWoDRnmlYn2UOyKc WkabBzHZQA+pQE/mauAAAAAADtSE0Z4ppFqKWwtFJS0ygpRSUUALRmkFLQFhRRSd6M0xi0GkzSZo GLmjPNJSZwKAFJpCaTNNzzQUOzSUlFIYtFJ2ooGLmim5oJp2AUGjOaSkFVYY6jNJmkzTsA7IozTc 0op2AdmjNJRmnYBc4ozSUoNFhi55p1NozRYB1KDTaM0WAdS5puaAeadgH5o7U3NLTsAuaUU2lB4p 2AdS02iiwxxNIKSgGnYB2asWJ/4mFt/11X+YqtmpbJ8alar3Myf+hChq6Jn8LPOfjH/yPI/69I/5 tXn9egfGP/keR/16R/zavP684+cCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACtDQf+Rh0z/r7 i/8AQxWfWhoP/Iw6Z/19xf8AoYoA+u7X/j1j/wB2pv8AP+f8/rxUNr/x6x/7v+f8/n2qb/P+f8/r Xxdf+LL1f5nQtgoo/wA/5/z+uaP8/wCf8/pmshh/n/P+f05o/wA/5/z/AEo/z/n/AD+lH+f8/wCf r2oAP8/5/wA/rxXyf45/5HXVf+u39BX1h/n/AD/n9a+T/HP/ACOuq/8AXb+gr1cn/jv0f5oipsc9 RRRX0hiFFFFABRRRQAUUUUAFFFFABRRRQAV1HhLXPsM32SVsI5yhPQH0rl6KPU6cJip4WsqsOn4n t8F2sgyp59Ksl1kGHUMPQivKdJ8UzWgWK6DSRjgOD8w/xrrLXxNaTKNl2n0fg1yzwabvBn3eGzPC 4uG6T7P+tTq40t4zlIkU+oFWku/L5JwK5RtfgRcm6tx/wMGsXUfGNvGpETtO/YDhaxll86jvUl+p pVrYShH3pJL+uiO51fxXb6ZYPPI+VUfKvd27AV4jqN9NqeoTXlw2ZJWLH29qfqGpXOpz+bcPnH3V HRfpVOumjh6dFWgfFZnj1ip2grRW3+YUUUVueYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV9GeEf+SB2H/Xvf/wDob185 19GeEf8Akgdh/wBe9/8A+hvV0/jXqOO6PNaKKSvrj1goopKBBRRRQAUlFFMQUhpabQAUUUUAJSUt JQIKSiimAUlLSUCCkoooASiiigQUZpKKYDg7DgMRTxO4PXNRUlKyC7LAum7qKeLle4Oaq0lTyIan IuieM8bqeHVuhB+lZ9FL2aK9ozRzxRms4OwHDEfjTxcSA8kH6ipdNlKqi/mjNUxdHuoP0OKkF0hP ORUOnIpVEWc0A1CsyN0cVJmpasUpD6XNR5pwPrU2KTH5opuaXNKw7i5pc03NLSsVcfmim5opWAdS UZooGJRRRQAUUUUxB0pKKTNAATSUtJTAQ0ZoopiJY25wakqvUytuGaTRcX0HKxVgykgg5BHauvs7 oXlokoxuIww9D3rj609Fu/JufJY/JLwPZu3+fpXPiKfNC63RnXhzRv2OhIxTT1p7Uw15pxIYetJ2 pTSGkWhDSdqU0lIpCUUUUh2A0lFFAwozRRSGFFJS0DsFLSUZpBYWlpuaM0DFJpM0E03NA7Du9FJm gUxi0oNNpaAFzRmkooAWlpKSgB2elJRRQMKOlJmimAtITSZ5pM0DFJpKSigoWkoopDCkzQTSU7DF ozSUlUkAtGaSinYBaKTNAPNVYYuaXPFNoosA7NFJS0WAXNFJRTsA6gUlKKLALS5puaM07AOzSg02 lFOwx2aXNNHFHanYB1KD702lzxRYBaXNMzS00hi5ozSd6R3Crk1SVwFd9o9+wp2nHOqWpP8Az2T/ ANCFUyxY5Jq1pv8AyFLT/rsn/oQrVw5Ysmfws4L4x/8AI8j/AK9I/wCbV5/XoHxj/wCR5H/XpH/N q8/rxT5sKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK0NB/wCRh0z/AK+4v/QxWfVnTblbLVLS 6dSyQzJIwXqQGB4/KgD7Ctf+PWP/AHfX/P8An9Jv8/5/z7e9eMwfHWCOBEfSpSyjBII/xqT/AIXx a/8AQJm/Mf4/56V8pVwWIlOTUHubqStuexf5/wA/5/xo/wA/5/z/AIV47/wvi1/6BMv5j/Gj/hfF t/0CZvzH+NZ/UcT/ACMfMu57F/n/AD/n39qP8/5/z/8AW8d/4Xxbf9Amb8x/j/nrR/wvi1/6BM35 j/Gj6jif5GHMu57F/n/P+fb3r5O8c/8AI66r/wBdv6CvT/8AhfFr/wBAmb8x/j/npXkXiDUk1jXr vUI0ZEnfcFbqOBXpZZhq1Ks5VI2Vv1RE2mtDNooor3TIKKKKACiiigAooooAKKKKACrFjZSaheR2 sTIrvnBc4HAJ/pVetbwz/wAjDa/8D/8AQDVRV5JGVebhSlJbpMuf8IbqP/Pa1/76b/4mj/hDdR/5 7Wv/AH03/wATXp2k+H7nV7W5uYp7SCC3KrJJczCNQWzjk/SnXOgG1WUvquluY4jKBDdB9+CBtGP4 uc49Aa6vZU72PB/tDF8vN09Dy/8A4Q3Uf+e1r/303/xNH/CG6j/z2tf++m/+JruKKfsIGf8AauI7 r7jh/wDhDdR/57Wv/fTf/E0f8IbqP/Pa1/76b/4mvStK0aTVI7mf7TBa21qqmaecnau44UYAJJJ9 qoTIsU8kaSLKqsVEi5wwB6jPODR7GBTzPFJJu2pwn/CG6j/z2tf++m/+Jo/4Q3Uf+e1r/wB9N/8A E13FFHsIE/2riO6+4861PQLvSrZZ55IWVnCAIxJzgnuB6VlV3HjL/kDxf9fA/wDQWrh65qsVGVke 3ga861HnnuFFFFZnYFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABX0Z4R/wCSB2P/AF73/wD6G9fOdfRnhH/kgdj/ANe9/wD+hvV0 /jXqOO6PNKKSivrz1RabS0lABRRRQIKKTNFABSUtIaACiko96BBSGikNABRRSU0IWkoooAQ0UUlA gooooASiiimIKSlNJQAUUlFAC5pKKKBXEooooAKSiimIKUOy/dYj6Gm0UhkwupB1IP1FSreL0ZSP pzVSkqXCLGpyRppMj/dYGpN1ZFSJcSJ0bI9DzWbo9jRVu5qZpc1SS8U8ONvv1FWVcMMggj2rNwa3 NozT2JM0oNMBpc1Fi0x+aYZVHUikY4WvRbO60fw/8ItJ1248PafqN/JeSRI08S8tvl5Y4yQFU4Hr j0rnr1fZpWV7mdWryJWV7nnfnJ6il8xcZzXqfiXWfDfhu10DXLfwhp0s2uQLPKkijbFGFQkKuMBj 5nUAZxzmo9R8OaZp3xZmtrTwxJqkLWK3MdjDsWGOQsVLNuIUL8vTpk9K5ljerRgsX3R5eJVPQimS XCqpOa9a8W+HvtHw21PU9V8OaZo+rWThoTYFTlMqPmK+xYYOegNUvGmp6L4W8PaTBa+GNMmvtR0w b7h4VBjGwDcMDliSTn2oWM5tEtQWLvolqcT4i0ZfD1/BbDU7S/EsCzeZbNkLkkYP5VlCRW4yK9gv PB2h3fxLtY5NPt4dNtNEW8lggjVFlfzGA3BQM8cn1wBWT4evNB+JI1TRh4ZstLuIrYz2U9qiqygE ABiAO5X2OTShjGo6q/cmGKaWqv3PN80VFA5eME9xUteitUdqdxKKKKoBKejYP86ZRmnYaZZoBKkE HBHQimRtlcHqKfUWNE7nXWdyLu0SUY3EYYeh71Ka5/RLvyrkwOfkk6Z7N/8AX/wroTXlVqfJNo4a keWViM00inmm1iCGmkpaSkUhKSlpKRQUUhNFA7BmiiikOwtJRmg0DsFM/eS3ENvCu6aaRY0X1Zjg fqaUnANdB8PNNOp+L/tTIWh0+Myn3kb5UH/oR/4DUydkZ1Z8kWzM8QaLqHhi6gg1BoX89C8bwsSp wcEcgcjI/MVXvrC4sNA07WZJomgvnZI0XO5SM9e3aur8Q2Wt6z8N57/WrGS21LTrySdVcgkwM2SO CeArY/7Z1l39+un/AA98F3rWlvdrHcykwXC7kfO8cj2zn6gVHMzkVeTiu5i6hbXmj3v2PU7c29xs D7C6t8pzg5UkdjUAuYz/ABD869H8R3VtffFbRdEudKsJoyvnPPJCGkceXNhCT1XODj1FZMEWk+J/ Hb+HIdDtLLT9OuJZpZIQFecoShU4HClmHHoO1NTLjinbVHHrcIxwGFSg55FdVoOpaB4z1e60FvDl nYwmN2s7m2QLKu09SQOvf07HNcZBIy5jlI3oSrY9QcGrUrm9KtzuzVi1RTBIp704HNM3FpaSimAt FFIKAF/GikzRmgYZpCaCaSgYUUlGKAClzSZpCaChelJRSZosMXNJRRmqsAUlFIaqwC0UmaKdgDNL SUtMYUuaSimA7NFJRRYBaM0lFOwDs0dqSjNFgHUZpKKpIB2aWm0UWGOzS02lB707ALS5ptLmqsAu eKM02lFOwxS2Bk9KrO5c5P4USybjtHQVHXRCnbVjH5q3pp/4mln/ANd0/wDQhVOremH/AImtn/13 T/0IU5r3WRP4WcJ8Y/8AkeR/16R/zavP69A+Mf8AyPI/69I/5tXn9fPnzYUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAdF/whuo/89rX/AL6b/wCJo/4Q3Uf+e1r/AN9N/wDE16NpGlXGtail jamMSuGYGRtqgAEnJ+gq+/hho2j36zo215FQlL1W25OMkDsO5rsdGmtD5yOYYuS5lt6HlX/CG6j/ AM9rX/vpv/iaP+EN1H/nta/99N/8TXpC6TK2mXt+ssTRWkyQtgkli2cEe3y1n0/YQIeZ4lb2+44f /hDdR/57Wv8A303/AMTR/wAIbqP/AD2tf++m/wDia7iij2EBf2riO6+44f8A4Q3Uf+e1r/303/xN YNxC1tcywOQWjcoSOmQcV6tXmGq/8hi9/wCviT/0I1lWpxglY9HLsZVxEpKfQqUUUVznrBRRRQAU UUUAFFFFABRRRQAVreGf+Rhtf+B/+gGsmtbwz/yMNr/wP/0A1UPiRhiv4E/R/ke5+GzYr4L186il w9t51tuFuwV85bHJBFR6fHpE9prr6fbTiKPTtw+1lXZX8xeVIAxx/WsK31We20i80xEjMN28byMQ dwKEkY5x39KSx1ObT7e9hiWNlvIfJkLgkhcg8c9eK7uV6ny6rRtFPon+v+Z0l/qI0jw5oX2KztFu Li1czTvArsw3sAOQcd+evT0rZv4rbQtSj0yC90CKygWMTwXUDPJPlQWLt5Z654weBiuCvdTmvrSx tpVjCWcRijKg5ILFueeuTWkPFDTQQpqGl2F/LAgjjnnVw+0dAxVhux70nBmkcRG7+Vvktdu5v2+o x6foPilNJa3lsoLmA2zPbo+VZ267l+bHbPTtWcbs6F4V02/tILY3upSzvLPLAkmxUYKEUMCADnJ4 rEGszrZ6lapDbpFqEiSSBEI2bCSAgBwBz71Np/iCS00/+z7mytb6zEnmpHcBv3bdypUgjPcdKOQX t07K9tH8ne/5aG3fPb2esaLqUOlwSLqdopuLFYxtcsSrbB/DnAIx0NJ4u0y18MWUel2cPmi6dpnv JFUnCsQIlIzgr/Fjqfbisr/hK7/+1zqflW32hYfItwIyFtlxgeWM8EDOM561SXWbn+x5tMlWOaCS UTKZAS0T9ypzxnvnNCi9AlWptSS3e39ef4fecb4y/wCQPF/18D/0Fq4eu48Zf8geL/r4H/oLVw9c 1f4z2sq/3derCiiisT0gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAK+i/CZx8ArE+lvf/wDob186V9FeFf8Ak3+z/wCva/8A/Q3q 6fxr1GtzzISKadkHvVPNKHI719eegpluioBMRTxKDQVzJj80UmQaKBi0lFFABQaKSgBKKKKBBSUU UwEooooAKSiigApKWkpiCiikoEFFFFACGkpaSgQUUUUAFJRRTEFGaSigApKKKACiiigANJS0lACU UUUCClV2RsqSD7UlIaAuXIrztIP+BCraOrqCpBHtWRTkkeM5ViDWcqaexrGq1uax5FdBf+IbS6+G mmeGUhuBd2l61w8jKvllT5nAOc5/eDt2NcvDdrJhW+Vv0NWK5KtBSa5uhs1GpZ9jf8V+IbTX9C8M WFtDcJJpNn9nmaVVCu22MZXBOR8h647V10nxQ0p/F1/fNp1+dMvtPjtJQNqzIVaQ5XDdMSH+IH8q 8zwKXArmlg6bViHhoNWO0uvFXhS18D6v4b0HSdTg+2kMJ7goxkfIyXO7I4XAxn8KyPGviC18TQ6O lpDcRGxsRbSecqjcwxyuCeOO+KwsD0pcCiGEhF3HHDQi7ne3nxKhTx3Za9YWU7WqacLG5guAqs67 yxK4JH93GfccVHH4w8K6BZaifCWh3tvqF/GY2lumG2FT2XDE4GenHQelcNgUYFL6lTF9VgMjTYgA 7U6lpK60rHQFJRmkqgCiikpoQ5G2tmrGeKq5qWJuNp/ChoqL6EodkcMpwwOQR2Ndfazi6tI5h/EO QOx71x1a+gXeyVrZuj/Mv17/AKfyrkxVPmhzLoRVjdXN096aaeaYa8owQ0000402kaISkpaSgpIK OlFJmgYtJSUUDFzSUZopAI2StaljryaX4Qv9Lsku4tTvZgz3SEKqoMcBg27OAe38RrMpCBmk1cid NTVmavhnxLLo93dprEt/qOnXVuYZITKZCCe4DsB0LA896oanqVve+DNG0O3iuVm0+R2MkqqFYEtj GCTnkZ4qDApNoo5UR9Xhe51V54v0O98T6R4ibTdRj1G1OydV2MjR7JBhcsMnc4544zWFZa3LpfjK 48QWkJZZbqaQwycFo5GJ2nGcHBHryKpbR6UuBQoII4aCOkt/E/hvRZ7zUvD+hXcWq3Ksoa5YeVFu OTtAY8Z5wAOmOKwYpdDj0bS4H0y6e/iug99MJMCeLJyo+bqRt7DGOtQ7QKNoo5UCw0V1NIXnhn+0 NWkGjXn2aaFVsE8zBhfadxb5u5werYx05xWZFuCAMecc0u0Zp3SmlY0hTURc0ZpKM0zQXNGaTNGa AFpKKSmMXNJSZpM0WHYXNGaTNJmnYY7NHam0UWGLSUUmaaQC0lFJTSAM0UUVVhhRRRTAWikNFMBc 0vam0tAC5opKWmAtFNzS5p2GOozTaM07AOzQKbmlqrAOpc02lp2GLS03NGadgHUUmaM1SQDqhmlw Ng696WSQIvuelVc5NbU6d9WMdmlBptKK3sA4Vc0z/kK2f/XdP/QhVKrmmf8AIVs/+u6f+hCs6i91 kz+FnDfGP/keR/16R/zavP69A+Mf/I8j/r0j/m1ef184fNBRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQB9A/D/b/wl8G/O3yZs4648tqk0dfDtx4i0mKxtb/e15GHF3JG6MmeRgKPasLSNVn0 XUFvbZI3kVHQCQEjDKVPQjsaj06+l0zUra+hVGlt5BIocEqSDnnFeg4tts+Pp1oxjGL6O/5f5HQ7 QvhPxEqgBRqEIAHbl61bzUo9P8R6Rp1vp1gLaeC1FyHtkYzb1XOSRkcHtjnmuPOsXB0+9stkXl3k yzyHByGXOMc9PmNOutbubvVLXUJEiEtssSoFB2kRgAZ59uaXI3uWq8UlbfT83/mdZaywXHinUfDA sbRNNUXMKL5Kl1aNWIffjcWyvr3qpodxA2g21vpl7pdlqYkf7T9vhUmYE/JtdlIAxxjjmsGDX7q3 8QT60kcJuZnldlKnYDIGDYGc/wARxzTrLW4LW0ihl0TTbpos7ZZUcMckn5trAN17jpRyspV4337/ AHaWtbbqVdXhurfV7qK9gSC5WQ+ZHGoVVPsBxj6V5Hqv/IYvf+viT/0I16zqOoXGqahPfXbh55m3 OQMD8PavJtV/5DF7/wBfEn/oRrLEfCjtymzqztt/wSpRRRXKe8FFFFABRRRQAUUUUAFFFFABWjoV 1DZ6zb3Fw+yJN25sE4ypHb61nUU07O5FSCnBwfXQ9D/4SbR/+fz/AMhP/hR/wk2j/wDP5/5Cf/Cv PKK2+sSPN/seh3f4f5Hof/CTaP8A8/n/AJCf/Cj/AISbR/8An8/8hP8A4V55RR9YkH9j0O7/AA/y PQ/+Em0f/n8/8hP/AIUf8JNo/wDz+f8AkJ/8K88oo+sSD+x6Hd/h/keh/wDCTaP/AM/n/kJ/8KP+ Em0f/n8/8hP/AIV55RR9YkH9j0O7/D/I6rxNrFhqGmxxWs/mOJgxGxhxgjuPeuVoorKc3J3Z3Yeh GhDkjsFFFFSbhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAV9FeFf+Tf7P/r21D/0N6+da+ivCv8Ayb/Z/wDXtqH/AKG9XT+Neo1u eT0UUGvrzsA0ZoooAUORUizetRUlA02iyrqe9OqpnFPEhFBSmWKSmLKD1p+c9KCr3Cg0UUxiUUUl AgpKU0lABSUUUwCiikoEFFFJQIWkNFJTAKKKKAEooooEFJRRQAUUUlABRRSUCuLRSUUAFJmlpKAF pKKKACiiigBKSlooEFWILox4V+U7eoqvSUmk9GOMmndGwjhlDKcg06sqKd4Tx07itKORZEDKcisJ QsdcKikSUtNpazsa3FopKKLAFFFJQIDSUtJTAQ0lLSVSEJShsEEUlFOwrlgHIyO9KkjRSLIhwykE H3FQxtg4/Kn0rF3ujtYJ1ubdJk+64z9Kc1YegXeGe0c9fmT+o/r+dbhxXhV6fs5uJhazGGmmnGmm sS0NpM80ppM0FiZoozRQMKKKTNABRRmjNA7BmikzzRQFgpaSj3oGFLSUUBYKWkopgKKM0maM0ALR SUZoAWikzSZp2HYdmmk0hNJmnYYtFNzRmnYB1JmkzSZosOw6jvSZozxRYBaKSkp2GLmikozTSAUm k+tJRVALS0lFMAopKWgBaKSimMXNFJRmnYBaCeaSiqSAdmkpM0ZppAOpc02jtVWAfmjNMzS5ppDH ZozTc0ZqrAOzQWCjJpuaryybjgdBWkIXYxGcu2TSUmaK6rWAdSg03NOpWAdmremf8haz/wCu6f8A oQqlzVzSz/xNrP8A67p/6EKiovdZM/hZxPxj/wCR5H/XpH/Nq8/r0D4x/wDI8j/r0j/m1ef18yfN BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB6H/wAJNo//AD+f+Qn/AMKP+Em0f/n8/wDI T/4V55RW/wBYkeV/Y9Du/wAP8j0P/hJtH/5/P/IT/wCFH/CTaP8A8/n/AJCf/CvPKKPrEg/seh3f 4f5Hof8Awk2j/wDP5/5Cf/Cj/hJtH/5/P/IT/wCFeeUUfWJB/Y9Du/w/yPQ/+Em0f/n8/wDIT/4V wmoSpPqV1LGdyPM7KcYyCSRVeionVc9zpw2Cp4Ztwb17hRRRWZ2BRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABX0V4V/5N/s/+vbUP/Q3r51r6K8K/8m/2 f/XtqH/ob1dP416jW55PRRRX152BRRRQAUUUUAJRRSUCFpQxHem0UDJVl9aeGDdDVejJFFxqZZoq ASkdeakDg96dylJMdRRRTHcSiiigBKKKSgQUUUUwCkoooEFFJRmgBKKKKACiikoELSGiigApKKKA CiikoAWkNFFABRRRQIKSloNACUUUUAFJS0lABUkUrRNuX8R61HRSGnbU1opVlQMv4ipKyYpWifK9 O49a0o5FkQMp4NYyhY6qdTmJKWm0tRY1CiiiiwCUUUUAIaQ0tNqiQpM0dqSqEGamVty5/OoKVW2n 2oBMsxStBMkqHDIciuxgnW6t0mT7rjOPT1riq2NBvPLla1c/K5yvsf8A6/8ASuLG0eeHMt0DR0Bp hpxphrxRobSUppDQWFJRSZpjsLmkozSZoHYXNJmijNA7BRSZooCwtGaTNGadh2FozTc0ZoCw7NJS ZNG6nYLDqQmm5ozRYLDs0Z9abn8qQmnYLDs0maTNNzVWHYcTzRmkpM07AOzSZpM0Zp2AXNFJmjNF gFopKM0WGOzRmm0Zp2AWim5op2AdmkpKXpTsAtFJmjNOwCj1pabRQA6jNNzQTQkMXNJmkozVpALm jNJmjNVYBaXNNzRVJDHZpc8U3NFUkA7NFNozVJDHUZpuaRmCjNWogJLJtGB1NQd6Qtk5J5pM10xj ZAOpabmimA8UuaaDS0WAcDVvS/8AkLWX/XdP/QhVKrmlH/ib2X/XdP8A0IVnUXuMmfws4z4x/wDI 8j/r0j/m1ef16B8Y/wDkeR/16R/zavP6+XPmgooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAr6K8K/8m/2f/XtqH/ob18619FeFf+Tf7P8A69tQ/wDQ3q6fxr1Gtzya iiivrzsFopKKAFpKKKACkpaSgQUUUlABRRRSAKKKSgQ4OR3p4kB68VFRQmNNosZzRVcEjpTxJ61S ZSkSUUgYHpRVDuFFFJQFxaSiigBKKDRQISilopgIaKKSgBaSiigQUUUUABpKKKACiiigAopKKAFo pKKQBRRRQAUlFFAXCiiigAqWCYwvnqp6ioqKTQ07O6NdXDKCDkGlzVC2n2HYx+U+var1ZONjrhPm Q6jNNzRmpsWOzSUZpM0WAM0lKaSmkISkpaQ0xCUUUlMRIjdj+FSKxRgykhgcgjsar1Kjbh70DTOx s7oXdqkoxk8MB2PepCa5vS7z7LcbWP7uTg+x7GuhJrwMVQ9lUt0excRc0maQmm5rnsWkOpKbupN1 OxVh+aTNM3UbqfKOw7NGaYTRmnYLDs0ZpmaM0+ULD80mabmkzRYB+6kzTc0madgH5ozTc0ZosA7N JmkzSZp2GOzRmm5oJp2ELmjNNz70E07DHZozTM0ZqrAOzRmm5ozTsA7PNGabmjNFgHZozTc0Zp2A dmjNNzRmjlAXNGTmkzRmnYBc0Z4pM0Zp2Admim5pc0rAOopuaM807ALmikzSZppDHZpM0hNJmrUQ HUUlLVWAWikzRmqSGLRmkozVJDFozSZzRmrSAXNV5H3Nx0FPkfAx3NQZraEeoDqKbRmtLCH5ozTc 0uadgHUZpuaXOKVhjs1c0o/8Tey/6+I//QhVLNXNK/5DFj/18R/+hCoqL3H6ET+FnH/GP/keR/16 R/zavP69A+Mf/I8j/r0j/m1ef18ofNhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRVq00y+vmxa2k0x/2EJp pX2Aq0V0EHgnxDPdR266bMsknQMMceteiaP8FoYoBca9qAjAGWSM8L9TXLXxVKhpN69jWnRnU1R4 3RXreqp8LtHY2ohuLqQcM8b5wfriuI13TNJe0OpaHJIbYNteKTqh7VNPGRm0nFpPq1oVKg0m007H N0UUV1mAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABX0V4V/wCTf7P/AK9tQ/8AQ3r51r6K8K/8m/2f/XtqH/ob1dP416jW 55NRRSV9edYtFFFABRRRQAUlLSUAFJRRQAUUUUgCkpaSgQUlFFABRRRSEFKHIpKSgCUSA9eKdmoK AxHSqUhqRNRTBIO9OznpVp3LTFoopKYC0lFIaBBRR2pKAFpKKKACiiigQUUmaKACikooAWikooAW ikooAWikopAFJS0UAJRRRQAUtJRQAtXbWbcNjdR096pUoOCCOCKTVy4y5Xc1aKihl81M9+4qSs7H UncWjNJS0WHcKSiigApKKKYhKKWkoAMUDg5FFFICUHIzW7pd8JIhBIRvUYX3Fc8CQamjkaNw6HDA 5BrGvRVWHKyouzOrJphNQ21yt1CHB+YcMPQ1Ka8NxcXyvc6EGaTNIaQ00AuTSZpM0hNVYY7NGabm k3U+UB+aM1Huo3U+UY/dS596i3UbqfIBJuozUe6k3UcgEuaM1HupN1HIBLmjNR7qTdT5AJM0Zpm6 jNPlCw7NGaZmlzTURDs0maTPpSZp8oD80ZpmaXNPlAdmjNNzRmjlAdmjNNzRmnygOzRmkop8oC5o pKM0WELRmkzRmjlAcDRmm96M0cox2aKbmjNNRAdmkzTc0ZqlEY7NGabmjNWogPzR+NNzRmnyjHZo puaM4qlEY7NFNzRmq5Rjs01mwKQmonfJx2rSMbgNZtxJopKK2sSLRSZop2AdmjNJRRYB2aM02igB 2au6T/yGbH/r4j/9CFUc1c0k/wDE5sf+viP/ANCFZ1F7j9CZ/Czk/jH/AMjyP+vSP+bV5/XoHxj/ AOR5H/XpH/Nq8/r5I+bCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAorV8P8Ah7UPEupp YadFvkYjcxOFTPcntXcf8KN8U/8APbTv/ApP8amU4xdmwseZUV6Ne/BbxRZWUtyTZSCNS2yO5Qs3 sBmvO3R4nZJEZHU4KsMEGiMoy+F3AbRRRVAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRX a/DDwunibxbDHcLus7cedN7gdvxoulqxN2Vzf8C/DOK5tYNX8QJKIJuba0QfNKP7xPZf59q9asYf s7fY9JtorJIhtkaNBtj9gerNWtez+fIthaBY9gHmSKOIV7Bf9o9vSo5JI7CCO3tog0rcRRZ6+rMf T1NeJis0lNKjQXvP+v6/A2w+H9p+9q/D0X+ZBPJbaTHuIeW4l+6CcySn69h+lYF3G2qtt1Nw8Uh8 sW0Zxt9/X8a3DaCJy882+5k/1kx7ew9APSq0t9b20gVrZlHIWUry1bLLZ4Slz25qrV/T7/6/M5MZ mEpvkpO0V+J4f45+H0ugqdRsN0tgzYYHloj6H/GuZjkFv4XlXcC9xOAFB5AUV9HTxrewyRtD5lvK pR1bHINeCeLvBl74dnkuCqmzaTajBuRnoDXRh51K9Ne2VpJ/eXh6kre8tTlaKKK7SwooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACvorwr/yb/Z/9e2of+hvXzrX0V4V/wCTfrP/AK9tQ/8AQ3q6fxr1GtzyWiiivrzrCiiigAoo ooAKKKKAEooNFAgopKKQBRRRQAlFFFAgpKKKBBRRSUhhRS0lAgoBI6UlFICRZPUYp/Wq9KGK9KpT 7jUu5PRTFkB46GnVqnctO4UlLSUAFFJRTEFFFFIBKKWkpgFFFFIBKKKWgAoopKACiiigAooooEFL SUUgCiiloASlopKBkkchjcMOnetBWDKCDwazBVi3l2nax+U9Pak0a05W0LlLTaWpsbi0UmaM0WGL SUUUAFFFFAgopKKAClBxSUUAWra4e2lDqeO49RW/HKsqB0bINcwDVyyuzA+wn5CfyrkxWG9ouaO6 NoT6M3CaaTSBgwyKQmvJStubhuNIWNJSZrVIBSaTNJmkzWiQC7qTNJmkqlEB2aN1NzRmq5QHZNGa bmjNHKA7JozTd3NG6jlAdmlzTN1GaOQB+aM0zNLmnyAPzRmmZozT5AH5ozTM0uaOQB9GaZmlzT5Q HZozTc0Zo5QHZpc03NGaOUQ6lzTc0maXKA7NGeaTNGaOUTFzRSUmaOUB2fejNNozT5QHZpMk0hNJ mqUSh2aM03NGapRAdmkzTc0ZqlEY/PvRmmZpc1XKA7NLmo80ZpqIyTNJmmbqQtVKIxWfAqPNNJya TNbKNiWPzRmm5ozTsA6kpKM07CHZozTc0tFguOzRmm0tKwDquaR/yGbH/r4j/wDQhVHNXdIP/E6s f+viP/0IVnVXuP0Jn8LOV+Mf/I8j/r0j/m1ef16B8Y/+R5H/AF6R/wA2rz+vkD5wKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKnsbY3uoW1oG2GeVYwxGcbiBn9agrQ0H/kYdM/6+4v8A0MUAfSfg 3wzD4U0lILbTi88mGkuDIpZsjge3f/IxXSfabn/nyf8A7+L6Z/z/AJFSWv8Ax6x/7tTf5/z/AJ/X ivlcRiISqycoJu/d/wCZulpuVTcXODmyb/v4v+f8/hXmXjX4WDXrwXmmQGzuCx81cqVI9hnjnHfv +Xq9FFHHKi704JfN6/iDjfc+fv8AhSOt/wDPyn/fK+uP71A+COtnpcp/3yv/AMVX0D/n/P8An9Oa P8/5/wA/0rp/tir/ACon2aPn7/hSOt/8/Kf98r6Z/vV5te2kthezWs6MkkTFWDDB/Kvsr/P+f8/r xXyf45/5HXVf+u39BXZgcfPEVHCStpcmUbK5z1FFFeqQFFFFABRRRQAUUUUAFFFFABRRRQAV678J rmPTvD2r3CXEUF1M6RLJKQFVc8kk9K8qsrSS9ukgjHJPJ9B613Vnp9vZQrHEnTnJ5Oa48XXjCDh1 Z7eUZFUzK8m7QW77+SPaYdf0SzsylvqdpeT9dkU6u8znqSAf/wBQp1jqEal55pAbqT7zdgOwHtXI eL/AH/CNaFY37Xi3P2hxHJGY8BWK7hj1HB6+1c9p2pzwMsEkxMR+VN38J7DPpUZNTw2GxDWIXvPZ 9Ea5vk1apgnicvqc8I3urNPTe3e3Y9f0+VLq5d2wQgyPrS6kVlVYyASzgD29f0ry5Nfu9Lm+0QPh z8u09G+tU9T8VatqenzWskyL5nR0BUr+IPSu3O8BV+uxkpJxVtOqPisCpV0pNWV9z2LV7y2sViWR oEdkBy2AelcD8QkGt+DrzaVbyE81doGOOSePYGuY1/VLfV7yKZbZdiRhcP64GelRWN3bW1pqjSJD bxGycYXPznjjk1nHnT2PoPYYdQbVT3u1tPS9zyeiiitjkCiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK+ivCv8Ayb9Z/wDX tqH/AKG9fOtfRXhX/k3+z/69tQ/9Derp/GvUa3PJaKKK+vOoSiiikAtJRRQAUUUUAFJS0lABRRRQ AUUlFAgoopKACkpaSkIWiiigApKWkoAKSiikISkpaSkIKVXK+4ptFNOwXsTqwbpS1XpwlPRuferj PuWpdyWigEEZBorUoKSiikAtFJRTAKKKSkIWikooAKKKKACkoooAKKKKAFopKKAFopKKAFooopAF LmkooGXLebPyN17GrFZgJBq5DNvGG+8P1pNG9Od9GT0UlFI1FopM0uaACijNFABRSUUALRRRQAUu aSigDQsrrGImPP8ACf6VoiUEc8GufyQQc81p20/nphvvjr7+9cmIw8X7x0U530Ze3D1FNLD1FQ5x 1o6iudUUjYlLj1FJuHqKiNJVqmgJs0ZqDkUu40/ZiuS5ozUW/wBqN5p8jAkzRmo95o3H1p8gEmaM 1HuPrRuPrRyASZozUe40u4+1PkAkzRn3qPcaN1HIBLmjNRbjRuPtT5QJc0ZqPeaN9HKBLmjNR7qX dRygSbqM0zdRuo5QH5pc1HmlzS5RD80uaj3UoNLlAfmjNNzRnilyiHZFGabmjNPlAdmkzTaXNPlG hc0maTNJmqURjs0mabmjNUojHZpM03NGapRAdmjNNzRmq5QHZozTc0m6qURjs0xmppbtTc1aiJsf mkzSZoqrCFzS5ptFFgHZoptLRYQ6jNNpc0WAdmjNJmjNFgHZq7pH/IasP+viP/0IVQq5pDY1vTx/ 08x/+hCs6q9x+hM/hZzPxj/5Hkf9ekf82rz+vQPjH/yPI/69I/5tXn9fGnzoUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAVoaD/wAjDpn/AF9xf+his+tDQf8AkYdM/wCvuL/0MUAfXdr/AMesf+7/ AJ/z+fapv8/5/wA/rUNr/wAesf8Au+v+f8/pN/n/AD/n296+LrfxZerOhbB/n/P+f1zR/n/P+f0z R/n/AD/n/Gj/AD/n/P8AhWQw/wA/5/z+lH+f8/5+vaj/AD/n/Pv7Uf5/z/n/AOsAH+f8/wCf1r5P 8c/8jrqv/Xb+gr6w/wA/5/z7e9fJ3jn/AJHXVf8Art/QV6uT/wAd+j/NEVNjn6KKK+kMQooooAKK KKACiiigAooooAKKKKAOg8KIpvJ2IBZUGD6c11lcHo199h1BHbOxvlYZx+Nd2rKwypBHtXjY+LVX m6M/SuFMRTngvZL4ot3+fU9D8eeKk1rwr4et0ZTI8ZuJwFI2suYxj2yJPyFedSkrE7A4ZRuB9COR XbeLo/B6aDph8Ptm9OPO5Ykrt5356NnHT3rkrSAXM+GYLDH88rnoAOcH61E1OpWS3emx1YWeHwmX SlZxiubSSs93/wAMi3q0DZDrkgcn8QDWTWxcalp8jtJ/adqFPQbu1YU2paY94lva3Xmu+eAuBn2r 6fER5kp31sr/AHH5JRvG8baXdiWsfxFdRxac0BI8yUjA9gc5/SunsNKnvlaQArCvV8ZyfQetcv4n 8FaxpNgus3brLbTSbA54bP0rkNzkaKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK+ivCv8Ayb9Z/wDXtqH/AKG9fOtf RXhb/k36z/69tQ/9Derp/GvUa3PJKKKK+uOoKKKSgBaKSigQtJmiigBKM0UUAFFFFABSUUUgCiii gQUUUlAC0lFFABRSUUhBRRSUABpKWkpCEoopKQgNFFJQIVWKnIqVZA3B4NQ0lVGTiUpNFqkqFZSv B5FTAgjIOa2jJS2NE0woooqgCiikzQAUUUlABRRRSAKKKTFAgooooGLRSUUALRRSUALRRRQAUuaS ikAtKCVIIPIptGaAL8UwkHo3cVLWaGIIIOCKtwziT5W4b+dKx0QqX0ZPRSUtBoFFFFABRRRQAUUU UDF/GikooAWnI5RgynBFMpaBp2NeKVZo9y9e49KXlTxWbDM0L7h07j1rTVlkQMvQ1zThyPyOmEro AwPWimkUAkVPL2LuOIpuKXcDRRZgJSUpopgJRS0lOwgoooosMWikozTsAtFJRQA6ikoosAtFJS0w CiijNAC5ooooELmjNJRSsAuTSg0lFFgHZpc03NGaVhDs0ZptGaLAOyaM03NGaaiMXNFN3UZqkhjq TNJmkJqkgHZpM03NFUkMdmkzSZpM81VgHE00mkJpuapITYuaM0lFUIXNGaSiiwDs0maSiiwDs0Z4 pKWgBaWm0tAC5pc02kZsUAKzYqzoxzrun5/5+Y//AEIVQLE1d0U/8T3Tv+vmP/0IVFRfu5ehlUd4 swfjH/yPI/69I/5tXn9egfGP/keR/wBekf8ANq8/r4o8AKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAK0NB/5GHTP+vuL/ANDFZ9XdGkSHXNPllcJGlzGzMxwAAwyTQB9fWv8Ax6x/7o/z/n8O9Tf5 /wA/5/SuLtfiZ4UFrGG1SJTt5BI4/Wpv+FmeE/8AoLQ/99D/AD/n8K+NrU5upJqL3fRnQnodd/n/ AD/n9MUf5/z/AJ/XFcj/AMLM8J/9BaL/AL6FH/CzPCf/AEFofzH+NZ+yqfyv7mO6Ou/z/n/P60f5 /wA/5+neuR/4WZ4T/wCgtD+Y/wAf8/Xmj/hZnhP/AKC0P/fQ/wAf8/zPZVP5X9zC6Ou/z/n/AD+l fJ3jn/kddV/67f0FfQf/AAszwn/0Fof++h/n/P4V87+LrqC98V6jc20iyQySbkdTkEYFeplMJxrt yVtP1RnU2MSiiivojIKKKKACiiigAooooAKKKKACiiigArptJ1W/S1US6bc3UIXbHLEGBGD64IPc ciuZr0Pwz/yL1r/wP/0M1UaMaz5ZGFfMK2Aiq1F2d7dgXUrIcvp2vPx9026gE/UHNZOsaxrOo2/2 O10u5s7MqA0axsS31bArraK2hgqcPh0ODEcTYzE29s+a3ds8w/srUf8Anwuv+/Lf4U5dN1NHDLY3 asDkERNx+lem0Vf1Zdzl/tmf8qOVsfFXjfTrdYLaW+WNeADATj8xWNrmva5q82zWLu5kZP8AlnLk bf8AgPavQ6878Tf8jDdf8A/9AFZ1aSgrnZgswliKjg1bS5k0UUVgeoFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV9E+Fv+ TfrP/r11D/0N6+dq+ifC3/Jv1n/166h/6G9XT+Neo1ueSUUUV9cdIUUUUAFFFFABRRSUALSUUUAF FFJSAKKKSgQtJRRQAUUUUAFFFJSEFFFJQIKKKSkAGiikoAKSlpKQgpKWigQlJS0lIBKVWKnINJRQ BOkgbjoafVWnpKRw3I9a2jU6MpT7k1FAORkdKK1NBKKKKBBRRSUALRSUUgFopKKAFopKWgBKKWig BKKWigBKKWigBKWkooAWikooGW4bjor/APfVWc1mZqWKdo+Oq+lKxrGp0ZeopqSLIMqfw9KfSNtw ooooAKKKKYwooooAKKKSgBwNWbacxNgn5D1FVacpxQ1dWZcZWNbcDSE1Ugl2/K3Tt7VY3VzuFmdC lcU0lG6jOadhi7jRvPpTaKLAP3CjcKbiiiwXHZpMim0hp2C4/dRuFR0m4DvT5RXJdw9aN1Q+YBSe Z6CnyhzE+6jdUHm+360eb7frRyBzFjdS5quJR3BpwkU9DRyjuS7qXdTM0uaVguO3UbqbRRYLjtxo 3Gm0ZosK47caN59abRRYB24+tLvOKZmkzT5Rkm+l3VFS5p8oD91GaZmjNPlGPzRupmaM07AO3UZp uaTNOwx+aM0zNLmnYB2aQmm9KTNNIBc0UlFVYQtFFFAhaKSgUALS0lFMYtFFFIBaKSms+360CuOZ sD3qIt600sTTc1SRDlccWq7oh/4n2nf9fUf/AKEKz81e0T/kP6d/19Rf+hCpqr93L0ZnN+6zG+Mf /I8j/r0j/m1ef16B8Y/+R5H/AF6R/wA2rz+vhjwwooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAmgtbi53fZ7eWXb97y0LY+uKl/srUf8Anwuv+/Lf4V0Xgn/l+/7Z/wDs1dvFpt/PGJIbK5kj boyRMQfxArohRUo3bPIxOYzpVnTjG9v8jyb+ytR/58Lr/vy3+FH9laj/AM+F1/35b/CvV5bC8hjW SW1mjRnMYLIRlhg4+vI/Oo7i3mtbh4LiJ4pozh0cYKn0Iq/q8e5zvN6q3geWf2VqP/Phdf8Aflv8 KP7K1H/nwuv+/Lf4V6fRR9WXcX9sz/lR5bLp97BGZJbS4jQdWeMgD8cVXr0PxN/yL11/wD/0MV55 WFWHI7HqYLEvEU3Nq2tgooorM7AooooAKKKKACiiigAooooAKKKKACvSvBttJe6Xp1rFjzJ5DGmf VpCB/OvNa9J8HXMlnpWnXUJAlhkMiE+okJH8q3w/xP0PLza3sY37r8mdpqsXhzTLi60xLa+uLiDd Gbzz1UGUccJtPy7vfOKln0/QtM0PS7y6iu7m5vYGcxJKEVMMRuztJPbj2PNRarc+HNTnutSDahBd T7pDarGjIJTzw+7O3PtmqWq6nDfabpFtEsgezt2ikLAYJLluOemDXSk3Y8WUopyenl9/+Xc2p9I8 P6XqtvoeoJeyXjiNbi6jlCrC7gEAJtO4DIzz61APDtppMGpXmsmaaK0vDZRQwMEM0mCSSxB2rt56 d6ml1vQNS1O31vUEvlvkCGe3iRTHO6AAEMTlQcDIwarp4jtdUh1G01tJlhvLv7ZHLbAM0MuCOhIy uDjr2qfeNH7K/Trb9L/8H56GJqMmnyzq+nW89vGV+eOaUSYbJ6EAcYx1FeX+Jv8AkYbr/gH/AKAK 9Q1FdOSdV02W5liC/M9wioS2T0AJ4xjvXl/ib/kYbr/gH/oAqa/wI6Mq/wB5lft+qMmiiiuM+iCi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAK+ifC3/ACb9Z/8AXrqH/ob187V9E+Fv+TfrP/r11D/0N6un8a9Rrc8kopKK+uOg WkoooAKKKKACiikoAWkoooAKKKKQBRRSUAFFJRQAUUUUCuFFJRSC4UUUUCEooopCCkopKACiiikI KSikoAKKKKQhKKKKAEo70UUhCqxU8VOrhvr6VXpKuM3EpSaLVFRJL2b86lrojJS2NU0wpKWimAlF FFAgopKKQC0UlLQAUUUUAFFFFAwooooAKWkooAKKKKAFpKKKAFVipypwatxXQOFk4Pr2qnRQVGTi atFZ8U7xcDlfQ1djlSUZU8+h60jojNSH0UUUFiUtJRTEFGaSimAuaWm0ZosBKrdqsRy44J4qoDUi Nmk43NIyLmaM1Ar4+lSBsis+WxsmO3Ed6N7etNzSUWC47zG9aTe3rTaKdhXHb29aTcfU0lJTsAtJ S0UAJRS0UwEoopcUAJRS0lMBQxHQkU4SNjsaZRRZBcl872/WlEo75FQ0UcqHcshgehpc1WzjpTxI e/NS4juTUlNDg+1OpWGLRSUUxi0UmaKYC0lFJTAdSZpKKYxaCaTNFFgFzRmm5pM1VhXHZozTc0Zp 2C46lpuaWgVxaM0lFAXFzS0lFAXFpaSloGLRSEgDNQvLngdKaVxNpD3kA4HWoi2aZmkzVJWM3K44 mkzSZopk3Fq/of8AyH9O/wCvqL/0MVQq/of/ACH9N/6+ov8A0IVnV/hy9GTL4WY/xj/5Hkf9ekf8 2rz+vQPjH/yPI/69I/5tXn9fCnihRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB1vgn/l+ /wC2f/s1e3sLw+D/AA79m8RRaSPKm3K9xJH5n7w8/IDnHvXiHgn/AJfv+2f/ALNXouqarBe6Jo1l EkgksY5EkLAYJZ9wxz6fSuymrwifOYuooYmq32X/ALaaF7bSf2LaXk2oz3kranJEzmZnjfaF+dc8 5Pr6YrVvtAXWPGXiO5miupreyk3NDaLullZjhVHBx3JODgCub/taD/hHLHTtknnQXj3DNgbSpCgA c9eDWofFVnLrmtvLFc/2ZqpBbyyFmjKnKsOcZBzxnvVtS6GEZ0n8Xl+T/Ufe+F4JLC3vlsr/AEdf tcdvPHfZICv0kViq5A7iofEWlWGkC4tv7E1SBkbbBeSzApLg9cbAMEehqjdyaHthSK91a6BmUy+Y ioBH/FtG5st6Z4q+ut6Xp2jX9nZ3mp3q3cPkpb3SKkUXIO7hjlhjjAFGom6butF9z/r5Hnvib/kX rr/gH/oYrzyvQ/E3/IvXX/AP/QxXnlc+I+I9bJ/4D9f0QUUUVgeqFFFFABRRRQAUUUUAFFFFABRR RQAV6H4Z/wCRetf+B/8AoZrzyitKc+R3OTGYX6zBQvbW561RXktFbfWfI87+xf7/AOH/AAT1qivJ aKPrPkH9i/3/AMP+CetV534m/wCRhuv+Af8AoArJorOpW51ax1YPL/q03Pmvpbb/AIIUUUViekFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAV9E+Fv+TfrP/r11D/0N6+dq+ifC/wDyb7af9euof+hvV0/jXqNbnkdFR7jS7q+r 50b3H0lJuFLmquhhRRRTAKKKKACiikoAKKKKQgopKKACkpaKQhKKKM0AFFGaSgBaSiikAUlFFAgp KWkoEFJRRSAKSlpKQgoopKAA0lLRSEJRRRQAlFFJSAKekhXg8imUU02ndBexaDBhkGiqysVOQanW QPx0PpXRCopaGilcdRRRWhQlFLRigBKKKKACiiikAUtJRQAtFJRQAtFJRQAtFJRQAtFFFABRRRTG JShipyCQfUUUUgLcV0D8snB9fWrNZVTQ3DR8HlPT0+lBtGp0ZfpDSK6uu5TkUtUaiUUUU7AFLTaW nYBc0oODTaM0WHcsI2R708NiqysQalVgRmpcTSMrk26jNR5pc1PKXcfmjNMzS5osFx2aM0maKBi5 opKKLALRmkooELRmkopjFzRmkpaACiikoAWikzRmmAtLTaXNAx2aUN70zNGaLBclDml31Fml3UrD uS7qM1HmjNHKO5LupM1HuozT5QuSZpM03NFOw7js0maSinYVxaKTNGadguLS00GjNOwXHUtNzS0W AWikzS0DFpRTaCwUcmgB9MaQL9ahecnheKiLVSj3Ic+xI0ham5pmaM1VjJsdmjNNzS5oC4tLmm0Z oC47NX9DP/E/03/r6i/9DFZ9X9DP/FQab/19Rf8AoYrKr/Dl6MUvhZlfGP8A5Hkf9ekf82rz+vQP jH/yPI/69I/5tXn9fCHjBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB1vgn/l+/7Z/wDs 1dbXktFbwr8sbWPKxOWe3qupz2v5f8E9aoryWir+s+Rh/Yv9/wDD/gnrVFeS0UfWfIP7F/v/AIf8 E9D8Tf8AIvXX/AP/AEMV55RRWNSfO7no4PC/VoOF763CiiiszrCiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvonwv/wAm+Wn/AF66h/6G9fO1fRPhf/k3 y0/69dQ/9Derp/GgR49RSUV9ObC0UlFACgn1pd9NopptDuP3ClzUdGaamFySimbiKXdVcyC4tFJn NLVDCikopCFpKKKAEooozSEGaM0lFABRRRSuAUlGaM0CCkzRRSAKKKKBCUUUlIQUUUlAC0lFFAgp KWkpAFIaWkoAKKKKQBRSUUATJL2b86kzVWnpIV47elbQq9GWp9yxRTVYMMg0tdFyxaSiloASiiig YUUUUAFFFFABRRRSAKKKKAClpKKACiiimAUUUUAFFFFADkkaNsqf/r1cinWQY6N6VRoBweOoplxm 4mlRVaG56LJ/31VkdMiqRvGSlsFFFFUULRSUUALmlDEGmUtFgJ1YGlzUAOKkDg9aTRopEmaXNMzS 5qbFXHg0uaZS5pWHcdmjNNzS0WC4tFJmjNFguLS803Ipc0WC4tGaTNGaB3FopueKM0WC4p60UlJm nYB9JSZoyadguOpKTNGaLBcdmjNNzRmnYLjs0u6mCjNOwXH5pc1HmlzRYdx+aXNR5ozRYdx+aXNM zQOlOwXH5pM0lGadguOzS5pmaXNAXHZpc1GXAphl9KLC5kifNIZQO9VmcnvTS1UokuoTtOe3FRFy eSaZupM1SViHJsfmkzTc0tBNxaWm0tAC5pc02jNIdx2aWm0UBcdmtDQz/wAVBpv/AF9Rf+his6tD Qj/xUGm/9fcX/oYrKt/Dl6MUnozM+Mf/ACPI/wCvSP8Am1ef16B8Y/8AkeR/16R/zavP6+DPICii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvonwv/AMm+Wn/XrqH/ AKG9fO1fRPhf/k3y0/69dQ/9Derp/GgR47RRSV9ObC0UlFAC0UUlAhaTtRRSAKKKKAEpckUlFADt /qKXINR0U+dhckoqPcRShqpTQXHUUAg96KdwCiikoAM0lBopCCiiigAoopKQhaSiigApKWkoAKSl pKQBRRSUCCiiikIKSlpKACiiigLiUUUUAFFFFACgkHIOKmSQNweDUFFXGbiNSaLVFQpKV4PIqUEE ZBzXRGalsappi0UUVYwooooASilpKBhS0lFAC0UlFAC0UlLQAUUUUAFFFFABRRRQAUlLSUwCpYp2 j4PK+lR0UDTad0aCOHXcp4paz0dkbKmrcUwkAB4b0q0zeM09yWikoqixaWkop2GLSikooGPBIpwa o6cKVhpkmaXNRg07NKxVx+aM0zNLmlYY7NLmmZpc0rDuOzRmm5ozRYLjs0ZpuaM0WC47NJmm5ozV WC47NJSUUWAdmjNNop2C47NGabRmiwXHZozTc0uadgFzS5puaTNFgHZozTc0Zp2C47NLk0zNLmnY dx+aXNR5pM07BckLUm/mmZpM07C5h5c0hamZpM0WJchxNITTc0lOxLYuaTNGaSmTcWikooAdRmm5 pc0BcXNLmmF1HU0wzeg/OiwuZE2fajdjrVYyMe+PpTc5OSaLC5y15ij+Kk85feq+aM0rC52T+f8A 7P61oaDKT4j0sY63cX/oYrIzWj4f/wCRk0v/AK/Iv/QxWdZfu5ejFKTsQ/GP/keR/wBekf8ANq8/ r0D4x/8AI8j/AK9I/wCbV5/XwB5wUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAV9E+GP8Ak3y0/wCvXUP/AEN6+dq+iPDH/Jvlr/166h/6G9XT+NAeO0UUV9MahRRR QAUUUlAC0UlFABRRSUCFpKKKQBRSUUgCiijNABQCe1JRSAduNLuFMpKamxXJM0VHRuNPn7hcfRTd /qKcCD3quZMAoopKACiijNAgopKKQBRmiigQlFLSUXGFFFFIVwpKWigQlFLSUAFFLSUAJRS0UAJR S0UAJShipyDRRTTsO5MkgbrwafVanrIRweRW8KvSRan3JqKQEMMg5pa2uaBRSUUALRRRTASiiloA SiiigYUUUUAFLSUUALRSUtABRRRTAKKKKACkpaSmIsRXGOH5HrVkEEcHPvWdT45WjPHTuKtSNYVL aMvUtRxyrIOOvpT6s3TuLS0lLQMWlpKBSKHUuabS0DFpabS0WGLRmkoosAuaXNNopWAdmkzSUU7A LmikzRQAuaM0lFMBc0uabRRYLjs0ZpKKdguLnmjNJRRYBaKSimAuaM0lFAC0tNzRmmFxaTNJRTFc CaTNGaTNMVxc0UlJmgVxaKSigQUlBIFNMgHTmgTY6gsB1NRF2Pt9KbTJciQyDtTC7HvTc0ZoJbYU UlFBItFJRQAtLTaWgBa0vD3/ACMul/8AX5F/6GKzK0vD/wDyMulf9fkP/oYrOt/Dl6MHsRfGP/ke R/16R/zavP69A+Mf/I8j/r0j/m1ef1+fHCFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RUkEEtzMkMEbSSucKijJJrQ/4RvWv+gXd/8Afo0AZdFaM2g6tbwvNNp1ykaDczNGQAPWs6gAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACu18BeB4vEwvtV1e7Nj4f0xN93cgfMxxnYnv8A njI45FcVXv8A4Cggf4O2tqUHl3lxMbgf3+WXn8APyrDE1lRpubOjC0HXqKCNG30TwP8A2ag0vwza SW8sYaOa4HmOwI4OWyf1rLgsfDLeHk1C98N6dbmOImceSvylchu3qDVv4W6JqWreDLZ41BgjkkjS aQ4UqHI/Gug8QfDbUfEOkR2sd9B9mldJHaB8+bH1wCccHg556V40li5TcXflvvboe3F4ONNSVua2 zfU858HeHNO1LTZtUvtKtcXkzPBE0QxHHngD9f0q5exeA9PkMV1FpSSDqoUMR9QOldb4h+H9m9la 2mreMLXw9ZxLtaBZkXzF4ABLMuMY9xS6V4K+C+nW/wA+qaTfuo5ludVVmP8AwFWA/SuingqtZupU k436HNUx1KglTpxUrde55jqnhjwtr8Lt4bvbeK/UZWBZPll9trcg+44rzR0aN2R1KupIZSMEGvqX SfAPwq8a289zoNmQLaby2uLWWaIq2M8bjg/XFeDfFDS7fRviTrVha7vJjlRhuOSS0ascn6sa9ChS nS91y5l57nnYitCt7yjyvy2ORoooroOYKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr6I8Mf8m+Wv8A166h/wChvXzvX0R4 Y/5N8tf+vXUP/Q3q6fxoDxyiiivpjQKKKKACikooAKKKKQBRSUUAFFFFIAooooAKSiikIKKKSkIK KKSkAUUUUAFJS0lIBQxFLu9abRQpNCH5BoqPNODetWp9wHUUgINLV7gFFJRSEFFGaSgBaKKSgBaK SlpAFFFFACUtFJTAKKKKACiiigAooooAKKKSgBQSDkHBqVZezfnUaI8hwilj7CrAsLgj7gH1YVLx EaT1lYak0HBopjwTwcshA9eopFlB68V1U68KiumaqaZJSUtFbFCUUtFACUtJRTAWkpaSgBaKACTg ck1KtrM2DswPc4rOpWp0/jaQN2IqKla2mUZKH8Oaip06sKivB3BO4UUUVYwooopiCilpKACkopaY CAkHIP5VaiuM8PwfWqpqRLeVxlUOPfilOrCmrzdhxm4l6gVAkdxF/BuX0zUqsG9QR1BHIp0sRSq/ BJM6YVIy2H0tJS1saAKWkooGOozSUtAwpaSigYtFJS0AFJS0UCCiiigAooopgFFFFABS0lFMAopO aWgAozSUUwFozSUtABRRRTASiikpiA02nH3phcDvQSxaKjMh7cU0knrTJciUuB70wyE+1MooJbYZ NFFJQSFFFJQIKKKKYBRRSUCFopKKAFooooAK0vD3/Iy6V/1+Q/8AoYrNrS8Pf8jLpX/X5D/6GKyr fw5ejB7Efxj/AOR5H/XpH/Nq8/r0D4x/8jyP+vSP+bV5/X58cQUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAU+GGS4njgiXdJIwRFHck4AplaGg/8AIw6Z/wBfcX/oYoA9x+GvgvTvDduup386Pqj4 2gA4iHUEH1z/ACFel/21H/z/AMn/AH8b/P8An14otiTbREnJ2jn6f5/x7VLj2/z0/wDrf/Xr5nEY mnOrJy5u2jX+Wxsk7FW41K2uoHgnu2kicYZWdiCK8A8cfDeWxv8A7ToW25tZXI8pSFZO/wBP8jHt 9E4z2/z/AJ/znNHX/P8An/Ptmqw+PhQbcVJ+rX+QOLZ8lf8ACH6//wBA2T/vtf8AGj/hD9f/AOgb J/32v+NfWv8An+v/ANf/AOtRjH+f8/569q6v7Zj/ACfiT7M+Sv8AhD9f/wCgbJ/32v8AjWK6NHIy OMMpII9DX2fj2/z0/wDrf/Xr5M8axRw+MtUjiRUQTcKowBwO1dWEzCOJm4KNtLilCyuYNFFFegQF FFFABRRRQAUUUUAFFFFABRRRQAV7P4fv2s/gqZE+/ElwV9iWbB/WvGK9r8A28d78PorWdd8Mvmo6 +oLEGvOzOSjSTe10enlUHOs0t7M3vCfxV8G+GfhVpuk3F3cTXq27xy21rAS6szMSdzYXv61F4Y8d +I/Hvh0aVaOukWmmRRRX19BITcTjBCiMYxGTsOTk47VyQ0o+C4Jo7vwtp3iPR2feZHUpcxD0LLzj 3wfwrsPBWiaTqgu9W+GmrwWc88YF5omrKZETB4IKncAMnB+bqee1dSqqtT5qLPPxFCrSvCSsylp2 jeDPGWiatZW2ni1mt2cHUJ8+asgBO9pGJJX1BP4DiuQ+Gnwjv/G7jUL1ns9EVsGYD55yOojB/wDQ jwPQ816h/wAKw8X+IJRa+I9U0mw0hn3XEGjrJvuPYlxwPz+leqqun+HtHjiiRLaytYxHHGvQKBgA etFKLppub0MMPTqW5ZatnOu+leA9Ih0XQrKOLA3BeuCf4mPVmOP09MV8s/EW6mvfH+rXFw++V5F3 NjH8CivedVvnvLi6vJPvPlsegxwPwFfPXjCTzfFd/J/eZT/46K4MHip4jESd/dS0+9HuY7CQw2Gi re83q/kzDooor1jxwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACvojwx/yb3a/9euof+hvXzvX0R4Y/5N7tf+vXUP8A0N6u n8aA8bopKK+lNBaKSigBaKSigAooopAFFFFABRmkopAFFFJSFcWkoooEFFFJSAKKKKACikopAFFF FIQUlLSUAFFFJSELShiKbRRdrYCQMDQajpQ2OtWp9wHUtICDRVgLSUUUAFFFFABRRRQAUUUUALSU UUAFFFFABRRRQAU6KMzSqi9TTau6auZ2b0Wsq9T2dNyQGpa2hJWC2iZ3PRUXLN+XWrljY/bUu28z Z9nt2m6Z3YIGP1q9ZOdP8N3N7FxcXE32VXHVEC7mx9cgVDo80cUWpiSRUL2Tom443NuXge/FfPNt u7AzhDI0LSiNjEpCs+35QT0BP4Gse/thEwkQYRjyPQ11nh2426pHZyZa1vSLeaPsQxwD9QSCDWJq kBiS4hbBaNiM+4Nb4aq6dRW6gYauV6dPSpVcN7H0qGivooVHEpSaLFFRLIR15FSAgjINdMZqWxqp Ji0UUVYwoop8I3TIP9oVM58kXLsFzQtbYrtAQtKxxgDJz6CugbSrDT8Lq17Itx/FbWqB2T/eYkAH 25pPDmI7u7u8AyWlpJPHns4wAfw3Z/CnWGlwyadJq988s8KOQYYOXJ65dv4R79a+OqVJVJOcnqzn buINIs79T/ZF48s4GfstwgSRh/skEhj7da5y7t8qXC4ZfvCuj1too5dMu7K3S0L2yyhYieGDsAc9 c8DmmeJERtTS4VQv2u3juGUDgM6gn9cn8aqjVlSmpx6DTschRQRgkelFfYp3V0bhSUtFMYZooopg FFFFMRbtIAw8xxkfwiuittIiW0S81K6FpBJzEoTfJKPUL2HuaoaTbLc3tjavwssqRsR7kA/zq1rl y91rV07cKshjReyIpwAPwFfHYqvKtVc38vQwbuyytlod2fLtdRuLeU8L9siARj/vKTj8RWTqGnzW lw9vcIY54/8AI57g0ytq9Y3fhiwupOZYJntdx6sgAZfyyRWMJyhJSi7NCTtscyk/zFHG1gce1TVT uhi4b3waSK4ZOD8y/wAq+2w9b2lKM31R3U6t1qXqKajq4ypyKdXQdCYtFFFAxc0daSloAWikzRmg YtFJminYVwozRRQFwooooAWikooAWikpaYBSUUUAFFFG4DvTAWimbx9aQufSgV0SUmQOTURYnvTT TFzEpdR0phkPbim0lBLkwJJ60lFFMkKSlpKBBRRSUCCiikoEFFFFMApKM0lIQtFJRQIM0ZpKKAHZ optLmgBc1peHv+Rl0r/r8h/9DFZma0vD3/IzaV/1+Q/+his638OXowew34x/8jyP+vSP+bV5/XoH xj/5Hkf9ekf82rz+vz44wooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArQ0H/kYdM/6+4v/AEMV n1oaD/yMOmf9fcX/AKGKAPru1/49Y/8Ad9f8/wCf0m/z/n/Pt71Da/8AHrH/ALo/z/n8O9Tf5/z/ AJ/Svi638SXqzoWwf5/z/n/Gj/P+f8/4Uf5/z/n9MUf5/wA/5/XFZDD/AD/n/Pv7Uf5/z/n/AOsf 5/z/AJ/Wj/P+f8/TvQAf5/z/AJ9vevk7xz/yOuq/9dv6CvrH/P8An/P6V8neOf8AkddV/wCu39BX q5P/AB36fqiKmxz9FFFfSGIUUUUAFFFFABRRRQAUUUUAFFFFABXt/wANiD4KtQD0kkB/76NeIV3/ AMOfFlvpTSaVqEgit5n3xSsflR+hBPYHA57fjXn5nSlUoe70dz0sqrRpYi83ZNWPUotTsZr6Wxju omuosb4Q3zDjPSsK88CabPqg1G0uLzTbknLNZSeXn1PTg/Sn+IPCNnr7pf287WmoIAY7qE9fTOOv 161hHVvG/hseXfaemrW69J4gSxHuRz+YrxaEX8VCdpdU9P8AgM93ESXw4iF49Gtfv6o9E0S61XQn Bi1zU7pApUx3s/ng/wDfQyPwIqxe6leajIHup2kI6A8AfQDivMG+KThSq+H7jzf7pl7/APfNY994 u8WavlIUXTYG7qNpx/vHn8q2eGxlXSrKy83/AJGCxWCo60o3fkv8zsvGni610LT5bWN1l1CZCqRg 52Aj7zen0714ncySTTtJMzNIwBYt1PArTvLW3szvkuTd3DHLy4IQfTdyx+oH9RlSyGWVnbqxz9K9 fBYaFCHu6+Z42OxU687y0tshlFFFdpwBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfRHhj/k3u1/69dQ/9Devnevojwx/y b3a/9euof+hvVQ+JAeNUUUV9KaBRRRmgApaSkoAWikopAFFFJQK4tFJRSEFFFFABRSUUhBRRRQMK SiikIKKKKACkoopAFFFJQIWkoopAFJRRSAKKKKBBTg/rTaShNrYCUEGioqcH9a0U+4x9FAOelFUA UUUUAFFFFABRRRQAUUUUAFLSUUAFWtPcJcgH+IYqrR05FRVgpwcX1A7vStmoaZPo7OqTNIJ7YscB nAwUz7jp7ismeCa2maGeJ45FOCrjBFZtvqCsoEx2sP4uxroIfFWpxQiNNQDogwPMCSFfoWBIrwKl KdN2kgLWi2psWXWrxCltbnfCG4M0g+6F9Rnkn2rmtTnLQuznLytk/nkmrOoa1Jdyma7unuJccZbO PYdhWHcTtcSb247AeldGFw8pTUmtEBFRRRXtAFAJByKKKLgSLID14NSVXpyuV9x6VvCt0kWp9yal Rtsit6EGmqwbpS1u0pxa6M03On0e/SwvllkUyW8iNFMo/ijYYOP5/hV7+ztU0qcXmlSST27f6u4t wWDD0Ydj6g1ydvdeWAj8r2PpWna6lLbNutbySFj3jkKk/lXymIwtSjJprTuYtNHQz217q8sN5qsE enWNvGI2fy/LBAJOFU9WJJ6cVjazqIvr6a7CeXHgLHHn7qKMKPyAqrdak9w2+6u3mYcZdy5rMuLk zYUDCD9arDYOpWktNO41FsgzRRRX1a0NgooopgLRSUUALRSZopga9lOyLDLG2HjIIPoRXY3Dw6nH /aGnaLZ3bP8ANcxZkMsbnqdoblSeQQK89gnMLcDKnqK0YL1UcSRTGNx0IbaRXy2MwdSlUbSvFmMo tM6e2iuLqTanhi1VR96SQSoij1LF8CqviC/tZjBY2CRLbW2SxizteQ43EZJOOABmsq51a6uU2XWo TSqOdskxYfkTWZPdhlKR9D1asKGFq1pWgvn0Ek2V7hw87sOmcCo6KK+vpQVOCguhutByOyNlTirc Vwr4B4aqNGa1TsXGbiauaWqEVyycN8y/yq2kiuMqc1adzojNMkpaTIozVFi0UmaM0ALRSZpM0AOo puTRTC46jNNooC4uaMim0UBcdupN3tSUlAri7jSZJ70UlMAooozQIKSiimISg0UUCEoopDTEFFJm igQUUlFAgoopKACiikoEFIaM0lFxC0lFGaVxBRSUZpXELRTc0ZouA6im5paLhcWtLw9/yM2lf9fk P/oYrMrS8O/8jNpP/X5D/wChis6z/dy9GDegfGP/AJHkf9ekf82rz+vQPjH/AMjyP+vSP+bV5/Xw ByBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABWhoP/ACMOmf8AX3F/6GKz60NB/wCRh0z/AK+4 v/QxQB9d2v8Ax6x8fwipv8/5/wA/pxVO0u7Y2kRFxEQV7OP8am+1W/8Az8Rf99j6/wCfz68V8VWa 9pLXqzpWxNRUP2q3/wCfiL/vsUC4WSaGC22zzSsVVFcDopPrxwD/AJNTCLnJRjq3+IbE3+f8/wCf 15o/z/n/AD/WsSTxNZq18kZjmlsWVbqKOZC8WXCcjPqRWr9qtz/y3i/77FXWo1KNvaKwk09ib/P+ f8/pxXyd45/5HXVf+u39BX1X9qt/+fiL/vsfX/P59eK+VPHBB8a6qQcgzdfwFehk/wDHfp+qJqbH P0UUV9IYhRRRQAUUUUAFFFFABRRRQAUV6Lpum2EmlWbvZWzM0CEsYlJJ2jnpVr+ytO/58LX/AL8r /hXQsO2tzyJZvCMmuV6HmFFen/2Vp3/Pha/9+V/wo/srTv8Anwtf+/K/4U/qz7k/2zD+VnnMGo31 qmy3vLiFP7scrKP0NS/21qv/AEE73/v+3+Neg/2Vp3/Pha/9+V/wo/srTv8Anwtf+/K/4VDwie9i lniWiT+889Or6m33tRuz9Z2/xqM6het968uD9ZW/xr0b+ytO/wCfC1/78r/hR/ZWnf8APha/9+V/ wp/VF5B/bifR/eeYu7SMWdizHqScmkr0/wDsrTv+fC1/78r/AIUf2Vp3/Pha/wDflf8ACn9Wfcn+ 2Yfys8wor0/+ytO/58LX/vyv+FH9lad/z4Wv/flf8Kf1Z9w/tmH8rPMKK1PEUUcGu3McUaRoNuFQ YA+Udqy652rOx61OftIKa6q4UUUUiwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAr6I8Mf8m92v/XrqH/ob18719EeGf8Ak3u1/wCvTUP/ AEN6qHxIDxnNGaSivpC7i5ozSUUXC4UtJRSuK4UUUUAFFFFABRSUUhBRRRQAUUlFAwooopCCiiko AWkoopAFJS0lAgooopAFJRRQAUUUUCCkoopAFFFFIAooooAOlOD+tNopptASgg9KKipwf1q1PuMf RQCD0oqwCiiigAooooAKKKKACkzSOcKTXqPiHwd4f0jRroppGqvbpYCe11+3mM8NxNtB2sijCISS MnH8qwq1402k+oHmFFdde/DbWLGyuJjfaTNcQWgvXsobkmfyMZL7So4GfXPpnjMN98Pdb0/RpdQl ks2kggW4uLJJibiGJsYZlxjuMgEkZpfWaXcDl6K668+HGr2Nhf3E1/pPn6fbfabyyW5LTwKQCAyh cZ59ce/TK6r8ONW0a2vJ5r3SrmSwMTXVpb3LNKiORtYjaMA5Hv3o+s0u4HIUVseLbH+zPFupWIs4 LPyZdv2eCVpUTgcBmAJ/EVj1rCXNFSQBRRRVAFFFFABT1l/vfnUZ6V6f4c8HaLqGh+FWuPD2rX0u stMlxfWk7BbTbKUDFdpXGOTkjoetRUxPsNRptHnAIPQ0tdXqXhLYuk2do2mW8ctxfxjU57xlFwkM u3c4IwuBjATJOagv/Amr2H2wmeynS3sF1JWhlYie3LbS6ZUdO4OK2p4+lJauzNFJM5qiujv/AANr NhppvGe1lZBbGW2hdjLF54/dhgVABJwOvUirV94PurDSpbKWPSzdR60ti+ofbGUKxh3mMhgFCjqW 65BGKp42l0YcyOSora8QeFb3w7b2V1NdWV5aXm8Q3FnIXQlCAw5AOQT6YNYtdFOrGpHmi9Bp3Cik orUYtLTaWgBaKSigBc0ZrtvBvhvT9U8Oahqkmk3Wu30FysI061uvJdIiuTKcDLc8ADuKddeDNGk0 rxXqVlqUtvHpk0K20F/mKRQwyyyoUzkn5U5GSpzXFLH04zcH0FzHD0V0l34D1ez0qe7e409ri2th d3GnpcZuYYSAd7LjGMEE85GRVjVPh1rGkwXzyX2lXFxYxC4uLS3uS0yRHHzlSo4GR7+3IrRY2g3b mDmRydFIDkUV1lBRRRTAKVWKnIODSUUDLUd12kH4irKuHGVIIrMpysVOVJBq1M0jUa3NOiqaXZHD jPuOtWEmjfowz6GtFJM2U0ySikpaZQUUUUAFJRRQAUUUlMAoopKBBRRSUAFFFFAgpM0UlMQUUUlA gJpKKSgQtJRmkoELSUZpKYri5pKM0maVxBmjNJSZoELmkzRSZpXELmkzSZozSuIM0ZpM0maVwFzR mkopXEOzRTaKLgOzWn4d/wCRn0n/AK/If/QxWVmtTw4f+Kn0n/r8h/8AQxWdV/u5ejB7DvjH/wAj yP8Ar0j/AJtXn9egfGP/AJHkf9ekf82rz+vgzmCiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK3vCdv Dc6rKk8McqiAkK6hhncvPNdj/ZWnf8+Fr/35X/CtoUXNXuedicxjh6nI43PMKVHaN1dGKupyrKcE H1Fenf2Vp3/Pha/9+V/wo/srTv8Anwtf+/K/4Vf1Z9zn/tmH8rPOxquoqAFv7oAdAJm/xpf7W1L/ AKCF3/3+b/GvQ/7K07/nwtf+/K/4Uf2Vp3/Pha/9+V/wqPqUfL7h/wBsw/lZ55/a2pf9BC7/AO/z f412/wAKfFtvonjVbzXtWmgsxbSoJJC8gVyMDgZNXP7K07/nwtf+/K/4Uf2Vp3/Pha/9+V/woWDS 1Vg/tmH8rOgvdc8A6d8PdaisNea88TX9uUnuCk264fzA2csgA6ZHp0yeteOf2tqX/QQu/wDv83+N eh/2Vp3/AD4Wv/flf8KP7K07/nwtf+/K/wCFN4Tm3sL+2Yfys88/tbUv+ghd/wDf5v8AGq0ssk0h klkaR26sxyT+Nemf2Vp3/Pha/wDflf8ACj+ytO/58LX/AL8r/hQsIltYP7Zh/KzzCivT/wCytO/5 8LX/AL8r/hR/ZWnf8+Fr/wB+V/wqvqz7h/bMP5WeYUV0/jC1t7b7F9nt4ot2/d5aBc/d64rmKwnH ldj08PWVemqiVrhRRRUmwUUUUAFFFFAHrfhi/XTtPtJWsrS7DWqLsukLKOAcgAjnj9a7fVdTs7HR dGvIvD2jGS9ikeQNA2AVfaMfN6V55pX/ACB7L/r3j/8AQRXWa7cwTeG/DkUU0byQwSiRFcEoTISA R24rvtex8kqjXtF/W6C702+1CPQoYba0D3iN5C26FWOZCPnJ9OeewFSL4Q883a2WsWF09nE8twsZ cFQoycZUbh2yPUVo2OtWWnXXhG5kmRktoJUnCMGaLczjJA5BAbNS+H9Gh0yfWJf7Vsrkf2bciIW0 u8su37zAfdHsecmk5NGkaUJNde+u2i/W5zmn6D9p0/8AtC8vrewsy5jSSYMxkYdQqqCTjuelWIvC F9NrcWmRTW7meA3EE6sfLlQAnIOOOhHPQ1saXqH27wnY2Fm+ki9spJQ8OoxxHzFdtwZGkGPUEZ7C n2uozxeIIV1K+0sLDp9wkf2Ro1jj3K2EyuF3E9h603KWoo0aVo3621/P+rFLRtG06S/m0hryzvp7 22dYZIg2IJ15UBmAyDgjI61R8K6fBLqN1eajCHs9OgeeaNxw7DhUPuWI/KsW0upbK8guoG2ywyLI h9CDkV2fiu/0uHR5V0m4ikfWrgXdwiMCYVCgiNsdDvZj+FDunbuRTcJR52kuXp37fjv6jtD0jTdW 8HNHLbxJqV5dyxWtwBjDqisqfQ8j8axFsYU8C3VzJbgXcepLDvI+ZV8skr+Yp5vUh8CWUcNyi3cW pvKEVxvUbFw2OuMjrWz4h1HTdQ8Em7t7iBby9vY57m0DjckgRldtvXaSAc/7VLVP5mloSj0uo/p+ aZS1V7LwlLFpcOl2d3fLEj3c94hk+dgG2qucAAEc9TXO6ne29/cJNBYQ2R2ASJCTsZsn5gDnbxjj 2rpNYtovF1xHq9jfWcd1LEi3VtczrEyyKoUld2AVIA6Vzep2CabcJAt7bXTlAztbtuRGyfl3dCcY PHHNVC3XcyxHNry/D02/r1/E8u8Tf8jDdf8AAP8A0AVk1reJv+Rhuv8AgH/oArJrhn8TPp8L/Ah6 L8goooqTcKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAK+iPDP/ACb3a/8AXpqH/ob18719EeGf+Te7X/r01D/0N6qHxIDxiiikr6MoWiko zSAWikooEFFFJQAtFJRQAtJRRQMKKKKQgooooAKSiigAoopKQhaSiigAooopAFJRRQAUUUUCCkoo pAFFFFABRRRQAUUUUgCiiigAooopAFOD+tNopptASjBoqMEg8U8MD161qpJjFopaSqAKKKKAEYZF duvj7T7LT9SGleGlsL/UbNrSdorxvswDDDOsGMAkdOTj35zxNGKyqUY1PiA9J8S+PNHjvbuTRtKj n1GfSo7A6p9ocAI0ah/3RGNw5XOe350NZ+J93rOiz281rerfz26wSTLqswgOAAWEAwoYgc5JHfHN cLiisVg6aQHrmteKfDT6Br16t1p1zq+r2C2zy20M8c8r/KCXRiUjAxzgndgVyN948a91jxHqH9mB P7atooPL8/Pk7NnOdvzZ2dOOvtXI4FFEMHCO+oGp4l1n/hIvEt/rBt/s/wBrk8zyt+/ZwBjOBnp6 Vl0UV0xioqyEFFFFMAoopaAENdjpPxEvtGt/DlvbW7eRpInSeIznZeJK5YhlxgYBIB+bnn2rj6MV nUpxqaSA7jS/iLDpDabHa6EVtrFL2KNfth8xUuHDDY+zKsgGN2DnJ6U67+Jj3PinS9XGkuYLOyax mtbi9aY3UTbtwd2XPO7uDyPwrhKKx+q097AdrpPxIu9O8aar4hudPS8TUTl7R5MKhVg0RBwc7Nq4 4/Ko9C8ez6TDB52nx30yaydWkklkwJGMTIVxtOD824N2IHFcdSg46VqqFLaSKT7nYeL/ABsPFWna fZLY3MC2cksglub5rl3344JZRjGPpXKU1WB46GnV30KcKcOWGxorW0CiiitxhRRRQAtFJRTA3dC1 rSdOtHt9S0H7a4mE0N1b3TW08ZxgrvAOV9uxya09Q8fHV5PEv9o6SkkOtJCFSO4KG3aEERtuwd/v nGfauQorllgqUpOTWorI7C/+ICXdrqFwmhxx67qNgLC71D7SxV49qqxEeMBiqgZz2rX8X+OtHfWd dfQ9Ljku9RtFspNV+0Ph4SiBgIiBg/Ltzn+GvN6KhZfRUkw5UA4FLRRXeigooopjCiiigAoopKBi 0UUlAEiSun3XOPSplvGH3lB+nFVaWmpNFKTWxdW7jPXK/UVIJoyM71/E1m0VfOyvas1e1FZQJByD zThLJnO9vzp85XtV2NKiqH2mX+/+gp32uTHRfyp86H7WJcoqoLs90BPscU4Xa/xIR9DmnzIftIli ioRdIT0YfhTvtEf979DT5kHMu5JSGm+an99fzpQQRkc0x3CiikzTFcM0lGaSgVwopM0ZoEFJRmkz RcQtJSZooEFBNITSUriFzSUUlIQpNJRSZpXEGaSikzSuIWkoopXEFFJRmlcBaKTNGaLgLWp4c/5G fSf+vyH/ANDFZdafhz/kaNJ/6/Yf/QxUVX+7l6MGSfGP/keR/wBekf8ANq8/r0D4x/8AI8j/AK9I /wCbV5/XwhzhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAdF4N/5DEv/AF7n/wBCWvZLKW103wNFqB0u xu7iS/eEtdRlsKEBwMEd68b8G/8AIYl/69z/AOhLXs1nbRap4Dhsk1DT4LiPUHlZLm5WI7dgGcE+ tddP4F6ngY2/1mVt+UhmttO1zw3fanaWKWF7p7IZ4oWYxyo5xkBiSpB96ji8IOWtre41SyttRuUV 4bOUvuO77oZgNqk9gT3FTSSWXh/wzqGnR38F7qGotGsn2Ylo4Y0O772MEk+laOo2ltrviaDxBFql jDYy+VLP5s6rJAVVQy7DyT8vGBzxV3a9Dk9nGVrq8tLr5vXTyt+py0+iXVvpct7LtXybs2ksPO9H xnntjgj8K0bnwZqFrr9jpDywGa7TerqTsTGdwJx1Xac1uaLq+l6r4i1xb+eO3sLudbyNpWC5McgI HPdlLCm2Ov2tzoGpand3Maanbm5W2jLgO32gryo6naS549aHKQRo0Wr3/pPX71sc/aeGjPpS6pPq Vpa2RmaEyS7idwAPCgEnOe3oc1b07QzpvjXRrW5aC6t7mWKWORPmjljY9cEexBBqrdXELeBtPtlm jMy3sztEGG4AquCR1x1rXgvrQav4Mc3UAS3ijEzGQYixKx+b049abb/MmEad1ptyv8rmPDoLX8+o 3clzBZWFtMUeeUHAJJwqqoJJ9hUN/oEljPZf6ZbSWd7/AKi8ViIyM4OcjIx3GK2IWg1fQdR0eO7t 4bpdSN5D50oRJlKlSAx4yOvJ71ahk0iyPh3RdSube5jgnkmu2R98UZf7qlhwRkDd2o5mh+xg1+vn e1vu/wAzCn8OxmwuLvT9VtL/AOyqHnjiV1ZVzjcAyjcMkZI9aWDw3mwtrm81O0sWuwTbRT7t0gzj cdoIUE9Ca6iK7uLfTtcj1XVNHHm2MqW1vaGEbjkdCg/IE5PpxWRqFpF4isNIu7a/sofs1mlpcx3E 6xtEUJ+bB5YEHPGaSkxyowWqWttvn6/r5j9f8PvdeMbixgFvaJb2kcs7N8qRqsa7mO0c8nt1Jrnt RsLWzSN7XVbe+VyQREjoy49Qyjiup1S7km8d3Fxomq2S4tY1WWeVBHMuxFKHd8pJ9D6HuKoeJls/ 7KtXli02HWDMwkTTmBQxYGCwUlQ2c9O1OLeiFWpxfPJLq/z6HlHjb/lx/wC2n/stclXW+Nv+XH/t p/7LXJVy1vjZ7uW/7rH5/mwooorI7gooooAKKKKAPT9K/wCQPZf9e8f/AKCKt1U0r/kD2X/XvH/6 CKt16UdkfFVfjl6sfFIYZklCqxRgwDjIOPUdxWzN4muprOa0tbKwsluBtmNpBtaReu0nJ49hiqya SJvDcuqxTFnguFimh2/dVhlXz7kEVqaXoslrf+G5Y71oL2/m8xAIw3kpvwr89c4Jx7Um0aU41Fot n+uhzHSiugt9FhmXUNS1S9eGyguDCXjiDSTSnJwq5AHAycmrEPha0vL3TDZ6g7WGou8SSyRbXjlU fcZc45JXkHvRzolUJvb+uhy9Fb9r4Zefwzfaq8/lz27sEtivLqpQOc+28VInhVpLyxtvtYTzbH7d dSOnFvHye3JO3B/EU+dB7Cpppuc5RW/Poum3OmXd5o99cTNZgNNFcQCMlCcb1wx4BI4PrUuraDpe jQILjUppLue2SeKKKAYXcucOxbjnPQH170cyB0JpX6eqOboooqjE878Tf8jDdf8AAP8A0AVk1reJ v+Rhuv8AgH/oArJrzZ/Ez7LC/wACHovyCiiipNwooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr6I8M/wDJvVr/ANemof8Aob18719EeGf+ Terb/r01D/0N6qHxIDxekoor6IoKKKKQBRRSUCFozSUUALmikooAWkoooAKKKKQBRSUUCFpKKKAC iiigAopKKQBRRRQIKKSigAooopAFFFFABRRRQAUUUUgCiiigAooooAKKKKACiiikAUUUUAOVscGn 1FSq2PpVxnbcCSigEEZorUApaSigAopaKAEopaSgAooooAKWiikAUUUUAFFFFABSUUUgCiiigApw fHXmm0U4ycXdAnYlBB6UtQgkHIqQMD9a64VVLR7milcWlpKK1LFopKKYC0UlLmmAUtJRTHcWikop gLRSUUxi0UUUAJS0lLQMSiiigAooooAKDRRQAlLRSUwFoopKBBRRRQAUuaSloAKKSigBwdgMBiPx pwlcD71Mop3YXJRO3saXz/8AZ/WoaKfMyuZk/nL6Gl8xT3qvRT52HMyzkHoRRVbNKCR3p84cxPmk zUW8+tLvNPnQ7klFM3j0pdwp3QXFJopMikpXEGaKKSkIKKKSkIKKSilcAooopXAKKKKBC1p+HP8A kaNJ/wCv2H/0MVl1p+HP+Ro0n/r9h/8AQxUVX+7l6MGTfGP/AJHkf9ekf82rz+vQPjH/AMjyP+vS P+bV5/XwxgFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB0Xg3/kMS/8AXuf/AEJa7ivLbK+udPmMtrJ5 bldpO0Hjr3+lXv8AhJtY/wCfz/yEn+FdFKtGMbM8fG5fVr1eeLVv68j0SivO/wDhJtY/5/P/ACEn +FH/AAk2sf8AP5/5CT/CtPrETj/sev3X4/5HolFed/8ACTax/wA/n/kJP8KP+Em1j/n8/wDISf4U fWIh/Y9fuvx/yPRKK87/AOEm1j/n8/8AISf4Uf8ACTax/wA/n/kJP8KPrEQ/sev3X4/5HolFed/8 JNrH/P5/5CT/AAo/4SbWP+fz/wAhJ/hR9YiH9j1+6/H/ACPRKK87/wCEm1j/AJ/P/ISf4Uf8JNrH /P5/5CT/AAo+sRD+x6/dfj/keiUV53/wk2sf8/n/AJCT/Cj/AISbWP8An8/8hJ/hR9YiH9j1+6/H /I1/G3/Lj/20/wDZa5Krd9qd5qPl/a5vM8vO35QMZxnoPYVUrmqSUpNo9vCUZUaKpy3X+YUUUVB0 hRRRQAUUUUAen6V/yB7L/r3j/wDQRVuqmlf8gey/694//QRVuvSjsj4qr8cvVm74Yv7O2uLuy1KU xaffW7QyuFLeWw+ZHwOSQwH51dfXbOX4gWmoBzHplpPFHCdp+WGPABxjPQZxjvXK0UnFN3KjXlGK iujv/Xkdno/iOOOx1HTU1WXS2lvDdQXaKxVsjBVwOQCMHp2qjq2r3UdxYTHxG2rS283mgBXCRsCC CCwGSfYdq5qijkV7lPETceX/AD/zsd9qHiPRX8UWiW0zf2M0U6XLbGBBnLF+MZ4yvQfw1Vh8V20H jjUL9ZJY7G5iazjmhBDxR4Co6g+m1TiuLopezRTxdRu/nf8AT7jrdW1K5bTbhH8Zvfq4AW3VJf3g yPvbgAvHPfpWZ4nv7bUdSgltZfMRbSGMnaRhlQAjn3rFoqlFIznXlNNP9f1YUUUVRied+Jv+Rhuv +Af+gCsmtbxN/wAjDdf8A/8AQBWTXmz+Jn2WF/gQ9F+QUUUVJuFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFfRHhn/k3q2/69NQ/9Devn evovwnDLcfAGyggjeWaS2v0SNFLMzF3AAA6kntVQ+JAeJUVtf8If4n/6FzV//AGT/wCJo/4Q/wAT /wDQuav/AOAMv/xNe9zx7jMWitr/AIQ/xP8A9C5q/wD4Ay//ABNH/CH+J/8AoXNX/wDAGX/4mjnj 3AxaK2v+EP8AE/8A0Lmr/wDgDL/8TR/wh/if/oXNX/8AAGX/AOJo549wMWitr/hD/E//AELmr/8A gDL/APE0n/CH+J/+hc1f/wAAZf8A4mjnj3AxqK2f+EP8T/8AQuav/wCAMv8A8TR/wh/if/oXNX/8 AZf/AImjnj3AxqStr/hD/E//AELmr/8AgDL/APE0f8If4n/6FzV//AGX/wCJo549xGLRW1/wh/if /oXNX/8AAGX/AOJo/wCEP8T/APQuav8A+AMv/wATRzx7gYtFbX/CH+J/+hc1f/wBl/8AiaP+EP8A E/8A0Lmr/wDgDL/8TS549wMWitr/AIQ7xP8A9C5q/wD4Ay//ABNH/CH+J/8AoXNX/wDAGX/4mjnj 3AxKK2v+EO8T/wDQuav/AOAMv/xNH/CHeJ/+hc1f/wAAZf8A4mjnj3AxaK2v+EO8T/8AQuax/wCA Mv8A8TR/wh3if/oW9Y/8AZf/AImjnj3EYtJW3/wh3if/AKFzV/8AwBl/+Jo/4Q7xP/0Ler/+AMv/ AMTRzx7gYlFbf/CHeKP+hb1f/wAAZf8A4mj/AIQ7xR/0Lesf+AMv/wATS549wMSitv8A4Q7xR/0L esf+AMv/AMTR/wAId4o/6FvWP/AGX/4mjnj3AxKK2/8AhDvFH/Qt6x/4Ay//ABNH/CHeKP8AoW9Y /wDAGX/4mjnj3AxKK2/+EO8Uf9C3rH/gDL/8TR/wh3ij/oW9Y/8AAGX/AOJo549wMSitv/hDvFH/ AELesf8AgDL/APE0f8Id4o/6FvWP/AGX/wCJpc8e4GJRW1/wh3ij/oW9Y/8AAGX/AOJpf+EO8Uf9 C3rH/gDL/wDE0c8e4GJRW1/wh3ij/oW9Y/8AAGX/AOJpf+EO8Uf9C3rH/gDL/wDE0c8e4GJRW3/w h3ij/oW9Y/8AAGX/AOJo/wCEO8Uf9C3rH/gDL/8AE0c8e4GJRW1/wh3ij/oW9Y/8AZf/AImj/hDv FH/Qt6x/4Ay//E0c8e4GLRW3/wAId4o/6FvWP/AGX/4mk/4Q7xR/0Lesf+AMv/xNHNHuBi0Vtf8A CHeKP+hb1j/wBl/+Jo/4Q7xR/wBC3rH/AIAy/wDxNLnj3AxgSOlSA5Fav/CHeKP+hb1j/wAAZf8A 4mlHg/xQDkeG9Y/8AZf/AImqjViuozJoraHhDxOf+Zc1cf8AbjL/APE0f8If4m/6FzV//AGT/wCJ rX2ke4GLS1s/8If4m/6FzV//AABk/wDiaP8AhD/E3/Quav8A+AUn/wATRzx7iMaitr/hD/E//Qua v/4BSf8AxNH/AAh/ib/oXNX/APAKX/4mjnj3AxaK2v8AhD/E3/Quav8A+AUn/wATR/wh/ib/AKFz V/8AwBk/+Jo549wMWitr/hD/ABP/ANC5q/8A4BSf/E0f8If4n/6FzV//AACk/wDiaOePcDFora/4 Q/xP/wBC5q//AIBSf/E0n/CH+J/+hc1f/wAAZP8A4mjnj3AxqStr/hD/ABP/ANC5q/8A4BSf/E0f 8If4n/6FzV//AABl/wDiaXPHuBi0Vtf8If4n/wChc1f/AMAZP/iaP+EP8T/9C5q//gDJ/wDE0c8e 4GLRW1/wh/if/oXNX/8AAGT/AOJo/wCEP8T/APQuav8A+AMn/wATRzx7gYtFbX/CH+J/+hc1f/wB k/8AiaP+EP8AE/8A0Lmr/wDgDJ/8TRzx7gYtFbX/AAh/if8A6FzV/wDwBk/+Jo/4Q/xP/wBC5q// AIAyf/E0c8e4GOHI69KfnPNav/CH+J/+hc1f/wAAZP8A4mlHhDxOP+Zc1f8A8AZP/ia2hiYrRspS 7mTRWyPCPiY/8y7q4/7cpP8A4mj/AIRDxN/0Lur/APgFJ/8AE10qrB/aRpcxqK2f+EQ8Tf8AQu6t /wCAUn/xNH/CIeJv+hd1b/wCk/8AiaftYd0FzGorZ/4RHxN/0Lur/wDgFJ/8TR/wiHib/oXdW/8A AKT/AOJqvaw/mQGPRWx/wiHib/oXdW/8ApP/AImj/hEfE3/Qu6t/4BSf/E0/aw/mX3hcx6K2f+EQ 8S/9C7q3/gFJ/wDE0f8ACI+Jv+hd1b/wCk/+Jo9rD+ZfeVcxqK2f+ER8Tf8AQu6t/wCAUn/xNH/C I+Jv+hd1b/wCk/8Aiaftaf8AMvvC5jUVs/8ACI+Jv+hd1b/wCk/+Jo/4RHxN/wBC7q3/AIBSf/E0 e1p/zL7wuY1FbP8AwiPib/oXdW/8ApP/AImj/hEfEv8A0Lurf+AUn/xNHtaf8y+8dzGxRWz/AMIj 4l/6F3Vv/AKT/wCJo/4RHxN/0Lurf+AUn/xNHtaf8y+8LoxqK2f+ER8Tf9C7q3/gFJ/8TR/wiHib /oXdW/8AAKT/AOJo9rT/AJl94XRi0Vtf8Ij4m/6F3Vv/AACk/wDiaT/hEfE3/Qu6v/4BSf8AxNP2 sP5l94XMaitn/hEPE3/Qu6t/4BSf/E0f8Ih4m/6F3V//AACk/wDiaPaw/mX3iujGorZ/4RDxN/0L ur/+AUn/AMTR/wAIh4m/6F3Vv/AKT/4mj2tP+ZfeFzGorZ/4RDxN/wBC7q3/AIBSf/E0f8Ih4m/6 F3Vv/AKT/wCJpe1h/MvvC5jUVs/8Ih4m/wChd1b/AMApP/iaP+EQ8Tf9C7q3/gFJ/wDE0e1p/wAy +8LmNRWz/wAIh4m/6F3Vv/AKT/4mj/hEPE3/AELurf8AgFJ/8TR7Wn/MvvC5jUVs/wDCIeJv+hd1 b/wCk/8AiaP+EQ8Tf9C7q3/gFJ/8TR7WH8y+8LmNRWz/AMIh4m/6F3Vv/AKT/wCJo/4RDxN/0Lur f+AUn/xNP2tP+ZfeFzHorY/4RDxN/wBC7q3/AIBSf/E0f8Ij4m/6F3Vv/AKT/wCJo9rT/mX3hcx6 K2f+ER8Tf9C7q3/gFJ/8TR/wiPib/oXdW/8AAKT/AOJo9rD+ZfeFzGozWz/wiPib/oXdW/8AAKT/ AOJo/wCER8Tf9C7q3/gFJ/8AE0e1p/zL7wuY2aXJrY/4RHxN/wBC7q3/AIBSf/E0f8Ij4m/6F3Vv /AKT/wCJo9tD+ZfeFzH3GlzWv/wiPib/AKF3V/8AwCk/+JpP+ER8Tf8AQu6v/wCAUn/xNP20P5l9 4XMnNJWv/wAIj4m/6F3Vv/AKT/4ml/4RHxN/0Lurf+AUn/xNL20P5kF0Y9FbH/CI+Jv+hd1b/wAA pP8A4mj/AIRHxN/0Lur/APgFJ/8AE0e2p/zL7wujGorZ/wCER8Tf9C7q3/gFJ/8AE0n/AAiHib/o XdW/8ApP/iaPbU/5l94XMfNFbH/CIeJv+hd1b/wCk/8AiaP+EQ8Tf9C7q3/gFJ/8TR7an/MvvC5j 1qeG/wDkaNI/6/Yf/QxUn/CIeJv+hd1b/wAApP8A4mtHQfC3iG38RaZPPoOqRRR3cTvI9pIqqocE kkjgAVFWrDklqthNlD4x/wDI8j/r0j/m1ef16B8Y/wDkeR/16R/zavP6+LMQooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAtJq V/Giol7cqqjAUSsAB6daX+1dR/5/7r/v83+NVKKfM+5HsodkW/7V1H/n/uv+/wA3+NH9q6j/AM/9 1/3+b/GqlFHM+4vZQ/lX3Fv+1dR/5/7r/v8AN/jR/auo/wDP/df9/m/xqpRRzPuHsofyr7i3/auo /wDP/df9/m/xo/tXUf8An/uv+/zf41Uoo5n3D2UP5V9xb/tXUf8An/uv+/zf40f2rqP/AD/3X/f5 v8aqUUcz7h7KH8q+4t/2rqP/AD/3X/f5v8aP7V1H/n/uv+/zf41Uoo5n3D2UP5V9w+WWSeQySyPI 56s5yT+NMoopGiVtEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABX1F8Kf+SYeF/+u9x/6PNfLtfUXwp/5Jh4X/673H/o80Aem0UU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFAHH6bNrGr6bHqH/CQJp9s+F8yaKIq8h6qoIGAD8uSSSQeKt2F9qVp4lTSN QuWnkaJ3bcqAYGNrqVUcHLDB6EVxMGq3Mnhu20FNJF3ApSeOeQHEZI3NjkAkFm6nuQRW2t/I5h8T TXZlvo7YL5ZVQrR9SmAPvHJ59T0xxXXmeIpYGyqr4rpWS8rP/P8AA8ijiYys1J3Vr6v5nS6vd3S6 pa2lneLC5gkmZCqtuwyBdwPIU5bpjp7Vmv4u1ILIY/D8koQNkxzE7mUSbgMIe8RH1dP73EfimW30 zxFZahI7B5rSWDHXdtdCoUdydzVzGn3sUEWsrdPaW812zgxSyRhskvw2Y+nzDljIMdABweujhozo xla//Du+xOIxdSlWkr6aHo9jq8NzpzXdwUtRHI0UvmSDajK20/Nxxn+dc5q/ipbS6lMN/JNGZiiJ bSw4VRHGc8xsTlmbv/CfSmeGnS38FwySNHHEmoxsWyAgX7QnOQFGMc5wBjsKrafF4tt7uyvr+5mT TRLE8s0mooY/LLDnO/BBB/HNc9OhB1J8zSUXs3a+501q9RU4KCbcuqV7bGroOuz6jd2jCadoZjPG 8cxjbBQRkEFUX++Rzmuivb6GwiV5AzO7bY40GWdvQD/IFcz4P0icWljqEs0IjVGMUMMQUfOAGLHG Sx2rkkn8KS81OJvEd8zyp/ogWFAWGEBUMx/EnH/AazpUo1qr5VZbmlatLDUU5u72NCHUb648y6SR VZH2fYZCi7uGJQHO7zAqlv7pB4zgkWrjWJN1kLG3jmF3A06mWUxgKNnorcnePyrmozJ4j1BEst62 wwt1cAkLLHn7n+0M9+nbua1dbkWx1XS0T5UW1nRR7BoatYeKrqnvv+TM5YqX1V1tn/wSlcr4zmuJ JIdSsII2OViUbgo9MlMmrWnalqyaLrSX9xFJe2KMVmjUY5j3jjAHGfSo/wC0/wDa/WodPZ7ux8Ve WrO7rtVVGSx8gAACt8TTtSd4pfI5cDinVrWu2Vb/AMWSWOo3Np51+/kSvFu82AZ2kjOPJ9qtaT4i uL+eFkmuNv2qOF0maNwyukh/hjUggoO9Zc/gjU9fvbrVbC9sWtbq4lkj3mRGA3nggpwR0qbTNEuf Dup29jeTwy3Et3BOFgDsFQLMuWJUAZJAAzmrxFLBrD81Nrm06vyuPDTxzxKVX4Nei87G94k8SHSY 0FqU8xZjHK08L+WoETSY3jAycL3OAc4NY9jrN5dafbXEmt3aySxK7KscGASASBmPpVbxpp1zqMzp b6fPeKl65YRQs+0+Rb4zgcd/1rnrDw5eJFcte2+r2sMccYjLtLGoJmjXAz/ss3H+FVhqNFYb2s7P 7r7+ZtVxMniPYpNefTY7mbXNRfwPpt/Cf9MuzAjSIoyCzAEgEbQT0+YqvPXoDnXutazYwm4juL+U 280azx3CW+1SZNmw7F3EnB+5u7GrPjXTrax8GWljGhFrDdQICRkou7HXacdcZyvXGedrcx4i1V9S 0u2iktTFKJY5Lp+D9quMpGGAG7jYp4K/xdDjnPDUlOHMopq76bHXUdpas1vCOv67qPjm7gvdRebT pBqBgtzFEBH5N0kaYZVBOFYjknNdHqevSi6W3tCkUAm8ia7cZ2tgnCjocEAEnjJ71zHg2VX8V2yj BZU1vJznOb+Lvk/zNL9qthoEtnqHBhUrcp/Erg5J+ueRXl5XetSnUnq4uW/lKSX4IyzLGKCi6eie mndJJ/e7mtZeJpFvWBuLi4tleNXa4hRCyudqvGVAyueDkd62L6e6l1d7SK8e2iigSQmNELMWZx1Y EYGz071yMrzanZWlvJGJNUzm32YyMHILdscDd29O1bGvup1+5t2kkj86xiAaNyjD55clSOQRkVOV Yr69duKTXbZ+hyzrzhQcm3uh+n6vFqt3e2tl4ivJZ7GTy7hfIjXY2SMZMQB5U9M9K1NO1gDQ7q91 CUBbJplmlCnlYyctgewzgV5j4X8M3mi65e311qU7xs5KhZmHnnk75OeSMng55z+PY2qyXvw78QLb o00k63wjWMbi5YNgADrnIr08ZRUKd13XTyY8DiPaVXHmurf5G9YeJ9N1QTLZG5knih877PJbSQSu h6FVkVcgkYz0z3rWicyRI5RkLKDsfqvsfevPTouo6e8r3D6hqjXuhSW0MkkS7rV1XcYiI1UYfIwS M5TGTkVj+KbFYvDuuvq2lXc9wdHjXTp1t2YQAQ4dd4GIiG3FgSNwIHPSvNPWPULbUobrUb6yjWQS 2bIshYDB3LuGOfQ+1SW19bXkt1FBJve0l8mYbSNr7FfHPX5XU8etcJr3h9rmXxZqI06WW/jihfTp RGxZZEiBzF/tbhgleTjBrX8P6dZ2Hi/xCzaV5V5c3fnw3QsyFeEwwhgJQu3/AFgclc5zk470Aa+o +I9L0u8W0uJpWuSnmGG3t5J3VOm5hGrFRweTgcGrNpqtjfztBaziWRYIrggKceXJu2NnGDnY35fS udjnk8PeK9buLywvprfUnhmguLS1efG2JUMbBASuCpYEjHz9etZmq6dbza9rN/JoUxutQ0WMWkv2 EyOkoScOpdQQj7WjXkjPABOKAO1uNShttTsrB1kMt2JDGQBtGwAnPPvVyuO0/Q003UPC/wBk08wo lvKbl1iwd5iQZkOPvHGMnk4rsaACobv/AI85/wDrm38qlJCjJIHOOar3LBrWblc+VJ0cnpx0/n6d KAPln4x/8jyP+vSP+bV5/XoHxj/5Hkf9ekf82rz+gAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAr6f+FriL4WeGpGzhZbljj2nNfMFXYtZ1SCCOCHUryOGMEJGk7B VBJJAAOBySfqTQB9of21bf3JfyH+NH9tW39yX8h/jXxl/b2sf9Ba+/8AAh/8aP7e1j/oLX3/AIEP /jQB9m/21bf3JfyH+NH9tW39yX8h/jXxl/b2sf8AQWvv/Ah/8aP7e1j/AKC19/4EP/jQB9m/21bf 3JfyH+NH9tW39yX8h/jXxl/b2sf9Ba+/8CH/AMaP7e1j/oLX3/gQ/wDjQB9m/wBtW39yX8h/jR/b Vt/cl/If418Zf29rH/QWvv8AwIf/ABo/t7WP+gtff+BD/wCNAH2b/bVt/cl/If40f21bf3JfyH+N fGX9vax/0Fr7/wACH/xo/t7WP+gtff8AgQ/+NAH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/wBB a+/8CH/xo/t7WP8AoLX3/gQ/+NAH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/0Fr7/wIf8Axo/t 7WP+gtff+BD/AONAH2b/AG1bf3JfyH+NH9tW39yX8h/jXxl/b2sf9Ba+/wDAh/8AGj+3tY/6C19/ 4EP/AI0AfZv9tW39yX8h/jR/bVt/cl/If418Zf29rH/QWvv/AAIf/Gj+3tY/6C19/wCBD/40AfZv 9tW39yX8h/jR/bVt/cl/If418Zf29rH/AEFr7/wIf/Gj+3tY/wCgtff+BD/40AfZv9tW39yX8h/j R/bVt/cl/If418Zf29rH/QWvv/Ah/wDGj+3tY/6C19/4EP8A40AfZv8AbVt/cl/If40f21bf3Jfy H+NfGX9vax/0Fr7/AMCH/wAaP7e1j/oLX3/gQ/8AjQB9m/21bf3JfyH+NH9tW39yX8h/jXxl/b2s f9Ba+/8AAh/8aP7e1j/oLX3/AIEP/jQB9m/21bf3JfyH+NH9tW39yX8h/jXxl/b2sf8AQWvv/Ah/ 8aP7e1j/AKC19/4EP/jQB9m/21bf3JfyH+NH9tW39yX8h/jXxl/b2sf9Ba+/8CH/AMaP7e1j/oLX 3/gQ/wDjQB9m/wBtW39yX8h/jR/bVt/cl/If418Zf29rH/QWvv8AwIf/ABo/t7WP+gtff+BD/wCN AH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/0Fr7/wACH/xo/t7WP+gtff8AgQ/+NAH2b/bVt/cl /If40f21bf3JfyH+NfGX9vax/wBBa+/8CH/xo/t7WP8AoLX3/gQ/+NAH2b/bVt/cl/If40f21bf3 JfyH+NfGX9vax/0Fr7/wIf8Axo/t7WP+gtff+BD/AONAH2b/AG1bf3JfyH+NH9tW39yX8h/jXxl/ b2sf9Ba+/wDAh/8AGj+3tY/6C19/4EP/AI0AfZv9tW39yX8h/jR/bVt/cl/If418Zf29rH/QWvv/ AAIf/Gj+3tY/6C19/wCBD/40AfZv9tW39yX8h/jR/bVt/cl/If418Zf29rH/AEFr7/wIf/Gj+3tY /wCgtff+BD/40AfZv9tW39yX8h/jR/bVt/cl/If418Zf29rH/QWvv/Ah/wDGj+3tY/6C19/4EP8A 40AfZv8AbVt/cl/If40f21bf3JfyH+NfGX9vax/0Fr7/AMCH/wAaP7e1j/oLX3/gQ/8AjQB9m/21 bf3JfyH+NH9tW39yX8h/jXxl/b2sf9Ba+/8AAh/8aP7e1j/oLX3/AIEP/jQB9m/21bf3JfyH+NH9 tW39yX8h/jXxl/b2sf8AQWvv/Ah/8aP7e1j/AKC19/4EP/jQB9m/21bf3JfyH+NH9tW39yX8h/jX xl/b2sf9Ba+/8CH/AMaP7e1j/oLX3/gQ/wDjQB9m/wBtW39yX8h/jR/bVt/cl/If418Zf29rH/QW vv8AwIf/ABo/t7WP+gtff+BD/wCNAH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/0Fr7/wACH/xo /t7WP+gtff8AgQ/+NAH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/wBBa+/8CH/xo/t7WP8AoLX3 /gQ/+NAH2b/bVt/cl/If40f21bf3JfyH+NfGX9vax/0Fb7/wIf8Axpf7d1f/AKCt9/4Ev/jQB9mf 21bf3JfyH+NH9tW39yX8h/jXxn/busf9BW+/8CX/AMaP7d1f/oK33/gQ/wDjQB9mf21bf3JfyH+N H9tW39yX8h/jXxp/bur/APQVvv8AwJf/ABo/t3V/+grff+BL/wCNAH2X/bVt/cl/If40f21bf3Jf yH+NfGf9u6x/0Fb7/wACH/xo/t3WMf8AIVvv/Al/8aAPsz+2rb+5L+Q/xo/tq2/uS/kP8a+M/wC3 dX/6Ct9/4Ev/AI0f27rH/QVvv/Ah/wDGgD7M/tq2/uS/kP8AGj+2rb+5L+Q/xr4z/t3V/wDoK33/ AIEv/jR/b2sf9BW+/wDAl/8AGgD7M/tq2/uS/kP8aP7atv7kv5D/ABr4y/t7WP8AoK33/gQ/+NH9 vax/0Fr7/wACH/xoA+zf7atv7kv5D/Gj+2rb+5L+Q/xr4y/t7WP+gtff+BD/AONH9vax/wBBa+/8 CH/xoA+zf7atv7kv5D/Gj+2rb+5L+Q/xr4y/t7WP+gtff+BD/wCNH9vax/0Fr7/wIf8AxoA+zf7a tv7kv5D/ABo/tq2/uS/kP8a+Mv7e1j/oLX3/AIEP/jR/b2sf9Ba+/wDAh/8AGgD7N/tq2/uS/kP8 aP7atv7kv5D/ABr4y/t7WP8AoLX3/gQ/+NH9vax/0Fr7/wACH/xoA+zf7atv7kv5D/Gj+2rb+5L+ Q/xr4y/t7WP+gtff+BD/AONH9vax/wBBa+/8CH/xoA+zf7atv7kv5D/Gj+2rb+5L+Q/xr4y/t7WP +gtff+BD/wCNH9vax/0Fr7/wIf8AxoA+zf7atv7kv5D/ABo/tq2/uS/kP8a+Mv7e1j/oLX3/AIEP /jR/b2sf9Ba+/wDAh/8AGgD7N/tq2/uS/kP8aP7atv7kv5D/ABr4y/t7WP8AoLX3/gQ/+NH9vax/ 0Fr7/wACH/xoA+zf7atv7kv5D/Gj+2rb+5L+Q/xr4y/t7WP+gtff+BD/AONH9vax/wBBa+/8CH/x oA+zf7atv7kv5D/Gj+2rb+5L+Q/xr4y/t7WP+gtff+BD/wCNH9vax/0Fr7/wIf8AxoA+tpdP8MTy tLJo0Rdzlj5SjJ/Okg0/w3bXCTQ6dIrI25V3HYD67N23P4V8lf29rH/QWvv/AAIf/Gj+3tY/6C19 /wCBD/40T/eW59bdyPZw7I+y5NVspV2yQO4BzhkB5/OsS/0fwzqd01ze2FzPM38T3EhwM5wBv4HJ 4HAr5P8A7e1j/oLX3/gQ/wDjR/b2sf8AQWvv/Ah/8auFSdN3g2vQc4RmrSVz7Ftb3T7OzFrDDP5I yMSNvJz1yWYk9e9UvsfhwSeYNKVXzuBVAMH2weK+R/7e1j/oLX3/AIEP/jR/b2sf9Ba+/wDAh/8A GobvqykraI+zE1ezjQJHDIijoFUAD9ayZLHw3LdSXMul+ZNIxdmcZ5JycZbjkk8dya+Sf7e1j/oL X3/gQ/8AjR/b2sf9Ba+/8CH/AMaqM5R+F2JlGMt0fZUOqWNvGI4YHRB2VQP61W1CTRtVWNb+wFwI ySnmRqSueuOfp+VfH39vax/0Fr7/AMCH/wAaP7e1j/oLX3/gQ/8AjSTad0NpNWZ9Z/2V4V/6AkX/ AH7H+NXtPl0jSkdLCyNujnLLGoAJ9etfH39vax/0Fr7/AMCH/wAaP7e1j/oLX3/gQ/8AjVOpOSs2 JQitUj66ntvD1zO882lq0jnczbAMn161NYto2myNJZ2JgZhhiigZH518f/29rH/QWvv/AAIf/Gj+ 3tY/6C19/wCBD/41BR9e3aaDfXBuLrTRLMwALlBk49eeahWy8NowZdKCsDkELgg/nXyR/b2sf9Ba +/8AAh/8aP7e1j/oLX3/AIEP/jQB9kXWoafe2z211bNNBIMPHIisrfUE1lRaV4VhlWWLRIUkU5Vl iAIP518mf29rH/QWvv8AwIf/ABo/t7WP+gtff+BD/wCNUpSSsmKyPrXT7Dw9pesT6raWd0l5P5u9 mnkdR5jh32ozlVywBOAOlWL1dC1KYTXmmLNKBgO8ak/nmvkL+3tY/wCgtff+BD/40f29rH/QWvv/ AAIf/Gpi+X4dA5Va1j6+00aLpLSNY2ckTOAGOSxwOgGWOB7Din38mjaoqLfWAuAn3fMjU7fpzXx9 /b2sf9Ba+/8AAh/8aP7e1j/oLX3/AIEP/jRBcnwaeguWNrW0PrP+yvCv/QFi/wC/Y/xrVttQ0+zg WC2t3jiXoqqMD9a+N/7e1j/oLX3/AIEP/jR/b2sf9Ba+/wDAh/8AGqlOUvidwUIx2R9m/wBtW39y X8h/jWbqEWi6pdJPe293KVCjy/PdYm2ncN0YcI2Cf4ga+RP7e1j/AKC19/4EP/jR/b2sf9Ba+/8A Ah/8ako+zf7atv7kv5D/ABo/tq2/uS/kP8a+Mv7e1j/oLX3/AIEP/jR/b2sf9Ba+/wDAh/8AGgD7 N/tq2/uS/kP8aP7atv7kv5D/ABr4y/t7WP8AoLX3/gQ/+NH9vax/0Fr7/wACH/xoA+zf7atv7kv5 D/Gj+2rb+5L+Q/xr4y/t7WP+gtff+BD/AONH9vax/wBBa+/8CH/xoA+zf7Zt85xOOnQL/nmo5tWg kgkjHn5ZGUZAxz0/Kvjb+3tY/wCgtff+BD/40f29rH/QWvv/AAIf/GgDsPjH/wAjyP8Ar0j/AJtX n9TXN3c3kgkuriWdwNoaVyxA9Mn61DQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFLSUtABS0lFMQZpaSlzQAlFFFABRRRQAUlLSUhhRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAtFF FMQUUdqOtABRSUuaACikopDFpKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigApaSigBaSiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooA/9k= --000000000000a71a3505e25a007c-- From nobody Sun Jun 26 15:41:39 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E05388A787F; Sun, 26 Jun 2022 15:44:29 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWFXY60l5z3jPq; Sun, 26 Jun 2022 15:44:29 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656258269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pT2dDbAQ+nf6xcZNZDmS4njjdP61ack9X7lNp5JbgLU=; b=kI2bU/P540Qa+2zftjlpChWM6uRyjWZY6OJy/HD3InhaOhG23aQz4GUbM51f6D3scnwkEr KpdvX1+E4UebdEmW8uDC05cWwp4Qcy1dmazXTZBIjsnUoFbMJJS7Mx0jmIOXXN2m+2sptH 75TkfH0J/x7ZU2nEWyU8xPkK3x4fAl7BIhDF4qQ68bspqnvti7dx4zPzu8/wj1kIugo9vN MCIBFBdFhFBajr2q5+t0HliSzrUOJQtnh+si7phR6BwCZ8HGC0hkVhLufpQd8QQOolFjZE 1+Z4+/ZIXXMA1cctVMNXnFvKTUYLAtyFbe2IcqYgcKSSJamVehCHAPm0l5TTPQ== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 49B966743; Sun, 26 Jun 2022 15:44:29 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <79b18529-2810-0ed8-e44f-563af8d23d14@freebsd.org> Date: Sun, 26 Jun 2022 16:41:39 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-GB To: Mario Marietto , hackers@freebsd.org References: Cc: =?UTF-8?Q?Corvin_K=c3=b6hne?= , FreeBSD virtualization From: Graham Perrin Subject: UdpDataProtocol.cpp (was: how to run bhyve and virtualbox at the same time) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656258269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pT2dDbAQ+nf6xcZNZDmS4njjdP61ack9X7lNp5JbgLU=; b=C7WS08ojcvNi8sSUDJrgqxiEavuMi8WG2QoQZj6WJtsbIJZJULxbHK214Qz+NwOLrtq2lh gNCPThrm+jk6ioEglKAIT+1F/9QAwIRGHMn4NZ7wFnMTncsOcsT+nZUP1yTJMdmaWkUBko q/xRSk1arHWte7wriIVt+WQo5tkWrMPAotKGmPUl6vWyfy0/V8IStJljLcTk27v8Vcdi43 jg3sYCE+1D8um7pvJrWbYFEXicYSAeAFwOBSKl6h04fzAA7FG0qGLp+8rqh8oXjd5Vx9zo galzqcmv1M2R0ibCQGryoCInqg4QZzr/5NoLlLBIgzB6ZzEQOVD83V0VlzKW5w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656258269; a=rsa-sha256; cv=none; b=XQ2KPqvdw+pOXmjkEpRpdOVhYlVo03hVQFEXH8/Hj7ssYoFNGj5Y+4zJOX2xNIHpcy2V/y YnfaHGIiPMlxJs1bjiu+Wkc5WgbtHqP9vERqzVvFY1edrWKje6xBgQkSjM9MLXxhJ5TLxe rjYm5CFpTFmH9OIFjX80SRVoXHGCBAF3mJu1b1UG+JinRYFAPy5gQEnaiofl0+/MwMafIE pOfwUSmTctnfBOCWGyASL3eDU/9PXIhhVeitEUKHQq9hcGghRF/HZ9ZkRf2x+uUxqTNnVb ZBQ4iuVg+ypCfXHJWSew/4nwT9af+ia9xXcPoXqT0/wSD6XVGtf8KjUAr10tDw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 26/06/2022 14:43, Mario Marietto wrote: > … I don't have any *UdpDataProtocol.cpp file *on my*FreeBSD > 13.1-RELEASE *system. … Hi UdpDataProtocol.cpp is: * present in source code for jacktrip * not present (not expected) in src for FreeBSD * not provided by any port. % pkg provides UdpDataProtocol.cpp % locate UdpDataProtocol.cpp % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #13 main-n256147-1c665e95d44-dirty: Wed Jun 15 07:49:44 BST 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC -NODEBUG amd64 1400061 1400061 % From nobody Sun Jun 26 16:32:25 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A15AA8679BF; Sun, 26 Jun 2022 16:33:03 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWGcZ1zsTz3pc3; Sun, 26 Jun 2022 16:33:02 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id v38so2210949ybi.3; Sun, 26 Jun 2022 09:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MtnMCq5Lh/EfOeERczO0g13F6Zlngi1+TmwO84o6Id8=; b=WIwBZINCqnzlrxWsC6znE5kCucCYj92ih7QwB/b+QTgejUviJc3iSu5u4YXwD+pTJs YuDCT0yX2dVg194AxIkGexSscieZ7kCGJq0qqr3yzFI3qYXH/LJG9gMNq9xWKbtxQJ0R AjR2uvoGoqVMvtPMkisPt/w3jb6J9w4opocRIEmPtwRO9OZIDHVSpqU8I5Nz3oXnYtsk wJp8FuEo6JsYe9gur2+t9P40jPTD7RlBTWxfyDfZYEW2uOW+u8Lv3D5QSn5oaVnmx2U6 59eo2swHmmpd9Ck3l3DeWMwwEhHEjdT66QjItJuqi6Bs0Wyc7J5/gIvW8jMe5GT0I+ip VlOA== 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=MtnMCq5Lh/EfOeERczO0g13F6Zlngi1+TmwO84o6Id8=; b=EDp6T+Oujr6Ouuwji0WUHXZsbVByiI9TJ6wswAobqhHtQaP6jWKnt1qBTIonm9P0kz y8UUOObAOuhqRNGvbYs0NQfYsBh3zgX+Vv+qP/fdvexCCAhaMIDqWoidNi2ern8jtHqR xDaFRykzQVIDi9fhv+zXkV06GaLRDBnrD57a1CH/A00N5g3AHa9jaYEsz13Fc5K44yIi 6N3WD9UZnv3bfGafCAgsZT+mvU3SMIgeLDI03HOEu+xBgUQYWRRH+e029zp5Mx+j9rp9 e+3g/lRdtZh5pY89JxICv6fQovlCrYWqfV54SwT4PRD573QaG6Q8zBe/R3G/PY5OfCS1 Y95g== X-Gm-Message-State: AJIora9P1h/cVMtPKtG6bRdoOTH1eERgIY5vaZS/Zpqw+sUqMPBS2IhN w3W+IDZTX4dLHaZ6VYr8Bj+JyO4TvwyETbgNyXi41dRT9Wk= X-Google-Smtp-Source: AGRyM1tcoo0FTRCo4/HUT4R9XC/ruaksu47lTyaWu/t2tfKSyYUY/LoiHkVw85gHBKlDbGq0kcR++FQZpjE/CzcpoaU= X-Received: by 2002:a25:d916:0:b0:66c:8096:1f12 with SMTP id q22-20020a25d916000000b0066c80961f12mr9661160ybg.392.1656261181575; Sun, 26 Jun 2022 09:33:01 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <79b18529-2810-0ed8-e44f-563af8d23d14@freebsd.org> In-Reply-To: <79b18529-2810-0ed8-e44f-563af8d23d14@freebsd.org> From: Mario Marietto Date: Sun, 26 Jun 2022 18:32:25 +0200 Message-ID: Subject: Re: UdpDataProtocol.cpp (was: how to run bhyve and virtualbox at the same time) To: Graham Perrin Cc: hackers@freebsd.org, =?UTF-8?Q?Corvin_K=C3=B6hne?= , FreeBSD virtualization Content-Type: multipart/alternative; boundary="00000000000062188505e25c5b7a" X-Rspamd-Queue-Id: 4LWGcZ1zsTz3pc3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=WIwBZINC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-3.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from]; NEURAL_HAM_SHORT(-0.72)[-0.716]; MLMMJ_DEST(0.00)[hackers,freebsd-virtualization]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000062188505e25c5b7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ok,but what should I do with that file ? How can I use it ? I've explained what I want to do,but I didn't understand how the UdpDataProtocol.cpp file can help me and if there is some method to run bhyve and virtualbox at the same time. Il giorno dom 26 giu 2022 alle ore 17:44 Graham Perrin < grahamperrin@freebsd.org> ha scritto: > On 26/06/2022 14:43, Mario Marietto wrote: > > > =E2=80=A6 I don't have any *UdpDataProtocol.cpp file *on my*FreeBSD > > 13.1-RELEASE *system. =E2=80=A6 > > Hi > > UdpDataProtocol.cpp is: > > * present in source code for jacktrip > * not present (not expected) in src for FreeBSD > * not provided by any port. > > % pkg provides UdpDataProtocol.cpp > % locate UdpDataProtocol.cpp > % uname -aKU > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #13 > main-n256147-1c665e95d44-dirty: Wed Jun 15 07:49:44 BST 2022 > root@mowa219-gjp4-8570p-freebsd > :/usr/obj/usr/src/amd64.amd64/sys/GENERIC > -NODEBUG amd64 1400061 1400061 > % > > --=20 Mario. --00000000000062188505e25c5b7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ok,but what should I do with that file ? How can I use it = ? I've explained what I want to do,but I didn't understand how the = UdpDataProtocol.cpp file can help me and if there is some method to run bhy= ve and virtualbox at the same time.

Il giorno dom 26 giu 2022 alle ore 1= 7:44 Graham Perrin <grahampe= rrin@freebsd.org> ha scritto:
On 26/06/2022 14:43, Mario Marietto wrote:

> =E2=80=A6 I don't have any *UdpDataProtocol.cpp file *on my*FreeBS= D
> 13.1-RELEASE *system. =E2=80=A6

Hi

UdpDataProtocol.cpp is:

* present in source code for jacktrip
* not present (not expected) in src for FreeBSD
* not provided by any port.

% pkg provides UdpDataProtocol.cpp
% locate UdpDataProtocol.cpp
% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #13 main-n256147-1c665e95d44-dirty: Wed Jun 15 07:49:44 BST 2022
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/= src/amd64.amd64/sys/GENERIC
-NODEBUG amd64 1400061 1400061
%



--
Mario.
--00000000000062188505e25c5b7a-- From nobody Sun Jun 26 18:47:11 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1FDEA87E472; Sun, 26 Jun 2022 18:47:49 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWKc40dflz4dBV; Sun, 26 Jun 2022 18:47:48 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yb1-xb2c.google.com with SMTP id x184so10513732ybg.12; Sun, 26 Jun 2022 11:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WWtM9zg4nT+AqgGIMfEzk5ITnTC+R1QclSAPU8NkPr8=; b=dfPPo/XspgkfHDkE09dlUqzsZC8DbXkS1zhdQmwfnuNyBwJD3lkzQZpFgq1Q/Xop5q XYfmtIw4M5jat4RfcyseRNX9DVDSDdlmYi0+k3GSb9nxuDjLRQ889mUnJ0offUqFh0b9 fVHvDhbeBH80axUZb43vTR3geS7KS3TcCcalgrcdH0NIW2G9yuB9/AcEdZaeELvNqAwi 66LyytXtAsOS1Qzj1H1yyPLVj1tlChLCd7+CVQHRUCWczZiz3NV4ZFpOgS0C6Q/eXPxT 9v2K0zRct526VFMVb3so6+RMF6Tapvh8ppGnd3On0iEbXhePXvgKqGrtgLL3n6pOA2kE jYbw== 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=WWtM9zg4nT+AqgGIMfEzk5ITnTC+R1QclSAPU8NkPr8=; b=jfz8Rc0/GH4wO2Uet/Sb11K1FGIWx99fB9kyWUNMRxJ0hIbbW1B/0izOdPZQfhOMEI cmb542KFcEXVgk83gSD/zj+/BgV0lMnqFeL46/OB/HFgs5dwDAp3cLSlud5AWgnAhQ9j i7tTWC6FL44W3yWCkh/Dj/te6D9W8sb0HwGPU6EcFsTttJkQwkDtiYzj52rnuxZVJSxx 36SxciR2T3KSBR105/ixpfptADInCnA+nrFjYvAShS5nnOBimKFKPlwwz2aV62Avy+gA z2uvsPpLL6SgJ9PViDJSdGsjIKi+frTTT07fPUiLynycvwhIjNDmLYKE0QKgDgpYuK4G W5gA== X-Gm-Message-State: AJIora+EmsZJBbXuFpbuCwrtk1sv2wd8X9kkkP+Nf7XrzixrhJaL8BKL KnzD2UuVN4PyHgoavWosTUPWDuCsKEsjWulaWq0= X-Google-Smtp-Source: AGRyM1sQn+LaIz4NZ9g2RpzDRaPPGNsaJwkJj8h1662/Nqyn9HbGqwcaM1pd97WtH/ba65Y23kRc3Q/8yU+kkw/6bEs= X-Received: by 2002:a25:d916:0:b0:66c:8096:1f12 with SMTP id q22-20020a25d916000000b0066c80961f12mr10164056ybg.392.1656269267488; Sun, 26 Jun 2022 11:47:47 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Sun, 26 Jun 2022 20:47:11 +0200 Message-ID: Subject: Re: how to run bhyve and virtualbox at the same time To: Dustin Marquess Cc: =?UTF-8?Q?Corvin_K=C3=B6hne?= , FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000057551505e25e3deb" X-Rspamd-Queue-Id: 4LWKc40dflz4dBV X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="dfPPo/Xs"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::b2c as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-3.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.882]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2c:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000057551505e25e3deb Content-Type: text/plain; charset="UTF-8" Sure,I knew about CIFS and NFS,but I didn't think about a 9P client. Anyway,who told you that I'm looking for the easiest route ? Sometimes I like to explore more exotic methods to try to accomplish a task,especially when I see that there would be some useful functions but that have not been explored,like an ingenious method to run virtualbox and bhyve at the same time,that could be useful. Il giorno dom 26 giu 2022 alle ore 20:29 Dustin Marquess < dmarquess@gmail.com> ha scritto: > On Sun, Jun 26, 2022 at 8:45 AM Mario Marietto > wrote: > >> If that can't be done,I'm forced to install the USB-IP server on FreeBSD >> itself and the client on MacOS,but this makes the task more complicated to >> accomplish. Even though there is no known USB over IP tool which can run >> natively on FreeBSD. For example I tried this one : >> > > macOS supports CIFS (SMB) and NFS mounts natively, so that would probably > be the easiest. There's also a 9P client for macOS ( > https://github.com/benavento/mac9p ) and a 9P server for *IX ( > https://github.com/chaos/diod ) that you can use, instead of dealing with > USB-over-IP. > > -Dustin > -- Mario. --00000000000057551505e25e3deb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure,I knew about CIFS and NFS,but I didn't think abou= t a 9P client. Anyway,who told you that I'm looking for the easiest rou= te ? Sometimes I like to explore more exotic methods to try to accomplish a= task,especially when I see that there would be some usef= ul functions but that have not been explored,like an ingenious method to run virtualbox and bhyve at the same time,that could= be useful.
<= br>
Il gior= no dom 26 giu 2022 alle ore 20:29 Dustin Marquess <dmarquess@gmail.com> ha scritto:=
On Sun, Jun 26, 2022 at 8:45 AM Mario Marietto <marietto2008@gmail.c= om> wrote:
If that can't be don= e,I'm forced to install the USB-IP server on FreeBSD itself and the cli= ent on MacOS,but this makes the task more complicated to accomplish. Even t= hough there is no known USB over IP tool which can run natively on FreeBSD.= For example I tried this one :

macOS supports CIFS (SMB) and NFS mounts natively, so that would probably = be the easiest. There's also a 9P client for macOS (=C2=A0https://github.com/bena= vento/mac9p ) and a 9P server for *IX (=C2=A0https://github.com/chaos/diod ) that = you can use, instead of dealing with USB-over-IP.

= -Dustin


--
Mario.
=
--00000000000057551505e25e3deb-- From nobody Sun Jun 26 19:00:54 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2E204863E1D for ; Sun, 26 Jun 2022 19:01:01 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWKvJ0Mkvz4kZc for ; Sun, 26 Jun 2022 19:00:59 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D17953200124 for ; Sun, 26 Jun 2022 15:00:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 26 Jun 2022 15:00:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1656270057; x=1656356457; bh=L6HdJzg5dN 9bK0lLmBHDI6tspE1ZX9oR0YEoJ9PSjQs=; b=U29HNbNuVrkGR/hH3YbPruIwyO sXj6qGZcZDPOOeUQN7NBYekMhx0z9KE3GmWOBxDFCYA6n30z0lKJqCUYVZ+9ekmd 4Zq/hfkBc7Khj/9C6oPxOdyTjua78SyJJxzKw5yrkZVBp9PJzn5LSCyd3LD8u6jt v1QsadR+V25qyrxY14bwXK/1AoC+3arKl4b9zLKWQ0ZqNEOAR5oU6J28gyFUoVkw z2cTyaymfx455ACSeo3jX4eLo/QoJ82WZKRuZvaBEX+UmrtdYNaCe0t9jEnclAdi gt395nUIqrh+xJy9SXJCkwwIyrMRgLh/uSU1B3LuGfEGJduyWv3wMijFplZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656270057; x=1656356457; bh=L6HdJzg5dN9bK0lLmBHDI6tspE1Z X9oR0YEoJ9PSjQs=; b=xem/swJPisc/iAX7y0j5sz22b2C5C8Tc4eLMcJ8ybgvU bQjdzI1DrThpFIh731VPMoYCnJdcY2N6liEI0x6nCLUiSq9Ai+hvPrVLAbUGeOfz 9iKSKAY6kH+JrPUNyWS+C4rAvqYC1SoteYpcqu8cPpccb/ZZeyySvJetZ2poh7cd CJdBHNEIF1V/EAwCG1DB04cKoIa0OQJ58TbjArhSA/fsuhi93Rdz6CmB+jedZOoY xX6gwjCKCNbLhiJgJJt3wmb75r4n2p9fKcGfXLqXX3891rxVxpDskOpu1lmzJevH ppuO1d40BmHrioJXhva6MKLBFbcsIS7c1aM7FYSZog== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegfedgudefgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvffhufgtgfesthejre dttdefjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecu ggftrfgrthhtvghrnhepkefgtdffgefhheegledvueevkedvkeejteeugfevheeitdfgke fhveelhedvleejnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 26 Jun 2022 15:00:56 -0400 (EDT) Message-ID: <334d80e2-c435-33a7-dea6-8548ef5e15a3@aetern.org> Date: Sun, 26 Jun 2022 22:00:54 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: hackers@freebsd.org From: Yuri Subject: ipmi ipmb support Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LWKvJ0Mkvz4kZc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=U29HNbNu; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="xem/swJP"; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.19 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[aetern.org]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from] X-ThisMailContainsUnwantedMimeParts: N Hi, I have put an initial attempt at implementing the IPMB support in ipmi driver: https://reviews.freebsd.org/D35605 It is pretty naive in that it does NOT wait for SMS_ATTN from BMC, nor does it any checks that data returned by GET_MSG from satellite controller corresponds to SEND_MSG we sent. Good news is that it works flawlessly for me on some system that I have tested, primarily HPE ProLiant DL380 Gen10. If anyone is interested, please review/test/possibly integrate with a TODO for making it more robust. From nobody Sun Jun 26 20:33:40 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 48E6D873BBF; Sun, 26 Jun 2022 20:34:17 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWMyw4NCTz3Fkb; Sun, 26 Jun 2022 20:34:16 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-3176b6ed923so67897657b3.11; Sun, 26 Jun 2022 13:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1MiliiF5LB6IugTrU8Ppmm5G3+YfvvsWVpR5Jyc6OMQ=; b=nEsmmkQnuwfIFhC6TOlWMiQ4b5L5G4sJH0n7DiBokZIyrcdSR20CoX84ppac4kpwzk 6svMNt43v3J3Eaua0HLk+5N/K+ZBXB7DYgMaPe7eVhmpCiJ6O6tiL9VWOhqERBevAWhj PdxJScX9zZqFxC+93ZZbk3f+KR2iONMfb7CXUEZAfNyLhQzHzpCZ+zN2mad/O129kBX4 SIVZDIJdyjHr2fbsiqT+gNB5oTFsRrOYvD1AL+Q6tzM5HUuInhrICrWLXQve+mtORNqO QlCtyNzETKz4Tn5foPDPN2jMIwzoiIeckTE+Myy31ahaR6HTpkU4kYXIkaR61pF90RjA FQBg== 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=1MiliiF5LB6IugTrU8Ppmm5G3+YfvvsWVpR5Jyc6OMQ=; b=3FtlLPQpzd3GJWNl4w2Nmk0jcCBubgNgQMNenw2KVoxx/3i4Ljm1popkOCl+LCeDdR Lx6rUh2/FWmojqYj6n7ji/OeOX2OBOBgJMlLXb8dBRprSLpgKRgHtuXjh8SUOZJsl++P VsI2vkOHlyeSfkzWuN0FD3eB3pKM5FxhNJY+5FSMqNTFJrRuzmbu6x6H/zax6gEjtyJD Vuj+tA8YUXqCHMzcKlv2PE71PmsbwUZMMffUKJ7BWmUBSJ5gACUb6557ZQ/IeKajkbMQ 7SlizNGWy73J9y9pwotBvoBpCQFm3Qp59KjsmuQATyPwpqlAztveKfomd5B/5xGZ4BRT Jx0g== X-Gm-Message-State: AJIora8tYxkdLmy16dT4rxq9BwGJs28edruL5QSZZNIzytY9m0DVHK2G 4dI8q+9DCs95EQC6+QCcbE+LZRfYNRsF3iEIw00= X-Google-Smtp-Source: AGRyM1ujysojotVCW4Bmed0jj0J/tJTb4xuxM5WhyYg3WTwrfXWBUgkNMRV9kHW30UVu7fg9R/3IdkNfI+SbQayWR4o= X-Received: by 2002:a0d:dd41:0:b0:318:3ac4:9b98 with SMTP id g62-20020a0ddd41000000b003183ac49b98mr11007362ywe.519.1656275655973; Sun, 26 Jun 2022 13:34:15 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Mario Marietto Date: Sun, 26 Jun 2022 22:33:40 +0200 Message-ID: Subject: Re: how to run bhyve and virtualbox at the same time To: Dustin Marquess Cc: =?UTF-8?Q?Corvin_K=C3=B6hne?= , FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001fe0e205e25fba84" X-Rspamd-Queue-Id: 4LWMyw4NCTz3Fkb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=nEsmmkQn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::1129 as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-3.56 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.892]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1129:from]; NEURAL_HAM_SHORT(-0.67)[-0.669]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000001fe0e205e25fba84 Content-Type: text/plain; charset="UTF-8" As far as I can see,bhyve can't run at the same time with virtualbox. So,let's change perspective. What about changing the bhyve source code so that macOS can be virtualized directly in bhyve ? Below you can see what are the parameters needed to boot and run MacOS Monterey with virtualbox : I already know that bhyve does not support them,but how much work is needed to give to bhyve the ability to accept them ? Most of them are EFI related,so I presume that the file uefi-firmware/BHYVE_BHF_CODE.fd should be patched heavily ? What else ? Il giorno dom 26 giu 2022 alle ore 20:47 Mario Marietto < marietto2008@gmail.com> ha scritto: > Sure,I knew about CIFS and NFS,but I didn't think about a 9P client. > Anyway,who told you that I'm looking for the easiest route ? Sometimes I > like to explore more exotic methods to try to accomplish a task,especially > when I see that there would be some useful functions but that have not been > explored,like an ingenious method to run virtualbox and bhyve at the same > time,that could be useful. > > Il giorno dom 26 giu 2022 alle ore 20:29 Dustin Marquess < > dmarquess@gmail.com> ha scritto: > >> On Sun, Jun 26, 2022 at 8:45 AM Mario Marietto >> wrote: >> >>> If that can't be done,I'm forced to install the USB-IP server on FreeBSD >>> itself and the client on MacOS,but this makes the task more complicated to >>> accomplish. Even though there is no known USB over IP tool which can run >>> natively on FreeBSD. For example I tried this one : >>> >> >> macOS supports CIFS (SMB) and NFS mounts natively, so that would probably >> be the easiest. There's also a 9P client for macOS ( >> https://github.com/benavento/mac9p ) and a 9P server for *IX ( >> https://github.com/chaos/diod ) that you can use, instead of dealing >> with USB-over-IP. >> >> -Dustin >> > > > -- > Mario. > -- Mario. --0000000000001fe0e205e25fba84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as I can see,bhyve can't run at the same t= ime with virtualbox. So,let's change perspective. What about changing t= he bhyve source code so that macOS can be virtualized directly in bhyve ?

Below you can see what are the parameters neede= d to boot and run MacOS Monterey with virtualbox :

=
=C2=A0 =C2=A0 <ExtraData>
=C2=A0 =C2=A0 =C2=A0 <ExtraDat= aItem name=3D"VBoxInternal/Devices/efi/0/Config/DmiBoardProduct" = value=3D"Mac-551B86E5744E2388"/>
=C2=A0 =C2=A0 =C2=A0 <E= xtraDataItem name=3D"VBoxInternal/Devices/efi/0/Config/DmiSystemProduc= t" value=3D"MacBookPro15,1"/>
=C2=A0 =C2=A0 =C2=A0 <= ;ExtraDataItem name=3D"VBoxInternal/Devices/efi/0/Config/DmiSystemVers= ion" value=3D"1.0"/>
=C2=A0 =C2=A0 =C2=A0 <ExtraDat= aItem name=3D"VBoxInternal/Devices/smc/0/Config/DeviceKey" value= =3D"ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc&q= uot;/>
=C2=A0 =C2=A0 =C2=A0 <ExtraDataItem name=3D"VBoxIntern= al/Devices/smc/0/Config/GetKeyFromRealSMC" value=3D"1"/><= br>=C2=A0 =C2=A0 =C2=A0 <ExtraDataItem name=3D"VBoxInternal/TM/TSCM= ode" value=3D"RealTSCOffset"/>
=C2=A0 =C2=A0 =C2=A0 &l= t;ExtraDataItem name=3D"VBoxInternal2/EfiGraphicsResolution" valu= e=3D"1500x900"/>
=C2=A0 =C2=A0 </ExtraData>

I already know that bhyve does not support them,but ho= w much work is needed to give to bhyve the ability to accept them ? Most of= them are EFI related,so I presume that the file uefi-firmware/BHYVE_BHF_CODE.fd should be patched heavily ? What else ?=

Il giorno dom 26 giu 2022 alle ore 20:47 Mario Mar= ietto <marietto2008@gmail.com<= /a>> ha scritto:
Sure,I knew about CIFS and NFS,but I didn't think = about a 9P client. Anyway,who told you that I'm looking for the easiest= route ? Sometimes I like to explore more exotic methods to try to accompli= sh a task,especially when I see that there would be some = useful functions but that have not been explored,like an ingenious method to run virtualbox and bhyve at the same time,that c= ould be useful.
Il = giorno dom 26 giu 2022 alle ore 20:29 Dustin Marquess <dmarquess@gmail.com> ha scri= tto:
On Sun, Jun 26, 2022 at 8:45 AM Mario Marietto <<= a href=3D"mailto:marietto2008@gmail.com" target=3D"_blank">marietto2008@gma= il.com> wrote:
If that can't be= done,I'm forced to install the USB-IP server on FreeBSD itself and the= client on MacOS,but this makes the task more complicated to accomplish. Ev= en though there is no known USB over IP tool which can run natively on Free= BSD. For example I tried this one :

=
macOS supports CIFS (SMB) and NFS mounts natively, so that would proba= bly be the easiest. There's also a 9P client for macOS (=C2=A0https://github.co= m/benavento/mac9p ) and a 9P server for *IX (=C2=A0https://github.com/chaos/diod )= that you can use, instead of dealing with USB-over-IP.

-Dustin


--
Mario.
=


--
Mario.
--0000000000001fe0e205e25fba84-- From nobody Sun Jun 26 23:46:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4272586E40E for ; Sun, 26 Jun 2022 23:47:13 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWSFW56Klz4YyJ for ; Sun, 26 Jun 2022 23:47:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id 5393B2110A8 for ; Sun, 26 Jun 2022 19:46:41 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (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 denninger.net (Postfix) with ESMTPSA id D896F3EDE1E for ; Sun, 26 Jun 2022 19:46:40 -0400 (EDT) Message-ID: <7c96bf50-42d1-b799-ec8d-146e26f1f014@denninger.net> Date: Sun, 26 Jun 2022 19:46:40 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 From: Karl Denninger Subject: Programing question regarding FCGI apps (in "C") To: freebsd-hackers@freebsd.org Content-Language: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080304010900090100080303" X-Rspamd-Queue-Id: 4LWSFW56Klz4YyJ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.90 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[97.81.26.48:received] X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms080304010900090100080303 Content-Type: multipart/alternative; boundary="------------w9EMxmDxfOVQz0PHHO0peT0M" --------------w9EMxmDxfOVQz0PHHO0peT0M Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I have an application that has been a "traditional" CGI app for a long time and am converting it to use the fcgi-dev "wrapper" under Apache along with writing a little program that manages the daemons (so if something goes wrong they get restarted with logging to the admin, I can issue a kill to all of them to update the code or a restart request, etc.) What I found is that with that wrapper in use the code runs fine -- but it leaks memory.  It is quite complex and uses the libpq library to talk to Postgres, but I've never seen problems with libpq leaking memory before.  Nonetheless I spent the rather-considerable time to make darn sure via wrapper functions that I wasn't leaking memory through inappropriate use of malloc/realloc/free or unpaired calls to the libpq functions that create allocations, including using wrappers to maintain a list of "active" allocations and outstanding requests, checking for dangling file handles, pollution of sentinel space in malloc'd memory and similar, tossing any discontinuities in the syslog if it finds any.  The code is clean and when it comes back for the next "accept()" there's nothing outstanding. This implies that either libpq has a problem or the fastcgi wrapper library does.  The former I've used a great deal over a long period of time (years) and have never had it cause trouble. The application does some "straight through" stuff out of cron as well and there I can run valgrind against it, which I have and there are no complaints with it unable to find any dangling allocations -- albeit not every function that is used in serving web requests in that library is used in the cron job. That leaves the fastcgi wrapper library.  There is a caution in there about anything that modifies the environment; I removed all the setproctitle() calls which I use to identify status and such, and there are no calls to setenv or putenv anywhere, nor any attempts to write back to any of the environment pointers -- that much I'm quite sure of. Anyone seen anything like this?  For obvious reasons this is not good behavior but tracking it down has proved elusive. Thanks in advance! -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------w9EMxmDxfOVQz0PHHO0peT0M Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I have an application that has been a "traditional" CGI app for a long time and am converting it to use the fcgi-dev "wrapper" under Apache along with writing a little program that manages the daemons (so if something goes wrong they get restarted with logging to the admin, I can issue a kill to all of them to update the code or a restart request, etc.)

What I found is that with that wrapper in use the code runs fine -- but it leaks memory.  It is quite complex and uses the libpq library to talk to Postgres, but I've never seen problems with libpq leaking memory before.  Nonetheless I spent the rather-considerable time to make darn sure via wrapper functions that I wasn't leaking memory through inappropriate use of malloc/realloc/free or unpaired calls to the libpq functions that create allocations, including using wrappers to maintain a list of "active" allocations and outstanding requests, checking for dangling file handles, pollution of sentinel space in malloc'd memory and similar, tossing any discontinuities in the syslog if it finds any.  The code is clean and when it comes back for the next "accept()" there's nothing outstanding.

This implies that either libpq has a problem or the fastcgi wrapper library does.  The former I've used a great deal over a long period of time (years) and have never had it cause trouble.  The application does some "straight through" stuff out of cron as well and there I can run valgrind against it, which I have and there are no complaints with it unable to find any dangling allocations -- albeit not every function that is used in serving web requests in that library is used in the cron job.

That leaves the fastcgi wrapper library.  There is a caution in there about anything that modifies the environment; I removed all the setproctitle() calls which I use to identify status and such, and there are no calls to setenv or putenv anywhere, nor any attempts to write back to any of the environment pointers -- that much I'm quite sure of.

Anyone seen anything like this?  For obvious reasons this is not good behavior but tracking it down has proved elusive.

Thanks in advance!

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------w9EMxmDxfOVQz0PHHO0peT0M-- --------------ms080304010900090100080303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjIwNjI2MjM0NjQx WjBPBgkqhkiG9w0BCQQxQgRAFuFgqIK1gtLij066ErbrSHE7QjHZd/+Q88Q6HSnYp1VtJPNN CWU4kHscUm86BChRq34yz0UiIyYTvVSwMqjeOTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCkb1B7gXo/I4OfXqA/zMmoKIeXmZ94QpP9e7XP4CbrzSJKOsZbqh0hItNEaKoklGU6 119SMPMC+rUc3L5CLGB+Fxkmk6njR7/RTrJGB0txJ8OV08rt4zwStySVHBJeQDklDxAGvBku 2rFaleMSdpfgcZ8flqmL9yJJHIfJLJ8e5nmqFzZJYYOmE1aiOJt0ek6Uzwq0wqnJfCd41Wud vMR1ZyPl83Z/VcHE5lJGCZsrIPgpqgZ3/TQlemP0WaoUHun9UzVrUycY+mSoDUBK3bVJynP2 r85cUeujN5LI/tPS0YEFGYEJ5ihDI9xuOcLsuRRZZQkYRAOObpophNAxu2q5+T7FNMfkfNZC 02wSQMGeU9q33/ErPXW1fZvwadu3FoaRYi18xZ4kK8TUhyOY7+zDZBCyx8dbajIGgljDDgom L/V70a1jAOOUZfM7e3AoTLyDzmFWuPIGGzCW2p1T/3hz4zh8B2AI6JmGA4S7WG8YTH0SFzQF Bwm3WvbaNNRzwWhoLDd5ppgLdZsaUnkd7SasWLLPPCY3TXEdijpNSsZCw28v//xKo8SeRyGw C68LTYGSvym3bjHirgDm/2/fG2TmkK8dcPWF6bN6Rpml22sih7rPF53g1nItWiWieFWR10CZ y68Z0ioxteF2bsTKIZgi3FtltKol8i65ANghZfELmAAAAAAAAA== --------------ms080304010900090100080303-- From nobody Mon Jun 27 14:55:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BF2E3864584 for ; Mon, 27 Jun 2022 14:56:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff::f7]) (using TLSv1.3 with cipher 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 "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWrQ74McCz4S36 for ; Mon, 27 Jun 2022 14:55:59 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 25REtj28092911 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 27 Jun 2022 10:55:52 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: <1c52fa31-b9d6-a78a-74f6-cc2fdc433c45@m5p.com> Date: Mon, 27 Jun 2022 10:55:45 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Missing freebsd-security-notifications? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4LWrQ74McCz4S36 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 2001:470:1f07:15ff::f7 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-2.19 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[m5p.com]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.89)[-0.895]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; TAGGED_FROM(0.00)[freebsd]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N My local daily security check reports: FreeBSD-kernel-12.3_1 is vulnerable: [... 10 different CVEs!] And yet I received nothing on freebsd-security-notifications! Checking the archives of the list appears to show that nothing has been sent since the beginning of the year. Something is wrong with this picture. -- George P.S. Yes, I am updating. From nobody Mon Jun 27 18:51:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C1C8867188; Mon, 27 Jun 2022 18:56:44 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWxlv35B4z3P7t; Mon, 27 Jun 2022 18:56:43 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7C3691EAC5; Mon, 27 Jun 2022 20:51:08 +0200 (CEST) Received: from shipon.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::83]) (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 mail.lysator.liu.se (Postfix) with ESMTPSA id 796171E9E3; Mon, 27 Jun 2022 20:51:08 +0200 (CEST) Date: Mon, 27 Jun 2022 20:51:07 +0200 From: Andreas Kempe To: freebsd-bluetooth@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: blued: bluetooth daemon - looking for testers Message-ID: Reply-To: freebsd-bluetooth@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4LWxlv35B4z3P7t X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=lysator.liu.se; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se X-Spamd-Result: default: False [3.00 / 15.00]; HAS_REPLYTO(0.00)[freebsd-bluetooth@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.99)[0.994]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; MLMMJ_DEST(0.00)[freebsd-bluetooth,freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; REPLYTO_EQ_TO_ADDR(5.00)[]; GREYLIST(0.00)[pass,body] X-ThisMailContainsUnwantedMimeParts: N Hello everyone, After having issues with my bluetooth mouse, I figured out that the problem was a lack of support for secure simple pairing and I reported on this a while back to freebsd-bluetooth and freebsd-hackers. This sent me down the rabbit hole of working on my own bluetooth daemon with the goal of providing a user friendly way of pairing and using bluetooth devices. At long last, I think I have something worth sharing! blued - what is it ================== blued is made up of three parts: a library, a daemon and a command line client. In its current state, it should allow you to pair a bluetooth mouse and, most likely, keyboard, but I have no keyboard to test with. With the current version of blued, bthidd is still needed for the mouse to work and a script is provided to automatically pair a mouse and configure bthidd appropriately. In the future, my aim is to either make blued work with bthidd directly or integrate its code into blued. This for a more seamless experience. If the supplied script works as expected, your mouse will get connected, paired and simply start working. If the mouse is turned off and on again, the daemon should let it reconnect without user intervention. What is needed to use blued v0.1? ================================= First you need to make sure you have working bluetooth drivers loaded, reading the bluetooth chapter of the FreeBSD handbook is recommended for this [0]. To test blued, you will need to compile the release found at the link below [1], and you will also have to patch your FreeBSD kernel with the patches in the kernel_patches directory of the release. The kernel patches are pretty small and you will only need to recompile the hci module. Instruction on how to build blued and apply the patches are provided in the README file. blued has primarily been tested on FreeBSD 12.3, but my patches applied cleanly on 13.1 when I tested. I am not supplying a port at the moment, but "make install" works and will install all needed files. The daemon binary is called blued, while the command line utility is called bluecontrol. Man pages for blued and bluecontrol should also have been installed. An example configuration file for blued is installed in /usr/local/share/examples/blued/blued.conf.example and can be copied to /usr/local/etc/blued.conf which is the default path blued checks for its configuration. blued outputs diagnostic data to syslog and on a default FreeBSD system, it can be found in /var/log/{debug.log,messages}. To start blued in the background after installing it, execute "blued &" as root. blued and bluecontrol both use capsicum and blued can be configured to drop its root privileges. Feedback! ========= I have only tried this software with my own mouse and realise that a sample size of one single bluetooth device is pretty small. I'm expecting issues and am greatly looking forward to feedback from others! In case of trouble, output from /var/log/debug.log and /var/log/messages as well as a traffic dump from "hcidump -x" while trying to pair will help with troubleshooting. If you want to get involved with the code and submit patches, you're welcome to do so and can find the code on Lysator's Git [2]! Thank you for you attention! Cordially, Andreas Kempe [0]: https://docs.freebsd.org/en/books/handbook/advanced-networking/#network-bluetooth [1]: https://git.lysator.liu.se/kempe/blued/-/releases/v0.1 [2]: https://git.lysator.liu.se/kempe/blued From eugen@grosbein.net Mon Jun 27 18:50:25 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E1BA8681E1; Mon, 27 Jun 2022 19:00:08 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWxqq4cQpz3QMH; Mon, 27 Jun 2022 19:00:07 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 25RIoRZW060789 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 18:50:27 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: marietto2008@gmail.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTP id 25RIoPBP008179; Tue, 28 Jun 2022 01:50:26 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: how to run bhyve and virtualbox at the same time To: Mario Marietto , =?UTF-8?Q?Corvin_K=c3=b6hne?= , FreeBSD virtualization , hackers@freebsd.org References: From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <62B9FBF1.6030906@grosbein.net> Date: Tue, 28 Jun 2022 01:50:25 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LWxqq4cQpz3QMH X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [2.56 / 15.00]; ARC_NA(0.00)[]; R_SPF_FAIL(1.00)[-all]; FREEFALL_USER(0.00)[eugen]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; GREYLIST(0.00)[pass,body]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.34)[-0.343]; FORGED_MUA_THUNDERBIRD_MSGID(4.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; FREEMAIL_TO(0.00)[gmail.com,beckhoff.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 26.06.2022 20:43, Mario Marietto wrote: > Hello to everyone. > > Just for educational purposes I've virtualized MacOS Monterey with Virtualbox in FreeBSD : > > Screenshot_2022-06-26_15-32-51.jpg > > Now,the problem is that Virtualbox supports only USB 1.0 speed devices because it does not support the USB 3.0/3.1 plugin/addon and since I use a lot of USB disks and I transfer data between them,I can't have a low level speed like that. So,I've thought of some ideas to overcome the problem. If you need to pass USB disk only (not other kinds of USB devices), then USB pass-through is not only way, there is another one: you can pass block device without performance hit. Optionally, in the /etc/devfs.rules: [localrules=10] add path 'da*' mode 0660 group vboxusers So, any CAM-supported disks including USB-attached is writable by vboxusers group. Then create VMDK link to actual device: $ VBoxManage internalcommands createrawvmdk -filename $HOME/usbdisk.vmdk -rawdisk /dev/da1 Then attach VMDK to the VM as fixed HDD. From nobody Mon Jun 27 19:34:23 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B6DA486D41D for ; Mon, 27 Jun 2022 19:34:36 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWybb34pCz3kh6 for ; Mon, 27 Jun 2022 19:34:35 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-101d2e81bceso14318306fac.0 for ; Mon, 27 Jun 2022 12:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hNeDNdcArc3iy1TLSrezlstlRjTav0sRa+1hpGRqxpU=; b=HV4lJSx1ppJagp4/C5eejXUXVSfZGSOPvgAXObM7nnV1G0NMfjaUZ9X/VDMEqX9SRd 7nRfEBhDdaqfpfiuzITGXzDZ2H3o8efm1kLXBGjedGnQEVybQl+vfinFqNBshuNvK/qj XDEOE4SwRNfapwL0KOnqw84mEG27T+J/9TjbE= 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=hNeDNdcArc3iy1TLSrezlstlRjTav0sRa+1hpGRqxpU=; b=3wFhSApf1gZhoxX8xDtFmZ2ZebUCqjSyXFtLeih6qeKyRktETw4vXaq5U5t3zC9TM6 UVXcCBYx4FV2JfsQ6xfl2/v9LuuqNS3STIyyCGGD1KpIlsoEE1bVYcyXeX10NbobQgJh KVmiuywZubG6t2bB/BkAPvHErykdoQ7qqg5i9yWYOgchQiucB/xoWncKqZdrrHVqdg/d bSabHLquayHPk/UkCA3A35M6c+u24RYJ3d6c+1HpZPLlYhbe6CYKQUjDSgM9begOQsXT M8jRlTGTjUE70aoXFF9moxxA+j/E5UVelrLs/K4pCo4vCUUFozVc6Qb+7j4vnpZChfDz Y2aQ== X-Gm-Message-State: AJIora9hI6LzLEiOft/YoEAZYeNfTOFLJfpqKGgY2pRH+cSjpaPZHniS 3n4xEAgOocMiEZjMTkc1dfYv+xIkSaYYT2Hh4Ld6HZ1OncA= X-Google-Smtp-Source: AGRyM1tZw3Bf2SQldnn2B8Lh7r6XgItYXQBl4laKiVjNK+c+cLq8MNRF4UKeUZ3pDHPiocdIU4mYZzx2KOr0VMEasWI= X-Received: by 2002:a05:6870:430c:b0:101:f886:3760 with SMTP id w12-20020a056870430c00b00101f8863760mr7915196oah.88.1656358474373; Mon, 27 Jun 2022 12:34:34 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <62B9FBF1.6030906@grosbein.net> In-Reply-To: <62B9FBF1.6030906@grosbein.net> From: Mario Lobo Date: Mon, 27 Jun 2022 16:34:23 -0300 Message-ID: Subject: Re: how to run bhyve and virtualbox at the same time To: hackers@freebsd.org Cc: freebsd-virtualization@freebsd.org Content-Type: multipart/alternative; boundary="0000000000007c6ee705e273021d" X-Rspamd-Queue-Id: 4LWybb34pCz3kh6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsd.com.br header.s=capeta header.b=HV4lJSx1; dmarc=none; spf=pass (mx1.freebsd.org: domain of lobo@bsd.com.br designates 2001:4860:4864:20::34 as permitted sender) smtp.mailfrom=lobo@bsd.com.br X-Spamd-Result: default: False [-3.49 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsd.com.br:s=capeta]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[bsd.com.br]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsd.com.br:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::34:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000007c6ee705e273021d Content-Type: text/plain; charset="UTF-8" On Mon, Jun 27, 2022 at 4:00 PM Eugene Grosbein wrote: > On 26.06.2022 20:43, Mario Marietto wrote: > > Hello to everyone. > > > > Just for educational purposes I've virtualized MacOS Monterey with > Virtualbox in FreeBSD : > > > > Screenshot_2022-06-26_15-32-51.jpg > > > > Now,the problem is that Virtualbox supports only USB 1.0 speed devices > because it does not support the USB 3.0/3.1 plugin/addon and since I use a > lot of USB disks and I transfer data between them,I can't have a low level > speed like that. So,I've thought of some ideas to overcome the problem. > > If you need to pass USB disk only (not other kinds of USB devices), then > USB pass-through is not only way, there is another one: > you can pass block device without performance hit. > > Optionally, in the /etc/devfs.rules: > > [localrules=10] > add path 'da*' mode 0660 group vboxusers > > So, any CAM-supported disks including USB-attached is writable by > vboxusers group. > > Then create VMDK link to actual device: > > $ VBoxManage internalcommands createrawvmdk -filename $HOME/usbdisk.vmdk > -rawdisk /dev/da1 > > Then attach VMDK to the VM as fixed HDD. > > > You don't need to go that far. You can share any local mounted disk with the virtualbox SharedFolder option. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] --0000000000007c6ee705e273021d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 27, 2022 at 4:00 PM Eugene Grosbein <eugen@grosbein.net> wrote:
=
On 26.06.2022 20:43, Mari= o Marietto wrote:
> Hello to everyone.
>
> Just for educational purposes I've virtualized MacOS Monterey with= Virtualbox in FreeBSD :
>
> Screenshot_2022-06-26_15-32-51.jpg
>
> Now,the problem is that Virtualbox supports only USB 1.0 speed devices= because it does not support the USB 3.0/3.1 plugin/addon and since I use a= lot of USB disks and I transfer data between them,I can't have a low l= evel speed like that. So,I've thought of some ideas to overcome the pro= blem.

If you need to pass USB disk only (not other kinds of USB devices), then US= B pass-through is not only way, there is another one:
you can pass block device without performance hit.

Optionally, in the /etc/devfs.rules:

[localrules=3D10]
add path 'da*' mode 0660 group vboxusers

So, any CAM-supported disks including USB-attached is writable by vboxusers= group.

Then create VMDK link to actual device:

$ VBoxManage internalcommands createrawvmdk -filename $HOME/usbdisk.vmdk -r= awdisk /dev/da1

Then attach VMDK to the VM as fixed HDD.



You don't need to go that fa= r.

You can share any local mounted disk with the virtualbox Sh= aredFolder option.
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD si= nce version 2.2.8 [not Pro-Audio.... YET!!]
--0000000000007c6ee705e273021d-- From nobody Mon Jun 27 19:41:38 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7F71687126B; Mon, 27 Jun 2022 19:42:15 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWymQ6JFmz3qb1; Mon, 27 Jun 2022 19:42:14 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-31bf3656517so5106137b3.12; Mon, 27 Jun 2022 12:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rcWtOKhY2BmTSIYREf3pE4a2rtbIKS7sa0Yqt/HoA24=; b=AeK8TccTC2WukENewKC68JkPY5r+7CFY3cSQ2PxEp9O8KnJfmRcQJ1P0gb3oDyS0Lv iW6gNkkwPvOgg9JhgrlUVql8Ced5lzPRrbFknmY5foazftCxL2/gFb1Zd7dSwYrZXA2R 8Df4grZze0JwD7+uYHwZStJFEPLo3KpwR18SnH/JJm10XmyuWUwTAurtZ2zJtmdXBqHE VkA6j9uV2ItPPY/2CerPrjv7ZcE+SJPdGzaouhcNIFeFd9XsInLyLPrNOeOVCQJXkQQE YBAOHl2URfY+o/uwcHuboUv48urFpuTA3qx4wPG3gCzu0gaNJXcyHvoA3DjQ2R4Hr57J aCHg== 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=rcWtOKhY2BmTSIYREf3pE4a2rtbIKS7sa0Yqt/HoA24=; b=gqbqI9zv3hMiKDI5SnZNWcYhiBu9ORWFHk9hkHOgkGyGQdl1+phcL8ZK1ZNtKB/Ucs +ETS1qa6tkWEoMhdYSTZjcuaVKIRjWuKmc7XW0rURbK5bB+/Gkezf09JV77eeTQFRWjr +CZQeqCApcG0BxdRWoBcZVw1sw9d2xtnYdikgam++AxnvBP5tfCFZa3ZqZUQAWy3fy3P mQoXQVBgpoQCa+FxhKqSd6GQmwrVf4k3EaWayP31l1fNI7kgMBDa/qdteyiLzwAHDPHC FiVzjdFhGX8GjlTxl4XhRmxeXFsrHA7y/HwTZkMoCP7/qi6VrJ9TgmudlRpHiWmThKVW /JIw== X-Gm-Message-State: AJIora8PxVFGCmT+BeQfxelsEnopIN3aNP83QAVPbsJZPhflX4uE8GKw W4ytlYb4Lx5j44MDXNjpDCSwnMLtJrn+FtoCaVk= X-Google-Smtp-Source: AGRyM1vcj+wHNKZQr/eJ7CfRqCyRTQ6xgnFROYVyT0h3goOwgzTDNHVwwMQwqboQWRiO4ncvX4mxXty3e9APaP7dmns= X-Received: by 2002:a81:1406:0:b0:317:9cca:6fe6 with SMTP id 6-20020a811406000000b003179cca6fe6mr16795551ywu.287.1656358934175; Mon, 27 Jun 2022 12:42:14 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <62B9FBF1.6030906@grosbein.net> In-Reply-To: <62B9FBF1.6030906@grosbein.net> From: Mario Marietto Date: Mon, 27 Jun 2022 21:41:38 +0200 Message-ID: Subject: Re: how to run bhyve and virtualbox at the same time To: Eugene Grosbein Cc: =?UTF-8?Q?Corvin_K=C3=B6hne?= , FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000e4654805e2731d7b" X-Rspamd-Queue-Id: 4LWymQ6JFmz3qb1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AeK8TccT; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) smtp.mailfrom=marietto2008@gmail.com X-Spamd-Result: default: False [-2.08 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_SHORT(0.92)[0.919]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112a:from]; MLMMJ_DEST(0.00)[freebsd-virtualization,hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000e4654805e2731d7b Content-Type: text/plain; charset="UTF-8" I did it already and it works. Fact is that if I use virtualbox I can't use bhyve at the same time. So It's not a good idea to use only virtualbox machines. Il giorno lun 27 giu 2022 alle ore 21:01 Eugene Grosbein ha scritto: > On 26.06.2022 20:43, Mario Marietto wrote: > > Hello to everyone. > > > > Just for educational purposes I've virtualized MacOS Monterey with > Virtualbox in FreeBSD : > > > > Screenshot_2022-06-26_15-32-51.jpg > > > > Now,the problem is that Virtualbox supports only USB 1.0 speed devices > because it does not support the USB 3.0/3.1 plugin/addon and since I use a > lot of USB disks and I transfer data between them,I can't have a low level > speed like that. So,I've thought of some ideas to overcome the problem. > > If you need to pass USB disk only (not other kinds of USB devices), then > USB pass-through is not only way, there is another one: > you can pass block device without performance hit. > > Optionally, in the /etc/devfs.rules: > > [localrules=10] > add path 'da*' mode 0660 group vboxusers > > So, any CAM-supported disks including USB-attached is writable by > vboxusers group. > > Then create VMDK link to actual device: > > $ VBoxManage internalcommands createrawvmdk -filename $HOME/usbdisk.vmdk > -rawdisk /dev/da1 > > Then attach VMDK to the VM as fixed HDD. > > > -- Mario. --000000000000e4654805e2731d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I did it already and it works. Fact is that if I use virtu= albox I can't use bhyve at the same time. So It's not a good idea t= o use only virtualbox machines.

Il giorno lun 27 giu 2022 alle ore 21:01= Eugene Grosbein <eugen@grosbein.n= et> ha scritto:
On 26.06.2022 20:43, Mario Marietto wrote:
> Hello to everyone.
>
> Just for educational purposes I've virtualized MacOS Monterey with= Virtualbox in FreeBSD :
>
> Screenshot_2022-06-26_15-32-51.jpg
>
> Now,the problem is that Virtualbox supports only USB 1.0 speed devices= because it does not support the USB 3.0/3.1 plugin/addon and since I use a= lot of USB disks and I transfer data between them,I can't have a low l= evel speed like that. So,I've thought of some ideas to overcome the pro= blem.

If you need to pass USB disk only (not other kinds of USB devices), then US= B pass-through is not only way, there is another one:
you can pass block device without performance hit.

Optionally, in the /etc/devfs.rules:

[localrules=3D10]
add path 'da*' mode 0660 group vboxusers

So, any CAM-supported disks including USB-attached is writable by vboxusers= group.

Then create VMDK link to actual device:

$ VBoxManage internalcommands createrawvmdk -filename $HOME/usbdisk.vmdk -r= awdisk /dev/da1

Then attach VMDK to the VM as fixed HDD.




--
Mario.
--000000000000e4654805e2731d7b-- From nobody Mon Jun 27 19:52:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E798E873766 for ; Mon, 27 Jun 2022 19:52:14 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from mail.bithabitat.de (mail.bithabitat.de [84.200.61.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWyzx6Qh1z3sHg for ; Mon, 27 Jun 2022 19:52:13 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=erdgeist.org; i=@erdgeist.org; q=dns/txt; s=erdgeist; t=1656359525; h=date : from : to : cc : subject : in-reply-to : message-id : references : mime-version : content-type : from; bh=0mOIBWVWm58TfKEbNMWkhEC/2F8yhAKAZzHDUbLhLjs=; b=gxWhMofQUSMVMsVMCA6q4GUKzLtFDFddhFsAqNH2eWPse3Wg0elYyTZ9JkB09LnTI6pkL 5K9MwitYbOaitr4ZysUAWqfc672ZZJHrdlkOz0LS+6kQcVVl72TrCx07ZbKU/OzmKrIEtE8 IXPce4vUlXnEsclrueyCE/I8cYDAIlvHmQkN1OA3api3xaGvW7JM3ehwNaftmRnccKckPmt AQVq0lQgG5DElOh7rnpVKBrBW47JJ+dQUtkfZp4aN3nsIPzlo6lNXEuIMJKxh25TUr0qohU FC/uPersr/MPCnQhJaOHfLAxERV2FeY1yAj9TSIgmRYfpYrfZQ5JeuqoCpAQ== Received: (qmail 94530 invoked from network); 27 Jun 2022 19:52:05 -0000 Received: from mail.bithabitat.de (HELO mail.bithabitat.de) (erdgeist@erdgeist.org) by mail.bithabitat.de with ESMTPS (TLS_AES_256_GCM_SHA384 encrypted); 27 Jun 2022 19:52:05 -0000 Date: Mon, 27 Jun 2022 21:52:05 +0200 (CEST) From: Dirk Engling To: freebsd-bluetooth@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: blued: bluetooth daemon - looking for testers In-Reply-To: Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4LWyzx6Qh1z3sHg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=erdgeist.org header.s=erdgeist header.b=gxWhMofQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of erdgeist@erdgeist.org designates 84.200.61.29 as permitted sender) smtp.mailfrom=erdgeist@erdgeist.org X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[erdgeist.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[erdgeist.org:~]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.69)[-0.687]; R_DKIM_PERMFAIL(0.00)[erdgeist.org:s=erdgeist]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:44066, ipnet:84.200.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, 27 Jun 2022, Andreas Kempe wrote: > After having issues with my bluetooth mouse, I figured out that the > problem was a lack of support for secure simple pairing and I reported > on this a while back to freebsd-bluetooth and freebsd-hackers. This > sent me down the rabbit hole of working on my own bluetooth daemon > with the goal of providing a user friendly way of pairing and using > bluetooth devices. I was at a similar point and wrote man 8 bluetooth-config a while ago. Did you find this and how does your approach differ? Best erdgeist From nobody Mon Jun 27 20:28:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 94926878DF0; Mon, 27 Jun 2022 20:28:15 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LWznV58cCz4Rqj; Mon, 27 Jun 2022 20:28:14 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 4BC591EA67; Mon, 27 Jun 2022 22:28:13 +0200 (CEST) Received: from shipon.lysator.liu.se (unknown [IPv6:2001:6b0:17:f0a0::83]) (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 mail.lysator.liu.se (Postfix) with ESMTPSA id 49B261F02F; Mon, 27 Jun 2022 22:28:13 +0200 (CEST) Date: Mon, 27 Jun 2022 22:28:12 +0200 From: Andreas Kempe To: freebsd-bluetooth@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: blued: bluetooth daemon - looking for testers Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4LWznV58cCz4Rqj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=lysator.liu.se; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se X-Spamd-Result: default: False [-3.91 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; NEURAL_HAM_SHORT(-0.91)[-0.912]; MLMMJ_DEST(0.00)[freebsd-bluetooth,freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 27, 2022 at 09:52:05PM +0200, Dirk Engling wrote: > > On Mon, 27 Jun 2022, Andreas Kempe wrote: > > > After having issues with my bluetooth mouse, I figured out that the > > problem was a lack of support for secure simple pairing and I reported > > on this a while back to freebsd-bluetooth and freebsd-hackers. This > > sent me down the rabbit hole of working on my own bluetooth daemon > > with the goal of providing a user friendly way of pairing and using > > bluetooth devices. > > I was at a similar point and wrote > > man 8 bluetooth-config > > a while ago. Did you find this and how does your approach differ? > The biggest difference in bluetooth functionality at the moment is that I implemented support for secure simple pairing, something that was missing in hcsecd, not allowing for my mouse to pair correctly. It would connect once, but refuse to reconnect. Functionality that could have been amended to hcsecd for sure and I did submit a rough PoC to the mailing lists that garnered no response. Thinking a bit about it, I wanted to aim a bit differently and realised I would most likely be rewriting the whole of hcsecd anyway. My wish is to provide something with an RPC that allows an unprivileged user to configure and manage bluetooth devices. blued listens on a unix socket and has a msgpack based IPC that allows a used with sufficient permissions on the socket to manage devices that are saved to an sqlite3 database. At the moment, I only provide a command line client, but a goal is to provide some kind of graphical user interface that can list devices and make the use of a command line unnecessary. My ideal is a process that looks much like the one on a Linux system, where the user sees devices in proximity pop up in a list, click it, select pair and the mouse starts working. As I wrote in the mail you responded to, this current version relies on a stand-alone bthidd for the mouse functionality, but when the pairing support has gotten to a point where it seems stable and working out in reality, I want to integrate bthidd with blued in some manner to make it seamless via the blued IPC API. Cordially, Andreas Kempe From nobody Tue Jun 28 09:29:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5BCAE875874 for ; Tue, 28 Jun 2022 09:29:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXK701tNDz4rfV for ; Tue, 28 Jun 2022 09:29:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656408572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QXANfcJUGDvyg8N34gt2lX8Gd54mU/IlaUn4FrHO7IU=; b=SfmZMP/YbN7pHhyP2T7eAM1rlvwOKMtv7Xbm0LjKTrAG+mSMZtRazqeRa4GI5GmLtCJw2F Y4jRPqcZo6cOgduYySA103i4fLfxkx+6zPXPuMAmUfeQ1dp4XtKWKqsgdKpfiy7LFFHoBX AAJ3Cn2nxug1yAPCuLyQpGG/htHu8zgfh7vy9j8/50Bg/od095K2BYpwL9MA79rn+7XVh4 4SR5Lga4JIkNo+I5xhsv6dOGlWLMCOKHaR07TQBcnH9vColuHKrTgf1+3I/YCT4ANQa3oG VPqMU0hg4tHvbw3cPHtPaTmWjzNNTYkwFPJiqRZy4/6snS0A1/NXrZyseDPPKQ== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 195172CDAA for ; Tue, 28 Jun 2022 09:29:32 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [10.164.186.150] (unknown [167.220.197.22]) by smtp.theravensnest.org (Postfix) with ESMTPSA id A5F8331AF6 for ; Tue, 28 Jun 2022 10:29:31 +0100 (BST) Message-ID: Date: Tue, 28 Jun 2022 10:29:29 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: how to run bhyve and virtualbox at the same time Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <62B9FBF1.6030906@grosbein.net> From: David Chisnall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1656408572; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QXANfcJUGDvyg8N34gt2lX8Gd54mU/IlaUn4FrHO7IU=; b=RV7wiRBVE7zn05iYPfNk+bsLEf0OgAzh8tB9UHoWCIhefe0AtCh2Jx4p54plOfKM+FX4/5 ekU4CcECRx+ekTc788iJrUzIxs4cOvIc4Q7Q/AF1KuJ1fua0ZJ3ewqpaIyawnwypmM16a0 NYW5p/jnI2Qcfz4Cse1LP2jEWL00g5awql0QfMJvSehX2qzFDEHfapKxRljzmq/sQBaQkA DXHqfRYhLBP2ONXkx5HPI2px3dyLJuYJnc1p1uF65Xhh9jHxA6S1uZNUDtq17HkSGcQlLm s9oEaM9/072YF9kGRuOHaHKlQpO7jktt745GUQtHtPxoWMaB0xBA1PDR2im2gQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1656408572; a=rsa-sha256; cv=none; b=rZXjIlQoXG5EqgEUr/L6bqapUVTTb4okogeNlMGR7clagouooo1jsJGVnO7s9zpxkt01gT z6meNmuHN+xSS7cn/N2MmRfp+yGeF/ITJFAwgyFqidnf3NWu/E3IrfjRbdfLnOfYPIwFhx yOvksoK4hwKKuA6PQ6a/XXevGVgQpjLmJ93VE9kQ7yZLjNZHRoOfBC3szSIP8jJTSsQs+D EjrPD65tSHxUMMXmYA9P8Uon01Em+B5mbpXWk4866Oqa9UWyWTTNdWib2dfsOQ3F5lHdgU 7YogJl+Mnx5kmKd0KEntS6veYAm9f/cfhgyej4DzqCsP/kbVIQoGwSqYxYVRRA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 27/06/2022 20:41, Mario Marietto wrote: > I did it already and it works. Fact is that if I use virtualbox I can't > use bhyve at the same time. So It's not a good idea to use only > virtualbox machines. On macOS, VirtualBox can coexist with other hypervisors because it does not provide a kernel module (it is not allowed to on recent macOS) but is, instead, layered on top of Apple's Hypervisor framework. bhyve has also been ported to sit on top of Apple's Hypervisor framework (xhyve, used by Docker) and I believe that the abstractions provided by the bhyve kernel module are fairly similar. It should be possible to port VirtualBox to sit on top of vmm.ko. I have not been able to find any documentation of the vmm(4) ioctls other than the source code, so I'd imagine that about 2/3 of this work would be documenting the kernel interfaces. David From nobody Tue Jun 28 10:01:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 852EC87A65E for ; Tue, 28 Jun 2022 10:01:25 +0000 (UTC) (envelope-from freebsd@aeichner.de) Received: from mail.a-eichner.de (mail.a-eichner.de [136.243.96.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4LXKqm5TXHz3CPG for ; Tue, 28 Jun 2022 10:01:24 +0000 (UTC) (envelope-from freebsd@aeichner.de) Received: from [192.168.2.234] (ip4d17e279.dynamic.kabel-deutschland.de [77.23.226.121]) by mail.a-eichner.de (Postfix) with ESMTPSA id A67D34C049A for ; Tue, 28 Jun 2022 12:01:18 +0200 (CEST) From: Alexander Eichner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: how to run bhyve and virtualbox at the same time Date: Tue, 28 Jun 2022 12:01:17 +0200 References: <62B9FBF1.6030906@grosbein.net> To: freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <1D2BDC88-6739-45E0-A609-98D6FF271733@aeichner.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4LXKqm5TXHz3CPG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@aeichner.de has no SPF policy when checking 136.243.96.80) smtp.mailfrom=freebsd@aeichner.de X-Spamd-Result: default: False [-1.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[aeichner.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:136.243.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[77.23.226.121:received] X-ThisMailContainsUnwantedMimeParts: N Hi, VirtualBox 6.1.x uses its own hypervisor with kernel modules on macOS, = it just uses some internal kernel interfaces to be able to share the hardware virtualization functionality with other hypervisors. On hosts other than Windows and macOS VirtualBox defaults to an = exclusive use of VT-x/SVM for performance reasons. That mode can be = changed to do the initialization every time VirtualBox is scheduled on a = particular CPU which has higher overhead but allows sharing the hardware = virtualization capabilities with other hypervisors. The setting can be changed with VBoxManage. Look = at the manual under [1] and search for =E2=80=9Ehwvirtexclusive=E2=80=9C. However bhyve would need to support something similar to be able to play = along, I don=E2=80=99t know whether it does. Regards, Alexander Eichner [1] https://www.virtualbox.org/manual/UserManual.html > On 28.06.2022 11:29, David Chisnall wrote: >=20 > On 27/06/2022 20:41, Mario Marietto wrote: >> I did it already and it works. Fact is that if I use virtualbox I = can't use bhyve at the same time. So It's not a good idea to use only = virtualbox machines. >=20 > On macOS, VirtualBox can coexist with other hypervisors because it = does not provide a kernel module (it is not allowed to on recent macOS) = but is, instead, layered on top of Apple's Hypervisor framework. >=20 > bhyve has also been ported to sit on top of Apple's Hypervisor = framework (xhyve, used by Docker) and I believe that the abstractions = provided by the bhyve kernel module are fairly similar. >=20 > It should be possible to port VirtualBox to sit on top of vmm.ko. I = have not been able to find any documentation of the vmm(4) ioctls other = than the source code, so I'd imagine that about 2/3 of this work would = be documenting the kernel interfaces. >=20 > David >=20 From nobody Tue Jun 28 14:43:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1229E87E000; Tue, 28 Jun 2022 14:43:39 +0000 (UTC) (envelope-from freebsd@aeichner.de) Received: from mail.a-eichner.de (mail.a-eichner.de [136.243.96.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4LXS5Q1SZXz4ZP0; Tue, 28 Jun 2022 14:43:37 +0000 (UTC) (envelope-from freebsd@aeichner.de) Received: from [192.168.2.234] (ip4d17e279.dynamic.kabel-deutschland.de [77.23.226.121]) by mail.a-eichner.de (Postfix) with ESMTPSA id C1DA64C5343; Tue, 28 Jun 2022 16:43:08 +0200 (CEST) From: Alexander Eichner Message-Id: <8166EF9F-7374-4B05-8269-427A76909002@aeichner.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_2457BFC7-3391-42E9-91F0-2E4D1A306A68" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: how to run bhyve and virtualbox at the same time Date: Tue, 28 Jun 2022 16:43:07 +0200 In-Reply-To: Cc: FreeBSD virtualization To: freebsd-hackers@freebsd.org References: <62B9FBF1.6030906@grosbein.net> <1D2BDC88-6739-45E0-A609-98D6FF271733@aeichner.de> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 4LXS5Q1SZXz4ZP0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@aeichner.de has no SPF policy when checking 136.243.96.80) smtp.mailfrom=freebsd@aeichner.de X-Spamd-Result: default: False [-0.15 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.664]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[aeichner.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; RCPT_COUNT_TWO(0.00)[2]; HTTP_TO_IP(1.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers,freebsd-virtualization]; R_SPF_NA(0.00)[no SPF record]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:136.243.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[77.23.226.121:received] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_2457BFC7-3391-42E9-91F0-2E4D1A306A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The content of the VBox.log strongly smells like bhyve wants to use = VT-x/SVM exclusively, unfortunately nothing VirtualBox can do anything = about. vmm.ko/bhyve would need to implement a mode for sharing those = capabilities. And because I forgot to add this to my last mail. I had a look at the = vmm.ko API already and found that the guest memory management API looks = quite strange and is completely different from what kvm/AppleHV/Hyper-V etc. do. With = those you allocate page aligned memory using mmap()/VirtualAlloc() and = pass the GPA and the userspace virtual pointer to the hypervisor for the mapping. = With vmm.ko you allocate the memory through the hypervisor directly = using an ioctl providing the GPA and size and you get a user space mapping by a = sub-sequent mmap() call on the character device for the given offset. = And with libvmm you only have the option to allocate all the memory up-front. Regards, Alexander Eichner > On 28.06.2022 15:32, Mario Marietto wrote: >=20 > I've rebooted and then I have launched virtualbox first and when macos = has been loaded totally,I gave the following command : >=20 > sudo kldload vmm >=20 > and this is what happened : >=20 > > I've attached the log files produced.... >=20 > Il giorno mar 28 giu 2022 alle ore 14:48 Mario Marietto = > ha scritto: > Ok. As root I have disabled the hwvirtexclusive property giving this = command : >=20 > VBoxManage setproperty hwvirtexclusive off >=20 > as explained here : https://www.virtualbox.org/manual/ch09.html = >=20 > this is what happens when I launch bhyve first and then virtualbox.... >=20 >=20 > >=20 > More interesting is to see what happens when I launch virtualbox = first,executing this script : >=20 > setxkbmap it > bhyvectl --vm=3Dvm0 --force-reset > bhyvectl --vm=3Dvm0 --destroy > bhyvectl --vm=3Dvm1 --force-reset > bhyvectl --vm=3Dvm1 --destroy > bhyvectl --vm=3Dvm2 --force-reset > bhyvectl --vm=3Dvm2 --destroy > bhyvectl --vm=3Dvm3 --force-reset > bhyvectl --vm=3Dvm3 --destroy > bhyvectl --vm=3Dvm4 --force-reset > bhyvectl --vm=3Dvm4 --destroy > bhyvectl --vm=3Dvm5 --force-reset > bhyvectl --vm=3Dvm5 --destroy > bhyvectl --vm=3Dvm6 --force-reset > bhyvectl --vm=3Dvm6 --destroy > bhyvectl --vm=3Dvm7 --force-reset > bhyvectl --vm=3Dvm7 --destroy > bhyvectl --vm=3Dvm8 --force-reset > bhyvectl --vm=3Dvm8 --destroy > bhyvectl --vm=3Dvm9 --force-reset > bhyvectl --vm=3Dvm9 --destroy > bhyvectl --vm=3Dvm10 --force-reset > bhyvectl --vm=3Dvm10 --destroy > bhyvectl --vm=3Dvm11 --force-reset > bhyvectl --vm=3Dvm11 --destroy > bhyvectl --vm=3Dvm12 --force-reset > bhyvectl --vm=3Dvm12 --destroy > bhyvectl --vm=3Dvm13 --force-reset > bhyvectl --vm=3Dvm13 --destroy > bhyvectl --vm=3Dvm14 --force-reset > bhyvectl --vm=3Dvm14 --destroy > bhyvectl --vm=3Dvm15 --force-reset > bhyvectl --vm=3Dvm15 --destroy > bhyvectl --vm=3Dvm16 --force-reset > bhyvectl --vm=3Dvm16 --destroy > bhyvectl --vm=3Dvm17 --force-reset > bhyvectl --vm=3Dvm17 --destroy > bhyvectl --vm=3Dvm18 --force-reset > bhyvectl --vm=3Dvm18 --destroy > bhyvectl --vm=3Dvm19 --force-reset > bhyvectl --vm=3Dvm19 --destroy > bhyvectl --vm=3Dvm20 --force-reset > bhyvectl --vm=3Dvm20 --destroy > sudo kldunload vmm > virtualbox >=20 > At this point MacOS is able to boot and run correctly. At this point I = tried to launch a bhyve vm executing this script : >=20 > bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ > -s 0,hostbridge \ > -s 1,nvme,/dev/nvd0,bootindex=3D1 \ > -s 2,ahci-hd,/dev/$vmdisk2 \ > -s 3,ahci-hd,/dev/$vmdisk3 \ > -s 4,ahci-hd,/dev/$vmdisk4 \ > -s 7,virtio-net,tap4 \ > -s 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \ > -s 29,fbuf,tcp=3D0.0.0.0:5904 ,w=3D1500,h=3D950 = \ > -s 30,xhci,tablet \ > -s 31,lpc \ > -l bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \ > vm4 < /dev/null & sleep 2 && vncviewer 0:4 >=20 > my FreeBSD 13.1-RELEASE totally crashed. I've seen a lot of errors on = the screen,a lot of them related to efi and my PC rebooted. It seems = that the file bhyve.core has not produced,even if I read "creating = memory dumping"... >=20 > Il giorno mar 28 giu 2022 alle ore 12:03 Alexander Eichner = > ha scritto: > Hi, >=20 > VirtualBox 6.1.x uses its own hypervisor with kernel modules on macOS, = it just uses some internal kernel interfaces to be able to share > the hardware virtualization functionality with other hypervisors. >=20 > On hosts other than Windows and macOS VirtualBox defaults to an = exclusive use of VT-x/SVM for performance reasons. That mode can be = changed > to do the initialization every time VirtualBox is scheduled on a = particular CPU which has higher overhead but allows sharing the hardware = virtualization capabilities > with other hypervisors. The setting can be changed with VBoxManage. = Look at the manual under [1] and search for =E2=80=9Ehwvirtexclusive=E2=80= =9C. > However bhyve would need to support something similar to be able to = play along, I don=E2=80=99t know whether it does. >=20 > Regards, > Alexander Eichner >=20 > [1] https://www.virtualbox.org/manual/UserManual.html = >=20 > > On 28.06.2022 11:29, David Chisnall wrote: > >=20 > > On 27/06/2022 20:41, Mario Marietto wrote: > >> I did it already and it works. Fact is that if I use virtualbox I = can't use bhyve at the same time. So It's not a good idea to use only = virtualbox machines. > >=20 > > On macOS, VirtualBox can coexist with other hypervisors because it = does not provide a kernel module (it is not allowed to on recent macOS) = but is, instead, layered on top of Apple's Hypervisor framework. > >=20 > > bhyve has also been ported to sit on top of Apple's Hypervisor = framework (xhyve, used by Docker) and I believe that the abstractions = provided by the bhyve kernel module are fairly similar. > >=20 > > It should be possible to port VirtualBox to sit on top of vmm.ko. I = have not been able to find any documentation of the vmm(4) ioctls other = than the source code, so I'd imagine that about 2/3 of this work would = be documenting the kernel interfaces. > >=20 > > David > >=20 >=20 >=20 >=20 >=20 > --=20 > Mario. >=20 >=20 > --=20 > Mario. > --Apple-Mail=_2457BFC7-3391-42E9-91F0-2E4D1A306A68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = content of the VBox.log strongly smells like bhyve wants to use VT-x/SVM = exclusively, unfortunately nothing VirtualBox can do anything about.
vmm.ko/bhyve would need to implement a mode for sharing those = capabilities.

And because I forgot to add this to my last mail. I had a = look at the vmm.ko API already and found that the guest memory = management API looks quite strange and
is = completely different from what kvm/AppleHV/Hyper-V etc. do. With those = you allocate page aligned memory using mmap()/VirtualAlloc() and pass = the GPA
and the userspace virtual pointer to the = hypervisor for the mapping. With vmm.ko you allocate the memory through = the hypervisor directly using an ioctl
providing = the GPA and size and you get a user space mapping by a sub-sequent = mmap() call on the character device for the given offset. And with = libvmm
you only have the option to allocate all the = memory up-front.

Regards,
Alexander Eichner

On 28.06.2022 15:32, Mario Marietto <marietto2008@gmail.com> wrote:

I've rebooted and = then I have launched virtualbox first and when macos has been loaded = totally,I gave the following command :

sudo kldload vmm
and this is what happened :

<Screenshot_2022-06-28_15-09-49.jpg><= br class=3D"">
I've attached the log files = produced....

Il giorno = mar 28 giu 2022 alle ore 14:48 Mario Marietto <marietto2008@gmail.com> ha scritto:
Ok. As root I have disabled the = hwvirtexclusive property giving this command :

VBoxManage setproperty =
hwvirtexclusive off

as explained here : https://www.virtualbox.org/manual/ch09.html

this is = what happens when I launch bhyve first and then virtualbox....


<Screenshot_2022-06-28_14-12-36.jpg><= br class=3D"">

More interesting is to see what happens when I launch = virtualbox first,executing this script :

setxkbmap it
bhyvectl = --vm=3Dvm0 --force-reset
bhyvectl --vm=3Dvm0 --destroy
bhyvectl --vm=3Dvm1 --force-reset
bhyvectl = --vm=3Dvm1 --destroy
bhyvectl --vm=3Dvm2 --force-reset
bhyvectl --vm=3Dvm2 --destroy
bhyvectl --vm=3Dvm3= --force-reset
bhyvectl --vm=3Dvm3 --destroy
bhyvectl --vm=3Dvm4 --force-reset
bhyvectl = --vm=3Dvm4 --destroy
bhyvectl --vm=3Dvm5 --force-reset
bhyvectl --vm=3Dvm5 --destroy
bhyvectl --vm=3Dvm6= --force-reset
bhyvectl --vm=3Dvm6 --destroy
bhyvectl --vm=3Dvm7 --force-reset
bhyvectl = --vm=3Dvm7 --destroy
bhyvectl --vm=3Dvm8 --force-reset
bhyvectl --vm=3Dvm8 --destroy
bhyvectl --vm=3Dvm9= --force-reset
bhyvectl --vm=3Dvm9 --destroy
bhyvectl --vm=3Dvm10 --force-reset
bhyvectl = --vm=3Dvm10 --destroy
bhyvectl --vm=3Dvm11 = --force-reset
bhyvectl --vm=3Dvm11 --destroy
bhyvectl --vm=3Dvm12 --force-reset
bhyvectl = --vm=3Dvm12 --destroy
bhyvectl --vm=3Dvm13 = --force-reset
bhyvectl --vm=3Dvm13 --destroy
bhyvectl --vm=3Dvm14 --force-reset
bhyvectl = --vm=3Dvm14 --destroy
bhyvectl --vm=3Dvm15 = --force-reset
bhyvectl --vm=3Dvm15 --destroy
bhyvectl --vm=3Dvm16 --force-reset
bhyvectl = --vm=3Dvm16 --destroy
bhyvectl --vm=3Dvm17 = --force-reset
bhyvectl --vm=3Dvm17 --destroy
bhyvectl --vm=3Dvm18 --force-reset
bhyvectl = --vm=3Dvm18 --destroy
bhyvectl --vm=3Dvm19 = --force-reset
bhyvectl --vm=3Dvm19 --destroy
bhyvectl --vm=3Dvm20 --force-reset
bhyvectl = --vm=3Dvm20 --destroy
sudo kldunload vmm
virtualbox

At this point MacOS is able to boot and run correctly. At = this point I tried to launch a bhyve vm executing this script = :

bhyve -S -c = sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s = 0,hostbridge \
-s 1,nvme,/dev/nvd0,bootindex=3D1 \
-s 2,ahci-hd,/dev/$vmdisk2 \
-s = 3,ahci-hd,/dev/$vmdisk3 \
-s 4,ahci-hd,/dev/$vmdisk4 \
-s 7,virtio-net,tap4 \
-s = 10,hda,play=3D/dev/dsp,rec=3D/dev/dsp \
-s 29,fbuf,tcp=3D0.0.0.0:5904,w=3D1500,h=3D950 \
-s = 30,xhci,tablet \
-s 31,lpc \
-l = bootrom,/usr/local/share/uefi-firmware/BHYVE_BHF_CODE.fd \
vm4 < /dev/null & sleep 2 && vncviewer 0:4

my = FreeBSD 13.1-RELEASE totally crashed. I've seen a lot of errors on the = screen,a lot of them related to efi and my PC rebooted. It seems that = the file bhyve.core has not produced,even if I read "creating memory = dumping"...

Il giorno = mar 28 giu 2022 alle ore 12:03 Alexander Eichner <freebsd@aeichner.de> ha scritto:
Hi,

VirtualBox 6.1.x uses its own hypervisor with kernel modules on macOS, = it just uses some internal kernel interfaces to be able to share
the hardware virtualization functionality with other hypervisors.

On hosts other than Windows and macOS VirtualBox defaults to an = exclusive use of VT-x/SVM for performance reasons. That mode can be = changed
to do the initialization every time VirtualBox is scheduled on a = particular CPU which has higher overhead but allows sharing the hardware = virtualization capabilities
with other hypervisors. The setting can be changed with VBoxManage. Look = at the manual under [1] and search for =E2=80=9Ehwvirtexclusive=E2=80=9C.<= br class=3D""> However bhyve would need to support something similar to be able to play = along, I don=E2=80=99t know whether it does.

Regards,
Alexander Eichner

[1] https://www.virtualbox.org/manual/UserManual.html

> On 28.06.2022 11:29, David Chisnall <theraven@FreeBSD.org> wrote:
>
> On 27/06/2022 20:41, Mario Marietto wrote:
>> I did it already and it works. Fact is that if I use virtualbox = I can't use bhyve at the same time. So It's not a good idea to use only = virtualbox machines.
>
> On macOS, VirtualBox can coexist with other hypervisors because it = does not provide a kernel module (it is not allowed to on recent macOS) = but is, instead, layered on top of Apple's Hypervisor framework.
>
> bhyve has also been ported to sit on top of Apple's Hypervisor = framework (xhyve, used by Docker) and I believe that the abstractions = provided by the bhyve kernel module are fairly similar.
>
> It should be possible to port VirtualBox to sit on top of = vmm.ko.  I have not been able to find any documentation of the = vmm(4) ioctls other than the source code, so I'd imagine that about 2/3 = of this work would be documenting the kernel interfaces.
>
> David
>




--
Mario.


--
Mario.
<logs.zip>
= --Apple-Mail=_2457BFC7-3391-42E9-91F0-2E4D1A306A68-- From nobody Tue Jun 28 17:11:24 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 05B6C86A3EE for ; Tue, 28 Jun 2022 17:11:36 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXWN63Jfkz4qqf for ; Tue, 28 Jun 2022 17:11:34 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 5A5BA320084E for ; Tue, 28 Jun 2022 13:11:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 28 Jun 2022 13:11:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm1; t=1656436286; x=1656522686; bh=0kQCZbTVtI rmq/G3vHV023BMtmplDT56x7OXF40NrsU=; b=ijtFsG7UhjlAyqK9/+9rXIuSAt Ck+hJnQc8P8J/Lw8X9WRG6NAVA4Q1QpQWYjXwzAZnSZmzsGBV2wxKlB/KfCXjCPK OgTDjstRhH4GvuhR3Kleh01W/rrtuDjatGiIV8GvVABobhctzU0nP54PI5lwCxHP pxoT9bP2dsUpsZIw1ZFKOrzaBuFO7v3M6dMlVSFEHk4Q5ScOsRDSRFlBr6HziCdG hoFIQy7zQwAPSqloWf1Fii2nYuXiCbWkf+dgK3EReLIWljcumrDz2KiqBnSILJVY xobZLcstE7YU2hC9gbbGhBg4UP7xwiI6epZqkDlBmlnXwMpan3cQUQW18KgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1656436286; x=1656522686; bh=0kQCZbTVtIrmq/G3vHV023BMtmpl DT56x7OXF40NrsU=; b=hSCHU83iBmC+IQDnxjbfm52zRNRh7jMuuwZ/fz2uzBUE Dsrda4Gbwb9oPqbW02n0uQ6wEEquUDg8FqLZh3PzNP/k1PilSvyWGvrDVq8Ddmrh ZXgPbUBvtijdgQR4SQKY4dDno3Ws2NXoINRzxMr6qouujwuJkrkF0CFa1+bSXCc3 eASuwtuK8p/txYJMmUS1RvX2q+6zO3CZ7pnIXkroLHGEO9oQIsbHcUzLYS0sfqVY FUxeW4ohajoNGUKK9Y9FOOUuIgPrge+tXLoIQtVM7WiZNfGFnvu3FU1uwb6NNIWi dEz30XxAWbfbNgCn3ViDF8dC0xZfHgd+TJYKiSNV5g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegjedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvffhufgtgfesthejre dttdefjeenucfhrhhomhepjghurhhiuceohihurhhisegrvghtvghrnhdrohhrgheqnecu ggftrfgrthhtvghrnhepkefgtdffgefhheegledvueevkedvkeejteeugfevheeitdfgke fhveelhedvleejnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 28 Jun 2022 13:11:26 -0400 (EDT) Message-ID: <2058ec43-7c77-6369-c706-e1e01e080515@aetern.org> Date: Tue, 28 Jun 2022 20:11:24 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: hackers@freebsd.org From: Yuri Subject: ipmi: do not omit lun in BMC addresses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LXWN63Jfkz4qqf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=ijtFsG7U; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=hSCHU83i; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.19 as permitted sender) smtp.mailfrom=yuri@aetern.org X-Spamd-Result: default: False [-4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm2]; FREEFALL_USER(0.00)[yuri]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[aetern.org]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from] X-ThisMailContainsUnwantedMimeParts: N Another simple review for ipmi driver, which fixes sensors on some systems where they were put on non-0 lun. This was the only difference with linux driver here, where the sensors worked. https://reviews.freebsd.org/D35612 From nobody Tue Jun 28 20:38:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B9AEA866E8E for ; Tue, 28 Jun 2022 20:39:00 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXbzS0n24z4QqW for ; Tue, 28 Jun 2022 20:39:00 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x731.google.com with SMTP id k10so10578377qke.9 for ; Tue, 28 Jun 2022 13:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=klVD4EqcN8FepRfhguVcqevzBhDOwp8jaylgYhn9aGs=; b=IOctWk97t2qanUrF4wxVimdj9VfK/IOEgqCIAOgF9yCp1j9FkeUGO2TfBd9FyVIIrq EvUQbqjA1dx9CS+xeKnGrnnaQwIFo5pfGjNm3fEjV+YxaJWJxtuEbdP0wasV/cvIkv5d p/hMOTLMcalwFMOUhVjo/DGPB61FPnfV4WiSMlewN8AV/b8MtaSef1l3AK5P+r0f4zrX y3KOJ0W2doBR/qIJEODaOKshEcF1+g6P8rMh9sITPWb4v4RLFIcTMyoFGUbqlmO4mBnB yYUJJ9d3UZwKH68o21j0OdLQkjs3pOzLx3V3WS203SKTuVBOfaws+2a9cggQoOATyzMH HkXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=klVD4EqcN8FepRfhguVcqevzBhDOwp8jaylgYhn9aGs=; b=ASBxzaHi+6oIi3nQXJ5v4ZqYgxU96KSQMnJxXmX8/ymtQZCQ+rp/dJrcIxTBQNSVKl 3JySo9cA5wjvnghoB2/amxWsZGZN71IW6db9vVYF4q+7tmMJQpO2YF665Geice5+VgNR 7zaP3Zdg4ofPXYqTwhKX0E+vxkY1qSszrc4ILzeS5tf5b/hsfZ/FaxciOidR8ri+d9bu oor7z+GueNmtjZ5idt9+hTPwVBBskY6JQe85B7TF6bNogf8E1pQTH9fCwUrc8LbaxPGp FHjWOLxsMGbXiTmCzoL07IHNQTgRmE449G1MBOQV4JC2NGavbfLqLg30sR6qMNOBraF6 XT4Q== X-Gm-Message-State: AJIora/EhzqOUo/l/qHxFPIv8jWEvkszus2F6zpTBDETCJEiuZYw2XHt 86nbQN4tx0keKmVOuTLtQG+9DmBkKYrBOiA8ZPY8FB++66MkZjHh X-Google-Smtp-Source: AGRyM1ugG7NgsHZ31WdggmiuMobBJ9m2gZb9ppzZAhf4x6Fsz14FoQtSY+GWlU2RXXUHG5RNS1ADLx6YXKfkGUNXgdM= X-Received: by 2002:a05:620a:1a1a:b0:6af:351e:62de with SMTP id bk26-20020a05620a1a1a00b006af351e62demr6273490qkb.667.1656448739390; Tue, 28 Jun 2022 13:38:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Jake Freeland Date: Tue, 28 Jun 2022 15:38:48 -0500 Message-ID: Subject: LinuxKPI debugfs Port To: freebsd-hackers@freebsd.org, Mark Johnston Content-Type: multipart/alternative; boundary="000000000000b34a5105e2880661" X-Rspamd-Queue-Id: 4LXbzS0n24z4QqW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=IOctWk97; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[technologyfriends.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000b34a5105e2880661 Content-Type: text/plain; charset="UTF-8" Hi there, I am working on porting Intel's igt-gpu-tools drm graphics driver testing suite to FreeBSD and I ran into some issues regarding debugfs. I spoke to manu@ who told me that CONFIG_DEBUG_FS is required for the testing to work properly. I started working on a debugfs port and quickly got confused about what manu@ meant by implementing "CONFIG_DEBUG_FS". Some quick internet searching says that CONFIG_DEBUG_FS is a Linux kernel configuration flag. I am curious how I would go about implementing this into FreeBSD. I copied the Linux debugfs source code into a new repository and attempted to compile it on FreeBSD as a kernel module: https://github.com/jakesfreeland/debugfs-freebsd Of course I was met with many, many incompatibility errors. I proceeded to copy the required `sys/compat/linuxkpi/common/include/linux` headers into my repository and I was met with two options: 1. continue modifying the LinuxKPI headers and commit my modifications to src. 2. re-engineer the debugfs source code to comply with the preexisting LinuxKPI headers. Many problems come with both approaches. First, if I modify the LinuxKPI headers, I'd be "copying" over some code from Linux's GPLv2 headers. I do not know how much I can "copy" before legal issues arise. Second, if I re-engineer the debugfs source code, I am revolting against what LinuxKPI stands for: running Linux code with little-to-no modification. I don't know what the correct approach is here. I also discovered that lindebugfs, a curtailed version of Linux's debugfs, already exists in FreeBSD's src. I am led to believe that this is exclusively used under the Linuxulator so it wouldn't help me. Is this correct? Thank you so much, Jake Freeland --000000000000b34a5105e2880661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I am working on porting I= ntel's igt-gpu-tools drm graphics driver testing
suite to Fre= eBSD and I ran into some issues regarding debugfs. I spoke
to man= u@ who told me that CONFIG_DEBUG_FS is required for the
testing t= o work properly. I started working on a debugfs port and quickly
= got confused about what manu@ meant by implementing=C2=A0"CONFIG_DEBUG= _FS".

Some quick internet searching says that= CONFIG_DEBUG_FS is a
Linux kernel configuration flag. I am curio= us how I would go about
implementing=C2=A0this into FreeBSD. I co= pied the Linux debugfs source
code into a new repository and atte= mpted to compile it on FreeBSD
as a kernel module:

=

<= div>Of course I was met with many, many incompatibility=C2=A0errors. I proc= eeded
to copy the required `sys/compat/linuxkpi/common/include/li= nux` headers
into my repository and I was met with two options:

1. continue modifying the LinuxKPI headers and comm= it my modifications
to src.

2. re-engine= er the debugfs source code to comply with the preexisting
LinuxKP= I headers.

Many problems come with both approaches= . First, if I modify the LinuxKPI
headers, I'd be "copyi= ng" over some code from Linux's GPLv2 headers.
I do not = know how much I can "copy" before legal issues arise. Second,
if I re-engineer the debugfs source code, I am revolting against wha= t LinuxKPI
stands for: running Linux code with little-to-no modif= ication. I don't know
what the correct approach is here.

I also discovered that lindebugfs, a curtailed version= of Linux's debugfs,
already exists in FreeBSD's src. I a= m led to believe=C2=A0that this is exclusively
used under the Lin= uxulator so it wouldn't help me. Is this correct?

<= div>Thank you so much,
Jake Freeland
--000000000000b34a5105e2880661-- From nobody Tue Jun 28 21:18:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 694F786CF6A for ; Tue, 28 Jun 2022 21:18:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXcrq4GpNz4WNl for ; Tue, 28 Jun 2022 21:18:19 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf29.google.com with SMTP id cs6so21976193qvb.6 for ; Tue, 28 Jun 2022 14:18:19 -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=Ykg53DPnvV49tQK5ztghYO/fIUJKwjjZV3cimgbCd1M=; b=ShOFPe9XGxoiPLjPxWx3ns01RNuU73wD2BE71u49QG2/LRVfgXxdCO+T01JrCdS9xo o2HLOeM+J334A6fdbliWWux+pJQR0hnz7fJ8fJVsaptsbu3DJ5OgZWgB1mWnROmHdIry 7lYTuqMgxy8RZR2UKww9iaBis+uj+kuZH4mPy6Ohj3xD07Nq1YJE7QlvgPfGby9qXY8e w3dTATMNYOaldn5k7tbuRfQMSvdAWoz9V7DQQdMrQqjVNojt5bSOFO9hOPgC2KBf2V7n 5J4m1zr5sUh95PGX3rH07nH3K79/pyPXD2cqLHjrOqLBGYLUzuOGPdhZcSdL8wVNPMgG rGzg== 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=Ykg53DPnvV49tQK5ztghYO/fIUJKwjjZV3cimgbCd1M=; b=BdORJ+IOESf8sP60SLWe0uqkS0JGgxvB1E+R7DZmex7/c98XfEvzHKU5NtTvkwfvb6 NKfzZli4hz2boYjWAwPfDU3u8HEpdpr2RJAUd5fM80DoerUT4DpY3pKbta7MX6l/By/D kN4z3JgL12B/jHC2u+VHBqwH0oHxI70kfzBpUk+x97pGlT6cVOTS+SRPdxgYEQQXFQ8S XY34joQKV7SDd3l6OdlOJcuiaIaQ9Fal62FL8suNJCWWFxMNul5zHp2+Zn3rkA7Mhidr 1SSK31IxZQMIUL+xk+7oajReW0wuGdY6v43oI4EJHtkUW4ZZmx9j7M4wRIxy5qzKJedK QBXw== X-Gm-Message-State: AJIora+PO25cwWXIWAi1/b+4qX5l6ybm/pVaW8Hld/yxwhpgVykLuy9Z XOu9RcBfSKOK5t5IK6xZoHW5tMpt4ko= X-Google-Smtp-Source: AGRyM1sbrVJMj5M0SCrCxBEAxqoZ2Huuo40rhwMF9UpAPPgx9ra7JA1g5hZqm7e1E1/RFrHVS//swA== X-Received: by 2002:ac8:5dce:0:b0:305:300e:146d with SMTP id e14-20020ac85dce000000b00305300e146dmr4881qtx.546.1656451092947; Tue, 28 Jun 2022 14:18:12 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id n1-20020a05620a294100b006aedbb30947sm2622816qkp.122.2022.06.28.14.18.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 14:18:12 -0700 (PDT) Date: Tue, 28 Jun 2022 17:18:09 -0400 From: Mark Johnston To: Jake Freeland Cc: freebsd-hackers@freebsd.org Subject: Re: LinuxKPI debugfs Port Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LXcrq4GpNz4WNl X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ShOFPe9X; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f29 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.71 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.02)[-0.016]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f29:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 28, 2022 at 03:38:48PM -0500, Jake Freeland wrote: > Hi there, > > I am working on porting Intel's igt-gpu-tools drm graphics driver testing > suite to FreeBSD and I ran into some issues regarding debugfs. I spoke > to manu@ who told me that CONFIG_DEBUG_FS is required for the > testing to work properly. I started working on a debugfs port and quickly > got confused about what manu@ meant by implementing "CONFIG_DEBUG_FS". I would guess that he meant to compile the i915kms driver with CONFIG_DEBUGFS configured. I'm not sure what the "right" way is to do that, but adding KCONFIG+= DEBUGFS to the end of kconfig.mk in the drm-kmod repository seems to do the trick for me, with the caveat that the driver doesn't compile. :) I think the task is to get it to compile by extending the existing debugfs shims in the LinuxKPI, but see my comments below. There is also a typo in the makefile there, see https://github.com/freebsd/drm-kmod/pull/185 > Some quick internet searching says that CONFIG_DEBUG_FS is a > Linux kernel configuration flag. I am curious how I would go about > implementing this into FreeBSD. I copied the Linux debugfs source > code into a new repository and attempted to compile it on FreeBSD > as a kernel module: > > https://github.com/jakesfreeland/debugfs-freebsd > > Of course I was met with many, many incompatibility errors. I proceeded > to copy the required `sys/compat/linuxkpi/common/include/linux` headers > into my repository and I was met with two options: Yes, that's not going to work and isn't the right approach. > 1. continue modifying the LinuxKPI headers and commit my modifications > to src. > > 2. re-engineer the debugfs source code to comply with the preexisting > LinuxKPI headers. > > Many problems come with both approaches. First, if I modify the LinuxKPI > headers, I'd be "copying" over some code from Linux's GPLv2 headers. > I do not know how much I can "copy" before legal issues arise. Second, > if I re-engineer the debugfs source code, I am revolting against what > LinuxKPI > stands for: running Linux code with little-to-no modification. I don't know > what the correct approach is here. The purpose of the LinuxKPI is to allow Linux _drivers_ to run (mostly) unmodified on FreeBSD. Generic kernel components like debugfs itself are not meant to run under the LinuxKPI and are out of its scope. debugfs provides a set of interfaces used by drivers, including i915, to export debug info. The LinuxKPI provides a partial implementation of that interface already, in debugfs.h and lindebugfs.c, and I think the task ahead of you is to extend it to allow i915 to compile with DEBUGFS configured. (But please double check that!) > I also discovered that lindebugfs, a curtailed version of Linux's debugfs, > already exists in FreeBSD's src. I am led to believe that this is > exclusively > used under the Linuxulator so it wouldn't help me. Is this correct? No, I don't think that's accurate. It's just another pseudo filesystem, it can be used by anything that knows how to open and read files. > Thank you so much, > Jake Freeland From nobody Tue Jun 28 22:11:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 7ED3D876BB2 for ; Tue, 28 Jun 2022 22:12:07 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXf2t1xsWz4gHk for ; Tue, 28 Jun 2022 22:12:06 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x736.google.com with SMTP id f14so10864840qkm.0 for ; Tue, 28 Jun 2022 15:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Sqh7sWyhEUw0SETvLcLZl3XmmBWk/vymorJIwloiyU=; b=PKK+QQexQtdiSpT1tfHwczwslSQgOn2+E6ts8OjjDFN7YXz8Uy32vBXAEatfjIl+G0 McsKJ3bPDwt9yGkXIECJa9czUoROfFkV6fzqpDBLVwhQU8TqU8rSX/bgMmGTgHm3j44z VQOFF37zBOoIKjJ6f587vMXCI9D31mdHWx3LZiXbVGLYJ4U4w0bIdKUlgAWAhDHj56H7 f9oXQ+fNbesOfrSSQm1ilyZM91xp8OUt99PulfD9cotRJvbEyZbkf3OxvVrKA4rcHVp2 1v1PEcl4wzHzf2Kfz2jWJSBtc1gLR+VwkOf/3y3fW39lNnjZUKNbt3GbPjt0D1NCkQwS MDfA== 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=3Sqh7sWyhEUw0SETvLcLZl3XmmBWk/vymorJIwloiyU=; b=2pXWMgm3p2K6H1XDHaQKBiRdtv/IxwCBi+1TUuDwvVuBlq/1u+rRbFiklM7H0/gqrb r6Nvz1kmJJldDyjv6Jc2onvRKAh8zTkDDgfCe7Gs3k8XEBTzQlceM/8rN2JoVw653n/I xfyeKO506D5uh2mb1HC3EAeKq4UCpo1gQGSlTR3nXigBjImUf91MRTkW2FoGcozxx74y pFCVX9Gaq0CsQXpJHAYu17ZaDDzqrqSMx+SEXaI1uHf36FndeaN1yX2YLZ6xefD/zrHY EDeVuc0NyE0AXnpKQH75SfIK+INbQwtNF6B0S0WvNUWrFAQYLX5URDyRlu+8yYfizU5b GqsA== X-Gm-Message-State: AJIora/UxtXEMRQqg0cs3RtdrSOKLtBcRtVBicxuP0hqc8c8jKv8zRuK vAiMOo8Dp5By3Unlg/IeHnZ4Y8vIwGFR7NieRiVa3Zq9LgCXCg== X-Google-Smtp-Source: AGRyM1uOCR/6ZPWrk5GQwF93pSsTN7GHBxQcIg6TGqFpsGDmrwnjXGPpscRCuDrw6fAA0jXcGX4Vy+wHetVmtAzysFM= X-Received: by 2002:a05:620a:c91:b0:6af:4b9:4c1b with SMTP id q17-20020a05620a0c9100b006af04b94c1bmr64707qki.615.1656454319714; Tue, 28 Jun 2022 15:11:59 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Tue, 28 Jun 2022 17:11:49 -0500 Message-ID: Subject: Re: LinuxKPI debugfs Port To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000005048c105e289538c" X-Rspamd-Queue-Id: 4LXf2t1xsWz4gHk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=PKK+QQex; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::736) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.07 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[technologyfriends.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; NEURAL_HAM_SHORT(-0.98)[-0.980]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000005048c105e289538c Content-Type: text/plain; charset="UTF-8" Mark, Your reply clears up a lot. I just forked drm-kmod, applied your Makefile patch, and added DEBUGFS to kconfig.mk. I am extremely excited to be back on track, especially now that I know how to proceed. Just to clarify, my job is to extend the current debugfs implementation (debugfs.h and lindebugfs.c) to include the missing functionality required for i915kms to compile and run successfully? I would ask manu@, but he has not responded to me in weeks. I greatly appreciate your explanations about LinuxKPI and lindebugfs. Extensive documentation is what draws me to FreeBSD, but I struggled to find any information regarding lindebugfs or LinuxKPI. I plan to write some of my own when I am done with this project to help others in my position :). Thank you so much, Jake Freeland On Tue, Jun 28, 2022 at 4:18 PM Mark Johnston wrote: > On Tue, Jun 28, 2022 at 03:38:48PM -0500, Jake Freeland wrote: > > Hi there, > > > > I am working on porting Intel's igt-gpu-tools drm graphics driver testing > > suite to FreeBSD and I ran into some issues regarding debugfs. I spoke > > to manu@ who told me that CONFIG_DEBUG_FS is required for the > > testing to work properly. I started working on a debugfs port and quickly > > got confused about what manu@ meant by implementing "CONFIG_DEBUG_FS". > > I would guess that he meant to compile the i915kms driver with > CONFIG_DEBUGFS configured. I'm not sure what the "right" way is to do > that, but adding > > KCONFIG+= DEBUGFS > > to the end of kconfig.mk in the drm-kmod repository seems to do the > trick for me, with the caveat that the driver doesn't compile. :) > > I think the task is to get it to compile by extending the existing > debugfs shims in the LinuxKPI, but see my comments below. > > There is also a typo in the makefile there, see > https://github.com/freebsd/drm-kmod/pull/185 > > > Some quick internet searching says that CONFIG_DEBUG_FS is a > > Linux kernel configuration flag. I am curious how I would go about > > implementing this into FreeBSD. I copied the Linux debugfs source > > code into a new repository and attempted to compile it on FreeBSD > > as a kernel module: > > > > https://github.com/jakesfreeland/debugfs-freebsd > > > > Of course I was met with many, many incompatibility errors. I proceeded > > to copy the required `sys/compat/linuxkpi/common/include/linux` headers > > into my repository and I was met with two options: > > Yes, that's not going to work and isn't the right approach. > > > 1. continue modifying the LinuxKPI headers and commit my modifications > > to src. > > > > 2. re-engineer the debugfs source code to comply with the preexisting > > LinuxKPI headers. > > > > Many problems come with both approaches. First, if I modify the LinuxKPI > > headers, I'd be "copying" over some code from Linux's GPLv2 headers. > > I do not know how much I can "copy" before legal issues arise. Second, > > if I re-engineer the debugfs source code, I am revolting against what > > LinuxKPI > > stands for: running Linux code with little-to-no modification. I don't > know > > what the correct approach is here. > > The purpose of the LinuxKPI is to allow Linux _drivers_ to run (mostly) > unmodified on FreeBSD. Generic kernel components like debugfs itself > are not meant to run under the LinuxKPI and are out of its scope. > > debugfs provides a set of interfaces used by drivers, including i915, to > export debug info. The LinuxKPI provides a partial implementation of > that interface already, in debugfs.h and lindebugfs.c, and I think the > task ahead of you is to extend it to allow i915 to compile with DEBUGFS > configured. (But please double check that!) > > > I also discovered that lindebugfs, a curtailed version of Linux's > debugfs, > > already exists in FreeBSD's src. I am led to believe that this is > > exclusively > > used under the Linuxulator so it wouldn't help me. Is this correct? > > No, I don't think that's accurate. It's just another pseudo filesystem, > it can be used by anything that knows how to open and read files. > > > Thank you so much, > > Jake Freeland > --0000000000005048c105e289538c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark,

Your reply clears up a lot. I jus= t forked drm-kmod, applied your Makefile
patch, and added DEBUGFS= to kconfig.mk. I am extremely=C2=A0excit= ed to be
back on track, especially now that I know how to proceed= .

Just to clarify, my job is to extend the current= debugfs implementation
(debugfs.h and lindebugfs.c) to include t= he missing functionality required
for i915kms to compile and run = successfully? I would ask manu@, but
he has not responded to me i= n weeks.

I greatly appreciate your explanations ab= out LinuxKPI and lindebugfs.
Extensive documentation=C2=A0is what= draws me to FreeBSD, but I struggled
to find any information reg= arding lindebugfs or LinuxKPI. I plan to write
some of my own whe= n I am done with this project to help others in my
position :).

Thank you so much,
Jake Freeland

On = Tue, Jun 28, 2022 at 4:18 PM Mark Johnston <markj@freebsd.org> wrote:
On Tue, Jun 28, 2022 at 03:38:48PM -0500, Jake Fr= eeland wrote:
> Hi there,
>
> I am working on porting Intel's igt-gpu-tools drm graphics driver = testing
> suite to FreeBSD and I ran into some issues regarding debugfs. I spoke=
> to manu@ who told me that CONFIG_DEBUG_FS is required for the
> testing to work properly. I started working on a debugfs port and quic= kly
> got confused about what manu@ meant by implementing "CONFIG_DEBUG= _FS".

I would guess that he meant to compile the i915kms driver with
CONFIG_DEBUGFS configured.=C2=A0 I'm not sure what the "right"= ; way is to do
that, but adding

KCONFIG+=3D DEBUGFS

to the end of kconfig.mk in the drm-kmod repository seems to do the
trick for me, with the caveat that the driver doesn't compile. :)

I think the task is to get it to compile by extending the existing
debugfs shims in the LinuxKPI, but see my comments below.

There is also a typo in the makefile there, see
https://github.com/freebsd/drm-kmod/pull/185

> Some quick internet searching says that CONFIG_DEBUG_FS is a
> Linux kernel configuration flag. I am curious how I would go about
> implementing this into FreeBSD. I copied the Linux debugfs source
> code into a new repository and attempted to compile it on FreeBSD
> as a kernel module:
>
> https://github.com/jakesfreeland/debugfs-freebs= d
>
> Of course I was met with many, many incompatibility errors. I proceede= d
> to copy the required `sys/compat/linuxkpi/common/include/linux` header= s
> into my repository and I was met with two options:

Yes, that's not going to work and isn't the right approach.

> 1. continue modifying the LinuxKPI headers and commit my modifications=
> to src.
>
> 2. re-engineer the debugfs source code to comply with the preexisting<= br> > LinuxKPI headers.
>
> Many problems come with both approaches. First, if I modify the LinuxK= PI
> headers, I'd be "copying" over some code from Linux'= s GPLv2 headers.
> I do not know how much I can "copy" before legal issues aris= e. Second,
> if I re-engineer the debugfs source code, I am revolting against what<= br> > LinuxKPI
> stands for: running Linux code with little-to-no modification. I don&#= 39;t know
> what the correct approach is here.

The purpose of the LinuxKPI is to allow Linux _drivers_ to run (mostly)
unmodified on FreeBSD.=C2=A0 Generic kernel components like debugfs itself<= br> are not meant to run under the LinuxKPI and are out of its scope.

debugfs provides a set of interfaces used by drivers, including i915, to export debug info.=C2=A0 The LinuxKPI provides a partial implementation of<= br> that interface already, in debugfs.h and lindebugfs.c, and I think the
task ahead of you is to extend it to allow i915 to compile with DEBUGFS
configured.=C2=A0 (But please double check that!)

> I also discovered that lindebugfs, a curtailed version of Linux's = debugfs,
> already exists in FreeBSD's src. I am led to believe that this is<= br> > exclusively
> used under the Linuxulator so it wouldn't help me. Is this correct= ?

No, I don't think that's accurate.=C2=A0 It's just another pseu= do filesystem,
it can be used by anything that knows how to open and read files.

> Thank you so much,
> Jake Freeland
--0000000000005048c105e289538c-- From nobody Wed Jun 29 05:52:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0038D86C9D7 for ; Wed, 29 Jun 2022 05:52:39 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LXrGF6ZJkz3nGt for ; Wed, 29 Jun 2022 05:52:37 +0000 (UTC) (envelope-from sghctoma@gmail.com) Received: by mail-ej1-x634.google.com with SMTP id sb34so30252947ejc.11 for ; Tue, 28 Jun 2022 22:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=OypwyC0wObtfsa4a2X/PC9PSaUs5KI5cNYxc3n1u+CA=; b=hD1YD4Dcr2sEzqctJqia+311kc8UFPuz8qAWf3B49BMBjjC7Zxu4YdJuT+vSYrA8Kx wFLazWLIWPMEMkMbnUoks4fDwqDHKGl0qBLABdy7bSquJu/ww2GGvUN+bJ1XgX1oYdUE Rwu2jgHrC2GceqntSGG1Iz/AUWKURXGm4AJNi35QTxy91TU0T+6bJyM3qwCz/x+fYtQ1 3fHWoEz9vVXL3WvGkK8TEKL+WL4GOXiQWBV+LaE0tnx1h6CaYA+FplMP2xd2LrmfTsPK sUrGHoUDKf3ZDWPSs36ToiuYP14TnONsuEQmd9qFdTJaK4XGx+7ZM42KTPbNoZ7R1pvj MdQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=OypwyC0wObtfsa4a2X/PC9PSaUs5KI5cNYxc3n1u+CA=; b=eisY3Odu1RPNP/OjVA2/QYNqTtOrW1NZRySVTd2yDGl+8q//clqgx0OOMqeebfcRi3 84cwiVvIr+Gk/Zx1v837G0vdtN7z2KDhXhloigi3I3Pw1DVLH9a9zRPWZ68NIm2MmhOk VboIDV683iK7dCp91sUgu5vzKop5+fd7d+l3xECLVjGVYOq0seZTT94sjYJ9k47b6+14 XdIOD6z4l4YDUFGuV91YIxYpySH1bElpnGWJC5/cjCSLXlrokC5xcy63VG9YyTsJtv8n pJlnhRmDeUOrSkKE402mPzgKzMp/IgvDOSZuRDDSe/tJwfYKMeH9VKIBcbZezcU97LXa bAVg== X-Gm-Message-State: AJIora/b4rGkIhdouodjrZ7C6LTlq+IzQPg4xaJBom+B5kbixclUCQAr irU1SeKj/blVDtsdABdNk5EURc+r5O4= X-Google-Smtp-Source: AGRyM1uwOPdjayiEtTJg9UWyVg70XKqCUwVqEqWinv4ZeJlpolHemH2adK3EC3YVw/78QlDA4H1PfQ== X-Received: by 2002:a17:907:2d8c:b0:726:2b37:6d44 with SMTP id gt12-20020a1709072d8c00b007262b376d44mr1644772ejc.224.1656481956303; Tue, 28 Jun 2022 22:52:36 -0700 (PDT) Received: from localhost (catv-176-63-12-154.catv.fixed.vodafone.hu. [176.63.12.154]) by smtp.gmail.com with ESMTPSA id g4-20020a170906868400b006fee98045cdsm7447796ejx.10.2022.06.28.22.52.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jun 2022 22:52:35 -0700 (PDT) Date: Wed, 29 Jun 2022 07:52:35 +0200 From: Tamas Szakaly To: freebsd-hackers@freebsd.org Subject: Re: how to run bhyve and virtualbox at the same time Message-ID: <20220629055235.35suv34p5cbv2qtg@telaranrhiod> Mail-Followup-To: freebsd-hackers@freebsd.org References: <62B9FBF1.6030906@grosbein.net> <1D2BDC88-6739-45E0-A609-98D6FF271733@aeichner.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1D2BDC88-6739-45E0-A609-98D6FF271733@aeichner.de> X-Rspamd-Queue-Id: 4LXrGF6ZJkz3nGt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hD1YD4Dc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of sghctoma@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=sghctoma@gmail.com X-Spamd-Result: default: False [-3.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.81)[-0.813]; RECEIVED_SPAMHAUS_PBL(0.00)[176.63.12.154:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, > On hosts other than Windows and macOS VirtualBox defaults to an exclusive use of VT-x/SVM for performance reasons. That mode can be changed > to do the initialization every time VirtualBox is scheduled on a particular CPU which has higher overhead but allows sharing the hardware virtualization capabilities > with other hypervisors. The setting can be changed with VBoxManage. Look at the manual under [1] and search for „hwvirtexclusive“. Sorry for the off-topic comment, but this might be interesting to other VirtualBox users: a happy side effect of turning "hwvirtexclusive" off is that it seems to solve the crash that occurs when the host is resuming from S3 sleep while having running VirtualBox VMs. Toma From nobody Wed Jun 29 13:51:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3A6B2866191 for ; Wed, 29 Jun 2022 13:51:52 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LY2vC30mvz4bST for ; Wed, 29 Jun 2022 13:51:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf30.google.com with SMTP id 2so9902121qvc.0 for ; Wed, 29 Jun 2022 06:51:51 -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=ftrzZr+cWRbtDt5+TcTePVDSZxsyT9wFJl1YfyC96nQ=; b=OlFRrQp3HSjpKIpSQ2W0FIYz6aclf7k56Sy6I+NZ9fNOll+18HKTV8CVf8PcrCq/xX P1rpaiKvv8vabhm5M3+LKz8JszHeF3CO4S8SPsdsA7nhaD1smu2PZJ3HxaLNtWtpPpm/ SkE7TZktBHYKZBwIqxqh4/vNwq96oJ01NVJUvocSSgVTKi5+f8/wSLgQorfjFiBt+Qcu nRqMUW9rlaSWDh49+wxBeeMgU5lIZjuWMXGT4X8cl2Ijwlf3Ip9/x4Ovvw7Ia6wfQDLo 8DrJBlR9j4X7e4Y6MuPQIFXcbVWatb4ngvf+cXi6pzuzWoRUHPCaqhJsWDYV82iNvEKC g4tw== 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=ftrzZr+cWRbtDt5+TcTePVDSZxsyT9wFJl1YfyC96nQ=; b=KeEG1vkPN9siSeEcCiRrIOGQn/wok0NTM5qU4nq6gwat5hOYiiD4gLYS60GQ9yZR6T SYxnYzgxHN50TpNuYQzPbiME0Bimf6Yu7syaS5NJD8ACxysJdmPnmQz3Vj59flHZ0tM3 sh8GWYxBMDTlJcieAIIzq1fOV28rFLSNzbN6lNpYegRK+bsqDkD3Vc7ic/FzGKAnA2st 7UPnatK7dd6p/mTd1r2Gnfn8UclAg+rJ/8vpoMwBEnKyowoVts3GTFQTe851wekZXiTc DOZ1OtO2s/02/djPE+eycvK323ZXhgurc9u+ty/8B7xjE87LwchUd0Vt8J4rdsBFihj8 4oDg== X-Gm-Message-State: AJIora8Z+O/IXUNvJZg2/U+WRgdJCVDpqEfKKiHzTP3/D9KCKUoV0UTv yU8FV4KuU7VKITGDiwIPiWniodNT8Sg= X-Google-Smtp-Source: AGRyM1tkceUZdK9to56Fapa3lbdLmvJbi0GljhpXSWfYgCEgbM4YYwbfDqBggvon6vwgvzsw5Pkx8w== X-Received: by 2002:ac8:5b88:0:b0:305:340b:6f14 with SMTP id a8-20020ac85b88000000b00305340b6f14mr2495933qta.344.1656510705506; Wed, 29 Jun 2022 06:51:45 -0700 (PDT) Received: from nuc (198-84-189-58.cpe.teksavvy.com. [198.84.189.58]) by smtp.gmail.com with ESMTPSA id bm9-20020a05620a198900b006a73ad95d40sm13018434qkb.55.2022.06.29.06.51.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 06:51:44 -0700 (PDT) Date: Wed, 29 Jun 2022 09:51:42 -0400 From: Mark Johnston To: Jake Freeland Cc: freebsd-hackers@freebsd.org Subject: Re: LinuxKPI debugfs Port Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4LY2vC30mvz4bST X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=OlFRrQp3; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::f30 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-0.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.71)[0.709]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Jun 28, 2022 at 05:11:49PM -0500, Jake Freeland wrote: > Mark, > > Your reply clears up a lot. I just forked drm-kmod, applied your Makefile > patch, and added DEBUGFS to kconfig.mk. I am extremely excited to be > back on track, especially now that I know how to proceed. > > Just to clarify, my job is to extend the current debugfs implementation > (debugfs.h and lindebugfs.c) to include the missing functionality required > for i915kms to compile and run successfully? I would ask manu@, but > he has not responded to me in weeks. I think so, yes. That's the shortest path to getting i915's debugfs files available for consumption by the test suite. > I greatly appreciate your explanations about LinuxKPI and lindebugfs. > Extensive documentation is what draws me to FreeBSD, but I struggled > to find any information regarding lindebugfs or LinuxKPI. I plan to write > some of my own when I am done with this project to help others in my > position :). That'd be welcome. This area is definitely under-documented, though it can be difficult to write useful documentation targeting kernel developers. A man page for lindebugfs would be a great start, as would an introductory page for the linuxkpi. From nobody Wed Jun 29 18:27:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AD4F787CB64 for ; Wed, 29 Jun 2022 18:27:39 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LY91R0bhgz4Zlh for ; Wed, 29 Jun 2022 18:27:39 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qv1-xf33.google.com with SMTP id n15so26055056qvh.12 for ; Wed, 29 Jun 2022 11:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PkF5lQ/zQRVeZF1PnQhMN7b3bjPSEHJh83NEWz1U1dc=; b=DR6xLZF5ViHJAhFxk53T2lh5cu7oKEnlEgx8qm/teo2/IRpf3bT4xlxhAbhDMy2xuK Zwxo5dGHU2fKFvyBYzDCewXsP/mr2HErFnRloM35kgO0qbUu6TlNwhwK7hg9R5juZnyl rd5FGo0NAO8rgvl2bOuNP82TtuNKmEJ1aUESKTm1ucTZBPp0BjKnh1f2e9KK8nFQw63u +8hyrv9OJLEPCyc7HctKpT1katzoB6xiE/fGE8+umNNc8ccU+xDQeJHV0sInWVihfrZT LOCb0GWOmg5/1eo2okUhinZjD3HVicgO0EIj+6f7sJwbq9AVo6tzSTV/OwZjn6KxmEb0 jBjg== 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=PkF5lQ/zQRVeZF1PnQhMN7b3bjPSEHJh83NEWz1U1dc=; b=2GVFKfLKBiDrNfEy9NnoIFzR/T6OnVoy4mKT9K1X65cg1HM2vR99N2MOVTvZNnPFM9 bMG9wYdI4QPC/Jnz9w44aStvOFnfMEe8vDsJ8btAr+JKZrPLZ1y2sk/e9+U9ZgIzEzRE dnGubKVZDo1yQWN09HeNZW054b07JLxTrnRiIcL54CwOHH9Bu/EOsvIJ/yyKdvFhtG/E smeu6jIvcVNynR9Z4oXcPkwCYZqx86C0pIB6ksPSSJqKnTzi7Egk3H/dL9HRf9OfZinp 97x8AoM5R4CEmL/+Cpm0mQXqwI2bOa9l2DI3QYg3J3O2hUDVoDvlL80SyC1Znz/XarPa BRUg== X-Gm-Message-State: AJIora8P8+uFTVEcCcvIMahPIB/BUbUnNczPA0w8ZI1sey/R/2MQyLI1 SKe/e7eaOVBQVfjqLVNxNqx3q/bLevNQ9JSggwgoXA== X-Google-Smtp-Source: AGRyM1sNFbmXewdvaZk30GnUlmJF1gSiuP/mvopVl2vNZZ6QJvSEBfhxGjJ+QQDKfjNzR9az/B79cRcf7gHauIpmLrw= X-Received: by 2002:a05:622a:180b:b0:31a:dd36:3c16 with SMTP id t11-20020a05622a180b00b0031add363c16mr3907645qtc.236.1656527251754; Wed, 29 Jun 2022 11:27:31 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Wed, 29 Jun 2022 13:27:21 -0500 Message-ID: Subject: Re: LinuxKPI debugfs Port To: Mark Johnston Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000066e56b05e29a4eb5" X-Rspamd-Queue-Id: 4LY91R0bhgz4Zlh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=DR6xLZF5; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::f33) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[jake]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[technologyfriends.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f33:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --00000000000066e56b05e29a4eb5 Content-Type: text/plain; charset="UTF-8" Mark, I was able to get Manu's attention and schedule a meeting with him to discuss this. I just finished and he was able to confirm that you're pointing me in the right direction. I greatly appreciate your guidance and help. I plan to finish this project and hopefully have enough knowledge, with the help of peers, to write informative LinuxKPI and lindebugfs man pages. Thank you again, Jake Freeland On Wed, Jun 29, 2022 at 8:51 AM Mark Johnston wrote: > On Tue, Jun 28, 2022 at 05:11:49PM -0500, Jake Freeland wrote: > > Mark, > > > > Your reply clears up a lot. I just forked drm-kmod, applied your Makefile > > patch, and added DEBUGFS to kconfig.mk. I am extremely excited to be > > back on track, especially now that I know how to proceed. > > > > Just to clarify, my job is to extend the current debugfs implementation > > (debugfs.h and lindebugfs.c) to include the missing functionality > required > > for i915kms to compile and run successfully? I would ask manu@, but > > he has not responded to me in weeks. > > I think so, yes. That's the shortest path to getting i915's debugfs > files available for consumption by the test suite. > > > I greatly appreciate your explanations about LinuxKPI and lindebugfs. > > Extensive documentation is what draws me to FreeBSD, but I struggled > > to find any information regarding lindebugfs or LinuxKPI. I plan to write > > some of my own when I am done with this project to help others in my > > position :). > > That'd be welcome. This area is definitely under-documented, though it > can be difficult to write useful documentation targeting kernel > developers. A man page for lindebugfs would be a great start, as would > an introductory page for the linuxkpi. > --00000000000066e56b05e29a4eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark,

I was able to get Manu's atte= ntion and schedule a meeting with
him to discuss=C2=A0this. I jus= t finished and he was able to confirm that
you're pointing=C2= =A0me in the right direction. I greatly appreciate your
guidance = and help.

I plan to finish this project and hopefu= lly=C2=A0have enough knowledge,
with the help of peers, to write = informative LinuxKPI and lindebugfs
man pages.

Thank you again,
Jake Freeland

On Wed, Jun 29, 2022= at 8:51 AM Mark Johnston <markj@fr= eebsd.org> wrote:
On Tue, Jun 28, 2022 at 05:11:49PM -0500, Jake Freeland wrote: > Mark,
>
> Your reply clears up a lot. I just forked drm-kmod, applied your Makef= ile
> patch, and added DEBUGFS to kconfig.mk. I am extremely excited to be
> back on track, especially now that I know how to proceed.
>
> Just to clarify, my job is to extend the current debugfs implementatio= n
> (debugfs.h and lindebugfs.c) to include the missing functionality requ= ired
> for i915kms to compile and run successfully? I would ask manu@, but > he has not responded to me in weeks.

I think so, yes.=C2=A0 That's the shortest path to getting i915's d= ebugfs
files available for consumption by the test suite.

> I greatly appreciate your explanations about LinuxKPI and lindebugfs.<= br> > Extensive documentation is what draws me to FreeBSD, but I struggled > to find any information regarding lindebugfs or LinuxKPI. I plan to wr= ite
> some of my own when I am done with this project to help others in my > position :).

That'd be welcome.=C2=A0 This area is definitely under-documented, thou= gh it
can be difficult to write useful documentation targeting kernel
developers.=C2=A0 A man page for lindebugfs would be a great start, as woul= d
an introductory page for the linuxkpi.
--00000000000066e56b05e29a4eb5-- From nobody Fri Jul 1 16:02:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D28DC8AF88B for ; Fri, 1 Jul 2022 16:02:41 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LZKjD6dQqz4ssK for ; Fri, 1 Jul 2022 16:02:40 +0000 (UTC) (envelope-from joh.hendriks@gmail.com) Received: by mail-wm1-x32e.google.com with SMTP id h14-20020a1ccc0e000000b0039eff745c53so1822043wmb.5 for ; Fri, 01 Jul 2022 09:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject:content-transfer-encoding; bh=2oNRRDRyijtHPLp82mojk0isz8JFZNfq/zKQ45+k/30=; b=JEgzjo34jB//764n57kmOf3xMnbMvoQDKPR9YlxcrmI0OX7juKJTO1ry1cXfm48eBm AQkvfKdlgW+vKVVwyQdWceSrqPKn+TeNdlRBZxlbPQSlzJJOiIz15W6PnnBMnQKh1xVP GeUKtlKwBuWeJYZL4jg2J34MYiuF1vqlrjWI7oxaZ8qcfJRiy+QcXngOPKVF77sJrS+R sxnJtkFHR8y/yjS5xvBGv3+jb2U8qWfNz5hTmNLH1s+5gkztpsveyuKi/EkE2mUCnfV4 YxjNoyt5/wBYqVoSCZVAM/GtKNir5PIYbh1Giv/BsW/C0rb+x37Js9jBmPKks2vcUuty SXpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=2oNRRDRyijtHPLp82mojk0isz8JFZNfq/zKQ45+k/30=; b=XxM0bHpVw1csPLY1KxehQ8geU//n9QMETbFY8xnnuMHfA40eHvVHUTqFfqcejcE71Q NtGJ1726ZGQTR/WbhD9k0Tq4fOgWFYlsGev7smzAKa37S8lL/CrKcsZM+nwPKCg8WY/L 6FBHV/B9FjRzGnx8Y23/NQaN16pPcS6xUjoGb15SBiP8Xh5an+iLdZMZ7LzMB12xIN4w pimt6eFBv3dFAEihFZg+6FwJWjUy2OwaSTbGBkbhjWUNntQzPAJzzK+b01vskFk9oIqk kd01N06r+AHuFbjvXqo/8R4eVhLGpkEvXGjMe0M00ajROgz3PFZjO8j5yGevmF+/+xbF nFWw== X-Gm-Message-State: AJIora+M9+TB9yscqueyZk4vSDWIKlt0+L7DcCccN80epR104hnjR49L JthOSRKKHEt/36oGPCGWduao65w/c9g= X-Google-Smtp-Source: AGRyM1vx767dBLcxUNQxv6nCVMiI9Bc/JFPZgTRQMvx3wT+aNAGiMaTU7h+BEYRLmd31PznPR/bgPg== X-Received: by 2002:a05:600c:21c3:b0:3a0:3aad:7f30 with SMTP id x3-20020a05600c21c300b003a03aad7f30mr19508561wmj.190.1656691354051; Fri, 01 Jul 2022 09:02:34 -0700 (PDT) Received: from [192.168.1.17] (85-147-130-226.cable.dynamic.v4.ziggo.nl. [85.147.130.226]) by smtp.gmail.com with ESMTPSA id e3-20020adfef03000000b0021bbd525b8esm23129295wro.45.2022.07.01.09.02.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jul 2022 09:02:33 -0700 (PDT) Message-ID: <9fdf5603-2468-eeb5-5549-9f8ab35de98e@gmail.com> Date: Fri, 1 Jul 2022 18:02:32 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0 Content-Language: en-US To: freebsd-hackers@freebsd.org From: Johan Hendriks Subject: OptionalObsoleteFiles.inc updates Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LZKjD6dQqz4ssK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=JEgzjo34; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johhendriks@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=johhendriks@gmail.com X-Spamd-Result: default: False [-1.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.030]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.43)[0.433]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N When running make-delete-old on 14-Current i noticed the following: [ /usr/src ] > make delete-old >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories rmdir: /usr/share/sendmail/cf/feature: Directory not empty rmdir: /usr/share/sendmail/cf: Directory not empty rmdir: /usr/share/sendmail: Directory not empty >>> Old directories removed If we do a list of that directory we still see some files. [ /usr/src ] > ls -al /usr/share/sendmail/cf/feature total 23 drwxr-xr-x  2 root  wheel    5 May 31 10:30 ./ drwxr-xr-x  3 root  wheel    3 May 31 10:30 ../ -r--r--r--  1 root  wheel  510 May  5 12:50 blocklist_recipients.m4 -r--r--r--  1 root  wheel  424 May  5 12:50 check_cert_altnames.m4 -r--r--r--  1 root  wheel  395 May  5 12:50 tls_failures.m4 I did see an old bug report that already noticed this and some other files. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254144 Can this file be patched? regards Johan Hendriks From nobody Wed Jul 6 08:16:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 692B31CFF90F for ; Wed, 6 Jul 2022 08:16:48 +0000 (UTC) (envelope-from tdtemccna@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LdC7M51wXz4k0c for ; Wed, 6 Jul 2022 08:16:47 +0000 (UTC) (envelope-from tdtemccna@gmail.com) Received: by mail-lf1-x12a.google.com with SMTP id d12so1258552lfq.12 for ; Wed, 06 Jul 2022 01:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=; b=aMFpVl9/C8/aa4XSXN/bFiJ6xdfwNUqyzn7/wOI/8acdbL/YYbkkP3z3qBHADzd2Hm hj/SqLcgfHcuTVFbG8O4ZXRyETKcXkisTVBo+gqBGAvsQo7bXcgwv+S66T/C2SM4mRBH TQqaRbipvIjfa0EB44Hsoq+/d/ZTog83PM91Wc8MF1dfW5Gr/UuHgT09dZ9rhpMu4/mn wSiHceEZB0pze1kKEAtItPeTLSensnjimFsu+5+l6w4uYcwm+GlNv5cWIqHjr3zxzgi5 TDJGFzNSfDJFfgMtHGVtnF3Ms3VX5renzyKYblShLXFEsBcoRCLX5I6+A2Xo8hUBdZGq yHVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qNJS8bXJjIJEOjJk4e4xeTOXLNTgbklFiRogoFnIe/0=; b=fu7snBodVGozu8mOwYX61irVIp0tqI3Ey35rzLXvFDY9Y0g9P11Bsw0RQZNLW1fW2s ZJTPYbGO97XqMbuzpQo4H+MMUg1uGWUIZbvm+NyDQyZIabv1KiY2cKyE/CDJpWCprdTk Q7TYGYm3fpyRmv++kVd0aucP6a1bqEvAgXQlH5jy5CaTDaR5FOjcmCKdLpYIzXw1C2qR UG5JZFn0N8xBiJvvfWH56I4WGmWxcGQ6nJ2c4qoPodWj7VET4CxKtqF04UtcL/5Ooxa/ wQF9PgPQf5P2WfRXm7Bv9JNr32+yvKIPInHrP3yfMGPq7NPfZ57kv9R2ILmdwvinL5/Q 8JUQ== X-Gm-Message-State: AJIora8yq6STLHH8hy3pLv32bse16f2+xyYIsPMCPcHXb2oiaefqokw+ ztPVuJ22t/XFKnZXscGRfXnj39hIxJpFtErecIhqsiiuqT8z9w== X-Google-Smtp-Source: AGRyM1vOTqfqh+2EV33bM+4PMyxnWRnYYQnvzlMeemSZWVE5AAYJXBEdQRmkX1at2Nkenw0bcra7iYgq5Mf4dm2mGzA= X-Received: by 2002:a05:6512:1590:b0:47f:6e14:a782 with SMTP id bp16-20020a056512159000b0047f6e14a782mr25450379lfb.131.1657095406351; Wed, 06 Jul 2022 01:16:46 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Turritopsis Dohrnii Teo En Ming Date: Wed, 6 Jul 2022 16:16:35 +0800 Message-ID: Subject: FreeBSD is a great operating system! To: freebsd-hackers@freebsd.org Cc: ceo@teo-en-ming-corp.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LdC7M51wXz4k0c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="aMFpVl9/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of tdtemccna@gmail.com designates 2a00:1450:4864:20::12a as permitted sender) smtp.mailfrom=tdtemccna@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SUBJECT_ENDS_EXCLAIM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12a:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Subject: FreeBSD is a great operating system! Good day from Singapore, I think FreeBSD is a great operating system! I support FreeBSD because the most popular pfSense firewall, the extremely popular OPNsense firewall and the BSD Router Project are all powered by FreeBSD! macOS is also based on FreeBSD! I use pfSense community edition firewall in my home. I am planning to try out OPNsense firewall next. I will continue to support FreeBSD! It is a great operating system! FreeBSD is a very good network operating system. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore 6 July 2022 Wed Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com From nobody Thu Jul 7 15:25:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C8A878D711A for ; Thu, 7 Jul 2022 15:25:18 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LT2z3CP2 for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KH-82 for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000Mxy-EK for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 2241F4801C0 for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5WTVeDD0034b for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BEC2A4801CA for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6UXX3L1vwF_X for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 9EDD94801BD for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 2/6] pps: Simplify capture and event processing Date: Thu, 7 Jul 2022 17:25:02 +0200 Message-Id: <20220707152506.55626-3-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LT2z3CP2 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Use local variables for the captured timehand and timecounter in pps_even= t(). This fixes a potential issue in the nsec preparation for hardpps(). Here= the timecounter was accessed through the captured timehand after the generati= on was checked. Make a snapshot of the relevent timehand values early in pps_event(). Ch= eck the timehand generation only once during the capture and event processing= . Use atomic_thread_fence_acq() similar to the other readers. --- sys/kern/kern_tc.c | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 20520adc0aba..b466fd4399e4 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1772,14 +1772,14 @@ pps_capture(struct pps_state *pps) #endif tc =3D th->th_counter; pps->capcount =3D tc->tc_get_timecount(tc); - atomic_thread_fence_acq(); - if (pps->capgen !=3D th->th_generation) - pps->capgen =3D 0; } =20 void pps_event(struct pps_state *pps, int event) { + struct timehands *capth; + struct timecounter *captc; + uint64_t capth_scale; struct bintime bt; struct timespec ts, *tsp, *osp; u_int tcount, *pcount; @@ -1798,9 +1798,17 @@ pps_event(struct pps_state *pps, int event) /* Nothing to do if not currently set to capture this event type. */ if ((event & pps->ppsparam.mode) =3D=3D 0) return; + + /* Make a snapshot of the captured timehand */ + capth =3D pps->capth; + captc =3D capth->th_counter; + capth_scale =3D capth->th_scale; + tcount =3D capth->th_offset_count; + bt =3D capth->th_bintime; + /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen =3D=3D 0 || pps->capgen !=3D - atomic_load_acq_int(&pps->capth->th_generation)) + atomic_thread_fence_acq(); + if (pps->capgen =3D=3D 0 || pps->capgen !=3D capth->th_generation) return; =20 /* Things would be easier with arrays. */ @@ -1838,25 +1846,19 @@ pps_event(struct pps_state *pps, int event) * If the timecounter changed, we cannot compare the count values, so * we have to drop the rest of the PPS-stuff until the next event. */ - if (pps->ppstc !=3D pps->capth->th_counter) { - pps->ppstc =3D pps->capth->th_counter; + if (__predict_false(pps->ppstc !=3D captc)) { + pps->ppstc =3D captc; *pcount =3D pps->capcount; pps->ppscount[2] =3D pps->capcount; return; } =20 /* Convert the count to a timespec. */ - tcount =3D pps->capcount - pps->capth->th_offset_count; - tcount &=3D pps->capth->th_counter->tc_counter_mask; - bt =3D pps->capth->th_bintime; - bintime_addx(&bt, pps->capth->th_scale * tcount); + tcount =3D pps->capcount - tcount; + tcount &=3D captc->tc_counter_mask; + bintime_addx(&bt, capth_scale * tcount); bintime2timespec(&bt, &ts); =20 - /* If the timecounter was wound up underneath us, bail out. */ - atomic_thread_fence_acq(); - if (pps->capgen !=3D pps->capth->th_generation) - return; - *pcount =3D pps->capcount; (*pseq)++; *tsp =3D ts; @@ -1890,9 +1892,9 @@ pps_event(struct pps_state *pps, int event) */ tcount =3D pps->capcount - pps->ppscount[2]; pps->ppscount[2] =3D pps->capcount; - tcount &=3D pps->capth->th_counter->tc_counter_mask; + tcount &=3D captc->tc_counter_mask; scale =3D (uint64_t)1 << 63; - scale /=3D pps->capth->th_counter->tc_frequency; + scale /=3D captc->tc_frequency; scale *=3D 2; bt.sec =3D 0; bt.frac =3D 0; --=20 2.35.3 From nobody Thu Jul 7 15:25:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F19D38D6FB7 for ; Thu, 7 Jul 2022 15:25:18 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LMlz3CLW for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KJ-8X for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000MyK-Ek for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 28FBE4800B5 for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id r548xX19EacF for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id D3CDB4801BD for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zJ-DRQ-bZDpW for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id B30DA4801C2 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 4/6] pps: Directly assign the timestamps in pps_event() Date: Thu, 7 Jul 2022 17:25:04 +0200 Message-Id: <20220707152506.55626-5-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LMlz3CLW X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --- sys/kern/kern_tc.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index b625726123af..be564e4347f8 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1860,8 +1860,7 @@ pps_event(struct pps_state *pps, int event) tcount =3D pps->capcount - tcount; tcount &=3D captc->tc_counter_mask; bintime_addx(&bt, capth_scale * tcount); - bintime2timespec(&bt, &ts); - *tsp =3D ts; + bintime2timespec(&bt, tsp); =20 if (foff) { timespecadd(tsp, osp, tsp); @@ -1876,9 +1875,8 @@ pps_event(struct pps_state *pps, int event) bt =3D pps->capffth->tick_time; ffclock_convert_delta(tcount, pps->capffth->cest.period, &bt); bintime_add(&bt, &pps->capffth->tick_time); - bintime2timespec(&bt, &ts); (*pseq_ffc)++; - *tsp_ffc =3D ts; + bintime2timespec(&bt, tsp_ffc); #endif =20 #ifdef PPS_SYNC --=20 2.35.3 From nobody Thu Jul 7 15:25:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F11BB8D70A3 for ; Thu, 7 Jul 2022 15:25:18 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LVKz3CRJ for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KF-67 for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000MxX-Ck for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0D43E4800C5 for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XRNoq7SskLtg for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BB1E24801C8 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cPFCQkFzoT8T for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 8FE884800B5 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 0/6] Simplify pps_capture() and pps_event() Date: Thu, 7 Jul 2022 17:25:00 +0200 Message-Id: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LVKz3CRJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This patch set tries to simplify the pps_capture() and pps_event() proces= sing. I am not sure if the rounding change is an improvement. Sebastian Huber (6): pps: Load timecounter once in pps_capture() pps: Simplify capture and event processing pps: Move pcount assignment in pps_event() pps: Directly assign the timestamps in pps_event() pps: Simplify the nsec calculation in pps_event() pps: Round to closest integer in pps_event() sys/kern/kern_tc.c | 72 +++++++++++++++++++++++----------------------- 1 file changed, 36 insertions(+), 36 deletions(-) --=20 2.35.3 From nobody Thu Jul 7 15:25:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 03BD58D6D40 for ; Thu, 7 Jul 2022 15:25:19 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LRZz3CJ5 for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KI-8F for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000MyI-EX for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 24A334801C3 for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YsK0HWSdFh9G for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id D295C4800B5 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2Bp2D5ThLlLD for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id A35A74801C0 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 3/6] pps: Move pcount assignment in pps_event() Date: Thu, 7 Jul 2022 17:25:03 +0200 Message-Id: <20220707152506.55626-4-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LRZz3CJ5 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.985]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Move the pseq increment. This makes it possible to reuse registers earli= er. --- sys/kern/kern_tc.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index b466fd4399e4..b625726123af 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1842,25 +1842,25 @@ pps_event(struct pps_state *pps, int event) #endif } =20 + *pcount =3D pps->capcount; + /* * If the timecounter changed, we cannot compare the count values, so * we have to drop the rest of the PPS-stuff until the next event. */ if (__predict_false(pps->ppstc !=3D captc)) { pps->ppstc =3D captc; - *pcount =3D pps->capcount; pps->ppscount[2] =3D pps->capcount; return; } =20 + (*pseq)++; + /* Convert the count to a timespec. */ tcount =3D pps->capcount - tcount; tcount &=3D captc->tc_counter_mask; bintime_addx(&bt, capth_scale * tcount); bintime2timespec(&bt, &ts); - - *pcount =3D pps->capcount; - (*pseq)++; *tsp =3D ts; =20 if (foff) { --=20 2.35.3 From nobody Thu Jul 7 15:25:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A0B78D6E7D for ; Thu, 7 Jul 2022 15:25:19 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LKkz3CJ4 for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KV-GW for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000N0U-MX for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4F77D4801BD for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HZCT2235HJkJ for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0ED944801CC for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id P-JXCvtyttTq for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id D4AF84801C3 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 6/6] pps: Round to closest integer in pps_event() Date: Thu, 7 Jul 2022 17:25:06 +0200 Message-Id: <20220707152506.55626-7-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LKkz3CJ4 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The comment above bintime2timespec() says: When converting between timestamps on parallel timescales of differing resolutions it is historical and scientific practice to round down. However, the nsec value is a time difference and not a timestamp. So, ro= unding to the closest integer is probably slightly better. --- sys/kern/kern_tc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index f29dd9b8e7f2..8db5911a4c0e 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1882,6 +1882,7 @@ pps_event(struct pps_state *pps, int event) #ifdef PPS_SYNC if (fhard) { uint64_t nsec; + uint64_t freq; =20 /* * Feed the NTP PLL/FLL. @@ -1893,7 +1894,8 @@ pps_event(struct pps_state *pps, int event) tcount &=3D captc->tc_counter_mask; nsec =3D 1000000000; nsec *=3D tcount; - nsec /=3D captc->tc_frequency; + freq =3D captc->tc_frequency; + nsec =3D (nesc + freq / 2) / freq; hardpps(tsp, (long)nsec); } #endif --=20 2.35.3 From nobody Thu Jul 7 15:25:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A0268D7208 for ; Thu, 7 Jul 2022 15:25:19 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bK4LMGz3CP1 for ; Thu, 7 Jul 2022 15:25:17 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNN-0008KG-6u for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNN-000Mxg-DL for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:09 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1563A4801CD for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cTCNlpqPyFQD for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BD4364801C9 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BqXysfgfZatA for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 9C9274800C5 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 1/6] pps: Load timecounter once in pps_capture() Date: Thu, 7 Jul 2022 17:25:01 +0200 Message-Id: <20220707152506.55626-2-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bK4LMGz3CP1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.21 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This ensures that the timecounter and the tc_get_timecount handler belong together. --- sys/kern/kern_tc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 37287df4d1fd..20520adc0aba 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1761,6 +1761,7 @@ void pps_capture(struct pps_state *pps) { struct timehands *th; + struct timecounter *tc; =20 KASSERT(pps !=3D NULL, ("NULL pps pointer in pps_capture")); th =3D timehands; @@ -1769,7 +1770,8 @@ pps_capture(struct pps_state *pps) #ifdef FFCLOCK pps->capffth =3D fftimehands; #endif - pps->capcount =3D th->th_counter->tc_get_timecount(th->th_counter); + tc =3D th->th_counter; + pps->capcount =3D tc->tc_get_timecount(tc); atomic_thread_fence_acq(); if (pps->capgen !=3D th->th_generation) pps->capgen =3D 0; --=20 2.35.3 From nobody Thu Jul 7 15:25:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A807D8D70F2 for ; Thu, 7 Jul 2022 15:25:22 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf0bP4lMHz3CXc for ; Thu, 7 Jul 2022 15:25:21 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9TNS-0008Kj-GS for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:14 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9TNS-000N0j-Mw for freebsd-hackers@freebsd.org; Thu, 07 Jul 2022 17:25:14 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 504F24801C2 for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nzhFTK2-WVml for ; Thu, 7 Jul 2022 17:25:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id E430F4801C4 for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BqURyWN2xxgt for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) Received: from zimbra.eb.localhost (unknown [192.168.96.242]) by mail.embedded-brains.de (Postfix) with ESMTPSA id C0E444801CC for ; Thu, 7 Jul 2022 17:25:08 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Subject: [PATCH 5/6] pps: Simplify the nsec calculation in pps_event() Date: Thu, 7 Jul 2022 17:25:05 +0200 Message-Id: <20220707152506.55626-6-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4Lf0bP4lMHz3CXc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [0.25 / 15.00]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.947]; R_MISSING_CHARSET(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148:c]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; MLMMJ_DEST(0.00)[freebsd-hackers]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[embedded-brains.de]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --- sys/kern/kern_tc.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index be564e4347f8..f29dd9b8e7f2 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1781,7 +1781,7 @@ pps_event(struct pps_state *pps, int event) struct timecounter *captc; uint64_t capth_scale; struct bintime bt; - struct timespec ts, *tsp, *osp; + struct timespec *tsp, *osp; u_int tcount, *pcount; int foff; pps_seq_t *pseq; @@ -1881,7 +1881,7 @@ pps_event(struct pps_state *pps, int event) =20 #ifdef PPS_SYNC if (fhard) { - uint64_t scale; + uint64_t nsec; =20 /* * Feed the NTP PLL/FLL. @@ -1891,14 +1891,10 @@ pps_event(struct pps_state *pps, int event) tcount =3D pps->capcount - pps->ppscount[2]; pps->ppscount[2] =3D pps->capcount; tcount &=3D captc->tc_counter_mask; - scale =3D (uint64_t)1 << 63; - scale /=3D captc->tc_frequency; - scale *=3D 2; - bt.sec =3D 0; - bt.frac =3D 0; - bintime_addx(&bt, scale * tcount); - bintime2timespec(&bt, &ts); - hardpps(tsp, ts.tv_nsec + 1000000000 * ts.tv_sec); + nsec =3D 1000000000; + nsec *=3D tcount; + nsec /=3D captc->tc_frequency; + hardpps(tsp, (long)nsec); } #endif =20 --=20 2.35.3 From nobody Thu Jul 7 15:52:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8FB9912D1A31 for ; Thu, 7 Jul 2022 15:53:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lf1CW3Txfz3QBS for ; Thu, 7 Jul 2022 15:53:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2c.google.com with SMTP id j63so3547372vkj.8 for ; Thu, 07 Jul 2022 08:53:11 -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=tNPsYj5S4OMxEZsQhZiEoNLgQ/fu6/rBU0/gwQRYF5c=; b=fAabS88pMbriF9fWeMkjxJf+72TibDwbxaEDKLh8KoDUbOM2BveLa/gpF23vmjQBW1 inF1NNrCUZf8tw2uMFxg4wnMDYHf+f2lCORdHJGjVB2xxxLTtw+RZNeob7DTEBjBAU5G q+jCNJGhwQvzCJ3STE5/5d9SSxqGsOM+u2jSvSCGrT98wbIQ9vPcuAQvyPtEweU4Y2zJ THo1uKA6lyZ2EOArW2PmQZIjFSdXTiAR2+u9mEwFpOCq5/4t3+i+06jh5rZ/RkxlTP9A Xa7W+s3/F/IaaE+4BOUjcSWO8Apfr2NwmFVMYfb6PVUeQMYN7YgBtU+iNzjE83fPsVzB g8kg== 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=tNPsYj5S4OMxEZsQhZiEoNLgQ/fu6/rBU0/gwQRYF5c=; b=eQB1m/QEi+ggCzYjaJ1G6aqR29V4nEHySbZwVGoHU4Kf38hu2B50dVC6+i+eoowAOy peABRqzWJQwOG792Acm5IHdZ57bxHNhgQrSOZHohLeMfE3KYnQRI6Bl+gxzQ6lScW5MQ aBfu03A7IWZ+B+QEUQ0OP3pbpVScf5TnuylvwQzeZHIDe/TfISCr8j0uIN49lZB2fd3j lLfiXEcs/kVuRBxpXKHQEf4D+IPseKsvSIuvJ+k9eohS7Uy1Bc+aGRvKGw5AV5f7012F Tsogm/WMwYEJhypw3ikxNC+hb0F9bLyIALBVKdNHToM1YR7UY6eeJjgNeWbbj9ETdqgO X/jA== X-Gm-Message-State: AJIora/YgiQ/W/bNZATL487QeF39jotXcj2nAvlgYWYH2hm7+qkdJVL4 vrT8V21qhCzAqqt5x/98tn5R6x6EGlD/jlsyOy10aQ== X-Google-Smtp-Source: AGRyM1vD/lRBQ7m+xvJrNsNycYI4qgIcDllx3sdcAa8qXC49z8BDK911EiPo/ya24Fu9535tCdGfZGeI4tGErF3DLCo= X-Received: by 2002:a1f:1bc8:0:b0:36c:a88c:961a with SMTP id b191-20020a1f1bc8000000b0036ca88c961amr26714765vkb.2.1657209180775; Thu, 07 Jul 2022 08:53:00 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> In-Reply-To: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> From: Warner Losh Date: Thu, 7 Jul 2022 09:52:49 -0600 Message-ID: Subject: Re: [PATCH 0/6] Simplify pps_capture() and pps_event() To: Sebastian Huber Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000008c0a1005e33914e9" X-Rspamd-Queue-Id: 4Lf1CW3Txfz3QBS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=fAabS88p; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-0.92 / 15.00]; NEURAL_HAM_SHORT(-0.92)[-0.919]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000008c0a1005e33914e9 Content-Type: text/plain; charset="UTF-8" You might have better luck getting these patches reviewed with either a pull request against github mentioning the usual time people (phk, etc), or as a series of phabricator reviews adding said people. If unsure, mention/add me and I'll add others :). Hackers is (or has been) a high enough volume list that this may not be noticed by those people, especially since there's not a strong tradition of reviewing patches here. On their surface (without having had time to study them in depth), these seem reasonable improvements. But having some context about why you are making these, and/or measurements you've done to show no harm (or hopefully an improvement) would be even better. This is slightly tricky code that has had about 20 years of "soak time" in some fairly demanding environments, and so some caution is advised in updating it. Warner On Thu, Jul 7, 2022 at 9:27 AM Sebastian Huber < sebastian.huber@embedded-brains.de> wrote: > This patch set tries to simplify the pps_capture() and pps_event() > processing. > I am not sure if the rounding change is an improvement. > > Sebastian Huber (6): > pps: Load timecounter once in pps_capture() > pps: Simplify capture and event processing > pps: Move pcount assignment in pps_event() > pps: Directly assign the timestamps in pps_event() > pps: Simplify the nsec calculation in pps_event() > pps: Round to closest integer in pps_event() > > sys/kern/kern_tc.c | 72 +++++++++++++++++++++++----------------------- > 1 file changed, 36 insertions(+), 36 deletions(-) > > -- > 2.35.3 > > > --0000000000008c0a1005e33914e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You might have better luck getting these patches reviewed = with either a pull request against github
mentioning the usual time peo= ple (phk, etc), or as a series=C2=A0of phabricator reviews adding said peop= le.
If unsure, mention/add me and I'll add others :).

Hackers is (or has been) a high enough volume list that t= his may not be noticed by those people,
especially since there= 9;s not a strong tradition of reviewing patches here.

<= div>On their surface (without having had time to study them in depth), thes= e seem reasonable improvements.
But having some context about why= you are making these, and/or measurements you've done to show no
=
harm (or hopefully an improvement) would be even better. This is sligh= tly tricky code that has had about 20
years of "soak time&qu= ot; in some fairly demanding environments, and so some caution is advised i= n updating
it.

Warner

On Thu, Jul 7= , 2022 at 9:27 AM Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:
This patch set tries to = simplify the pps_capture() and pps_event() processing.
I am not sure if the rounding change is an improvement.

Sebastian Huber (6):
=C2=A0 pps: Load timecounter once in pps_capture()
=C2=A0 pps: Simplify capture and event processing
=C2=A0 pps: Move pcount assignment in pps_event()
=C2=A0 pps: Directly assign the timestamps in pps_event()
=C2=A0 pps: Simplify the nsec calculation in pps_event()
=C2=A0 pps: Round to closest integer in pps_event()

=C2=A0sys/kern/kern_tc.c | 72 +++++++++++++++++++++++----------------------= -
=C2=A01 file changed, 36 insertions(+), 36 deletions(-)

--
2.35.3


--0000000000008c0a1005e33914e9-- From nobody Fri Jul 8 06:45:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 04D0017D0756 for ; Fri, 8 Jul 2022 06:45:34 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LfP171Jvmz3gvV for ; Fri, 8 Jul 2022 06:45:31 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-ej1-f54.google.com with SMTP id sb34so36062479ejc.11 for ; Thu, 07 Jul 2022 23:45:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject:content-transfer-encoding; bh=v05Q5sffxePOl2O3TC2Y8qMgvIUgaxZqF0PEmYKAi7I=; b=rIP1gYpHbmx5PooQ72MhGMJfO13Ihmc3K7w9I6boq1LvDr4TR0N5Okkta8ZIopu9RS aOakMz6OsS7bBiJWrGdtm/i6JL8PiW1/GOaewCIszwsWcIxsBskvqeqnpl5ep/5Lohoy EXSo3f34mKPEdqJLlyn2CGWgOMRCLXTgXVnyBaVQGT/URsA4Sgm4IRg9gsCLCekrVL94 z1vbtCfAEP3bZF2/WdsVRepntFJlLShobRf4m31Zqr+w4y/JMFN2MU29nV7J6AqVcq5Q IryB2vnzZPofHqwvuRalav81Voq3g4VhYvqvc7vC/LwyIffaKyTQl1XIixULW9d/B4qY sUog== X-Gm-Message-State: AJIora+svPQ5gh8cAXkriihKr/Drfu72Q8qwYJL3DEFb9njVlS1SS9hU XUgz1uSTjlgdWALb0P+1L9koCl9biQbdjA== X-Google-Smtp-Source: AGRyM1s9Y5fB35vNlZyzUKIcjD0blPnRSRba8HFLTbyrBDK0ZyiusFsbBuFgyafxk0IeVEQWShjiyw== X-Received: by 2002:a17:907:3d8a:b0:726:396d:1848 with SMTP id he10-20020a1709073d8a00b00726396d1848mr1911680ejc.339.1657262729972; Thu, 07 Jul 2022 23:45:29 -0700 (PDT) Received: from ?IPV6:2a02:8109:8680:1304:5e5f:67ff:fef4:ffd8? ([2a02:8109:8680:1304:5e5f:67ff:fef4:ffd8]) by smtp.gmail.com with ESMTPSA id h16-20020a056402095000b0043a56c0ededsm10798591edz.74.2022.07.07.23.45.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 23:45:29 -0700 (PDT) Message-ID: <738cc926-798d-78d8-1f8c-4d99f4395346@FreeBSD.org> Date: Fri, 8 Jul 2022 08:45:30 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: FreeBSD Hackers From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: Patch: rc(8) testing framework Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LfP171Jvmz3gvV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mpp302@gmail.com designates 209.85.218.54 as permitted sender) smtp.mailfrom=mpp302@gmail.com X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[0mp@FreeBSD.org,mpp302@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.54:from]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.54:from]; ARC_NA(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; BLOCKLISTDE_FAIL(0.00)[2a02:8109:8680:1304:5e5f:67ff:fef4:ffd8:server fail,209.85.218.54:server fail]; FROM_NEQ_ENVFROM(0.00)[0mp@FreeBSD.org,mpp302@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Hackers, I've posted a patch adding initial tests for the rc(8) framework. Currently, it covers the _oomprotect behavior. https://reviews.freebsd.org/D35745 Reviews welcome. Best, Mateusz From nobody Fri Jul 8 06:58:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EDB8F17D35A4 for ; Fri, 8 Jul 2022 06:58:34 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LfPJ957Qcz3jyg for ; Fri, 8 Jul 2022 06:58:33 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy01.your-server.de ([78.46.139.224]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1o9hwb-000Mw9-Tx; Fri, 08 Jul 2022 08:58:30 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1o9hwc-000Dyp-3N; Fri, 08 Jul 2022 08:58:30 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id C1203480040; Fri, 8 Jul 2022 08:58:29 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id jNBA1lN3Tl0E; Fri, 8 Jul 2022 08:58:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 5CB3748016F; Fri, 8 Jul 2022 08:58:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 99_xpCVyinkB; Fri, 8 Jul 2022 08:58:29 +0200 (CEST) Received: from [192.168.96.159] (unknown [192.168.96.159]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 3B402480040; Fri, 8 Jul 2022 08:58:29 +0200 (CEST) Message-ID: <5efeedf3-51dc-e186-48a4-c3dd14b7712e@embedded-brains.de> Date: Fri, 8 Jul 2022 08:58:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 0/6] Simplify pps_capture() and pps_event() Content-Language: en-US To: Warner Losh Cc: FreeBSD Hackers References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26596/Thu Jul 7 09:53:54 2022) X-Rspamd-Queue-Id: 4LfPJ957Qcz3jyg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-1.40 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[78.46.139.224:received]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; R_DKIM_NA(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_X_AS(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 07.07.22 17:52, Warner Losh wrote: > You might have better luck getting these patches reviewed with either a= =20 > pull request against github > mentioning the usual time people (phk, etc), or as a series=C2=A0of=20 > phabricator reviews adding said people. > If unsure, mention/add me and I'll add others :). Thanks for the hint. I opened a Github pull request: https://github.com/freebsd/freebsd-src/pull/604 >=20 > Hackers is (or has been) a high enough volume list that this may not be= =20 > noticed by those people, > especially since there's not a strong tradition of reviewing patches he= re. >=20 > On their surface (without having had time to study them in depth), thes= e=20 > seem reasonable improvements. > But having some context about why you are making these, and/or=20 > measurements you've done to show no > harm (or hopefully an improvement) would be even better. This is=20 > slightly tricky code that has had about 20 > years of "soak time" in some fairly demanding environments, and so some= =20 > caution is advised in updating > it. I don't use FreeBSD directly. I use the FreeBSD timecounters in RTEMS.=20 We recently enabled the PPS_SYNC support and would like to use it for=20 the time synchronization on a spacecraft. For this we have to do a=20 specification and validation tests. This work increases with every "if"=20 in the code. I didn't test the patch on a real system so far (in fact,=20 patch 6 has a typo which was detected by the CI runner). We will=20 definitely do extensive testing when the hardware is available. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Fri Jul 8 15:37:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E0D9C17FBFA1 for ; Fri, 8 Jul 2022 15:37:27 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (kazi.fit.vutbr.cz [IPv6:2001:67c:1220:808::93e5:80c]) (using TLSv1.3 with cipher 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 "kazi.fit.vutbr.cz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lfcpt2mVmz3tnn for ; Fri, 8 Jul 2022 15:37:26 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (8.17.1.9/8.17.1) with ESMTPS id 268FbFxb029352 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Jul 2022 17:37:15 +0200 (CEST) (envelope-from cejkar@fit.vutbr.cz) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fit.vutbr.cz; s=mx1; t=1657294635; bh=nq37K0vOPG1IHq6yExto4Z32B0+uIRB+4wwjRIt5bco=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=wbH3d7emzO4UaNLQ0yFxhZnVX1BTWdXzSwaR/0vPHKEFCJAUPCGfNlObw2jlLfhdN CzrNinC+iDyjzs3cbV58g/DERp8eDD+Y98bS+m7cbGipLKIcgNUQt0bmK3+k1N1AY/ qSuTZ42GrAuVMrLByKCZeIokRI407i58UUfTErqw= Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.17.1.9/8.17.1/Submit) id 268FbAUM029347; Fri, 8 Jul 2022 17:37:10 +0200 (CEST) (envelope-from cejkar@fit.vutbr.cz) X-Authentication-Warning: kazi.fit.vutbr.cz: cejkar set sender to cejkar@fit.vutbr.cz using -f Date: Fri, 8 Jul 2022 17:37:10 +0200 From: Cejka Rudolf To: Warner Losh Cc: Emmanuel Vadot , FreeBSD Hackers Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Lfcpt2mVmz3tnn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fit.vutbr.cz header.s=mx1 header.b=wbH3d7em; dmarc=pass (policy=none) header.from=fit.vutbr.cz; spf=pass (mx1.freebsd.org: domain of cejkar@fit.vutbr.cz designates 2001:67c:1220:808::93e5:80c as permitted sender) smtp.mailfrom=cejkar@fit.vutbr.cz X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[fit.vutbr.cz,none]; R_SPF_ALLOW(-0.20)[+a:kazi.fit.vutbr.cz]; R_DKIM_ALLOW(-0.20)[fit.vutbr.cz:s=mx1]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[fit.vutbr.cz:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:197451, ipnet:2001:67c:1220::/46, country:CZ]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote (2022/06/23): > On Thu, Jun 23, 2022 at 1:44 AM Cejka Rudolf wrote: > > Hello, > > so is there any solution for problem below now? > > > > Cejka Rudolf wrote (2021/11/29): > > > Hello, > > > I have one problem or two with VT in FreeBSD 12. I wrote a question in > > > freebsd-stable what to do, but without response, so I still have to > > > use SC. Please, could you look at it? There is not configured device > > > /dev/console without monitor after upgrade from 11 to 12 and device > > > /dev/kbdmux0 is busy using VT but not with SC. > > > > > > Subject: Unable to grab keyboard with VT on a headless node in stable/12 > > > > > > Hello, > > > I have a headless node without monitor and without keyboard. There > > > is just network and USB card reader in keyboard mode. > > > > > > In stable/11, there was no problem to disconnect USB card reader > > > from kbdmux using kbdcontrol -A ukbd0 < /dev/console and open > > > /dev/ukbd0 in a program. > > > > > > However, under stable/12 it works just with connected monitor. > > > > > > Without monitor, there is an error: > > > > > > # kbdcontrol < /dev/console > > > -bash: /dev/console: Device not configured > > > > > > Furthermore with default VT, it is also impossible to use /dev/kbdmux0: > > > > > > # kbdcontrol < /dev/kbdmux0 > > > -bash: /dev/kbdmux0: Device busy > > > > > > I have found a workaround using SC, where it is possible to atleast > > > open /dev/kbdmux0 and use kbdcontrol -A ukbd0 < /dev/kbdmux0, but why > > > keyboard operation is now dependend on connected monitor? And why VT > > > does not allow to open /dev/kbdmux0? > > > > > > Thank you. > > > > Have you filed a bug for this? This looks like a legit bug and one that > should be easy(ish) to reproduce. Not yet, I'm still not sure, if it is a bug or a feature. > Or at least it looks that way on the surface, there might be a pilot error > as well that just happened to > work before and needs a slightly different workaround to what you are > doing... During getting answers to your questions I finally found a workaround - do not use /dev/console nor /dev/kbdmux0, but use /dev/ttyv0. With /dev/ttyv0 I can detach USB card reader: # usbconfig show_ifdrv ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.2.0: ukbd0: ugen0.2.1: uhid0: from kbdmux0 using kbdcontrol -A ukbd0 And it's an actual monitor connected that's the only difference? Yes. > Or is this some KVM switch that's connected, so there's an atkbd > in the mix somewhere? No, just direct cable connection between computer and monitor. > What's the difference in dmesg between > these two boots? Is this with EFI or legacy BIOS boot? > A dmesg with bootverbose would be most enligtening. It is EFI boot and it seems that the only interesting difference is that with connected monitor there is kernel: VT(efifb): resolution 1280x1024 while with disconnected monitor there is kernel: VT(vga): resolution 640x480 > 'Not conifgured' is ENXIO which is returned when /dev/console isn't there > (eg, no /dev/console), which seems weird in the extreme. And it's 'bash' > that's giving the message, which means kbdcontrol isn't even getting invoked. Ok, however there is question, what is the suggested device for kbdcontrol. I see just /dev/kbdmux0 or /dev/console in manual. SC with or without monitor, both are the same (I temporarily connected also one USB keyboard): # kbdcontrol -i And I'm also a little confused, detach ukbd0 from a usb card reader? That's > an interesting setup. While > it won't affect whether or not this is a bug, I'd be interested to know > more details there... Detach ukbd0 (= USB card reader) from kbdmux0, so USB card reader is usable as an inpout in a program. Without detach, characters from USB card reader are grabbed by kbdmux0. PC connected to the network with USB card reader works as a controller for Xerox printer for users authentication, when they want to make paid paper copies. -- Rudolf Cejka https://www.fit.vut.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 1/2, 612 00 Brno, Czech Republic From nobody Sat Jul 9 16:26:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4838A180857F for ; Sat, 9 Jul 2022 16:26:41 +0000 (UTC) (envelope-from marc@bumblingdork.com) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgFsD0n1Cz3cZ5 for ; Sat, 9 Jul 2022 16:26:40 +0000 (UTC) (envelope-from marc@bumblingdork.com) Received: by mail-ed1-x52b.google.com with SMTP id r18so1757157edb.9 for ; Sat, 09 Jul 2022 09:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bumblingdork.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=MAYyHjTBzXfRralR4w9DsIGAhxxDfHZqKq6sPTogICE=; b=ZMU/U4PUOujB7itVvI+09kRDMPeO0usL+LCdax93Yos2khe8gOktEBLE79wN8hqjbr oA6Zd+rEXIsuza6erKLyN1jfG7b4fcb4VPsi8ukWdnYT2nE3C5TQOmZd5WAlD4AtATUR Ayed0ObDAil9o+T/ZUR/OGnqKVcgLQ3S0dJGqhVvYXtjW28mzsRjy4t06p7sSsz7dP2D 6J/GgKl1R3PpAHlRXmyLwrDLaZimIe62WBh0bxsWESJzDtsdcmWHzNIQ8cLjJasFY52W qoRHewQtoYtGobW3U4LHMsPkfAKoYjmqYZOPFmBXBT294i+SpFZEPwaG9KG01fBBRpOG AeJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=MAYyHjTBzXfRralR4w9DsIGAhxxDfHZqKq6sPTogICE=; b=gcsuktlZ/yHFC/MWtW1YMVGV2BRcU2ari4TH5IfJaBQvqqWfNLfJ4ENL4hR6tQaRox 7dDzKqezqBRPb/AlxiWLPMRR+3Y/o2tCeiKla+EEj7QqjDGH2Kus8FkCZdolDNKo1vrz JRbIg5BYNmbJlH/sZJHPI9Fgd86AtZSxz4Gt2G1BLtbhVt7PQ26Z+o3uSRJ8uLacJlxD SAbxUO/jhr/LtOq1lYlBNFrNAnMxsxrJKifiSeMShQkPE3+l+PRicBJW/n96Tmwh2BnB PE/nJadD8F6YP3WrIF6LciLJ9eQX5zyWy0oUFpanORXh6fSh1qox6uyRbY/90/cIVNDE DaPg== X-Gm-Message-State: AJIora+nxOiJ1VTBCvocD38gUkDF287/7YS4yNqhDgrf1wGrEp8Js1Cx ect/ow8GXu8C0WWj4CqLMiCQCmqz0ITACA== X-Google-Smtp-Source: AGRyM1tLss3LdkZEQOelItQi9/9hN9uFtsdPq66XWgak5/IIbtsDtHfjsCo6IhgZ60Q/5bNFDGaxNg== X-Received: by 2002:a05:6402:4446:b0:43a:3f52:4172 with SMTP id o6-20020a056402444600b0043a3f524172mr12246923edb.417.1657383998445; Sat, 09 Jul 2022 09:26:38 -0700 (PDT) Received: from smtpclient.apple (2a02-a467-ec-1-7443-d497-4af2-1567.fixed6.kpn.net. [2a02:a467:ec:1:7443:d497:4af2:1567]) by smtp.gmail.com with ESMTPSA id s10-20020a1709064d8a00b0072b33e91f96sm729689eju.190.2022.07.09.09.26.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2022 09:26:38 -0700 (PDT) From: Marc Veldman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Canonical way / best practice for 128-bit integers Message-Id: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> Date: Sat, 9 Jul 2022 18:26:37 +0200 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LgFsD0n1Cz3cZ5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bumblingdork.com header.s=google header.b="ZMU/U4PU"; dmarc=pass (policy=none) header.from=bumblingdork.com; spf=pass (mx1.freebsd.org: domain of marc@bumblingdork.com designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=marc@bumblingdork.com X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[bumblingdork.com,none]; R_DKIM_ALLOW(-0.20)[bumblingdork.com:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[bumblingdork.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52b:from]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[marc]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I=E2=80=99m working on some bluetooth code, and that involves handling = 128-bit uuids. There are various ways to handle in the FreeBSD codebase, like in sdp.h: /* * SDP int128/uint128 parameter */ =20 struct int128 { int8_t b[16]; }; typedef struct int128 int128_t; typedef struct int128 uint128_t; and in sys/dev/random/uint128.h #ifdef USE_REAL_UINT128_T typedef __uint128_t uint128_t; #define UINT128_ZERO 0ULL #else typedef struct { /* Ignore endianness */ uint64_t u128t_word0; uint64_t u128t_word1; } uint128_t; static const uint128_t very_long_zero =3D {0UL,0UL}; #define UINT128_ZERO very_long_zero #endif Is there any recommended / standard way to handle 128 bit integers in a = portable way? Best regards, Marc Veldman= From nobody Sat Jul 9 16:56:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 468D0180F817 for ; Sat, 9 Jul 2022 16:55:08 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgGV33yBzz3jfW for ; Sat, 9 Jul 2022 16:55:07 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qk1-x730.google.com with SMTP id z7so1140606qko.8 for ; Sat, 09 Jul 2022 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=WyqGVv9+tD8/uyGJNvkzKjNu/rtXrPx7oUMQJ2F1V3o=; b=pWuVFYaHen706X10QGIZ46kejlkbjZhckBJmTPljuV/S2c0KwxkAavWWU75tdkniBi KzrnjzGouPpKOxkJiz+J1sDzoUghw6uxRE3qU7wCAX7icZWUWlIlPfnImocAfQOys3B/ B9X/4BAYkfFFUgzk65CfLtwcbCWSH9CJG0i2M15OiqT7L/wPqCowzwR4/4zTFYJZNFGU mQueOV7YQGvRMIIjiH0q2gVOrwARNdjF80uuHb01ohaXTAzL6J8a/zmmNmPdB0CTNO5K uoS+Pw+AJCYieqHWqMQ9/CVV++C/utK/0yW//LKTimB4wjFFh7V14B8OUCCXcoKup0VT HYuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=WyqGVv9+tD8/uyGJNvkzKjNu/rtXrPx7oUMQJ2F1V3o=; b=gyr92rid27OukHL3coX7e1Hlb/ZosXkCf1S45aYF6y/DPnZqSMm6N+dHMtj4l+8CBV 8sQb07Q0CulM5ZpYVsNgpBUo280LHeC4tkSoOGxmP7Ww/K2fYVD3DkmWz25h3z+BiiOB q98xavK/g3umQ0CDpe9OGn1fR9qTouNPZPU1BhWrJsyp+5PHYTFFLsoAVUxzoBX1gVS7 WnvaPihR3WunvQfS+NiCiNmvXF5QM6OkcvxCkw6P34EP8Ti3f4k60Yur4//O2fk11T2L onyayYcuGALa76nAi88hHx7RtacDnYphRwSCdXItdj/9PF7b5Dj3aGfPeOPmC2QIFGoF Y7sA== X-Gm-Message-State: AJIora/iUbQ9vBv5KsuzYN/FlrbhkGS8oTKoRr2q8vWF86xgtNBCr49O MCp1Lu0RiS9U9PkGwyzNsQfLUdbOb3A= X-Google-Smtp-Source: AGRyM1sUKrkliBUdQclV3c/bMXmweoeCmuIwE9AyBstlg4AvKXipCSAWYvhNiFYcKuun9O6YmiFTlg== X-Received: by 2002:a05:620a:22fa:b0:6af:6c8c:32e8 with SMTP id p26-20020a05620a22fa00b006af6c8c32e8mr6372447qki.15.1657385706536; Sat, 09 Jul 2022 09:55:06 -0700 (PDT) Received: from ?IPV6:2603:6000:a401:3a00:6e88:14ff:fea7:590c? (2603-6000-a401-3a00-6e88-14ff-fea7-590c.res6.spectrum.com. [2603:6000:a401:3a00:6e88:14ff:fea7:590c]) by smtp.gmail.com with ESMTPSA id i6-20020a05620a404600b006af1f0af045sm1701926qko.107.2022.07.09.09.55.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Jul 2022 09:55:06 -0700 (PDT) Message-ID: <483b4eb6-bd9b-49f4-1697-993bd41493fc@gmail.com> Date: Sat, 9 Jul 2022 11:56:05 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: Canonical way / best practice for 128-bit integers Content-Language: en-US To: freebsd-hackers@freebsd.org References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> From: Jason Bacon In-Reply-To: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 X-Rspamd-Queue-Id: 4LgGV33yBzz3jfW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pWuVFYaH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::730 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-3.88 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.98)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers] X-ThisMailContainsUnwantedMimeParts: N T24gNy85LzIyIDExOjI2LCBNYXJjIFZlbGRtYW4gd3JvdGU6DQo+IEhlbGxvLA0KPiANCj4g SeKAmW0gd29ya2luZyBvbiBzb21lIGJsdWV0b290aCBjb2RlLCBhbmQgdGhhdCBpbnZvbHZl cyBoYW5kbGluZyAxMjgtYml0IHV1aWRzLg0KPiBUaGVyZSBhcmUgdmFyaW91cyB3YXlzIHRv IGhhbmRsZSBpbiB0aGUgRnJlZUJTRCBjb2RlYmFzZSwgbGlrZSBpbiBzZHAuaDoNCj4gDQo+ IC8qDQo+ICAgKiBTRFAgaW50MTI4L3VpbnQxMjggcGFyYW1ldGVyDQo+ICAgKi8NCj4gICAg ICANCj4gc3RydWN0IGludDEyOCB7DQo+ICAgICAgICAgIGludDhfdCAgYlsxNl07DQo+IH07 DQo+IHR5cGVkZWYgc3RydWN0IGludDEyOCAgIGludDEyOF90Ow0KPiB0eXBlZGVmIHN0cnVj dCBpbnQxMjggICB1aW50MTI4X3Q7DQo+IA0KPiBhbmQgaW4gc3lzL2Rldi9yYW5kb20vdWlu dDEyOC5oDQo+IA0KPiAjaWZkZWYgVVNFX1JFQUxfVUlOVDEyOF9UDQo+IHR5cGVkZWYgX191 aW50MTI4X3QgdWludDEyOF90Ow0KPiAjZGVmaW5lIFVJTlQxMjhfWkVSTyAwVUxMDQo+ICNl bHNlDQo+IHR5cGVkZWYgc3RydWN0IHsNCj4gICAgICAgICAgLyogSWdub3JlIGVuZGlhbm5l c3MgKi8NCj4gICAgICAgICAgdWludDY0X3QgdTEyOHRfd29yZDA7DQo+ICAgICAgICAgIHVp bnQ2NF90IHUxMjh0X3dvcmQxOw0KPiB9IHVpbnQxMjhfdDsNCj4gc3RhdGljIGNvbnN0IHVp bnQxMjhfdCB2ZXJ5X2xvbmdfemVybyA9IHswVUwsMFVMfTsNCj4gI2RlZmluZSBVSU5UMTI4 X1pFUk8gdmVyeV9sb25nX3plcm8NCj4gI2VuZGlmDQo+IA0KPiBJcyB0aGVyZSBhbnkgcmVj b21tZW5kZWQgLyBzdGFuZGFyZCB3YXkgdG8gaGFuZGxlIDEyOCBiaXQgaW50ZWdlcnMgaW4g YSBwb3J0YWJsZSB3YXk/DQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiBNYXJjIFZlbGRt YW4NCg0KSGF2ZSB5b3UgdHJpZWQgd29ya2luZyB3aXRoIF9fdWludDEyOF90PyAgU3VwcG9y dCBpcyBub3QgY29tcGxldGUsIGUuZy4gDQppbiBpbnR0eXBlcy5oIGFuZCBwcmludGYoKSwg YnV0IGFyaXRobWV0aWMgd29ya3M6DQoNCk5ldEJTRCBuZXRic2Q5LmFjYWRpeCAgYmFjb24g fiAxMDAyOiAocGtnc3JjKTogY2F0IGp1bmsuYw0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j bHVkZSA8c3lzZXhpdHMuaD4NCg0KaW50ICAgICBtYWluKGludCBhcmdjLGNoYXIgKmFyZ3Zb XSkNCg0Kew0KICAgICBfX3VpbnQxMjhfdCB4ID0gMjAsIHkgPSAzMDsNCg0KICAgICBwcmlu dGYoIiV6dSAlbHVcbiIsIHNpemVvZih4KSwgKHVuc2lnbmVkIGxvbmcpKHggKyB5KSk7DQog ICAgIHJldHVybiBFWF9PSzsNCn0NCg0KTmV0QlNEIG5ldGJzZDkuYWNhZGl4ICBiYWNvbiB+ IDEwMDM6IChwa2dzcmMpOiAuL2p1bmsNCjE2IDUwDQoNCi0tIA0KTGlmZSBpcyBhIGdhbWUu ICBQbGF5IGhhcmQuICBQbGF5IGZhaXIuICBIYXZlIGZ1bi4NCg== From nobody Sat Jul 9 17:04:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8FC1A1CF8D44 for ; Sat, 9 Jul 2022 17:05:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgGjX2dnTz3l9L; Sat, 9 Jul 2022 17:05:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1657386304; h=from:from:reply-to:subject:subject:date:date: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=j1Ya2znd0KcrMAuuxI66AMspJ4gWyPjdIOMkdhzMYlQ=; b=fsGbWboUW8TWTQg4M2P8EWmrWHjNQxic8uhKiUVNpa2FM3GSIMgn7HeMBjijzArUwzH2mC NPk3flGjIxwXGPx90d8icOq4sX+eWTfRtN1/HhbhmjlRTpwNpu59usvlJqLhINPWlDf4KE SKKIT/4lsy1Tq2zHEmtS8uXoCkJHOTKa0YrKYh/e5pgTX9GEgglkuxjcjpG2VcQU7aK2n6 iQRpa+qhsaQJaKw50OUxsO8ltv8YMQZsIK6/eKsxrt31U1XaN6bIF+hq05pJlTwlKyIVhB IXPdBGWGhfbqyTDX3O5mR7j97hO8YnicZoBaumMZxGbR4a02Cw7lJIziXI6tyw== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LgGjX0ytQzt19; Sat, 9 Jul 2022 17:05:04 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BE5AC59198; Sat, 9 Jul 2022 19:05:02 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_19D6C1EC-0B51-42A1-83A4-80531A847B04"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Canonical way / best practice for 128-bit integers From: Dimitry Andric In-Reply-To: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> Date: Sat, 9 Jul 2022 19:04:56 +0200 Cc: freebsd-hackers@freebsd.org Message-Id: <903B6B84-4AFE-4BB5-94F5-5DFD65BAC1B6@FreeBSD.org> References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> To: Marc Veldman X-Mailer: Apple Mail (2.3696.100.31) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1657386304; h=from:from:reply-to:subject:subject:date:date: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=j1Ya2znd0KcrMAuuxI66AMspJ4gWyPjdIOMkdhzMYlQ=; b=iaiII6zWBcwzKNNbdwxuzk0upIDWjaYKB5o13NKeaivAp4ZiulP8oZtLjBQm0tWuZARhfS PJyBE3+rfYk46fv4z+/5qsiH5iOr2vbfJGTxWT/mnYqImf7ZzaFME0Q8EgQWBL6VdQHDlD 8U10xVAlkOzivpq/aeFIavOleKzljKlZtufFDfu29/9Fx7bIEwwmGN1vNNC5RQtTvWSetd dzp54SnCzgJitIVMB9eSS2FKQZEVrPAtoD4pD14jOugp8wjaCRDb32W81QxDF9VDuLdIhg fVMDqWhe8a3njPIZyp1eJB7ruysxlmrkM6aYMJ4yi2lHrIjBitXly2XcoHTB8w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657386304; a=rsa-sha256; cv=none; b=w5Mvo7UyBXume93lmeHWmzcpnQS839d8601uaAk8RInr9EF0kfU3F4hDRYmSsrlqv+MBy7 etxx5NFZtAt+UbaZwkSUv8c3YeOLhD9r/cWQ4BFT5d3sJOF02gtykI5A/9E4SH/7PFoB0F joanCopudCzHfKG+6vAfRW0X2rg1yTprWi6rcsWDcVSVouZwivPPGhjwezvGTUj4VO6YKB waazaZixMSeGyRFKTbQpoUcGo9SEWtyLUDSyRIkWYD2stzx/mo1ACWCRvWQg8ne14AXfMI tU95et1KryUg9j3uxnx5txj3jAn1QU6+MbwSPb0B0FtU7WHGpqYHgJwTH3/48g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_19D6C1EC-0B51-42A1-83A4-80531A847B04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Jul 2022, at 18:26, Marc Veldman wrote: >=20 > I=E2=80=99m working on some bluetooth code, and that involves handling = 128-bit uuids. > There are various ways to handle in the FreeBSD codebase, like in = sdp.h: >=20 > /* > * SDP int128/uint128 parameter > */ >=20 > struct int128 { > int8_t b[16]; > }; > typedef struct int128 int128_t; > typedef struct int128 uint128_t; >=20 > and in sys/dev/random/uint128.h >=20 > #ifdef USE_REAL_UINT128_T > typedef __uint128_t uint128_t; > #define UINT128_ZERO 0ULL > #else > typedef struct { > /* Ignore endianness */ > uint64_t u128t_word0; > uint64_t u128t_word1; > } uint128_t; > static const uint128_t very_long_zero =3D {0UL,0UL}; > #define UINT128_ZERO very_long_zero > #endif >=20 > Is there any recommended / standard way to handle 128 bit integers in = a portable way? Of course recent compilers have built-in support for __int128_t and __uint128_t, but it comes with a *lot* of caveats: not supported on all architectures, definitely never on 32-bit ones, differences between compilers, and even compiler versions, etc etc. If you want it portable, the only way is to handle them as two 64 bit integers, and leave any arithmetic or conversion to library routines. -Dimitry --Apple-Mail=_19D6C1EC-0B51-42A1-83A4-80531A847B04 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYsm1OAAKCRCwXqMKLiCW o5I3AKDzzb2cukXMkAtdkHeual+eLBrfoACg4amAZVsEloIRb3Ja2XQu9NfOqm8= =1lVZ -----END PGP SIGNATURE----- --Apple-Mail=_19D6C1EC-0B51-42A1-83A4-80531A847B04-- From eugen@grosbein.net Sat Jul 9 19:27:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3BFD917D7381 for ; Sat, 9 Jul 2022 19:27:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgKsl01m9z42F5 for ; Sat, 9 Jul 2022 19:27:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 269JRCYQ074615 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Jul 2022 19:27:13 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: marc@bumblingdork.com Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 269JRBWN068482 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 10 Jul 2022 02:27:11 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Canonical way / best practice for 128-bit integers To: Marc Veldman , freebsd-hackers@freebsd.org References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> From: Eugene Grosbein Message-ID: Date: Sun, 10 Jul 2022 02:27:02 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LgKsl01m9z42F5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 09.07.2022 23:26, Marc Veldman wrote: > Hello, > > I’m working on some bluetooth code, and that involves handling 128-bit uuids. > There are various ways to handle in the FreeBSD codebase, like in sdp.h: > > /* > * SDP int128/uint128 parameter > */ > > struct int128 { > int8_t b[16]; > }; > typedef struct int128 int128_t; > typedef struct int128 uint128_t; > > and in sys/dev/random/uint128.h > > #ifdef USE_REAL_UINT128_T > typedef __uint128_t uint128_t; > #define UINT128_ZERO 0ULL > #else > typedef struct { > /* Ignore endianness */ > uint64_t u128t_word0; > uint64_t u128t_word1; > } uint128_t; > static const uint128_t very_long_zero = {0UL,0UL}; > #define UINT128_ZERO very_long_zero > #endif > > Is there any recommended / standard way to handle 128 bit integers in a portable way? UUIDs are not integer numbers with arithmetic, so you should not look for 128 bit ints, if you need portability. For example, 32 bit i386 arch lacks hardware support for 128 bit ints, so FreeBSD does not support 128 bit ints with arithmetic for i386 but it does not mean that you cannot use 128 bit UUIDs there. We have uuid(3) manual for DCE 1.1 compliant UUID type uuid_t and functions. From nobody Sun Jul 10 03:09:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EA98217FA649 for ; Sun, 10 Jul 2022 03:09:06 +0000 (UTC) (envelope-from marc@bumblingdork.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgX6T5yq3z3v3Q for ; Sun, 10 Jul 2022 03:09:05 +0000 (UTC) (envelope-from marc@bumblingdork.com) Received: by mail-ed1-x529.google.com with SMTP id e15so2692869edj.2 for ; Sat, 09 Jul 2022 20:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bumblingdork.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=vy4ABm7em5Y/Zx2A54lYg07W/z9PCesI6UoBULPSFbw=; b=AdPCi0jh4M295jb9ULQI2w6rRHsN/vgNS7VQWawA4VObvNEeRI4DDO0bcpkKmArE+/ LmzpOkswBLQmPFjkaVD0c0Zek/cdy0vurZFyK21vrZJOOa56OFOLJ90HRlIB0EskwxVu B+g/5UlGYjoKme6rszP2NF3KAtNLEWgx3BRKnTh74A/E7nUe97vQCbAL3jTeTZlBUFnt kKxnkfP0ZmB92v3llv+NmSrQsGh2/RJfoWIsRHjHx1s5/xo5KPa+Qr5exDETV2Y7djBY 2BqpawjPQnnZtZj8qkO1+oNlJqY0rj99wxuvzjmZGmFVk97RFr3spYpzE4m9QmOms+XW nd1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=vy4ABm7em5Y/Zx2A54lYg07W/z9PCesI6UoBULPSFbw=; b=DCwuRLzbUPyQDZRnyZpkjT7Cstp6mAzI37YGPMN6TrgkCIl0BfyxVulVSP/bBZH6pV yn/3LbcXFjv4zm0dp+6Cn08wQIWJvHvJL7rkfC6vOSUmTs5da5TLML8al/9ZboE1Cg2f t9x93Fg0oVOG8D5iYvhSBwPtVSASaA6J+oFAK5ZyVNRNEoBZzKwigkkhqxU9PRbRsk+l QcQtK34NJvpg6PKBb1Z28omQ/UaAYMH251zk3mtJ7W14WwCdbEJ9hablSFRqINwmd6qs xBApy1WZ8fUe58cOfR72pa7B8/LafsZ2RXh4kT4r4n2UCQP2CWQ0JwxTUFHxqJEql9/g tGsw== X-Gm-Message-State: AJIora9V+RB1ZqF2h4ywrbjn2rbo6IXklQNvCXma1PJ9N6II+rJMWjyy gP8j+qsJFAPwd6ZRphmQcgzm2jU7H0BI1g== X-Google-Smtp-Source: AGRyM1uuhisRbgw+6OX9R+mSYAREOBrSaPkbBbYPPmrFylYp4F7ZKoIFOu/uZ8b4Q+QSm/USjb+sxg== X-Received: by 2002:aa7:c0c4:0:b0:43a:20cf:3c68 with SMTP id j4-20020aa7c0c4000000b0043a20cf3c68mr15648889edp.172.1657422544429; Sat, 09 Jul 2022 20:09:04 -0700 (PDT) Received: from smtpclient.apple (2a02-a467-ec-1-1d41-7a05-7ac8-4c9f.fixed6.kpn.net. [2a02:a467:ec:1:1d41:7a05:7ac8:4c9f]) by smtp.gmail.com with ESMTPSA id ec10-20020a0564020d4a00b0043a45dc7158sm1962448edb.72.2022.07.09.20.09.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jul 2022 20:09:04 -0700 (PDT) From: Marc Veldman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Canonical way / best practice for 128-bit integers Date: Sun, 10 Jul 2022 05:09:03 +0200 References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> To: Eugene Grosbein , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4LgX6T5yq3z3v3Q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bumblingdork.com header.s=google header.b=AdPCi0jh; dmarc=pass (policy=none) header.from=bumblingdork.com; spf=pass (mx1.freebsd.org: domain of marc@bumblingdork.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=marc@bumblingdork.com X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[bumblingdork.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[bumblingdork.com:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[marc]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bumblingdork.com:+]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Eugene, > On 9 Jul 2022, at 21:27, Eugene Grosbein wrote: >=20 > 09.07.2022 23:26, Marc Veldman wrote: >> Hello, >>=20 >> I=E2=80=99m working on some bluetooth code, and that involves = handling 128-bit uuids. >> There are various ways to handle in the FreeBSD codebase, like in = sdp.h: >> Is there any recommended / standard way to handle 128 bit integers in = a portable way? >=20 > UUIDs are not integer numbers with arithmetic, so you should not look = for 128 bit ints, if you need portability. In Bluetooth, not quite. Bluetooth also has 32-bit and 16-bit =E2=80=9CUUI= D aliases=E2=80=9D, which can require some arithmetic/bitshifting. > For example, 32 bit i386 arch lacks hardware support for 128 bit ints, > so FreeBSD does not support 128 bit ints with arithmetic for i386 > but it does not mean that you cannot use 128 bit UUIDs there. >=20 > We have uuid(3) manual for DCE 1.1 compliant UUID type uuid_t and = functions. That looks like a good candidate to have a look at. Thanks! Best regards, Marc Veldman From nobody Sun Jul 10 04:24:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4F86D1CFD39B for ; Sun, 10 Jul 2022 04:25:00 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LgYp32bXsz43N1; Sun, 10 Jul 2022 04:24:59 +0000 (UTC) (envelope-from plmahan@gmail.com) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-10bffc214ffso3338848fac.1; Sat, 09 Jul 2022 21:24:59 -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=57Xr6+i+m5uwIt0ZwzF7ftFpZa6e6qA0O1cci92HcPE=; b=iS4AbaKaf5CgVwK8BahbmpO0x1BvioklDnmUZ37maUD/qD60A5wyUWGHf5/33btvZs +s4COafrsh65wVx250FX9rw4VVfdf/2Eq4+WQLc7p1Sbl2X28OUOnalS3BUYsKWj8ViB YQHNV9XEva1ZCCxBNfOOL63gYpjYhWgv4d4H42UFzVpKk/wxRj/luZR4s9YUgrbuWDZl ONbwI6P6mTYXmewsCnUHcvTVC1qslLkZG6ct1Za3dGgF/9569MVnhxac7hyaevFQip6z q/iUR1+Lr2pf5Pea4ApcQmee4+g0T0ZcUVq0VkSTOx02jlpl0Z9O8pxbunt/UCDvDHsp 16Hg== 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=57Xr6+i+m5uwIt0ZwzF7ftFpZa6e6qA0O1cci92HcPE=; b=VhfUrDbFZd6MOiVuP4OGZjDZvEz8eMS2gQH/nUH/P5+RupGbbqUwfp1VPk/1Ntvbst hFqz+VrAAdZ85t6f32H5ms0oJaIWEWhtmYqGumqW4u7UJ27sngnFfk6NuHZeJDXEOc0y LAT2u3bWZ5cRppWvdXrXq6iyFgMkqh09PGHOJeRBDVJhBXvZnzfevtrcXeGMyWuft4kp /9hHz7iK6R2D848ZDg7gNr555xagPaXD7Ekl/QEoe7f3Ek9O4Z9czT6g1ryO97xnhmcd PCrtq/th2v/CgTEBi5xA691U2/UL0ntc4t1+OzBdeRyPInsoHT8aXhm1Ly0ocZ5aiSVo mxVw== X-Gm-Message-State: AJIora8DfHLOKd+ZuBH8bT9PyBt2qA0bJsYhoGKVUV8otNQh6F+r3v7c DNIGVA9Tq73wbfAuYyrdFHUw8pRJ467z8OXJUIcq9w23 X-Google-Smtp-Source: AGRyM1uvkd5OzHqqcmbbD5S+jeJvCQGc0G8sxBn4g9j09zii8a9FpBPvFMgIM/JbihDPyQd4CNZwMvgjup7dv0k5Uu0= X-Received: by 2002:a05:6870:1794:b0:10b:f7b8:af82 with SMTP id r20-20020a056870179400b0010bf7b8af82mr4144394oae.238.1657427098089; Sat, 09 Jul 2022 21:24:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <86CB4C22-9CAB-4578-8F11-962B4B08F756@bumblingdork.com> <903B6B84-4AFE-4BB5-94F5-5DFD65BAC1B6@FreeBSD.org> In-Reply-To: <903B6B84-4AFE-4BB5-94F5-5DFD65BAC1B6@FreeBSD.org> From: Patrick Mahan Date: Sat, 9 Jul 2022 21:24:47 -0700 Message-ID: Subject: Re: Canonical way / best practice for 128-bit integers To: Dimitry Andric Cc: Marc Veldman , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006c3c9305e36bd197" X-Rspamd-Queue-Id: 4LgYp32bXsz43N1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iS4AbaKa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of plmahan@gmail.com designates 2001:4860:4864:20::2e as permitted sender) smtp.mailfrom=plmahan@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2e:from]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000006c3c9305e36bd197 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 9, 2022 at 10:06 AM Dimitry Andric wrote: > On 9 Jul 2022, at 18:26, Marc Veldman wrote: > > > > I=E2=80=99m working on some bluetooth code, and that involves handling = 128-bit > uuids. > > There are various ways to handle in the FreeBSD codebase, like in sdp.h= : > > > > /* > > * SDP int128/uint128 parameter > > */ > > > > struct int128 { > > int8_t b[16]; > > }; > > typedef struct int128 int128_t; > > typedef struct int128 uint128_t; > > > > and in sys/dev/random/uint128.h > > > > #ifdef USE_REAL_UINT128_T > > typedef __uint128_t uint128_t; > > #define UINT128_ZERO 0ULL > > #else > > typedef struct { > > /* Ignore endianness */ > > uint64_t u128t_word0; > > uint64_t u128t_word1; > > } uint128_t; > > static const uint128_t very_long_zero =3D {0UL,0UL}; > > #define UINT128_ZERO very_long_zero > > #endif > > > > Is there any recommended / standard way to handle 128 bit integers in a > portable way? > > Of course recent compilers have built-in support for __int128_t and > __uint128_t, but it comes with a *lot* of caveats: not supported on all > architectures, definitely never on 32-bit ones, differences between > compilers, and even compiler versions, etc etc. > > If you want it portable, the only way is to handle them as two 64 bit > integers, and leave any arithmetic or conversion to library routines. > > I second this, especially if you want to use any of the underlying assembly code. For example, the Intel architecture supports the data type but does not support 128-bit instructions but instead requires you to shift the upper 64 bits to operate with a 64-bit instruction. I found this out when we needed to speed up the ability to walk a 128-bit bitmask (we were doing it the hard way). I wound up converting everything back to 64-bit and saw a tremendous speed up in our code. I mostly use it for defining the storage of an IP address (either IPv4 or IPv6) where storage does not need to be exceedingly tight. Also, I have only used it on Intel/AMD architectures. Back when I was working in MIPS architectures (mostly Cavium multi-core) we did not have this data type available. And I have only briefly looked at AArch64 so it may or may not be supported there. Patrick --0000000000006c3c9305e36bd197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 9, 2022 at 10:06 AM Dimitry A= ndric <dim@freebsd.org> wrote:=
On 9 Jul 2022, at 18:26, Marc Veldman <marc@bumblingdork.com> wrote:<= br> >
> I=E2=80=99m working on some bluetooth code, and that involves handling= 128-bit uuids.
> There are various ways to handle in the FreeBSD codebase, like in sdp.= h:
>
> /*
> * SDP int128/uint128 parameter
> */
>
> struct int128 {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int8_t=C2=A0 b[16];
> };
> typedef struct int128=C2=A0 =C2=A0int128_t;
> typedef struct int128=C2=A0 =C2=A0uint128_t;
>
> and in sys/dev/random/uint128.h
>
> #ifdef USE_REAL_UINT128_T
> typedef __uint128_t uint128_t;
> #define UINT128_ZERO 0ULL
> #else
> typedef struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Ignore endianness */
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64_t u128t_word0;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64_t u128t_word1;
> } uint128_t;
> static const uint128_t very_long_zero =3D {0UL,0UL};
> #define UINT128_ZERO very_long_zero
> #endif
>
> Is there any recommended / standard way to handle 128 bit integers in = a portable way?

Of course recent compilers have built-in support for __int128_t and
__uint128_t, but it comes with a *lot* of caveats: not supported on all
architectures, definitely never on 32-bit ones, differences between
compilers, and even compiler versions, etc etc.

If you want it portable, the only way is to handle them as two 64 bit
integers, and leave any arithmetic or conversion to library routines.


I second this, especially if you want = to use any of the underlying assembly code.=C2=A0 For example, the Intel ar= chitecture supports the data type but does not support 128-bit instructions= but instead requires you to shift the upper=C2=A064 bits to operate with a= 64-bit instruction.

I found this out when we need= ed to speed up the ability to walk a 128-bit bitmask (we were doing it the = hard way).=C2=A0 =C2=A0I wound up converting everything back to 64-bit and = saw a tremendous speed up in our code.

I mostly us= e it for defining the storage of an IP address (either IPv4 or IPv6) where = storage does not need to be exceedingly tight.

Als= o, I have only used it on Intel/AMD architectures.=C2=A0 Back when I was wo= rking in MIPS architectures (mostly Cavium multi-core) we did not have this= data type available.=C2=A0 And I have only briefly looked at AArch64 so it= may or may not be supported there.

Patrick
<= /div>
--0000000000006c3c9305e36bd197-- From nobody Mon Jul 11 13:16:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CDBF61CFF8CC for ; Mon, 11 Jul 2022 13:24:19 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LhPjr6vSJz3j2l for ; Mon, 11 Jul 2022 13:24:15 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26BDH67G050275 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 11 Jul 2022 22:47:15 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657545439; bh=AW6vJ2gb7MrlYwNVd7iBjowGt0YatjHZsafYhAozTr4=; h=From:Date:Subject:To; b=rMWRaQOS9E9cxemVy+E4RZxybOjZCGznRTMLWbBqEHdJcN1LclnHSuB1XrjMJZys+ vIqvhDT/kg9USNePwnc/2DXFOTCBgaCXe58xow9mpAGjdY2T7P6OZcqX8mIoi4bS+U +XG2iJ8yAoV05r4G31g+TCOeZl7F1nnXpI1sNlD4= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26BDGkLD050267 for ; Mon, 11 Jul 2022 22:46:46 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:816a:96ed:835a:e348 Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:816a:96ed:835a:e348] [2403:5800:5200:4700:816a:96ed:835a:e348]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26BDGkvQ050250; Mon, 11 Jul 2022 22:46:46 +0930 From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Mon, 11 Jul 2022 22:46:33 +0930 Subject: VFS mount rollback for virtio 9pfs Message-Id: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> To: freebsd-hackers X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LhPjr6vSJz3j2l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=rMWRaQOS; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I am attempting to get the Juniper virtfs code = (http://github.com/Juniper/virtfs) working and I have managed to get it = to a point where it mounts and things seem to work = (https://github.com/DanielO/freebsd-src/tree/9pfs) although I have only = tested on bhyve so far (but feel free to test elsewhere :) During the process I found the Juniper code would ask for 9p2000.u but = is written for 9p2000.L (I think bhyve is more rigid about what it = allows than Xen etc). This was easily fixed but I want to make the handling of a similar error = in future correct. The virtfs_unmount code as it stands will fail when = the kernel tries to rollback the mount. The end result is the ref count = for the file system is not decremented so the KLD can't be unloaded. I attempted to fix this by squashing the return value to 0 in the event = of a forced unmount but that results in the mount rollback hanging in = 'mntref' while it waits for the mount ref count to go to 0. I assume I am missing something obvious but I can't work out what it is = so any clue much appreciated. Thanks. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Tue Jul 12 14:33:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 441981D0792D for ; Tue, 12 Jul 2022 14:33:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lj3Br37zZz49t9 for ; Tue, 12 Jul 2022 14:33:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id i21so8193480qtw.12 for ; Tue, 12 Jul 2022 07:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fZrpm85PyvduIc1V/KaeYKXty8mkve/0mWMdhF43xSI=; b=n0Rqal8DkPf7Lhu5v40Buu1E6fg2rKVO6UBt3X+J2eswBCTw6Q4F4M2J1klkRQYf/z /3pUkgJWPcsBD+fC6YGwdhc0bJaZw/i8QO3Hy19wr/Q+S1vKzpir2VjGNatKla0ajKJQ zMCWIlIFkjgGSkd5Cg0JYfmMaVyaubL4YwHrW6fd0EMTXNYKtXNYjzA5upq6XC4O6uYo y69taMfTThgOJN2/ATrng4szjYqIML6BCDL5SuPeIeBgIP9YeOXFVQdz83qIwE2lOg+I kVAyA9Dd5ocDjxcE8mMJfrU52LpBMXZTbeWde0+SmLQ3MVxn7xSoycyAvYrT24G5lPjT JBWg== 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=fZrpm85PyvduIc1V/KaeYKXty8mkve/0mWMdhF43xSI=; b=zmJ+h/lwGY9TaVuKRFslvCS5SzUVhiF0KnmNuOBjoocl5mC/zry7RcurcFzas5fkas LWopMjSxkuLzMfE5AXYB/8ema1NVxs3x96I1VxEeDn24vM1MOJfctMo0Pw774aGny3Zc oqH2uTU3TH5okoOudDnkgjbmO0pXI3oG/hMo0svivAHT5Vgx2UMC9tyd2/XtraVPHnSg ag6edkC56nl4IXIK5fDR1/MLG/BqNpUZhU/IcNOT7KRhPwOy0kud2Kv42ff4RTOzQfop H/oUO7p8JyeQBp61BHl0chU82nnwMiVPN7Y0iEVVjgiGmkxTjGhVHVd/XgVpxKvRmI6Y kAzg== X-Gm-Message-State: AJIora9DJSH4w+CGPuKcQXBfq45NC37CAEW8MSV73UuTpmTozl1MZ2gg 8/w+cb2yQM3lMg1sGMtQgsK2F9GQo6M= X-Google-Smtp-Source: AGRyM1sa9tiBi9Dl7jE17X5USPWUr5dur2Vnend10Qd1hbZg/gdtdTktA8ZEIgwYWWjlyexKP+4rcg== X-Received: by 2002:ac8:5996:0:b0:31e:92c8:bd98 with SMTP id e22-20020ac85996000000b0031e92c8bd98mr18915191qte.232.1657636387681; Tue, 12 Jul 2022 07:33:07 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id n20-20020a05620a295400b006b54e630a98sm316162qkp.96.2022.07.12.07.33.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 07:33:06 -0700 (PDT) Date: Tue, 12 Jul 2022 10:33:04 -0400 From: Mark Johnston To: Daniel O'Connor Cc: freebsd-hackers Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> X-Rspamd-Queue-Id: 4Lj3Br37zZz49t9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=n0Rqal8D; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.64 / 15.00]; NEURAL_HAM_LONG(-0.99)[-0.991]; NEURAL_HAM_SHORT(-0.99)[-0.988]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::830:server fail,192.0.220.237:server fail]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 11, 2022 at 10:46:33PM +0930, Daniel O'Connor wrote: > Hi, > I am attempting to get the Juniper virtfs code (http://github.com/Juniper/virtfs) working and I have managed to get it to a point where it mounts and things seem to work (https://github.com/DanielO/freebsd-src/tree/9pfs) although I have only tested on bhyve so far (but feel free to test elsewhere :) > > During the process I found the Juniper code would ask for 9p2000.u but is written for 9p2000.L (I think bhyve is more rigid about what it allows than Xen etc). > > This was easily fixed but I want to make the handling of a similar error in future correct. The virtfs_unmount code as it stands will fail when the kernel tries to rollback the mount. The end result is the ref count for the file system is not decremented so the KLD can't be unloaded. How does virtfs_unmount() fail? The tsleep() call there looks suspicious, it's using the address of a local variable as a wait channel, so I don't understand how it'll ever get signalled. > I attempted to fix this by squashing the return value to 0 in the event of a forced unmount but that results in the mount rollback hanging in 'mntref' while it waits for the mount ref count to go to 0. > > I assume I am missing something obvious but I can't work out what it is so any clue much appreciated. > > Thanks. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > > From nobody Tue Jul 12 23:12:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 30A0C1D23BD3 for ; Tue, 12 Jul 2022 23:24:21 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LjGzm4N68z3Wq5 for ; Tue, 12 Jul 2022 23:24:20 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26CNCefq035964 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 13 Jul 2022 08:42:50 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657667573; bh=36mwhPAhRpTbgKn9j9oyBJNbE5WTSslwHGqPBEQ7/sI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=KRMpkzvyNI2qIAcFo3nbTA6i//nzxoUzyYKVfltaiD7erErSp7DR4qZB/+KAx1+xC y4cb7hztteKtQprsIxiRtkB3D6OvQGb+fOOMs2RsDLCMVoz74vnZGMs1qCIygssn76 KK+XSkBh8aR8QcpJJVWi6t8Okq3LQPOWQeh+VU4c= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26CNCa4F035960 for ; Wed, 13 Jul 2022 08:42:36 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:b9d9:fc6f:cbb1:cf48 Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:b9d9:fc6f:cbb1:cf48] [2403:5800:5200:4700:b9d9:fc6f:cbb1:cf48]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26CNCaLe035954; Wed, 13 Jul 2022 08:42:36 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: VFS mount rollback for virtio 9pfs From: "Daniel O'Connor" In-Reply-To: Date: Wed, 13 Jul 2022 08:42:29 +0930 Cc: freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> To: Mark Johnston X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LjGzm4N68z3Wq5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=KRMpkzvy; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 13 Jul 2022, at 00:03, Mark Johnston wrote: >> This was easily fixed but I want to make the handling of a similar = error in future correct. The virtfs_unmount code as it stands will fail = when the kernel tries to rollback the mount. The end result is the ref = count for the file system is not decremented so the KLD can't be = unloaded. >=20 > How does virtfs_unmount() fail? The tsleep() call there looks > suspicious, it's using the address of a local variable as a wait > channel, so I don't understand how it'll ever get signalled. Yes good point, I don't think it ever gets woken up - it just times out. Without any changes (ie what is in my git tree at now) it returns EBUSY. If I change it like so: if (mntflags & MNT_FORCE || mp->mnt_kern_flag & MNTK_UNMOUNTF) flags |=3D FORCECLOSE; And then later to squash the return value to 0 if FORCECLOSE is set then = mount hangs: load: 0.46 cmd: mount 988 [mntref] 1.42r 0.00u 0.03s 0% 2252k mi_switch+0xc2 _sleep+0x1fc vfs_mount_destroy+0xa4 = vfs_domount_first+0x382 vfs_domount+0x2ad vfs_donmount+0x8f8 = sys_nmount+0x69 amd64_syscall+0x10c fast_syscall_common+0xf8 -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Wed Jul 13 06:16:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2EA721D05C56 for ; Wed, 13 Jul 2022 06:24:19 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LjSJJ429Xz4KJN for ; Wed, 13 Jul 2022 06:24:16 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26D6GfDj053436 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 13 Jul 2022 15:46:45 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657693010; bh=2fbix+IdFkRMmY0qRNXcwLrvUTHw1RqMGh/ANJtryxI=; h=From:Date:Subject:To; b=eQBxdZxp+OJm+vhYLsY8R5ePv1BQjp3iZWlDHi+VeZcmhRkRUt2FYHb2zoWdYcbXr qkI6a4M0V4T3Zd/yU492/pqlRpYGqG0N+DGtwiabyZnbf5PLEjSux0fHikwW/eT2cf jvC3vbrIzeFj5Xp4xOE25yYQuOduv69bM1XR/HHc= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26D6GRkl053425 for ; Wed, 13 Jul 2022 15:46:27 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2001:44b8:1d2:8900:80bb:59a3:4e07:2285 Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:80bb:59a3:4e07:2285] [2001:44b8:1d2:8900:80bb:59a3:4e07:2285]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26D6GMpa053422; Wed, 13 Jul 2022 15:46:27 +0930 From: "Daniel O'Connor" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Date: Wed, 13 Jul 2022 15:46:21 +0930 Subject: Cross build 13.1 from OSX Message-Id: <80925A7C-D6E6-401A-A2F5-9267B0644C72@dons.net.au> To: freebsd-hackers X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LjSJJ429Xz4KJN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=eQBxdZxp; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I'm trying to cross build from OSX (with stuff built from Macports). I = modified make.py to add /opt/local/bin to the path then ran: env XCC=3D/opt/local/bin/clang-mp-14 XCXX=3D/opt/local/bin/clang++-mp-14 = XCPP=3D/opt/local/bin/clang-cpp-mp-14 XLD=3D/opt/local/bin/ld.lld-mp-14 = MAKEOBJDIRPREFIX=3D/tmp/freebsdobj --host-bindir=3D/opt/local/bin = tools/build/make.py TARGET=3Damd64 TARGET_ARCH=3Damd64 kernel-toolchain However it bombs out trying to build compile_et: -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /Users/oconnd1/projects/freebsd; INSTALL=3D"sh = /Users/oconnd1/projects/freebsd/tools/install.sh" = TOOLS_PREFIX=3D/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd6= 4.amd64/tmp = PATH=3D/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/= tmp/legacy/usr/sbin:/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd= /amd64.amd64/tmp/legacy/usr/bin:/private/tmp/freebsdobj/Users/oconnd1/proj= ects/freebsd/amd64.amd64/tmp/legacy/bin:/private/tmp/freebsdobj/Users/ocon= nd1/projects/freebsd/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sb= in:/usr/bin = WORLDTMP=3D/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.am= d64/tmp MAKEFLAGS=3D"-m /Users/oconnd1/projects/freebsd/tools/build/mk = -D WITH_AUTO_OBJ -D WITHOUT_CLEAN -m = /Users/oconnd1/projects/freebsd/share/mk" = /tmp/freebsdobj/bmake-install/bin/bmake -f Makefile.inc1 DESTDIR=3D = OBJTOP=3D'/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd= 64/tmp/obj-tools' OBJROOT=3D'${OBJTOP}/' MAKEOBJDIRPREFIX=3D = BOOTSTRAPPING=3D0 BWPHASE=3Dbootstrap-tools -DNO_CPU_CFLAGS -DNO_LINT = -DNO_PIC -DNO_SHARED MK_CTF=3Dno MK_CLANG_EXTRAS=3Dno = MK_CLANG_FORMAT=3Dno MK_CLANG_FULL=3Dno MK_HTML=3Dno MK_MAN=3Dno = MK_PROFILE=3Dno MK_RETPOLINE=3Dno MK_SSP=3Dno MK_TESTS=3Dno = MK_WERROR=3Dno MK_INCLUDES=3Dyes MK_MAN_UTILS=3Dyes = MK_LLVM_TARGET_ALL=3Dno bootstrap-tools =3D=3D=3D> usr.bin/compile_et (obj,all,install) [Creating objdir = /private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/obj= -tools/usr.bin/compile_et...] yacc -d -o parse.c = /Users/oconnd1/projects/freebsd/contrib/com_err/parse.y lex -olex.c /Users/oconnd1/projects/freebsd/contrib/com_err/lex.l echo compile_et: = /private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/leg= acy/usr/lib/libroken.a /usr/lib/libcrypt.a = /private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/obj= -tools/kerberos5/lib/libvers/libvers.a = /private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/leg= acy/usr/lib/libegacy.a >> .depend /usr/bin/cc -O2 -pipe -fno-common -I. = -I/Users/oconnd1/projects/freebsd/contrib/com_err -MD = -MF.depend.compile_et.o -MTcompile_et.o -std=3Dgnu99 = -Wno-format-zero-length -Wno-pointer-sign -Wno-system-headers = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Wno-typedef-redefinition = -Werror=3Dincompatible-pointer-types-discards-qualifiers = -Qunused-arguments = -I/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/l= egacy/usr/include -Werror=3Dimplicit-function-declaration = -Werror=3Dimplicit-int -Werror=3Dreturn-type -Wundef = -DHAVE_NBTOOL_CONFIG_H=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/common = -D_DARWIN_C_SOURCE=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/mac = -idirafter /Users/oconnd1/projects/freebsd/contrib/libarchive/libarchive = -c /Users/oconnd1/projects/freebsd/contrib/com_err/compile_et.c -o = compile_et.o /usr/bin/cc -O2 -pipe -fno-common -I. = -I/Users/oconnd1/projects/freebsd/contrib/com_err -MD = -MF.depend.parse.o -MTparse.o -std=3Dgnu99 -Wno-format-zero-length = -Wno-pointer-sign -Wno-system-headers -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Wno-typedef-redefinition = -Werror=3Dincompatible-pointer-types-discards-qualifiers = -Qunused-arguments = -I/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/l= egacy/usr/include -Werror=3Dimplicit-function-declaration = -Werror=3Dimplicit-int -Werror=3Dreturn-type -Wundef = -DHAVE_NBTOOL_CONFIG_H=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/common = -D_DARWIN_C_SOURCE=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/mac = -idirafter /Users/oconnd1/projects/freebsd/contrib/libarchive/libarchive = -c parse.c -o parse.o /usr/bin/cc -O2 -pipe -fno-common -I. = -I/Users/oconnd1/projects/freebsd/contrib/com_err -MD -MF.depend.lex.o = -MTlex.o -std=3Dgnu99 -Wno-format-zero-length -Wno-pointer-sign = -Wno-system-headers -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality = -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Wno-typedef-redefinition = -Werror=3Dincompatible-pointer-types-discards-qualifiers = -Qunused-arguments = -I/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/l= egacy/usr/include -Werror=3Dimplicit-function-declaration = -Werror=3Dimplicit-int -Werror=3Dreturn-type -Wundef = -DHAVE_NBTOOL_CONFIG_H=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/common = -D_DARWIN_C_SOURCE=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/mac = -idirafter /Users/oconnd1/projects/freebsd/contrib/libarchive/libarchive = -c lex.c -o lex.o /usr/bin/cc -O2 -pipe -fno-common -I. = -I/Users/oconnd1/projects/freebsd/contrib/com_err -std=3Dgnu99 = -Wno-format-zero-length -Wno-pointer-sign -Wno-system-headers = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Wno-typedef-redefinition = -Werror=3Dincompatible-pointer-types-discards-qualifiers = -Qunused-arguments = -I/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/l= egacy/usr/include -Werror=3Dimplicit-function-declaration = -Werror=3Dimplicit-int -Werror=3Dreturn-type -Wundef = -DHAVE_NBTOOL_CONFIG_H=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/common = -D_DARWIN_C_SOURCE=3D1 = -I/Users/oconnd1/projects/freebsd/tools/build/cross-build/include/mac = -idirafter /Users/oconnd1/projects/freebsd/contrib/libarchive/libarchive = = -L/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/l= egacy/usr/lib -o compile_et compile_et.o parse.o lex.o = -L/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/o= bj-tools/kerberos5/lib/libroken -lroken = -L/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/o= bj-tools/lib/libcrypt -lcrypt = -L/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/o= bj-tools/kerberos5/lib/libvers -lvers -legacy -lresolv ld: warning: directory not found for option = '-L/private/tmp/freebsdobj/Users/oconnd1/projects/freebsd/amd64.amd64/tmp/= obj-tools/lib/libcrypt' ld: library not found for -lcrypt clang: error: linker command failed with exit code 1 (use -v to see = invocation) *** Error code 1 Stop. bmake[3]: stopped in /Users/oconnd1/projects/freebsd/usr.bin/compile_et *** Error code 1 My tree is a (slightly modified) clone of = fc952ac2212b121aa6eefc273f5960ec3e0a466d I see usr.bin/compile_et/Makefile.depend has libcrypt but not sure why = it doesn't get built. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Jul 14 03:01:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3A10A1CFF29D for ; Thu, 14 Jul 2022 03:24:20 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lk0G94Qrbz41XP for ; Thu, 14 Jul 2022 03:24:16 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26E32DEV007149 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 14 Jul 2022 12:32:14 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657767739; bh=z4P7XqKdOg1moprvGFtFBvAEcG9geUBkYpcE2BAXtN0=; h=Subject:From:In-Reply-To:Date:References:To; b=IsuCBl8AeNhcckPxFxEMp1ZHA469BRZ6RYnC/DSBRAzSCsR5B8mtXsqymX8p1zqbI lTzEI+K9r/C251sK4GWJiK1rJLMvWeolzFzJHG0DFxHmEFO+GXVjnMLHaXpI8Ai8NR UMjFfwb3Uj7mGfcYWa4pf4Esu8dFdlwSFNDznq2E= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26E31uqP007128 for ; Thu, 14 Jul 2022 12:31:56 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2001:44b8:1d2:8900:84ec:1587:cfb4:408 Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:84ec:1587:cfb4:408] [2001:44b8:1d2:8900:84ec:1587:cfb4:408]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26E31pPu007120; Thu, 14 Jul 2022 12:31:56 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: Cross build 13.1 from OSX From: "Daniel O'Connor" In-Reply-To: <80925A7C-D6E6-401A-A2F5-9267B0644C72@dons.net.au> Date: Thu, 14 Jul 2022 12:31:50 +0930 Content-Transfer-Encoding: quoted-printable Message-Id: <22451765-B21E-4FA5-B891-32177A94AFF9@dons.net.au> References: <80925A7C-D6E6-401A-A2F5-9267B0644C72@dons.net.au> To: freebsd-hackers X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4Lk0G94Qrbz41XP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=IsuCBl8A; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 13 Jul 2022, at 15:46, Daniel O'Connor wrote: >=20 > ld: library not found for -lcrypt > clang: error: linker command failed with exit code 1 (use -v to see = invocation) > *** Error code 1 >=20 > Stop. > bmake[3]: stopped in = /Users/oconnd1/projects/freebsd/usr.bin/compile_et > *** Error code 1 >=20 > My tree is a (slightly modified) clone of = fc952ac2212b121aa6eefc273f5960ec3e0a466d >=20 > I see usr.bin/compile_et/Makefile.depend has libcrypt but not sure why = it doesn't get built. Adding 'crypt' to LIBADD gets the build working, not sure if that is the = right solution or a kludge though. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Jul 14 10:12:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lk9Jy6rCGz4Wcrw for ; Thu, 14 Jul 2022 10:12:18 +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 4Lk9Jy0Pbrz3f58 for ; Thu, 14 Jul 2022 10:12:18 +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=XpxOJZTWs43XRB8fY/iWTakVqBGx8eSXk9JMlq0+xx8=; b=h6KTDvpRI9RAVttApSQYDrvE3X /ZsgUSjO3Tjt/L6Y3pZSrImyk4eII0ZRQO+KDu5mZeT4Yev3CcimgUy+7pX+D2/mUoHVLPXbAr4i3 4i09wWVpJHCWU3+3CdnP1UJC7PAQPYNHDU2fhrpzj/fZX5U4GQnLsedW6OFiwb7IS95LePdhdZJl7 yqUOqoC9jgLixYrsNbJm0h5XxRv8nYDwk+KO+Pp5vY2Xbiy3uJ12a8Y6L7pM7cwwMzjKg48UZC2ib EqdrUFTiYRec0UvV3mPogb5e+0ZgvuwJ8gMEZQIk0yJ+Dr6T5DqyDFe9ODqQ4LoJsuTeqIlCn6Zfv M59hxn6g==; 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 1oBvpQ-00604Q-82 for freebsd-hackers@freebsd.org; Thu, 14 Jul 2022 12:12:16 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1oBvpP-0000xm-Pn for freebsd-hackers@freebsd.org; Thu, 14 Jul 2022 10:12:15 +0000 Date: Thu, 14 Jul 2022 12:12:14 +0200 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d2zamt7g25huwano" Content-Disposition: inline In-Reply-To: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> User-Agent: NeoMutt/20220429 X-Rspamd-Queue-Id: 4Lk9Jy0Pbrz3f58 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=h6KTDvpR; 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 [-8.80 / 15.00]; SIGNED_PGP(-2.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[palmen-it.de:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --d2zamt7g25huwano Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Daniel O'Connor [20220711 22:46]: > I am attempting to get the Juniper virtfs code > (http://github.com/Juniper/virtfs) working and I have managed to get > it to a point where it mounts and things seem to work > (https://github.com/DanielO/freebsd-src/tree/9pfs) although I have > only tested on bhyve so far (but feel free to test elsewhere :) Awesome, I've been waiting for this feature! Thanks for working on it. I hope once you're done, you'll rebase it onto main and suggest if for inclusion :) 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 --d2zamt7g25huwano Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmLP6/kACgkQPvKLCrwC 2irfwgf+JCVtOnXgIUxKDUAZfpbuQ+hfJbHd0mh5M297Ksgi66YmBr8Z7r1PZl1d J89y98cUSPLU38Ryw3qqw6atG8ATyjxXODqLOSxnwaFd3pyLnoLWGBg1oYv6eoaG bb+Y+hmu6oFiChj4W5Qdtl5aC/kbbiID5Ceojxm7wPClbMQ32DK58PjZmpT161Rr lEy36AUY3O4Yci3s71ro8DJwNPxY4lO5ppWX95oEm9pcH+6t2H1REb6RMWITT5hn 6s1nQR0+WHPxyyr3RHE5Llr4LXjUsX7UeYX7QN1wuHTzK1d+crKBywTCNzjwFQIr LwzU9XFeE3476k/hE8WV1cmxI1ILgw== =W79H -----END PGP SIGNATURE----- --d2zamt7g25huwano-- From nobody Thu Jul 14 11:27:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LkC1S24lGz4WmnB for ; Thu, 14 Jul 2022 11:29:00 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LkC1P2MG7z3krc for ; Thu, 14 Jul 2022 11:28:56 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26EBSEko029099 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 14 Jul 2022 20:58:25 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657798109; bh=sKQ5bDZH359EHwAGQKFSR+MGthIfqQjrFP3e6qCq3rc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=huw7Zj74Ik/LUECorMgV2CA0eS+KjH964F0MhQyRXWSMffng0sTIF5e5u8l+QMtaX LZDOahG1+TyQN/1nHnSsy9/ErE5dvmdFf1Ea0pNVBpHyVPwii9bCMmcX2W+r0RGIfb kijmF8eHJePhRnaObK1yFdLTMZNMDLuoMfr9ZwvM= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26EBRrbc029084 for ; Thu, 14 Jul 2022 20:57:53 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:d4f7:e0f:bb7f:67b1 Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:d4f7:e0f:bb7f:67b1] [2403:5800:5200:4700:d4f7:e0f:bb7f:67b1]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26EBRrd3029072; Thu, 14 Jul 2022 20:57:53 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: VFS mount rollback for virtio 9pfs From: "Daniel O'Connor" In-Reply-To: <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> Date: Thu, 14 Jul 2022 20:57:45 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> To: Felix Palmen X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LkC1P2MG7z3krc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=huw7Zj74; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 14 Jul 2022, at 19:42, Felix Palmen wrote: >=20 > * Daniel O'Connor [20220711 22:46]: >> I am attempting to get the Juniper virtfs code >> (http://github.com/Juniper/virtfs) working and I have managed to get >> it to a point where it mounts and things seem to work >> (https://github.com/DanielO/freebsd-src/tree/9pfs) although I have >> only tested on bhyve so far (but feel free to test elsewhere :) >=20 > Awesome, I've been waiting for this feature! Thanks for working on it. >=20 > I hope once you're done, you'll rebase it onto main and suggest if for > inclusion :) That's the plan but if you want to test it you should be able to clone = the repo and build the KLDs, eg: git clone --depth 1 --branch 9pfs = https://github.com/DanielO/freebsd-src.git 9pfs cd 9pfs/sys/dev/virtio/9pnet make && sudo make install cd ../9pfs make && sudo make install Then to use it: kldload virtio_9pfs mount -t virtfs somesharename /some/mount/point -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Jul 14 13:42:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LkGF82QKsz1J4rQ for ; Thu, 14 Jul 2022 13:54:20 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LkGF55zNKz40p0 for ; Thu, 14 Jul 2022 13:54:16 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26EDgjKD036976 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 14 Jul 2022 23:12:49 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1657806173; bh=cJhxCr9QbcAUdEc24GhX+g3yDG8dNqogi9y1zH8TiTI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SmdbyNfc1+jRE6OaN4A4IzOwEdicpC9MQKCfusSh4nwqJYi0SDa8HKu4nl0X4r1FG 4WArjKMN3wtDs9JuhvYM7bqxgICCAiDfnVLjFUJHEWfpg9kPatQfP4d59PZZIFydVF SwD5bjkJP7RqPFa/h63WJDnSei598GqNlGe0yQWQ= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26EDgSG9036953 for ; Thu, 14 Jul 2022 23:12:28 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:d4f7:e0f:bb7f:67b1 Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:d4f7:e0f:bb7f:67b1] [2403:5800:5200:4700:d4f7:e0f:bb7f:67b1]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26EDfuor036889; Thu, 14 Jul 2022 23:12:28 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: VFS mount rollback for virtio 9pfs From: "Daniel O'Connor" In-Reply-To: Date: Thu, 14 Jul 2022 23:12:28 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <07D63390-AC48-4A19-A717-F6CAF546E1A6@dons.net.au> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> To: Felix Palmen X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LkGF55zNKz40p0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=SmdbyNfc; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 14 Jul 2022, at 20:57, Daniel O'Connor wrote: >=20 >=20 >=20 >> On 14 Jul 2022, at 19:42, Felix Palmen wrote: >>=20 >> * Daniel O'Connor [20220711 22:46]: >>> I am attempting to get the Juniper virtfs code >>> (http://github.com/Juniper/virtfs) working and I have managed to get >>> it to a point where it mounts and things seem to work >>> (https://github.com/DanielO/freebsd-src/tree/9pfs) although I have >>> only tested on bhyve so far (but feel free to test elsewhere :) >>=20 >> Awesome, I've been waiting for this feature! Thanks for working on = it. >>=20 >> I hope once you're done, you'll rebase it onto main and suggest if = for >> inclusion :) >=20 > That's the plan but if you want to test it you should be able to clone = the repo and build the KLDs, eg: > git clone --depth 1 --branch 9pfs = https://github.com/DanielO/freebsd-src.git 9pfs > cd 9pfs/sys/dev/virtio/9pnet This should be.. cd 9pfs/sys/modules/virtio/9pnet > make && sudo make install > cd ../9pfs > make && sudo make install >=20 > Then to use it: > kldload virtio_9pfs > mount -t virtfs somesharename /some/mount/point -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Thu Jul 14 20:05:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LkQT96NqQz4T34y for ; Thu, 14 Jul 2022 20:05:17 +0000 (UTC) (envelope-from jwd@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LkQT95t7cz3RkG for ; Thu, 14 Jul 2022 20:05:17 +0000 (UTC) (envelope-from jwd@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1657829117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=q9CjjJWceBsQMRv9UldDRrzflSCUFffdZ4N3Od2Aw8c=; b=gPE6fWxzPXzB4YokWLsDkwpHT3Jhl9fu+AjzO14Gzo1ZHuwyEFx2AHB9jha9epGdUunknF tpsUHbED2mTi3MY6SwGQTQPwdnNqjcKdF8I2OYxXBmuNZ3B112c+364SphrKo8D/RnqYI+ bFWEoL2uNuj+Ev4ldOTOOq5dVTkJKtAUe2WjATJsIIU+8ImgYYdh4nCdLQkmuXXrxcqkDU 15S5NVUnipHEGOQ9oQwf0tlf5FhkG6/x0RgrGQ/otwppvD6a6N3AXYy+Y7IekNHzgKsW3h cmrLPw81U+hsc+JrrcUQdxXtRTNfoiWIAPQZlh5Vr3+YYYWDnfo46vAhMcZNqw== Received: by freefall.freebsd.org (Postfix, from userid 821) id B976A1732; Thu, 14 Jul 2022 20:05:17 +0000 (UTC) Date: Thu, 14 Jul 2022 20:05:17 +0000 From: John To: FreeBSD-Hackers Subject: Dynamic VF mac address manipulation / Bhyve Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1657829117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=q9CjjJWceBsQMRv9UldDRrzflSCUFffdZ4N3Od2Aw8c=; b=ObhItjlF1q06CrL36gjyeHR5PaBgEwa6uIFypSaD6fTQVAuCP0nxm8cVdtha8p9TNJQwU6 TKIRd/1+hYd3fbTenCzUMC9SE83DXguSdimzA3D4GJvy/YkbRbRI/BEyPFGvOc3Uq7kAbm J9DYQ5r3SAJ/k9Up7RvOqsSfLFmeaNMWDFuIGUAHxDXV7j4HF1qV09Vbz9hJEJY1CMZ7V0 i8E1Yhf+A9Aa0267nBb3Mmo5VqTknzlzVcP6bTCXXwJPenw9jT7t5Tu5aP7R9KJ0HEcdB9 WAYeZ0z5ki6cHrt6T9GsFBCAl5Arj1ohHZwrDpd2HasjA9tVr5ddLI2QWrMIwA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1657829117; a=rsa-sha256; cv=none; b=v9Xo5+tHbBwMnHMdW9I4aV4sJkVWweGaNTMaS2MCMdPKQ49sV8x68rkHM51q4d7HPcucik GAKrGVrVYWQD84XIjfOU8u+t5IGsNq9uIMMhIFf+jOhBssbd70h/SkzVi5QIvjCgUE0G3E Yx3CXDRt2FnLGy+jyEjMcnU70duQ1u5V87pAi6N4B+HztwL1y0xSJuL5YM0Zu+rJUD21tR X/r9WyjpSVeNklGS1MtO2ROxvQdMpfoWUq4EjT/wfUNE1wkrIcnbamrQvw62APIUiFo6QX OFFkhZujtYrW517H3qbRNwLkuhmPK/XZ21/EF/VEwzTrbvBsxAmhWmoGlmZZEA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi - I am slowly converting a Linux based qemu/kvm solution to FreeBSD Bhyve where VMs have mac addresses assigned to them. Linux allows individual VF entries per $iface to be manipulated: ip link set ${iface} vf $vface mac $vfmac The VF is then passed into qemu/kvm and the VM sees the mac address as assigned above ($vfmac): -device vfio-pci,host=81:02.1,bus=pci.1,id=vfnet0 iovctl allows for mac address control of all VFs under an interface at one time - and requires the destruction and re-creation of all VF entries in order to modify a single entry - which breaks existing running VMs. Is there a way I have missed to modify the mac address of a single VF which is presented to a VM? I have tried the following steps. # iovctl -C -f /root/iov-cc0.conf # Create, for instance, 4 VFs agains cc0. # pciconf -l | grep vf t6vf0@pci0:65:0:8: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1425 device=0x6808 subvendor=0x1425 subdevice=0x0000 t6vf1@pci0:65:0:12: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1425 device=0x6808 subvendor=0x1425 subdevice=0x0000 t6vf2@pci0:65:0:16: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1425 device=0x6808 subvendor=0x1425 subdevice=0x0000 t6vf3@pci0:65:0:20: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1425 device=0x6808 subvendor=0x1425 subdevice=0x0000 ccv0: flags=8802 metric 0 mtu 1500 options=66ec07bb (100GBase-SR4 ) status: active nd6 options=29 ccv1: flags=8802 metric 0 mtu 1500 options=66ec07bb (100GBase-SR4 ) status: active nd6 options=29 ccv2: flags=8802 metric 0 mtu 1500 options=66ec07bb (100GBase-SR4 ) status: active nd6 options=29 ccv3: flags=8802 metric 0 mtu 1500 options=66ec07bb (100GBase-SR4 ) status: active nd6 options=29 Note: initial mac 02:00:00:00:00:00 indicating not-in-use and/or available. # ifconfig ccv3 ether 02:22:33:44:55:66 # ifconfig ccv3 ccv3: flags=8802 metric 0 mtu 1500 options=66ec07bb ether 02:22:33:44:55:66 hwaddr 02:00:00:00:00:00 media: Ethernet 100GBase-SR4 (100GBase-SR4 ) status: active nd6 options=29 Ether now shows with new mac - hwaddr the original as assigned by iovctl. Now re-assign the VF device to the pass-thru driver: devctl set driver -f pci0:65:0:20 ppt The VF device can now be passed into bhyve (65/0/20) but the new value 02:22:33:44:55:66 is lost and the prior value 02:00:00:00:00:00 is seen by the vm - but we want 02:22:33:44:55:66. So the new mac is a property of the driver, not the VF. At this point I'm wondering if adding a -U (update) option to iovctl or a new standalone program to target an individual iface/vf pair for update might be the answer. Comments welcome. Thanks, John From nobody Thu Jul 14 20:46:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LkRP43PRzz4T7wX for ; Thu, 14 Jul 2022 20:46:48 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LkRP346vbz3ZXW for ; Thu, 14 Jul 2022 20:46:47 +0000 (UTC) (envelope-from nyan@myuji.xyz) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 536A13200920 for ; Thu, 14 Jul 2022 16:46:46 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Thu, 14 Jul 2022 16:46:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=myuji.xyz; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1657831605; x=1657918005; bh=XZjjUOfCH7 m3bikdYxST1JX3hX2XvPnlwOK30SsXY8k=; b=DMV5PcJmkqR1yzAe+58YFrPJOt jarPxPtvEIowJ1XwcggpsZhk9D9uJE3KTjwWRaDx9i11lPwMhjgZFzuHK5wq7vh+ T5Oe3qROh2abt15ZJWbxxgvr9/14De8GMfi+mc2yo4z6tDKnMWIGLqid/ufZD/uW pgGwyDYzUHqvNFrmkne4imZu4hLYKE/SFUTSBFmWLVNp0lZkqo7r6ZwPQjidXw3M J4JLmUNhAAL5bnGiD+PcrDAXKHFZKPt+fbHUvCG/fwjR85vQ76BjcAWcWsczzeym yMOxfS5MEaafBVnrplZiCD5x8DSbv2mpkv/1SEds6V53BWTH9R76R5JXnNhQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1657831605; x=1657918005; bh=XZjjUOfCH7m3bikdYxST1JX3hX2X vPnlwOK30SsXY8k=; b=OgvBTYLu37/8J6pfhF0q2ll04GkS1sZn7Sqz7W4oxCvG ZAIbfCCBCPt79I3AqhCrZ2URKHkUvshEEd7ZXB/0CXTW0l04iqt3Q7MXZigPe9Fr KPbXPU9OUcxNQL+wyw83AUxig9G5F4DwgjFqRsktgN/WDnxFxU//FcpTm+st1Yrh jZDy38M3Hd6e5BYmAyQ3/h84Uf7dYps77sM2jYumabbpJ9Z6tAAQR4yr1ZhAp5pI nQzGOBS8zbPZ8hRxGwBzhWQN4lupKRo/ub2nW77Zmy1FLcBL+pwdnDgsrOOFm6TZ bvyjmZA51J45oIdyUWDc2DPZfdcS26WgkyJxskvE3Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudejledgudehhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculdefhedmnecujfgurhepof gfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfoihgthhgrvghlucgj rghnucfmrgcuvehhihhufdcuoehnhigrnhesmhihuhhjihdrgiihiieqnecuggftrfgrth htvghrnhepgefguedugfekveegffekudekjeeukedthedtvdffueetleegvdfgffeukedv ueehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnh ihrghnsehmhihujhhirdighiii X-ME-Proxy: Feedback-ID: i9dd946d0:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 80E3D2720078; Thu, 14 Jul 2022 16:46:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-755-g3e1da8b93f-fm-20220708.002-g3e1da8b9 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <01972a40-b8e3-494f-a3ca-a69c20f8fbee@www.fastmail.com> In-Reply-To: References: Date: Thu, 14 Jul 2022 22:46:25 +0200 From: "Michael Yan Ka Chiu" To: freebsd-hackers@freebsd.org Subject: Re: Dynamic VF mac address manipulation / Bhyve Content-Type: multipart/alternative; boundary=058093b9ed0d4b1dbddbc06093576862 X-Rspamd-Queue-Id: 4LkRP346vbz3ZXW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=myuji.xyz header.s=fm3 header.b=DMV5PcJm; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=OgvBTYLu; dmarc=none; spf=pass (mx1.freebsd.org: domain of nyan@myuji.xyz designates 64.147.123.20 as permitted sender) smtp.mailfrom=nyan@myuji.xyz X-Spamd-Result: default: False [-3.59 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; R_DKIM_ALLOW(-0.20)[myuji.xyz:s=fm3,messagingengine.com:s=fm3]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[myuji.xyz]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; DKIM_TRACE(0.00)[myuji.xyz:+,messagingengine.com:+]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEFALL_USER(0.00)[nyan]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --058093b9ed0d4b1dbddbc06093576862 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2022, at 10:05 PM, John wrote: > Hi - >=20 > I am slowly converting a Linux based qemu/kvm solution to FreeBSD > Bhyve where VMs have mac addresses assigned to them. > I have tried the following steps. > # ifconfig ccv3 ether 02:22:33:44:55:66 AFAIK for SR-IOV, the PF driver is actually the one responsible to confi= gure the VF, so setting the mac address via the VF interface cannot crea= te a persistent mac address. > devctl set driver -f pci0:65:0:20 ppt >=20 > The VF device can now be passed into bhyve (65/0/20) but the new > value 02:22:33:44:55:66 is lost and the prior value 02:00:00:00:00:00 > is seen by the vm - but we want 02:22:33:44:55:66. So the new mac is > a property of the driver, not the VF. >=20 >=20 > At this point I'm wondering if adding a -U (update) option to iovctl > or a new standalone program to target an individual iface/vf pair > for update might be the answer. >=20 >=20 > Comments welcome. >=20 > Thanks, > John I=E2=80=99m just thinking out loud here. I have work on similar tools an= d have some thoughts on how to make VF more manageable. For example cur= rently there=E2=80=99s no way to really tell the pf of the vf actually b= elonging to, this is especially an issue with Sriov enabled nic as you c= an=E2=80=99t keep track of the physical port number. I think maybe a different ppt like driver (let=E2=80=99s just call it io= v for now) can be useful. Maybe with this iov device, we can have the P= F driver to register some hooks to reconfigure specific VF, show the top= ology between PFs and VFs and even allow dynamic creation of VF if the P= F driver can somehow support it? Best, Michael --058093b9ed0d4b1dbddbc06093576862 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 14,= 2022, at 10:05 PM, John wrote:
Hi -

I am slowly conve= rting a Linux based qemu/kvm solution to FreeBSD
Bhyve whe= re VMs have mac addresses assigned to them.
<= br>
I have trie= d the following steps.
# ifconfig ccv3 ether 02:22:33:44:5= 5:66

AFAIK for SR-IOV, the PF = driver is actually the one responsible to configure the VF, so setting t= he mac address via the VF interface cannot create a persistent mac addre= ss.
devctl = set driver -f pci0:65:0:20 ppt

The VF devic= e can now be passed into bhyve (65/0/20) but the new
value= 02:22:33:44:55:66 is lost and the prior value 02:00:00:00:00:00
is seen by the vm - but we want 02:22:33:44:55:66. So the new mac= is
a property of the driver, not the VF.

At this point I'm wondering if adding a -U (= update) option to iovctl
or a new standalone program to ta= rget an individual iface/vf pair
for update might be the a= nswer.


Comments welcome.
=

Thanks,
John
I=E2=80=99m just thinking out loud here. I have work on similar = tools and have some thoughts on how to make  VF more manageable. Fo= r example currently there=E2=80=99s no way to really tell the pf of the = vf actually belonging to, this is especially an issue with Sriov enabled= nic as you can=E2=80=99t keep track of the physical port number.

I think maybe a different ppt like driver (let=E2= =80=99s just call it iov for now) can be useful. Maybe with this  i= ov device, we can have the PF driver to register some hooks to reconfigu= re specific VF, show the topology between PFs and VFs and even allow dyn= amic creation of VF if the PF driver can somehow support it?

Best,
Michael

--058093b9ed0d4b1dbddbc06093576862-- From nobody Fri Jul 15 13:16:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LksMc56xKz4Wf4h for ; Fri, 15 Jul 2022 13:17:00 +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 4LksMb1r7Mz3stG for ; Fri, 15 Jul 2022 13:16:59 +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=WglcBYv+oJeSAReN9qA6+UNQ3pxD9djV3WjBwkxFNx0=; b=v+qei/ytn/We+iGugmKoruyUDo z1E1Rxwxtk8aVSM7qKh3BjHVevYCxmtWlWBmriBiuuBDM82LIq9i+ENsGnFKj21tRZHJd14B7Qo37 cfio6UNOQUo2jSHjaAqtfq0kD/9DpUzZ0b7NjZRZ3Kzr/EAy2KqUYCCtv2LNd5IwiB1+9kPVskBAq qphpo3GD/5hDGMfASB7QWfOODbcBDr68kt6dAEHqwe/bn5JZwbl8I6xl33YOu3cCy5iJICqXoJI8w M2coR4+2cKp2S3NBpEXjZKYL8c2hCOy+iM01bIWspmbPOF9j5GVcsDfgm/lLmcgVHDg0dOM+o35DQ oqYnUu4A==; 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 1oCLBh-0065jT-3V for freebsd-hackers@freebsd.org; Fri, 15 Jul 2022 15:16:57 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1oCLBg-000Ft0-Lm for freebsd-hackers@freebsd.org; Fri, 15 Jul 2022 13:16:56 +0000 Date: Fri, 15 Jul 2022 15:16:56 +0200 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wmry544psttv7pxp" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20220429 X-Rspamd-Queue-Id: 4LksMb1r7Mz3stG X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b="v+qei/yt"; 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 [-8.80 / 15.00]; SIGNED_PGP(-2.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[palmen-it.de:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --wmry544psttv7pxp Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Daniel O'Connor [20220714 20:57]: > That's the plan but if you want to test it you should be able to clone > the repo [...] I tested it, successful so far as it seems! Thanks again! My usecase is a 14-CURRENT VM I mostly use for testing ports with poudriere. It's only running when needed (cause it hogs quite some RAM) and still I want the logs always available. So far I used NFS for that which had some performance issues with ports producing *lots* of output like e.g. gcc. Now it's using 9pfs instead \o/ =E2=80=93 will see whether this improves performance. ---- For reference (if anyone else wants to give it a shot), here's what I did so far: - fetched your branch into my local src repo, rebased it onto main - rebuilt and reinstalled the system - tried to load the modules, noticed they're not yet included in recursive build (remind me to add that, hehe), so manually did make / make install in their dirs - added virtio_9pnet and virtio_9pfs to kld_list in /etc/rc.conf - couldn't figure out how to use it with fstab, so added this stupid little rc script: /usr/local/etc/rc.d/mountvirtfs #v+ #!/bin/sh # PROVIDE: mountvirtfs # REQUIRE: DAEMON # BEFORE: LOGIN =2E /etc/rc.subr name=3D"mountvirtfs" desc=3D"mount VirtFS shares from host" start_cmd=3D"mountvirtfs_start" stop_cmd=3D":" mountvirtfs_start() { mount -t virtfs -o trans=3Dvirtio logs /usr/local/poudriere/data/lo= gs mount -t virtfs -o trans=3Dvirtio html /usr/local/share/poudriere/h= tml } run_rc_command "$1" #v- Well, it works! # mount | grep virtfs logs on /usr/local/poudriere/data/logs (virtfs, local) html on /usr/local/share/poudriere/html (virtfs, local) 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 --wmry544psttv7pxp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmLRaMMACgkQPvKLCrwC 2irI5QgAjk2pO7u9nPm6Gelpi4xuuJvE7+VNMJGgcT1aik9dd7PcAFZrB6ECmWpV qYZxinxazNtAwDftOPJX2jy4mmnXOpGRjNriDKJWohYYSHsJBETh1RxZBk74DDZV WYTDj7TNPI+HKt3pFBCQOkSK6O4xOyzJstApl/Y9WDGbFRHDJ10e4FXCWuUYt7Rj 8ebMKxdFqEwkChovLGoLiyg7ruvKjAWF32lRi20Hkqnckbh3o/fxy/1s2ejNPF6N AVXHXb48+3evwPoLmlc7rHVwHMHrgahZaawfWCGtLaLtZcrZV3quzU0OfrVOOfBc U1gsy/Xxpd4Dz50wuZWO038tm1bXJA== =7d6n -----END PGP SIGNATURE----- --wmry544psttv7pxp-- From nobody Fri Jul 15 15:15:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lkw003CcRz4WsX9 for ; Fri, 15 Jul 2022 15:15:12 +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 4Lkvzz3vmrz460t for ; Fri, 15 Jul 2022 15:15:11 +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=Bq22xKV7sodqCUu+teyRgEEyuCW+AtWpkt/muK/Nmf0=; b=wk8WV+u4AQxK+Hof+jIjRgyp6H 2+Y5zxe3cmH1ZJtVTWRU+gIVYVT0Vv7noVxxn9cmqKRgBKY1S955tY0xL6E1x/SaVfBeS5bGy7DSx 42ZUWldVgM07fJTadZyesEZg5zf220UEhxq4vzovg2FakNET6SxQgwJgDTaZY0fs7L1euyPGK2y9t fw4x9n57TGOKW80u+BOXqJhHHcS/kbVbWfT/Bj+FRBEb4EaJtlno1QAMb3MX4FMspKSImP1SKqZLT 0nlX0L0jTycbN+lhSBggkujEHJYcUPutZaLry2ZiWbL53+dxitWemjb2ocM12KLG6vn6OMAYl8tnt X5KQMeoA==; 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 1oCN25-0065zw-RP for freebsd-hackers@freebsd.org; Fri, 15 Jul 2022 17:15:09 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1oCN25-000Goh-GY for freebsd-hackers@freebsd.org; Fri, 15 Jul 2022 15:15:09 +0000 Date: Fri, 15 Jul 2022 17:15:09 +0200 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6hr2x3ftkkwa7rx4" Content-Disposition: inline In-Reply-To: <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> User-Agent: NeoMutt/20220429 X-Rspamd-Queue-Id: 4Lkvzz3vmrz460t X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=wk8WV+u4; 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 [-8.80 / 15.00]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1:c]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[palmen-it.de:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --6hr2x3ftkkwa7rx4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Felix Palmen [20220715 15:16]: > I tested it, successful so far as it seems! Thanks again! Unfortunately, it doesn't work reliably yet. Trying a testport with poudriere logs mounted via virtfs, I got errors like these: #v+ /usr/bin/awk: can't open file 14a-default/2022-07-15_16h43m01s/.poudriere.j= ailname input record number 1, file 14a-default/2022-07-15_16h43m01s/.poudriere.ja= ilname rename: /usr/local/poudriere/data/logs/bulk/14a-default/2022-07-15_16h43m01= s/.tmp-.poudriere.snap_loadavg.OV0Gxx2m to /usr/local/poudriere/data/logs/b= ulk/14a-default/2022-07-15_16h43m01s/.poudriere.snap_loadavg: Invalid argum= ent _mktemp: mkstemp failed on 14a-default/2022-07-15_16h43m01s/.tmp-.data.json= =2EstpmwmGg: Invalid argument mapfile_write: Missing handle #v- after that, the mount is somehow broken: # ls -l /usr/local/poudriere/data/logs/ ls: bulk: Invalid argument So, probably it's back to NFS *for now*. Still the best attempt I've seen so far, all others I tried crashed the kernel on mount ;) 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 --6hr2x3ftkkwa7rx4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmLRhH0ACgkQPvKLCrwC 2ioXmQgAhI495TGD8XGQ8hT8n0KLxJtpFocjlx/Sb+5TdCaT/7zK1ZtExSiT9qvu fQv1+EuXfCN1DXRgLeHAtwT5nsyjJLbjSauJ+Vzepq3cfG5iSC8rXEt4oujHHaSY tnCIRsh5/Dluz1QBFcdUoos+p4qmLB96NAVpeAuQivMdtpwGkwLkjf9Gg/liRiO8 HzDvD1wfZR2eeUIIISMC1Gg/vAhYM9GKECQ+F322rgPE+gQSw9RcJY0ZGVvGKgtW 2psJBiS/WqfrXzC6Ijzo7QdxY/lF4SkNnfrUmFRdJ3leADp55ZNQprACj/Me6WjN eo1sn9tp5dHGj7IbrT2NZEvs1WlVpw== =CXqv -----END PGP SIGNATURE----- --6hr2x3ftkkwa7rx4-- From nobody Sat Jul 16 13:40:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LlTrR6sxSz4WYY4 for ; Sat, 16 Jul 2022 13:40:39 +0000 (UTC) (envelope-from daniel.lovasko@gmail.com) Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LlTrR046Qz3NXW for ; Sat, 16 Jul 2022 13:40:39 +0000 (UTC) (envelope-from daniel.lovasko@gmail.com) Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-31c89653790so69676147b3.13 for ; Sat, 16 Jul 2022 06:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=0BZHQGS+ADjrDXswejVpKSGklIxE5z2vbgJI/x93uD0=; b=hNM09DHUJvymQfX1+Qiq2LPqpRoeOQpC17+Tto1WYF+v7FH45IxhF21Us9UxB++fDn rRuasVMGEOEHY6FxyfS25ydcg5Qk9hq6UfUfchS/qatRPmnHxS9diqfXuENjqBwDDIQl 8SsEYGFq1kaYTe2efKNSAIbTJVSQD6OeT7eeXepu25hn00WejAyGlrDTecgORz5mtWMY 2DuXjkpqRO4YRlbtrodxkNr+lmk4YIgvGCOcxSjQ6u9Xr5BvUNL6vhQrJ+DqGgVKMemM 2BwyuwjKkaaq8gHxuI1iSYXkVJ6BZCZopMJtQDFq1xywp13CWYhln3jBOp5Tya9o1F9m RAng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0BZHQGS+ADjrDXswejVpKSGklIxE5z2vbgJI/x93uD0=; b=631vmai/vI3OBfNygyjsFQHprG1rbKHI7cVhElEmhDSuiX/hodOqS8YrACj67G0u1w O9O2gdF1qep9gn9vUcHR4DLQxvs0a2PP06zeuEJKdTSbcnm4PoaZXuw+Z6qszP/NIntT 5L99ZqSvyLVrzkqKwlkXYURLyrIGIVWI7sxNKyJiNLcKbsFqtDaNeU6ma92W7kCHDfe/ 1YPWuLM9OtMXdjAHFlcE1p4nSeHl4rHk59l+EADgSlYj0lqb/wZb7N2wMUZ9yH25BrQx Rd3GJ1wlR/9LCCXUFJZNSZme/q8A3FMV9r9KaoMI0+SUoq9LsTXICTl1HFSq0lj85bv5 d9pQ== X-Gm-Message-State: AJIora+wrTI9jn57zXdB90bZdGCCum8HRtx6K6cSLfhS5PS2ik2XGLPc lsrxpkFhfWPVY2zQiuMK0rdIhNKb8kd4FwH/TjkXu1JlIaIn X-Google-Smtp-Source: AGRyM1uxCVwHDw1+6KMVIo01/LqjUAIpcy9JgZXCubE0EY8eCmCfFYsQ5Y1Q0cYq+RlyJg5BdXHrtJLXMTf1YU27o4Q= X-Received: by 2002:a0d:c2c1:0:b0:31d:6b53:bc02 with SMTP id e184-20020a0dc2c1000000b0031d6b53bc02mr20707132ywd.402.1657978838063; Sat, 16 Jul 2022 06:40:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Daniel Lovasko Date: Sat, 16 Jul 2022 15:40:27 +0200 Message-ID: Subject: NanoPi Fire3 u-boot To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LlTrR046Qz3NXW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hNM09DHU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of daniel.lovasko@gmail.com designates 2607:f8b0:4864:20::112f as permitted sender) smtp.mailfrom=daniel.lovasko@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.989]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::112f:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hello all, I purchased a few NanoPi Fire3 [1] boards and would love to run FreeBSD on them. I see that there are u-boot packages for a number of NanoPi boards, but Fire3 is not included. The CPU involved is "Samsung S5P6818 octa-core ARM Cortex-A53". How would I go about decoding the necessary partitions and sizes to get this running? I found this repository [2] that contains some scripts, but I am unable to decode the required details. I am happy to experiment a bit to get this running, and we could create the resulting package as well. Many thanks in advance, Daniel [1] https://www.friendlyelec.com/index.php?route=product/product&product_id=206 [2] https://github.com/friendlyarm/sd-fuse_s5p6818 From nobody Mon Jul 18 01:48:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LmQ4W51Ztz4WnTt for ; Mon, 18 Jul 2022 01:54:19 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LmQ4T4C1Jz3pw0 for ; Mon, 18 Jul 2022 01:54:16 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 26I1mtBR089779 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 18 Jul 2022 11:19:12 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1658108957; bh=KJpu2o5f4gPObDtN6FlGb1p1+DCXoWssyMdDfVb7KKg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=rgoj/OC2zm6iro0gROo44l9rK8Ec5YkcfHyuJOBy42Jx8/nx1SauD00ogy8aGnzj/ uyEjeh9n8ZLnvVDW3us/eXSqBXfwy8HXMedCjv+AWWF3cPFlgclHhWAl9mCQmCAv2B G/qx0NMA+JociJSjlFEPcSmSQ9fYQ7pf0fPzpigQ= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 26I1mbuD089773 for ; Mon, 18 Jul 2022 11:18:37 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2001:44b8:1d2:8900:18eb:b660:6778:2efb Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:18eb:b660:6778:2efb] [2001:44b8:1d2:8900:18eb:b660:6778:2efb]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 26I1mVUl089765; Mon, 18 Jul 2022 11:18:37 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\)) Subject: Re: VFS mount rollback for virtio 9pfs From: "Daniel O'Connor" In-Reply-To: <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> Date: Mon, 18 Jul 2022 11:18:31 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> To: Felix Palmen X-Mailer: Apple Mail (2.3696.100.31) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4LmQ4T4C1Jz3pw0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b="rgoj/OC2"; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 16 Jul 2022, at 00:45, Felix Palmen wrote: > * Felix Palmen [20220715 15:16]: >> I tested it, successful so far as it seems! Thanks again! >=20 > Unfortunately, it doesn't work reliably yet. Trying a testport with > poudriere logs mounted via virtfs, I got errors like these: >=20 > #v+ > /usr/bin/awk: can't open file = 14a-default/2022-07-15_16h43m01s/.poudriere.jailname > input record number 1, file = 14a-default/2022-07-15_16h43m01s/.poudriere.jailname >=20 > rename: = /usr/local/poudriere/data/logs/bulk/14a-default/2022-07-15_16h43m01s/.tmp-= .poudriere.snap_loadavg.OV0Gxx2m to = /usr/local/poudriere/data/logs/bulk/14a-default/2022-07-15_16h43m01s/.poud= riere.snap_loadavg: Invalid argument >=20 > _mktemp: mkstemp failed on = 14a-default/2022-07-15_16h43m01s/.tmp-.data.json.stpmwmGg: Invalid = argument >=20 > mapfile_write: Missing handle > #v- >=20 > after that, the mount is somehow broken: >=20 > # ls -l /usr/local/poudriere/data/logs/ > ls: bulk: Invalid argument Hmm fun! :) I did copy the tmpfs tests but they are mostly basic functional tests = rather that exercising race conditions and the like. > So, probably it's back to NFS *for now*. >=20 > Still the best attempt I've seen so far, all others I tried crashed = the > kernel on mount ;) Thanks for testing it, I will try some more intensive tests. Which hypervisor are you using BTW? -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Mon Jul 18 06:53:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LmXjL2Jfpz4WVM4 for ; Mon, 18 Jul 2022 06:53:10 +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 4LmXjK0lkgz4Bq8 for ; Mon, 18 Jul 2022 06:53:09 +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=CNHTTexlUxwrqCpojity3ST9HOjIDs7NsLS1CI3MzGM=; b=a6T5sjbLkKgQYO/JAv+KXTdbdm Fl0SEvv8g/t+QB5jP96eUybBotc0Hfl0+/VyJLMwTFCFqc9LfGkl3jIDCviBwK5fA3oAUMZyKXBfa bWNi/nRpoUQHhjRDZpQSbRDeETNljUmS9KXF5FwztKEYBO8njTM5jyjeM2pwpm4LG/k5ksc1P8M40 oJ6AKXKNuWW1qKkJ741AJ6xewd+eO64ETmnTv2Vp6ioBtNKjpkwmrKNCW+yyxaks9vXD9dUFoFmMr q4ElEMTwra7rYYrTD+rLXA8YGlI1s8CojOboye59C+S9ITsdITWL2WMIQ/5YAPUVyYizPadosNUj2 WI6+I5DA==; 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 1oDKcr-006IyO-Kb for freebsd-hackers@freebsd.org; Mon, 18 Jul 2022 08:53:05 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1oDKcr-000PdU-8d for freebsd-hackers@freebsd.org; Mon, 18 Jul 2022 06:53:05 +0000 Date: Mon, 18 Jul 2022 08:53:04 +0200 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: VFS mount rollback for virtio 9pfs Message-ID: <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@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: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zn227pzumht4mt57" Content-Disposition: inline In-Reply-To: <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> User-Agent: NeoMutt/20220429 X-Rspamd-Queue-Id: 4LmXjK0lkgz4Bq8 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=a6T5sjbL; 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 [-8.80 / 15.00]; SIGNED_PGP(-2.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[palmen-it.de:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --zn227pzumht4mt57 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Daniel O'Connor [20220718 11:18]: > Thanks for testing it, I will try some more intensive tests. > Which hypervisor are you using BTW? That's bhyve on 13.1-RELEASE. The vm has 6 vcpus. I didn't test with a 13.1 guest though, only -CURRENT. Maybe poudriere is a good manual testcase (it's doing lots of filesystem ops on logs) ;) 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 --zn227pzumht4mt57 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmLVA0oACgkQPvKLCrwC 2iqs8Af/RFC1TVUg/CHyb2nt2kREnjyJKUpadt0cexAahLK0Rq3FogTy3IbKG7gE h9Snqb6xN2YES4KujlRvGQmk0gPLKGIIc/MTFrM+2hszGZwAR9Y/cUsxQzEwrXCJ DnwrzHFklSyzWlCN/nnOTHXh1LzazTSjLaDcZ7sDgLMzcy68lkE33BK6VXQQTtiR hBtjidRfLRdRtPMrvhw6tuSFUyQOzR08x1J0pN8J6uWktmIK692HjQj6iZhZHCe/ 5xEU/fM487T0EvmJWP6bTfuX0iaYSX+SYivHhIo7ot+f/5vMBcuEDWuzqtivLMDr WPbPCIOI/KLpqtuGaXjcLxsoLZpWEQ== =mpwG -----END PGP SIGNATURE----- --zn227pzumht4mt57-- From nobody Mon Jul 18 07:00:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LmXtb757xz4WVxQ for ; Mon, 18 Jul 2022 07:01:11 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LmXtb0YSFz4DXq for ; Mon, 18 Jul 2022 07:01:11 +0000 (UTC) (envelope-from arka.sw1988@gmail.com) Received: by mail-vs1-xe29.google.com with SMTP id s1so9572292vsr.12 for ; Mon, 18 Jul 2022 00:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Akd6e2wxCVtM6oE1vKXJWDghFwyxOqVNFNWOqqhRZVM=; b=MFbv/TIr9w18mPgGerMuNYylwc/VqZNBrjQz+gPadiiK8Ere8QZLSxt7cQM3w0zLWb /bvrcQ43jsEVagjQ7EvYupfwDgm/Y3OHuDSwvH2ixi4K6b/Wj5XJLDi+oZN+ZflWujou bQeEgk0uAuMRqk+qA1gfuJfyaubmOBQvWH0sAvMSU6fekmm3uO5PD+Mky/m6FHti5pVQ oA871vXFByzeSSF7n1aKw48OjE8D41dC2FP1voDMkzgVCHbZH1EbbqjtueMDUHoMEgb3 BRtHqF/6au+UqHHCmd+IqWeRN08Dyk4H9A8FpvueoJFdnU8jSvcU0JEq7fbbaiFSNzNT bPJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Akd6e2wxCVtM6oE1vKXJWDghFwyxOqVNFNWOqqhRZVM=; b=EDMKqrK1Fjql9zEwBly6ytvsZFWoymweerYXv4jAUnUhMXXkEe/h+9e61/9Dj+WWVm QaVHm/i5yWh/Pmxvh97ekTjiCUwc/xUzJiGbw6WgJtEsCx0caRDxoIXO5WvBW0pb6Txu 5Bo2Lq/cFrZESKPSWu/HgeRFcR6OLXSNAzqFVAoeQKCysK8qAvmAtSNZFfGN3UU/ysFO 34D8o7jbxeTgdkssWBZZ7m1gxMSmJK98l7LFuMQZQPRoD/G7X7buDOiEtF1Z8SW0e1kK bMELXbtX7obq9Fm5o3fkaES6Ge5Pb+37wiVNUwRMpM0y8EaC1xkN2ynkBEqASy9NfUsx ddwg== X-Gm-Message-State: AJIora8SWWu/ydfAtyGVK5ALls5RXD3Wo2RFAy3OeL0Gxw6oms3ukSvv F2zdITQBObU1RwMqSCvtQLGLRSspI87j/vrQHa6dyhgqVO8= X-Google-Smtp-Source: AGRyM1vbg5PUKrxGPfO7fCPlyqiHkX2el2CJxZUiJrMiNy2dnnbStqh2JWOpQ+duEwEqH3Ey3kdNDbZQ1AKG/beCwBU= X-Received: by 2002:a05:6102:216:b0:357:1810:99c0 with SMTP id z22-20020a056102021600b00357181099c0mr8110434vsp.41.1658127670286; Mon, 18 Jul 2022 00:01:10 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Arka Sharma Date: Mon, 18 Jul 2022 12:30:59 +0530 Message-ID: Subject: Private resident count in procstat(1) To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c79dbc05e40eee26" X-Rspamd-Queue-Id: 4LmXtb0YSFz4DXq X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="MFbv/TIr"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of arka.sw1988@gmail.com designates 2607:f8b0:4864:20::e29 as permitted sender) smtp.mailfrom=arka.sw1988@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.94)[-0.940]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e29:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000c79dbc05e40eee26 Content-Type: text/plain; charset="UTF-8" Hi All, I tracked the PRES field and observed that 'kve->kve_private_resident' is the count of vm_page contained by vm_object if the vm_map entry doesn't contain a shadow object. My question is why this field is called private resident as I understand the underlying vm_object will also contain pages which correspond to other map entries for the same process, and for shared mapping it could be referenced by map entries with other process as well. For the RES field my understanding is, it is the sum of pages of shadow objects and the tail of the object chain for the range of the given map entry and we also have 'ki_rssize' which is 'pm_stats.resident_count' plus the sum of kernel stack pages of the threads. Is there a situation the RES value will be greater than 'ki_rssize' ? Please correct me if above understanding is wrong. Regards, Arka --000000000000c79dbc05e40eee26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I tracked the PRES field and ob= served that 'kve<= span style=3D"color:rgb(0,0,0);font-family:Consolas,"Courier New"= ,monospace;font-size:14px;white-space:pre">->kve_private_resident' is the count of= vm_page contained by vm_object if the vm_map entry doesn't contain a s= hadow object. My question is why this field is called private=C2=A0resident= as I understand the underlying vm_object will also contain pages which cor= respond to other map entries for the same process, and for shared mapping i= t could be referenced by map entries with other process as well.=C2=A0

For the RES field my understanding is, it is the sum o= f pages of shadow objects and the tail of the object chain for the range of= the given map entry and we also have 'ki_rssize' which is 'pm_stats.resident_co= unt' plus the sum of kernel stack pages of the threads. Is there= a situation the RES value will be greater than 'ki_rssize' ?

P= lease correct me if above understanding is wrong.

= Regards,
Arka
--000000000000c79dbc05e40eee26-- From nobody Mon Jul 18 12:20:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lmgyl193Dz4Syvl for ; Mon, 18 Jul 2022 12:20:15 +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 4Lmgyk40zKz3Vky for ; Mon, 18 Jul 2022 12:20:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 26ICK7Ut029470 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 18 Jul 2022 15:20:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 26ICK7Yg029469; Mon, 18 Jul 2022 15:20:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Jul 2022 15:20:07 +0300 From: Konstantin Belousov To: Arka Sharma Cc: freebsd-hackers@freebsd.org Subject: Re: Private resident count in procstat(1) Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: 4Lmgyk40zKz3Vky X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.07 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-0.08)[-0.079]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_XAW(0.00)[]; TAGGED_RCPT(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 18, 2022 at 12:30:59PM +0530, Arka Sharma wrote: > Hi All, > > I tracked the PRES field and observed that 'kve->kve_private_resident' is > the count of vm_page contained by vm_object if the vm_map entry doesn't > contain a shadow object. My question is why this field is called > private resident as I understand the underlying vm_object will also contain > pages which correspond to other map entries for the same process, and for > shared mapping it could be referenced by map entries with other process as > well. > > For the RES field my understanding is, it is the sum of pages of shadow > objects and the tail of the object chain for the range of the given map > entry and we also have 'ki_rssize' which is 'pm_stats.resident_count' plus > the sum of kernel stack pages of the threads. Is there a situation the RES > value will be greater than 'ki_rssize' ? > > Please correct me if above understanding is wrong. The definition of the resident and 'private resident' per-process count are quite arbitrary. I do not think it is possible for Mach VM to have a single definition that would serve all desired uses. Whatever the algorithm to calculate the values is chosen, it should be good enough for common case, while not penalize corner situations by too consuming computations. For instance, if we have a shadow chain behind the top object, should the resident pages in the objects below the top accounted to RSS? Should shadowed pages be accounted, and if not, where their count should go? They do consume memory, leaving less pages available to the rest of the system. On the other hand, if we account them to each address space that this shadow participates in, we would do over-accounting. Another issue is that it is not possible to determine fast if the mapping is shared, or truely shared. Imagine MAP_SHARED anonymous mapping in the process that never forked. Or tmpfs mapped file with no other mappings. In all that cases formally the mappings are shared, but it is very hard to prove that there is no other mappings. More, there are at least three places that look at RSS in kernel: - the pure userspace reporting in kern.proc.vmmap - OOM code that looks for the largest process - swapout code that selects a process to swap out Each place that (slightly) different definition of the residency. From nobody Mon Jul 18 20:08:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LmtML0x2sz4X3Vs for ; Mon, 18 Jul 2022 20:08:46 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LmtMK0SVtz3mRF for ; Mon, 18 Jul 2022 20:08:44 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: (Authenticated sender: daniel.engberg@pyret.net) by mail.gandi.net (Postfix) with ESMTPA id 04A5B1C0006; Mon, 18 Jul 2022 20:08:39 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 18 Jul 2022 22:08:39 +0200 From: Daniel Engberg To: Daniel Lovasko Cc: freebsd-hackers@freebsd.org Subject: Re: NanoPi Fire3 u-boot In-Reply-To: References: Message-ID: <96bd4c824caad015b0a6621a94a22b00@FreeBSD.org> X-Sender: diizzy@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LmtMK0SVtz3mRF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 217.70.183.197 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[217.70.183.197:from]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[diizzy]; R_SPF_SOFTFAIL(0.00)[~all:c]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-07-16 15:40, Daniel Lovasko wrote: > Hello all, > > I purchased a few NanoPi Fire3 [1] boards and would love to run > FreeBSD on them. I see that there are u-boot packages for a number of > NanoPi boards, but Fire3 is not included. The CPU involved is "Samsung > S5P6818 octa-core ARM Cortex-A53". > > How would I go about decoding the necessary partitions and sizes to > get this running? I found this repository [2] that contains some > scripts, but I am unable to decode the required details. I am happy to > experiment a bit to get this running, and we could create the > resulting package as well. > > Many thanks in advance, > Daniel > > [1] > https://www.friendlyelec.com/index.php?route=product/product&product_id=206 > [2] https://github.com/friendlyarm/sd-fuse_s5p6818 Hi, Unfortunately there is no support for this SoC and to my knowledge no planned development. Questions related to arm are recommended to be sent to the arm mailing list. Best regards, Daniel From nobody Tue Jul 19 06:31:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ln89Q4N8jz4WTCc; Tue, 19 Jul 2022 06:31:06 +0000 (UTC) (envelope-from weh@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020019.outbound.protection.outlook.com [52.101.128.19]) (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 4Ln89P31q5z3hhy; Tue, 19 Jul 2022 06:31:05 +0000 (UTC) (envelope-from weh@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A4/3W9l5HJ+nQy9RIXt0Jhs26qQsWCmrPBYCGa5RWO1R/Id/1fHBRIjsg11Sp1aIQtLEpaTW0TniZta0ac0XD/Hr1ZTMuEaV9I/k2ggmnFlzGQJSAvp81QvJHmdSjcr4gL5zOLqXitFA6QPVK1Uysv6hMtPo6s+b0iSfMEJvSGHqy/ioG4THuRYLxD7zVB2L578u1cXnexjZiOyBvIZGoY0cRskfTDyAXwp00KIHNcUFaVkB36gzQNfKdeUgQhBNdvMbUJTjE72R/rEwEn0KLhVZRyiI6Kv5g3VuQzk7lwiSOjRT6VEcxCwx+B5Ty+jQD421xcXx2b5GBW6jAsDf8Q== 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=ygw8DZ3NDhyzwSCswHIWplwHVuEw/g4LpkZ0rVumBtY=; b=M5Z76ZLBvV2tpuVQSNaB8aL2OTIyBxkcUv4pKqilx/Y+JXDcc87CPkTZ41pPKB4q5XH0CCmDiXiijbJkFAszGNRm5RSh/3gsYthehK3ruPMz3OIGw1VjGJ0rWjzchcPIerzUcoXSYChkYnMyCsmkjASaUup14TsK+9HueeUQgS9ft7xp90IkEm/3fzatU+6XF1YA/PIiEh9me+fOPAT+B9U/bCRz/WitGAam1uI1Z66f5PcFzvhXipoOa0ZjiEr3vCNVGUIpgbyjZ8uYuSCoiqB/4aHS/Uppu90QtO/0ir+NEZtEq50AsOCyDWEV3F/ln35MiN8rxftbQMsKAZvJKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ygw8DZ3NDhyzwSCswHIWplwHVuEw/g4LpkZ0rVumBtY=; b=SVlLZawSIAFRy/tZmaGj9hlAja5IB6f6W67t6eQ3qmGCKVZSZ/MA7Ibqayw3bTDAfOfHqzvw5Wkm1kPoPye4ZmSpF+E/9221zvk+DB2ZAyMZMhIElD+KeRrZJkMuoZiizNVwnPVMCoX61oyXO+61qxTKlwUHstOtN+QkeQnWrHw= Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM (2603:1096:4:fc::7) by PUZP153MB0633.APCP153.PROD.OUTLOOK.COM (2603:1096:301:e6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.0; Tue, 19 Jul 2022 06:31:00 +0000 Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::30fe:e371:c3a9:4d3c]) by SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::30fe:e371:c3a9:4d3c%5]) with mapi id 15.20.5482.001; Tue, 19 Jul 2022 06:31:00 +0000 From: Wei Hu To: "freebsd-arm@freebsd.org" , "freebsd-hackers@FreeBSD.org" CC: Li-Wen Hsu , Souradeep Chakrabarti , "andrew@FreeBSD.org" Subject: UFS checksum error during arm64 VM installation Thread-Topic: UFS checksum error during arm64 VM installation Thread-Index: AdibNk5aqz8/PSh4TQaFvv/Uzh2qRw== Date: Tue, 19 Jul 2022 06:31:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5bdf1bb0-06c4-4ba3-991b-58a1d2b90326;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-07-19T06:05:59Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34b9f111-eed1-40f4-3e9f-08da69503efb x-ms-traffictypediagnostic: PUZP153MB0633:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 184zO+fwl3yN3hja0l+CCFd/T76tjxf96ZQ9RyOVE38vfXxyRZPm8Bq0FyEr4GPKkPSYfJDNZHI2NUQmpdHfg1pADAKYFiI+EdrAe6F6hHmGGai5SJ3whbL8tHIjBFwQkHznWnsNtjM2v+JmiX1VJXH91TCyQaOYhJD0WehTkz14a2pRv9ReLj6tXzXrnbVLS51d88AseFXEejeUCt/z+iKZeLqqhWSanApTMQtSHTATlqnnBojosQuYBDeeR4JVj/7eFBPplnPov/ZPHGap0052rb4qteMOnwAN1W8ifdk1tYz1C5zGH6NtrEQqzF+z66pWaLDrxHvsa4tAeWr3YUPH8xJJ22FzyixCjGgdTjOyLxu/0SUUZMYW2fgC0TcmHt7Pdv86g38+1BaFm5t971EP8rTrHhSsOCd4BjaCHivpL9uVpxBFLt04ed81RhfjuxGhbHUuWhCuSzTKamgmEGVBufmburgdlYqTNMXZCGPbOLnb+RzmX/wMtI+w0X0NmmIHbf+/klBpEnQnI3aly35SCGMDCuZkMAMLy7fIOEfF38Z2qo7/6IKYpf2hrCnCK7UdPBkDEbr56dizoApETL+JtY3RmyZ5Ww4Cj4cT+uI0ufU6pkLPmquZW/PFd7RgoS8NckegocLXNZq80AKSK8784z8Nr39JHGWJ+JgePNUO8FbA9/GKrf4kDHnEmQeZ0S7b+xHG35HOLge4a3JG0MLblD2FrJoaUMlP8dqdB7c+ITdLrk495FkvcccX4N8+QRM5Adt3OSjigqzJjyiO3N9mccAoLp16rrHDE2Xhmi4Sdm5Pu5a5V4Fyb4NUybhHwbNzlId/LIeNgMr4R8dMzLsOzw/LoJXTOLag1Vlj8Ik= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SI2P153MB0441.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(396003)(346002)(39860400002)(136003)(376002)(451199009)(10290500003)(38070700005)(82950400001)(82960400001)(71200400001)(86362001)(8990500004)(478600001)(7696005)(6506007)(316002)(122000001)(26005)(4743002)(450100002)(54906003)(110136005)(9686003)(186003)(64756008)(76116006)(66556008)(66476007)(5660300002)(55016003)(52536014)(66946007)(8936002)(8676002)(41300700001)(66446008)(33656002)(4326008)(38100700002)(2906002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?EHrHsG88PD76NvytDk3lni5Xg66tkNR5RKqt0q1ZvdJIHszRrRBVC+azsSTF?= =?us-ascii?Q?+Of9S39/BIOH99cTjIgNszEofgwR7mFMvfzZby7IEiHOzu2J3GkAOjtxwEav?= =?us-ascii?Q?zmi4MtzWOSrYbIkL+qejfDWKf2XIsXwHJgDARPA7yd5i+Rt67Sbs/QjXwdIM?= =?us-ascii?Q?JgtmOoBpwxS35G3p50MVmA71gDv8LtvrR05quHD+UTS4ZQOHZHYbCXCHwy1f?= =?us-ascii?Q?xEmBB3QHckXP9sWx+hKgxt3y1ZoqTqiUIm30BH7ENWmOuLU9t2mXm53nt3zV?= =?us-ascii?Q?aJSd6Y8OnAcpzewSt8vSb6Aso6F6Xe1VD3uWWhEMymw366T+96kNJ+W1EjM8?= =?us-ascii?Q?515W5IFwwEtapab6ZFogY18LRs0tIeiclMdAWyD+ITqgKGhZ/+JyjzhgDYoU?= =?us-ascii?Q?er+vssQyl4iHRkqtNxXzIsBwSUfOvoNZk9Tc+scxoCyI8bXBPWl82lublSW6?= =?us-ascii?Q?aTjOyCnMpvZV89f4ELfJ71cTJc+jSskofuYZEJp7t+2tCkfTNRUcqa1Onwhu?= =?us-ascii?Q?VovCvFckqnfnxjqvBKcinJasKhJ5yrrIWq+LYynQ6kP1oMPBpQtggYischMT?= =?us-ascii?Q?Jy5qY/Lzodk3KdnYYfIE2v4JahFsBXfagCvit9RONLpI2dvqdn2MuyGM9UcT?= =?us-ascii?Q?OTBnUjonQj2nRuy568GlwYSFHEu1kK+zxjsZABbxy3wgtcC7B804t56yqsRk?= =?us-ascii?Q?7kCLTNYXyQghshiEAlXc66oNzCjmPyD55yFihdVcAiKHk9aT4zpQsh79uVcF?= =?us-ascii?Q?eF8PHiTGsdD9Zftp8LlPbiNzf4aCUIMVB2jwf6t8xOxF7Db/6zM9OmjktmVq?= =?us-ascii?Q?dVa7ta5Bq+U5JT8gFu7aTTL/4warPi5+8Si9bX9ww5SH/8yzKRfdxrGIkZdB?= =?us-ascii?Q?DDbQdgiveY9tGILGogp/UN+Xr9+NPsf0CaXWKl0QGgzvKxhoNRJ1DC7qh4UZ?= =?us-ascii?Q?CegZ4tAT5+NQDMZZLAsM9wwRlmYc4Kkh1cA1xi0AqlJwkS57K0iLxbDieCow?= =?us-ascii?Q?FHBYE8iyHqNd3p+m28eIXg/RuqZ/rM6eZlCDwymzmeHbhmBnd8U7Lf+pzZmV?= =?us-ascii?Q?aM2O9BhxS1Q+fudTvNN4s8EUN7q3+zyS/RQLaQCms0orJTzjz4uV0CCLm8Di?= =?us-ascii?Q?9+I9ZWHrJgM20yLNNhFRlX9Y63lAW9PFfpI2eyjgpR41VEkfn++/QDyYVLH8?= =?us-ascii?Q?6gDgKxrW+ZagZqek7QB32LWfr51+5wm+lQ8ZKJDBuuEmr5a8Q4S7IGHB0okS?= =?us-ascii?Q?P5KFn3SnM/AHTUw5+TsESdfUvtHLdpgVCYP+4mHseohu206mcozu9Dfayc0M?= =?us-ascii?Q?kMHb/+CfsFg6iG0B9oVji0ZB0VgoVJK8PS+Fo11NZy/XM7a9JHq63ojUWcqY?= =?us-ascii?Q?Z+UDA3yCUap4EOoRLJpkHeBSQES08h5Uyns8kSfqvSFJyofwiyvwt9XCVLqh?= =?us-ascii?Q?n/r1kPdAUVijycyKv9gL37jH6QxeMJGq0mwsemiyC4jjBXpzwwcZtBfd7URM?= =?us-ascii?Q?oYNEP7Tr7pv06o1pGWmAK089N/Ipfe3Yb5HB2rBAR+USp7rMob4csSjvjgE5?= =?us-ascii?Q?WcVW9NJTUWWuvf5NrBQ66ShQkHOk7FoHVOuRDAOy?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SI2P153MB0441.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 34b9f111-eed1-40f4-3e9f-08da69503efb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2022 06:31:00.0987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hff5E7HCoxHb5e9fJLe+aXhqXYq50nbY2VdjvZi4t9adNDRfZ6o0yXEVcYKOe5ZSjKlyQLTBOzFbwo1Duct1Ig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZP153MB0633 X-Rspamd-Queue-Id: 4Ln89P31q5z3hhy X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=SVlLZawS; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of weh@microsoft.com designates 52.101.128.19 as permitted sender) smtp.mailfrom=weh@microsoft.com X-Spamd-Result: default: False [-9.50 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; SUBJECT_ENDS_SPACES(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.19:from]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi,=20 We are trying to bring up FreeBSD on ARM64 Hyper-V. We are seeing the iso = image booted up fine and we can install the root disk with ZFS. However, wh= en choosing to install the root disk with UFS, we are seeing UFS checksum e= rrors as below and the installation just failed. ... UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 41, cgp: 0x45721f90 !=3D= bp: 0x23b0cc8 UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 42, cgp: 0xbb1ba737 !=3D= bp: 0xfc52b46f UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 43, cgp: 0x12671d05 !=3D= bp: 0x552e0e5d UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 44, cgp: 0x4224a088 !=3D= bp: 0x56db3d0 UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 45, cgp: 0xea211974 !=3D= bp: 0x913217c9 UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 0, cgp: 0xae78ec43 !=3D = bp: 0x3467ffcc UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 1, cgp: 0x7fc7e750 !=3D = bp: 0x388ef408 UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 2, cgp: 0x81ae5ff7 !=3D = bp: 0xc6e74caf /mnt: create/symlink failed, no inodes free We are not sure if this is a UFS on ARM64 problem or Microsoft Hyper-V issu= e. Any idea? Thanks, Wei From nobody Wed Jul 20 19:30:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lp5Q36sYSz4Wm6G; Wed, 20 Jul 2022 19:30:19 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lp5Q24mHgz3S3B; Wed, 20 Jul 2022 19:30:18 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 26KJU7IJ037021 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jul 2022 21:30:08 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1658345408; bh=eDC3ajNzXlJ+PF0LHi5Vld8gp/TCdIOCSlimZaWPFxc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WGwLTfCQXT9YIr/h7BrMdRT3DmpNgWwHBX1o2ls+vlJplqhWDmVrmjZI36jpDB2K+ qH2G6z6zglfgSysW0ImTELlhMOUr/ckCyqohIsbTT3HCHE5h0axoV2QrfZXMez7kOt 2OaaWrWPdpq6uNFBRPVzmG0Whde7ByxVjxPPoeE8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 26KJU7Ei077677; Wed, 20 Jul 2022 21:30:07 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 26KJU60L077674; Wed, 20 Jul 2022 21:30:07 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 20 Jul 2022 21:30:06 +0200 (CEST) From: Wojciech Puchar To: Wei Hu cc: "freebsd-arm@freebsd.org" , "freebsd-hackers@FreeBSD.org" , Li-Wen Hsu , Souradeep Chakrabarti , "andrew@FreeBSD.org" Subject: Re: UFS checksum error during arm64 VM installation In-Reply-To: Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Lp5Q24mHgz3S3B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=WGwLTfCQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; SUBJECT_ENDS_SPACES(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-arm@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N hard to say. I've never in my life seen such an error, using FreeBSD for about 15 years, lots of different computers. Anyway i never used FreeBSD as guest on any VM, and i don't use Windows nor it's VM host software. May be a bug in Hyper-V that improperly emulates SCSI controller (i think it's emulating SCSI because your device is /dev/da*) - which result in error only on some kind of loads. ZFS and UFS works completely different. For example UFS is far more probable to do parallel writes to different locations in the same time. In the other hand it may be FreeBSD bug if Hyper-V emulated SCSI conform to standards but behave different than real SCSI controller and disk. As you are from microsoft you certainly could debug hyper-V to check if all reads and writes perform properly - i.e. writes data that it should write from guest memory, reads what it should and place in guest memory properly. I sugges to force fsck on this partition to check if it shows this checksum error or not. fsck doesn't do parallel reads If not - it's read handling problem. If yes - it may be both, but most probably write handling problems. From nobody Sun Jul 24 12:36:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LrN2V0L3Wz4XjDd for ; Sun, 24 Jul 2022 12:36:18 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from mail.pappacoda.it (mail.pappacoda.it [128.116.175.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LrN2S5vbNz3rmW for ; Sun, 24 Jul 2022 12:36:16 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from [127.0.0.1] (mail.pappacoda.it [128.116.175.254]) by mail.pappacoda.it (Postfix) with ESMTPSA id 98CCE3D519 for ; Sun, 24 Jul 2022 14:36:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pappacoda.it; s=20211226; t=1658666174; bh=dL1Dp9i+fTyjeSUTM6Hu5jg/ww9+xXGRje+WRkta9KY=; h=Date:From:To:Subject:From; b=pcKn++1Hxls05PZeAaZJR12OhPj2ocrWdLI6xYG99PLg+swT4utsukoaGTB4Saz3q 89YALA/RlPlk98lg4bzv2VHvoHoOJUEdq4OQTat4yRB1I6LR+CPSaTkKlYtuHwzBwr FpmBewOCfQyr7XdRR61Bhl5EilKHv+GP51M3ygPWT51vOUK368UPbYg1bZUfxX1rGz qkQyl0czqkBpr35QZyCNJN7o/ccQ33pRIEtL/6LMkScq5p1woD+FRRQCtgiCiwK4+3 olmiZEbWxm2wKRYrkCyjgW79beiAkcLA/LecmkOQONsT9D0VFv9Y+ENpSwS7HEe35t 7lEWNQWcj7V8g== Date: Sun, 24 Jul 2022 14:36:14 +0200 From: Andrea Pappacoda To: freebsd-hackers@FreeBSD.org Subject: pkg-config and share/ User-Agent: K-9 Mail for Android Message-ID: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----TAMCRYSQZ3J1TC9SF0N7WNR6CFGBLT Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LrN2S5vbNz3rmW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pappacoda.it header.s=20211226 header.b=pcKn++1H; dmarc=pass (policy=reject) header.from=pappacoda.it; spf=pass (mx1.freebsd.org: domain of andrea@pappacoda.it designates 128.116.175.254 as permitted sender) smtp.mailfrom=andrea@pappacoda.it X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[pappacoda.it,reject]; R_DKIM_ALLOW(-0.20)[pappacoda.it:s=20211226]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:35612, ipnet:128.116.128.0/17, country:IT]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[pappacoda.it:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ------TAMCRYSQZ3J1TC9SF0N7WNR6CFGBLT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone! First time on the FreeBSD mailing lists, I hope this is not in= the wrong section :) I'd like to ask/discuss about FreeBSD's pkg-config behaviour=2E [As far as= I understand][1], on FreeBSD pkgconf looks for =2Epc files in the /usr/lib= and /usr/libdata directories, but completely ignores /usr/share=2E Why is = that? Where should arch-independent packages install their =2Epc files? I came here after a short discussion on a [GitHub issue][2], and I recomme= nd looking at that thread too because it gives a lot of information about w= hat the issue with not looking in share/ is, but in short it creates intero= perability problems with OSs wanting to use that directory for cross-build = purposes=2E Could somebody please help me understand why things work this way here, an= d if this unusual pkg-config behaviour could be improved? Thanks! [1]: https://cgit=2Efreebsd=2Eorg/ports/tree/devel/pkgconf/Makefile#n23 [2]: https://github=2Ecom/marzer/tomlplusplus/pull/165 ------TAMCRYSQZ3J1TC9SF0N7WNR6CFGBLT Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone! First time on the FreeBSD mailing l= ists, I hope this is not in the wrong section :)

I'd like to ask/dis= cuss about FreeBSD's pkg-config behaviour=2E [As far as I understand][1], o= n FreeBSD pkgconf looks for =2Epc files in the /usr/lib and /usr/libdata di= rectories, but completely ignores /usr/share=2E Why is that? Where should a= rch-independent packages install their =2Epc files?

I came here afte= r a short discussion on a [GitHub issue][2], and I recommend looking at tha= t thread too because it gives a lot of information about what the issue wit= h not looking in share/ is, but in short it creates interoperability proble= ms with OSs wanting to use that directory for cross-build purposes=2E
Could somebody please help me understand why things work this way here, a= nd if this unusual pkg-config behaviour could be improved?

Thanks!
[1]: https://cgit=2Efreebsd=2Eorg/ports/tree/devel/pkgconf/Makefi= le#n23

[2]: https://github=2Ecom/marzer/tomlplusplus/pull/165 ------TAMCRYSQZ3J1TC9SF0N7WNR6CFGBLT-- From nobody Mon Jul 25 06:45:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LrrC85jwCz4Xbfv for ; Mon, 25 Jul 2022 06:45:24 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LrrC74h9nz3h6p for ; Mon, 25 Jul 2022 06:45:23 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oFrq7-000HZS-52; Mon, 25 Jul 2022 08:45:15 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFrq7-000Tc4-BI; Mon, 25 Jul 2022 08:45:15 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1062648017A; Mon, 25 Jul 2022 08:45:15 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id hiVItYyjYWVE; Mon, 25 Jul 2022 08:45:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id C80A94801AA; Mon, 25 Jul 2022 08:45:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k6y1x0Il6jHi; Mon, 25 Jul 2022 08:45:14 +0200 (CEST) Received: from [10.10.171.6] (unknown [10.10.171.6]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 8B79348017A; Mon, 25 Jul 2022 08:45:14 +0200 (CEST) Message-ID: <1fd224f7-0f20-d0ac-b4c2-007c6713fad7@embedded-brains.de> Date: Mon, 25 Jul 2022 08:45:13 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 0/6] Simplify pps_capture() and pps_event() Content-Language: en-US To: Warner Losh Cc: FreeBSD Hackers References: <20220707152506.55626-1-sebastian.huber@embedded-brains.de> From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.6/26611/Sun Jul 24 09:58:48 2022) X-Rspamd-Queue-Id: 4LrrC74h9nz3h6p X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of sebastian.huber@embedded-brains.de designates 85.10.215.148 as permitted sender) smtp.mailfrom=sebastian.huber@embedded-brains.de X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; R_SPF_ALLOW(-0.20)[+ip4:85.10.215.148]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:85.10.192.0/18, country:DE]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_SEVEN(0.00)[8]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[embedded-brains.de]; HAS_X_AS(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello Warner, On 07/07/2022 17:52, Warner Losh wrote: > You might have better luck getting these patches reviewed with either a= =20 > pull request against github > mentioning the usual time people (phk, etc), or as a series=C2=A0of=20 > phabricator reviews adding said people. > If unsure, mention/add me and I'll add others :). the Github pull request didn't get much attention. Should I open a=20 Phabricator review instead? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ From nobody Mon Jul 25 08:15:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LrtCF02dKz4Wp9q for ; Mon, 25 Jul 2022 08:15:37 +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 4LrtCD6jvKz3p8M; Mon, 25 Jul 2022 08:15:36 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658736936; h=from:from:reply-to:subject:subject:date:date: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=jb2aUft7cM7SgXWR391idDjxajL9lOKkvtfAAQvt6Dk=; b=uDMy2ReL7A9fM649dMm9tsm/6CL/phBDiXNMNJiNdY4rf3CJUNRmp8xEfXJyF0NfCPTPhU 108B/ZeNAUDirU1griBM8LU06PeUiRaLkJ3uU8lpkigMuxWQCEpkUKrBocg0LY0PD1s7F2 hq63JFcwW4x6X/Jlib6LMkVKN24pjWtULGzDaGAWAsMD39J7twuNaXDDeiBCa7t78P0rfq g+dadQizWgIfvCWvrRDYb5pG0iR2gIyVP7swH/Wxfc68VK5NXN4Kvv2G8CA613t8Fa5Qoc S3etOFQP1k22kLyEgVj4d4c3o8RuGhxeNrmXg0a+RD7pKPLRT1y8z/ijIoUA1g== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LrtCD56shz13TK; Mon, 25 Jul 2022 08:15:36 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id B8F9DF2911; Mon, 25 Jul 2022 10:15:35 +0200 (CEST) Date: Mon, 25 Jul 2022 10:15:35 +0200 From: Baptiste Daroussin To: Andrea Pappacoda Cc: freebsd-hackers@FreeBSD.org Subject: Re: pkg-config and share/ Message-ID: <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658736936; h=from:from:reply-to:subject:subject:date:date: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=jb2aUft7cM7SgXWR391idDjxajL9lOKkvtfAAQvt6Dk=; b=G7tnRVpE/edvtECgyLvEOjBoGK6V5rB3RY4s12GJpMum/9rGARG6lN1UPbKzvbHMw4xgCL PWj+O6EatQXXZGRHEf2Nx/cfiDtrbzfVtB30bEjL58xDE5g6g2TO4NM9MA84c7NSdaOp72 caoU4kWxH5DO459rDkDFmjCzI3W67Ti1eHV/7f1hbci6TGFtD+sMAV/ljIbbnlVZ0He0nL 2aY5+7Z2l80ogGN+A7g9du96KK1FICRIoX8XVGQ/V9h3m/V9PU+ePg+enXrcrlynO+bknO J7QjvpEfelEPFV8vdNuQUkAQ8leysDW9LWLmjJa4ePvAwbrWY7PXblW380poQA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658736936; a=rsa-sha256; cv=none; b=fjjcA0qkBSeLstHnUV60CGvFA1bgbB1qzeNNSWG7Sd0gGX0aC6mZmcYXGy6F5KFOTMzfBJ ZF4BsTWdlS4W7ye0otzjQ7W75J0W+sw6z/hxbvrBl6d3KKIN4OWlAxwuw1Jm5QlXKpkuDl oRFb9MpodfWvW04RFS7UEG6DLNVRAWZNjee4ms7Fmhd+DjDwWLEaCzmyCOom+TdYuPVFdz 4Vj7WYgj6QMhEcqlxBnQb5eGfzG65lh6rJNhTHIPPWM745sCJ6zACBfQiG7jD8yjsDyF9x 1nQkH91BVlRU1fyxvt/hw64OeE3IV1rWPd+eh7b/CCop3BgcO0BGfIhXHgG43g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Jul 24, 2022 at 02:36:14PM +0200, Andrea Pappacoda wrote: > Hi everyone! First time on the FreeBSD mailing lists, I hope this is not in the wrong section :) > > I'd like to ask/discuss about FreeBSD's pkg-config behaviour. [As far as I understand][1], on FreeBSD pkgconf looks for .pc files in the /usr/lib and /usr/libdata directories, but completely ignores /usr/share. Why is that? Where should arch-independent packages install their .pc files? > > I came here after a short discussion on a [GitHub issue][2], and I recommend looking at that thread too because it gives a lot of information about what the issue with not looking in share/ is, but in short it creates interoperability problems with OSs wanting to use that directory for cross-build purposes. > > Could somebody please help me understand why things work this way here, and if this unusual pkg-config behaviour could be improved? > > Thanks! > > [1]: https://cgit.freebsd.org/ports/tree/devel/pkgconf/Makefile#n23 > > [2]: https://github.com/marzer/tomlplusplus/pull/165 Hello, pkgconf does not look into /usr/lib but only /usr/libdata, tradionnaly on freebsd libdata has been used to store things used by the tool chain somehow but not being an actual library: gcc's configuration data at the time, ldscripts at the time, both empty now. man hier(4) will provide you the information. When pkg-config came out, (before my time) the .pc files were naturally added to libdata which is where most people hacking on freebsd would have expected it. So when we switched to pkgconf we preserved that. Note that the ports tree on freebsd does not need patching as it automatically moves the .pc files from the "linux" location to libdata. I do hope that this answers your question! Best regards, Bapt From nobody Mon Jul 25 09:08:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LrvNC3Gg7z4WwTs for ; Mon, 25 Jul 2022 09:08:27 +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 4LrvNC14hKz3scb; Mon, 25 Jul 2022 09:08:27 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658740107; h=from:from:reply-to:subject:subject:date:date: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=YsrbhOUS4EHq/LP9FDcnhfBpI2eXy3j3R7MXiqt0U90=; b=et0j9YsT6IS6rqAzEJdHF1SYsPKrytHkJNUfYDkTioBiZfB0JLAEI/8xeMyQsEU+zN+5VL pJOEmoqyMkmHrIzexI+EtPD/XcPrgVgf7gQteDQbgccyKV4FGHCtEM0u9Z6ncEMLPM4RaA ymwInZSjYh3f9OAnTveY/aNV5b25pah3MORpgHRiSXjNnchdrotrZF8jUr1rx2Ygl18qlA 8q1UBoe3tnhQIT6D+ztu1DcP97JsTinqXChInM+2mIxDXNaRdumZPJjfLIr5fKO8T4ooR7 W2aofflLXbL7IYB/5hkU8M4ErcJFULxEdKTbf3+w4V5ygLeQ47WMUyrGK9VZCg== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LrvNB6SSwz130G; Mon, 25 Jul 2022 09:08:26 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id D2011F343D; Mon, 25 Jul 2022 11:08:24 +0200 (CEST) Date: Mon, 25 Jul 2022 11:08:24 +0200 From: Baptiste Daroussin To: Alex Dupre Cc: Andrea Pappacoda , freebsd-hackers@FreeBSD.org Subject: Re: pkg-config and share/ Message-ID: <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658740107; h=from:from:reply-to:subject:subject:date:date: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=YsrbhOUS4EHq/LP9FDcnhfBpI2eXy3j3R7MXiqt0U90=; b=ABZtgnniHOeAUMC0Q0BBLHoUgamadz78370Z7oed7QPRM92uGZlGzAk59SSU7FMAEz3vHg 4vVNHqeprSz7lX6cLdMnJJNOoEqSbCDe3K5VOJX4vYcIwGBFE9GiS2Qus1Y0kFHfXZkuX7 igRPIZh2UTHoODHJqNUwzXqk+sZzAIjJJ4sls0nzxt2B6vnNVnLtSeSao2IFftT0NyFQpe eDn3nXXQ3stAi58/JaNy0E3qJr9fMtLUBwhnoMYZgI9Dir2gF6pt1hjTuiBowSeuvzo2Id d/bEja98xK9zN3TJ7rOba7eZj9wIgu0vf07Vb4xv90gMQFsV5GrCVi3/+QOWjw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658740107; a=rsa-sha256; cv=none; b=q2dkLVVYpNtBBBKEbXoApqImTXW+bITnuZgHvI35rS4r0s3z+F7G7BfPN3UmMz7OcaXr9e Pm0eRQ6OTkpvIKL40Bu1zB5IF0WGpyroDtzZxAn3sSVH5QUpt/e13RragtvG0dabGNXw+g oa74KBt4KgMJj4VBf7d+PphPvP3s9mcQSvXewVShxY1nt+m/BQwlNzY8ue2I6CRg5Ww0b2 cwKphA19ufiy/O/l6nEUbRHn2524Y2hX5GSv+4dtI6hwj2CBoxhiHzp2149BkMG/Dj7tTW VvcPqU0Erw6zowc/GAJqXolr9zqutIff1guSCcAAaRHOFdJvN0tnXnZlhGUuZw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 25, 2022 at 10:54:57AM +0200, Alex Dupre wrote: > On 25/07/22 10:15, Baptiste Daroussin wrote: > > When pkg-config came out, (before my time) the .pc files were naturally added to > > libdata which is where most people hacking on freebsd would have expected it. > > > > So when we switched to pkgconf we preserved that. > > > > Note that the ports tree on freebsd does not need patching as it automatically > > moves the .pc files from the "linux" location to libdata. > > > > I do hope that this answers your question! > > I'm not sure this fully answers Andrea's question. It explains why we use > `libdata` instead of `lib`, but not exactly why we don't use `share` at all. > Is it desired or simply it was added in pkg-config in a second time and > never added to the FreeBSD port? Not really except if someone comes with a strong argument, we can manipulate where pkgconf does look at, via environment variable if needed. The reason we don't look elsewhere by default it to ensure we keep the room "clean" and people carefully store things where they are expected to be, if they don't, they do it on purpose and we offer mechanism to help them, (the env variable). > > As a side note, Andrea, do you know we have `USES=pathfix` in ports to > transparently handle these path differences? pathfix is not necessary anymore for this case, as I state in my previous email, this is now all automatic. best regards, Bapt From nobody Mon Jul 25 10:04:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lrwd4753Lz4X3T8 for ; Mon, 25 Jul 2022 10:04:40 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from mail.pappacoda.it (mail.pappacoda.it [128.116.175.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lrwd36dl9z3ynt; Mon, 25 Jul 2022 10:04:39 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from [192.168.178.195] (mail.pappacoda.it [128.116.175.254]) by mail.pappacoda.it (Postfix) with ESMTPSA id CF6EA3D51D; Mon, 25 Jul 2022 12:04:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pappacoda.it; s=20211226; t=1658743471; bh=8+XjRFtALpk/H/psa1gkiwR9tQo1q1c+uzV1EEYmffA=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=U9jVslUBOBGFAo7DT1zQOrIWieaWBepP46/ejEVzsvJIBM7K7oUBEBPJXvHIxbOQw 0/z/4AiJ7EwdbFFgR9RJveMKmC1x0ApQLurKitlKsPLkBK4zwWFlkZ/EZnpdwRy8wV ccrKsuXiQdAZDdGVHZU8cZ6oo1FMbTU30vXdawaNgPRlZVBkeSfUH/cfq6E5gBzpyf k9JHMKo3qax5Ouze64+DlWVhjifDibTNVV7pIbsbzg/qHKY6ZSTs07TJO/VnAAisKQ NYl8fi76SYtUA5kWjxl1rg0poQygs4ZLFSn/woNj9+S7IWA7DruiVzgXoPD+6QhPP1 Cb/BSkB+Djzfw== Date: Mon, 25 Jul 2022 12:04:24 +0200 From: Andrea Pappacoda Subject: Re: pkg-config and share/ To: Baptiste Daroussin Cc: Alex Dupre , freebsd-hackers@FreeBSD.org Message-Id: In-Reply-To: <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> X-Mailer: geary/40.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Rspamd-Queue-Id: 4Lrwd36dl9z3ynt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pappacoda.it header.s=20211226 header.b=U9jVslUB; dmarc=pass (policy=reject) header.from=pappacoda.it; spf=pass (mx1.freebsd.org: domain of andrea@pappacoda.it designates 128.116.175.254 as permitted sender) smtp.mailfrom=andrea@pappacoda.it X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[pappacoda.it,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[pappacoda.it:s=20211226]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:35612, ipnet:128.116.128.0/17, country:IT]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[pappacoda.it:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Il giorno lun 25 lug 2022 alle 11:08:24 +02:00:00, Baptiste Daroussin ha scritto: > On Mon, Jul 25, 2022 at 10:54:57AM +0200, Alex Dupre wrote: >> On 25/07/22 10:15, Baptiste Daroussin wrote: >> > When pkg-config came out, (before my time) the .pc files were >> naturally added to >> > libdata which is where most people hacking on freebsd would have >> expected it. >> > >> > So when we switched to pkgconf we preserved that. >> > >> > Note that the ports tree on freebsd does not need patching as it >> automatically >> > moves the .pc files from the "linux" location to libdata. >> Oh, nice! So I can simply install to share/ and FreeBSD will figure it out, right? >> I'm not sure this fully answers Andrea's question. It explains why >> we use >> `libdata` instead of `lib`, but not exactly why we don't use >> `share` at all. >> Is it desired or simply it was added in pkg-config in a second time >> and >> never added to the FreeBSD port? > > Not really except if someone comes with a strong argument, we can > manipulate > where pkgconf does look at, via environment variable if needed. Yeah, I still feel that ignoring share/ is a bit odd, especially because you lose the possibility of determining if a given .pc file refers to an architecture-independent library or not. I don't know how much FreeBSD cares about cross-builds, but I believe that keeping everything in the same dir makes things harder (if not impossible). > The reason we don't look elsewhere by default it to ensure we keep > the room > "clean" and people carefully store things where they are expected to > be, if they > don't, they do it on purpose and we offer mechanism to help them, > (the env > variable). Yep, this makes sense. Every choice has its own trade-offs :) Thank you both for your replies! -- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49 From nobody Mon Jul 25 11:10:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lry5P10nKz4XC00 for ; Mon, 25 Jul 2022 11:10:49 +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 4Lry5P0Wp8z43qh; Mon, 25 Jul 2022 11:10:49 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658747449; h=from:from:reply-to:subject:subject:date:date: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=ARfKI/PaLc5oWljgtYJkt4c0Wgx0JUvlmeQj8W93nPw=; b=gjBvGQeZnYq+sMlzEWjcBFnXB39LDJ10tuks96QexWO73FWbajCXPT4hT5T8U91BpvPOFS 1iixC4aKaX1qHV3zDBoZoZybhrBqsEeBrUhT+VQ5l/2CcDVRUpV3GSS5gaVZu4SfI83ufJ x9y5//7pUAwQHdxmHs8ZkB2hAEhwxNQ9kxVfsytGENdpW32bcUSKiz2friwdtUhX1Z3HEM GEaNlulDwS9aXjwWGBMEAsnT8l7YAcCG5yibNoJ6rL7iMaP71hHG++X83tk5/GQXRxhCNR flnVtYq3GbhpFIEbeBiDlDw33DfBBW38QX6LSWamP/5feJCcmcdmW0uSmQTg8A== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Lry5N62CZz15Zl; Mon, 25 Jul 2022 11:10:48 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id B79A0F3A76; Mon, 25 Jul 2022 13:10:46 +0200 (CEST) Date: Mon, 25 Jul 2022 13:10:46 +0200 From: Baptiste Daroussin To: Andrea Pappacoda Cc: Alex Dupre , freebsd-hackers@FreeBSD.org Subject: Re: pkg-config and share/ Message-ID: <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658747449; h=from:from:reply-to:subject:subject:date:date: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=ARfKI/PaLc5oWljgtYJkt4c0Wgx0JUvlmeQj8W93nPw=; b=URjc2XaMFE3ks+MXIQUXdKRD7V0U33xzGEamjHlfzkAWlzaaMWECk9BtIYR/3xOGr4kY/f bsfTYTVFHtFT7eoTabMH3GzWFfNznRL6MMxf5ecP1sXvtPqy+QwJnfjKnT076SN/eqzYWU ftbd+6+CQYS4H9rzv2/PfLNMbLyafXZDDKX2IGX/reBcJtAShBFzWsZCzmEDtRYNTDfM8Q 4FUAsolU6mQQMKCf00yFsC1ZRfb2iU/Bn0nLyg+nIRs83sSDvQin8TIFVkzQVTG+yiEiFR wfEa9VmdBzM26wDzGJal8sBrAq4Q7HPwC0BTaQmtSW9sPj6LuRm0WtaO8a2UAA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658747449; a=rsa-sha256; cv=none; b=qtMrW3EwACDB8lWui4FH289SKRWh365kJHCjHGUu/lA9oFIVmQSvBOmpG2cHDEDJFZLFrM p1vE0BVUL+xltTMqE4YYfKqkMyiV3iNT0nLNOi8PT2XMt3pqaxEZtAOOx0ZFCBHStJMKNO vSpR82LjW73Jl40xhIGstW/ZvfJNsjEXojMib3YW9+e7XPmNkmqv+JjF2VkhJMSKX6anbi D7x2Hk5Z7wfUkZEXWxX0nK+lalXPHBELL2/U4h0jtV2xF63PaWg/RHnU/Q6mSyQaxjwMtT TkL/M89v+zD2bz/j/3tAc5/QABcLmMs06tMUkyA1VI6tNAfl7R2rgdwkWr4z0g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 25, 2022 at 12:04:24PM +0200, Andrea Pappacoda wrote: > Il giorno lun 25 lug 2022 alle 11:08:24 +02:00:00, Baptiste Daroussin > ha scritto: > > On Mon, Jul 25, 2022 at 10:54:57AM +0200, Alex Dupre wrote: > > > On 25/07/22 10:15, Baptiste Daroussin wrote: > > > > When pkg-config came out, (before my time) the .pc files were > > > naturally added to > > > > libdata which is where most people hacking on freebsd would have > > > expected it. > > > > > > > > So when we switched to pkgconf we preserved that. > > > > > > > > Note that the ports tree on freebsd does not need patching as it > > > automatically > > > > moves the .pc files from the "linux" location to libdata. > > > > > Oh, nice! So I can simply install to share/ and FreeBSD will figure it out, > right? if you create a package for the ports tree yes! > > > > I'm not sure this fully answers Andrea's question. It explains why > > > we use > > > `libdata` instead of `lib`, but not exactly why we don't use > > > `share` at all. > > > Is it desired or simply it was added in pkg-config in a second time > > > and > > > never added to the FreeBSD port? > > > > Not really except if someone comes with a strong argument, we can > > manipulate > > where pkgconf does look at, via environment variable if needed. > > Yeah, I still feel that ignoring share/ is a bit odd, especially because you > lose the possibility of determining if a given .pc file refers to an > architecture-independent library or not. I don't know how much FreeBSD cares > about cross-builds, but I believe that keeping everything in the same dir > makes things harder (if not impossible). how do I lose that? there is something that I am missing here. what is fundamentally different from share/pkgconfig and libdata/pkgconfig beside the name of the directory? > > > The reason we don't look elsewhere by default it to ensure we keep the > > room > > "clean" and people carefully store things where they are expected to be, > > if they > > don't, they do it on purpose and we offer mechanism to help them, (the > > env > > variable). > > Yep, this makes sense. Every choice has its own trade-offs :) > > Thank you both for your replies! > > -- > OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49 > > Best regards, bapt From nobody Mon Jul 25 13:56:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ls1mR3tlkz4XYMg for ; Mon, 25 Jul 2022 13:56:23 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from mail.pappacoda.it (mail.pappacoda.it [128.116.175.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ls1mQ3nJZz4MtN; Mon, 25 Jul 2022 13:56:22 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from [192.168.178.195] (mail.pappacoda.it [128.116.175.254]) by mail.pappacoda.it (Postfix) with ESMTPSA id 15B6C3D51D; Mon, 25 Jul 2022 15:56:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pappacoda.it; s=20211226; t=1658757380; bh=cyHBlFOE1UVz7drCugHblOtrE3ff6/v9v8nO8yxQn38=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=PtiAU4jDEfmifIBryEOSXYCHb91d7jDnCq0E4I7yPXIbrr7OHzJpYbZ4MuMWiEOKm F3nNfo3HT9t93o7fiFXykBXS4zEJx/6lBRR8VyxN8DYvJzjKOR8VVZwjF1jZvP5hfm uhN2gtnTa2qE5srVB3KN7xxnjogMiCCrHGnYyGbwzExGYQQeAwnLYAj+5Nz3G6nYNW 0PCWNtSAOXmhtfCNYiXNWyIYv4RkENxBfsphZjD9lM5rulZcrM9R3a5uCpCVbyPDQZ SHo0vsLzePq9mHoZP/rfpu2rB96OMPpNtObQ5SSEHOAvKKG3qRNV1jLnfP4rQcVtcu t3l5eN1BOCwhA== Date: Mon, 25 Jul 2022 15:56:12 +0200 From: Andrea Pappacoda Subject: Re: pkg-config and share/ To: Baptiste Daroussin Cc: Alex Dupre , freebsd-hackers@FreeBSD.org Message-Id: In-Reply-To: <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> X-Mailer: geary/40.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Rspamd-Queue-Id: 4Ls1mQ3nJZz4MtN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pappacoda.it header.s=20211226 header.b=PtiAU4jD; dmarc=pass (policy=reject) header.from=pappacoda.it; spf=pass (mx1.freebsd.org: domain of andrea@pappacoda.it designates 128.116.175.254 as permitted sender) smtp.mailfrom=andrea@pappacoda.it X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[pappacoda.it,reject]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[pappacoda.it:s=20211226]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:35612, ipnet:128.116.128.0/17, country:IT]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[pappacoda.it:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Il giorno lun 25 lug 2022 alle 13:10:46 +02:00:00, Baptiste Daroussin ha scritto: > how do I lose that? there is something that I am missing here. what is > fundamentally different from share/pkgconfig and libdata/pkgconfig > beside the > name of the directory? I guess the difference is in the meaning of the two locations. If a .pc file is in share/ you can be sure it can be used for cross compilation, as share/ only contains arch-independent stuff. And if it is in libdata/? Maybe, I can't know, it could be either arch-specific or arch-independent. For example, if I'm cross compiling to a riscv target and I find the toml++ library in share/pkgconfig/, I can use the library for the build as it is arch-independent (header-only lib, in this case). If I instead find the .pc file in libdata/pkgconfig/, I can't use it anymore, as it could either be arch-independent (header-only version), or arch-specific (toml++ can also be compiled as a proper shared library). That's how I see things, but I might be missing something. Hope I made this a bit cleaner :) -- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49 From nobody Tue Jul 26 15:37:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lsgyl6QYsz4XL2Z for ; Tue, 26 Jul 2022 15:37:35 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lsgyk6xhLz3N2D; Tue, 26 Jul 2022 15:37:34 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: (Authenticated sender: daniel.engberg@pyret.net) by mail.gandi.net (Postfix) with ESMTPA id 68E7A60008; Tue, 26 Jul 2022 15:37:32 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 26 Jul 2022 17:37:32 +0200 From: Daniel Engberg To: Baptiste Daroussin Cc: Andrea Pappacoda , Alex Dupre , freebsd-hackers@freebsd.org Subject: Re: pkg-config and share/ In-Reply-To: <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> Message-ID: <5f6e03bd468695f368e55a8839dc2838@FreeBSD.org> X-Sender: diizzy@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Lsgyk6xhLz3N2D X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::223 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::223:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[diizzy]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-07-25 13:10, Baptiste Daroussin wrote: > On Mon, Jul 25, 2022 at 12:04:24PM +0200, Andrea Pappacoda wrote: >> Il giorno lun 25 lug 2022 alle 11:08:24 +02:00:00, Baptiste Daroussin >> ha scritto: >> > On Mon, Jul 25, 2022 at 10:54:57AM +0200, Alex Dupre wrote: >> > > On 25/07/22 10:15, Baptiste Daroussin wrote: >> > > > When pkg-config came out, (before my time) the .pc files were >> > > naturally added to >> > > > libdata which is where most people hacking on freebsd would have >> > > expected it. >> > > > >> > > > So when we switched to pkgconf we preserved that. >> > > > >> > > > Note that the ports tree on freebsd does not need patching as it >> > > automatically >> > > > moves the .pc files from the "linux" location to libdata. >> > > >> >> Oh, nice! So I can simply install to share/ and FreeBSD will figure it >> out, >> right? > > if you create a package for the ports tree yes! It doesn't move .pc files from share on my test boxes at least >> >> > > I'm not sure this fully answers Andrea's question. It explains why >> > > we use >> > > `libdata` instead of `lib`, but not exactly why we don't use >> > > `share` at all. >> > > Is it desired or simply it was added in pkg-config in a second time >> > > and >> > > never added to the FreeBSD port? >> > >> > Not really except if someone comes with a strong argument, we can >> > manipulate >> > where pkgconf does look at, via environment variable if needed. >> >> Yeah, I still feel that ignoring share/ is a bit odd, especially >> because you >> lose the possibility of determining if a given .pc file refers to an >> architecture-independent library or not. I don't know how much FreeBSD >> cares >> about cross-builds, but I believe that keeping everything in the same >> dir >> makes things harder (if not impossible). > > how do I lose that? there is something that I am missing here. what is > fundamentally different from share/pkgconfig and libdata/pkgconfig > beside the > name of the directory? >> >> > The reason we don't look elsewhere by default it to ensure we keep the >> > room >> > "clean" and people carefully store things where they are expected to be, >> > if they >> > don't, they do it on purpose and we offer mechanism to help them, (the >> > env >> > variable). >> >> Yep, this makes sense. Every choice has its own trade-offs :) >> >> Thank you both for your replies! >> >> -- >> OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49 >> >> > > Best regards, > bapt From nobody Thu Jul 28 23:08:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Lv5th2gCvz4XFY4 for ; Thu, 28 Jul 2022 23:09:00 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from mail.pappacoda.it (mail.pappacoda.it [128.116.175.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lv5tg4DYGz44RW; Thu, 28 Jul 2022 23:08:59 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from [192.168.178.107] (orino.pappacoda.it [128.116.201.23]) by mail.pappacoda.it (Postfix) with ESMTPSA id AF0273D520; Fri, 29 Jul 2022 01:08:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pappacoda.it; s=20211226; t=1659049731; bh=f87KdmqDVqsj6Fl6BIQf+o0g2mtS0y+YW+A3AEbIICM=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=ldyAzWqWze3sYT80Mm1R60S/HWurc1XwHZO9LANupdN2UdSMfA7S0s9Da1nXJL1AR K9GMRYI88Nyi1baMxPlurQHVOxyEBbFihYitEMibNTtrlhR1Qv/ugq5esfAdpTlSgp b67A8jBKnhJDhSHSMgOnVzoz+RffqI/AVy9WEqMPKGDuugAebjv6lm8g+gjNb20A1+ OZ4FyhR+S8HoSAYxmhpTKlB3XYDFAZ0+tuZsAmsYcymJQmGxHrgtO1Nkm7t4lZkcLa JtqQxD0I3742blhuqz7rRFGYh6H7VfjhFIppFcw/6HTiGeYMUo0JH8IrKu7zVkBNpQ I1z18mZAFcFlw== Date: Fri, 29 Jul 2022 01:08:43 +0200 From: Andrea Pappacoda Subject: Re: pkg-config and share/ To: Baptiste Daroussin Cc: Daniel Engberg , Alex Dupre , freebsd-hackers@FreeBSD.org Message-Id: In-Reply-To: References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> X-Mailer: geary/40.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Rspamd-Queue-Id: 4Lv5tg4DYGz44RW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pappacoda.it header.s=20211226 header.b=ldyAzWqW; dmarc=pass (policy=reject) header.from=pappacoda.it; spf=pass (mx1.freebsd.org: domain of andrea@pappacoda.it designates 128.116.175.254 as permitted sender) smtp.mailfrom=andrea@pappacoda.it X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[pappacoda.it,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[pappacoda.it:s=20211226]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:35612, ipnet:128.116.128.0/17, country:IT]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[pappacoda.it:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Il giorno lun 25 lug 2022 alle 15:56:12 +02:00:00, Andrea Pappacoda ha scritto: >> what is >> fundamentally different from share/pkgconfig and libdata/pkgconfig >> beside the >> name of the directory? > > I guess the difference is in the meaning of the two locations. If a > .pc file is in share/ you can be sure it can be used for cross > compilation, as share/ only contains arch-independent stuff. And if > it is in libdata/? Maybe, I can't know, it could be either > arch-specific or arch-independent. Hi Bapt, sorry to ping this thread, but I think I forgot to specify my intents clearly. Given the usefulness of using share/pkgconfig/, and the fact that pkgconf upstream and many different OSes use that directory too, would you consider making your pkgconf honour that directory too? If not, could you please point me to where I should go / who should I ask to make the Ports system move .pc files from share/ to libdata/? As Daniel (diizzy) mentioned, it seems that currently only files from lib/ are moved to libdata/. If you're not convinced of share/'s usefulness, please pay this thread a visit: https://github.com/marzer/tomlplusplus/pull/165 Thanks for your time! From nobody Fri Jul 29 06:12:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvHHf11qVz4X2QT; Fri, 29 Jul 2022 06:12:46 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvHHd1g5kz3QlL; Fri, 29 Jul 2022 06:12:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from [10.0.0.2] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252]) by anubis.delphij.net (Postfix) with ESMTPSA id 0B8E855D18; Thu, 28 Jul 2022 23:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1659075158; x=1659089558; bh=sQyCpMSQHJiYvNoXiUg4FCzBVkHHW1fAxJeVxFPBI+c=; h=Date:Reply-To:To:From:Subject; b=qxVeal2d6Xzl4ikqyJ7QXhwtnAufNhhLfXG0XAYQF9Ps6yXH1y/MZYED8b+6MBqRH Rky8GM9l6Jg0Zj0MpTZaxr7VsU0xGygN3ILqGtty/QtaRKQApGF/DF6WFrH6C/T0p6 aMEYgynKf/ncuJi8d9vueqC2wAkg8twRAfsiLHP0fA4TS0nGQLwE5JJ2pjibV6wLZ+ Az0Iu/uLzsssYuKPMlPycPGJEpqEMOuF2q5lwQBfsI00q8W0yWpF68pGpvvBT0HhAH igxevRPSOdn0XFNwcw6kKMrLlDXyaWvvX8KuX8iuE/LO+DlzF3mt8TaoI2SuJOulGF UM9zKKe8wHBtQ== Message-ID: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> Date: Thu, 28 Jul 2022 23:12:36 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Reply-To: d@delphij.net Content-Language: en-US To: freebsd-current , freebsd-hackers@freebsd.org From: Xin Li Organization: The FreeBSD Project Subject: Proposal: remove /usr/bin/minigzip Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LvHHd1g5kz3QlL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=qxVeal2d; dmarc=pass (policy=reject) header.from=delphij.net; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; DKIM_TRACE(0.00)[delphij.net:+]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; HAS_ORG_HEADER(0.00)[]; HAS_REPLYTO(0.00)[d@delphij.net]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[delphij]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I'd like to remove /usr/bin/minigzip , a patch is available at: https://reviews.freebsd.org/D35979 The minigzip is originally an example application shipped with zlib to demonstrate how to use it to implement basic functionality of gzip. It was connected to the base system in 1997, mainly because there wasn't a GPL-free implementation of gzip(1): https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b Now we already have a GPL-free gzip(1) implementation in base system for quite a while, so it seems that there isn't much value of keeping minigzip around. A quick grep suggests that it's not being used by the base system anywhere, nor in the ports tree. Any objections? Cheers, From eugen@grosbein.net Fri Jul 29 06:24:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvHYT01kNz4X4KG; Fri, 29 Jul 2022 06:24:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvHYR5SPNz3TTB; Fri, 29 Jul 2022 06:24:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 26T6OKdq032468 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jul 2022 06:24:21 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: d@delphij.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 26T6OIkF060488 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 Jul 2022 13:24:18 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Proposal: remove /usr/bin/minigzip To: d@delphij.net, freebsd-current , freebsd-hackers@freebsd.org References: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> From: Eugene Grosbein Message-ID: Date: Fri, 29 Jul 2022 13:24:10 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LvHYR5SPNz3TTB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[eugen]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 29.07.2022 13:12, Xin Li пишет: > Hi, > > I'd like to remove /usr/bin/minigzip , a patch is available at: > > https://reviews.freebsd.org/D35979 > > The minigzip is originally an example application shipped with zlib to demonstrate how to use it to implement basic functionality of gzip. It was connected to the base system in 1997, mainly because there wasn't a GPL-free implementation of gzip(1): > > https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b > > Now we already have a GPL-free gzip(1) implementation in base system for quite a while, so it seems that there isn't much value of keeping minigzip around. A quick grep suggests that it's not being used by the base system anywhere, nor in the ports tree. > > Any objections? Have you considered embedded applications (crunchgen etc.)? In 13.1/amd64, /usr/bin/minigzip binary is about 11KB and links with libc and libz only. OTOH, /usr/bin/gzip is about six times larger (64KB) and additionally needs libbz2, liblzma, libmd and libthr. From nobody Fri Jul 29 07:33:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvK5H4Rlhz4XFGl for ; Fri, 29 Jul 2022 07:33:55 +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 4LvK5H3nqSz3Zn9; Fri, 29 Jul 2022 07:33:55 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659080035; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3oeH3Kziz0sr3hu+BbE2+vg320jMslomHQqax0RCpAQ=; b=GVoBK5WoXZbc/2rHlDZgV7mRaQDZSUEBA5OcdLDau6DMseTgEl04NipF/F7nmuP89vFrgr 7HjEFFXH3Ep/vAvNQPuxbj3HeptyY4cvYZPWjvVMTyJPugmyE8z0SYvhqsi/qf5KczNau9 3FQgQbsMW/oSZ5IUlWbZ4MS/onc+WotT0sqz/EXa8fr1xMoen5zts0vDJqejCmE0MYXkTH 15JYE27lTMZy1OAIWydaamO84gi3Mw01g/TY3ic67bgrUEIqvNgmQmUrSwzJQ7GK62y/52 n5avszjW6x4+JQtWbIfGwdP5SOL/xPVYqtgF/mzpTDfceGfAvyX6fMK1BLv/hA== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LvK5H26VXzgn7; Fri, 29 Jul 2022 07:33:55 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 9854B1209D1; Fri, 29 Jul 2022 09:33:53 +0200 (CEST) Date: Fri, 29 Jul 2022 09:33:53 +0200 From: Baptiste Daroussin To: Andrea Pappacoda Cc: Daniel Engberg , Alex Dupre , freebsd-hackers@FreeBSD.org Subject: Re: pkg-config and share/ Message-ID: <20220729073353.mp3ztbnzyeif4zv7@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659080035; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3oeH3Kziz0sr3hu+BbE2+vg320jMslomHQqax0RCpAQ=; b=r1QYgTN0NWFhIDpq8IqzGkBdFZt2MuJ4JX5FhPbkWIoyLYTjsCxYsqg2DLqR5I+lvQ4Ut+ BbgS0m7gNFKrATxXTBlOVgCvcbSrR8LfqaCx96kp9QPVruSmghjelYHt2asYBdSNiKSwRD nq6aA5w3wk91Wew1O44L+CIrqdgJ1ws4d0QQ8QKskZKwcRXdpRyxDTWHIEiQx4dRDPvs9D 08s16KacY9KPmV8xYvzG5ffiL1xJimQ8SxK1cEIm1eie7EQ/oqfacNIlsG83qeBXGq6qVn K1io9WTzUncobHz17zRGsdXgLW7etdX5qSahVMCExMc9iaXy0VZL85xeo7S1jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659080035; a=rsa-sha256; cv=none; b=NssXtqyh/QTMhgWIaTmhRBDJ/hwz3cm2cPMu/FvZfLnBa+vGpGF86BoGajMwzEeNgtL+w8 rY8MdvJoQpTQ9zQt1FaFFdonYbXsMe2l3sZR7eDW0qMPHfu4neisQaFfFxDTdbx0oK6qv3 2SkhdnIhrJmXd+brfYoRYbP0LBBaavSoex4K+T/GAMDmKFl7l+sh8TwESzyXxkPY8bbx/T F8njorvD5AdhXw3bVq1DWU5MEUL/2ZarFbJd0wjQw/t7DM9TZjEC5CAgmTqHwIRwggAooy xKPPg0XvTMXBFHJX3GrhN1ivLxxt6fnHXoUetQHW8KhuqTlou3kgFgMsu4/p8Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 29, 2022 at 01:08:43AM +0200, Andrea Pappacoda wrote: > Il giorno lun 25 lug 2022 alle 15:56:12 +02:00:00, Andrea Pappacoda > ha scritto: > > > what is > > > fundamentally different from share/pkgconfig and libdata/pkgconfig > > > =7Fbeside the > > > name of the directory? > >=20 > > I guess the difference is in the meaning of the two locations. If a .pc > > file is in share/ you can be sure it can be used for cross compilation, > > as share/ only contains arch-independent stuff. And if it is in > > libdata/? Maybe, I can't know, it could be either arch-specific or > > arch-independent. >=20 > Hi Bapt, sorry to ping this thread, but I think I forgot to specify my > intents clearly. >=20 > Given the usefulness of using share/pkgconfig/, and the fact that pkgconf > upstream and many different OSes use that directory too, would you consid= er > making your pkgconf honour that directory too? >=20 > If not, could you please point me to where I should go / who should I ask= to > make the Ports system move .pc files from share/ to libdata/? As Daniel > (diizzy) mentioned, it seems that currently only files from lib/ are moved > to libdata/. >=20 > If you're not convinced of share/'s usefulness, please pay this thread a > visit: https://github.com/marzer/tomlplusplus/pull/165 >=20 > Thanks for your time! >=20 >=20 What is interesting is: I am the second contributor to the pkgconf project,= we were iirc the first big project to entirely switch to pkgconf and we never = ever needed share/pkgconfig, after digging back in history I can see it was there since forever, and when I performed the switch from pkg-config to pkgconf a= nd never ever reintroduced anything but libdata/pkgconfig (our equivalent of lib/pkgconfig), so this would be the first use case. And yes the auto population of libdata/pkgconfig is done by moving the files =66rom lib/pkgconfig not moving the files from share/pkgconfig. I will add support for share/pkgconfig asap. Thank for the pointer. Best regards, Bapt From nobody Fri Jul 29 07:49:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvKR75Jktz4XJ0Z for ; Fri, 29 Jul 2022 07:49:23 +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 4LvKR72vhKz3cKS; Fri, 29 Jul 2022 07:49:23 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659080963; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tehncbfq/VIQw/GGwv2h3XF15Zu8jdUOeR1UBq6YC2c=; b=rdpg+ewVhZPXVDPHfZdJpxCURHwoqwWvPpYJFKJfIYmrQM9VU0hCMTWO5kevh9eaG/lKpl 9wGk1S+Qquan0Mkrp1DZ2QTcT0CyXEMB0KbbAEs4RXLDkeb/SonUu51LhRA8B5q2ucjzRu uwGoi0W/Rv7k8Ed8fbP6GOHmuTvoX0Duduqjpwc7AMKRScxxyS/U1Qxs20P2wl1vPgC81X Ln1Qq4Q1W2W1ffUwHwpkjAe1/5NYH4oka8kwZzVMzexhe9+5A5mBDcEOIKVCbafE/27luc SRWpQeV3K7FxYsWEE/icdzvCk1+Q8QB3R7wfi7lqWyNojuO4A7J/O2oppohBLA== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LvKR71KNGzgwr; Fri, 29 Jul 2022 07:49:23 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 7F467120AE3; Fri, 29 Jul 2022 09:49:21 +0200 (CEST) Date: Fri, 29 Jul 2022 09:49:21 +0200 From: Baptiste Daroussin To: Andrea Pappacoda Cc: Daniel Engberg , Alex Dupre , freebsd-hackers@FreeBSD.org Subject: Re: pkg-config and share/ Message-ID: <20220729074921.7sg2kqgydsjqwjqa@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> <20220729073353.mp3ztbnzyeif4zv7@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20220729073353.mp3ztbnzyeif4zv7@aniel.nours.eu> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659080963; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tehncbfq/VIQw/GGwv2h3XF15Zu8jdUOeR1UBq6YC2c=; b=VqHcPCH5aKwvOxfm2cQ+pWo6OeVSvEbsXLKAqtP9wLcScVjaqeAsQ+A7YT+GMAiZovqmnX vi3XCPYnfvGgc6FrbkjdkjtGU/kc77QwIb+EIYcvielgU6BbTR95PlNRRTuFQiEvIBI63y 15PcCzFqkKirDe4+55Gujgd4vTdpz42u/eI34/d5KTj39c4E3uuodGN12qyMzlnA0DUz2m NLq/Lf9T9nUYGGROwim28QzGE6q6hSJqOAO2o7jJW1IxM0vwT5DZjAR8/LN/q8BW4dOGmD JQxCUAhxeTmyUVYeIiKbkynQSsZx7591Tl0B/hlzzn6qel6NGj0BidWkbIud9A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659080963; a=rsa-sha256; cv=none; b=mSW+FYcZtKTyhQgf0RC+iMatWV7qf5J1IWDKk1FUj453bA3UDcAazAFRXZp66XNCL2h6kW 38ot3f+msDTMEo92Amvgju0Qqql8jnQtkAd1skk6GaG1ZhXYYtJ5eytLh6Ceo7igpi/sAt SaD6+vcUoEcAdTsZNQ/oMV2Gl+lOps/ehPrCZ/k06UVXySmWfZOAGirNEOI39l36UlqHUd soZfeuTvocq9TKklLNP2w4Hwg1bXUgMxogrMhT+WAb3SsOjbAR28yrJAXhtKavWKNKHaiU yI+P1vXwfW6UN2t5yw6zNluBg8DDEi8a4jdmiqz0CQzFCTkwxnH6XynuhRJWGQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 29, 2022 at 09:33:53AM +0200, Baptiste Daroussin wrote: > On Fri, Jul 29, 2022 at 01:08:43AM +0200, Andrea Pappacoda wrote: > > Il giorno lun 25 lug 2022 alle 15:56:12 +02:00:00, Andrea Pappacoda > > ha scritto: > > > > what is > > > > fundamentally different from share/pkgconfig and libdata/pkgconfig > > > > =7Fbeside the > > > > name of the directory? > > >=20 > > > I guess the difference is in the meaning of the two locations. If a .= pc > > > file is in share/ you can be sure it can be used for cross compilatio= n, > > > as share/ only contains arch-independent stuff. And if it is in > > > libdata/? Maybe, I can't know, it could be either arch-specific or > > > arch-independent. > >=20 > > Hi Bapt, sorry to ping this thread, but I think I forgot to specify my > > intents clearly. > >=20 > > Given the usefulness of using share/pkgconfig/, and the fact that pkgco= nf > > upstream and many different OSes use that directory too, would you cons= ider > > making your pkgconf honour that directory too? > >=20 > > If not, could you please point me to where I should go / who should I a= sk to > > make the Ports system move .pc files from share/ to libdata/? As Daniel > > (diizzy) mentioned, it seems that currently only files from lib/ are mo= ved > > to libdata/. > >=20 > > If you're not convinced of share/'s usefulness, please pay this thread a > > visit: https://github.com/marzer/tomlplusplus/pull/165 > >=20 > > Thanks for your time! > >=20 > >=20 >=20 > What is interesting is: I am the second contributor to the pkgconf projec= t, we > were iirc the first big project to entirely switch to pkgconf and we neve= r ever > needed share/pkgconfig, after digging back in history I can see it was th= ere > since forever, and when I performed the switch from pkg-config to pkgconf= and > never ever reintroduced anything but libdata/pkgconfig (our equivalent of > lib/pkgconfig), so this would be the first use case. >=20 > And yes the auto population of libdata/pkgconfig is done by moving the fi= les > from lib/pkgconfig not moving the files from share/pkgconfig. >=20 > I will add support for share/pkgconfig asap. >=20 > Thank for the pointer. >=20 > Best regards, > Bapt Done https://cgit.freebsd.org/ports/commit/?id=3Dd48fab59daa56e0b3b6ffecef57a69c= 32ae9c0a7 Best regards, Bapt From nobody Fri Jul 29 07:52:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvKVw058Cz4XJY3; Fri, 29 Jul 2022 07:52:40 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvKVt6nCVz3dDR; Fri, 29 Jul 2022 07:52:38 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from [10.0.0.2] (c-141-193-140-252.rev.sailinternet.net [141.193.140.252]) by anubis.delphij.net (Postfix) with ESMTPSA id 86D5055C60; Fri, 29 Jul 2022 00:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1659081157; x=1659095557; bh=WakUH30bnNZ+djJWkGrfhCv8Pq6Zy3WUi1kNbeOWwCM=; h=Date:Reply-To:To:References:From:Subject:In-Reply-To; b=hZuQPHAhYvHK0TCjmtpJs1cYtvDBJP8sL/uNhK7CB9YB82m+aVpi0gYmjHKYHrhPi gDMambQGLsVDIrPP+bpW4VHr4EpVUzwgnwPLSgruwq+2enETSbuYidNkMgyvtwxxdG wmbmaICPheKj0V9b9FlQLQ7mqb/J0eBEYw9O4HxN0R1CAcAF36xOvBBg47Lp7y4v2E NcyyZVkFwTM9JHeVKevLMDoOp5oAcqWp9yHdTBfToBJnrp44Hb9y6zqVKMZ31fxg5U BmyW7h1+z9PX/fIlz65HfJOhDEfus09PbHmum8xCCpZma+jdvscDU2qiFawsya88BP G72fO6kQ4fuSg== Message-ID: Date: Fri, 29 Jul 2022 00:52:36 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Reply-To: d@delphij.net Content-Language: en-US To: Eugene Grosbein , d@delphij.net, freebsd-current , freebsd-hackers@freebsd.org References: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> From: Xin Li Organization: The FreeBSD Project Subject: Re: Proposal: remove /usr/bin/minigzip In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4LvKVt6nCVz3dDR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=hZuQPHAh; dmarc=pass (policy=reject) header.from=delphij.net; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[delphij.net:+]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; HAS_ORG_HEADER(0.00)[]; HAS_REPLYTO(0.00)[d@delphij.net]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[delphij]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 7/28/22 23:24, Eugene Grosbein wrote: > 29.07.2022 13:12, Xin Li пишет: >> Hi, >> >> I'd like to remove /usr/bin/minigzip , a patch is available at: >> >> https://reviews.freebsd.org/D35979 >> >> The minigzip is originally an example application shipped with zlib to demonstrate how to use it to implement basic functionality of gzip. It was connected to the base system in 1997, mainly because there wasn't a GPL-free implementation of gzip(1): >> >> https://cgit.freebsd.org/src/commit/usr.bin/minigzip?id=85e55f7ab8473307fb16c5bce8c2e933a317215b >> >> Now we already have a GPL-free gzip(1) implementation in base system for quite a while, so it seems that there isn't much value of keeping minigzip around. A quick grep suggests that it's not being used by the base system anywhere, nor in the ports tree. >> >> Any objections? > > Have you considered embedded applications (crunchgen etc.)? Yes, but I don't think it's being used in real life anywhere, base system crunchgen examples, including rescue and tools/bsdbox, are all using the real gzip. > In 13.1/amd64, /usr/bin/minigzip binary is about 11KB and links with libc and libz only. > > OTOH, /usr/bin/gzip is about six times larger (64KB) and additionally needs libbz2, liblzma, libmd and libthr. It's a little bit unfair to compare the sizes of the executables directly :-) After all, the C library accounted for 94.4% and 75.4% of space for minigzip and gzip respectively: $ F=/usr/bin/minigzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | sort)) 12 /usr/bin/minigzip 1939 /lib/libc.so.7 104 /lib/libz.so.6 2054 total $ F=/usr/bin/gzip; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | sort)) 63 /usr/bin/gzip 1939 /lib/libc.so.7 107 /lib/libmd.so.6 122 /lib/libthr.so.3 104 /lib/libz.so.6 77 /usr/lib/libbz2.so.4 163 /usr/lib/liblzma.so.5 2573 total So yes, gzip is bigger, but arguably it's just about 0.5MiB, or 25% larger, and among that 2573KB, 2510KB or 97.6% was shared library. But for applications that really want to have smaller footprint, bzip2 might be a better alternative -- the binary is bigger than minigzip, but library was smaller than zlib so the total size is actually a little bit smaller: $ F=/usr/bin/bzip2; du -Akc $(echo ${F} $(ldd -f '%p\n' ${F} | grep ^/ | sort)) 34 /usr/bin/bzip2 1939 /lib/libc.so.7 77 /usr/lib/libbz2.so.4 2050 total (It's true that zlib is a much more popular library and is used in more scenarios, like ppp, etc., so in reality this might actually added 99kb (=34+77-12), I just wanted to say that there are other options, and if minigzip is not really being used, building it on every FreeBSD machines doesn't seem to be a good use of resources). Cheers, From eugen@grosbein.net Fri Jul 29 08:02:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvKk62jzHz4XKwJ; Fri, 29 Jul 2022 08:02:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvKk55Czzz3gnG; Fri, 29 Jul 2022 08:02:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 26T8291A033100 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jul 2022 08:02:09 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: d@delphij.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 26T828pE061312 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 29 Jul 2022 15:02:08 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Proposal: remove /usr/bin/minigzip To: d@delphij.net, freebsd-current , freebsd-hackers@freebsd.org References: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> From: Eugene Grosbein Message-ID: <7d1865f4-92df-4903-b8ce-4c767dafecbd@grosbein.net> Date: Fri, 29 Jul 2022 15:02:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4LvKk55Czzz3gnG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[eugen]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[grosbein.net]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 29.07.2022 14:52, Xin Li wrote: > (It's true that zlib is a much more popular library and is used in more scenarios, like ppp, etc., so in reality this might actually added 99kb (=34+77-12), I just wanted to say that there are other options, and if minigzip is not really being used, building it on every FreeBSD machines doesn't seem to be a good use of resources). For embedded appliances, the code is rebuilt from scratch generally, so please consider adding something like WITH_MINIGZIP src.conf(5) knob disabled by default to disconnect it from default built. So, every FreeBSD machine will not build it. From nobody Fri Jul 29 10:19:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvNmk41b6z4XgRK for ; Fri, 29 Jul 2022 10:19:50 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from mail.pappacoda.it (mail.pappacoda.it [128.116.175.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvNmj3r2fz3sYS; Fri, 29 Jul 2022 10:19:49 +0000 (UTC) (envelope-from andrea@pappacoda.it) Received: from [192.168.178.107] (orino.pappacoda.it [128.116.201.23]) by mail.pappacoda.it (Postfix) with ESMTPSA id 714723D52A; Fri, 29 Jul 2022 12:19:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pappacoda.it; s=20211226; t=1659089986; bh=se6aoGKSXjiZOhnAR3W0TjzTm0ulmbtUTKlaAThf5mg=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=w7sISw1bXr8EiSmJDhIYp6acHPBrWwLQCHkQs2oa5WSuuYiZbb/OqUHSuaiyWKH6O HGSOl2JboQq8YHL4CbBfkrfV9KFAGjvmJJRFRUtsk7qKx3gibXFo3eNW3WabSYLL7I 2iLfhPxgFAHLqjarrwLShvO6PfVnO3MzJ2eHmAfqKJ3yfGqJUyOxV2URVk9KLFn1Cp oVHyqruh5gvECrc4xwUKd5291SxxwLz7tEnYVGz6W0W7KDtvnsZhYcqdFduV9MG/8J b6zIWq8p994Xf6ejvSwtWyJGeQfJWafa9qkiZyLHQrbXyUz7hn0/FDllEVUABf9P32 c7jRDLfb4lW9w== Date: Fri, 29 Jul 2022 12:19:39 +0200 From: Andrea Pappacoda Subject: Re: pkg-config and share/ To: Baptiste Daroussin Cc: Daniel Engberg , Alex Dupre , freebsd-hackers@FreeBSD.org Message-Id: In-Reply-To: <20220729074921.7sg2kqgydsjqwjqa@aniel.nours.eu> References: <50B3D276-5E68-4F87-97FB-71D75D3D9602@pappacoda.it> <20220725081535.vuxy74odqt2cxdnw@aniel.nours.eu> <20220725090824.qfeypgyugx6f7i6q@aniel.nours.eu> <20220725111046.7sr7yyvsm5f3hyhj@aniel.nours.eu> <20220729073353.mp3ztbnzyeif4zv7@aniel.nours.eu> <20220729074921.7sg2kqgydsjqwjqa@aniel.nours.eu> X-Mailer: geary/40.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Rspamd-Queue-Id: 4LvNmj3r2fz3sYS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pappacoda.it header.s=20211226 header.b=w7sISw1b; dmarc=pass (policy=reject) header.from=pappacoda.it; spf=pass (mx1.freebsd.org: domain of andrea@pappacoda.it designates 128.116.175.254 as permitted sender) smtp.mailfrom=andrea@pappacoda.it X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[pappacoda.it,reject]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[pappacoda.it:s=20211226]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; ASN(0.00)[asn:35612, ipnet:128.116.128.0/17, country:IT]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[pappacoda.it:+]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Il giorno ven 29 lug 2022 alle 09:49:21 +02:00:00, Baptiste Daroussin ha scritto: >> What is interesting is: I am the second contributor to the pkgconf >> project, we >> were iirc the first big project to entirely switch to pkgconf and >> we never ever >> needed share/pkgconfig, after digging back in history I can see it >> was there >> since forever, and when I performed the switch from pkg-config to >> pkgconf and >> never ever reintroduced anything but libdata/pkgconfig (our >> equivalent of >> lib/pkgconfig), so this would be the first use case. >> >> And yes the auto population of libdata/pkgconfig is done by moving >> the files >> from lib/pkgconfig not moving the files from share/pkgconfig. >> >> I will add support for share/pkgconfig asap. >> >> Thank for the pointer. >> >> Best regards, >> Bapt > > Done > https://cgit.freebsd.org/ports/commit/?id=d48fab59daa56e0b3b6ffecef57a69c32ae9c0a7 Oh, you're right, I didn't notice that you're a major pkgconf contributor. Thanks for your work, it is a really nice tool :) And of course, thanks for adding share/pkgconfig/ this quickly! Bye From nobody Fri Jul 29 15:04:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvW506qRsz4XR1w; Fri, 29 Jul 2022 15:04:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvW4z4kfpz3Jbt; Fri, 29 Jul 2022 15:04:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f43.google.com with SMTP id l23so9012182ejr.5; Fri, 29 Jul 2022 08:04:19 -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:content-transfer-encoding; bh=pTYK92VpyXKekIHr9jtfDpymIAioz12t7Bs8dKTGHOA=; b=wD3nbbywwz31GmS3ukqFJ2fEOhNeajBlv2ig8xCqtVSCdM2d6gIJr14bqorEmX4FqG qLCr/tGYZX3KUnTdvqHvFOhNB+JEfMD4Xu4AWgZURVuPYL9Chxf5SzsqBEa1p1LNJs4T KGKXyAB/QiLgEf8m3XZmXNSRZI23xbbLus6w+7igPXClwlwVc//u2kfM5ZEUT4RGz05y 4rz7nd7dHx+jTPdzyKhDnE0WC+VmdDlEMfDbPnI6+NKStzbrtz0JovF5+FKPTDOb4kze LjouVAbt+PD2a/VQGPzYK6SieKgCykpabZ9eYjm59wTutkZMRNWWwBDzXIUVcXgSsQJq 9RbQ== X-Gm-Message-State: AJIora9fDQtoYuM0dtln35zErbGhiPvj7cshh11fF7+/z0F4V+f7YEjC P9yjafWpRaSQuvbj1oGoIe1zG+KvTqx3kwbtgw38PaWF X-Google-Smtp-Source: AGRyM1sXGOIaamdrauuptLOtxC2kLOwPPa/0yO8oAX8g6ZMYc+7bs2Z01RKf6vMtvXnAa7Q8tRJj6n7yTPD6XQoNq9s= X-Received: by 2002:a17:906:ef8b:b0:72b:4a67:8ae5 with SMTP id ze11-20020a170906ef8b00b0072b4a678ae5mr3221475ejb.763.1659107058143; Fri, 29 Jul 2022 08:04:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Fri, 29 Jul 2022 11:04:07 -0400 Message-ID: Subject: Re: UFS checksum error during arm64 VM installation To: Wei Hu Cc: "freebsd-arm@freebsd.org" , "freebsd-hackers@FreeBSD.org" , Li-Wen Hsu , Souradeep Chakrabarti , "andrew@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4LvW4z4kfpz3Jbt X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.43:from]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.43:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FREEFALL_USER(0.00)[carpeddiem]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Tue, 19 Jul 2022 at 02:31, Wei Hu wrote: > > Hi, > > We are trying to bring up FreeBSD on ARM64 Hyper-V. We are seeing the is= o image booted up fine and we can install the root disk with ZFS. However, = when choosing to install the root disk with UFS, we are seeing UFS checksum= errors as below and the installation just failed. > > ... > UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 41, cgp: 0x45721f90 != =3D bp: 0x23b0cc8 ... Hi Wei, I assume you're trying this on relatively recent main? (There were some cylinder checksum issues some time ago, I think related to growfs, but as far as I know they were all fixed long ago.) From nobody Fri Jul 29 15:32:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvWjs2TJFz4XWmV; Fri, 29 Jul 2022 15:32:49 +0000 (UTC) (envelope-from weh@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020014.outbound.protection.outlook.com [52.101.128.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvWjr20Z8z3Q9k; Fri, 29 Jul 2022 15:32:48 +0000 (UTC) (envelope-from weh@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W3s7IVkUdWjb1D14QiisbD5FAlX/goL/ogvMjkiixDD4AAv7QGw7l73iSLdOLpIht76InpICmh+stiDxOHCBKCaifOEefmcfL5EFspq/BpGikwRFQJxJhhKjKQN+3aCr96aZP7ZAgTeJT/aFWDHuP2rvGzJKpXLE4wlYGsJ438SHepbNgIiNHkcAO0xs48dPpyPF3tZnH97T7oMOk6njnVppHqztAubdbJvpJUwVwsV+Rj/FNdKt1A9XQu//S6yTNqEqTJRqaX3hFiK4Yi8kw7vV4oebWaHRrzgPiHXRl0tZUmWoBXGjrTzFHgvSgCARoDdabxJencGtCnNsAVUDPg== 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=HrLjxdI1G6BYs0USITuWQf0U8I31Bm6Q/xwYy3PV2k8=; b=Tve+ja+B7Ko8ZD/nTD63v516tQAsVHHfoEJ8RKpZR0+mlGj3e5ASv5vqny7nb/TaOk8kR3SKIrcJRWgLvXmTbMkPdJdvU7Y+y31RP/mug42d6SIOUHaGBC7ST6LrXIWP14VT6KAjVzRGVE+kxbwGShdcjc/1aloU6InT1xiYsxZbohfoehtWuEN0B38cTtaO3K5lECOXxSDrpHcYIklQhI1Okn2Xj7h22dQ8llSbgJDzBu7fkufzFQcD62W3o/incxvNlOl/x0O9KxeJcm1GxsNJGGbLl5rLvbi0A3KhfHeOcDvGMQHO5ev+guU/ipKJEQk5t2swwGFEJG4r4Kd1BA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HrLjxdI1G6BYs0USITuWQf0U8I31Bm6Q/xwYy3PV2k8=; b=aWh6e6EB7vqaYwUSUKYmsTdcN0CRc9ubRbnS4+CNMeMxWpHf/Bf0KSRyOl/EC2uBMYKd9Ck+UgjX+pfwXUpKnY4fiG9UXvdcZKziRAXrQpHPXEQXnEV/MOvu4UYDcmJwRSUZcOOEK6wtQ8ROzYzRCSzuocFK3suVbwg50ObaUOc= Received: from TYZP153MB0447.APCP153.PROD.OUTLOOK.COM (2603:1096:400:23::6) by SG2P153MB0379.APCP153.PROD.OUTLOOK.COM (2603:1096:0:7::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.1; Fri, 29 Jul 2022 15:32:43 +0000 Received: from TYZP153MB0447.APCP153.PROD.OUTLOOK.COM ([fe80::dc03:1e5a:4673:be48]) by TYZP153MB0447.APCP153.PROD.OUTLOOK.COM ([fe80::dc03:1e5a:4673:be48%6]) with mapi id 15.20.5504.008; Fri, 29 Jul 2022 15:32:41 +0000 From: Wei Hu To: Ed Maste CC: "freebsd-arm@freebsd.org" , "freebsd-hackers@FreeBSD.org" , Li-Wen Hsu , Souradeep Chakrabarti , "andrew@FreeBSD.org" Subject: RE: UFS checksum error during arm64 VM installation Thread-Topic: UFS checksum error during arm64 VM installation Thread-Index: AdibNk5aqz8/PSh4TQaFvv/Uzh2qRwIJiSyAAABkyqA= Date: Fri, 29 Jul 2022 15:32:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=dce16481-8845-4729-b9fa-34351ba20fbc;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-07-29T15:15:23Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a9335906-95d0-45bd-19d3-08da7177936e x-ms-traffictypediagnostic: SG2P153MB0379:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nwKjOi3rMmohCjv3K88ueIDnJu+u35Y1VKrAEQpvMiKf2YiYUcUcIas0+IK0ws5HBzgA4Oh0qZ1PRoYL0tk1/uxEVSsnjDeEu7vfoTphseelb1JE89Uf2alM1QSw52zceQTnkOSZ76LZAih36NoPBhbxBDg1j9NLcep4oO2pc9C9LS5cDxw+wH2eksu5Yc5Q2yCM5dWrwUaI9mfcMJA8a5XxtcuaxEGnndv1gA+M6l0Fsz2SVzm49EfhFxOW+q8Xx+H4R0WzIsW+n5sJt5QW9MSlUDmffrykxNNdvyNqiAN72Q1/AgUHjhlqEpeN2YfJr0x0x5IZPiZY8SYwQIMXwzBAs/M5LCjdeIyn+yot3QVVXRUK8vxKi7xxalITXFm406CLAQqB+ZgCJsIO23zp04vqtaNhvzBSGhPNvS/HouYd7tIRwJFn7N6/foKwgf/DzO1G6uJ4FPyRKegMtjls/jFdmu8AaVWq4KuF0vV0oUNKs5j69ZAhnmQspH7CPg10Jw7xwnV9TSbjAXSPk7cpRL4uiou1w+RNO5Vl+BfWe448102U8hPpHbFkjBwaTyrFxSBC31VBemFTuDB9lxQrWh712vvWhVc8f+PvwL0WFErp0+M9vB70s0Kb06ILnKGMAL2MidJPnm8Huy2qc89Fn/yzLAiGdIZwk2z5NieY/0wasW5VgikWhIoPLq9Kd1WbABtQhMVrXIx492VijhzZTV8SVq2ULJrTqWqE/zTwzoRg8gQHg9MexnfdzSDvqgBZPnxk+VUT+xL+ubAsUTYoybZ0+pn4hGKRGU2Pj9c9WQvWvR+1M1QPJVQlBGRXTom1/dyQ+QTt8hIGB7rSwz6xYFemfxwxL2DOnpZMTcef99E= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYZP153MB0447.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230016)(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(451199009)(66946007)(478600001)(33656002)(64756008)(66446008)(8676002)(66476007)(66556008)(4326008)(76116006)(82960400001)(450100002)(9686003)(82950400001)(38070700005)(2906002)(8990500004)(6506007)(186003)(7696005)(86362001)(41300700001)(52536014)(8936002)(4744005)(316002)(54906003)(10290500003)(6916009)(5660300002)(55016003)(38100700002)(71200400001)(122000001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SG9SQ1kyZG5ETzRyKzE1b1N5YTJCRno2R1BVMDZ1OG9QRzdwNWFsSWQzbVhp?= =?utf-8?B?dTJxdFdJVkJ0bkRQOW1ycXcwRVcrNUlNY1RyT3FORTZZdXBKNmNHVG82cjJO?= =?utf-8?B?VUVmTVJUZGdWZEg3d0FKNHRGQlA3cWdTRkF6MEdyTzRFNERITnVlNmZueU92?= =?utf-8?B?U2lHZERFc1BoL0pSMFNLSk1vVjB4U1dFYUJGYmtpSHMvbW96VC9Ed2JJbDZm?= =?utf-8?B?c3VXNGhYbHFoTm1xNTl4TFRPYWN3NjFzWWJjbEhyZGhMUm54OGhOcndBbW5X?= =?utf-8?B?b0hzZDd3Rk1KRkkySXZ4VVRtSzhla0FyZDJjT0Y5bkc0N3c3bVhudmZOV0Rh?= =?utf-8?B?R0dnem95RnQ3blZiSkluWUNoWFBwN2RvaUt0M21ZQnhFeWhzbXZhOGJqK1Zq?= =?utf-8?B?MUU0a3JqaHR4dUpnL0p4cVN5Z3c4a3RxMTZ6MEtyWXZrMisvNkJ1aGFKVml4?= =?utf-8?B?S0lBSzl6VkNoZkxUUURGT2srK0V3dmtaRmdWMmxDaWt5cjM1YlhEOWZFVy9r?= =?utf-8?B?VG9uOHErNk9pQU9kRHBURnJGbTlTRFUzOXI4MnR3a3l4ZkdPVkxOa1VMQTZ4?= =?utf-8?B?V29sUDNKM2FlNWZXYTlRVUpZcHJVY3lKL0JDbHZLUUYrd2V5WElGSkxJckVT?= =?utf-8?B?TEV2Q3hTWkpDc29ONUIzUzU4ajdHSFFKT1c2QThLMDJqNFpvbG1vMGd1YSty?= =?utf-8?B?ZjZTTm9tYWRJQUkwUHpXYWNjcEZmVlFROW80MVlRcUxmSnJ5NWV0MitrMnlO?= =?utf-8?B?a2hQczNFMldSL2trbGtmZVpwLzFlVnNiMDYwYVQrUW9iVlY3L3E2bnZBZTJF?= =?utf-8?B?a01SbW5pb21KbWJ2SW1uTTl6U1JFcFE0YjcvNExCUFVlNXZhanhCYStsT3cx?= =?utf-8?B?V1luK2tzLzcxWDB4ZmdtT3RSeHRNb0ZnTmp0ZDZtejdQUjdWdnVnaG1yWVBV?= =?utf-8?B?SmlIZzMyTWNkeWlWRUxVeGp1NU5MMVRaeXo3b2h0NC9IcWJNdkpKMXJ0ME1Z?= =?utf-8?B?RVh3aVBTN0Z3dG4wbkxaQ3lSOUpyMGZUNnJrQm9EcHU2TUdGaVkrK1ZiV05t?= =?utf-8?B?UGNFVXpmU21CUWNyMGI5ZldaVEhKaGt0emFyVHE5UFZlMVFpQlJ1eEJ0OUFk?= =?utf-8?B?b2RsNTBFU1FFc2E5eUpyK1A3R2NCNXpvVzZFVFV5ZjFUZHcxRGF5VlFUbUN0?= =?utf-8?B?dUs2c2NoS3NyaUJSWFRLenp5YUhmUDM4MGZxVytobHhQL1B0UW13RU5yczV6?= =?utf-8?B?L085QXFLcS9VY3A0MnZiMm1EYmY5SmxlUll0QU81ZmdOWmFMZVlRRWN6aG1m?= =?utf-8?B?WTB3K1BrQ2R3U1RjQm1peVNsTVpnSlNZWGRTNVB2aE13N2ZvRWhVS0NDVGdV?= =?utf-8?B?Q241aXZWR0xGeWd4TmpPMUl0N3liNUhuQS9xNTExZzJwZVkrSzlnZk8yU0F5?= =?utf-8?B?ZnNmYks4U3pYZGoxbXoveEZxckwrMllPQmMreTdvY2pBbEttemI5OHg2aEoz?= =?utf-8?B?Wm5XSjBpV21xcTZrUll1RUdlakMxc09veThmMDZIT3BOUTY0OEo5UEdjbXNt?= =?utf-8?B?Y0YwNUdPdXZmQXNDS1Jic3Vuc3RBVklhUnJQbjc2aVl4S1FjUVFFV1dFQTU1?= =?utf-8?B?dG5Wb0lWV2oyYmdYNUZyUGg5NnNwSTZOa2tPT3Q0aFlqL0FuY2NEMVVvNENv?= =?utf-8?B?TXM4V1hNS1FBWHlrSWJIQXFPWThra09xbkdwWDdkWGFXNGVOUDIxKyt4Nmcv?= =?utf-8?B?V2hzMzFzdXUvUmhLNW1aVTVaMEFIN0NMbEY3S1lhTm1qc0RXY0lKWHEzTE03?= =?utf-8?B?SUZwYXVwWUorb3F0VmpsdlJkZDNYeXpYU1RMVjV2ME1WM2gxYVZ3K3BROFZJ?= =?utf-8?B?VDlBQ1ZHOTJudGo2cjJyNll3cEg2UGhYMGxTK0Z1NmdoRmZ1ZEIyQ3QyWkJV?= =?utf-8?B?aFNXejhNQXJ4dkNLWkZyUW8yVkVSU2FoT1FkV3dSYzJZaG82cDRFaXd1N1B4?= =?utf-8?B?RW5HTUV6c255cHZZa01pVmUwOERBK2QvazVndGJqZkYvQm0xY2hrTm0vSUpQ?= =?utf-8?B?S3FwclNHWG5HanlEV2xCWTFiV3NZRzIzQ2E4ekQ1aEZuQWJZbmF5MjFjb1VK?= =?utf-8?B?TFI1SUFQTnM0MFI5d0Z4dERrc0MyQmlFNzZyaHBXMEVkVEFQVjhQOXlRQTNK?= =?utf-8?B?bEE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYZP153MB0447.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a9335906-95d0-45bd-19d3-08da7177936e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2022 15:32:41.4534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lo6TVqipOP1jBs10+wV/caZs3ePwnWuH/ad1p8GD8zzp8SKndUswDoSaJv7n6lcL3ymTfWfD3L7cYp8+w/ySCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2P153MB0379 X-Rspamd-Queue-Id: 4LvWjr20Z8z3Q9k X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=aWh6e6EB; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of weh@microsoft.com designates 52.101.128.14 as permitted sender) smtp.mailfrom=weh@microsoft.com X-Spamd-Result: default: False [-8.87 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MIME_BASE64_TEXT(0.10)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.14:from]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N PiA+DQo+ID4gSGksDQo+ID4NCj4gPiBXZSBhcmUgdHJ5aW5nIHRvIGJyaW5nIHVwIEZyZWVCU0Qg b24gQVJNNjQgSHlwZXItVi4gIFdlIGFyZSBzZWVpbmcgdGhlIGlzbw0KPiBpbWFnZSBib290ZWQg dXAgZmluZSBhbmQgd2UgY2FuIGluc3RhbGwgdGhlIHJvb3QgZGlzayB3aXRoIFpGUy4gSG93ZXZl ciwNCj4gd2hlbiBjaG9vc2luZyB0byBpbnN0YWxsIHRoZSByb290IGRpc2sgd2l0aCBVRlMsIHdl IGFyZSBzZWVpbmcgVUZTIGNoZWNrc3VtDQo+IGVycm9ycyBhcyBiZWxvdyBhbmQgdGhlIGluc3Rh bGxhdGlvbiBqdXN0IGZhaWxlZC4NCj4gPg0KPiA+IC4uLg0KPiA+IFVGUyAvZGV2L2RhMHAyICgv bW50KSBjeWxpbmRlciBjaGVja3N1bSBmYWlsZWQ6IGNnIDQxLCBjZ3A6IDB4NDU3MjFmOTANCj4g PiAhPSBicDogMHgyM2IwY2M4DQo+IC4uLg0KPiANCj4gSGkgV2VpLCBJIGFzc3VtZSB5b3UncmUg dHJ5aW5nIHRoaXMgb24gcmVsYXRpdmVseSByZWNlbnQgbWFpbj8gKFRoZXJlIHdlcmUgc29tZQ0K PiBjeWxpbmRlciBjaGVja3N1bSBpc3N1ZXMgc29tZSB0aW1lIGFnbywgSSB0aGluayByZWxhdGVk IHRvIGdyb3dmcywgYnV0IGFzIGZhciBhcw0KPiBJIGtub3cgdGhleSB3ZXJlIGFsbCBmaXhlZCBs b25nIGFnby4pDQoNCkhpIEVkLCBZZXMsIHdlIGFyZSB0cnlpbmcgZnJvbSByZWNlbnQgbWFpbiAo SnVuZSwgMjAyMikuDQo= From nobody Fri Jul 29 16:06:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvXTF3ts8z4Xc8g; Fri, 29 Jul 2022 16:06:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvXTD5zl8z3W0x; Fri, 29 Jul 2022 16:06:56 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f45.google.com with SMTP id l23so9315616ejr.5; Fri, 29 Jul 2022 09:06:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HhHmeZVnHdEP3jMZmwH3e9iT7m/m8JQo8+L1Fx5akRM=; b=6a0caFE0dihIipls4FwAZQYFDdK1WONFZZymP7MhMC2OBLaM2HRGKoAzZpA27599c0 e2S9T8e0eGwTLjygPz75mKWmyr5KXsAX4xl+KK0u+yYJEOl9eUcIBZCTHE59/twMfXjK bV/LMR+Omj9I/hdgd+QyOyx8fA9OxZmW/GPpsYyrCogbLjAGbtFs+WjDGB3ZgOkedmXz 9Q7IpLcG451fEBVKx6/QMlU9VTgklsTSguueStGm9/y2uJSY54IB7TjzZiTppbp9FK9A s+Jo9woa22Z9y1u1Sak8vpcTWmxaU3ACz9EFnJRapi7S8j5JpvUuRBj4BwKE31dUOd3a ps6w== X-Gm-Message-State: AJIora+b0yYEml3bg+3sW46yzdnQp6N+f5Yn9LxRJl/8cZX3Vc+HKA45 In+HusD3MnaPUmQDXN6tUdz/yyKhDhzxNoACZu1cvN7Dje8= X-Google-Smtp-Source: AGRyM1v9Cw2QkDPqsUtdR0UtVh7RVxbf/2H3FPtXnC81pgOJjLcfkUsKsp/XsEgg4yoeqzobLKMiBudh6yVX2de16YA= X-Received: by 2002:a17:906:8478:b0:72b:4f81:29d8 with SMTP id hx24-20020a170906847800b0072b4f8129d8mr3352860ejc.179.1659110814830; Fri, 29 Jul 2022 09:06:54 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <0d8e1b38-bcd2-0875-1864-3385c502646d@delphij.net> In-Reply-To: From: Ed Maste Date: Fri, 29 Jul 2022 12:06:43 -0400 Message-ID: Subject: Re: Proposal: remove /usr/bin/minigzip To: d@delphij.net Cc: Eugene Grosbein , freebsd-current , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4LvXTD5zl8z3W0x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.45 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.45:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.45:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, 29 Jul 2022 at 03:52, Xin Li wrote: > But for applications that really want to have smaller footprint, bzip2 > might be a better alternative -- the binary is bigger than minigzip, but > library was smaller than zlib so the total size is actually a little bit > smaller: ... For applications where tens of kilobytes is a real concern, something like Rob Landley's "toybox" is probably a better bet. I configured it to include only gzip and get: $ ls -l toybox -r-xr-xr-x 1 emaste emaste 36880 Jul 29 11:59 toybox $ ./toybox gzip $ $ ldd ./toybox ./toybox: libc.so.7 => /lib/libc.so.7 (0x822a42000) so it's about 25K larger than minigzip, but doesn't depend on libz and could result in a rather smaller image. Toybox is at https://landley.net/toybox/ From nobody Fri Jul 29 21:26:36 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvgZ82gTtz4WyZx for ; Fri, 29 Jul 2022 21:26:40 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvgZ75Czwz3Pc7 for ; Fri, 29 Jul 2022 21:26:39 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: by mail-pg1-x52c.google.com with SMTP id r186so4931952pgr.2 for ; Fri, 29 Jul 2022 14:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc; bh=U5A59Zk1k2bLx0MZVJYipidGNZbO2THg19hM+OUrnB0=; b=pNhzJSp+y4J9vN1iLEswR00Mkx4pQyxNrGsQk/wglhlIplvtFNYzWT/ixmPJzuvx7/ hkEzQL42mfpOVs17psnt5nvLy+K9+o5SBM9W0ZKrsiroJaOqWK4uhkrO1oGthfljPAVy JNTRNrm/GJUK18/ZXJt+3Nt7+bY9QthXmvaOKil9ECNHMLVnE1sOJ9EhMU3lfIw3UVxI IWikzX+1kB1QFkHU2+IKm4ytJAeayR+FG0GwU43LSlJNyAReKXK0QP+7mpHHrEymuxLO rKvogJNTw7d8j+A222R5BgAOjhf6RsVv3gVx5Sn5aXANWvSkjWimEe/uwIL5Q+x+ZHID 6rBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc; bh=U5A59Zk1k2bLx0MZVJYipidGNZbO2THg19hM+OUrnB0=; b=H53UL9Tyg8FUtO39urRjNDenUdaKIRiFDAv5D7mbSQ96S1DR9kuL7yq9bZrFu6lfl7 SJeC5MqzntzXQSC2DkmBJmHr6sw+HjmxcdQ66PraqMTzmu+G7wiqdrvVq8SQm/MdYE8X 9JCgkCatwQtWaEnFSKIJ+zazktu89WGZluWeREkn//7BLI/UYTSdHZG58fblNA7MF2UI cBwg5tXtOANh5ws50NOT4rVq4uIv+b54sAyvLKPYxHW/w5S9k9Rrq6LG4kDY1JD6Of4r iwkF3kDRqgK+VHXQTdPpss1DgRMhAli+WXcGM48Igaat6PYSr0nXZ0LJ+zJFfJTy1Q8V kkzQ== X-Gm-Message-State: AJIora/ZWsR+FF2qDn8N2XjTdVwU6v+o5UDJ6yOVaoO1NXC71FsJMZCp +6311JK57LeR5XLlAoptW06jKmB6Yo4/moOF X-Google-Smtp-Source: AGRyM1vEjOEfO4XT+px+ap5q3p3/l98Taz22llJET2hV9TLq0ccUxg+XWoC9y9GiWahyIwZELFndsg== X-Received: by 2002:a63:8:0:b0:41a:390e:71e5 with SMTP id 8-20020a630008000000b0041a390e71e5mr4287409pga.480.1659129998216; Fri, 29 Jul 2022 14:26:38 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:5430:10b1:b11a:6454:a7d4:d6b9]) by smtp.gmail.com with ESMTPSA id q27-20020aa7983b000000b0052ac038672esm3371421pfl.33.2022.07.29.14.26.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2022 14:26:37 -0700 (PDT) From: Christopher Bowman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: lua loader Message-Id: Date: Fri, 29 Jul 2022 14:26:36 -0700 To: hackers@freebsd.org X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 4LvgZ75Czwz3Pc7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chrisbowman-com.20210112.gappssmtp.com header.s=20210112 header.b=pNhzJSp+; dmarc=none; spf=none (mx1.freebsd.org: domain of crb@chrisbowman.com has no SPF policy when checking 2607:f8b0:4864:20::52c) smtp.mailfrom=crb@chrisbowman.com X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[chrisbowman-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::52c:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[chrisbowman-com.20210112.gappssmtp.com:+]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[chrisbowman.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I=E2=80=99ve been looking through the lua code in /boot/loader/lua I = can=E2=80=99t really say I understand how the FDT gets loaded or even = find the code that does but I am able to load a DTB using: load -t dtb /boot/dtb/foo.dtb It doesn=E2=80=99t see that overlays are supported (at least in the lua = loader). I have a fdt_overlay=3D=E2=80=9Coverlay.dtb=E2=80=9D statement = in my loader.conf but I don=E2=80=99t see it being honored. Am I correct in understanding that? If I=E2=80=99m not correct could someone point me at the code that does = the overlay loading so I could look at it? Thanks Christopher= From nobody Sat Jul 30 01:05:50 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvmR94q4gz4XbTd for ; Sat, 30 Jul 2022 01:05:57 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) Received: from sender4-pp-o92.zoho.com (sender4-pp-o92.zoho.com [136.143.188.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4LvmR83KrLz3lFJ for ; Sat, 30 Jul 2022 01:05:56 +0000 (UTC) (envelope-from obsto.clades@zohomail.com) ARC-Seal: i=1; a=rsa-sha256; t=1659143153; cv=none; d=zohomail.com; s=zohoarc; b=WYVGk6QLNcH6loDY3iLPeII0mCf731w/euDBhX9S3S70aGv74eZcriaU4pgsZl/ZTg908DSa4uCN2KJSwHVdFLdowU/I0YR+V2FUNk5e8du9OQ53Hug03CXCinp6iKYOaG5ccr5KVXQHXcib2XzNOi4uFI9eliddEt3HaoYlx2I= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1659143153; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=OJq5hMavammC/LJOoe8bCJbYC0yzPSuUEszR3x2oZ10=; b=WYVUanvAOuHyj7LrxiFwVZfnJ3bmzbT3GuOUyBrnnZbfyEl/yguoIVUlK7kvqMMyZoqf6FFac+q522MsC0aJX2i7QR2WCmJSMTTZuztV6WV/68UV7E9oim+HOWBe992W9jft8/cUwe3tkQxNKBDaKobExsDNkL3UAUdK0DEJkP8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zohomail.com; spf=pass smtp.mailfrom=obsto.clades@zohomail.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1659143153; s=zm2022; d=zohomail.com; i=obsto.clades@zohomail.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To:Cc; bh=OJq5hMavammC/LJOoe8bCJbYC0yzPSuUEszR3x2oZ10=; b=ax2J71gXKi+4eX5KLxrKsDp0Z24/N2Q6irLG3iiRRFbxbMEENJ29L8kA8f8ytTOJ uu4Q4V2juuu/ej11n4raaU3KiviDjxNWsZ4RvA4SUPKZdnndwLasGtZVq20IjpFTjyh EZ70/x2BR4oZwmT+eI5DibC+S0jtxcA9Hklwhb3A= Received: from [10.0.0.2] (75-172-30-63.tukw.qwest.net [75.172.30.63]) by mx.zohomail.com with SMTPS id 1659143151501863.4113407864423; Fri, 29 Jul 2022 18:05:51 -0700 (PDT) Message-ID: <5a874623-76e4-7fd6-2e81-2aed51f07cbd@zohomail.com> Date: Fri, 29 Jul 2022 18:05:50 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: lua loader Content-Language: en-US To: hackers@freebsd.org References: From: Obsto Clades In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External X-Rspamd-Queue-Id: 4LvmR83KrLz3lFJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=zohomail.com header.s=zm2022 header.b=ax2J71gX; arc=pass ("zohomail.com:s=zohoarc:i=1"); dmarc=pass (policy=reject) header.from=zohomail.com; spf=pass (mx1.freebsd.org: domain of obsto.clades@zohomail.com designates 136.143.188.92 as permitted sender) smtp.mailfrom=obsto.clades@zohomail.com X-Spamd-Result: default: False [-5.00 / 15.00]; ARC_ALLOW(-1.00)[zohomail.com:s=zohoarc:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[zohomail.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:136.143.188.0/24]; R_DKIM_ALLOW(-0.20)[zohomail.com:s=zm2022]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2639, ipnet:136.143.188.0/23, country:US]; DKIM_TRACE(0.00)[zohomail.com:+]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[136.143.188.92:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[zohomail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N I am also interesting in learning more about the lua loader.  So, if anybody replies to Christopher's question, could you please include me in your replies. On 7/29/22 14:26, Christopher Bowman wrote: > I’ve been looking through the lua code in /boot/loader/lua I can’t really say I understand how the FDT gets loaded or even find the code that does but I am able to load a DTB using: > > load -t dtb /boot/dtb/foo.dtb > > It doesn’t see that overlays are supported (at least in the lua loader). I have a fdt_overlay=“overlay.dtb” statement in my loader.conf but I don’t see it being honored. > Am I correct in understanding that? > > If I’m not correct could someone point me at the code that does the overlay loading so I could look at it? > Thanks > Christopher -- Obsto Clades, LLC From nobody Sat Jul 30 01:14:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LvmdB5fW5z4XbvZ for ; Sat, 30 Jul 2022 01:14:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Lvmd94yzcz3mjQ for ; Sat, 30 Jul 2022 01:14:37 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659143674; bh=kuv58Iz0tecUKUV5ShQnTc3fQBhJA10Nx5yBB9GmSBQ=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=kwYm+PUoxjk55EKl6Tp/KHx2OCulhUtwzXO8RP/93TpyPWKj0qsZ1kMTV8HXcPQIn2a/VfP3UgsJs0HU3xY5GU3PsA0kCvtT8z8dGrYv/oNEJp/OAl01UPLfkFNwz183g/CcF6KmB/G91/+RkfBxtKL2+m5IQbW3zhJLwwh5jXF81dgA7tlq2dSnweAHCuZ/UdYUduJxZJg2MU3n71p7cZ0xe5JzFCU9z1MidjS/ahH7Z1c0Gkwntz4ZvSDzTsp5vrNj2qYzJPSksQb/POBelCEVDo8PqgPUqDiY43yaJZMrNCDYAVJ/PTsR0ElGIdXviVWtLO9WdHdQta0KvFUUsA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659143674; bh=K6f3C6SFssLbEJ3jm7Nt1LOsuhPmR6HBnxbbCD2hT9M=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=dVfERnA9Ji1NaAv9jCYCyFeSgENa5F6DQ03X9ilHvzSvEotI6XcCYcsu6DeKTUvcZI3I9QeyoslQHOU2PcBxG05uUf5rr0LiopnlndxAC7RlD9A4VAxWhsyo9UcfM1v7MrQIZ7HCR6c0FyLAAFTs3895gIaXPVqYOLkwt6fsJbRAjC2ke+EHNN0D3GzO/K6CBituD1FROP7+J2zbGmyPTfR6Uz9zX+H66NW4jT3RZ2nV9jZHdCM8X8WPCivDhFUkXEOpqvfG3+uhDezK6DBmrl0wX9i0O8JQdlRFngXb/RIXNrrbRaVJydofh6Lgbj9nMTGrOBb/z7OtPD7XOUSWxw== X-YMail-OSG: CsYzSMkVM1nGUxpJijIL9GlUo7A9rzENsMWNFkHY8qwRpwTzS9c8TFBf1ZqgwCn yvHCGy68PyDlRP8f5XeHn_2Of1qEHMJOZCK0kNHydMb2_BEorN0ogfrxwyQ3OrxSLg4OPR2puK8z niWnakw1e7qwjH7nKqu9zj_8tcPckmFvszvmp4RDmBLNyQOAMg1NCyAAIfVcJzTUDLAv4ohAUPQH ZgAI0EhyV7CDXuAIgjKhVkKnhTVkEMFO0WPyEMQU63XXbgIOdrjrkdZKlNil_fcQOnk0BuncJkuy XkMSnzdVbMiIiN3yePQtc9S6hgTUI.Igtlp01KZ_fBCso1z3GOKT1Wk.FZC.SEkwhQ0VdV32U2wW FF6Dik5xb6HuE6SrIgSLnmkTh3iSM2EjIumuV17UHpIMppaduAXHm1YTgtRK1vn.yvFT8JJf3TAH vXvzDCO0bZ2P9ez0SQ.g6aZwTvuvF9EMWdxRxMs_YJ5ePwBwwsLpudWsqTW_jpbt4OzO8S_aZUKB nBkW7m2QHN8cncE56B6V.1Ajibh9LKxJCLQEJNyljH9vrzL5xuDKJVWbATxMGA02kekLNYyb5EDp ea3hP2yI_BrZ09wJ.mBAP.YbyEJRFGYq5eweRt_MuZAer0ZHFTVzgzmLDJNQNP_P9K8sK57phG7J UpW9VFXwDRjKyQzIvYBwV2f6di0n4Ct2YfkKSOnQI094ACfxEa..4poMOSF.5v9YiBR6_BZxxfQ3 agXw6m3QwOD0tO2bcHNKUHVcVa2WeHWzPqbVACI4wkKp377_cB99lKk3pTdGjyngmuu4UCg68wcV qZXfZQ9CSbSPeYS7qRVcsNrNidC8Z.lk8UltS3eGoXY3WnPrUIF3gRqQtIw61aU6nv.ys46TVfcz w.loPujtQo7MxtToVFIJrgRccR0KzK4btpG.vJGF7JJt8hNL8rxbQ1LS7CPx3mt5bHGwobZI_vur Kd_C2BSNw4KDDas5_nDxt8K9LATHOkMFyG1ITx5aYyqBY6a8W1uMp3JGRKVYsndvfHYnZV5pUt4U qmcveKpF0TxGcexu2eOIQyFhxMNqdGos0xThlIpoD2ffsGnW7KrUYVPYAOIAW0HUqHMWuhy_I25Y f3JYKGV5ibZwW52NZvyvMb5WgsbH5Nm1ZWSTHvAhk9mgsSk4AmVFhq12BZs8nCo84PORa.HUqbx_ x23.fGerdpj89cKonRUzzwgQtDsCJcwIUMvMgd.A1CiANVD3XVGLMJysdqeZ.DhhIVehYzclodRw F7tojLHiQihK4GlGFCrle44NFbPiYqlbaa2LMzjJuwxJ.RWor1r9GtE.pzDGTuiZ_nbM0yIQN_84 RNlvzgdPV02LWJENZBH6kWmVkC2ns7zRwbt9UwlGx1qFw0HyOxcxBTwShSpBgQgcOJLM7kC.4027 VbP.c6tV3UQd2qR1p16FJaloSFTYb6rm_oZWaIC3nTwEtiDC_oz5zWpvqgkueIXWUj95Easw8AHN 6MG83KNwBpk5We2ZXIu3UXksgfw0IIpwqQS8LYV_mNzzJ2J3LalO1KTFMlt4wPtIFDCGxN1JBN2o qZDcFk48sQhOQXf6M_g0oW_yh3XYDggVmCgqQQW5ZVKGQmdiWZZECTes3AIKTGn7dkgSDy789NsN WLZWFjFHb87dOal0b6aq_UOFgzmCb1LaPyFhGFFK7v4ZezLurvoODV9jqXUfRxLueBQG.q2ELfLH sXpSqKbnz6Wyhj4uuHPNIDJaQ8V2EkApka0Py4FFsynVWjSXbnjJ.hGBjAmw6yGRh9eEoOGj3LLf G.9A9CJzvHCeXhLY9KZyJ7Z56PHtwsEuI_L2b6vR.U.yMx00.HEqJobL41hy0jFdftb9EHgHnKU1 n7ieSSTg0Kvhhy73WDdZ1ELfd6sbZBjkCPjhyPw9jTnqLbT2KRK.8oTzl27TUD9vbWyHaE5ijK8h aVdNJLPJiPFzUy9n8suBa6QQOMoOFmLFXAaJlbtBF_foKm3s4pa3Z7AosKNDLnrU.BbB8ltrsspQ BiYnM2XJRMv9aRG_EQkYHrxIaM0aXXUz8zEkLrSCmydWIAAdNx4fAe6bGhi6PlRjC766EvxPy9nv SeslOUPxSVLBk1ZiqfRADkWeIaaIMAl5IEJKIaDsvEPSLlIvz5g_WZO4xc_E8JpKgcbWIdocWgp3 3E0vum4m.ry0N.750O.DCAah6VJwhQMGJgNylk2CAd5sVh9Y.KPVzrNNkRjBnw84CKXZO61uMict RLsCk1XoZhwchBSwmB2ZhUYDhGAoRSCjgK6BR61dIalgkbZFeyK009jdgWpqrr7qctcY9ixl4Iqy 34neJSrmTAPs- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jul 2022 01:14:34 +0000 Received: by hermes--production-gq1-7b45fb68df-d9xbj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d286a9e52b6a7445b6a2cb1561e027f0; Sat, 30 Jul 2022 01:14:31 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: RE: UFS checksum error during arm64 VM installation Message-Id: Date: Fri, 29 Jul 2022 18:14:30 -0700 Cc: Ed Maste To: weh@microsoft.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Lvmd94yzcz3mjQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=kwYm+PUo; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.31 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.81)[-0.815]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Wei Hu wrote on Date: Fri, 29 Jul 2022 15:32:41 UTC : > > > We are trying to bring up FreeBSD on ARM64 Hyper-V. We are seeing = the iso > > image booted up fine and we can install the root disk with ZFS. = However, > > when choosing to install the root disk with UFS, we are seeing UFS = checksum > > errors as below and the installation just failed. > > > > > > ... > > > UFS /dev/da0p2 (/mnt) cylinder checksum failed: cg 41, cgp: = 0x45721f90 > > > !=3D bp: 0x23b0cc8 > > ... > >=20 > > Hi Wei, I assume you're trying this on relatively recent main? = (There were some > > cylinder checksum issues some time ago, I think related to growfs, = but as far as > > I know they were all fixed long ago.) >=20 > Hi Ed, Yes, we are trying from recent main (June, 2022). I do not know if the following is related or not. But it can suggest avoiding late-May to until fairly recent versions for activity that would read UFS superblocks or create UFS file systems and such: possible rejections could happen that later code would tolerate. There has been a bunch of recent activity about valdiating superblocks and such, starting in late may with: QUOTE author Kirk McKusick 2022-05-27 19:21:11 = +0000 committer Kirk McKusick 2022-05-27 = 19:22:07 +0000 commit 076002f24d35962f0d21f44bfddd34ee4d7f015d (patch) tree 5b6a4cb01a3afaefad15e7e6e9cc4cbcea0ffadf parent eca6e0f7e460bf9a4a6e1bd5198d75168280c88e (diff) download src-076002f24d35962f0d21f44bfddd34ee4d7f015d.tar.gz src-076002f24d35962f0d21f44bfddd34ee4d7f015d.zip Do comprehensive UFS/FFS superblock integrity checks when reading a = superblock. Historically only minimal checks were made of a superblock when it was read in as it was assumed that fsck would have been run to correct any errors before attempting to use the filesystem. Recently several bug reports have been submitted reporting kernel panics that can be triggered by deliberately corrupting filesystem superblocks, see Bug 263979 - [meta] UFS / FFS / GEOM crash (panic) tracking which is tracking the reported corruption bugs. This change upgrades the checks that are performed. These additional checks should prevent panics from a corrupted superblock. Although it appears in only one place, the new code will apply to the kernel modules and (through libufs) user applications that read in superblocks. . . . END QUOTE There have been well over a dozen related updates since then, including some activity in the last couple of weeks. Even growfs got a fix. Some changes were to avoid false rejections from old tool behavior that left behind somewhat odd UFS internal information, leaving file systems in a not-obvious state. Non-dangerous examples of such are now more tolerated. Some of the issues did block (re)booting normally for various folks for a time. These have been being fixed as they showed up. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jul 31 04:12:18 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4LwSW973pnz4XslL for ; Sun, 31 Jul 2022 04:11:49 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LwSW96fR0z3nXf for ; Sun, 31 Jul 2022 04:11:49 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659240709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZFvIqr8uyme7BBUfwMqpgPzPHE8x5MnDyqcmRnNMDtg=; b=quimJ6OyNp7wqdkdjwi9B+ivMcXYTKt7XwaGP0nFrm5KF3salPIy7njw0TF+yU8+Ix17NY ed6kKJppg0YOxYRMZjv5+Db9hrRWDuZ6wKy3nNEPZ3iDwEAuxmWPxUBcJAe7WqzRS9x8k4 h0L8nYxVwr1dGq6Wkj7dzGkosEhzAlWSeLgJjmysxhOpviRyPXoqK+n8X9mgcIEA7NI6Qc FrQ7VX6Z8yIwnZt+CigZCwArHjKviEY6F87PmTm8I5sIgIEkR6J3Lv0FznbC0OCNJWhVPE IfQWGvfURzQlaWbi7eClHs2saSZOa/UILP6TEuSwcK5EZHKojMbw0my69VaFIA== Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4LwSW95HhNz1QKh for ; Sun, 31 Jul 2022 04:11:49 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-ej1-f54.google.com with SMTP id kb8so231166ejc.4 for ; Sat, 30 Jul 2022 21:11:49 -0700 (PDT) X-Gm-Message-State: AJIora+eUzlLqc4fUeYGfHm8VUKblDwF03oE7kwGlVRkC2G7Sqeixw8y ZIwLBtl35IHDz1DSBiiQcOZwd35uEotv4X0p5B4= X-Google-Smtp-Source: AGRyM1uuYb0OvHiiNJ+GTBGGW6s2cOfAAL7sZxuBQrqbpZJL3EyH9laR+uby4qXJe9FN2KqDbtNBpaOSwfWhPEKyi4Y= X-Received: by 2002:a17:906:8477:b0:72b:3e65:55c5 with SMTP id hx23-20020a170906847700b0072b3e6555c5mr7731567ejc.255.1659240708665; Sat, 30 Jul 2022 21:11:48 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <5a874623-76e4-7fd6-2e81-2aed51f07cbd@zohomail.com> In-Reply-To: <5a874623-76e4-7fd6-2e81-2aed51f07cbd@zohomail.com> From: Kyle Evans Date: Sat, 30 Jul 2022 21:12:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: lua loader To: Obsto Clades Cc: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659240709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZFvIqr8uyme7BBUfwMqpgPzPHE8x5MnDyqcmRnNMDtg=; b=wGsCdryVdoT6VVvGKmIvvznvLVNVSKDy37m4sgpZNVdV+6JcPnS2xyjP2lzeSbLCpVZH36 ryoKD7B3NHjRmhrzE06sXHKsjViOxiDLdd1bSR2aYOxnFy/stU2dmNV8NTTG2n9ytzok+9 0vB2Qmd9bdG5LO8V5ZBWYtLDdXZVxG/mRKJck/JOMGKbCikNwYzVN//7D1FyB4vir4aEop 1xQ40FBwoABmA+N/Yf4Hn486YY5O6IrFqLOPpVtNKc0pl3BRT+rylSunbY1k+r+cLkMgFB wpZHAa+C7nWrYNL7XkNAm7TPjrKh0GT4IZBs3FoL0EgWyZxVGc7BblGgJx6LPQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659240709; a=rsa-sha256; cv=none; b=PkMrOTIQMfsgBxITRqSlyrAV/PYA1gOaTbpBAqu1MAgRGvFXETvThmgVfcnIKVxL+0G7ZP cn0Fqc7gSEzlZwOzIO4/ODxDJqvYNzRVEY5s/JiKvZsiGYC2i6NiWGz5j4b+jz7kHRsVRd I5cOeA1HKmubWTG761kOHGnY0hQzZNiCRvsy2v6DqGrK5kDB3z7r3gC83r5Re1qu/KB3Yp XiYr7MrGWQTzbyj+WaOKSlv9zR3P8j2ss0vTs3LazxTITBYGWeHV+K8sObsHjLsPIa+9QI f7LDee672YW91zqtwHgsivbvYLa+Q5BlBhMbc8l/hd62NPni1nJSlJM8I3eErA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 29, 2022 at 6:06 PM Obsto Clades wr= ote: > > On 7/29/22 14:26, Christopher Bowman wrote: > > I=E2=80=99ve been looking through the lua code in /boot/loader/lua I ca= n=E2=80=99t really say I understand how the FDT gets loaded or even find th= e code that does but I am able to load a DTB using: > > > > load -t dtb /boot/dtb/foo.dtb > > > > It doesn=E2=80=99t see that overlays are supported (at least in the lua= loader). I have a fdt_overlay=3D=E2=80=9Coverlay.dtb=E2=80=9D statement i= n my loader.conf but I don=E2=80=99t see it being honored. > > Am I correct in understanding that? > > > > If I=E2=80=99m not correct could someone point me at the code that does= the overlay loading so I could look at it? > > Thanks > > Christopher > > > I am also interesting in learning more about the lua loader. So, if > anybody replies to Christopher's question, could you please include me > in your replies. > Hey, I ended up reaching out to Christopher out-of-band (IRC) after identifying them from a question they had asked a couple days ago. The answer to this particular question is that fdt_overlays doesn't require any real interpreter support -- it's all implemented in C (see: stand/fdt/fdt_loader_cmd.c; I had gotten the path wrong both in IRC and another e-mail I sent not too long ago. D'oh!). The interpreted scripts will read loader.conf and stuff (most) of the contents into the loader environment, which is how the C part understands that it needs to apply some overlay(s). A couple of different actions will trigger overlay application; it should happen automatically at or maybe a little after loadelf (lualoader's term for it) but before jumping to the kernel, or you can drop to the loader prompt and trigger it manually by trying to inspect the loaded FDT with the fdt command. Thanks, Kyle Evans From nobody Sun Aug 7 04:10:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M0m8P3fshz4YqDX for ; Sun, 7 Aug 2022 04:10:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M0m8N1L0Bz3g4j for ; Sun, 7 Aug 2022 04:10:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659845426; bh=bmHbW3sPeRBpfU9vA8OI06SuzWfFIdasijJ3IgsIQEU=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=YFH2nSXVWl5f8wEuJ7QdcM1AxGEnJPxVXgZiN3jGyuOQc+A0+roKRLRmZEiIqHzIJWN4Mfzqm930m2L/ei/s5H6iqUBywtXlNC60K7d1mvPqlHUW/2wedqAOjoxOZSpDn8htEd8TB7/ZNK87ChQ8yrsUOkFk7Yrvl2eChOfemLoyC1v8ZA/RTFWFHuUA7pv1TSS0XQGpGhGmHvxbtEkpRpAEHnKADXJIoSWWj1HasTGfcya2lzU31jdnu+As10sspUV1IUcw4y0/3aJhan72Z4rQiqelg4rSYK4Z07G2P9WIhwSq+Ayl2jTYVC1fA0Ve2D0IoRVzm9O6hJxyg4JRjg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659845426; bh=sC+pju6YII/xT4ifjD4XEAjlfIlUDD7pxe3H+4+ew6/=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=QSBUQrCFqKUDoDXEYpPRbNfWJh+yzV+EjDGIkbw3B+WShdzHkXru9dJG8dt4AfXURlBkh396S+B2dMheIR61oLAYFrCQO32bcuDso6NGWsd3WQ+tg1RTLvpKgQDghpWOfyjl6QX69O+gzr6k7X7NXx4FU+RMaFffEHINVpkWja3mRsoAJ3aeObEBUJ7eTfjOYVGsGF9czMcqoLwk1Kl7IZbNiiOsGm9SB2VS/zOT0czFzN0qYShtSaVOUWWaQ/L7nvrBRBR41HNOYgh7VuN0auuU77LztPMh/e9dfQzowLpfxeju4nzIIrhemtmNOkvj/kMI9P2Dms4mxcvpV/YxcA== X-YMail-OSG: l23YtJkVM1lUkfPnWEeepVheQwpQR37QgsJmsbj8VEMHHCinckMQazxEMkTQOdB YanFy.jNq.A_y6oFdTSN1SpLMxbN9C4_rKgkmLhlj3..RYBmJklvdWU1GEnzAaJGzmLIsGUSe9dM QMH5KN_A9JD9B1YM0_n.mkedJGtgCHZuMZrui9n.f3nDa8Kv_mxwAS62D4wNjVQ6QqfKlSvQHffc S3pQ1qH60avUhw2cxdVOHH8li76G2RooYW8n86CWsEBbyn1mrZqZWOHVHcYPMswQvBVdqaRCr521 9VON0gdlkn2INNbfT658PKqvVNgHHz2nXjuyiSENXrAk3iWMgq7ooLj7_bmLFV7eOCOHtvQ8bJ4Q Ynf4SrYrM4p3AgZz4P8tHKKUdi5uVeK4483wevc0OiNC_Zfl4fDJtnxcIqa41QIA217DsFRKIx1y Mosm90mIUIbTxBOTSZ2OcwMO1TZoWNFHQkSjnYsecjWybIw3Xs990JuOjCYzc3n1riSasjywp2LD SnwPC5hS3lc57QHEvIuZ4CfrN8mEuKeHDjvQftsI6r4qwspOKOJUmYkQOeMC.XofZ07QAFOw9LSB I9WVkBd8kFtaSihVC8ytD9qtDEVrYma7QVPUgT1_.Mw6Oafc.xs_oqH.n8KYQ.v5xYDO9c8RM8ge IyEt2OHekJS10lioaJeh.GyHlkR4AYg4Hg3ZVu0jlDMRQqM9azYIW1ctIkSA.KstZzW0CmFqLfUR 7YOMYQooPSnPWPskdQZ1wJzQ5lCEznvawMpIOlRu_0MCM1JkbrmV2kIHdJPoUJ7oc3WMKxmmakxA VIc8fU1IEMuCKZPFVZF5MOzdeXus55yRD3tJqUFFrjST3cFeGHyTcib2tD9.TSDAPZBOMPPaiXGF vGGztEdj2Ay6x8GfojtMYagNDZYdnyn4HtMO9cGv7aLJkqB.Le9HIiAeyj8rVLFVCfntawFhZN6a 1XqjkE.L2U5yz2PsAEVWAaAVLlpQNUsoccOEZ72qRCoT6NOYB_Kfjq.HLCKTGohOOytvlu33WUEc YlH10Kvez2YhCh_3Ay4UDMq7vkBWQ_VfKfvmkrw581lj5rY9A2jGvobhXaZuQop5hA2AxV2EQmor ZbRNLKV9bi29HilYGfu2m8yS65kEvA2wUCACjjNcv7RTqTSnpkCBVkFTQmQ9.qWhLAj0_I1aOmFe 0FeI1W5U24Y04mlcJ_NgqavLGVxzenk1uFkRbP_spDHS0yN8NKzGQB0tKKI38R84YcMl3n4DcVez ADEvXkIiFWbDHRg7nZ1brnByJ0CwQ7JRZNF9eoMr._U9xw11u3JWMEtzsTqSsQv26UPC1KCTz.gS adqdZome7pw1L_OuVdwbgWrExR2TMDDX8GifoAF8ZE_uIKpDWFUflNw5fc1ParVo0OfCwZOe.SZs qX9Vzn5n_ycaYUfvrteIVC2u7bvz0fYmiktAg3m_AAjsEGk6cg57eHK5qwfBW8kfdLROvU3WYaMI Rzjrc3cx00jZZHQja9qux3VC7abUMVCSj_0EeW7QAoTpU8adxDewgYBpd7Jqhil.HRTpGuW7Esyn 9eo8kZJruBR5RP_px_8o1cw_5xAZj9OucFFfAELA8.gE1msoeA25rptpETrX_3unxh5zuVWdR4se duHpGK41Ic5cXUy8QQnjOKd3eu0XApsSnBZwGJ56DQng36Zo0anUHfRMNgfjfSWsflDYVCQe6eD0 aSLCprLSEmNUpTZdGkA1CQLR.6g0lK0QyI1klp3zXahQmVQuRwyF2BbaZ3hX4SX6L3jI1CEd6qHB y89xBXw4z5pB6ath8kyl73fQnsF0quJ87EvqrSMqE9i1XMPoMWxUEk709dsY580uDKThD_VhyO3B h9jp5TNV.8phTZdJ.st43sBQwL1KkVmIJfGjhfyjhd.YwIILlxVzzgi9E_fHkBEPCVdNPeg0hGWB dOYolltSirxloZEdrR.Pon5zIPCfCCPsSwgA53qf3o2_f9Q_iRLVVcoQE7oe6UR3bOXBlTGxuebG dCRL.67oFmBEBcWQSU7vheGUf9CekbaevrZKFiv6Hj5_FCbvCKkB8ZjA_rknPChoZvWPrYH.8jxD 0KaPk9fwH5EjzVWPT81AtonAsheOScNr7Vo2lNm7TMsfNcSGRx3bzghR2YKrIXoUn2I8qJJnlIwE TKKH7jJKn50TqtLkZbto5xo4oYR7T4npgpwZG1QMcOEzm4iLXOUxOiy3vwfvUTjHs9usHqEuYAlC wPtdDXcrNT6X8EVgzJHF1VgG0OIkDjS_gECyoRLiZjtZo5nYPFcltM8Maema4.XkFG6BRGMoiFgH ZRTWQcfB8UX0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 04:10:26 +0000 Received: by hermes--production-gq1-686964ccb6-5tbjz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ef41e137f23b21105f6b2a1a702bd2ff; Sun, 07 Aug 2022 04:10:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-Id: Date: Sat, 6 Aug 2022 21:10:23 -0700 Cc: Ed Maste , FreeBSD Hackers , freebsd-arm To: Glen Barber , Warner Losh , "Rodney W. Grimes" X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4M0m8N1L0Bz3g4j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=YFH2nSXV; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.43 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_MEDIUM(-0.94)[-0.941]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N The oddities look like indicated below. # mdconfig -u md1 -f = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img # gpart show . . . =3D> 63 10485697 md1 MBR (5.0G) 63 1985 - free - (993K) 2048 102400 1 fat32lba [active] (50M) 104448 10381312 2 freebsd (5.0G) =3D> 0 10381312 md1s2 BSD (5.0G) 0 10381312 1 freebsd-ufs (5.0G) =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) 0 10381312 1 freebsd-ufs (5.0G) =3D> 0 10381312 ufs/rootfs BSD (5.0G) 0 10381312 1 freebsd-ufs (5.0G) So: ufs/rootfs apparently identifies the BSD instead of the freebsd-ufs . Same for the ufsid/* . This leads to: # gpart show -p=20 . . . =3D> 63 10485697 md1 MBR (5.0G) 63 1985 - free - (993K) 2048 102400 md1s1 fat32lba [active] (50M) 104448 10381312 md1s2 freebsd (5.0G) =3D> 0 10381312 md1s2 BSD (5.0G) 0 10381312 md1s2a freebsd-ufs (5.0G) =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G) =3D> 0 10381312 ufs/rootfs BSD (5.0G) 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) freebsd-ufs has the unexpected label: ufs/rootfsa # ls -Tld /dev/ufs/* crw-r----- 1 root operator 0x6c Aug 6 20:19:58 2022 /dev/ufs/rootfs crw-r----- 1 root operator 0x6e Aug 6 20:19:58 2022 /dev/ufs/rootfsa Things were actually set up for ufs/rootfs naming as the identification of the freebsd-ufs content, per the release/tools/arm.subr commands ( from last month's main-n256584-5bc926af9fd1 ): if [ "${PART_SCHEME}" =3D "MBR" ]; then chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s = ${FAT_SIZE} ${mddev} chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a fi Note that the newfs command references /dev/${mddev}s2a instead of /dev/${mddev}s2 but the rootfs label ends up referencing /dev/${mddev}s2 . Is having "0 10381312" for the md*s2 and for the md*s2a a fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need to be moved to a different (non-zero) offset inside BSD? Or is this a different kind of bug? I'll not repeat the kinds of explorations that I reported last week unless someone wants to request something. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 7 19:32:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M18cQ3qqVz4Ymfs; Sun, 7 Aug 2022 19:32:38 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M18cQ2p3wz48jC; Sun, 7 Aug 2022 19:32:38 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id D695F56052; Sun, 7 Aug 2022 19:32:36 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us D695F56052 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Glen Barber In-Reply-To: Date: Sun, 7 Aug 2022 15:32:35 -0400 Cc: Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers , freebsd-arm Message-Id: References: To: Mark Millard X-Mailer: iPhone Mail (19G71) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M18cQ2p3wz48jC X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. I honestly do not have any idea where the problems you are seeing are creepi= ng in. Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure how to p= roceed otherwise. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 7, 2022, at 12:10 AM, Mark Millard wrote: >=20 > =EF=BB=BFThe oddities look like indicated below. >=20 > # mdconfig -u md1 -f FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5= c60d72-257129.img > # gpart show > . . . >=20 > =3D> 63 10485697 md1 MBR (5.0G) > 63 1985 - free - (993K) > 2048 102400 1 fat32lba [active] (50M) > 104448 10381312 2 freebsd (5.0G) >=20 > =3D> 0 10381312 md1s2 BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufs/rootfs BSD (5.0G) > 0 10381312 1 freebsd-ufs (5.0G) >=20 > So: ufs/rootfs apparently identifies the BSD instead of the > freebsd-ufs . Same for the ufsid/* . This leads to: >=20 > # gpart show -p=20 > . . . >=20 > =3D> 63 10485697 md1 MBR (5.0G) > 63 1985 - free - (993K) > 2048 102400 md1s1 fat32lba [active] (50M) > 104448 10381312 md1s2 freebsd (5.0G) >=20 > =3D> 0 10381312 md1s2 BSD (5.0G) > 0 10381312 md1s2a freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) > 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G) >=20 > =3D> 0 10381312 ufs/rootfs BSD (5.0G) > 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) >=20 > freebsd-ufs has the unexpected label: ufs/rootfsa >=20 > # ls -Tld /dev/ufs/* > crw-r----- 1 root operator 0x6c Aug 6 20:19:58 2022 /dev/ufs/rootfs > crw-r----- 1 root operator 0x6e Aug 6 20:19:58 2022 /dev/ufs/rootfsa >=20 > Things were actually set up for ufs/rootfs naming as the > identification of the freebsd-ufs content, per the > release/tools/arm.subr commands ( from last month's > main-n256584-5bc926af9fd1 ): >=20 > if [ "${PART_SCHEME}" =3D "MBR" ]; then > chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s ${FAT_SIZ= E} ${mddev} > chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} > chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE}= /dev/${mddev}s1 > chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} > chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 > chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev= }s2 > chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a > fi >=20 > Note that the newfs command references /dev/${mddev}s2a instead > of /dev/${mddev}s2 but the rootfs label ends up referencing > /dev/${mddev}s2 . >=20 > Is having "0 10381312" for the md*s2 and for the md*s2a a > fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need > to be moved to a different (non-zero) offset inside BSD? >=20 > Or is this a different kind of bug? >=20 > I'll not repeat the kinds of explorations that I reported last > week unless someone wants to request something. >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com >=20 From nobody Sun Aug 7 19:50:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M190z2n58z4YppS for ; Sun, 7 Aug 2022 19:50:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-54.consmr.mail.gq1.yahoo.com (sonic316-54.consmr.mail.gq1.yahoo.com [98.137.69.30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M190x71zLz3DR0 for ; Sun, 7 Aug 2022 19:50:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=ms5YE/uSFH+aKxrPdovtf3vsgMPHoVwUDElZ79Qhfbw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=S+FKvDyQsLawrAXVH1sjM3NfmEqIaaXqzB9DMbYxA3ee8AJ0wj/DgB/S18ECfkwk+Ao2diS6sy0t1u1bUjA7WPvRLFD7CZzNplzwfth75YXKXJFsqH58onFfx8FE3B16kL7O5kqI125ayw6FpkKptuTVGkR086YjUNQ6bHCzn8GHAy9f6UZi/aGMzFTWb2R5VVuL0tzOFjX6kBgsWfH1mMBKKFJ9zNIVI70WLsE66XhiZMBSeB8pCi8eUksi5zckIbyj7Q8vAZbnm/CJXR5h1J6dsRIO9y09htsFc0QwQfNNJFCkYZ4sgoOAQEYEG1sPdF3wzk1UoSCZ+wWmT3BPxQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659901823; bh=3QxCHxTyPL3MLHpREC+T3GQ98nYyJvUanGkiHP7w2N4=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=F7+nbVC3HCzI7OC14VVhDjAxx38As6gjobOfUpwTNap41leZjZyd4wQijb3ljXBQARKnHotUqVa+gmgT9N8tRVnqnmRjE+QvGPf1t0ucZMWNRlMC9SEyywWpDAlMzf4dDUZ9a2AfRyCBJIbH27fNOcJ523eCan3eBeXp6uBo0GF/9HqdXPF+DJwKtpl9762tJHbXGwSgEbzlvWWlQdqVipV6TYodYCjMolLHmKCaPdxUCYMmx+1oWXS71uYB3i6zKGb/VcXREaCK9r4xQasCP39DtDYuByWQ0qaMIZ4dSRsWht9ssPHu1GAS9evVQtbh4Agnn8rcLvBDoEihktxv8Q== X-YMail-OSG: ZzC3IsEVM1l7CpyWcLEgIlYIs2FDPxGUJkcQqF1YB6U5lz9yHkWqKburQyZz4O7 iJCkN_QuOwr_ePfZPHnBfcKqdwkVRxo4TqZVeIYBJMtV16YAHv3j3QW6U9GnNC.7nlRYjK6eBOfC HRtIXRYPHJMQSXsC9fy7nN3OcFgWRKzW0Rze785B51Ggt1alzTLbM5VaxYh3.PpVrucKMak4q4AA H2zFetwc2nTU2jVuK4ccD7HSEG7QHztMK9kQIgQZTxUhP3qESKncx6pSvdHQaVmS6bIYdO7y5wRE Ll56HM4mX5EEjX_2E9E2N.ZAuqTb33X00LV_6LVYm2r9vfVUFGAwOBNRWXBBVy_OSOFp0H8My_cb BqASdRV.tqVaZRAlydMlI8JX88rlIN1YVUemuuxyqnDS7rAM7JipydFwEpev6DmJ8TVbndU_J7KF pzME_Y7RMKkEpCd3uiyiobvSOPUVbV9u4hOEA0dkkX3lu1ct_lEX9daz0OV5SOakMJlFPKtSTbY9 peL3Ma2xEdqOJSVPx.H_mjUzhGTgZkuMoH2zWhCE_f9GOb3KXvAJEQnpj8Zo6CsZJ4YG_f9mI_Wo 3U9kPCdrJPQPPiKvKBQM3YKDc5sUKrMtMD9htRoloEQQG3TkvO2gSc4hdKLe94By3fteTlxCrU6h _5SERDQc9ksU1jBypLjAienzVJcfxyVLP39z7FUgdfwrRJUDDNaS05A4gKN8TqwMR3O077zJTsWa j7RXdDq3uhC5nsWpO8AWUQtHorMswVoAvZaKum4jT4z_WyQILdssHe7jks9g0T9UtoMeEirRanVy E7hMmRxTI3rXjNcr3TsUrWtVXxLuA5fXP8HS6e7B2MPFcV.p9IPmAf5tLHwsRQJO4RoXfbnqogXq 2LWUYr1dTeVLEjYIlFydKEbVPu3.x3RpBDJrdtHEJijsXwRexrVxvrkLpMQeqUWT6Rb6SaICaVqP VuBNXGicY8ETQC5Z79Nlz0XAfXWC0ZyTGme4KE9GawcBCYUwVRwx5ovQVOJgvAQSLX75xqsk5zLq w4FGyRQsmLiKcZMROKubpHBatvDOhGsoMViPOmnhzG2mUc_k2PUdR9QR0lg6GjWIr2o2gqXhslgc hbTvk27tlluKJjA7XYw4NOqqZSivIhpFIpgTdbXgpwFSvGVivRrZLuJ9PYEJ3pKcj1fHV3S5VTD2 SpbfW2epN9yMVwY0_0QsBjEktLs6bp0xPxozz3hLJ1Vgc6zjUZoeiB7DE03LydIvKZn.3aAI11r3 kCnskgGFFpFm0IT0FkD.1Ye66tpuJOoeUYvLHS2Byc3F1GRZmfubHD3ZU5bb4_U.9mFuguXye8UT Ph9QO4tdSKOVuwQurFC2NH6dxqmYfgnb9jPQQg9Yete7T29vKlS1m6b.sEYhydCbSstN2WLd1M4Z Xl_bR5c_z2Xr.SoSnrJ8SJm4KfuDCPzO.8aPpTVahvOJvgLc4Se0tafk0xrZV1ORg7kIqFrJnDju EqkF0TXaq55PpnsaKD1z4dqKsvJmG7rAwZPuP_nYiKewHcXMa7J6h66FrE4LL7lshuiCZNYbjjcQ riGnRyJtaGPXNXaDMbJ6gakxpobH5CvhlYW2nWD_1j0hGcn8LNVqb7ZLh.WYY0.2F52pvA4jO1xo 965iwcXHH_DqUvp.jZfsHwmAsdFH12Xv6Pw5PJG.cGD9SbZDy1r5L5vsLArF_uxXmFdpGwZoRyce vR_bTjzRPLIZZypQ3crBG_JVjxOGbJ1aDDj9RxJH06R5RuzdJsfunYBtRMBT8mf5Zx4OwEdwCj9H ne2wkBgHjtsanbnvzc8U04qyGU6Zw8Ma2uP0RLKDjBlT_j6B.OtmoqiTDHaEA4mAPS5TmqsEW2uU jtKm_4dIBB5X1ky8NPWmvLWKXww7vTd9mTMtxZSQ7SJeRM91IAtey4hbRv7c9A0oYUcBGTLyJrZD 0Ik_PvGHSPqj0HPvQ97n88l54lezgopnDvQC2AKNchz9cSBRumCEGhFMqS7a1fmfuCMIddtwFdTc pGN15U61MejvoLAZndfGjbBuneTSsR8JQSiuek8Y9srIrk6yVf7ZXYcfkOZrBg0wtWASGZHEun35 awN6neHJHSZv_kqfmYG3O0svB6NV5cXJkwwweEIMmX6c5khkOAN9ASb5SHavtRcI7JH1t6UgcWPO qdQC.._oC4Gn54BYODxymZCKOjzldJRGvc2pNDohfc7q_AFc23V0dq_cTBauKut8VJFr3FIYu6NK rS3WPiS8xJfNv0v1eYBDAqI6HoZI.YYMgs8OGLyuBwfvOEOXy6NLF_i_oQgM7ObvDskZOT2uyCid WLt9vNYcS X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 19:50:23 +0000 Received: by hermes--production-gq1-686964ccb6-fq25x (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4960ff856c766e649e2ea3f0ff4987e8; Sun, 07 Aug 2022 19:50:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Mark Millard In-Reply-To: Date: Sun, 7 Aug 2022 12:50:21 -0700 Cc: Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> References: To: Glen Barber X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M190x71zLz3DR0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=S+FKvDyQ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_MEDIUM(-0.30)[-0.304]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.30:from]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-7, at 12:32, Glen Barber wrote: > Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. >=20 > I honestly do not have any idea where the problems you are seeing are = creeping in. >=20 > Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure = how to proceed otherwise. My guess is that if the release/tools/arm.subr line: chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 was instead (note the added -b use): chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k = ${mddev}s2 then the line: chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a would work as expected and things would still be aligned: no aliasing of BSD vs. freebsd-ufs. (In part this is by prior steps already having achieved alignment of BSD.) But I do not know how to classify doing so: Work around? Known required-procedure for -L rootfs to correctly identify the the freebsd-ufs /dev/${mddev}s2a ? Absent better information from folks that know more, I'd suggest trying such an adjusted release/tools/arm.subr next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in place, if such an experiment can be reasonable. > Glen > Sent from my phone. > Please excuse my brevity and/or typos. >=20 >> On Aug 7, 2022, at 12:10 AM, Mark Millard wrote: >>=20 >> =EF=BB=BFThe oddities look like indicated below. >>=20 >> # mdconfig -u md1 -f = FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220805-e24c5c60d72-257129.img >> # gpart show >> . . . >>=20 >> =3D> 63 10485697 md1 MBR (5.0G) >> 63 1985 - free - (993K) >> 2048 102400 1 fat32lba [active] (50M) >> 104448 10381312 2 freebsd (5.0G) >>=20 >> =3D> 0 10381312 md1s2 BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufs/rootfs BSD (5.0G) >> 0 10381312 1 freebsd-ufs (5.0G) >>=20 >> So: ufs/rootfs apparently identifies the BSD instead of the >> freebsd-ufs . Same for the ufsid/* . This leads to: >>=20 >> # gpart show -p=20 >> . . . >>=20 >> =3D> 63 10485697 md1 MBR (5.0G) >> 63 1985 - free - (993K) >> 2048 102400 md1s1 fat32lba [active] (50M) >> 104448 10381312 md1s2 freebsd (5.0G) >>=20 >> =3D> 0 10381312 md1s2 BSD (5.0G) >> 0 10381312 md1s2a freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufsid/62ed01f3345560d8 BSD (5.0G) >> 0 10381312 ufsid/62ed01f3345560d8a freebsd-ufs (5.0G) >>=20 >> =3D> 0 10381312 ufs/rootfs BSD (5.0G) >> 0 10381312 ufs/rootfsa freebsd-ufs (5.0G) >>=20 >> freebsd-ufs has the unexpected label: ufs/rootfsa >>=20 >> # ls -Tld /dev/ufs/* >> crw-r----- 1 root operator 0x6c Aug 6 20:19:58 2022 = /dev/ufs/rootfs >> crw-r----- 1 root operator 0x6e Aug 6 20:19:58 2022 = /dev/ufs/rootfsa >>=20 >> Things were actually set up for ufs/rootfs naming as the >> identification of the freebsd-ufs content, per the >> release/tools/arm.subr commands ( from last month's >> main-n256584-5bc926af9fd1 ): >>=20 >> if [ "${PART_SCHEME}" =3D "MBR" ]; then >> chroot ${CHROOTDIR} gpart add -t '!12' -a 512k -s = ${FAT_SIZE} ${mddev} >> chroot ${CHROOTDIR} gpart set -a active -i 1 ${mddev} >> chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 >> chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} >> chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 >> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 >> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a >> fi >>=20 >> Note that the newfs command references /dev/${mddev}s2a instead >> of /dev/${mddev}s2 but the rootfs label ends up referencing >> /dev/${mddev}s2 . >>=20 >> Is having "0 10381312" for the md*s2 and for the md*s2a a >> fundamental problem? Does freebsd-ufs ( a.k.a. md*s2a ) need >> to be moved to a different (non-zero) offset inside BSD? >>=20 >> Or is this a different kind of bug? >>=20 >> I'll not repeat the kinds of explorations that I reported last >> week unless someone wants to request something. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 7 22:16:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M1DFS2Q98z4XxZm for ; Sun, 7 Aug 2022 22:16:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1DFS1F2Lz3ZbB for ; Sun, 7 Aug 2022 22:16:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659910586; bh=q1/2YIMYpXRcIrFkcVOiazxroVFTq+djsanbzkZTRA8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=CsitsPvrTeqoMEv1OTMEccJbnviA2LJFfkgr+mKNpO7o7JnBbLzNEUqt2HrVPfU/wtl5mDhJat+hbqXd+HdF8PswssZk2HWw6OpyXbC6JPK4d+fIkHDWi54fpUv6LHHZMWuRixgqWEvaFoyKUet72N3KkXsrh1JdKpedMAg8/Q4bNkuFVxjWsi7/2wO3Ch9frji8yjbUeHYjSbSNRFCatXjJxslX/xp5ufkds3nE0YF5bUdjUZA+xpJ+fiJv4GrdSVfsZbzCvqYbTulwVZWuqsDEK8MTPgJIbYnYnV5WtjDjSTR/jdCE77bCr9yVvjB/uS69T3IWpdSKTeRTeYg08A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659910586; bh=57pN1WQ9GzQB09QQBikyGMlyPAO1ZH87JxigUw1O5o8=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cmPqIgpQMwDEnqeHGKKh4kGGF463lcjh9Rg6GwySy3yqDANwCpLWQVGpoVF5jb6V5nsHJJK+VOAXfR/tokgRsFfCML+DSov0loVncHOU3WAIMOlyvcs/ElY/86D4oC6gM6F9+p5/oayzZBuVmxJZQfyM5jMUICwINx8oMPldu0E/vq5q/DRTFQa86xyMT94IHOwl+U3h7Ut6xMTw+PynYJ34HRr1FxBLTqWGzsOzDaHU75A/1kF9D+4k8Xv4//tdkjTCn9JaxymFcp+Clh3rhjPzzX61rv8yqgYHgQN7eSu22RTJCwXqv6zjQZndXXuGFFxGb1ww0m2f1+cOKdIoCA== X-YMail-OSG: 4B_Md_YVM1mADBAJvyUQOp1H7JC.1HvkDGM0A36vTQQs7v70jQL4PBxQhoZI8ga 3h1TQjk0c8Q.Lsp5ShxBuHoRMcFrx2sIf.HOC1V3LJXewTK3kX4a1Nz4ixpVW4ue70EaQe5swM5e 6OMrnxQwq5Aug_KJT52cHMm9BiJkumbd0vqSqr1czsPUZh7Naz106dJ9dR7KD9_maYUpGoWyxe0K wC5bJhdHmZUtV1XuaxgZ5ADb.PKFhYdlJ9QmibNQHKwSKnTz8CaR5.4m5r0DaeeDWvmUM6cmt39q BQzywbznUqNzcr2fUp2MxvXBt0Yy97wH9KNCobXGh1f_obwpi2yHXtR8CxpsJVQEe2ralbcMInVo LpyUBdSTs.xRSSUXVhiJLeDnq82Amm0y2su2LQFt9dxWENHDxB4XS.odkQtgIIGX_LmKy7dG.yDq hAjGJDmTF6L.Z6HZnXUVSz4b9qoa_ZkV6mj3Zw8gc8hgIW0yCeBY5xB4laGqV7UioJ7fhGUEwMKv X7g2Tpb3eAG9OPh5JW_7qI4NyIqkAp9HKVjqYcGMkZOJ1Ucn1Dc132U40qCHN6PP3MWka_vNrf3j rmOeJjzcxbfLDGBuDfatDn52R40qa5acUxF940IUHZBp4eBsY10pcCXJZTLUpY6kmZwPnokapoFr 4mSXaM2PXfj8gG.Q1z3q__3rgW4w7cSFBiaewl7zjLw7OY_PKjkIIbxBGiiLtWLqtHqnUK2iZSJI B51yperhyVZvikufxjugLK5Uu1aPxa6sM9wwIaH.Udx_TAPiwVN1xZnVGRFXhtfx8zsJ1bg2z73L 703kcubsQt.Ka7Hv2A1uMkbmZXLLE6YLBTP35ToDDcU0mpY4yAM5z2ChWJxpFx5VJTZuenzqzJPX lF5V5q4gu_.yRVNJ83MyqnyKI7hV9osxeHagnuEW_4b4JZotAC9I7_isf9JzlL49eCOfATbhM08B lniX8wjSsGHP3cE1ZsycjrKShhVpYt5CeD47DorDqRXHGd_J3uFysG6SM6LRrsiH.3tp.aedEZjj CKPrY19RSzB9EIfaMA5uKG_F90wVOpKDG2bWlwU2NhuFKeOWu8EesUQorfbiozdWVkgItu0.Jk5N trDjkuQXtnCAiIXtpOpwpO06nH0nqT_jFSa.jZqUoOfFoa2gj1vu5mSqyjBhIstcxbHrC9VLGogF 3.KP9TZXFqzo.E0L0giXddYOFWWmPHtNsbsFiClwiUMEbN.Rmn6XzzyEZPuC2DO4dVC6bAhP5xwH HHdOOBnF_j2pu617amw5F54JJF3Tdwl7Kll2I.wckBF.GP9IiIpYxPNyurPcEasDNzzERLqW4klR AutIW2B6G5A6QqSx2H0gci_KPVTZQNlWaemoiT376K_1xQVFwermhd7f9pI3qw5BxZ8P2Ul3pcGe Kulkq6kP3dXjUIwyIAie.xH6AAekTSW0FfG4iyYJ65D3wRNdhJuTiRbqqpwy_INKzxLCHiB3U4RA SVcUlc.Q_DjFjhrpGDM5eXmLRMEfp_uqiXBp8h9VheBzNMw6AQwj3h0Qemea2kCLiUzPkDJbjc0D GvqJjlU8Os0Mk0Up9L2TYD9JEw4xJMFT0wdOXF4H9k0kAYnD3cUYUu.E.X9ZgnLX.BxjCQVCsg._ IS1kTzR5c652qBUiyeP_lvwJ1Lq541.GqXvyfQCLGSwe8n5kydU.k1LxYv.B8YGlemfSsMvE_5FH ABjlzZg7OCjE1iq1gHrGOlP0wm6XrJ3MIpHfVmgr1ag.rroVOXi0zd_sD3.AoPNTOmoUw35EUuuT LZcUYEaiqVMfmfUKrJvHc0fmD4fWzX8it5Y_X8jnUhZrSBRVg2Fip.1fytiyqpzb1pTj3wJGfgzU fVfzNAO8rSfWRKmSsNDkLV7mCpO9xR.becYjRIdZ5DFYX0ToofeMUZlg54cbyvAGAi7KtylBmpcb iQzo8hjWVK3A2CeirmjSUVy0cxPXY_Ue6F2yXShMda87ncWl6qKQvbStalw0- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 7 Aug 2022 22:16:26 +0000 Received: by hermes--production-ne1-6649c47445-znbvb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID afe50112fc0d2df2592cf31fd213da77; Sun, 07 Aug 2022 22:16:21 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Mark Millard In-Reply-To: <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com> Date: Sun, 7 Aug 2022 15:16:19 -0700 Cc: freebsd-arm , Glen Barber , Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <2016951A-BF16-4780-85FF-0B77E91FBBD4@yahoo.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <99DC4046-AB8D-4D10-9475-94A8DC89DCFA@cyclaero.com> To: "Dr. Rolf Jansen" X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M1DFS1F2Lz3ZbB X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 2022-Aug-7, at 14:51, Dr. Rolf Jansen = wrote: >=20 >> Am 07.08.2022 um 16:50 schrieb Mark Millard : >>=20 >> On 2022-Aug-7, at 12:32, Glen Barber wrote: >>=20 >>> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. >>>=20 >>> I honestly do not have any idea where the problems you are seeing = are creeping in. >>>=20 >>> Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure = how to proceed otherwise. >>=20 >> My guess is that if the release/tools/arm.subr line: >>=20 >> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 >>=20 >> was instead (note the added -b use): >>=20 >> chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a = 64k ${mddev}s2 >>=20 >> then the line: >>=20 >> chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a >>=20 >> would work as expected and things would still be aligned: >> no aliasing of BSD vs. freebsd-ufs. (In part this is by >> prior steps already having achieved alignment of BSD.) >=20 > =46rom a strict mathematical stand point of view, -a is not necessary = when using -b with an aligned value. "-a" controls more than the start offset: also the size. QUOTE -a alignment If specified, then the gpart utility tries = to align start offset and partition size to be multiple of alignment value. END QUOTE I expect your statement would at most apply to the start offset, not to everything "-a" does. > Personally I don=E2=80=99t use the -a option of gpart anymore since it = started to do funny magics in front of face. If I remember correct, = gpart of the FreeBSD 9.x-RELEASES was still OK (or was it 8?). Nowadays, = I align all my storage media by employing -b with a reasonable value. >=20 I've no clue of the specifics that you are referencing and so can not = check. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Aug 7 22:43:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M1Ds46nylz4Y2BB; Sun, 7 Aug 2022 22:43:52 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from mail0.glenbarber.us (mail0.glenbarber.us [IPv6:2607:fc50:1:2300:1001:1001:1001:face]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail0.glenbarber.us", Issuer "Gandi Standard SSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1Ds46Nvsz3cxM; Sun, 7 Aug 2022 22:43:52 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from smtpclient.apple (70.15.90.15.res-cmts.sewb.ptd.net [70.15.90.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by mail0.glenbarber.us (Postfix) with ESMTPSA id BBF3D56203; Sun, 7 Aug 2022 22:43:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 mail0.glenbarber.us BBF3D56203 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Glen Barber In-Reply-To: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> Date: Sun, 7 Aug 2022 18:43:44 -0400 Cc: Warner Losh , "Rodney W. Grimes" , Ed Maste , FreeBSD Hackers , freebsd-arm Message-Id: <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> To: Mark Millard X-Mailer: iPhone Mail (19G71) X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M1Ds46Nvsz3cxM X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Will do. I=E2=80=99ll commit the suggested change to main tomorrow. Thank you for your vigilant investigation. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Aug 7, 2022, at 3:50 PM, Mark Millard wrote: >=20 > =EF=BB=BFOn 2022-Aug-7, at 12:32, Glen Barber wrote: >=20 >> Correct, it was set to =E2=80=9C0=E2=80=9D for these builds. >>=20 >> I honestly do not have any idea where the problems you are seeing are cre= eping in. >>=20 >> Should it be set back to =E2=80=9C1=E2=80=9D? I=E2=80=99m not sure how t= o proceed otherwise. >=20 > My guess is that if the release/tools/arm.subr line: >=20 > chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s= 2 >=20 > was instead (note the added -b use): >=20 > chroot ${CHROOTDIR} gpart add -t freebsd-ufs -b 64k -a 64k ${= mddev}s2 >=20 > then the line: >=20 > chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a >=20 > would work as expected and things would still be aligned: > no aliasing of BSD vs. freebsd-ufs. (In part this is by > prior steps already having achieved alignment of BSD.) >=20 > But I do not know how to classify doing so: Work around? > Known required-procedure for -L rootfs to correctly > identify the the freebsd-ufs /dev/${mddev}s2a ? >=20 > Absent better information from folks that know more, I'd > suggest trying such an adjusted release/tools/arm.subr > next week, leaving kern.geom.part.mbr.enforce_chs=3D0 in > place, if such an experiment can be reasonable. >=20 >> Glen >> Sent from my phone. >> Please excuse my brevity and/or typos. From nobody Mon Aug 8 21:33:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M1qFR3gG1z4YDRS; Mon, 8 Aug 2022 21:33:31 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1qFR3FMtz3xn7; Mon, 8 Aug 2022 21:33:31 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659994411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gXWe/CxpRoBpbu6t8DEMSob1zm2H86CyCB29WkrdZcY=; b=ApjfObVZwF0m58HvXMStRtakmI1rx9ZegfX4jaomPt0RSaj17p3tsTuTlKtv1QOrxW/M1w djic/MZbUhH6jn+TNaCw8lRn1vtkruE5zm/0nkdg3RtDGSJ0yMPKxrhQTD8xWtJpBu81FZ ny1WXoJ1sCiFQ3M1dsxauJKciVPXFIbMkE1Oaw8VYoh8X827selS+3BIUuRALxwCUuODbZ 7CWCb+KFaUJBG+/9PvYdelPPe/AufuMfhKWASydbIMLpiHlyyfKU19S8Vof8iPbTYfADF/ 8f7VZrhMo6jlRTDqHhYkipJaCzliMQgdtLSKtpYbvdKPK+gCbrdVpvAY+lQCSA== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 5D4AC13A44; Mon, 8 Aug 2022 21:33:31 +0000 (UTC) Date: Mon, 8 Aug 2022 21:33:31 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2022 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename="report.txt" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659994411; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=gXWe/CxpRoBpbu6t8DEMSob1zm2H86CyCB29WkrdZcY=; b=MLS4Zl+g/F2bikcHUsN2ggNZDUOEBE99himJeHJGQ3tZOUdiVDm1gnvx6zMQ9DCK+rZzkh G0+6O4OXKrg61Ij2msUopN3EwxsuK7rG7m3/MVICXneJBeb8SfIbiCdncB1YjNFVb2oNWl UL4Ghwz7X0jmiTlJSg3z0f6aDd07Z+NAq3ITXidpOxdcRlcRNgtHfq6q+Cx6l0PUlpx5TS x5Ff8mCehTIHbTgM9rNnR5w3+5zyK85ieFVAJllAoEoZ9E+8VgKiTqoL+8bLFSD4rrjkQU dSDNViWWXHZxwxc7d/uu3p7GhSVWDc+ggnojpv2EQ5ejUEHIRU7eR0jnrOLd+w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659994411; a=rsa-sha256; cv=none; b=aSLcxrkFLcHLrVzZ63kZq0VdVPyYvUbew1R0gnNNZbk5KZb9Z3YzM/JmFAtrgFGquvopvZ DE90Mox0r45Qjsyt85+1aA660RMG4lMzI/Srkrp0+eHlO8uViOogcmSrKjoy5553McLuFS v8f66xZRrjQI+WkbwpAK6v4A+cVdm9dVzdJAWIi/H0W3mEVAbvGutOpdxQ8S7mEdvBhRAu mpqnWRT7w86194Aa/3RHK3/bG2VPzD3aE/G4tm+UhHrzC/lQxzAz1/0AqXirghQmJh7EJp rp+f4X3KJjR/hjBRarmW7FhhHjIyjpfXwnpTUf6kRkVqf2tVxdF1vat141zdRg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N FreeBSD Quarterly Status Report Second Quarter 2022 Here is the second quarterly report of 2022, with 26 reports included. This quarter the quarterly team managed to publish the report much faster and, hopefully, with much fewer mistakes. If however you notice some errors, please report them so that we can correct them and also add some automatic checks in our tools to prevent them in the future and stay as efficient as possible in the pubblication process. We would also like to remind you that if for any reason you need more time to submit a quarterly report, the team will wait for you, but please warn us so that we are aware that some report is still missing. Many thanks to all those that have chosen to share their work with the FreeBSD community through the quarterly reports. Lorenzo Salvadore, on behalf of the status report team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2022-04-2022-06/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection • Projects □ Linux compatibility layer update □ go on FreeBSD riscv64 □ FreeBSD on Microsoft HyperV and Azure • Userland □ Ongoing work on LLDB multiprocess debugging support □ ZFS support in makefs(8) □ Base System OpenSSH Update □ pf status update • Kernel □ ENA FreeBSD Driver Update □ New Bluetooth® configuration daemon: blued □ OpenVPN DCO □ Wireless updates □ Shared page address randomization • Architectures □ NXP DPAA2 support □ Medium-sized superpages on arm64 and beyond • Documentation □ Documentation Engineering Team • Ports □ KDE on FreeBSD □ Elsewhere □ GCC: updating GCC_DEFAULT and other improvements □ Valgrind - Numerous bugfixes and updates for 13.1 / 14.0 □ Pantheon desktop on FreeBSD □ Feature Complete Port of Intel’s igt-gpu-tools ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. The twelfth FreeBSD Core Team was elected by active developers. The core.12 members are: • Baptiste Daroussin (bapt, incumbent) • Benedict Reuschling (bcr) • Ed Maste (emaste, incumbent) • Greg Lehey (grog) • John Baldwin (jhb) • Li-Wen Hsu (lwhsu) • Emmanuel Vadot (manu) • Tobias C. Berner (tcberner) • Mateusz Piotrowski (0mp) On June 10th the outgoing core.11 and incoming core.12 teams held a handover meeting, and the new Core Team was announced on Jun 18. The current Core Team secretary, Muhammad Moinur Rahman (bofh), will step down after the appointment of a new Core Team secretary and handover tasks completes. In this quarter, src commit bits of Kornel Dulęba (kd) and Dmitry Salychev (dsl) have been approved. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.FreeBSDFoundation.org Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/ Donate URL: https://www.FreeBSDFoundation.org/donate/ Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/ FreeBSD-foundation-partnership-program FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/ Foundation News and Events URL: https://www.FreeBSDFoundation.org/ news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Fundraising Efforts First, I’d like to send a big thank you to everyone who gave a financial contribution to our efforts. We are 100% funded by your donations, so every contribution helps us continue to support FreeBSD in many ways, including some of the work funded and published in this status report. Our goal this year is to raise at a minimum $1,400,000 towards a spending budget of around $2,000,000. As I write this report, we’ve brought in under $200,000 towards that goal. So, we obviously need to step up our effort of fundraising. It’s by far the hardest part of my job. I’d much prefer talking to folks in our community on how we can help you, help create content to recruit more users and contributors to the Project, and understand challenges and painpoints that individuals and organizations have in using FreeBSD, so we can help improve those areas. Asking for money is not on that list. We support FreeBSD in five main areas. Software development is the largest area we fund with six software developers on staff who step in to implement new features, support tier 1 platforms, review patches, and fix issues. You can find out some of the work we did under OS Improvements in this report. FreeBSD Advocacy is another area that we support to spread the word about FreeBSD at conferences, in presentations online and in-person, tutorials and how-to guides. We purchase and support hardware for the FreeBSD infrastructure that supports the work going on in the Project. Virtual and in-person events are organized by the Foundation to help connect and engage community members to share their knowledge and collaborate on projects. Finally, we provide legal support to the Project when needed and protect the FreeBSD trademarks. If you haven’t made a donation this year, please consider making one at https:/ /freebsdfoundation.org/donate/. We also have a Partnership Program for larger commercial donors. You can find out more at https://freebsdfoundation.org/our-donors/ freebsd-foundation-partnership-program/ OS Improvements During the second quarter of 2022, 243 src, 62 ports, and 12 doc tree commits were made that identified The FreeBSD Foundation as a sponsor. This represents 10.6, 0.7, and 4.5% of the total number of commits to each repository. Sponsored Work You can read about some of the Foundation-sponsored work in individual quarterly report entries. • Base System OpenSSH Update • Ongoing work on LLDB multiprocess debugging support • Wireless Status • ZFS support in makefs Other ongoing sponsored work is described here. • FreeBSD Wireguard Improvements The aim of the Wireguard project is to improve support for the FreeBSD Wirguard kernel module. The work by John Baldwin involved adapting the module to use FreeBSD's OCF rather than Wireguard's internal implementations. It also involved adding new ciphers and API support. The latest upstream release incorporates this work. • Openstack on FreeBSD OpenStack is a cloud system for different types of resources like virtual machines. However, OpenStack only unofficially supports FreeBSD as a guest system. That means users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible run OpenStack on FreeBSD hosts. The goal of this project is port OpenStack components so that FreeBSD can function as an OpenStack host. • Bhyve Issue Support The Foundation recently signed a new contract for Byhve support. This contract will allow John Baldwin to dedicate time to Bhyve as issues arise, especially security issues. • Handbook Improvement Exploration Under sponsorship from the Foundation, Pau Amma wrapped up a mini-project to explore how the Handbook can be improved. A survey was sent out and the results will be shared soon. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. Supporting FreeBSD Infrastructure The Foundation provides hardware and support for the Project. A new Australian mirror was brought online by the Cluster Administration team. If you are a FreeBSD user in Oceania or southeast Asia, please let us know if download speeds for installer images and packages has improved. With your donations, the Foundation purchased new hardware to repair two PowerPC package builders, one for little endian packages (powerpc64le) and the second for big endian packages (powerpc64, powerpc). The new hardware just arrived at the data center and will be installed soon. Expect lots of PowerPC packages in the near future. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature and video tutorials, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are continuing to attend virtual events and planning the June 2022 Developer Summit. In addition to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: • Secured our booth and nonprofit sponsor status for All Things Open, October 30-November 2, 2022, Raleigh, NC. • Finalized our booth and workshop at Scale 19x in Los Angeles, CA on July 28-30. The FreeBSD workshop will be held Friday,Jul 29, 2022 and you can visit the Foundation at booth 502. • Confirmed our Silver Sponsorship of EuroBSDcon 2022, September 15-18, Vienna, Austria • Sponsored and helped organize the June 2022 FreeBSD Developer Summit, June 16-17, 2022. Videos are available on the FreeBSD Project YouTube channel. • Celebrated FreeBSD Day June 19, 2022 and throughout the following week. • Secured our Friends level sponsorship of COSCUP, July30-31, Taiwan • Published the FreeBSD Foundation Spring 2022 Update • New Blog Posts □ Let’s Talk About Foundation Funding □ New Board Member Interview: Cat Allman □ Welcome FreeBSD Google Summer of Code Participants □ FreeBSD Foundation Work in the 13.1 Release □ Foundation Elects New Officers, Interviews Outgoing Board Members □ Help Us Celebrate FreeBSD Day All Week Long • New and Updated How-To and Quick Guides: □ Networking Basics: WiFi and Bluetooth □ Audio on FreeBSD □ Installing FreeBSD with VirtualBox (Mac/Windows) - Video Guide □ An Introduction to the FreeBSD Operating System - Video Guide □ Installing a Desktop Environment on FreeBSD - Video Guide □ Installing a Port on FreeBSD - Video Guide We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https:// www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https:// www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.FreeBSDFoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 13.1-RELEASE schedule URL: https://www.freebsd.org/releases/13.1R/ schedule/ FreeBSD 13.1-RELEASE announcement URL: https://www.freebsd.org/releases/13.1R/ announce/ FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the second quarter of 2022, the Release Engineering Team completed work on the 13.1-RELEASE cycle. This is the second release from the stable/13 branch. Throughout the release cycle, three BETA builds and six RC (release candidate) builds have occurred, moving the final release date from April 21, 2022 to May 16, 2022, as some last-minute issues were identified. We thank all FreeBSD developers and contributors for testing the 13.1-RELEASE, reporting problems, and being diligent with proprosed changes as the cycle progressed. Additionally throughout the quarter, several development snapshots builds were released for the main, stable/13, and stable/12 branches. Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration /#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: • Installed a new mirror in Sydney, Australia hosted by IX Australia • Fixed CI cluster hardware failure • Set up a new internal monitoring system • Regular cluster-wide software upgrades • Regular support for FreeBSD.org user accounts Work in progress: • Work with the PowerPC team to improve the package builders, universal, and reference machines. • Plan Hardware refresh, and fixing misc failures in each sites • Improve the package building infrastructure • Review the service jails and service administrators operation • Working with doceng@ to improve deployment of https://www.freebsd.org and https://docs.freebsd.org • Improve the web service architecture • Improve the cluster backup plan • Improve the log analysis system We are looking for an additional full mirror site (five servers) in Europe. See generic mirrored layout for our needs. Offers of additional single-server mirrors (see tiny mirror) are always welcome too, especially in Europe. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. During the second quarter of 2022, we continued working with the contributors and developers in the project to fulfill their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important completed tasks: • Fixed the hardware failure issue of the CI cluster Work in progress tasks: • Designing and implementing pre-commit CI building and testing (to support the workflow working group) • Designing and implementing use of CI cluster to build release artifacts as release engineering does • Testing and merging pull requests in the FreeBSD-ci repo • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Organizing the scripts in freebsd-ci repository to prepare for merging to src repository • Updating documents on wiki Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Adding more external toolchain related jobs • Improving maturity of the hardware lab and adding more hardware for testing • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don’t hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/# ports-contributing FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. The number of ports is slightly above 30,000. The last quarter saw 9,137 commits by 151 committers on the "main" and 589 commits by 61 committers on the "2022Q2" branch. At the time of writing, there are 2,700 open ports PRs of which 682 are unassigned. Compared to the previous quarter, there was a slight decrease in commit activity and a constant number of PRs. Note: Freshports appears to overcount substantially. This quarter’s ports count was derived differently and is not comparable with the previous quarter’s. During the last quarter, portmgr welcomed back salvadore@ but also said goodbye to seven ports committers due to lack of activity. In its bi-weekly meetings, portmgr discussed the following topics: * the future of ca_root_nss * feasibility of the base system providing certain .pc files * ways to deal with incompatibilities in kernel module ports on minor version upgrades of the base system Following a discussion among developers, portmgr decided to grant all documentation and source committers approval to fix any documentation-related error in the Ports Tree which does not affect its functionality. The following changes were made to the Ports Tree during 2022q2: * pkg got updated to version 1.18.3, Firefox to version 102.0 and Chromium to version 103.0.50060.53 * Default versions of GCC, Lazarus, Python and Ruby got updated to respectively 11 (powerpcspe keeps version 8), 2.2.2, 3.9, and 3.0. * Two new USES were added, gstreamer to support ports based on GStreamer plugins and pytest to help testing with pytest. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. Linux compatibility layer update Contact: Dmitry Chagin Contact: Edward Tomasz Napierala < trasz@FreeBSD.org> The goal of this project is to improve FreeBSD’s ability to execute unmodified Linux binaries. Current support status of specific Linux applications is being tracked at the Linux app status Wiki page. Implementation of the Y2k38 Linux project is mostly finished; all '*_time64()' system calls are committed. The state of the arm64 Linux emulation layer was brought to the state of the amd64 Linux emulation layer: i.e., implemented the vDSO, machine dependend futexes, signals delivery. The thread affinity system calls were modified to implement Linux semantics. In total, over 50 bugs were fixed; glibc-2.35 tests suite reports less than 80 failed tests. All changes in the Linux emulation layer are merged to the stable/13 branch. Initial support for fancy Linux system call tracing has been added to libsysdecode and kdump. There is ongoing work to make tracing more syscalls work. Sponsor: EPSRC (Edward’s work) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ go on FreeBSD riscv64 Links: golang Home Page URL: https://github.com/golang/go FreeBSD riscv64 github repo URL: https://github.com/MikaelUrankar/go/tree/ freebsd_riscv64 FreeBSD riscv64 golang issue URL: https://github.com/golang/go/issues/53466 Contact: Mikaël Urankar Contact: Dmitri Goutnik Work has been done to port go on FreeBSD riscv64 which builds and passes all run.bash tests, including cgo (tested under QEMU and on Unmatched). A pull request is created upstream and the proposal has been added to the active column of the proposals project and will be reviewed at the weekly proposal review meetings. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD on Microsoft HyperV and Azure Links: Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/ MicrosoftAzure Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV Contact: Microsoft FreeBSD Integration Services Team Contact: freebsd-cloud Mailing List Contact: The FreeBSD Azure Release Engineering Team Contact: Wei Hu Contact: Li-Wen Hsu The 13.1-RELEASE image on Azure Marketplace has been published. Work in progress tasks: • Automating the image building and publishing process • Building and publishing ZFS-based images to Azure Marketplace □ The taks will be benefited by merging of ZFS support of makefs(8) and release(7) ☆ https://reviews.freebsd.org/D23334 ☆ https://reviews.freebsd.org/D34426 ☆ https://reviews.freebsd.org/D35248 • Building and publishing Hyper-V gen2 VM images to Azure Marketplace □ Blocked by https://bugs.freebsd.org/264267 The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft. Wei Hu and his colleagues in Microsoft are working on several tasks sponsored by Microsoft: • Fixing booting issue on Hyper-V gen2 VM in Azure □ https://bugs.freebsd.org/264267 • Porting Hyper-V guest support to aarch64 Open tasks: • Update FreeBSD related doc at https://docs.microsoft.com • Support FreeBSD in Azure Pipelines • Update Azure agent port to the latest version • Upstream local modifications of Azure agent Sponsor: Microsoft for work by Wei Hu and others in Microsoft, and for resources for the rest Sponsor: The FreeBSD Foundation for everything else ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. Ongoing work on LLDB multiprocess debugging support Links: Moritz Systems Project Description URL: https://www.moritz.systems/blog/ multiprocess-support-for-lldb/ Progress Report 1 URL: https://www.moritz.systems/blog/ implementing-non-stop-protocol-compatibility-in-lldb/ Contact: Kamil Rytarowski Contact: Michał Górny According to the upstream description, "LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler." FreeBSD includes LLDB in the base system. The previous sponsored projects improved LLDB, to make it a credible debugger for the base system, although it still has a few limitations compared to the contemporary versions of GNU GDB. This project started in April 2022. It aims to implement full support for debugging multiple processes simultaneously. At the start of the project, LLDB featured very limited support for multiprocess debugging. The client featured support for debugging multiple independent processes simultaneously via maintaining multiple connections to different server instances. Thanks to our earlier work, the server was able to process fork(2) and vfork(2) calls and either detach the newly forked child and continue tracing the parent process, or detach the parent and follow the child (equivalent to GDB’s follow-fork-mode setting). Once the project is finished, LLDB will be able to trace an arbitrary number of forked processes simultaneously (equivalent to GDB’s detach-on-fork off). Full support for the multiprocess extension to the GDB Remote Serial Protocol will be implemented, as well as partial support for the non-stop extension that will enable multiple processes to be resumed and stopped independently. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ZFS support in makefs(8) Links: Mailing list post URL: https://lists.freebsd.org/archives/freebsd-hackers/ 2022-May/001128.html makefs(8) code review URL: link:https://reviews.freebsd.org/D35248 release(7) code review URL: link:https://reviews.freebsd.org/D34426 Contact: Mark Johnston makefs(8) is a utility, originating in NetBSD, that creates file system images entirely in userspace. It is a useful component of a toolchain to build virtual machine (VM) images since it does not require any special privileges, unlike the approach of formatting a character device, mounting the fresh file system, and copying files onto it. Moreover, makefs can create reproducible images and aims to minimize resource consumption. Currently, FreeBSD’s makefs can build UFS, cd9660, and msdos (FAT) file system images. Recent work enables the creation of ZFS images by makefs. This makes it easier to build ZFS-based VM images. makefs' ZFS support includes the ability to create multiple datasets, with each mapped to a directory in the input file hierarchy. Many ZFS features are not supported however, as the implementation provides only what is needed to get reproducible root pools. Follow-up work enables the creation of ZFS-based VM and cloud images by the release(7) framework, using this new makefs extension. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Base System OpenSSH Update Links: OpenSSH URL: https://www.openssh.com/ OpenSSH 8.9 release notes URL:https://www.openssh.com/txt/release-8.9[https:// www.openssh.com/txt/release-8.9] OpenSSH 9.0 release notes URL:https://www.openssh.com/txt/release-9.0[https:// www.openssh.com/txt/release-9.0] Contact: Ed Maste OpenSSH, a suite of remote login and file transfer tools, was updated from version 8.8p1 to 9.0p1 in the FreeBSD base system. It has not yet been merged to the stable/13 and stable/12 branches. I anticipate doing so in July. NOTE: OpenSSH 9.0p1 switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default. The -O flag is available to use the previous protocol instead. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ pf status update Contact: Kristof Provost Contact: Reid Linnemann < rlinnemann@netgate.com> Ethernet pf recently grew support for filtering on Ethernet layer. See the 2021q2 pf_ethernet report. Since then the Ethernet layer filtering has been extended with: • anchor support • ability to look into the layer 3 header, for matching with source/ destination IP(v4/v6) addresses • table support for IP address matching • direct dispatch to dummynet • pass Ethernet layer packets directly to dummynet, rather than tagging the packets and relying on layer 3 to handle dummynet Dummynet pf recently started being able to use dummynet for packet scheduling. This support has been extended and improved, and is now believed to be ready for production. One notable fix is that reply-to/route-to’d traffic is now subject to dummynet scheduling as well. Last match timestamp pf now tracks when a rule was last matched. Similar to ipfw rule timestamps, these timestamps internally are uint32_t snaps of the system "wall time" clock in seconds. (See time(9).) The timestamp is CPU local and updated each time a rule or a state is matched. Sponsor: Rubicon Communications, LLC ("Netgate") ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ENA FreeBSD Driver Update Links: ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ ena/README.rst Contact: Michal Krawczyk Contact: Dawid Gorecki Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: • Upstream of the ENA driver v2.5.0, which included: • Improvement to the reset routine handling, • Extension of the timer service lifetime in order to be able to detect more hardware failures, • Fix logic for verifying the Tx request ID, • Fix IPv6 L4 checksum offload handling for the Tx, • Add NUMA awareness to the driver. • Internal review of the upcoming ENA driver release (v2.6.0), including: • Further reset handling improvements, • Code cleanup and style fixes, • Logging improvements, • Fix to the retrieval of the ENI metrics. Work in progress: • Testing of the upcoming ENA driver release (v2.6.0). Sponsor: Amazon.com Inc ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ New Bluetooth® configuration daemon: blued Links: blued git URL: https://git.lysator.liu.se/kempe/blued Contact: Mail: kempe@lysator.liu.se IRC: kempe@libera.chat Introduction The blued utility provides an IPC interface that lets an unprivileged user connect to and use Bluetooth devices in a user-friendly way and supports secure simple pairing (public-key cryptography and if the device allows it man-in-the-middle protection). What is blued? There are three parts to blued: a library, a daemon and a command line utility. The library abstracts away bluetooth details, the daemon manages Bluetooth devices and the command line utility lets users list or scan for Bluetooth devices, pair with a device, or unpair from one. The command line utility communicates with the daemon via a UNIX socket. Unlike bthidd and hcsecd, blued supports secure simple pairing and provides an IPC. To get a HID device to work, bthidd is still needed. A script is provided to pair a Bluetooth device and appropriately configure bthidd so it just works and reconnects without user intervention. Once pairing has proven stable and bugs have been ironed out, the plan is to integrate bthidd with/into blued in some way to have HID devices automatically start functioning when paired without the use of an external script. A long-term goal is to provide a graphical user interface that can list devices and provide a simple one-click setup to connect them. Installing and using blued v0.1 You need the optional src component installed in /etc/src. First, make sure you have working Bluetooth drivers loaded as explained in the FreeBSD handbook. To test blued, fetch the blued v0.1 source code. Then compile it, patch your FreeBSD kernel with the patches in kernel_patches, and recompile the hci module as explained in README. I have primarily tested blued on FreeBSD 12.3, but my patches applied cleanly on 13.1 when I tested. I am not supplying a port at the moment, but it is possible to run the software straight from the build directory or run "make install" that will install all needed files. Both blued and bluecontrol use capsicum and blued can be configured to drop its root privileges. For more information, refer to the Running blued section of README. Helping out Testing I have only tried this software with my own mouse and realise that a sample size of one single bluetooth device is pretty small. I’m expecting issues and am greatly looking forward to feedback from others! In case of trouble, output from /var/log/debug.log and /var/log/messages as well as a traffic dump from "hcidump -x" while trying to pair will help with troubleshooting. Contributing If you want to get involved with the code and submit patches, you’re welcome to visit the repository on Lysator’s Git. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ OpenVPN DCO Links: D34340 URL: D34340 OpenVPN wiki URL: OpenVPN wiki Contact: Kristof Provost OpenVPN DCO (or Data Channel Offload) moves OpenVPN data packet processing into the kernel. Traditionally OpenVPN uses a tun(4) interface to transmit and receive packets. In this setup received packets are received by the kernel, passed to the OpenVPN application for decryption, then passed back into the kernel for network stack processing. This requires several transitions between kernel- and userspace, and naturally imposes a performance cost. The new if_ovpn OpenVPN DCO offload driver performs the encryption/decryption entirely within the kernel, improving performance. Initial performance testing shows throughput improved from around 660Mbit/s to around 2Gbit/s. The userspace OpenVPN code also requires modification to use the new if_ovpn offload driver. This is expected to be part of a future 2.6.0 OpenVPN release. Sponsor: Rubicon Communications, LLC ("Netgate") ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Wireless updates Links: Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/ Iwlwifi Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/ WiFi/Rtw88 Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org /WiFi/Rtw89 Contact: Bjoern A. Zeeb The overall project aims to bring support for newer chipsets to FreeBSD currently using LinuxKPI compat code backed by native net80211 and kernel code. In addition the aim is to continue work towards supporting newer wireless standards. During the second quarter 40 commits went into FreeBSD CURRENT. With more users trying multiple drivers support time has also gone up. An earlier version of the Intel iwlwifi-derived wireless driver shipped in 13.1-RELEASE bringing this work into a first FreeBSD release. The iwlwifi driver and firmware were since updated in CURRENT and stable/13 again as part of ongoing development. Changes in files shared with the upstream Intel Linux version of the driver are now less than 400 lines. Lately a longer-standing problem for older chipsets was (hopefully) solved allowing iwm(4)-supported cards to work with iwlwifi(4) again after almost three months. The main focus for the project until the end of the year will most exclusively be getting us to contemporary speeds. On April 1st, using the same LinuxKPI infrastructure built mostly with the iwlwifi work, Realtek’s rtw88(4) driver got comitted into CURRENT. Due to an issue with DMA the next weeks a workaround was developed and put into the tree so users no longer have to patch the kernel. The driver still needs a tunable set in loader.conf for machines with more than 4GB of physical memory. This tunable allowed the driver to be merged to stable/13 in June followed by further updates in CURRENT and stable/13. As the USB parts for rtw88 based chipsets are prepared to be included in Linux, work has started (needing more time) to prepare FreeBSD to be able to support the USB parts as well. During the last months Realtek’s rtw89 has already been compiling and remains a work in progress to run stably and associate before it can be enabled in CURRENT. Thanks to all the users for testing and reporting back, patiently waiting for the next update, bugfix, or just a reply from me. It is a great pleasure to work with you! Keep sending the bug reports to me, but remember that your thanks should go to the FreeBSD Foundation for making most of this possible. For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Shared page address randomization Links: D35392 D35393 D35349 Contact: Kornel Duleba Contact: Marcin Wojtas The shared page is an R/X page that is mapped into each process by the image activator. It stores the signal trampoline, as well as other metadata e.g. information needed to implement user space timecounters. Previously it was mapped at the top of the process virtual address space. With the described changes its address will be randomized. We plan to turn the feature on by default for 64bit binaries, across all architectures. Currently the patches are under review and await approval. Sponsor: Stormshield ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for the new hardware platform. NXP DPAA2 support Links Change history Tree Contact: Dmitry Salychev Contact: Bjoern A. Zeeb Some of the NXP SoCs (LX2160A, LS1088A) are shipped with DPAA2, the second generation of the data path acceleration architecture. It allows to dynamically configure and wire packet processing "objects" (DPNI for a network interface, DPMAC for media access controller, etc.) together to form a network-on-a-chip. During the last quarter the driver started working well enough to be used on SolidRun' Honeycomb LX2 (ACPI test platform) and Traverse Technologies has produced a FreeBSD preview for (their) Ten64 (used as FDT test platform). The driver is still work-in-progress, but is getting close for a review to get the first version into the tree for everyone to benefit from it. WIP: • FDT MDIO support. FreeBSD currently lacks support for the SPF parts. • Driver resources de-allocation to unload dpaa2.ko properly. • Bug fixes and improvements. TODO: • CPU affinity for DPIOs and DPNIs. • Cached memory-backed software portals. • Bottlenecks mitigation. • Further parts (DPSW, DCE, etc.) supported by the hardware. Sponsor: Bare Enthusiasm :) Sponsor: Traverse Technologies (providing Ten64 HW for testing) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Medium-sized superpages on arm64 and beyond Contact: Eliot H. Solomon Contact: Alan L. Cox The 64-bit ARM architecture’s page table descriptor format contains a flag called the Contiguous bit. This tells the MMU that it can cache an aligned, physically contiguous group of 16 page table entries which have identical permissions and attributes using only 1 TLB entry. The Contiguous bit, as well as the conceptually similar Svnapot extension to the RISC-V architecture, allows for the use of 64 KiB superpages. These medium-sized superpages can bring to smaller memory objects the address-translation speedup typically associated with more traditional 2 MiB superpages. This project focuses on bringing support for medium-sized superpages to FreeBSD. So far, we have modified the arm64 pmap code to automatically utilize 64 KiB superpages by detecting physically contiguous page table entries and promoting them using the Contiguous bit. Now, we are working to adapt the kernel’s superpage reservation module to support 64 KiB reservations in addition to the current 2 MiB ones. Adding medium-sized reservations will allow the virtual memory system to explicitly allocate pieces of memory which fit the requirements for superpage promotion, rather than just hoping that they occur by chance. Our goal is to accomplish this in a general way that makes it possible to specify multiple arbitrary power-of-two reservation sizes, making it easier to take advantage of hardware features on other architectures like Ryzen’s PTE Coalescing, which transparently merges groups of 4 KiB page table entries into medium-sized superpages. Sponsor: Department of Computer Science, Rice University ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project Link: FreeBSD Documentation Project Primer for New Contributors Link: Documentation Engineering Team Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter, Graham Perrin (grahamperrin@) and Pau Amma (pauamma@), were granted documentation commit bits. Several items are pending and in discussion: • Mirroring the Website and Documentation portal with the GeoDNS infrastructure of the project. • How to handle Trademarks in the documentation. • Remove outdated translations from the Website and Documentation portal. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate Link: FreeBSD Weblate Instance Q2 2022 Status • 12 languages • 152 registered users (9 new users) Languages • Chinese (Simplified) (zh-cn) • Chinese (Traditional) (zh-tw) • Dutch (nl) • French (fr) • German (de) • Indonesian (id) • Italian (it) • Norwegian (nb-no) • Persian (fa-ir) • Portuguese (pt-br) • Spanish (es) • Turkish (tr) We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Work in progress) 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Work in progress) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Not started) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software from the KDE Community, along with dependencies and related software, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@ as well, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items of import to the entire desktop stack. KDE Stack KDE Gear releases happen each quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release each month as well. These (large) updates land shortly after their upstream release and are not listed separately. • astro/kstars latest release 3.5.9. • deskutils/grantleetheme got an entry in UPDATING because of some unusual changes to the installed structure of the port. • deskutils/kalendar joined the KDE Gear releases. • devel/okteta updates to the binary (and octal and hexadecimal) data viewer and editor. • finance/kraft needed specific build-fixes for newer KDE Frameworks. • games/gcompris-qt expanded, new releases, and now supports more image formats (needed for some activities). • graphics/digikam no longer needs a SQL server during the build. • graphics/krita was updated to 5.0.5, likely the last 5.0 version. • math/labplot has a huge number of new features in recent releases, well worth looking at if you need any kind of data-plotting. • net-im/ruqola was updated. This is a Qt-styled Rocket chat application. • www/falkon joined the KDE Gear releases. Related Applications • archivers/quazip was updated. • deskutils/semantik updated. • devel/py-qt5-pyqt updated so that the port now pulls in DBus as well. DBus is needed by nearly all desktop Qt applications, including those written in Python. • devel/qcoro had build issues on certain FreeBSD versions, resolved. • devel/qtcreator updated with each new release. • devel/qt5 had its infrastructure updated in ports so it does not produce strange error messages during de-installation. • graphics/ksnip and related libraries updated to recent releases. • Matrix clients Nheko (net-im/nheko) and Neochat (net-im/neochat) were updated following releases and library bumps. • x11/rsibreak updated; helps prevent injury while writing long quarterly reports. Elsewhere • devel/appstream update supports more application-information. • devel/cmake prefers generic python3 over versioned-python3, if users have multiple python3 ports and lang/python3 installed. • devel/dbus updated. • graphics/poppler updated several times. • graphics/ImageMagick (both 6 and 7) updated several times. • multimedia/gstreamer updated. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC: updating GCC_DEFAULT and other improvements Links: GCC Project URL: https://gcc.gnu.org GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ Contact: Contact: Gerald Pfeifer Contact: Lorenzo Salvadore Contact: Piotr Kubaj • salvadore@ worked on the upgrade of GCC_DEFAULT in Mk/ bsd.default-versions.mk from 10 to 11, opening bug reports based on antoine@'s exp-runs and fixing some: many thanks to all those that helped with this task. The GCC_DEFAULT update from GCC 10 to GCC 11 has now been committed by gerald@ and happened in time for the next quarterly branch. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378 • pkubaj@ switched GCC bootstrapping to use Link Time Optimization for GCC itself for GCC 11 and newer by introducing a new option enabled by default. Building with LTO_BOOTSTRAP enabled requires significant amounts of memory and time. How much resources are actually needed depends on your configuration (e.g. are you building from ports or with poudriere? What is your architecture?). To give an idea, a user reported needing 5 GiB of tmpfs, while in PR 265254 a need of about 130 GB of memory is estimated due to an excessive amount of processes spawning (see also https://gcc.gnu.org/ bugzilla/show_bug.cgi?id=106328). Consider disabling LTO_BOOTSTRAP in favor of STANDARD_BOOTSTRAP (or disabling BOOTSTRAP altogether) in case that is a problem. • pkubaj@ also added lang/gcc12 and lang/gcc13-devel ports and updated lang/ gcc9 to 9.5. • Help is still needed with these three changes to work through with upstream GCC (requires src expertise, not ports): □ upstreaming lang/gcc11/patch-gets-no-more □ upstreaming lang/gcc11/patch-arm-unwind-cxx-support □ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Valgrind - Numerous bugfixes and updates for 13.1 / 14.0 Links Valgrind Home Page URL: https://www.valgrind.org/ Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html Contact: Paul Floyd A quite significant number of bug fixes have been made to Valgrind on FreeBSD over the past few months. In particular, the i386 version has largely 'caught up' with its bigger brother amd64. The devel/valgrind-devel port has been bumped up to 3.20.0.g20220612,1 which includes all of the following changes. If you use Valgrind regularly please swtch to valgrind-devel. Here is a list of changes since the release of Valgrind 3.19.0 (which is the version available with the devel/valgrind port). • incorrect signal resumption if a signal arrives when Valgrind is saving the carry flag for a syscall • fixed reading DWARF debuginfo from PT_LOADs generated by lld post version 9, which splits the RW segment into two parts, this affects mainly shared libraries (.so files) • on i386 implement correctly the management of thread GDTs which was limiting applications to only ever creating 8192 threads • make the first page of the 'brk' invalid for addressing • analysis and cleanup of the regression test suite and in particular tweak the i386 leak tests to not detect possible leaks due to left over pointers in ECX. • make coredumps readable by lldb • improve the setting of errno by C allocating functions • fix building of Valgrind with llvm-devel (15.0.0) For FreeBSD 13.1 / 14.0 there are • syscall wrappers for funlinkat, copy_file_range, swapoff, shm_open2 • add K_INFO handling to fcntl • add handling for new auxv entries • added some default suppressions for DRD and Helgrind There is now an initial version of vgdb invoker support - this allows vgdb to use ptrace to force valgrind to poll for gdb commands. This is not yet available in the ports versions. That does not leave much in the way of outstanding issues. I expect that 14.0 and newer versions of llvm will keep on requiring support. Apart from that there is • some small problems with error messages getting the correct source information • better core dumps (low priority) • TLS (thread local storage) handling for Helgrind (difficult if not impossible) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Pantheon desktop on FreeBSD Links: elementary OS URL: https://elementary.io Development repository URL: https://codeberg.org/olivierd/ freebsd-ports-elementary Contact: Olivier Duchateau The Pantheon desktop environment is designed for elementary OS. It builds on GNOME technologies (such as Mutter, GNOME Shell, GTK 3 and 4) and it is written in Vala. The goal is to have a new desktop for users. Some features are not well supported, but we can have full session. The repository contains Mk/Uses framework elementary.mk, official applications, and curated ports which depend of x11-toolkits/granite (total of 56 new ports). I have submitted several patches, especially: • x11-toolkits/granite7 • devel/libgee update to 0.20.5 bug #262893 • sysutils/bamf update to 0.5.6 bug #264203 Open tasks • Add support of user settings (it is very Ubuntu-centric) • Finish porting wingpanel-indicator-power (power management) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Feature Complete Port of Intel’s igt-gpu-tools Links: FreeBSD Wiki Project Page URL: https://wiki.freebsd.org/ SummerOfCode2022Projects/ ImprovingTheLinuxKPICompatibilityLayerForTheFreeBSDGraphicsStack Status Reports URL: https://cdaemon.com/tags/gsoc2022 Contact: Jake Freeland Intel’s igt-gpu-tools serves as a generic testing suite for drm drivers on Linux. The igt-gpu-tools suite is separated into tests and tools that target kms, memory management, and command submission. The utility provides low-level reporting for transparent tracking of kernel changes and efficient debugging of modern drm drivers. Porting the project to FreeBSD could introduce greater stability in future releases of FreeBSD’s LinuxKPI-driven drm drivers. A proper kms-driven testing suite could also increase code output and bring the FreeBSD desktop experience up to speed with the Linux codebase. The project officially started under FreeBSD’s Google Summer of Code program on June 13, 2022. My adapted code can compile with non-FreeBSD compatible snippets removed. The plan is to reimplement these stripped components in a POSIX compliant fashion. Notable incompatible code includes: debugfs, libkmod, libprocps, Linux performance events, and Linux userfaultfd. If you would like to assist in the porting of libkmod or libprocps into the ports tree, don’t hesitate to contact me. When the FreeBSD compatible code is complete, I will run the modified igt tests using a host of graphics processors on FreeBSD 14.0-CURRENT. If all is well, the project’s diff will be submitted into the ports tree. Sponsor: FreeBSD Google Summer of Code From nobody Tue Aug 9 18:06:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M2Lc71RjQz4YjZW; Tue, 9 Aug 2022 18:06:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M2Lc55NK7z3LJw; Tue, 9 Aug 2022 18:06:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ed1-f41.google.com with SMTP id w3so16177670edc.2; Tue, 09 Aug 2022 11:06:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=rzDGOXSJ4uuw/0ccw/r4aB3KQrA+4wGcWWEZ7zJIs30=; b=xocnNyjZ7PncKdDOrlzeAM3wB/iMk1UTMvEqKli6sSLeiww45tjb01jOBNNkH8JsuU Hvd4fQvT4DK3EkCTixEfpY5oMIbe2dhUYX5U2xbC3g7uRRRKPOvoz5LByfwR78EkP2w9 P+1QhUsrD/Rhx1eJUWZYBehev6v06th/Dg5BHA35EgkcFJaHQQ3jBCfcVMY09kIxjs1w dDq2XB32NQcZgUZwyuZ+rnXlWRkyEBSE1/oLddIZm59E8VItkIWo4yiNiu+xXm+hy4E+ fslQBIZCv3xLRF8UuvQsaNdzuaxXsLX7Q1FK4N9+K05PR7qr1HH28EV9QD1q7cdQd2yR jsGA== X-Gm-Message-State: ACgBeo0Ozq4pTKT/qBuY+Zof4nvdd0EUyE6BNQz1+KNPsXacpjauThzo eTBR94Coa9GMpHaeRaGdUnIwohPGzb+Gx4/saHk/JiXMYME= X-Google-Smtp-Source: AA6agR4ajXhg5R7hs9Ep2mpj2bGYGynsOSrq1BqjE+V+5zCNEjK9XAod1MJY//UXaeWTC1eRP1RnDV+83dSYp4p7828= X-Received: by 2002:a05:6402:27d2:b0:43e:3ff6:ad58 with SMTP id c18-20020a05640227d200b0043e3ff6ad58mr22607256ede.234.1660068387315; Tue, 09 Aug 2022 11:06:27 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> In-Reply-To: <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> From: Ed Maste Date: Tue, 9 Aug 2022 14:06:14 -0400 Message-ID: Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use To: Glen Barber Cc: Mark Millard , Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4M2Lc55NK7z3LJw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-arm@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.41:from]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.41:from]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_CC(0.00)[yahoo.com,bsdimp.com,gndrsh.dnsmgr.net,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: > > Will do. I=E2=80=99ll commit the suggested change to main tomorrow. > > Thank you for your vigilant investigation. Shall I commit the enforce_chs check now? --- commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a Author: Ed Maste Date: Tue Jul 19 16:47:49 2022 -0400 release: ensure enforce_chs sysctl is 0 We do not want CHS-based alignment for VM or SD card release images. Sponsored by: The FreeBSD Foundation diff --git a/release/tools/arm.subr b/release/tools/arm.subr index 6e4ae731a0b9..01c5303cd4e1 100644 --- a/release/tools/arm.subr +++ b/release/tools/arm.subr @@ -62,6 +62,10 @@ umount_loop() { } arm_create_disk() { + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; then + return 1 + fi + # Create the target raw file and temporary work directory. chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} if [ "${PART_SCHEME}" =3D "GPT" ]; then From nobody Tue Aug 9 18:15:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M2LpK1Z5gz4Yl8C; Tue, 9 Aug 2022 18:15:21 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M2LpK0xl1z3N9q; Tue, 9 Aug 2022 18:15:21 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660068921; h=from:from:reply-to:subject:subject:date:date: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=wKmAGPrZc3JTHzSg0KUKiXU1myAjP1ULcgxHocVHjmg=; b=TfyBezOSS+QExbCdGsnqPsXCZFS+GwjJBOmu63++Gytj8+JtHyr3oKL633KZNDq7Oya0F0 OZJdR8pntJF+YAQ/RwlsK33saHIHPM89rPYP/xbmnND0poSGj3xqWqOnWbjTirdeXi3Ucq PkEAUZc9mt3trKyMZKrTAveCXjHlQYmyDvuRVaccioMAeTJedpsyoLNZ8w1aEtuymMFwBy Hg2SczEt4xCN/2ievcLOZaXYu8YXf+hk94HsTu+PXpMZ6QYv2jrAGs/11Wp08cZmG2YS/e 229PBvXgHvm2ydMWXG0i0baTratn29kPD9rJCZvGhPxi8xCDBnwMHDLupgRUvg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 74B2816220; Tue, 9 Aug 2022 18:15:20 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Tue, 9 Aug 2022 18:15:13 +0000 From: Glen Barber To: Ed Maste Cc: Mark Millard , Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <20220809181513.GG30607@FreeBSD.org> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JO68zLCmjMElvUWJ" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660068921; h=from:from:reply-to:subject:subject:date:date: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=wKmAGPrZc3JTHzSg0KUKiXU1myAjP1ULcgxHocVHjmg=; b=ueJLJZXGdYy+1fetMMfTTzv5zLwWws8ww6TgNA7KcTZ3Q4Xhi85R8o4+4TQ8PR3VF99hJJ 946fUqgFn/JgB2uRZdLHtRQfE1uFw0q6exfjgD+LOxZgRD0MeoIj6o5+yBk6RmtAg/6P++ cZlN/9i8/+c7uWqh5Xfp3ngsbSBxTHulvhThFyW6xXvurOxc2h98p66PWEyVtA5dCqB9F2 ZyhDljUkOmngECacuP/Nw/HLcHVa25ln0wwfERsS3DQ1nFDIdADLKDbPdzMmnYYAqq1k14 HSmS28K0C2G4WI2uXR5fQf9oXihccZkWOFZif1zJfysitdUQp39Pc30QPsuJVQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660068921; a=rsa-sha256; cv=none; b=rMMSVo/jvzfdFpH7oV2+2tphdbCbE4bhLospwO8rYoGTjYjHX4zyKWdold0+ogECOIJ1T0 r3rpSij3iDqsCHDPb+eVoxUQGlvXaEz5npq6GsDzBzUjoaXeH5MP9DPGklfEYLc+EW2rBI eitAjUzAfF0KEkVQAmZmgNG/FKPd668oD7fPucgyw0trRPmzJpjG5VPD2ueHqtX3L3l8k4 yTQ8OKVlMEm+M2hdZ0kI8yZBwTQYzbNpAUn3zkF1GGSISCNGEWWOEQk61ITHZDQoA+NsUN gmi8G56taAuGRD3awF4jU/YVUQ7Hpnvd5DqQ6ynmuzx84xZnrqXpjeBmq52rUQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --JO68zLCmjMElvUWJ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: > On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: > > > > Will do. I=E2=80=99ll commit the suggested change to main tomorrow. > > > > Thank you for your vigilant investigation. >=20 > Shall I commit the enforce_chs check now? > --- > commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a > Author: Ed Maste > Date: Tue Jul 19 16:47:49 2022 -0400 >=20 > release: ensure enforce_chs sysctl is 0 >=20 > We do not want CHS-based alignment for VM or SD card release images. >=20 > Sponsored by: The FreeBSD Foundation >=20 > diff --git a/release/tools/arm.subr b/release/tools/arm.subr > index 6e4ae731a0b9..01c5303cd4e1 100644 > --- a/release/tools/arm.subr > +++ b/release/tools/arm.subr > @@ -62,6 +62,10 @@ umount_loop() { > } >=20 > arm_create_disk() { > + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; then > + return 1 > + fi > + > # Create the target raw file and temporary work directory. > chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} > if [ "${PART_SCHEME}" =3D "GPT" ]; then >=20 Good question. Do we still want to ensure it is set to '0'? I'm a bit confused from the back-and-forth on the original thread. If we do want to ensure it is set to '0', yes, please go ahead. Glen --JO68zLCmjMElvUWJ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmLypCwACgkQAxRYpUeP 4pPj4A//fpME+l0kRIO41QC6b/TFUDVGi7cNITaNjYr27uaqKVyub9A1Hx4OlUuj VpIZhjm7zmvdscd02HZKqg5LiZyNopH2fd4Y9pXvFBoUamBqX6QwYzUlPN6WKkEF wXwcquYFZ355F3fN/2iJTkyvMEbhzcHRods+IupJkOC0Lbfxg4hXkv/9Ro2nEw0D uITxwgpfQUL9v/l7D+gd7XL/6HRY+Hx8s4LUt4GZDMqEWZX9r5d1GUHEZAEu3AWf yWuFMDsxygI3U2n+zrSG9L+kDEKKAzrORGVfDiAkN5Y/kIkSueitZer0Wyk0Kf+W InhZvFZZvfBBRw0b5ZUWQRoNXVrSydRFEAKrxOvh1uaC3WTZuc44lJVttuL0wLIW 6m2lJU9hvGJSYwv9xd3lwak9JXjYIfc0GhrpvPjIYaIQdUL7ahsvExJrSvlWYlm+ Ncil0a32gb0uwPJQPxFwdpH9DUmukJd2JfeenSIoaNYFWsUD6pJ2o9oIsNrTr4ZE ffDK+0qFhS2dQfshZwK/E4GNBinLeuJPsBBr5/dVUC2LIs3glYUwcTpkwNiLZZAS v/Qrt6ytjXwmjAvD2Xt2FU9Fvn1/44Uc/+5p0WG52g0W76Dbw3PIsknHoTKzMlE+ 9EpQBP2bR6ca8eWz4qiaGxBb+LtDEGsHwMsknRcaU820h3JXvYA= =Rsh+ -----END PGP SIGNATURE----- --JO68zLCmjMElvUWJ-- From nobody Tue Aug 9 18:55:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M2MhS0MmZz4YsT3 for ; Tue, 9 Aug 2022 18:55:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M2MhQ53NJz3Wnc for ; Tue, 9 Aug 2022 18:55:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660071316; bh=NRgVoKv5+OL81YH/b6LG64w+kMwiHk7+qpARnEL4TxI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=q8snKVIalyJJJgiK0t7P3YKEcC5XG8KfG9PXlo5po6cn0yyu03713WqyUcEKhOrdCgI/GuyfYfGzIFOlZRGdFxrqNE/dgUOcIGb5DdIkPo3lxqW8njrUrajJ7aT0eAPN0MwtF8vMQNN7yYZV3KZtNwbjUoyIZ20ll4ePblC0TOhr7D4cmyElOehYHPOFTrd1FGcyWbRl6g8l03V/T3ZA0pAaOzMoQ2Z5i1I1QtU3L7WeG6kxAATUOp4fI+HpiMdyMnxTBDIGhLcXXVhRWifHGmwzkFndCazzxhbUQSN5FV46Ysq6N2kbxpEhCWEE/9Seh++PJ7Qs9zH8B0hIbBGXjQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660071316; bh=A674o1kYvDojDoa0atcVRgSbp6Ku4sSU+GPaJ3/rAZn=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=f6s1iCoG43j21OHXgXm6gGxi6GWI31RNNhuysM5d6oxd21QKLaKSzHIJ5Mj36IzS9WYuZP38dQQmBq8CLsNnywRCNopHhILubjYxp7q6jgSHrdIfiEqqzDeuMwAASbWkwuy42NH53hJ8KBzzO3NYmht1hwt09LxnNjI7GW4g2RYXuK8rfsnCgevSDEfXLIxUj6kc43zibetVJ66LeMH2UD6CqcvADFm7BQb/mBjHswhhNavclvI31N1KMGMaPPcRVgXJDMNpVpxPvYnoHJzQPdilsfLcyRpGTe2o6LmAFEFVk0u5pYf37uWvtl3ICM/hoUo1Z8XBluALp6DTLRv2Vg== X-YMail-OSG: 0obiDwcVM1mzOCpp7kv0KHlHDaVLRTLQ9scDxAe7Il3lJGre_KRHfkmYNhC6ICM 3Ifkx7i0aiShx99zNBD1hh28JsshRFtdiqDPNLAtUpBt9R9cCXnQJ0a1JE2qemvE3SrkCnC0Sm1Q ZqGew_3k3fi0FaD5NYnoa4RZwqfzxmp_rFUQ7bKQuFYvCUARdBFfqUdQR1CGv7kRTy61DvL3_eEg 6ysfrEcOkBw.N5ua5ylnvv3dhgg2vp6lkGQmgQQ5Xue1GZXyn96MsNT4xM_ars6I6Ixy4ck9C_P7 zX6Q31P7aiFGEj6etsgAS2eb7iuqyiKAW63kWWQG01E_gusjliNvA4hpjTfgtX4PEpw2uiJE._5o Jq8qiZLOLtQo7OWFfySscvihbBzO7cINEM1be.E3vS4rG.xzcpXbhAfu1jnJNti5EVLDc.cSJnc1 7IfTvnpNY2VCoDOq3cSUejrhX7jgzM18O.5XqC5fSEPpVK1VKCMMINxz8drkzeSdwk7c6Vk2DXqG VOTPCzxVeTyOD3M1HIIDfA3lcMJibMhEt6D7xHFztR8LYepv1TycQSQ7u1xnpxRRB8kjit0WzoPn zm74NoupRyjgISyVvb8z5AV9wO1SP2JYBO6azfOCbVXwkL6KkUwNvZVF9_q.drkBLTpjTPUS_MYd dd3v4oVzINAt6UqEuoaghC7LWnQ7fkh_F4vIMp6qLTDAJaARNO3hr7CKxcfgYPMj8MJw3z91XnEz 10H0ft9yQqtYXMyHIQ06sn_0g2CFXFZSrlP.mDLD9on2vFEU_z_6dgji9ssZFWdJ7_MtkPVaL7I1 LDpeE0zZx7c6r7ee5kAjrmAIxN3Ic4umA54p3zgOIX7emgBGq2ZGemniYowAu7oEqvUGrBxODZE_ keVMLyibSGgM_OTT8p8xQPIUrp0UZAFiIgosAjOp.p4hGHDCRXYnSDACVVz_zXTgQ5vxAeldVoHu kLHcIG_xfI.rQKnSyOwOAWo3tme178K9f23g307lMurwDZy2n1.8xKSnbiiHLIJfqqh8xpYlAL2r eV_F23oTxqO8oM_fsaZ3tbowpZj43HZJKncwl.qhZ8o8vuFKN3BEB9yc37EfA7e5_gs4DQd.LRi0 XBduCsbC1K_lLhMTnYVDziiS78035IQdc7TdhH6lehfXUnrOw5F.57.D_FroCm2j3kcKnmKMBw3Q 1N.GbG4.uOFO1uFMEloWGvh_JZA75cifmvjEmRTMGFGgXjuAp_yHPq9YNPCtSdQl_Df0zRqhmLHo p20K.QS7bbJE8J3hQOYjKEULnfiBtvTFNYi0.jNtdmLvv3wnoF6ItVhKxCA91lFGkuRP2p8_cu3l _qmC6WQ1Kii6JuCyQG0bc3F3qWWt7yvetQRPQ_btljyt6WDs6fE_7WdzwoYYJMejNVyT0Bk1PGy1 epruufnFll7rQv_u04hx5WS.kPuqISdKWhoNBsCNqJ2F08U4JjIeit7q2YDqtBtn8JlI8xJ4AVTX vyFMKcuXACjaQ5zY1iogNMaJoGSNccPeJ16rWgF0isIJGhV8i5TI1KLp8NXMNvynNO1sS8MwQIpc R53cGbbVKvagv88jmKNGKbS73rbbun5Ul3At3cJNX7EecxDTtdp6NAh2H.PlY556z1inAaVzM0PK cHxhAdffkW4LNdg_joKHwLoLIiGAOh6oxLVrz0T7awzj0T9iq8VnDSiWoC3WJciJz2pwYqt7I97g ijT3S1IJvKVBuRJf_xTa5dMKxBBC_ZIEAtK4ohOd72UEn0nIuQNHrE1kwlcMxVEVeKM5z8qrvWLS NQP3ihb7V4UiJjQ3drh6hm7QEGRcVna2f3iPr6GIGGwzuNKwGcjKL4AbkseJqADnQDvQf7VmVGtf Fn3xvRFSxFpXXg7T.wDtXfH0MECw4cM8kWX6QnvpoMqYcSBDn1KIlabE57uRBSiwj5cQx1zqgMK0 UXafsjUQZaZ6FBjISjk4FBL01EPb96hlCzNadYcGCbb7_1eu5Qh0CvLzUZzxvw46XlJa.Z1BivI_ cDJ.zj.xgeln4jOGpcQL7mm6eufHn.LlCV5NKEN11jwWZ0RuJuURUsX7YJ1K16TwyAeZLbDoeUC3 alk.BENx2QlVPmnLmM.0KwvWkyV9W7ozkARckL9wv2Jve2mc9n8SeTZieviWS0M.xDoTcPs0YzyZ NK6sok8zzyWsnaEWKB.hX3oFIVWcOJAd7eb0dln_vbLbUDVjeJY.4ySBDl_V6Z0I41hCwrYBYn5b KyskpxPaI_Hd1S9NKhZZrhRs.uYyeUarwoC3_43aQHCMj1MXzFiwxjC5y6pPolgdp2z7_TiFPEdG OUOwbBTI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Aug 2022 18:55:16 +0000 Received: by hermes--production-ne1-6649c47445-zp4l8 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 67d7542a3b0ff56c91b8a724acf0e36c; Tue, 09 Aug 2022 18:55:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Mark Millard In-Reply-To: <20220809181513.GG30607@FreeBSD.org> Date: Tue, 9 Aug 2022 11:55:12 -0700 Cc: Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> To: Glen Barber , Ed Maste X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M2MhQ53NJz3Wnc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=q8snKVIa; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.23 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.74)[-0.741]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-9, at 11:15, Glen Barber wrote: > On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: >> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: >>>=20 >>> Will do. I=E2=80=99ll commit the suggested change to main tomorrow. >>>=20 >>> Thank you for your vigilant investigation. >>=20 >> Shall I commit the enforce_chs check now? >> --- >> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a >> Author: Ed Maste >> Date: Tue Jul 19 16:47:49 2022 -0400 >>=20 >> release: ensure enforce_chs sysctl is 0 >>=20 >> We do not want CHS-based alignment for VM or SD card release = images. >>=20 >> Sponsored by: The FreeBSD Foundation >>=20 >> diff --git a/release/tools/arm.subr b/release/tools/arm.subr >> index 6e4ae731a0b9..01c5303cd4e1 100644 >> --- a/release/tools/arm.subr >> +++ b/release/tools/arm.subr >> @@ -62,6 +62,10 @@ umount_loop() { >> } >>=20 >> arm_create_disk() { >> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; = then >> + return 1 >> + fi >> + >> # Create the target raw file and temporary work directory. >> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} >> if [ "${PART_SCHEME}" =3D "GPT" ]; then >>=20 >=20 > Good question. Do we still want to ensure it is set to '0'? I'm a = bit > confused from the back-and-forth on the original thread. >=20 > If we do want to ensure it is set to '0', yes, please go ahead. >=20 Hopefully this week's experiment with explicitly avoiding BSD and freebsd-ufs having the same offset inside BSD (avoiding both offsets being zero) will allow the UFS labeling to work right: freebsd-ufs being tied to a unique offset inside BSD. I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to cause the offsets to be different is reasonable, despite that it happens to make them distinct: the freebsd-ufs offset is better controlled explicitly elsewhere. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Aug 10 19:36:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M30Yl234xz4Xxdk for ; Wed, 10 Aug 2022 19:36:43 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M30Yk4Fxrz3hTY for ; Wed, 10 Aug 2022 19:36:42 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.7.155] (d155.p9.wifi.dcrosstech.com [10.1.7.155]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 27AJaQnE011358 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Wed, 10 Aug 2022 19:36:26 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d155.p9.wifi.dcrosstech.com [10.1.7.155] claimed to be [10.1.7.155] Message-ID: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> Date: Wed, 10 Aug 2022 15:36:25 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: freebsd-hackers@freebsd.org From: "David E. Cross" Subject: "missing" SAs/ENs? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4M30Yk4Fxrz3hTY X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[crossfamilyweb.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N We just had a big dump of multiple SAs and ENs yesterday.  At least one of those I know has been pending for months (and AFAIK was ready to go technically within days).  Additionally I know of and personally have been hit by 3 other things that I feel really should have been ENs and out by now (and am maintaining my own patches for): 1. loader handling of root geli disks is broken.     This one is a big deal, it completely bricks systems, there has been a patch for months. 2. userboot.so doesn't work when compiled with BIND_NOW. relatively minor, affects few people with non-standard build options, but likewise known for a long time, patch committed. 3. compile hang in certain circumstances with LLVM with CPU targeting on AVX512 processors.  Again, minor, affects few people with non-standard build options, but also know for a long time with a patch I suspect by the fact that I've personally hit these 3 that there exist many others that other people have hit that I have not (yet. It feels like there is a backup or stoppage of EN/SA processing. From nobody Wed Aug 10 20:14:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M31Np4tC1z4Y936 for ; Wed, 10 Aug 2022 20:14:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M31Np4S6dz3sJ3 for ; Wed, 10 Aug 2022 20:14:02 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660162442; h=from:from:reply-to:subject:subject:date:date: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=6eMYetE1T70092FgtzMaTmK+UVvrUf0cwR4Sp6kGnhs=; b=kH4p6oqZcToCAASi2FmAwaLd/PpIRKWmCVRqewF7Bm/cOjy4YNkm7gB7lGGgQhfUncIvyF OKb4HCfrrtT3VGNARS6opUsdy7HzoVI+XsGoaTfm0vocdGea9Kh/b7pjckpZQ0Ed3Q7haN 4wjh3FTwv/L96aZ8avke1wEwDBfgiG24TwpJ/MGEVV8wU1HgE1Loo5z9JYuP4trM4Ip7Rd E9DxOYs8PYmHvcQH+FMZHURs5PHyEZoNaN7nnclTUbw/gMmYCZ7UuZKh33tmAiYBljUJ4P zyyRivJbTuZyItXwZjewukCbnn9Jnzih9TMeLCrq938uIQjMfjoFWOlAnXHuGQ== Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M31Np3QZbzb3y for ; Wed, 10 Aug 2022 20:14:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-ed1-f42.google.com with SMTP id r4so20483134edi.8 for ; Wed, 10 Aug 2022 13:14:02 -0700 (PDT) X-Gm-Message-State: ACgBeo1dgDWtUK2KLZ0NtyzSZnW4yzAcJH5wNpxg/ioHMZE5dBgbhufO tj8Z6ijG/NI7monnfq2ugrKr6NKjkAxtpVOjsSI= X-Google-Smtp-Source: AA6agR4LzSQhD2bNShxZh5sNXLtbKugj+oqbz/XfzuCFc4JhSdgGmtSZHu94ItiZwJGhJxsFQZH69ZFskVlo1cjd75c= X-Received: by 2002:a05:6402:424d:b0:43e:95d8:eb46 with SMTP id g13-20020a056402424d00b0043e95d8eb46mr27781611edb.306.1660162441385; Wed, 10 Aug 2022 13:14:01 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> In-Reply-To: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> From: Kyle Evans Date: Wed, 10 Aug 2022 13:14:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: "missing" SAs/ENs? To: "David E. Cross" Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660162442; h=from:from:reply-to:subject:subject:date:date: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=6eMYetE1T70092FgtzMaTmK+UVvrUf0cwR4Sp6kGnhs=; b=jUeic4aJQTx2pI3gO7ejHzYvImdHyf50b/kaeC6+VZwWIeyJBk5aKTSmeP1yd0slulSZ39 2dj7IsFVr9YYdQSQjHoW2KfoRD2GKK2vzn1ajc3nliQ3XIlC7nAzVkn0T8FYkdoB3H/aNV EKBZOGc2O/wjYPMa+EFi63wIT51cg3vKTB+oRWCqQwzU67SmAUFcY4k3J4A2rEqnD5WD8W RCd73ESTgmSJQJ4WmaGlJAXl/Z31RDG+FTktD9pe0MLKs58f3JGyzq7v6s2kk67KXOkg90 lNJTrV7eZF0FXUJSLmQNVNyNGgdyLupUZ74RHLpPDiHRoRV4QCwcbFrJ0NqILA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660162442; a=rsa-sha256; cv=none; b=W30Anyc9Q7l+bGDnwZ1tfahmr6VVCfKFUJmO3vij+SwKjet8cLMTLLH3T12PCeAvydcobZ AsDrBcqgDwAHQnhjwW2YkF30cKaUERxMQe+5IRehmHGAZUye96QVB6RX+PYrlyomLReE89 wVI11GunhSSwi02DQqE+cifRBZArxTWcyY0O3MxSC9CKL29Hy9JQ1/uwm+y5kpe8doWDuv k9QelP7AJ7gk7d0pRyNyrvEK30yk8cAXb4UXA5/iP8w2v8blsvfTJf54kFOSl6EsGUaE6o 3NMmWgJJ9OhJjTb7ibQd87lk2RpwA+xXHXvpYP1tuyPQuc5ZIPfbiaXERDVTew== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Wed, Aug 10, 2022 at 12:36 PM David E. Cross wrote: > > We just had a big dump of multiple SAs and ENs yesterday. At least one > of those I know has been pending for months (and AFAIK was ready to go > technically within days). Additionally I know of and personally have > been hit by 3 other things that I feel really should have been ENs and > out by now (and am maintaining my own patches for): > > 1. loader handling of root geli disks is broken. > > This one is a big deal, it completely bricks systems, there has > been a patch for months. > > 2. userboot.so doesn't work when compiled with BIND_NOW. relatively > minor, affects few people with non-standard build options, but likewise > known for a long time, patch committed. > > 3. compile hang in certain circumstances with LLVM with CPU targeting on > AVX512 processors. Again, minor, affects few people with non-standard > build options, but also know for a long time with a patch > > > I suspect by the fact that I've personally hit these 3 that there exist > many others that other people have hit that I have not (yet. > > > It feels like there is a backup or stoppage of EN/SA processing. > I'm not familiar with #1/#3, but I didn't feel that #2 warranted an EN and thus, didn't fill out a template for it. This is a non-standard build configuration and has been broken for a long enough time that there's almost certainly nobody else trying this at all, given that yours was the first report. Errata notices are only issued on an as-needed basis, when someone fills out the template and submits it. Thanks, Kyle Evans From nobody Wed Aug 10 20:26:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M31gJ0Yw0z4YCtS for ; Wed, 10 Aug 2022 20:26:36 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-250.nys.biz.rr.com [24.97.5.250]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M31gH075sz3vJD; Wed, 10 Aug 2022 20:26:34 +0000 (UTC) (envelope-from david@crossfamilyweb.com) X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.7.155] (d155.p9.wifi.dcrosstech.com [10.1.7.155]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 27AKQSRW022017 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 10 Aug 2022 20:26:29 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d155.p9.wifi.dcrosstech.com [10.1.7.155] claimed to be [10.1.7.155] Message-ID: Date: Wed, 10 Aug 2022 16:26:28 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: "missing" SAs/ENs? Content-Language: en-US To: Kyle Evans Cc: freebsd-hackers@freebsd.org References: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> From: "David E. Cross" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4M31gH075sz3vJD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.250 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com X-Spamd-Result: default: False [-2.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[crossfamilyweb.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 8/10/22 16:14, Kyle Evans wrote: > On Wed, Aug 10, 2022 at 12:36 PM David E. Cross > wrote: >> We just had a big dump of multiple SAs and ENs yesterday. At least one >> of those I know has been pending for months (and AFAIK was ready to go >> technically within days). Additionally I know of and personally have >> been hit by 3 other things that I feel really should have been ENs and >> out by now (and am maintaining my own patches for): >> >> 1. loader handling of root geli disks is broken. >> >> This one is a big deal, it completely bricks systems, there has >> been a patch for months. >> >> 2. userboot.so doesn't work when compiled with BIND_NOW. relatively >> minor, affects few people with non-standard build options, but likewise >> known for a long time, patch committed. >> >> 3. compile hang in certain circumstances with LLVM with CPU targeting on >> AVX512 processors. Again, minor, affects few people with non-standard >> build options, but also know for a long time with a patch >> >> >> I suspect by the fact that I've personally hit these 3 that there exist >> many others that other people have hit that I have not (yet. >> >> >> It feels like there is a backup or stoppage of EN/SA processing. >> > I'm not familiar with #1/#3, but I didn't feel that #2 warranted an EN > and thus, didn't fill out a template for it. This is a non-standard > build configuration and has been broken for a long enough time that > there's almost certainly nobody else trying this at all, given that > yours was the first report. Errata notices are only issued on an > as-needed basis, when someone fills out the template and submits it. > > Thanks, > > Kyle Evans #2 wasn't even me who reported it, I (mercifully) found all of these issues by searching existing bug reports (which also shows this is hitting multiple people, some of us just may squeak louder than others).  Also why I didn't file an EN request, I thought it was handled. I definitely appreciate that non-standard compile or execution options can complicate decisions on what all to include as an EN; these (to me) seem to fit that.  They are a result of configuring the system in a way that is documented to work, are hard breaks (removing functionality) when it doesn't work, and the patches for all are trivial (no more than a few lines).  For example if 'device foobar' prevented the kernel from compiling, or caused a panic, even if 'foobar' was not in GENERIC, I'd expect an EN to be issued.  if it just worked poorly, maybe not, especially if it was dozens of lines. Where is the EN template?  I'll gladly fill out 3 for these. From nobody Fri Aug 12 01:37:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M3mX24mYrz4ZKsR for ; Fri, 12 Aug 2022 01:37:54 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3mX16tJTz44YP; Fri, 12 Aug 2022 01:37:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f47.google.com with SMTP id y13so36387049ejp.13; Thu, 11 Aug 2022 18:37:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=4oa21TnRMn8DTxeJk/Jr9iV55I1fc4tBwsTLNZg+J8A=; b=xozTG8548+UQvjc3CEQzR6Azl9amaCxswGBSheNgUdgRppH79YKMWc9jTxqiLGCPlD 9rHHlalZbdoDn6CSeuexA+8WoOYNVz2YMwmeq1wt+vZgbGUlJkP2eaCShUjJCXC2sBLI kF1yhphf4PQy6wKlbCpXr2xj87zXxwI/l+6OI9p9AH7e2TMu9nwWhOTMQoqsKDviDpS6 MQMpaz3ip1yecz0rw8C5lEvByxETVFKOE8qws/qyxYu+j7ybCAwFjEQ0qzKRUCjkYlvY YiA+H6/yxlVol7gCTTXMiFWa3YveixwouI2A1Aj3vMquH9xCkfHukUOYPXeCl4VjwJlf rk1A== X-Gm-Message-State: ACgBeo2P0W14VWUP9sKeM3reOg21Bb+7ZfF6P1vOHimn4YC1tLXw3FiM v3D0rZJ4Mo88xFlJuKRCmA/fKpr3yXYsLmiqUthWkCY2rXc= X-Google-Smtp-Source: AA6agR7aQ+P3sIsjrMC1DwtPNPwozdxq8LIujhTDzcvkMCKTu2D6bdQVP11o65TGlrJSuVao6DcxiiBVTdkAJrcatOE= X-Received: by 2002:a17:906:9f2a:b0:730:bc30:da30 with SMTP id fy42-20020a1709069f2a00b00730bc30da30mr1117419ejc.763.1660268272237; Thu, 11 Aug 2022 18:37:52 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <84c585bb-15d8-75e9-0a9c-3f10e94314ef@crossfamilyweb.com> In-Reply-To: From: Ed Maste Date: Thu, 11 Aug 2022 21:37:39 -0400 Message-ID: Subject: Re: "missing" SAs/ENs? To: "David E. Cross" Cc: Kyle Evans , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M3mX16tJTz44YP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.47:from]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.47:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Wed, 10 Aug 2022 at 16:26, David E. Cross wrote: > Where is the EN template? I'll gladly fill out 3 for these. The errata template can be found at https://www.freebsd.org/security/errata-template.txt From nobody Fri Aug 12 20:34:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4FmD1jx4z4Z9Vx for ; Fri, 12 Aug 2022 20:35:08 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4FmC3NkFz3xFT for ; Fri, 12 Aug 2022 20:35:07 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id c17so2769615lfb.3 for ; Fri, 12 Aug 2022 13:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=6a+WdKWQYnCU9ZLMS9fahsD/z9RZYT1usbQTU5fDmSU=; b=IOdMtqlgtJ/NN1N2E2DGWhuf+TEj/GzsZVrK2/AO8Nla/8Chi5mpjM6J90atIMdO24 B84n0Mbb8AkckPF0KX8f1CASEHPQa+HlpXblwxn1A6ljSiSBFF3ldw9eijx20Vt3lVfZ /HIQkGgwgppuBCURkCWfq0RtJklFLUBN7gI/pjtywcHU9QapozC40enK5h/68yLf/7Pc ol3eR+U1GT33+LAHjYElMMdHiUDtNVO1j/1CquKV3ctiNhBQ1YqP1PVczi/F+09R3w5g AtI4zwR5linC5t++ktSkI3FwqniIM6Lt78fM1uBT3DcFaVkIUxUBz4SrEJB8Bo1Tj+eE 7hkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=6a+WdKWQYnCU9ZLMS9fahsD/z9RZYT1usbQTU5fDmSU=; b=dPl1/60Ir+ZPdizyfkegvP4jT46qiwXGwQky2vtk1a7FEAConj0uF5czTQxPZSpD1b PJFl8xsojW7is7qNQgDHoLFCnVGfyXvyaJwfF8fqRgF5MqNRe436HpKVst7FgmPR2Ri7 i5HsxHi0orGk1Wpki2GpDVEn5tQSOPLeKhTIeWBS7yGrlYdJb2z5QUTdG9nHBoL3kqHf pLac131xtkeogVzid8X+S/x1iHtkUKLxb95SmsW440e8dQNOwLY1n5hQ3T7wBuXM7A5L yuTtpckpU5hhVQt4iLLGuRMtArAYllA5alwCn7mheazodL+1Oxud1v/oI6yMD2jpMSdl akLg== X-Gm-Message-State: ACgBeo2pjYPU6vEqfZZMsFzxtoq5SDmYlDkwDffiF1sROdBI646rmXMz CBmZiJnvnuAkn+KH9dOx98ORYBqPokapu/ddF0x1nzI2 X-Google-Smtp-Source: AA6agR4Yt//ElAnm5+aI7+tLTazyTh+BiLBzUN0uiGsp3KBsopvKT648gVpaMi/B2gyLwo/2qtyUC+YQkU0V4UTRqMI= X-Received: by 2002:ac2:5f77:0:b0:48b:3886:5d55 with SMTP id c23-20020ac25f77000000b0048b38865d55mr1702539lfc.668.1660336505026; Fri, 12 Aug 2022 13:35:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Harris Snyder Date: Fri, 12 Aug 2022 16:34:53 -0400 Message-ID: Subject: Strange behavior of USB PCIe add-in cards To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M4FmC3NkFz3xFT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IOdMtqlg; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of harris.snyder@gmail.com designates 2a00:1450:4864:20::135 as permitted sender) smtp.mailfrom=harris.snyder@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.94)[-0.936]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hello everyone, I have two USB3 PCIe cards (different chipset vendors) that are both exhibiting the same symptoms: - They are detected and attached to the xhci driver. - They sort of work (a usb stick seems to work for file IO) - When an interactive device (e.g. USB sound card, mouse, or keyboard) is connected, they seem to drop the overwhelming majority of input events. For example, the mouse moves jerkily, at intervals of several seconds. Most keypresses on a keyboard are missed, and occasionally a "key up" event seems to be missed and the same key is typed repeatedly. A USB sound card has stutters and hitches in the audio output. Does anybody recognize this behaviour or know of a solution? I have tried: - A different PCIe slot - Two different PCIe USB3 cards from different vendors (and different chipset vendors - VIA and ASMedia). One of the cards uses the VIA VL806, which some users on the FreeBSD forum have reported working... I'm using CURRENT, but about 2 weeks behind... Thanks, Harris From nobody Sat Aug 13 00:16:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4LgS10j9z4Z0xr for ; Sat, 13 Aug 2022 00:16:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4LgR0yXlz3C05 for ; Sat, 13 Aug 2022 00:16:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660349777; bh=bk/hVOdh8NyqsNPM1otQ35RQAFzHgsAbwT18NeaCLso=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=qcjfMyPJz3TvxooYuEaC1dvefqzdom5q7+pO508yOuwgH71+lbHvPp2wNRzkXYltfoCmXAx+oVOH7IHdNys4iYGWx1abgFCXrs+K+lQt5SEavQWBISdb0tVuZmM7d0nhnE0uX3EQxFBrOTk18lk+NkhPv/4uQHkHoIOYwF4DXQyN9PmGnSQpM7/1kbTyDyLiQFbemcJtNtgJSObcdudciGqxksBWCE5LGxVHupMgEa5jTfQtOLRPmYA2fhtzqOJeOZv0n5zWLsMlOhhUoe8OqEaKfnnEHPwhEbPrlf5j7LlNGhIOH6Gn5o4cwVYyziln/XQArDbTdb0F4CBEb4tV9g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1660349777; bh=BBxE74IQi2Tg/8+UsgOcyo+F6AS008LxOrGntQpXobd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=D9eZ6AVJiXxbCj31M0xMQBXdX3fgkqp6pJ2t17P/f7b+igMJiDnFHBjPtsNzEgVZ0z75XOXJuf6R+4U7Medlqzv8xdhA5+Yofh/gPjeXcyJ+OlsDHdprMwcGBsr0xH1iwda4jgZSTbz3q7OumTIb9MQJVNzHPbvD+5KHtNTUvDY2dZ8cgffocJ/5p+j59W6gzcURS/ddgwm0JQG7ZcS3/o+HVVhpFXFwP0uQo1eFJnzcknnvZdahX5gAZrElVpP6Drx4O2M2kv7dTb/YeZVN239lUKhqLbQ4+j+DXNfOEPjet+T6ia5SUA30IU/NG3qlje1iKExbd23CERbTelQsCA== X-YMail-OSG: WadpHvMVM1mgvV9Gh4vLS7N9PSfnA4rAaw8yB.uR.QZuXiu4a2uWfTy1pHpJ8Xu xEpJZ6voxGkEKut6IMjKUWnbzcMFgCBruEs4yGRfyehlD_7120n9JJWW3g5uheL7Sk5uryNCIUp4 T5MQ57VzeKvOLD2E0XgEz1JgHuGwWl8p.j5izmRfS7C4.tEI5VyA1OEM8uupHVxp5vekhpH425Mx NRY8afOsPUIWynJps.zsnmY.ryVeXsxRPiAF951P8YnzQwKD85vdCTp5zAgMwkIK9IyqLhNxXLcw iqzQZvkCZ2tvu9PAcfsCFSqKlvSxzQFtpqS82AnAXts0e.tlBfPiCX9a_0tbUcP5EroZKdsHsGDT 7OBrp9oXWCPvdt8Y.xAPjreiOWp6LJr1lOPf3Zj1asqgAsMp088kptXL0ePQKeWuVCFkss3wVpge 1k1nvP4DS6X3y7DdHtA2BzMm9tHD0pq1TX3eNLVCRzLqGdWVCHF4tJhgIQYxczOEDgiLSqbFz.DI hENkur.adQ4c1p9lFFhw2WEHn7cJefZG6gpB92yQaSJj8fuN1Kj0wp0WCUZuBdTBvTR2NxH.UmU_ vcmsUDj0sW_5f70NpWBRuC4A5E_7n2f2XyO0t7Ffz9_AY1YEXzFpt6BQbkI8DW1VXx78V_e2hDeT laGeP8ur.3cqtj1GErJZfI0fTn1ZSsVRMudVr9ebyjZbyJfgsnEcMFiIkHOKLzalxllsZqNzMdGH w5vWIwesW6uHEVM9.Rgc_LvIX8Cln6uoCCruWv2RRPDefdrzI4wpWBInpAT4YW6QY3t685Tirpoa sdfzNB2v1rBY77DZ9rEzFXK3GF0EEdHXnUNNnbOfH6npJNWtpJm3N6kob0dXbJ0Ah9gThO7ONmFQ PmcmeKohLUMBnapUmptQ01oFjrWHPjckhGfy2m01dcjlNHfaMcbfaTXMsJdK4ASuJB8UV2fsxrLu jnx.iWGa9s_MA_vMlLZVmUHBXSQI2No8ui4Jr7lsIXkRAc6JMsHNg_U2W1uGhmVmsuJp2k2is.Cz QCSZCANe08umDE3N7FEbKEKUQlTIfixSsEEhnfRUHJqgBYN79wBhEy0oxNR8HljnEGdEhiMvix9Z woLINREMTwOQDG3.7ItuF5EVGqGbNTHyPyDm46rzSaPPBJJybwfTTumy5CNKiZPzH0yALyrX0pBh Z1liQvLpPotAF0n_2His.YBBefqlatUQuIriJEsZuEqJZ2pyTbPRo4aKJ9poFMD74yaVki9fEAQ_ BxA_M8iRVMOJKsF1syyrhiYu7AUogCe0bPaTPwKyCFwMpZm8Qvw2Dp06PvlStTXESkRr7W.TLlGm GoDqx6S7By4tg_x8wLUDQp32el85Iic1d8NG24WFfneag5ZtQxyWFECqLc0mdzb6Pmj4qe5gvM9O NPCDCiTOIM.bMY99Y7FlJfggkTh_.HCFf4zd19xgpQep0qzJNRPP.gSc4voEVxCWTjX1BDqZHONE 1F2ScYcOTWdt1Z7uUqd._4tGP9XYZ6Q7ojAWeD1wKDPHnRxo4kkSmvKoAvunyqOBIyqSk4uhtFms hEFqGBij679f3nygTvwTeECGKFKBGHVe9nL9l3FaBsC8uX8LsBwfALIfAuCOyKAMsA2jYhfpDdkJ N278.5PffVrrvsFvKpW5ZxfASFBoAhOR2Fl55KniN0TFsrbk321HP57_xTeF4L7RIF_uIntuaFCj Nl3ESiCGL80R77yJwI47HAK5AKmL3rskvBip7GWJgzeDimYuQ4e6IbhxyzyUUwgbmPU5c867HZOj 1Wq2lyQ7vkkB8H7rQvh7z57PjZQXKZ2NIWE_BOR6n0pr3DfzQAj5Drz63yl1xc_RxtlbHkc4NwGx VNgwFV.KJUpYbmPaL8rYKsEqh6cd12RQZJKThdPKeJKvmBWS7qu..q.VA244jKnO_PowC2mV.Vm8 bc7HqnQ1kpxdtU15_b9nHkhIJQiGdjsoDwgdR7ise2Dq5.izzepdngzTm7UX8E0T5EHESW10rHZv 2.CysrgUtzWhx1voOK1nAWjxBbiDYKirmnT5gl5YDJ6YjHpVFP8I1IMi_z3EbmCY6Uz1EdgrEWko LiSyR_eGR8uwEKLLmwyhf_ThcC_JQLDHrlIQmyzyikT8S35vKF7TM77_JFIsBCwzLT3Bb2967624 KYegxvFLbg4htUqfNqwOv5xoEDtQczdy7JUJiKtbFeh_zYusLlWiblLlOpYs2_j5SrMboK2yS88T cs46ykJntglEvTbG9HlyvDeKuNb0UGLZRReR.MQyAjgZAv9WCETdKkqS4K5aNQ_I.JNa_LX9gsvD xyjaopS.MpUjYNIUD3..SxbG1r4ywsYob_WjzGBpbogFMsjmCSsljBlTOkonRynbt1pL3Fdc3BfN gueDFcRu.cpxJxuL9KDU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 13 Aug 2022 00:16:17 +0000 Received: by hermes--production-gq1-686964ccb6-8l9xn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bd257bcf7abc987ecbad0d2016e5016f; Sat, 13 Aug 2022 00:16:13 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use From: Mark Millard In-Reply-To: Date: Fri, 12 Aug 2022 17:16:12 -0700 Cc: Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm , "Dr. Rolf Jansen" Content-Transfer-Encoding: quoted-printable Message-Id: <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> To: Glen Barber , Ed Maste X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4M4LgR0yXlz3C05 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qcjfMyPJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.33 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; NEURAL_HAM_MEDIUM(-0.84)[-0.837]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 2022-Aug-9, at 11:55, Mark Millard wrote: > On 2022-Aug-9, at 11:15, Glen Barber wrote: >=20 >> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: >>> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: >>>>=20 >>>> Will do. I=E2=80=99ll commit the suggested change to main = tomorrow. >>>>=20 >>>> Thank you for your vigilant investigation. >>>=20 >>> Shall I commit the enforce_chs check now? >>> --- >>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a >>> Author: Ed Maste >>> Date: Tue Jul 19 16:47:49 2022 -0400 >>>=20 >>> release: ensure enforce_chs sysctl is 0 >>>=20 >>> We do not want CHS-based alignment for VM or SD card release = images. >>>=20 >>> Sponsored by: The FreeBSD Foundation >>>=20 >>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr >>> index 6e4ae731a0b9..01c5303cd4e1 100644 >>> --- a/release/tools/arm.subr >>> +++ b/release/tools/arm.subr >>> @@ -62,6 +62,10 @@ umount_loop() { >>> } >>>=20 >>> arm_create_disk() { >>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; = then >>> + return 1 >>> + fi >>> + >>> # Create the target raw file and temporary work directory. >>> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} >>> if [ "${PART_SCHEME}" =3D "GPT" ]; then >>>=20 >>=20 >> Good question. Do we still want to ensure it is set to '0'? I'm a = bit >> confused from the back-and-forth on the original thread. >>=20 >> If we do want to ensure it is set to '0', yes, please go ahead. >>=20 >=20 > Hopefully this week's experiment with explicitly avoiding BSD > and freebsd-ufs having the same offset inside BSD (avoiding > both offsets being zero) will allow the UFS labeling to work > right: freebsd-ufs being tied to a unique offset inside BSD. >=20 > I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to > cause the offsets to be different is reasonable, despite that > it happens to make them distinct: the freebsd-ufs offset is > better controlled explicitly elsewhere. >=20 The experiment with this week's snapshot is working just fine. It is based on the update: QUOTE The branch main has been updated by gjb: URL: = https://cgit.FreeBSD.org/src/commit/?id=3D45add40717c24ef0b5418664fae1718b= 15a0422b commit 45add40717c24ef0b5418664fae1718b15a0422b Author: Glen Barber AuthorDate: 2022-08-08 14:59:29 +0000 Commit: Glen Barber CommitDate: 2022-08-08 14:59:29 +0000 release: fix alignment for arm SoCs =20 MFC after: 3 days Submitted by: Mark Millard Sponsored by: Rubicon Communications, LLC ("Netgate") --- release/tools/arm.subr | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release/tools/arm.subr b/release/tools/arm.subr index 3dea17339958..25d4640cc26b 100644 --- a/release/tools/arm.subr +++ b/release/tools/arm.subr @@ -77,7 +77,7 @@ arm_create_disk() { chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F = ${FAT_TYPE} /dev/${mddev}s1 chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 - chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k = ${mddev}s2 + chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k -b = 64k ${mddev}s2 chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a fi END QUOTE This is unlike when the "-b 64k" was not present. This includes rebooting after the initial boot, unlike before. This is for dd'ing to USB3 NVMe SSD media and testing, for both of: FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img (The -b use implicitly also changed the size of the freebsd-ufs slice, making it smaller.) For the media growfs is involved in the initial boot. glabel list now shows ufs/rootfs bound to da0s2a and does not show a ufs/rootfsa at all. There is no binding to da0s2 (BSD) shown. # glabel list Geom name: da0s1 Providers: 1. Name: msdosfs/MSDOSBOOT Mediasize: 52428800 (50M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 102400 length: 52428800 index: 0 Consumers: 1. Name: da0s1 Mediasize: 52428800 (50M) Sectorsize: 512 Stripesize: 0 Stripeoffset: 1048576 Mode: r1w1e2 Geom name: da0s2a Providers: 1. Name: ufs/rootfs Mediasize: 240003866624 (224G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 53542912 Mode: r1w1e1 secoffset: 0 offset: 0 seclength: 468757552 length: 240003866624 index: 0 Consumers: 1. Name: da0s2a Mediasize: 240003866624 (224G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 53542912 Mode: r1w1e2 # gpart show -p =3D> 63 468862065 da0 MBR (224G) 63 1985 - free - (993K) 2048 102400 da0s1 fat32lba [active] (50M) 104448 468757680 da0s2 freebsd (224G) =3D> 0 468757680 da0s2 BSD (224G) 0 128 - free - (64K) 128 468757552 da0s2a freebsd-ufs (224G) A difference in behavior is that "gpart show" does not report the ufs/rootfs labeling. For all I know, this could be expected. glabel does show ufs/rootfs . I do not know what would happen if only the size had been made smaller but the starting offset had been left at 0. But the evidence from the "without -b" and "with -b" testing is that having starting offset 0 in BSD and the same size as BSD can be a problem for the freebsd-ufs slice as processed by the initial boot, at least when ufs labeling is in use (here ufs/rootfs). So far, this week's snapshots look good to me for the issue having been avoided but ending up better aligned overall than when kern.geom.part.mbr.enforce_chs=3D1 was in use. If a larger alignment is needed at some point for freebsd-ufs, adjusting the pair of gpart add arguments "-a 64k -b 64k" should deal with it. Notes: The USB3 NNVMe SSD based testing was with a 8GiByte RPi4B and so does have the addition of: # # Local addition that avoids USB3 SSD boot failures that look like:=20 # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20 # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ?=20 initial_turbo=3D60=20 in the config.txt file that the RPi* firmware uses. (It is for a separate issue --and FreeBSD does not have such in place by default at this time.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Aug 13 00:30:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4M016SJdz4Z4H5; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4M0162ctz3G4c; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660350641; h=from:from:reply-to:subject:subject:date:date: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=VINIE4Iq4ABuqbCN8aiWS+ZoRa3oSpND1AjjwK8jSko=; b=kr8fFEnNjxx9nydVabQ2Lq7bp0N6wP7cFoF0bVV029hH6fTMMK+CPc+Mcdfts21FaLImaT 4MrDf0UHOjzqROT2e0HAp3+mE3jlDCbp0oI8S4/z+qRWjfNEGvjJwDkt+yuO/gW5IwI3Ra wuG1CdbbpCbK5Dm6DARYVSfCtiisOTGcyAJ03GGGqiexxRCvl1R6q6RHFVoOq0pqduqOWL +iBLS0FtXDH0xJQ+BiprQRarommmKUg+wCo/7LGOpnaOnWCNGn2lkhi0SINwGRSyAtvZSe yuubX+2klQfwTWU4RWUY9Y0C6Bs5eMsXZyeZdeZOW3AedmPqmhBrRHQjWIH4Og== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 3B610610; Sat, 13 Aug 2022 00:30:41 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 13 Aug 2022 00:30:34 +0000 From: Glen Barber To: Mark Millard Cc: Ed Maste , Warner Losh , "Rodney W. Grimes" , FreeBSD Hackers , freebsd-arm , "Dr. Rolf Jansen" Subject: Re: Looks like the arm 20220805 snapshots are still odd, so probably kern.geom.part.mbr.enforce_chs=0 was still in use Message-ID: <20220813003034.GP30607@FreeBSD.org> References: <6AF28022-A8E7-46B3-B64E-99D217E9B6AC@yahoo.com> <0E0083BD-A749-4112-8FDA-62326EA95F8A@freebsd.org> <20220809181513.GG30607@FreeBSD.org> <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Mua2edsUln3Jw4OC" Content-Disposition: inline In-Reply-To: <944D4959-780A-4A45-B8F7-9F3E00741E48@yahoo.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660350641; h=from:from:reply-to:subject:subject:date:date: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=VINIE4Iq4ABuqbCN8aiWS+ZoRa3oSpND1AjjwK8jSko=; b=uwvR9dRQfCZd6KvrybDxpMt6RB0fPP44V+454+PXWuOmabfYlOzbJfs+bOlEU1kxfXN/Me H04YHijNq+z3A7fNeAuncI0hbwFJU3VgIdzCLu7mezCu4/mUFABgDHDAobmN0qNRG8INvJ OQczwEvSqEHwyB4PRaEfF4ntGkW2h5MKbehqrrbHX0caPneQ6t0qOku/EsJj2dDzEO3qaA xMwEwdi5Sz359GWModYda/LzTT02BZRNpZzboIQS6Q48k2a8mNJcNA4kK2/yensmwwacA6 LNbVkIgrPcArA8PZ83+6Aia64FUpHIZQ+al9MWl3+oppTBfcYZo8D7JSVXI+4w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660350641; a=rsa-sha256; cv=none; b=b9hIhMhhzw4+2tbqD3XUJIC7YKMy0Cpj4t4h+kIVBjx5o5SWal2jcQtdAJxmdOBNaeBsRy 7yGVH2IQmn6MRbee3WBFso4DapV3fiMLF5rHFZOifkTLI0KcXrwxObI1n3cJoXbNRPws6t uSlhzR9W447XyHuQGGmWmer11lhPp9ijSEIyARQmyVVPjoktmE1mbv22AKe4gmr/00jBUG SkSD2+0gUqPxCpu6vILIUtSpJWbVAJngo7DlhHVfzUq0QAM15js7xVFlPxZk2y8FAjuT/H /zT/Llo6I0VyFfSyOLMr8ORR3wA64SBWXqmWgP7+e9Zc/vUCnt5g7CX6PfVWiw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Mua2edsUln3Jw4OC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 12, 2022 at 05:16:12PM -0700, Mark Millard wrote: > On 2022-Aug-9, at 11:55, Mark Millard wrote: >=20 > > On 2022-Aug-9, at 11:15, Glen Barber wrote: > >=20 > >> On Tue, Aug 09, 2022 at 02:06:14PM -0400, Ed Maste wrote: > >>> On Sun, 7 Aug 2022 at 18:43, Glen Barber wrote: > >>>>=20 > >>>> Will do. I=E2=80=99ll commit the suggested change to main tomorrow. > >>>>=20 > >>>> Thank you for your vigilant investigation. > >>>=20 > >>> Shall I commit the enforce_chs check now? > >>> --- > >>> commit 6ee7d69e6b526f35789b23ba570025f1c3b39c1a > >>> Author: Ed Maste > >>> Date: Tue Jul 19 16:47:49 2022 -0400 > >>>=20 > >>> release: ensure enforce_chs sysctl is 0 > >>>=20 > >>> We do not want CHS-based alignment for VM or SD card release images. > >>>=20 > >>> Sponsored by: The FreeBSD Foundation > >>>=20 > >>> diff --git a/release/tools/arm.subr b/release/tools/arm.subr > >>> index 6e4ae731a0b9..01c5303cd4e1 100644 > >>> --- a/release/tools/arm.subr > >>> +++ b/release/tools/arm.subr > >>> @@ -62,6 +62,10 @@ umount_loop() { > >>> } > >>>=20 > >>> arm_create_disk() { > >>> + if [ $(sysctl -n kern.geom.part.mbr.enforce_chs) !=3D 0 ]; th= en > >>> + return 1 > >>> + fi > >>> + > >>> # Create the target raw file and temporary work directory. > >>> chroot ${CHROOTDIR} gpart create -s ${PART_SCHEME} ${mddev} > >>> if [ "${PART_SCHEME}" =3D "GPT" ]; then > >>>=20 > >>=20 > >> Good question. Do we still want to ensure it is set to '0'? I'm a bit > >> confused from the back-and-forth on the original thread. > >>=20 > >> If we do want to ensure it is set to '0', yes, please go ahead. > >>=20 > >=20 > > Hopefully this week's experiment with explicitly avoiding BSD > > and freebsd-ufs having the same offset inside BSD (avoiding > > both offsets being zero) will allow the UFS labeling to work > > right: freebsd-ufs being tied to a unique offset inside BSD. > >=20 > > I really doubt that using kern.geom.part.mbr.enforce_chs=3D1 to > > cause the offsets to be different is reasonable, despite that > > it happens to make them distinct: the freebsd-ufs offset is > > better controlled explicitly elsewhere. > >=20 >=20 > The experiment with this week's snapshot is working just fine. > It is based on the update: >=20 > QUOTE > The branch main has been updated by gjb: >=20 > URL: https://cgit.FreeBSD.org/src/commit/?id=3D45add40717c24ef0b5418664fa= e1718b15a0422b >=20 > commit 45add40717c24ef0b5418664fae1718b15a0422b > Author: Glen Barber > AuthorDate: 2022-08-08 14:59:29 +0000 > Commit: Glen Barber > CommitDate: 2022-08-08 14:59:29 +0000 >=20 > release: fix alignment for arm SoCs > =20 > MFC after: 3 days > Submitted by: Mark Millard > Sponsored by: Rubicon Communications, LLC ("Netgate") > --- > release/tools/arm.subr | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/release/tools/arm.subr b/release/tools/arm.subr > index 3dea17339958..25d4640cc26b 100644 > --- a/release/tools/arm.subr > +++ b/release/tools/arm.subr > @@ -77,7 +77,7 @@ arm_create_disk() { > chroot ${CHROOTDIR} newfs_msdos -L msdosboot -F ${FAT_TYPE} /dev/${mdd= ev}s1 > chroot ${CHROOTDIR} gpart add -t freebsd ${mddev} > chroot ${CHROOTDIR} gpart create -s bsd ${mddev}s2 > - chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k ${mddev}s2 > + chroot ${CHROOTDIR} gpart add -t freebsd-ufs -a 64k -b 64k ${mddev}s2 > chroot ${CHROOTDIR} newfs -U -L rootfs /dev/${mddev}s2a > fi > END QUOTE >=20 > This is unlike when the "-b 64k" was not present. This > includes rebooting after the initial boot, unlike before. > This is for dd'ing to USB3 NVMe SSD media and testing, > for both of: >=20 > FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20220812-6a70a0c8bfa-257314.img > FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20220812-eb2a9b78586-252107.img >=20 > (The -b use implicitly also changed the size of the freebsd-ufs > slice, making it smaller.) For the media growfs is involved in > the initial boot. >=20 > glabel list now shows ufs/rootfs bound to da0s2a and does not > show a ufs/rootfsa at all. There is no binding to da0s2 (BSD) > shown. >=20 > # glabel list > Geom name: da0s1 > Providers: > 1. Name: msdosfs/MSDOSBOOT > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r1w1e1 > secoffset: 0 > offset: 0 > seclength: 102400 > length: 52428800 > index: 0 > Consumers: > 1. Name: da0s1 > Mediasize: 52428800 (50M) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 1048576 > Mode: r1w1e2 >=20 > Geom name: da0s2a > Providers: > 1. Name: ufs/rootfs > Mediasize: 240003866624 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53542912 > Mode: r1w1e1 > secoffset: 0 > offset: 0 > seclength: 468757552 > length: 240003866624 > index: 0 > Consumers: > 1. Name: da0s2a > Mediasize: 240003866624 (224G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 53542912 > Mode: r1w1e2 >=20 > # gpart show -p > =3D> 63 468862065 da0 MBR (224G) > 63 1985 - free - (993K) > 2048 102400 da0s1 fat32lba [active] (50M) > 104448 468757680 da0s2 freebsd (224G) >=20 > =3D> 0 468757680 da0s2 BSD (224G) > 0 128 - free - (64K) > 128 468757552 da0s2a freebsd-ufs (224G) >=20 > A difference in behavior is that "gpart show" does not > report the ufs/rootfs labeling. For all I know, this > could be expected. glabel does show ufs/rootfs . >=20 > I do not know what would happen if only the size had > been made smaller but the starting offset had been left > at 0. >=20 > But the evidence from the "without -b" and "with -b" > testing is that having starting offset 0 in BSD > and the same size as BSD can be a problem for the > freebsd-ufs slice as processed by the initial boot, > at least when ufs labeling is in use (here ufs/rootfs). >=20 > So far, this week's snapshots look good to me for the > issue having been avoided but ending up better aligned > overall than when kern.geom.part.mbr.enforce_chs=3D1 was > in use. >=20 > If a larger alignment is needed at some point for > freebsd-ufs, adjusting the pair of gpart add arguments > "-a 64k -b 64k" should deal with it. >=20 >=20 > Notes: >=20 > The USB3 NNVMe SSD based testing was with a 8GiByte > RPi4B and so does have the addition of: >=20 > # > # Local addition that avoids USB3 SSD boot failures that look like:=20 > # uhub_reattach_port: port ? reset failed, error=3DUSB_ERR_TIMEOUT=20 > # uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port = ?=20 > initial_turbo=3D60=20 >=20 > in the config.txt file that the RPi* firmware uses. > (It is for a separate issue --and FreeBSD does not > have such in place by default at this time.) >=20 Mark, Thank you very much for the detailed information, and of course for reporting the problem, and testing variations of the correct behavior. Glen --Mua2edsUln3Jw4OC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmL28KUACgkQAxRYpUeP 4pO27g//dXjEFscvG6vXKerHSwgSjTNT09+LzwL3ENMTvf4NyB68K3Eje5MiWeCR FSwvLaIXK8LH7oLdTasstHe5dP35ICBAJANJS23CfQdoEDS3T/7cnVd5vbAOUSyl mlovvgQPoWZgRLHIJ0THYCIC+S3rK7YF0lW1Nk5vMrK1hQpYh5s9dFDJ1k8bOQLL ek5q2Bo3E8h0LhtbgvDGSZLlh7BMBzWxzPuoCBvws2Ga3PKLL7Jb5uutGqeHL2bS 4CZrJQDalFs/+55R0D1qQyMakTnQ43llBgy7XggLKitMpXVoG2bX12LLQB1GtnU/ zciF/nCD0BTY1Cyy8kuKz4/U1FjpBVYfdL20BOLE3XM7Yo4wzDj5BgXbHL7vLrJN CphXPsmHnRFLETfxVA64QbTRlPpAj/fc3g3Eav/pfau3ubjmvCk9i9QrokSG+OWl 9BLu0UwPaZZfir8jREahV+Pd0a4G3zy8HGsHyq7KTqqm/mzGL2Qx5eKBUAa8OywG jbrJiF72PCU+83y39uSYZthVQx8t3A5+r4V/27Y3Em5pvYEEMELRfF3907hPErmP 0OPxo6yFs7FAkLJmZeWfa+brttfRfh2HeQx6U3kh2cF7/cRFKWxu3qORI5tCr/jm B+wZj6mJQGZ3pnUy8Pr+8LvFA75A+TvFdsOZSWj8H93JB1+O8RU= =KC81 -----END PGP SIGNATURE----- --Mua2edsUln3Jw4OC-- From nobody Sat Aug 13 12:16:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4ffn2c9Kz4Z8DC for ; Sat, 13 Aug 2022 12:16:49 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4ffm2ssHz3k9j for ; Sat, 13 Aug 2022 12:16:48 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: by mail-ej1-x629.google.com with SMTP id w19so6063839ejc.7 for ; Sat, 13 Aug 2022 05:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc; bh=1N09lH6ShsgukPIiYjH5mFOSg5bzw8HH7IPy+abupqg=; b=CiK+6Pzcg/uSPm0qts+VllbJMiSgLQ2be9H8pUPQWuUcWWvA/jRxBPKXuLgWwoeQDB 6XFgW3mmewM9aTWoTSXK9zCpGhtnSgUFi8kyuZJNS+/Vzuw+S98ZI2ghiuiNIFp53Y3q NwLcW3KfQ4cXCax9POdiXm24KUDZUkQwg7nPDu3/WYRcgah/OSHvwzwCKY8YpOcfQg4I 6uyV4BQAnk/c+r/fqo4ZR2eX3gqRfCAotOZts4aD3wyiz4JLVMWqIaXcZcObCEU/vu6w +3tcZX2v/k//nEW6iUwQvAEqDzBNvrIlTTDePB7jMvqQQKDAyagv9awrimlKkHCqR1xJ GLnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=1N09lH6ShsgukPIiYjH5mFOSg5bzw8HH7IPy+abupqg=; b=LGgtRQxxRQmxPS13b145KWcWb7Uhtu9gEQaopXB1CNl4PPAnlk12tIz1b4Gr82HX33 iUpq/cZjMT+X9jErutBmsljHqVaqXVRXX3OerIscV6D4lr87iPJ6rRXph5RoT19sIg2G GgCVOWFwTz2kLp3iIOpulace/4HEaZl88JR4fvLEtk5fceiQI6Oo6HXeD4JMR8DKk6XA Jnoy0rhb14LnE0Ly6HQbvi9qS9eCpVbAHX7deHvE3dYVdFafr5ToW23o/GeXhfDxnBiP Vm8WychLrOlx59DqgwNHdVQcRiM46Itsbut06xVAErS0RNuxnzFrv6ALGTEcsozLw/CQ kQSw== X-Gm-Message-State: ACgBeo3BKowLU3A9hkL/jk9BtvxSMpNgb9xkzZsGckTSvYHdHkcHUW0Y DQzlHe5o5urDory9L9B8evTv8P+AfOo= X-Google-Smtp-Source: AA6agR7t7JAoBoVMO7h8fYyAtFcxiHzoaiMogibnw5Lqmjoq2t/ltQwbcv3rl8pVlg9PG63XTdSToA== X-Received: by 2002:a17:907:3f94:b0:731:6473:b36c with SMTP id hr20-20020a1709073f9400b007316473b36cmr5503863ejc.525.1660393004065; Sat, 13 Aug 2022 05:16:44 -0700 (PDT) Received: from [192.168.0.109] ([91.187.59.126]) by smtp.gmail.com with ESMTPSA id x4-20020a1709065ac400b00730b3bdd8d7sm1838861ejs.179.2022.08.13.05.16.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 05:16:43 -0700 (PDT) Message-ID: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Date: Sat, 13 Aug 2022 14:16:33 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: freebsd-hackers@FreeBSD.org From: meator Subject: How to monitor a directory in FreeBSD? Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------maHW3ECKvLTYDPswhJhd8K0H" X-Rspamd-Queue-Id: 4M4ffm2ssHz3k9j X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CiK+6Pzc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of meator.dev@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=meator.dev@gmail.com X-Spamd-Result: default: False [-2.01 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_MEDIUM(0.98)[0.980]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_BASE64_TEXT(0.10)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------maHW3ECKvLTYDPswhJhd8K0H Content-Type: multipart/mixed; boundary="------------ipNNRhgmHEt810wVweLljYyv"; protected-headers="v1" From: meator To: freebsd-hackers@FreeBSD.org Message-ID: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Subject: How to monitor a directory in FreeBSD? --------------ipNNRhgmHEt810wVweLljYyv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGVsbG8uIEknbSB3b3JraW5nIG9uIGEgQyBwcm9ncmFtIHRoYXQgbmVlZHMgdG8ga25vdyB3 aGV0aGVyIGZpbGVzIGFuZCANCmRpcmVjdG9yaWVzIGluIGEgc3BlY2lmaWMgZGlyZWN0b3J5 IHdlcmUgYWRkZWQsIG1vZGlmaWVkIG9yIGRlbGV0ZWQuIChJdCANCnNob3VsZCBhbHNvIGJl IGRvbmUgcmVjdXJzaXZlbHkgZm9yIGFsbCBzdWJkaXJlY3RvcmllcywgYnV0IHRvIGtlZXAg aXQgDQpzaW1wbGUgSSBkb24ndCB0YWtlIHJlY3Vyc2lvbiBpbnRvIGFjY291bnQuIEl0IHNo b3VsZG4ndCBiZSB0aGF0IGhhcmQgdG8gDQppbXBsZW1lbnQgaXQgYWZ0ZXIgSSB3aWxsIGJl IGFibGUgdG8gbW9uaXRvciBhIGRpcmVjdG9yeSBub25yZWN1cnNpdmVseS4pDQoNCkkgZG9u J3QgaGF2ZSBtdWNoIGV4cGVyaWVuY2Ugd2l0aCBCU0QgcHJvZ3JhbW1pbmcgYnV0IEkga25v dyBQT1NJWC4gSSANCmhhdmUgdXNlZCBpbm90aWZ5IGJlZm9yZSBmb3IgdGhpcyBwdXJwb3Nl LCBidXQgQlNEIGRvZXNuJ3QgaGF2ZSBpdCBzbyBJIA0Kc3RhcnRlZCBsb29raW5nIGZvciBC U0QgYWx0ZXJuYXRpdmVzLiBUaGUgaW50ZXJuZXQgbGVhZCBtZSB0byBrcXVldWUuIEkgDQpz YXcgc29tZSBjcml0aWNpc20gb2YgaXQsIGJ1dCBJIGRvbid0IG5lZWQgdG8gbW9uaXRvciBz ZXZlcmFsIHRob3VzYW5kcyANCm9mIGZpbGVzLCBzbyBJIGhvcGUgaXQgd2lsbCBiZSB1c2Fi bGUgZm9yIG15IHVzZSBjYXNlLg0KDQpUaGUgRVZGSUxUX1ZOT0RFIGZpbHRlciBkb2N1bWVu dGF0aW9uIGluIGtxdWV1ZSgyKSBkb2Vzbid0IHJlYWxseSB0YWxrIA0KYWJvdXQgZmlsZXMg YW5kIGRpcmVjdG9yaWVzLCBpdCB0YWxrcyBhYm91dCBmaWxlIGRlc2NyaXB0b3JzLiBJbm90 aWZ5IG9uIA0KdGhlIG90aGVyIGhhbmQgaXMgdmVyeSBleHBsaWNpdCBhYm91dCBoYW5kbGlu ZyBmaWxlcyBpbiB0aGUgbW9uaXRvcmVkIA0KZGlyZWN0b3J5LiBLcXVldWUgY2FuIHN0aWxs IGRldGVjdCBjcmVhdGlvbiBhbmQgZGVsZXRpb24gb2YgZmlsZXMgaW5zaWRlIA0KdGhlIG1v bml0b3JlZCBkaXJlY3Rvcnkgd2l0aCBOT1RFX1dSSVRFIGZvciBmaWxlcyBhbmQgTk9URV9M SU5LIGZvciANCmRpcmVjdG9yaWVzIChhdCBsZWFzdCBJIHRoaW5rLCBJIG1hZGUgYSBsaXR0 bGUgdGVzdCBwcm9ncmFtIHRvIHRlc3QgdGhpcykuDQoNClRoaXMgaXMgdXNlZnVsLCBidXQg SSBkb24ndCBzZWUgYW55IG9idmlvdXMgd2F5IHRvIGlkZW50aWZ5IGEgbmV3bHkgDQpjcmVh dGVkIGZpbGUgaW5zaWRlIHRoZSBtb25pdG9yZWQgZGlyZWN0b3J5LiBGaWxlIGNyZWF0aW9u IHdvdWxkIHJlc3VsdCANCmluIE5PVEVfV1JJVEUsIGJ1dCBzdHJ1Y3Qga2V2ZW50IGRvZXNu J3QgaGF2ZSBhbnkgIm5hbWUiIGZpZWxkICh1bmxpa2UgDQppbm90aWZ5KSB0aGF0IHdvdWxk IHNob3cgd2hpY2ggZmlsZSB3YXMgY3JlYXRlZC4gSSB3b3VsZCBoYXZlIHRvIG1ha2UgYSAN Cmxpc3Qgb2YgZGlyZWN0b3JpZXMgYW5kIGNvbXBhcmUgdGhlIG9sZCBzdGF0ZSB3aXRoIHRo ZSBjdXJyZW50IHN0YXRlIHRvIA0Kc2VlIHRoZSBmaWxlIHdoaWNoIHdhcyBhZGRlZC4NCg0K S3F1ZXVlIGFsc28gZG9lc24ndCBzZWVtIHRvIGRldGVjdCBtb2RpZmljYXRpb24gb2YgZmls ZXMgaW5zaWRlIHRoZSANCm1vbml0b3JlZCBkaXJlY3RvcnkuIERvZXMgdGhpcyBtZWFuIHRo YXQgSSB3b3VsZCBoYXZlIHRvIG1vbml0b3IgZXZlcnkgDQpzaW5nbGUgZmlsZSBpbiB0aGUg ZGlyZWN0b3J5IHRvIG1ha2UgdGhpcyB3b3JrPw0KDQpJIHRoaW5rIHRoaXMgc2hvd3MgdGhh dCBrcXVldWUgaXNuJ3QgcmVhbGx5IG1lYW50IHRvIGJlIHVzZWQgZm9yIA0KbW9uaXRvcmlu ZyBkaXJlY3RvcnkgbWVtYmVycy4gSXMgdGhpcyB0cnVlPyBIYXZlIEkgbWlzdW5kZXJzdG9v ZCBzb21ldGhpbmc/DQo= --------------ipNNRhgmHEt810wVweLljYyv-- --------------maHW3ECKvLTYDPswhJhd8K0H Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEew9YpeDxouoRV4pzGhTLNGTL5b8FAmL3liIACgkQGhTLNGTL 5b9dqwv/fMMoSaquAPSEK9nDvQymWQli06jhZ0DdR6J1C1+J2S2AtFlmDNmIsonD gwlxoD1ymZmMCk6x5GXOo5Hi/0bx6F8osGUOnfWZbHiOVqZAJWGweL+SdvuyaN0t Qzq6ZwVfa6EDFywi0ML0+3seFsx+zTLRfT+2rB09j5Lc6uU7K2+Q0DWCUXmU1vv+ b4PD4C9CZBqHrBUremPvlBv/AL/fnmvXv9YmM0x3UbbfoIZdO8l5WzTp6MJ+VFF7 HQxANUtslRids1x4iEeg1I6dV3A6vCHAsbbpXF2N8QkJ5t6rpMkInT33GEfYK10e FCB1nq2HDKWPxr+faCUOo3QM5fsDhq1jGolP9Dxf33TJWEgxW9J0zg4bhTIA5C8K Wtbc/KaXBtKSAgfi5phM2MY7xyLvCwkS+qqW0S2HykTCUy7w12n0enIJivywfhNo goiPO+HOs91NAgGqwrZQXnURQ915ro+fS2cF179YJW7IW3yQZJ4DzHYKzhfd95QO ulTwE/Oj =rVe0 -----END PGP SIGNATURE----- --------------maHW3ECKvLTYDPswhJhd8K0H-- From nobody Sat Aug 13 14:28:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4jc3224jz4YnGB for ; Sat, 13 Aug 2022 14:29:39 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4jc31SzPz419n for ; Sat, 13 Aug 2022 14:29:39 +0000 (UTC) (envelope-from wulf@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660400979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x/L3kDS1a8nQlXoBTd0pnwquxfnjVO216PAP0y3NFrk=; b=aoNCVEmoUMhw49srDEHQ/n+xKa5JIYtN65T3FE8BunfoNdHy4EgJ4doBLqxXZHyqLME0nG 2KMTN/K1tau9CxNzBWsWQhGwM7Gyx99IrzoJL5maFQQZ4JNO8c9ptKIt4potaqxgQckfp7 sTMnEFgPJnIO2YbR4P6JThJy89dRohzX0zpQXyYF+MPr6b0sgBlvzGTwdnjSsrk1xzlrht EVdxxrwgDrmWP1oJAc67EmkHZykIXMW1KxOF+6k2G9x/c79xfDRfbRz7F1wmV+UQegEXuP 6eIdPAjGmVfNqCAQMk/Up8pB+UkYt35KQcuEGKi9sr3T4suNfp2ni7gfnW8png== Received: from [192.168.0.30] (unknown [94.45.210.186]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: wulf) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4jc25ZrfzkJl for ; Sat, 13 Aug 2022 14:29:38 +0000 (UTC) (envelope-from wulf@FreeBSD.org) Message-ID: <8e4a993d-795a-158b-d8fc-72fe6475baa6@FreeBSD.org> Date: Sat, 13 Aug 2022 17:28:51 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: How to monitor a directory in FreeBSD? Content-Language: en-US To: freebsd-hackers@freebsd.org References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> From: Vladimir Kondratyev In-Reply-To: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660400979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x/L3kDS1a8nQlXoBTd0pnwquxfnjVO216PAP0y3NFrk=; b=OF38gouGPYmLzj6WP/5EUN8E3HIfEXsgiUiTmoI5QnZgWuke2ikw0zBDTj5nYLm9KwvMMY AmDz/QC3ktzXbtM8QaL2ExIDHUoy4AnO1CWAjYcDKU2+KDT9jJBUG5wFo1a9Z9IBGuTB+f vBeWV64FFvejWV52lP6iAKHfUn3BMKQOV60aUR6ZDQpMF+LTVgNVxunba8RPI+qwzvxBrS LvxQ7mZBVeaP0HuC7RacLCBHoZDCcBgANtcGQ49tWS5z6elaCS6MxriGG2+EYFPNI0cYm3 WmPeSzBw90MapzDVuDDgywbvNYdcIXjj6aJhyMYsshSStBhUisGfTzIjMRkT1Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660400979; a=rsa-sha256; cv=none; b=NyLBxNXWv5bSeTwTQwYML/mhxjMSRoxScKzVd3QlcGQgQ0jiD0cpCa9jnMjQndx2dYE8ym dKZBrdgwSckZjThu4FL2xRNAPFs5LP44Dg9hJZF8hAThsHK6RUMG1/p6Mq0bW+Z23lMVT5 J3pWIYWgDOM0ZbncAKLjOINaFud/Ns+XDL78uTHX+qwJLW8/GHK1JpJedso4TG3i/s7MJi WVFNHAv0eMccZNpNwM1r5cVij30gpW2A4S75yx3KtJUPPC/oPvPIx8uzrqBmCr2taZx6pA +gbdfSn9fwBIEvHx1PT9nsNQszHQYmegE4xtujIDzvgZjmUfibdeEeDYSaknRg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 13.08.2022 15:16, meator wrote: > Hello. I'm working on a C program that needs to know whether files and > directories in a specific directory were added, modified or deleted. (It should > also be done recursively for all subdirectories, but to keep it simple I don't > take recursion into account. It shouldn't be that hard to implement it after I > will be able to monitor a directory nonrecursively.) > > I don't have much experience with BSD programming but I know POSIX. I have used > inotify before for this purpose, but BSD doesn't have it so I started looking > for BSD alternatives. The internet lead me to kqueue. I saw some criticism of > it, but I don't need to monitor several thousands of files, so I hope it will be > usable for my use case. > > The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk about > files and directories, it talks about file descriptors. Inotify on the other > hand is very explicit about handling files in the monitored directory. Kqueue > can still detect creation and deletion of files inside the monitored directory > with NOTE_WRITE for files and NOTE_LINK for directories (at least I think, I > made a little test program to test this). > > This is useful, but I don't see any obvious way to identify a newly created file > inside the monitored directory. File creation would result in NOTE_WRITE, but > struct kevent doesn't have any "name" field (unlike inotify) that would show > which file was created. I would have to make a list of directories and compare > the old state with the current state to see the file which was added. > > Kqueue also doesn't seem to detect modification of files inside the monitored > directory. Does this mean that I would have to monitor every single file in the > directory to make this work? > > I think this shows that kqueue isn't really meant to be used for monitoring > directory members. Is this true? Have I misunderstood something? It looks that inotifywait from sysutils/inotify-tools is what you need -- WBR Vladimir Kondratyev From nobody Sat Aug 13 15:35:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4l4B2PNkz4Z5sd for ; Sat, 13 Aug 2022 15:35:38 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4l4927wkz49Tk for ; Sat, 13 Aug 2022 15:35:37 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-vs1-f46.google.com with SMTP id q15so3500105vsr.0 for ; Sat, 13 Aug 2022 08:35:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=n/AFrS3LUJpQ+sgjMlZiaebJPGAKEEfLIUaHZm0svIs=; b=nfbQQz+P/JGmh+d5eNB/vG1vyJkksSfPjUbv3/Expvv2NkJjo1GMQ983zG0sXZUDBO msnf96WHkv4r7f606uC42S3aYwJ+CtJzAei7VPwGaZ00DckcupZ95c3/EvjffOd+13s6 gC+DyXh4FQOVTujvgDMwDWJSyfmkTMc4I1VE3eHJuG2HqXLp29qXGuxgW3we5iD+yJTx 1uccEHLNDoHIdcDlIfLhn8vXnLn70x61W7otfbAsV6iBLru4rOk1q4BtwXUwGIrFVtRc gOD3D9j3ZLc1tQ4ksNC3Yv35dRLUZ72TGdQ8rpcigVn/QRdGxZdnHeYllNMfzlFnwJxY peBQ== X-Gm-Message-State: ACgBeo19qtdlYQ8ybZPSWislhnmFzOHpvOdDiv1Dn8VfhiX9TzLvxBCP JJ7jhsCLd/MtSG6u0vQPlTv2mkBSt/OEvQ== X-Google-Smtp-Source: AA6agR4nNWDBGAYb0YkFoCKfR03VoS+z7mu3fcO+4vtgGWdEIzvzJc6JkLfudpZBLpkdIXHKJlAuvw== X-Received: by 2002:a05:6102:5e6:b0:385:361:5892 with SMTP id w6-20020a05610205e600b0038503615892mr3648077vsf.7.1660404936025; Sat, 13 Aug 2022 08:35:36 -0700 (PDT) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com. [209.85.221.176]) by smtp.gmail.com with ESMTPSA id y12-20020ab05b8c000000b003844b2e1462sm2124133uae.13.2022.08.13.08.35.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 08:35:35 -0700 (PDT) Received: by mail-vk1-f176.google.com with SMTP id bi51so1826209vkb.5 for ; Sat, 13 Aug 2022 08:35:35 -0700 (PDT) X-Received: by 2002:ac5:cb6e:0:b0:37d:2a0b:af66 with SMTP id l14-20020ac5cb6e000000b0037d2a0baf66mr3836740vkn.30.1660404935319; Sat, 13 Aug 2022 08:35:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> In-Reply-To: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> From: Gleb Popov Date: Sat, 13 Aug 2022 18:35:21 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: How to monitor a directory in FreeBSD? To: meator Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="0000000000005a65d605e6212676" X-Rspamd-Queue-Id: 4M4l4927wkz49Tk X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of 6yearold@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=6yearold@gmail.com X-Spamd-Result: default: False [-1.36 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.36)[-0.356]; FORGED_SENDER(0.30)[arrowd@freebsd.org,6yearold@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.46:from,209.85.221.176:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[arrowd@freebsd.org,6yearold@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.46:from] X-ThisMailContainsUnwantedMimeParts: N --0000000000005a65d605e6212676 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 13, 2022, 15:16 meator wrote: > Hello. I'm working on a C program that needs to know whether files and > directories in a specific directory were added, modified or deleted. (It > should also be done recursively for all subdirectories, but to keep it > simple I don't take recursion into account. It shouldn't be that hard to > implement it after I will be able to monitor a directory nonrecursively.) > > I don't have much experience with BSD programming but I know POSIX. I > have used inotify before for this purpose, but BSD doesn't have it so I > started looking for BSD alternatives. The internet lead me to kqueue. I > saw some criticism of it, but I don't need to monitor several thousands > of files, so I hope it will be usable for my use case. > > The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk > about files and directories, it talks about file descriptors. Inotify on > the other hand is very explicit about handling files in the monitored > directory. Kqueue can still detect creation and deletion of files inside > the monitored directory with NOTE_WRITE for files and NOTE_LINK for > directories (at least I think, I made a little test program to test this). > > This is useful, but I don't see any obvious way to identify a newly > created file inside the monitored directory. File creation would result > in NOTE_WRITE, but struct kevent doesn't have any "name" field (unlike > inotify) that would show which file was created. I would have to make a > list of directories and compare the old state with the current state to > see the file which was added. > > Kqueue also doesn't seem to detect modification of files inside the > monitored directory. Does this mean that I would have to monitor every > single file in the directory to make this work? > > I think this shows that kqueue isn't really meant to be used for > monitoring directory members. Is this true? Have I misunderstood something? > Yes, there is no native API to monitor directories. You can use libinotify from ports, which replicates Linux inotify API and it does have ability to monitor directories. > --0000000000005a65d605e6212676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Aug 13, 2022, 15:16 meator <meator.dev@gmail.com> wrote:
Hello. I'm working on a C program that needs = to know whether files and
directories in a specific directory were added, modified or deleted. (It should also be done recursively for all subdirectories, but to keep it
simple I don't take recursion into account. It shouldn't be that ha= rd to
implement it after I will be able to monitor a directory nonrecursively.)
I don't have much experience with BSD programming but I know POSIX. I <= br> have used inotify before for this purpose, but BSD doesn't have it so I=
started looking for BSD alternatives. The internet lead me to kqueue. I saw some criticism of it, but I don't need to monitor several thousands=
of files, so I hope it will be usable for my use case.

The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk =
about files and directories, it talks about file descriptors. Inotify on the other hand is very explicit about handling files in the monitored
directory. Kqueue can still detect creation and deletion of files inside the monitored directory with NOTE_WRITE for files and NOTE_LINK for
directories (at least I think, I made a little test program to test this).<= br>
This is useful, but I don't see any obvious way to identify a newly created file inside the monitored directory. File creation would result in NOTE_WRITE, but struct kevent doesn't have any "name" fiel= d (unlike
inotify) that would show which file was created. I would have to make a list of directories and compare the old state with the current state to see the file which was added.

Kqueue also doesn't seem to detect modification of files inside the monitored directory. Does this mean that I would have to monitor every
single file in the directory to make this work?

I think this shows that kqueue isn't really meant to be used for
monitoring directory members. Is this true? Have I misunderstood something?=

= Yes, there is no native API to monitor directories. You can use libinotify = from ports, which replicates Linux inotify API and it does have ability to = monitor directories.
--0000000000005a65d605e6212676-- From nobody Sat Aug 13 16:51:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4mlr0lp3z4ZR8C for ; Sat, 13 Aug 2022 16:51:36 +0000 (UTC) (envelope-from leres@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 4M4mlr0L5nz3RWM; Sat, 13 Aug 2022 16:51:36 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660409496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q0h4jbA54ZtjhlyOLyzoizBGmo8k7McblNoGtk5TCMA=; b=IV0LNNZq9PxY9mMWatUWhNHqQBfoRQ3Lpst6PsUj7Jufhl9BRApaq2FVCnlLw0CjbdIWms bz+LbaoHbucdfteMwTklnTpQQ2qgQ8DWlJ0VP4F0J5RC598VK0s0JlBGH+sZL3IULT0I0A c0U7TVshCju1tXaJq+djPtMw1QtMXYvcaqlf24Pxisvbp2ztzEShksnkvwgyR2aC0/+o1c 5i7I8gkm4rFB10Q6etK+36S1WMWENlJG0OPhKPpq4BRdv0dCY+NgENbsTtj5jzPlqpcFAQ ZSPPJRODTT5m42KdP+jPqvJK9Ell0+h3L1zffblInvk8LcrI+QW7DvDAAwR10w== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20::38]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M4mlq3l41znLb; Sat, 13 Aug 2022 16:51:35 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <754a7f6d-8fbe-aae0-796b-e5c0e782fc4f@freebsd.org> Date: Sat, 13 Aug 2022 09:51:32 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: How to monitor a directory in FreeBSD? Content-Language: en-US To: meator , freebsd-hackers@FreeBSD.org References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> From: Craig Leres In-Reply-To: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660409496; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q0h4jbA54ZtjhlyOLyzoizBGmo8k7McblNoGtk5TCMA=; b=oM5lYxJbjtyjkQzXh5sh3yRiwn8kQZ4XcCoRh3VXe/RZSyl3iM/Ui5PAdKqFGKB2iJqzLH +Wn9cnDBScvdJ6vgOE+ETw9o9Au17ttga6ORmH4Dn0PwH6o+oJh7jW3LsExo2DKSa7UCY9 c/S74i/e9NDk3Nh7FQT3JasSlSMM7yFN/cq6NGI/3sWRvB3i464oKksHNCbwtNj2Co8UKP OETZFK57NkTqgRFN9ed/s7cOqMxyRUa7eNfh/Z+XeZ743dIQFeSkCSsGlLC5eM3PJNG/Kq Bf6cSM1dX9nSjAoMUZsoZbqQZ8oDnnY+bwtk9jX+G5+gXpWXiulRR6rSULUJ0A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660409496; a=rsa-sha256; cv=none; b=u18PameLv2AuMmy35e3RdKGnNGlVIovlb8KqDaAJTvpAHHn7eNP9SFhfGroPdFErMcL56l qiaqxyEFmizOSqsRLJlrFvOmXOYVtxLzSdKzzT6vs7uZvPjLAZy+DNkXv6Hl7ba55tix48 aGYp2fYB1S9kkQeaX8c2yC3QxPJzTPtvSR6+RIAOSyOIt9iS2Hkg0AuKRZbxY6dmLN2sam +43fg27RG49uEEgW3NDi2QGaz010OVTvyg3hddOIRa579BQymlhrpRxC3IlOYYShvghUbZ D5yG0m0C1Ujc8cBaf0Zj+C219oNbQSYsYGuG2ovcP3bWYAUgYsHuTUJVsr77Jg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 8/13/22 05:16, meator wrote: > Hello. I'm working on a C program that needs to know whether files and > directories in a specific directory were added, modified or deleted. (It > should also be done recursively for all subdirectories, but to keep it > simple I don't take recursion into account. It shouldn't be that hard to > implement it after I will be able to monitor a directory nonrecursively.) > > I don't have much experience with BSD programming but I know POSIX. I > have used inotify before for this purpose, but BSD doesn't have it so I > started looking for BSD alternatives. The internet lead me to kqueue. I > saw some criticism of it, but I don't need to monitor several thousands > of files, so I hope it will be usable for my use case. > > The EVFILT_VNODE filter documentation in kqueue(2) doesn't really talk > about files and directories, it talks about file descriptors. Inotify on > the other hand is very explicit about handling files in the monitored > directory. Kqueue can still detect creation and deletion of files inside > the monitored directory with NOTE_WRITE for files and NOTE_LINK for > directories (at least I think, I made a little test program to test this). > > This is useful, but I don't see any obvious way to identify a newly > created file inside the monitored directory. File creation would result > in NOTE_WRITE, but struct kevent doesn't have any "name" field (unlike > inotify) that would show which file was created. I would have to make a > list of directories and compare the old state with the current state to > see the file which was added. > > Kqueue also doesn't seem to detect modification of files inside the > monitored directory. Does this mean that I would have to monitor every > single file in the directory to make this work? > > I think this shows that kqueue isn't really meant to be used for > monitoring directory members. Is this true? Have I misunderstood something? The way I've done it is is to use EVFILT_VNODE/NOTE_WRITE to tell me when the directory has changed and then roll my own opendir()/readdir() code to detect what (if anything) was added or deleted. Craig From nobody Sat Aug 13 19:09:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4qpl3fjBz4Yd0p for ; Sat, 13 Aug 2022 19:09:19 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4qpk3jd6z3lql; Sat, 13 Aug 2022 19:09:18 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: by mail-ed1-x52f.google.com with SMTP id s11so4930997edd.13; Sat, 13 Aug 2022 12:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc; bh=1qAgkdS+DJvYRarzep60Ie/VibN9zI6mSaBqgHmwy6I=; b=KhpYCzhPiZVjfx6SJwecj95n+NC7exVY7finhMv7ei4c+sp4lDI4NSKrgLqYr6dv/+ Z2hLNDBLU0WRmxqv+7U6jFUo60K1fv94hfCcDFPmrIrn5hrqcf2umLnwaMIkq3Vr6Bzf peM1PDgP6D6uaYSgDAL0CyjntLp8K0SFRi2Uqd576lMJx3IH/9rN25F3lzX6hQEmVaLs hm8pBY5yu6xUhC7z1S6V8hOUnvxHt4tpIq9Jcr7Hd3ZVOOkR7Z7q7+eoF8aIJRkTokGA ipqxAhsF7Or4Dh9EVsprkbFNcxtBeDvBYVwKhoob+7sJ2riykddqDi2iAsjVPmD/i6pf ae0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc; bh=1qAgkdS+DJvYRarzep60Ie/VibN9zI6mSaBqgHmwy6I=; b=8Fye7Tn/8hdWJC4oYjRxS5jThjHBQu6hjxIQVN/5q6EUiR4CthYeTeNaP/BG/JQSZi KuJcO16GVMbbcSDep+xBpCEzKbvb97Q9TXdKtM9Y8HP64ygFFp9Lu/YefAkVktxFYsXC LFNhS4R52+42uarQ8P9XvPgGggMyjTQBWM4uvR+uQrZf9DFghsCrU52q7s4ArE+q8iQi RzSgTq/hEKbLQKiGoc9RYI5fON5iwvEBJzB9EIfajgMxlp/civ1K6D5OLrhwCeXw/EB+ jRcJU90qdXn8/AVCsMalSJ/06u+GYfB94fGLF02xzMhuCsfB6yzYgS12UvWNuJdKUANH c17Q== X-Gm-Message-State: ACgBeo0Bz+NT4wYfZCWIaXLq2U9Nw7hKUsI6p26A0IirGe45uahUr4nl h/k6kVukBhjRSzd3LjLuY+Rjoy1h5ok= X-Google-Smtp-Source: AA6agR5ApeGjWYmw0QWwLZmPHFIm57NraK4n1hLwTZwF3M+q5zp2L1tu+QgsDMx3zqxPUdAYAKF1LQ== X-Received: by 2002:a05:6402:50cb:b0:440:87d4:3ad2 with SMTP id h11-20020a05640250cb00b0044087d43ad2mr8335179edb.219.1660417757275; Sat, 13 Aug 2022 12:09:17 -0700 (PDT) Received: from [192.168.0.109] ([91.187.59.126]) by smtp.gmail.com with ESMTPSA id kd1-20020a17090798c100b007262a1c8d20sm2220330ejc.19.2022.08.13.12.09.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 12:09:16 -0700 (PDT) Message-ID: Date: Sat, 13 Aug 2022 21:09:14 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: How to monitor a directory in FreeBSD? Content-Language: en-US To: Gleb Popov References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Cc: freebsd-hackers From: meator In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------zR7es85qzLzC22mOV3txUPGH" X-Rspamd-Queue-Id: 4M4qpk3jd6z3lql X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KhpYCzhP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of meator.dev@gmail.com designates 2a00:1450:4864:20::52f as permitted sender) smtp.mailfrom=meator.dev@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; TAGGED_FROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52f:from]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------zR7es85qzLzC22mOV3txUPGH Content-Type: multipart/mixed; boundary="------------7Y3eEWeT0xyk0yf2HOAdrU4n"; protected-headers="v1" From: meator To: Gleb Popov Cc: freebsd-hackers Message-ID: Subject: Re: How to monitor a directory in FreeBSD? References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> In-Reply-To: --------------7Y3eEWeT0xyk0yf2HOAdrU4n Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOC8xMy8yMiAxNzozNSwgR2xlYiBQb3BvdiB3cm90ZToNCj4gDQo+IFllcywgdGhlcmUg aXMgbm8gbmF0aXZlIEFQSSB0byBtb25pdG9yIGRpcmVjdG9yaWVzLiBZb3UgY2FuIHVzZSAN Cj4gbGliaW5vdGlmeSBmcm9tIHBvcnRzLCB3aGljaCByZXBsaWNhdGVzIExpbnV4IGlub3Rp ZnkgQVBJIGFuZCBpdCBkb2VzIA0KPiBoYXZlIGFiaWxpdHkgdG8gbW9uaXRvciBkaXJlY3Rv cmllcy4NCj4gDQoNCkkgd291bGQgbGlrZSB0byBhdm9pZCBleHRyYSBkZXBlbmRlbmNpZXMu IElmIEkgd291bGQgbGlrZSB0byBkbyB0aGlzLCANCnRoYW4gSSB3b3VsZCBwcm9iYWJseSBj aG9vc2UgRkFNIG9mIEdhbWluLiBUaGUgTGludXggUHJvZ3JhbW1pbmcgDQpJbnRlcmZhY2Ug Ym9vayByZWZlcmVuY2VzIHRoZXNlIHR3byBhcyBhIG1vcmUgY3Jvc3MgcGxhdGZvcm0gDQph bHRlcm5hdGl2ZXMgdG8gaW5vdGlmeS4gVGhlIHByb2dyYW0gSSdtIHdvcmtpbmcgb24gc2hv dWxkIGFsc28gd29yayBvbiANCkxpbnV4LiBJJ20gY3VycmVudGx5IHdhbnQgdG8gaW1wbGVt ZW50IGJvdGggaW5vdGlmeSBhbmQga3F1ZXVlIGFuZCBtYWtlIA0KdGhlIHByZXByb2Nlc3Nv ciBwaWNrIHRoZSByaWdodCBvbmUgd2hlbiBjb21waWxpbmcuDQoNCkJ1dCBJIGRpZG4ndCBr bm93IGlub3RpZnkgZm9yIEJTRCBleGlzdHMuIFRoaXMgd291bGQgbWVhbiB0aGF0IEkgDQp3 b3VsZG4ndCBoYXZlIHRvIGltcGxlbWVudCB0aGUgZGlyZWN0b3J5IG1vbml0b3JpbmcgdHdp Y2UuIEknbGwgdGFrZSANCnRoaXMgaW50byBjb25zaWRlcmF0aW9uLiBUaGFua3MhDQo= --------------7Y3eEWeT0xyk0yf2HOAdrU4n-- --------------zR7es85qzLzC22mOV3txUPGH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEew9YpeDxouoRV4pzGhTLNGTL5b8FAmL39toACgkQGhTLNGTL 5b8TUAv9EvMrzIzX4uVvlS0odAjTuyUWXSmVMDk0bwKuuvNLNJyPQ+9ctk9e9YuX CkjaxZlCEJY1M3ZKPNkZ+Xrr1nfy7bQG9MG3HfjzclDpa1ms5jsnurpOWmGwbTIK qFTwvbST99hFRbXE9fEyvEPewwA3F5ProdpmMNjtvn5eAMPDfuweJY6C/oObDabl 7pWvVnguaiDcfLabwMtrWhQlULqh6LpPw4PJ7l0thH4Q83cWp8aLA0yu1wlKZP3G wQ5pH+961RYHaF9iMpoH3BNd5w3XG7cDXOKqdnvy+VvXf/JYaWks/xycLYW0IYDz 9DqHn5cVUTwzjM7dBY1yqVG2I/AzuRlKH9iEtqaJIlBq+86HeSf8gcybK/H/Dqs5 rxAwxgzn2cRNe99eCJbTmlgr0grCACH9GgwYjXK+fJS29uENheN7Ltx9L0Z5fsLm HBJ0TiMQWH4eAN8kxM4I7ctZhtWgEEptlXQfV+8U93tXcFQAWHjTRL+0GNhNaAFx 7Ozcg1Qr =LZ+R -----END PGP SIGNATURE----- --------------zR7es85qzLzC22mOV3txUPGH-- From nobody Sat Aug 13 19:15:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4qxm2Cnyz4YgLs for ; Sat, 13 Aug 2022 19:15:24 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4qxl4zf9z3nbV; Sat, 13 Aug 2022 19:15:23 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: by mail-ej1-x633.google.com with SMTP id i14so7164100ejg.6; Sat, 13 Aug 2022 12:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc; bh=Pw71qzD0EH/10xVw5e7qdkWujyNU/JCgPdkp5DriXkc=; b=GZP3KODUmV6acEklqM+BFEBOvBsCNHi+iOa/h0OoiLBCuHarKn6Javnm/TEIPOST9O svLiB3wl37Ycm0Fvfg7CegfNH0Uu7TVig4QRL2zkm+bospLA4hIZlOnx041dAnzz/JTc +cbR76Zfx6uSfMm1Sd7NnMAgibRbrD6paq+pSOBVH1ydjSuHB6M56+VMSrHjU0cLltSe hrMLuNwkDb5LwYGjXOMRgfSpOcMf+Ory1i+EFkVs+EQAEislOXxfyomv1qiCArLtseWw cvwd34TAH2iIQX7UzI5KSmfkfM+CjC9JF3mzPrxZu3QC2M2SbS3LYxDvyhtvwz3YZ2nI J4aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:cc:references:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc; bh=Pw71qzD0EH/10xVw5e7qdkWujyNU/JCgPdkp5DriXkc=; b=41XCrsfhqGleqd/hoRDCwj42q491C7TkF+bhWDsTLHbboO4f6kwaGwhTB/gAaDqeHE QWHekZhHOBfypCu2K0VCdxV6yWHjMiaJeLrWpfCUnsxntBUg4I52hDBPjLlINUAP53gH Rp7EBo+QKU5C0sNYFoi37NyJcdhrP5LOMg/MllLVeTah+uVsysfHCdtrsYKITB395ZLk LW6gMo7YRUPEEWBOojEwyWGfLR1OvD68rwjjFriL01y4q06uqYt2TshmpOK5QYfFln9x GyvYzn3op10q5hXQnNAfUStLPkIZgkAXqTkGf0c+c7qwk/E7Gd+trbdm8S9dgFcIByEF m8gg== X-Gm-Message-State: ACgBeo28x6qZHshn9HF3ND30xdJZyH0FAEcXZWk5Im8N5XugGurckyr+ 4SyWwVN6STpe1UqoVapep+5wgwZS8qU= X-Google-Smtp-Source: AA6agR413syPJfW14fwK5QbHyxvlC42RyBhHFOSShRXvb4sIbZ87j3h6MzpDVejAL1qZ5p52YIOgqg== X-Received: by 2002:a17:906:29d:b0:6f0:18d8:7be0 with SMTP id 29-20020a170906029d00b006f018d87be0mr5986205ejf.561.1660418122212; Sat, 13 Aug 2022 12:15:22 -0700 (PDT) Received: from [192.168.0.109] ([91.187.59.126]) by smtp.gmail.com with ESMTPSA id w20-20020aa7da54000000b0043bba5ed21csm3410699eds.15.2022.08.13.12.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 12:15:21 -0700 (PDT) Message-ID: <7229e09b-483c-ed8e-f32b-a89f56587146@gmail.com> Date: Sat, 13 Aug 2022 21:15:19 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: How to monitor a directory in FreeBSD? Content-Language: en-US To: Craig Leres References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> <754a7f6d-8fbe-aae0-796b-e5c0e782fc4f@freebsd.org> Cc: freebsd-hackers From: meator In-Reply-To: <754a7f6d-8fbe-aae0-796b-e5c0e782fc4f@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------n2CL5cbhtXsLDhFM2gojpj5V" X-Rspamd-Queue-Id: 4M4qxl4zf9z3nbV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=GZP3KODU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of meator.dev@gmail.com designates 2a00:1450:4864:20::633 as permitted sender) smtp.mailfrom=meator.dev@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[0.999]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::633:from]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------n2CL5cbhtXsLDhFM2gojpj5V Content-Type: multipart/mixed; boundary="------------7SPXw4eYjTUgoLKPiS0dBm0i"; protected-headers="v1" From: meator To: Craig Leres Cc: freebsd-hackers Message-ID: <7229e09b-483c-ed8e-f32b-a89f56587146@gmail.com> Subject: Re: How to monitor a directory in FreeBSD? References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> <754a7f6d-8fbe-aae0-796b-e5c0e782fc4f@freebsd.org> In-Reply-To: <754a7f6d-8fbe-aae0-796b-e5c0e782fc4f@freebsd.org> --------------7SPXw4eYjTUgoLKPiS0dBm0i Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOC8xMy8yMiAxODo1MSwgQ3JhaWcgTGVyZXMgd3JvdGU6DQo+IA0KPiBUaGUgd2F5IEkn dmUgZG9uZSBpdCBpcyBpcyB0byB1c2UgRVZGSUxUX1ZOT0RFL05PVEVfV1JJVEUgdG8gdGVs bCBtZSANCj4gd2hlbiB0aGUgZGlyZWN0b3J5IGhhcyBjaGFuZ2VkIGFuZCB0aGVuIHJvbGwg bXkgb3duIG9wZW5kaXIoKS9yZWFkZGlyKCkgDQo+IGNvZGUgdG8gZGV0ZWN0IHdoYXQgKGlm IGFueXRoaW5nKSB3YXMgYWRkZWQgb3IgZGVsZXRlZC4NCg0KVGhpcyBsb29rcyBsaWtlIHRo ZSBtb3N0IG5hdHVyYWwgc29sdXRpb24sIGJ1dCBJIHdvdWxkIGhhdmUgdG8ga2VlcCBhbmQg DQpyZW1lbWJlciB0aGUgc3RhdGUgdG8gYmUgYWJsZSB0byB0ZWxsIHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gdGhlIGN1cnJlbnQgDQpzdGF0ZSBhbmQgdGhlIHN0YXRlIGJlZm9yZS4gVGhp cyB3b3VsZCBhZGQgY29tcGxleGl0eSB0byB0aGUgY29kZSwgYnV0IA0KaXQgc2hvdWxkbid0 IGJlIHRoYXQgaGFyZCB0byBpbXBsZW1lbnQgaW4gbXkgdXNlIGNhc2UuIFRoYW5rcyENCg== --------------7SPXw4eYjTUgoLKPiS0dBm0i-- --------------n2CL5cbhtXsLDhFM2gojpj5V Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEew9YpeDxouoRV4pzGhTLNGTL5b8FAmL3+EcACgkQGhTLNGTL 5b+gnAwAi6iE5tjbqTpUmZS62iU7ycQiRRDW+VuWZNAb0s1rdhRJqXFlz14gT8WY FifRZN1mBdqLWHguRLaiKeFpC2aB8+sXRGpdTCCXFd2ZhzifQPbxrX3epa+GKNMn RU/mqVu6grH/dFlmuMpuwIxuxq659fjvQQqCYORyNjY/YdVFc2bQNDA0ySBQAvTv 3o2dI5mxA4nkZfVBa0rNfvW8SH3wTzrKXeIgvn9p8egyGDHlnSfg+vwSXPJAk0Kt A4rEOfY6U+qIK68bcVdIclSZ7KOoLm949RK4ahCjrDRZEuqCYmCu/C/c6CZbn9lQ Tje19AgjdBOgowft8ROhuOqWzybXdqByCzWcOp8ctK8pW0zWnEPkml6RPv1X7x45 55b+tnBiCCHV+t5xup7Lh5a73LaOfs94rDKiZ3vYEELug/+VbJfONM8UPPivuz2u /TYz/lF1P0iCB5Q+yJDOTd9Y01oxaWh7zeMdyXVQHctYKyqbgDtPYxYLO2kkGHpn pMGtGDZ6 =2IJS -----END PGP SIGNATURE----- --------------n2CL5cbhtXsLDhFM2gojpj5V-- From nobody Sat Aug 13 19:19:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4r2J6JVVz4YgZB for ; Sat, 13 Aug 2022 19:19:20 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4r2H4fBmz3pZn for ; Sat, 13 Aug 2022 19:19:19 +0000 (UTC) (envelope-from mgorny@moritz.systems) Received: by mail-wm1-x32e.google.com with SMTP id ay12so2043356wmb.1 for ; Sat, 13 Aug 2022 12:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=moritz-systems.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc; bh=beFs/8MMrZU46L+L5STsiYWPs8mFik1RMW4nyraT3Jo=; b=qWFl64owy4wTbCmwBATDnj3BWqSosBdWJDBd97VqMEs+ud7zCXcgXEXayDiATXoke2 7lLuCldeaKG6hNpEm1Ra8yYZExeSEsGAqp0j7AqZviUQCw/HkDiGAthAd23T9DPOAutz ZLQy+pS7xUhsUXwtAyhx+v4t4OWugpGWVbApEzStpS2RCHSgk/TKPDtfv3bQw/zHgm6p EGPM5ENx7muRWSBe9vls0K7UBViEcNJ1k1ID3wM8Y9NA60SRcBe16RoPGtoloTp4JQVg qWmGShv+DgNzFTiL0ralXBdCTDe/3BNRbsOvi+5bve/U8yyXd5BfTe2bUinnFaX/edix +BiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc; bh=beFs/8MMrZU46L+L5STsiYWPs8mFik1RMW4nyraT3Jo=; b=a9XuH5ej9TxapAk2irCdfHWIaKE1XXY0ZDW5CH/OeR2mbVwOsrAmUsqZwJ0KHSQmji XWy0e1uMvQ4kfT9UH2u/s3+HC0JIdEuKW5Nq6cjUlPCApfBX19/TFfBd67ywhegiw6v0 cDkE+kU1b6bvWJBbdzXA6ujG3dIZAqouiL7lFr64V3RxkaQVYVZFZ+dKZO/07KlQgqja vVwsdNF8TJNCUVdZ7dmUOTiWyqFlNa3uS/Cimk8r5A4rOP8QhZLm2g77nUwYVd0NgpqV tZZ7T2+/YmLyb7IPz5hTMB/xAcHeQ5+Kem2gIvMuh1OY7iKOhfI3DfGtQ2ZOxol5nhyB WwkQ== X-Gm-Message-State: ACgBeo1oQ4Y/NLD1G72q4WYwKBCczK0sQ1j0Wj6GR7+PtTZCwAXccdoH BXehbPAW18JudoUaWNgoxXUREA== X-Google-Smtp-Source: AA6agR7J+ZX2q/7yRN9ObFxY1cRaGf0st1db0MxPGf69r0MyRRtcPBuFcJIprnMmufnusJzl5gRplg== X-Received: by 2002:a05:600c:4f84:b0:3a5:c6b4:e7c9 with SMTP id n4-20020a05600c4f8400b003a5c6b4e7c9mr5955113wmq.149.1660418357871; Sat, 13 Aug 2022 12:19:17 -0700 (PDT) Received: from [192.168.1.1] (c141-88.icpnet.pl. [85.221.141.88]) by smtp.gmail.com with ESMTPSA id h23-20020a05600c145700b003a529b7bc27sm3809541wmi.9.2022.08.13.12.19.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Aug 2022 12:19:17 -0700 (PDT) Message-ID: <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> Subject: Re: How to monitor a directory in FreeBSD? From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: meator , Gleb Popov Cc: freebsd-hackers Date: Sat, 13 Aug 2022 21:19:16 +0200 In-Reply-To: References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4M4r2H4fBmz3pZn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=moritz-systems.20210112.gappssmtp.com header.s=20210112 header.b=qWFl64ow; dmarc=none; spf=softfail (mx1.freebsd.org: 2a00:1450:4864:20::32e is neither permitted nor denied by domain of mgorny@moritz.systems) smtp.mailfrom=mgorny@moritz.systems X-Spamd-Result: default: False [-1.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; R_MIXED_CHARSET(1.00)[subject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[moritz-systems.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[moritz.systems]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[moritz-systems.20210112.gappssmtp.com:+]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32e:from]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On Sat, 2022-08-13 at 21:09 +0200, meator wrote: > On 8/13/22 17:35, Gleb Popov wrote: > >=20 > > Yes, there is no native API to monitor directories. You can use=20 > > libinotify from ports, which replicates Linux inotify API and it does= =20 > > have ability to monitor directories. > >=20 >=20 > I would like to avoid extra dependencies. If I would like to do this,=20 > than I would probably choose FAM of Gamin. The Linux Programming=20 > Interface book references these two as a more cross platform=20 > alternatives to inotify. The program I'm working on should also work on= =20 > Linux. I'm currently want to implement both inotify and kqueue and make= =20 > the preprocessor pick the right one when compiling. >=20 > But I didn't know inotify for BSD exists. This would mean that I=20 > wouldn't have to implement the directory monitoring twice. I'll take=20 > this into consideration. Thanks! I'm afraid I'm going to be a bit of spoilsport but please bear in mind that inotify -- at least on Linux -- is not 100% reliable (or at least it wasn't the last time I've used it). In general, it's a great optimization but your program also needs to have fallback logic to periodically check for changes that weren't reported. --=20 Best regards, Micha=C5=82 G=C3=B3rny From nobody Sat Aug 13 21:10:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M4tVM35Jxz4YTk7 for ; Sat, 13 Aug 2022 21:10:19 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M4tVL39W6z4FKv for ; Sat, 13 Aug 2022 21:10:18 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id o22so5154487edc.10 for ; Sat, 13 Aug 2022 14:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:subject:from:cc:references:to:content-language :user-agent:mime-version:date:message-id:from:to:cc; bh=S0unNOwagkzs4rvGl+xv/5OMi70AyvFuMPleZ2kdN5k=; b=XpdwU457lbn250Daxx55AfCddUgvLzSqBE1PBGZCpeDErcIMepiL9C7lHGAuXOgMqR LAVR8hafLWoCozq0quvQPT8udlvIdBq4TW27B3unArxST6hpjDKAgdbbvY/NYgclIeEj dB04drvM6LA4JdsmKqQ305Cd5O666L/5/szNjrMHcHBlSK4kqMXS9U1B7zbMiIa1/T9b AhdcIIBDLtuC0gZtwZBg8UYULUNYuPP37ffCScrE1lFQmRVMYYlDcY7p3OaeEU96cqcy EYE2S86Aw3sT5heuyBZdNqJRQTXPNioXTLr4JT2yfZIgDTV2RJgBma1ZzAf8NzZTPtFP NhEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:subject:from:cc:references:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc; bh=S0unNOwagkzs4rvGl+xv/5OMi70AyvFuMPleZ2kdN5k=; b=YFDmkDOBlNP9IJsqU2B1u0zj880bj5cTS1/JHLspie1u8HElgTYgcze5j28K1k8/Zw 5gCp1ih+y9N/zdOZwd5AR21MyaALktxdJAprI/VasFl3ltFbsLL+TxR5mzlI4oPBCE+D FddLDqRVQJabIYX3BL3wz9tfBz1TFWepWXrZx3Lii+O/mc6IpzHlC2HQ0OGiq24kNueb AQb2e8VmVuJUB06Y5QxBrcuuDUIbOSN+FNQCGS3duCL8vUedWMoxnSBpPv1LTeypmn09 nrKUDXWBaBAuRQPUrOwbalDvpgYoKG1j4aaP2J0HfiZziAO8y13MjJS2tGEbbQbtI6m9 K7jQ== X-Gm-Message-State: ACgBeo2wbTImD2k5XTAhFcHnJP99wVqLDkLL38AcXzBg1yKGry8GjttS qJSV2zvk727EzqQhnlbyItSvsviiROE= X-Google-Smtp-Source: AA6agR6AEbsRkTxfBjyS8OzabZHrwxkWs7LS6DYTJCo1Sisumr3We+EmSAkUDYcvQKKtPTbce/Rxcw== X-Received: by 2002:a05:6402:f17:b0:43e:4700:f63e with SMTP id i23-20020a0564020f1700b0043e4700f63emr8690850eda.190.1660425017250; Sat, 13 Aug 2022 14:10:17 -0700 (PDT) Received: from [192.168.0.109] ([91.187.59.126]) by smtp.gmail.com with ESMTPSA id gq17-20020a170906e25100b00730e5397057sm2235019ejb.185.2022.08.13.14.10.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 13 Aug 2022 14:10:16 -0700 (PDT) Message-ID: <933211a4-7d87-b7ab-89c6-2b3f0a5b3e26@gmail.com> Date: Sat, 13 Aug 2022 23:10:03 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> Cc: freebsd-hackers From: meator Subject: Re: How to monitor a directory in FreeBSD? In-Reply-To: <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------qrI00ZuZrGNaJdmnuCIasKq7" X-Rspamd-Queue-Id: 4M4tVL39W6z4FKv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=XpdwU457; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of meator.dev@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=meator.dev@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_SPAM_MEDIUM(1.00)[0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_BASE64_TEXT(0.10)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------qrI00ZuZrGNaJdmnuCIasKq7 Content-Type: multipart/mixed; boundary="------------MhkkP8VvlY1FJiJ4X8RB4GPG"; protected-headers="v1" From: meator To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: freebsd-hackers Message-ID: <933211a4-7d87-b7ab-89c6-2b3f0a5b3e26@gmail.com> Subject: Re: How to monitor a directory in FreeBSD? References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> In-Reply-To: <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> --------------MhkkP8VvlY1FJiJ4X8RB4GPG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gOC8xMy8yMiAyMToxOSwgTWljaGHFgiBHw7Nybnkgd3JvdGU6DQo+IA0KPiBJJ20gYWZy YWlkIEknbSBnb2luZyB0byBiZSBhIGJpdCBvZiBzcG9pbHNwb3J0IGJ1dCBwbGVhc2UgYmVh ciBpbiBtaW5kDQo+IHRoYXQgaW5vdGlmeSAtLSBhdCBsZWFzdCBvbiBMaW51eCAtLSBpcyBu b3QgMTAwJSByZWxpYWJsZSAob3IgYXQgbGVhc3QNCj4gaXQgd2Fzbid0IHRoZSBsYXN0IHRp bWUgSSd2ZSB1c2VkIGl0KS4gIEluIGdlbmVyYWwsIGl0J3MgYSBncmVhdA0KPiBvcHRpbWl6 YXRpb24gYnV0IHlvdXIgcHJvZ3JhbSBhbHNvIG5lZWRzIHRvIGhhdmUgZmFsbGJhY2sgbG9n aWMgdG8NCj4gcGVyaW9kaWNhbGx5IGNoZWNrIGZvciBjaGFuZ2VzIHRoYXQgd2VyZW4ndCBy ZXBvcnRlZC4NCj4gDQoNClllYWggeWVhaCwgSSByZWFkIGlub3RpZnkoNyksIEkga25vdyB0 aGF0IHRoZSBxdWV1ZSBjYW4gb3ZlcmZsb3csIGV2ZW50cyANCmNhbiBiZSBsb3N0LCBpdCBj YW4gY29sbGFwc2UgZXZlbnRzIHdoZW4gdGhleSBhcmUgaWRlbnRpY2FsLCB0aGVyZSBhcmUg DQpsaW1pdHMsIHRoZSBmaWxlc3lzdGVtIG1pZ2h0IG5vdCBzdXBwb3J0IGlub3RpZnksIHRo ZSBmaWxlcyBvciB0aGUgDQptb25pdG9yZWQgZGlyZWN0b3J5IGl0c2VsZiBjb3VsZCBiZSBz eW1saW5rcyBvciBjYW4gaGF2ZSBhIHN5bWxpbmsgaW4gDQppdHMgcGF0aCB3aGljaCBjYW4g YmUgYnJva2VuLCBjYW4gY3ljbGUgYW5kIGNhbiBjYXVzZSBzZWN1cml0eSANCnZ1bG5lcmFi aWxpdGllcywgdGhlcmUgY2FuIGJlIG1vdW50cG9pbnRzIGludm9sdmVkIHdoaWNoIGJlaGF2 ZSANCmRpZmZlcmVudGx5IHRoYW4gZXZlcnl0aGluZyBlbHNlLCB0aGVyZSBjYW4gYmUgcGVy bWlzc2lvbiBpc3N1ZXMsIHNvbWUgDQpzeXNjYWxscyBjYW4gYnlwYXNzIHNvbWUgbW9uaXRv cmluZywgdGhhdCBoYW5kbGluZyByZW5hbWluZyBvZiBmaWxlcyBhbmQgDQpkaXJlY3Rvcmll cyBpcyBoZWxsLi4uDQo= --------------MhkkP8VvlY1FJiJ4X8RB4GPG-- --------------qrI00ZuZrGNaJdmnuCIasKq7 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEew9YpeDxouoRV4pzGhTLNGTL5b8FAmL4EysACgkQGhTLNGTL 5b//agv9EsuolPhZXmmD8o9pR36bxMq+V/AhaHqM7Kjq2lnyGVwgl96XSbLh3J01 aFYTw/AJALa7XtrLkXiFV8qajwny6LYbrsBB0fjwcckn7DsUw0R4z8SGxza/f+TY NHKgudpqVi0x6XTjcGhO9TuATgCH+e385w2eS2nHIvK8MjgWz+diCfZvx1ZPpsf2 YkG7oBVvD4/hgkEhRc9/r7ks6GQLuYLCZ7ZlaOxJBvXzfCaD/jlsShcNSIG2ueU5 LDNFuAvxyy4Ebds3yXPrEfIUHNT4YOsAO9hBc6h0z+so27+jpvxpnBoZdK4WG4x6 u61iaHoJ+AbW+ID8ximcXa1ecqMwKqgq8yDk7anatGt0TPzcgdeZ/MsihcBKDCjh WJdFinOxR5txuKXT821Fwx3qufkEDg3rXkwM4J0y/MeS5iCuMugcem9Fknl9JBjh d+dxiEFcfpync+PkBkJxAGC6Vq0s6UvWJU8Yp4slZA/QqFLAaTRfyW5RxX0vCQVE f8CXJaFt =mbaA -----END PGP SIGNATURE----- --------------qrI00ZuZrGNaJdmnuCIasKq7-- From nobody Sun Aug 14 06:00:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M56H7535mz4Z4yV for ; Sun, 14 Aug 2022 06:01:23 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: from mx1.101011010.xyz (mx1.101011010.xyz [94.130.97.216]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mx1.101011010.xyz", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M56H72LPhz3MZv; Sun, 14 Aug 2022 06:01:22 +0000 (UTC) (envelope-from zeus@ibs.dn.ua) Received: by mx1.101011010.xyz with ESMTPS id 27E61I3n053348 on Sun, 14 Aug 2022 09:01:20 +0300 (EEST) DKIM-Signature: v=1;a=rsa-sha256;d=ibs.dn.ua;s=mail;c=relaxed/relaxed; q=dns/txt; h=From:From:Reply-To:Reply-To:Subject:Subject:Date:Date:To:Cc:Resent-Date :Resent-From:Resent-To:Resent-Cc:In-Reply-To:References:List-Id:List-Help :List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aQyriOXw/KAddV0wJhfIVYFHK/+5k4Z1d5wW91n+AKM=; b=NeQw4XQcMqwj+MTROoCEoxIm0jUzNn0W5/iilp5LZWqJp/dAuN3lp5UnNFPswMSsbgn3lsYnuFwL 3bth5UjgJ9qHvmXA2xZ3ZR4hp0JXjGm7OilztWoGKpC6rkEZzVnQXoe2HyOZQyMyDhZL3VzVFNGyFV Kad4urbea5YJfnGkNuXSgPcLre7Y4O9bdhUsXfwHZel66109nsEB9ySC7pX4Sa1lSoYXPBEwuCJ0g8 HHXvPrrUOsJaXBMaIsAhxBon3wZgvca6rzeqNTCzJFNPV+G/WvpBGvn5GQEwYzl3prn7ZKRm/g6wVa oiYbstZy+Aj8otl1A/f81cE+6tDRH5GQ==; Received: on behalf of honored client by relay.xx with ESMTPS id 27E60IZT068724 on Sun, 14 Aug 2022 09:00:19 +0300 (EEST) From: "Zeus Panchenko" To: "=?us-ascii?Q?=3D=3FUTF-8=3FQ=3FMicha=3DC5=3D82=5FG=3DC3=3DB3rny=3F=3D?=" Cc: "meator" , "Gleb Popov" , "freebsd-hackers" Subject: Re: How to monitor a directory in FreeBSD? In-reply-to: Your message of Sat, 13 Aug 2022 21:19:16 +0200 <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> References: <652f3c12-388c-04d0-ebeb-753b76b2b742@gmail.com> <0cb00216675d883162148e6dc1e0b90c4c8be5f2.camel@moritz.systems> Organization: I.B.S. LLC Reply-To: "Zeus Panchenko" X-Attribution: zeus Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWxsbGdnZ3U1NQTExN cXFzx8fG/v7+f8hyWAAACXUlEQVQ4jUWSwXYiIRBFi4yyhtjtWpmRdTL0ZC3TJOukDa6Rc+T/P2F eFepwtFvr8upVFVDua8mLWw6La4VIKTuMdAPOebdU55sQs3n/D1xFFPFGVGh4AHKttr5K0bS6g7N ZCge7qpVLB+f1Z2WAj2OKXwIWt/bXpdXSiu8KXbviWkHxF5td9+lg2e3xlI2SCvatK8YLfHyh9lw 15yrad8Va5eXg4Llr7QmAaC+dL9sDt9iad/DX3OKvLMBf+dm0A0QuMrTvYIevSik1IaSVvgjIHt5 lSCG2ynNRpEcBZ8cgDWk+Ns99qzsYYV3MZoppWzGtYlTO9+meG6m/g92iNO9LfQB2JZsMpoJs7QG ku2KtabRK0bZRwDLyBDvwlxTm6ZlP7qyOqLcfqtLexpDSB4M0H3I/PQy1emvjjzgK+A0LmMKl6Lq zlqzh0VGAw440F6MJd8cY0nI7wiF/fVIBGY7UNCAXy6DmfYGCLLI0wtDbVcDUMqtJLmAhLqODQAe riERAxXJ1/QYGpa0ymqyytpKC19MNXHjvFmEsfcHIrncFR4xdbYWgmfEGLCcZokpGbGj1egMR+6M 1BkNX1pDdhPcOXpAnAeLQUwQLYepgQoZVNGS61yaE8CYA7gYAcWKzwGstACY2HTFvvOwk4FXAG/a mKHni/EcA/GkOk7I0IK7UMIf3+SahU8/FJdiE7KcuWdM3MFocUDEEIX9LfJoo4xV5tnNKc3jJuSs SZWgnnhepgU1zN4Hii18yW4RwDX52CXUtk0Hqz6cHOIUkWaX8fDcB+J7y1y2xDHwjv/8Buu8Ekz6 7tXQAAAAASUVORK5CYII= X-Mailer: MH-E 8.6+git; nil; GNU Emacs 27.2 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Aug 2022 09:00:18 +0300 Message-ID: <20220814090018.68722@relay.xx> User-Agent: MH (GNU Mailutils 3.15) X-Relay-Agent: mailfromd (8.13) X-Relay-URL: https://mx1.101011010.xyz/smtp.html X-Relay-VirStat: UNCHECKED X-Relay-SpamStat: NO X-Relay-SpamScore: -2.300 of 3.500 X-Relay-SpamKeys: AWL,BAYES_00,NO_RECEIVED,NO_RELAYS,T_SCC_BODY_TEXT_LINE X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M56H72LPhz3MZv X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; local_wl_ip(0.00)[94.130.97.216] X-ThisMailContainsUnwantedMimeParts: N may be, try to look on sysutils/direvent Micha=C5=82 G=C3=B3rny wrote: > On Sat, 2022-08-13 at 21:09 +0200, meator wrote: > > On 8/13/22 17:35, Gleb Popov wrote: > > >=20 > > > Yes, there is no native API to monitor directories. You can use=20 > > > libinotify from ports, which replicates Linux inotify API and it does= =20 > > > have ability to monitor directories. > > >=20 > >=20 > > I would like to avoid extra dependencies. If I would like to do this,=20 > > than I would probably choose FAM of Gamin. The Linux Programming=20 > > Interface book references these two as a more cross platform=20 > > alternatives to inotify. The program I'm working on should also work on= =20 > > Linux. I'm currently want to implement both inotify and kqueue and make= =20 > > the preprocessor pick the right one when compiling. > >=20 > > But I didn't know inotify for BSD exists. This would mean that I=20 > > wouldn't have to implement the directory monitoring twice. I'll take=20 > > this into consideration. Thanks! >=20 > I'm afraid I'm going to be a bit of spoilsport but please bear in mind > that inotify -- at least on Linux -- is not 100% reliable (or at least > it wasn't the last time I've used it). In general, it's a great > optimization but your program also needs to have fallback logic to > periodically check for changes that weren't reported. >=20 > --=20 > Best regards, > Micha=C5=82 G=C3=B3rny >=20 >=20 >=20 <#secure method=3Dpgp mode=3Dsign sender=3D0FF7A32A> --=20 Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) From nobody Mon Aug 15 14:23:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M5xNK14zsz4Z6Hl for ; Mon, 15 Aug 2022 14:23:45 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (2a02-a44b-36d-100--2.fixed6.kpn.net [IPv6:2a02:a44b:36d:100::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M5xNJ1KxMz3fZh for ; Mon, 15 Aug 2022 14:23:44 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 766C44081B for ; Mon, 15 Aug 2022 16:23:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UtHsiOMsdLp9 for ; Mon, 15 Aug 2022 16:23:35 +0200 (CEST) Received: by gvr.gvr.org (Postfix, from userid 657) id 3CD2340408; Mon, 15 Aug 2022 16:23:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20220114; t=1660573415; bh=ByZtsfNI/ohyo92PRdA3a6C7mNmcAG8gHc75h8/w9hw=; h=Date:From:To:Subject; b=TxbqZNYhBj9gH6ezRoSX+CNpenngJiiL2svOwGnAKbqKc516/n3dWpdlpNgCk5LIX yvsV/y4gsoXQ1OEGHSspc32VuMgziqa1CF27r64ruryh0/S93neUpg5Z0ZloBF+4EA gFuA2qgpStpEUWLQyqdpt5FBgQIJdNZoIdLy83IGY5CNM3atSqAjYg4vNFG3HUHwf7 hovpOk/0o+DA6Gn+XLdozYz9/tIjwWs0Reiw+Q7xWL0O5+CoEYg/o+7XeJbIlmx9QM /85HsnnY5XmoZFcFlYi4g3bCo2WAHTWZfLq7A9GW+N7CNQ8V95hkDgdtF6uxxa+E8z 03tk4oPHAdOOQ== Date: Mon, 15 Aug 2022 16:23:35 +0200 From: Guido van Rooij To: freebsd-hackers@freebsd.org Subject: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4M5xNJ1KxMz3fZh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20220114 header.b=TxbqZNYh; dmarc=pass (policy=none) header.from=gvr.org; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 2a02:a44b:36d:100::2 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gvr.org,none]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20220114]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[gvr.org:+]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[guido]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:1136, ipnet:2a02:a400::/25, country:NL] X-ThisMailContainsUnwantedMimeParts: N Currently I have a system with ZFS on GELI. I use the ability in the EFI loader to enter the GELI password. Is it possible somehow to use a serial console to enter the password? My system does have a COM1 port but it isn't recognised at the early bot stage. There I only see: Consoles: EFI console GELI Passphrase for disk0p4: (Note: this is early in the boot process so there is no access to boot.config (or any other file in the ZFS pool) as it still on encrypted storage at that time). Regards, -Guido From nobody Mon Aug 15 20:20:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M65JF13Stz4Yp6N for ; Mon, 15 Aug 2022 20:20:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M65JD3vFKz3R94 for ; Mon, 15 Aug 2022 20:20:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id b124so8228537vsc.9 for ; Mon, 15 Aug 2022 13:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=GCPW5VHwDIkjiKg8ON+OPKlEdxP3Fz2v8xHwtohHHtc=; b=zvJHV7B2eWLU3Qelq3tR4pGyky5gHuS2SCtqy+g5I73O9Icu2U3lIy5gOk1rxvUIKp DvX02iVVdzAsA4dpXvTq735KAR5Eq65SanRtgRMFbSP51ybNWCVWqx+d9fGigPPzLFFe ysPawrMp5LaLpwo0z6shtaqpAgBsV8orJbjGreKCFW5fFX+0PAzlxnTTfIED84t+8LeM Fab6CojDeMTbgNh8SNpM9lgFmOw6HqaJuls4+wLlIU5UbvpeHYt0LlRAAHc513c1n2xO 7vlmfPYy9dZAeSmBKX1iRDQAul5RFtBXpDh/fKuhvdMkQO0zat/T/yt96gKfr2wgohP4 G1Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=GCPW5VHwDIkjiKg8ON+OPKlEdxP3Fz2v8xHwtohHHtc=; b=UwbAVa7tNiVxY3QFhke/U4/2wfMfxYlKIZe3Bj/tcb8VU0rTgB6V4lGw12uH2ugfuc sJwWTrooAIizbpSyoOSYshQo13gCGLNdFcma9X8DHZL2/jq+3LU1ozVP2s8r8eSg5rwZ 8ttphODqRzgnvGwExtJOuLXJMQjEKM7lZfmerCIo0oqCwcBK2gzTg3Gt1bObbDLn9lwd pJXh3LFzWF/49i2wYs8PnpnSubxFxZpi4e1Y/WF+CFa2dt/2IXthZcgQNb8kLobmozHH hIV+h8D1U0fw0HSOupF1aPgOu6vC18QfkEQYPBhIlZLBGLIL45DuCMq/dRAUAYfMlmS4 NXRA== X-Gm-Message-State: ACgBeo0oxuSlh7U30C1I23WBR9ylNXyq8eQl7FuSVQXpOaVAuadnvcUw wILFltNrcgwdkjb2lU8LQSRPVlSONsFERsdaKhigOcTcgxTlLw== X-Google-Smtp-Source: AA6agR7inyMpUFDHOFtR4diuraUhUgxV3QKpslsGAFqcEoa9SBjHEw55hOMSji8cTF7Us87+ySNI2jQpOV109kh6FSk= X-Received: by 2002:a67:b208:0:b0:357:e999:441c with SMTP id b8-20020a67b208000000b00357e999441cmr6662502vsf.67.1660594843682; Mon, 15 Aug 2022 13:20:43 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 15 Aug 2022 14:20:32 -0600 Message-ID: Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool To: Guido van Rooij Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000c61b1305e64d5de3" X-Rspamd-Queue-Id: 4M65JD3vFKz3R94 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=zvJHV7B2; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2a) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2a:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000c61b1305e64d5de3 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij wrote: > Currently I have a system with ZFS on GELI. I use the ability in > the EFI loader to enter the GELI password. > > Is it possible somehow to use a serial console to enter the password? > My system does have a COM1 port but it isn't recognised at the early > bot stage. There I only see: > > Consoles: EFI console > GELI Passphrase for disk0p4: > > (Note: this is early in the boot process so there is no access to > boot.config (or any other file in the ZFS pool) as it still on > encrypted storage at that time). > The boot loader.efi will read ESP:/efi/freebsd/loader.env for environment variables. You can use that to set the COM1 port since it appears your EFI system doesn't do console redirection. If you want it to only prompt COM1 for the password, but everything else is on the efi console, that's a lot harder. Warner --000000000000c61b1305e64d5de3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Aug 15, 2022 at 8:23 AM Guido= van Rooij <guido@gvr.org> wrote= :
Currently I ha= ve a system with ZFS on GELI. I use the ability in
the EFI loader to enter the GELI password.

Is it possible somehow to use a serial console to enter the password?
My system does have a COM1 port but it isn't recognised at the early bot stage. There I only see:

=C2=A0 =C2=A0 Consoles: EFI console
=C2=A0 =C2=A0 GELI Passphrase for disk0p4:

(Note: this is early in the boot process so there is no access to
boot.config (or any other file in the ZFS pool) as it still on
encrypted storage at that time).

The bo= ot loader.efi will read ESP:/efi/freebsd/loader.env for environment
variables. You can use that to set the COM1 port since it appears your
EFI system doesn't do console redirection.

If you want it to only prompt COM1 for the password, but everything e= lse is
on the efi console, that's a lot harder.
Warner
--000000000000c61b1305e64d5de3-- From nobody Tue Aug 16 04:43:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6JT16zRMz4ZMhX for ; Tue, 16 Aug 2022 04:44:05 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resqmta-c1p-024061.sys.comcast.net (resqmta-c1p-024061.sys.comcast.net [IPv6:2001:558:fd00:56::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6JT06zFbz3Tq6 for ; Tue, 16 Aug 2022 04:44:04 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resomta-c1p-023413.sys.comcast.net ([96.102.18.230]) by resqmta-c1p-024061.sys.comcast.net with ESMTP id NoLPoReQUmYliNoQootVl1; Tue, 16 Aug 2022 04:43:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1660625038; bh=HbczTSICiwjDup+DryEvj8GIaAyw2wResQdldJIl+xg=; h=Received:Received:From:Content-Type:Mime-Version:Subject: Message-Id:Date:To; b=MHj2YZ/jQf7gJljR7BHpdRL6/tENfyDsFr/s3lE01mVYJ3/rJmpx1+7qUWF+p2MAH ICsKmu4UVteUDllXM1wa0NM2QfJ9znpiNlqVm4FSGhSgGBCteZnOPy288BA723qizt 2BJvi3PQJPuW0NgziJ1Rzt/MjYjHRDLfgD2k0mUmnjXBAbKDo8tK4JgUNyz47h6veP btin0A1wLwdlskFfX1pi44l6LNjkj7uGGKhzXqCZkEvsMDij4uhbtz0huzKuFUZtJR RsEhl+smEsnVjxXlHQF5mEhLq+NHaFIaV8w0aL6eTBeMeA/JHzXYKsmO9lhwY2sLyd vwrm+TRvn8pgQ== Received: from smtpclient.apple ([71.231.182.61]) by resomta-c1p-023413.sys.comcast.net with ESMTPA id NoQNoiJjMk1I5NoQToezle; Tue, 16 Aug 2022 04:43:37 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehfedgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucfhohhrghgvugcujffvvffrufculdegtddmnecujfgurhephfgtggfukfffvffosegrtdhmrehhtddvnecuhfhrohhmpeetlhgvgicutehrshhlrghnuceorghrrghrshhlrghnsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedtudeuleegieeihfdvveejkeeuieejvefhlefgtdfgkeejvdeutedvgeeiudetffenucffohhmrghinheptghouggvtghovhdrtghomhdptghirhhruhhsqdgtihdrtghomhdptghouggvtghovhdrihhonecukfhppeejuddrvdefuddrudekvddriedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepshhmthhptghlihgvnhhtrdgrphhplhgvpdhinhgvthepjedurddvfedurddukedvrdeiuddpmhgrihhlfhhrohhmpegrrhgrrhhslhgrnhestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepuddprhgtphhtthhopehfrhgvvggsshguqdhhrggtkhgvrhhssehfrhgvvggsshgurdhorhhg X-Xfinity-VMeta: sc=40.00;st=legit From: Alex Arslan Content-Type: multipart/alternative; boundary="Apple-Mail=_A0DC7288-A16A-495D-BF8A-B0588787FBDF" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Hang in futex wait with a Node.js binary in Linuxulator Message-Id: <16777BDC-22D3-4ACC-95E8-95933D587341@comcast.net> Date: Mon, 15 Aug 2022 21:43:29 -0700 To: "freebsd-hackers@freebsd.org" X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4M6JT06zFbz3Tq6 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b="MHj2YZ/j"; dmarc=pass (policy=none) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of ararslan@comcast.net designates 2001:558:fd00:56::6 as permitted sender) smtp.mailfrom=ararslan@comcast.net X-Spamd-Result: default: False [0.99 / 15.00]; HFILTER_HELO_5(3.00)[resqmta-c1p-024061.sys.comcast.net]; URI_COUNT_ODD(1.00)[11]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,none]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-0.41)[-0.415]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd00:56::/64]; RCVD_IN_DNSWL_LOW(-0.10)[96.102.18.230:received]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[comcast.net]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[comcast.net:+]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[comcast.net]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A0DC7288-A16A-495D-BF8A-B0588787FBDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, I'm trying to run the Linux binary for Codecov's official coverage = uploader (https://docs.codecov.com/docs/codecov-uploader = ) on FreeBSD via = Linuxulator. It's a statically compiled Node.js application built with = the Node.js package called pkg. The application's own verbose logging = shows that it completes, but the process just hangs indefinitely, using = 0 CPU and not letting go of its memory. With devel/linux-c7-strace, it = appears it's getting stuck on: futex(0x8427f1b70, FUTEX_WAIT_PRIVATE, 2, NULL Too stuck to even finish printing the argument list or closing = parenthesis, apparently! A Cirrus CI build log where I set the process = to terminate via timeout is available at = https://cirrus-ci.com/task/6610515924353024 = but it's actually = reproducible for me locally with just curl -O https://uploader.codecov.io/latest/linux/codecov chmod +x codecov ./codecov -h Does anyone have any advice for how to debug this further? Thanks, Alex= --Apple-Mail=_A0DC7288-A16A-495D-BF8A-B0588787FBDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = folks,

I'm trying to = run the Linux binary for Codecov's official coverage uploader (https://docs.codecov.com/docs/codecov-uploader) on = FreeBSD via Linuxulator. It's a statically compiled Node.js application = built with the Node.js package called pkg. The application's own verbose = logging shows that it completes, but the process just hangs = indefinitely, using 0 CPU and not letting go of its memory. With = devel/linux-c7-strace, it appears it's getting stuck on:

futex(0x8427f1b70, = FUTEX_WAIT_PRIVATE, 2, NULL

Too stuck to even finish printing the argument list or = closing parenthesis, apparently! A Cirrus CI build log where I set the = process to terminate via timeout is available at https://cirrus-ci.com/task/6610515924353024 but it's = actually reproducible for me locally with just

curl = -O https://uploader.codecov.io/latest/linux/codecov
chmod +x codecov
./codecov -h

Does anyone have any advice for how to debug this = further?

Thanks,
Alex
= --Apple-Mail=_A0DC7288-A16A-495D-BF8A-B0588787FBDF-- From nobody Tue Aug 16 06:51:55 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6MJc4Fxtz4ZfWs for ; Tue, 16 Aug 2022 06:52:00 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6MJb5SLTz3dY7 for ; Tue, 16 Aug 2022 06:51:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: (Authenticated sender: andriy.gapon@uabsd.com) by mail.gandi.net (Postfix) with ESMTPSA id 2B99FE0008 for ; Tue, 16 Aug 2022 06:51:56 +0000 (UTC) Message-ID: Date: Tue, 16 Aug 2022 09:51:55 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.12.0 Content-Language: en-US To: hackers@FreeBSD.org From: Andriy Gapon Subject: different console settings for loader[.efi] and kernel Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4M6MJb5SLTz3dY7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::224 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::224:from]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[avg]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_DN_NONE(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N It seems that console variable in loader.conf affects both the OS/kernel and the loader itself. Is there a way to have different console settings between those? Let me explain. I have a system that I access in several different ways: via its physical serial console, via IPMI / iKVM, and sometimes via its physical video console. console is set to "comconsole, efi". The system uses EFI boot. The BIOS is configured to "redirect" video console to serial and to stop the redirection once an OS starts. The setup works fine before the loader (e.g., for entering BIOS settings) and it works fine once the kernel starts. But while in the loader, every character printed gets doubled on the serial console. I guess that this is because the loader prints it to both the serial output and the EFI output while the BIOS still redirects the EFI output to the serial. I would like to solve that double printing while keeping both the serial console and the video / EFI console usable. So, one way would be for the loader to use only the EFI console and let the BIOS redirect take care of the serial. I guess that another way would be for the loader to announce itself as an "OS" (whatever that technically means), so that the BIOS stops its redirection. Thank you. -- Andriy Gapon https://standforukraine.com https://razomforukraine.org From nobody Tue Aug 16 09:44:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6R8G1CLWz4YZMZ for ; Tue, 16 Aug 2022 09:45:02 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (81-206-207-166.fixed.kpn.net [81.206.207.166]) (using TLSv1.3 with cipher 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 "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6R8F2dxpz3vZB for ; Tue, 16 Aug 2022 09:45:00 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 7ABF54086B; Tue, 16 Aug 2022 11:44:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RLp1d-B8UCX6; Tue, 16 Aug 2022 11:44:53 +0200 (CEST) Received: by gvr.gvr.org (Postfix, from userid 657) id 39A1640869; Tue, 16 Aug 2022 11:44:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20220114; t=1660643093; bh=tYEoldwuPl9OVomUA9vaurFRyGd7yeWMPaAtH3UVjbM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XNmZdg6giAmSS0O/TvgfzXx0g15G9I9hg6a9NYQSGxU6/LD+R7JBwQ60KI83PQPt+ 477JABOjcLLRv+kv9yj0RiI3n05BfHhadwery8F3enuW7xjQ/OBwMVDc8+HLPlxX9D Lj1Or4vNz1UDleex4PUqnwe45EcH7/UFMd+oV8Xl3GGVFCdMyv1ryAhLVk8SQr8jsx niAxoIUBaqSo50fdefoYDg/De0XI/YujNGICtBSEhLOWnnaMnf8ihjISuRJmRdemsB xNMKpAuSDzCVhcXiBEtNhsnxyFsTDqwNbyungy8JhXWDpMr2g51AMJg1+RaxfPEkaf ++LXXClXQIoTw== Date: Tue, 16 Aug 2022 11:44:53 +0200 From: Guido van Rooij To: Warner Losh Cc: FreeBSD Hackers Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4M6R8F2dxpz3vZB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20220114 header.b=XNmZdg6g; dmarc=pass (policy=none) header.from=gvr.org; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 81.206.207.166 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gvr.org,none]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20220114]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[guido]; DKIM_TRACE(0.00)[gvr.org:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:1136, ipnet:81.204.0.0/14, country:NL] X-ThisMailContainsUnwantedMimeParts: N On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: > On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org> > wrote: > > Currently I have a system with ZFS on GELI. I use the ability in > the EFI loader to enter the GELI password. > Is it possible somehow to use a serial console to enter the > password? > My system does have a COM1 port but it isn't recognised at the early > bot stage. There I only see: > Â Â Consoles: EFI console > Â Â GELI Passphrase for disk0p4: > (Note: this is early in the boot process so there is no access to > boot.config (or any other file in the ZFS pool) as it still on > encrypted storage at that time). > > The boot loader.efi will read ESP:/efi/freebsd/loader.env for > environment > variables. You can use that to set the COM1 port since it appears your > EFI system doesn't do console redirection. > If you want it to only prompt COM1 for the password, but everything > else is > on the efi console, that's a lot harder. Hi Warner, Thanks, but somehow I still cannot get it to work properly. Content of /efi/freebsd/loader.env: boot_multicons="YES" console="efi comconsole" The boot prompt still only shows "Consoles: EFI console". When I boot I get the GELI passphrase prompt at the EFI console only. But when the kernel starts to run I do get output to the serial console, staring with: ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. So it seems the loader.env file is read correctly (it didn't output anything to the serial console before I created efi/freebsd/loader.env). But looking at the source I see in efi/loader/main.c:read_loader_env(): if (fn) { printf(" Reading loader env vars from %s\n", fn); parse_loader_efi_config(boot_img->DeviceHandle, fn); } I never saw the printf appearing. I do not understand this. Hope you can help me further! Regards, -Guido From nobody Tue Aug 16 16:52:00 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6cd936X5z4Yrc8 for ; Tue, 16 Aug 2022 16:52:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6cd85Nk7z3h73 for ; Tue, 16 Aug 2022 16:52:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2f.google.com with SMTP id v128so10701027vsb.10 for ; Tue, 16 Aug 2022 09:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=PojUpjcedcMu4ZChsEqfJrGFb5KGMnNGtMnsiIjG/ws=; b=1kbXIpyYo0n7N3qP9ZlgrcEZcSgBkvZKLkdb3/urVO10UBOhmtJh8L8FFlJVwqgexx iH8s0wVfL1P4MseEYk0dxpw55tqPB5dUaf3DGYlp7QgV7sl7IuwVIrTBn1C3/NCox4lb Mm2yUyHBumJgk9H8lrFH80eA9t3uVzuXkyPk8SclSTgtLkFwY4lqLaEd+8z8kyAtElQk bwEwOcq2CF6NsZPP1UV5s3eqSAPVn0FDX15pqJHzjtUHuvyVN6G0hLNRsvH2LXG+4gZA Vhxi3mN9x+jclko4V6wYaN71WQ1UC40z06Fusv/02tTCCkQ2W7cZG/dG8UCca49tUlmi A2aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=PojUpjcedcMu4ZChsEqfJrGFb5KGMnNGtMnsiIjG/ws=; b=0HnyFEGU+44a5ufhzfjDeJdDXJWMhutZNqWpkTGouYu0dB1t+IkGcHoxqkocmSq96T f9fgeGyIZItzO4aa09AHQOvDwg5BiFLnOPaO076Kp0cNI7U0JaHdceE5C4bB8GQZrTm+ tLC8q7bHYkdT4ZubH62qzGCwobogyF0R7o85vgPu7Co+WaVz60yc48XOfDwtRexMM+Dv LJ1Cy4fqMV44z0o+NqMWtidwLvhJQ9LdcGPHhVTSlwSMCDvO+QJ+IF4WZ25ChGRi/yhg YbQaY/HTZFjaYBXQiBYl4smp3J9p/R692M6nqabCdCBzxCRXLsZDxrJeXHDT1thQxZtC Qn4w== X-Gm-Message-State: ACgBeo3xoRBoA3hPTJzV0YBh7iDLs7wsMtPWwnBfRb+FacwabAShblAt oXu5tj9hY8uYIzlYRlgKPaM+jO7uMKLyA92VCudxLA== X-Google-Smtp-Source: AA6agR79dahLfmCIZk7Jg1CixWxaRwIVyKvP5KxxHgov+KfpoQfPLutTQugLZYTfUneYNxXl45VcXDi/tx/rSH4NAHo= X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id n5-20020a67ac45000000b00388a1ff7e89mr9373642vsh.42.1660668731788; Tue, 16 Aug 2022 09:52:11 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 16 Aug 2022 10:52:00 -0600 Message-ID: Subject: Re: different console settings for loader[.efi] and kernel To: Andriy Gapon Cc: "freebsd-hackers@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000d9246c05e65e91f7" X-Rspamd-Queue-Id: 4M6cd85Nk7z3h73 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=1kbXIpyY; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000d9246c05e65e91f7 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 16, 2022 at 12:52 AM Andriy Gapon wrote: > > It seems that console variable in loader.conf affects both the OS/kernel > and the loader itself. Is there a way to have different console > settings between those? > Yes. > Let me explain. I have a system that I access in several different > ways: via its physical serial console, via IPMI / iKVM, and sometimes > via its physical video console. > console is set to "comconsole, efi". > The system uses EFI boot. > The BIOS is configured to "redirect" video console to serial and to stop > the redirection once an OS starts. > > The setup works fine before the loader (e.g., for entering BIOS > settings) and it works fine once the kernel starts. > But while in the loader, every character printed gets doubled on the > serial console. I guess that this is because the loader prints it to > both the serial output and the EFI output while the BIOS still redirects > the EFI output to the serial. > Yes. You've told it to have two consoles, and when they are the same hardware you'll get that doubling. > I would like to solve that double printing while keeping both the serial > console and the video / EFI console usable. > Double printing is trivial to fix: Don't add 'comconsole' to the consoles. EFI loader uses the generic console facilities. So when it's doing redirect, just set it to EFI. > So, one way would be for the loader to use only the EFI console and let > the BIOS redirect take care of the serial. > console=efi does exactly that on my systems. > I guess that another way would be for the loader to announce itself as > an "OS" (whatever that technically means), so that the BIOS stops its > redirection. > Now, having said that, there's one issue with EFI. EFI specifies the UID which the boot loader can't decode into an address, and the current kernel doesn't verify the address is correct, nor can it use this UID to do cninit (because ACPI isn't brought up enough to find the address yet). In those cases, you'll need to use an additional environment variable from the loader: hw.uart.console="io:1016,br:115200" this sets the port to 0x3f8 for the kernel, but the loader won't do anything with it. The kernel will. Warner --000000000000d9246c05e65e91f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 16, 2022 at 12:52 AM Andr= iy Gapon <avg@freebsd.org> wro= te:

It seems that console variable in loader.conf affects both the OS/kernel and the loader itself.=C2=A0 Is there a way to have different console
settings between those?

Yes.
= =C2=A0
Let me explain.=C2=A0 I have a system that I access in several different ways: via its physical serial console, via IPMI / iKVM, and sometimes
via its physical video console.
console is set to "comconsole, efi".
The system uses EFI boot.
The BIOS is configured to "redirect" video console to serial and = to stop
the redirection once an OS starts.

The setup works fine before the loader (e.g., for entering BIOS
settings) and it works fine once the kernel starts.
But while in the loader, every character printed gets doubled on the
serial console.=C2=A0 I guess that this is because the loader prints it to =
both the serial output and the EFI output while the BIOS still redirects the EFI output to the serial.

Yes. You&= #39;ve told it to have two consoles, and when they are the same hardware
you'll get that doubling.
=C2=A0
I would like to solve that double printing while keeping both the serial console and the video / EFI console usable.

=
Double printing is trivial to fix: Don't add 'comconsole' = to the consoles. EFI loader
uses the generic console facilities. = So when it's doing redirect, just set it to EFI.
=C2=A0
=
So, one way would be for the loader to use only the EFI console and let the BIOS redirect take care of the serial.

<= div>console=3Defi does exactly that on my systems.
=C2=A0
I guess that another way would be for the loader to announce itself as
an "OS" (whatever that technically means), so that the BIOS stops= its
redirection.

Now, having said that, the= re's one issue with EFI. EFI specifies the UID
which the boot= loader can't decode into an address, and the current kernel
= doesn't verify the address is correct, nor can it use this UID to do cn= init
(because ACPI isn't brought up enough to find the addres= s yet). In those cases,
you'll need to use an additional envi= ronment variable from the loader:

hw.uart.console= =3D"io:1016,br:115200"

this sets the por= t to 0x3f8 for the kernel, but the loader won't do anything with it.
The kernel will.

Warner
--000000000000d9246c05e65e91f7-- From nobody Tue Aug 16 17:08:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6d0c0sp4z4Yvbq for ; Tue, 16 Aug 2022 17:09:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6d0b0Qgtz3lkW for ; Tue, 16 Aug 2022 17:09:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x931.google.com with SMTP id s5so3379729uar.1 for ; Tue, 16 Aug 2022 10:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=AJxb66+tn0B6075EJJqdPsaszbMRKlGemenFjjRnpzI=; b=7Klv0UyHknJnOhC2lLoDeSW077MPk7Tycdh6YbtnPOurf5uH0xTnrSUy6/EwVJuFly XEXCkQxcDReneFSKvrnhU3aiQFnkJpK49r2leLzc0K9Kpbuas/W5o2N73NgxK63pN5Jd ReRkfeWR24AotXHfvj0c1RGDXG4b6v7bplYSL4Rc916LBo7GF9Xr4X5Gl9RShGTfBfqU sfBg3cPrGcaPCTxu0NT3a52Cx+cVVzDDrAnVoIQigmJ+zLtjB11Rm4Brx+hkFKYssoxh JFVm29/KccA940RySJKsJH1mEmeNCo72Ll93GgdwWV1OiLSpv17NgUEkbcstbeOY9OCm JZxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=AJxb66+tn0B6075EJJqdPsaszbMRKlGemenFjjRnpzI=; b=2ziF5bo++bKibKTvofYCCS5BAJCzkNbhwJVpuw9veNkUXrFw6aCCFCE1xkJ8hQVppb R9dny298sNmklsdU+xD6xL++3QeBqMIPFykKIalYpqTYhD4bBysBHnMy3ajSKIC095kq mW4q5Cjn68OGtL9Eo8Wkt0waLXz/6uNa/KqIvL+UDR8Eux0R64Ed14WX4kKJ8AVepRRX Y6IoiwRozh+fJeU8HqOKb9armhaJuksPOAFhzaWeAZPYeXDI2Z+FIIoyXrfhMVAuqK69 8hdDgPmv6g3RBy+we6/64rVfXZt1jUyqbfJYK7A90XHCTz+kbjAB0WQOcb5QrclUgxRm 0Hlw== X-Gm-Message-State: ACgBeo23Wb8zzfcE+d+CygsoA05ysGUcqC1mmiclaOqvBMTBZ7q8rw50 joohgME3CKfxrXkulhAEPyL4gKVSAHvut3uUSv1KUxwjr94= X-Google-Smtp-Source: AA6agR70ie12MolBR5hiQOgZElOsuec02Tym8oKQoLhMFTXfEnHdgdRx1ybYTVe0Fn6WZ6XxIkRh58fYQj+oDh9ni4k= X-Received: by 2002:ab0:15ed:0:b0:365:f250:7384 with SMTP id j42-20020ab015ed000000b00365f2507384mr8974198uae.44.1660669742109; Tue, 16 Aug 2022 10:09:02 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 16 Aug 2022 11:08:51 -0600 Message-ID: Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool To: Guido van Rooij Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000011715a05e65ece16" X-Rspamd-Queue-Id: 4M6d0b0Qgtz3lkW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=7Klv0UyH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::931) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000011715a05e65ece16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij wrote: > On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: > > On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org> > > wrote: > > > > Currently I have a system with ZFS on GELI. I use the ability in > > the EFI loader to enter the GELI password. > > Is it possible somehow to use a serial console to enter the > > password? > > My system does have a COM1 port but it isn't recognised at the ear= ly > > bot stage. There I only see: > > =C3=82 =C3=82 Consoles: EFI console > > =C3=82 =C3=82 GELI Passphrase for disk0p4: > > (Note: this is early in the boot process so there is no access to > > boot.config (or any other file in the ZFS pool) as it still on > > encrypted storage at that time). > > > > The boot loader.efi will read ESP:/efi/freebsd/loader.env for > > environment > > variables. You can use that to set the COM1 port since it appears yo= ur > > EFI system doesn't do console redirection. > > If you want it to only prompt COM1 for the password, but everything > > else is > > on the efi console, that's a lot harder. > > Hi Warner, > > Thanks, but somehow I still cannot get it to work properly. > Content of /efi/freebsd/loader.env: > boot_multicons=3D"YES" > console=3D"efi comconsole" > > The boot prompt still only shows "Consoles: EFI console". > Yes. That's printed before we process the ESP file and switch to the new console... > When I boot I get the GELI passphrase prompt at the EFI console only. But > when the kernel starts > to run I do get output to the serial console, staring with: > ---<>--- > Copyright (c) 1992-2021 The FreeBSD Project. > > So it seems the loader.env file is read correctly (it didn't output > anything to the serial > console before I created efi/freebsd/loader.env). But looking at the > source I see in > efi/loader/main.c:read_loader_env(): > if (fn) { > printf(" Reading loader env vars from %s\n", fn); > parse_loader_efi_config(boot_img->DeviceHandle, fn); > } > I never saw the printf appearing. I do not understand this. > It should have appeared on the video console of the EFI console (assuming no serial redirect is going on in that BIOS). I'd have to delve more deeply into the prompts for the GELI password than I have time to do this morning. What if you type the password blind into the serial port? Warner --00000000000011715a05e65ece16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 16, 2022 at 3:44 AM Guido= van Rooij <guido@gvr.org> wrote= :
On Mon, Aug 15= , 2022 at 02:20:32PM -0600, Warner Losh wrote:
>=C2=A0 =C2=A0 On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org>
>=C2=A0 =C2=A0 wrote:
>
>=C2=A0 =C2=A0 =C2=A0 Currently I have a system with ZFS on GELI. I use = the ability in
>=C2=A0 =C2=A0 =C2=A0 the EFI loader to enter the GELI password.
>=C2=A0 =C2=A0 =C2=A0 Is it possible somehow to use a serial console to = enter the
>=C2=A0 =C2=A0 =C2=A0 password?
>=C2=A0 =C2=A0 =C2=A0 My system does have a COM1 port but it isn't r= ecognised at the early
>=C2=A0 =C2=A0 =C2=A0 bot stage. There I only see:
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 Consoles: EFI console >=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 GELI Passphrase for disk= 0p4:
>=C2=A0 =C2=A0 =C2=A0 (Note: this is early in the boot process so there = is no access to
>=C2=A0 =C2=A0 =C2=A0 boot.config (or any other file in the ZFS pool) as= it still on
>=C2=A0 =C2=A0 =C2=A0 encrypted storage at that time).
>
>=C2=A0 =C2=A0 The boot loader.efi will read ESP:/efi/freebsd/loader.env= for
>=C2=A0 =C2=A0 environment
>=C2=A0 =C2=A0 variables. You can use that to set the COM1 port since it= appears your
>=C2=A0 =C2=A0 EFI system doesn't do console redirection.
>=C2=A0 =C2=A0 If you want it to only prompt COM1 for the password, but = everything
>=C2=A0 =C2=A0 else is
>=C2=A0 =C2=A0 on the efi console, that's a lot harder.

Hi Warner,

Thanks, but somehow I still cannot get it to work properly.
Content of /efi/freebsd/loader.env:
boot_multicons=3D"YES"
console=3D"efi comconsole"

The boot prompt still only shows "Consoles: EFI console".

Yes. That's printed before we process the = ESP file and switch to the new console...
=C2=A0
When I boot I get the GELI passphrase prompt at the EFI console only. But w= hen the kernel starts
to run I do get output to the serial console, staring with:
---<<BOOT>>---
Copyright (c) 1992-2021 The FreeBSD Project.

So it seems the loader.env file is read correctly (it didn't output any= thing to the serial
console before I created efi/freebsd/loader.env). But looking at the source= I see in
efi/loader/main.c:read_loader_env():
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (fn) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("=C2=A0= =C2=A0 Reading loader env vars from %s\n", fn);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parse_loader_efi_co= nfig(boot_img->DeviceHandle, fn);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
I never saw the printf appearing. I do not understand this.

It should have appeared on the video console of the EF= I console (assuming no serial
redirect is going on in that BIOS).=

I'd have to delve more deeply into the prompt= s for the GELI password than I have
time to do this morning. What= if you type the password blind into the serial port?

<= div>Warner
--00000000000011715a05e65ece16-- From nobody Tue Aug 16 19:19:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6gtt198Bz4ZCfk for ; Tue, 16 Aug 2022 19:19:18 +0000 (UTC) (envelope-from adridg@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 4M6gtt0gDgz3PZD; Tue, 16 Aug 2022 19:19:18 +0000 (UTC) (envelope-from adridg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660677558; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GeiH4H/y7VTQw0nPYCuwuD37WK21xCZNcx0cLClVHm8=; b=BkHuDZLwnwB3s7F9D/2Wxh47nSyd8AedhRihBGU59SI9bck+JfcoWsKGNYfG3jUvOQs3YG QU3VfvpFM8YecY6Nfo3h+o7IZU2sRxtfdvoY5Xc1pSmQ2w6kst3RNQwkIrfR+T3472QLP/ M+s7kWyzDnKp4Oq+t0w4+ubQqjbq+yTvkVmDuUNdmRA1e7A/wJgXiEEuluOnWMSy4MzvoP SOPtyeygrmixo4QFv5rMbA+YHcG5A3bcOFSGVhUkaBe80NK0Bkp6WT4Dk7gCPNcJxemt5a Xf0hUeZU44KD47tbBe1exBCZDOnRkZvM2Va2/tf2DWYOoVu1kMGHTPYL0f7TJw== Received: from beastie.bionicmutton.org (2a02-a46a-34af-1-2ef0-5dff-fe62-ecc.fixed6.kpn.net [IPv6:2a02:a46a:34af:1:2ef0:5dff:fe62:ecc]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: adridg) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M6gts4y0mz14St; Tue, 16 Aug 2022 19:19:17 +0000 (UTC) (envelope-from adridg@freebsd.org) From: Adriaan de Groot To: freebsd-hackers@freebsd.org, Lorenzo Salvadore Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2022 Date: Tue, 16 Aug 2022 21:19:09 +0200 Message-ID: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1805298.Rtz6emdoko"; micalg="pgp-sha256"; protocol="application/pgp-signature" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660677558; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GeiH4H/y7VTQw0nPYCuwuD37WK21xCZNcx0cLClVHm8=; b=bnSBCvOoefBx3FYOHM/uH5AYQAwno/sYg4nHrf9mD1HRRc25GBsIYTj2SAFHhxSGOZ9bbQ 3KuU6tfnde7HqGkgvKHTXyonpBAPdDxiRK4z8u6M19HBLkf9fEmWYUfi0c7X52ZK0Scs5t /fka1pNSawkyaT3Rrfdx7gtbx91ev7QWMgw3jyw8J0xiOYgvqrp4xGRHl7Mn/unmU3XHci AKOhZGzinL3bO7KVeoQSCQV01gf+TXefS0APIzjMJdro/5R4Jayi1nn+toza3xfNIY9B49 u4vP5W1Rrp0vCbUJ2fZkjU/deAZ2jbKOFx8d7sIdefdq53PKD9DiNM2IcoXw0g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660677558; a=rsa-sha256; cv=none; b=YDWlREXrrQOiCTybPl3qzYRs5UQoAZVGzy2eKDSlqUnWwIeBIXnV981zcO49jEGuEoQPO/ qzsFUJNRQq5pkwoWm/AWt2UAGVq7x4H5u8sqZNLP5svavkX0GsoDrr6zj+YyEtY4/VJXNy WyUNzZhN+hwAWPSMrLYFaPMko1dxcm+dsCIWNbbH42AqSJuBzi75i4Rs3acGC1vAHwZUmG 7LNV5gX8JNJ8xkUd/ieARnh2qNqDt+GJ2+kjDaTzurYs00OOWHNWIAZnDQdMXBNURKLrdg PXASe5r3H/UzjkODtsfaOb5x7ZFxC5qu1nDvJ/a3RUgnI8thM6n8W+X1vb4i/A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --nextPart1805298.Rtz6emdoko Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8"; protected-headers="v1" From: Adriaan de Groot Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2022 Date: Tue, 16 Aug 2022 21:19:09 +0200 Message-ID: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> Organization: FreeBSD In-Reply-To: References: MIME-Version: 1.0 On Monday, 8 August 2022 23:33:31 CEST Lorenzo Salvadore wrote: > FreeBSD Quarterly Status Report Second Quarter 2022 > > Here is the second quarterly report of 2022, with 26 reports included. > > This quarter the quarterly team managed to publish the report much faster > and, hopefully, with much fewer mistakes. If however you notice some > errors, please report them so that we can correct them and also add some > automatic checks in our tools to prevent them in the future and stay as > efficient as possible in the pubblication process. <1500 lines of reports snipped> Lorenzo, I'd like to thank you for coordinating this huge writing effort. Pau, as well, who is behind-the-scenes editing. Deb, for being the shadowy supporter. Dozens of contributors to the report. This shows off just how *much* happens in FreeBSD outside of one's immediate silo (which is ports, for me). [ade] --nextPart1805298.Rtz6emdoko Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQGzBAABCAAdFiEESUdADzdGoDiQC7F4Mo10LYgHpDUFAmL77a0ACgkQMo10LYgH pDWTZgwA2288cpoujY/HK0up//yZU7To8r16kdbWww9uoRaDhm2DR8orn2MacL1D O7zrDUSqFvoYP6GQFus44EKNVTKL/OAQDDtGJhKhUz+qGZshVWwBPwf0SzQBIGmG /5aDa4xoD/tnWjkIf2ADh23X+sg344XbUzGvJgZlrH5N1o/OuWKLUWM4iO7iRHSM S/psYe7zLg1eJQ8pLfjt3K+EsFljrORA3s9rOENx6As1U2SK3HlW1GeHlmPXUkQ2 JmUYoA8vzouPDar3D/zVbwSp1g5L2poNTXkXKa1q8S4cxhzJnYhAyi301OWVkU9u WydzhYBu3P9WHuZ89x7XWGetJGqP4UFdshc+uQuKfP+PeyOYZSJV08WcbnUg4r5j zr7CDmcHzqDU69ENUI7QyxKL2ieN5aGkT4ndzVTHLBdMBW4o64/K3N6yYWhWXMJP hF2Uuxx8Lf1kxn6xYVel/qgh0uL7vVIuHziccsRfg0CVTC6A8NSM/aTc07iYPiRA EN2MQ1a7 =nmo0 -----END PGP SIGNATURE----- --nextPart1805298.Rtz6emdoko-- From nobody Wed Aug 17 07:28:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M704k5Dd2z4ZNFQ for ; Wed, 17 Aug 2022 07:28:54 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (heemeyer.club [195.93.173.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M704j3pn5z3j6w for ; Wed, 17 Aug 2022 07:28:53 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (localhost [127.0.0.1]) by heemeyer.club (8.17.1/8.16.1) with ESMTP id 27H7Sfi7005607; Wed, 17 Aug 2022 10:28:41 +0300 (MSK) (envelope-from dchagin@heemeyer.club) Received: (from dchagin@localhost) by heemeyer.club (8.17.1/8.16.1/Submit) id 27H7SffP005606; Wed, 17 Aug 2022 10:28:41 +0300 (MSK) (envelope-from dchagin) Date: Wed, 17 Aug 2022 10:28:41 +0300 From: Dmitry Chagin To: Alex Arslan Cc: "freebsd-hackers@freebsd.org" Subject: Re: Hang in futex wait with a Node.js binary in Linuxulator Message-ID: References: <16777BDC-22D3-4ACC-95E8-95933D587341@comcast.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16777BDC-22D3-4ACC-95E8-95933D587341@comcast.net> X-Rspamd-Queue-Id: 4M704j3pn5z3j6w X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dchagin@heemeyer.club has no SPF policy when checking 195.93.173.158) smtp.mailfrom=dchagin@heemeyer.club X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:61400, ipnet:195.93.173.0/24, country:RU]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[comcast.net]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[dchagin]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[heemeyer.club]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Aug 15, 2022 at 09:43:29PM -0700, Alex Arslan wrote: > Hi folks, > > I'm trying to run the Linux binary for Codecov's official coverage uploader (https://docs.codecov.com/docs/codecov-uploader ) on FreeBSD via Linuxulator. It's a statically compiled Node.js application built with the Node.js package called pkg. The application's own verbose logging shows that it completes, but the process just hangs indefinitely, using 0 CPU and not letting go of its memory. With devel/linux-c7-strace, it appears it's getting stuck on: > > futex(0x8427f1b70, FUTEX_WAIT_PRIVATE, 2, NULL > > Too stuck to even finish printing the argument list or closing parenthesis, apparently! A Cirrus CI build log where I set the process to terminate via timeout is available at https://cirrus-ci.com/task/6610515924353024 but it's actually reproducible for me locally with just > > curl -O https://uploader.codecov.io/latest/linux/codecov > chmod +x codecov > ./codecov -h > > Does anyone have any advice for how to debug this further? > hi, mostly by ktrace -di/kdump -HAR and see which uaddr wake-up missed, which freebsd version you are used? From nobody Wed Aug 17 13:35:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M78D32gRrz4ZTS3 for ; Wed, 17 Aug 2022 13:35:47 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (2a02-a44b-36d-100--2.fixed6.kpn.net [IPv6:2a02:a44b:36d:100::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M78D243CFz3Dqx for ; Wed, 17 Aug 2022 13:35:46 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 734194055A; Wed, 17 Aug 2022 15:35:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ll6TFlRTek17; Wed, 17 Aug 2022 15:35:37 +0200 (CEST) Received: from smtpclient.apple (unknown [192.168.100.129]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: guido) by gvr.gvr.org (Postfix) with ESMTPSA id 252B24050F; Wed, 17 Aug 2022 15:35:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20220114; t=1660743337; bh=KZEjaazm2OJSlBryfSuwQpdnpWCY7FDz5UFpdtF/0Jg=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=uQGQTm92X9Vaq+UDS7PCrp/inaO78F/hy+MkmDpiQ9ppjJ8+70pVHSHjtHBTLLNGa ic3PvpBBRUF5KHctl3BYgwEas987bT0bWHIXw61duDgVEP0FoKJnotIbB8YC66R0EM KdpTspIEscrf0n3ezkKHgInE22gMAjv8fkk1ekiCczFoWiBVQ5Q5CphqQWH871QE+H 0iSaB1H00oiuTx5rWtX49i/Wd1qvh85L9B7aymFg42Vr95tYsmyuy5Sy8GOPewS2of A5Lrbph8eMFZBtQfXft6TV5sZ+g5KSVsPs0DV71qgBnX4M8W8ifsP04jeL1GzBfb0M Hz3fhn2biTFJQ== Content-Type: multipart/alternative; boundary=Apple-Mail-2BE90669-3CE1-409B-95F1-0E243BCB1217 Content-Transfer-Encoding: 7bit From: Guido van Rooij List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool Date: Wed, 17 Aug 2022 15:35:36 +0200 Message-Id: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> References: Cc: FreeBSD Hackers In-Reply-To: To: Warner Losh X-Mailer: iPhone Mail (19G71) X-Rspamd-Queue-Id: 4M78D243CFz3Dqx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20220114 header.b=uQGQTm92; dmarc=pass (policy=none) header.from=gvr.org; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 2a02:a44b:36d:100::2 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gvr.org,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20220114]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:1136, ipnet:2a02:a400::/25, country:NL]; FREEFALL_USER(0.00)[guido]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gvr.org:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-2BE90669-3CE1-409B-95F1-0E243BCB1217 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 16 Aug 2022, at 19:09, Warner Losh wrote: >=20 > =EF=BB=BF >=20 >=20 >> On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij wrote: >> On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: >> > On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org> >> > wrote: >> >=20 >> > Currently I have a system with ZFS on GELI. I use the ability in >> > the EFI loader to enter the GELI password. >> > Is it possible somehow to use a serial console to enter the >> > password? >> > My system does have a COM1 port but it isn't recognised at the ear= ly >> > bot stage. There I only see: >> > =C3=82 =C3=82 Consoles: EFI console >> > =C3=82 =C3=82 GELI Passphrase for disk0p4: >> > (Note: this is early in the boot process so there is no access to >> > boot.config (or any other file in the ZFS pool) as it still on >> > encrypted storage at that time). >> >=20 >> > The boot loader.efi will read ESP:/efi/freebsd/loader.env for >> > environment >> > variables. You can use that to set the COM1 port since it appears yo= ur >> > EFI system doesn't do console redirection. >> > If you want it to only prompt COM1 for the password, but everything >> > else is >> > on the efi console, that's a lot harder. >>=20 >> Hi Warner, >>=20 >> Thanks, but somehow I still cannot get it to work properly. >> Content of /efi/freebsd/loader.env: >> boot_multicons=3D"YES" >> console=3D"efi comconsole" >>=20 >> The boot prompt still only shows "Consoles: EFI console". >=20 > Yes. That's printed before we process the ESP file and switch to the new c= onsole... > =20 >> When I boot I get the GELI passphrase prompt at the EFI console only. But= when the kernel starts >> to run I do get output to the serial console, staring with: >> ---<>--- >> Copyright (c) 1992-2021 The FreeBSD Project. >>=20 >> So it seems the loader.env file is read correctly (it didn't output anyth= ing to the serial >> console before I created efi/freebsd/loader.env). But looking at the sour= ce I see in=20 >> efi/loader/main.c:read_loader_env(): >> if (fn) { >> printf(" Reading loader env vars from %s\n", fn); >> parse_loader_efi_config(boot_img->DeviceHandle, fn); >> } >> I never saw the printf appearing. I do not understand this. >=20 > It should have appeared on the video console of the EFI console (assuming n= o serial > redirect is going on in that BIOS). >=20 It surely did not. > I'd have to delve more deeply into the prompts for the GELI password than I= have > time to do this morning. What if you type the password blind into the seri= al port? >=20 Tried that but nothing happened. When I enter the passphrase after typing it in via the serial port, it worked immediately so we can conclude that no single keystroke=20 got through. -Guido=20 --Apple-Mail-2BE90669-3CE1-409B-95F1-0E243BCB1217 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 16 Aug 2022, at 19:= 09, Warner Losh <imp@bsdimp.com> wrote:

=EF=BB=BF


On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij <guido@gvr.org> wrote:
On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warne= r Losh wrote:
>    On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org>
>    wrote:
>
>      Currently I have a system with ZFS on GELI. I use t= he ability in
>      the EFI loader to enter the GELI password.
>      Is it possible somehow to use a serial console to e= nter the
>      password?
>      My system does have a COM1 port but it isn't recogn= ised at the early
>      bot stage. There I only see:
>      =C3=82  =C3=82  Consoles: EFI console
= >      =C3=82  =C3=82  GELI Passphrase for disk0= p4:
>      (Note: this is early in the boot process so there i= s no access to
>      boot.config (or any other file in the ZFS pool) as i= t still on
>      encrypted storage at that time).
>
>    The boot loader.efi will read ESP:/efi/freebsd/loader.env f= or
>    environment
>    variables. You can use that to set the COM1 port since it a= ppears your
>    EFI system doesn't do console redirection.
>    If you want it to only prompt COM1 for the password, but e= verything
>    else is
>    on the efi console, that's a lot harder.

Hi Warner,

Thanks, but somehow I still cannot get it to work properly.
Content of /efi/freebsd/loader.env:
boot_multicons=3D"YES"
console=3D"efi comconsole"

The boot prompt still only shows "Consoles: EFI console".

Yes. That's printed before we process the ESP file and swi= tch to the new console...
 
When I boot I get the GELI passphrase prompt at the EFI console only. But wh= en the kernel starts
to run I do get output to the serial console, staring with:
---<<BOOT>>---
Copyright (c) 1992-2021 The FreeBSD Project.

So it seems the loader.env file is read correctly (it didn't output anything= to the serial
console before I created efi/freebsd/loader.env). But looking at the source I= see in
efi/loader/main.c:read_loader_env():
        if (fn) {
                printf("   = ; Reading loader env vars from %s\n", fn);
                parse_loader_efi_con= fig(boot_img->DeviceHandle, fn);
        }
I never saw the printf appearing. I do not understand this.
=

It should have appeared on the video console of the EFI c= onsole (assuming no serial
redirect is going on in that BIOS).


It surely did= not.
I'd have to delve more deeply into the prompts for t= he GELI password than I have
time to do this morning. What if you t= ype the password blind into the serial port?


Tried that but nothing happened. When Ienter the passphrase after typing it in via
the serial port, it= worked immediately so
we can conclude that no single keystroke&nb= sp;
got through.

-Guido 
= --Apple-Mail-2BE90669-3CE1-409B-95F1-0E243BCB1217-- From nobody Wed Aug 17 13:59:25 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M78lT2M8Vz4ZWn0 for ; Wed, 17 Aug 2022 13:59:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M78lS3X6Jz3JDG for ; Wed, 17 Aug 2022 13:59:32 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: (Authenticated sender: andriy.gapon@uabsd.com) by mail.gandi.net (Postfix) with ESMTPSA id 5B9A41C0007; Wed, 17 Aug 2022 13:59:26 +0000 (UTC) Message-ID: Date: Wed, 17 Aug 2022 16:59:25 +0300 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.12.0 Subject: Re: different console settings for loader[.efi] and kernel Content-Language: en-US To: Warner Losh Cc: "freebsd-hackers@freebsd.org" References: From: Andriy Gapon In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4M78lS3X6Jz3JDG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::225 is neither permitted nor denied by domain of avg@FreeBSD.org) smtp.mailfrom=avg@FreeBSD.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::225:from]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[avg]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-08-16 19:52, Warner Losh wrote: > > > On Tue, Aug 16, 2022 at 12:52 AM Andriy Gapon > wrote: > > > It seems that console variable in loader.conf affects both the > OS/kernel > and the loader itself.  Is there a way to have different console > settings between those? > > > Yes. > > Let me explain.  I have a system that I access in several different > ways: via its physical serial console, via IPMI / iKVM, and sometimes > via its physical video console. > console is set to "comconsole, efi". > The system uses EFI boot. > The BIOS is configured to "redirect" video console to serial and to > stop > the redirection once an OS starts. > > The setup works fine before the loader (e.g., for entering BIOS > settings) and it works fine once the kernel starts. > But while in the loader, every character printed gets doubled on the > serial console.  I guess that this is because the loader prints it to > both the serial output and the EFI output while the BIOS still > redirects > the EFI output to the serial. > > > Yes. You've told it to have two consoles, and when they are the same > hardware > you'll get that doubling. Yup. > > I would like to solve that double printing while keeping both the > serial > console and the video / EFI console usable. > > > Double printing is trivial to fix: Don't add 'comconsole' to the > consoles. EFI loader > uses the generic console facilities. So when it's doing redirect, just > set it to EFI. The reason I added comconsole was that I did not know of any other way to instruct the kernel to use the serial console. > > So, one way would be for the loader to use only the EFI console and let > the BIOS redirect take care of the serial. > > > console=efi does exactly that on my systems. > > I guess that another way would be for the loader to announce itself as > an "OS" (whatever that technically means), so that the BIOS stops its > redirection. > > > Now, having said that, there's one issue with EFI. EFI specifies the UID > which the boot loader can't decode into an address, and the current kernel > doesn't verify the address is correct, nor can it use this UID to do cninit > (because ACPI isn't brought up enough to find the address yet). In those > cases, > you'll need to use an additional environment variable from the loader: > > hw.uart.console="io:1016,br:115200" > > this sets the port to 0x3f8 for the kernel, but the loader won't do > anything with it. > The kernel will. Thank you very much! This is exactly what I was looking for. -- Andriy Gapon https://standforukraine.com https://razomforukraine.org From nobody Wed Aug 17 15:19:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7BXD1NwPz4ZhG8 for ; Wed, 17 Aug 2022 15:19:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7BXC4BBKz3Xvh for ; Wed, 17 Aug 2022 15:19:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-lj1-x233.google.com with SMTP id by6so13850416ljb.11 for ; Wed, 17 Aug 2022 08:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=s0ptzqhYZcun7Ee17C5x1Vewk7k6v6A0rrJod0O3nL0=; b=b3HOs0zGyydHeaO/2iXuq93B5UdLpbt9zX6be91axHc10TbxL9Z4hQwnJ6yp7zlk2s jnDrJasK3LTx4aUN5utDftC01k+u+XDgcNHDT3nh8ld3uTv7GYEwbPvwUCf9gjLKuOw/ eGSFtQlyNioZ5QgJenMLAe1g0qSi/Pr/xjXTO9Ma/3zHoZM+UVaZNQlt4wlUaPJWYluh Tkg0a3+H/rHJAcvTpBnDPd7pKsxU33rI/IV62tJnSsBcueeA1pGoz/5DfBcxtWGxSOPm j246hHCcF3UsTHNDYVzkU0BRn/00FXbwJXHJVkuA30rktaYZg8Ak6kPTe2IKZR8DVC/7 wmng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=s0ptzqhYZcun7Ee17C5x1Vewk7k6v6A0rrJod0O3nL0=; b=JBh1u0RosmYPapz40t3sXx0k3hyKNO0gHv9XgRxmqpjV3DMwgMO4ALoie8xfMG9pM/ vTi75rPF9Dq/oq1iiyVkcPFBpY4FY6x9FGTAgyBbLceNPkcbHnM47xqMfgSD6SbB6CkF U+pXmvqswSXa6WElsQmCvTT5aCCKCr4GsTls9J83e/0H1ay+ekwbE7Q89VEXRZ5M/Z7y Bhv3F1xMiSYaHhpRKvSGPE9XcMoBxFvjyN5QDOzcEbqcM1IQxBSrZtKweBHVLpS/0WFX qPC+/aaTmZ4tMkWU8EoM1uS9m+LBzy/KubF1bwdmYwRMyFaAvpMOG7bXF8JLe7CqsoEU 9Gzw== X-Gm-Message-State: ACgBeo2IMmdCo3ue+f2rH9XdL2y8azfUBowwCfika2F1k1EUFEkf8D+x /jWRJghdYNc80uiQacrTyvo+B8PpCMLeJ2De9cr/AScK9j8= X-Google-Smtp-Source: AA6agR75R467OQO1C023+E3Dhssi06GH5MOhbNoRsPEPYFId2lLuyW3tZBtTXUCLdHTQIs/cLEZYMN0eBnkelOTXBk0= X-Received: by 2002:a05:651c:201:b0:25e:695d:2b4 with SMTP id y1-20020a05651c020100b0025e695d02b4mr8146581ljn.87.1660749593739; Wed, 17 Aug 2022 08:19:53 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> In-Reply-To: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> From: Warner Losh Date: Wed, 17 Aug 2022 09:19:42 -0600 Message-ID: Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool To: Guido van Rooij Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000989dcf05e67165f4" X-Rspamd-Queue-Id: 4M7BXC4BBKz3Xvh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=b3HOs0zG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::233) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::233:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000989dcf05e67165f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2022 at 7:35 AM Guido van Rooij wrote: > > > On 16 Aug 2022, at 19:09, Warner Losh wrote: > > =EF=BB=BF > > > On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij wrote: > >> On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: >> > On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org> >> > wrote: >> > >> > Currently I have a system with ZFS on GELI. I use the ability in >> > the EFI loader to enter the GELI password. >> > Is it possible somehow to use a serial console to enter the >> > password? >> > My system does have a COM1 port but it isn't recognised at the >> early >> > bot stage. There I only see: >> > =C3=82 =C3=82 Consoles: EFI console >> > =C3=82 =C3=82 GELI Passphrase for disk0p4: >> > (Note: this is early in the boot process so there is no access to >> > boot.config (or any other file in the ZFS pool) as it still on >> > encrypted storage at that time). >> > >> > The boot loader.efi will read ESP:/efi/freebsd/loader.env for >> > environment >> > variables. You can use that to set the COM1 port since it appears >> your >> > EFI system doesn't do console redirection. >> > If you want it to only prompt COM1 for the password, but everything >> > else is >> > on the efi console, that's a lot harder. >> >> Hi Warner, >> >> Thanks, but somehow I still cannot get it to work properly. >> Content of /efi/freebsd/loader.env: >> boot_multicons=3D"YES" >> console=3D"efi comconsole" >> >> The boot prompt still only shows "Consoles: EFI console". >> > > Yes. That's printed before we process the ESP file and switch to the new > console... > > >> When I boot I get the GELI passphrase prompt at the EFI console only. Bu= t >> when the kernel starts >> to run I do get output to the serial console, staring with: >> ---<>--- >> Copyright (c) 1992-2021 The FreeBSD Project. >> >> So it seems the loader.env file is read correctly (it didn't output >> anything to the serial >> console before I created efi/freebsd/loader.env). But looking at the >> source I see in >> efi/loader/main.c:read_loader_env(): >> if (fn) { >> printf(" Reading loader env vars from %s\n", fn); >> parse_loader_efi_config(boot_img->DeviceHandle, fn); >> } >> I never saw the printf appearing. I do not understand this. >> > > It should have appeared on the video console of the EFI console (assuming > no serial > redirect is going on in that BIOS). > > > It surely did not. > > I'd have to delve more deeply into the prompts for the GELI password than > I have > time to do this morning. What if you type the password blind into the > serial port? > > > Tried that but nothing happened. When I > enter the passphrase after typing it in via > the serial port, it worked immediately so > we can conclude that no single keystroke > got through. > OK. I'll have to delve a little more deeply then... Warner --000000000000989dcf05e67165f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Aug 17, 2022 at 7:35 AM Guido= van Rooij <guido@gvr.org> wrote= :


=
On 16 Aug 2022, at 19:09, Warner Losh <imp@bsdimp.com> wrote:<= br>
=EF=BB= =BF


On Tue, Aug 16, 2022 at 3:44 AM Gu= ido van Rooij <guido@= gvr.org> wrote:
On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote:
>=C2=A0 =C2=A0 On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij <[1]guido@gvr.org>
>=C2=A0 =C2=A0 wrote:
>
>=C2=A0 =C2=A0 =C2=A0 Currently I have a system with ZFS on GELI. I use = the ability in
>=C2=A0 =C2=A0 =C2=A0 the EFI loader to enter the GELI password.
>=C2=A0 =C2=A0 =C2=A0 Is it possible somehow to use a serial console to = enter the
>=C2=A0 =C2=A0 =C2=A0 password?
>=C2=A0 =C2=A0 =C2=A0 My system does have a COM1 port but it isn't r= ecognised at the early
>=C2=A0 =C2=A0 =C2=A0 bot stage. There I only see:
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 Consoles: EFI console >=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 GELI Passphrase for disk= 0p4:
>=C2=A0 =C2=A0 =C2=A0 (Note: this is early in the boot process so there = is no access to
>=C2=A0 =C2=A0 =C2=A0 boot.config (or any other file in the ZFS pool) as= it still on
>=C2=A0 =C2=A0 =C2=A0 encrypted storage at that time).
>
>=C2=A0 =C2=A0 The boot loader.efi will read ESP:/efi/freebsd/loader.env= for
>=C2=A0 =C2=A0 environment
>=C2=A0 =C2=A0 variables. You can use that to set the COM1 port since it= appears your
>=C2=A0 =C2=A0 EFI system doesn't do console redirection.
>=C2=A0 =C2=A0 If you want it to only prompt COM1 for the password, but = everything
>=C2=A0 =C2=A0 else is
>=C2=A0 =C2=A0 on the efi console, that's a lot harder.

Hi Warner,

Thanks, but somehow I still cannot get it to work properly.
Content of /efi/freebsd/loader.env:
boot_multicons=3D"YES"
console=3D"efi comconsole"

The boot prompt still only shows "Consoles: EFI console".

Yes. That's printed before we process the = ESP file and switch to the new console...
=C2=A0
When I boot I get the GELI passphrase prompt at the EFI console only. But w= hen the kernel starts
to run I do get output to the serial console, staring with:
---<<BOOT>>---
Copyright (c) 1992-2021 The FreeBSD Project.

So it seems the loader.env file is read correctly (it didn't output any= thing to the serial
console before I created efi/freebsd/loader.env). But looking at the source= I see in
efi/loader/main.c:read_loader_env():
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (fn) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 printf("=C2=A0= =C2=A0 Reading loader env vars from %s\n", fn);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parse_loader_efi_co= nfig(boot_img->DeviceHandle, fn);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
I never saw the printf appearing. I do not understand this.

It should have appeared on the video console of the EF= I console (assuming no serial
redirect is going on in that BIOS).=


It surel= y did not.
<= div class=3D"gmail_quote">
I'd have to delve more deeply into the p= rompts for the GELI password than I have
time to do this morning.= What if you type the password blind into the serial port?


Tried that but nothing ha= ppened. When I
enter the passphrase after typing it in via
th= e serial port, it worked immediately so
we can conclude that no s= ingle keystroke=C2=A0
got through.
<= br>
OK. I'll have to delve a little more deeply then...
=

Warner=C2=A0
--000000000000989dcf05e67165f4-- From nobody Wed Aug 17 17:08:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7Dy46x7Mz4YhHV for ; Wed, 17 Aug 2022 17:09:00 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7Dy40294z3vWt for ; Wed, 17 Aug 2022 17:08:59 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: (Authenticated sender: daniel.engberg@pyret.net) by mail.gandi.net (Postfix) with ESMTPA id 8EA251BF203; Wed, 17 Aug 2022 17:08:57 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Wed, 17 Aug 2022 19:08:57 +0200 From: Daniel Engberg To: Harris Snyder Cc: freebsd-hackers@freebsd.org Subject: Re: Strange behavior of USB PCIe add-in cards In-Reply-To: References: Message-ID: <2c108a487ff68d38f448dc5e001faad2@FreeBSD.org> X-Sender: daniel.engberg.lists@pyret.net Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4M7Dy40294z3vWt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of daniel.engberg.lists@pyret.net designates 2001:4b98:dc4:8::228 as permitted sender) smtp.mailfrom=daniel.engberg.lists@pyret.net X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc4:8::/64]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::228:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:203476, ipnet:2001:4b98:dc4::/48, country:FR]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[pyret.net]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-08-12 22:34, Harris Snyder wrote: > Hello everyone, > > I have two USB3 PCIe cards (different chipset vendors) that are both > exhibiting the same symptoms: > - They are detected and attached to the xhci driver. > - They sort of work (a usb stick seems to work for file IO) > - When an interactive device (e.g. USB sound card, mouse, or keyboard) > is connected, they seem to drop the overwhelming majority of input > events. For example, the mouse moves jerkily, at intervals of several > seconds. Most keypresses on a keyboard are missed, and occasionally a > "key up" event seems to be missed and the same key is typed > repeatedly. A USB sound card has stutters and hitches in the audio > output. > > Does anybody recognize this behaviour or know of a solution? I have > tried: > - A different PCIe slot > - Two different PCIe USB3 cards from different vendors (and different > chipset vendors - VIA and ASMedia). One of the cards uses the VIA > VL806, which some users on the FreeBSD forum have reported working... > > I'm using CURRENT, but about 2 weeks behind... > > Thanks, > Harris Hi, Early USB 3 controllers were quite unstable and unreliable so unless you're on very old hardware I'd suggest that you look for a decent USB hub instead if you need more ports. In my experience VIA (Labs) VL817 works very well in general, one device that uses it is ORICO MH4U-U3 or at least used to. You might want to go for the newer VL822 controller however finding out what chipset is used can be a bit hard but according to the product images this one uses it for example https://www.amazon.com/HOYOKI-Powered-Adapter-Slippter-Keyboard/dp/B098D7H5XD . I've also used one hub based on ASMedia ASM1074 which worked fine for my use case but the quality of the product was very questionable, this controller doesn't seem to be very common and if you find one it's usually a very poorly made product overall. There are other vendors too such as Cypress, Fresco Logic, Genesys Logic etc but when I looked they're either very rare (Cypress and Fresco Logic) or people have very mixed experiences (Genesys Logic) however their newer ones might be better such as GL3590. But if you want to give the USB PCIe cards a go the VIA one your mentioned is very old so I would highly suggest that you try to update the firmware. Unforunately that usually requires you to search various forums etc to find the flashing utility and firmware. Having a quick look this page ( https://github.com/jpmorrison/VL805 ) seems to be relevent and the other ones it links too. Do keep in mind that you may brick your card if you flash using wrong firmware or if it process hangs for whatever reason. This is also true for your ASMedia card, some controllers even include "easter eggs". See https://github.com/smx-smx/ASMTool , https://github.com/cyrozap/asmedia-xhc-re for more information. In some BIOSes you have a toggle for "PCI Timer Latency" option, usually you want to keep this at 32 or 64 which usually is the default may also be a cause. Regarding your peripherals, are they known to be working and/or have your tried using the motherboard chipset controller instead? There are also reports of stuttering using Ryzen systems which may be what you're using (search the mailing lists for more information). Providing what hardware (mainboard, cpu) are you using and arch (i386, amd64) would also be helpful in trying to debug your issue. Best regards, Daniel From nobody Thu Aug 18 04:45:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7XQt38QQz4ZKFR for ; Thu, 18 Aug 2022 04:46:30 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resqmta-h1p-028589.sys.comcast.net (resqmta-h1p-028589.sys.comcast.net [IPv6:2001:558:fd02:2446::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7XQs0Y5rz40ym for ; Thu, 18 Aug 2022 04:46:28 +0000 (UTC) (envelope-from ararslan@comcast.net) Received: from resomta-h1p-027908.sys.comcast.net ([96.102.179.197]) by resqmta-h1p-028589.sys.comcast.net with ESMTP id OX54oaD3VXQ9eOXQDo9mEa; Thu, 18 Aug 2022 04:46:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1660797981; bh=AklBm0mF2VtIqPw7YTU3dOO0OOiDw98rVyFdbBChH5I=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=3tApV8BZ0X1cqxk4g8iF5XdokWYCWeoQqJibua75oeEaywwmfgcaOw/gmInfDp0rN oRHnarAFGbmrSWFf1lSlYMr8Z0P5avho5g6cqVzRZxxbD/tp/QpFXCKgzqIwVisuUN Uf1sBQlD9ZPjZyRJi2jjmxIUw6KSSuQ7fQit0U76Z0CevQwxG0KDx7Ua28R0KHxWUx 4yhCm/vAuXh3aIsoHMjDC2fccG3PlOaHQsA2C+W/7Zxi0nx+trYKzfisgOQAFhu+FI pBsIOrS0Et2jlJFTLmyMlmCIo4MqlCIvLqfsWuiFyYpvXH0JMMLrroB4VCgvswTfAf eQwi/1cTGk50A== Received: from smtpclient.apple ([71.231.182.61]) by resomta-h1p-027908.sys.comcast.net with ESMTPA id OXPpovrF5yhzHOXPqo1s7w; Thu, 18 Aug 2022 04:46:00 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvfedrvdehjedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffvefgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhgvgicutehrshhlrghnuceorghrrghrshhlrghnsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeejtdektedtgefhgeefhedvieehjeelgedvveefvedvudekkeffheegtdehkeefgfenucffohhmrghinheptghouggvtghovhdrtghomhdptghirhhruhhsqdgtihdrtghomhdptghouggvtghovhdrihhonecukfhppeejuddrvdefuddrudekvddriedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepshhmthhptghlihgvnhhtrdgrphhplhgvpdhinhgvthepjedurddvfedurddukedvrdeiuddpmhgrihhlfhhrohhmpegrrhgrrhhslhgrnhestghomhgtrghsthdrnhgvthdpnhgspghrtghpthhtohepvddprhgtphhtthhopegutghhrghgihhnsehhvggvmhgvhigvrhdrtghluhgspdhrtghpthhtohepfhhrvggvsghsugdqhhgrtghkvghrshesfhhrvggvsghsugdrohhrgh X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Hang in futex wait with a Node.js binary in Linuxulator From: Alex Arslan In-Reply-To: Date: Wed, 17 Aug 2022 21:45:57 -0700 Cc: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <16777BDC-22D3-4ACC-95E8-95933D587341@comcast.net> To: Dmitry Chagin X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4M7XQs0Y5rz40ym X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=comcast.net header.s=20190202a header.b=3tApV8BZ; dmarc=pass (policy=none) header.from=comcast.net; spf=pass (mx1.freebsd.org: domain of ararslan@comcast.net designates 2001:558:fd02:2446::6 as permitted sender) smtp.mailfrom=ararslan@comcast.net X-Spamd-Result: default: False [-0.41 / 15.00]; HFILTER_HELO_5(3.00)[resqmta-h1p-028589.sys.comcast.net]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; NEURAL_HAM_MEDIUM(-0.92)[-0.924]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[comcast.net,none]; R_DKIM_ALLOW(-0.20)[comcast.net:s=20190202a]; R_SPF_ALLOW(-0.20)[+ip6:2001:558:fd02:2446::/64]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[comcast.net:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; ASN(0.00)[asn:7922, ipnet:2001:558::/29, country:US]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_FROM(0.00)[comcast.net]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_ENVFROM(0.00)[comcast.net]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[comcast.net:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hi Dmitry, thanks for the help! Regarding the version, I've observed the = hang on FreeBSD 12.2, 12.3, and 13.0. When looking at the kdump output, = I see linux_sys_futex(0x8427eeb70,0x80,0x2,0,0,0) as the last output before the SIGINT I sent to stop the hang. If I = understand correctly, this is the same as what I posted before=E2=80=94a = futex waiting for the value 2 to be written to a process-private = address=E2=80=94which would mean that the address the wake-up missed was = 0x8427eeb70, the first argument to the call. Is that right? There is no = wake-up sent though. I looked for that address in the full kdump output = and didn't find it, and I'm not sure what else to be looking for. = Apologies if I'm missing something obvious here, I'm quite new to this = kind of debugging. > On Aug 17, 2022, at 12:28 AM, Dmitry Chagin = wrote: >=20 > On Mon, Aug 15, 2022 at 09:43:29PM -0700, Alex Arslan wrote: >> Hi folks, >>=20 >> I'm trying to run the Linux binary for Codecov's official coverage = uploader (https://docs.codecov.com/docs/codecov-uploader = ) on FreeBSD via = Linuxulator. It's a statically compiled Node.js application built with = the Node.js package called pkg. The application's own verbose logging = shows that it completes, but the process just hangs indefinitely, using = 0 CPU and not letting go of its memory. With devel/linux-c7-strace, it = appears it's getting stuck on: >>=20 >> futex(0x8427f1b70, FUTEX_WAIT_PRIVATE, 2, NULL >>=20 >> Too stuck to even finish printing the argument list or closing = parenthesis, apparently! A Cirrus CI build log where I set the process = to terminate via timeout is available at = https://cirrus-ci.com/task/6610515924353024 = but it's actually = reproducible for me locally with just >>=20 >> curl -O https://uploader.codecov.io/latest/linux/codecov >> chmod +x codecov >> ./codecov -h >>=20 >> Does anyone have any advice for how to debug this further? >>=20 >=20 > hi, mostly by ktrace -di/kdump -HAR and see which uaddr wake-up = missed, > which freebsd version you are used? >=20 From nobody Thu Aug 18 08:35:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7dWT7017z4YrR7 for ; Thu, 18 Aug 2022 08:35:49 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (heemeyer.club [195.93.173.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7dWS6yqTz3LfW for ; Thu, 18 Aug 2022 08:35:48 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (localhost [127.0.0.1]) by heemeyer.club (8.17.1/8.16.1) with ESMTP id 27I8Za2K034044; Thu, 18 Aug 2022 11:35:36 +0300 (MSK) (envelope-from dchagin@heemeyer.club) Received: (from dchagin@localhost) by heemeyer.club (8.17.1/8.16.1/Submit) id 27I8ZaaU034043; Thu, 18 Aug 2022 11:35:36 +0300 (MSK) (envelope-from dchagin) Date: Thu, 18 Aug 2022 11:35:35 +0300 From: Dmitry Chagin To: Alex Arslan Cc: "freebsd-hackers@freebsd.org" Subject: Re: Hang in futex wait with a Node.js binary in Linuxulator Message-ID: References: <16777BDC-22D3-4ACC-95E8-95933D587341@comcast.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4M7dWS6yqTz3LfW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dchagin@heemeyer.club has no SPF policy when checking 195.93.173.158) smtp.mailfrom=dchagin@heemeyer.club X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:61400, ipnet:195.93.173.0/24, country:RU]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[comcast.net]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[dchagin]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[heemeyer.club]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Aug 17, 2022 at 09:45:57PM -0700, Alex Arslan wrote: > Hi Dmitry, thanks for the help! Regarding the version, I've observed the hang on FreeBSD 12.2, 12.3, and 13.0. When looking at the kdump output, I see > > linux_sys_futex(0x8427eeb70,0x80,0x2,0,0,0) > > as the last output before the SIGINT I sent to stop the hang. If I understand correctly, this is the same as what I posted before—a futex waiting for the value 2 to be written to a process-private address—which would mean that the address the wake-up missed was 0x8427eeb70, the first argument to the call. Is that right? There is no wake-up sent though. I looked for that address in the full kdump output and didn't find it, and I'm not sure what else to be looking for. Apologies if I'm missing something obvious here, I'm quite new to this kind of debugging. > yes, you are right. if possible, upgrade to stable/13, it is the same as the -current. I checked stable/13, it's the same behaviour( > > On Aug 17, 2022, at 12:28 AM, Dmitry Chagin wrote: > > > > On Mon, Aug 15, 2022 at 09:43:29PM -0700, Alex Arslan wrote: > >> Hi folks, > >> > >> I'm trying to run the Linux binary for Codecov's official coverage uploader (https://docs.codecov.com/docs/codecov-uploader ) on FreeBSD via Linuxulator. It's a statically compiled Node.js application built with the Node.js package called pkg. The application's own verbose logging shows that it completes, but the process just hangs indefinitely, using 0 CPU and not letting go of its memory. With devel/linux-c7-strace, it appears it's getting stuck on: > >> > >> futex(0x8427f1b70, FUTEX_WAIT_PRIVATE, 2, NULL > >> > >> Too stuck to even finish printing the argument list or closing parenthesis, apparently! A Cirrus CI build log where I set the process to terminate via timeout is available at https://cirrus-ci.com/task/6610515924353024 but it's actually reproducible for me locally with just > >> > >> curl -O https://uploader.codecov.io/latest/linux/codecov > >> chmod +x codecov > >> ./codecov -h > >> > >> Does anyone have any advice for how to debug this further? > >> > > > > hi, mostly by ktrace -di/kdump -HAR and see which uaddr wake-up missed, > > which freebsd version you are used? > > > > From nobody Thu Aug 18 16:08:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7qZM5Grsz4ZrFY for ; Thu, 18 Aug 2022 16:08:59 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7qZM0Bm4z47Mv for ; Thu, 18 Aug 2022 16:08:58 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from [198.18.2.12] (24-236-44-43-dynamic.midco.net [24.236.44.43]) by smtp.vangyzen.net (Postfix) with ESMTPSA id E00FC56477 for ; Thu, 18 Aug 2022 11:08:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=vangyzen.net; s=default; t=1660838931; bh=IrBtEPS+j6dfGaX210IwyLkfeknnDh3gFB+xVCiggzw=; h=Date:To:From:Subject; b=UpZ3ICPIayY6b3q4r9UbrJiEZze06QaWWykSPcsiBIuBWJNW5lPUu9IK8BAUzOiGY TRj+faes6ELArkg5d8e45GdIk3C5+553MVCAxCmVnL7+qNqylSzfIk+FAQOBUkgMp+ s/qz2WmRLXbQJQ16HjjlrwXZaUtK60BR9NxwMMpqJNwb2iWuhNZNzQQf/pJlfU4z6b fzKFma0+OheRtzT3VHRJiBzDyNjKca+TpJ7WRIqeSo+VrRu0Ka+QjdQXKZXv5N3pTA 5U+ksiXHXQFVkJTLwnYc63SM3CUplMKVOWJF6jHAQetf36ZndFK3zp6+qervOsU3Pn gXNKWfiaTsNSg== Message-ID: Date: Thu, 18 Aug 2022 11:08:47 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: freebsd-hackers From: Eric van Gyzen Subject: Impact of FreeBSD-SA-22:10.aio Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4M7qZM0Bm4z47Mv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=vangyzen.net header.s=default header.b=UpZ3ICPI; dmarc=pass (policy=none) header.from=vangyzen.net; spf=pass (mx1.freebsd.org: domain of eric@vangyzen.net designates 199.48.133.146 as permitted sender) smtp.mailfrom=eric@vangyzen.net X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[vangyzen.net,none]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[vangyzen.net:s=default]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:36236, ipnet:199.48.132.0/22, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[vangyzen.net:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[eric]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N The Impact section of FreeBSD-SA-22:10.aio says An attacker may cause the reference count to overflow, leading to a use after free (UAF). I don't see how the refcount can overflow. That seems to be prevented by REFCOUNT_SATURATED and friends. Does anyone care to enlighten me? There is the small window between fetchadd and detecting saturation; is this the [only] way? Cheers, Eric From nobody Thu Aug 18 16:15:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7qkN0QhJz4Zs3Z for ; Thu, 18 Aug 2022 16:15:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7qkM2c7lz49YC for ; Thu, 18 Aug 2022 16:15:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72a.google.com with SMTP id n21so1470242qkk.3 for ; Thu, 18 Aug 2022 09:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc; bh=Omp1OXW5DKN5HZ8a5KDXm+QOw+P048r3r2DUjduiYfE=; b=hE0zHaApG35nFZl1hTHCUZt40DDuOJh/yd6ug2iUx7IEPR78zyjkXSa1C3Az4AeoyG 2R+J3WWCldPmtk1bOxsr4GOC5EaNqeM3OgUgTlIHkQhTBJwEz3dTZ/k7qq4bHiBvLjgp DfSNq8sEIkuoP0DXNuJP0fOlE8f4qKtCnVWpi8nuP2Alg7mfTA1/6g06Ke+OL55Qm6P5 bP/sJTWZzJB8L0IuZfwrSNMhSVdGuVd68AqM2d1pQ+2UNX06QVqKNYah4NER1AUIYuk5 UMGzwH155dhes4QjsVz5tbxb6sveloyTrT48AMepx6aKug3yJ9mPf2pruuNfmSBwoXyX xBRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc; bh=Omp1OXW5DKN5HZ8a5KDXm+QOw+P048r3r2DUjduiYfE=; b=I+j8RrWeiGGUVmnVVgiQDPb4q6dY3yl+EhtrGUqKwKIsRJp5/X4kfRrJwG83cRwiJV qffgHxQbCAgcyOg0b3z3Gbo9WKSVs3s0bxRPeecfadUdGMiGEgT5RHYYF4wPp8ywsS8p qErIP49yU6DmgmHHPaD0vRZR3wAZsDBH4bMRSH2AUifUFLuh4hq1dTv7lQ+nAqkLVJiL 2YM0UD2kEbI72HO6W1G77/7JFXslxFpH+ntK2w7kggVx6l5LBZNwraoT2lvwSyuStqx6 rvzIcVIKomPopFnyVViZ4vKUrhcreN9T1vmGINs4xjeJFcC61yI+ZBFOaZZpfs/qc6Mv YiJg== X-Gm-Message-State: ACgBeo0cm7x3Ff4ZKB5cwjyFLxbz0fbOeEcPD6S0ZpD8wHI/PJt7/w+L pqgWRyvlI/in9kIro/rFf7ZGkF47EaY= X-Google-Smtp-Source: AA6agR6A1+DRPrIn6xoPVVyOnVlXHSo4w8ZF1srvMuSm9lWETfIibOB7Jg0KgQz0wdKo/OJapCdFvA== X-Received: by 2002:a05:620a:1402:b0:6bb:6c8a:e590 with SMTP id d2-20020a05620a140200b006bb6c8ae590mr2594354qkj.598.1660839354440; Thu, 18 Aug 2022 09:15:54 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id z15-20020a05622a060f00b0034308283775sm1316706qta.21.2022.08.18.09.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Aug 2022 09:15:53 -0700 (PDT) Date: Thu, 18 Aug 2022 12:15:51 -0400 From: Mark Johnston To: Eric van Gyzen Cc: freebsd-hackers Subject: Re: Impact of FreeBSD-SA-22:10.aio Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4M7qkM2c7lz49YC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hE0zHaAp; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72a as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72a:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Aug 18, 2022 at 11:08:47AM -0500, Eric van Gyzen wrote: > The Impact section of FreeBSD-SA-22:10.aio says > > An attacker may cause the reference count to overflow, > leading to a use after free (UAF). > > I don't see how the refcount can overflow. That seems to be prevented > by REFCOUNT_SATURATED and friends. Does anyone care to enlighten me? > There is the small window between fetchadd and detecting saturation; is > this the [only] way? The refcount implementation in 12.3 doesn't handle overflow or underflow at all, so it is vulnerable. I believe you're right that that mitigation converts the bug into a memory leak in 13.0, and so the advisory erroneously lists 13.0 as vulnerable when it isn't. From nobody Thu Aug 18 18:01:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7t505t3Sz4YsqG for ; Thu, 18 Aug 2022 18:02:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7t5017qLz3M7t; Thu, 18 Aug 2022 18:02:12 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f53.google.com with SMTP id a7so4692701ejp.2; Thu, 18 Aug 2022 11:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=O3AYoKZ0itoP7iNsmUSBa40ZPXqV1m8+8YbC83f/fwU=; b=mkYxTx3HLUtKINKkeLIjx671gP8hDFV87hM0DVa/XTDfWhfaXR3ea2gMBCpu5JSBIr /ssKoRcvVEPvnWVWD8/EzJudZn0pfGq1iDN1YvEaFB70WM9yv8+cOWD1J10P8AUXg7Uu d3KfxDl68ko4FBzsZU9NLaEbMajRFGaCxnvXtxSJGl1U9LYgvqQx/IW6Dnv/hxw+DNc7 xyh9/Lsw6ejemQRkBm3B7tkQJdBZP28t3jnv/GJ1cE8nviG1on3kz0WJQA779D7/ZHkg d+2q2obCZeKvdjxdlxtQPFoHXDt8clA53AuZq04RAbbLbF7V4kgD+qAwIpZcJPgQXzUN MbiQ== X-Gm-Message-State: ACgBeo2ZISkXQFySmXOBUblmgNOJE1Kix+qq5wG8bFS0EfKsCtDQwRyx B5bwn9L4be/dyzINtrh6AaCBuWJkz8AqfrO6/KDWzouidJ8= X-Google-Smtp-Source: AA6agR6IKhf/MJKZGTBSBB+pgdBdYmyhb3O6kThOnx1eNm1Qz3WLpxH0sHC49ekh2ybTB86UZcj+WmXCVIP5RzwFg6w= X-Received: by 2002:a17:907:3ea7:b0:730:9a8b:b8f1 with SMTP id hs39-20020a1709073ea700b007309a8bb8f1mr2561906ejc.168.1660845729118; Thu, 18 Aug 2022 11:02:09 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Thu, 18 Aug 2022 14:01:58 -0400 Message-ID: Subject: Re: Impact of FreeBSD-SA-22:10.aio To: Mark Johnston Cc: Eric van Gyzen , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M7t5017qLz3M7t X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.53 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.218.53:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.53:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 18 Aug 2022 at 12:16, Mark Johnston wrote: > > The refcount implementation in 12.3 doesn't handle overflow or underflow > at all, so it is vulnerable. I believe you're right that that > mitigation converts the bug into a memory leak in 13.0, and so the > advisory erroneously lists 13.0 as vulnerable when it isn't. I suppose it is really an SA for 12.3 and an EN for 13.0. We should perhaps update the advisory text to make this clear - e.g.: III. Impact -An attacker may cause the reference count to overflow, leading to a -use after free (UAF). +On FreeBSD 12.3 an attacker may cause the reference count to overflow, +leading to a use after free (UAF). On FreeBSD 13.0 a mitigation in the +reference counting implementation limits the impact to a memory leak (which +may lead to a denial of service). From nobody Thu Aug 18 20:15:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7x3C5rG4z4ZC4B for ; Thu, 18 Aug 2022 20:15:51 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7x3B6hqXz3cpJ; Thu, 18 Aug 2022 20:15:50 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Date: Thu, 18 Aug 2022 20:15:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail3; t=1660853749; x=1661112949; bh=MT5+96ep2K7EnvaZsqfxtg6/KJCDFxqqBqS2ola/m+o=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=CiCeYewJo0KDGdQLN5gLfVMEds+xQzFQ8JpJfTKFywtxzpCUh/TaTrQflVGI1bx6H cs4c9UdJwpL9q3uSAqQcaT8jU8POOwussYUi7ahdWgPmyXdS5byG6IRU/Ze8Kzx7wA iQbW4R+JAzAPmyGtd0rio+UO1y8/VXaBQzZaj9nzKC8E01KBDbn9hFG37jWyOsTy+v hO1215xAS22oFuEQy8wK722Md/E3+Nh6rV4Z95Jt389Jr+Gy/+6ktWNtqXhIO3tGvX C81J3gJlDgayXLz9NBc6LQnaswdXA2FLHcp5GscuuWnY9jDx4rbJM36tChpRQ+NjFp EFoyWd48E7BJQ== To: Adriaan de Groot From: Lorenzo Salvadore Cc: freebsd-hackers@freebsd.org, Lorenzo Salvadore Reply-To: Lorenzo Salvadore Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2022 Message-ID: In-Reply-To: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> References: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> Feedback-ID: 8540510:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4M7x3B6hqXz3cpJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=CiCeYewJ; dmarc=pass (policy=quarantine) header.from=protonmail.ch; spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.40.133 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.985]; DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24:c]; R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[protonmail.ch:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; HAS_REPLYTO(0.00)[phascolarctos@protonmail.ch]; TO_MATCH_ENVRCPT_SOME(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Tuesday, August 16th, 2022 at 21:19, Adriaan de Groot wrote: >=20 >=20 > On Monday, 8 August 2022 23:33:31 CEST Lorenzo Salvadore wrote: >=20 > > FreeBSD Quarterly Status Report Second Quarter 2022 > >=20 > > Here is the second quarterly report of 2022, with 26 reports included. > >=20 > > This quarter the quarterly team managed to publish the report much fast= er > > and, hopefully, with much fewer mistakes. If however you notice some > > errors, please report them so that we can correct them and also add som= e > > automatic checks in our tools to prevent them in the future and stay as > > efficient as possible in the pubblication process. >=20 >=20 > <1500 lines of reports snipped> >=20 >=20 > Lorenzo, I'd like to thank you for coordinating this huge writing effort.= Pau, > as well, who is behind-the-scenes editing. Deb, for being the shadowy > supporter. Dozens of contributors to the report. This shows off just how > much happens in FreeBSD outside of one's immediate silo (which is ports, = for > me). You're welcome, it's our pleasure to keep updated the community with those reports. Thank you very much for appreciating our work, Lorenzo Salvadore From nobody Thu Aug 18 21:29:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M7yh33kxWz4ZMs9 for ; Thu, 18 Aug 2022 21:29:23 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M7yh22jz8z3nwl; Thu, 18 Aug 2022 21:29:22 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ej1-f48.google.com with SMTP id j8so5531197ejx.9; Thu, 18 Aug 2022 14:29:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Qw9rNF6j3yMTLgYK5nnrT3KX191bY/YYTK/ge9IFY7w=; b=37w+acNHhSDae8PARDsmkbgPperE1Wzz62mv0JSRPNV4LxyWTRV6EEYnGP5XBuGMqX N/yg8/p6Yga9yZK9rrdNqsmTvRAwOkiY3CsxlGECeOaFrLgkaR51xGCjSTnDrwCCf6ab 3yK/be5f5GFKBxyK74xDmZ7j0KhcZMyreEgK5+E7CdOX9xFlKfjMytfEL5/XgA31I9fZ 7gDcuCD3/ffj/Y8HF/5wKAXN7ctxvcT/Zksv6fPYW8lf2XRV46ZhI/gy2paxKWKCckEu OGCwUeSrJdz9rCX8DHTA4pIrgszRoq0RpaFdAQ/QR7/gc3zW5fKBgKZlBbEMLyA/13/F MyWQ== X-Gm-Message-State: ACgBeo2CVBKT8ly6CRGXa2aWWSAvq5JxUMH5bP5SkFVWGTBZkuvWP2Rs HqE8VRYsNmKw8rnVRkzsgTV48r0bR4qHKuPEU48mVvGU X-Google-Smtp-Source: AA6agR6BEMu+MEQfHT+FMVJC9autrqQYHu150ka332TKZKrsUd1QMcpOFqDsUTwHTNKwW+L4nT1+IbOMhsRURLOYIvI= X-Received: by 2002:a17:906:9beb:b0:730:8e6c:a8fa with SMTP id de43-20020a1709069beb00b007308e6ca8famr2893189ejc.258.1660858160147; Thu, 18 Aug 2022 14:29:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Thu, 18 Aug 2022 17:29:09 -0400 Message-ID: Subject: Re: Impact of FreeBSD-SA-22:10.aio To: Mark Johnston Cc: Eric van Gyzen , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M7yh22jz8z3nwl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.218.48:from]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.48:from]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 18 Aug 2022 at 14:01, Ed Maste wrote: > > On Thu, 18 Aug 2022 at 12:16, Mark Johnston wrote: > > > > The refcount implementation in 12.3 doesn't handle overflow or underflow > > at all, so it is vulnerable. I believe you're right that that > > mitigation converts the bug into a memory leak in 13.0, and so the > > advisory erroneously lists 13.0 as vulnerable when it isn't. > > I suppose it is really an SA for 12.3 and an EN for 13.0. Unfortunately this is not the case - crhold() does not currently use the refcount(9) API, so does not benefit from the refcount overflow mitigation that it provides. We'll address this one way or another (for example, using refcount(9) or checking for overflow explicitly) to provide a mitigation in case there's another missing crfree. From nobody Fri Aug 19 08:20:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M8F7M1Rysz4Zs7N for ; Fri, 19 Aug 2022 08:20:31 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (81-206-207-166.fixed.kpn.net [81.206.207.166]) (using TLSv1.3 with cipher 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 "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M8F7L1NZ4z3fj5 for ; Fri, 19 Aug 2022 08:20:29 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 218D541496; Fri, 19 Aug 2022 10:20:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F_kGZTSJrANB; Fri, 19 Aug 2022 10:20:22 +0200 (CEST) Received: by gvr.gvr.org (Postfix, from userid 657) id F15CD41604; Fri, 19 Aug 2022 10:20:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20220114; t=1660897221; bh=nvNRTXofo7lMylUz3nB1cVKWzzfpAeXuj1dNqIo6tR8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=sOwqqDInUJb/nOt9fjz2wIdsFhQbkV1OKKvyrK3yDmAQBPyLiY1x/A9JQGeEpf1K2 jZGoia2PQUF0A6pFnEfme6hX1OWxf7J1Jy8WW9jz47TU0LTIT+P1D2aP9KXwgZQYK3 5OWJNXyiNBg8kBaXVH15wUD5gTWzMOcjVQ55p+5zxDUPeHU+5/p+pmAzVwFnHCUag6 gNUZeb2yvFwmtrHfczpFREuwCfdCB23vCK0OX4Ykin8qoxWqDxPzIXQ9dgd1Pd4676 BWia4BEkt00qe6O6FPvllTJtuRPy/FapSRprnlZju4LNyxiw6MeTTKKKVwb4ycGSuz qDjVNJgx76bOg== Date: Fri, 19 Aug 2022 10:20:21 +0200 From: Guido van Rooij To: Warner Losh Cc: FreeBSD Hackers Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool Message-ID: References: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4M8F7L1NZ4z3fj5 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20220114 header.b=sOwqqDIn; dmarc=pass (policy=none) header.from=gvr.org; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 81.206.207.166 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-3.34 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_MIXED_CHARSET(0.66)[]; DMARC_POLICY_ALLOW(-0.50)[gvr.org,none]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20220114]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gvr.org:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[guido]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:1136, ipnet:81.204.0.0/14, country:NL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Aug 17, 2022 at 09:19:42AM -0600, Warner Losh wrote: > On Wed, Aug 17, 2022 at 7:35 AM Guido van Rooij <[1]guido@gvr.org> > wrote: > > On 16 Aug 2022, at 19:09, Warner Losh <[2]imp@bsdimp.com> wrote: > > ďťż > On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij <[3]guido@gvr.org> > wrote: > > On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: > >  On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij > <[1][4]guido@gvr.org> > >  wrote: > > > >   Currently I have a system with ZFS on GELI. I use the > ability in > >   the EFI loader to enter the GELI password. > >   Is it possible somehow to use a serial console to enter > the > >   password? > >   My system does have a COM1 port but it isn't recognised at > the early > >   bot stage. There I only see: > >   Ă Ă Consoles: EFI console > >   Ă Ă GELI Passphrase for disk0p4: > >   (Note: this is early in the boot process so there is no > access to > >   boot.config (or any other file in the ZFS pool) as it > still on > >   encrypted storage at that time). > > > >  The boot loader.efi will read ESP:/efi/freebsd/loader.env for > >  environment > >  variables. You can use that to set the COM1 port since it > appears your > >  EFI system doesn't do console redirection. > >  If you want it to only prompt COM1 for the password, but > everything > >  else is > >  on the efi console, that's a lot harder. > Hi Warner, > Thanks, but somehow I still cannot get it to work properly. > Content of /efi/freebsd/loader.env: > boot_multicons="YES" > console="efi comconsole" > The boot prompt still only shows "Consoles: EFI console". > > Yes. That's printed before we process the ESP file and switch to the > new console... >  > > When I boot I get the GELI passphrase prompt at the EFI console > only. But when the kernel starts > to run I do get output to the serial console, staring with: > ---<>--- > Copyright (c) 1992-2021 The FreeBSD Project. > So it seems the loader.env file is read correctly (it didn't output > anything to the serial > console before I created efi/freebsd/loader.env). But looking at the > source I see in > efi/loader/main.c:read_loader_env(): >     if (fn) { >         printf("  Reading loader env vars from > %s\n", fn); >         > parse_loader_efi_config(boot_img->DeviceHandle, fn); >     } > I never saw the printf appearing. I do not understand this. > > It should have appeared on the video console of the EFI console > (assuming no serial > redirect is going on in that BIOS). > > It surely did not. > > I'd have to delve more deeply into the prompts for the GELI password > than I have > time to do this morning. What if you type the password blind into the > serial port? > > Tried that but nothing happened. When I > enter the passphrase after typing it in via > the serial port, it worked immediately so > we can conclude that no single keystroke > got through. > > OK. I'll have to delve a little more deeply then... I Think I know why it does not work. The "Consoles:" line is printed in cons_probe() which is called in main(): setenv("console", "efi", 1); cons_probe(); So that explains why we see Consoles: EFI console Then we see in main(): for (i = 0; devsw[i] != NULL; i++) if (devsw[i]->dv_init != NULL) (devsw[i]->dv_init)(); The way I understand it, is this the place where the GELI passphrase prompt originates from. But only after that, we see the call to load /efi/freebsd/loader.env Shouldn't the dv_init() calls be moved to after the call to boot_howto_to_env(howto)? Regards, -Guido From nobody Fri Aug 19 14:55:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M8PvV63kYz4ZKX8 for ; Fri, 19 Aug 2022 14:55:50 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M8PvV1GWMz4J6N for ; Fri, 19 Aug 2022 14:55:50 +0000 (UTC) (envelope-from harris.snyder@gmail.com) Received: by mail-lf1-x133.google.com with SMTP id u9so6416826lfg.11 for ; Fri, 19 Aug 2022 07:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=a6eEkSQwE0cxin9k30CBrzO5c+5pa987tYg6uravOvA=; b=Sp5QhREpGonMAo4L0/PouFoVEeXQyMhtXT0w6Y8tYbcYcltEoIzDMkaUgUCCSuIacC UjJtqN1xhh3f63Jm1GqHfXXUf0wIGifyWUm3lR4q72p+u7KsFMVM57/pHrTxKmI7a7T9 Z96ADOLUiulO/yHx25iMrQQ8Pi4JEywubYBTp1rC6oyip+RFwvc+yBgVtUcelPyI4gJe 3ceZNTCek2UU9x03hOxGJjdJgm3y+dZKBhUfipJ/gIVGt4oHe+maqINbHwUG38VgoBK9 eyM6GsjjxW+LAO/U7BhBJNUfFQkpHyx+OP3X9srbWiDvOKFkr0mZLaL1L8GXzSHisqtd yzwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=a6eEkSQwE0cxin9k30CBrzO5c+5pa987tYg6uravOvA=; b=om4LsGUaYyu51zYBJm0FSILkElqRiAryOBxe0f4/K4lXEWe5+mNNGO1vMwAJvD2BZl IjA20T7TcO442cJ4bkovEzTYDa5ULFPeksL4VKAd2AmiSN/xgOudKtEaJqAGWF+yUV6/ ORiYcbMYWW0KoRa8nAY07FQ+mfS4sTofjD+53ZMEHDq6GafkP0LJNue+dJZ9rhP4EpUO 6m4Mqa9Pac2bSwnHDN32iA8hvbpGF2YNXa8+ebsmCWyuIAlB7co4vC437HsG2OeRFvWG eWarTMtncDP+B6rrMeJG4UYnGNES95evbYybX4G/dRPgWB+Vylqz+Edex72heO4SeNYa HDFQ== X-Gm-Message-State: ACgBeo0fDFCFu8DGB1Z+n8uTAyMQc3Cfigoy4vnirA0kPnkFOMAnsS8h LZRB4UUQWI+9G7q33CCK/CpKaAGhuViTilq2FMf+B0PwOC8= X-Google-Smtp-Source: AA6agR6v1qubPIj/mO66N8NybVwIy+hVrBz/pXJG7iBrCihZAK9HB7g4RuD9Ar4XGG8h8VncQOsKT5mLdRMTHsXrAmo= X-Received: by 2002:a05:6512:250b:b0:492:c03c:a114 with SMTP id be11-20020a056512250b00b00492c03ca114mr2470410lfb.592.1660920948403; Fri, 19 Aug 2022 07:55:48 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2c108a487ff68d38f448dc5e001faad2@FreeBSD.org> In-Reply-To: <2c108a487ff68d38f448dc5e001faad2@FreeBSD.org> From: Harris Snyder Date: Fri, 19 Aug 2022 10:55:36 -0400 Message-ID: Subject: Re: Strange behavior of USB PCIe add-in cards To: Daniel Engberg Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M8PvV1GWMz4J6N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Sp5QhREp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of harris.snyder@gmail.com designates 2a00:1450:4864:20::133 as permitted sender) smtp.mailfrom=harris.snyder@gmail.com X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.997]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::133:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Daniel, Thanks very much for your reply. Re-reading my initial email, it's obviously missing some information, for which I apologize. Chiefly, - I do want to go with a PCIe card instead of a hub, because the ultimate goal is to use the card with PCIe passthrough in bhyve. - Also, I am indeed on an AMD x86_64 system (Epyc rather than Ryzen, but very likely suffers from the same issue you've mentioned) I'll definitely search the mailing list for other people's reports of this. The motherboard is a supermicro H11DSi and the CPUs are 2x Epyc 7003. There's no chipset on the motherboard in the traditional sense for desktop PCs. I have ordered a third controller (built around the Renesas uPD720202, which is also on the old side I think) based on several recommendations, so we will see if that chip fares any better. In the meantime, I will try: - Updating the firmware on both of the cards that I have (I'm willing to accept the bricking risk). - Checking the bios for PCI timer latency - Searching the mailing list for reports of usb stuttering on Ryzen systems and possible solutions. Thank you very much for all of your suggestions! Harris On Wed, Aug 17, 2022 at 1:08 PM Daniel Engberg wrote: > > On 2022-08-12 22:34, Harris Snyder wrote: > > Hello everyone, > > > > I have two USB3 PCIe cards (different chipset vendors) that are both > > exhibiting the same symptoms: > > - They are detected and attached to the xhci driver. > > - They sort of work (a usb stick seems to work for file IO) > > - When an interactive device (e.g. USB sound card, mouse, or keyboard) > > is connected, they seem to drop the overwhelming majority of input > > events. For example, the mouse moves jerkily, at intervals of several > > seconds. Most keypresses on a keyboard are missed, and occasionally a > > "key up" event seems to be missed and the same key is typed > > repeatedly. A USB sound card has stutters and hitches in the audio > > output. > > > > Does anybody recognize this behaviour or know of a solution? I have > > tried: > > - A different PCIe slot > > - Two different PCIe USB3 cards from different vendors (and different > > chipset vendors - VIA and ASMedia). One of the cards uses the VIA > > VL806, which some users on the FreeBSD forum have reported working... > > > > I'm using CURRENT, but about 2 weeks behind... > > > > Thanks, > > Harris > > Hi, > > Early USB 3 controllers were quite unstable and unreliable so unless > you're on very old hardware I'd suggest that you look for a decent USB > hub instead if you need more ports. In my experience VIA (Labs) VL817 > works very well in general, one device that uses it is ORICO MH4U-U3 or > at least used to. You might want to go for the newer VL822 controller > however finding out what chipset is used can be a bit hard but according > to the product images this one uses it for example > https://www.amazon.com/HOYOKI-Powered-Adapter-Slippter-Keyboard/dp/B098D7H5XD > . I've also used one hub based on ASMedia ASM1074 which worked fine for > my use case but the quality of the product was very questionable, this > controller doesn't seem to be very common and if you find one it's > usually a very poorly made product overall. There are other vendors too > such as Cypress, Fresco Logic, Genesys Logic etc but when I looked > they're either very rare (Cypress and Fresco Logic) or people have very > mixed experiences (Genesys Logic) however their newer ones might be > better such as GL3590. > > But if you want to give the USB PCIe cards a go the VIA one your > mentioned is very old so I would highly suggest that you try to update > the firmware. Unforunately that usually requires you to search various > forums etc to find the flashing utility and firmware. Having a quick > look this page ( https://github.com/jpmorrison/VL805 ) seems to be > relevent and the other ones it links too. Do keep in mind that you may > brick your card if you flash using wrong firmware or if it process hangs > for whatever reason. This is also true for your ASMedia card, some > controllers even include "easter eggs". See > https://github.com/smx-smx/ASMTool , > https://github.com/cyrozap/asmedia-xhc-re for more information. In some > BIOSes you have a toggle for "PCI Timer Latency" option, usually you > want to keep this at 32 or 64 which usually is the default may also be a > cause. > > Regarding your peripherals, are they known to be working and/or have > your tried using the motherboard chipset controller instead? There are > also reports of stuttering using Ryzen systems which may be what you're > using (search the mailing lists for more information). > > Providing what hardware (mainboard, cpu) are you using and arch (i386, > amd64) would also be helpful in trying to debug your issue. > > Best regards, > Daniel From nobody Fri Aug 19 15:07:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M8Q9638lfz4ZLbN for ; Fri, 19 Aug 2022 15:07:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M8Q955k6mz4LFH for ; Fri, 19 Aug 2022 15:07:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa36.google.com with SMTP id w129so2362382vkg.10 for ; Fri, 19 Aug 2022 08:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=akf8cEe/d0s1gg2a8CXhKrY6+gpr4z8hkax4VEquunk=; b=8VOnBJ3Jns/qyYqof0SkN13aAksVh5asExhaUKSduXHAADoU/c8h2IRvLk1BQ0boPw h3n7g78sKGd2hCF7jC/57tHZlL9tZHlus4xPnZqdOhip/jVwnO2kFekLHLNekgO0eNuU NnhZuBORX0vOhu85crLfmI/xof/+4Zbs/WqaRxXv6nEaRLup/wC5r0qDGM7jsCAj0i5A 3Rlycyk39rqq/cV3G3qqimyDLY1T2z+rWXhXKhmnWfvncIIwPrTxHhZr0kULrzq/TTGS QLrkiadpxGpJ8a9DHt23wt5EzUXJTrPWuMd1KQt+DG6cArLuzEwvwLWaShFTTsApQQJo M1xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=akf8cEe/d0s1gg2a8CXhKrY6+gpr4z8hkax4VEquunk=; b=2OH46zTT+1OaOEbkLOtn5LGF6SiM54v5JJrma6Q7oeKZ/AjNtlrXwonkzO8f0mmz4O 8LPtqigVouhl4xCIcBwz/i0aO4oLpNaOltFQloMx2ScT5Qwl4Psw8ZZQ3miIGLI00K1w 4aq9tbfPxQlv4jeqGMYFKv5uvHz0LxgD4sq10XFgWJLsOZpNDhgt+Op5TwDBVZKx56bE 8H0oCnHRgKrvQfTBKuDF9dho1108+b4EnHCxwRPD216RGLmc2V2dacD/4h047xqz77bB htmB4ttAM1J7fEgBXJ1UqyYiEv+teiP3ViJK8oCfH89hw/hoTLQ+X+RrgwayHYner5oM ytcQ== X-Gm-Message-State: ACgBeo3vSQSI6fEYooEHoMDHyp6ELtHOTKjUTZcWIN4000sKnDrU6U1b j9Ibd5yPA3/9LGjhvNXJSm878YxsFv+gTXaQNhvwFzB56CI= X-Google-Smtp-Source: AA6agR7T7Jfxnmx5CmHohqvAvS11necb//HqYEyprv0b4T6cWf8ejUKGvVSD651IYhfsS18gWp3oV8Dizd5qTAhLk8M= X-Received: by 2002:a1f:e3c5:0:b0:380:68eb:e647 with SMTP id a188-20020a1fe3c5000000b0038068ebe647mr3382493vkh.11.1660921656858; Fri, 19 Aug 2022 08:07:36 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> In-Reply-To: From: Warner Losh Date: Fri, 19 Aug 2022 09:07:25 -0600 Message-ID: Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool To: Guido van Rooij Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000005b6f6205e699756c" X-Rspamd-Queue-Id: 4M8Q955k6mz4LFH X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=8VOnBJ3J; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a36) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; R_MIXED_CHARSET(0.50)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a36:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000005b6f6205e699756c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 19, 2022 at 2:20 AM Guido van Rooij wrote: > On Wed, Aug 17, 2022 at 09:19:42AM -0600, Warner Losh wrote: > > On Wed, Aug 17, 2022 at 7:35 AM Guido van Rooij <[1]guido@gvr.org> > > wrote: > > > > On 16 Aug 2022, at 19:09, Warner Losh <[2]imp@bsdimp.com> wrote: > > > > =C3=AF=C2=BB=C2=BF > > On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij <[3]guido@gvr.org> > > wrote: > > > > On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh wrote: > > >=C3=82 =C3=82 On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij > > <[1][4]guido@gvr.org> > > >=C3=82 =C3=82 wrote: > > > > > >=C3=82 =C3=82 =C3=82 Currently I have a system with ZFS on GEL= I. I use the > > ability in > > >=C3=82 =C3=82 =C3=82 the EFI loader to enter the GELI password= . > > >=C3=82 =C3=82 =C3=82 Is it possible somehow to use a serial co= nsole to enter > > the > > >=C3=82 =C3=82 =C3=82 password? > > >=C3=82 =C3=82 =C3=82 My system does have a COM1 port but it is= n't recognised at > > the early > > >=C3=82 =C3=82 =C3=82 bot stage. There I only see: > > >=C3=82 =C3=82 =C3=82 =C3=83=C3=82 =C3=83=C3=82 Consoles: EFI= console > > >=C3=82 =C3=82 =C3=82 =C3=83=C3=82 =C3=83=C3=82 GELI Passphra= se for disk0p4: > > >=C3=82 =C3=82 =C3=82 (Note: this is early in the boot process = so there is no > > access to > > >=C3=82 =C3=82 =C3=82 boot.config (or any other file in the ZFS= pool) as it > > still on > > >=C3=82 =C3=82 =C3=82 encrypted storage at that time). > > > > > >=C3=82 =C3=82 The boot loader.efi will read ESP:/efi/freebsd/lo= ader.env for > > >=C3=82 =C3=82 environment > > >=C3=82 =C3=82 variables. You can use that to set the COM1 port = since it > > appears your > > >=C3=82 =C3=82 EFI system doesn't do console redirection. > > >=C3=82 =C3=82 If you want it to only prompt COM1 for the passwo= rd, but > > everything > > >=C3=82 =C3=82 else is > > >=C3=82 =C3=82 on the efi console, that's a lot harder. > > Hi Warner, > > Thanks, but somehow I still cannot get it to work properly. > > Content of /efi/freebsd/loader.env: > > boot_multicons=3D"YES" > > console=3D"efi comconsole" > > The boot prompt still only shows "Consoles: EFI console". > > > > Yes. That's printed before we process the ESP file and switch to the > > new console... > > =C3=82 > > > > When I boot I get the GELI passphrase prompt at the EFI console > > only. But when the kernel starts > > to run I do get output to the serial console, staring with: > > ---<>--- > > Copyright (c) 1992-2021 The FreeBSD Project. > > So it seems the loader.env file is read correctly (it didn't outpu= t > > anything to the serial > > console before I created efi/freebsd/loader.env). But looking at t= he > > source I see in > > efi/loader/main.c:read_loader_env(): > > =C3=82 =C3=82 =C3=82 =C3=82 if (fn) { > > =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 pr= intf("=C3=82 =C3=82 Reading loader env vars from > > %s\n", fn); > > =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 =C3=82 > > parse_loader_efi_config(boot_img->DeviceHandle, fn); > > =C3=82 =C3=82 =C3=82 =C3=82 } > > I never saw the printf appearing. I do not understand this. > > > > It should have appeared on the video console of the EFI console > > (assuming no serial > > redirect is going on in that BIOS). > > > > It surely did not. > > > > I'd have to delve more deeply into the prompts for the GELI password > > than I have > > time to do this morning. What if you type the password blind into th= e > > serial port? > > > > Tried that but nothing happened. When I > > enter the passphrase after typing it in via > > the serial port, it worked immediately so > > we can conclude that no single keystroke=C3=82 > > got through. > > > > OK. I'll have to delve a little more deeply then... > > I Think I know why it does not work. The "Consoles:" line is printed in > cons_probe() > which is called in main(): > setenv("console", "efi", 1); > cons_probe(); > So that explains why we see Consoles: EFI console > Then we see in main(): > for (i =3D 0; devsw[i] !=3D NULL; i++) > if (devsw[i]->dv_init !=3D NULL) > (devsw[i]->dv_init)(); > The way I understand it, is this the place where the GELI passphrase > prompt originates > from. > Well, not quite. We prompt for the GELI password when we first open a device in devopen (at least that's where we call geli_probe_and_attach())[*]. This should be a bit later, though. I'll have to put some debug prints in to see when it's called... But it looks like we probe for geli, according to the debug, at this point, so something needs to be done to sort out this chicken and egg problem. > But only after that, we see the call to load /efi/freebsd/loader.env > > Shouldn't the dv_init() calls be moved to after the call to > boot_howto_to_env(howto)? > You have discovered a wonderful chicken and egg. If we don't call dv_init we can't do I/O to the devices, so we can't change the console. But, the boot_hwoto_to_env() call only sets env variables that will be used to either set boot args to the kernel or other env variables that are used to communicate the console. It doesn't actually change the console, so is the wrong thing to locate. The likely best way to approach this is to fix loader.efi to initialize enough of the devices so that we can read files off the ESP early enough to set a good console for further interaction. Warner [*] this leads to a bit of a layering violation that causes a circular dependency, but I digress... --0000000000005b6f6205e699756c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Aug 19, 2022 at 2:20 AM Guido= van Rooij <guido@gvr.org> wrote= :
On Wed, Aug 17= , 2022 at 09:19:42AM -0600, Warner Losh wrote:
>=C2=A0 =C2=A0 On Wed, Aug 17, 2022 at 7:35 AM Guido van Rooij <[1]guido@gvr.org>
>=C2=A0 =C2=A0 wrote:
>
>=C2=A0 =C2=A0 =C2=A0 On 16 Aug 2022, at 19:09, Warner Losh <[2]imp@bsdimp.com> wrote= :
>
>=C2=A0 =C2=A0 =C3=AF=C2=BB=C2=BF
>=C2=A0 =C2=A0 On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij <[3]guido@gvr.org>
>=C2=A0 =C2=A0 wrote:
>
>=C2=A0 =C2=A0 =C2=A0 On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner L= osh wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 On Mon, Aug 15, 2022= at 8:23 AM Guido van Rooij
>=C2=A0 =C2=A0 =C2=A0 <[1][4]guido@gvr.org>
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 Current= ly I have a system with ZFS on GELI. I use the
>=C2=A0 =C2=A0 =C2=A0 ability in
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 the EFI= loader to enter the GELI password.
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 Is it p= ossible somehow to use a serial console to enter
>=C2=A0 =C2=A0 =C2=A0 the
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 passwor= d?
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 My syst= em does have a COM1 port but it isn't recognised at
>=C2=A0 =C2=A0 =C2=A0 the early
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 bot sta= ge. There I only see:
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=83= =C3=82=C2=A0 =C3=83=C3=82=C2=A0 Consoles: EFI console
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=83= =C3=82=C2=A0 =C3=83=C3=82=C2=A0 GELI Passphrase for disk0p4:
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 (Note: = this is early in the boot process so there is no
>=C2=A0 =C2=A0 =C2=A0 access to
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 boot.co= nfig (or any other file in the ZFS pool) as it
>=C2=A0 =C2=A0 =C2=A0 still on
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 encrypt= ed storage at that time).
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 The boot loader.efi = will read ESP:/efi/freebsd/loader.env for
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 environment
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 variables. You can u= se that to set the COM1 port since it
>=C2=A0 =C2=A0 =C2=A0 appears your
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 EFI system doesn'= ;t do console redirection.
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 If you want it to on= ly prompt COM1 for the password, but
>=C2=A0 =C2=A0 =C2=A0 everything
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 else is
>=C2=A0 =C2=A0 =C2=A0 >=C3=82=C2=A0 =C3=82=C2=A0 on the efi console, = that's a lot harder.
>=C2=A0 =C2=A0 =C2=A0 Hi Warner,
>=C2=A0 =C2=A0 =C2=A0 Thanks, but somehow I still cannot get it to work = properly.
>=C2=A0 =C2=A0 =C2=A0 Content of /efi/freebsd/loader.env:
>=C2=A0 =C2=A0 =C2=A0 boot_multicons=3D"YES"
>=C2=A0 =C2=A0 =C2=A0 console=3D"efi comconsole"
>=C2=A0 =C2=A0 =C2=A0 The boot prompt still only shows "Consoles: E= FI console".
>
>=C2=A0 =C2=A0 Yes. That's printed before we process the ESP file an= d switch to the
>=C2=A0 =C2=A0 new console...
>=C2=A0 =C2=A0 =C3=82
>
>=C2=A0 =C2=A0 =C2=A0 When I boot I get the GELI passphrase prompt at th= e EFI console
>=C2=A0 =C2=A0 =C2=A0 only. But when the kernel starts
>=C2=A0 =C2=A0 =C2=A0 to run I do get output to the serial console, star= ing with:
>=C2=A0 =C2=A0 =C2=A0 ---<<BOOT>>---
>=C2=A0 =C2=A0 =C2=A0 Copyright (c) 1992-2021 The FreeBSD Project.
>=C2=A0 =C2=A0 =C2=A0 So it seems the loader.env file is read correctly = (it didn't output
>=C2=A0 =C2=A0 =C2=A0 anything to the serial
>=C2=A0 =C2=A0 =C2=A0 console before I created efi/freebsd/loader.env). = But looking at the
>=C2=A0 =C2=A0 =C2=A0 source I see in
>=C2=A0 =C2=A0 =C2=A0 efi/loader/main.c:read_loader_env():
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2= =A0 if (fn) {
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 printf("=C3=82= =C2=A0 =C3=82=C2=A0 Reading loader env vars from
>=C2=A0 =C2=A0 =C2=A0 %s\n", fn);
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2= =A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82
>=C2=A0 =C2=A0 =C2=A0 parse_loader_efi_config(boot_img->DeviceHandle,= fn);
>=C2=A0 =C2=A0 =C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2=A0 =C3=82=C2= =A0 }
>=C2=A0 =C2=A0 =C2=A0 I never saw the printf appearing. I do not underst= and this.
>
>=C2=A0 =C2=A0 It should have appeared on the video console of the EFI c= onsole
>=C2=A0 =C2=A0 (assuming no serial
>=C2=A0 =C2=A0 redirect is going on in that BIOS).
>
>=C2=A0 =C2=A0 It surely did not.
>
>=C2=A0 =C2=A0 I'd have to delve more deeply into the prompts for th= e GELI password
>=C2=A0 =C2=A0 than I have
>=C2=A0 =C2=A0 time to do this morning. What if you type the password bl= ind into the
>=C2=A0 =C2=A0 serial port?
>
>=C2=A0 =C2=A0 Tried that but nothing happened. When I
>=C2=A0 =C2=A0 enter the passphrase after typing it in via
>=C2=A0 =C2=A0 the serial port, it worked immediately so
>=C2=A0 =C2=A0 we can conclude that no single keystroke=C3=82
>=C2=A0 =C2=A0 got through.
>
>=C2=A0 =C2=A0 OK. I'll have to delve a little more deeply then...
I Think I know why it does not work. The "Consoles:" line is prin= ted in cons_probe()
which is called in main():
=C2=A0 =C2=A0 =C2=A0 =C2=A0 setenv("console", "efi", 1)= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cons_probe();
So that explains why we see Consoles: EFI console
Then we see in main():
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (i =3D 0; devsw[i] !=3D NULL; i++)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (devsw[i]->dv= _init !=3D NULL)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (devsw[i]->dv_init)();
The way I understand it, is this the place where the GELI passphrase prompt= originates
from.

Well, not quite. We prompt for th= e GELI password when we first open a device in devopen
(at least = that's where we call geli_probe_and_attach())[*]. This should be a bit = later, though.
I'll have to put some debug prints in to see w= hen it's called... But it looks like we probe for
geli, accor= ding to the debug, at this point, so something needs to be done to sort out= this
chicken and egg problem.
=C2=A0
But only after that, we see the call to load /efi/freebsd/loader.env

Shouldn't the dv_init() calls be moved to after the call to boot_howto_= to_env(howto)?

You have discovered a wo= nderful chicken and egg. If we don't call dv_init we can't do I/O
to the devices, so we can't change the console.

=
But, the boot_hwoto_to_env() call only sets env variables that w= ill be used to either set
boot args to the kernel or other env va= riables that are used to communicate the console.
It doesn't = actually change the console, so is the wrong thing to locate.
The likely best way to approach this is to fix loader.efi to in= itialize enough of the devices
so that we can read files off the = ESP early enough to set a good console for further
interaction.

Warner

[*] this leads to a= bit of a layering violation that causes a circular dependency, but I digre= ss...
--0000000000005b6f6205e699756c-- From nobody Sat Aug 20 02:56:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M8jvG62vsz4Z0Ly for ; Sat, 20 Aug 2022 02:56:42 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4M8jvF3nP9z3QlK; Sat, 20 Aug 2022 02:56:41 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 76A6A4C20BE; Fri, 19 Aug 2022 21:56:39 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 20 Aug 2022 02:56:39 +0000 From: Pau Amma To: Adriaan de Groot Cc: freebsd-hackers@freebsd.org, Lorenzo Salvadore Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2022 In-Reply-To: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> References: <3154895.pkS5VuaG3T@beastie.bionicmutton.org> User-Agent: Roundcube Webmail/1.4.8 Message-ID: X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4M8jvF3nP9z3QlK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; RWL_MAILSPIKE_GOOD(-0.10)[75.145.166.65:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; HAS_ORG_HEADER(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[pauamma]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-08-16 19:19, Adriaan de Groot wrote: > On Monday, 8 August 2022 23:33:31 CEST Lorenzo Salvadore wrote: >> FreeBSD Quarterly Status Report Second Quarter 2022 >> > <1500 lines of reports snipped> > > Lorenzo, I'd like to thank you for coordinating this huge writing > effort. Pau, > as well, who is behind-the-scenes editing. Thank you. (BTW, I don't remember whether I mentioned whether I mentioned this to you or this list before, but my preferred form of this name is "Pau Amma". It's actually a single name in 2 words, not a first name, last name pair. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Sat Aug 20 08:09:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M8rr36Y38z4ZdVF for ; Sat, 20 Aug 2022 08:09:23 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M8rr33ldwz3qt7 for ; Sat, 20 Aug 2022 08:09:23 +0000 (UTC) (envelope-from obiwac@gmail.com) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-335624d1e26so175174977b3.4 for ; Sat, 20 Aug 2022 01:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=ErL8UCfpsIBKCTOu3kzo6jIwn0RUUUHSBMQ92rlhT9o=; b=nxjYC0V4oWr2EK8GrVQibnme5aZ9D666mAkOlj1AyseI121ZLQpJSZLr1Wj1hkKrwu Ud8KPy8bisnQ9qyc8mQJVxfSDdlxzGET/sHAvYCzhh0RWQN4OxRs/mnC2YG/9D+ti1yX RDmkdinlbcq1xf+foiKKHD0SaUANR5G6dZ4mO/27Lyy1IZzm42/0EOr+6OVVTaUff6Tv CdLKj7D3RO+Vt1DlNrrbQeb8UrMDOurCAu0hgtpA22YtQckY6D82SVcOs7wlmZR5yiQ6 PKGG5rSXUCI1UE4Vu8N4V2JjS22MonZilnYG17hnqstMXBgbOT8eLgPBYlkHgBUL5X16 w36A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=ErL8UCfpsIBKCTOu3kzo6jIwn0RUUUHSBMQ92rlhT9o=; b=HKB+EO9jINyNIgY0b5TGDpcWm6ZdUAyjyasDbjOzTpGcttvoD0UiE8s0QMoOeBfakw OmH2CiuCycV3MP/m57uvvj/rQpx63qTULswhz+PRsrspOX+SGOzOTjY//cO/1jiZpYXs H+FH5o58MwDIfxYvnDaNcC0tfM7cQfdwvPlcQIS8IAfXBRUk6t84suifWtjoAsOfxXxF JkH+gwbP+9hTS0gn+DE7CInJynfNS2xzic8KMxn+FI+ydh3XghYvuFdJXugWej1oSMZR jD2j5ckulr3Kpp7gLJgE/vb0x+H0WV0xxXMdiuUoD6XJ9J2+pxEnaLrxp8Kp28T1CuYS z5ug== X-Gm-Message-State: ACgBeo0wKlPhpQeQybcrxJqcEAEtd992q+v5HDGw/krfxuKjzgCt5Ase +NXqo5ODns+5OD1lVNJzMk5DrmAZG+jEDPRffennMTMo X-Google-Smtp-Source: AA6agR4xJhqnVutDo8F3kUuRBwDDu8+7IHlGyNPVJz4giuc23kqbHRETjQrZsAvB7XGug5dE40e17NkYYY8PydI2H40= X-Received: by 2002:a25:d501:0:b0:671:7124:7749 with SMTP id r1-20020a25d501000000b0067171247749mr10755138ybe.23.1660982962635; Sat, 20 Aug 2022 01:09:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: obiwac Date: Sat, 20 Aug 2022 10:09:10 +0200 Message-ID: Subject: Call for testing/review of D35807 (libc: Add `strverscmp(3)` & `versionsort(3)`) To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000077491805e6a7bb7a" X-Rspamd-Queue-Id: 4M8rr33ldwz3qt7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=nxjYC0V4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of obiwac@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=obiwac@gmail.com X-Spamd-Result: default: False [-3.94 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; NEURAL_HAM_LONG(-0.96)[-0.955]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000077491805e6a7bb7a Content-Type: text/plain; charset="UTF-8" What's up, I've written a small patch to introduce strverscmp(3) & versionsort(3) (for scandir(3)) to FreeBSD's libc (in preparation for a future patch to add a '-v' flag to ls(1)), similar to what already exists in glibc: https://reviews.freebsd.org/D35807 As lwshu@ suggested, I'm writing this little message to call for a few more eyes on said code to make sure I didn't egregiously mess up somewhere :) Thank you for your time and have an excellent weekend, Aymeric --00000000000077491805e6a7bb7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's up,

I've written a small patch to introduce strverscmp(3) & versions= ort(3) (for scandir(3)) to FreeBSD's libc (in preparation for a future = patch to add a '-v' flag to ls(1)), similar to what already exists = in glibc: https://reviews.fr= eebsd.org/D35807

As = lwshu@ suggested, I'm writing this little message to call for a few mor= e eyes on said code to make sure I didn't egregiously mess up somewhere= :)

Thank you for your t= ime and have an excellent weekend,
Aymeric


--00000000000077491805e6a7bb7a-- From nobody Sun Aug 21 11:11:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M9Xqz1VnGz4ZWh8 for ; Sun, 21 Aug 2022 11:11:43 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (2a02-a44b-36d-100--2.fixed6.kpn.net [IPv6:2a02:a44b:36d:100::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gvr.gvr.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M9Xqx5J2yz3tDK for ; Sun, 21 Aug 2022 11:11:41 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (localhost [127.0.0.1]) by gvr.gvr.org (Postfix) with ESMTP id 5042642238; Sun, 21 Aug 2022 13:11:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at gvr.org Received: from gvr.gvr.org ([127.0.0.1]) by gvr.gvr.org (gvr.gvr.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2m8WhHK6gjSc; Sun, 21 Aug 2022 13:11:22 +0200 (CEST) Received: by gvr.gvr.org (Postfix, from userid 657) id 1BD1D4207E; Sun, 21 Aug 2022 13:11:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gvr.org; s=20220114; t=1661080282; bh=9E/uFxe/7klnoYy9FZO3hapuvQ5xm51eOkG38y98Fyo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=tjt2PyB0cVdSMg7Bg1WxxOc1rGkXpjYMQOLiwSi6Q4qwfKhsKkgXRFzQdGhJCCWte I0uBSH1+rQUWbf/iF0U6OORuWeC6LbcKMu7PBGGbXj9C/y4w9rXBqYSz4kaTSIDm8i sckwXLh2wK67w1EEvMzblf9uUSblHYgNQiRY5RTmIJAbUleH9X/Mr95NRfqbkXu1M3 97z+6Uhj3JnOSZ2tuTuTmfzNcKojz1Vgfl9dsOqdJHSeXL8xw6nSdzqCwOzb2znH9L XOL7aLnDQ0f2WPN6UEZ7u8UMQQ4qr1L9WfsRM/105sh4rXVhUa9GzQqHePp/mEBvHk muwCelzGr0b3A== Date: Sun, 21 Aug 2022 13:11:22 +0200 From: Guido van Rooij To: Warner Losh Cc: FreeBSD Hackers Subject: Re: How to use serial console to enter GELI password to boot kernel on a GELI encrypted ZFS pool Message-ID: References: <1BFD8C02-370F-4E59-BC89-EEF970B44934@gvr.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4M9Xqx5J2yz3tDK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gvr.org header.s=20220114 header.b=tjt2PyB0; dmarc=pass (policy=none) header.from=gvr.org; spf=pass (mx1.freebsd.org: domain of guido@gvr.org designates 2a02:a44b:36d:100::2 as permitted sender) smtp.mailfrom=guido@gvr.org X-Spamd-Result: default: False [-2.20 / 15.00]; R_MIXED_CHARSET(1.80)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gvr.org,none]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[gvr.org:s=20220114]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gvr.org:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[guido]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:1136, ipnet:2a02:a400::/25, country:NL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Aug 19, 2022 at 09:07:25AM -0600, Warner Losh wrote: > On Fri, Aug 19, 2022 at 2:20 AM Guido van Rooij <[1]guido@gvr.org> > wrote: > > On Wed, Aug 17, 2022 at 09:19:42AM -0600, Warner Losh wrote: > >  On Wed, Aug 17, 2022 at 7:35 AM Guido van Rooij > <[1][2]guido@gvr.org> > >  wrote: > > > >   On 16 Aug 2022, at 19:09, Warner Losh > <[2][3]imp@bsdimp.com> wrote: > > > >  ï¿ > >  On Tue, Aug 16, 2022 at 3:44 AM Guido van Rooij > <[3][4]guido@gvr.org> > >  wrote: > > > >   On Mon, Aug 15, 2022 at 02:20:32PM -0600, Warner Losh > wrote: > >   >Ă Ă On Mon, Aug 15, 2022 at 8:23 AM Guido van Rooij > >   <[1][4][5]guido@gvr.org> > >   >Ă Ă wrote: > >   > > >   >Ă Ă Ă Currently I have a system with ZFS on GELI. I > use the > >   ability in > >   >Ă Ă Ă the EFI loader to enter the GELI password. > >   >Ă Ă Ă Is it possible somehow to use a serial > console to enter > >   the > >   >Ă Ă Ă password? > >   >Ă Ă Ă My system does have a COM1 port but it isn't > recognised at > >   the early > >   >Ă Ă Ă bot stage. There I only see: > >   >Ă Ă Ă ĂĂ ĂĂ Consoles: EFI console > >   >Ă Ă Ă ĂĂ ĂĂ GELI Passphrase for disk0p4: > >   >Ă Ă Ă (Note: this is early in the boot process so > there is no > >   access to > >   >Ă Ă Ă boot.config (or any other file in the ZFS > pool) as it > >   still on > >   >Ă Ă Ă encrypted storage at that time). > >   > > >   >Ă Ă The boot loader.efi will read > ESP:/efi/freebsd/loader.env for > >   >Ă Ă environment > >   >Ă Ă variables. You can use that to set the COM1 port > since it > >   appears your > >   >Ă Ă EFI system doesn't do console redirection. > >   >Ă Ă If you want it to only prompt COM1 for the > password, but > >   everything > >   >Ă Ă else is > >   >Ă Ă on the efi console, that's a lot harder. > >   Hi Warner, > >   Thanks, but somehow I still cannot get it to work > properly. > >   Content of /efi/freebsd/loader.env: > >   boot_multicons="YES" > >   console="efi comconsole" > >   The boot prompt still only shows "Consoles: EFI console". > > > >  Yes. That's printed before we process the ESP file and switch > to the > >  new console... > >  à > > > >   When I boot I get the GELI passphrase prompt at the EFI > console > >   only. But when the kernel starts > >   to run I do get output to the serial console, staring > with: > >   ---<>--- > >   Copyright (c) 1992-2021 The FreeBSD Project. > >   So it seems the loader.env file is read correctly (it > didn't output > >   anything to the serial > >   console before I created efi/freebsd/loader.env). But > looking at the > >   source I see in > >   efi/loader/main.c:read_loader_env(): > >   Ă Ă Ă Ă if (fn) { > >   Ă Ă Ă Ă Ă Ă Ă Ă printf("Ă Ă Reading > loader env vars from > >   %s\n", fn); > >   Ă Ă Ă Ă Ă Ă Ă à > >   parse_loader_efi_config(boot_img->DeviceHandle, fn); > >   Ă Ă Ă Ă } > >   I never saw the printf appearing. I do not understand > this. > > > >  It should have appeared on the video console of the EFI > console > >  (assuming no serial > >  redirect is going on in that BIOS). > > > >  It surely did not. > > > >  I'd have to delve more deeply into the prompts for the GELI > password > >  than I have > >  time to do this morning. What if you type the password blind > into the > >  serial port? > > > >  Tried that but nothing happened. When I > >  enter the passphrase after typing it in via > >  the serial port, it worked immediately so > >  we can conclude that no single keystrokeĂ > >  got through. > > > >  OK. I'll have to delve a little more deeply then... > I Think I know why it does not work. The "Consoles:" line is printed > in cons_probe() > which is called in main(): >     setenv("console", "efi", 1); >     cons_probe(); > So that explains why we see Consoles: EFI console > Then we see in main(): >     for (i = 0; devsw[i] != NULL; i++) >         if (devsw[i]->dv_init != NULL) >             (devsw[i]->dv_init)(); > The way I understand it, is this the place where the GELI passphrase > prompt originates > from. > > Well, not quite. We prompt for the GELI password when we first open a > device in devopen > (at least that's where we call geli_probe_and_attach())[*]. This should > be a bit later, though. > I'll have to put some debug prints in to see when it's called... But it > looks like we probe for > geli, according to the debug, at this point, so something needs to be > done to sort out this > chicken and egg problem. >  > > But only after that, we see the call to load /efi/freebsd/loader.env > Shouldn't the dv_init() calls be moved to after the call to > boot_howto_to_env(howto)? > > You have discovered a wonderful chicken and egg. If we don't call > dv_init we can't do I/O > to the devices, so we can't change the console. > But, the boot_hwoto_to_env() call only sets env variables that will be > used to either set > boot args to the kernel or other env variables that are used to > communicate the console. > It doesn't actually change the console, so is the wrong thing to > locate. > The likely best way to approach this is to fix loader.efi to initialize > enough of the devices > so that we can read files off the ESP early enough to set a good > console for further > interaction. > Warner > [*] this leads to a bit of a layering violation that causes a circular > dependency, but I digress... > Hi Warner, We know for sure that the filesystem the EFI loader is read from is not encrypted and thus we should be able to read the /efi/freebsd/loader.env. So how about doing the dv_init() loop twice: The first time without trying to unlock encrypted geom's. We can then safely read /efi/freebsd/loader.env. The second dv_init() loop, we only trying to unlock the encrypted ones. -Guido From nobody Mon Aug 22 07:32:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MB3wj1yMWz4b5qp for ; Mon, 22 Aug 2022 07:32:37 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MB3wh4VLLz3S6c for ; Mon, 22 Aug 2022 07:32:36 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-io1-xd2a.google.com with SMTP id d68so7614539iof.11 for ; Mon, 22 Aug 2022 00:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc; bh=P1T0ZGkezcopgFAnGJAtMj5SL813ElPVB1P/XvxlENU=; b=bsR8B+hry4GdvjmSMazSPqEg6ncKW2bSsr69LknFCHFIMVXNScuUb7iThXsSR7/tgE KkoMcmnFkDcG8zJBg61T5l6CkIg1Far7Q474ppLWj22MQmfmnDtTMCXRP+/HLErPR+pc gi5eiL1zP1gEiwGsXq4X6diyf1UWuUEWHF/N/l8Xkhc4uHJ8HrBo+jUVV8fstt539jqz pEfkCQv6wwY99CYSt3ZdMJSreSypa7SWnuTjknFHYIE7RlWV4suNK3zGDl3kWfkfehOj i0yKAHFOt+Z0jEG6G1jmGQggtE1Sg6UFXzB9IjpWK874pnpUsCOy9A0dveS42MxRoyEL qEcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc; bh=P1T0ZGkezcopgFAnGJAtMj5SL813ElPVB1P/XvxlENU=; b=ibNjIyhcvUz830QRjls5pPiX3GRJEiGolHMR3IVfhOCACcGZdZGJfXufvp7l1L1Xio bhOL5tg7KtQO/m/A4ff27HWeovrzH1seRIhJDq/JD16E3wq05BPBmWbNEk7pKABl/CpU kWNGPcXYqQXNqq2wJNDmTUQHEEDpAKVULcebIwrTnECfLhA0jFvWvJVdgHJqODu8UX9Y 9z3qakfmK5YekfSYKB3BTLtNM6zpvrV1AVLQSEzJ4LmlXat5goX+jKnAvSD+9rPeqjfX cjBW4okbls4PfDW7oVHYcwUxPXvE5WzXeQj3pG/GBP0DtJEcFZHbe9ZLG4AhfWMhlxqT 9V8Q== X-Gm-Message-State: ACgBeo1pZSJtnqsT6Gp58WNLmH9LyjZWBj6uGJOEpZ93UUU38QXIpE1x KZ0H35+BgI0JNJkSsnB3vmugPpZUkeMq3ycln5QJPcI4jR0= X-Google-Smtp-Source: AA6agR5WWL1+gCwE+YZXHjWuvjABwBOYtQ2ZcgCLM++3kUZKdbQk2fvScSvqpWsndJN92yQMaLVfezGV2a3lhM0GxlE= X-Received: by 2002:a02:6386:0:b0:349:d0b1:bb7 with SMTP id j128-20020a026386000000b00349d0b10bb7mr2697809jac.172.1661153555635; Mon, 22 Aug 2022 00:32:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Mon, 22 Aug 2022 09:32:24 +0200 Message-ID: Subject: resend from questions [Fwd: Catastrophic I/O error in root pool] To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MB3wh4VLLz3S6c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=bsR8B+hr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2a:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hi, perhaps I'll be more successful here - if you read questions@ too, please excuse :-) additional question: is it possible that what I describe below is a result of an import attempt on linux (Fedora 34)? thx Michael ---------- Forwarded message --------- From: Michael Schuster Date: Wed, Aug 10, 2022 at 10:57 PM Subject: Catastrophic I/O error in root pool To: questions Hi, After several months of not booting my laptop with FreeBSD current (been using linux off a different part of the same SSD), I attempted to do so yesterday, only to be confronted with a boot failure and a message about catastrophic I/O failure in the root pool (exact words may be different, typing from memory). Attempts to import the pool while booted from FreeBSD USB stick caused the system to hang, also with the same message on the console. Importing a different pool from the other SSD worked. I then booted linux and ran "dd if=/dev/nvme... of=/dev/null" over the complete partition w/o a single glitch. (I did NOT attempt to import the pool here, that's caused a different sort of problem previously) Finally, I installed and ran smartctl (still on linux), which - although it doesn't know about my specific device - seemed to indicate "no error". Any data important to me is on the working pool, so I'm prepared to overwrite the root pool, unless there's good reason not to (like a simpler fix for the current situation :-) ) TIA for all and any hints, pointers, advice. Michael -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Tue Aug 23 18:48:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MBytS34fvz4bGW6 for ; Tue, 23 Aug 2022 18:48:48 +0000 (UTC) (envelope-from porsolic@gmail.com) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MBytR3yCNz3PhJ for ; Tue, 23 Aug 2022 18:48:47 +0000 (UTC) (envelope-from porsolic@gmail.com) Received: by mail-io1-xd2a.google.com with SMTP id n202so6122394iod.6 for ; Tue, 23 Aug 2022 11:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=xye1pfmn2ckMy8gJW5zIsYMtf9+GGHHdU48HOLlQNJE=; b=MD4tD0KcbX6FAqAeGjlRyIhgYgQO7cYripQsQrS4zviceASp+5oMskVK097MvsRTUI XETnPAHExtpHV8Lh++m8e8LxNp0+v6Y7GS49caBR5+AbHz4QqM81ZtjhiG9S2v9F10lG MqVeFGH06/9ciSuEvPYUpn8hpqslFTK+toBNCHtV6LfOiMBy8TlhFJ1Mjf9JK5UcCchQ iZrWE19ZkMkR6r8uQuCyy5C/fsjc7l+q0kYhJv6LmhDJ/EB2qDJpUelfckgZOY8fThbC GsnftV60BmwRCYoOh33W0L97xLADTXl26RodXvXrk+zCgsVSzF85bUkYXi0U7DLyJiKz nN2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=xye1pfmn2ckMy8gJW5zIsYMtf9+GGHHdU48HOLlQNJE=; b=JNwDE+Lp36Sw4WlM7P5jOBMnOzdp7VQggDiufmnXQKobTYPHDk9fRs480lCPmnZjZM qIBdTBwgVIbt+yIU8CnLRN2xTB764XEc9F4TnJeWYoC6taPVj7CcnNRqI3rnUjP2ctjs FjeJ+918dPLyZ9EQA0zKCdTtbnQP8ECdeFA0htIXWhXgJOaZyDiNBQdIfMzc27JdwNr+ D+Gmgs/oeyeFIyUjIQnIuAoLOKGOhyc47UDo1UMREepOs6i1nzko/qp5GqDpVW6FiNg3 DxMgdvOSKdAYZasHWCeVxpH7bnxNw4yOC+jzprwEAnGrm++b1ltLX6XwNooQaV0jewjI p+hA== X-Gm-Message-State: ACgBeo06aqcoLQRrHH63AeCMN2zoMwcJb58Cn6/d6MHrF2L1tEI99/9n Jdj5Ytbi7PUjLlk5patsVbhEHV9C1/0YxLZfo6Kxarr1TvU0+A== X-Google-Smtp-Source: AA6agR4egPI9CRzzDokLfp6pv0czCea5dXZCf9S0WDT0+ZaSl5VxhBRx4ZyHDejJaX7orgI9Lgtgh6fD2XxKLdoJFtI= X-Received: by 2002:a05:6638:2386:b0:344:c9ed:a48e with SMTP id q6-20020a056638238600b00344c9eda48emr12692181jat.180.1661280526531; Tue, 23 Aug 2022 11:48:46 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: porsolic Date: Tue, 23 Aug 2022 20:48:35 +0200 Message-ID: Subject: Too much RAM used for wired memory To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000a8049a05e6ed03c5" X-Rspamd-Queue-Id: 4MBytR3yCNz3PhJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=MD4tD0Kc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of porsolic@gmail.com designates 2607:f8b0:4864:20::d2a as permitted sender) smtp.mailfrom=porsolic@gmail.com X-Spamd-Result: default: False [-3.95 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.95)[-0.952]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2a:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000a8049a05e6ed03c5 Content-Type: text/plain; charset="UTF-8" My PC uses too much wired memory after few days. After two weeks of uptime, wired memory usage is more than 50% of my RAM (17G Wired, 32 GB of physical RAM) PC is used with ZFS, 1 VM (bhyve, 1 CPU, 256 MB of RAM, passthru PCIe LAN card, pinned to 1 phy CPU, priority/nice is -10), Xorg, multiple Firefox instances (one used for playing videos), work in shell (zsh, tmux, vim, ...), GUI filemanager, GUI PDF reader and sometimes with KiCAD and/or WINE. Even after stopping VM, all programs, Xorg, tmux, dbus, avahi, moused, cups, other daemons, exporting non-root ZFS pool, going to single user mode - wired memory still doesn't decrease man vmstat shows: -z Report on memory used by the kernel zone allocator, uma(9), by zone. Is that the same as wired memory? How can I see what exactly is using that much of wired memory? What metrics should I use to pinpoint issue? vmstat? sysctl counters? # uname -srpKU FreeBSD 13.1-RELEASE amd64 1301000 1301000 # top -nSz | head -6 last pid: 1884; load averages: 2.57, 2.96, 2.91 up 15+05:21:55 15:00:00 191 processes: 5 running, 184 sleeping, 1 zombie, 1 waiting CPU: 5.1% user, 0.0% nice, 4.2% system, 0.1% interrupt, 90.7% idle Mem: 6136M Active, 3218M Inact, 1986M Laundry, 17G Wired, 96K Buf, 719M Free ARC: 1513M Total, 548M MFU, 419M MRU, 11M Anon, 17M Header, 517M Other 464M Compressed, 633M Uncompressed, 1.36:1 Ratio # vmstat -s | grep wired 4354572 pages wired down 65537 virtual user pages wired down # vmstat -m | (head -n1 && sort -hk3 | tail -5) Type InUse MemUse Requests Size(s) vtbuf 24 4560K 70 4096 linux 52226 17342K 2088029157 16,32,64,128,256,384,512,1024,2048,4096,8192,16384,32768,65536 amdvi 16924 67689K 16924 32,4096 solaris 888982 303053K 5679401089 16,32,64,128,256,384,512,1024,2048,4096,8192,16384,32768,65536 drm_kms 18446744073709504758 18014398509470267K 14 64 # vmstat -z | sort -t , -k3 | (head -n1 && tail -5) ITEM SIZE LIMIT USED FREE REQ FAILSLEEP XDOMAIN malloc-384: 384, 0, 368738, 1982,1477234413, 0, 0, 0 dnode_t: 816, 0, 383683, 192,235818160, 0, 0, 0 dmu_buf_impl_t: 296, 0, 386372, 27938,569079198, 0, 0, 0 vm pgcache: 4096, 0, 646128, 1726,2444497080,66010, 0, 0 vm pgcache: 4096, 0, 6560096, 4312,6998441782,53699, 0, 0 # zfs-stats -MA ------------------------------------------------------------------------ ZFS Subsystem Report Tue Aug 23 15:00:00 2022 ------------------------------------------------------------------------ System Memory: 20.73% 5.99 GiB Active, 10.87% 3.14 GiB Inact 57.45% 16.61 GiB Wired, 0.00% 0 Bytes Cache 2.40% 709.61 MiB Free, 8.56% 2.47 GiB Gap Real Installed: 32.00 GiB Real Available: 92.97% 29.75 GiB Real Managed: 97.19% 28.92 GiB Logical Total: 32.00 GiB Logical Used: 88.01% 28.16 GiB Logical Free: 11.99% 3.84 GiB Kernel Memory: 16.00 EiB Data: 100.00% 16.00 EiB Text: 0.00% 49.03 MiB Kernel Memory Map: 4.00 GiB Size: 63.11% 2.52 GiB Free: 36.89% 1.48 GiB ------------------------------------------------------------------------ ARC Summary: (HEALTHY) Memory Throttle Count: 0 ARC Misc: Deleted: 39.87 m Mutex Misses: 7.69 m Evict Skips: 3.07 b ARC Size: 36.95% 1.48 GiB Target Size: (Adaptive) 28.12% 1.12 GiB Min Size (Hard Limit): 23.24% 952.04 MiB Max Size (High Water): 4:1 4.00 GiB Compressed Data Size: 464.17 MiB Decompressed Data Size: 632.91 MiB Compression Factor: 1.36 ARC Size Breakdown: Recently Used Cache Size: 55.47% 839.54 MiB Frequently Used Cache Size: 44.53% 673.85 MiB ARC Hash Breakdown: Elements Max: 448.86 k Elements Current: 12.85% 57.67 k Collisions: 2.04 m Chain Max: 5 Chains: 408 ------------------------------------------------------------------------ --000000000000a8049a05e6ed03c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My PC uses too much wired memory after few days.
After = two weeks of uptime, wired memory usage is more than 50% of my RAM (17G Wir= ed, 32 GB of physical RAM)
PC is used with ZFS, 1 VM (bhyve, 1 CPU, 256 = MB of RAM, passthru PCIe LAN card, pinned to 1 phy CPU, priority/nice is -1= 0), Xorg, multiple Firefox instances (one used for playing videos), work in= shell (zsh, tmux, vim, ...), GUI filemanager, GUI PDF reader and sometimes= with KiCAD and/or WINE.

Even after stopping VM, all programs, Xorg,= tmux, dbus, avahi, moused, cups, other daemons, exporting non-root ZFS poo= l, going to single user mode - wired memory still doesn't decrease
<= br>man vmstat shows:
-z =C2=A0 =C2=A0 =C2=A0Report on memory used by the= kernel zone allocator, uma(9), by zone.

Is that the same as wired m= emory?

How can I see what exactly is using that much of wired memory= ?
What metrics should I use to pinpoint issue? vmstat? sysctl counters?<= br>
# uname -srpKU
FreeBSD 13.1-RELEASE amd64 1301000 1301000

= # top -nSz | head -6
last pid: =C2=A01884; =C2=A0load averages: =C2=A02.= 57, =C2=A02.96, =C2=A02.91 =C2=A0up 15+05:21:55 =C2=A0 =C2=A015:00:00
19= 1 processes: 5 running, 184 sleeping, 1 zombie, 1 waiting
CPU: =C2=A05.1= % user, =C2=A00.0% nice, =C2=A04.2% system, =C2=A00.1% interrupt, 90.7% idl= e
Mem: 6136M Active, 3218M Inact, 1986M Laundry, 17G Wired, 96K Buf, 719= M Free
ARC: 1513M Total, 548M MFU, 419M MRU, 11M Anon, 17M Header, 517M = Other
=C2=A0 =C2=A0 =C2=A0464M Compressed, 633M Uncompressed, 1.36:1 Rat= io

# vmstat -s | grep wired
=C2=A0 4354572 pages wired down
= =C2=A0 =C2=A0 65537 virtual user pages wired down

# vmstat -m | (hea= d -n1 && sort -hk3 | tail -5)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Type InUse MemUse Requests =C2=A0Size(s)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vtb= uf =C2=A0 =C2=A024 =C2=A04560K =C2=A0 =C2=A0 =C2=A0 70 =C2=A04096
=C2=A0= =C2=A0 =C2=A0 =C2=A0 linux 52226 17342K 2088029157 =C2=A016,32,64,128,256,= 384,512,1024,2048,4096,8192,16384,32768,65536
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 amdvi 16924 67689K =C2=A0 =C2=A016924 =C2=A032,4096
=C2=A0 =C2=A0 = =C2=A0 solaris 888982 303053K 5679401089 =C2=A016,32,64,128,256,384,512,102= 4,2048,4096,8192,16384,32768,65536
=C2=A0 =C2=A0 =C2=A0 drm_kms 18446744= 073709504758 18014398509470267K =C2=A0 =C2=A0 =C2=A0 14 =C2=A064

# v= mstat -z | sort -t , -k3 | (head -n1 && tail -5)
ITEM =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SIZE =C2=A0LIMIT =C2= =A0 =C2=A0 USED =C2=A0 =C2=A0 FREE =C2=A0 =C2=A0 =C2=A0REQ =C2=A0 =C2=A0 FA= ILSLEEP XDOMAIN
malloc-384: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 38= 4, =C2=A0 =C2=A0 =C2=A00, =C2=A0368738, =C2=A0 =C2=A01982,1477234413, =C2= =A0 0, =C2=A0 0, =C2=A0 0
dnode_t: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0816, =C2=A0 =C2=A0 =C2=A00, =C2=A0383683, =C2=A0 =C2=A0= 192,235818160, =C2=A0 0, =C2=A0 0, =C2=A0 0
dmu_buf_impl_t: =C2=A0 =C2= =A0 =C2=A0 =C2=A0 296, =C2=A0 =C2=A0 =C2=A00, =C2=A0386372, =C2=A0 27938,56= 9079198, =C2=A0 0, =C2=A0 0, =C2=A0 0
vm pgcache: =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A04096, =C2=A0 =C2=A0 =C2=A00, =C2=A0646128, =C2=A0 =C2= =A01726,2444497080,66010, =C2=A0 0, =C2=A0 0
vm pgcache: =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A04096, =C2=A0 =C2=A0 =C2=A00, 6560096, =C2=A0 =C2= =A04312,6998441782,53699, =C2=A0 0, =C2=A0 0

# zfs-stats -MA

= ------------------------------------------------------------------------ZFS Subsystem Report Tue Aug 23 15:00:00 2022
----------------------= --------------------------------------------------

System Memory:
20.73% 5.99 GiB Active, 10.87% 3.14 GiB Inact
57.45% 16.61 GiB Wi= red, 0.00% 0 Bytes Cache
2.40% 709.61 MiB Free, 8.56% 2.47 GiB Gap
<= br> Real Installed: 32.00 GiB
Real Available: 92.97% 29.75 GiB
= Real Managed: 97.19% 28.92 GiB

Logical Total: 32.00 GiB
L= ogical Used: 88.01% 28.16 GiB
Logical Free: 11.99% 3.84 GiB

= Kernel Memory: 16.00 EiB
Data: 100.00% 16.00 EiB
Text: 0.= 00% 49.03 MiB

Kernel Memory Map: 4.00 GiB
Size: 63.11% 2.5= 2 GiB
Free: 36.89% 1.48 GiB

---------------------------------= ---------------------------------------

ARC Summary: (HEALTHY)
M= emory Throttle Count: 0

ARC Misc:
Deleted: 39.87 m
Mute= x Misses: 7.69 m
Evict Skips: 3.07 b

ARC Size: 36.95% 1= .48 GiB
Target Size: (Adaptive) 28.12% 1.12 GiB
Min Size (Hard Lim= it): 23.24% 952.04 MiB
Max Size (High Water): 4:1 4.00 GiB
Compre= ssed Data Size: 464.17 MiB
Decompressed Data Size: 632.91 MiB
C= ompression Factor: 1.36

ARC Size Breakdown:
Recently Used Cach= e Size: 55.47% 839.54 MiB
Frequently Used Cache Size: 44.53% 673.85 MiB=

ARC Hash Breakdown:
Elements Max: 448.86 k
Elements Curr= ent: 12.85% 57.67 k
Collisions: 2.04 m
Chain Max: 5
Chai= ns: 408

--------------------------------------------------------= ----------------
--000000000000a8049a05e6ed03c5-- From nobody Tue Aug 23 21:27:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MC2Q85h98z4ZL75 for ; Tue, 23 Aug 2022 21:28:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MC2Q80Df0z3fFc for ; Tue, 23 Aug 2022 21:28:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id e28so11413571qts.1 for ; Tue, 23 Aug 2022 14:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc; bh=BrRb89lx5McEEEOBPd7g0E0BJm62Bu8rxZxhkZP5pLs=; b=hwnv5GNRgZOHpwZMMfTEjoaJsJTRTvhJba4okoJIUCn/MDpT9evJ7UcOsKgK6OP40V yB8N8ppY9oGUpvP5/y0WMcKV6MMMcUwDU/MR3rlVUdO/zYyWRIAj45dB6B55I6JvlgyP qSpJLZjOQ2BoewdTkdCb4PAsJREozn6Z66fYKD2aXyUjn/n35txz8BUt8KFI6ztu6/mD Gejeg9iDojfyQoE4utGYj6yeqiinBjsa98lO2rhUi2TO4lwN26FmuU9QZAIm4SW2K7jS p8nwU8+pmZbiA9jWJki8jEI5VPsnxLAsw5mWS8iDH2e95/8D806jcTGVctWY3J7HNon8 vrDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc; bh=BrRb89lx5McEEEOBPd7g0E0BJm62Bu8rxZxhkZP5pLs=; b=xAsuRzUe9eZfVPpS7Lmxol8ThSZcYg1YJAQ3nVwRA7UBsI0dGykNJfwCmHkXcfy3IF Do21JHOVmoSgONtHsfSzFbMEQCf5UdWrhIXMyi26GP8S/IHMfodANw6TQa9luBDycDvM JGaOEpAwKZpANmp3hi0z2z6nKDCARmrMz9zLVqpPmsEeJVMbPHtp6LwQ3tOnrCDrt1GL 7HEqhxuNq4/+zhpP+MV3DLMhMorkc3lveK4v9hV5XJ5Am7DOqvuxn0/bsx9PjJ9BO43w ixDwj6B/bZiDG4lifiMIEWxISKYGIiYe0IWRmJ8LhMRMkpQugRGyirbCYAkj9EPF9EwW b60w== X-Gm-Message-State: ACgBeo0M7ywvho9NyOAdWztmbcTgO1P8PCQiMcBvWp/efSpj+A95WSVU oUV8dZzRysMV38HD5Sfkj/vHS5+iBB8= X-Google-Smtp-Source: AA6agR75abFDDwg8c32RWZjKcvnZutvPHJcSxTMki4DN/04Vnbh9w5VOCDlbJSP/v6oYdl1MDY6e4g== X-Received: by 2002:a05:622a:4c:b0:343:5d26:562f with SMTP id y12-20020a05622a004c00b003435d26562fmr21303768qtw.613.1661290079301; Tue, 23 Aug 2022 14:27:59 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id y10-20020a05620a44ca00b006bb41ac3b6bsm16205969qkp.113.2022.08.23.14.27.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 14:27:57 -0700 (PDT) Date: Tue, 23 Aug 2022 17:27:55 -0400 From: Mark Johnston To: "Cavallo, Joseph" Cc: "freebsd-hackers@freebsd.org" Subject: Re: Quick question about geom/g_mirror.c g_mirror_sync_stop() function Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4MC2Q80Df0z3fFc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hwnv5GNR; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::829 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.69 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.997]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::829:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Aug 22, 2022 at 10:30:15PM +0000, Cavallo, Joseph wrote: > Hi Mark, > > Thank you for your response while traveling. > > In g_mirror_sync_stop() it quickly calls “free(disk->d_sync.ds_bios, M_MIRROR);”. But at that point can’t these bios still be in progress in the g_mirror_disk.d_sync.ds_consumer or in the g_mirror_disk.ds_consumer? They can, yes. Note though that disk->d_sync.ds_bios is an array of pointers to BIOs, not an array of BIOs, so freeing ds_bios doesn't impact pending synchronization I/O. g_mirror_sync_request() will notice in the BIO_WRITE path that the sync GEOM has gone away and will free the BIO at that point, or earlier if an I/O error occurred. Alternately, if the mirror itself is being destroyed, g_mirror_destroy_provider() will free any BIOs queued for the worker thread (see the special handling of synchronization BIOs there). > In the g_mirror_ctl_remove() path it calls “g_mirror_event_send(disk, G_MIRROR_DISK_STATE_DESTROY, G_MIRROR_EVENT_DONTWAIT);” That leads to “g_mirror_destroy_disk()” which quickly calls “g_mirror_sync_stop()”. I can’t find where it quiesces those bios so that it can free them right then and there. Later it does the g_mirror_kill_consumer() but that would just jump out when it got to the g_mirror_is_busy() test unless it was all quiesced (I think). > > I’ve run FreeBSD 13.1 with 2 64GB SCSI disks mirror (data volume). It looks like it defaults to 2 sync bios. I did the remove of the disk getting synched in the middle of a sync, and of course it works fine 100% of the time. It does not crash. But I’m trying to understand how that is. How does it avoid the pitfall that I think I see? > > Many thanks in advance. Take your time. Enjoy your travels. > > --Joe > > From: Mark Johnston > Sent: Saturday, August 20, 2022 2:20 PM > To: Cavallo, Joseph > Subject: [EXTERNAL] Re: Quick question about mirror.c > > > [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] > > ________________________________ > Hi Joe, > > I am happy to try to answer questions about that code, but I'm traveling and might take a few days to reply. Please include freebsd-hackers@freebsd.org in the email, in case someone else is able to answer. > > Thanks, > -Mark > > On Fri., Aug. 19, 2022, 12:08 Cavallo, Joseph, > wrote: > Hi Mark, > > I reside in MA, USA. > > I'm using the FreeBSD Geom/mirror project that you're a contributor to. > > I have a quick question about the g_mirror_sync_stop() routine. Would you be able to help? > > Thx, Joe From nobody Wed Aug 24 04:27:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCCjy007cz4b7X7 for ; Wed, 24 Aug 2022 04:27:17 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCCjx3Z1Hz3DmX for ; Wed, 24 Aug 2022 04:27:17 +0000 (UTC) (envelope-from mason@blisses.org) Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id DE5E017D577 for ; Wed, 24 Aug 2022 00:27:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1661315236; bh=cOAbMt1szS1B0+2VDddMzSiqeYUzpp4t25tx//SWQFA=; h=Date:From:To:Subject:From; b=bPqAjuhBmZvJnl0rNm4yXdOO2X3mCTe9MLpIL1dlaJdolgsVN6On278Xp9M1HP/TZ CZjqNVBMY3DjUSJuMcjR4cz568/e6kdjYMyOhLbbFo8DYKpkyvSFSeuLk8ZkXOOMR4 ycygIGN3KECRBD8T8s5I2d3FuPwXcQBRthU9IdzhD6N35rcTm7V4H1s1TwnllwSHaS On0bFQIBVF1PnepUkmQxRsl8/d3I0tmGOBxtSdhucO97ML/zDBuKHH09Y01aGGmu5j EBXZb4Etd6rI99qamcfdDDlm8827uD/8uTLiznB+6u8EGcDqEiUc4GABtBGEAcempF e75bGJ8B1+iQg== Date: Wed, 24 Aug 2022 00:27:15 -0400 From: Mason Loring Bliss To: freebsd-hackers@freebsd.org Subject: Help debugging Vultr boot delay...? Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tcWydc0rw/1b+Tx0" Content-Disposition: inline X-Rspamd-Queue-Id: 4MCCjx3Z1Hz3DmX X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b=bPqAjuhB; dmarc=pass (policy=quarantine) header.from=blisses.org; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; R_SPF_ALLOW(-0.20)[+mx:c]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --tcWydc0rw/1b+Tx0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all. I noticed a couple oddities with Vultr's FreeBSD support recently. The first was that when you asked for a 13.1 VM (with the alternative being 12.3) you'd actually get a 13.0 image. They've addressed this now, so it's no longer a concern. The second issue is still there and while I've brought it to their attention, it'd probably be useful if they had some expert help. What I'm observing with new VMs, both their images and via FreeBSD's own install media, is a pause of one and three quarters minutes (around 105 seconds) between: ugen0.2: at usbus0 and the next line, which appears to be: hdacc0: at cad 0 on hdac0 FreeBSD believes it's on Hyper-V 10.0.14393 [SP0] but the same VM booted into GNU/Linux probes KVM, so I've got to ask about that. Given fairly limited access to the VM - pretty much, a KVM console and whatever I can manage to be saved to disk - is there any useful way I can get more data about what's going on during the visible pause? This appears with the FreeBSD 13.1 install (disc1) ISO and with 13.0 as supplied by Vultr, but I can boot other ISOs with something custom to explore, as needed. Thanks in advance if anyone has clues or ideas. I'll report back when I know more, regardless. --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --tcWydc0rw/1b+Tx0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmMFqKEACgkQnrJXcHbv JVUvfxAAsxEnbE/TgSiPC5pUVpjxJyIqDq9T2TqXQROdqiv+BN6qe/bPy23iyRUm j5pHKYmD87D8l9xdbz9JNqhDYhOBoQ7u3StV+NbwkOI7d8Ovux4rBKztE4Eo/7Gm Cz3lhtDYQFG+rGU6ItCA1uvZ7xQnJPsxx2MXsxHwW5oFmXmXwUR5nRjf/Ohl1Ppt wJTJio2szA6ei51vO1dzVORtg2d9QDk0fKF6wMgMyZgjaobyuEH3jkNQ2QyfAJby Dr8FCUa396I1m6M06WTQLD+rlWzhEAbb4fqvymYIEoPA9ehsNkff3M3r58m4pUU5 vKGNhuwjgP7nHoCNz8mPjLuFYVpQ3xr/xGINPXHtqqdZOTUci+cajbvUhSCpjUbX M9ielJe6wXqJgQmslGCtoEiEh/chgk3FTlZaNFlTet15Kq0g2luqU4ZuqmgIBuGO rggT/eP3jHvJWKcPyi80WN38kIAN1ePBKE2MQG4uDKr6m4nhCXNt9PCboe48/zSr WZMOvPpOhLqnIxZ90acAHx16cX8Ao2Fh1Ci81Fi3rSLGM45WXwx5VmAyKwLAZYJo gTIN9qz1Z1Zz+ebPg7RHMfGHXKpyudanNENuatkLwKY572xiASNx3zF4YuC9McsF RXc3LR2hpIAN6eAyRqWn7nV/67IxOMEBTVZHjrEblOl7W7XBLnc= =yNh3 -----END PGP SIGNATURE----- --tcWydc0rw/1b+Tx0-- From eugen@grosbein.net Wed Aug 24 05:34:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCFDQ3Zlcz4ZH8D for ; Wed, 24 Aug 2022 05:35:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCFDP43Hmz3KG9 for ; Wed, 24 Aug 2022 05:35:17 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27O5Yvup086241 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Aug 2022 05:34:58 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mason@blisses.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27O5Yt9O017437 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 24 Aug 2022 12:34:55 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Help debugging Vultr boot delay...? To: Mason Loring Bliss , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Wed, 24 Aug 2022 12:34:50 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4MCFDP43Hmz3KG9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 24.08.2022 11:27, Mason Loring Bliss wrote: > Hi all. I noticed a couple oddities with Vultr's FreeBSD support recently. > The first was that when you asked for a 13.1 VM (with the alternative being > 12.3) you'd actually get a 13.0 image. They've addressed this now, so it's > no longer a concern. > > The second issue is still there and while I've brought it to their > attention, it'd probably be useful if they had some expert help. What I'm > observing with new VMs, both their images and via FreeBSD's own install > media, is a pause of one and three quarters minutes (around 105 seconds) > between: > > ugen0.2: at usbus0 > > and the next line, which appears to be: > > hdacc0: at cad 0 on hdac0 > > FreeBSD believes it's on Hyper-V 10.0.14393 [SP0] but the same VM booted > into GNU/Linux probes KVM, so I've got to ask about that. > > Given fairly limited access to the VM - pretty much, a KVM console and > whatever I can manage to be saved to disk - is there any useful way I can > get more data about what's going on during the visible pause? This appears > with the FreeBSD 13.1 install (disc1) ISO and with 13.0 as supplied by > Vultr, but I can boot other ISOs with something custom to explore, as > needed. > > Thanks in advance if anyone has clues or ideas. I'll report back when I > know more, regardless. I have my own small VM at vultr.com. If I run "ping X.X.X.X" against it from outside, then "shutdown -r now" from inside the VM, I get exactly 20 probes lost (20 seconds) after it stops responding and starts responding again after reboot. So, my instance has not such problem. I created it in times of 13.0-RELEASE but I booted in off FreeBSD official ISO image for 64 bits, destroyed pre-installed GPT partitioning and installed 13.0 system using MBR+ZFS-on-slice. Since then, it was upgraded to 13.1-STABLE/amd64. Also I have in /boot/loader.conf: beastie_disable="YES" autoboot_delay="3" kern.vty=sc hw.memtest.tests=0 aesni_load="YES" dumpdev="/dev/label/swap" zfs_load="YES" vfs.root.mountfrom="zfs:z" vfs.zfs.arc_max="100M" vfs.zfs.vdev.cache.size="32M" vfs.zfs.prefetch_disable="1" vfs.zfs.vdev.trim_on_init="0" vfs.zfs.compressed_arc_enabled="1" vfs.zfs.abd_scatter_enabled="0" My kernel is GENERIC plus three options: KDB, KDB_UNATTENDED and KDB_TRACE usbconfig shows me: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) Please post output of "pciconf -lvvv". From nobody Wed Aug 24 14:20:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCSt931zVz4bHSF for ; Wed, 24 Aug 2022 14:20:17 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCSt81xCdz3ynT for ; Wed, 24 Aug 2022 14:20:16 +0000 (UTC) (envelope-from mason@blisses.org) Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id C84D4176EF4; Wed, 24 Aug 2022 10:20:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1661350814; bh=a17d1imeM/jQnlvoOuxzNBgRIn5seCeZipnpn27P2W4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n3fOx3499GjYkt4pxffTcz0xFICJ0ALp9Z60maXNCN8hsAloHTDocMhFezjT5CPsY k381QduZhDaY2uYPPTjiU143g9YIaxTz8Ronq4rMzDBEcQz3WltIOQZmMr8t27eOhF S8a4O0wqm8AOzdje1Lm+EoKElwwOinmL437g1ivABxjnjqw12MB4eVzGp7eAI04UEB 0LlhCleTo4V966iUurf0ADndk2+B9n0aQoKvh8p+PkCRLNdU9a5lrLy0cVVOeNo0hj uNh5wxDUDUZvKGI4slnvF54QdpUXgYmk8VV3ywWWiKPIcGCJRp7cV8kts0Rbp/lB/y Myyr9x9BX3zQg== Date: Wed, 24 Aug 2022 10:20:13 -0400 From: Mason Loring Bliss To: Eugene Grosbein Cc: freebsd-hackers@freebsd.org Subject: Re: Help debugging Vultr boot delay...? Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BcMho9/8JHFvRhmu" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4MCSt81xCdz3ynT X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b=n3fOx349; dmarc=pass (policy=quarantine) header.from=blisses.org; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --BcMho9/8JHFvRhmu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2022 at 12:34:50PM +0700, Eugene Grosbein wrote: > So, my instance has not such problem. This appears to be something new, although that you're not seeing it on that VM is interesting. It might be specific to some datacenters. My testing here has used the New Jersey data center. I've just spun up a new one to collect usbconfig and pciconf output. usbconfig: ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12M= bps) pwr=3DSAVE (0mA) ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12= Mbps) pwr=3DON (100mA) --------------------------------------------------------------------------- pciconf -lvvv: hostb0@pci0:0:0:0: class=3D0x060000 rev=3D0x02 hdr=3D0x00 vendor=3D0x8086 d= evice=3D0x1237 subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '440FX - 82441FX PMC [Natoma]' class =3D bridge subclass =3D HOST-PCI isab0@pci0:0:1:0: class=3D0x060100 rev=3D0x00 hdr=3D0x00 vendor=3D0x8086 de= vice=3D0x7000 subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '82371SB PIIX3 ISA [Natoma/Triton II]' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:1:1: class=3D0x010180 rev=3D0x00 hdr=3D0x00 vendor=3D0x8086 = device=3D0x7010 subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '82371SB PIIX3 IDE [Natoma/Triton II]' class =3D mass storage subclass =3D ATA uhci0@pci0:0:1:2: class=3D0x0c0300 rev=3D0x01 hdr=3D0x00 vendor=3D0x8086 de= vice=3D0x7020 subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '82371SB PIIX3 USB [Natoma/Triton II]' class =3D serial bus subclass =3D USB intsmb0@pci0:0:1:3: class=3D0x068000 rev=3D0x03 hdr=3D0x00 vendor=3D0x8086 = device=3D0x7113 subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ACPI' class =3D bridge vgapci0@pci0:0:2:0: class=3D0x030000 rev=3D0x02 hdr=3D0x00 vendor=3D0x1234 = device=3D0x1111 subvendor=3D0x1af4 subdevice=3D0x1100 class =3D display subclass =3D VGA virtio_pci0@pci0:0:3:0: class=3D0x020000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1000 subvendor=3D0x1af4 subdevice=3D0x0001 vendor =3D 'Red Hat, Inc.' device =3D 'Virtio network device' class =3D network subclass =3D ethernet hdac0@pci0:0:4:0: class=3D0x040300 rev=3D0x03 hdr=3D0x00 vendor=3D0x8086 de= vice=3D0x293e subvendor=3D0x1af4 subdevice=3D0x1100 vendor =3D 'Intel Corporation' device =3D '82801I (ICH9 Family) HD Audio Controller' class =3D multimedia subclass =3D HDA virtio_pci1@pci0:0:5:0: class=3D0x010000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1001 subvendor=3D0x1af4 subdevice=3D0x0002 vendor =3D 'Red Hat, Inc.' device =3D 'Virtio block device' class =3D mass storage subclass =3D SCSI virtio_pci2@pci0:0:6:0: class=3D0x00ff00 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1002 subvendor=3D0x1af4 subdevice=3D0x0005 vendor =3D 'Red Hat, Inc.' device =3D 'Virtio memory balloon' class =3D old virtio_pci3@pci0:0:7:0: class=3D0x00ff00 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1005 subvendor=3D0x1af4 subdevice=3D0x0004 vendor =3D 'Red Hat, Inc.' device =3D 'Virtio RNG' class =3D old --------------------------------------------------------------------------- dmesg: Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-RELEASE-p1 GENERIC amd64 FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-= 13.0.0-0-gd7b669b3a303) VT(vga): text 80x25 Hyper-V Version: 6.1.7100 [SP0] Features=3D0xa7e PM Features=3D0x0 [C0] Features3=3D0x108 Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 CPU: Intel Core Processor (Broadwell, no TSX, IBRS) (2394.46-MHz K8-class C= PU) Origin=3D"GenuineIntel" Id=3D0x306d2 Family=3D0x6 Model=3D0x3d Steppi= ng=3D2 Features=3D0x783fbff Features2=3D0xfffa3203 AMD Features=3D0x28100800 AMD Features2=3D0x21 Structured Extended Features=3D0x7a9 Structured Extended Features3=3D0x84000000 XSAVE Features=3D0x1 Hypervisor: Origin =3D "Microsoft Hv" real memory =3D 536870912 (512 MB) avail memory =3D 481386496 (459 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 Timecounter "Hyper-V-TSC" frequency 10000000 Hz quality 3000 random: entropy device external interface kbd1 at kbdmux0 vtvga0: smbios0: at iomem 0xf5910-0xf592e smbios0: Version: 2.8, BCD Revision: 2.8 aesni0: acpi0: acpi0: Power Button (fixed) cpu0: on acpi0 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 100000000 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x608-0x60b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 vmbus0: on pcib0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,= 0x376,0xc120-0xc12f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc0c0-0xc0df irq 11 at = device 1.2 on pci0 usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xfd000000-0xfdffffff,0xfebf4000-0xfe= bf4fff at device 2.0 on pci0 vgapci0: Boot video device virtio_pci0: port 0xc0e0-0xc0ff mem 0= xfebf5000-0xfebf5fff,0xfe000000-0xfe003fff irq 11 at device 3.0 on pci0 vtnet0: on virtio_pci0 vtnet0: Ethernet address: 56:00:04:1d:b6:06 vtnet0: netmap queues/slots: TX 1/256, RX 1/128 000.000758 [ 450] vtnet_netmap_attach vtnet attached txq=3D1, txd=3D2= 56 rxq=3D1, rxd=3D128 hdac0: mem 0xfebf0000-0xfebf3fff irq 11 at de= vice 4.0 on pci0 virtio_pci1: port 0xc000-0xc07f mem 0xf= ebf6000-0xfebf6fff,0xfe004000-0xfe007fff irq 10 at device 5.0 on pci0 vtblk0: on virtio_pci1 vtblk0: 10240MB (20971520 512 byte sectors) virtio_pci2: port 0xc080-0xc0bf mem 0= xfe008000-0xfe00bfff irq 10 at device 6.0 on pci0 vtballoon0: on virtio_pci2 virtio_pci3: port 0xc100-0xc11f mem 0= xfe00c000-0xfe00ffff irq 11 at device 7.0 on pci0 acpi_syscontainer0: on acpi0 acpi_syscontainer1: port 0xaf00-0xaf0b on acpi0 acpi_syscontainer2: port 0xafe0-0xafe3 on acpi0 acpi_syscontainer3: port 0xae00-0xae13 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.= 0. psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on= acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 orm0: at iomem 0xea000-0xeffff pnpid ORM0000 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff pnpid PNP= 0900 on isa0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 attimer0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. fdc0: No FDOUT register! Timecounter "TSC-low" frequency 1197226946 Hz quality 800 Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0 on usbus0 uhub0: on usbus0 GEOM: vtbd0: the secondary GPT header is not in the last LBA. uhub0: 2 ports with 2 removable, self powered ugen0.2: at usbus0 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 3 and 5 on hdaa0 Trying to mount root from ufs:/dev/ufs/rootfs [rw]... cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number QM00003 cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present intsmb0: irq 9 at device 1.3 on pci0 intsmb0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 lo0: link state changed to UP uhid0 on uhub0 uhid0: on usbus0 vtnet0: link state changed to UP --=20 Mason Loring Bliss mason@blisses.org http://blisses.org/ = =20 For more enjoyment and greater efficiency, consumption is being standardize= d. --BcMho9/8JHFvRhmu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmMGM5sACgkQnrJXcHbv JVXYlA//QHHTA/YxJJMb9XORHkT6QbuuKf77wzfFxWeFyie3qqx7A4gcND1uG3KV oE2rKGUV1FQIKqseOhX+QoMT8HH/2sNE2j1ZliIIo3uEIMf/EiWW1YNfYEHGU3jP iUm9Zy9X+3rSv1UOL4FpqeAlUs0yzcKofLMCbsP4NOInirOedbxmonOhWnjeexFJ T1u923sQC7xSYthOPeYwsifWaoFU3Xca3XKOxTaMnNs3RtQN+eXRsfoW8yOPUowm ONzVqH+MVP/LUaHyVMveHf325inwnuMihYbh0kEkQjc03EdoyYqrkXotm8zQWnmf 4V+B3ec1UHc7SlMQXV8usRE9L5fdGkxhIgXdQtoKjiJGYvd5jUqPxX62/tfeZkhy WgJN7gwJQBmaCY5V8acaBsgzWVEOCbe/WNdMiqdBk00qMW5FF0oE8SsMH2lrZ7uT YXmBBn+l9Co2oLTpev8rm6qO8kU4FQIaESWI+T0up5IdVEPuKhJgC5/3GOEh/MvF LD4DqZ5CoZxc7//BMWCR0h1SYGNosEKMHJ5kazFhEKDYh3uTaaBqXg01tNSzd8Jw U04FjhoszUU12u57y5Ud8MlpAGClPZR7TJKdEb7fiaTmEp5YH6NwsZzVFjNRJzu6 VaIusJUbJYIfruCM846N7etUO30SBu+G6AgAjGVlhrW39rmh2S4= =Lodf -----END PGP SIGNATURE----- --BcMho9/8JHFvRhmu-- From nobody Thu Aug 25 06:31:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCtRW05M4z4b0bM for ; Thu, 25 Aug 2022 06:32:07 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCtRT6B0Tz3PxQ for ; Thu, 25 Aug 2022 06:32:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 27P6Vt76072973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Aug 2022 08:31:56 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1661409116; bh=8XZGII+Ug2kS5b+DpdiyFVkRljp0VEWhQShRnPjczpM=; h=Date:From:To:Subject; b=Ic+YsvkUTjZ7z8YvrmNZbLYhDSzQzmmsQJrrWB3U4HuOPQ4vdpz3WBJ+PUl1DPTiT zyB2G1fp5aLz7aMVspnEfspk3BXfDA80dXRzTP/rCn3TSgUC3S6iFkbu7L9aDQPnop op71J8NQj1x8JeLgj8S9lSY50v0TVJdIat25mj3E= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 27P6VtYr060716 for ; Thu, 25 Aug 2022 08:31:55 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 27P6Vtvi060713 for ; Thu, 25 Aug 2022 08:31:55 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 25 Aug 2022 08:31:55 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: ipfw nat problem Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4MCtRT6B0Tz3PxQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=Ic+YsvkU; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N i use ipfw nat redirect feature for a long time. never had problems until now. my ipfw config queue flush pipe flush #define INTERNETIP 1.2.3.4 #define INTERNET igb1 nat 1 config ip 1.2.3.4 \ redirect_port tcp 10.255.255.253:22 20023 \ redirect_port tcp 10.255.255.254:22 20022 // table 1 flush table 1 add 5.6.7.8 add 6 skipto 1000 all from any to any via INTERNET in add 7 skipto 2000 all from any to any via INTERNET out add 10 allow all from any to any add 1000 deny all from table(1) to any add 1001 deny tcp from any to me 3306 add 1010 nat 1 all from any to me add 1999 allow all from any to any add 2000 reject tcp from me to any 113 add 2001 nat 1 all from 10.255.255.0/24 to any add 2002 allow all from any to any this is server with 2 jails - i want these 2 jails ssh server be available from outside. And it is. I can log in do many thing for a long time interactively no problems. But trying to transfer files like ssh -p 20023 loginname@server "tar cf - something"|tar xpf - or scp it always disconnects after transfering about 100kB in logs i see Aug 25 08:29:35 <4.6> 10.255.255.253 sshd[63621]: Fssh_packet_write_poll: Connection from user blebleble 9.9.9.9 port 53899: Permission denied No other errors i have no problems doing such operations on host directly over ssh. I do use ssh redirects using nat on many servers without problems. What can i do to find a source of this problem? From nobody Thu Aug 25 06:36:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCtXT1wqBz4b0rR for ; Thu, 25 Aug 2022 06:36:25 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCtXS4SqBz3R6p for ; Thu, 25 Aug 2022 06:36:24 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 27P6aMCG077171 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Aug 2022 08:36:22 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1661409383; bh=ffoi/S58D9NPO1S0uXO8nwmK5haw77P4KP6JTx1WBmI=; h=Date:From:To:Subject:In-Reply-To:References; b=YYuVI7Vq4qHe8gT5jI2TccSg3G8GrLhjuIv2A3jr6Q7iFrIG+ADOZNMrerAj1+S1/ 1fb01L0AcxhaoNpWmxqslitgHsd6B2uXnF0Af8lnafXDIML2uih7z5CGQ6dzxmg4Hd LqBco4jEioWBFW0oxdGTI/qoYSpMndHYK6Gb2vps= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 27P6aMWq060740 for ; Thu, 25 Aug 2022 08:36:22 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 27P6aMd4060737 for ; Thu, 25 Aug 2022 08:36:22 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Thu, 25 Aug 2022 08:36:22 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: Re: ipfw nat problem In-Reply-To: Message-ID: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MCtXS4SqBz3R6p X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=YYuVI7Vq; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N found a reason. forwarding was set to 0 in sysctl On Thu, 25 Aug 2022, Wojciech Puchar wrote: > i use ipfw nat redirect feature for a long time. never had problems until > now. > > my ipfw config > > queue flush > pipe flush > #define INTERNETIP 1.2.3.4 > #define INTERNET igb1 > nat 1 config ip 1.2.3.4 \ > redirect_port tcp 10.255.255.253:22 20023 \ > redirect_port tcp 10.255.255.254:22 20022 > // > table 1 flush > table 1 add 5.6.7.8 > > add 6 skipto 1000 all from any to any via INTERNET in > add 7 skipto 2000 all from any to any via INTERNET out > add 10 allow all from any to any > > > add 1000 deny all from table(1) to any > add 1001 deny tcp from any to me 3306 > add 1010 nat 1 all from any to me > add 1999 allow all from any to any > > add 2000 reject tcp from me to any 113 > add 2001 nat 1 all from 10.255.255.0/24 to any > add 2002 allow all from any to any > > > this is server with 2 jails - i want these 2 jails ssh server be available > from outside. > > And it is. I can log in do many thing for a long time interactively no > problems. > > But trying to transfer files like ssh -p 20023 loginname@server "tar cf - > something"|tar xpf - > > or scp > > it always disconnects after transfering about 100kB > > > in logs i see > > Aug 25 08:29:35 <4.6> 10.255.255.253 sshd[63621]: Fssh_packet_write_poll: > Connection from user blebleble 9.9.9.9 port 53899: Permission denied > > No other errors > > > i have no problems doing such operations on host directly over ssh. > > I do use ssh redirects using nat on many servers without problems. > What can i do to find a source of this problem? > > From eugen@grosbein.net Thu Aug 25 06:49:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCtqx2Crhz4b2Qf for ; Thu, 25 Aug 2022 06:49:49 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCtqw489Rz3SD4 for ; Thu, 25 Aug 2022 06:49:48 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27P6ndXr001269 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Aug 2022 06:49:39 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27P6nbfG030948 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 25 Aug 2022 13:49:37 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ipfw nat problem To: Wojciech Puchar , freebsd-hackers@freebsd.org References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> From: Eugene Grosbein Message-ID: Date: Thu, 25 Aug 2022 13:49:31 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4MCtqw489Rz3SD4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 25.08.2022 13:36, Wojciech Puchar wrote: > found a reason. forwarding was set to 0 in sysctl Never set net.inet.ip.forwarding=1 manually or via /etc/sysctl.conf. Always use gateway_enable="YES" in /etc/rc.conf, or else system scripts started with devd on any interface creation (tunX, ngX, etc.) will switch forwarding to 0 again. From nobody Fri Aug 26 08:04:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MDXS13FvCz4ZXNf for ; Fri, 26 Aug 2022 08:04:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MDXRz4jMxz3hsj for ; Fri, 26 Aug 2022 08:04:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 27Q84cxg066119 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Aug 2022 10:04:39 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1661501079; bh=C9kVtowBbs4aEcSAJ2V+6y8D0SrgvZxS60PWfQjFu8w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Vpi834d7jDH5xOwkdcSp4LxiQFzHcrrDx0IDuKsPwi//4Kvb3LrtMBS46WJ1entb5 ZM+GeaDewl3o56Ki7d78IcBC4ELgKnMLw1871JO7NduwknHfoqq1i0MvqRYnFlAIoA zSZFYirf3KoRYFX6dCS5wiw4n/jsr9PJQEJGs5Q0= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 27Q84cND067438; Fri, 26 Aug 2022 10:04:38 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 27Q84bAp067435; Fri, 26 Aug 2022 10:04:37 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 26 Aug 2022 10:04:37 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: ipfw nat problem In-Reply-To: Message-ID: References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MDXRz4jMxz3hsj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=Vpi834d7; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[puchar.net]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N >> found a reason. forwarding was set to 0 in sysctl > > Never set net.inet.ip.forwarding=1 manually or via /etc/sysctl.conf. > > Always use gateway_enable="YES" in /etc/rc.conf, or else system scripts started with devd I don't use devd on servers. > on any interface creation (tunX, ngX, etc.) will switch forwarding to 0 again. Well - i do create tun or other interfaces without problems. Can you point an example of this? From eugen@grosbein.net Fri Aug 26 09:26:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MDZGY5KKMz4ZgWc for ; Fri, 26 Aug 2022 09:26:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MDZGX4C0sz3pW4 for ; Fri, 26 Aug 2022 09:26:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27Q9QZkj075083 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Aug 2022 09:26:35 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27Q9QXh4043471 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Aug 2022 16:26:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ipfw nat problem To: Wojciech Puchar References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <57a9cad0-c2ef-6e1f-2185-0f7563fe3758@grosbein.net> Date: Fri, 26 Aug 2022 16:26:26 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4MDZGX4C0sz3pW4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.08.2022 15:04, Wojciech Puchar wrote: >>> found a reason. forwarding was set to 0 in sysctl >> >> Never set net.inet.ip.forwarding=1 manually or via /etc/sysctl.conf. >> >> Always use gateway_enable="YES" in /etc/rc.conf, or else system scripts started with devd > > I don't use devd on servers. > >> on any interface creation (tunX, ngX, etc.) will switch forwarding to 0 again. > > Well - i do create tun or other interfaces without problems. Can you point an example of this? Some scripts (f.e. from /etc/devd.conf) invoke /etc/pccard_ether $subsystem start (the name "pccard_ether" is just historic, it serves any cloned network interface). It runs "/etc/rc.d/netif quietstart" $ifn that runs "/etc/rc.d/routing static any $_if" that may reset net.inet.ip.forwarding=0 unless you have gateway_enable="YES" in /etc/rc.conf despite you could have set net.inet.ip.forwarding=1 via sysctl.conf. From nobody Fri Aug 26 10:42:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MDbxh5j76z4ZpYY for ; Fri, 26 Aug 2022 10:42:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MDbxg71qKz3tlF for ; Fri, 26 Aug 2022 10:42:15 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 27QAgCTh085431 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Aug 2022 12:42:13 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1661510533; bh=aPdOfmwhoWKuCGFlwwkadSg+PzdqLzULhN+2LNG+MTQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Hb7iBLDVBg3aByeeA4wk5KGSB2M/PqcmYuyFtlsjC8donTbTRNVM+0m7CMPYTIbuq 0DTdU5ZrLA4Nx8T/Eab9mVbT4LB1kkXi/ap2eYL41MgBRz/7hB7535qF8n++baJMdr WYpQTyFaBzpWgwg6SNHCvClvr75GlFYSpDK3+QbQ= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 27QAgCMo067992; Fri, 26 Aug 2022 12:42:12 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 27QAgBxh067989; Fri, 26 Aug 2022 12:42:11 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 26 Aug 2022 12:42:11 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: ipfw nat problem In-Reply-To: <57a9cad0-c2ef-6e1f-2185-0f7563fe3758@grosbein.net> Message-ID: <90b59493-95d6-5b2a-b0dc-2fece0a9df7b@puchar.net> References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> <57a9cad0-c2ef-6e1f-2185-0f7563fe3758@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MDbxg71qKz3tlF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=Hb7iBLDV; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >>> on any interface creation (tunX, ngX, etc.) will switch forwarding to 0 again. >> >> Well - i do create tun or other interfaces without problems. Can you point an example of this? > > Some scripts (f.e. from /etc/devd.conf) invoke /etc/pccard_ether $subsystem start > (the name "pccard_ether" is just historic, it serves any cloned network interface). > > It runs "/etc/rc.d/netif quietstart" $ifn that runs "/etc/rc.d/routing static any $_if" > that may reset net.inet.ip.forwarding=0 unless you have gateway_enable="YES" in /etc/rc.conf > despite you could have set net.inet.ip.forwarding=1 via sysctl.conf. > > > > Thanks. Fortunately i don't use devd on any servers. Anyway - with ip.forwarding on ssh still disconnect randomly. Just after much larger amount of data transmitted (like 10-100MB, not <1MB) Just on this server. Any ideas what may be wrong? From eugen@grosbein.net Fri Aug 26 11:53:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MDdXX2fMyz4Zx50 for ; Fri, 26 Aug 2022 11:54:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MDdXW3KLCz40Dm for ; Fri, 26 Aug 2022 11:54:03 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27QBrvWG015087 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Aug 2022 11:53:58 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: wojtek@puchar.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27QBrvBu044667 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Aug 2022 18:53:57 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ipfw nat problem To: Wojciech Puchar References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> <57a9cad0-c2ef-6e1f-2185-0f7563fe3758@grosbein.net> <90b59493-95d6-5b2a-b0dc-2fece0a9df7b@puchar.net> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <71545bb7-a5ea-510f-8d67-4f07fe0887ae@grosbein.net> Date: Fri, 26 Aug 2022 18:53:49 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <90b59493-95d6-5b2a-b0dc-2fece0a9df7b@puchar.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.2 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4MDdXW3KLCz40Dm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 26.08.2022 17:42, Wojciech Puchar wrote: > Anyway - with ip.forwarding on ssh still disconnect randomly. Just after much larger amount of data transmitted (like 10-100MB, not <1MB) > > Just on this server. Any ideas what may be wrong? Maybe you use ipfw nat (or natd) and forgot to disable TSO on external interface, so some packets get broken as TSO is not compatible with libalias. I've read some reports that pfnat may have problems with TSO, too. From nobody Sat Aug 27 14:29:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFJxz4CXgz4ZWyg for ; Sat, 27 Aug 2022 14:29:59 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4MFJxy55wHz3V9Z for ; Sat, 27 Aug 2022 14:29:58 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 27RETmf3063823; Sat, 27 Aug 2022 15:29:48 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 27RETkGg063822; Sat, 27 Aug 2022 15:29:47 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net> Date: Sat, 27 Aug 2022 15:29:46 +0100 Organization: Dyslexic Fish To: mason@blisses.org, freebsd-hackers@FreeBSD.org Cc: eugen@grosbein.net Subject: Re: Help debugging Vultr boot delay...? References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Sat, 27 Aug 2022 15:29:48 +0100 (BST) X-Rspamd-Queue-Id: 4MFJxy55wHz3V9Z X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.70 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jamie]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Mason Loring Bliss wrote: > The second issue is still there and while I've brought it to their > attention, it'd probably be useful if they had some expert help. What I'm > observing with new VMs, both their images and via FreeBSD's own install > media, is a pause of one and three quarters minutes (around 105 seconds) > between: > > ugen0.2: at usbus0 > > and the next line, which appears to be: > > hdacc0: at cad 0 on hdac0 > > FreeBSD believes it's on Hyper-V 10.0.14393 [SP0] but the same VM booted > into GNU/Linux probes KVM, so I've got to ask about that. It appears to be their new KVM software. I have a number of vultr VMs (all running FreeBSD, obviously!) and there is no problem. I created a new 13.1 and a new 12.3 and saw the problem you describe. I then snapshotted one of my live 13.0 instances, and restored that to a new VM, and the problems you describe then appeared. Remember, identical disk contents, different results. Doing a 'kenv' on both boxes, the only relevant difference is smbios.system.version / smbios.chassis.version as such: < smbios.chassis.version="pc-i440fx-5.2" > smbios.chassis.version="pc-i440fx-7.0" < smbios.system.version="pc-i440fx-5.2" > smbios.system.version="pc-i440fx-7.0" The new instances are clearly being installed with a newer QEMU/KVM host. Comparing dmesg.boot is more interesting. As you say, the hypervisor is now grocked as Microsoft Hv These are the relevant differences. Again, exactly the same disk contents (running 13.0 in this case): > Hyper-V Version: 10.0.14393 [SP0] > Features=0xa7e > PM Features=0x0 [C0] > Features3=0x108 > Timecounter "Hyper-V" frequency 10000000 Hz quality 2000 > CPU: Intel Core Processor (Skylake, IBRS) (3408.00-MHz K8-class CPU) < Hypervisor: Origin = "KVMKVMKVM" --- > Hypervisor: Origin = "Microsoft Hv" > Timecounter "Hyper-V-TSC" frequency 10000000 Hz quality 3000 > vmbus0: on pcib0 > hdac0: mem 0xfebf0000-0xfebf3fff irq 11 at device 4.0 on pci0 > hdacc0: at cad 0 on hdac0 > hdaa0: at nid 1 on hdacc0 > pcm0: at nid 3 and 5 on hdaa0 Why is the host even announcing an audio device to the guests?! And is it more than coincidence that the delay comes before hdacc0 is groked? Anyway, if the fault is with FreeBSD, it's not a recent fault, it's just that changes in their host software are revealing them. Hope this helps a bit. Cheers, Jamie From nobody Sat Aug 27 14:41:44 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFKCl59lRz4ZYHy for ; Sat, 27 Aug 2022 14:41:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFKCj68zkz3WqR for ; Sat, 27 Aug 2022 14:41:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From; bh=qz3XcrRUS2aiHfkzFMrcvopDmnN3UYQMbjOsDdKDGk8=; b=aFrsxju3qUIW8+eTSGnXjEpbxzgsen/oAYHVDg+eTEoFR5Es/O9fvh7GWQuCCBnd0WJR6jXy8hNQ6rqQRFi66hDe+I5BexJDePHHOlyjIe0MBXx6AAOl665QlBFLGuSCDi09t20P3CdnUFHQPEcg/ov7MIuHnb2VSRXE4UV6od4cSXdUAntM/3oCTp3T+Hl8M+3f3HuemI6y+LrkW/OFvIPaBN3zzYwoEuslP0cpmkgiLZMja43qAEHFpHXNWR/aoq3fZaB7g0OA2ARwcff46hjxSOFfgBsLFv6FndVdnhA2BEQ+VGHZ4b+uFOjUjxWD5VNL078TOmcDTfjNwCCbeg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1oRx0L-0000SQ-1W for hackers@freebsd.org; Sat, 27 Aug 2022 17:41:45 +0300 From: Daniel Braniss Content-Type: multipart/alternative; boundary="Apple-Mail=_DB2A709E-22A5-447C-9DCC-7290F133167D" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: GLIBCXX_3.4.20 not found Message-Id: <7E480491-8FDD-4FCB-AF70-85A50FA6DA2C@cs.huji.ac.il> Date: Sat, 27 Aug 2022 17:41:44 +0300 To: freebsd-hackers X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MFKCj68zkz3WqR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=aFrsxju3; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_DB2A709E-22A5-447C-9DCC-7290F133167D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi all, the subject is the short version :-) actually I=E2=80=99m using espressif idf stuff for some time now, to = compile programs for esp32 et.all, but their latest version 5.1 (not = stable) complains each time any of the compilers (they need linux.ko) is run =E2=80=A6=20 /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required = by = /cs/system/danny/.espressif-latest/tools/xtensa-esp32-elf/esp-2022r1-11.2.= 0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/11.2.0/cc1plus) so is there any version of libstdc++ that has the missing symbol? thanks for any insight, danny =09= --Apple-Mail=_DB2A709E-22A5-447C-9DCC-7290F133167D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 hi = all,
 the subject is the short version :-)

actually I=E2=80=99m = using espressif idf stuff for some time now, to compile programs for = esp32 et.all, but their latest version 5.1 (not stable) = complains
each time any of the compilers (they need = linux.ko) is run
=E2=80=A6 
  =    /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found = (required by = /cs/system/danny/.espressif-latest/tools/xtensa-esp32-elf/esp-2022r1-11.2.= 0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/11.2.0/cc1plus)


so is there any version = of libstdc++ that has the missing symbol?

thanks for any insight,

= danny

=
= --Apple-Mail=_DB2A709E-22A5-447C-9DCC-7290F133167D-- From nobody Sat Aug 27 14:50:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFKPD71djz4ZZ7d for ; Sat, 27 Aug 2022 14:50:08 +0000 (UTC) (envelope-from zirias@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFKPD6Wdrz3YTq for ; Sat, 27 Aug 2022 14:50:08 +0000 (UTC) (envelope-from zirias@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1661611808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QFZSufFhHZVysYzBsm1vSHdSLbab3wNsZCA7HOy3WGQ=; b=NYJbHVLgpBYzpeqj+BEqKM6OvPYiQtxi1eRpf0jLh6IHwmsU2WCh74KPlCLct5923C7oUd pxeM0li93CEhMeAmeIFCaZ+vHHtByh6ww4lO/Rv+y+tLD9W17R+OM+MIxozJFGdc73cP5n /270tUct/9l5RoY13ojwhbRWdwxv2KPHKXC/7kj4zEjla8GROGPEBTg7LbozIGSphgxmnk 8AqmUc5sTRHPzk6zqwfmivfBiEmBLhHZiPbr8mwwdSbD3GcrHq7ITMvXlG2WGSuwUYvgdh R8hkjlW1MHhktS6qN8OaeNT9eKT1FrdN4/G9H5nUbkhx237wtpGS2vfRxmAW1w== Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: zirias/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MFKPD5TGtz17cL for ; Sat, 27 Aug 2022 14:50:08 +0000 (UTC) (envelope-from zirias@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QFZSufFhHZVysYzBsm1vSHdSLbab3wNsZCA7HOy3WGQ=; b=k7M5G86qHeb/TdXbCYGU5m1CzE ADA32n34mJCUlPjftN5NJWis3V+8ZzZ3bcUScmdlDeoQWkCHCBnp7SsEqLQdkO8S+P2dnyEAebLnX cklO4c2rzp7OkZuRcLT9zro7YDQeG22EjliW03fzndw2SK1tYsaX+effsMX3BmnNwuBTqQ6x3pFtG BODOnt5ekVAcaREG0IDCbVjO6JZ1wXQbaoP6X/uPc7UDv40cvRGAPVvjtfR8+qob0GDds/k1xYzqF 9Lj5nwR0hBR4iij10os+I1p0o7upZatGPxU8W7oUhNa6P3X5mNSd/bFRqjfZs3C4SaZPKAZWogXpn G9hzB0pg==; 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 1oRx8R-001i4v-Fn for freebsd-hackers@freebsd.org; Sat, 27 Aug 2022 16:50:07 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.95 (FreeBSD)) (envelope-from ) id 1oRx8R-000493-4p for freebsd-hackers@freebsd.org; Sat, 27 Aug 2022 14:50:07 +0000 Date: Sat, 27 Aug 2022 16:50:06 +0200 From: Felix Palmen To: freebsd-hackers@freebsd.org Subject: Re: GLIBCXX_3.4.20 not found Message-ID: <20220827145006.kg2xd3mau3x44ylz@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-hackers@freebsd.org X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R( Organization: FreeBSD.org References: <7E480491-8FDD-4FCB-AF70-85A50FA6DA2C@cs.huji.ac.il> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rlkt5o5eag6jpm64" Content-Disposition: inline In-Reply-To: <7E480491-8FDD-4FCB-AF70-85A50FA6DA2C@cs.huji.ac.il> User-Agent: NeoMutt/20220429 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1661611808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=QFZSufFhHZVysYzBsm1vSHdSLbab3wNsZCA7HOy3WGQ=; b=Aw2viiXhDvwuEjDQ7rmtc0GOo07wnZ11Mgtg/QUgTLL9lKK7KobeBRSG4nJ/4ImuCK/Uk+ XQdtqUI+RjqhSBqeTPS+PJ277C71Zkx5jGtQvX9+MyJOMkOoOWjyHZp6L6PcAI9saA3oqi pbYC61tlNyRe2QsY8uEP6CnBXI/faaIMx/C/uKTSB8qN/1LIfzSgznyNOOarGzaP2LtXyF mjEistDqAyF8L5UaGnf6IhHp409Ah931DfutsVcJAAewjCkCfVuvSMtnUObj6EwUHX3O0U EDzyKWCrNl3yjeoTptcpuKAgqT9zDe4cvpeDzd5Rv+xRla/IqLzhm16eA4jmLQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661611808; a=rsa-sha256; cv=none; b=RWrhdcv/TxYkVSFfiQG6gt6EhJTN55kWTV02C1q3ifRt/YIrBRfe9QZYozzCK3V42ywdRr s7PeA8hlbSCXLVig51VcErFDFdI2Wg8Wg55tXu9ghCEcpY5890H4aQzh66BGTPrko88ESw TJkQuOFaA9Yo4gJlFAn6LRgB3TmoaEXeKvEWo/w3N9nkkYUxB/KMorhY545C24OEen57ie YscOASev2Oq6N3GZACyjGGiYiFDI6V6vaGVkJnYYdTpLbgHLahoqb4v1+YOkPDMw95QGIh dMgmW2Y7I6tuOqWp+RMisAnbQGENBEI+Vz85nQxjRgFGx4Rz4HqzWWZhjQoWpg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --rlkt5o5eag6jpm64 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Daniel Braniss [20220827 17:41]: > so is there any version of libstdc++ that has the missing symbol? Most likely not. This libstdc++ is just repackaged from whatever CentOS-7 provides, and yes, that's kind of "ancient". The "easiest" solution would probably be to install some other Linux distribution in a jail and use that instead. There are quite some howtos out there on the web :) Cheers, Felix --=20 Felix Palmen {private} felix@palmen-it.de -- ports committer (mentee) -- {web} http://palmen-it.de {pgp public key} http://palmen-it.de/pub.txt {pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231 --rlkt5o5eag6jpm64 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEABYKAH0WIQRpNhPVW79IN7ISOsxUreAGmHnyMQUCYwovHl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0Njkz NjEzRDU1QkJGNDgzN0IyMTIzQUNDNTRBREUwMDY5ODc5RjIzMQAKCRBUreAGmHny Ma68AP0ZeFBgHi3frEWWNYvlJSOxRbOahbsasyi1QZgpu8FEiwD+OV6AAcjmIP13 t2hDsYXWekSrKFf7LWSpCftapVgFxgE= =8xh3 -----END PGP SIGNATURE----- --rlkt5o5eag6jpm64-- From nobody Sat Aug 27 19:22:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFRS44gY6z4b2rh for ; Sat, 27 Aug 2022 19:23:00 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFRS36b20z3wqm for ; Sat, 27 Aug 2022 19:22:59 +0000 (UTC) (envelope-from mason@blisses.org) Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id E187E17D952; Sat, 27 Aug 2022 15:22:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1661628172; bh=Kk6+5Pa2PsZdzHkdC+yVeS53Ny5MwyTKTsHbAKL6yLc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=P33wvZRxjkK2VLNQTaqYULXvJEsb8fmufaZTbqhufFTC0JlOLVWw/0YS/M+PV/vbO zk32vBEr5Ue5fXYQDTn/M7HdcFM5HqQw3PqsQ+tNjyCT9XA29+wZ1B8ieAVx8YOyA3 0Ne7AAyie5tucsRcEoCX78SBZTcr+rIJYS455iU18fhnYWH+pZ6zRN7kNWYdeKT1fL /Xekuid34NYCiiKLZ5NXtjkNvuEvfQ9JyTzGD7OGWokVwa/VaPwZqzIiaPP9baPJf+ XWxJXt7AuX/Pie8ullpZEOKKajNWv/lTz+SaM39oDfjvza2zXb/ZuN5izokXUAagPM ALxTShdI44bRQ== Date: Sat, 27 Aug 2022 15:22:51 -0400 From: Mason Loring Bliss To: Jamie Landeg-Jones Cc: freebsd-hackers@freebsd.org, eugen@grosbein.net Subject: Re: Help debugging Vultr boot delay...? Message-ID: References: <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ecqGcqUUDxIYJ6My" Content-Disposition: inline In-Reply-To: <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net> X-Rspamd-Queue-Id: 4MFRS36b20z3wqm X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b=P33wvZRx; dmarc=pass (policy=quarantine) header.from=blisses.org; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-5.10 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --ecqGcqUUDxIYJ6My Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2022 at 03:29:46PM +0100, Jamie Landeg-Jones wrote: > < smbios.chassis.version=3D"pc-i440fx-5.2" > > smbios.chassis.version=3D"pc-i440fx-7.0" > < smbios.system.version=3D"pc-i440fx-5.2" > > smbios.system.version=3D"pc-i440fx-7.0" This is interesting. I've included the new detail in my Vultr report. =46rom the bug report: > I see 5.2 matching Debian stable and 7.0 matching Debian testing/sid > (or Bullseye backports) if it's Debian, with the only Ubuntu match > being Kinetic Kudo, 22.10, and I'm guessing you're not running that > since it's not released yet. So I'm going to spin up a hypervisor here using QEMU/KVM versions to match and I'll see if I can reproduce the odd results. --=20 Mason Loring Bliss mason@blisses.org They also surf, who only stand on waves. --ecqGcqUUDxIYJ6My Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmMKbwcACgkQnrJXcHbv JVWzDxAA1LFPeKFCOH71mXMxEGsLNyu7T962wtmGSpHNj1TGf7G/03mwH+dryutv UGuOVYzWzt6kHUPQRUy6lnGvktqKcxGnEbADtD6fd9g4n6ITRylHSoHzemx+GirL oXmkE0Rz6lucM1xosByDy3WIq7ODTYZIxY1oUd9/4kkbE82eExkYIsvvdkzTjPEF 1QO7C3sQdqP+zJ6y1cLNxJBdU5FslmlFQ1JTJw/IG+QTMrUElIuI5X3MdHquomfO 5TEFOAciJ7XgtYLXMpQ5noRkiG171gVRf3PYsHEFxVDPWkSPw2QczBS741O1/ARW hkjQfSWdJNjZfHJ8IJsAlYcf7DhSe3T5kUntYmQGHGcDeIBD4bqU1maMOlfCS5Y4 pGaXdZQ9jqpX7ehDwppy0U8L8X/F17dZFEH1Yk6FcghIZyrfAqgpGXkd222dBbxu myuOSPh8fCQeCjqNEKeebvI6n2vAl9oKRhbLpvXFTM0KR3zF+fsMbakUcO9P8JGS wuZH1vDFkhWxbpUi1ujZ5M5CDdlQJYFbyDoY4xRd4+Dgbm2fdUw9Ew+i7RFggAJQ EcMhSshKeWXAOxJrr3UVvlkC/XdQGfPFprKWuCQzGf6ENeEWaxyQAEsknYnfBYo1 39mSiH/OzQx2T1nW9j5A51/wah5h/UwEKo4oCX/aDRWJr2P14Hs= =r1/F -----END PGP SIGNATURE----- --ecqGcqUUDxIYJ6My-- From nobody Sat Aug 27 19:30:20 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFRcv4XLPz4b3ZN for ; Sat, 27 Aug 2022 19:30:39 +0000 (UTC) (envelope-from freebsd-ml@daemonbytes.net) Received: from mxout01.bytecamp.net (mxout01.bytecamp.net [212.204.60.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFRct2yQcz3y0F for ; Sat, 27 Aug 2022 19:30:38 +0000 (UTC) (envelope-from freebsd-ml@daemonbytes.net) Received: by mxout01.bytecamp.net (Postfix, from userid 1001) id 287402F927; Sat, 27 Aug 2022 21:30:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=daemonbytes.net; h=date:from:to:subject:message-id:in-reply-to:references:mime-version:content-type:content-transfer-encoding; s=20140709; bh=sH/aLn3cC03kJZIdlDrbMea0heU=; b=FIG/+Hm/jxbyDZ5OYSJz+MVs8Op06xxSfJft5N1pFvwFRPmIQE+rn83GNWToN0b5qqdjep9lOxrYYRv1qZSeBHW+0NTSc3dOelvltIoDTzmrASnB6jeeSzYCZaeLkU1Ydz3oyS3NRDy9LmK0pivsijgYHR0abBqcGDRtHfib/TM= Received: from mail.bytecamp.net (mail.bytecamp.net [212.204.60.9]) by mxout01.bytecamp.net (Postfix) with ESMTP id D99672F924 for ; Sat, 27 Aug 2022 21:30:35 +0200 (CEST) Received: (qmail 76158 invoked from network); 27 Aug 2022 21:30:35 +0200 Received: from unknown (HELO elitebook) (request@daemonbytes.net@46.114.210.16) by mail.bytecamp.net with ESMTPS (DHE-RSA-AES256-GCM-SHA384 encrypted); 27 Aug 2022 21:30:35 +0200 Date: Sat, 27 Aug 2022 21:30:20 +0200 From: "Daniel Dowse - daemonbytes.net" To: freebsd-hackers Subject: Re: GLIBCXX_3.4.20 not found Message-Id: <20220827213020.b69351d492bc17b92ec4b561@daemonbytes.net> In-Reply-To: <20220827145006.kg2xd3mau3x44ylz@nexus.home.palmen-it.de> References: <7E480491-8FDD-4FCB-AF70-85A50FA6DA2C@cs.huji.ac.il> <20220827145006.kg2xd3mau3x44ylz@nexus.home.palmen-it.de> Organization: daemonbytes.net X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MFRct2yQcz3y0F X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=daemonbytes.net header.s=20140709 header.b="FIG/+Hm/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-ml@daemonbytes.net designates 212.204.60.217 as permitted sender) smtp.mailfrom=freebsd-ml@daemonbytes.net X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[212.204.60.217:from,212.204.60.9:received]; R_SPF_ALLOW(-0.20)[+ip4:212.204.60.0/24]; R_DKIM_ALLOW(-0.20)[daemonbytes.net:s=20140709]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12693, ipnet:212.204.32.0/19, country:DE]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[daemonbytes.net:+]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[daemonbytes.net]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 27 Aug 2022 16:50:06 +0200 Felix Palmen wrote: >[...] > The "easiest" solution would probably be to install some other Linux > distribution in a jail and use that instead. There are quite some howtos > out there on the web :) > >[...] Hi Danny, for Felix's idea you could simply use BastilleBSD ( https://bastillebsd.org ). https://bastillebsd.org/blog/2021/08/01/bastille-experiments-with-ubuntu-and-debian-linux-containers/ Good luck & best regards Daniel From eugen@grosbein.net Sat Aug 27 20:36:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MFTCC73yGz4b9dl for ; Sat, 27 Aug 2022 20:41:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MFTCB5Y7Cz44YV for ; Sat, 27 Aug 2022 20:41:58 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27RKaR50065261 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Aug 2022 20:36:28 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: mason@blisses.org Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27RKaOJf061991 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 28 Aug 2022 03:36:24 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Help debugging Vultr boot delay...? To: Mason Loring Bliss References: Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <0d0cd0fe-06f3-bab6-8fc9-949115f0ffba@grosbein.net> Date: Sun, 28 Aug 2022 03:36:15 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.4 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on eg.sd.rdtc.ru X-Rspamd-Queue-Id: 4MFTCB5Y7Cz44YV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[grosbein.net]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 24.08.2022 21:20, Mason Loring Bliss wrote: > On Wed, Aug 24, 2022 at 12:34:50PM +0700, Eugene Grosbein wrote: > >> So, my instance has not such problem. > > This appears to be something new, although that you're not seeing it on > that VM is interesting. It might be specific to some datacenters. > > My testing here has used the New Jersey data center. > > I've just spun up a new one to collect usbconfig and pciconf output. > > usbconfig: > > ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) > ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) usbconfig output is same as mine. And pciconf is very similar with only difference in VGA, mine shows: vgapci0@pci0:0:2:0: class=0x030000 rev=0x00 hdr=0x00 vendor=0x1013 device=0x00b8 subvendor=0x1af4 subdevice=0x1100 vendor = 'Cirrus Logic' device = 'GD 5446' class = display subclass = VGA Also, I use syscons for system console, sc(4) not vt(4). > --------------------------------------------------------------------------- > > pciconf -lvvv: > > hostb0@pci0:0:0:0: class=0x060000 rev=0x02 hdr=0x00 vendor=0x8086 device=0x1237 subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '440FX - 82441FX PMC [Natoma]' > class = bridge > subclass = HOST-PCI > isab0@pci0:0:1:0: class=0x060100 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7000 subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '82371SB PIIX3 ISA [Natoma/Triton II]' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:1:1: class=0x010180 rev=0x00 hdr=0x00 vendor=0x8086 device=0x7010 subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '82371SB PIIX3 IDE [Natoma/Triton II]' > class = mass storage > subclass = ATA > uhci0@pci0:0:1:2: class=0x0c0300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x7020 subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '82371SB PIIX3 USB [Natoma/Triton II]' > class = serial bus > subclass = USB > intsmb0@pci0:0:1:3: class=0x068000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x7113 subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4 ACPI' > class = bridge > vgapci0@pci0:0:2:0: class=0x030000 rev=0x02 hdr=0x00 vendor=0x1234 device=0x1111 subvendor=0x1af4 subdevice=0x1100 > class = display > subclass = VGA > virtio_pci0@pci0:0:3:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1000 subvendor=0x1af4 subdevice=0x0001 > vendor = 'Red Hat, Inc.' > device = 'Virtio network device' > class = network > subclass = ethernet > hdac0@pci0:0:4:0: class=0x040300 rev=0x03 hdr=0x00 vendor=0x8086 device=0x293e subvendor=0x1af4 subdevice=0x1100 > vendor = 'Intel Corporation' > device = '82801I (ICH9 Family) HD Audio Controller' > class = multimedia > subclass = HDA > virtio_pci1@pci0:0:5:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 > vendor = 'Red Hat, Inc.' > device = 'Virtio block device' > class = mass storage > subclass = SCSI > virtio_pci2@pci0:0:6:0: class=0x00ff00 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1002 subvendor=0x1af4 subdevice=0x0005 > vendor = 'Red Hat, Inc.' > device = 'Virtio memory balloon' > class = old > virtio_pci3@pci0:0:7:0: class=0x00ff00 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1005 subvendor=0x1af4 subdevice=0x0004 > vendor = 'Red Hat, Inc.' > device = 'Virtio RNG' > class = old dmesg is quite different because my instance is FreeBSD 13.1-STABLE #0 37c9ff4ad and Hypervisor: Origin = "KVMKVMKVM" real memory = 1073741824 (1024 MB) etc. From nobody Mon Aug 29 12:59:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MGVrb3v6rz4b57S for ; Mon, 29 Aug 2022 12:59:27 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MGVrZ3FJSz46ht for ; Mon, 29 Aug 2022 12:59:26 +0000 (UTC) (envelope-from meator.dev@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id b16so2464756wru.7 for ; Mon, 29 Aug 2022 05:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:from:to:cc; bh=sSaqctWoFsOfJwWxT6DmiskWd0BGzs+6lvKf/a41HgQ=; b=DDyYbv/anjcr9zyyTVTlPZZpssb5GqxTsORsKjETRPhvbd1fU9QZzOap1kgfp64/T4 Nj1ArZXVVOG00FK6/V+qp/Wop8XTOQnFMzNSgqG0Aywoc56ZCIZddwRqK1PP35SrEa40 IyauOz5bnnfRCEkdb4c5XnZsFrOMVWhHvQMNNkeapym80dqXIsApwOh4v03MfIbpWZ4A 9nR8w1bso7HF6zHYwggsjH3SIYT8ieXI9dHsw3q82viv5rvjxwKYwojJGR7zsOMHrP0A 6ruzuHCERhgmqCQM9zu8ppQoYzahuB7y4Jwz0cuerdpf5Bkr/8w0H2lFCe1lGuPcz32d h7/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=subject:from:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=sSaqctWoFsOfJwWxT6DmiskWd0BGzs+6lvKf/a41HgQ=; b=ngJWdqV1Puhzxkd1TFkVXl14eqmuQfIc3C0xoY67xLyjKhJNqNGPDiqeK5lY64FngM WXU9cBGw/DPfulhgch4Ha9vXU/g6VH2S+T7xpjxelLRb5yV5qZMZaiODm7sDgfvSyLDg LP0J7mTqtnf41BZVj94lPokyaZXOuadpIC39XNY053PgR1Di/GTnZ0Xpto60eK14kEcB yP+CNV3gQiK+gGy0JL2xlJaluX39vMgX1uQN7LsdHTIpK2IDsqa1JhaPk3wPV3uwW6jr hnL56+vYP/ugIBa+y8o88T3Ei2m9TpHDwgmsbYEhrRCWP6qlISSV8gpRCdlWApxNl3VK NfAw== X-Gm-Message-State: ACgBeo1Bn9vKcA4fXpU5hq2G3yii3jPoJAFFh0NfZddDMerdxx3gXB0R 8uYjO7m8S8wmSXHlk+kFS2jD1rznghU= X-Google-Smtp-Source: AA6agR5C3UcpMlbzQqffGB3vPCLbTYgyCWnCZB19i+UVpjnb6srUHKm8+FAqyuEg6GOLmm4KL//dzg== X-Received: by 2002:a5d:6da9:0:b0:225:59e9:68d7 with SMTP id u9-20020a5d6da9000000b0022559e968d7mr6386038wrs.475.1661777965365; Mon, 29 Aug 2022 05:59:25 -0700 (PDT) Received: from [192.168.0.109] ([91.187.59.126]) by smtp.gmail.com with ESMTPSA id r38-20020a05600c322600b003a536d5aa2esm8298899wmp.11.2022.08.29.05.59.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Aug 2022 05:59:24 -0700 (PDT) Message-ID: <8f80646a-eae5-5252-2d07-74cf9b601ce2@gmail.com> Date: Mon, 29 Aug 2022 14:59:11 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Content-Language: en-US To: freebsd-hackers From: meator Subject: How to detect file creation and file modification inside a directory? Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Bc12WuIevqzXL1g8QZXYJ0fI" X-Rspamd-Queue-Id: 4MGVrZ3FJSz46ht X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="DDyYbv/a"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of meator.dev@gmail.com designates 2a00:1450:4864:20::434 as permitted sender) smtp.mailfrom=meator.dev@gmail.com X-Spamd-Result: default: False [-2.06 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.992]; NEURAL_SPAM_MEDIUM(0.93)[0.932]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::434:from]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------Bc12WuIevqzXL1g8QZXYJ0fI Content-Type: multipart/mixed; boundary="------------1lPu3OfbbqQA009hUObVfI4h"; protected-headers="v1" From: meator To: freebsd-hackers Message-ID: <8f80646a-eae5-5252-2d07-74cf9b601ce2@gmail.com> Subject: How to detect file creation and file modification inside a directory? --------------1lPu3OfbbqQA009hUObVfI4h Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkuIEkgd291bGQgbGlrZSB0byBwb3J0IGEgaW5vdGlmeSBjYXBhYmxlIHByb2dyYW0gdG8g RnJlZUJTRC4gSSd2ZSANCmFza2VkIGFyb3VuZCBoZXJlIGFuZCBJIHdhcyByZWNvbW1lbmRl ZCB0byB1c2UgbGliaW5vdGlmeS1rcXVldWUuIFRoaXMgDQppcyBuaWNlIGJlY2F1c2UgSSB3 b3VsZG4ndCBoYXZlIHRvIHJld3JpdGUgdGhlIGlub3RpZnkgbG9naWMgYW5kIEkgY291bGQg DQpqdXN0IHJldXNlIGl0LiBPciBzbyBJIHRob3VnaHQuDQoNCk15IGdvYWwgaXMgdG8gZGV0 ZWN0IGZpbGUgY3JlYXRpb24gYW5kIGZpbGUgY2hhbmdlcyBpbiBhIHNwZWNpZmljIA0KZGly ZWN0b3J5LiBUaGUgd2F5IEkgZG8gdGhpcyBpcyB0byBpbm90aWZ5X2FkZF93YXRjaChmZCwg ImRpcmVjdG9yeSIsIA0KSU5fTU9ESUZZKS4gQnV0IEkndmUgZm91bmQgb3V0IHRoYXQgZ2V0 dGluZyBhIElOX01PRElGWSBldmVudCBpcyBwcmV0dHkgDQptdWNoIGltcG9zc2libGUgb24g RnJlZUJTRC4gSGVyZSBhcmUgbXkgZXhwZXJpbWVudHM6IA0KaHR0cHM6Ly9hc2NpaW5lbWEu b3JnL2EvREpNVUNMeUFXanlIZ1VRbUc0QkFmZ0RSVQ0KDQpJJ20gZ2V0dGluZyBJTl9PUEVO IGFuZCBJTl9BQ0NFU1MgZXZlbnRzLiBCdXQgdGhlc2UgYXJlIGFtYmlndW91cy4gSSANCmRv bid0IGNhcmUgYWJvdXQgb3BlbmluZyBvciBhY2Nlc3NpbmcgdGhlIGZpbGVzLCBJIGFtIGlu dGVyZXN0ZWQgaW4gDQp3cml0aW5nIHRoZW0uIEhvdyBjYW4gSSBkZXRlY3QgdGhpcz8gSXMg bGliaW5vdGlmeS1rcXVldWUgY2FwYWJsZSBvZiANCnRoaXMgb3Igc2hvdWxkIEkgbG9vayBm b3IgYWx0ZXJuYXRpdmVzPyBNeSBvdGhlciBvcHRpb25zIGFyZSByYXcgDQprcXVldWUoKSBh bmQgc3lzdXRpbHMvZGlyZXZlbnQuIHN5c3V0aWxzL2RpcmV2ZW50IGRvZXNuJ3QgcmVhbGx5 IGhhdmUgYSANCndheSB0byBpbnRlZ3JhdGUgaXQgaW50byBhIEMrKyBwcm9ncmFtLg0K --------------1lPu3OfbbqQA009hUObVfI4h-- --------------Bc12WuIevqzXL1g8QZXYJ0fI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEEew9YpeDxouoRV4pzGhTLNGTL5b8FAmMMuCAACgkQGhTLNGTL 5b+a7Qv+KmyK+SApuAQKKApj6BwQt2hl+BZnwbiVrWKgV3EzVyKGhIheqWuWsIJa 8uZDJuask68e/ZpDwURvOFmtDJtr9pwz1auVtv/UHqKvG85ahf2yDY+NpH6W/MXe wzRhyMw5K0cSIDTgDkFyYVB7VSFTKBU2D50t/RcX8sUMJVNPkXYwX72BCFixfxvd 1wP+SVyDwmy15+sGuzwjUMVQP62oNui3FlsYXMr+f8DyAU9mzfIONXOb44v4kkJ8 1as+CsHDD9zkWkhwszj1zjAeE8ZLJYhzDdET4+Gc5axWeNf6CbkrTrIeAzDUml7E OuudPyVvFCt6aWg/bQAApidcAYVSNxFfJcLiWt94if5AZUewBAswCX7VKTBdHLBR 8vso4hs1EZBs8JFau6FtFM+JPWBNfEkM/uQRyiZeNGvTvJH8wIUo3G4gUd8anbAZ eZsqH7EB3awZQ+Uka/TOOTCS7MdGU4y4uEW1UUZpvnMyI8vj37pdxsiPCfKR+qcO 9qJjnToq =g2d+ -----END PGP SIGNATURE----- --------------Bc12WuIevqzXL1g8QZXYJ0fI-- From nobody Mon Aug 29 20:17:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MGhZY3TyJz4Zd1k for ; Mon, 29 Aug 2022 20:17:57 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MGhZX5VGNz3dxP for ; Mon, 29 Aug 2022 20:17:56 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qt1-x82a.google.com with SMTP id y18so7057311qtv.5 for ; Mon, 29 Aug 2022 13:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc; bh=iprGCSlZcn7hmyJm3INdthMtneGdfWxeLz3oCLzMFiU=; b=TUeXZnBTPY3GP16/bDGQlln5mhqpYlm18ghoYPY8Ph3Jmj/Sp2fZLtQfvUcjz6Aeoo xvQHoUEh/VoIT3zDbjg/6OOWSaihGVhgzL4c13i/u5aKlN7TkGxoUjcWOr3mLyduD7R3 DCHFq3KW5GKqhBEziydwo3s+/HhpHxLcsD38YNocbX+cxgTeCPVAY39bMm3Y03gU8mX+ KMLpcJaTBY6zDpPzHAENJu03Rd6lKFQo15w6sCftdzTrsM1pZQmXjMWbvfUGbt+JkVuj wol595WohzP8LIhR8QzI7q2M6A6IlQxGIPMVJhtlIHJWVBRnoVztNyiNms09M08HSq/6 97bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc; bh=iprGCSlZcn7hmyJm3INdthMtneGdfWxeLz3oCLzMFiU=; b=rDrfXmeCRpXaXVBaqQ7x3wMTNL/jopjHNLktBXtWOREmx61MYq4UF6U07AgDMhWGuJ zNKYZsu0NvieVWzbqzSAIWzT+zzRyWhAfIg9t84WYwDtOttNtUafg+KDFQ7ZA45jjKVg w3z5Rdd0lsk2N7FZg44kzUrRoSabSrCcORHwUybhXcuOXxboZcn8/NRZkszheXtnmLkM +K1/6poGO5RS82K6Y13gnmo2ROjq60vkgUYRShc43ZBoR1f7aTYglIZVUYLqpb/tdz6g KF4mVH0syA1mPZ8RCNEpKEIj6YlUFrO93Venwpt3brIFoan/Pf+HnpO5xyjrEDJs+Mqm OE6Q== X-Gm-Message-State: ACgBeo2cdLE2MIsbePuR3wvlkKHS9yoagPuUlzvQq0mxfvh3MnFaubwL dKnMOb1cmS0Z4WwL/57OXZBsCZq2ttkLMrFoea+C1AChD3R4/wIz X-Google-Smtp-Source: AA6agR7CEvV1LxbSKTi8tCF+ab18etHrxvF3Gtv85AjJ3kh6u/0Gg3P67Db5YcICyNdWEE1JBC+HVJQPkkQIlH60fcU= X-Received: by 2002:ac8:7f84:0:b0:343:6984:5af2 with SMTP id z4-20020ac87f84000000b0034369845af2mr11939885qtj.494.1661804275971; Mon, 29 Aug 2022 13:17:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Jake Freeland Date: Mon, 29 Aug 2022 15:17:51 -0500 Message-ID: Subject: SRC Contributions: Advice and Objections To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000008e484305e766f552" X-Rspamd-Queue-Id: 4MGhZX5VGNz3dxP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=TUeXZnBT; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::82a) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from]; ARC_NA(0.00)[]; DMARC_NA(0.00)[technologyfriends.net]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jake]; DKIM_TRACE(0.00)[technologyfriends.net:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000008e484305e766f552 Content-Type: text/plain; charset="UTF-8" Hi there, I've been hard at work over the last few months contributing to FreeBSD through the Google Summer of Code program and learning about the operating system. Now that I am almost finished with porting Intel's igt-gpu-tools to FreeBSD, I am thinking about other potential SRC contributions that I can get started on. I ran into a few OS-related problems during my project that I would like to fix. I thought I would share those issues here for advice and potential objections. * Implementing signalfd: https://man7.org/linux/man-pages/man2/signalfd.2.html This is a huge one. I needed to comment a lot of important code inside of igt-gpu-tools to compensate for signalfd's absence. I am reading The Design and Implementation of the FreeBSD Operating System by McKusick, Neville-Neil, and Watson (excellent read by the way) to get a comprehensive grasp on how FreeBSD handles signals and file descriptors internally. I plan to finish the book and get started on this first. * Implementing timerfd: https://man7.org/linux/man-pages/man2/timerfd_gettime.2.html I am unsure whether it would be beneficial to upstream POSIX timer patches for igt-gpu-tools or to implement timerfd for FreeBSD. I am erring on the side of implementing timerfd if other applications need to use it in the future. * Implementing userfaultfd: https://man7.org/linux/man-pages/man2/userfaultfd.2.html Page fault handling and processing from the userspace. * Adding %m format specifier to scanf: The %m format specifier is a POSIX extension to the ISO C standard that can precede %c, %s, and %[. The %m allocates a memory buffer to hold the string including a terminating null character. * Adding the gettid() funtion: https://man7.org/linux/man-pages/man2/gettid.2.html This function grabs the thread identifier for the currently running process. I am not yet informed about FreeBSD's thread scheduling so I don't know if adding this function is even necessary. * Adding ETIME errno: I am not sure how necessary this one is because ETIMEDOUT exists, but I understand the distinction between the two. I would think that ETIME would already be present if it were necessary. Any input would be appreciated. Thank you, Jake Freeland --0000000000008e484305e766f552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I've been hard at wor= k over the last few months contributing to FreeBSD through
the Go= ogle Summer of Code program and learning about the operating system.
<= div>Now that I am almost finished with porting Intel's igt-gpu-tools to= FreeBSD, I am
thinking about other potential SRC contributions t= hat I can get started on.

I ran into a few OS-rela= ted problems during my project that I would like to fix.
I though= t I would share those issues here for advice and potential objections.

* Implementing signalfd:
This is a huge one. I needed to com= ment a lot of important code inside
of igt-gpu-tools to compensat= e for signalfd's=C2=A0absence. I am reading The
Design and Im= plementation of the FreeBSD Operating System by McKusick,
Neville= -Neil, and Watson (excellent read by the way) to get a comprehensive
<= div>grasp on how FreeBSD handles signals and file descriptors internally.
I plan to finish the book and get started on this first.

* Implementing timerfd:
I am unsure whether it = would be beneficial to upstream POSIX timer
patches for igt-gpu-t= ools or to implement timerfd for FreeBSD. I am
erring on the side= of implementing timerfd if other applications need
to use it in = the future.

* = Implementing userfaultfd:
Page fault handling and processing from the u= serspace.

* Ad= ding %m format specifier to scanf:
The %m format specifier is a P= OSIX extension to the ISO C standard that can precede
%c, %s, and= %[. The %m allocates a memory buffer to hold the string including a
<= div>terminating null character.

* Adding the getti= d() funtion:
https://man7.org/linux/man-pages/man2/gettid.2.html
This function grabs the thread identifier for the currently running = process.
I am not yet informed about FreeBSD's thread schedul= ing so I don't know
if adding this function is even necessary= .

* Adding ETIME errno:
I am = not sure how necessary this one is because ETIMEDOUT exists, but I
understand the distinction between the two. I would think that ETIME
would already be present if it were necessary.

Any input would be appreciated.

Tha= nk you,
Jake Freeland
--0000000000008e484305e766f552-- From eugen@grosbein.net Mon Aug 29 20:34:42 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MGhyL630yz4ZfhB for ; Mon, 29 Aug 2022 20:35:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MGhyK69zhz3gRw for ; Mon, 29 Aug 2022 20:35:05 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.16.1/8.16.1) with ESMTPS id 27TKYsVK022245 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Aug 2022 20:34:55 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: jake@technologyfriends.net Received: from [10.58.0.11] (dadvw [10.58.0.11] (may be forged)) by eg.sd.rdtc.ru (8.16.1/8.16.1) with ESMTPS id 27TKYrEQ087825 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 30 Aug 2022 03:34:53 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: SRC Contributions: Advice and Objections To: Jake Freeland , freebsd-hackers@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Tue, 30 Aug 2022 03:34:42 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT autolearn=disabled version=3.4.6 X-Spam-Report: * -0.0 SHORTCIRCUIT No description available. * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on hz.grosbein.net X-Rspamd-Queue-Id: 4MGhyK69zhz3gRw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=fail (mx1.freebsd.org: domain of eugen@grosbein.net does not designate 2a01:4f8:c2c:26d8::2 as permitted sender) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_FAIL(1.00)[-all]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FREEFALL_USER(0.00)[eugen]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[grosbein.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 30.08.2022 3:17, Jake Freeland wrote: > * Adding the gettid() funtion: > https://man7.org/linux/man-pages/man2/gettid.2.html > This function grabs the thread identifier for the currently running process. > I am not yet informed about FreeBSD's thread scheduling so I don't know > if adding this function is even necessary. Take a look at pthread_getthreadid_np(3) From nobody Mon Aug 29 20:39:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MGj3t6DJFz4ZgRY for ; Mon, 29 Aug 2022 20:39:54 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MGj3s6wWYz3hbT for ; Mon, 29 Aug 2022 20:39:53 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id B0D353C0199; Mon, 29 Aug 2022 20:39:47 +0000 (UTC) Date: Mon, 29 Aug 2022 20:39:47 +0000 From: Brooks Davis To: Jake Freeland Cc: freebsd-hackers@freebsd.org Subject: Re: SRC Contributions: Advice and Objections Message-ID: <20220829203947.GB89898@spindle.one-eyed-alien.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4MGj3s6wWYz3hbT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-3.90 / 15.00]; SIGNED_PGP(-2.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCPT_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; FREEFALL_USER(0.00)[brooks]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Aug 29, 2022 at 03:17:51PM -0500, Jake Freeland wrote: > * Implementing timerfd: > https://man7.org/linux/man-pages/man2/timerfd_gettime.2.html > I am unsure whether it would be beneficial to upstream POSIX timer > patches for igt-gpu-tools or to implement timerfd for FreeBSD. I am > erring on the side of implementing timerfd if other applications need > to use it in the future. This might be a good place to start on kernel work because we already have an implementation for linux compat. You'd need to move the implementation into sys/kern and add manpages, syscall, and libc wrappers. IMO this is a good idea vs using a wrapper epoll-shim because it allows better support for timers in capability mode. > * Adding %m format specifier to scanf: > The %m format specifier is a POSIX extension to the ISO C standard that can > precede > %c, %s, and %[. The %m allocates a memory buffer to hold the string > including a > terminating null character. This seems reasonable (unless there's a move afoot to deprecate this in a future POSIX, but I don't think I've seen traffic to that effect.) -- Brooks --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJjDSQTAAoJEKzQXbSebgfA2UoH/jNnRQ/+f8b1Enxb4ZrEswji M3g9CzJgUPs5ANhRzPAWXKHKLcafN3UKHdgnTEs+yDZATdMVrRJ2SnjRx1LznYJ2 cnGmTit4ovGfyFLYNAoSMo17rm7oZS96RMKwh5fQF0iLQy8HD/6A/WaLJifebTSw BdxzRwyG6qjHudyiHlr5Ge350s8Oxlu3yQQW18UgqJc9VpsvQn7+1Vbmt2agU5p0 8ckri8dkDFRogQRw3VzbYzWOWS3b+r8ugAV6EkF5trHDvFfspu6HXKKlPfqtV3b6 qhl0s8LZrixVdS6/srdF9Jc/mUkt29IuUP4NTSvdgIxFrgdHEr9iIsJ+5VrTvaI= =/Yg2 -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From nobody Tue Aug 30 16:24:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MHCMQ4jh0z4ZqNh for ; Tue, 30 Aug 2022 16:25:06 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MHCMP3PZnz44pR for ; Tue, 30 Aug 2022 16:25:05 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: by mail-qk1-x731.google.com with SMTP id j6so8795888qkl.10 for ; Tue, 30 Aug 2022 09:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=myb0aelF5nn13Om80UM9y4QxQGWxQO+DlRJEqQ22+EI=; b=hP0M6CDrCChQKLHiPkGwXhgA/CL20jaPpRGopa1T7YFonfjC43hdeWkzfy0S+pF3O+ hnSZZyJuBcHcHydeLYiSb2o4b/C21wNU4iYwRo+0jvn0GZZjvOjDXXkaHHVAwQ9vaF4c xSf0DI7Z7MKcsjRTVd3yzChQ4ICmRzXNDOa/AbUJ3/noVtvcwJfKPmu5HOvSl0WyCzeg p4CUNxXzoS4n5RqBrr8Gqftw48urkcSTyWxAb9LrJ/yaFAn4UzcVHC0/mFNhNyxSs9XU QvdiE3vtoK80RQJ6zqmMCAs540XZXC4PgdaAHsiVuPXZkqMAPukRFXAWDk7N+U+s7sy6 Rrrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=myb0aelF5nn13Om80UM9y4QxQGWxQO+DlRJEqQ22+EI=; b=tSq4jXxJZ3om9R/EvtKeRqE0QrI94o68B/DRggCpB6JWJ9zz+mt/YOaS9DnBwYfbAo T4IVvmUV9FXxhKfdr6vub32IXpRZA/1JmfMcjgIYyKZowp2bquLnoZhyq6M1QmBqQIIX QyzoRUi1+3w8uVBKnOaE5zkZ8kaBLAFQYW2QD0JfjjqSZIbZruV4Z3gQINag/82EOf8G Kk4kd3BiHm6GnIOG5wXuyCqzuxqrLglSyty4Qxe3quO+6lVdWuAMLRspyd/8jVOuLqOR 00DxgEc2T/OotmbKUEfjlyn4j2FCPlvosJFl+G34hB23PZUSyvMdru/v4n8M4GyEcx/2 pIDw== X-Gm-Message-State: ACgBeo1yZbVdAHSGnW8AlRacwMF/PVzAqbIi22XVvhqN7kAlyaeJoGyG Jwz0SFtzApV0WEU1In0omygZHuoF5Vs7orTp9hUH8Q== X-Google-Smtp-Source: AA6agR4Algvx0Js5RVv1aquYvpzn39SJpXrD/k1PAGrS5muba1ud8AoRuaE6J7syhNXVWSMo7ANgb/f5NsPwBFmezVk= X-Received: by 2002:a05:620a:25c8:b0:6ae:bf82:8f36 with SMTP id y8-20020a05620a25c800b006aebf828f36mr13039441qko.354.1661876703879; Tue, 30 Aug 2022 09:25:03 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20220829203947.GB89898@spindle.one-eyed-alien.net> In-Reply-To: <20220829203947.GB89898@spindle.one-eyed-alien.net> From: Jake Freeland Date: Tue, 30 Aug 2022 11:24:55 -0500 Message-ID: Subject: Re: SRC Contributions: Advice and Objections To: Brooks Davis Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009876e705e777d2aa" X-Rspamd-Queue-Id: 4MHCMP3PZnz44pR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=hP0M6CDr; dmarc=none; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=jake@technologyfriends.net X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; DKIM_TRACE(0.00)[technologyfriends.net:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jake]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[technologyfriends.net]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000009876e705e777d2aa Content-Type: text/plain; charset="UTF-8" Brooks, Thank you for the response. I did not know there was a pre-existing LinuxKPI timerfd implementation. I will surely use that as reference for building the native FreeBSD version. The %m format specifier is not incredibly important for my work, but I thought it would be nice to have in FreeBSD's libc. Has there been discussion about deprecating %m from POSIX in the past? Jake Freeland On Mon, Aug 29, 2022 at 3:39 PM Brooks Davis wrote: > On Mon, Aug 29, 2022 at 03:17:51PM -0500, Jake Freeland wrote: > > * Implementing timerfd: > > https://man7.org/linux/man-pages/man2/timerfd_gettime.2.html > > I am unsure whether it would be beneficial to upstream POSIX timer > > patches for igt-gpu-tools or to implement timerfd for FreeBSD. I am > > erring on the side of implementing timerfd if other applications need > > to use it in the future. > > This might be a good place to start on kernel work because we already > have an implementation for linux compat. You'd need to move the > implementation into sys/kern and add manpages, syscall, and libc > wrappers. IMO this is a good idea vs using a wrapper epoll-shim because > it allows better support for timers in capability mode. > > > * Adding %m format specifier to scanf: > > The %m format specifier is a POSIX extension to the ISO C standard that > can > > precede > > %c, %s, and %[. The %m allocates a memory buffer to hold the string > > including a > > terminating null character. > > This seems reasonable (unless there's a move afoot to deprecate this in > a future POSIX, but I don't think I've seen traffic to that effect.) > > -- Brooks > --0000000000009876e705e777d2aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brooks,

Thank you for the response. I d= id not know there was a pre-existing LinuxKPI
timerfd implementat= ion. I will surely use that as reference for building the native
= FreeBSD version. The %m format specifier is not incredibly important for my= work,
but I thought it would be nice to have in FreeBSD's li= bc. Has there been discussion
about deprecating %m from POSIX in = the past?

Jake Freeland

On Mon, Aug 29, 2022= at 3:39 PM Brooks Davis <brooks@f= reebsd.org> wrote:
On Mon, Aug 29, 2022 at 03:17:51PM -0500, Jake Freeland wrote: > * Implementing timerfd:
> https://man7.org/linux/man-pages/ma= n2/timerfd_gettime.2.html
> I am unsure whether it would be beneficial to upstream POSIX timer
> patches for igt-gpu-tools or to implement timerfd for FreeBSD. I am > erring on the side of implementing timerfd if other applications need<= br> > to use it in the future.

This might be a good place to start on kernel work because we already
have an implementation for linux compat.=C2=A0 You'd need to move the implementation into sys/kern and add manpages, syscall, and libc
wrappers.=C2=A0 IMO this is a good idea vs using a wrapper epoll-shim becau= se
it allows better support for timers in capability mode.

> * Adding %m format specifier to scanf:
> The %m format specifier is a POSIX extension to the ISO C standard tha= t can
> precede
> %c, %s, and %[. The %m allocates a memory buffer to hold the string > including a
> terminating null character.

This seems reasonable (unless there's a move afoot to deprecate this in=
a future POSIX, but I don't think I've seen traffic to that effect.= )

-- Brooks
--0000000000009876e705e777d2aa-- From nobody Wed Aug 31 10:12:35 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MHg3J5B3nz4Zv9h; Wed, 31 Aug 2022 10:12:44 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward502j.mail.yandex.net (forward502j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MHg3H5nFFz44GG; Wed, 31 Aug 2022 10:12:43 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from sas2-e7f6fb703652.qloud-c.yandex.net (sas2-e7f6fb703652.qloud-c.yandex.net [IPv6:2a02:6b8:c14:4fa6:0:640:e7f6:fb70]) by forward502j.mail.yandex.net (Yandex) with ESMTP id D09261120E63; Wed, 31 Aug 2022 13:12:38 +0300 (MSK) Received: by sas2-e7f6fb703652.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id CTwy6lM0Js-CajOPujJ; Wed, 31 Aug 2022 13:12:37 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1661940757; bh=o/a4xDm9ts1gACqwSPfa/huiXzuqGcvZw5u3ayXlLCY=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=GiseuKxML0HvScpHC6P2UqBhcEo/jcpjuY/kTJWrpBLlcXY33cpNQBAjxhZ6P+Ki4 uHkbktWLErLqsunaPW3eiceLwQMKUgqn5aiIs75npgjB/JYqnw2qr7GZgF1mvsHuMB +Oton6UsbQlc2e9EkrasAcyGiV53yrLdFkW115DA= Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: FWSync driver about IPFW synchronization From: "Alexander V. Chernikov" In-Reply-To: <20220827174810.69a63888dc85bc3694296f79@elwix.org> Date: Wed, 31 Aug 2022 11:12:35 +0100 Cc: net@freebsd.org, ipfw@freebsd.org, hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <00EB39D7-C435-49B5-9899-80F215F3986F@ipfw.ru> References: <20220827174810.69a63888dc85bc3694296f79@elwix.org> To: Michael Pounov X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MHg3H5nFFz44GG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=GiseuKxM; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:801:2::112 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0::/52:c]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org,ipfw@freebsd.org,net@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:208722, ipnet:2a02:6b8::/32, country:FI]; FREEFALL_USER(0.00)[melifaro]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[ipfw.ru]; RCPT_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 27 Aug 2022, at 15:48, Michael Pounov wrote: >=20 > Hello all >=20 > I want to propose one new feature about IPFW. FWSync driver exchange = dynamic state and aliase records between routers. > If you have interest about such feature to be implemented at FreeBSD = code base. You are fill free to get it. >=20 > I will be glad also for dicussion about current FWSync driver. >=20 > There is a help, how it can be install and patch OS code base to have = connection between them > http://www.elwix.org/site/documentation/fwsync-document/ Kernel-space syncer which is able to sync nat states is a pretty good = approach. Mind putting it on phabricator? The current format is not particularly = easy to review/integrate. >=20 > Best Regards > Michael Pounov =20 >=20 > From nobody Wed Aug 31 13:25:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MHlLP1lZMz4bQ46 for ; Wed, 31 Aug 2022 13:26:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MHlLM5zdwz3jxr for ; Wed, 31 Aug 2022 13:26:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 27VDQ0ZD098414 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Aug 2022 15:26:00 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1661952361; bh=08sj/z2FimAIVurjKOqUgAnBYkUmlwxiH0OlbjCtQy4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R3Zvhvc+pOQBAHdxuQVjUUV0nBMYJtUhIVGNPaB8dr8X16WACP47iccJF9PdKk9pf +msuAZhJBkK78N9dx45mg3qTFSs4w3a2tcSUVrdaCqUNgoUTeV5X5N+B7ljg1OsCmw SPlk+B5clpSevFfJnhJQa207sO3pjzWqSdI0vpJw= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 27VDPxax093726; Wed, 31 Aug 2022 15:25:59 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 27VDPxQY093723; Wed, 31 Aug 2022 15:25:59 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 31 Aug 2022 15:25:59 +0200 (CEST) From: Wojciech Puchar To: Eugene Grosbein cc: freebsd-hackers@freebsd.org Subject: Re: ipfw nat problem In-Reply-To: <71545bb7-a5ea-510f-8d67-4f07fe0887ae@grosbein.net> Message-ID: <6943ac7f-d8dc-c4f7-55c1-aff365be246a@puchar.net> References: <623ac39e-2915-463a-9e4c-9f99bae28c69@puchar.net> <57a9cad0-c2ef-6e1f-2185-0f7563fe3758@grosbein.net> <90b59493-95d6-5b2a-b0dc-2fece0a9df7b@puchar.net> <71545bb7-a5ea-510f-8d67-4f07fe0887ae@grosbein.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MHlLM5zdwz3jxr X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=R3Zvhvc+; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 26 Aug 2022, Eugene Grosbein wrote: > 26.08.2022 17:42, Wojciech Puchar wrote: > >> Anyway - with ip.forwarding on ssh still disconnect randomly. Just after much larger amount of data transmitted (like 10-100MB, not <1MB) >> >> Just on this server. Any ideas what may be wrong? > > Maybe you use ipfw nat (or natd) and forgot to disable TSO on external interface, > so some packets get broken as TSO is not compatible with libalias. Right. TSO. Now it's fixed. From nobody Thu Sep 1 00:00:08 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJ1Q03vLHz4bjZ7; Thu, 1 Sep 2022 00:00:08 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MJ1Q02hDvz3sqx; Thu, 1 Sep 2022 00:00:08 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1661990408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=G1LDVHAoU8THrSlO73FFeIjz46KPvYokMnNWcLsHF6i9z5I7DwpE1pdN5bcDUld11coFL2 D3BnFaUvMYSmBpU5KNDwbiNwW6QZRu/H+Dj6evMlNcrnlpOeEE59cm8FTcx0eQgiO2ud3U ICd36xTgFn7/lgozer72gJ/GE+MxGRKO8SFWc0tIJjj/Rm1Gf22mo9VACQL9NFVxyrweaR io1nwYbmuWo2sPDroJbpOQu0Wc/SGE7cbmZhEW/+7PExKkcA2x3iBg5Lldah0nsDVadRkh vOJ/Qd6a0yS6zbtJTIH0ruUHJNDTkdRjvllYCG6mPQcb/aT2PzW9WTGCWDUhkw== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 34F3A173A9; Thu, 1 Sep 2022 00:00:08 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: Call for 2022Q3 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20220901000008.34F3A173A9@freefall.freebsd.org> Date: Thu, 1 Sep 2022 00:00:08 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1661990408; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=fGeHSZxYqCH/HXQujod2RBmG81zZena28K1aR/jY7idqy8hAM0bL4qcEEvDkKCpzsJhSO/ HYyMI1ffXNRum7QQnpc6RgmaBv+Nq4m4cWDmUzUQN7YBAtcsxY1DYZzK9cSofnRKrwLLr7 8RzdMniS0o8a5K30s99RI4cAoUNeZRU0rESxEQzMO3gkEhK9z7rwUEoYFPpqicoh+F7rKS Jzbb5eisaFKNmNPoFUTND/GHJ5rBvRiDc5odU6FnlL2/5qeYVydPBUL3f7eA9HeYKK4qUu yHauYiO4pJYKdcbAhiUqSR104eg+xBzfcTvAPM/cplQp4i4xC7FSItAnD4PBdw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1661990408; a=rsa-sha256; cv=none; b=npiMCWPUzHLvEkmck/qhB1v3qhQBi4/qfV4yJWtp08ZyZTO3K1BLg5oCT2jIQj5DxGBi+g mqTLDntrGujKbGiHrjzc9N8GLfpYfvDrQQZuJMMRwtPSZyuq5wTBb0S8JLNRUAc01r+mdB Q8bSIyCQ/b8ZqdPOl3vMZyd68LUk1gz5j34d/GSnwpPfnxSnY/L8blpdlwiPkx76Lvn3TA qe4dhHiEQunMSy/mcRDF9IkHCMQv4jqyYQTSMTxHILSF6Bvq2eAaUIiohSVf68vgI+HI/C u7dgk/F0OeJ1V1zLqJ1q6Qlmo/H/gkwQ064iUiVXeFkp1Nr+VIrpUPIcKMO0hA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is September, 30th 2022 for work done since the last round of Quarterly Reports: July 2022 - September 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q3 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Thu Sep 1 04:40:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJ7cW70bvz4bCXB for ; Thu, 1 Sep 2022 04:39:39 +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 4MJ7cW6SWJz3DGK for ; Thu, 1 Sep 2022 04:39:39 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662007179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pkxaf4U/l5RQCswm8yUiiVFhKx8j1LsenVqr88iwaR8=; b=cMAsbqUwCywpcY1NP0fgQix6rr0TphB2OxCbwdl9gAwjRcdsvy0FZxR6I+mkIsekJvjxlB GWQ8knBXoC30zNXlQFSMss5eU1CP9utSCJimh+ydX3Tc5Rb6lUt7f/A+kva4xIeTvbYgb7 VVfTsc7S4q6H4v+fLMH+erj86b+L7hJ/W7armi5nr+IlvfhpcXpEKlodPau0X6sMGTnXr8 BcJerNvfkcS3h/ifQHvBxK7BrjpbSZ6/tVJeFHbbV4lzMxvI+6iMfPvCmYnGEJpDXpgq8g 0MEdxoI1yRaSnKWp0JU5Lqk+MpLfs8Mln78imPYUv86l1iEg7u96azw07KrusA== Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MJ7cW5PnWzWgW for ; Thu, 1 Sep 2022 04:39:39 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qv1-f46.google.com with SMTP id jy14so6850159qvb.12 for ; Wed, 31 Aug 2022 21:39:39 -0700 (PDT) X-Gm-Message-State: ACgBeo29e+R/E/jcxyPZ/ZtObDje6KzzH0Yv+MAnioBmlovaVzu8iukx JMAA1CbCbbd++TFLv8boNfxnBaICCS+v73cJ7kE= X-Google-Smtp-Source: AA6agR6nQgYxm57BmPSyE5hHTMviJmKjTHrpEIu0EcMAwIgQpMki/U5/8BcVvAWQIa4VwDna34yOM+KS3wlUz3Yn2ss= X-Received: by 2002:a05:6214:5086:b0:499:2e7:d7fa with SMTP id kk6-20020a056214508600b0049902e7d7famr15784226qvb.109.1662007179110; Wed, 31 Aug 2022 21:39:39 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Kyle Evans Date: Wed, 31 Aug 2022 21:40:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: FreeBSD on Apple M1 To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662007179; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pkxaf4U/l5RQCswm8yUiiVFhKx8j1LsenVqr88iwaR8=; b=H1S1q3AeEOvzdPp2+y+5MSb8c5ltigGWoXdEFpdQEX6n718/lTSOMyX6se2pbowLRkBjC7 xoE0QvqTpYRJd+JjRfRKl2hUzGPzfz7jv6MmB1srFPaYP00Cq25mlM225IJSy3m53YABQk c7FoLiNCWXeHNaKZpE40a+jH2S5AADmPtLpKh2rphGxl/vzJLDZoXiBuQTAVb2IZ1Yv1Gu Iy5WgoZHDhr+F4nNbjXh9oKYmHhq26rHdFMPv374+TA1rMrwnchYX7OhOOVz6TKkFBZGoJ dZDARwobdFKJwg/eL7KQIkbStuZTTbnqcjKsfplucTJL7VTfWZY+gAbvWXN8aQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662007179; a=rsa-sha256; cv=none; b=rJRIty3Qdz1SmXHFcsbdFMgMJIB+sWXXM9KzgJ2Vq7n+1BP5BaYP76fI0Sy2Hv/gv15X0d SZvifYgPz3ZejsM6FUn0WUtJxifL7vyJ0wk7IHqCqMSywJA1vnzKY/fuCk3+lpPszP/lg5 LIU0LFWLCHirtKaozVXNbmJp2pAtL6iQTk5/aJqA7X/Dckxarp+XQu+QCQImCQR60qcA4H i8NRyroxppBS8wRQlvDKS8MVpE5xve4AVnZSBTXhj24pEuWL20RNAS2JwVNpsalouTFLaa AqAFLw6ySvFmM9deWqyFJcRhUBEDxcX7tD9Qhhsawq1DlAcP0aSc6IGeO1Lx+w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi, Thanks to a donation from nc@, I had received an Apple M1 Mini for FreeBSD baremetal porting purposes a long while back -- we made some amount of progress, but have since stalled a bit due to some issues (lack of familiarity with FreeBSD USB/PCI, time). I'd like to open up this hardware a bit for other people to hop in and help out, so I've setup an account on a local Mac Studio running macOS that may be used for serial access to the M1 mini, which is our initial target. If you have any experience with USB/PCI on FreeBSD or want to take a stab at it, please get in touch and I will arrange access. I'll be at EuroBSDCon and fully intend to try and poke a couple people about the problem areas we're currently experiencing there, as well. Thanks, Kyle Evans From nobody Thu Sep 1 23:36:44 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJcwC3vK8z4b2vj for ; Thu, 1 Sep 2022 23:39:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MJcwB4Ttgz44dm for ; Thu, 1 Sep 2022 23:39:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 281NdrFn066473 for ; Thu, 1 Sep 2022 23:39:53 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 281NdrNQ066472 for hackers@freebsd.org; Thu, 1 Sep 2022 16:39:53 -0700 (PDT) (envelope-from david) Resent-From: David Wolfskill Resent-Date: Thu, 1 Sep 2022 16:39:53 -0700 Resent-Message-ID: Resent-To: hackers@freebsd.org X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJcrh4LJKz4b2fS for ; Thu, 1 Sep 2022 23:36:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MJcrg3yq9z44dh for ; Thu, 1 Sep 2022 23:36:51 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 281NaiC5066410; Thu, 1 Sep 2022 23:36:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 281Nai0a066409; Thu, 1 Sep 2022 16:36:44 -0700 (PDT) (envelope-from david) Date: Thu, 1 Sep 2022 16:36:44 -0700 From: David Wolfskill To: hackers@freebsd.org Subject: Reasonable/sane limits for kern.msgbufsize? Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RuaTJOZqeFO4W2mx" Content-Disposition: inline X-ThisMailContainsUnwantedMimeParts: N X-Rspamd-Queue-Id: 4MJcwB4Ttgz44dm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [-4.56 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170:c]; MAILLIST(-0.15)[generic]; HAS_LIST_UNSUB(-0.01)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; DMARC_NA(0.00)[catwhisker.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCVD_COUNT_SEVEN(0.00)[7] X-ThisMailContainsUnwantedMimeParts: N --RuaTJOZqeFO4W2mx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Empirically, I have found that for dmesg.boot to contain the full dmesg =66rom a verbose boot on one of my machines, starting from: ---<>--- APIC: Using the MADT enumerator. Copyright (c) 1992-2021 The FreeBSD Project. =2E.. I need to increase kern.msgbufsize to above 200KiB (204800); so far, 262144 (256KiB) seems to work for stable/12. (Actual size of /var/run/dmesg.boot just now was 216929 -- 212KiB.) Note that the default value is 96KiB (98304). In this particular case, the machine has 256GiB RAM -- but kernel address space (I expect) remains a constrained resource. How much trouble am I asking for if I set kern.msgbufsize=3D262144 in /boot/laoder.conf? It might be cool to be able to do that only for a verbose boot, and have a somewhat more reasonable value for a non-verbose boot.... [Rationale: I build FreeBSD often -- tracking head, stable/13 and (currently) stable/12 daily. I place salient information on a Web site; that includes a copy of /var/run/dmesg.boot -- from a verbose boot. But I noted a while back that much of the first part of the latter was missing; I only found out "how much" a few minutes ago.] Peace, david --=20 David H. Wolfskill david@catwhisker.org See "Truth Social"? Read it as "Pravda" -- and adjust expectations accordi= ngly. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --RuaTJOZqeFO4W2mx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYxFCDF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1Hu+AP4gw5agBu/cxC8BJEXbMzoT8ZGkbCt3JFYPVGKa/x5AtgEA3gXfX9oAb8Qj bXKCc9GF1tmb+fQySp92HEkbS7xmZgQ= =bf91 -----END PGP SIGNATURE----- --RuaTJOZqeFO4W2mx-- From nobody Fri Sep 2 12:12:42 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MJxdd0rRFz4btwd for ; Fri, 2 Sep 2022 12:13:25 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MJxdc0828z44FW for ; Fri, 2 Sep 2022 12:13:23 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id C91D824FE8; Fri, 2 Sep 2022 14:13:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1662120787; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=I070WxEJ7QBcvXRg0V3dTg3AcPP6Xn9AXdDqE4minoQ=; b=sLlj8OfA6HACzK1PxJ5qNUF7/iT+5KGL4WFJVXSyBoWzbwDwHWFJR154XISbvT0i541dpZ XXFqo+0LiGON/QNNdQPyuZ915+SIoMqdxKNPWVCPThIHdD/TpS12Jns1NwadX198JHjlcj 69QNddk6pH7JpGmz8oZ3pM7IVJzYZehWZnIsZNO4MUSNsMAUQ7stfdoQsFrIa8Ob62I4B4 n19mVV6MfuIBf2HDNq0KfzQ7Rs8+AcQ74X7smZicRa+0QOcCw5T5+t0w539PJa2DBRfztR r31Fv6b1oZfdkUJwhrGEcWXnm1pRTEGVK8bPF+LICZ5gYJz4QE5NtGAN+YOJMg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 8383E8628; Fri, 2 Sep 2022 14:12:43 +0200 (CEST) Date: Fri, 02 Sep 2022 14:12:42 +0200 Message-ID: <20220902141242.Horde.F8KUcpLMmFg47nq6-kf_UgK@webmail.leidinger.net> From: Alexander Leidinger To: David Wolfskill Cc: hackers@freebsd.org Subject: Re: Reasonable/sane limits for kern.msgbufsize? In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_Id9dcEJlWhBSK7X5faYJhNL"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4MJxdc0828z44FW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=sLlj8OfA; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 2a00:1828:2000:313::1:5 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-4.10 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_Id9dcEJlWhBSK7X5faYJhNL Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting David Wolfskill (from Thu, 1 Sep 2022=20=20 16:36:44=20-0700): > How much trouble am I asking for if I set > > kern.msgbufsize=3D262144 > > in /boot/laoder.conf? I have it set to 204800 since some years (5-10). I haven't seen an=20=20 issue=20which I would attribute to this setting. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_Id9dcEJlWhBSK7X5faYJhNL Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMR8zoACgkQEg2wmwP4 2IYZRRAAigYYMDoi04jaldKvVIzjnIPIBlXemZu2LNbCBKptQ0wky7znViQTOUKw IBeqfcz/iJs6tlhJlw73vfaBawx0NOiP/G3zYh+Z62Y00Cab0A3TRnqImZvXHuJd ysaG1Gh70bjgPQ3zussn4H8RjPrmRupnVrBBkBoXgjG0PCxH/R0PdJqizRAWeuDM plRDHV7s84WD9xU2gB788Lw8dN7VN7DwqbMzkr8+IQleg8JGAddrVveW5m12Eonr lGol19k0RxG/602qtJffm4a9YWW9ht4hddI6DT/Tigc2fWzqRL/HeK9pExW50ge9 p7w0hhj9lC0bgweZZol1+c3eVf9qtSSNVZwd+ELF7hqlBb5GFgJQzDfLGOhvzqXV lI+2tpGXOj7q+0S3YmtIPWgBq4VNcKCBE4cfBAK4E8TKTjWTtyG/sp7InZsWsmAh RJqem+opDaA181nUsleTH7oWqIzVBvqLC7YyrR6lcHFjI0wNPEyUdqgYPHWVbuD/ jynnlRss3rEIwulUAGSAVJRZqPqw1KQrwpaSwc6LjTbMeViCxjCy4QPBUbbB6sYI ANc+LZHZG8fnUyY3LI8O6YoM1dRd553gUi+Bz8TsniYDLNlwzcmmPOkRu5wYGpcu FvTymgn9OeUsq46XFJGtpKksjlNQDMWIJSqU9A+0EpObmRTaWkk= =E4Ux -----END PGP SIGNATURE----- --=_Id9dcEJlWhBSK7X5faYJhNL-- From nobody Mon Sep 5 04:24:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MLb5m1YrLz4c2H0 for ; Mon, 5 Sep 2022 04:25:00 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4MLb5l0Ns2z42J2 for ; Mon, 5 Sep 2022 04:24:58 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 2854OnO2054177; Mon, 5 Sep 2022 05:24:50 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 2854Onkd054176; Mon, 5 Sep 2022 05:24:49 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202209050424.2854Onkd054176@donotpassgo.dyslexicfish.net> Date: Mon, 05 Sep 2022 05:24:49 +0100 Organization: Dyslexic Fish To: mason@blisses.org, jamie@catflap.org Cc: freebsd-hackers@freebsd.org, eugen@grosbein.net Subject: Re: Help debugging Vultr boot delay...? References: <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net> In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 05 Sep 2022 05:24:50 +0100 (BST) X-Rspamd-Queue-Id: 4MLb5l0Ns2z42J2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-2.70 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jamie]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; HAS_ORG_HEADER(0.00)[]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Mason Loring Bliss wrote: > On Sat, Aug 27, 2022 at 03:29:46PM +0100, Jamie Landeg-Jones wrote: > > > < smbios.chassis.version="pc-i440fx-5.2" > > > smbios.chassis.version="pc-i440fx-7.0" > > < smbios.system.version="pc-i440fx-5.2" > > > smbios.system.version="pc-i440fx-7.0" > > This is interesting. I've included the new detail in my Vultr report. > > From the bug report: > > > I see 5.2 matching Debian stable and 7.0 matching Debian testing/sid > > (or Bullseye backports) if it's Debian, with the only Ubuntu match > > being Kinetic Kudo, 22.10, and I'm guessing you're not running that > > since it's not released yet. > > So I'm going to spin up a hypervisor here using QEMU/KVM versions to match > and I'll see if I can reproduce the odd results. One thing I didn't try, and that's creating a FreeBSD instance with the "q35" system version. (That should happen if you do a manual install from an ISO.) -- q35 was disabled for FreeBSD due to problems which I think have been fixed in current/stable (but not made it to "release" yet. So trying a recent "current" ISO may prove useful. Cheers, jamie From nobody Mon Sep 5 15:29:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MLsrf00G0z1HBWp for ; Mon, 5 Sep 2022 15:29:38 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MLsrd03C9z3xpP for ; Mon, 5 Sep 2022 15:29:37 +0000 (UTC) (envelope-from mason@blisses.org) Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id B024617D751; Mon, 5 Sep 2022 11:29:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1662391768; bh=gRgNn5/6bxZNM6Vgiu9+RQiOAX9oDpUDCbuUQoaESPw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AkVqo//JyzV8+bG6inHRaEafVSFd1LpHWhVRQVOs0Mv0GPgzCDsGdpdvu6nkWgJA4 ijoHDJHUbpuvLfreF8aJABj7wjSSXZgTPVlPNoL7TkI8ww/vyiYzKBmkvcOMWssOvX UveX/Z10C26//Z+8qxWPNg/a5bn8cFw9mxUvct2L+E9G9NX2P1al2iVZmY+JaSn2g5 Ttcc/8b2Ztl+20r9YLiLKAo5uVqMQMiFZ5siuiYlUAgEn72dwTaFGOo2/LLrQ01IEo CZ2NekNLgbgL9dDdaKH6oXR6vMWDUdjlnB38xdUwltOq7Tx4CnFLGRKZlv+EW1zpMk P/4GF+Nb+e7Aw== Date: Mon, 5 Sep 2022 11:29:27 -0400 From: Mason Loring Bliss To: Jamie Landeg-Jones Cc: freebsd-hackers@freebsd.org, eugen@grosbein.net Subject: Re: Help debugging Vultr boot delay...? Message-ID: References: <202208271429.27RETkGg063822@donotpassgo.dyslexicfish.net> <202209050424.2854Onkd054176@donotpassgo.dyslexicfish.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sMQKahRbI9qzUMiz" Content-Disposition: inline In-Reply-To: <202209050424.2854Onkd054176@donotpassgo.dyslexicfish.net> X-Rspamd-Queue-Id: 4MLsrd03C9z3xpP X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b="AkVqo//J"; dmarc=pass (policy=quarantine) header.from=blisses.org; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-5.08 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --sMQKahRbI9qzUMiz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 05, 2022 at 05:24:49AM +0100, Jamie Landeg-Jones wrote: > One thing I didn't try, and that's creating a FreeBSD instance with the > "q35" system version. (That should happen if you do a manual install from > an ISO.) Vultr's data seems to match QEMU as shipped in newish Ubuntu and/or Debian Testing or backports, so I spun up a hypervisor using Debian backports. Despite matching the version(s) I can't seem to elicit the same odd hypervisor probe or the delay during boot, either with the default i440FX or with Q35. That said, good idea about trying a -current ISO on Vultr to see if that responds differently. Thank you. --=20 Mason Loring Bliss mason@blisses.org Ewige Blumenkra= ft! (if awake 'sleep (aref #(sleep dream) (random 2))) -- Hamlet, Act III, Scen= e I --sMQKahRbI9qzUMiz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmMWFdQACgkQnrJXcHbv JVVj7w/9EG2AY3oCEHPHPyB45WjiMYdkXwDbObSWHFvlvFn8IxjF1hZjouqqqKtD fulgH9TkARv4+csTtjhGhDmNYq191WfzQQ7PzJblx9kPH5MmUEwTYSA6g0yBGYzO M+cGBO7koXsMm5X081jkuhXL+ufs16NRLeRjBXky2nuSikVQev94T7FjfS1vr3qA OV8dBbbPgtzJDqG8vduYwsAxvnt/DOm0iwRFgBIIA6NwNwyEwAuCjZLbqCng/BqT EFpW30XCQRjkPnzlc4erwZ2HQsJfdg+GSv2zNSvdL0lNnSf1GmBXQB685S429v1z t2gmSkERB5Ga7RqbNDJCiMYgpKXqmCfIUlS5Bm7B3QuszC9SjLhLUaA1ala+gggX QEAYUph3wbJTvh1U1XswUcs2/IFwGLZb0GaUZgCWlXm1cEQSYiR0CZikW73QW5Cc f6b3spBgH644FyXNvtAYWcfkl/xqf7KQDdPVwcqT0ZcXP6n58ri35FEKlmcnoPu7 3lT4HEakW3F1XDdCQ2XxjwRpWLvuTxKmnjL6SnT2dG0KuHUEZqxTz7oQGyDvkeYF mINkZv0b3hrf9vEqA9DZmZQSqTEu+N0hrCIZwC7x2sKm93BKi3otfzL6gLcY7sN4 ZCojnm8x+dJB3EHUJr+RBIS1tBg8jOlp9HEaWP79htW/lGc7Q/I= =VG3v -----END PGP SIGNATURE----- --sMQKahRbI9qzUMiz-- From nobody Wed Sep 7 08:30:35 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MMwSs0spfz4bvll for ; Wed, 7 Sep 2022 08:31:09 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MMwSq6hg8z4DPR for ; Wed, 7 Sep 2022 08:31:07 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from outgoing.leidinger.net (p5b165562.dip0.t-ipconnect.de [91.22.85.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id 9414B24472 for ; Wed, 7 Sep 2022 10:30:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1662539454; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=Lfpbm+pTaxYFNQDOpdYVLL85wZqCd0f3cTxKRp4m3Js=; b=IeLICE/9qasaQVtW29yf/C3uEGXFyGVnIS9IM/LhAzhL7hTEUrXPSXsHCn7ihRN/NlJWdJ DDYcodV7M3oh76orrnK0zVQ4RDYfqHWShl0yqa6JmDulRPdJihR9I6+iafDmiGT6RZy07h fzCg5sDZlHCilEML/KddB2b15z4lwtoTvt7JXvxLEnozUhYVbIRejc5NSFs0jYe0zABfD3 b7P532Ur2FsdqQjMFnf/5xJJoUEkiPlfir3XJFYv46O6P1zVDojo44WWynkT9LhGRn92n1 RZVgS81zGbzTWEIVts6lvJ2NF+aoZJB7+hZslWaY7IJA7amUdnsIquhTaErFPA== Received: from webmail.leidinger.net (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (Client did not present a certificate) by outgoing.leidinger.net (Postfix) with ESMTPS id 5399085C2 for ; Wed, 7 Sep 2022 10:30:36 +0200 (CEST) Date: Wed, 07 Sep 2022 10:30:35 +0200 Message-ID: <20220907103035.Horde.QnPH99OPFHigN6eBfGewFjP@webmail.leidinger.net> From: Alexander Leidinger To: hackers@freebsd.org Subject: Rust in the kernel Accept-Language: de,en Content-Type: multipart/signed; boundary="=_3RoTqRrnn6Q7c36vOKuK-1e"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4MMwSq6hg8z4DPR X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b="IeLICE/9"; dmarc=pass (policy=quarantine) header.from=leidinger.net; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[leidinger.net:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_3RoTqRrnn6Q7c36vOKuK-1e Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I haven't seen it discussed somewhere, so: David Young has ported the=20= =20 old=20rust kernel module example to a more recent version of Rust. https://research.nccgroup.com/2022/08/31/writing-freebsd-kernel-modules-in-= rust/ https://github.com/nccgroup/freebsd-kernel-module-rust Maybe someone is interested in this. Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_3RoTqRrnn6Q7c36vOKuK-1e Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmMYVqsACgkQEg2wmwP4 2IbNRA/9FMz6FpRcrF0raWsnztPLgz8hXDOq0extUKetTI6rW8F2XeWP/yT4mfYD X5uzBB7t+7w5cHxUOsgezMGlNLeAScHiu/AE48mGUs9vRgPEwDRGBaDYpBpfatWf vjsNl6lCY8hrgKOsjtSZI2qNRAfgd/rKcaQghYZ39MNZBzsgALE3VDtVqVwCFHbO jlMDxQJrtq702JVH/Bpz1m7q6KE9Rdtd6y2Zh54xa9fcv7kaKoP/16S5DmQ3lGrh rx89M5VymynsSiw5/dyrdznhjuMQNbWFgjX5ebSdBr9as9MJxykRlz7QJdsOHcKB 8MfIOaKZ4plCBxJdidokmu+kbZy4+kO3oAvIju/XQbMU9x1eqm9mZoDTHIFTpWIf cT7HElBDwnAabLdxCGWwwdhrmnazaAtvt5UkfrbrlZ2aSzgFpBgCgjN8mn7x5kQq PLIzeRUoiTWKU2n+W8VDWiMd/duCQijru9W1WMzFa9/vt+3m1csGejKiyBy3wUL8 j0joWzZENA0RI0y40MNE36mRFlmi1hkTpLuA4ClN0mtlaR6NRJeBl7A5XQSKe8cy QWQNTKK29y4V1vrSqn7JRIGrezOCPt3J519pjPgUv1Z2bssEYy36ijp69x2mnW9K DqQe/VXg6w3Rkxe0YTjMx7qeF01Equi2++OMbwuwCNG6HJ0vKfo= =4jcV -----END PGP SIGNATURE----- --=_3RoTqRrnn6Q7c36vOKuK-1e-- From nobody Thu Sep 8 00:15:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNKQ66WrVz4bWxP for ; Thu, 8 Sep 2022 00:15:10 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNKQ532WXz3nXK for ; Thu, 8 Sep 2022 00:15:09 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 99E3B5C00DA for ; Wed, 7 Sep 2022 20:15:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 07 Sep 2022 20:15:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1662596108; x=1662682508; bh=qvd56Tkvr6ARKYEzPta6Sh/xYT2wGzgZtcE Mexl++5c=; b=iqApE0runDYSMo7siI33B0RaD+KOdPKQMtdafUrGWuPSOWwC/IK lItXBqOX1mWDz7ak7fbmu6sBErmM3DFXgqzQ1r+yTwpZGzqGlCoFmLNosYj+ciyG V4frySaKsu5/EPnEvD/3LAEO6vx1GUA0sX1j/7gvyFfXF9FjCqU05Ljz9muxkFkO 1oYlBwiAZtCUYI7AUJNxxQ/XQ56tr7NP+lpFwSBPCISt7pQcRt5bLVrmY6KOuAHn CuGJtCHKRgSkPkCKcj8Qmhp02lQpLXwkmMlX/TgIFiaCvJ9ZgTo3G07RpO+cbQ3P DNe6qb8HVS6KVW/Awy8mKCMjqhGkfX16JFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1662596108; x= 1662682508; bh=qvd56Tkvr6ARKYEzPta6Sh/xYT2wGzgZtcEMexl++5c=; b=M aIXbpafPNfxbTdv6yZfGOZ19ckQgV6Qo+/Qj3Vsy6a3p155aogR+cF+tYUDp50cd 4jHok3Hek+7tzA0srgaogCH+JSO4RclZks9eQcoDPF4giF+zaNOlcamCYDXVe5k7 6E8zFfkLdP1cYCV1rhcOp6SWlMGo0cexmI4rI6//qO6Kt/uWMxrYB/40S5Yq/rrJ WelicfDjOjLi0frGgKiwhW1G3wuC1ZjIfl8gwJOvUT3V1bjl62ylCYP3noe2T8eT x3nkiRfV+Ppp5ty9WkTkMSIGKa81fXtbQxE7wx/FO25Jd1cUUUeygLj6ZsiO/rXN KZePUJ9Pomc35O/LBlYpQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedtuddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 7 Sep 2022 20:15:08 -0400 (EDT) Date: Thu, 8 Sep 2022 01:15:06 +0100 From: void To: freebsd-hackers@freebsd.org Subject: poudriere odd error Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Rspamd-Queue-Id: 4MNKQ532WXz3nXK X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=iqApE0ru; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="M aIXbpa"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.29 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-5.10 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.29]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.29:from]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hi, I hope this is the appropriate list for this query. I think I'm right thinking that poudriere would be used by lots of devs? I'm seeing the following output when poudriere starts ptsort: cycle involving doxygen-1.9.5,2 and py39-breathe-4.34.0 ptsort: cycle involving libgd-2.3.3_1,1 and graphviz-2.50.0_9 ptsort: cycle involving texlive-base-20210325_7 and texlive-texmf-20210325 ptsort: cycle involving texlive-base-20210325_7 and doxygen-1.9.5,2 [00:06:30] Balancing pool It then carries on building. Is it a port problem, poudriere problem or a problem with the ports tree? Need I worry? TIA, -- From nobody Thu Sep 8 11:03:39 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNbpW5JLcz4bqtb for ; Thu, 8 Sep 2022 11:03:47 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNbpV2Yqtz42VX for ; Thu, 8 Sep 2022 11:03:46 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 288B3dAr057859 for ; Thu, 8 Sep 2022 11:03:39 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 288B3dOV057858 for hackers@freebsd.org; Thu, 8 Sep 2022 04:03:39 -0700 (PDT) (envelope-from david) Date: Thu, 8 Sep 2022 04:03:39 -0700 From: David Wolfskill To: hackers@freebsd.org Subject: [summary] Re: Reasonable/sane limits for kern.msgbufsize? Message-ID: Reply-To: hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="S+ZF1wz8N/XG85Zg" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4MNbpV2Yqtz42VX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of david@catwhisker.org designates 107.204.234.170 as permitted sender) smtp.mailfrom=david@catwhisker.org X-Spamd-Result: default: False [0.60 / 15.00]; REPLYTO_EQ_TO_ADDR(5.00)[]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; DMARC_NA(0.00)[catwhisker.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_REPLYTO(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --S+ZF1wz8N/XG85Zg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2022 at 04:36:44PM -0700, David Wolfskill wrote: > ... > How much trouble am I asking for if I set >=20 > kern.msgbufsize=3D262144 >=20 > in /boot/laoder.conf? > ... I received a couple of responses from folks who had increased kern.msgbufsize by a fair amount (to 204800 & 1MB, respectively) since=20 several years ago, with no ill effects attributable to that. As I already had a shell script I use to control rebooting (e.g., whether or not to boot verbosely; from which slice to boot), I merely augmented that script so that if I'm requesting a verbose boot, I also set things up to increase kern.msgbufsize "appropriately" (and reset to default if I'm requesting a non-verbose boot). This is probably a bit conservative, but it seems to be working for me -- and /var/run/dmesg.boot gets the full boot log, even for a verbose boot, which was the intent. Ref. the (recent) "dmesg" links on https://www.catwhisker.org/~david/FreeBSD/history/, such as https://www.catwhisker.org/~david/FreeBSD/history/freebeast.14_dmesg.txt Peace, david --=20 David H. Wolfskill david@catwhisker.org "In my administration, I'm going to enforce all laws concerning the protection of classified information. No one will be above the law." -- D. Trump, August, 2016 See https://www.catwhisker.org/~david/publickey.gpg for my public key. --S+ZF1wz8N/XG85Zg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSr0Kzv+UJRY3wfOii0+6PfV4Ix1AUCYxnMC18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0QUJE MEFDRUZGOTQyNTE2MzdDMUYzQTI4QjRGQkEzREY1NzgyMzFENAAKCRC0+6PfV4Ix 1AZOAP4mJNXTt665e+yFePX7ta3oJ6hqwx9HPXdoT0eY7yUOQgD+KnElc3WViepT zh7BFUxZ43Kd33JpZJ7BYBn8Rk28Fgw= =Tq+3 -----END PGP SIGNATURE----- --S+ZF1wz8N/XG85Zg-- From nobody Thu Sep 8 17:21:26 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNmBJ74hXz4cXPm for ; Thu, 8 Sep 2022 17:21:28 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNmBJ40hmz3bZR for ; Thu, 8 Sep 2022 17:21:28 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-pl1-x630.google.com with SMTP id v1so5223495plo.9 for ; Thu, 08 Sep 2022 10:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date; bh=nKhhd5bWKQm6WqmmrvhauAaDOdaKNYW/HK8p1MN6Hjo=; b=SYUV8Guh9D+NKyln16+epJZtSg66HLse94hUQGNxYqbOAAFfqnBL2IzV+Y8FHS+YuB rz2LDTf+xy7WYZKVLShbqNpcXnhGHnEtV8OgwtksNs17mRtIteVqmHAkipKm/gMoqUl1 RNbOK+TjNm2nQ4/+jNBdpfqF377PXnbZFc4So0s0SZU2S9vmtvJJ+E0Pildw755IJUa2 bWu5BjViI09HT7Ey/xupDetp8odybxKe3hctvfi08BtYywnZy00dQZaq+xT8FlRN//nA /aory+VmRtnBcqgLGRc3yUaNEROVPeynbChjexX4QDmk+5NWVSmMXiW86xsVisFg7KC6 /3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=nKhhd5bWKQm6WqmmrvhauAaDOdaKNYW/HK8p1MN6Hjo=; b=4qk+ah3Z7d/vRnkQJif85aUTMv7QQPJ7u1VlB5FA6tWBqu8jN13WUBQN2u7hQcVKhR 4yZbDziK+VL53hkhrfNfUXyCeb1unywXRB0H6fpzx92shcyLCbzGdsdUcr5D21X6qAcE cXfsU6vLCtp9wHnRUteJLqEpeQKqnKMOSsS/NpuaFfVjBKBZNOM7PKKCvSRl/AMFRtHk jN/HSaAbHmyMSNHr+GqEb5YdfZ16oxmGByl3Huej0h9sppzGa88stgOYYJd232r7ejPQ RKq9d4jNqMjCcmcRQgjrcxALWtV8v5TgAtVj8Ja/z6eCwcF5LzmXh/kY6ziwk6e9z/lZ qiwA== X-Gm-Message-State: ACgBeo2aQijqfVcOOGo147ctVBLnP7mSWlGv7B6h2EdKV/iBy4l8m1FC KvmmpDOUU9rSM45mXf5Da7DFZ2PvO06JrhQcgzBu4Ojhj42Ck5kS X-Google-Smtp-Source: AA6agR6sINIb5rGYnVpfmJDaNunUOs4c2G1fKWc5Ms05vyfc3fTtTV/fdJFLBuXO34zH0dDcrTlNaeP4d2ItCGfXXOU= X-Received: by 2002:a17:902:f782:b0:173:1206:cee0 with SMTP id q2-20020a170902f78200b001731206cee0mr9545520pln.130.1662657687171; Thu, 08 Sep 2022 10:21:27 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a17:902:ccc9:b0:175:41cd:2693 with HTTP; Thu, 8 Sep 2022 10:21:26 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Thu, 8 Sep 2022 13:21:26 -0400 Message-ID: Subject: Re: [summary] Re: Reasonable/sane limits for kern.msgbufsize? To: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MNmBJ40hmz3bZR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SYUV8Guh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::630 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.78 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; NEURAL_HAM_SHORT(-0.79)[-0.791]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::630:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > sane limits for kern.msgbufsize > ... > /var/run/dmesg.boot gets the full boot log, even for a verbose A sane default might exist where users can stuff their boxes and kernels full of hardware (drives, GPU's, USB's, CPU cores, LINT, etc) and have the entire verbose boot through login still available in the buffer. Default at times past may not have even supported verbose LINT w/no hw. From nobody Thu Sep 8 23:30:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MNwNM5Gjkz4c2n8 for ; Thu, 8 Sep 2022 23:30:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MNwNM03wVz40WZ for ; Thu, 8 Sep 2022 23:30:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt1-f175.google.com with SMTP id x5so144743qtv.9 for ; Thu, 08 Sep 2022 16:30:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=WxyGsnRQxKB4JRIEyoxu+Ei/vnzKondUwOKXVwAyZv0=; b=DFer4IVz5ze86RSnNiTc9jTsQCxtFdgeYfgC28uCsd1OnjuH0hLdBvhOIkSmApLXYB BanmgDtNHVcdSwTizLPo052XqRRYTTsqmMQ0EO8DOtseIdW4ywSS/rGB7VQYJpJg8XnL N6csiYPhjTCG6mY1Gc1UlAO5EsVHHpZYbSaIhnqeGtE4kExJS8CTao0dpiLo71KNtFFH d9qvrGxa05qcsJmzBlxIMkhT1GJ29ScOQiynQS5bkR66kLwRYVJnhHw1oxzNNQSzj0jD P6KTmv4cvYx7u7vQtAjXnQrMswtIIcyJX+/Eri2pB2a9HGACe7A69jKb2StSjTTaSIsY kJSw== X-Gm-Message-State: ACgBeo3QLwO0N/DhK50dyQfEfZKYpnHZnWcdnPi1uVPPbT6BPRxU+AQ2 wCUlDJVzv2PY3il13nyoaTrJaovl56bBkzGZlJc= X-Received: by 2002:ac8:59c3:0:b0:343:6528:db29 with SMTP id f3-20020ac859c3000000b003436528db29mt10317716qtf.575.1662679842072; Thu, 08 Sep 2022 16:30:42 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 8 Sep 2022 17:30:31 -0600 Message-ID: Subject: Re: sysctl is too slow Cc: Mateusz Guzik , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MNwNM03wVz40WZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-0.92 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.93)[-0.926]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.175:from]; DMARC_NA(0.00)[freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.160.175:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEFALL_USER(0.00)[asomers]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N I finally got around to this. Here's the review: https://reviews.freebsd.org/D36500 On Mon, Aug 23, 2021 at 6:54 AM Alan Somers wrote: > > Ideally, but it's not very high priority, since it's merely a performance issue in a monitoring tool. > > On Mon, Aug 23, 2021 at 6:05 AM Mateusz Guzik wrote: >> >> So is this something you plan on fixing? >> >> On 8/17/21, Alan Somers wrote: >> > Actually, I did get a flamegraph, and only 0.77% of samples were in ZFS. >> > >> > On Mon, Aug 16, 2021 at 7:19 PM Mateusz Guzik wrote: >> > >> >> On 8/16/21, Alan Somers wrote: >> >> > Yes, I see what you're talking about now. There are a bunch of linked >> >> > lists in sysctl_find_oid etc. Good point. >> >> > -Alan >> >> > >> >> >> >> You still want to get a flamegraph, chances are most of the problem is in >> >> zfs. >> >> >> >> > On Mon, Aug 16, 2021 at 1:30 PM Mateusz Guzik >> >> > wrote: >> >> > >> >> >> Last time I checked lookup of a sysctl was very bad with linear scans >> >> all >> >> >> over. >> >> >> >> >> >> Short of complete revamp of the entire thing I would start with >> >> >> replacing the scans with a RB tree at each level. As is if you indeed >> >> >> have 5000 datasets, you are doing increasingly longer walks. >> >> >> >> >> >> On 8/16/21, Alan Somers wrote: >> >> >> > ztop feels very sluggish on a server with 5000 ZFS datasets. Dtrace >> >> >> shows >> >> >> > that almost all of its time is spent in sys_sysctl. ktrace shows >> >> >> > that >> >> >> both >> >> >> > ztop and sysctl(8) call sys_sysctl a total of five times for each >> >> >> > sysctl >> >> >> > they care about: >> >> >> > >> >> >> > 1) To get the next oid >> >> >> > 2) To get the sysctl's name >> >> >> > 3) To get the oidfmt >> >> >> > 4) To get the size of the value >> >> >> > 5) To get the value itself. >> >> >> > >> >> >> > Each of these steps takes about equal time, and together all five >> >> >> > take >> >> >> > about 100us. If the time per call is mostly syscall overhead, then >> >> the >> >> >> > process could be sped up by 80% by combining all of these things >> >> >> > into >> >> a >> >> >> > single syscall: return the next oid, its name, its format, the size >> >> >> > of >> >> >> its >> >> >> > value, and optimistically the value itself, assuming the user passed >> >> >> > a >> >> >> > sufficiently large buffer. >> >> >> > >> >> >> > Am I missing something? Is there any other reason why sysctl is so >> >> >> > slow? >> >> >> > Or should I forget about it, and try to export ZFS's dataset stats >> >> >> through >> >> >> > devstat instead? >> >> >> > -Alan >> >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> Mateusz Guzik >> >> >> >> >> > >> >> >> >> >> >> -- >> >> Mateusz Guzik >> >> >> > >> >> >> -- >> Mateusz Guzik From nobody Fri Sep 9 14:23:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPJBm4kg9z4bWTV for ; Fri, 9 Sep 2022 14:23:44 +0000 (UTC) (envelope-from ihor@antonovs.family) Received: from mail.antonovs.family (mail.antonovs.family [100.25.240.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.antonovs.family", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPJBl5mWQz3lZf for ; Fri, 9 Sep 2022 14:23:43 +0000 (UTC) (envelope-from ihor@antonovs.family) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antonovs.family; s=20200215; t=1662733413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=jSgm2pjkQwrPKYHEvIDC9LbLQX/CZbW+TMZywnQGS+k=; b=jYppvhHp9vIF1GtG9h7pYSXpy30KD/2mEqoU31ZBCosp95T2X+InWhzDnHq02BOJtoymie Wi7jAfm6je+w9bGBofYrhXk2b03Iw5Bp21DwqSuCD/ATvqY73EYWtFXRpcqMgh6E3akKLr bpZhImA4Pf0v1cFA5timR1ZZg7Mbbf8= Received: by mail.antonovs.family (OpenSMTPD) with ESMTPSA id ef7bc9be (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 9 Sep 2022 14:23:33 +0000 (UTC) Date: Fri, 09 Sep 2022 14:23:31 +0000 From: Ihor Antonov To: freebsd-hackers@freebsd.org Subject: Re: poudriere odd error In-Reply-To: References: Message-ID: <038EC8C3-DB5E-43BD-9F4E-2E31C3120BC9@antonovs.family> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Autocrypt: addr=ihor@antonovs.family; keydata= mQINBF4X96IBEADvPg+NzZJSLGnsT8ZihXguiLzgswOy80sbCzHguMy4UVv9NC8F8C90+mDIuWAg fg1XdFgxOkhY5k/z4hlpFRTO5MWDylV60ZcxqpkyRIeUSAYP5Yr5469PT/hS0midWn9Mn7gylGzk Se2+1+CaUHbhgoIkVjih1+VmwOpK7O8+tbh6X4pJ3MlUVayOWzXjdQezZtEx6zs0q9mp7HmekmGJ e+40yevbVUJz4YtUF91XJ4x/oSIyqWpM37HQVuQSWA4bZryJiP6kO2YgfLUCKPgmq8XTQ7QmZMl1 FA0Kq9kpdGHg96pW6vNUD85iPTLb8oiOn/wQwMzjG/Qgnlc+af3LKoZj/tNgXbrYBzRzSwqmz9Se 6XzrYlZvveCevFvW7Jmw252HmmWUJNSuLInFt5+d56t/CRIktocIV9FLjmmvfh5eVmfPM/B0OmOt Ok9yL/H7KLs0AzKcIj8c/SZBw3rn2EyaxShxE8UmYnNSgnTw84nBU0yq1avZglSLGrneRTMBhWQ0 lbvHhpDGkkBwMLevhBAkRaXegou8Fbvycaqkoq8RD8rVzBD/ZU7bOX1Jv6s+iwEYRI6Z8aHfOhfa KcqejBY/Kso4GOUve8TuJ2DRGf57FBDlTxC10wIG/Z7ZxEgEs5uW4UMUxfoQWfJlzKp1hW9YBVXQ 6tt4C4WVoLXTHQARAQABtCNJaG9yIEFudG9ub3YgPGlob3JAYW50b25vdnMuZmFtaWx5PokCTAQT AQoANhYhBJQDEDtVbpD+Sidu5pHxUSdIg+HGBQJeF/eiAhsBBAsJCAcEFQoJCAUWAgMBAAIeAQIX gAAKCRCR8VEnSIPhxkp5D/sGxDnG3iAbd6t8NK0LTeReLpfxjunyHWf08ANpcVEPXnwx4veib0pr cHjEHYloAH5NG8Hfno+ptme08Z7b+6OzQNiwxoaF+BwbUfqhS7AOOjZumds/QLjbQh89iH6AZ5b5 OirsfnOrpz5IcX/MP6GuYKli/a6W5H4S9Bi8XOTJkaGaTMoUFVip7STHXlg7VB32tloVpRjAllWD xhIycr61yMEkR2wHSjQvil2iVj8APU+o4+TiHtjGP8y0XCubh6mI16dgmu8KX+7MOfKw9X4ncJlG pcMhH1cX5RohaAu2kPSAhMP5FicfLwroJWdyJvQT/JSkhPsM+uvRFM1DC+w3Zs3iyLJZRZcc1l+k pqpv82vD6YOQ+7/RoTnPMhuL/NahSvIhZ1O1kx49C6sCE5XQRaCa2C1gEeMMFQU9j7KlrYKj5sfe mrRtSZSloJpOS0SEMiPwN9Vjmku2kKHfQwDhtuQb9ydrMyI5NjUSI12QGcWGk0Nyf+95hWkcqUDM vJA2UHGmPd2Ww4V+LKVu+FJmWrEDoM6n+VeRb/aj78PBXDv/G6WJZvOs3G1b4BxtwkHSeVgBSY+g DFOwBOaSbC3i9Du1O5m+5rsOYnfIU9eNO286KXb1aOYTVdzfGm/SF6+w58tlhv3RvohYdLFcJRKk WIFvNvdcceqgs+CWFcYDgrkCDQReF/vQARAAx4vv42zzaEOIxvPxReDGE7P7o8GzQ+qkWH4fojVV +e4dcvxG6JZFZ6oE2RYk1gglGrZnobJoEbJIAJnE1kGWEwdGChgHBY+wrI/zDCfN6mOp14Pd7giE qA2Xoi39VNongJefxnf7LfrgLJq7bDh0wjoBHkUPTcliwr6xw08graZKnw01QHpTWD/03HwfGIUO +H5QMUqV/gQNltvAF61/45mRfTik+q0Y4WkqSyeqZzx67u4plSErtFjbevAMyCBJr2syczi8nCtT BPvfE5DashMeGAuEjb4xBejSfc/aI5/zxQSVzjd1Kx1jrR05UFVIP0JMDEYHZkz6LkIhAWiy7gIT klsUzMjGQ8tKP0akzmAuuRBKCYtkE+ksIfV+kon9tmflsgCFVM0U3F6RTtQHZ1ShFRlNpkTkd5OU Kvn6QrndujmsXhdsJT+4xhW1KTpUKCs9rSvc391usVCVc7hRHTrdCtyEWVNfJpCWStYGU2bgGhZd vTsp+JtLpVkmta/w3xgmM0i42Oa3OeyykdJ6DnlBDcGkMnmvN8XTItHnulNDEE7HVlqkDjK26+35 q6UiekUPjqGtmZAO+d3+/dIj3Xe0lwgzPkSyPWiXW2e0bSwRBB8njZWIhMWeMff5rVm+w12flBNl BupcoXb04V+j2tf/LY8J7asEhIziaIdnbJcAEQEAAYkCPAQYAQoAJhYhBJQDEDtVbpD+Sidu5pHx USdIg+HGBQJeF/vQAhsMBQkFo5qAAAoJEJHxUSdIg+HGv0YP/2N8IjErOIFdZ+3G8UDu0spl+KLn Dxbp7790N+2eaZX8gg4+5HQyhVPCyd6xKqBtsGLBGZWlrvP97wDV+SZg6kO1EEwi/AYYXC2rDcpB Njo/PT4jQli/LfvZ0Cb+Z0pUMJVrMwtsJJHAUCKIcgH0o8v9YVQ6QADkTel5M0NW6QMLse93J0QS kdjm9MvpolzSEXAWsGUL2Go8eVahm9CSaskMzG9H4RBV4g/hSCQV3SMHzfDK/IV4dPKfEpPg5UBB /0QLFcaqBYBGI5NTcZRFOjM7ftT+lXfwUIr1igOPB937P6Q50Da8eFkpH6WJNcySZTNYqFkbT1XP JmvEVufZkM9iPXu9GPwHmV9+4vWgcMxhnRxlnSCT1fhDtT4Mw41+gXwyYd5ygt4sTwlrgwhMIF6D ecVlxtLi8BSnrt340e9PZ1MRc512k8ifiNEqbVYMmgjXj+C8LPAlvJU56gJrfQ81T7+IdFIwGw5K fnnGsW8TIrOdy3uTchse89xM2E2fvinF0TUX7LdVYVAfvvOsxqf78KQQP81XNImt7geRNfIb8vWm /q3XfDPPbzbYH/5OFlAe6o/Yc9rqMhk2yi7mWk4Nh7EozHbl5atPgnii623tcxVoADSHEWzT5x5d /byCGU02+nqFKz0evE9nfwN7ppDkq0/n7B2hwMGYwA2n/I5buQINBF4X+1EBEACz6Oh0tYGQz7AF 24qiBoKUEm0xHVvvS22ooe6X7q8UtO92nCMPg5KeOJ9s7CjvpVRt8gpLXd+nP9apV8Fy0H+UO683 P9Gx/EEY5CuqDMaTywEZr/x8W1Cwofzakrae3iuuyDR0iBo9SBk9rSp9AXeQOtwai2BLZNCuYz+d l1FAeL9s4aN+f8Rrb/W4KNsKggTb0LNd5Ls29Ib6GSBHJYBM1ayvmSaNYj/q7rqjF7C53frmjX3U 6CI5jglH7tPyMkaL8faIyDuQiPdO0fJREQKdgjs/OOAX10hibljv+Xs3ECLUJKKXoFUJi1o2Pv+1 oGQZuH48NzkC5I1tlk88JuW6TKOP4Y85dixQRx50dmoV2v2qQlJJZlyOfC7LN6HEVJMyzH1OMGXm +vIUDp5H60B1LzCoyhGwNfXqjdkIUG0H7jzJDgh0kSRcn0g+U3a/hB6bEz/M4LN7ht7IWJHsf3/e MHZqnqiOEReGb1UF3s/6b97X6liW01zzcHI76oH+fsIPTzDUXP5d5SWgVf3WImHlkkbopiU0vw+3 RiBA0KjNvsDTMOVLwMJrPKrn2VG3PdKOuQQ6Y+clBrQX/ot8PObvvfBOW1vFtaNS504NtwUQw+pm kMsQO29i0ItWDQ3SQqWVVgfIhjlcmMKREa4a+w2PqZv1Rvwxpj3tt862J40xDQARAQABiQRyBBgB CgAmFiEElAMQO1VukP5KJ27mkfFRJ0iD4cYFAl4X+1ECGwIFCQWjmoACQAkQkfFRJ0iD4cbBdCAE GQEKAB0WIQS8W94JadeWCAifMLdxDR5Fc+WtqAUCXhf7UQAKCRBxDR5Fc+WtqLxvD/9uSg496UCk hkse8k/m0HgQk5rHu+AKn3G6GR8hGvcDdA/iWklj20UHRkUFXz5A1aFygrNYSvU+lhUoqaJZ0gQX Gom6bdpkHF6FH+RoqgTzhG1TbsW58VLYoTnSO18mYVIdrJeUnQGN8vyawFLODeNyxkwpNZpM+Z5p FE5bfXdE4y+mamwo6ND9KsTwcPFmvAZLjCHcRhQ7k8OEq2pO5NTsuxql91EZ4WMtqpgarIra3QkJ grrh3KOT1xi5WFCzkwcIHEfHDauqUPOoAwoshZnJZJP6xwg8mMze34nyzfsdYXZlyGkw81aWoOdq Jg9W34mvnXf1vJaQ6iJYFyeei3zT1hgWTanCt9rWJixT0Sd+QhXDOeHvRFNeF5XOfiwxrj1X2Hwc YNpQBYFgtbmRoEjXWafUe2x9SSMKb42Rj6W13eftUFgdshje4IIrL8rSTgjunFxRMiFHyo4frv8F 0GSo7mQmgERtQkxZPJdZakOLL/RitnC3TIFjIuEEaRQ+ia4dsT8Vr3wur1Yw+ZiDgmroRO1Xq6V3 znY0diefYTUPldygGG8bN099BNbEhj/WkoZoLETYCuU4OEe+SrSpPwyqT1Kb5ie/4Slk4zvPqubv LaE0zxPa3sshRGTK6lWkxsb6uGIRe8d6kXNjZG+AJQ2FBdcHE2SurFZ/NhbCg1XHDMUkEACbiI4Q QnvdUfEioJCp5OkeETyD8pyb609rIdej5b//oDWUMV5eLJvrabQQt+nwvcV5QT6WxK0NlecHDyD1 wb2V92C2qi2LZoxnzpOW5DMNcASuoHi1pdPvwDGSS37MdnKZqSYu0VnF94BDNO0arhJv9Hc3JpE+ wxiRdHtewep8xj3tDPrfYjcbyewhtUzgPBl/Y6EvTwB/s7WBKX+LQJNwOUYKtKC5J9ccxpcTFXJF L8Vf2PzmuBVRgZ+ZFZwD87Dnk4Y/tUkr6Eb3KlZPmFczDvVw+1X/4GumNPTpHB/fgnrOhSkZSYin VYI1yttAXClfcyUd3bo+omyJjtYHyKae1TJ9RA9Ea6R0VbTW/YRw605/w7OHJ1jsKD0flf6KcAR3 bIBwJcM6PhM+EvQSbvkZurjDxXUimGYVQGgQgy2NDY+a8IRW5Juwtuqsx0o943fWBrcM0rcJGpx6 uzkFO1hUEeNHqDmTh0aADJ3pL/d/gjthx7s0wYGsULTk2wGbQie5b6VA5yUzDrzRWB8z10EXNsFH AQnuGViu0roenv+N45DgGhpAcpKuCpTre36qym3RALrX9brpBdcGKPeJVp1TE6exQxa5FroKJike G73aG8h/D2m+N4a6UlD+M3pVw049VpcAY0Tfthyt5hW56OYJTNYHHjD4ZiMigHHy/ydgXA== X-Rspamd-Queue-Id: 4MPJBl5mWQz3lZf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=antonovs.family header.s=20200215 header.b=jYppvhHp; dmarc=pass (policy=none) header.from=antonovs.family; spf=pass (mx1.freebsd.org: domain of ihor@antonovs.family designates 100.25.240.195 as permitted sender) smtp.mailfrom=ihor@antonovs.family X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[antonovs.family,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[antonovs.family:s=20200215]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[antonovs.family:+]; ASN(0.00)[asn:14618, ipnet:100.24.0.0/13, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On September 8, 2022 12:15:06 AM UTC, void wrote: >Hi, I hope this is the appropriate list for this query=2E I think I'm rig= ht thinking that poudriere would be used by lots of devs? > >I'm seeing the following output when poudriere starts > >ptsort: cycle involving doxygen-1=2E9=2E5,2 and py39-breathe-4=2E34=2E0 >ptsort: cycle involving libgd-2=2E3=2E3_1,1 and graphviz-2=2E50=2E0_9 >ptsort: cycle involving texlive-base-20210325_7 and texlive-texmf-2021032= 5 >ptsort: cycle involving texlive-base-20210325_7 and doxygen-1=2E9=2E5,2 >[00:06:30] Balancing pool > >It then carries on building=2E > >Is it a port problem, poudriere problem or a problem with the ports tree? >Need I worry? > >TIA, This looks like a problem with ports=2E It tells you about cyclic dependen= cies between packages=2E It doesnt know whic package to build because of th= e dependecy cycle=2E Ihor From nobody Fri Sep 9 16:15:15 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPLgb4v3pz4blb6 for ; Fri, 9 Sep 2022 16:15:23 +0000 (UTC) (envelope-from mwlucas@mail.mwl.io) Received: from mail.mwl.io (mail.mwl.io [155.138.237.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPLgZ6n2fz3yg6 for ; Fri, 9 Sep 2022 16:15:22 +0000 (UTC) (envelope-from mwlucas@mail.mwl.io) Received: from mail.mwl.io (localhost [127.0.0.1]) by mail.mwl.io (8.16.1/8.16.1) with ESMTP id 289GFFnu072503 for ; Fri, 9 Sep 2022 12:15:16 -0400 (EDT) (envelope-from mwlucas@mail.mwl.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=michaelwlucas.com; s=mwl; t=1662740116; bh=D08jEhFN6FFIHAzP98JLNggcVWMUizi3Vnov7DsIkzY=; h=Date:From:To:Subject; b=TwJH9jKeUTT1P6rV3yjkXs1ZmVZGMMtKo2SweXPnkU9Uu56o5T71EC6HuRvsx3BoT 6c/rdwBlf1OGhkpGLaPrPsRXJks57dNgaynGBqvUiHzbzwOqMRajVYW9wUtO1ZSCI6 PUbTOidgddIicvQaLe3P4zkbGGEMbOQ7XNQ6BS7qSing/QYHRO5Z2kkpl6WBxYlIq6 mBQHhQRP3u6LyPvulnKlmjYQb3HeE7LtXhKTr+zm5oWnCcsiNNOx1xL+CNQoG8oJ1j +FvDZMzWDUb8TBAgQopAkqfDgtNOTX9/GtGoWaStWOhL3IqtaYh7v8szWrIFQP9u1t el2A56yjPtfSA== Received: (from mwlucas@localhost) by mail.mwl.io (8.16.1/8.16.1/Submit) id 289GFFN8072183 for hackers@freebsd.org; Fri, 9 Sep 2022 12:15:15 -0400 (EDT) (envelope-from mwlucas) Date: Fri, 9 Sep 2022 12:15:15 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: openbsd disklabels incompatible? Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (mail.mwl.io [0.0.0.0]); Fri, 09 Sep 2022 12:15:16 -0400 (EDT) X-Rspamd-Queue-Id: 4MPLgZ6n2fz3yg6 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=michaelwlucas.com header.s=mwl header.b=TwJH9jKe; dmarc=none; spf=none (mx1.freebsd.org: domain of mwlucas@mail.mwl.io has no SPF policy when checking 155.138.237.75) smtp.mailfrom=mwlucas@mail.mwl.io X-Spamd-Result: default: False [-2.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[mwlucas@michaelwlucas.com,mwlucas@mail.mwl.io]; R_DKIM_ALLOW(-0.20)[michaelwlucas.com:s=mwl]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DKIM_TRACE(0.00)[michaelwlucas.com:+]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[michaelwlucas.com]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[mwlucas]; ARC_NA(0.00)[]; ASN(0.00)[asn:20473, ipnet:155.138.224.0/20, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mwlucas@michaelwlucas.com,mwlucas@mail.mwl.io] X-ThisMailContainsUnwantedMimeParts: N Hi, I don't know if anyone cares, if this is a bug, or what. Using ctl as an iscsi target for an OpenBSD initiator, and GEOM tells me: GEOM: zvol/zroot/iscsi1p1: invalid disklabel GEOM: gpt/OpenBSD%20Area: invalid disklabel. Is this expected? It doesn't seem to matter for iscsi, but it might bite someone? Have our labels forked? ==ml -- Michael W. Lucas https://mwl.io/ author of: Absolute OpenBSD, SSH Mastery, git commit murder, Absolute FreeBSD, Immortal Clay, Prohibition Orcs, etc, etc, etc... ### New books: TLS Mastery, the Networknomicon, $ git sync murder ### From nobody Fri Sep 9 17:33:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPNQB20g3z4bw7C for ; Fri, 9 Sep 2022 17:33:54 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPNQ93Pvnz3FBK for ; Fri, 9 Sep 2022 17:33:53 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D088A32000F9; Fri, 9 Sep 2022 13:33:51 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Fri, 09 Sep 2022 13:33:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1662744831; x= 1662831231; bh=19J9uE79Wc+f2GVYrgALcNFhgQea8wA71vtdioRAtgM=; b=z J40viJ/pBKhZt5SioYOLhZcSz8pOdo3uHJUTLIR+d8SeK3p6y5+4Ar6pMaq1BA0G U5/n9ha7qu0VaHTxlJA3D82UCv5iQm40PnLq6JrbbtmQeiGweteCL0BSFVhvsshk mLqa72AR9/27paVQYQ2AGgsZFz7JIjIJg4NAS6pK1igEe/LBFVnjKYJeBZDTB3gr dEf6oNIxqdbjUDETdZn/W7V+n4JlFbDnZT6FDyWxUPcKbNV+YEG0msiP1Oh0L61C uKQ4qzwQeC+c6M8dBDHSA6FTL/HjrdjKdIc47SGKm39silYTjz8sjIMbo9bPNY95 AVXZ36aNAf+KOV/7dlE/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1662744831; x=1662831231; bh=1 9J9uE79Wc+f2GVYrgALcNFhgQea8wA71vtdioRAtgM=; b=tLT9VK9LRCPo+pJFe IJOVufgSEtO1vY3M1Z13jvvkaZ67M9Per7X3e3Ra8dEMJTaufR/bRZOEkBdwoCik +VQKEvtX1UMoYaxCw65XH/7bRZ1LHY4as/m8gYrnaIBQpeZPQjVoe/rivH31OBwB TAPqb9PUql+MBX8HLE38HhC5de/mLBFz9+rPYWhD7bSQg2AdD13vWbkHr5Oe0wbO UaQvN4NQlMsQeeB44/flDD8nrBWJZNAvZNDkkDC42BgACfUOzMvi6nKbogcdN8Wb lbC9Ns0Qj3VavHC6gBCom6t0r5lXyg3ntx0bkNEViliX/7WRtC+uaT7PiBGEQDU0 d9yrQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedthedguddujecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdff rghvvgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrth eqnecuggftrfgrthhtvghrnheptdfhtefhjeekieehvdfhieeiieeltdehheeuteeilefh ffelhefhhfeffeetjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E7DA36A0073; Fri, 9 Sep 2022 13:33:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-927-gf4c98c8499-fm-20220826.002-gf4c98c84 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <279f9299-864f-4197-a523-c632e7ede3fb@www.fastmail.com> In-Reply-To: References: Date: Fri, 09 Sep 2022 19:33:30 +0200 From: "Dave Cottlehuber" To: "FreeBSD Hackers" , "Michael W. Lucas" Subject: Re: openbsd disklabels incompatible? Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MPNQ93Pvnz3FBK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm3 header.b="z J40viJ"; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=tLT9VK9L; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 64.147.123.21 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-2.59 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; MID_RHS_WWW(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm3,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; DMARC_NA(0.00)[skunkwerks.at]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEFALL_USER(0.00)[dch]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 9 Sep 2022, at 18:15, Michael W. Lucas wrote: > GEOM: zvol/zroot/iscsi1p1: invalid disklabel > GEOM: gpt/OpenBSD%20Area: invalid disklabel. My dual boot laptop shows this too so I wouldn=E2=80=99t worry unduly.=20 I guess the bits have rotted a little over the years. A+ Dave From nobody Fri Sep 9 19:55:21 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPRYc40hGz4cBq5 for ; Fri, 9 Sep 2022 19:55:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPRYb3dTbz3P7s for ; Fri, 9 Sep 2022 19:55:31 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 289JtMHQ037686 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 9 Sep 2022 21:55:23 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1662753323; bh=hs/DQ74qz+Wlb0QnccMTt8lcq+6y4VJBWydrFKYes20=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oSqK8Zy/ivCel/eWCMW52tel3UOwS3S0mWa73jsv3an3Lun3JSSTEau/9ECNLfKy1 to48C9K6Vv0g9zWIAWVH/9YBfLh81m2XI8MRzXCV1RvqG1SXKQ43dx+uqsljSsUKPO V/jn9Hs79j+6lo5SIc48jWDvYOEoTag6MwGehjIE= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 289JtMcs001268; Fri, 9 Sep 2022 21:55:22 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 289JtL8x001265; Fri, 9 Sep 2022 21:55:21 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 9 Sep 2022 21:55:21 +0200 (CEST) From: Wojciech Puchar To: "Michael W. Lucas" cc: hackers@freebsd.org Subject: Re: openbsd disklabels incompatible? In-Reply-To: Message-ID: <9f3c8ab-a028-a67c-ea11-e8c64cf9fe72@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MPRYb3dTbz3P7s X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b="oSqK8Zy/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; HAS_XAW(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[puchar.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > GEOM: zvol/zroot/iscsi1p1: invalid disklabel > GEOM: gpt/OpenBSD%20Area: invalid disklabel. > > Is this expected? It doesn't seem to matter for iscsi, but it might > bite someone? Just ignore - except you will like to mount it's filesystem from FreeBSD than you will not be able easily. If at all - i don't know if OpenBSD UFS is compatible with FreeBSD > Have our labels forked? No idea. Tried openbsd once and that's all. From nobody Fri Sep 9 20:02:11 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPRjX6y8mz4cCd5 for ; Fri, 9 Sep 2022 20:02:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPRjX0sYzz3QXk for ; Fri, 9 Sep 2022 20:02:24 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt1-f181.google.com with SMTP id x7so1961268qtv.9 for ; Fri, 09 Sep 2022 13:02:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=1E4H3gaXOZpIBI2qnTModsuov8e3+zwmrB/vJD8eMfA=; b=2IxTCH9PdjaiFntdMBCiJxrhsQZhxEUGtmZT6fjWkmqalaqtfKHuhW1UlGsFrP82kZ zIXnn5hCpjkBmHNdR70EBH/7cfkjjOrV/gNmODx/EJiKEibPZI7V+7i9J3bXyYTOSQ6p c5Cexklt984J5c2YRUtrGn4dnx5TcbFlo6S/XO/s4Xjum91WVnw7fNOQVHzUBkmmPLn7 MHI6/ACtP7t96IJfMC1ICz561U2sa08gzuMU7OQ/tWMp4MwUhZ0BE37pB9gxN3jBNJsz KYWucH0AmRaJzXKT25sIfapsFGnZfkl7UdBy0xLZ90A5P0N2XC7k2UdHw0XKpxIfHcv8 2Buw== X-Gm-Message-State: ACgBeo0BryqWjFYAt5XIlRZVXo2kLSdwBeUzA7L1Fs2+kqYKUFuGf0aj 6Ojayjv8oSQ3pfq/PIdjUIdoTORgwshiOzeA+ZxJt+Hn+/U= X-Google-Smtp-Source: AA6agR4+RA8BTrvHeMQd9dmwJVqzVxvJpvaOpCPR534lkPHA/9xpF5koSdm7Tz0h2sg4ixjwEleQHHCYewJfzLcHz6s= X-Received: by 2002:a05:622a:2593:b0:35b:a66e:ac5e with SMTP id cj19-20020a05622a259300b0035ba66eac5emr824485qtb.659.1662753743227; Fri, 09 Sep 2022 13:02:23 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Fri, 9 Sep 2022 14:02:11 -0600 Message-ID: Subject: Re: openbsd disklabels incompatible? To: "Michael W. Lucas" Cc: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MPRjX0sYzz3QXk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.10 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.160.181:from]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.181:from]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Fri, Sep 9, 2022 at 10:15 AM Michael W. Lucas wrote: > > Hi, > > I don't know if anyone cares, if this is a bug, or what. > > Using ctl as an iscsi target for an OpenBSD initiator, and GEOM tells > me: > > GEOM: zvol/zroot/iscsi1p1: invalid disklabel > GEOM: gpt/OpenBSD%20Area: invalid disklabel. > > Is this expected? It doesn't seem to matter for iscsi, but it might > bite someone? Have our labels forked? This isn't a problem for iSCSI. It just means that GEOM is tasting the partition, and can't find anything that it can mount. But you don't need to mount it in order to export it via ctld. Also, pro tip: if you do zfs set volmode=dev zroot/iscsi1 Then geom won't even see the device. That will prevent these warning messages, and is slightly faster. I'm assuming that your zvol is named "zroot/iscsi1", and you've partitioned it, but are serving the entire volume via ctld. -Alan From nobody Fri Sep 9 20:19:19 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPS5G3Tgxz4cFNh for ; Fri, 9 Sep 2022 20:19:30 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPS5F27CSz3S5M for ; Fri, 9 Sep 2022 20:19:29 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4MPS560hnfz6gtH; Fri, 9 Sep 2022 22:19:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1662754760; x= 1664569161; bh=6oxIDKs9tmcJuwaEmAqzrWskHWtIo5NBZXhQrJs/cWs=; b=O lLWiU0puokkiH18FhB+X53CixJJoPV0eA5iuBSG8WEM2+jIMAoi3DFpoqN64ToWi RWWidFrdEZH8cuULZ1P9zYPJtnIfGbdMMI8NdkbX+Rk9cO1EvxKwAd4GoE04h0Q8 us3dqqFOdUCst46UanD2cz47nEk13YV5eQRiF7KcR1hQPCqNblzVpDjRNgcWwk3X nb1bbEdEdU0AXSXrsH4LeaNNZel4fycPNPQx4RK7HFrDwKNY4QYtFOXHzPsy9b0w hCcEZir09jyIrQZgwCqh3iyIJcOfiF/GLP1Z7r6jtG/nUCKp9vKt5P+hE/cn1jlG RAx85ZRreYSawQcoqJEGw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id hi_neE5C8EHn; Fri, 9 Sep 2022 22:19:20 +0200 (CEST) Message-ID: Date: Fri, 9 Sep 2022 22:19:19 +0200 Subject: Re: openbsd disklabels incompatible? Content-Language: en-US To: Wojciech Puchar , "Michael W. Lucas" Cc: hackers@freebsd.org References: <9f3c8ab-a028-a67c-ea11-e8c64cf9fe72@puchar.net> From: Guido Falsi In-Reply-To: <9f3c8ab-a028-a67c-ea11-e8c64cf9fe72@puchar.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MPS5F27CSz3S5M X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="O lLWiU0"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.00 / 15.00]; MISSING_MIME_VERSION(2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[madpilot.net:+]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 09/09/22 21:55, Wojciech Puchar wrote: >> GEOM: zvol/zroot/iscsi1p1: invalid disklabel >> GEOM: gpt/OpenBSD%20Area: invalid disklabel. >> >> Is this expected? It doesn't seem to matter for iscsi, but it might >> bite someone? > Just ignore - except you will like to mount it's filesystem from FreeBSD > than you will not be able easily. If at all - i don't know if OpenBSD > UFS is compatible with FreeBSD Reminds me of a friend who, in 90s, on a Sun sparcstation 5, installed NetBSD (1.2.something I think) and mounted Solaris UFS on NetBSD...The booted Solaris and found all the permissions messed up badly, with the system refusing to boot multiuser. At the time he said something about UFS on Solaris being derived from BSD UFS and fundamentally the same thing, so they should be compatible. Guess he was wrong. The morale is: if in doubt don't cross mount, nothing will warn you of possible breakage. -- Guido Falsi From nobody Sat Sep 10 01:00:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPZKP60JKz4bqSt for ; Sat, 10 Sep 2022 01:00:25 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPZKP0B9gz3lPN for ; Sat, 10 Sep 2022 01:00:25 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C68F13200564 for ; Fri, 9 Sep 2022 21:00:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 09 Sep 2022 21:00:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1662771621; x=1662858021; bh=2RKM1sUojT qxgmYEmtYcixyFoUcF5Rc/EwVAXXFR7OA=; b=hfdszgW3sfJzrR4nfS4D5esnr3 Z0sddufY9xKqpQM+H7iVDg9zZwXZORRRGoJPRNEAiw3Ntxfl8ZtartsNIYGNe/n9 yd0yadnv0WuXaoKgeiAxplpvS5V0dKxz/4VPInRAl2tX1POZPHieDYa0878L2bPh oSGI6Pfd0N9F8bZ5RefzEBYn4t+yMLxyL1vbsiZw9JRPOZwXe5IF77utaBA1kzV8 9vr3+JxvpWQKDOdcYi7Rly1Rb3WLBOSE1nNdx24rO/ccUCeyS1eXU4QIgq4w9dB6 R1NhE2PjMdehrBJCChcvKei7MxIs5PLECoKy6yVwcwuKr2/vdvGbSYtu9VOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1662771621; x=1662858021; bh=2RKM1sUojTqxgmYEmtYcixyFoUcF 5Rc/EwVAXXFR7OA=; b=YfugD4EL52VJha5j4MXN1+hP4vEMCLM5LwBVgXjplmWU 9yS1dgcoddhBfgs+3u72XA9Hh7E8xtMbKAfwuPO8IHkXmuGL8+0nMxpojTjejgXP oHWq3Ytwwjot2o0DIZBAxPe78Tev0X20cF12Yr0WfsUvRSdDOeKq5fyg7bXJ4/Jp AB9HkB1A95pNOD5HaF8oiYMuSoiQcTe7stmXORV24KR7QBMoQSw9f3lPdV67pIjf IM2MsCMwFiMRyz3GhH7FaSSoUieimOBgjIx1KAtX9bf86iq5xD7BhF278ikOmfoN 5AqRuSs3DEfwvKOejzsEDwHNRaTMw8qOChLE+9IgKQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedtiedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtro dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepieevgfefgeffhffggfeitdejjefhteeffefgleefieevleevjeeuieduge elgffgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 9 Sep 2022 21:00:20 -0400 (EDT) Date: Sat, 10 Sep 2022 02:00:18 +0100 From: void To: freebsd-hackers@freebsd.org Subject: Re: poudriere odd error Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <038EC8C3-DB5E-43BD-9F4E-2E31C3120BC9@antonovs.family> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <038EC8C3-DB5E-43BD-9F4E-2E31C3120BC9@antonovs.family> X-Rspamd-Queue-Id: 4MPZKP0B9gz3lPN X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=hfdszgW3; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=YfugD4EL; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.24 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-5.04 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.945]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from] X-ThisMailContainsUnwantedMimeParts: N On Fri, Sep 09, 2022 at 02:23:31PM +0000, Ihor Antonov wrote: > This looks like a problem with ports. It tells you about cyclic dependencies > between packages. It doesnt know whic package to build because of the > dependecy cycle. Thanks, I'll raise a PR with ports -- From nobody Sat Sep 10 08:25:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPmCc5fFlz4bSBl for ; Sat, 10 Sep 2022 08:26:04 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPmCb5cKHz3NZX for ; Sat, 10 Sep 2022 08:26:03 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4MPmCZ44RVz6fh9 for ; Sat, 10 Sep 2022 10:26:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1662798359; x= 1664612760; bh=rcd5/Q1AX5xgcMEkJJcBC3IkYWs4zoaFJN4Yzmna2+w=; b=l kV+0q68rfXk7Lz4ZhCXiFgrX6KmMy9xqB8aqQOOjJQiUiL76ojBuTpY+RfON1XNn rQOmVnhLw+gS1wQvkHq+hZB63x4Brrolt5K3xqKFEYghFHg/dSUczg9X4XtiGPyl NVIeOx7jtYp1wXQDuCrCK5Us3VcXHv3d/Lrpce9VQ5FXz3c5VV2JqmgZewz/0LWp 7L4gbwE7gI39WevgZTEfH4iPPpVrKrPnzqSuRMfM7GtxrTVy6gUgfP/S7pgi+qGj A/kmemS7LsqzJ9JZ6CV/mVb4aPDpxgOzDEjXRT4FblJj9uuvbEo1k7FSCnMTcXO6 awTobU+fynALWUPPJvoVA== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id rbUukbfMI_BY for ; Sat, 10 Sep 2022 10:25:59 +0200 (CEST) Message-ID: <0dd051be-d6ce-11ca-a444-137f129f362f@madpilot.net> Date: Sat, 10 Sep 2022 10:25:59 +0200 Subject: Re: poudriere odd error Content-Language: en-US To: freebsd-hackers@freebsd.org References: <038EC8C3-DB5E-43BD-9F4E-2E31C3120BC9@antonovs.family> From: Guido Falsi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MPmCb5cKHz3NZX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="l kV+0q6"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.72 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.72)[-0.715]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[madpilot.net:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 10/09/22 03:00, void wrote: > On Fri, Sep 09, 2022 at 02:23:31PM +0000, Ihor Antonov wrote: >> This looks like a problem with ports. It tells you about cyclic >> dependencies >> between packages. It doesnt know whic package to build because of the >> dependecy cycle. > > Thanks, I'll raise a PR with ports Could be due to custom options. Maybe the ports with default options are ok, but some custom option you set triggers the circular dependency. This needs to be fixed in the ports tree anyway and is not your fault, but in such a case it would be helpful if you could state any custom options you have, and try to isolate the one causing the issue. -- Guido Falsi From nobody Sat Sep 10 08:52:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MPmnf09C2z4bVfH; Sat, 10 Sep 2022 08:52:06 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MPmnd2yskz3RBM; Sat, 10 Sep 2022 08:52:05 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4MPmnc297Fz6fh9; Sat, 10 Sep 2022 10:52:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:subject :subject:from:from:content-language:date:date:message-id :received; s=bjowvop61wgh; t=1662799922; x=1664614323; bh=Ru6b0d siLFPp9Ugh9NWblJAub9gFrwagtR20i4OK6Wk=; b=A5r6Or5NHvZwSy7JeTY1+P EWR2ruwgv893DMXnG+5EaN5JhneedYROfTHYZ94jnQnMgsCdHjiMBzcM0260FXdh USY6vYptAGRR5iF5kF6NTgTDwHJ/ys67VWhrTxtVrHd9XCmK2j4KYJWSnb2Dz187 OIdyvwNLTetDzh3RGk5drDHF5CyP4nEhaT7IKh61nTLhvQVsW7R8GLGqdELjQE/B I3VltP2Q4MPRUucOvUQTa6KdQ7FiSoLIeENfoNfP6Ql5HFnj7pgAiE0BHiBm2Cb9 X36+XK4d2iDYNGlu+vRT6ZJe0bJjZ+8zy6/kVTfQwNmUurOcfZuXZcg10cpSDEIg == Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id za6VcjTotUbD; Sat, 10 Sep 2022 10:52:02 +0200 (CEST) Message-ID: Date: Sat, 10 Sep 2022 10:52:01 +0200 To: freebsd-hackers@freebsd.org, virtualization@FreeBSD.org Content-Language: en-US From: Guido Falsi Subject: Dynamic hostname in rc.conf (for bhyve VMs) Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MPmnd2yskz3RBM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b=A5r6Or5N; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.46 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_LONG(-0.46)[-0.463]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,virtualization@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[madpilot.net:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Hi, Since rc.conf is just a shell script I'd like to be able to set hostname dynamically. This is bhyve related because what I'd like to do is pass an hostname to VMs via the -e option to bhyveload(8), and then read it in rc.conf, maybe via sysctl to set the hostname accordingly. By the way I'm using vm-bhyve [1] to manage my VMs. its configuration files are also shell scripts, so I was planning to hack some simple logic there, host side, to derive the hostname from filesystem (useful for cloned VMs). Could not find any example or documentation about any step of this. Is this even possible with current tools? I'm open to hacky solutions to start with, then maybe refine them. I'm trying to do this because I'm using a local dnsmasq that exposes DNS with the hostnames provided by VMs, but clones get the same naem as the machien they're cloned from and mask those in this small internal DNS. If each clone could provide it's different name it would be much better. Thanks in advance for any help/suggestions. [1] https://github.com/churchers/vm-bhyve -- Guido Falsi From nobody Sat Sep 10 17:22:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQ07N22Z5z4bX2B for ; Sat, 10 Sep 2022 17:23:12 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQ07L4THJz3VhX for ; Sat, 10 Sep 2022 17:23:09 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 28AHMx4U083797; Sun, 11 Sep 2022 02:23:00 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 11 Sep 2022 02:22:59 +0900 From: Tomoaki AOKI To: Guido Falsi Cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic hostname in rc.conf (for bhyve VMs) Message-Id: <20220911022259.a51af1f585f24af6bfb6d4e4@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MQ07L4THJz3VhX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.59 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 10 Sep 2022 10:52:01 +0200 Guido Falsi wrote: > Hi, > > Since rc.conf is just a shell script I'd like to be able to set hostname > dynamically. > > This is bhyve related because what I'd like to do is pass an hostname to > VMs via the -e option to bhyveload(8), and then read it in rc.conf, > maybe via sysctl to set the hostname accordingly. > > By the way I'm using vm-bhyve [1] to manage my VMs. its configuration > files are also shell scripts, so I was planning to hack some simple > logic there, host side, to derive the hostname from filesystem (useful > for cloned VMs). > > Could not find any example or documentation about any step of this. > > Is this even possible with current tools? I'm open to hacky solutions to > start with, then maybe refine them. > > > I'm trying to do this because I'm using a local dnsmasq that exposes DNS > with the hostnames provided by VMs, but clones get the same naem as the > machien they're cloned from and mask those in this small internal DNS. > If each clone could provide it's different name it would be much better. > > > Thanks in advance for any help/suggestions. > > > [1] https://github.com/churchers/vm-bhyve > > -- > Guido Falsi > IIUC, and if you obtain IP addresses of each VMs via DHCP, just keeping hostname on rc.conf would be suffice. /etc/rc.d/hostname has a functionality to get hostname by hostname=`/bin/kenv dhcp.host-name`, meaning hostname is set using what DHCP server supplied, if NOT in a jail. See the script for details. -- Tomoaki AOKI From nobody Sat Sep 10 21:12:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQ5Cr4XF1z4c216 for ; Sat, 10 Sep 2022 21:12:24 +0000 (UTC) (envelope-from mason@blisses.org) Received: from yangtze.blisses.org (yangtze.blisses.org [144.202.50.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQ5Cq3Z1Wz3wbq for ; Sat, 10 Sep 2022 21:12:23 +0000 (UTC) (envelope-from mason@blisses.org) Received: from contoocook.blisses.org (contoocook.blisses.org [68.238.57.52]) by yangtze.blisses.org (Postfix) with ESMTP id F3DB017DC99 for ; Sat, 10 Sep 2022 17:12:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=blisses.org; s=default; t=1662844335; bh=Fur8a/U7zB6oFhC6eZxGtUm8g25oAyshJl95Y9UvMw8=; h=Date:From:To:Subject:From; b=wYx27Mgwt1YQhFNibmSxU6b0vV191CSj5btxgDppnkzTP8QJd8hzDPbR7gClHgI2c ClMjyuWRIKQOvSP5AgKSgWItVbAMAAdDAIJ/mPm8nZXmzYTe7JeRshq0EolW4CfUv1 4x2K7qyjwzBei3hvo+XM+D9MbbtoNJ2bsXRwQ6ZUWoWFdF7is1iSyBabhjccsuzV30 6oMxflOgK3CXwC34/fkGI+KPPRXgmDFAPrrLPfwemsrE1vubBjWw6dJJ4nbfPxp27z 2o3GxwXF0U20T3WEvfQx84PYG/VTXfSurBAxoqJ8xv6XSjdi4By5SECdrQe1k4RYrF dc8uWLql74lDw== Date: Sat, 10 Sep 2022 17:12:14 -0400 From: Mason Loring Bliss To: freebsd-hackers@freebsd.org Subject: Simple bugs with image impact for the project... Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XbbRxMAqTDL4nN5a" Content-Disposition: inline X-Rspamd-Queue-Id: 4MQ5Cq3Z1Wz3wbq X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blisses.org header.s=default header.b=wYx27Mgw; dmarc=pass (policy=quarantine) header.from=blisses.org; spf=pass (mx1.freebsd.org: domain of mason@blisses.org designates 144.202.50.44 as permitted sender) smtp.mailfrom=mason@blisses.org X-Spamd-Result: default: False [-6.10 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[blisses.org,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[blisses.org:s=default]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:20473, ipnet:144.202.48.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[blisses.org:+]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --XbbRxMAqTDL4nN5a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd noted FreeBSD 13.0's end of life on IRC a couple times, and then opened a bug to have it removed from the freebsd.org front page. Between my live mentions and opening a bug, Graham Perrin opened his own, and found more things to correct, so his is the right one to drive forward. But here we are, September 10th, heading towards two weeks of 13.0 no longer having formal support, and the main page still notes 13.0 as being supported. This feels like something that ought to be so trivially easy to correct as to not warrant mention, but instead it seems to be dragging on, and it seems like a problem that the project can't post correct and up to date information about itself on the web site, despite at least a couple people interested in seeing it updated, one of whom (Graham) has a commit bit, as I understand it. What's missing? Please take this as a desire to understand the current state and to see process improvement, not as a complaint about volunteers not doing work on a schedule. (That said, I'd volunteer if that'd make it happen. I updated the Torrents wiki page, moving 13.0 out of current releases, because I could, but I (appropriately, since I'm not formally tied to the project) don't have access to update the main web site.) --=20 Mason Loring Bliss (( If I have not seen as far as others, it is because mason@blisses.org )) giants were standing on my shoulders. - Hal Abels= on --XbbRxMAqTDL4nN5a Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEEXtBZz1axB5rEDCEnrJXcHbvJVUFAmMc/awACgkQnrJXcHbv JVVojhAAs7Le3BGQ23eZ5qn6Bn2mm3HtS3hwpWcTzcyfUDQuEjYAGG/75eKIwxsD YYv1RUhgdN4yJF4S/GouE2x+/tFJoW2gHHsox9vqMkwuH4MI1YLQ2Dsn5dkie9pu LvB2Btyd//UJitGDLnjO+3vzMQ7ZbSKGBHw8GkHVdyWmMh77cYCtrSuLivExspG7 gXBxJROiCoNJU4b+p+WcJ+0M4m9i+cUwTMlgbJvFKbfP3T0QmK1mrpNP4x4MyiNv XzGfff+kJ7/Lgc8ZNKj2xp+VjZX2c/PnzRbYk6Qgi584Wn3LoRRocS4eqG0OKd1b gyMHM1wLAqieO232HVtuwjHahdKMJZIJ1QGUwUFMiDy4IYcYDIalcdt8ifUVxq3R V8S30v+d6ViWXQVEXlsMNLBMlbeOe3g6KYxDIog+dapfqFhXrA5i8x14kSrJzbgn woKXAh61RdLBweyPKa4myEpqHRyi9d/PO3OXX+zfNwAEYxrs1SE21PZTAJ0SSiD0 meXyJeNVwLX37pMnChU4SfQ5+a48Ws8EN206rSbzDMcWxg7TnA0FexHjykgTGZ3d 0bfcU/o3V1YeWcKEx89felTNcn8K/C4FNtM1MDXryjtJoiF/wDJ1V9OnxMlROk+I bxtswfA0x7Xi9NYtUiUjGUJfWK1OpVSsMop8k8SUWLwz8BBbmqo= =qtSJ -----END PGP SIGNATURE----- --XbbRxMAqTDL4nN5a-- From nobody Sat Sep 10 21:29:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQ5bK5nRYz4c3Pr for ; Sat, 10 Sep 2022 21:29:17 +0000 (UTC) (envelope-from carlavilla@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 4MQ5bK5HTTz3y6L for ; Sat, 10 Sep 2022 21:29:17 +0000 (UTC) (envelope-from carlavilla@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662845357; h=from:from:reply-to:subject:subject:date:date: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=D90vHhllu+7HrioyVRtK3N9xyKbKCA9DAkPMSltWI3k=; b=NamKFbxSz+WtKPIRRcCNW5jTCKUxaLk/LGWeA1QfEfrH+CHmj2ruTAJED8zk03oHHesEtO Fr9SxDE0usQmhIbmc8aweU93UkNs6XRTLg8uB/t8kagANdFl9u08wCXLO5YTQKvrTmeczb Oqp9rndL60V8Qbq2g7D8Oykhg0lhN5yVyI/FP+vg3espMfvO0Id5YdiBVHFQ+om16/bSp2 tOuehvNDQs9hqOyjgAcBKFr2tTZ7FuE8ut+xPz6L1psEt5iXpOfp1BRlfWf0Vtu1ynrzrj eWC+eq3zlZNKgq3Cu7tPiwKvwKM4EiHNhdD5PyQuKpCIJw1CTTeW62ZfSSN37g== Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: carlavilla) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MQ5bK4KMgz1Ld8 for ; Sat, 10 Sep 2022 21:29:17 +0000 (UTC) (envelope-from carlavilla@freebsd.org) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-127f5411b9cso13188907fac.4 for ; Sat, 10 Sep 2022 14:29:17 -0700 (PDT) X-Gm-Message-State: ACgBeo0y122zID44pRYw4c8+8TCBy6pK1QW5LG2AInIU8GZwpWt3HWcm U9wntHIpTXFhURPrs6Uut8LudyB+sucppYeiVrg= X-Google-Smtp-Source: AA6agR7ZpmJuWv43wGEX4Eq5APmXOmBjZlUsdZMyawAVrOdMTgiEGYebB7RS+vRJcalGppAcWgU3MnPJQG2q7HwsMUI= X-Received: by 2002:a05:6808:1408:b0:343:1ae:87cb with SMTP id w8-20020a056808140800b0034301ae87cbmr6406378oiv.201.1662845356759; Sat, 10 Sep 2022 14:29:16 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Sergio Carlavilla Date: Sat, 10 Sep 2022 23:29:04 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Simple bugs with image impact for the project... To: Mason Loring Bliss Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000ce5eb905e8595ac2" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662845357; h=from:from:reply-to:subject:subject:date:date: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=D90vHhllu+7HrioyVRtK3N9xyKbKCA9DAkPMSltWI3k=; b=EksVDDBT1pJcbXAWlKCx32Qw9XLTE/pgY0eFYWSUi4g8LFvKKn7uhxMciObY8GXTBn0mDR IxdNyJevGplS38uPKtdvESBVoLvTG+x9yVB1fhqLUpxMfnAqGtm9tyiz3AyY+n/BhEa4Gp n2f9wno5cJqkjMoFV77QYR2GxI768yCyFf22O9KSc/Szm8VONutLJhfKTJvmvHNe59zTgW Q9GKFNYkjEMyuZ+OxpYkQaV0HbkJ3pm1R6BKcq5Zc8XI6FCWjhgTpDEPX0pr0Mfe4Jbob8 f5mOATUXgPzMKF2jzUOmBCgXnLysXwL6PMgnbsCn4X4GLn4NvqK2Fanp6pQMLA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662845357; a=rsa-sha256; cv=none; b=fI+EvlXiSFOLa8y67b+9i9nJVttHv5bs96igkDtcxx03Ew4R+5o5apg6N+AYOzPt+RjKct Ktfl5+rib/qT52dfJvr+pI6j5ATsYOaZOwpx48aozSsBIkNz4vPCrMmn4QFJoO0Xjms9xk z8Hs2aT4hyNBr03sSRYSloerwA+K3J9wa2zJ/wyP9Y+ozAGivcsqHjpTfpw4AAjHSloJoy uZmk356AB7vtuR+isTKtYTRZwHrUFs53JjO2Znfu/ZnyDb8SsvwXx9mizYrBQGvMWk/u6t Sle9KueFrhll3KDIdjOoFdhGwqtb/9snA/PYQmwoqTqzZb9fzyOG1gXxC/uRCw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --000000000000ce5eb905e8595ac2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry for the top posting, I'm using my phone. It's true that this error can be fixed easily, but the idea is to teach other committers how to handle this. Graham will fix this so soon :) Sorry for the inconvenience. Btw, the documentation code is in our git at cgit.FreeBSD.org If you want to learn how to upgrade our website/documentation portal, please ping me. Bye! El s=C3=A1b., 10 sept. 2022 23:12, Mason Loring Bliss escribi=C3=B3: > I'd noted FreeBSD 13.0's end of life on IRC a couple times, and then open= ed > a bug to have it removed from the freebsd.org front page. Between my live > mentions and opening a bug, Graham Perrin opened his own, and found more > things to correct, so his is the right one to drive forward. But here we > are, September 10th, heading towards two weeks of 13.0 no longer having > formal support, and the main page still notes 13.0 as being supported. > > This feels like something that ought to be so trivially easy to correct a= s > to not warrant mention, but instead it seems to be dragging on, and it > seems like a problem that the project can't post correct and up to date > information about itself on the web site, despite at least a couple peopl= e > interested in seeing it updated, one of whom (Graham) has a commit bit, a= s > I understand it. > > What's missing? > > Please take this as a desire to understand the current state and to see > process improvement, not as a complaint about volunteers not doing work o= n > a schedule. (That said, I'd volunteer if that'd make it happen. I updated > the Torrents wiki page, moving 13.0 out of current releases, because I > could, but I (appropriately, since I'm not formally tied to the project) > don't have access to update the main web site.) > > -- > Mason Loring Bliss (( If I have not seen as far as others, it is becau= se > mason@blisses.org )) giants were standing on my shoulders. - Hal > Abelson > --000000000000ce5eb905e8595ac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Sorry fo= r the top posting, I'm using my phone.

It's true that this error can be fixed easily, but t= he idea is to teach other committers how to handle this. Graham will fix th= is so soon :)

Sorry for = the inconvenience.

Btw, = the documentation code is in our git at cgit.FreeBSD.org

If= you want to learn how to upgrade our website/documentation portal, please = ping me.

Bye!

El s= =C3=A1b., 10 sept. 2022 23:12, Mason Loring Bliss <mason@blisses.org> escribi=C3=B3:
I'd noted FreeBSD 13.0's end of life on IRC a= couple times, and then opened
a bug to have it removed from the freebsd.org front page. Between m= y live
mentions and opening a bug, Graham Perrin opened his own, and found more things to correct, so his is the right one to drive forward. But here we are, September 10th, heading towards two weeks of 13.0 no longer having
formal support, and the main page still notes 13.0 as being supported.

This feels like something that ought to be so trivially easy to correct as<= br> to not warrant mention, but instead it seems to be dragging on, and it
seems like a problem that the project can't post correct and up to date=
information about itself on the web site, despite at least a couple people<= br> interested in seeing it updated, one of whom (Graham) has a commit bit, as<= br> I understand it.

What's missing?

Please take this as a desire to understand the current state and to see
process improvement, not as a complaint about volunteers not doing work on<= br> a schedule. (That said, I'd volunteer if that'd make it happen. I u= pdated
the Torrents wiki page, moving 13.0 out of current releases, because I
could, but I (appropriately, since I'm not formally tied to the project= )
don't have access to update the main web site.)

--
Mason Loring Bliss=C2=A0 ((=C2=A0 =C2=A0If I have not seen as far as others= , it is because
=C2=A0mason@blisses.org=C2=A0 =C2=A0))=C2=A0 =C2=A0giants were standing = on my shoulders. - Hal Abelson
--000000000000ce5eb905e8595ac2-- From nobody Sun Sep 11 02:38:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQDSX4s0jz4bdrk for ; Sun, 11 Sep 2022 02:38:52 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQDSX4PHlz4Ms6 for ; Sun, 11 Sep 2022 02:38:52 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662863932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2dgO8aX3UA5gnmahyrR8w9AjDbGp967zUCzcnMRbq1Y=; b=pGP7ZYIB69qD+mod14aTPABHofboelj0wPGht1C9fDguGwvOImvBsVp+DDCsXqU4DsFK1s EW/ylLV/800lkMH3fjL/9KhQya966f8nVaYmRy/rDcN3oSZt9anyzDyywKafrNMDD9W32h dWTkyfekbHn2sCthDdruJd0rC2RyUgeWERBMbSLwuWRt5rb21TQRJMSB1cSwsV2og9uFIn kE3Y/qIF7Otf50yoSpVsPPY3Bj0WQwctv+Q2M3eQcAGekj6QMvewsaa4+N+grbAQWxytLv v8xjDTLnR+UGHqkdqOyGVGZDnRh8UlHkZvP1c9TNqjmpAMJAfbeFutpMeTNIAQ== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MQDSX22Hnz1MYq for ; Sun, 11 Sep 2022 02:38:52 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Sun, 11 Sep 2022 03:38:50 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: Simple bugs with image impact for the project... Content-Language: en-GB To: freebsd-hackers@freebsd.org References: From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662863932; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2dgO8aX3UA5gnmahyrR8w9AjDbGp967zUCzcnMRbq1Y=; b=UW1C+tUYoxFk96z+MLD75e6BOz11utRHs5Ng4Cs0aPfEjRfOk3gO1WWaEzfkCi4fpxAYsU LoJhPKCn6yXdEDtleP/0izxZSeev8LvxGq+wfk5RUYiJagUa6tTdwu08SqZBsfYF3touXa 9hxuLU9uctuEJzVufZ3W0aeFUqWYrnPFETNbC3nseFSVIZJ0Psi8wJjm/eTy4S4ybMqhUX jn2KedVMpzT5ff6q4gkL7yF7xoHU2hdgB+fHwrCbjmTL+0Sg4uNKVS1Sf3yvEriQs1O49A 4eRJ5jkPPeoDesHkOdF6yA1qx0eYIrhNbbqUBNtkk3uZ+DnEHdhRwbv8WVOeUQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662863932; a=rsa-sha256; cv=none; b=onf27GxJ9NktX8HeKbxDt6v/MoWoxxE/AsSrX7OOt427Pcrr0xbLWxP9NE1uCBxl4+KOjg iUXlqML0wYadmGw5GnxVxRjOUdY/gU54NPf0600WPFfYhonvO50yiOeOKzZFhnYlnlBnW0 D+BMZYPhQkejs8tHZbRW6dKclt+GnmvC8MLjkhm4t9n9f7l9jDy7pzU2z7nw6tjmGPe0MI h4tqZN2Bsl8X65ZWKjsqOys/9hjVWJUKv8x8ADKN8D4y+4IDeH4Jg9ADudHFAcncIP//HM EMmjsTLJrK9TvqukL01374C+guCgAFU/kgs6x28cTrFBpEOa+vWBGN6gOTDkhw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 10/09/2022 22:12, Mason Loring Bliss wrote: > ... heading towards two weeks of 13.0 no longer having formal support, and the main page still notes 13.0 as being supported. ... > > ... dragging on, ... yesterday for the home page, and more. this morning for . Enjoy :-) Not mentioned at , but for me, the general drag is command-line use of git. I'm far happier with GitHub-oriented workflow. The more specific drags prior to included my niece's wedding, out of town (the holiday that I mentioned at ) and illness. I chose to assign 266167 to myself because, amongst other things, my attention to release-oriented issues a few months ago caught the eye of gjb@ (one of my mentors); 266167 is a good fit for this, and for the learning process. I guess, some oversights are a consequence of site content being somewhat "all over the place". I imagine significant improvements parallel to, or reasonably soon after, the redesign of the site. HTH From nobody Sun Sep 11 15:31:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MQYby3VNBz4c4fg for ; Sun, 11 Sep 2022 15:31:26 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MQYbx2lGwz40hf for ; Sun, 11 Sep 2022 15:31:25 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 89B705C00D0 for ; Sun, 11 Sep 2022 11:31:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sun, 11 Sep 2022 11:31:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1662910284; x=1662996684; bh=m9f+PaMri3SIHbT2lRUv56SNyYaBKFdg47q feoFXa0M=; b=Luu1T2p2G3Pzb8vnm3R2cLldSr0FjqumubhJUZnZxob1SW/MS2h xpt6Bvwhm1B4rxC531iYWl595HeeuEWpm2RoqSG+3+jMBTTbEqOZDSDmswhqIIfm pKKph5zPmlZERcJgkboqMoCIi93Mn2BRZJqhiwcn9ZMTonlKKsp17torRJfKR/If vRsjINKzKTcStykhuzcvkw1RG8gDGMBxIT8mNUBiZyTx/ZtW/xS8/Trg+AlGdKzV bBXQgL0tRnxagmhJ6F7BnRlqE0/T4vGeYwGAdOEEmnCfdH+c0sCJnK1+4Y77P2Li OYC+uEKYiPeXZb9WwJW+fZxnTogZV1ln/Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1662910284; x= 1662996684; bh=m9f+PaMri3SIHbT2lRUv56SNyYaBKFdg47qfeoFXa0M=; b=Q P5LeZ/sDGNDJ91hrIZe00XCuSfWMEFjg99oDzdsrMBUekS7Yai2+JKUwkwBKDHKK RlckPt36eMyx3Qd3wdzlc8oXUlmpjhZzRBTQiHfY/J7zJim+4ly6/mT+PU7YGcAT 4Wd0oYF2z4niZpZIJF55RXZUK6/pLt6sPw5TfDWsLb10PCKT1kuO0kAmHApIg8ut 3FWNxetYWRa4DHFnPNUKw1mitu2hkYPNXrChCMV4fhhNAMCnmS1zZQUFxpqaQCKX Rea+qn5U7pLp6LpcwsP2A6XU1TSYM4ib7MkgCFa1xmfZrdRDUHKH9uZw+sibOBwC Lf0fSHc2ovU01JQUMr5rw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfedutddgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepfeetleevtdeujefguedufedukeegieetheeuieefkeekheeiuefgveeljefhie efnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgpdhrrghsphgsvghrrhihphhirdgt ohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvh hoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 11 Sep 2022 11:31:23 -0400 (EDT) Date: Sun, 11 Sep 2022 16:31:21 +0100 From: void To: freebsd-hackers@freebsd.org Subject: [can freebsd utilise gpu split memory on rpi4] Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Rspamd-Queue-Id: 4MQYbx2lGwz40hf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=Luu1T2p2; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="Q P5LeZ/"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-5.20 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hello, Posting this here in the hope that someone might know a bit about arm64 internals in the way cpu/gmu memory split applies or doesn't apply for x11 etc on -current. TIA ----- Forwarded message from void ----- Date: Sun, 4 Sep 2022 15:00:35 +0100 From: void To: freebsd-arm@freebsd.org Subject: can freebsd utilise gpu split memory on rpi4 Mail-Followup-To: freebsd-arm@freebsd.org List-Id: Porting FreeBSD to ARM processors Hi, tl;dr : I'm trying to make a freebsd desktop configuration for rpi4b. Is freebsd able to utilise the GPU part of the raspberry pi 4b? In config.txt there can be a GPU_MEM statement for a variable size, the remaining memory being used by the CPU. Would it make sense to set this as large as possible for a desktop environment, or will it simply subtract from available memory and not be used, or does it not have any effect at all in freebsd/xorg ? GPU memory split appears under legacy options. https://www.raspberrypi.com/documentation/computers/config_txt.html#legacy-options it's not clear to me if these would even work under latest firmware. -- ----- End forwarded message ----- -- From nobody Tue Sep 13 16:03:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MRpDm5j34z4bkpW for ; Tue, 13 Sep 2022 16:04:08 +0000 (UTC) (envelope-from jo@bruelltuete.com) Received: from email.jo-t.de (seppel.jo-t.de [45.132.244.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MRpDl4PT3z47cc for ; Tue, 13 Sep 2022 16:04:07 +0000 (UTC) (envelope-from jo@bruelltuete.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bruelltuete.com; s=bruelltuete18a; t=1663085041; bh=T3LCkgOpmm3OJqJpxNutxlNjcpdH3ncQyC7CY1pvAK8=; h=Message-ID:Date:MIME-Version:To:From:Subject:From; b=A/WpmJEyNewr7QUaIk3He3dGih9XaxknnauccQzxq+hX786Sq5hrqzQCSSJh2RGgF xe7VVx5ft7AVCU4Q3gKeShyOImosVYVtNhGame4MrB9kssNOYrZNacYvmCQ29xRAYK 3O5fomDDYELqjvfFZLShf3DJUM7NtrXiWypwWmSt22jdYx+jflSNy5Qcxro8lz8INz 0erErh92W3c/u5GYX4by+a8dm/50PdqVcGmaJ5PasvYxjFmrolY2Mi7WF8JQBstEQ4 OjxKM1PA/3EtkpS5u+sDQ1ymJSkpbGmDDEd8vKP+w2YvY4xpsBimEWf5ZCeuHQjjew JuxYFhbnhYA6Q== Message-ID: <9b87dd66-de57-f363-279e-dc33134c0fa6@bruelltuete.com> Date: Tue, 13 Sep 2022 17:03:58 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Language: en-GB To: freebsd-hackers@FreeBSD.org From: Johannes Totz Subject: How to sync/mutex with acpi_tz_get_temperature() Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MRpDl4PT3z47cc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bruelltuete.com header.s=bruelltuete18a header.b="A/WpmJEy"; dmarc=pass (policy=none) header.from=bruelltuete.com; spf=pass (mx1.freebsd.org: domain of jo@bruelltuete.com designates 45.132.244.126 as permitted sender) smtp.mailfrom=jo@bruelltuete.com X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.69)[-0.695]; DMARC_POLICY_ALLOW(-0.50)[bruelltuete.com,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[bruelltuete.com:s=bruelltuete18a]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:197540, ipnet:45.132.244.0/22, country:DE]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bruelltuete.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi there, I would like to make sure that some of my code does not run concurrently with acpi_tz_get_temperature() [https://github.com/freebsd/freebsd-src/blob/main/sys/dev/acpica/acpi_thermal.c#L465]. What's the best way to achieve that? I wrote a small driver for one of those SuperIO hardware monitors that measures fan speed, voltage, temperature etc. That works fine. But looking at my board/BIOS's ASL, invoking _TMP is not safe to do concurrently with my driver. [see footnote] Ultimately, acpi_tz_thread() [https://github.com/freebsd/freebsd-src/blob/main/sys/dev/acpica/acpi_thermal.c#L949] is calling acpi_tz_get_temperature() with a few hops in-between. There are a few instances of ACPI_LOCK(thermal) etc but nothing that guards acpi_tz_get_temperature() specifically. Anyone have ideas/pointers? thanks, Johannes footnote: Reading from that chip is stateful, as in you need to do I/O to select which register you want to read/write and then read/write from another location to access the value of that register. Try to do that from 2 threads at the same time, one of them will read/write the wrong register, thus you can glitch ACPI into doing something disruptive/destructive. From nobody Wed Sep 14 13:43:00 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSM3d5KZ6z4c8Vf; Wed, 14 Sep 2022 13:43:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSM3c2xqjz3wWJ; Wed, 14 Sep 2022 13:43:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Cc:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=u68S5X4F80/oUGnEx9etXBqOLzXOpBcSs2e5+vrQLC0=; b=ziSMBPzf8j8TKB3xK2GavlNgzD9ieg259HmtVVfmwUwCJrA1lFvZvOIbY+ynUym3MMY05cktTwJXZn5hVv6QGv5f8piJKspijto83DPtoOQCaWuNNlyFDk23kJToqE2FUSOzzs55s59a4qm1ijXqA330pP8NkvTbMfWeEpV3xoGNbMzbnYws/1fHQo6YGa8kIt7yAcDRDImP+TnUBq/n8yIr/U43glbKcMvsxet9HdbucCluGu5gAmcNeY2LJHVQb93CHa0XaDEgkTn6CNkd/zJrv0XMpJzLt0GLn46HkcAPDK4op7RX511lINmB4RTReAwy38ghD2BUevDhyIcC9Q==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1oYSfM-000DCF-9A; Wed, 14 Sep 2022 16:43:00 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: USB chip CH9102F Message-Id: Date: Wed, 14 Sep 2022 16:43:00 +0300 Cc: "usb@freebsd.org" To: freebsd-hackers X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MSM3c2xqjz3wWJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=ziSMBPzf; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MLMMJ_DEST(0.00)[hackers@freebsd.org,usb@FreeBSD.org]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; TO_DN_EQ_ADDR_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, is there/will there be any support for this chip? CH9102F. there is a driver for linux and windows, but event though it sort of = works on FreeBSD, the magic needed to flash the firmware on newer esp32=E2=80=99s is not = working. thanks, danny From nobody Wed Sep 14 14:34:12 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSNBc1BtMz4cGP7; Wed, 14 Sep 2022 14:34:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSNBb2YnYz426J; Wed, 14 Sep 2022 14:34:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=5RxODDPeL3vcs1H0UULgrD9Oxv8mrGca6LiInjeKLzY=; b=qw7lMvmT6Q0AZOmnSVJuQTBPtptAqFIAe4wD4IE4YlpS72SqfX2feW9zILFMsNV4goxMu51lvDz4/WJ/zufR9+TgdYa7O1N/DRNmmwotINlxKiRVn752P2H8NRmCqFJWpSeiGwCtcOFAFRJpYKne5YOe8tsN/gy14HCf8WNRNBX5e8gVq0UQDgynGnMqPMULDRkuwvy77ElxNtHFI6fhwJCczhPYY0lJejmAvOIPLlCCiwXntO9iQ36OPy7YdyE4IDWZPyAFnKKWvIVygrk7zbgBqeoI6kGB3wrKD+7B15UiiV0eYd7RqEh7bsW4cKmBaAanSz7DQdqgEtz8hdIzSA==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1oYTSu-000ED6-9W; Wed, 14 Sep 2022 17:34:12 +0300 From: Daniel Braniss Message-Id: <117B32B3-E6F9-4611-A8C1-BBBF9BE69372@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_80E5B465-F037-4268-BEA6-0E5D34EF2E2D" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: USB chip CH9102F Date: Wed, 14 Sep 2022 17:34:12 +0300 In-Reply-To: Cc: freebsd-hackers , "usb@freebsd.org" To: Hans Petter Selasky References: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MSNBb2YnYz426J X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=qw7lMvmT; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org,usb@FreeBSD.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_80E5B465-F037-4268-BEA6-0E5D34EF2E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2022, at 17:27, Hans Petter Selasky wrote: >=20 > On 9/14/22 15:43, Daniel Braniss wrote: >> Hi, >> is there/will there be any support for this chip? CH9102F. >> there is a driver for linux and windows, but event though it sort of = works on FreeBSD, >> the magic needed to flash the firmware on newer esp32=E2=80=99s is = not working. >> thanks, >> danny >=20 > Which driver is currently used for this chip? >=20 Sep 14 12:17:23 pampero kernel: ugen0.4: at usbus0 Sep 14 12:17:23 pampero kernel: umodem0 on uhub0 Sep 14 12:17:23 pampero kernel: umodem0: on usbus0 Sep 14 12:17:23 pampero kernel: umodem0: data interface 1, has no CM = over data, has no break > --HPS --Apple-Mail=_80E5B465-F037-4268-BEA6-0E5D34EF2E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2022, at 17:27, Hans Petter Selasky <hps@selasky.org> = wrote:

On 9/14/22 15:43, Daniel Braniss wrote:
Hi,
is = there/will there be any support for this chip? CH9102F.
there is a driver for linux and windows, but event though it = sort of works on FreeBSD,
the magic needed to flash the = firmware on newer esp32=E2=80=99s is not working.
thanks, = danny

Which driver is = currently used for this chip?


Sep 14 12:17:23 pampero = kernel: ugen0.4: <vendor 0x1a86 USB Single Serial> at = usbus0
Sep 14 12:17:23 pampero = kernel: umodem0 on uhub0
Sep 14 = 12:17:23 pampero kernel: umodem0: <vendor 0x1a86 USB Single Serial, = class 2/0, rev 1.10/4.43, addr 53> on usbus0
Sep 14 12:17:23 pampero kernel: umodem0: = data interface 1, has no CM over data, has no break


--HPS

= --Apple-Mail=_80E5B465-F037-4268-BEA6-0E5D34EF2E2D-- From nobody Wed Sep 14 15:14:54 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSP5x4RSYz4cLwy for ; Wed, 14 Sep 2022 15:15:17 +0000 (UTC) (envelope-from cederom@tlen.pl) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSP5v72nfz47xs for ; Wed, 14 Sep 2022 15:15:15 +0000 (UTC) (envelope-from cederom@tlen.pl) Received: (wp-smtpd smtp.tlen.pl 11119 invoked from network); 14 Sep 2022 17:15:07 +0200 Received: from mail-yb1-f178.google.com (cederom@tlen.pl@[209.85.219.178]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 14 Sep 2022 17:15:07 +0200 Received: by mail-yb1-f178.google.com with SMTP id e187so17023848ybh.10; Wed, 14 Sep 2022 08:15:07 -0700 (PDT) X-Gm-Message-State: ACrzQf3R/hDo3qEJ3C3+L7g3ObJ8bmKyPlcJcJEe/RP1J0D4XrlbJngJ FH/J0JjbVUxXG6dfYtkwHF9ewm5ZUDpJFUMc1+8= X-Google-Smtp-Source: AMsMyM4agS1rOuWm8PkbHBmBSvEhB9lmccHuScGRrO3nWOnCVvHbjhm4U1gbgxvipLoyi5V/mJseQ8SBqbCDFOHR/d0= X-Received: by 2002:a25:6d04:0:b0:6b0:1f0b:dccd with SMTP id i4-20020a256d04000000b006b01f0bdccdmr1451908ybc.359.1663168506114; Wed, 14 Sep 2022 08:15:06 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: CeDeROM Date: Wed, 14 Sep 2022 17:14:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: USB chip CH9102F To: Daniel Braniss Cc: freebsd-hackers , "usb@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-WP-MailID: 08ba9dc942212483fd917d6b70837608 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0W00001 [IcJd] X-Rspamd-Queue-Id: 4MSP5v72nfz47xs X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of cederom@tlen.pl designates 193.222.135.158 as permitted sender) smtp.mailfrom=cederom@tlen.pl X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:193.222.135.0/24]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.178:received]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:31080, ipnet:193.222.135.0/24, country:PL]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[tlen.pl]; RWL_MAILSPIKE_POSSIBLE(0.00)[193.222.135.158:from] X-ThisMailContainsUnwantedMimeParts: N On Wed, Sep 14, 2022 at 3:43 PM Daniel Braniss wrote: > Hi, > is there/will there be any support for this chip? CH9102F. > > there is a driver for linux and windows, but event though it sort of work= s on FreeBSD, > the magic needed to flash the firmware on newer esp32=E2=80=99s is not wo= rking. I also bought USB-C based UART-to-USB adapter from Waveshare with CH343G chip and use it for ESP32 flashing. This chip is a bit tricky and I have noticed it is less reliable for initial flashing on a custom ESP32 board (boot mode selection using RTS/CTS pins). It sometimes fails, while older USB-UART converters works fine. What are your problems exactly? Are you sure this is not the custom hardware design issue? Do you have Reset and BootSel pins on your board that you can trigger by hand in order to help USB-UART cable? What is your magic that you need to do in order to flash the chip successfu= lly? Does standard operations (UART CLI) work as expected? Did you take a look at man stty and use stty crtscts / stty -crtscts to see if that fixes anything? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Wed Sep 14 15:55:05 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSPzx5MTFz4cRHp; Wed, 14 Sep 2022 15:55:09 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSPzw4L4sz3FWY; Wed, 14 Sep 2022 15:55:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=BQqmicVjnGSa7XzyQbDZp5bj9RgmnA65DmdAiud1fIk=; b=zEa8Zw/99X+BrNmzRhK7Lr7QzlHlbGYabZXlZ4vZ1Qfz7Lyiq2EfZ6n/DghciQS0eFBH9vxoyof8G2WkqQKaU3p6MN5zjfHCIr6t0fiGRt4EQUEcss45N14FCC0XC7u2TytT39j9XJVij2HIURdnIyEMj6RxyUhzcqrP45Sfc69pI9NqORTlfwUQBSlUCAu2/Kl0FPibI0DsN3RplF8MxMwfyndGMNMxLkt8BzDDuPGn+RMQq+bqEOdzrYijrbNRXYcHCDrcZLX/MFI2eF/ohMuXzVSkjrkLAQ0AfPEPe0x1l699ArJD+goG1Kd8o50iVkhubivlEAfuYzdhF+yMHg==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1oYUjB-000FlJ-MI; Wed, 14 Sep 2022 18:55:05 +0300 From: Daniel Braniss Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_04A01092-B1D2-4D18-A892-6500F906BB84" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: USB chip CH9102F Date: Wed, 14 Sep 2022 18:55:05 +0300 In-Reply-To: Cc: freebsd-hackers , "usb@freebsd.org" To: CeDeROM References: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MSPzw4L4sz3FWY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b="zEa8Zw/9"; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org,usb@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_04A01092-B1D2-4D18-A892-6500F906BB84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2022, at 18:14, CeDeROM wrote: >=20 > On Wed, Sep 14, 2022 at 3:43 PM Daniel Braniss wrote: >> Hi, >> is there/will there be any support for this chip? CH9102F. >>=20 >> there is a driver for linux and windows, but event though it sort of = works on FreeBSD, >> the magic needed to flash the firmware on newer esp32=E2=80=99s is = not working. >=20 > I also bought USB-C based UART-to-USB adapter from Waveshare with > CH343G chip and use it for ESP32 flashing. >=20 > This chip is a bit tricky and I have noticed it is less reliable for > initial flashing on a custom ESP32 board (boot mode selection using > RTS/CTS pins). It sometimes fails, while older USB-UART converters > works fine. >=20 > What are your problems exactly? >=20 > Are you sure this is not the custom hardware design issue? >=20 > Do you have Reset and BootSel pins on your board that you can trigger > by hand in order to help USB-UART cable? >=20 > What is your magic that you need to do in order to flash the chip = successfully? >=20 > Does standard operations (UART CLI) work as expected? >=20 > Did you take a look at man stty and use stty crtscts / stty > -crtscts to see if that fixes anything? >=20 > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info i have many esp32=E2=80=99s, all the old ones work fine, it=E2=80=99s = only the latest ones, for example: m5stac esp3c3 and my latest batch of m5stack base black v1,26 which i get: pampa> /vol/src/esp/current/components/esptool_py/esptool/esptool.py -p = /dev/ttyU0 read_mac esptool.py v3.3-dev Serial port /dev/ttyU0 Connecting... Failed to get PID of a device on /dev/ttyU0, using standard reset = sequence. . Detecting chip type... ESP32-C3 Chip is ESP32-C3 (revision 3) Features: Wi-Fi Crystal is 40MHz MAC: 7c:df:a1:a3:61:74 Uploading stub... A fatal error occurred: Failed to write to target RAM (result was = 01070000: Operation timed out) the fatal error I also get when trying to flash/erase/ etc. i have some esp32 that have usb, some don=E2=80=99t, some can flash, = some need sounding g0, etc, I can mostly work with them, it=E2=80=99s only the latest batch, which = =E2=80=99seem=E2=80=99 to have this CH9102f that fail to flash with the above =E2=80=98A fatal error =E2=80=A6=E2=80=99 BTW, regular connect via usb works, so i get console messages ok. thanks, danny --Apple-Mail=_04A01092-B1D2-4D18-A892-6500F906BB84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2022, at 18:14, CeDeROM <cederom@tlen.pl> = wrote:

On Wed, Sep 14, 2022 at 3:43 PM Daniel Braniss wrote:
Hi,
is = there/will there be any support for this chip? CH9102F.

there is a driver for linux and windows, but event though it = sort of works on FreeBSD,
the magic needed to flash the = firmware on newer esp32=E2=80=99s is not working.

I also bought USB-C based = UART-to-USB adapter from Waveshare with
CH343G chip and = use it for ESP32 flashing.

This chip is a = bit tricky and I have noticed it is less reliable for
initial flashing on a custom ESP32 board (boot mode selection = using
RTS/CTS pins). It sometimes fails, while older = USB-UART converters
works fine.

What are your problems exactly?

Are you sure this is not the custom hardware design issue?

Do you have Reset and BootSel pins on your = board that you can trigger
by hand in order to help = USB-UART cable?

What is your magic that you = need to do in order to flash the chip successfully?

Does standard operations (UART CLI) work as expected?

Did you take a look at man stty and use stty = crtscts <port> / stty
-crtscts <port> to see = if that fixes anything?

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

i have = many esp32=E2=80=99s, all the old ones work fine, it=E2=80=99s only the = latest ones, for example: m5stac esp3c3 and my latest
batch of = m5stack base black v1,26 which i get:

pampa> = /vol/src/esp/current/components/esptool_py/esptool/esptool.py -p = /dev/ttyU0 read_mac
esptool.py = v3.3-dev
Serial port = /dev/ttyU0
Connecting...
Failed to get PID of a device on = /dev/ttyU0, using standard reset sequence.
.
Detecting chip type... = ESP32-C3
Chip is ESP32-C3 (revision = 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:a3:61:74
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result = was 01070000: Operation timed out)


the fatal = error I also get when trying to flash/erase/ = etc.


i have some esp32 that have usb, some don=E2=80=99t, = some can flash, some need sounding g0, etc,
I can mostly work with them, = it=E2=80=99s only the latest batch, which =E2=80=99seem=E2=80=99= to have this CH9102f that
fail to flash with the = above =E2=80=98A fatal error =E2=80=A6=E2=80=99


BTW,= regular connect via usb works, so i get console messages ok.

thanks,

= danny

= --Apple-Mail=_04A01092-B1D2-4D18-A892-6500F906BB84-- From nobody Thu Sep 15 00:00:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSclS0mHgz4cXy1; Thu, 15 Sep 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSclS0F63z3tT2; Thu, 15 Sep 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663200004; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=NNDB7hdZRf3sTVZqHcjX1NoRAQRY2s4FPSER7hm3hgllVsbnJnSaYnxhhToUN5wSf/xdEU 2ixtXd6IowVqXP9Y1S3ZRWrYEiWgSw4l6OhNAcjU7qb0R+d6LGWCjliIc2vyZDy2DNGv0w 6iqtsZBy+eoVZs+t/gmnVkmq487Tu5Uj/mm5mZ/mbMtOHsIWBbbEFicKxkAtdG+9s83Hcq 9512IBwLOagT+Wb64izg/MaBwWs2c+/5WBTe/OjXyB+9EBPQV63VoeTzgZXtl0AVvbnS8Z 1Rid7afg7UqIG90jxf4A+Fc4Ho91clV+QHSaL+6NmKoZdsfDjNE07TsHxqCYNQ== Received: by freefall.freebsd.org (Postfix, from userid 1472) id C545CA8F7; Thu, 15 Sep 2022 00:00:03 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q3 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20220915000003.C545CA8F7@freefall.freebsd.org> Date: Thu, 15 Sep 2022 00:00:03 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663200004; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=w0upiJ4n56abGegJ+6iLAsvLdc8GEbCl4878nq6PbyrRBy7NFotUgISdpEvcH68bgsnAyJ B+kSWviTsc4RKNYsMXDRNUyPgHP4jj+jNi0wR0BVeBnwIFSG96jUy2N7Mv3rmfv6AwdsaO 2tjbcHOzDvHDLJ1nC9xQLqLuk0QBl7zWWVtwE4AApAnGnvK7Mwzw2bohAIKQVEuTqvGJ2J OAdrnhl7yb1ZuSuRSmb0UFjpwKciclt/K/huqr6hxH+d1qhJgbdYrwPhCCCktkcYdTWEs3 mrQ+/DtKcrtnSORtDehzGzzd7b0rhLj9hf9v2avXHeg/m8+PnfbkqUd9M4LTeQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663200004; a=rsa-sha256; cv=none; b=ZwZ/LNK9K7MsFctfFxXn+k3/y+AUBLeYFysRbPKPK7Svk4H7aUCnQsv6jNn7ziTtTSDWb2 Ev2mX1WXGKdcrJ9S5utAW3n7xeSFdabxYzESnsySRauDVKKxYk4vSKFpiu/q0f0zyHyLTr ZHGSi8CecKr3ntDuTVaNZIxS02ksPWMgk+BGDFz1kwuvrRBnOFA8oIxOw6UIVK9zipRKCb dYCCvJKG0OKI+b3qP4O1sMEn8CIPmpurMxu5gQdE5ysjFKQozU3OVc1jiEqPGRDMfHzpZy Pf4RUYiVowmoriyeWa8o8AWpb4NMW1O0kpS0x9rl4tvb9wXxUmRXijHJFB1csg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is September, 30th 2022 for work done since the last round of Quarterly Reports: July 2022 - September 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q3 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Thu Sep 15 12:29:45 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSxNY3Cc7z4c5r7; Thu, 15 Sep 2022 12:29:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSxNX1xbMz3m6q; Thu, 15 Sep 2022 12:29:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=TNdaM3VANthJACElyypZr+WCr+ok+5+JzyJyrQeZQLI=; b=ZPARK5T7cx4rtjlL7mEmeC9jFS7JqKP1x/rCnFdbti1NkPK1JMynJzeXsmOsS8xaDBU5JBpAc/HXUd8VIOBX795ymF3WEAwxlYASTRa7Mi3woTgXULY8FIV6iDHpL5r33AuX4WQJyQSGvXCoKAuDJyvkGWt38z4/6+OylPv5+MkayZf921aYY/wswBxUlbgahqr12ZcW9R+BdG29vPDNXKSmVAt6RF5fsr4UC9xS0UoYNDbAogoWv7v/5u1sbZcPVJmQfF871fCtJN+bLtBjleXMp+2WCElQEbEpPOwOC9o1Y4qhxW6+LKtjJqnKpMvLajV997NeEWKQgCPKOo6oqw==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1oYo01-000DIc-8s; Thu, 15 Sep 2022 15:29:45 +0300 From: Daniel Braniss Message-Id: <2658B51D-E40A-4B08-8EDF-7CF1264B0FB4@cs.huji.ac.il> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B7298CB-40D9-437F-8508-6C670CBDA90B" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: USB chip CH9102F Date: Thu, 15 Sep 2022 15:29:45 +0300 In-Reply-To: Cc: freebsd-hackers , "usb@freebsd.org" To: CeDeROM References: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MSxNX1xbMz3m6q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=ZPARK5T7; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org,usb@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_8B7298CB-40D9-437F-8508-6C670CBDA90B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2022, at 18:14, CeDeROM wrote: >=20 > On Wed, Sep 14, 2022 at 3:43 PM Daniel Braniss wrote: >> Hi, >> is there/will there be any support for this chip? CH9102F. >>=20 >> there is a driver for linux and windows, but event though it sort of = works on FreeBSD, >> the magic needed to flash the firmware on newer esp32=E2=80=99s is = not working. >=20 > I also bought USB-C based UART-to-USB adapter from Waveshare with > CH343G chip and use it for ESP32 flashing. >=20 > This chip is a bit tricky and I have noticed it is less reliable for > initial flashing on a custom ESP32 board (boot mode selection using > RTS/CTS pins). It sometimes fails, while older USB-UART converters > works fine. >=20 > What are your problems exactly? >=20 pampa> /vol/src/esp/current/components/esptool_py/esptool/esptool.py -p = /dev/ttyU0 read_mac esptool.py v3.3-dev Serial port /dev/ttyU0 Connecting... Failed to get PID of a device on /dev/ttyU0, using standard reset = sequence. . Detecting chip type... ESP32-C3 Chip is ESP32-C3 (revision 3) Features: Wi-Fi Crystal is 40MHz MAC: 7c:df:a1:a3:61:74 Uploading stub... A fatal error occurred: Failed to write to target RAM (result was = 01070000: Operation timed out) > Are you sure this is not the custom hardware design issue? >=20 no, it=E2=80=99 happens on several esp32s specially from m5stack > Do you have Reset and BootSel pins on your board that you can trigger > by hand in order to help USB-UART cable? this particular onw, m6stack black/basic, has no gpio-0 available to = enter download mode, the older models have no problem with the usb-c >=20 > What is your magic that you need to do in order to flash the chip = successfully? see the above. some other boards I just connect gpio-0 to ground, or have to press a = button before power on, but I can flash. Also, as soon as I manage to flash, I can continue = flashing over the air. >=20 > Does standard operations (UART CLI) work as expected? again, all boards/thingis i have no problem reading the console, and = even writing >=20 > Did you take a look at man stty and use stty crtscts / stty > -crtscts to see if that fixes anything? the initial (or when my software crashes) flashing is done via a python = that does all the magic. >=20 > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >=20 well, it does feel better knowing i=E2=80=99m not the only one with this = problem :-) --Apple-Mail=_8B7298CB-40D9-437F-8508-6C670CBDA90B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2022, at 18:14, CeDeROM <cederom@tlen.pl> = wrote:

On Wed, Sep 14, 2022 at 3:43 PM Daniel Braniss wrote:
Hi,
is = there/will there be any support for this chip? CH9102F.

there is a driver for linux and windows, but event though it = sort of works on FreeBSD,
the magic needed to flash the = firmware on newer esp32=E2=80=99s is not working.

I also bought USB-C based = UART-to-USB adapter from Waveshare with
CH343G chip and = use it for ESP32 flashing.

This chip is a = bit tricky and I have noticed it is less reliable for
initial flashing on a custom ESP32 board (boot mode selection = using
RTS/CTS pins). It sometimes fails, while older = USB-UART converters
works fine.

What are your problems exactly?

pampa> = /vol/src/esp/current/components/esptool_py/esptool/esptool.py -p = /dev/ttyU0 read_mac
esptool.py = v3.3-dev
Serial port = /dev/ttyU0
Connecting...
Failed to get PID of a device on = /dev/ttyU0, using standard reset sequence.
.
Detecting chip type... = ESP32-C3
Chip is ESP32-C3 (revision = 3)
Features: Wi-Fi
Crystal is 40MHz
MAC: 7c:df:a1:a3:61:74
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result = was 01070000: Operation timed out)

Are you sure = this is not the custom hardware design issue?

no, it=E2=80=99 happens on several = esp32s specially from m5stack

Do you have = Reset and BootSel pins on your board that you can trigger
by= hand in order to help USB-UART cable?
this particular onw, m6stack = black/basic, has no gpio-0 available to enter
download mode, = the older models have no problem with the usb-c

What is your magic that you need to do in order to flash the = chip successfully?
see the = above.
some other boards I just connect gpio-0 to ground, or = have to press a button before power on,
but I can flash. Also, = as soon as I manage to flash, I can continue flashing over the = air.


Does standard operations (UART = CLI) work as expected?
again, all = boards/thingis i have no problem reading the console, and even = writing

Did you take a look at man = stty and use stty crtscts <port> / stty
-crtscts = <port> to see if that fixes anything?

the = initial (or when my software crashes) flashing is done via a python that = does all the magic.

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



well, it does feel = better knowing i=E2=80=99m not the only one with this problem = :-)

= --Apple-Mail=_8B7298CB-40D9-437F-8508-6C670CBDA90B-- From nobody Thu Sep 15 13:45:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MSz3m0x3Hz4cJ87; Thu, 15 Sep 2022 13:45:24 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [95.217.20.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MSz3l1TVdz3vSq; Thu, 15 Sep 2022 13:45:23 +0000 (UTC) (envelope-from des@des.no) Received: from ltc.des.no (unknown [84.211.31.80]) by smtp.des.no (Postfix) with ESMTPSA id AE3CF25C81; Thu, 15 Sep 2022 13:45:14 +0000 (UTC) Received: by ltc.des.no (Postfix, from userid 1001) id 3763E92A05; Thu, 15 Sep 2022 15:45:14 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-security@freebsd.org Subject: Putting OPIE to rest User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (berkeley-unix) Date: Thu, 15 Sep 2022 15:45:14 +0200 Message-ID: <86h718sqdx.fsf@ltc.des.no> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MSz3l1TVdz3vSq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of des@des.no designates 95.217.20.81 as permitted sender) smtp.mailfrom=des@des.no X-Spamd-Result: default: False [-2.58 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_MIXED_CHARSET(0.71)[subject]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:95.217.0.0/16, country:DE]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[des]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[des.no]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I will be removing OPIE from the main branch within the next few days. It has long outlived its usefulness. Anyone still using it should look into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). https://reviews.freebsd.org/D36592 DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From nobody Thu Sep 15 23:00:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTCNP1Y1Dz4ccTf; Thu, 15 Sep 2022 23:00:37 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTCNN3ZZTz3xhp; Thu, 15 Sep 2022 23:00:36 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-pl1-x62c.google.com with SMTP id l10so19750158plb.10; Thu, 15 Sep 2022 16:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date; bh=gLruk2nidha8R62TkgaOHg0e26WXRaBz3m5BXBrVhoo=; b=G+LD/RKdVCweubJZ8OqPVD+lS6expHB+ecnO/BJYeuw1CGsYfypoUTSLCu5p0UGdSj /8Zh9YitukTG5y8qeXte+gQbtQ4UlRkpToPMyWpwQoXZnQ2QHJNb0/+CnqAy88p1R8OW ntzh64FVYfb96OBZ8qmjBesnMJoaRHVZ3bikZfPXd1h5dIl4iGdgYfnpTV3mYA6+Fuad mcuTbnwslkmD1otpOYjEztQzxCADTQ2eb60tVMEFFL/MeZ5RqVVnE9t+Ms5WfuBgYixB jve7uxIeAmz8qXhtzdUfzdyaFgA/DNWcCi0gs9GgBw5FHIeu607FGewANv9TQ2IlCkN2 V/kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=gLruk2nidha8R62TkgaOHg0e26WXRaBz3m5BXBrVhoo=; b=FkXk7AVzIla3AqmrszoSxQZX/Zt5cNq0wL/bxeaWnhULmT6LbNi2hSTQpV0zfnBXRW v4xFfaIl1kkEmD/ae6rmRHPpiqkUyZrmb0VbdSWyjZQHUYGeR8ZEHCnOdJRf+cfwQy28 RGi8+oT0PLShmfSsNur5Fq+PD4jDZAtbKTHEmRgIWGeoWkemsh7I1i3xeE7hc/DD4T8I O+XDSJN92FYP+eVTtbsyRxRq5CWoQBkvveIdOkLIqjpiTKZXZU5ORQeitVMb7r8sqKmT MH2ljlbsPtX3lneLNKSfHl2DxYyot8GuHMOvvBMBnYHomrBvwb5s7x9l/wAqgLB/3W2N Tetw== X-Gm-Message-State: ACrzQf1FTWdJLyyvk3VB5Ohxd5hYSn6W4YJEHUaOXIzsE8Lz6XQbWFcc I1vxD5CQbcOP5FbMtzRZMCJKXlbgKOM6psDdjcunVmcT/Zen1c3Sj38= X-Google-Smtp-Source: AMsMyM4N7Vm064HzmmxQ4iU4V/a5hF2nVDIZRdQ0fmLAB/FPeclm+1E6rswlQ0njFisCA9FdkU2OVv/sDs4XODDRYPE= X-Received: by 2002:a17:902:f682:b0:178:3ede:a12f with SMTP id l2-20020a170902f68200b001783edea12fmr1857064plg.26.1663282833258; Thu, 15 Sep 2022 16:00:33 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a17:902:ccc9:b0:175:41cd:2693 with HTTP; Thu, 15 Sep 2022 16:00:32 -0700 (PDT) In-Reply-To: <86h718sqdx.fsf@ltc.des.no> References: <86h718sqdx.fsf@ltc.des.no> From: grarpamp Date: Thu, 15 Sep 2022 19:00:32 -0400 Message-ID: Subject: Re: Putting OPIE to rest To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, des@des.no Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MTCNN3ZZTz3xhp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="G+LD/RKd"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::62c as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.53 / 15.00]; NEURAL_HAM_MEDIUM(-0.86)[-0.857]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_LONG(-0.48)[-0.475]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_SHORT(-0.20)[-0.199]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::62c:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 9/15/22, Dag-Erling Sm=C3=B8rgrav wrote: > I will be removing OPIE from the main branch within the next few days. > It has long outlived its usefulness. Anyone still using it should look > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). > https://reviews.freebsd.org/D36592 At least so long as PAM remains available, OPIE should be maintained as a PAM option, and be updated. OPIE is the only PAM that allows printing out the future secure tokens. Old school, secure, it just works. HOTP requires hardware, TOTP requires time, neither are printable, both of those require some other [hackable] hw/sw device that costs $$$ money, and those devices all have different threat/failure/admin models than simple paper. If people don't like... - The hash algo, a volunteer committer can update it to sha256. - The list of words, a volunteer committer can update it to read from a list of admin supplied words in: /etc/opie_words.txt - The number of words, a volunteer committer can add an option to the config for that. - The writeable state breaking in a read-only root, a volunteer committer can add a config option to point that elsewhere. - The randomness, a volunteer committer can update it to modern randomness. And if people still don't like it, then commit those simple updates, and push it out to ports, instead of killing users use of it. From nobody Thu Sep 15 23:31:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTD435bDGz4chDq; Thu, 15 Sep 2022 23:31:31 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTD423fNdz45TQ; Thu, 15 Sep 2022 23:31:30 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id y82so30047531yby.6; Thu, 15 Sep 2022 16:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=68051deLQQFKhwRlUVi0FAESOL7aVmr8iH4mHpz+VO0=; b=SRq3FjmC26BuzwsF64XuEXY/LpRCaEsA63oYJ/jCxxu2trRIOk75+Y9HnzmVJpHY/3 TzOJWLD/+kEJw9VBqpp7WmqNAWhbt2vQxg0azXVI0FTuGA044P5TwtyL8sYbyoh5WveJ jsCxvx4r7MVkJgyjTB5X6OtX9b5Z9mQYITYW99qcyQuDSB2ElsGRsvZFbSE3TkbW3RSv brm3awZQ8Uk4o17sBMB23avxgmaANoLqbLGomEz28aVxVW3HUOoUAhRMARrv1rUQjNiQ CYgzI5zhHSWcV5ZR3npGY+aAaEINXXPggeVdETF0qUNDLV1oTy0V0jJU1wb3Nh9bKuhh ApXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=68051deLQQFKhwRlUVi0FAESOL7aVmr8iH4mHpz+VO0=; b=PPosX29immUg8d6918T0rZ15BXFsoGecJ/pv4B+GLMn1XiqtMvutIM2qPwoFevbrgy YSQduqh2W+Nhm9yK7O5ppRVGLR6q6bBWM4ntcCUMmOKHx8sx6wzcdhuZEbUmz59gxVoy 15lux+YjuZ54LMW/k/KiAOymjyl1jqpc/F+umrALv72XrZUCQp+awZ1dUNktJju4u48V jlLu3xYzSpBFk1jkcKE8dl8NAu75MFcNrsnH6LkJP754YxXXmNJn6m/wMzHbf7I/pjIg kCOZ+9QO+qNXJISGn0rXNJNQs9obsaogDMRLO1KB8ZWNjyrGGPPGIdNE6Mzm5aD9JyEL WyFw== X-Gm-Message-State: ACrzQf1L037jqdF9zQ3VQSuZdcIIl0P1agPCgyScgiU3BF3n2EWGqaa3 mHNtiQz0E6Fu43oPPKjYqYGVcMi3V9ySASezLao= X-Google-Smtp-Source: AMsMyM6f47azINm3ZLMCK2RH0lgSK0XRb2miNPtz1wz8n4Xxi6+3pF+IKojJxgC1L5zbNoxGzeZqPQZcV1XR1xL7Vzc= X-Received: by 2002:a25:5f42:0:b0:6af:662c:f48f with SMTP id h2-20020a255f42000000b006af662cf48fmr1900225ybm.566.1663284689419; Thu, 15 Sep 2022 16:31:29 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <86h718sqdx.fsf@ltc.des.no> In-Reply-To: From: Joe Schaefer Date: Thu, 15 Sep 2022 19:31:18 -0400 Message-ID: Subject: Re: Putting OPIE to rest To: grarpamp Cc: des@des.no, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-security@freebsd.org Content-Type: multipart/alternative; boundary="00000000000012c19505e8bfa5be" X-Rspamd-Queue-Id: 4MTD423fNdz45TQ X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SRq3FjmC; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of joesuf4@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=joesuf4@gmail.com X-Spamd-Result: default: False [-2.84 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.95)[-0.955]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_SPAM_LONG(0.12)[0.117]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000012c19505e8bfa5be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable google-authenticator-libpam works for sudo controls? On Thu, Sep 15, 2022 at 7:01 PM grarpamp wrote: > On 9/15/22, Dag-Erling Sm=C3=B8rgrav wrote: > > I will be removing OPIE from the main branch within the next few days. > > It has long outlived its usefulness. Anyone still using it should look > > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). > > https://reviews.freebsd.org/D36592 > > At least so long as PAM remains available, OPIE should be > maintained as a PAM option, and be updated. > > OPIE is the only PAM that allows printing out the future > secure tokens. Old school, secure, it just works. > > HOTP requires hardware, TOTP requires time, > neither are printable, both of those require some other > [hackable] hw/sw device that costs $$$ money, and > those devices all have different threat/failure/admin models > than simple paper. > > If people don't like... > - The hash algo, a volunteer committer can update it to sha256. > - The list of words, a volunteer committer can update it to > read from a list of admin supplied words in: > /etc/opie_words.txt > - The number of words, a volunteer committer can add an > option to the config for that. > - The writeable state breaking in a read-only root, a volunteer > committer can add a config option to point that elsewhere. > - The randomness, a volunteer committer can update it > to modern randomness. > > And if people still don't like it, then commit those simple updates, > and push it out to ports, instead of killing users use of it. > > --00000000000012c19505e8bfa5be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
google-authenticator-libpam works for sudo controls?

= On Thu, Sep 15, 2022 at 7:01 PM grarpamp <grarpamp@gmail.com> wrote:
On 9/15= /22, Dag-Erling Sm=C3=B8rgrav <des@des.no> wrote:
> I will be removing OPIE from the main branch within the next few days.=
> It has long outlived its usefulness.=C2=A0 Anyone still using it shoul= d look
> into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).=
> https://reviews.freebsd.org/D36592

At least so long as PAM remains available, OPIE should be
maintained as a PAM option, and be updated.

OPIE is the only PAM that allows printing out the future
secure tokens. Old school, secure, it just works.

HOTP requires hardware, TOTP requires time,
neither are printable, both of those require some other
[hackable] hw/sw device that costs $$$ money, and
those devices all have different threat/failure/admin models
than simple paper.

If people don't like...
- The hash algo, a volunteer committer can update it to sha256.
- The list of words, a volunteer committer can update it to
read from a list of admin supplied words in:
/etc/opie_words.txt
- The number of words, a volunteer committer can add an
option to the config for that.
- The writeable state breaking in a read-only root, a volunteer
committer can add a config option to point that elsewhere.
- The randomness, a volunteer committer can update it
to modern randomness.

And if people still don't like it, then commit those simple updates, and push it out to ports, instead of killing users use of it.

--00000000000012c19505e8bfa5be-- From nobody Thu Sep 15 23:38:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTDDS5yNsz4cjNY; Thu, 15 Sep 2022 23:38:48 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [IPv6:2a01:4f9:c011:3eaf::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTDDQ4L09z46Rd; Thu, 15 Sep 2022 23:38:46 +0000 (UTC) (envelope-from des@des.no) Received: from ltc.des.no (unknown [84.211.31.80]) by smtp.des.no (Postfix) with ESMTPSA id A302D26161; Thu, 15 Sep 2022 23:38:35 +0000 (UTC) Received: by ltc.des.no (Postfix, from userid 1001) id 435B4924D4; Fri, 16 Sep 2022 01:38:35 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: grarpamp Cc: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: Re: Putting OPIE to rest In-Reply-To: (grarpamp@gmail.com's message of "Thu, 15 Sep 2022 19:00:32 -0400") References: <86h718sqdx.fsf@ltc.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (berkeley-unix) Date: Fri, 16 Sep 2022 01:38:35 +0200 Message-ID: <86czbwryx0.fsf@ltc.des.no> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MTDDQ4L09z46Rd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of des@des.no designates 2a01:4f9:c011:3eaf::2 as permitted sender) smtp.mailfrom=des@des.no X-Spamd-Result: default: False [-2.67 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_MIXED_CHARSET(0.62)[subject]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; ASN(0.00)[asn:24940, ipnet:2a01:4f9::/32, country:DE]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[des]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[des.no]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N grarpamp writes: > OPIE is the only PAM that allows printing out the future > secure tokens. Old school, secure, it just works. > > HOTP requires hardware, TOTP requires time, > neither are printable, both of those require some other > [hackable] hw/sw device that costs $$$ money, and > those devices all have different threat/failure/admin models > than simple paper. Neither HOTP nor TOTP require dedicated devices. HOTP codes are sequential and can be pre-generated and printed if that's what you prefer. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From nobody Fri Sep 16 07:24:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTQYV6QyYz4bl1V; Fri, 16 Sep 2022 07:24:14 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTQYV30gTz3kdR; Fri, 16 Sep 2022 07:24:14 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-pj1-x1031.google.com with SMTP id n23-20020a17090a091700b00202a51cc78bso18533367pjn.2; Fri, 16 Sep 2022 00:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=RkHJr/JsSHuvG4JHqXt/aWmV2ukBp5endp7nhKWeSms=; b=lMB3N0tW+3Hv3A1LsjRTcxVuTwhBkA3IhlJAyPYmRIl6JNA1Ls5pWg/lxMICKwVdZB srJ1rL6EIOpPNJcbw2hryj7LfYyRCMD9gc01G+Fn4p/KHVIGnwvLdrZPVNGS85+/0vmi n1Jidarx8LKTUPrAixyDQ2lp+cnHppXpvEQAn9+e/+w3ITSAFDDyjkVcvMCc/6ky8x6H nLny+WGSdfEyqt1bHBAU+lL+byt+rFqexPmM42XZ9C/X9You3GuJaHjYqM3X+MLRe3eP eaVTYkE3QQxt5nrpaP8MQtCrfHkefA2GrgZGcT4aJeEpRuBZuesvDpxAeG/a7uoKtcvQ cPsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=RkHJr/JsSHuvG4JHqXt/aWmV2ukBp5endp7nhKWeSms=; b=rQp6TpSewEo0myjab+YH/fIKZdd+7AeooA8nbJAPwkv78phkxMsLPgpQaLQYbwe8K6 Q3MFziD1baB9eRRRudPAhZlO1aLiT7Y4wAlDVyfaNrhm6L67VxHzKT4MV72F8k1u50f+ 5ASxdKnn8jxxQ0qsZjpMCVSL980N/E6aEZXHQgyLYVrO3I9N2ezl2YQx4xTpm80bParm ZFPwmcwuNvpV6qDfmLm5io1yg6Oo4igQ+Slp6kl+VC5RXjoPC3qo5CFwtKX3CKbwk+/o /IzwOLy2ClhwDzmeCQvpgpY5MbY0IhsTtK6ucU2PsquWOFiMBYIicSOpWhzav2ZknEC6 f4mA== X-Gm-Message-State: ACrzQf39J3CtZgeEhx8IO8tO+nMQrk1Sg2/pHZp8rY7efHjNDuQkmjop i09JToAnm4LF0OnemouIvnwBuCRV++DN9//h1O115EFDyK0= X-Google-Smtp-Source: AMsMyM7RfGaGi7vaHjEkx3LfoB6FCNdc/070tTTLoOA+4MREkemKZd8PVjXnuzcMEDWMEUAFMvDL6aEJbiqNrfNOXUk= X-Received: by 2002:a17:90b:1d8b:b0:200:5367:5ecd with SMTP id pf11-20020a17090b1d8b00b0020053675ecdmr14969072pjb.165.1663313052799; Fri, 16 Sep 2022 00:24:12 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:7022:249f:b0:45:6892:6b88 with HTTP; Fri, 16 Sep 2022 00:24:11 -0700 (PDT) From: Luna Jernberg Date: Fri, 16 Sep 2022 09:24:11 +0200 Message-ID: Subject: FreeBSD Dev Summit Day 2 at EuroBSDCON 2022 in Vienna To: freebsd-hackers , freebsd-advocacy@freebsd.org, freebsd-women , devsummit@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MTQYV30gTz3kdR X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=lMB3N0tW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::1031 as permitted sender) smtp.mailfrom=droidbittin@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-advocacy@freebsd.org,freebsd-women@freebsd.org,devsummit@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Hello Day #2 of the FreeBSD Dev Summit in Vienna: https://wiki.freebsd.org/DevSummit/202209 is being streamed currently: https://bsdtv-hls.secdn.net/bsdtv-channel/play/input_track1.smil/playlist.m3u8 also the talks from the conference will be streamed tommorow and on Sunday http://2022.eurobsdcon.org/program From nobody Fri Sep 16 09:11:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTSx54yqPz4c5fL; Fri, 16 Sep 2022 09:11:21 +0000 (UTC) (envelope-from uhrerq@gmail.com) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTSx46cFSz3y9l; Fri, 16 Sep 2022 09:11:20 +0000 (UTC) (envelope-from uhrerq@gmail.com) Received: by mail-qk1-x735.google.com with SMTP id s9so12972448qkg.4; Fri, 16 Sep 2022 02:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=MLjQqL7R4ih4HZ5volM4HTgbs8O0P6fCbPFvyoNfe80=; b=TJc6rfmc2PzOfijurOEKZRy8iM4YyHriSYQOKR9yj/wzkUkOwUpnNNrC6I6r/iki8n 1qjXOoMjozgOcD9w8cZN0lX8xfdRIIWY46m5ihOjFdNoRtDgNb16AmjtSvwWxS9clzIr A48HVyUIGrdy0e2OSD7buV+UR9gU35wLyOn4nJ7FRfasbyrnageajN5PUh4+VFwFWQHm RvYJWTj+GuLj/6Bc3LH9D0hvs1bqDxy2DtqYH1TRz6dlF+WV+IZZ7hUzhmO4A6mOrXGC lx1BhglpKhVdmNCjePa2G0KaawFawmQaM++ApLtAFu+8HG+DnOUaJ9zqXs23GZbxjSGa AHAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=MLjQqL7R4ih4HZ5volM4HTgbs8O0P6fCbPFvyoNfe80=; b=QYZ+QKamg5df7ocSIzlodq26hHvzJXiz5fI+TmtoNnHn9MOdHD3blKyVLwLwKZCy8g MMb0Oaidlku9OBqsd1Jl+6aVd+PT1zo15Mbtck+Ja1+WLHejR61No5bVw/SeQlPtjsd8 nFvNAYHLUs/2KKH+S7QX9e1Keo5F1rCApujag7AoY/+/FwCTFzwXAvMxqnMDMjRdJn9H GIwk3KpHatNHXLktdAzIFM6Ium36gghlqKZ9zk1h+rx7RzoXDLgwoxouAVEBWNLvfZOr 5q0C/jIkmZKDdvjpA0vZ+/DMUvj2J81juY1YD3XM77mbpsejkapIh6iWdBfFvuLbTKr+ p+dQ== X-Gm-Message-State: ACrzQf1pNGeOm4HMGY8LawYC6nsPORKqAqDwJHAdxteZWOGUz1gaS1z3 szXXvwSyb6glrzGN//JKXf7OC62RN0I9y+vjyW8= X-Google-Smtp-Source: AMsMyM6ky3DcFQw1LtHZTcmJy247KxfiyrvCX2lXd9jxr7bcKBAfrqzNBeW7mrEKrGaMZkdUYRogzN8k7o2ESY4hq7U= X-Received: by 2002:a37:4246:0:b0:6cd:e5b5:aefe with SMTP id p67-20020a374246000000b006cde5b5aefemr3086588qka.546.1663319480307; Fri, 16 Sep 2022 02:11:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ethan Xia Date: Fri, 16 Sep 2022 17:11:06 +0800 Message-ID: Subject: Re: FreeBSD Dev Summit Day 2 at EuroBSDCON 2022 in Vienna To: Luna Jernberg Cc: freebsd-hackers , freebsd-advocacy@freebsd.org, freebsd-women , devsummit@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c5996905e8c7be81" X-Rspamd-Queue-Id: 4MTSx46cFSz3y9l X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=TJc6rfmc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of uhrerq@gmail.com designates 2607:f8b0:4864:20::735 as permitted sender) smtp.mailfrom=uhrerq@gmail.com X-Spamd-Result: default: False [-3.24 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.63)[-0.633]; NEURAL_HAM_SHORT(-0.61)[-0.606]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-advocacy@freebsd.org,freebsd-women@freebsd.org,devsummit@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000c5996905e8c7be81 Content-Type: text/plain; charset="UTF-8" Thanks for sharing! Regards, Ethan On Fri, Sep 16, 2022 at 3:24 PM Luna Jernberg wrote: > Hello > > Day #2 of the FreeBSD Dev Summit in Vienna: > https://wiki.freebsd.org/DevSummit/202209 is being streamed currently: > > https://bsdtv-hls.secdn.net/bsdtv-channel/play/input_track1.smil/playlist.m3u8 > also the talks from the conference will be streamed tommorow and on > Sunday http://2022.eurobsdcon.org/program > > --000000000000c5996905e8c7be81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for sharing!=C2=A0

Regards,=C2= =A0

Ethan

On Fri, Sep 16, 2022 at 3:24 PM Lun= a Jernberg <droidbittin@gmail.c= om> wrote:
https://wiki.freebsd.org/DevSummit/202209 is being stre= amed currently:
https://bsdtv-hls.secd= n.net/bsdtv-channel/play/input_track1.smil/playlist.m3u8
also the talks from the conference will be streamed tommorow and on
Sunday http://2022.eurobsdcon.org/program

--000000000000c5996905e8c7be81-- From nobody Fri Sep 16 09:13:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTSzN2Mk6z4c6R3; Fri, 16 Sep 2022 09:13:20 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTSzM5qJGz406c; Fri, 16 Sep 2022 09:13:19 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: by mail-pf1-x42f.google.com with SMTP id u132so20643572pfc.6; Fri, 16 Sep 2022 02:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date; bh=pr4EtNE/K+fQts7UD2mJtB+XiNWVMEzHCWYaovvyKSY=; b=fyE78Jx7Fu172g/lAWdh10SBUzyVY5GfWdenHreyhskq6zHPiiTqVXbQqZ/Mxom/aP hLe0gPcmfktFtj4OhlG41BC/5NEeMiUhrmoZHFaWf8Lx6UVEaff76m4sT2JoyMl2DZwJ TKc88y4SJhjoC781ONQm0W2CgJk63QnJTqQXM/CiRBUK+ZE/bW6sfYdGb7QBq2Q3vVx6 7rwsAwpPV1Zxe+zcCmkrWIaXqC3ZeAHLhaQpbGCmkU3hREoXsKaBtr+1hfrfSIhYo552 Nt88Nv6nfL+Biid4Zwv6AsLlQSMktMOZeo0siSmFA0drtzkvBoNKpF4GrdE3sYLakNsU hdwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=pr4EtNE/K+fQts7UD2mJtB+XiNWVMEzHCWYaovvyKSY=; b=eHaApPmSp2Lw5lIDlpQHvmQbufZFzpL70+gHl6kEDhFop3ri2pbvtBEB2fw26Z3f2U A29g2xLoNKS3nSKEVPscirhhNygXbnN8fZTv4TqOLMNKmKWiPEaAlQNbIHcZ0zhVC4Nv NhvPgC7hmi0G+eDrto6rYk6vLWKhI8nKENKR0fiVY4ZxupC1C/g7tqSOpWF9i/kJv4Zu BtwMjgQCiubeBd33x+UvPNw394nlEjgxLT/xNZc64FFOoZpq+X6R6fuAwOil8xnV12mI UZg2cJK9x7BFo7swDMhH8GazaLEwcCSCt8SLclCNsppxFHvb3ObRLKylaIJKu1nCIlNI J3PA== X-Gm-Message-State: ACrzQf06PVmvyjUXyr2Fy6lQjhuFtYOdrw9EEcaSY/Khq6ebT8owxxqE E/U3dpBjQ3nDF6NUYoVx1eXd0wVCsM19Ih04D4ZjAPPYTXQ= X-Google-Smtp-Source: AMsMyM4wdMAPiJrUOfoegRWBO4WwYB+WXXxyWcpu3BzIwkhpEXHhcuS/FWiLtfBTUka4D5l/AvNmTMfty7/dKWWHgJ0= X-Received: by 2002:a05:6a00:1484:b0:547:89e:272c with SMTP id v4-20020a056a00148400b00547089e272cmr3924229pfu.0.1663319598277; Fri, 16 Sep 2022 02:13:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a05:7022:249f:b0:45:6892:6b88 with HTTP; Fri, 16 Sep 2022 02:13:17 -0700 (PDT) In-Reply-To: References: From: Luna Jernberg Date: Fri, 16 Sep 2022 11:13:17 +0200 Message-ID: Subject: Re: FreeBSD Dev Summit Day 2 at EuroBSDCON 2022 in Vienna To: freebsd-hackers , freebsd-advocacy@freebsd.org, freebsd-women , devsummit@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MTSzM5qJGz406c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fyE78Jx7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::42f as permitted sender) smtp.mailfrom=droidbittin@gmail.com X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.65)[-0.651]; NEURAL_HAM_SHORT(-0.54)[-0.542]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-advocacy@freebsd.org,freebsd-women@freebsd.org,devsummit@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42f:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N New link: https://bsdtv-player.secdn.net/theatre/c726dda9-ffb0-4afa-bf71-55cfc9ab7b67 On 9/16/22, Luna Jernberg wrote: > Hello > > Day #2 of the FreeBSD Dev Summit in Vienna: > https://wiki.freebsd.org/DevSummit/202209 is being streamed currently: > https://bsdtv-hls.secdn.net/bsdtv-channel/play/input_track1.smil/playlist.m3u8 > also the talks from the conference will be streamed tommorow and on > Sunday http://2022.eurobsdcon.org/program > From nobody Fri Sep 16 17:46:25 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MThMc3CYWz4cgsg; Fri, 16 Sep 2022 17:46:36 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MThMb5lqwz42qc; Fri, 16 Sep 2022 17:46:35 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-3321c2a8d4cso268566537b3.5; Fri, 16 Sep 2022 10:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=zwtq5yeA+nU4ulxspYZSesH3qS3nTTO92BYtD/QCM/g=; b=NgSMybG3fQRBFqtlvDgImHITueYcKbLqXdi9g82NhSY6GsbLVvPCSitaKLoHanh40l 46znCljEhVDNo3ISosw1S3CwncqF5T5URgIKhBdke/LoeswQ5lwXCh1lbfM7LkiM6ylL CiGazY4V8AVCdxIzHrJF5D0xeAfk5/q37/os02ryhXqEIVlQEZaxKVZrHiy00lRtQiww tLbSeG/x9YCEe0Pz1SbnGZqYgwV3Q3N0coqKUO0FB/NFyOiMAstI77TEutTVUwmtMGFk wyNBVwZJg0abF63/oGl03hNft9BnHxGJ9+B+X7IEJRn7dciZGaQnIxuXOi6JxkV1VmKf dR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=zwtq5yeA+nU4ulxspYZSesH3qS3nTTO92BYtD/QCM/g=; b=dpI5sz7+jNIDyVss2sR3QvorwnT+qn9R4aUx1MTHobDnGCGhrnaMNwTWnmk8Hr4H8D 4115HAK9vSC5gNh735rbOYTbWWXTpL1a6ubcGJ88oi+LKOHUnU+yURIXgvg69uaRWZ1M uHT2W4qVuqfgEyc3V3uxJI6+gv1NcrH829Bf9Qd0MEocvkjL8bger9vqGvr5xJPcORqM bHlL/Ln9QSS/z9sbWAf/2c7+/QohKz0CN/r4KlGPkoWZd0/UDvPfCLg/nLUpfngF6Mio LYRNoIcsEBbcoODQJubuuTWOGF7qGCWdlUz63lI6eAdWv0STA/J0tZOFr2uzrkqvUE7T 0Iuw== X-Gm-Message-State: ACrzQf3Tw7sjsOmmPv2a4nGdB0MTEN0ogiaajVbDFWVZJZnlWT21hh7Q DB2/DskHmSDK4EVxpjeLhq6twug76Tem+cM3kbSMsGUW X-Google-Smtp-Source: AMsMyM6CV985tnpYbYmeJratGe8px1tpb5is3vN2AOJe1oJAclas8sAmNq3noKs7Z5MLDzPalrj0nKCkHc/OOtGa86c= X-Received: by 2002:a0d:cf83:0:b0:349:8534:589c with SMTP id r125-20020a0dcf83000000b003498534589cmr5229107ywd.356.1663350394728; Fri, 16 Sep 2022 10:46:34 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <86h718sqdx.fsf@ltc.des.no> In-Reply-To: From: Joe Schaefer Date: Fri, 16 Sep 2022 13:46:25 -0400 Message-ID: Subject: Re: Putting OPIE to rest To: grarpamp Cc: des@des.no, freebsd-current@freebsd.org, freebsd-hackers , freebsd-security@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006a347405e8cef1f6" X-Rspamd-Queue-Id: 4MThMb5lqwz42qc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=NgSMybG3; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of joesuf4@gmail.com designates 2607:f8b0:4864:20::1133 as permitted sender) smtp.mailfrom=joesuf4@gmail.com X-Spamd-Result: default: False [-3.83 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_LONG(-0.96)[-0.958]; NEURAL_HAM_MEDIUM(-0.88)[-0.879]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1133:from]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org,freebsd-security@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --0000000000006a347405e8cef1f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Answering my own question: yes it can, but there's no "challenge" string for TOTP nor HOTP. If you want sha-1 in an "opie" framework, check out https://github.com/SunStarSys/orthrus On Thu, Sep 15, 2022 at 7:31 PM Joe Schaefer wrote: > google-authenticator-libpam works for sudo controls? > > On Thu, Sep 15, 2022 at 7:01 PM grarpamp wrote: > >> On 9/15/22, Dag-Erling Sm=C3=B8rgrav wrote: >> > I will be removing OPIE from the main branch within the next few days. >> > It has long outlived its usefulness. Anyone still using it should loo= k >> > into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator). >> > https://reviews.freebsd.org/D36592 >> >> At least so long as PAM remains available, OPIE should be >> maintained as a PAM option, and be updated. >> >> OPIE is the only PAM that allows printing out the future >> secure tokens. Old school, secure, it just works. >> >> HOTP requires hardware, TOTP requires time, >> neither are printable, both of those require some other >> [hackable] hw/sw device that costs $$$ money, and >> those devices all have different threat/failure/admin models >> than simple paper. >> >> If people don't like... >> - The hash algo, a volunteer committer can update it to sha256. >> - The list of words, a volunteer committer can update it to >> read from a list of admin supplied words in: >> /etc/opie_words.txt >> - The number of words, a volunteer committer can add an >> option to the config for that. >> - The writeable state breaking in a read-only root, a volunteer >> committer can add a config option to point that elsewhere. >> - The randomness, a volunteer committer can update it >> to modern randomness. >> >> And if people still don't like it, then commit those simple updates, >> and push it out to ports, instead of killing users use of it. >> >> --0000000000006a347405e8cef1f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Answering my own question: yes it can, but there's no = "challenge" string for TOTP nor HOTP.
If you want sha-1 in an= "opie" framework, check out https://github.com/SunStarSys/orthrus


On Thu, Sep 15, 2022 at 7:31 PM Joe Schaefer <joesuf4@gmail.com> wrote:
google-authenticator-libpam = works for sudo controls?

On Thu, Sep 15, 2022 at 7:01 PM grarpamp <= grarpamp@gmail.com<= /a>> wrote:
O= n 9/15/22, Dag-Erling Sm=C3=B8rgrav <des@des.no> wrote:
> I will be removing OPIE from the main branch within the next few days.=
> It has long outlived its usefulness.=C2=A0 Anyone still using it shoul= d look
> into OATH HOTP / TOTP instead (cf. security/pam_google_authenticator).=
> https://reviews.freebsd.org/D36592

At least so long as PAM remains available, OPIE should be
maintained as a PAM option, and be updated.

OPIE is the only PAM that allows printing out the future
secure tokens. Old school, secure, it just works.

HOTP requires hardware, TOTP requires time,
neither are printable, both of those require some other
[hackable] hw/sw device that costs $$$ money, and
those devices all have different threat/failure/admin models
than simple paper.

If people don't like...
- The hash algo, a volunteer committer can update it to sha256.
- The list of words, a volunteer committer can update it to
read from a list of admin supplied words in:
/etc/opie_words.txt
- The number of words, a volunteer committer can add an
option to the config for that.
- The writeable state breaking in a read-only root, a volunteer
committer can add a config option to point that elsewhere.
- The randomness, a volunteer committer can update it
to modern randomness.

And if people still don't like it, then commit those simple updates, and push it out to ports, instead of killing users use of it.

--0000000000006a347405e8cef1f6-- From nobody Fri Sep 16 21:31:45 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MTnMW6XGvz4c6QN for ; Fri, 16 Sep 2022 21:31:51 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MTnMV6l5fz3dFh for ; Fri, 16 Sep 2022 21:31:50 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: by mail-pj1-x1031.google.com with SMTP id n23-20020a17090a091700b00202a51cc78bso972910pjn.2 for ; Fri, 16 Sep 2022 14:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date; bh=DwP4R01mEzgmgKuNPSXWPXEQDO4z1aCfCtJF9GU1z2Y=; b=BuFMy57+DC5nAEPRg/PbIN0T3Z1OWDmMPm6/6E9FyZjDS1M0jHDpRbhM9HoQnQQeUc Tx8+W7pT/37Z53pT633uCRGXbbOZxdAFdi5EohdUP7cnymHT9nX9QQWbfJXghGfHZIJ7 +7OUiMmd/FsqoZme8ck614ay8CsCen93heN5viZKLIdephA4mh809vkFUlnuZE+jFL2E 4hF/51aft1put35LJt6sSIc/dKA+SJwwTugqYGJzmy3PNm6YpiVHle4B+JVbJkegKgOG sn4MX2ff5cMWJmY+4rXXC+FhGXQ+MvYvk5mDVZZww7YNJ7aYzSdVksC4bfT5c0CxbVcT Hmqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date; bh=DwP4R01mEzgmgKuNPSXWPXEQDO4z1aCfCtJF9GU1z2Y=; b=ojpmXyn4eni/Ak4/QrPt8nJbnKVpY1rXDGhY+fTUPiAeKo0zl+k/GnIerNQEwFpUxR yMsZOC3ZhOPOH0lZtHIBkt54n/z9tZ5omTiFlJCeCOpAin1E0WNbyEIlXS3d+8cFP9Bm dNlJ7Dugpp5RPZ8VT6LEuSnawax9gu/8lRvb979IZmQUW4eHyQJEq3VSol8HRr2u1gQZ zclrQ0fK1WTS8wM5cHvoxD3UIAlB4o3Yn7SiF+kWrewV6A+vhEz3nLaRFPxjInPeMU08 JjjHIF4+kJeEvkjr+KzT8rZC8FKAjVzFh8HaUJTZessuWcwjRcPmVLjP0GlUVpzoQTJ6 e1HA== X-Gm-Message-State: ACrzQf3pq9pFmfqzXxo22f2wmZMMcfuoOodRQAxeScTPNyXWlei196Zm PLrC53BsJj4NZXO/7bwDQpYPYgHzyzbyzGu4cK8= X-Google-Smtp-Source: AMsMyM4f927Yf3/HNH9cr2qD7BxIkneUtP+gSgM8dcHCmzqpRLKcHu/+PN22PepWksYubsxLxeAokA== X-Received: by 2002:a17:903:18a:b0:178:3ad0:2689 with SMTP id z10-20020a170903018a00b001783ad02689mr1773041plg.20.1663363909464; Fri, 16 Sep 2022 14:31:49 -0700 (PDT) Received: from smtpclient.apple ([2600:1700:5430:10b1:a154:1458:2987:31df]) by smtp.gmail.com with ESMTPSA id q18-20020a170902dad200b001782aee4881sm12524586plx.153.2022.09.16.14.31.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2022 14:31:48 -0700 (PDT) From: Christopher Bowman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Controller timeout in SDHCI Message-Id: <6F53CEFE-E4CC-452B-A64C-F312A550C40F@chrisbowman.com> Date: Fri, 16 Sep 2022 14:31:45 -0700 To: hackers@freebsd.org X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MTnMV6l5fz3dFh X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chrisbowman-com.20210112.gappssmtp.com header.s=20210112 header.b=BuFMy57+; dmarc=none; spf=none (mx1.freebsd.org: domain of crb@chrisbowman.com has no SPF policy when checking 2607:f8b0:4864:20::1031) smtp.mailfrom=crb@chrisbowman.com X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[chrisbowman-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1031:from]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[chrisbowman-com.20210112.gappssmtp.com:+]; DMARC_NA(0.00)[chrisbowman.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I am working on a Xilinx ZYNQ (ARM cortex A9) based board. I have a = 13.0 setup working but my freshly build 13.1 doesn=E2=80=99t boot. Upon boot while probing and attaching devices I get the following = message which=20 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0202 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This whole section repeats and the only register which seems to change = is the Sys addr which goes to 0. I imagine that the interrupt which signals a completion of a SDHCI read = is probably not getting back to the driver and thus the timeout triggers = but I=E2=80=99m not sure. I believe the FDT for the working and 13.0 and the failing 13.1 are = identical. If anyone has any suggestions as to where to start looking that would be = greatly appreciated. Regards, Christopher= From nobody Sat Sep 17 11:42:59 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MV8Ff4kvkz4cX0Z for ; Sat, 17 Sep 2022 11:43:02 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MV8Ff4Cq9z40x4; Sat, 17 Sep 2022 11:43:02 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663414982; h=from:from:reply-to:subject:subject:date:date: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=apvk4+MXXuoJMnt5fKFfW26PRGcm5LjviNdnRZ6nebI=; b=GtMLbL27zIAAzwzhA4dy8DSrUVXY5b2ZygSpce9+tEfEmlx2yrw5ILzkuvChzlImNzfgl7 TDRiYg086FoKsIPX3tHmmmajgppf39GkDYRxX93VsaUUeHJNd63L48rGAqK3jshxvVheyY OYwhlP2wqUX2/riqTyter8ArXx3NQg7viUMk2/xg9duqk6Z1uWShwofQa3SEkij0fcm+g3 9TheDt/2NLuZhrOLov1zZOu988UgeBaW5rgvxcCnHE7RasrfqGtoKQZloIoS2e4o4YhUWZ GigdwOSrdLk61WWjlouQDV6M8MwzCLUA+PvbapM6LLvzGvVy6W4aCp6YdI5Kbg== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MV8Ff1HsrzvsW; Sat, 17 Sep 2022 11:43:02 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Sat, 17 Sep 2022 12:42:59 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Simple bugs with image impact for the project... Content-Language: en-GB To: Mason Loring Bliss References: Cc: freebsd-hackers@freebsd.org From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------A8TPVjuAC5Nk0R0RcTcqcIM2" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663414982; h=from:from:reply-to:subject:subject:date:date: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=apvk4+MXXuoJMnt5fKFfW26PRGcm5LjviNdnRZ6nebI=; b=AEYUypWZH2nJ+/WuXLI0S5pdkCUxiosWJUdubyJ0t1otfCXNMrV42qM8EkfiMnIsDBnuXX m0eC1zJPtE/LhgOeRQzW7oFM1WLrWZSLNn4eetaafq0Tfpt2Q3OZ8z0JSLdpW+K/EUJVCX 0MHjx30zwGbdck8DAdrACV5que8Q+cQ/gDgUnnAWwY2g1iDK4ndKnyTRYyFziaZmaTnOvo 4PoUMYaTEeAFSSgkVJFo+TOid/rlf+MBjlmdVwqXcPML6e9B/47Po+CmCxH+gFdsDRmHxZ kYOPTYlqEtXhu4vOiirG7WLr4Wbot1gMDCwxU0uuPIyJMYe5kM7lOtNIZJvDQQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663414982; a=rsa-sha256; cv=none; b=R27QAxK6YsKF1wF8zZRFFvOSmJcW7+5i4nROVD5KcMxvbS4Jbmav797nhxvZEJ3HJWkVEO RMLBPwvIuDTfoCusoNQNiXsi+VHVHVM/8A8F65WybDMvNaOFkb2LcmAAO0gbYGe1peYYYW WUTeGJXIvjkjmpa22sjW4S55lIJCIL1gwqxSFswpK7OIC1rulvaO9fZ7v/NDuVmBiPsRAC okpmHOVRKCXLbNXreCFSKVG9a6KOrk6S9smVMtUaaVXYmW/Y0f0q+KshYqOnsdcrURWxKP yCGN8FMAuK7a4CNKs4Ap1AmzOuoakcP3x6i5z7Mre+BjXUJzbI6y4NNLe5k7gw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------A8TPVjuAC5Nk0R0RcTcqcIM2 Content-Type: multipart/mixed; boundary="------------ACGE0fbSvt27bf9m60l0Ptp2"; protected-headers="v1" From: Graham Perrin To: Mason Loring Bliss Cc: freebsd-hackers@freebsd.org Message-ID: Subject: Re: Simple bugs with image impact for the project... References: In-Reply-To: --------------ACGE0fbSvt27bf9m60l0Ptp2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTAvMDkvMjAyMiAyMjoxMiwgTWFzb24gTG9yaW5nIEJsaXNzIHdyb3RlOg0KDQo+IOKL rw0KPg0KPiBQbGVhc2UgdGFrZSB0aGlzIGFzIGEgZGVzaXJlIHRvIHVuZGVyc3RhbmQgdGhl IGN1cnJlbnQgc3RhdGUgYW5kIHRvIHNlZQ0KPiBwcm9jZXNzIGltcHJvdmVtZW50LCBub3Qg YXMgYSBjb21wbGFpbnQgYWJvdXQgdm9sdW50ZWVycyBub3QgZG9pbmcgd29yayBvbg0KPiBh IHNjaGVkdWxlLiAoVGhhdCBzYWlkLCBJJ2Qgdm9sdW50ZWVyIGlmIHRoYXQnZCBtYWtlIGl0 IGhhcHBlbi4g4ouvDQoNCg0KVGhhdCdzIGtpbmQgOi0pDQoNCkZZSSwgDQo8aHR0cHM6Ly9n aXRodWIuY29tL2ZyZWVic2QvZnJlZWJzZC1kb2MvY29tbWl0LzlkNTk1MTQwNGU0MjU3MjVh ODQyNjUxMTNhYmVmMWMzYjJlODZkOTE+IA0KcmVtb3ZlZCB0aGUgZGVhZCAxMy4wIHNlY3Rp b24gZnJvbSBHZXQgRnJlZUJTRCANCjxodHRwczovL3d3dy5mcmVlYnNkLm9yZy93aGVyZS8+ LiBGb3IgdGhlIHJlbWFpbmRlciBvZiB0aGUgcGFnZSwgDQo8aHR0cHM6Ly9yZXZpZXdzLmZy ZWVic2Qub3JnL0QzNjUyMz4gYXdhaXRzIHJldmlldy4NCg0KVGhlIDEzLjAgZGVhZHdvb2Qg aW4gdGhlIHNpZGViYXIgYXQgdGhhdCBwYWdlLCBhbmQgb3RoZXJzLCBtaWdodCBiZSBsZXNz IA0KcHJvbWluZW50LCBzdGlsbCwgSSdkIGxpa2UgdG8gY29ycmVjdCB0aGlzIChhbmQgYWRk IDE0LjApIGJlZm9yZSB0b28gDQpsb25nLiA8aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1 Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNjYxNjc+DQoNCkcNCg0K --------------ACGE0fbSvt27bf9m60l0Ptp2-- --------------A8TPVjuAC5Nk0R0RcTcqcIM2 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmMlssQFAwAAAAAACgkQt2dIb0oY1AsE ehAAhqeixSbSgHUU/gLtpnHdZQKDNZ5BtzCxSbfhp4aH2hYwlQZYmYB9MpgY9PnjXpdKT5m626lH N81tp3ICgDHcOSWGBHxVYjrwDgHIaNBRDXPaQWcWZDPaNTSlpeYrQYwG4bsjVwu71qLzdB1l65L4 4ZTrbW/Gg3w4zs+I/v+rRQTE1wwyIf5Q/c8U9lSYQ4rst9DNvglms/0tzrcosQDyt6TR4uF6D4nT 0LLkQ0MgFbWQZTrGZSu27RDkkyYt4ih+E0FbVe2Z6kOHoFqQ9dXAS0kT6dUqJtO4rdrlKsXU4PxE F5xfY5mOFzsG00u+1KocaaEp52tug2s5162vxkMu8h33s9NOKovUHlfapFjNSBe6hss57wX16biz gJ6wIUhXcIAr+wdufmQbl+5bYhFujYMdFWm0AyVBMGWSXqXeX3w2XwStapA5sbtUfmqWOu+LTsvL 72Mot68zEXExnWbfDx8Clp0222CgajaoJx96K4qaTt7hSv9H/QKLRPcIDIlZGSjsHC1V9kSSljON XfhYv52PRJxCljbGcc4/VWT9XtXOoERhWlqzbDW4e3hAdodwn4P0M/isIZ3yucm8s7nAMD7HU4Y6 6G5CV7QXtKJEP31LAc8f8tTThygyMRXQGlEdmXbcQXMO+ptTbeWPjR1f5GlSAVNhjYqKV37tVlW8 CQ4= =ITBH -----END PGP SIGNATURE----- --------------A8TPVjuAC5Nk0R0RcTcqcIM2-- From nobody Sat Sep 17 16:35:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MVGlG3v0lz2l1t8 for ; Sat, 17 Sep 2022 16:35:38 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MVGlF37pZz3W88 for ; Sat, 17 Sep 2022 16:35:37 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4MVGl61yWJz6fYm; Sat, 17 Sep 2022 18:35:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1663432527; x= 1665246928; bh=gaRLuHmzY+VYkqjoPBPBjiNql8Nn/4qIALjsehk7tfA=; b=K ccgrV9O6v7OJwlGJtCsH3B+FaRDXQoJsL/9LwipoAE5FSdqz8Bl18EF5iaSxZgV0 boWbSXkyJXKR0y7Mq49hgD/psOCiE+G+JOXEJrMqHaxRWwW2+hN1DUJkPGNTy4JV OR5+k+y8Ydj08sKv0eyNa1Ay+Zqog4NPui9lrTyqIFiJHi2qfa2BXjzj96uUdwDJ NK+sbzNHoY1BFk5A4Pard/+TYrfQozTeeUozwY5inUZs67m15ZZPNva8kQpGag0+ ppNjl45ODg2RoLxXpiiWfIL/4rrLpieX2/XcaRltGpMNYYX5j9qzOLgwM2Z4TrwS loDP/td84qu9LbIDx1FZQ== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id X9A66iasDVYL; Sat, 17 Sep 2022 18:35:27 +0200 (CEST) Message-ID: Date: Sat, 17 Sep 2022 18:35:26 +0200 Subject: Re: Dynamic hostname in rc.conf (for bhyve VMs) To: Tomoaki AOKI Cc: freebsd-hackers@freebsd.org References: <20220911022259.a51af1f585f24af6bfb6d4e4@dec.sakura.ne.jp> Content-Language: en-US From: Guido Falsi In-Reply-To: <20220911022259.a51af1f585f24af6bfb6d4e4@dec.sakura.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MVGlF37pZz3W88 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="K ccgrV9"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.57 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; NEURAL_HAM_LONG(-0.94)[-0.939]; NEURAL_HAM_MEDIUM(-0.65)[-0.646]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 10/09/22 19:22, Tomoaki AOKI wrote: > On Sat, 10 Sep 2022 10:52:01 +0200 > Guido Falsi wrote: > >> Hi, >> >> Since rc.conf is just a shell script I'd like to be able to set hostname >> dynamically. >> >> This is bhyve related because what I'd like to do is pass an hostname to >> VMs via the -e option to bhyveload(8), and then read it in rc.conf, >> maybe via sysctl to set the hostname accordingly. >> >> By the way I'm using vm-bhyve [1] to manage my VMs. its configuration >> files are also shell scripts, so I was planning to hack some simple >> logic there, host side, to derive the hostname from filesystem (useful >> for cloned VMs). >> >> Could not find any example or documentation about any step of this. >> >> Is this even possible with current tools? I'm open to hacky solutions to >> start with, then maybe refine them. >> >> >> I'm trying to do this because I'm using a local dnsmasq that exposes DNS >> with the hostnames provided by VMs, but clones get the same naem as the >> machien they're cloned from and mask those in this small internal DNS. >> If each clone could provide it's different name it would be much better. >> >> >> Thanks in advance for any help/suggestions. >> >> >> [1] https://github.com/churchers/vm-bhyve >> >> -- >> Guido Falsi >> > > IIUC, and if you obtain IP addresses of each VMs via DHCP, > just keeping hostname on rc.conf would be suffice. > > /etc/rc.d/hostname has a functionality to get hostname by > hostname=`/bin/kenv dhcp.host-name`, meaning hostname is set using > what DHCP server supplied, if NOT in a jail. > > See the script for details. > Hi! Sorry for the delay in replying. Thanks for your suggestion of using kenv, I completely overlooked that! It was the missing piece for me. In fact my basic idea almost works perfectly once I use kenv to read variables passed by bhyveload. Only problem is that the vm configuration file used bu vm-bhyve is not a shell script but treated as a key pair. So i can't do logic in there. I ended up creating a very simple local patch to vm-bhyve here that does what I need: https://github.com/madpilot78/vm-bhyve/tree/bhyveload_pass_vm_hostname I think I will propose the patch upstream too, maybe with some cleanup. So thanks again! -- Guido Falsi From nobody Sat Sep 17 19:42:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MVLtX5y0Vz4cDBv; Sat, 17 Sep 2022 19:42:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MVLtW6cczz3r6f; Sat, 17 Sep 2022 19:42:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4MVLtV1qsxz6dbZ; Sat, 17 Sep 2022 21:42:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :subject:subject:from:from:content-language:references:date:date :message-id:received; s=bjowvop61wgh; t=1663443728; x= 1665258129; bh=gKy4YWUcWwrpjK37K0H04lwyOrEJX2CM6uhFVvamRd0=; b=h dY89X/DEfrSGupgKDom5XOi2PW9NiHR1pMgHLaw+Kp+as4QV2+4ArxK3g4424yr1 Hzi+HvEZsQQUqf4zfAt360HPDrH2xSJ/F+nnTM+BYOVphjGyYo71pqwQ+VRm60pJ HwqqbgHkuVxNPH1O93Cs9AbB52AsL2fonmpASLFYir/ZVhlx53cwcem4FabDmNPf NGiPfm1aZwI9LAetI1ioYKQf978YWifFPR4ePmSS3Hd/stGU726dAotskUR9fjJs EKNuP3DZKp30kWVCORfpdb2fxuprvpNZPc9rjgKNIr9/NmRr4aqBaYmGZFDnkO6s c2Im62RjJWfN0LY0UqRmA== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id IO32pqeGtppr; Sat, 17 Sep 2022 21:42:08 +0200 (CEST) Message-ID: <1fa4124e-4542-f710-2545-cc8b8a1dea63@madpilot.net> Date: Sat, 17 Sep 2022 21:42:07 +0200 To: John Kennedy Cc: freebsd-hackers@freebsd.org, virtualization@freebsd.org References: Content-Language: en-US From: Guido Falsi Subject: Re: Dynamic hostname in rc.conf (for bhyve VMs) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MVLtW6cczz3r6f X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="h dY89X/"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-1.27 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_LONG(-0.31)[-0.308]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,virtualization@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 17/09/22 21:22, John Kennedy wrote: > On Sat, Sep 10, 2022 at 10:52:01AM +0200, Guido Falsi wrote: >> Since rc.conf is just a shell script I'd like to be able to set hostname >> dynamically. > > AFAIK, not a shell-script (although variables are set in that syntax). I'm sure about this, rc.conf is sourced through the shell. So it is a shell script. You can verify this by checking the load_rc_config() function in /etc/rc.subr which runs (beyond a lot of other things): . /etc/rc.conf I was wrong about vm-bhyve machine configuration file, which is a simple key/value pair file. > > I wasn't trying to do exactly what you are, but one thing I did was set the > MAC address as one of the bhyve options: > > ... > -s 5,virtio-net,tap2,mac=00:01:02:03:04:05 > ... > > (Changed the MAC address in the example, but pick a safe one for your setup) > > Should be able to provide your own rc.d configuration file that does > something like do a switch on MAC and call the hostname script directly. > > I already succeeded by adding "-e bhyve_vm_name=${_name}" (where _name contains the name of the vm) to bhyveload arguments, then reading it with kenv from rc.conf: hostname="$(/bin/kenv bhyve_vm_name).internal.vms" Works like a charm. -- Guido Falsi From nobody Sat Sep 24 00:00:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MZ8KL15kGz4dGb9; Sat, 24 Sep 2022 00:00:06 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MZ8KL0WLgz3rkp; Sat, 24 Sep 2022 00:00:06 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663977606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=Qz8zi/y6oP6137Dhlcgou53SC4vVKWCL9d+q5XvUoB4kI289p5Dl14QBucDgw9Bo6o3lHm xfeAcPy//+dN0D4sSKIVPREA75ZoZ3Gk9ODByAUuxoGhRAoTTMlnw3ezzeBDGR3NOF8l50 Bw3nJhmejPKjLkw2SEkter5LCl5hF21KbZRd3c/FGmQOuvccs/h7Urt3McZxLJhfwL6CbE L3Qy3QN0awXldCaTguIh1ZZJI6tNn6JMmNbYICc+WXcO1qfiYGlXxzsaXThT/wdxWDyeGp J1vOKMeepIHMFRENuuC+fiiXjnFaAcGKEmJKXyjKKn6EHqsH/7P17jrBjTkRFg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id E61284AB6; Sat, 24 Sep 2022 00:00:05 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2022Q3 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org,soc-students@FreeBSD.org,soc-mentors@FreeBSD.org Message-Id: <20220924000005.E61284AB6@freefall.freebsd.org> Date: Sat, 24 Sep 2022 00:00:05 +0000 (UTC) From: Lorenzo Salvadore ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1663977606; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=vngKnMenvFLbydWH7rCyoIyzIeyaZz7Sv4Bsb5kw6N8=; b=EY57eT8hhUNaNydAs1J2lS2y+9LtNXJ3w+lFGfZN3/1E6JwD0RWBgLOO7CvOkXmmGJmjfQ vgr9BD6Q57vxW/dM6AjSdwRblevnw07Nl+a5p3VbvoVpEGL1/6afiSO5BXh5xw/ys8qlIK bml5wSPLDytMeUAjEOQqtojBf4JYcJSkXncT8CDq2iqDx+xY3nZmZBUTWoa6oQe9wdn55E zoI6KeyQB0v8Xe3ZQYNArCTwNlkIs2WfSoTOcusM6NzcgGaHqCRD1eCQ1TXr7e5U65ovKW owHnbgJclhONNsz8keGAy9pC/uqshJlpdrUPXxuCZ3DQsltD9S33tB/yQPwz1Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1663977606; a=rsa-sha256; cv=none; b=xGOz5qm87xoh1NNsBh1RrGJ4HcykSok7lZwotgsC4Jmwf7iJngbQ4w9vMzU53Cfdzww5M6 QriJdPujONSZW9Gp+JxV/QGUg/S/ytufUTXtx4+tIHsy3B5UPVfvqsNHYtQ7OEEr7neOKu BmTjVv7vPshtX/ykwbWffOsu/VddyqlhUep8bD7U/PTZDEm/l5JLTQM2gsRY09jWdhuPwT i5734I4kYsH+ToAh/XGgmSQ8rJhRiXz6sz/bo+ZzCU8ecpLCSPYEzzOdHtCVVRVRUWXvEd IG1xpbWppWvc0jSmQ+haFYD37FH06ehqeRk1c4IIw9eCGxOOLfKkX82h+EweZg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is September, 30th 2022 for work done since the last round of Quarterly Reports: July 2022 - September 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q3 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Tue Sep 27 02:29:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mc3VY2063z4cvCZ for ; Tue, 27 Sep 2022 02:29:41 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mc3VX1cL1z3MTZ for ; Tue, 27 Sep 2022 02:29:40 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id A2DE73200929 for ; Mon, 26 Sep 2022 22:29:38 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Mon, 26 Sep 2022 22:29:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1664245778; x=1664332178; bh=qlK8MpMRjEDcwD/Fk6WzuM9cCs0oKLFoQVh V8/ZEY+g=; b=WWw8OCNrJ0S5USh7yf9+CKFYQdBXgrQvGl0TEMzc+RuRp4hph0O hfYa+wT7XHx5/50piRLWtM339YJ4qik2prfPqBw4zmtRmnRrkKppqeRK+kF6axra ezMjyZRKeJZBn/LAasfbl0yJXUAcvLkrqgzhcZA5ePO3njIiKPgjrHE9DiAG7OOp sn4PcKYILccdnsOgP1KoayNjypSllEELVL7MMyT1NSUKP9VXOBByC+iesQOkGHV/ Pu9+Z4xgiSBtwpkMMRrnadk/J6yX7ZIdWu8nFlJ8AQMt4bnM1mkt0VQLBzPUi0wH DM4QuxOA9APhVwfn3e0vqh/lEDsKC3NhTWQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1664245778; x= 1664332178; bh=qlK8MpMRjEDcwD/Fk6WzuM9cCs0oKLFoQVhV8/ZEY+g=; b=g PZRNzkaANg/tR4pmgd0jtH1STS8q4UDjoBekVgftzMvK/NyKCiO8TGtXxKzNR07x Uuzv5KEFeOUHzsjYFbQK6cC7E0Ki1zEf6nHJaOPwPyFWp3FVM2bmIsvQJcflZYIz h334vhhwydekJslPNNvbs8eFHFDyNDEsDQWqDKXYqyNPPfLRWhzouHhfvxAPaL7r DbNxIupqV0M/mQbzwfelcylSXD0w4QktwjKi0NgyQ3M3v9mdxorPVbmTxm6z9p5o GUWsLBL0IndLVsm3qIb6CaU8IoxlrM9LBiwMUNlNHaladiEXnFR8DyUvfsMRK4NN CD4/YmQmnFvZKKRQ7voOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegfedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeegjeeuieegfedttdfffeffgfdtffefteegfeelteefjedugfehvdelgffhud ekgeenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CFF542A20080; Mon, 26 Sep 2022 22:29:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> Date: Tue, 27 Sep 2022 02:29:16 +0000 From: void To: freebsd-hackers@freebsd.org Subject: poudriere cannot build 12.3R jail on a 13-stable system - cp: [vdso]: No such file or directory Content-Type: text/plain X-Rspamd-Queue-Id: 4Mc3VX1cL1z3MTZ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=WWw8OCNr; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="g PZRNzk"; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.20 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-4.04 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_WWW(0.50)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, On a very recent (amd64) 13-stable system, I try to make an (amd64) 12.3R poudriere jail like so poudriere jail -c -j 123R -J8 -m git+https -v releng/12.3 It fails 'installworld' with the following: 'cp: [vdso]: No such file or directory' A quick ddg search reveals https://lists.freebsd.org/archives/freebsd-current/2022-April/001736.html concerning building 13-stable. But the fix/workaround is to apply a patch and I don't know if that can be done when using the poudriere mechanism to create the jail. How should I proceed? The same host creates 13.1R and 13-stable systems fine. I have not yet tried making a 12.2R or a 12-stable system yet. The output leading up to it follows -------------------------------------------------------------- >>> Install check world -------------------------------------------------------------- --- installworld --- mkdir -p /tmp/install.ELdRMFKz progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp date echo egrep find grep id install ln make mkdir mtree mv pwd_mkdb rm sed services_mkdb sh sort strip sysctl test true uname wc zic tzsetup makewhatis; do if progpath=`which $prog`; then echo $progpath; else echo "Required tool $prog not found in PATH." >&2; exit 1; fi; done); libs=$(ldd -f "%o %p\n" -f "%o %p\n" $progs 2>/dev/null | sort -u | while read line; do $line; if [ "$2 $3" != "not found" ]; then echo $2; else echo "Required library $1 not found." >&2; exit 1; fi; done); cp $libs $progs /tmp/install.ELdRMFKz cp: [vdso]: No such file or directory *** [installworld] Error code 1 make[1]: stopped in /usr/local/poudriere/jails/123R/usr/src 1 error make[1]: stopped in /usr/local/poudriere/jails/123R/usr/src make: stopped in /usr/local/poudriere/jails/123R/usr/src [00:40:22] Error: Failed to 'make installworld' [00:40:22] Error while creating jail, cleaning up. [00:40:22] Removing 123R jail... done [00:40:23] Cleaning 123R data... done TIA, From nobody Tue Sep 27 15:49:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4McPFx2Zqyz4V5rD for ; Tue, 27 Sep 2022 15:49:57 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4McPFw2BbBz3jL9 for ; Tue, 27 Sep 2022 15:49:56 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B4F965C0097 for ; Tue, 27 Sep 2022 11:49:54 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Tue, 27 Sep 2022 11:49:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1664293794; x=1664380194; bh=gobN/l+8Rq o8uEMkjjP5+Ux3U6sKD+tKmXgC9ZUaMHE=; b=cS34iwGIYXVMcmK2NwVIohiHIl 4tCw4z3OlX7Ydw3IukOwyoKkQ7t/TF5qv3/YK+AiQxzzRRMYdQmh737ds0IIMHoe 4enbG9EtT6cawbWfDAx10TLG/zt02Mwi1ts4Bgcwa/DwUW2um3pd1TQRQQUXWcld /MZ3Mg9dAH0Xfjrifi1Jd2MX2xCrxondDgwQK88KG10gNMW8ubssKD6gMuq9hJov FDGDjvqS1VXHRx+d/35yXaYQ1IF4alCm5d6nsn53bQTfNpwbcwsz+XS0wxSGTBjr S+vMxeFcvhiOiK/PN39sVH8kqjDjJVNHcwiy9upO8Unbs6pJ+4A1NBeJZYEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1664293794; x=1664380194; bh=gobN/l+8Rqo8uEMkjjP5+Ux3U6sK D+tKmXgC9ZUaMHE=; b=Q0eEdVodG63NWHRwR3sFbRUjMvej1/foiTbPqfdNPSyu iYkpnVF6hkfc6L1C5WuH85tHn7rXQxGUsF2ELU2+fU19BDeWd7QlRyYU3h7YQA3u zIYmZtf6WX9me6u8kk8Ds4H2PPEKoQj+Q3Y6OhNAatf66sGCbmYiG2YTZ1vK+ANh eSdSPMHL5zkMAJz87rV6SaB1XXVnDp+XOJS342R3PNjKO39I2Kpw0V/O1CkgI5vw //ng1izRbpXLeaPMVf89l1pgjlkMYld0LpEKJMgmtGjtn91Tqh0AqJ6ljYH0vN95 3la3Kr1+WE3gUX8jfWKUObSMCXQ57QiK/85SqOTtxw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegiedgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeeitedvueehtdehtddvhfeuhfevhedvieelvdeiffehveelheegfedule ejudekvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82C502A20079; Tue, 27 Sep 2022 11:49:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: In-Reply-To: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> References: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> Date: Tue, 27 Sep 2022 15:49:34 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: poudriere cannot build 12.3R jail on a 13-stable system - cp: [vdso]: No such file or directory Content-Type: text/plain X-Rspamd-Queue-Id: 4McPFw2BbBz3jL9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=cS34iwGI; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=Q0eEdVod; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-4.05 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.957]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_WWW(0.50)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; XM_UA_NO_VERSION(0.01)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 27 Sep 2022, at 02:29, void wrote: > The same host creates 13.1R and 13-stable systems fine. I have not yet > tried making a 12.2R or a 12-stable system yet. 12-stable poudriere jail builds correctly From nobody Wed Sep 28 02:32:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4McgYJ44nyz4V92M for ; Wed, 28 Sep 2022 02:34:12 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4McgYH0l0sz3bdS for ; Wed, 28 Sep 2022 02:34:11 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0B25A5C009B for ; Tue, 27 Sep 2022 22:34:10 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Tue, 27 Sep 2022 22:34:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1664332450; x=1664418850; bh=LaFxcO8Qzb ZJmBCtT6cr8WGOzMv+X/4LMZ3PWliylmg=; b=JqVg5slUulmDPTbV9YPYhIn6o9 Qz8SmtcOtWiGpdIkfUykahrSJl6+nRmEKCGrcGJExq1uVpgjyCI0Df/NxXtsUwTV 3Le5/zQ/SaTVNKhI2zTeVyL0NKax37WeUe/pPtcMTr4KYjy+ApvgzJtAayAo3YxS Eb9qdlGvZhxc5I67HN1p/sn8gSSNzTrsXtpCZT8WfSU0dGkoKYPFAHnq0YiUGoMl UEKuZTdbeB4ioNh8zVReDdT32gwiHFA11rPRaXKaWoykIeqmyBz9/Y+XladvqHP3 RgtvEZSB/STf67DHrTyd66G8EILVkEsEqaDfIUkMI/vL5nYQHrUKrpuzf68A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1664332450; x=1664418850; bh=LaFxcO8QzbZJmBCtT6cr8WGOzMv+ X/4LMZ3PWliylmg=; b=NHMWWLUymXenZ8jMlCFHdjnUY/NVf5Sy8fqlXauccH6h NfuLf2vCP35TeVauBQhZ6vfpPegE86ZjwIclJjhfmBkNvoo8mppiHTWmpY+EC4nd 4lS+Xw9cKaiVqD851MPsDe2gTob0LGHazlxc7LG0wxv3H1j6sYcTp2jpzHzW6vvx 4ExFh4holRtKKPzFLTOKjRW8FG2EekHpSDu0GkR8yecan6Nrc1b9r/J04IBi0Gyi qhkx6tmpdqgfuNor+8by7P8LghDzNtX325Y2EnYn8AzDMtRn56vEoQ2yWGiibbDP GsG6kP+1IN++SEuQ9yO2QphpcAOJbXy3SEC2V0ay1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegjedgheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeeiieehuedtudeikeduieekvdffgefgfeevvdefheffgedutdehtdetvd fhveekhfenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD9362A20079; Tue, 27 Sep 2022 22:34:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: In-Reply-To: References: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> Date: Wed, 28 Sep 2022 03:32:11 +0100 From: void To: freebsd-hackers@freebsd.org Subject: Re: poudriere cannot build 12.3R jail on a 13-stable system - cp: [vdso]: No such file or directory Content-Type: text/plain X-Rspamd-Queue-Id: 4McgYH0l0sz3bdS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=JqVg5slU; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=NHMWWLUy; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.28 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-4.19 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_WWW(0.50)[]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.28]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.28:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.28:from]; XM_UA_NO_VERSION(0.01)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-ThisMailContainsUnwantedMimeParts: N On Tue, 27 Sep 2022, at 15:49, void wrote: > On Tue, 27 Sep 2022, at 02:29, void wrote: > >> The same host creates 13.1R and 13-stable systems fine. I have not yet >> tried making a 12.2R or a 12-stable system yet. > > 12-stable poudriere jail builds correctly 12.2 fails at the same place. Tried to build 12.3R poudriere with locally patched (from the review mentioned in https://lists.freebsd.org/archives/freebsd-current/2022-April/001737.html ) not really expecting it to patch as here trying to build a 12.3R jail whereas the context of the patch is addressing the same issue for building 13-stable on -current # cd /tmp # git clone ssh://anongit@git.freebsd.org/src.git # cd src # git checkout releng/12.3 # wget https://reviews.freebsd.org/file/data/3pwqyimbgzwstgvcmkos/PHID-FILE-xj5gncvnwh542umtjq7s/D34734.diff # patch < D34734.diff The patch fails to apply when the sources are checked out to 12.3 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/Makefile.inc1 b/Makefile.inc1 |--- a/Makefile.inc1 |+++ b/Makefile.inc1 -------------------------- Patching file Makefile.inc1 using Plan A... Hunk #1 failed at 1368. 1 out of 1 hunks failed--saving rejects to Makefile.inc1.rej Hmm... Ignoring the trailing garbage. done From nobody Wed Sep 28 09:19:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4McrY96y5sz4d7FX for ; Wed, 28 Sep 2022 09:19:41 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4McrY81sLdz44rX for ; Wed, 28 Sep 2022 09:19:40 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 28S9JLqM076069; Wed, 28 Sep 2022 18:19:22 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 28 Sep 2022 18:19:21 +0900 From: Tomoaki AOKI To: void Cc: freebsd-hackers@freebsd.org Subject: Re: poudriere cannot build 12.3R jail on a 13-stable system - cp: [vdso]: No such file or directory Message-Id: <20220928181921.6b43d82ffc7ba765b8d19303@dec.sakura.ne.jp> In-Reply-To: References: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__28_Sep_2022_18_19_21_+0900_zqdI_OeJNY_mw=Yc" X-Rspamd-Queue-Id: 4McrY81sLdz44rX X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; HAS_ATTACHMENT(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --Multipart=_Wed__28_Sep_2022_18_19_21_+0900_zqdI_OeJNY_mw=Yc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 28 Sep 2022 03:32:11 +0100 void wrote: > On Tue, 27 Sep 2022, at 15:49, void wrote: > > On Tue, 27 Sep 2022, at 02:29, void wrote: > > > >> The same host creates 13.1R and 13-stable systems fine. I have not yet > >> tried making a 12.2R or a 12-stable system yet. > > > > 12-stable poudriere jail builds correctly > > 12.2 fails at the same place. > > Tried to build 12.3R poudriere with locally patched (from the review mentioned in https://lists.freebsd.org/archives/freebsd-current/2022-April/001737.html ) not really expecting it to patch as here trying to build a 12.3R jail whereas the context > of the patch is addressing the same issue for building 13-stable on -current > > # cd /tmp > # git clone ssh://anongit@git.freebsd.org/src.git > # cd src > # git checkout releng/12.3 > # wget https://reviews.freebsd.org/file/data/3pwqyimbgzwstgvcmkos/PHID-FILE-xj5gncvnwh542umtjq7s/D34734.diff > # patch < D34734.diff > > The patch fails to apply when the sources are checked out to 12.3 > > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |diff --git a/Makefile.inc1 b/Makefile.inc1 > |--- a/Makefile.inc1 > |+++ b/Makefile.inc1 > -------------------------- > Patching file Makefile.inc1 using Plan A... > Hunk #1 failed at 1368. > 1 out of 1 hunks failed--saving rejects to Makefile.inc1.rej > Hmm... Ignoring the trailing garbage. > done I'm not a user of poudriere, but looking into the patch you mentioned and src of releng/12.3, it shouldn't apply as is. The conditional at the top of the patch only appears on releng/13.0 and later only. (Seems to be introduced at r364760 on SVN era. [1]) Modifying the patch manually to be "just applicable" is quite easy, but not sure the patch works as intended without the conditional. Attaching modified patch but I cannot assure it builds/works. An advice for the future: For diffs on phablicator, use "-p1" option for patch. This time, the target file is at current directory, so it is OK, but if any of the targets are in subdirectories, the patch SHOULDN'T apply without the option. And try with option "-C" first to check whether it can be applicable or not. BTW, annotate view on svnweb was quite useful on the situation like this (Want to check when the code was introduced). But I cannot find equivalent functionality on cgit. :-( [1] https://svnweb.freebsd.org/base/head/Makefile.inc1?r1=364759&r2=364760& -- Tomoaki AOKI --Multipart=_Wed__28_Sep_2022_18_19_21_+0900_zqdI_OeJNY_mw=Yc Content-Type: text/x-diff; name="D34734-12.x.diff" Content-Disposition: attachment; filename="D34734-12.x.diff" Content-Transfer-Encoding: 7bit diff --git a/Makefile.inc1 b/Makefile.inc1 --- a/Makefile.inc1 +++ b/Makefile.inc1 @@ -1366,6 +1366,10 @@ done); \ libs=$$(ldd -f "%o %p\n" -f "%o %p\n" $$progs 2>/dev/null | sort -u | \ while read line; do \ + case $$line in \ + "["*"]") \ + continue;; \ + esac; \ set -- $$line; \ if [ "$$2 $$3" != "not found" ]; then \ echo $$2; \ --Multipart=_Wed__28_Sep_2022_18_19_21_+0900_zqdI_OeJNY_mw=Yc-- From nobody Wed Sep 28 13:30:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mcy6x4fXGz4VBLk for ; Wed, 28 Sep 2022 13:30:49 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mcy6w4kWKz3Ydt for ; Wed, 28 Sep 2022 13:30:48 +0000 (UTC) (envelope-from void@f-m.fm) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 78A1D3200921 for ; Wed, 28 Sep 2022 09:30:46 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Wed, 28 Sep 2022 09:30:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1664371845; x=1664458245; bh=gOIY0QDkri iNBtmMTaW5kIUVBvJOIBDMRARyVFMtp4E=; b=NU5EX+p9U75+horZz5CpXNj3G6 sveqAllaNjbU+It4dhJiI7q3Rya6FfgRXYt880gle1v2Qq+8h0RhdxxBh9Ws2KOp xfza+Ta2v0xV0wnzGI8iEQdHsYV18y0gUY/zt+h3SXhpdPFLsnQymHp0LHh52Tp0 ttSzbY81SmYYpbUzFtBUxTbHUTaYGw9I5sKnsUiydPJbEVWWwbO2fLVTtCFgXGia RX5RsysrW7djgIAFUZwe+NnXXn30ervdRSnYtWuV3YJ5Oel3pwlbWw0V+xKfm7tw 2hdsNRbuhcf1vF7HhuCHmAHTLS6xr3bM+0Jf+sRNMyb8C11By3VgVi5CqDEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1664371845; x=1664458245; bh=gOIY0QDkriiNBtmMTaW5kIUVBvJO IBDMRARyVFMtp4E=; b=w+UdL3xeSF6+XDlM0j+5zGvx69OYzbIK7mmZAjv+i4fK L6DYcJCTTemZF4ft8HVBpXTcJ39DluLCfmezghFuj3Nl5EfDknqmMdODrIMZ1Cdm DpbjESeVFx4Of+bzkneVMy069qVyxI5kUWcIx2s5d/1nYWlUyOlGXCbX4EqyrucP qRqWFLB8wUPOxHIwb0DdODId3lEhqq/vKrNeMyFHODHDMazWB5aDcB2QFRFqm1kR hMdQ8o9suYFymeQ1eb3v+5wEnME9doXJUo99oAeoMXpk/aNdy6MFkHJ+XFBTcsNs ZiXRcTdm9T2uaVcM0f5tJFv9phBuCz8cErTjywj3oA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeegkedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffr rghtthgvrhhnpeeitedvueehtdehtddvhfeuhfevhedvieelvdeiffehveelheegfedule ejudekvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id B2EE42A20079; Wed, 28 Sep 2022 09:30:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-968-g04df58079d-fm-20220921.001-g04df5807 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-Id: <0023fc09-a62d-4759-889f-d1d33fee82b9@app.fastmail.com> In-Reply-To: <20220928181921.6b43d82ffc7ba765b8d19303@dec.sakura.ne.jp> References: <26824204-ea59-4233-8bc7-d88ccbf75637@www.fastmail.com> <20220928181921.6b43d82ffc7ba765b8d19303@dec.sakura.ne.jp> Date: Wed, 28 Sep 2022 13:30:15 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: poudriere cannot build 12.3R jail on a 13-stable system - cp: [vdso]: No such file or directory Content-Type: text/plain X-Rspamd-Queue-Id: 4Mcy6w4kWKz3Ydt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=NU5EX+p9; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=w+UdL3xe; dmarc=pass (policy=none) header.from=f-m.fm; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm X-Spamd-Result: default: False [-4.51 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.918]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from] X-ThisMailContainsUnwantedMimeParts: N Hi, thank you for your patch. The patch (eventually) worked. At first patch didn't and the .rej had the cryptic message "\ No newline at end of line" and it looked fine, but in vim and less. Eventually thought the patch might have invisible chars so viewed it in vi and ee and sure enough, there was "^M" on every line. So removed all those in vi and the patch applied and the poudriere jail has built without error. I guess the "^M" happened anywhere along the way, or even in my webmail client, or the process of saving it locally from the client. Thanks again! From nobody Fri Sep 30 07:26:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mf1xw65WTz4YF4X for ; Fri, 30 Sep 2022 07:26:44 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mf1xw5F5Mz46fV for ; Fri, 30 Sep 2022 07:26:44 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664522804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=vsHujXT7O5MViwWh8B26cTvmNOEzgJ4NX8hZn5iqc1I=; b=UqQa4QOxy2fRaSBg1wPrSztu1A3GTvga3ANYlSyvxxbU6hL0xPs1lu9oBoZqF6FxHn4ZBj VeF6dpwnEaGE9jp+/vwh9wbhuJYP+0DDwtP78o7jHZrKr9UrsrTZ5YRXVqRbp7ej1dDKAJ 2fssOxl/gyKLhvIMiv8ekGCVekTgo6YKdO8tGmtO8GVAkfTG3OsK9hFFaJgLcFbo9YzTlS 9rWAQVE8L28ImRQQBjDNG55i66qtPuehxXYjaZpFbmxrQRSN194exlPOQf9RJ7U/hV66t3 BsDwKKSCR2Q0YVS43DcYvvvbyuwYzVmivX6HH+xCG84oHgeYeb7xV+6Mepqc6Q== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mf1xw2ygYz1132 for ; Fri, 30 Sep 2022 07:26:44 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> Date: Fri, 30 Sep 2022 08:26:43 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 To: freebsd-hackers@freebsd.org Content-Language: en-GB From: Graham Perrin Subject: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD Organization: FreeBSD Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------XPFnFvalUOp3YrNF8EM5fjZD" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664522804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=vsHujXT7O5MViwWh8B26cTvmNOEzgJ4NX8hZn5iqc1I=; b=HCvFtW0hwDBBrlTvTR9XKQvuf5xO7hbeAeNIyqj14KtRscZaKIx/s040t8RhCV4esMMuLo rfW80nR4B4URjI/dlMzFpV41zzbD4f1IqKXg2itEU/5wZ6lX5R0xq0Sjflhly79P4rUX3C H75dIqRtHxahRu6FUzV9Zp5vKDLVlosmbbpuVhlSoMr9yPFWVmyLfIY6yBtnWUs5Pn1dsW 9TEXcEz5MsYoaaG/uPeEfB3RFvJ+3zX/vAz50mzUKO6A2WXg9y2jN/c+zYjm1+McjOyGai eVKZAow2lmG6/lZxK0SwcWsoAPCcMlem3DAXoKAWY8vVQdEWGPU1Bc9m31S7ag== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664522804; a=rsa-sha256; cv=none; b=i+udKalgeXF/tou12MFRO7h6LvqmkGyVkk/5vHM/inPE7rIZT6UgUcXxxjTk8PRnK3HzFl suOOzMNgHe28zqaRzFdkWAsdB78Wz3ZYUoPW+sw6ZGtGX4CWTO+zpTcmTeE7TIKy0RX4Xx 5RI6bSOviUAAc0TYjl5IXZknhjgptuVyfHtA659158eDXRCBRqaSTNZY0KMWCDm9b2fov5 M6R4xM9O7rasE4MNItZKTfouc+AOUPpB9fCQpIeqPRZq3NHLPGSjuEt8A4CYq709pmK6hN pbJDo2hIEahjLJXxN0qGIDaDaEiLhdM1bDd77eti+hI+R0iQtyhgD7IUGV22Cw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------XPFnFvalUOp3YrNF8EM5fjZD Content-Type: multipart/mixed; boundary="------------w8SafMzRQFXwix3ZMQaP2fzV"; protected-headers="v1" From: Graham Perrin To: freebsd-hackers@freebsd.org Message-ID: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> Subject: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD --------------w8SafMzRQFXwix3ZMQaP2fzV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 PGh0dHBzOi8vd3d3LmZyZWVic2Qub3JnL3JlbGVhc2VzLzEzLjFSL2Fubm91bmNlLyNfYXZh aWxhYmlsaXR5PiBhbmQgDQplbHNld2hlcmU6DQoNCmJzPTFtDQoNCldoeSBzbyBzbWFsbD8N Cg0KSSBmaW5kIHRoaW5ncyBtdWNoIGZhc3RlciB3aXRoIGEgbGFyZ2VyIGJsb2NrIHNpemUu IElzIHRoaXMgbXkgaW1hZ2luYXRpb24/DQoNCg== --------------w8SafMzRQFXwix3ZMQaP2fzV-- --------------XPFnFvalUOp3YrNF8EM5fjZD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmM2mjMFAwAAAAAACgkQt2dIb0oY1Aud Lg/+Oz8zZzOI1DzsH8lWom08rqNbazmiJ/bxMYlMV3lpKMvHAD0WUloAueYo9pUchTrjoTOceMg3 lFRsB5n8PJPG11fZwEWPRdoG0HDCFf3Omu4G1qs3ymaa65YyUuMvX7NsZ3aI3UgQFvJLg8oViM1n RutrU7nbYkkvKmAI9UYrENVZBWiwhRh6ZjTtePgxJOl7cwebwi2Z+NptHHlNZTFTKDn/Iuti4VDY igM0/PK7mH5wYFj1vktro6AaC5hxcFmaWQKRIdbMzd3/gyqV18Fh9KdpDQHlY1IorzD/NPvhJdsa SxsLQ4Y7rS+PeHjqaum9g0jBr6MNeUP6y+3NnqPLHYHaTNf+61nMgXrRH+CocF19t+/2485cjPv2 w2OK4/cFbNerfIwe73D6uzKRXXebAGoGtESAF76jN7ACp+DR9xUPIqs4ggMxmLYBHslKGNyMLuOQ Oppe0vy3Nn5iNSUh5S3zNG+E+vZ/ga3lCUI11P08fd5ChoNozfdZR6aON9ThA/55d3YbfrmWbPAb 4kW+jC+cIXh/y4/XWVISxhw+tihHa5+YUQqD+7FAfTiVGL5X8f/c9AXRiSjBHlZLyv8i7VbH21S0 +jq1TaAr8u+Gfy9yk86ETHoYT9pCsfJw7TkPkytJsVtbD3XMEioiMU1JBr4qE66EAWxl0jxRf6Sf u44= =El4a -----END PGP SIGNATURE----- --------------XPFnFvalUOp3YrNF8EM5fjZD-- From nobody Fri Sep 30 11:34:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mf7T708pKz4df6Y for ; Fri, 30 Sep 2022 11:35:39 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mf7T453NXz3TNM for ; Fri, 30 Sep 2022 11:35:35 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 28UBZ0Wf087110 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 30 Sep 2022 21:05:00 +0930 (ACST) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1664537705; bh=rLQes1qiKEKJg0NSA2hpudN11Aej+xapuFugyjgENLM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=BtVt7aYhZZmLoyJJo058cN5JCv/CDNE8PMTiaOaOUcpUIBs2z/FdWoXyCg+tMcUIc lC26DLJtpkGPbk4H+eFhp0/7XArB2rGEtdwjp487BEwR5zE5K9UmNVZ+TODBxtRYha WX28vG/70tNRwy5pge+N3HNUA/3/ALvA5KQ+imYo= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 28UBYrw2087080 for ; Fri, 30 Sep 2022 21:04:53 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2403:5800:5200:4700:3928:39c3:614e:a9b Received: from smtpclient.apple ([IPv6:2403:5800:5200:4700:3928:39c3:614e:a9b] [2403:5800:5200:4700:3928:39c3:614e:a9b]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 28UBYra3087071; Fri, 30 Sep 2022 21:04:53 +0930 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD From: "Daniel O'Connor" In-Reply-To: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> Date: Fri, 30 Sep 2022 21:04:45 +0930 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C0C2819-439C-448F-A576-A63AEBD45F5F@dons.net.au> References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> To: Graham Perrin X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4Mf7T453NXz3TNM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=BtVt7aYh; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 30 Sep 2022, at 16:56, Graham Perrin = wrote: > and = elsewhere: >=20 > bs=3D1m >=20 > Why so small? >=20 > I find things much faster with a larger block size. Is this my = imagination? 1m seems large and I wouldn't have expected much improvement past, say.. = 128k. What sort of improvements do you see? ISTR when I have looked before it wasn't much better than 16k. Since it's conv=3Dsync I think you can crank up the size as much as you = like without a problem though (unless your destination device is close = to the image size in which case the padding might make it appear to = fail) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Sep 30 16:33:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MfG5K4RZYz4f6Rb for ; Fri, 30 Sep 2022 16:33:57 +0000 (UTC) (envelope-from leres@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 4MfG5K3vCTz3qxy; Fri, 30 Sep 2022 16:33:57 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664555637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yNwpZOJ3bwvoSCOH7BCFWkptPCwVX9hNZUFNCUSxD38=; b=F6PAn8CCEWMFII/cr1Vfnr2Xgg25lU8QQYDK5zfmWK6+YNAnJz40F8+Gf2B3Xyx0aza8uV naWqi/8Q8+nKvyVDrRTIB+tsVaSixVwSgnm8CK5GK/2A6jw/iofKjn5I9CCBq/7n8mkOlu UQU5y7RtUSArsBMKkbaq3ZUA6TwTyuVcipj30bLl77vAinNRpBt+KuQqiOGiyOFdKsEJhO 3kbkcQcIY0DkXqK/3KgH4ujwzhiONjYyLkaquzSEuVqXcXsfo12oa4fwFofopwJNdfBx2p gCuDJ65Fb4XyxRWmHlW38geTVCRmCw3N8k7ju9n6xJNCgNWtGkttycM3DDW0rw== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe09:150e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MfG5K0t1wz12x7; Fri, 30 Sep 2022 16:33:56 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> Date: Fri, 30 Sep 2022 09:33:55 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD Content-Language: en-US To: Graham Perrin , freebsd-hackers@freebsd.org References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> From: Craig Leres In-Reply-To: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664555637; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yNwpZOJ3bwvoSCOH7BCFWkptPCwVX9hNZUFNCUSxD38=; b=Sj7GaYVPfBYoXA7aKPpknyJMkdu5pyS+4jqv3oN4UhovbGEuqVT2PYDnss2gGnE95dj+iE YJPGsSyXKZZPlPCF4AEEl6htUj1vz+zDVq4Qn4c52wc1UkjZvp5cbcTDw+oZi9obKOctXZ AjSEHOLDtY1rhE1rgRgBI4olbD4wCEkOBMf4w/gUF7i/dT4Z4x9BQe5xpk5Bfkvy2FrI+Y fGGv4OmErDtNGCDt0J9iMKzPKU41V+wc/N36VsxuCpRtFpM9qMeP0wRm89ItIsDvXyByjt wDgh+tALIQMbk03OEjPwUaCCAmMH5kiDTHVLtZfNQ2oSJO2JfewFPYA41EmrLw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664555637; a=rsa-sha256; cv=none; b=p/mJ69rTAwBiKh401Ms2UfSTACB7dXAg5QQxQez/4ba/8UpFVw4EdvAv6BGFqKf0/A9JHg hQDG09zuv8iXzPEKVGYaHFXkLsz3Rbws919vwnIZxxKNZEL0x76jJ+q4XmsixebQCY6FBG zmqZCUEQ3NbYNSK5WRHLDXnGOjI0P0VVLZqCt5ll6AKTeUn2Z5xoVxP/PSaMxz9eREhlhi pCp4Rg1bgXmRhVTKkZmqfJ/v+O4aVCx+BWpE/3DpgtO+BFt2oGTjf20FgwyC4aa71QH9AX Lbq3jMqSZc6rDSXBRVR+YG0FpWgarEid2yB3jDsu5Mk0pu3HfJACTGJPPnpw0Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 9/30/22 00:26, Graham Perrin wrote: > and > elsewhere: > > bs=1m > > Why so small? > > I find things much faster with a larger block size. Is this my imagination? I rarely use dd after learning about recoverdisk(1). But I see why dd would be referenced in installation instructions (e.g. switching from a linux distro). Craig From nobody Sat Oct 1 16:00:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MfsJl4pMzz4ctcF for ; Sat, 1 Oct 2022 16:00:55 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from christos (mail.margiolis.net [95.179.159.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 SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MfsJk3xb4z3t0W; Sat, 1 Oct 2022 16:00:54 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=jaXL8L8tKT7N 67OOaxequzQphrPQ2caX+YY/JhYE4Yk=; h=subject:cc:to:from:date; d=margiolis.net; b=WDx26kasqhsE+t8MYPcVrYKzPnJzVqkLca8Kenzq+IwKbiLKCdS BBAlCL+IKNyZgGa+lVSel3Rp4PKdB/fpS8Z+QkanoRhO1sEEfBVjJegQN8WihY7PN1Bujf UkVPB/fZpkLBxTHkWCk5csIRlizAmhgyaq5wfQ0osxlmk4wWrM= Received: from pleb (ppp-94-66-59-136.home.otenet.gr [94.66.59.136]) by christos (OpenSMTPD) with ESMTPSA id fe0d493a (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Sat, 1 Oct 2022 16:00:46 +0000 (UTC) Date: Sat, 1 Oct 2022 19:00:15 +0300 From: Christos Margiolis To: freebsd-hackers@freebsd.org Cc: markj@freebsd.org Subject: Instruction-level dynamic tracing Message-ID: <20221001160015.sce47pwwtqu62vcr@pleb> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4MfsJk3xb4z3t0W X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=margiolis.net header.s=default header.b=WDx26kas; dmarc=none; spf=softfail (mx1.freebsd.org: 95.179.159.8 is neither permitted nor denied by domain of christos@freebsd.org) smtp.mailfrom=christos@freebsd.org X-Spamd-Result: default: False [0.27 / 15.00]; HFILTER_HELO_5(3.00)[christos]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.927]; MID_RHS_NOT_FQDN(0.50)[]; R_DKIM_ALLOW(-0.20)[margiolis.net:s=default]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:20473, ipnet:95.179.144.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[margiolis.net:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; FREEFALL_USER(0.00)[christos]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, Me and markj@ implemented a new DTrace provider (kinst) that allows for arbitrary kernel instruction tracing. The provider is currently implemented only for amd64, but we plan to port it to other architectures in the future as well. kinst probes take the form of: kinst::: where "function" is the kernel function to be traced, and "offset" is the offset to a specific instruction. This offset can be obtained from the function's disassembly using kgdb. For example, if I want to trace the second instruction in amd64_syscall(), I first need to figure out the offset to the second instruction: # kgdb (kgdb) disas /r amd64_syscall Dump of assembler code for function amd64_syscall: 0xffffffff809256c0 <+0>: 55 push %rbp 0xffffffff809256c1 <+1>: 48 89 e5 mov %rsp,%rbp 0xffffffff809256c4 <+4>: 41 57 push %r15 The offset is 1. To trace it: # dtrace -n 'kinst::amd64_syscall:1' Final code review: https://reviews.freebsd.org/D36851 Any review of the code would be appreciated. Christos From nobody Sat Oct 1 17:34:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MfvP75s15z4d6Vy for ; Sat, 1 Oct 2022 17:34:51 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MfvP56nfnz49TT; Sat, 1 Oct 2022 17:34:49 +0000 (UTC) (envelope-from phascolarctos@protonmail.ch) Date: Sat, 01 Oct 2022 17:34:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.ch; s=protonmail3; t=1664645687; x=1664904887; bh=eSCM3Pz9mr1ooRhH0E92GgObNMZOWGEfebFgLhCSI5Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=iQifSaZQH6GC7k3Bk3rWOyqZkbQSOaks8QBXbJasOGlGBODqQ4GJqEd05CtJuq2kM LfwL0FoChIOJUJks/2w6PFh5kGUgW6FPzoz7Tup8CcDgMdnH4fNNoncq0ccWVTDOgM qtZXlRYcnc9RkCSPzTiTgsRC5h2wOKhG+lhAqEGT7kSWYbUnXPatL1vOSXcHN7/jYX qPVXlmHRJZK4CbjkFHngedRyhVogvjN5je6GfZ7MpB1vJkr5eGc432s3Kzovy9hH8Q 6TIWnIx17sQX1d8TTeAOnKsf4+df8O9jDPD8tQFh2KoqO1P4l5gLMan7mu+353vQ7Z D6PWevzrzPyYg== To: Christos Margiolis From: Lorenzo Salvadore Cc: freebsd-hackers@freebsd.org, markj@freebsd.org Subject: Re: Instruction-level dynamic tracing Message-ID: <3vrXrpXrJquSyYmJEymJHUGSK5ikqCH_dQrIx37b4Il0U5e3aELEikYxQYe0foStcE3ZI29Z7zu-ij63Mfy6mOuqyFGWPilgGsmgVCUJok0=@protonmail.ch> In-Reply-To: <20221001160015.sce47pwwtqu62vcr@pleb> References: <20221001160015.sce47pwwtqu62vcr@pleb> Feedback-ID: 8540510:user:proton List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4MfvP56nfnz49TT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.ch header.s=protonmail3 header.b=iQifSaZQ; dmarc=pass (policy=quarantine) header.from=protonmail.ch; spf=pass (mx1.freebsd.org: domain of phascolarctos@protonmail.ch designates 185.70.43.16 as permitted sender) smtp.mailfrom=phascolarctos@protonmail.ch X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[protonmail.ch,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[protonmail.ch:s=protonmail3]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[protonmail.ch:+]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.43.16:from] X-ThisMailContainsUnwantedMimeParts: N ------- Original Message ------- On Saturday, October 1st, 2022 at 18:00, Christos Margiolis wrote: >=20 >=20 > Hello, >=20 > Me and markj@ implemented a new DTrace provider (kinst) that allows for > arbitrary kernel instruction tracing. The provider is currently > implemented only for amd64, but we plan to port it to other > architectures in the future as well. >=20 > kinst probes take the form of: >=20 > kinst::: >=20 >=20 > where "function" is the kernel function to be traced, and "offset" is > the offset to a specific instruction. This offset can be obtained from > the function's disassembly using kgdb. >=20 > For example, if I want to trace the second instruction in > amd64_syscall(), I first need to figure out the offset to the > second instruction: >=20 > # kgdb > (kgdb) disas /r amd64_syscall > Dump of assembler code for function amd64_syscall: > 0xffffffff809256c0 <+0>: 55 push %rbp >=20 > 0xffffffff809256c1 <+1>: 48 89 e5 mov %rsp,%rbp >=20 > 0xffffffff809256c4 <+4>: 41 57 push %r15 >=20 >=20 > The offset is 1. To trace it: >=20 > # dtrace -n 'kinst::amd64_syscall:1' >=20 > Final code review: https://reviews.freebsd.org/D36851 > Any review of the code would be appreciated. The project seems very interesting. Have you considered sharing it through quarterly status reports? Quarterly status reports can help increasing the visibility of your work and thus you might get more reviewing for your code= . Technically the deadline for submitting 2022q3 reports was yesterday, but as a member of the quarterly team I can tell you that we can wait for you if you want to submit a report: just tell us that it is coming and we will wait. Here you can find details on how to submit a report: https://github.com/freebsd/freebsd-quarterly As for the text of your report, I think the text of your mail is already good as a first draft for starting the report reviewing process. Cheers, Lorenzo Salvadore From nobody Sat Oct 1 23:45:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mg3cz54nyz4V8hp for ; Sat, 1 Oct 2022 23:45:39 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mg3cz4WWzz3ZH5 for ; Sat, 1 Oct 2022 23:45:39 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664667939; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kQA0buDjlJMcCk73l+kamCCYI65nvVLa3s+Qj2QYgrQ=; b=rkhd6xnxrCURmC/YTI8tPQVFXNUMZobGaoOtC37i4k2rxQabhEohWst7E7SDkykWVa1ajg P03N2awHtOHvKoZySlFKSjgJrWfMCFExhL4w1bH4kCMTAXXq6NstrblmeWGzczPK80dW1A ql957Xj0l0qJR9SipCJwAnwI7+H4249f1B14IgthSX8QcT/YARM7fysMAWU2O7houiCd2u Ajtm9HhXaCq1JKk/wL6EAGOO/MOAMpgDbRZYQa9B6ZxBnOYXuISTe2bc9te6jHHVUblbKV 1EcF3VasmLa63u7pf5WBloMeBHDh5AdTFEtf0+F4ba0wuozXof7dgO5balC6bg== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg3cz29BGz18l7 for ; Sat, 1 Oct 2022 23:45:39 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> Date: Sun, 2 Oct 2022 00:45:37 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> From: Graham Perrin Organization: FreeBSD In-Reply-To: <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------VdNCbriUloTrUNMwJK6b3QF9" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664667939; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kQA0buDjlJMcCk73l+kamCCYI65nvVLa3s+Qj2QYgrQ=; b=hgf3XY5R/ThoncGT2osONH3AwqnI13v/jNoN5Wai7top/6752EfSgJgZ9kT6oGoKdhBxEQ YqB12Niu70Bz2oL5JFiay1EBYUvYU8uGkCh0Yyu66bdNOA5bAABaxrfxWcJtS6DSRAVSXZ qwINjRG64YMeyDiKXxwGw2VOISd1LSTfIscsfEdVKqffqbTQiMUaroRObGyeoP/Y9ktykA 1deYF3iE8zWL+MFY6AKfIyQ4Hq9kw0cAELwRedCAgPQk7GgOj0kCaFGzZZ1ZHDvrPdb4x9 dCgFeNShBZD0rk9OAloFVQALJDcg3EHg+5r02IAdcLud5LCfsAOvJ9HCv/++2A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664667939; a=rsa-sha256; cv=none; b=I5V6aKvQhi95WYFb3cAsp2MyObkMCYyaRbbLq/5TwvwnD53C0CsOoZsLCf5etZ3+s909Za /azcPiXaycBes2dB8obvAKATtYvfP6JRFsJ8Ig4ql5a0QVkAVkMoKJr/etNKSt2dC3YEWT i2VITxJmect2XO4IQqzfPaylzGlQ10igU/j7Wm2l7fSO5fABMg4yH7QRPoFpER5m+8WsuI y5IkzOAIZTDkjnkn8/m9F0mxcZx31vxvUQS21o+blusladWkjiaS7DJj3c896jSLF+jAS0 CT+ox6W9NQAJ0rlRgwNDWgaMrLt43hYN1ExDYo0dpHlaxjS5d9N9iKoUJR+QGQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------VdNCbriUloTrUNMwJK6b3QF9 Content-Type: multipart/mixed; boundary="------------dlbrzUWdMTjIlneUuu5O5HnO"; protected-headers="v1" From: Graham Perrin To: freebsd-hackers@freebsd.org Message-ID: <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> In-Reply-To: <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> --------------dlbrzUWdMTjIlneUuu5O5HnO Content-Type: multipart/alternative; boundary="------------3uXyoRfMS9Vn0oCCEsUCCNkk" --------------3uXyoRfMS9Vn0oCCEsUCCNkk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMzAvMDkvMjAyMiAxNzozMywgQ3JhaWcgTGVyZXMgd3JvdGU6DQo+IE9uIDkvMzAvMjIg MDA6MjYsIEdyYWhhbSBQZXJyaW4gd3JvdGU6DQo+PiA8aHR0cHM6Ly93d3cuZnJlZWJzZC5v cmcvcmVsZWFzZXMvMTMuMVIvYW5ub3VuY2UvI19hdmFpbGFiaWxpdHk+IGFuZCANCj4+IGVs c2V3aGVyZToNCj4+DQo+PiBicz0xbQ0KPj4NCj4+IFdoeSBzbyBzbWFsbD8NCj4+DQo+PiBJ IGZpbmQgdGhpbmdzIG11Y2ggZmFzdGVyIHdpdGggYSBsYXJnZXIgYmxvY2sgc2l6ZS4gSXMg dGhpcyBteSANCj4+IGltYWdpbmF0aW9uPw0KPg0KPiBJIHJhcmVseSB1c2UgZGQgYWZ0ZXIg bGVhcm5pbmcgYWJvdXQgcmVjb3ZlcmRpc2soMSkuIEJ1dCBJIHNlZSB3aHkgZGQgDQo+IHdv dWxkIGJlIHJlZmVyZW5jZWQgaW4gaW5zdGFsbGF0aW9uIGluc3RydWN0aW9ucyAoZS5nLiBz d2l0Y2hpbmcgZnJvbSANCj4gYSBsaW51eCBkaXN0cm8pLg0KPg0KPiDCoMKgwqDCoMKgwqDC oCBDcmFpZw0KDQoNCkV2aWRlbnRseSwgdGhlIGRpZmZlcmVuY2UgaW4gc3BlZWQgd2FzIG15 IGltYWdpbmF0aW9uLg0KDQpJIGZvdW5kIGxlc3MgdGhhbiBvbmUgc2Vjb25kIGRpZmZlcmVu Y2UgYmV0d2VlbiB0aGVzZSB0d28gY29tbWFuZHM6DQoNCnRpbWUgcmVjb3ZlcmRpc2sgLXYg RnJlZUJTRC0xMy4xLVJFTEVBU0UtYW1kNjQtZHZkMS5pc28gL2Rldi9kYTMNCg0KdGltZSBn ZGQgaWY9RnJlZUJTRC0xMy4xLVJFTEVBU0UtYW1kNjQtZHZkMS5pc28gb2Y9L2Rldi9kYTMg DQpzdGF0dXM9cHJvZ3Jlc3MgY29udj1zeW5jIGJzPTEwTQ0KDQpyZWNvdmVyZGlzaygxKSBp cyBhIGdyZWF0IGhpbnQuIFRoYW5rcy4NCg0K --------------3uXyoRfMS9Vn0oCCEsUCCNkk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 30/09/2022 17:33, Craig Leres wrote= :
On 9/30/22 00:26, Graham Perrin wrote:
<http= s://www.freebsd.org/releases/13.1R/announce/#_availability> and elsewhere:

bs=3D1m

Why so small?

I find things much faster with a larger block size. Is this my imagination?

I rarely use dd after learning about recoverdisk(1). But I see why dd would be referenced in installation instructions (e.g. switching from a linux distro).

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Craig


Evidently, the difference in speed was my imagination.

I found less than one second difference between these two commands:

time recoverdisk -v FreeBSD-13.1-RELEASE-amd64-dvd1.iso /dev/da3

time gdd if=3DFreeBSD-13.1-RELEASE-amd64-dvd1.iso of=3D/dev/da3 status=3Dprogress conv=3Dsync bs=3D10M

recoverdisk(1) is a great hint. Thanks.

--------------3uXyoRfMS9Vn0oCCEsUCCNkk-- --------------dlbrzUWdMTjIlneUuu5O5HnO-- --------------VdNCbriUloTrUNMwJK6b3QF9 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmM40SEFAwAAAAAACgkQt2dIb0oY1AuC kA/+O6qLmn/LCKvj6qfGxFR5XsiM0La/Du5l4bZ8EU4mPwy+CnQcZqYdP7XAVnD5BqhjDye1ced5 /wAc0x/Yk1l/IBWkyf9Rs0GrNAo92O4SCH2AhYtiwrH5xpCa/1BvM3dVXaJcQYlpF1HrmFwkoDhB VNKxTBKqNCZuvZcXYM2nqiGhVhn016mWdqsMk7JqCJk486SBweh4PXHiJqIuCj8STdI/6E9hWFSk BSu8/dacx42ihRfnuosOOkm7kOTGKEiKeeVDMkaIRWA7UAxC5UfTIP3+bZk/tqN88DruRqAMv6Bz YilRpnShgu3sKA/S81esccBUJyTQEl5r2EMdzA6EB646xebe6lZ1tXjcz7ft8wAC3ZSu2MVaGwv7 XD7JFUy2ce7r308surYTXc1xDjbCrc02dcxKXwBKLmuOezFe7oPVirmwZ3jX43NUOg8m0FRzg9Zt ESAnXjYVdwQbk7E1foblniLcp7U1ixevXbJc6gWXaSdOPR1Y0fDwOD3oX/UC07vd/qabqGt+zaWU X4P5NN+DC7daOn6GP6lARQCUx6kpXeyZxfZpil9bqNhTFVXJtavuWcwHoUcsyVm/bar/Ow5K4Lmd eF89r7rmG6/PMZRXrFko5ex5cqns1p/KVV3EyYXsfWljB+UykJ7pKDuni1e+YihUCqSOAtwcuJhk 0wo= =d97j -----END PGP SIGNATURE----- --------------VdNCbriUloTrUNMwJK6b3QF9-- From nobody Sun Oct 2 02:26:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mg7BP4NRkz4ddwj for ; Sun, 2 Oct 2022 02:26:21 +0000 (UTC) (envelope-from leres@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 4Mg7BP3yYhz3nP7; Sun, 2 Oct 2022 02:26:21 +0000 (UTC) (envelope-from leres@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664677581; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T+L7UFB7glUkyAMADX2vpMAxXkNpq7WvaeoE+gAfhSM=; b=rrYDMI8yXg23vfRqDQH8jy4dZKjbrxgoyoa6pz/TgIEgwpU/xyDt/7wJLoAkQrcNxH/Okp MOgUERKh5sIihZEYNrWKlpmYiQkxxlFm0kfN2V+1xpWKxJMp5Q/Lcsp0DwPvKMjuaC+U8P GYIkKXgBmHL585A+TXVY2RWry4MG4VBiucEH4VjRFzNZJO185gPCiRbVgZpNu8bTXdpEmx wTOZBfS0366F/uYNTYl1goLqiSKNWh1xYJs61l/VTslwFf2R5pZgfO95JHR4yeQinZCymD eBAak4jLVGaEUMUAIt5NX/wmGaHZSgI9yseKdOS9HIcRaMKF18JvIPDVbnAUuA== Received: from [IPV6:fd:1965::2] (unknown [IPv6:2600:1700:a570:e20:f2ad:4eff:fe09:150e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: leres) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mg7BP10hmz19SZ; Sun, 2 Oct 2022 02:26:21 +0000 (UTC) (envelope-from leres@freebsd.org) Message-ID: <1b5ba983-db7f-9387-3b09-e07cb6895f82@freebsd.org> Date: Sat, 1 Oct 2022 19:26:19 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD Content-Language: en-US To: Graham Perrin , freebsd-hackers@freebsd.org References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> From: Craig Leres In-Reply-To: <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664677581; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T+L7UFB7glUkyAMADX2vpMAxXkNpq7WvaeoE+gAfhSM=; b=CyA0lnsMPivQ4wk+LaTWMNdV7pbpJcPRwHQ5XDt2qhBeaTyuik51qJgzLWpJWEtr6QLFYI Hmm34WR/NJm5XSSNyJlbm3YNpo8Ww+g4M/08vi/tNa8kvoAaB7a1qq3fOrj11X+0FTvZUJ 4U7jZ2lIrK+TCrRWRqTy/xWwyrlyWgp4fJC05k2jWW1OJ3EmDEIw1y1N+LZ0HXnTtVlvHD 6UOq9jQr8We5l9Pa41L8gXe05IpQsOZ0Zjm19PN73lHRRkVaRw/RTAAYpq5qteAsdPRvz3 V8EV01LeJ67AZG0OeyD3nNT8oxwpIu7CZaGciu2TBwPLynLaS3UZnrHwkMzfzg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664677581; a=rsa-sha256; cv=none; b=PawNOzqltK6fQDPJrf96g0mV52TdGQIsWwdH4TdbuFVTB3a/7PjuBOwULE7mUt4OmL3cVy eqkv6OOghIulHGjxGqEGC/17HBbR/+1wOCr9SNv2OvmEB7TlgksmbZU++F6vAeTaUVm/e2 Awazttol6nilJ4lM+LPCYD3qOxTHpjQz/2+lDkoFudxVgSMb+5haKNFFFegtgG8OWT6Sx0 0o8EuJXYdgvTwmNOtBmAGoW2BbKvYUb6mayMcXYsNhswSyTkrEjzvG9/G05kP+/Wj2vSqK Sg3p6jVWQk9MQQlVB3GgNHUmYp3pzqIo+5oAnSxm1s21vvlH60Bsq/oEs9Nyhw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 10/1/22 16:45, Graham Perrin wrote: > Evidently, the difference in speed was my imagination. > > I found less than one second difference between these two commands: > > time recoverdisk -v FreeBSD-13.1-RELEASE-amd64-dvd1.iso /dev/da3 > > time gdd if=FreeBSD-13.1-RELEASE-amd64-dvd1.iso of=/dev/da3 > status=progress conv=sync bs=10M > > recoverdisk(1) is a great hint. Thanks. Years ago I had a failing HD that I wanted to image (maybe a TiVo disk?) dd wasn't cutting it so I looked around and found a tool someone wrote that would do large reads but reduce the buffer size when it encountered errors. Years later I discovered recoverdisk which is a nice implementation of this clever strategy. My only issue is that I find it super difficult to remember what it's called! Craig From nobody Sun Oct 2 07:36:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MgG4Q13qdz4fCXT for ; Sun, 2 Oct 2022 07:36:38 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MgG4P19sHz3TPX for ; Sun, 2 Oct 2022 07:36:37 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vs1-xe30.google.com with SMTP id k6so8669968vsc.8 for ; Sun, 02 Oct 2022 00:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date; bh=sBWlnJnPIuhQC9Ae2qfCYVFWGvpThXWr2Msudswtxqo=; b=oOekjDc2+W4MNgAAZ89NaJZPezAH9rLx2JN4NQE4FvGojZuK9ZKw/Fr8REXMaR6Pf7 Utrph7ecU743fJGKCIpmMbcLjuGSq0FKSDUXbBHh+tD9cguhm/2ErI99cdT/arFYVg/f sr9ntXkVg4e15EriSGtoHgmKCtWYJ8APsK0dwExu23x8noyhxOLxmH6S/+4WdEZ8dHDO ihsVUe7JodHjhnYgF3YSoUxJ2528yamiFPIvss9K2xBNpaDzsMheNhFuWilGCro4nDDX GsSNZtQimTTncFjp0eDrROc8zql0UmhRMC5MZ/9o2JqNXnZHLVVuGTn0PMMdtSYW2PBj y6tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=sBWlnJnPIuhQC9Ae2qfCYVFWGvpThXWr2Msudswtxqo=; b=Mj3XvH1DKccO6QYGBJtraStgKvpUD/FRLxWQNIG2UIqzHRgjCzir1ADdYLVVgUcMDJ SvZKiZvf0S92yNAV1vgg4ISv83aQn9q8s6juzZy5aV/PVEU+eiXef00cEb97We9vql0J qFRgZhjA510wA2KZNyVtpjJgCAsoA+e61nkOiWllRgVLQwQWGDmCwlPAk9xChY2SY2iC P351WUR2PvFAy7AcAFEhKf64v6+9CKP9tTiRckflq2e+aj9zKk1V48Zo7MNhI1zt2znD uwpXdT8KlyOyamDwwcUfbiOETER9A1uigYzwaJKWzXcA1jkuUOZU0JQaQqwGgNHBgy/i fXxA== X-Gm-Message-State: ACrzQf269LduJWy/0TrX/quOVJpEfjYarFG47GlN/6JlIiN5ai2jak9v AJ5L93RnixEGnZdZCVMmz4g9HNTXkfa2yax52bY2OMTrrpT/gY2qVcE= X-Google-Smtp-Source: AMsMyM4bU7Tzhi4tOYkT34m7b2sWDnYUGKm2jsGBD4uRTvX7EkCgUzy1wkkDCBrdqqqw4z77uAy4TRUr1JjFG8F3y90= X-Received: by 2002:a05:6102:578e:b0:3a6:759a:36d9 with SMTP id dh14-20020a056102578e00b003a6759a36d9mr78365vsb.84.1664696195973; Sun, 02 Oct 2022 00:36:35 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:ad4c:0:b0:2f2:b273:f8c with HTTP; Sun, 2 Oct 2022 00:36:35 -0700 (PDT) In-Reply-To: <1b5ba983-db7f-9387-3b09-e07cb6895f82@freebsd.org> References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> <1b5ba983-db7f-9387-3b09-e07cb6895f82@freebsd.org> From: grarpamp Date: Sun, 2 Oct 2022 03:36:35 -0400 Message-ID: Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MgG4P19sHz3TPX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=oOekjDc2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e30 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-2.89 / 15.00]; NEURAL_HAM_LONG(-0.86)[-0.864]; NEURAL_HAM_SHORT(-0.73)[-0.734]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_MEDIUM(-0.29)[-0.293]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e30:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N > 1MB ... 16kB ... 128kB ... etc Different devices, media, drivers, interfaces. With them, plotting different bs=2^n , n: 0~20 ... will steadily both drop time and iops, and increase bandwidth, tapering off to no further benefit, often notably at the page size 8k. Can also be seen with iozone, iostat, gstat, etc. 1M tended to be a handy streaming catch all. From nobody Sun Oct 2 19:45:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MgZh65QxMz4cxLk for ; Sun, 2 Oct 2022 20:05:10 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4MgZh56hkTz3V5c for ; Sun, 2 Oct 2022 20:05:09 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from [192.168.5.3] ([76.132.248.201]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 292JjUA0051540 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sun, 2 Oct 2022 12:45:30 -0700 (PDT) (envelope-from yuri@FreeBSD.org) X-Authentication-Warning: shell1.rawbw.com: Host [76.132.248.201] claimed to be [192.168.5.3] Message-ID: <9b0d34b0-ab9a-66e8-a127-7d7e92f826b7@tsoft.com> Date: Sun, 2 Oct 2022 12:45:29 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: Freebsd hackers list From: Yuri Subject: Is ncurses incompletely installed because it is missing terminfo? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MgZh56hkTz3V5c X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 198.144.192.42 is neither permitted nor denied by domain of yuri@FreeBSD.org) smtp.mailfrom=yuri@FreeBSD.org X-Spamd-Result: default: False [1.50 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FREEFALL_USER(0.00)[yuri]; ARC_NA(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; GREYLIST(0.00)[pass,body] X-ThisMailContainsUnwantedMimeParts: N On 13.1 STABLE the manpage terminfo(5) says that terminfo should be installed in /usr/share/misc/terminfo/*/*. But there are no such files. Is this manpage outdated or incorrect, or is this part of ncurses missing? Yuri From nobody Sun Oct 2 23:19:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mgg036ZgVz4dpwv for ; Sun, 2 Oct 2022 23:19:15 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4Mgg024zvhz3qbT; Sun, 2 Oct 2022 23:19:14 +0000 (UTC) (envelope-from jamie@catflap.org) X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 292NJ8cu044190; Mon, 3 Oct 2022 00:19:08 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 292NJ7xE044189; Mon, 3 Oct 2022 00:19:07 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202210022319.292NJ7xE044189@donotpassgo.dyslexicfish.net> Date: Mon, 03 Oct 2022 00:19:07 +0100 Organization: Dyslexic Fish To: leres@FreeBSD.org, grahamperrin@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <3ea35f4d-8efa-cf93-d462-0d8ce997b7aa@freebsd.org> <49157a68-f015-d7fb-8b78-759e1b089359@freebsd.org> <1b5ba983-db7f-9387-3b09-e07cb6895f82@freebsd.org> In-Reply-To: <1b5ba983-db7f-9387-3b09-e07cb6895f82@freebsd.org> User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 03 Oct 2022 00:19:08 +0100 (BST) X-Rspamd-Queue-Id: 4Mgg024zvhz3qbT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jamie]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US] X-ThisMailContainsUnwantedMimeParts: N In the past, I've had better than expected results using sysutils/ddrescue. Do you know how that compares to recoverdisk? Cheers, Jamie From nobody Mon Oct 3 08:26:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mgv786GQdz4ctNp for ; Mon, 3 Oct 2022 08:26:12 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mgv770M5Qz3cT6; Mon, 3 Oct 2022 08:26:10 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2938Q1n0094913 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Oct 2022 10:26:02 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1664785562; bh=78ehySCQjRP3DMF484t49u7DxQ0IIh+WH9bwBPljZBQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dDOJJdOkAWeW3K+iSsnQPhzCoxSaCjC+LK1kg2do/AyorfdKg1UDy19fES3eP6tK4 EJwBwi8UbTcM+ZE5UOdoyIve02zmsb2fwRe/DUYYBYnknike0J+pcERBLtgB3CJ9AD /KxOLs+X4ksijplgLOLfIjo2YIg4Oa5miyWsdZEQ= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2938Q1wD055412; Mon, 3 Oct 2022 10:26:01 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2938Q10X055409; Mon, 3 Oct 2022 10:26:01 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 3 Oct 2022 10:26:01 +0200 (CEST) From: Wojciech Puchar To: Graham Perrin cc: freebsd-hackers@freebsd.org Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD In-Reply-To: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> Message-ID: <750a38c-2c86-a571-eb65-f63998b7649f@puchar.net> References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Mgv770M5Qz3cT6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=dDOJJdOk; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[puchar.net]; DKIM_TRACE(0.00)[puchar.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > and > elsewhere: > > bs=1m > > Why so small? I've just checked. 128kB, 1MB and 4MB makes no noticable difference From nobody Mon Oct 3 15:26:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mh4Rr2PCDz4d0W9; Mon, 3 Oct 2022 15:26:16 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout4.lrau.net (mailout4.lrau.net [IPv6:2a05:bec0:26:2::73]) (using TLSv1.3 with cipher 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 "mailout4.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh4Rp2fZnz47W1; Mon, 3 Oct 2022 15:26:14 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:In-Reply-To:Subject:Date:Mime-Version:Content-Type: Message-Id:From: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=ZF30VY8mkoTGfDc+FuzR2D7l7orTPEivtvXR+D0J6WQ=; b=G2eGC1WQH6dE14id0L4rDRiqb2 QWl5v/Wj3MjBUYbHlU2VXtftP0eYTDmRmcISJwunWFXNkKExK2G3dvd+rrWmi3ogFh4iDA4oMKCik IqENNh3hugwUee7+lmVcm+FACFctuxweIT82TRW19CrMt26hSVFUvmNqnbEqvPSMv7o2U7U4zl3yD g4prGOS3xV9qD66E4LAOoqQKCzni8EBg4kWvZ8VJO2WJ2QZMamx59XsDvIMlGAL98UBnF2Z763Z2p ZiX/RiisUYoSJoHaleqVVuy24xY3AsJ+FvETnKTg0yEXhcn7EiIto7jOm7b5+nNMkG0jlxA+G6QVH 7ZALGmdQ==; Received: from [2a05:bec0:26:2::74] (helo=imap4.lrau.net) by mailout4.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1ofNKb-000Ntl-4t; Mon, 03 Oct 2022 15:26:09 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664810768-11078-8168/7/136; Mon, 3 Oct 2022 15:26:08 +0000 From: Axel Rau Message-Id: <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_B4FAB519-BB9C-4D16-82A3-B8D44681F591" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Date: Mon, 3 Oct 2022 17:26:07 +0200 Subject: Re: Accessing I2C-Bus via ELV USB-I2C In-Reply-To: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> To: hardware@freebsd.org, freebsd-hackers@freebsd.org References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4Mh4Rp2fZnz47W1 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=G2eGC1WQ; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:2::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-3.90 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:2::73:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[chaos1.de]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_B4FAB519-BB9C-4D16-82A3-B8D44681F591 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =46rom time to time the I2C layer on top of the uart locks up and can=E2=80=99t be recovered via its built in reset command. Initialialization at [1]:2564 is missing the greeting message. looking at the traffic with usbdump -d ugen1.3 -v -v -v -s 1024 > usb.txt I=E2=80=99m missing some response data from the I2C controller. Questions: 1. On usbdump, why is the hexdump mssing on some lines like frame[0] WRITE bytes ? 2. Do we have a tool to dump traffic directly on the uart layer? Any help appreciated, Axel [1]: https://github.com/mc3/home2l/blob/master/brownies/brownies.C > Am 27.04.2022 um 23:08 schrieb Axel Rau : >=20 > Next journey starts: >=20 > For the home2l project, I need a supported I2C interface via USB. > I got this one: > https://de.elv.com/elv-usb-ic-interface-usb-i2c-092255?fs=3D1805459039 > Unfortunately it shows up as a serial device on FreeBSD: >=20 > ugen0.2: at usbus0, cfg=3D0 = md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (500mA) >=20 > bLength =3D 0x0012 > bDescriptorType =3D 0x0001 > bcdUSB =3D 0x0110 > bDeviceClass =3D 0x0000 > bDeviceSubClass =3D 0x0000 > bDeviceProtocol =3D 0x0000 > bMaxPacketSize0 =3D 0x0040 > idVendor =3D 0x10c4 > idProduct =3D 0xea60 > bcdDevice =3D 0x0100 > iManufacturer =3D 0x0001 > iProduct =3D 0x0002 > iSerialNumber =3D 0x0003 > bNumConfigurations =3D 0x0001 >=20 > In loader.conf, I have: > uslcom_load=3D"YES" > iic_load=3D"YES" > iicbus_loa >=20 > But the i2c utility does not show a new bus. >=20 > From dmesg: > root@axels-bsdbox:~ # dmesg | grep iic > ig4iic0: mem 0xdf230000-0xdf23= 0fff irq 16 at device 21.0 on pci0 > ig4iic0: Using MSI > iicbus0: on ig4iic0 > iic0: on iicbus0 > ig4iic1: mem 0xdf22f000-0xdf22= ffff irq 17 at device 21.1 on pci0 > ig4iic1: Using MSI > iicbus1: on ig4iic1 > iic1: on iicbus1 > root@axels-bsdbox:~ # dmesg | grep I2C > ig4iic0: mem 0xdf230000-0xdf23= 0fff irq 16 at device 21.0 on pci0 > iicbus0: on ig4iic0 > iic0: on iicbus0 > ig4iic1: mem 0xdf22f000-0xdf22= ffff irq 17 at device 21.1 on pci0 > iicbus1: on ig4iic1 > iic1: on iicbus1 > ugen0.2: at usbus0 > uslcom0: on usbus0 >=20 > They provide a (linux) driver ("Treiber") which seems to implement the = I2C protocoll on top of the serial interface. > Do we have such a driver on FreeBSD, or exist other supported I2C = devices to be plugged into USB? >=20 > Any help appreciated, > Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_B4FAB519-BB9C-4D16-82A3-B8D44681F591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 From time to = time the I2C layer on top of the uart locks up
and can=E2=80= =99t be recovered via its built in reset command.
In= itialialization at [1]:2564 is missing the greeting message.

looking at the traffic with
usbdump -d ugen1.3 -v -v -v -s 1024 > = usb.txt
I=E2=80=99m missing some response = data from the I2C controller.

<= div class=3D"">Questions:
1. On usbdump, why is the = hexdump mssing on some lines like
frame[0] WRITE <n> bytes  ?

2. Do we have a = tool to dump traffic directly on the uart layer?

Any help appreciated, Axel


=
Am 27.04.2022 um 23:08 schrieb Axel Rau <Axel.Rau@chaos1.de>:

Next = journey starts:

For the home2l project, I = need a supported I2C interface via USB.
I got this one:
https://de.elv.com/elv-usb-ic-interface-u= sb-i2c-092255?fs=3D1805459039
Unfortunately it shows = up as a serial device on FreeBSD:

ugen0.2: = <Silicon Labs ELV USB-I2C-Interface> at usbus0, cfg=3D0 md=3DHOST = spd=3DFULL (12Mbps) pwr=3DON (500mA)

=  bLength =3D 0x0012
 bDescriptorType =3D = 0x0001
 bcdUSB =3D 0x0110
 bDevic= eClass =3D 0x0000  <Probed by interface class>
=  bDeviceSubClass =3D 0x0000
 bDeviceProtocol = =3D 0x0000
 bMaxPacketSize0 =3D 0x0040
=  idVendor =3D 0x10c4
 idProduct =3D 0xea60
 bcdDevice =3D 0x0100
 iManufacturer= =3D 0x0001  <Silicon Labs>
 iProduct =3D = 0x0002  <ELV USB-I2C-Interface>
 iSerialNu= mber =3D 0x0003  <B5AAP0EEUK6A3CIZ>
 bNumC= onfigurations =3D 0x0001

In loader.conf, I = have:
uslcom_load=3D"YES"
iic_load=3D"YES"iicbus_loa

But the i2c utility = does not show a new bus.

From dmesg:
root@axels-bsdbox:~ # dmesg | grep iic
ig4iic0: = <Intel Sunrise Point-H I2C Controller-0> mem 0xdf230000-0xdf230fff = irq 16 at device 21.0 on pci0
ig4iic0: Using MSI
iicbus0: <Philips I2C bus (ACPI-hinted)> on ig4iic0
iic0: <I2C generic I/O> on iicbus0
ig4iic1= : <Intel Sunrise Point-H I2C Controller-1> mem 0xdf22f000-0xdf22fff= f irq 17 at device 21.1 on pci0
ig4iic1: Using MSI
iicbus1: <Philips I2C bus (ACPI-hinted)> on ig4iic1
iic1: <I2C generic I/O> on iicbus1
root@ax= els-bsdbox:~ # dmesg | grep I2C
ig4iic0: <Intel Sunrise = Point-H I2C Controller-0> mem 0xdf230000-0xdf230fff irq 16 at device = 21.0 on pci0
iicbus0: <Philips I2C bus (ACPI-hinted)>= on ig4iic0
iic0: <I2C generic I/O> on iicbus0
ig4iic1: <Intel Sunrise Point-H I2C Controller-1> mem = 0xdf22f000-0xdf22ffff irq 17 at device 21.1 on pci0
iicbus1= : <Philips I2C bus (ACPI-hinted)> on ig4iic1
iic1: = <I2C generic I/O> on iicbus1
ugen0.2: <Silicon = Labs ELV USB-I2C-Interface> at usbus0
uslcom0: <ELV = USB-I2C-Interface> on usbus0

They = provide a (linux) driver ("Treiber") which seems to implement the I2C = protocoll on top of the serial interface.
Do we have such = a driver on FreeBSD, or exist other supported I2C devices to be plugged = into USB?

Any help appreciated,
Axel


---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_B4FAB519-BB9C-4D16-82A3-B8D44681F591-- From nobody Mon Oct 3 15:50:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mh50V1bRqz4d3hk; Mon, 3 Oct 2022 15:51:06 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mh50T1md7z3F5X; Mon, 3 Oct 2022 15:51:05 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GBJyq8az/8h8VTJsaBla4Q2OrzebC57bjK741XfT38M=; b=cLw+57Lp8CCRT4H7vG2bjPotCS xLNpT1Rtgfq4zwKoRpwVjmydBjAgjaR053DFC3+Cug05mZgErwX6UqXqyn9ODTDYvSGjOw2h3R5/v V2iiBdgRv58uo4AhqYHjP+2ZyKciigNrQFg1/LSHphe/FmZTeFBRYWJOky5i9mD0v5bI3xLseOLpU e2hehA/krrf4RgJzPLDwZ3AR/GDyZinwqSDsBeP15hjuzI3N85IbUpojcBZST+ghNTmdtmm0j/dVv GwQCMMfOcarHUQo52683N/+dPZKFIETdaYtxKKW3oKO/TBgHma/3DNdsUEox1VFewdOL3HpIp8k3b DnyN33ow==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1ofNig-000KqL-7W; Mon, 03 Oct 2022 15:51:02 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664812257-12388-8168/7/137; Mon, 3 Oct 2022 15:50:57 +0000 From: Axel Rau Message-Id: <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_9287BA0D-147A-4061-AAD0-D00C73E2A288" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C Date: Mon, 3 Oct 2022 17:50:57 +0200 In-Reply-To: <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org To: Hans Petter Selasky References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4Mh50T1md7z3F5X X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=cLw+57Lp; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-4.00 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2a05:bec0:26:5::73:from,2a05:bec0:26:5::74:received]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9287BA0D-147A-4061-AAD0-D00C73E2A288 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 03.10.2022 um 17:38 schrieb Hans Petter Selasky : >=20 > On 10/3/22 17:26, Axel Rau wrote: >> Questions: >> 1. On usbdump, why is the hexdump mssing on some lines like >> frame[0] WRITE bytes ? >=20 > The -s arguments tells to only grab the first 1024 bytes. Maybe it is = truncated. >=20 > Try setting -s to 65536 >=20 That does not help: - - -=20 usbdump -d ugen1.3 -v -v -v -s 65536 > usb.txt - - - 15:46:38.539679 usbus1.3 DONE-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0,ERR=3D0 frame[0] WRITE 8 bytes flags 0 <0> status 0xca1a1 - - - Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_9287BA0D-147A-4061-AAD0-D00C73E2A288 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=

= Am 03.10.2022 um 17:38 schrieb Hans Petter Selasky <hps@selasky.org>:

On 10/3/22 = 17:26, Axel Rau wrote:
Questions:
1. On usbdump, why is the hexdump mssing on = some lines like
frame[0] WRITE <n> bytes  ?

The -s arguments tells to only grab the = first 1024 bytes. Maybe it is truncated.

Try= setting -s to 65536


That does not help:
- - - 
usbdump -d ugen1.3 -v = -v -v -s 65536 > usb.txt
- - -
15:46:38.539= 679 usbus1.3 DONE-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0= ,ERR=3D0
 frame[0] WRITE 8 bytes
 flags 0 = <0>
 status 0xca1a1 <OPEN|STARTED|CONTROL_XFR|CON= TROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
- - -

A= xel
---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_9287BA0D-147A-4061-AAD0-D00C73E2A288-- From nobody Mon Oct 3 15:54:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mh54d0vF7z4d3sl for ; Mon, 3 Oct 2022 15:54:41 +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 4Mh54d0RWqz3Gpq; Mon, 3 Oct 2022 15:54:41 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664812481; h=from:from:reply-to:subject:subject:date:date: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=YZhefOTH6baLi+EL/ShR5RdvVv03UZMRZYla4zzUvTc=; b=ERvxnPK4BlWC9G9FJw09Xr84m3nfpivZjFe8qFpxYGWvpWVc81YmgijVDgB8Q2vU3BsWvk PFQRhLTq4yPHQgRcZzdDA76RtelyCorAgutOauiAp0ERDmUnBeF8Lz7q/wckoBME2euGtz 1o1VBbs66fKslEyPJgJcq2sG8ZFRkUzBym42jcWOo5fob3u4xC9olnYFxKOEIMqKD2Cvzc fH1D1iIK9s3Asn8ZD3Jrv1jMNHSaZ7+RdlPPRiXeVoLzOCA0Szlo1pbYc8fHQEakfoUk5M pTSVynulT2v0jXZph95FxAIHtHgEhSiI2IebZYyPEOsWq4uGVpsszxJ+4plIlg== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mh54c5vR3z1HnB; Mon, 3 Oct 2022 15:54:40 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id B950A898EE; Mon, 3 Oct 2022 17:54:37 +0200 (CEST) Date: Mon, 3 Oct 2022 17:54:37 +0200 From: Baptiste Daroussin To: Yuri Cc: Freebsd hackers list Subject: Re: Is ncurses incompletely installed because it is missing terminfo? Message-ID: <20221003155437.obu3i7o2vk2i2mbj@aniel.nours.eu> References: <9b0d34b0-ab9a-66e8-a127-7d7e92f826b7@tsoft.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b0d34b0-ab9a-66e8-a127-7d7e92f826b7@tsoft.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664812481; h=from:from:reply-to:subject:subject:date:date: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=YZhefOTH6baLi+EL/ShR5RdvVv03UZMRZYla4zzUvTc=; b=Ox/qzcrMBllLh+vNavGiGAhmGGIr7q1jm4gcj74BZM4RJ5M+6VDNTyjR22FJswR1lu5Zwv QaJWOjNvEqKRVu1z3hNR9Jjb8T3vQhhKAMpPOtaTx/WZdXD0L3rPXQCP64x0vA48SEsSVF ycFp2VdN0OHE6WRaNn5SLJ+GDGgmieHurQD8Zyy+1jCcXFtz75EB/JtZHiJuPSPfGdWROI dRkhs87EJh5zkHDk7y05XMYv7LMvR42kpUUSUrjD5LsaA3r0m7fHHOnY68rX5vrQLs0sLd gqP1swzOwESiPONTc8hgphgUt1Ls/s0psBpP1rFRrEO/+uiK8ppudove8+h9Uw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664812481; a=rsa-sha256; cv=none; b=cQii4omYfjJ6GVDg+0IM6TPmPD+Fr0CN+kGCRDj9L78fDrj/CDio9hrxgl1IaE9Y9620el GgX1GY2U8TgQpnl6q0TIzwiGGNw42CPsVkbYscBFGe3+nhlmnhz1kpj+ezcptNLYZjP71K /isXQqz4+13mD/Du3f7N6axwTD4SysXCdg6OGaVpQnvzAkfQyrlf+YroTD5yKOBCGigao4 Mqw6mKTWINlzuGK0Nu6KjV5Q50f6CzoRzhHlKPf1Z/xL7rKz1coSmMZtKRLtxrR9wSlEtC 7Dzn8cXxf201TgIhLWEZBeziWHvaO7oC0v6MbNniqOgYvrDfG7JPzvqeXPVJSQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 02, 2022 at 12:45:29PM -0700, Yuri wrote: > On 13.1 STABLE the manpage terminfo(5) says that terminfo should be > installed in /usr/share/misc/terminfo/*/*. > > But there are no such files. > > Is this manpage outdated or incorrect, or is this part of ncurses missing? In base we do not provide terminfo db only termcap db note that in freebsd 14 we still do not provide terminfo db in base however if installed from ports we do read it (terminfo-db package) Bapt From nobody Mon Oct 3 23:35:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhHJk5Dw0z4V46S; Mon, 3 Oct 2022 23:35:50 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhHJj3gL6z3Y8W; Mon, 3 Oct 2022 23:35:49 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BV7zLkLIfPvLGwJBSbY45l/hG6g3N1kSi+nW+wS/aX4=; b=lZwtJWIVEQtpZBg0Qg1wfrFQAT Y4VPtedwH/MLDBLOVBKgvD7MTUruZC7+Hq+1sKYheRn4dO5PEGwAPSbFciQe2NCITMWgHKTQ3VWUw kviQ0+tH6ASrZcTAXs8aSMruhtKhTDHEobtfK628HgtGqC+HcMvvOvh6G+E7+UXY6sVWBzai0RlQr LK8xiNodzDUb6kbMDpkjsb06ID+/i8pqgialFU9tUjZidAsf40pOE0zH61ORo8K9kRn75diylSSUj AGgaCQe34Z8kVBfNjDUBUBhEtbDqjLWZEw6bkYKEEnCX7drSiRrXRMHBG7/u58/TJXKSwxPzXXOtW jeH0HANg==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1ofUyS-0004v4-7T; Mon, 03 Oct 2022 23:35:48 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664840147-10753-8168/7/134; Mon, 3 Oct 2022 23:35:47 +0000 From: Axel Rau Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1FC94436-7C1D-49C5-8D20-E39F94CC131C" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C Date: Tue, 4 Oct 2022 01:35:47 +0200 In-Reply-To: <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org To: Hans Petter Selasky References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MhHJj3gL6z3Y8W X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=lZwtJWIV; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-4.00 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2a05:bec0:26:5::73:from,2a05:bec0:26:5::74:received]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_1FC94436-7C1D-49C5-8D20-E39F94CC131C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 03.10.2022 um 17:57 schrieb Hans Petter Selasky : >=20 > Can you show the full sequence from the SUBM-CTRL-EP ? - - - 15:46:38.538480 usbus1.3 SUBM-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D= 8,IVAL=3D0 frame[0] WRITE 8 bytes 0000 41 07 01 01 00 00 00 00 -- -- -- -- -- -- -- -- |A....... = | flags 0 <0> status 0xca1a3 15:46:38.539679 usbus1.3 DONE-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0,ERR=3D0 frame[0] WRITE 8 bytes flags 0 <0> status 0xca1a1 15:46:38.539719 usbus1.3 SUBM-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D= 8,IVAL=3D0 frame[0] WRITE 8 bytes 0000 41 07 02 02 00 00 00 00 -- -- -- -- -- -- -- -- |A....... = | flags 0 <0> status 0xea1a3 15:46:38.540291 usbus1.3 DONE-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0,ERR=3D0 frame[0] WRITE 8 bytes flags 0 <0> status 0xea1a1 - - - Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_1FC94436-7C1D-49C5-8D20-E39F94CC131C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=

= Am 03.10.2022 um 17:57 schrieb Hans Petter Selasky <hps@selasky.org>:

Can you show the full sequence from the SUBM-CTRL-EP ?<= br style=3D"caret-color: rgb(0, 0, 0); font-family: Menlo-Regular; = font-size: 12px; font-style: normal; font-variant-caps: normal; font-weig= ht: normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; -webkit-tex= t-stroke-width: 0px; text-decoration: none;" class=3D"">
- - -
15:46:38.538480 usbus1.3 = SUBM-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D8,IVAL=3D0
 frame[0] WRITE 8 bytes
 0000 =  41 07 01 01 00 00 00 00  -- -- -- -- -- -- -- --  |A.....= ..        |
 flags 0 = <0>
 status 0xca1a3 <OPEN|TRANSFERRING= |STARTED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|= DOING_CALLBACK|0>
15:46:38.539679 usbus1.3 = DONE-CTRL-EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
 frame[0] WRITE 8 bytes
 = flags 0 <0>
 status 0xca1a1 <OPEN|STAR= TED|CONTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING= _CALLBACK|0>
15:46:38.539719 usbus1.3 SUBM-CTRL-E= P=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D8,IVAL=3D0
&n= bsp;frame[0] WRITE 8 bytes
 0000  41 07 = 02 02 00 00 00 00  -- -- -- -- -- -- -- --  |A.......   =      |
 flags 0 <0>
<= div class=3D""> status 0xea1a3 <OPEN|TRANSFERRING|STARTED|CONTROL= _XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOI= NG_CALLBACK|0>
15:46:38.540291 usbus1.3 DONE-CTRL= -EP=3D00000000,SPD=3DFULL,NFR=3D1,SLEN=3D0,IVAL=3D0,ERR=3D0
 frame[0] WRITE 8 bytes
 flags = 0 <0>
 status 0xea1a1 <OPEN|STARTED|CO= NTROL_XFR|CONTROL_HDR|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMME= D|DOING_CALLBACK|0>
- - -
Axel
---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_1FC94436-7C1D-49C5-8D20-E39F94CC131C-- From nobody Tue Oct 4 09:01:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhWs82SXCz4V9j4; Tue, 4 Oct 2022 09:01:16 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhWs736xjz3H5v; Tue, 4 Oct 2022 09:01:15 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RE/qeqy/0G8KcAytlUzhgLIaXhJ8W+oCtqKtAuQqvao=; b=UmIrd363gK+Q9yhfa/qFRAHuA1 FzEkOyLlUzTYj5Nb7bWHo+4Rwgn69aNTT9HvCRGKmSr9QetO1xcWAAs3J14QLpoXvNWwkmz76aTDI B2yWHxCuW7VPtrfCmpNEO40l+9OgfAoLHvHIhdJtpnvwaypA9jU+6SjTtHH+4NvXPf4muLhvJ7QrV Q02KV/3Wdf8tYBOn1WdVgeECP9vPgiyba8TH+kLqFbkfVqJ3W6Ec0lfFfcTQYDlshs6BY1vN/rvS+ rIBn6vRkYpI9fMWJquqhJBFfrmQvW6hP2yBwFzLMLWXbAuMwMQ18hEhvgubSoPEwi2IynwhOWrHNP il3VsLlQ==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1ofdne-0009pb-6f; Tue, 04 Oct 2022 09:01:14 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664874073-11466-8168/7/183; Tue, 4 Oct 2022 09:01:13 +0000 From: Axel Rau Message-Id: <490EBA38-E103-4DC1-8A42-E16A8279980D@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_FEFA34C4-536B-4B59-9C0A-7C95E2B9AC49" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C Date: Tue, 4 Oct 2022 11:01:13 +0200 In-Reply-To: Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org To: Hans Petter Selasky References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MhWs736xjz3H5v X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=UmIrd363; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-4.00 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2a05:bec0:26:5::73:from,2a05:bec0:26:5::74:received]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_FEFA34C4-536B-4B59-9C0A-7C95E2B9AC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky : >=20 >=20 > That looks normal. >=20 > The DONE transaction transferred the SETUP packet, but still lists = frame [0], but is not dumping the data, because it has already been = sent. frame [0] is always the SETUP packet for control endpoints. >=20 > --HPS Thanks for your analysis. Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_FEFA34C4-536B-4B59-9C0A-7C95E2B9AC49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


=
Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky = <hps@selasky.org>= :


That looks normal.

The DONE transaction transferred the SETUP = packet, but still lists frame [0], but is not dumping the data, because = it has already been sent. frame [0] is always the SETUP packet for = control endpoints.

--HPS

Thanks for your analysis.
Axel
---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_FEFA34C4-536B-4B59-9C0A-7C95E2B9AC49-- From nobody Tue Oct 4 10:03:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhYDn75nHz4cyX1; Tue, 4 Oct 2022 10:03:21 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhYDn3wKGz3M0V; Tue, 4 Oct 2022 10:03:21 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=iAbUprfAPsrEUM2xMvC3UQ3rKkkHCHRmoZy9mn5hgsQ=; b=XLlkkG6orFG6kcE7VjYrVHMgS6 s+DltDtXLCjdcQt5SKwly36c6IuuHWPLR7g8jmyvW/th0EUQr0PUCZEl38jtuT5slOGV0Ym/nbRpK 1AmbwxE5/Tl/QjMeUWDjV3HsLDuryUAaAvjQrxXHuWJwtFWbV1CX4GK9N/uVTTO4OYF9Tt2UdFClM XR5/a+CzegZbuhvRc02gNSBRohs0DO7sAJJbASeQlPxqkroibTJ6KQ2ENhkAPavcV+oSDf8WH+l/8 cD8poku3504IPboVpo2bAgH0f4iIxkByVe0W6P1D03HWqvuec1T/i8Qi8bmTL22R22iREKDrP++Rn G9YGWVgQ==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1ofelk-000FAe-7F; Tue, 04 Oct 2022 10:03:20 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664877799-11078-8168/7/140; Tue, 4 Oct 2022 10:03:19 +0000 Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C From: Axel Rau In-Reply-To: <490EBA38-E103-4DC1-8A42-E16A8279980D@Chaos1.DE> Date: Tue, 4 Oct 2022 12:03:19 +0200 Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <017C6EBE-910E-43E7-AAF7-A3D9ECE85EFF@Chaos1.DE> References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> <490EBA38-E103-4DC1-8A42-E16A8279980D@Chaos1.DE> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MhYDn3wKGz3M0V X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=XLlkkG6o; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-4.00 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2a05:bec0:26:5::73:from,2a05:bec0:26:5::74:received]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Am 04.10.2022 um 10:39 schrieb Hans Petter Selasky : >=20 > That looks normal. >=20 > The DONE transaction transferred the SETUP packet, but still lists = frame [0], but is not dumping the data, because it has already been = sent. frame [0] is always the SETUP packet for control endpoints. >=20 So where should I dig further to find out why the read at 09:28:44.885162= shows only 'e:' from the string, shown completely at 09:28:47.463632 (2nd block) ? 09:28:44.878743 usbus1.3 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D= 4,IVAL=3D0 frame[0] WRITE 1 bytes 0000 3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? = | flags 0x8 status 0xca023 09:28:44.878816 usbus1.3 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0,ERR=3D0 frame[0] WRITE 1 bytes flags 0x8 status 0xca021 09:28:44.885162 usbus1.3 DONE-BULK-EP=3D00000081,SPD=3DFULL,NFR=3D1,SLEN=3D= 4,IVAL=3D0,ERR=3D0 frame[0] READ 2 bytes 0000 65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: = | flags 0xa status 0xcb021 09:28:44.885176 usbus1.3 SUBM-BULK-EP=3D00000081,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 1024 bytes flags 0xa status 0xeb023 09:28:44.888153 usbus1.3 DONE-BULK-EP=3D00000081,SPD=3DFULL,NFR=3D1,SLEN=3D= 24,IVAL=3D0,ERR=3D0 frame[0] READ 24 bytes 0000 31 31 35 32 30 30 20 62 69 74 2F 73 0D 0A 49 32 |115200 = bit/s..I2| 0010 43 2D 43 6C 6F 63 6B 3A -- -- -- -- -- -- -- -- |C-Clock: = | flags 0xa =20 Here I get the right response: 09:28:47.457426 usbus1.3 SUBM-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D= 4,IVAL=3D0 frame[0] WRITE 1 bytes 0000 3F -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |? = | flags 0x8 status 0xca023 09:28:47.457462 usbus1.3 DONE-BULK-EP=3D00000001,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0,ERR=3D0 frame[0] WRITE 1 bytes flags 0x8 status 0xca021 09:28:47.463632 usbus1.3 DONE-BULK-EP=3D00000081,SPD=3DFULL,NFR=3D1,SLEN=3D= 68,IVAL=3D0,ERR=3D0 frame[0] READ 66 bytes 0000 0D 0A 45 4C 56 20 55 53 42 2D 49 32 43 2D 49 6E |..ELV USB-I2C-I= n| 0010 74 65 72 66 61 63 65 20 76 31 2E 38 20 28 43 61 |terface v1.8 = (Ca| 0020 6C 3A 35 43 29 0D 0A 4C 61 73 74 20 41 64 72 65 |l:5C)..Last = Adre| 0030 73 73 3A 30 78 30 30 0D 0A 42 61 75 64 72 61 74 |ss:0x00..Baudra= t| 0040 65 3A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |e: = | flags 0xa status 0xeb021 09:28:47.463644 usbus1.3 SUBM-BULK-EP=3D00000081,SPD=3DFULL,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 1024 bytes flags 0xa status 0xcb023 Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius >=20 =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius From nobody Tue Oct 4 20:38:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MhqKb094fz4dflh for ; Tue, 4 Oct 2022 20:38:27 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MhqKY2DRZz3C2g for ; Tue, 4 Oct 2022 20:38:25 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-pj1-f53.google.com with SMTP id x32-20020a17090a38a300b00209dced49cfso11489395pjb.0 for ; Tue, 04 Oct 2022 13:38:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=TUIySC2sGEEg5mG0iR8shWsfmKSUDnsr1mOpiPKLi3w=; b=dTx0u4GW3UUEtqHfQx9d3sS9cwgP3fdE2kRPjQKLS0VjkWoNtKWwL948m4CEOpea+a OfwpTzm6rBMk/gPiwczT6m+ro5CEDfo3ijBtTkvLQErvdBA0LsVVZY5NnF9KdIYNYUji RXOD4ncssPElw3LxaNvAWPpKmvkAa/b9qNrZsUU1BNyZ7LIDeUQoYiKzDbJ0r5fqDDZ0 Rvz5cMwU72bhR122bYd16QO3irN0z6YiIciFUgeE1gKxchuIIMct7MjSDmjmq+YHbbXd NUXvc5ZjvaCmQjA9VkM9XAhRILnF4Hy9kf6OoX7Us+XmTeuFndOPzDHo1N4VcUCrNqWT mcZA== X-Gm-Message-State: ACrzQf2znZf/UWO69rJdAAup445ldGyOStS0OrJFX/HpYvyIlpWQoBJJ 6gD86rg96fZ5sTROD3dprbcIOXBQNo992Ea2cwG3eD/NhGU= X-Google-Smtp-Source: AMsMyM5LzKULRHJLwDD/L4tQNCF+FXH5eONbVAlK8BNz5GCnQCB4/YnKbgXqLDXz4chW9bc3sw0Q88d1Ct5TUg8d01o= X-Received: by 2002:a17:902:e80f:b0:178:fee:c5fe with SMTP id u15-20020a170902e80f00b001780feec5femr28247783plg.85.1664915902802; Tue, 04 Oct 2022 13:38:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Ed Maste Date: Tue, 4 Oct 2022 16:38:13 -0400 Message-ID: Subject: OpenSSH 9.1p1 update in the base system To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MhqKY2DRZz3C2g X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-3.10 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; RWL_MAILSPIKE_GOOD(-0.10)[209.85.216.53:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.216.53:from]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N OpenSSH 9.1p1 has been released, and I will update the FreeBSD base system soon. If you want to try it out now a patch is available for testing at https://people.freebsd.org/~emaste/openssh/FreeBSD-base-openssh-9.1p1-20221004-162159.diff The release notes: Changes since OpenSSH 9.0 ========================= This release is focused on bug fixing. Security ======== This release contains fixes for three minor memory safety problems. None are believed to be exploitable, but we report most memory safety problems as potential security vulnerabilities out of caution. * ssh-keyscan(1): fix a one-byte overflow in SSH- banner processing. Reported by Qualys * ssh-keygen(1): double free() in error path of file hashing step in signing/verify code; GHPR333 * ssh-keysign(8): double-free in error path introduced in openssh-8.9 Potentially-incompatible changes ------------------------------ -- * The portable OpenSSH project now signs commits and release tags using git's recent SSH signature support. The list of developer signing keys is included in the repository as .git_allowed_signers and is cross-signed using the PGP key that is still used to sign release artifacts: https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/RELEASE_KEY.asc * ssh(1), sshd(8): SetEnv directives in ssh_config and sshd_config are now first-match-wins to match other directives. Previously if an environment variable was multiply specified the last set value would have been used. bz3438 * ssh-keygen(8): ssh-keygen -A (generate all default host key types) will no longer generate DSA keys, as these are insecure and have not been used by default for some years. New features ------------ * ssh(1), sshd(8): add a RequiredRSASize directive to set a minimum RSA key length. Keys below this length will be ignored for user authentication and for host authentication in sshd(8). ssh(1) will terminate a connection if the server offers an RSA key that falls below this limit, as the SSH protocol does not include the ability to retry a failed key exchange. * sftp-server(8): add a "users-groups-by-id@openssh.com" extension request that allows the client to obtain user/group names that correspond to a set of uids/gids. * sftp(1): use "users-groups-by-id@openssh.com" sftp-server extension (when available) to fill in user/group names for directory listings. * sftp-server(8): support the "home-directory" extension request defined in draft-ietf-secsh-filexfer-extensions-00. This overlaps a bit with the existing "expand-path@openssh.com", but some other clients support it. * ssh-keygen(1), sshd(8): allow certificate validity intervals, sshsig verification times and authorized_keys expiry-time options to accept dates in the UTC time zone in addition to the default of interpreting them in the system time zone. YYYYMMDD and YYMMDDHHMM[SS] dates/times will be interpreted as UTC if suffixed with a 'Z' character. Also allow certificate validity intervals to be specified in raw seconds-since-epoch as hex value, e.g. -V 0x1234:0x4567890. This is intended for use by regress tests and other tools that call ssh-keygen as part of a CA workflow. bz3468 * sftp(1): allow arguments to the sftp -D option, e.g. sftp -D "/usr/libexec/sftp-server -el debug3" * ssh-keygen(1): allow the existing -U (use agent) flag to work with "-Y sign" operations, where it will be interpreted to require that the private keys is hosted in an agent; bz3429 Bugfixes -------- * ssh-keygen(1): implement the "verify-required" certificate option. This was already documented when support for user-verified FIDO keys was added, but the ssh-keygen(1) code was missing. * ssh-agent(1): hook up the restrict_websafe command-line flag; previously the flag was accepted but never actually used. * sftp(1): improve filename tab completions: never try to complete names to non-existent commands, and better match the completion type (local or remote filename) against the argument position being completed. * ssh-keygen(1), ssh(1), ssh-agent(1): several fixes to FIDO key handling, especially relating to keys that request user-verification. These should reduce the number of unnecessary PIN prompts for keys that support intrinsic user verification. GHPR302, GHPR329 * ssh-keygen(1): when enrolling a FIDO resident key, check if a credential with matching application and user ID strings already exists and, if so, prompt the user for confirmation before overwriting the credential. GHPR329 * sshd(8): improve logging of errors when opening authorized_keys files. bz2042 * ssh(1): avoid multiplexing operations that could cause SIGPIPE from causing the client to exit early. bz3454 * ssh_config(5), sshd_config(5): clarify that the RekeyLimit directive applies to both transmitted and received data. GHPR328 * ssh-keygen(1): avoid double fclose() in error path. * sshd(8): log an error if pipe() fails while accepting a connection. bz3447 * ssh(1), ssh-keygen(1): fix possible NULL deref when built without FIDO support. bz3443 * ssh-keyscan(1): add missing *-sk types to ssh-keyscan manpage. GHPR294. * sshd(8): ensure that authentication passwords are cleared from memory in error paths. GHPR286 * ssh(1), ssh-agent(1): avoid possibility of notifier code executing kill(-1). GHPR286 * ssh_config(5): note that the ProxyJump directive also accepts the same tokens as ProxyCommand. GHPR305. * scp(1): do not not ftruncate(3) files early when in sftp mode. The previous behaviour of unconditionally truncating the destination file would cause "scp ~/foo localhost:foo" and the reverse "scp localhost:foo ~/foo" to delete all the contents of their destination. bz3431 * ssh-keygen(1): improve error message when 'ssh-keygen -Y sign' is unable to load a private key; bz3429 * sftp(1), scp(1): when performing operations that glob(3) a remote path, ensure that the implicit working directory used to construct that path escapes glob(3) characters. This prevents glob characters from being processed in places they shouldn't, e.g. "cd /tmp/a*/", "get *.txt" should have the get operation treat the path "/tmp/a*" literally and not attempt to expand it. * ssh(1), sshd(8): be stricter in which characters will be accepted in specifying a mask length; allow only 0-9. GHPR278 * ssh-keygen(1): avoid printing hash algorithm twice when dumping a KRL * ssh(1), sshd(8): continue running local I/O for open channels during SSH transport rekeying. This should make ~-escapes work in the client (e.g. to exit) if the connection happened to have stalled during a rekey event. * ssh(1), sshd(8): avoid potential poll() spin during rekeying * Further hardening for sshbuf internals: disallow "reparenting" a hierarchical sshbuf and zero the entire buffer if reallocation fails. GHPR287 Portability ----------- * ssh(1), ssh-keygen(1), sshd(8): automatically enable the built-in FIDO security key support if libfido2 is found and usable, unless --without-security-key-builtin was requested. * ssh(1), ssh-keygen(1), sshd(8): many fixes to make the WinHello FIDO device usable on Cygwin. The windows://hello FIDO device will be automatically used by default on this platform unless requested otherwise, or when probing resident FIDO credentials (an operation not currently supported by WinHello). * Portable OpenSSH: remove workarounds for obsolete and unsupported versions of OpenSSL libcrypto. In particular, this release removes fallback support for OpenSSL that lacks AES-CTR or AES-GCM. Those AES cipher modes were added to OpenSSL prior to the minimum version currently supported by OpenSSH, so this is not expected to impact any currently supported configurations. * sshd(8): fix SANDBOX_SECCOMP_FILTER_DEBUG on current Linux/glibc * All: resync and clean up internal CSPRNG code. * scp(1), sftp(1), sftp-server(8): avoid linking these programs with unnecessary libraries. They are no longer linked against libz and libcrypto. This may be of benefit to space constrained systems using any of those components in isolation. * sshd(8): add AUDIT_ARCH_PPC to supported seccomp sandbox architectures. * configure: remove special casing of crypt(). configure will no longer search for crypt() in libcrypto, as it was removed from there years ago. configure will now only search libc and libcrypt. * configure: refuse to use OpenSSL 3.0.4 due to potential RCE in its RSA implementation (CVE-2022-2274) on x86_64. * All: request 1.1x API compatibility for OpenSSL >=3.x; GHPR#322 * ssh(1), ssh-keygen(1), sshd(8): fix a number of missing includes required by the XMSS code on some platforms. * sshd(8): cache timezone data in capsicum sandbox. From nobody Wed Oct 5 11:55:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MjCgh4bqsz4f4Yb; Wed, 5 Oct 2022 11:55:28 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout4.lrau.net (mailout4.lrau.net [IPv6:2a05:bec0:26:2::73]) (using TLSv1.3 with cipher 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 "mailout4.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MjCgg51vVz3MDX; Wed, 5 Oct 2022 11:55:27 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IiQznazTxYvHtU6hRE3sYFO9MKnQgNu0+SbE254V0go=; b=C0U/5FVDm/Zcl0V577Zp8/fFKw VC6PGVI3inaIBsx0b9YaKuJwRjRxinXlfPHd53mVc8N2TEnAYF7Cr92V1x6Kxl5CBbXGIIUKCrN9C +S1+whPrj2wnkBFS2+cKGs70Y6UHk/nF6uOi8C4KN4FzHS97lSnoNqjBfzN6VfSFHiK10FdvaTfX/ 7aws6eFl843b4+a8HvBD8OcirFikcwrMlNJsp4VPPyM8sAeXlPey25c7iXRWBEU3lpfAgmHLAIsLa 3WaV4ZluC9qoy+PiMijG0XwlysdtUKW1N09skQMJSxjdingby+fgDxGVANXqk1Jgj9vlg+lKtGmwH 8NGhTUog==; Received: from [2a05:bec0:26:2::74] (helo=imap4.lrau.net) by mailout4.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1og2zj-0003uv-4H; Wed, 05 Oct 2022 11:55:23 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664970922-10326-8168/7/156; Wed, 5 Oct 2022 11:55:22 +0000 From: Axel Rau Message-Id: <752FCC61-496D-40C5-8A99-143F15B1EE84@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E42947A-F854-4C69-8415-B0726CD1FFE1" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C Date: Wed, 5 Oct 2022 13:55:22 +0200 In-Reply-To: <84c5bc0b-1c72-d50d-6289-ac91a0878bd1@selasky.org> Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org To: Hans Petter Selasky References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> <490EBA38-E103-4DC1-8A42-E16A8279980D@Chaos1.DE> <017C6EBE-910E-43E7-AAF7-A3D9ECE85EFF@Chaos1.DE> <84c5bc0b-1c72-d50d-6289-ac91a0878bd1@selasky.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MjCgg51vVz3MDX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b="C0U/5FVD"; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:2::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-3.90 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2a05:bec0:26:2::73:from]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_5E42947A-F854-4C69-8415-B0726CD1FFE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 04.10.2022 um 13:43 schrieb Hans Petter Selasky : >=20 > Did you clear the endpoint halt condition (for RX BULK endpoint and TX = BULK endpoint), to reset the so-called USB data-toggle, before starting = to communicate with the device? Else you risk loosing a USB packet? If I do not want to touch th USB stuff, can I get the same effect by = close/open of the serial device? Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_5E42947A-F854-4C69-8415-B0726CD1FFE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=

= Am 04.10.2022 um 13:43 schrieb Hans Petter Selasky <hps@selasky.org>:

Did you clear the endpoint halt condition (for RX BULK = endpoint and TX BULK endpoint), to reset the so-called USB data-toggle, = before starting to communicate with the device? Else you risk loosing a = USB packet?

=
If I do not want to touch th USB stuff, can I get the same effect = by close/open of the serial device?

A= xel
---
P= GP-Key: CDE74120  =E2=98=80  computing @ chaos claudius

--Apple-Mail=_5E42947A-F854-4C69-8415-B0726CD1FFE1-- From nobody Wed Oct 5 12:10:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MjD1G3ShMz4f5jF for ; Wed, 5 Oct 2022 12:10:42 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4MjD1F0y09z3Ntc for ; Wed, 5 Oct 2022 12:10:41 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 515684C03F2 for ; Wed, 5 Oct 2022 07:10:40 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Wed, 05 Oct 2022 12:10:40 +0000 From: Pau Amma To: freebsd-hackers@freebsd.org Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD In-Reply-To: <750a38c-2c86-a571-eb65-f63998b7649f@puchar.net> References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <750a38c-2c86-a571-eb65-f63998b7649f@puchar.net> User-Agent: Roundcube Webmail/1.4.8 Message-ID: <3999539a33b13a2843ae50b5ba3c44fa@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MjD1F0y09z3Ntc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[75.145.166.65:from]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[pauamma]; HAS_ORG_HEADER(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-10-03 08:26, Wojciech Puchar wrote: >> and >> elsewhere: >> >> bs=1m >> >> Why so small? > I've just checked. 128kB, 1MB and 4MB makes no noticable difference I remember someone in #freebsd (memory says debdrup) saying 128K is the largest amount FreeBSD will write to a file or device as a single unit. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Wed Oct 5 13:43:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MjG4b20GDz4fG7Z for ; Wed, 5 Oct 2022 13:43:43 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MjG4Y3rQmz3VnW for ; Wed, 5 Oct 2022 13:43:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 295DhVIn085559 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Oct 2022 15:43:32 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1664977412; bh=SQO+r5ntk/T/B2YsJyXEA3BMFY7pa+CsjCxut/gDWyI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uWqNv9aOmuMVcC1knLG/YAl4wneOEvT7lFhwKRAmz4JPUhW8pLGsUGGRvlpbRdq1h a5RzuARf4COjnCGtigpZHwrWaIMO7zriS1/yUGTbiwiExi/0q2ST+cqI60PQbTrVP4 CrWJtuA/Els8Tty7Cq/YH6gJO3eWYTB4rgebIpMI= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 295DhV8U071307; Wed, 5 Oct 2022 15:43:31 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 295DhVmc071304; Wed, 5 Oct 2022 15:43:31 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 5 Oct 2022 15:43:31 +0200 (CEST) From: Wojciech Puchar To: Pau Amma cc: freebsd-hackers@freebsd.org Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD In-Reply-To: <3999539a33b13a2843ae50b5ba3c44fa@gundo.com> Message-ID: References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <750a38c-2c86-a571-eb65-f63998b7649f@puchar.net> <3999539a33b13a2843ae50b5ba3c44fa@gundo.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MjG4Y3rQmz3VnW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=uWqNv9aO; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N unless you have options MAXPHYS=4194304 like i do On Wed, 5 Oct 2022, Pau Amma wrote: > On 2022-10-03 08:26, Wojciech Puchar wrote: >>> and >>> elsewhere: >>> >>> bs=1m >>> >>> Why so small? >> I've just checked. 128kB, 1MB and 4MB makes no noticable difference > > I remember someone in #freebsd (memory says debdrup) saying 128K is the > largest amount FreeBSD will write to a file or device as a single unit. > > -- > #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters > #StandWithUkrainians > English: he/him/his (singular they/them/their/theirs OK) > French: il/le/lui (iel/iel and ielle/ielle OK) > Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) > > > From nobody Wed Oct 5 16:31:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MjKpJ0NC9z4V8WC; Wed, 5 Oct 2022 16:31:36 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) Received: from mailout5.lrau.net (mailout5.lrau.net [IPv6:2a05:bec0:26:5::73]) (using TLSv1.3 with cipher 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 "mailout5.lrau.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MjKpH33jBz3pQ8; Wed, 5 Oct 2022 16:31:35 +0000 (UTC) (envelope-from Axel.Rau@Chaos1.DE) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=chaos1.de; s=2022; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=h00AoV1Exprvu501pO7bCen2LyI1QGRFf2xFSgcrh+o=; b=DqDEFfdgEb8tsZdt+9boeby0ex seoFRK41cNsfD2E0ArfmmbYGVCCzbpOwI6PHU7p6g7GiXH4KnaLZWkHgTLwZK2G6998+P4c/P7o4W prwoVX7KALnqDuSrNujYeN3xN4ZkHTaoFJ++i8ajgpOuMhIYGSw/fPKy2h4BJ8CWwd4KmD5akVvw1 vEXldhMg3pmQrlfPsRW4DFwoA2OpbJ9mMjHw/Sqpb+lurEKvnQJPlObwXRb6eg9zI05OjYe24ofQJ UYFt6bh5fD/lNUakaUtepKWy15DbbVRWOzaC3FVXYzPbfHbvQdH8VU8eTXCRuqAdlYAf/WcXEePB/ nPF+vHDg==; Received: from [2a05:bec0:26:5::74] (helo=imap5.lrau.net) by mailout5.lrau.net with esmtp (Exim 4.95 (FreeBSD)) (envelope-from ) id 1og7Iy-000N98-7L; Wed, 05 Oct 2022 16:31:32 +0000 Received: from Axel.Rau@Chaos1.DE by imap5.lrau.net (Archiveopteryx 3.2.0) with esmtpsa id 1664987487-11466-8168/7/189; Wed, 5 Oct 2022 16:31:27 +0000 From: Axel Rau Message-Id: <23E6D546-DAEF-468D-AE40-752EEB279C8A@Chaos1.DE> Content-Type: multipart/alternative; boundary="Apple-Mail=_31A3D805-29A8-41CD-AB61-E08C5B1687EF" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Subject: Re: Accessing I2C-Bus via ELV USB-I2C Date: Wed, 5 Oct 2022 18:31:26 +0200 In-Reply-To: Cc: hardware@freebsd.org, freebsd-hackers@freebsd.org To: Hans Petter Selasky References: <996df5c0-ffa7-f1bf-a9e2-6dd47d7b49e6@Chaos1.DE> <35D556D7-56EC-4295-93D6-80A4CFE6DCE9@Chaos1.DE> <37c55124-5cd5-6fd1-ca46-9265ebe47b18@selasky.org> <602324D8-515B-4061-8689-5638E9A82759@Chaos1.DE> <2cb6203f-03da-9a05-24a5-c851f1424503@selasky.org> <490EBA38-E103-4DC1-8A42-E16A8279980D@Chaos1.DE> <017C6EBE-910E-43E7-AAF7-A3D9ECE85EFF@Chaos1.DE> <84c5bc0b-1c72-d50d-6289-ac91a0878bd1@selasky.org> <752FCC61-496D-40C5-8A99-143F15B1EE84@Chaos1.DE> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MjKpH33jBz3pQ8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chaos1.de header.s=2022 header.b=DqDEFfdg; dmarc=none; spf=none (mx1.freebsd.org: domain of Axel.Rau@Chaos1.DE has no SPF policy when checking 2a05:bec0:26:5::73) smtp.mailfrom=Axel.Rau@Chaos1.DE X-Spamd-Result: default: False [-3.99 / 15.00]; DWL_DNSWL_LOW(-1.00)[chaos1.de:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.994]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_LOW(-0.20)[2a05:bec0:26:5::73:from,2a05:bec0:26:5::74:received]; R_DKIM_ALLOW(-0.20)[chaos1.de:s=2022]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:197071, ipnet:2a05:bec0::/29, country:DE]; MLMMJ_DEST(0.00)[hardware@freebsd.org,freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[chaos1.de:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[chaos1.de]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_31A3D805-29A8-41CD-AB61-E08C5B1687EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Am 05.10.2022 um 16:46 schrieb Hans Petter Selasky : >=20 > On 10/5/22 13:55, Axel Rau wrote: >> If I do not want to touch th USB stuff, can I get the same effect by = close/open of the serial device? >=20 > The uslcom driver only does this right after attach, in 13-stable and = 14-main. >=20 > Does the attached patch make any difference for you? >=20 > --HPS > <0001-uslcom-4-Clear-stall-at-every-open.patch> As this is a production server, I try to avoid reboots. Meanwhile, I have inserted a read loop which eats the fragments and allows the following status query to get a clean response. With this patch, recovery seems to work. Additionally I have eliminated a hub and connected the device directly = to a port. Hopefully this will stop the frequent `/dev/cuaU0: Bus connection = lost`events. Thanks for your time, Axel =2D-- PGP-Key: CDE74120 =E2=98=80 computing @ chaos claudius --Apple-Mail=_31A3D805-29A8-41CD-AB61-E08C5B1687EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=

= Am 05.10.2022 um 16:46 schrieb Hans Petter Selasky <hps@selasky.org>:

On 10/5/22 = 13:55, Axel Rau wrote:
If I do not want to touch th USB stuff, can I get the same effect by = close/open of the serial device?

The uslcom driver only does this right after attach, in 13-stable and = 14-main.

Does the attached patch make any = difference for you?

--HPS
<0001-u= slcom-4-Clear-stall-at-every-open.patch>
As this is a production server, I try to avoid reboots.

Meanwhile, I have = inserted a read loop which eats the fragments
and = allows the following status query to get a clean response.
With this patch, recovery seems to work.
=
Additionally I have eliminated a = hub and connected the device directly to a port.
Hop= efully this will stop the frequent `/dev/cuaU0: Bus connection lost`event= s.

Thanks for = your time,
Axel
---
PGP-Key: CDE74120  =E2=98=80 =  computing @ chaos claudius

--Apple-Mail=_31A3D805-29A8-41CD-AB61-E08C5B1687EF-- From nobody Wed Oct 5 21:41:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MjSgq0Wl0z4f88X for ; Wed, 5 Oct 2022 21:41:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MjSgp2hjmz3Hrr for ; Wed, 5 Oct 2022 21:41:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x629.google.com with SMTP id b2so541294eja.6 for ; Wed, 05 Oct 2022 14:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=p7Ytw52+sj6uEblG7xdDg/P5LQixYdCDfjMZ/0Q4e9k=; b=cd9AGrbD0xh5ue0WshICoAlscTbCpFBKbJCIjJyGjrDxjUZgvEmz3tbmfqTrM6JXTu xe1XFaktJFkk98QgMiuudI8fjOeuslEeQaAuERBgK+d04kBGctVWIB1tmx0yOIXEHFd/ HDkmHJ+OUvqml7ERsA280iewgpMGX7Bb/vYdyUb7VrfJxh6MEyFlv9jtATrk4tRsT9M4 hAGoLftQxe2vFimhx9cRi6I/8F1thiL5XRrkppd0WT8EPHiShpeOZ1hbxD1sUKp0aWep DWT3zIUIhty6XGFiy5J4XTZEZQtVLUrn6nqCiiklg2j7OVXge7UlWLv0Mn/7zwA33kAk fuww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p7Ytw52+sj6uEblG7xdDg/P5LQixYdCDfjMZ/0Q4e9k=; b=44YQWKfnvqoLnvSp+booDRP0JegD/KOCg7SeUhjb4R+gLf7vn1k7OQGIV1xL2MiOH8 UPTeJJ4P9oq4HLzzYiS0OGY+2HpcbmJvQlZYcstFdz0bimIIv2aWFDIyoyG+tg9jfctR mnYDs+8vC4nrK5VQsh0UsMZT2xKcjQcgJb3h01jaBbcHq+E1sTTdLjYXE3k4Xqwn17sm WzE0/FG3H3VVfY3kOMlRd4tFE0UOJB0cpZ3Kq2RU8QyWloxXOvtjSRIEc8m6djhmBLg2 oYQOKCx8qKb5eceQ3/d6Ta61X+zYylck/l8lautVCv7rxGuutGEeGOIrHeqr6XtnoBuR ScJw== X-Gm-Message-State: ACrzQf1SXwTCFvtcWh7gz/OUrTSfgct2+W00GHXubDPWTXyP94WaMXs0 LZJptGP7Cl28Z4k2FE72MoNdJ+ELGoF+hTCOSv0ARe24EaE= X-Google-Smtp-Source: AMsMyM7vc/l4lOxuvMfe6pHfR2tflXMBEnIYSIsaCD6PCe2CzTmjZQXA53exfq1jpJR5Pa6qHcYzx6EOYSxCEMWquUI= X-Received: by 2002:a17:907:6e28:b0:78d:20d7:1431 with SMTP id sd40-20020a1709076e2800b0078d20d71431mr1297404ejc.333.1665006085067; Wed, 05 Oct 2022 14:41:25 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <1cede94a-c114-17fa-a81c-bb58c2b5879c@freebsd.org> <750a38c-2c86-a571-eb65-f63998b7649f@puchar.net> <3999539a33b13a2843ae50b5ba3c44fa@gundo.com> In-Reply-To: <3999539a33b13a2843ae50b5ba3c44fa@gundo.com> From: Warner Losh Date: Wed, 5 Oct 2022 15:41:13 -0600 Message-ID: Subject: Re: Block sizes for dd(1) to USB memory sticks (flash drives) for installers for FreeBSD To: Pau Amma Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000003fefde05ea5070ad" X-Rspamd-Queue-Id: 4MjSgp2hjmz3Hrr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=cd9AGrbD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::629) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --0000000000003fefde05ea5070ad Content-Type: text/plain; charset="UTF-8" On Wed, Oct 5, 2022 at 6:10 AM Pau Amma wrote: > On 2022-10-03 08:26, Wojciech Puchar wrote: > >> and > >> elsewhere: > >> > >> bs=1m > >> > >> Why so small? > > I've just checked. 128kB, 1MB and 4MB makes no noticable difference > > I remember someone in #freebsd (memory says debdrup) saying 128K is the > largest amount FreeBSD will write to a file or device as a single unit. maxphys used to be 128k. That changed in 13 to be 1MB (though it can be as large as 8MB). However, the maximum transfer size often is 256k or 512k for USB thumb drives and in the cases where it's less than 1MB, we'll do less. Warner --0000000000003fefde05ea5070ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 5, 2022 at 6:10 AM Pau Am= ma <pauamma@gundo.com> wrote= :
On 2022-10-03 = 08:26, Wojciech Puchar wrote:
>> <https://www.freebsd.org/r= eleases/13.1R/announce/#_availability> and
>> elsewhere:
>>
>> bs=3D1m
>>
>> Why so small?
> I've just checked. 128kB, 1MB and 4MB makes no noticable differenc= e

I remember someone in #freebsd (memory says debdrup) saying 128K is the largest amount FreeBSD will write to a file or device as a single unit.

maxphys used to be 128k. That changed in 13 to= be 1MB (though it can be as large
as 8MB).=C2=A0

<= /div>
However, the maximum transfer size often is 256k or 512k for USB = thumb drives
and in the cases where it's less than 1MB, we= 9;ll do less.

Warner
--0000000000003fefde05ea5070ad-- From nobody Thu Oct 6 23:22:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mk6td369jz4dld0 for ; Thu, 6 Oct 2022 23:23:05 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mk6tc6Plwz40Jk for ; Thu, 6 Oct 2022 23:23:04 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 296NMvoT019764 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 6 Oct 2022 19:23:03 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Thu, 6 Oct 2022 19:22:56 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: Strange "make buildworld" error Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=10.0 tests=HELO_NO_DOMAIN, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4Mk6tc6Plwz40Jk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TO_DN_ALL(0.00)[]; TAGGED_FROM(0.00)[freebsd]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On a FreeBSD 12.3-RELEASE-p6, I have updated /usr/src to 13.1-RELEASE. Running "make buildworld" resulted in this error while building shared library libclang_rt.asan-x86_64.so: ld: error: duplicate symbol: __asan::FlushUnneededASanShadowMemory(unsigned long, unsigned long) >>> defined at asan_linux.cpp:118 (/usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_linux.cpp:118) >>> asan/asan_linux.pico:(__asan::FlushUnneededASanShadowMemory(unsigned long, unsigned long)) >>> defined at asan_poisoning.cpp:65 (/usr/src/contrib/llvm-project/compiler-rt/lib/asan/asan_poisoning.cpp:65) >>> asan/asan_poisoning.pico:(.text+0x530) However, line 65 of asan_poisoning.cpp neither defines nor even references FlushUnneededASanShadowMemory. Instead, it defines AsanPoisonOrUnpoisonIntraObjectRedzone. A complete typescript is here: https://www.m5p.com/~george/FlushUnneededASanShadowMemory.xz I am mystified. -- George From nobody Sat Oct 8 00:33:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MkmPr6Qg8z4fFgs for ; Sat, 8 Oct 2022 00:33:52 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MkmPr2Z9gz3n4C for ; Sat, 8 Oct 2022 00:33:52 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 2980Xj9m080722 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 7 Oct 2022 20:33:51 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Fri, 7 Oct 2022 20:33:45 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: Strange "make buildworld" error Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4MkmPr2Z9gz3n4C X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com X-Spamd-Result: default: False [-3.22 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.918]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[freebsd]; DMARC_NA(0.00)[m5p.com]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 10/6/22 19:22, George Mitchell wrote: > On a FreeBSD 12.3-RELEASE-p6, I have updated /usr/src to 13.1-RELEASE. > Running "make buildworld" resulted in this error while building shared > library libclang_rt.asan-x86_64.so: >[... a puzzling error ...] After running gitup to make sure my /usr/src was okay, and deleting /usr/obj, I started another buildworld, and it has gotten past this point in the build (though it hasn't completed yet). So I don't have a clue what went wrong, but progress is happening. -- George From nobody Sat Oct 8 13:24:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml5T11XzYz4fMmD for ; Sat, 8 Oct 2022 13:22:45 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml5T048L5z3cYC for ; Sat, 8 Oct 2022 13:22:44 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qv1-xf34.google.com with SMTP id i9so4711155qvu.1 for ; Sat, 08 Oct 2022 06:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=rnr7zmW74/vYGdmzLfGe4C27JzB5N1NEQYHxMeIkOSw=; b=Fo4doMHRNUIvKwODbi6WZ+FuvFCYYFngBl82mFxrv/4I2F4RRG4UmDuSmHBXOWdP60 yMbL8ga96os9A3VF0LZce+ldNElEJq2Yl7dKm8MNnRpFDTfec0UnnimfTuTiD5iEGPv/ sFKSPokOfGe3eEqyeNr4W9vwWNWvFktJZogzoaTLePY8SOohmSm4k8MPkRoPaiqsk6wk skihs/s2W6o5av224rnxGu/tzac1f6FLSccxO7CM2TdFK6P4jkRtzzidjnI/yLI+Ni7d KZJm39LCReM0PE4kdrzR1UIq/tvRUwI6aGqO+M57aN4Pi9oWysvWgJXyNXJm8rcgssty mMWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=rnr7zmW74/vYGdmzLfGe4C27JzB5N1NEQYHxMeIkOSw=; b=P87IMW4VRr153SAbGQxEEV8lrapO25JkpPbZ8T/hx6hb/KxWICd5A1yp5U+owmuIXO +flaIe0AD8M8z28NmIMnbDDTKOodTbpZb478BPlc/1WOQJLFbUn+oODqPI+BojAumqBQ dk1N29FebE0RWGoEnBhosBZQ4LNY1igXiq6411Bhl5M0+oMszNLSvZYOS4KnHAyrcv5D kwpYygx9ghywcfj/hC3U+565Vywz+gSa2kZdJHNj229OmXrgc/Z3ZPJmEJf+rqFBSelp 9FxOuiHS4gcRN/IZVCof7tkhlwLAZbUobFVMOAkwGE64bQufSw75mKVU/lpqLeObfncL N/VA== X-Gm-Message-State: ACrzQf15Z/dWVFT2BLG9pfR9VdSgEPWOt4i7TMXVmOfehblyklMk9QE4 A1xpg/gjHchurZH+OOinlGY5iFHqP9jB0Q== X-Google-Smtp-Source: AMsMyM7+Cd5DR4gY5d0MhH+ioBKmp/iL3ixwiBNEV7lMAFAKFT1yJlwrA1Zn1cjn+9Cp3rLxiTt+HA== X-Received: by 2002:a0c:dc84:0:b0:4b1:8503:2c41 with SMTP id n4-20020a0cdc84000000b004b185032c41mr7825936qvk.6.1665235363311; Sat, 08 Oct 2022 06:22:43 -0700 (PDT) Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com. [209.85.128.170]) by smtp.gmail.com with ESMTPSA id bz23-20020a05622a1e9700b00394235898e3sm4315051qtb.75.2022.10.08.06.22.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Oct 2022 06:22:39 -0700 (PDT) Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-354c7abf786so66621847b3.0; Sat, 08 Oct 2022 06:22:38 -0700 (PDT) X-Received: by 2002:a0d:f905:0:b0:345:3b1b:a00d with SMTP id j5-20020a0df905000000b003453b1ba00dmr8585460ywf.510.1665235358102; Sat, 08 Oct 2022 06:22:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Tomek CEDRO Date: Sat, 8 Oct 2022 15:24:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: cross build toolchains for mc68000 To: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Ml5T048L5z3cYC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=Fo4doMHR; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::f34) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f34:from,209.85.128.170:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N Hello world :-) I would like to identify a cross platform development build toolchain for MC68000 targets such as 16-bit Atari and Amiga. I cannot quickly find such toolchain with `pkg search mc68000` nor `make quicksearch key=mc68000" in the ports tree. I did find some tools for 8-bit MOS6502 at port tree: make quicksearch key="6502" Port: acme-0.97.r319,1 Port: cc65-2.19 Port: dxa65-0.1.4 Port: vasm-1.8c Path: /usr/ports/devel/vasm Port: xa65-2.3.11 Port: p5-Acme-6502-0.77_2 Port: nesasm-20040314_1 Do we have such dedicated toolchains for MC68000? Maybe generic GCC/LLVM can generate binaries for those targert? Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Oct 8 13:34:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml5kM4sMDz4fNnS; Sat, 8 Oct 2022 13:34:19 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml5kL5qwYz3gSr; Sat, 8 Oct 2022 13:34:18 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 0835989291; Sat, 8 Oct 2022 13:34:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 298DYAXw012430 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 8 Oct 2022 13:34:10 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 298DY9A7012429; Sat, 8 Oct 2022 13:34:09 GMT (envelope-from phk) Message-Id: <202210081334.298DY9A7012429@critter.freebsd.dk> To: Tomek CEDRO cc: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Subject: Re: cross build toolchains for mc68000 In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12427.1665236049.1@critter.freebsd.dk> Date: Sat, 08 Oct 2022 13:34:09 +0000 X-Rspamd-Queue-Id: 4Ml5kL5qwYz3gSr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.dk]; FREEFALL_USER(0.00)[phk]; ARC_NA(0.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk] X-ThisMailContainsUnwantedMimeParts: N -------- Tomek CEDRO writes: > I would like to identify a cross platform development build toolchain > for MC68000 targets such as 16-bit Atari and Amiga. I think gcc is your best bet, but I'm not sure if contemporary gcc still has 68k support of if you have to use an older version. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Sat Oct 8 13:46:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml5z36Nqcz4fPsJ for ; Sat, 8 Oct 2022 13:45:19 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml5z26sxCz3hd7 for ; Sat, 8 Oct 2022 13:45:18 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qk1-x72c.google.com with SMTP id x13so1893688qkg.11 for ; Sat, 08 Oct 2022 06:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Yx3g0pXUWqo03sxatt5QhOAnxi807gb9WxJO8Dn0iEM=; b=iUXF71CRQKdZR3zc/1z4RhZW9fiiQD0uPnk3v0/s1kp7t8K/3IWeVZMZLdB3lrewk/ +Ht0A8FRs9xvLa4G8hc7Bun0zwibthg0phFqxW+7/f9FAoZL0+ZoVr+4gSO9+SmlwIkT TWr7loC00qt/JI517X0k+2MRf7xfpKniJatpQLN7nR0XoO3N8yh/bsEql0ZWPexibNNe Rf4hbwaEDjCDhkipEUnnCBSGusH+QAxEYpFBEiAwYd64lNpSK62E4GpK0OrYld8ts1H8 y+cLV6lDETy9DpqDFqSegx6D3XG/oCQ7u/8FruRacCv5JcE9ymIYBuR8CvFeTuh2tEZt 67fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Yx3g0pXUWqo03sxatt5QhOAnxi807gb9WxJO8Dn0iEM=; b=vrmEMjRSvsUAoe77ETLMMREr1zz4u/kLIdh6XquXicqOylBXB8V0VHUZIRHXdG5r9/ n3laW+f5+Sk4TV8+PyUdVOYMlhpBmIEM62NcH2Nu6z8lRqskoDH4XtN0usOqCLhFMXYk JSbagXefF5NlO9qbjDCnHCBReeLmQRb/FZktA7+XiE0jYdpt26D8v1hBqOQGyvCWuo7V m1LCS83hHt2Uw49Alo6ebUO3xk13xunvVaa/BgriAB2GdU14gsw6PDMjh4Q8+69raoO3 gREI2eWjndGduQeBvmTHWHo7Zby0n3C4Hp99j8IXZbZJeIopmhDFv+jDGIq174i4xqWc 8qHA== X-Gm-Message-State: ACrzQf1y/trpS8n65jlHtF3ucTa9itEec6SZmQbP25Km6UoMV4SEkP7d 4vP0L8/horF/yaP3tqgReGKv06AKl4idSw== X-Google-Smtp-Source: AMsMyM5fkdIs4e4iIPgY4IoqJFfrQUXO+HRSBnX/sMecAo0PBrimWTo184zTh2wQi4fFpiVrK6t8eQ== X-Received: by 2002:a37:aa43:0:b0:6eb:f80:ec46 with SMTP id t64-20020a37aa43000000b006eb0f80ec46mr2018586qke.106.1665236717791; Sat, 08 Oct 2022 06:45:17 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id s2-20020a05620a29c200b006cbdc9f178esm4705162qkp.25.2022.10.08.06.45.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Oct 2022 06:45:10 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id 207so8619552ybn.1; Sat, 08 Oct 2022 06:45:09 -0700 (PDT) X-Received: by 2002:a25:6611:0:b0:6bd:2d:6992 with SMTP id a17-20020a256611000000b006bd002d6992mr9689563ybc.173.1665236709102; Sat, 08 Oct 2022 06:45:09 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202210081334.298DY9A7012429@critter.freebsd.dk> In-Reply-To: <202210081334.298DY9A7012429@critter.freebsd.dk> From: Tomek CEDRO Date: Sat, 8 Oct 2022 15:46:47 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: cross build toolchains for mc68000 To: Poul-Henning Kamp Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Ml5z26sxCz3hd7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=iUXF71CR; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::72c) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72c:from,209.85.219.172:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 8, 2022 at 3:34 PM Poul-Henning Kamp wrote: > Tomek CEDRO writes: > > I would like to identify a cross platform development build toolchain > > for MC68000 targets such as 16-bit Atari and Amiga. > > I think gcc is your best bet, but I'm not sure if contemporary gcc > still has 68k support of if you have to use an older version. TANK U SIR! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Oct 8 13:47:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml61S3Xr6z4fQFW; Sat, 8 Oct 2022 13:47:24 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml61R10N8z3kZh; Sat, 8 Oct 2022 13:47:23 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 298Dl9Ss099079 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Oct 2022 15:47:10 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1665236830; bh=M/hIrc8yLAjy0Qu6GChxtTn8jvpqPLU21PtB49IqR6Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=L02eVzOjkb7CxrCXrR+58xBVmf3dQsfBQUBeUEeP+FGdkVCjqJpMl/Ov8Ctk/8lhg GATSZ47k+r3cYhPg6XvdcOuAIeUt83UGST/noXrwc7MACd6L/VPkgCrQb90si1Majn Bk7lLHEsjK7QSuwJ3HRYf0wbtzTQLpEPerrKS3lo= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 298Dl9Zp016878; Sat, 8 Oct 2022 15:47:09 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 298Dl9iZ016875; Sat, 8 Oct 2022 15:47:09 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sat, 8 Oct 2022 15:47:09 +0200 (CEST) From: Wojciech Puchar To: Tomek CEDRO cc: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Subject: Re: cross build toolchains for mc68000 In-Reply-To: Message-ID: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Ml61R10N8z3kZh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=L02eVzOj; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N AFAIK gcc dropped this support so find out what version still supported 68k and download sources and simply compile it from scratch. For sure there are support for Amiga hunk and Atari prg executable format > Hello world :-) > > I would like to identify a cross platform development build toolchain > for MC68000 targets such as 16-bit Atari and Amiga. > > I cannot quickly find such toolchain with `pkg search mc68000` nor > `make quicksearch key=mc68000" in the ports tree. > > I did find some tools for 8-bit MOS6502 at port tree: > make quicksearch key="6502" > Port: acme-0.97.r319,1 > Port: cc65-2.19 > Port: dxa65-0.1.4 > Port: vasm-1.8c > Path: /usr/ports/devel/vasm > Port: xa65-2.3.11 > Port: p5-Acme-6502-0.77_2 > Port: nesasm-20040314_1 > > Do we have such dedicated toolchains for MC68000? Maybe generic > GCC/LLVM can generate binaries for those targert? > > Any hints welcome :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > From nobody Sat Oct 8 14:01:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml6J64Xyjz4fRKh for ; Sat, 8 Oct 2022 14:00:06 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml6J460w2z3mL2 for ; Sat, 8 Oct 2022 14:00:04 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qt1-x835.google.com with SMTP id y20so4316228qtv.5 for ; Sat, 08 Oct 2022 07:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HRr1rtK7Tf1HXX7m7KHLXEHLLQ0XYc6QvgQW8m7qP6A=; b=E+wDgHwz81cCXOhsKlVKqbs0GBWY6sJbjfV20sdbP45M1VWO8C2/p6l5/0HCvEP1Iy QS89WC75+AnmAUKRZJkMvVmbrZi9OFzVJT+ohBK6gA+nxINTSlGjIT0G8xUs+MFw1VSS NhEw8yvrngWT732++VbiahhPXvTi5EEtpX8c8W2SDPgQDktZiJUEB8NwBGcq+Q9115Du +ZiO4lVvatSeBwVN1tUq7J+QhN4GKX9x43FqesAMCss8dxeLN57r6tZwgYOuU4Fi9q95 m7tWCrQJxtmKPKzNHv4PFl/+Gi4xiE+x+i6C3F8/MWy1VFdlIY35nIJaKtYgR95AHnOA /8SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HRr1rtK7Tf1HXX7m7KHLXEHLLQ0XYc6QvgQW8m7qP6A=; b=0zosO0cRR1iH1M+quPMXjb68BhfEPoavbtIiptYlDP7xC/lC0LZq9MV0yEtTKc0/lH xYjIg+FmbmT0viu7Qf1H7i25DuonB0GJdhNqu611jolcjxZb4EjXONA9BsNQXRtbU9Ig /2Vn6r4CsnOpWvf4c7NZEBv4CUSH1rM83SwQa49LEFE3v3mlWR+ykZNmubfkwfJH/OIZ r8B7JANrAWr4vlgU++6//4TOpnLuBp6DvI/1bdN/x9cA/tIyMnOmTNGPo3zzmjClqNjj +dKwLwxOwEkHTH1G9ltf4Wz4R3ONiZ5VaFOGJiJpbw9AezJGQue55xk+NNcK1ngrV6fF 6MvA== X-Gm-Message-State: ACrzQf1JW7iFKLCcKRbzQlNS/NCwG/Ha91D2n2yhc9KWFUvOMu5G1UIv GH+hNIjQGfFeJX37xPR1BMLU8/KzExm6fQ== X-Google-Smtp-Source: AMsMyM51UDPk8/2tI5oz/MWLWpS7ulJ3bp9dfyDBxN4FdvVmz3c3kc1KLpmLs3RsgK6OtYkCdARHIA== X-Received: by 2002:ac8:5910:0:b0:364:b851:7379 with SMTP id 16-20020ac85910000000b00364b8517379mr8220844qty.369.1665237603469; Sat, 08 Oct 2022 07:00:03 -0700 (PDT) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com. [209.85.219.182]) by smtp.gmail.com with ESMTPSA id bs32-20020a05620a472000b006e54251993esm4837867qkb.97.2022.10.08.07.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Oct 2022 07:00:01 -0700 (PDT) Received: by mail-yb1-f182.google.com with SMTP id t186so3094862yba.12; Sat, 08 Oct 2022 07:00:01 -0700 (PDT) X-Received: by 2002:a25:cf87:0:b0:6be:6c1b:cafb with SMTP id f129-20020a25cf87000000b006be6c1bcafbmr9327911ybg.402.1665237601201; Sat, 08 Oct 2022 07:00:01 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> In-Reply-To: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> From: Tomek CEDRO Date: Sat, 8 Oct 2022 16:01:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: cross build toolchains for mc68000 To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Ml6J460w2z3mL2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=E+wDgHwz; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::835) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.182:received,2607:f8b0:4864:20::835:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: > > AFAIK gcc dropped this support so find out what version still supported > 68k and download sources and simply compile it from scratch. > > For sure there are support for Amiga hunk and Atari prg executable format Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and Amiga Kickstart replacement one day.. as for now I am researching toolchains on FreeBSD as NuttX is close to 11.0 release :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Sat Oct 8 16:02:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ml9161vVPz4V1JG; Sat, 8 Oct 2022 16:02:18 +0000 (UTC) (envelope-from garyj@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ml9146bvjz3y6r; Sat, 8 Oct 2022 16:02:16 +0000 (UTC) (envelope-from garyj@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1665244932; bh=DTdIViAthucBO+34E749aIAKgDgx11J646sIYutDHz8=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References: Reply-To; b=BSUCENSFCeOYLDmCW8DboYrwPWIjNs2fZDvBMe9GXWWtWI3f+xuE1j8V0ilcSPj5m WwJ++6T0ErNLcaVd30l3+XQxZW+L8+q4MBCIX/4Y6rEY3632cIZqCIJyQ4YfGGEfgD 1JT2/6kgzEOTJQoeSFezT1TB/kIMlBrZdTICPqas= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from ernst.home ([217.226.63.123]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mi2Nv-1pKMeT2lvN-00e3Sx; Sat, 08 Oct 2022 18:02:12 +0200 Date: Sat, 8 Oct 2022 18:02:10 +0200 From: Gary Jennejohn To: Tomek CEDRO Cc: Wojciech Puchar , freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Subject: Re: cross build toolchains for mc68000 Message-ID: <20221008180210.3afb188f@ernst.home> In-Reply-To: References: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> Reply-To: garyj@gmx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:x/Ol/lSjFPXSSp27c08V5etsBwnxuY7o7bp+ez9pSXYsFWoIyI7 9J2EPwsc60h2aP0+ck5gfR8X7NiJv/MzrEMvbypT3z619g5STLogwaLm/KjYhAWpuDHlyzU 13y/4OhImxafBcA6GI2TvXTotA9+uOYzj0trh+tObSIIoiBaVW6GKHB+6kDs9wUNFrnGq13 HGojavaJOIFg7x/7vrCAQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:aWw9eDd/JIc=:mzWV6r59Cl3sv/bMkBLtxf ekmRaBC7qJjtgmx6PPSIVqIpXeS+ZvmP5zdLgj5maRuSXFIffwfMGvQoo85TbfACbTvxkma8e e249XiquDkYs0gxEdpohYTj8xjl+mDbR5b+hVhTCzawyNNaJ5A/RT9UMBl2ApHelXwGvLmXO1 ydebDsVZo0PZT2yVfXN96L70CDPO7wiSasOcNnihat65yB7/YRXUbsXn0Gnqd11/u5jLFzWv2 qb+lYZGQuby0CxymRHqPD5Lf/het+bmz03qVMcYco1NscnVTvWhfL/1OBGGMCMbn7D7vGw/iH UZlwPe2+jHXNrwYbiefwKXFW8+O0W3sSou2/W6DlyOrzC1kHV9fmtiOiZQtuMOKATPGNk8LFi oefqx2LbciKfxKfsBqZufUYESPGVSUy4w6Dn3uXU+epSirPM7ZnTNVGimEONh3IBw5vzTL5y3 9hPYCzNZeh7s/sFNsFzkVFraN3YRqM7qgJAS+XKuCU6ZFEZyxKfFQm5tsvOCGIDAQBvfpc56A pgFKlGrqee3kbAoK2HIUgdkHr/NwGLTio8LPWnuWBNmHu6KqvQKQhEzXgb4X+WbvGn9S+Qeya kvI6mP7n8W0CaCY8QXopCXM+Gm6og++SC/YaAou/evn/qNKe9kSMbqo58vLk9AWbnL6bBoeA+ 4Qhnmy8LM9tOgfS6NngNnpasoVE4Ruo7iVeZ79SUTknVQYx/KWD4l4Aye6caq9sET0qZ6BxuD RFws1SlEvw6URB+WHYX4f+fX5VQ3Oj+rDEgZcEPkWLcHcWseh55eRNJ2gQAah2rsi8GB0Q5Ib ORyAqjqkrIk2ccapuyMsFruUhEvMVGr9HTAzGRHECLJu9CgjwckI+nSqbLG6qcwhLG8+QQs7b kfhhm8Le29rXFTdxlOMuBiqGx5Co9yAn/oGYX6LpbH4L8JIEEd10+NNtoXSYQmrrFVielgtPn aNxpR8NDsG4v9bFGThuBR8Vhs4aw2FIFjG6jmn39MSj1v2yiIW+SPbHOAU0MwDsseYK/MI77G N74W8GPkh84Ae8WPGO+MtGvu5YLogQ0LLSQfDI/F0aJ5yyoNVH3OHcSYsdezLzjd9vsDmPEBc MVGWWnuuTJlShxvCdR9ADjWfjeaRF0bqJqUVzYlTxILw7OCSxXPv9aeVUtTFkB7RET/oqa4zO VQjhu0PhK+/yRlPOu3OVwB35zDiTok063UrPxb0S4IGWfUKG1pAaPW0X0nxRuKKOdbn/pcEJK vtCL6W0ij2mmyUqIIRhJRbTdiQwvwXo+QFUNy4sxgCeX+lu1ppxAapWM377y0J/2ni10rjEXa OCymEScKPu8yzKLYARP1UI2cX2qJmJ8TEEg7yV0+8tleOlpudr+6iYdVYE3ZzjVvQFFNq3G1/ 1WgyE+IFxaSzhHgrBQCHYcajdt7Q5DPCIssRUetGjnmsSUyBEXmT1gJN6VcGEtwf2/hnOJeDn ukdBZAUl/WfyhTcNa5k5+dTdYUCDy3LiiUAAN9IAQqDOvJ4c0mNq4eZoR2AKXW7zHy++Xzc8D +ci/ESvTAfEYtXEs+z4wbeNv9AfBuOxDF4RNMGPPh4QAu X-Rspamd-Queue-Id: 4Ml9146bvjz3y6r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=BSUCENSF; dmarc=pass (policy=none) header.from=gmx.de; spf=pass (mx1.freebsd.org: domain of garyj@gmx.de designates 212.227.15.19 as permitted sender) smtp.mailfrom=garyj@gmx.de X-Spamd-Result: default: False [-4.14 / 15.00]; DWL_DNSWL_LOW(-1.00)[gmx.net:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmx.de,none]; R_SPF_ALLOW(-0.20)[+ip4:212.227.15.0/25]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; NEURAL_HAM_MEDIUM(-0.04)[-0.038]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmx.de]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[garyj@gmx.de]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; FREEMAIL_FROM(0.00)[gmx.de]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; REPLYTO_ADDR_EQ_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; FREEMAIL_ENVFROM(0.00)[gmx.de]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, 8 Oct 2022 16:01:39 +0200 Tomek CEDRO wrote: > On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: > > > > AFAIK gcc dropped this support so find out what version still supporte= d > > 68k and download sources and simply compile it from scratch. > > > > For sure there are support for Amiga hunk and Atari prg executable for= mat > > Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and > Amiga Kickstart replacement one day.. as for now I am researching > toolchains on FreeBSD as NuttX is close to 11.0 release :-) > According to the NetBSD gcc man page their version still supports mc680x0 CPUs. The date on the man page is 2022, so you might want to take a look at the current NetBSD gcc source. =2D- Gary Jennejohn From nobody Sun Oct 9 07:28:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MlYYh1f08z4f1RX; Sun, 9 Oct 2022 07:28:24 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org (mail.bsd4all.org [88.99.169.216]) by mx1.freebsd.org (Postfix) with ESMTP id 4MlYYg2953z4J4r; Sun, 9 Oct 2022 07:28:23 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org (localhost [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id A52AA86B1; Sun, 9 Oct 2022 09:28:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by mail.bsd4all.org (mail.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5XtMF9TFkpP; Sun, 9 Oct 2022 09:28:18 +0200 (CEST) Received: from smtpclient.apple (pony_ip [204.168.249.121]) by mail.bsd4all.org (Postfix) with ESMTPSA id 982D48706; Sun, 9 Oct 2022 09:28:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Peter Blok List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: cross build toolchains for mc68000 Date: Sun, 9 Oct 2022 09:28:14 +0200 Message-Id: <2BD55DAF-9459-41D7-9BFC-78C95D7234D8@bsd4all.org> References: <20221008180210.3afb188f@ernst.home> Cc: Tomek CEDRO , Wojciech Puchar , freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List In-Reply-To: <20221008180210.3afb188f@ernst.home> To: garyj@gmx.de X-Mailer: iPad Mail (19H12) X-Rspamd-Queue-Id: 4MlYYg2953z4J4r X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pblok@bsd4all.org designates 88.99.169.216 as permitted sender) smtp.mailfrom=pblok@bsd4all.org X-Spamd-Result: default: False [-2.69 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmx.de]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; DMARC_NA(0.00)[bsd4all.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Perhaps the Amsterdam Compiler Kit is usable for you Peter Sent from my iPad > On 8 Oct 2022, at 18:02, Gary Jennejohn wrote: >=20 > =EF=BB=BFOn Sat, 8 Oct 2022 16:01:39 +0200 > Tomek CEDRO wrote: >=20 >>> On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: >>>=20 >>> AFAIK gcc dropped this support so find out what version still supported >>> 68k and download sources and simply compile it from scratch. >>>=20 >>> For sure there are support for Amiga hunk and Atari prg executable forma= t >>=20 >> Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and >> Amiga Kickstart replacement one day.. as for now I am researching >> toolchains on FreeBSD as NuttX is close to 11.0 release :-) >>=20 >=20 > According to the NetBSD gcc man page their version still supports mc680x0 > CPUs. The date on the man page is 2022, so you might want to take a look > at the current NetBSD gcc source. >=20 > -- > Gary Jennejohn >=20 From nobody Sun Oct 9 15:10:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mllps43CNz4ds3H for ; Sun, 9 Oct 2022 15:10:29 +0000 (UTC) (envelope-from hans@beastielabs.net) Received: from ewsoutbound.kpnmail.nl (ewsoutbound.kpnmail.nl [195.121.94.185]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mllpr06wwz3Vhj for ; Sun, 9 Oct 2022 15:10:27 +0000 (UTC) (envelope-from hans@beastielabs.net) X-KPN-MessageId: 6f52bb04-47e4-11ed-bfe8-005056999439 Received: from smtp.kpnmail.nl (unknown [10.31.155.7]) by ewsoutbound.so.kpn.org (Halon) with ESMTPS id 6f52bb04-47e4-11ed-bfe8-005056999439; Sun, 09 Oct 2022 17:09:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kpnmail.nl; s=kpnmail01; h=content-type:from:to:subject:mime-version:date:message-id; bh=sdGTxFFQQ+Lu2sQ5RQHOA+MVNfnazitbS3o3KLaJeFo=; b=in/k6Eyj/kWQgP9N6MgzjhhQ4+nySgAuCBMaETODbD9ew6A9tql7vWxa797uhEEBCK6OxKWSgXKxP O01sy+Gsdq4tLCduxco0sBXdT11pbdLYFiAZD1gP/VO3uVo59oikYZSarZ9x7ivEeZpSE4R/HK4ITL 3+rrrUDqqZchiZMk= X-KPN-MID: 33|x+0jNfqhOUzVwQQ6F1baQNS2H9nZMa4SrDbm4gI55vdiIQXPrHc60yzSyrfX/IR WSySJf5BBRN2+E1nrQPH7ig== X-KPN-VerifiedSender: No X-CMASSUN: 33|40dB93itKus6euFtIsAVEu4HFiE97WvByOAj63KfXVSrIznPA9Mvs+VSPkOVlfG K6P+gKqzb1ZZ1bj8ZuJ6YXQ== X-Originating-IP: 77.171.212.158 Received: from [192.168.66.163] (77-171-212-158.fixed.kpn.net [77.171.212.158]) by smtp.xs4all.nl (Halon) with ESMTPSA id 6c6e636b-47e4-11ed-8bc9-005056998788; Sun, 09 Oct 2022 17:09:52 +0200 (CEST) Message-ID: <93ad6766-ff31-0765-df4f-37346ab27f27@beastielabs.net> Date: Sun, 9 Oct 2022 17:10:24 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: cross build toolchains for mc68000 Content-Language: en-US To: Tomek CEDRO , Wojciech Puchar Cc: freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List References: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> From: Hans Ottevanger In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mllpr06wwz3Vhj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=kpnmail.nl header.s=kpnmail01 header.b="in/k6Eyj"; dmarc=none; spf=none (mx1.freebsd.org: domain of hans@beastielabs.net has no SPF policy when checking 195.121.94.185) smtp.mailfrom=hans@beastielabs.net X-Spamd-Result: default: False [-3.39 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.988]; R_DKIM_ALLOW(-0.20)[kpnmail.nl:s=kpnmail01]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[195.121.94.185:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:8737, ipnet:195.121.64.0/18, country:NL]; DKIM_TRACE(0.00)[kpnmail.nl:+]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; HAS_XOIP(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[beastielabs.net]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 10/8/22 16:01, Tomek CEDRO wrote: > On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: >> >> AFAIK gcc dropped this support so find out what version still supported >> 68k and download sources and simply compile it from scratch. >> >> For sure there are support for Amiga hunk and Atari prg executable format > > Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and > Amiga Kickstart replacement one day.. as for now I am researching > toolchains on FreeBSD as NuttX is close to 11.0 release :-) > There were plans to drop m68k support in GCC version 11 if certain required changes were not made. Someone made those changes, so after all m68k support remained and is present and working, even in GCC 12. However, the number of readily available host/target combinations for cross compiling is quite limited these days, so you will be mostly on your own there. I made a cross development environment for Minix-68k (mostly Atari ST and TT), hosted on FreeBSD, but also working on Linux and Mac. Maybe you could use that as a starting point. It currently works up to GCC 12.2, for C, C++ and Fortran. See http://www.beastielabs.net/crossdev.html. If you need further discussion, you can contact me off-list. -- Kind regards, Hans Ottevanger Eindhoven, Netherlands hans@beastielabs.net www.beastielabs.net From nobody Mon Oct 10 06:41:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mm8T11Sn2z4df98; Mon, 10 Oct 2022 06:41:25 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mm8Sz4pnGz3Qgv; Mon, 10 Oct 2022 06:41:23 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 29A6fC0i022726 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Oct 2022 08:41:13 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1665384073; bh=fRfYmC0bmNds7RfXLqKuQYIHOtijOuYxMRRbWqkMhbw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fCEHCqrvyomvxsP2k+LSBP+MoI0TGGCdHWYJWRzXKmznDX8rWRiFyDOJH40I+sIrf drrekETJOgKfQms4xAYyfXU0EXU+R/42EANL3n7+7r0QnBnsUWUFJWXhi0VChnfuJn VfKW0BzcxchYmPv2z3yqawICqPICU2Vn+xkJqbYM= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 29A6fCx8028957; Mon, 10 Oct 2022 08:41:12 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 29A6f9MK028954; Mon, 10 Oct 2022 08:41:09 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 10 Oct 2022 08:41:09 +0200 (CEST) From: Wojciech Puchar To: Peter Blok cc: garyj@gmx.de, Tomek CEDRO , freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Subject: Re: cross build toolchains for mc68000 In-Reply-To: <2BD55DAF-9459-41D7-9BFC-78C95D7234D8@bsd4all.org> Message-ID: <47866f8a-ba9-128d-dfce-37146f63725@puchar.net> References: <20221008180210.3afb188f@ernst.home> <2BD55DAF-9459-41D7-9BFC-78C95D7234D8@bsd4all.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3974694515-1952749630-1665384072=:28953" X-Rspamd-Queue-Id: 4Mm8Sz4pnGz3Qgv X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=fCEHCqrv; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-2.50 / 15.00]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_CC(0.00)[gmx.de,cedro.info,freebsd.org]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; DMARC_NA(0.00)[puchar.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-1952749630-1665384072=:28953 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Perhaps the Amsterdam Compiler Kit is usable for you Not highly optimizing compiler VBCC would be better choice > > Peter > > Sent from my iPad > >> On 8 Oct 2022, at 18:02, Gary Jennejohn wrote: >> >> ďťżOn Sat, 8 Oct 2022 16:01:39 +0200 >> Tomek CEDRO wrote: >> >>>> On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: >>>> >>>> AFAIK gcc dropped this support so find out what version still supported >>>> 68k and download sources and simply compile it from scratch. >>>> >>>> For sure there are support for Amiga hunk and Atari prg executable format >>> >>> Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and >>> Amiga Kickstart replacement one day.. as for now I am researching >>> toolchains on FreeBSD as NuttX is close to 11.0 release :-) >>> >> >> According to the NetBSD gcc man page their version still supports mc680x0 >> CPUs. The date on the man page is 2022, so you might want to take a look >> at the current NetBSD gcc source. >> >> -- >> Gary Jennejohn >> > > --3974694515-1952749630-1665384072=:28953-- From nobody Mon Oct 10 07:38:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mm9l32kqFz4dllh; Mon, 10 Oct 2022 07:38:39 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mm9l1738Kz3Td8; Mon, 10 Oct 2022 07:38:37 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-yb1-xb31.google.com with SMTP id 126so12117661ybw.3; Mon, 10 Oct 2022 00:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=AJv+mPOKBDCL9x4iiosyCT7eqW/7MVKk5D7v6pGiL6E=; b=Uti8WZ6uW/F2pnTcBwYPb+djzZvZdEHuMuJYzBxdktn9QY2Fg8JcES5u4n2+LqWp8N 0R30/spZdg8iPNwZS6vEnXKZ6k76Yx8U8Bfr85PjMQpcHzHaaPHb8JWoxy83wi59IEtY GBjvRTArK+oLbcsIjOJ8VDNH01uHyw+SHGcjZx+SGMN2wjIGYv9rCsiDZUOtPI0N5jrN hm+iDsh+qO3NT0boP7fFq1zr2/OrurW3QLmg2xLOSMVoQlPYfwIxZw1f8B3lUNnRH0cg mJ/9DT/jbRMW5VZAQRbR864T2buZHbuiktLqBug/KR3y4IdkHlD9WOdBa5CahVGTocB+ 3PUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AJv+mPOKBDCL9x4iiosyCT7eqW/7MVKk5D7v6pGiL6E=; b=fKAbgueR7pSIZEhKtIndELs3PZrTBYa/pPu+ef0BYPkFhBPE6PyKlW1wBotHG4tbJu Mhk6ETdcEYTlt6FlBCmHAWehb07zWFz4u7sArKsx33rLOKaxh47NjI35Fv40Fmr58jfu 6GGWL7NrG8nCNPg5Xp/7sXuyxHhU8p+KNXMIW1E2IQHmSYyRSNnc3OjPmH5Gpwshe1qr OoqXdHV7bOjoTqhIaaOr5fwwHcDRTcyZYXw9DDejm7sxJTgZvpnuSxnTyNylcCDOISSV 28ObYp1Hgzau3RJ3XdcblMtG+cSizBdo1QimlZH3XlD2UTYX1qQOeNRdxjJUtg4nz657 8jag== X-Gm-Message-State: ACrzQf3MYpTdNDf+LF0vgruEAW2A3mjV/lFxrw2MG0463R4ymYpCMgYe OCy9/6Z35PCU/KqR6QU84E/KqMARrFBSDeU+k7g= X-Google-Smtp-Source: AMsMyM4iQLNZ6yv2rizc1x4DTroe+DwHf7RURHmYB4GCe2R6aESq2POCrzLco72otrkaXN+Vy0T4+vmpQdTWk37Xkro= X-Received: by 2002:a05:6902:4e1:b0:6bd:bc66:86db with SMTP id w1-20020a05690204e100b006bdbc6686dbmr17077901ybs.277.1665387516923; Mon, 10 Oct 2022 00:38:36 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221008180210.3afb188f@ernst.home> <2BD55DAF-9459-41D7-9BFC-78C95D7234D8@bsd4all.org> <47866f8a-ba9-128d-dfce-37146f63725@puchar.net> In-Reply-To: <47866f8a-ba9-128d-dfce-37146f63725@puchar.net> From: Mehmet Erol Sanliturk Date: Mon, 10 Oct 2022 10:38:00 +0300 Message-ID: Subject: Re: cross build toolchains for mc68000 To: Wojciech Puchar Cc: Peter Blok , garyj@gmx.de, Tomek CEDRO , freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Content-Type: multipart/alternative; boundary="0000000000005c11e205eaa93fc7" X-Rspamd-Queue-Id: 4Mm9l1738Kz3Td8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Uti8WZ6u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of m.e.sanliturk@gmail.com designates 2607:f8b0:4864:20::b31 as permitted sender) smtp.mailfrom=m.e.sanliturk@gmail.com X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.89)[-0.889]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b31:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_CC(0.00)[bsd4all.org,gmx.de,cedro.info,freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000005c11e205eaa93fc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 10, 2022 at 9:41 AM Wojciech Puchar wrote: > > Perhaps the Amsterdam Compiler Kit is usable for you > > Not highly optimizing compiler > > VBCC would be better choice > > https://en.wikipedia.org/wiki/Vbcc vbcc http://www.compilers.de/vbcc.html Dr. Volker Barthelmann=C2=B4s Compiler Page vbcc - portable ISO C compiler ( For legal rules , please see : http://www.ibaug.de/vbcc/doc/vbcc.pdf ) With my best wishes . Mehmet Erol Sanliturk > > > > Peter > > > > Sent from my iPad > > > >> On 8 Oct 2022, at 18:02, Gary Jennejohn wrote: > >> > >> =EF=BB=BFOn Sat, 8 Oct 2022 16:01:39 +0200 > >> Tomek CEDRO wrote: > >> > >>>> On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: > >>>> > >>>> AFAIK gcc dropped this support so find out what version still > supported > >>>> 68k and download sources and simply compile it from scratch. > >>>> > >>>> For sure there are support for Amiga hunk and Atari prg executable > format > >>> > >>> Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and > >>> Amiga Kickstart replacement one day.. as for now I am researching > >>> toolchains on FreeBSD as NuttX is close to 11.0 release :-) > >>> > >> > >> According to the NetBSD gcc man page their version still supports > mc680x0 > >> CPUs. The date on the man page is 2022, so you might want to take a > look > >> at the current NetBSD gcc source. > >> > >> -- > >> Gary Jennejohn > >> > > > > --0000000000005c11e205eaa93fc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 10, 2022= at 9:41 AM Wojciech Puchar <wojtek= @puchar.net> wrote:
> Perhaps the Amsterdam Compiler Kit is usable for you

Not highly optimizing compiler

VBCC would be better choice


<= br>

http://www.= compilers.de/vbcc.html
Dr. Volker Barthelmann=C2=B4s
Compiler Pag= e
vbcc - portable ISO C compiler

( For legal ru= les , please see : http://www.ibaug.de/vbcc/doc/vbcc.pdf )

<= /div>

With my best wishes .
Mehmet Erol Sanliturk



=C2=A0
>
> Peter
>
> Sent from my iPad
>
>> On 8 Oct 2022, at 18:02, Gary Jennejohn <garyj@gmx.de> wrote:
>>
>> =EF=BB=BFOn Sat, 8 Oct 2022 16:01:39 +0200
>> Tomek CEDRO <tomek@cedro.info> wrote:
>>
>>>> On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote:
>>>>
>>>> AFAIK gcc dropped this support so find out what version st= ill supported
>>>> 68k and download sources and simply compile it from scratc= h.
>>>>
>>>> For sure there are support for Amiga hunk and Atari prg ex= ecutable format
>>>
>>> Thanks Wohciech :-) I would like to port NuttX RTOS as Atari T= OS and
>>> Amiga Kickstart replacement one day.. as for now I am research= ing
>>> toolchains on FreeBSD as NuttX is close to 11.0 release :-) >>>
>>
>> According to the NetBSD gcc man page their version still supports = mc680x0
>> CPUs.=C2=A0 The date on the man page is 2022, so you might want to= take a look
>> at the current NetBSD gcc source.
>>
>> --
>> Gary Jennejohn
>>
>
>
--0000000000005c11e205eaa93fc7-- From nobody Mon Oct 10 17:27:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MmQpD4L8Cz4fqkn for ; Mon, 10 Oct 2022 17:27:16 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmQpC5pHvz4M19 for ; Mon, 10 Oct 2022 17:27:15 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qt1-x82e.google.com with SMTP id bb5so1526645qtb.11 for ; Mon, 10 Oct 2022 10:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8/M2tFbGaF7FsCGcUyzzTRzoBuRTAwAe1H2qC13G2m0=; b=GOX++pM8/eNzNhFxGMw8/wQZP23zOBX3WPm16zC6pp8BRIflNUQtbQ7FJU7Kya0+7X KIWEAeZYS3Mb4nXaGpSBO6fqGXOiTEyVj166o77r+h5H8Zq/6U3C8u9wbhVq1Ppt8I0a FI6YEv/Q5mmzwCJrxrSlSCk4uh1tiYwgFr5EKkftiwlP+mhQPI/xsg+mgUYSJ+hCHG8+ +p6PWrCv+QLT+Kwoa8dgxUYaoXm2fpHbySRx48sSv42jIHDb7WEs5hmEjVGKnYQSGHU8 5rkKP4CXorxtSYeYYnJe03xoNIszNHEPcop2AVNQ/oO00xRyeNO9tF645l/DgjhqGvg/ xhFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8/M2tFbGaF7FsCGcUyzzTRzoBuRTAwAe1H2qC13G2m0=; b=fm6MjPH1nQhqjSWMqj0/ONjHQH2zqvpi7bOIfXvR2jy2A2jPKrBP8+I4kDQbFzwmDC 5VmPCQYI3VWZhJzZUSV5eURp4gB+Hmk/HA4g94/sSlgCtUJqYYws+257Gp7pDz4sgq5e oX1o2ON67DynGeUyAsPIVjQ1uTOe/YpNeSbv+S6abpCROnbBT301q/bbmEcQgIOAOlBX 855QDuLt6WRyQM3Zz2Gw7j76CHXncUbGo1aLugZ8LN9x57nzVwbqxoKY+93gwD4VuMtz b3B8RuStdWdJ+a27dEGioLZM7IJMgIwiHZBG6xhraY6XI4IxFsljhNIDuRld9Fh/YCVV 90uw== X-Gm-Message-State: ACrzQf2bTGsErnpZntW35+Uq8jcHzRzCxLaUn4gea5Bmz3YTdRJA8du9 FFYB84jXjjPwvEnOJB8Jtn0JfPDifEiKyQ== X-Google-Smtp-Source: AMsMyM5303VP9+Kf9P08f7RvzbBRGbhCMj0qQXw+JR0K36ZGiv99as4qk9QaVKqUZCtzD2rUO2OWQw== X-Received: by 2002:ac8:7fc1:0:b0:35c:be1b:2831 with SMTP id b1-20020ac87fc1000000b0035cbe1b2831mr15780234qtk.353.1665422835016; Mon, 10 Oct 2022 10:27:15 -0700 (PDT) Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com. [209.85.219.178]) by smtp.gmail.com with ESMTPSA id ga25-20020a05622a591900b0035d1f846b91sm8880724qtb.64.2022.10.10.10.27.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 10:27:14 -0700 (PDT) Received: by mail-yb1-f178.google.com with SMTP id 81so13744498ybf.7; Mon, 10 Oct 2022 10:27:14 -0700 (PDT) X-Received: by 2002:a25:cf87:0:b0:6be:6c1b:cafb with SMTP id f129-20020a25cf87000000b006be6c1bcafbmr18679615ybg.402.1665422833736; Mon, 10 Oct 2022 10:27:13 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <608a3c62-3f85-684-c9ac-9fe3f7b76b@puchar.net> <93ad6766-ff31-0765-df4f-37346ab27f27@beastielabs.net> In-Reply-To: <93ad6766-ff31-0765-df4f-37346ab27f27@beastielabs.net> From: Tomek CEDRO Date: Mon, 10 Oct 2022 19:27:02 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: cross build toolchains for mc68000 To: Hans Ottevanger Cc: Wojciech Puchar , freebsd-hackers@freebsd.org, FreeBSD Questions Mailing List Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MmQpC5pHvz4M19 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=GOX++pM8; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::82e) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82e:from,209.85.219.178:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 9, 2022 at 5:10 PM Hans Ottevanger wrote: > On 10/8/22 16:01, Tomek CEDRO wrote: > > On Sat, Oct 8, 2022 at 3:47 PM Wojciech Puchar wrote: > >> > >> AFAIK gcc dropped this support so find out what version still supported > >> 68k and download sources and simply compile it from scratch. > >> > >> For sure there are support for Amiga hunk and Atari prg executable format > > > > Thanks Wohciech :-) I would like to port NuttX RTOS as Atari TOS and > > Amiga Kickstart replacement one day.. as for now I am researching > > toolchains on FreeBSD as NuttX is close to 11.0 release :-) > > > > There were plans to drop m68k support in GCC version 11 if certain > required changes were not made. Someone made those changes, so after all > m68k support remained and is present and working, even in GCC 12. > However, the number of readily available host/target combinations for > cross compiling is quite limited these days, so you will be mostly on > your own there. > > I made a cross development environment for Minix-68k (mostly Atari ST > and TT), hosted on FreeBSD, but also working on Linux and Mac. Maybe you > could use that as a starting point. It currently works up to GCC 12.2, > for C, C++ and Fortran. See http://www.beastielabs.net/crossdev.html. > > If you need further discussion, you can contact me off-list. Thank You Hans! That looks like a perfect bootstrap of the mc68k build environment with results that can be verified out-of-the box! :-) Have you considered moving your mc68k toolchain and maybe even Minix to FreeBSD Ports so anyone could build is / install with pkg? :-) I will send further questions in a private messages :-) Thank you! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu Oct 13 22:48:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpPnF59jcz4fqJV for ; Thu, 13 Oct 2022 22:48:17 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpPnD3P5Dz4DGP for ; Thu, 13 Oct 2022 22:48:15 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 29DMm69l033768 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2022 00:48:07 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1665701287; bh=eFKAHUgQfTC6edr2t3SP1TuY0GjezV837buSB6IdITQ=; h=Date:From:To:Subject; b=tCDeS6ypLajn6t2lkW5mhuWtdrzodhMVaTR0lEUjt0zNlhtbnuUxdpae1PWG9hDEZ Q4I7fPvJfkVW1mWTBtQc7Pc2eGO4UZRFPk9IvH4nJcnrWf/7G0zTh9RsgO0/eTrOLQ 30oqR7Ix6kvSKjTBHMsR/3Pj6be2B8d/qfFmYeEY= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 29DMm5KL007894 for ; Fri, 14 Oct 2022 00:48:05 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 29DMm358007891 for ; Fri, 14 Oct 2022 00:48:05 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 14 Oct 2022 00:48:03 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: is this FreeBSD problem or HP switch Message-ID: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4MpPnD3P5Dz4DGP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=tCDeS6yp; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N i have HP-2530-24G switch in home and 3 VLANs. there was no traffic on 2 of them, one vlan have full bandwitch traffic from computer A to computer B - at 1000Mbit/s At this time ping from computer C to computer A (computer C have 100Mbit/s card) was random between 1 and 1000ms. Just limiting artifically speed to 950Mbit/s solved the problem. Is this because switch behaves that way or can it be a FreeBSD problem (all computers runs FreeBSD) From nobody Thu Oct 13 23:02:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpQ5K5Zrrz4dsk0 for ; Thu, 13 Oct 2022 23:02:13 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpQ5J6FWlz4G4j for ; Thu, 13 Oct 2022 23:02:12 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk1-x735.google.com with SMTP id o22so1449847qkl.8 for ; Thu, 13 Oct 2022 16:02:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EXL1hL8vkMcgWCSUAnZ3WGzs+7s3+Vp3XLCXYuEzpIo=; b=Pu9P6jrgUqsdkqj/VoUXd9YfCCd6KopmBnesOVeiz4ssBjvBGD+QPUQetVR9z+Kh5U UoBFuu+y0D6B1eAVZkhb4TQZmLwdSEyNK6ZDXiJJToHkatob2vWTz+Ov9OeN+UqcqXkC JRbr1oZoTN64ONUssQI/NrtikU9favZ6efkPQVMajCIgf8iedLescVx5aWpK67SwrbeL M/naGGOifbc/t4ZqTQhj2SP3fLIIZscGQPuFMqHb2RTZzFweeMdE30e0RBpRJt1HeUrr drBf1FoSg1t1IhCUI4yggrGI6Hy+Vf9U/Kdil+VW5wqTmpoUihCvnnkZxEV+/78ghJ+L 8NUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EXL1hL8vkMcgWCSUAnZ3WGzs+7s3+Vp3XLCXYuEzpIo=; b=gh+Ks1i+x4x9QQdnvVc9Ss4iWdU3T+zZeJHjQBseRwAmi2Qg7q8S7f04120Q0gpLYK OIaVUEORo5QyvHDm4eMIFdpOx35MczvcUnjpk39HXk1ePoh2QjdRrbIBgYHFLrHO0yeK mFtOiKe24QSo2JXGCZfpFujUM70m6JtPZ2ndxa0YPRC9LNn9rkJXxOr1+XYAU60/0Hfy d1DMenZ95tMcgMo4xWr0ck22cOKJfL2bhHCLCBQ/PaKV1n4qk9rvg6808t8wkRJZJHZM 53MYznteQjnlcuyXYhaASC6/CZPkW6dZqhpGa2CanWO/12p5goByKkZRJ4gM1hruAONL myUg== X-Gm-Message-State: ACrzQf0cUTKRBixTBXFuBN95HHfOe23hL+Th+rFEnFi2n9YO5qn861yY gclNxAeHsuqTpDXfRtuzj6VqD96xuBz1pyHLEPfFaQ== X-Google-Smtp-Source: AMsMyM6jS3urRV+Nb3k9HvUY/qjkLpUEaEIrHqIaoc4HammWHSCdGaphlu3b9W425kn5p8FJ9liJBPVJg/O3TUPCxu4= X-Received: by 2002:a37:b2c5:0:b0:6df:f8d6:6ea0 with SMTP id b188-20020a37b2c5000000b006dff8d66ea0mr1851069qkf.386.1665702131286; Thu, 13 Oct 2022 16:02:11 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> In-Reply-To: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> From: Mark Saad Date: Thu, 13 Oct 2022 19:02:00 -0400 Message-ID: Subject: Re: is this FreeBSD problem or HP switch To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000d6580c05eaf27fef" X-Rspamd-Queue-Id: 4MpQ5J6FWlz4G4j X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount.org header.s=google header.b=Pu9P6jrg; dmarc=none; spf=pass (mx1.freebsd.org: domain of nonesuch@longcount.org designates 2607:f8b0:4864:20::735 as permitted sender) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[longcount.org:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::735:from]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[longcount.org:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[longcount.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000d6580c05eaf27fef Content-Type: text/plain; charset="UTF-8" Wojciech There could be a lot going on here. I have used HP-2530's on HP DL360's running FreeBSD without many problems. They are store and forward switches , so they do buffer packets before sending them along. So it could be dropping some of them but that should be easy to discover by looking at the switch's interface and checking how many errors you have on each port . However the issue you describe is probably not a FreeBSD problem or Switch problem, but more of a how busy your computer A is. When you start to saturate a network card for either packets per second or bits per second the OS will have to deal with it by delaying the response of other traffic by one way or another. Imagine your computer A is running a web server and you are hammering it with 1Gb/s of traffic. The CPU on that server will also become busy handling the traffic and running the webserver. When you then send that same computer ICMP, another TCP session , UDP traffic etc. The Network card will be unable to process the traffic , as it's out of resources, or it could accept the traffic in and the cpu may not idle enough to pick the packets off the card and process them in a in a timely manner. I hope that helps. On Thu, Oct 13, 2022 at 6:48 PM Wojciech Puchar wrote: > i have HP-2530-24G switch in home and 3 VLANs. > there was no traffic on 2 of them, one vlan have full bandwitch traffic > from computer A to computer B - at 1000Mbit/s > At this time ping from computer C to computer A (computer C have 100Mbit/s > card) was random between 1 and 1000ms. > > Just limiting artifically speed to 950Mbit/s solved the problem. > > Is this because switch behaves that way or can it be a FreeBSD problem > (all computers runs FreeBSD) > > > > -- mark saad | nonesuch@longcount.org --000000000000d6580c05eaf27fef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wojciech
=C2=A0=C2=A0 Ther= e could be a lot going on here. I have used HP-2530's on HP DL360's= running FreeBSD without many problems.
They are store and forwar= d switches , so they do buffer packets before sending them along. So it cou= ld be dropping some of them
but that should be easy to discover b= y looking at the switch's interface and checking how many errors you ha= ve on each port .
However the issue you describe is probably not = a FreeBSD problem or Switch problem, but more of a how busy your computer A= is.
When you start to saturate a network card for either pa= ckets per second or bits per second the OS will have to deal with it by del= aying
=C2=A0the response of other traffic by one way or another. = Imagine your computer A is running a web server and you are hammering it wi= th
1Gb/s of traffic. The CPU on that server will also become= busy handling the traffic and running the webserver. When you then send
=C2=A0that same computer ICMP, another TCP session , UDP traffic et= c. The Network card will be unable to process the traffic , as it's out=
of resources, or it could accept the traffic in and the cpu= may not idle enough to pick the packets off the card and process them in a=
in a timely manner.=C2=A0

I h= ope that helps.

On Thu, Oct 13, 2022 at 6:48 PM Wojciech Puchar &= lt;wojtek@puchar.net> wrote:
i have HP-2530-24G= switch in home and 3 VLANs.
there was no traffic on 2 of them, one vlan have full bandwitch traffic from computer A to computer B - at 1000Mbit/s
At this time ping from computer C to computer A (computer C have 100Mbit/s =
card) was random between 1 and 1000ms.

Just limiting artifically speed to 950Mbit/s solved the problem.

Is this because switch behaves that way or can it be a FreeBSD problem
(all computers runs FreeBSD)





--
mark saad | nonesuch@longcount.org
--000000000000d6580c05eaf27fef-- From nobody Fri Oct 14 00:11:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpRcZ4Mf0z4f25M for ; Fri, 14 Oct 2022 00:10:54 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpRcZ0K03z4L9K for ; Fri, 14 Oct 2022 00:10:54 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-qt1-x831.google.com with SMTP id l28so2794194qtv.4 for ; Thu, 13 Oct 2022 17:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=z9w8K+jmcRG9qB+BFqXvos2WqS8HKEPKst+utdYLh9Y=; b=Qps9UaAmenCFQ8lJ3PhIFvGzJfbuSEknDGxHG0kFWEGC4gkxqOMR8XPtn3PTKd7RR/ KFZF8qSr0ZKqqSM0VViuXNvDmDxlvP2kBpJG8KCKZIfaCVvcBPEMpYpFe75htX334mdL 2BxqsnoLvcMj9y8KQB3yE6BIaJvMTgeJqMeEX4nOdJJAUikTXtan6tL424+PrmZ2/FGX UHH/M/o4WIFUTA3XVyupHvejIiEBhnGrrnVQmO9HWR8AYeDnCFegUDVH4DrfR1P1wHYU M5mk73Wkappvs9NZLZdfSu62KtRnTMVuFFHFBq/sNx/zd5U/36Rmb3IbOvIrEMWJD/fQ U6zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=z9w8K+jmcRG9qB+BFqXvos2WqS8HKEPKst+utdYLh9Y=; b=wEY8QgGLygUUfU36xhgh02RE52XtbwYxFcTVXHmEtQy5a1EYoe3IKHkmKLzb6bmNmD KEbqjAqU17ab+/Hz/BuXGoumdAV5xkKhqTc/rhJLQNlHssVcZZTjk+NHk537eNRybiGx Kg0J9LkdNp0ABP3F8Bl1Xg1mu6V/cYBoGX+Qtx9fESsrBzdIBJsOFfRWTMinPaOXFhWd LpB5Ldtqw8lpiZkLbHsFNcYLAwmOMWibIsoQ23ISNKneRJhZbTRAizfe28y5iQZyrfEA lfjq5PK8sVphd402+ofydBoERaMpem0NludEYmpYzTzRFYNx74n8Pjg40MPIcY5nv7cj g1+g== X-Gm-Message-State: ACrzQf2vMs8OacVo7+QXKiX6ZDwIHDPNiMchFk1U7wVsRFHKGetKTiid wTW4Zqp7jwW3pGJaFeCZ87kdTtEoLU0= X-Google-Smtp-Source: AMsMyM6yd4sHrnYqA+2YJWwqdmAuyNx27koJt8nYJqwZkZDz+bc7gJzicj+psAfsWCUJVjgZX94Htg== X-Received: by 2002:ac8:7f0b:0:b0:392:4001:64b3 with SMTP id f11-20020ac87f0b000000b00392400164b3mr2214690qtk.132.1665706252944; Thu, 13 Oct 2022 17:10:52 -0700 (PDT) Received: from [192.168.0.59] (cpe-184-58-230-200.wi.res.rr.com. [184.58.230.200]) by smtp.gmail.com with ESMTPSA id s21-20020a05620a29d500b006bb78d095c5sm1088761qkp.79.2022.10.13.17.10.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Oct 2022 17:10:52 -0700 (PDT) Message-ID: Date: Thu, 13 Oct 2022 19:11:06 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: is this FreeBSD problem or HP switch Content-Language: en-US To: freebsd-hackers@freebsd.org References: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> From: Jason Bacon In-Reply-To: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MpRcZ0K03z4L9K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Qps9UaAm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of bacon4000@gmail.com designates 2607:f8b0:4864:20::831 as permitted sender) smtp.mailfrom=bacon4000@gmail.com X-Spamd-Result: default: False [-2.09 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_SPAM_SHORT(0.91)[0.914]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::831:from]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 10/13/22 17:48, Wojciech Puchar wrote: > i have HP-2530-24G switch in home and 3 VLANs. > there was no traffic on 2 of them, one vlan have full bandwitch traffic > from computer A to computer B - at 1000Mbit/s > At this time ping from computer C to computer A (computer C have > 100Mbit/s card) was random between 1 and 1000ms. > > Just limiting artifically speed to 950Mbit/s solved the problem. > > Is this because switch behaves that way or can it be a FreeBSD problem > (all computers runs FreeBSD) > > > I saw an issue some years ago where one of my FreeBSD servers was overwhelming a Cisco switch while pushing files out to HTCondor nodes, causing it to drop packets. Our networks guru confirmed the problem by monitoring the switch. Since no handshaking was possible, I worked around it by throttling the interface on the FreeBSD box, using ipfw if I recall correctly. -- Life is a game. Play hard. Play fair. Have fun. From nobody Fri Oct 14 01:01:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpSmd62YYz4f7NY for ; Fri, 14 Oct 2022 01:02:57 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net [IPv6:2403:5800:5200:4700:225:90ff:fe47:39b4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "dons.net.au", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpSmb1z08z4PXW for ; Fri, 14 Oct 2022 01:02:54 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (localhost [127.0.0.1]) by midget.dons.net.au (8.17.1/8.16.1) with ESMTPS id 29E126cv067753 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 14 Oct 2022 11:32:18 +1030 (ACDT) (envelope-from darius@dons.net.au) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dons.net.au; s=default; t=1665709343; bh=o2IDSOIemuuvl5O5CyZk5qqjW/GHnSreB5aTMAIID64=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=OWImJj8Dv6s1Kn9VU81QOwdHI4WIHysy4BETu5KFlsjHQl3de1w9c/bMqFG53qYdP sAwvXkSxBv56Xnt+VJ82YElLRc6McXatN86qeXcnYQbngdnVVjO/Agd+icDfCJspPY q19+Y508bEJh5V9xvtqk8FVw9QSoR9R9rtU9wwag= Received: (from mailnull@localhost) by midget.dons.net.au (8.17.1/8.16.1/Submit) id 29E11l7I067745 for ; Fri, 14 Oct 2022 11:31:47 +1030 (ACDT) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-a1a524833438212bf543e143edafb27bc4d2c346: 2001:44b8:1d2:8900:3cdb:3f9b:1904:a7c1 Received: from smtpclient.apple ([IPv6:2001:44b8:1d2:8900:3cdb:3f9b:1904:a7c1] [2001:44b8:1d2:8900:3cdb:3f9b:1904:a7c1]) by 2403-5800-5200-4700-225-90ff-fe47-39b4.ip6.aussiebb.net (envelope-sender ) (MIMEDefang) with ESMTP id 29E11fxr067739; Fri, 14 Oct 2022 11:31:47 +1030 Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: VFS mount rollback for virtio 9pfs From: "Daniel O'Connor" In-Reply-To: <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> Date: Fri, 14 Oct 2022 11:31:36 +1030 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E450927-1932-412E-A568-A2F84582BD26@dons.net.au> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> To: Felix Palmen X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 1.3 (*) No, score=1.3 required=5.0 tests=RDNS_NONE,SPF_HELO_NONE, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.5 X-Scanned-By: MIMEDefang 2.84 on 10.0.2.1 X-Rspamd-Queue-Id: 4MpSmb1z08z4PXW X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=dons.net.au header.s=default header.b=OWImJj8D; dmarc=pass (policy=quarantine) header.from=dons.net.au; spf=pass (mx1.freebsd.org: domain of darius@dons.net.au designates 2403:5800:5200:4700:225:90ff:fe47:39b4 as permitted sender) smtp.mailfrom=darius@dons.net.au X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[dons.net.au,quarantine]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[dons.net.au:+]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:4764, ipnet:2403:5800::/32, country:AU]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Felix, > On 18 Jul 2022, at 16:23, Felix Palmen wrote: >=20 > * Daniel O'Connor [20220718 11:18]: >> Thanks for testing it, I will try some more intensive tests. >> Which hypervisor are you using BTW? >=20 > That's bhyve on 13.1-RELEASE. The vm has 6 vcpus. >=20 > I didn't test with a 13.1 guest though, only -CURRENT. >=20 > Maybe poudriere is a good manual testcase (it's doing lots of = filesystem > ops on logs) ;) Sorry for the delay in replying, unfortunately I've been swamped at = work. It's come to my attention that someone else also ported this: https://github.com/swills/virtfs-9p-kmod I was wondering if you would be interesting in trying and seeing how it = fairs. Unfortunately I am not in a position to do a test poudriere with = it as yet. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From nobody Fri Oct 14 02:11:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpVHW0r7Dz4fGpb for ; Fri, 14 Oct 2022 02:11:19 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpVHV1xTjz3DMd for ; Fri, 14 Oct 2022 02:11:18 +0000 (UTC) (envelope-from zlei.huang@gmail.com) Received: by mail-pj1-x1033.google.com with SMTP id 70so3619184pjo.4 for ; Thu, 13 Oct 2022 19:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:to:references:message-id:subject:mime-version:from:from:to:cc :subject:date:message-id:reply-to; bh=WYEVdkoZPqrMso85CBSLUmubrzI6Oyb2NfEevvhQi2Q=; b=pXL8VkhAUhc9Suj5GrCSCBCl9KHPDpg9c8VIjPvs94Qt0bSm8aKlK76eIEhMB3qTRC R3yNfgJNuiwzvzwkjLRpacrFcTFGkEtuxheDkg6HNfUitArgqUJZTYqPYSwcn2l5XKVZ /kpmyO5+upUXc4VTbUwvnacIDfLS69TDYbEIvxmfgECLcOj8Y5N0Bxah1R+slzc9ol2a 6fjagDz/pztsb0WQeivKQSd5TN4hPabSP/jziORjuokXECbAR8VI3b7ltzj7Q8kTWq7Y 7aG4QHOF4O4hfePS9eK4lnNEJoL1jkmODyooSo863fE9DlYt/sk0S5AZLgnq07mFAYKt GQJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=date:to:references:message-id:subject:mime-version:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WYEVdkoZPqrMso85CBSLUmubrzI6Oyb2NfEevvhQi2Q=; b=LEVbVbflfsRFdSgtwdpwzzXG4voud6Zm9+SKthl3oGUYQYSvjKL/IR3OFIqwSu9AcB otP82wgwSu5vtTvaO99kUU7OBfLAb4sn3SzYqCKGBlCVX0kWh9CqWFvNNgK/QZoMzf6k ephsWAPGSeAEZ5a9ZG24C7tGulJidKgnFZSGUBINA3o2Oto4IRvhR71qHtXTkohJRi3Q 7oVzcAivs1lIDi9m4snZfW8bcXPMnG3dfoHv7lgStW1ze1HbN1JhLPCqaSaThvVr1kaH 9nYITCIN2wE+nsNJO9OLDt1DoiD3+YutXQALhUkDrWcq5dZy8v4sSktvpD9U+x2+WDXg 2/Rw== X-Gm-Message-State: ACrzQf2SVKxEEYXihcEZvTeFu5CXvw5SyV8FH01yubTPzLrmA6iYzctz UL3jdTsQqq4umq5ImRvUk+rz0v3xEUIJNQyu X-Google-Smtp-Source: AMsMyM5jsJj7pHFCirBTTmbJbPMK3riBp2gyRb36VumLXOvjCr/vI5gryevRRjeRp2+huhFKckat8Q== X-Received: by 2002:a17:902:e545:b0:182:6c84:7fc0 with SMTP id n5-20020a170902e54500b001826c847fc0mr2762134plf.144.1665713476804; Thu, 13 Oct 2022 19:11:16 -0700 (PDT) Received: from ?IPv6:fd03:a1b3:1819::8001? ([2001:19f0:6001:9db:98f0:9fe0:3545:10]) by smtp.gmail.com with ESMTPSA id 21-20020a630f55000000b00469e09532e0sm359654pgp.18.2022.10.13.19.11.15 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2022 19:11:16 -0700 (PDT) From: Zhenlei Huang Content-Type: multipart/alternative; boundary="Apple-Mail=_1B9F8BDB-791D-4B91-BEA9-AD06384BD454" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Fwd: is this FreeBSD problem or HP switch Message-Id: References: <7E97376C-7FCC-46E9-9626-A9D260B01793@gmail.com> To: freebsd-hackers@freebsd.org Date: Fri, 14 Oct 2022 10:11:06 +0800 X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Rspamd-Queue-Id: 4MpVHV1xTjz3DMd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pXL8VkhA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zlei.huang@gmail.com designates 2607:f8b0:4864:20::1033 as permitted sender) smtp.mailfrom=zlei.huang@gmail.com X-Spamd-Result: default: False [-2.48 / 15.00]; URI_COUNT_ODD(1.00)[5]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1033:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_1B9F8BDB-791D-4B91-BEA9-AD06384BD454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for missing CC > Begin forwarded message: >=20 > From: Zhenlei Huang > Subject: Re: is this FreeBSD problem or HP switch > Date: October 14, 2022 at 10:08:13 AM GMT+8 > To: Jason Bacon >=20 >=20 >=20 >> On Oct 14, 2022, at 8:11 AM, Jason Bacon > wrote: >>=20 >> On 10/13/22 17:48, Wojciech Puchar wrote: >>> i have HP-2530-24G switch in home and 3 VLANs. >>> there was no traffic on 2 of them, one vlan have full bandwitch = traffic from computer A to computer B - at 1000Mbit/s >>> At this time ping from computer C to computer A (computer C have = 100Mbit/s card) was random between 1 and 1000ms. >>> Just limiting artifically speed to 950Mbit/s solved the problem. >>> Is this because switch behaves that way or can it be a FreeBSD = problem (all computers runs FreeBSD) >>=20 >> I saw an issue some years ago where one of my FreeBSD servers was = overwhelming a Cisco switch while pushing files out to HTCondor nodes, = causing it to drop packets. Our networks guru confirmed the problem by = monitoring the switch. Since no handshaking was possible, I worked = around it by throttling the interface on the FreeBSD box, using ipfw if = I recall correctly. >>=20 >> --=20 >> Life is a game. Play hard. Play fair. Have fun. >>=20 >>=20 >=20 >=20 > Modern x86 hardware can easily saturate Gigabit network. Probably it = is not the issue of the box, or the OS ( FreeBSD in the context ). > There's an old post about ICMP packet drops on the HPE community, = https://community.hpe.com/t5/aruba-provision-based/hp-procuvre-2530-icmp-p= acket-lost/td-p/6347333 = . Although I can not conclude it is the = problem of switch, but you can try connection the two FreeBSD box = directly with crossover ethernet cable and repeat the test. >=20 > Also the statistics reported by switch / OS are extremely useful in = production ( when excluding some suspicious objects is not an option ). >=20 > Best regards, > Zhenlei --Apple-Mail=_1B9F8BDB-791D-4B91-BEA9-AD06384BD454 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Sorry= for missing CC

Begin forwarded = message:

From: = Zhenlei Huang <zlei.huang@gmail.com>
Subject: = Re: is this = FreeBSD problem or HP switch
Date: = October 14, 2022 at 10:08:13 AM = GMT+8
To: = Jason Bacon <bacon4000@gmail.com>



On Oct = 14, 2022, at 8:11 AM, Jason Bacon <bacon4000@gmail.com>= wrote:

On 10/13/22 17:48, Wojciech Puchar wrote:
i have HP-2530-24G = switch in home and 3 VLANs.
there was no traffic on 2 of = them, one vlan have full bandwitch traffic from computer A to computer B = - at 1000Mbit/s
At this time ping from computer C to = computer A (computer C have 100Mbit/s card) was random between 1 and = 1000ms.
Just limiting artifically speed to 950Mbit/s = solved the problem.
Is this because switch behaves that = way or can it be a FreeBSD problem (all computers runs FreeBSD)

I saw an issue some years ago = where one of my FreeBSD servers was overwhelming a Cisco switch while = pushing files out to HTCondor nodes, causing it to drop packets. =  Our networks guru confirmed the problem by monitoring the switch. =  Since no handshaking was possible, I worked around it by = throttling the interface on the FreeBSD box, using ipfw if I recall = correctly.

--
Life is a = game.  Play hard.  Play fair.  Have fun.



Modern x86 hardware can = easily saturate Gigabit network. Probably it is not the issue of the = box, or the OS ( FreeBSD in the context ).
There's = an old post about ICMP packet drops on the HPE community, https://community.hpe.com/t5/aruba-provision-based/hp-procuvre-= 2530-icmp-packet-lost/td-p/6347333 . Although I can not = conclude it is the problem of switch, but you can try connection the two = FreeBSD box directly with crossover ethernet cable and repeat the = test.

Also the = statistics reported by switch / OS are extremely useful in production ( = when excluding some suspicious objects is not an option ).

Best regards,
Zhenlei

= --Apple-Mail=_1B9F8BDB-791D-4B91-BEA9-AD06384BD454-- From nobody Fri Oct 14 06:03:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpbRM1njKz4fhCn for ; Fri, 14 Oct 2022 06:03:27 +0000 (UTC) (envelope-from weh@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020025.outbound.protection.outlook.com [52.101.128.25]) (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 4MpbRK44c3z3TsC; Fri, 14 Oct 2022 06:03:25 +0000 (UTC) (envelope-from weh@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nYZjolnLz9t35JGvDgv17DXciswW8dadQP2uANAL3pHC2rN+K4Ocd3fAWKl9HzwCZS81+NINwTN1b/rKhGa3G9qsO6FBJeUquZG6JYHsRS6Tt0fLXvRUkSbEMjeXAG4ksYz9U7QPNfnjjy0kq6xl7tQ2iOzI8lzuST1sObrqHmFsp5HbF/sZQ8d/p7ncAJJI17IsFJFfdSFEeQQlxEyQDLuQfjYpOB0b48M4BrcE5uLH+bko9/7ybVdPotQ0W8PB/7/lrgew7B49H+t2Jx3+/3te8k3vMWeMTf1/hrOeXZWtOuyxlXXGoIeSOUzUU5RMLCboP8k00w5xsgyIykBP0g== 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=wmv0hZXrGvWQC5k9xllp/awi4Udvz/i0egHGtl3aTUw=; b=OmEKw16RHo9Aimg5mFENOFWNT5xqieBlDaERlPPN6JisXaFMRamcOZ1bLE2SR8R59lrYSrrOoRd0eTLujztkw3DiRIS6BN5ZmM68TlxSuXQRovjAoqzoAXT4M3EeatwGgLOZAFZI9+xKti/GmJ8vz0IV6tQatyjEuYNKY6d002ZXB8A0PA3Z3GStGUyjKHmqrgwiNjVWh/l/5clleBAFVnN5kCvrRLh1egnkpDZ5/AzKBaC05NV+2klLoP5O6Hk0jABapwZ692IW+PBwKqvcbRwjyMpjs2q+8YmYaB0UbhdCIrFJB2ZcMrV9RHxNw2WUokAmfU6jYrDcRW/4/GB5HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wmv0hZXrGvWQC5k9xllp/awi4Udvz/i0egHGtl3aTUw=; b=aISYRa//RdIHG3vhUcYBZ0xxvHnBQxz4KK4SIOcVNhs8Nl21wnXLYe5vxwzwcBpKwnSKZR48v2irYpIP6NXalGKK5AK/X7cBEgMt+uB541lfms6IA8b7Td668woTR7tDu6qO0zL5SheyGfGfGy9mujynJbcEtTnr/swIJ3tGbRc= Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM (2603:1096:4:fc::7) by PSAP153MB0440.APCP153.PROD.OUTLOOK.COM (2603:1096:301:35::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.6; Fri, 14 Oct 2022 06:03:18 +0000 Received: from SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::f43d:48c8:6f6f:30c8]) by SI2P153MB0441.APCP153.PROD.OUTLOOK.COM ([fe80::f43d:48c8:6f6f:30c8%4]) with mapi id 15.20.5746.011; Fri, 14 Oct 2022 06:03:19 +0000 From: Wei Hu To: "freebsd-hackers@FreeBSD.org" , John Baldwin CC: Li-Wen Hsu , Souradeep Chakrabarti Subject: FW: newbus and acpi issue on Hyper-V Thread-Topic: newbus and acpi issue on Hyper-V Thread-Index: Adje4its1rEr3VLNTVqns+Y8gVfIcQAQEYzwABwHzMA= Date: Fri, 14 Oct 2022 06:03:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0cbaf113-947b-4307-b77e-2906a090e6a0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-10-13T08:45:10Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SI2P153MB0441:EE_|PSAP153MB0440:EE_ x-ms-office365-filtering-correlation-id: 7774b440-5d05-4fbd-4375-08daada9caed x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PuAlDNqbuGKwiN2aoZgHtRsEeV1AoHKFBefeuzD5mYgAJxxoyLAGgCkprEju3CuYSLnBjaVsK1U8WNbI05JZnSj6qb94MlpTxse0RKwVmMkDlcqtwJS7d9LW7I+jbHf/XVVD0pkaNwyHuQwg/xt5/YVDX3S5xIkgDp0OKuoDgvJSVbHBJQaF/ak3/RgasinwyBJNZ8q/NnYUL7RIlohKwwybE/BV45Jl0xvxnnZ0KMFD6vvSdmM+vQ9TNqB/UizqWK9ilH0n40SLnZSqERz2Pq3FwkWxV/UHQEmLrclKwZJNudM46CxpqcHUIL/0ilyMhlBs4Ydg2ZcvEv3th6fDNYdvYEkTm2HiDGb5RMM9n+9FxgrmIIo1fNYRuyeQkiqcrJpNgzZSLzjKMhfZlHcuYwtIeZApOMVwchjkBbEGqz4YjAQD9jDpQrhDH1PB1Iqk7+3BlBvVeDOGSN8yfjtLPzYXylD6S7z/lXj7fhWeto6Kis9d9F1sY/McFJsanTPbsDcLz9gHlUVDnbWyoqdwjDsimEjAmk3HGENwso+wblojJp3W6MmhVKxoFr7u4u7YQpYPf0ZcbhOm0B87o4E/toIheKf9wITy/NHSP3gowVPmnZTUAuJ5PZdo7KSco+StTDcNHqhQB84TV05IIsyaoCMAFK4lhIlBJlSUcvMax+IbLEfDSvwOCA9C/MQgAltGba7SsXFSrsyuEYfYyUWSHANtanXvekBvLjy+HLt1YROhrahe76vo9yGvLeEq36jlVU4TMBjqDQCOyWVHPfI9/8cBtJ8nnXRc4C7hrengwOw04xfhJKjAWh4ja1S4EXbn x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SI2P153MB0441.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(451199015)(478600001)(10290500003)(83380400001)(66899015)(54906003)(66556008)(8990500004)(110136005)(66476007)(4326008)(66446008)(64756008)(8676002)(316002)(66946007)(76116006)(86362001)(55016003)(450100002)(107886003)(82960400001)(82950400001)(7696005)(6506007)(41300700001)(71200400001)(9686003)(26005)(9326002)(5660300002)(38070700005)(52536014)(33656002)(38100700002)(8936002)(186003)(99936003)(122000001)(2906002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2R/np8tivLjxfaWGXS5yLFZDrZkcrWKP2hjkrd0T6Bh36l8lkIiu8J32fNuO?= =?us-ascii?Q?pLAp0Kj9DAgTrgZkZJlvS9ah5dT9p20HHC+ArtHcQBfS83C3eLuNvYhKf0OM?= =?us-ascii?Q?zVCEByC+0hcefPm/z7eV5r85PU0ZELhjmIy52RHS8PKOrEMF9r5rUQ+WUGb1?= =?us-ascii?Q?PBHFMth4bjc1snTXh2OcElEW5MJuP+Urb5G+6jUE91OWy/TsI3e+EQUMOPS6?= =?us-ascii?Q?e98vtLpqlIQbeo2cp9SSCyh7Cr9gV2NvH9w/nGOva6NrtgN4/sS7Ec84dRvx?= =?us-ascii?Q?JES/8gQN7ycDplMnZ0GVep6igvGUN2CtrbOoEYgDqTLuuyy8skZmfujnpoVw?= =?us-ascii?Q?S0pNt8NN0u/WadUyhtpSpeV3BZ9r4ydl1/9W4vlLJKeoDVmYWCMh6a3LzSXg?= =?us-ascii?Q?sU5vlK9wUpZViozOMlb+PjPx1VN+aZML4FnvtuANJ/LAMwHvBxu4IC5ibRAP?= =?us-ascii?Q?kXDl3PCZbq/ORQVNsQhJyenNYaQgIdfaok0eLqoB34A0M4VIKA0NA3VULiza?= =?us-ascii?Q?qaMv3zJuzxyykMO0b/osXYKOrPhFvd4GWBp37NnhOykgucl1wPA3sUihNVUN?= =?us-ascii?Q?SkC2W5qYrzgwpOXlsTXh+QFEfZaal1MfactKOlhg6AmRbPVvUrFjBAeWLGwF?= =?us-ascii?Q?NxdUpXo/IXxZiW6aQfaeHPuyRIY4RAhFwApTIkWfdcXafz6G0wDSd5oKJAQ9?= =?us-ascii?Q?sC9vmRGRn6Hf7rP2YmVQ2kMwh4+1vyvdpJWS08W+14bwJCjORjh9sE/TD3I3?= =?us-ascii?Q?YOFWl6CnDokvq1X8jDmxsIUo6pMMXAnm+Lo/qmRCUSDNAzEwKPQTaFEU0GAK?= =?us-ascii?Q?6U2EZPNroWnTqJ1QDw8aT7QuUJrTgIPDSP2u8RJt+JQRqSVrTJ1GQYK3sxnR?= =?us-ascii?Q?Xmx2kglsOu91WfGSJ565Hy9Vf+2SdBbcMEGkEGnboQWD3keqjpqqJwR/4CW4?= =?us-ascii?Q?bfXxh7eJcmhp2P5QtUZ5Xo8DGUBCsWiwFVoLLZqpa1NZF3/9PKMHtSWiCs7c?= =?us-ascii?Q?uqNScfDUHOOkYm+EgSw4NlqQNpxH8WVdeBjrq5/7ISC5LGfLLGIhS4XQwh7g?= =?us-ascii?Q?v8sHlOsjg0EJOwjyYR5WmzIE7qxjocK2YHAkN20lLJnKUlyyQwilmy8l8bf1?= =?us-ascii?Q?QKQG+dUOtvcunOGAAfI6fNpidN4649UJ9saAAK3LHGIZDUTBVWys2J8Tk8p6?= =?us-ascii?Q?tKU/HkdDsF+lNErKOyEoecpT501yJuZ3YlivC0MsRbscV9U04j0XL3Zgv41w?= =?us-ascii?Q?bWEuMtgwJKIdSHrpLrEsYCkLtdRYjQDvH5W6hsAVriWBMUPTb684YpptuJPB?= =?us-ascii?Q?R6Wv0UGV4f7g21FDq7HXf1xeQ4u24ctp3MJtbMa6khLSe5WUu1xOpq2F2uFA?= =?us-ascii?Q?Ad8Az2EaTzo1wt2zV4DLjXyDUlj1ErjvTAhYW9VVypg0EZ9rUeVO511bP2jq?= =?us-ascii?Q?lLcMrH3Lyy4bfQfquRYlRnzZbMI4bGgf3yhyFtAmYsQu8Ado9rb1tEOvHhr0?= =?us-ascii?Q?aMaDEX7ouENiU1HHGF43kFL85ofNNzI4Q+UOCeik47j562Z28vhugg17Q4RK?= =?us-ascii?Q?9Pa2oSJOcqZI4VYfCkU=3D?= Content-Type: multipart/related; boundary="_004_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_"; type="multipart/alternative" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SI2P153MB0441.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7774b440-5d05-4fbd-4375-08daada9caed X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2022 06:03:19.1502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ur/TjTiNMJt3N4nCb4uSm3COdjGFjT+nm8gaTZD+dxvvN5fTsBnytpZefi7GIu3w8aAZ9T7P2lWpjvAuQVjO3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0440 X-Rspamd-Queue-Id: 4MpbRK44c3z3TsC X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b="aISYRa//"; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of weh@microsoft.com designates 52.101.128.25 as permitted sender) smtp.mailfrom=weh@microsoft.com X-Spamd-Result: default: False [-10.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.25:from]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --_004_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_ Content-Type: multipart/alternative; boundary="_000_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_" --_000_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We are working on enabling FreeBSD running on ARM64 Hyper-V at Microsoft. R= ight now we are hitting a road blocker which seems only happening on FreeBS= D guest, due to its newbus architecture and how resources are presented in = Hyper-V's ACPI tables. I am writing in hope to find a short term solution o= r workaround. Without it, it would be hard to make SRIOV work on ARM64 Free= BSD guests. Appreciate any inputs. Here are the details. Hyper-V presents two system resources at two differen= t places/nodes in its ACPI table. 1) PCI mmio resource in HID "ACPI0004", which is needed by the FreeBSD gues= t for SRIOV devices. Device (\_SB.VMOD) <-- This is currently owned by acpi_syscontainer m= odule on FreeBSD { Name (_HID, "ACPI0004" /* Module Device */) // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { ... } CreateDWordField (_CRS, \_SB.VMOD._Y00._MIN, MIN6) // _MIN: Minimu= m Base Address CreateDWordField (_CRS, \_SB.VMOD._Y00._MAX, MAX6) // _MAX: Maximu= m Base Address CreateDWordField (_CRS, \_SB.VMOD._Y00._LEN, LEN6) // _LEN: Length CreateQWordField (_CRS, \_SB.VMOD._Y01._MIN, MIN7) // _MIN: Minimu= m Base Address CreateQWordField (_CRS, \_SB.VMOD._Y01._MAX, MAX7) // _MAX: Maximu= m Base Address CreateQWordField (_CRS, \_SB.VMOD._Y01._LEN, LEN7) // _LEN: Length Method (_INI, 0, NotSerialized) // _INI: Initialize { MIN6 =3D MG2B /* \MG2B */ LEN6 =3D MG2L /* \MG2L */ Local0 =3D MG2L /* \MG2L */ MAX6 =3D (MIN6 + Local0--) Local1 =3D (HMIB << 0x14) Local2 =3D (HMIL << 0x14) MIN7 =3D Local1 LEN7 =3D Local2 Local0 =3D Local2 MAX7 =3D (MIN7 + Local0--) } } 2) Vmbus IRQ resource in HID "VMBus", which is needed to get Hyper-V vmbus = interrupt to work on guests. Device (\_SB.VMOD.VMBS) <--- currently owned by vmbus_res module on FreeB= SD { ... Name (_HID, "VMBus") // _HID: Hardware ID Name (_UID, Zero) // _UID: Unique ID ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, ) { 0x00000012, } }) } On x86, FreeBSD just needs PCI mmio resource 1). We ignore the vmbus IRQ re= source in the ACPI and pick a fixed vector for all cpu interrupt. But on AR= M64, the guest needs all the information in order to make bus_alloc_resouce= () to work for both interrupt and mmio. Therefore, the main Hyper-V device = driver vmbus needs to be the child for both these nodes to make the resourc= e allocation to work. But it seems to us that one device driver can only ha= ve one parent in the newbus architecture, we can only make one resource all= ocation to work in this scenario, either IRQ or mmio, but not both. Following is a picture of current device tree on a AMD64 FreeBSD guest on H= yper-V [cid:image002.png@01D8DF2F.A3DB8800] As you can see vmbus module is under acpi_syscontainer which owns PCI mmio = resource. The vmbus IRQ resouce is owned by vmbus_res module, which is just= a place holder for this resouce and never been used on am64. On ARM64, vmb= us module needs to be the child for both vmbus_res and acpi_syscontainer to= get the both resources, which doesn't seem to be possible under newbus arc= hitecture. Any suggestions or workarounds are welcome. Thanks in advacne. Wei --_000_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We are working on enabling FreeBSD running on ARM= 64 Hyper-V at Microsoft. Right now we are hitting a road blocker which seem= s only happening on FreeBSD guest, due to its newbus architecture and how r= esources are presented in Hyper-V's ACPI tables. I am writing in hope to find a short term solution or workaro= und. Without it, it would be hard to make SRIOV work on ARM64 FreeBSD guest= s. Appreciate any inputs.

 

Here are the details. Hyper-V presents two system= resources at two different places/nodes in its ACPI table.

 

1) PCI mmio resource in HID "ACPI0004",= which is needed by the FreeBSD guest for SRIOV devices.

 

   Device (\_SB.VMOD)   = <-- This is currently owned by acpi_syscontainer module on FreeBSD=

    {

        Name (= _HID, "ACPI0004= " /* Module Device */)  // _HID: Hardware ID

        Name (= _UID, Zero)  // _UID: Unique ID

        Name (= _CRS, ResourceTemplate ()  // _CRS: Current Resource Settings

        {=

        &= nbsp;   ...

        }=

        Create= DWordField (_CRS, \_SB.VMOD._Y00._MIN, MIN6)  // _MIN: Minimum Base Ad= dress

        Create= DWordField (_CRS, \_SB.VMOD._Y00._MAX, MAX6)  // _MAX: Maximum Base Ad= dress

        Create= DWordField (_CRS, \_SB.VMOD._Y00._LEN, LEN6)  // _LEN: Length

        Create= QWordField (_CRS, \_SB.VMOD._Y01._MIN, MIN7)  // _MIN: Minimum Base Ad= dress

        Create= QWordField (_CRS, \_SB.VMOD._Y01._MAX, MAX7)  // _MAX: Maximum Base Ad= dress

        Create= QWordField (_CRS, \_SB.VMOD._Y01._LEN, LEN7)  // _LEN: Length

        Method= (_INI, 0, NotSerialized)  // _INI: Initialize

        {=

        &= nbsp;   MIN6 =3D MG2B /* \MG2B */

        &= nbsp;   LEN6 =3D MG2L /* \MG2L */

        &= nbsp;   Local0 =3D MG2L /* \MG2L */

        &= nbsp;   MAX6 =3D (MIN6 + Local0--)

        &= nbsp;   Local1 =3D (HMIB << 0x14)

        &= nbsp;   Local2 =3D (HMIL << 0x14)

        &= nbsp;   MIN7 =3D Local1

        &= nbsp;   LEN7 =3D Local2

         =    Local0 =3D Local2

        &= nbsp;   MAX7 =3D (MIN7 + Local0--)

        }=

    }

 

2) Vmbus IRQ resource in HID "VMBus", w= hich is needed to get Hyper-V vmbus interrupt to work on guests.=

Device (\_SB.VMOD.VMBS)   <--- curre= ntly owned by vmbus_res module on FreeBSD

    {

        ...

        Name (= _HID, "VMBus")  // _HID: Hardware ID

        Name (= _UID, Zero)  // _UID: Unique ID

        ...

        Name (= _CRS, ResourceTemplate ()  // _CRS: Current Resource Settings

        {=

        &= nbsp;   Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive,= ,, )

        &= nbsp;   {

        &= nbsp;       0x00000012,

        &= nbsp;   }

        })

    }

 

On x86, FreeBSD just needs PCI mmio resource 1). = We ignore the vmbus IRQ resource in the ACPI and pick a fixed vector for al= l cpu interrupt. But on ARM64, the guest needs all the information in order= to make bus_alloc_resouce() to work for both interrupt and mmio. Therefore, the main Hyper-V device driver vmb= us needs to be the child for both these nodes to make the resource allocati= on to work. But it seems to us that one device driver can only have one par= ent in the newbus architecture, we can only make one resource allocation to work in this scenario, either = IRQ or mmio, but not both.

 

Following is a picture of current device tree on = a AMD64 FreeBSD guest on Hyper-V

 

 

As you can see vmbus module is under acpi_syscont= ainer which owns PCI mmio resource. The vmbus IRQ resouce is owned by vmbus= _res module, which is just a place holder for this resouce and never been u= sed on am64. On ARM64, vmbus module needs to be the child for both vmbus_res and acpi_syscontainer to get the = both resources, which doesn’t seem to be possible under newbus archit= ecture.

 

Any suggestions or workarounds are welcome. Thank= s in advacne.

 

Wei

 

 

--_000_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_-- --_004_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=24247; creation-date="Thu, 13 Oct 2022 11:43:28 GMT"; modification-date="Fri, 14 Oct 2022 06:03:18 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeQAAADaCAIAAAD4y6bHAAAAAXNSR0IArs4c6QAAXnFJREFUeF7t XQdAFMf73St0jg7SuwiiYuy99xpb1NgSSzQm5meM6T3/FGOKKZYUU4yJJbH33rAC9oJIld7rHdfv /m8ZWA5ERbgDDmbcbOaW2Slvdt9+++bbGZ5Wq2VooAhQBCgCFIGmjQC/aVeP1o4iQBGgCFAEWAQo WdPrgCJAEaAIGAEClKyNoJNoFSkCFAGKACVreg1QBCgCFAEjQICStRF0Eq0iRYAiQBGgZE2vAYoA RYAiYAQIULI2gk6iVaQIUAQoApSs6TVAEaAIUASMAAFK1kbQSbSKFAGKAEWAkjW9BigCFAGKgBEg QMnaCDqJVpEiQBGgCFCyptcARYAiQBEwAgQoWRtBJ9EqUgQoAhQBStZGfQ3oc8bEGudffPDgg0XW kKYWUznS6R6N+sqjlW94BHj0nml40PVZojopI/HEz38nxMSmDOjSZmD39juOXpEoxCUSno1rm8mL n29jwzfTLU8rzrp9aev2Y+lipYrh8XkCcyvHHuNm9WnnamPCKBSKH3784e7la1oB37dj+6ULF4ms RdF3b//11/qk+GxLK4tRY8ZOmjhOXbTn7213TpyJd3Ky/fzzz83MzBh1QmrcyV9QjXsJTz89bvr0 6RVlFmRFR/y+fldyqZBvJnJ3tfYLEJ48mfP0mHGjR/XVJw40L4pAc0eAWtbG3sMarUYJkt26ZfMP P60/cv5GemFJqVwlzbsXe/ng+n8uZOZIdVqYd/X0sQ2bDsdkFBZLpDL8k4qL85LP7vjz5KWbeQzD Yxi5XCnJjr5y/tj6/85KVRqcm59678g/Px25kpicK9aqlWxuWgWPp71w8eLatWtRdFn+akarlMvl //675ejRo1yJqZcjjmzeeDM9v0BcqlCqCrOTrh78Zf26Py9Exhg77rT+FIGGRgCWNQ3NAIHBA/tZ ubZ59fsdybKy1kgjT29cbOIw/fT5e1zrxLd/fXHO1JDBb5xNVXIHNcV3vpve/tlX3vn6Qn75wZKo vRtW9JrwQWR8lkYri9j9y9LRPVYeiE2WVsFp9erV9vb2JSUlukfDwsLmzZvHHfnt3deH+Xr/c6+E VEqWdWvrq529Pfp//ePeZoA5bQJFoCERoJZ1Qz8dDVReiVg6ok/Yt69M8CCqh3kX69ZPq4oOapXZ XIlrX/3F0tH7i/++7O0h5A7yRCH/++sXM2npgS9/KD9o3XnQoCFfjC5+bcW/iyZPPnY83Gbu78/1 9fUyr1J3pbLMyq4aNBrWGOdCoZpJkigKc4vkZYfMXIInvv/dFysXDugdYCAcaLYUgeaKACXrZtKz ao3WypLlaa5H+ebOWnUhRBKuhScypRs3/Pnps2NHDh82bCgJw4YNGz5uwmt//Lq6MDmcS2np2bn7 qDmB1zceOpwao+n+8sQQZ+tKfifJWJviceANH9x1+pCgv5ZPHzNo6KixE56dM//tVYdLHdraevo/ 7lT6d4oARaAKApSsm8kFweMxanUVq5ZQKY5zQaXRWpgI7CxNBQJhRRAgKDVOo8eMnDlzBJdSqxSn xMfZuHmFtGttZc6/fTvjQZiQsYDH8Pk6BeBRwRfopgzt02/BS4u7BbhY8eTF+VkpiXE3r0Tt3XM4 NjapmeBOm0ERaCgEKFk3FNINXg6/jKd5vMou7udqPnfe81/8t33fgQMHDnLhwMH9u/ft3bN06TK5 ptxWjrt4aPsvK4tGvb3s9WE9HG+9891/0SkYgKwSREKeiwk/S8o9IbQKSZFSLtXl6xK1jUW7sT/8 te3g4UO7tv79wxdvzR0dePSPHy4dP9bgeNACKQLGjQAla+PuP672fHCkoIpVa2Jigr+SPQlLV87K KchY/NyqOyVVWi3LTzy2+cc/N/x0RcaSde6ptXt279zvtPyDp4OHTZw/auzEZZ7hCz/bevxmVhWr 2Uo4UCRcf70wVc0elmTdXv/WlJR7MZYiGy7Z6u9/7T9k2qVMlVZo6eTp/1SvPgO6dbJzDNXy7ZsJ 7rQZFIGGQkDw0UcfNVRZtBwDIKBOSI/b8tlXW7dt352emizR8kuDO7qZXIs4vvPDz9bH3rubfj8p y85F7hPoK2TMWvm72Yosi+KO7dq2b9++/QcPwr4+dPDw6YjbBRrb1u27BXk4fbfys09XfLPn9DVz K6uFU4aam5vHJKT8+NPvxw8cunD5rImFaZf27Ugz7B1MbRy1O//dcXzvviMH9x87e73Ipu35SxdT Yu8WMoL0gPYdrE337jm5a9vuLl6qw4cP/bt169YtO49eze749NTx4/p7O1kbAA6aJUWg2SJAydrY u7ZYXJR2K6bU3z8wtG2Ik6ubd8fO3maFmcmZmbnadu3aenq4OwUGeQYEemGAkGfl5unqay/MSMvR Ck1MzC0szM0tLSztnL1COnbr3DHM3YJ37WpkKd82qG3HEb2Cu3TpampqViBWZBRrO/jYO7RCTsFP hYYQyEzt7J183CUpqTyBUGBm5ezm02XIRO9W9j5ujo7unm4dOgdYmWhUGkdH2x4hLhKFRqZQ8k0s bT1Cp89+uqOfY6XBb+w9QOtPEWgQBOgXjA0Cs6EKgWpRZXxP7+XA44OnO0ZZ5gRS7chDC8UQZ9Vz 9V49miFFoOUgQMm65fQ1bSlFgCJgxAjQAUYj7jxadYoARaDlIEDJuuX0NW0pRYAiYMQIULI24s6j VacIUARaDgKUrFtOX9OWUgQoAkaMACVrI+48WnWKAEWg5SBAybrl9DVtKUWAImDECFCyNuLOo1Wn CFAEWg4ClKxbTl/TllIEKAJGjAAlayPuPFp1igBFoOUgQL9gbDl9XZeWSiQSrKyIqfusra1r+5V5 Xcqh51AEKAKPQYBa1vQSeRQCiYmJERER0dHRKpWKIkURoAg0IgKUrBsRfCMo+vbt21ik4OLFizWu uGgEDaBVpAg0FwQoWTeXnjRMO7AArlrNLi5ANRDDAExzpQjUFgFK1rVFqmWmIwa1paVly2w+bTVF oOkgQMm66fRFU6wJyBqWtampKbWsm2L30Dq1JAQoWbek3q5TWylN1wk2ehJFQM8IULLWM6DNLDs4 gUC21l11t5k1kDaHImAsCFCyNpaeapx6UhmkcXCnpVIEHkCAkjW9KB6FAARrLLooFGK1XRooAhSB xkSAknVjok/LpghQBCgCtUSAknUtgWqhyRQKBYxrc3NzOszYQq8A2uwmgwAl6ybTFU2yItwAIyXr Jtk/tFItCAFK1i2os+vQVJA1AmXqOkBHT6EI6BcBStb6xbO55WZmZmZhYSEQCJpbw2h7KALGhgCd ItXYeqxh63vlypWioqKQkBAXFxc+nz7aGxZ9WhpFQAcBStb0cngUAqWlpWSAkX4XQy8UikDjIkDJ unHxp6VTBCgCFIFaIUBfbGsFE01EEaAIUAQaFwFK1o2LPy2dIkARoAjUCgFK1rWCiSaiCFAEKAKN iwAl68bFn5ZOEaAIUARqhQAl61rBRBNRBCgCFIHGRYCSdePi33xKx+R8zacxtCUUgaaHACXrptcn xlajTz/99Ndff635k/SHMDgldmPrZFrfxkeA+lk3fh8Yew3wfSPCjh07HmgIbG2eRqnMjj4feb+w RCKxtra18+nSK8RZKOSzfzP2ltP6UwQaEAFK1g0IdjMtavTo0QEBAT/88EON7ctNvP7fqhV7E8QS WZGtpa3If+w7yyaHejs0UzBosygChkKAkrWhkG05+UokEkwbgvmeamhy3rFj+7c/v8Zx45q5A7r4 x54/8vv/5hUt+/uZEf0H2LcchGhLKQJ6QIBq1noA0XiyeOQYYC0GCLkkusOJVlZWYGqsq/sgDveP 34jefy3opYleIf74a2A7r4mLA6N23bl1KtV4QKM1pQg0CQSoZd0kuqF+ldAyWum9G9fiElPzJUoB o1XIFE6+7dqEdQ1w4lXXhVXi3PvR4ZHRRVI16NXS1snRs41r2lWXDp3sWnur86OOhWcmJecG+TgO 7R5y6Myt/FKlls8zNbP2eap/mK+DpUllTePj48+dO4cJnvLy8jp06NCvX78HW3Hgk3d27dje7ujN Z51Nndg/Z0kzN7UbfHfO7MkfvDm0fq2mZ1MEWhYCgo8++qhltbgZthb2bvHpg3sOHjp6Ierm3ds3 rl4KvxJfmM+49OvgWtVJQ55288LhXdv+3n34UuTV69euxqekZxYprqxcbuHp79MlVJa+/Zc/z3z6 2aobl0518LT5c+uBC5ev3bp96/adu8mFQqdWLu7O1ty7WFRU1Lp162JjY1etWoWZ+SZMmPAgtPuP Hg2/cWfJkpc9TMiU2GYareiHNRvC2nsM6N+1GXYFbRJFwHAI4H2WBuNHQJOcVZCRV1zeEHXMO8sX BgQPwCIvuk3TJP669PmJgT0W77+dXSCWqTVaaUHq7QPfeVqbfPnlV2xKjRK7ObOeZRjztv2WH4tO K2YzkGbfj3izv8/s/1v3d6KGyxCZK5Vs+k6dOs2YMaNGDD948/V2Af5FqsqzlPJ8L5+Q9z/8wvgx py2gCDQoAlSzNtxzsCFzlsee3PLd8rnjRgzqN2TU9Dkfbdl5lFFmVqvBhk+25DH2kz9Z2jfI2c7K jM9jzO08Aro9/cr4iT39fdjEPCF2WrXG2td/xscLOwa6i1h72NzZs82CD6dmXbt+8rfdXJ5YPkYo ZNNj/7AvYtRaRq3VmuiIMTyeCR4JjFbVkOjQsigCzQABStZG34mq0qJ723/ccfD89RzGyc2rtb+3 u5uflZUtj6eo1rZ/T8dZ2NjPHdpaxHIsS8usMOHo8+zCxWFdOnOJpTKFv4fDnAGBjuXJGIYvChg4 T12YnnH16IN4Qft+2CKNlnyeBZ9XAMu6/DStRpXHF1jx+DW5jhh9V9AGUAQMiAAlawOC2zBZl+Tn b/y/z2JLbfov+GD1zxt+++Wnb1Z+PHxQT5lMWa0CmQzfVMB4VR4tH3306NvPxhfeGuWMiv8JIS1X ORkp3RlGweMVPFGj3E35HqaCa6VKSflpJUrJdYGpF9/U7YnyoYkpAhQBStZGfw0UKTR/xsqmPzNo +bj2lqakOUozc8gP1Zs2wM6sRKbeI665yZqKLwpNBbwksXJjirKUc8bTypi8bTyBvalNtyfCq52N WZit2Z700jwieyhzJGl7TO06m4raPlE+NDFFgCJAydrorwELHtPDTH0vRxlDmqJJ3frJ0l2//G5l Y1NtVfKX3xujzkn4esmPsbLKVufFn1u1dMYnf2w+kld+0NTKIv/mjR2LPrqaXG4Qa4pjV8z7zMIv qP+CqQ/ixYnX3J+450TIEP+2Q732fbJLmstqMqUZJds/Pugzsp3vgCCjx502gCLQsAhQ172GxdsA pQl5aid+ZlRcysWIO6lxd65eisostbyVmB0bF+3s5HRf2EpoJXI0YxUPez83TYks997tuPh7V+F5 d/HCxQvhV6KTClXmnqGdggN8XMsM8/+278xOips7snNs3J3IK5cvR5w5eeZiTJZo0JTpIwe1tS9z wVOkRVy9cGzXsYibN65v3bq1pKTERiRCdhHXCnh8Sw+3chHF1NmWb2IedzQ8Mzc5PvHWmZPnLsdb jpk/fUBHN1tqJxjgYqBZNmMEKFkbfecKzU0DugclRZy/cSkiOqMwL18zZN5rTp6eWfduiEtLC1zb e3p4+FqXydPCVm0DvX2tC48dOnbzbvzd6OiU9FyVjf+o55aM7tHGq1xCYTZt2ioSqX/65c1zew9E Rl2+Hp2YVSwc+MJ7k/uHeZiXy9yK5DMR50/vOhV9PykRlrW1tXVWVmZCQkJ8ipmHh2dosHMZrFqG b29r7+ejuX7yxr3IyEixku818uUXBrd1MRfQiZyM/sqjDWhYBOgXjA2Lt8FK03Weg29GmRBRJlrX 4KhR3dGuWpJJkyZlZWWdPXuWzYJTNB7M5yH+eo8r8GGeIwaDhmZMEWgWCNB30WbRjWWczIUyiq44 UkP7dNOy8XIruCKlqakpcaAmVF8eHsynejYPTVilcnRe1GZyxdFmNDQC1LJuaMSbbnmajIK0fes2 JH69ar1KKZs/f75UIukzY07/fr08m26lac0oAi0FAWpZt5Sefnw7tWJZ0dXDh/a2auXWpk2bvXv3 Hti/7/b9tJLHn0lTUAQoAgZHgFrWBoeYFkARoAhQBOqPALWs648hzYEiQBGgCBgcAUrWBoeYFkAR oAhQBOqPACXr+mNIc6AIUAQoAgZHgJK1wSGmBVAEKAIUgfojQMm6/hjSHCgCFAGKgMERoGRtcIhp ARQBigBFoP4IUNe9+mPYbHOQSqWlpaVYvovM/mFubt5sm0obRhFo8ghQsm7yXdQgFcRqL1zAnB8g 6OLiYkzMlJmZKZFIsIS5r6+vj4+PnZ0dvyzg03LdSIPUkRZCEWjRCFCybtHdzzU+MTExJiYmLi4O q5Uj4GdRUZG7u3tISAhs6oyMjNTUVMzuRFgbwc/Pj9t7etLP0elVRBEwOAKUrA0OcVMroKCgAMyL kJaWhn16ejp4GUKHpaWlhYUFtA4ExMHRDg4OrVq1MjMzw3TVhWVBLBZDG5GVBXlZwE+scW5jYwNm R2K3suDq6oo9cmtqbaf1oQgYLwKUrI237x5fc1Aq1AxwMfYkEM7FES7gIAQN0CuMZQgd3t7e2Ht5 ecGIrrEAWNmE5bEnERyBcmJraysSicDaZE8C4gjgfd0Iint81WkKigBFoCoClKybyRUBxVldFrgI rOCkpCTozgiQNRCgciABTGDM0xRUEQIDA2FB1xMFUD9XCikLAXo3aBpqCagfzwBuD6MbxjtUb5jz RPgmETrRdT17gZ7evBGgZN1M+vf+/fv37t2D3MzpzpA7wMvEUiZ72M7Ozs6QOMiqibCdsUeoP0uS MUk8CbAnAXEoJDk5OSkpKZzkgjjMcIgqTk5OAQEB/v7+qBX2CKghLPFm0hm0GRQBAyBAydoAoBo4 S5AdqDk5ORkkiD20iNzcXKwYADOWCA5WZQERe3t7+G9we0Tqz8tP1DiY+URvIWoMiUCHgYcJ8Qsk gfzEIwTPEg8PD5jeeMyQ4OLi8kQl0sQUgeaKACXrJt2zGMEDwXFCM5GbwXfga7JHgNwBwxYEB+OU s6MfITo3hQaDoPGMwdgmAtG+YXGjRXjkcA8b8uwhTx0Y3UQT55RxOnrZFPqR1qEhEaBk3ZBoP6os GKG6SgJ+grzAYtCdof9iTyIYM4T5GRwcDM25dVmA6IwjTaUZ9asHXhSI9o09EdxxRKFQYPwTggl8 BPEQgumNZxL2IG4oOUTyJsIO0b7rVwV6NkWgiSJAybqpdAz0XIjOcHYmns53796FEQ1tF0IzCRB2 sYd7HETnagzVwOKG4SDjRke5wVL4BQIHIvhgD5QQQYDTN8xwjF4CFrIHONDBQeLNBg3D4UxzNkYE KFk3Qq8RPw2Od0A92dnZcJAg/m2c9xssRyjO2HMR8gFhI9S4sYuEol1N/CGeiEASAVoQVG8iDXFO 3zDDieqNCAL9Vr6x+5CWX18EKFnXF8FHnw/ugFdGflmA4ow4AmiFG1tDBEwEQxJv+oRWSMCbPr5G MWzljD932NdQvaF3kwDVKC8vD2BC0a4WoH3jUYcHIXn+kQgCNcON/ypoKS2gZK23nsYrPKgZujP2 CKAMkDLYBJ4bEGGJ/wYCKBsSMzydITcTX2eIztTnQW/dwDCwr4E20b4RiS8LeFiSzyzxIIRUggjk b8QdHR1B68SFkQsP+yBIj5WkWVEEnhQBStZPithD00PW4HycoT5HR0eDlyFrgIuJ4kx0VRAErDwy ERIZEMOe2nd66waGgW+M7rxUiOMI3mBgehPpiTw4EQeb47WGfL1JeocEaN/oOD1WiWZFEag/ApSs 64Ih7nzc8MQ9g0QgOsMc45ya8U0gect+8CNsmG91KZKeU28E8K5DNG7dwDmAE8kbz1eyRzfBGxLW NzHGiRcKaL3etaAZUATqiAAl68cAhzscn5zgJRpiKLcnkxlhz81qhFzguYH7mQRye9NBrTpelQ17 GgYn8WU8BCvsYX2TPQgdT18MG8DnBHt0JSJkEBgPYHxeRAJ5PFOn74btsRZaGiXryo7H+zJcekmA 6Iw9bmOYzOSVmZupDp9QQ2KGuEF8nPHKjAi1uZrfDYQe1/Vwx/sT3qLw8Ib3JPeBJSJkikEI4iB3 BHA6iSBA4Gp+sNAWNRYClKwrkYc9BQdneDpDcSYB1haMJgwGQtAEKRNqhlcvDnIT8BP1mYrOjXUF G65con1zexLB2xWRvMHdRP4GocMjBc7vZIJvTvvGpYIXLMrXhuuglpZzCyVrTnQmXwbCWwC8DM6F bwACFGcEEsc7L/numUy7gT11FWhpN0m19kIBwysXCbiQIJgggi934JTJeWeSOI5DJ4EXJvHFJOIY Api9hWNIm18HBJo/WcOXDncOdGfIFwiIQH3GPUa0DuJshyk4wNS4r/BWqzuLEKi5DpjSU1omAlDM EIj8jQj2uNggm5AJDrk5DqGT4Ejbtm07d+4MM7xlYkVbXQcEmjlZ456BOx0Ccdsic3WCssln3JA1 SIDQQUXnOlw99JTHIgDjmgjfxGuIRHARDhw4cO7cuYMGDXpsDjQBRYAg0MzJes2aNbt374YzVmho KCc6g6bh6UzERGjNXKDXBEVA7whA6Uae2JOAOIRvMDhe6eBkApFN7yXSDJsrAs2crGFN41UUtwfk ZgiFZKJnvIc21+6k7TIiBHBZtsyZXoyoj5pUVZs5WTcprGllKAIUAYpAnRFoiVO41RkseiJFgCJA EWgsBChZNxbytFyKAEWAIvAECFCyfgKwaFKKAEWAItBYCFCybizkabkUAYoAReAJEKBk/QRg0aQU AYoARaCxEKBk3VjI03JriwCZoKO2qWk6vSJAwdcrnPXKrGHIuvqdRu+98k6jHPS4qxczbIwePfrw 4cOPS0j/rn8E8K3vyJEjT506pf+s65hjzc/sFnIbNZCftSr7RkzUkS3nCwsKi8eOHT18+PA6dlaz O02cEn0tIvxEXIm5pljk3a1Dp169Q+ybXSvr3iBMtYHZWtatW7do0aK659IyzoQNpN/ZH/FlPKYS 3LBhw+zZs5sAhGBqnkapSrmw8+CtjKz8QjtbO+fQUeN7+lpZCNm/NYEqGrQKDWNZM1ppflHq7StX r6xZ8+O+ffsM2iSjyjzv0uljW7ccvHrr1p07N47v2nlwz6E0BaM2qjYYtLL4JhvTaGDKOoOW0jwy B1NjHpLIyEh9NQdTAffv3x+Laegrw/rlAzaW56ZE/bNx9+nwiDsxd65cPLf7z78vxaVLWwBTA7oG sqy5TgoODh4yZMjq1avr123N4mytpvTqh0vWZCbwBp1cPx1NOv754l0Xbmle3/5xdycns2ZvKDSL TmxijVj+2mv//fcf5ttuYvXST3W0WcdOH9gw9dfAzT/OH9TZoyDhxrpZQ+9OX/f00xMmejb/++VR lvXDlOV6K85PBuuDxdWmArVJw11BtUxcy2SPvTC5yX3OrzoutHfotnQMOaXP9HYd+3scWXGuNB+2 QosOD0KNkS5DIILBywez5SZdqvanR18A+ro86tNMrD+GtTBqbFHts33kHWeAkd5aS85Jp2Nv/Hu9 xztTnNu4ozn27nbTPuwVezTu5r57tW9dI6ZMSEjA28/Zs2frVofHWNZ4q/rrr79yckuszPh9encf O2ESKQarqWze8l9+dqGpuWDo0B79+3ZZ9/PWhPsp7jZW/s72cVl5PoPGOQjkRTfOJoh50hKpX8d+ fUYMa2PLBAeHjBs3aOXKz7av3xCXWSiWKxm+mYW999AJEzv4iMzYvDVM6ZmDx24fPZ0s4Gveeust rADAaLKLMk//9V/S7eikbt06Y27JitZKStNv/71hT0KBSmsqcnKwCgwyiYzI79ih+zOThz0RIrmp KUe3/JOq1NxPzwwL67Bg/vz4iwdPR91Jyi42MxGqLAMnjOnXoU3Z+2Bp0unDpyJvJoq1WJycp9EK vdt27TFwSIgj+8dK7UyTce3UqQOHIwr4NuZmVn5+FiZm6qtXZK++8pyXJ7vuqkatfqtTG9XYZ0d/ +sng8rpG7di8f86ytOsXPvP3dX6i+hsysUYmyTp7+NDtxKwiiVKgVSsU2uB+E7t1CQsoa3JZqGi3 +H7U+bNHz98RK3k8rdrer4Ong4tf8lnPaS+6uElT75z5e0dyalrmsyM7h/i6/rH9vEwgVKs09h6t OwwcPyiInT2cA3DPnj1RUVGYBhrT286fP79Tp071aGNh1t3LWzYdTpeb8E2t3VwtPb2F587mjRs9 qn+/LpjZfP2vq2/fSxLwTEL8PGfPW2BVNo95qVS6/veNSfduajUq/zahLyxYAE2GYcQlKTc3/bUv sUiNS87F0cq/tcmli/ndu/aeMJ7Md1reAmV65Pb94dH3c5VqHpb6atVhoE9+vI+12m3qAjs+U0ao annate17T8el58vVDLvUvZld50FjenZp7WRSlpPy6tWoK9sPpBQU5D07qrepidmpyGgtX1VQJGzT vc+Qcf08+JxQq9Yq0r/85veff/krNzd7woQJmCJKrVZqtBaWNkEfvTfXw90JV5xKkX/+yOEb91Lz xQoBo5FLlQE9Rnfr2TPEpTq0O3fuvHr1KubdxqzcGC1o3759ZQr1/Yykc39tu5+UnNGvc1DXdkH7 T1+XqaRiCc/WPWjsnKl+VkyVmdK04qzoy7sPhGeXqtWsqC6wsHbsMmJKtzaOVhWrnkUd3n85MipT y8fyl0uXLWvj43Ju77bwu5kKuVRj4uDi02Hu1P7mpsJD3638e+2PA07fGecmKqtykbpwZ8fBp4YM G7Xqi2cevDwWL14Mfjx06BCmQcYCIyTBiy++uHbtWi7xypUr33zzTfLzyy+/fOONN3AKZuhslEfv iBEjMMW5bvV0G/WYlbZlckV8bGzU9k2CwLY2rYPGVpxaWnj/xoVNO6/aPdXGuXvXQI1Gnpaetmb1 aq9WLvOenZycfOtMVpEl38Rdnis3tVQUJd/NkifLXD6e09Hc3Czhzt0ze/aeu3ynSCpTqNUwmPiC VCwGIB41uHtHf0tc65qCkuKcEydOXb8WsXDhQpasGYVKjmnd03/++ad79/pzZF2QGHNu529nLqcX qsytRI7FuZq82HNf/pI5fdb/npSsFXJZVnJShlb419+b3A/a9A/zP3su4kZ8RoFEKuTzCwQW/fvJ 0Xp5UcKRHfsuXL2bll/CE+IvfJBubkFRSYmYN26kn4MZp17cO7bn+METF+5JBJZ2NjaO8vyEpLhr /x00f2byWELWuKcjJKpePG3Xyg4J5ZneVEm2aTWyehCT3k/VatTy1LT01NQsiVwjUMukJdlR6fwC sWrxpM4VheFtSc3I0o7v2Xv8/NV7OWIhjy/gaYu1Zhk3Lx/859vFfcdjnUKFNCshMfGP33/LuNNl wqjhN+8lCszNeFplcnpWanapaM6Udt52FhU5YrpEDHBhKtHNmzd37dq1PmSdcT3i5J5N4ddzFAKR lchJkleUdPniqj+KHB39QNa4LbFG7v4Nv+WVqkcsWjxVpbYqq4NGrUiNOfLrX+f5pvYvL7Ajpn1+ XHT4zj9OX8koVuOScyrJU+bEnPvy5+y5i0wryBpQlOYl3dy7Zde5mNQCicKEzzc1EUotHC/v3ehu wbw8bUFZ9pKMe9cPbD9w6V5qsRRrX7Az9WIq1fxCaWHe4GEju7sIoFGWSCXZt27d3r1rmzQ3uX1Y p5jEDFOhMjsxNjG3sMDMc8lwPyGfvKeiETKsSYcJ3FUqxe3bt5GbRqNSa61E9qZymEQkkUaZnpmB Sd2LZBqhViEryryarkkv1ITM6V3tooEfCBYtw3rQ//77b9++fauQNSNTyLIxn+VPa9dd7hA8b86M 23HpAr6yODNFGn0rV9T6lbGh7nZldhcbim6fP3v8aPjNxAwlJiRm28kIhclFUpVyxIguTwU6lD21 ivPyMlOTo4ulWzdv9nGyHj6g95nIG/HZEq2qVKItzlO5qctegJKVmmiZ5h1LvkN55tZ8q75qxZ8a eeyDFz0M2CNHjmAue/Kn8PDwPn36IALiBkGDlBEHORLsSBqQ+4P5NOQR8lxBzUlVqwdupt2HRtSK My/2+G792m35lUlUGWdubJsx7Ieo4wkq7ujAfn17jJ4Uy/6+06dLgF+XUZsuF5f99e57by0NaDsN sd59ewkZwfhBz/9zPlVSfqo079rOmW29Zr303p501qOWBIxD4sEOrHUrNnbs2MGDB3NHDv7281An 218uJeaUHVIWp+16q3uge6fFy9c/vl0PSbFo8UvmePyO6Pr6D9uvppL6a1Oy5GK5ViuOubHvXbfA Mct/PJyCn+VBfHHTRy8OCpq/+frtvEo0XunVac7UWUcrQLt/+qcPxgXYuj59+VoCOQ8r1IR4e733 3nu6Fdm58z9Tc+e4uPI0dW6Ffk9UqZWxKTkFxRKIBiqlVFN0sXuX7pOmLNQtRSPNzjj5WpeuI0Yv /vlOOWxabXHcvrXLbExNLl2K5BKHhrRmmIDRi369X4FWbPg/r/R0nfrTiVNpymo1x5qHGOb6/fff 69OiX15/ZUyboE2xxdKyXIrvR2xYFOrs1Pf7nw5w2f63fO7C0YNXxMqKuT5UisVX3n3mpZUvfnOF S7Zn7ffDXB3XX04hHSsvSNq+vIufa5dl7/3FpVFnHN3zwwxr7wk/7L2ZV3FFK+IPzxnZpVe3niSZ OnXf75/OtPaZtP54XGFFGk1mxOeTeowaOOzzyAIJzOKyANtWZGUZ2HvCtzvOFZJDaX++99IM7w5v yuTV4cKbKKZrfxhWoO/4tNzcghI8eJRKuVZ6dezIoX36TXxYerzTYD5hPCxrTNC7Z3cr97b/+25b krSsqsVnDv26wLzVcxFXksrTazSy2N8XzJwaMvD1M/dl6opcZNmXPx/feuby/1t7VaKbM1Z0snNw 7OZmvnTB/G/33lCU/U0iw90nK3O1137zxed+bq3yJKQbSSgNbtvp5VfeeLCGsKC5msNSBlmTNDgI bzTdSLVziQ3+YIY4iHMJgSKiGyeJUSJsc5SFBKQIkpjEEarlTFIiEEOeBOSAfB4sHUdq4Q3CF/R+ d/G1aPm2r05yTH89qvDPL268PcK9q1/l+s24ulxMmUA2UYhcK3rKz2Z6J1HZKW14JtZq6S3E1KWl zv3G9fr0s3Gd3CzLTzW3Dxny1e8L+EVZ697cwBWB9ZAefLRUEy6LlOp7xdLCwnI7VChyH//W1599 vXTCKJ23tid8MuJ9zswjMOSV31+ePjzMg9SfcXcytTJlrp+89ueHm5b8+uXixcM8K9/0rLpPX/zS Z2/u/eSb+9fYNpJwv1SeXCCVScp/evebsGDFqs8/nOzhVjnfvIbRVtPv8RM0/oRVNnRyrVqWcmLd e3NH9woO8g9s133ApPcvXblsbcG+anAhN6Pw21c3t5865fm3ZoWUw8YwooDOA2Z/9ew0X6dyf0Rc c7JSWY9Zw1/8eI5XxbUT2KXbohXzLv28OebEpWqNqfEyeNIGZ8tVcUVScbGcoC3yfmrqx9+v+HJ+ 725+XFZjFvbr0Nv/16WbFEWl5KC0VP3Vy1s7htjPeeEpLlmhUh1bJC0ulJMb0dTOZ8K733z29Stj hrbl0pz49+Kezdfn/fb5qP4hDhUdbOI/9LkJz786fCBJtuunw2dPJLy04auR3X1tK9LwWnVdsmLB wD5uvy35rrS4vBp4qCuUqldnjX51Qi8bcrL7dHMXH3nOHkZb/R555DcsWp42+9yfny+e0D+0TUBA 2879xrxx5NR5a8uHvsY9epxAUiob0/+pr/43ydO8rAGiPjatx8hz92oUuaSaGq1mzSvrbD0CP9u6 sq+3Gcc1Zs6d3v7nF01u7v6v1+h2Jfpao5A5jFo6bMlnC4eGECnI0oxxw2h7WQnAnNWYqtwzeB1R 45VBNx8Sh1ndrVu3B4/jCFlN7c8//4SpVGOChx3EKbiAwfvTp08/c+YMF+fSQ1FBuTgOKxMvN4Rz Ed+yZUu1PGHUv/DCCyTBsGHDiI2P0KtXL+RQYwUeI4OUncPjezwdVvpObNLdW8zAYIYRqi8nFCWc cZrxZitb7q5kodRqTXjlDxMNT2hlVsnjWmh02hKkkSvVXYPcZ/R0013ckGdq7dp9gfDn95Kv7GKY 50hFcaE8OPbDPaxImk4dg56f2P3g16+eWG1pJ7IW2dq4ejh5hQ0LaR36RH2gm1iuVLk62o0f2M4b BnZFIGM2KSWqTZcTPb565+LPVlYahZJcITyBmakiLyc1KzpSXgKnjjBy0vOzRu0+fn7F3LF/2FpZ Wlk7ONm4BwQFPjXKXFR+xyGNo5APYsZNWbF+qkKjFgtMnJBnneuv9xOLY6+c++eHf2/xvNoPmzva 0dTMTMA3uXfzhlJVhayLpMptNzLeDPIY5sUpGWxdnP1CJvxvqb0rq/yQblWoNJ19nUa4mFTedOZ+ PmFTipKmSXJ7MEyVV3K9fEE3bHC3wpRrG9+cs8faEmse29rbuHm5+Tw12sHLl4PLPHBcWz+xz+qf zheM6OdgaatKKYzdv5cZ/opfp+46F2vXziEzx3bas2LJ0e8tbEXWNrjkPJ29woa3CgzhsrqcWnQ5 Xfxb32A/Tgwou1C6jBynFLN3AcLZxNz4Qvl7/f3YkTKdYB34tLNXZur1vzWqJQzD6jEshWm1bs52 bBblKU35JlZaVc6DfQ1V8WEjgJK02MgNX26NVNq0HjBruDP0dzNTi8z7SUrlQ8kaRVe743RLVGk0 9jZWhFLLAo9v0UqrzsMrLvkNy/JwQuHd2/9cTk7+Vy1jm1GWDMHCrGjr5jNdu2Gw5nXufBSnUqt7 dgga1N5FFzlBBc1b8nk2fH6OUmNrQUR/DaPK4vGt+ILqa6VCd4YZW+MSl+BZYhSDQ7Hm6oMYPuII UZOJRrF8+XIujuJIWbCLSQT8Cxd1khXi0JR0s0V6lA7RgxxEtpyDPDLn5PVqNamFZc1eIaJRXS1C PDJ/PZSGfsg+sS8j+W7onOctzarclmz3VGSPc6pcNXj0lf0NB61MeDV99WFZJtpV3v/4IeAxrMSl E/hla3FxoXVY2MuvLgl1MpFkJUbfvhYVeenMyTMHDp65E3P/ifpANzEuKVszRpepub+qeTx4aajy s3IzUlNS08tDWnJCYo5Yaj1q1Ah/33JKwinj58x+ZvwwJ1VeasLdm9fhEnruxNEzh45fLK6wmNCw MAuhTMNcqyw+RqtIFVp25vGq3OV1boteToy5Fb3xty1uXQfPfPkNGA6vLl36yitz/Hw98A6umz+6 Fzc9CFjn7mX/LjA3de7YSWgJ3qmkETzoqvq78LUaaLR4chnE5aPr4EEvLHzez1Kenxp/5+bVyIsX Tp84s/9Q+P2UrIomoG72wUGh0/pLth6PuVfIKJLunfz3H//Js4JC2uk2M7hzp5f+91KIA1+ckRh9 63pUxKUzJ3DJhd+NrbwbgQs2i8rRv/IMrD097YPLOR0CLgbbalrkHK9swrIboQrryhVV0X7AwiRl 4H7GXVNjSElM/mPdBps23aYtfv3tt95a9uqrL700NzTEv1o/1v6aQTlKVVXT/oEHhZTHV0hKSrPS 2MVPK26YtLTUuERZz15dnh7fs1px4IcAO/7Drn4PE36gGT+yVF1QfppEJb4kMPXim1W+IXEZciID OQLlnSzgB6aeNm0aOYga1b69ekyJcqFNV8sQDP7oImpD1mwOQTNGOHXtsuv/thcXy/bsTMu6If5w uovFE/kCl9GuuZAflVrwX5JMqa7sWPgXlMb9pVbyHP1Gc9U15/NcTPnF5eYrDrPpVQq57jdaSoGd efvxP27ac+Zs+NE9237+9uNXpoVd2vbzoc1/1xlZdmTmIcZJK6F2UmvXDzZs23/qdPg5Lpw/fy48 /MyJ/fsPtgvryDVLYtl68PwPdp04H37i0LZ/fv/mg/ndvWTrP3gzI7n8QQI8hvvZlSrUR5PLdQ9t 1iVJboyd/yi+KRniahIhoVgVXmSyfN7wwSHwKEAA0WZo1DKMFunWT2QqGOtjH5lacLpQ97BWrVRI JWKxQqWokHzMhPzzyQW703TUHnlCZsw261Y9ze2CqrWZdHc9P8yTCV09Bzy3Yfexs+imHZtXf/nm 7OHee1Z/HnniWEVxbCmuYb6j35l3Yf3xhHPXIu/k/rm19O3pgV38qrg2KAQO1k9NXLtl35mzZ47s /nfdNx++NKXd2c2rj237l6t5B0fL9vbm/9xMT9N998BVLiuVlJZKyi6Rnq4iH0uT32/m5ymqXG2a rAPF2TGOfuP5gvI3u4cjUGbeVA2WAh7Mz4LKuwYKAXpAgVSZpZrD2cwLMwaP61hmUkBtU2WqVKXV +lE3v8eCX2O/cAdRud52gpeWLPn1+PHws5U3DBs7eyr8zJk333xHpdWx8MqaAzX1Ydd9GweLbu7W +2PzssijXl6YG7Pb3LGtpXP566zuidXsU06z5pgaKsSmTZsa5R6DRc+NfHIVeOxS97Ula8Z0UKBN SP+Uz49EfLTVvH16wHw8y6q9q8P3SFjxxoK3J6Gw0sZi1fEyKcHS1iZ2786fXnj3eExJRZ9oZUln Xp/xjdTCbt4KzieP8TLjj7UVbImWxJCHtyxzyyczb58/YmVTaZfv2L6/e69xpxKKNSZWzt6tu/Yd PKJPNyenYKW2Jtv94d2i+67HelDV5KmKszv3C5n//vh3lnz5x76bVSQARpERc+Gf7z88cPNWSkUp M6cvemH5lykaxtTWNbBtxz4D+/fs2JEx8dVW+DXhmu63rLc0N/vst+VvQxc234g8Et/3zYGW9jWZ XI1yWTGMjzm/nxWz505halkFipMuvDtp+rWoOzZ2dro1cnaze+ObqZf+2vLbys2V5ooq/8bxjW/O Gv3lsajr4vLkJpYW0Zu2H3xn1c3i8iMx509+sWhN34Uz2g2GDFIlmMNxmAfXt6rOYA+9nWvG6Juv 1gwZ/dy1AoZnYefhH9JjwKChPTtbiVqrtLoyHi5oX3vPaTMFe2L2zPozJlL87LfeIptqLwpbNu/s 2XdieHKp1tTaxSeoW7/Bw3t3dXDAJVeJxrAp3cc/0/6HWW8di0hkaZJcv7l3t3792vJXX/otTox2 T1s8rFd/r5VTlx6+nFYpQxTf+vH1NUeOJ83+cbm5Tfk1gPFVIFDmNVgZAMiDsODP3kLGXq76Pbq0 AmxtafqdfZt3JSRkeInMhtrwj90rjCl7e1HkXv9sxuzwg+Eiu8pBlGq4kqKrg19RC9wmcAHQrRU6 Cz/JHgGuH699PSslPemVxb8kVL1hlEXJJ/5d+8/m3y9LtcqKUmvsa1ZMqQj+/f3CpoQc/2R7fmI+ jpXmSja/e8xzUOuQsZUaFEkL4oNl/WhbFQ4hmMZA1wOEE45rvoz0dxTVI04pJEvUAYOKJE4cB2ss qjaadfmJQe08Jk13fHv5j+5jVo6YpetZoirKS1zz878RERdFdn6//HHyhecHQvbfvWvHqtVdhs2Z FyqCPc1DJaZNn33yVHjfp0LnDBbt+fGNXfB9EwoEWoxRq0z7LHhm/Oj+bSpJyrd98Mx3F3634/sP 9pq727BXqtA8QGLmcubYof9b8WXAjPlTvBwLC8QQP67tWHtTCA/N3OKSYhB7t2cmjxrS74mAxRWZ lJjw608/m1hYnDp9Ojcn5/3332dXoRaLO3TqPGPObHKjmLi0CRu+8LX84wmnN759UsN6WbNWBE8g MGE9B10CQmwcnCtsnZt300xj40+1EyWnZuXnF8qkpSoLx/9985aHX8XHuzyefZ8lY+9u33dk85K3 Loh4xWnxxU7tpr0xxMPe8iGvsk/UKj0lbts9bPbrM3/65f3o/1p5OFhbCgX2wxZZRbx/YNe2T9sE OwyYPr5tKw9LnsDKIWDIkuXJOy/cPP7eonALoQlfLeebmVvYOfkOf/6pIF+/Cs1MJlePG+g/prP6 j/de0fB5alWpXMazHLRsztguT3mxpAwbtOTG1p3hcbczNFJxIRzI4A0SH3cPXgACy66zp/dqE1jh u1W7Nt5Pyz9/Ivzy1u+PF4lzcvLFErFGYDrptUV9RlZ3kDIXOc95Z9A73+9ML8h/a0VfW2gZVUNW TvHNyxHXtq++Coe/rNySkhI1w+szc9rYYZWXnLl/737jzd7M3nV+44pzm0zMBDy+RimwthXZBXQb 0b5TK3NzjOH4Dxwx2apAdujsxi/PbeKbCvmwGPCGqbHuMfy5/qP7uFviKaGMuBp5efVv1+AJvvr7 73L45h2HDwyTn9mxJ/qvjZvgJbJ82bL2z7/Yo23rNhV20+DR/ZWy1D0rXr1rZ2kvMoP/pFojtHHw 8Vdo2oX4L/hw4brt371/cKOXi70lX2vXe7ZdVNaZY4c/+vQzx8GzRrXzChDxtCpZ8fUt28MTYrK1 xQW5KPqXX365efNaqZQntO42d+YAf5/c9NhjP/+dePPWncL8vG/Wdew4bU5Pq9vXz177ag0739bn n3w86MWlHfr162nKd+oxc5b43PHTN9a8s5x122MdDUHyfBNTc2sbhzZhrf3MeaY8Zud//12KjJBI ZeV9HR+PBeAxsjr9+bmdQytHbk18e7cbzJ92bvPG1f+3295EU1SUaj1hxqBO/YNqWAIbSnFERMSj zVVgDoLmXgU4B4/aXVb1SkW89IiLN9xFOP1627ZtqHmNWdfasmYYGx/vPs+93M53yJSebYZyVweb K+hWDXDHjR2LT8mLS8R4Fk6aNGlA/wG4lIkG2a1rtxEjRsqksuEjxix/c8ms2SMCnUy0KjnOkim1 Anu/MQsWDesXpnsLWrr5dJu9YECgoyNPWiSWafhW7QdNeW7Rq0OHDBJLJAqNFuNy7doFPztjtp+9 GaOAT36JpFShMPeaPGXY4N7V9aDH4opRHLlcVlxcNGDAAHxTUFqKTyKkcnioKjmtEE94S0uXpxbM HNkj2FWoKJXJZEiAvUrLt3byDus5JNi1FadfTJs+YeLIvrY8GVJIxMUlSrNW/h0WLxjeyokbDIG+ 2xqeiJOGBwEZcZHYq/vAQROmdLTm4T59Qtvxse2rewIb3zb9Zs/v7WMn0kqLpRpTW+9hs+YvXra8 X5/e8C5XYAiqPG8TRhTy7MyJEwZ3EGkAjQwQqnnmrgFPjZ7+3MBAV6cKwwCgdh/QadL0wc6mapW8 tESidfANG/vCkr7+jhXQgLeUSoVcLBbjxn7mmWdgaxQWFQFtuVxVh8Xp+/XvOfe5yW4WrBIhFhfj auLZ+j83Z1Tn0OrjSzye2j/UUebcy9al+zh/vskD90dYx3YzZs70sTXV4pITs5ecysJ76rThA3uw w0plAXjYuoUM/N+LEzp42/EhAuFKkSv4Fs5h/ceOHT88zM4E9ASJ3Dds0NLFE0M9RAIVsCqVyxUq U+eeE2ZMfGYUpBe2ZLjhyCT4LGjKlCk+3t64s8rmilWXFBe1b9/hmSlTQGeyinFuUrZPt57jZs/q 4SIUqmRiiRS9IxQ5hzwVivFtgZ17n+cW9mnt6sCTlUjVfAu3AVOfX7Ts9RHDhkrEErlKXTFcQMBX oHMBNVu0j08RC74C4JeNX8LrVI67Y/KkSX179ykuLinTddSlkhI7O3ukt7ezE0tKy/VAgWefQUPn jO/mIFAp5bjM2TtGIVfi8x//9j06hnVxKUNYoYKbZGVfs8WxV5Csqi8QO67gFjh44bPdXR3NCvIK hNa23WcsGtrWD9+PPXi/PPvss5yzBzSHmj2XGQYsyfnJEYUE/F7jsCoOctRfYxzjhMR9G6HGeLWc Ob9kjqlxIh6NqHmNt2vt5wZhRzR0sqj285FcgAvsAXGt7uTBnfnIbDGsXJCfD+v4sXIncLe2tray akIysR7AaapZAG0vL6+5c+d98snHdatjSUmxRFL6MKlK5+rQguYcHJ7MBtfIi699N/kfs2fc+s5Z 3rmaBML6Oz32cqpbo5rIWbW5q2uTRp/NqQd7cF8w6rM+hszr0V8w1p6sDVlHA+QdGxsLL8vi4uJq Yt+DRcFGWLVq1dKlSw1QC5plJXlyD3uQNcZ2IDTVDZ1nnpny33/bIKc++nR0a8+ePc+fP/9EpahK E0f3fmP2m4tnTCt3iH6i02liioDhEGi2ZA2a3rVrFxQ3DBg+Gj6k6d27d7t2VTy0DId4y81Zee7y 2W3LP7l+6tTJVq1ahWG6CaHwua9XDw4NeGBqikeBdPz4cTyJH/sMRrdiIuxx48Y9FnDQ+oIFCxIT k6ytTKWlReHnol1d3V97bRFxpKWBItBEEGieZF2H19U6nNJEutBoqqG8cPns9ve/ira1tcNHecWF hWZWVjO/WDUwhNUcaxkM0U0YdcD7clJSkoWFJZ8vENlY5OYUDhw4+O23K7/XqGX1aDKKgOEQaJ5k bTi8aM51RaChpc661rPyPEM8GOpfK5pDi0WAknWL7XracIoARcCYEHgC1z1jahatK0WAIkARaF4I ULJuXv1JW0MRoAg0UwQoWTfTjqXNoghQBJoXApSsm1d/0tZQBCgCzRQBStbNtGNps5owAo+YJLoJ 15pWrZERaEyyJmv9NjIAtHiKQIMjgMseE3hipcQGL5kWaMQI1Jes8TVBg80r+AiYscQkN5k3mUaL hGozfJPHAxfqvCa8vjoci/3Qx5W+wDSufE6ePIm1aPE9jnFVm9a2ERGoF1mT9YN1p4xqxJboFs0t lKm7uBlqi8nbuD/BtMHiEdyUso1Sc8zyhXWAGn1N5UZpewsvFB9MRkVFYfl2zJzXwqGgza8lAvUi a6yz8Omnn6IkGLPcipDEesUeHAQqhG2Ln8T6JiZtNUscHFrtOLLSTUNyw+lcytpbo7qTDT733HO6 K/pgukLwNZlPtlrQNcAJk+oqNlwDSZVIVQkCpLG61XuwzuQlAMggGeKTJ0/GDOi17C2arNkg4OTk hLkecS3pzMHbbBpHG2IQBOpF1tz6weBBrPtLKogJv7HqAZn4tTZr/YLuyXyySP9oOxeGMOiVS1wb PPA4GTRoEGFbnMut6EPOJctJPCiG6C5cjzaiVkiJCcJJSswOTpqJPSZ1I/kjYCFOsrAxUpKGoFCu zrCguScQtyI95th9WB1q0zqaxngR8PDwwPStuBIoWRtvJzZwzetO1rrrB4MEDx8+TOxfsDZnz+qu 9Ys4aVu1tX7JgsEImCn8xIkTj25/LRe4BG8SC7dfv35kOnCcWONiOTByU1PJelXlAQYyHjbcVOVo DqkVSJnMt4mfaAsWoidxmMbkTJjt5BGFRxc5BbTOIYBqACKuFG6ScgJItTo08EVAi2t4BDDvoJ2d HbWsGx554y2x7mSNNuvSHwgOxiZZYv1hizLUCJPuujsPLiKpewpRmYl68GjEiTANouTsfaxQWeMC 7yjR09NTNzcsGs+tIU+Ok1r16tWLUDB+gqBhRJP4I9YNgi6JdwtuPJMr5WFrrBnvZURr/qQIuLq6 UrJ+UtBaePp6kbUu/cGaBjOCrzGvfN0whXVJnDeqsSeXG1kUh1D2Y5dtx1mwXkGmREwnagMnrJM8 QfrIrdqjxdvbGySr2wRSKyRDbjgFDSQEjdwetloaOR2kjwcGt2gQ9a6t24XRLM/CXNv29va4/OgA Y7PsX0M0qu5kXW39YHAZXvPB15wsUMvqcjo1ZBAICDgLVjAnqjyoYpNya5k56gNJhCSGOI44Z5UT QfnBJTIh6WDEj0uGKpFaIYCakQlMbMRB2agwZJZH1AQpaxzArHYKavKw51Mtm0mTGR0CIpEIlnVm ZiaWPjC6ytMKNwoCdSdrQl5knI0Espr6o5cTrrGRRCgA/XELVsIgBSPrulXoemhwtu1jIcMjBLUi I3vInBNSkDPyR6g25Egy1E3G1QrHQc14ihBLHESMZFg57BF1QEo8DDgZpEYXPbSLy/OxzaEJmhMC tra2WEkyPz+/OTWKtsVwCNRrPmuYn7A6Hy00G67q9c8ZZjuxfBtRoEAdoLpwo6z1bxTNwVgQwO0D pW7ZsmVY4R6SiLFUm9azsRCol2UNy1H3q5PGakOdy8Wt8kSOgHUu6GEnQvXG04Iytd6BNYoM4Wft 4+OTlpZWWFhoFBWmlWxcBOplWTdu1WnpFAGjRgDL/q5fvx7mArS4Tp06GXVbaOUbAIF6WdYNUD9a BEWguSJgbWvrGxCALwAKioqaaxtpu/SIACVrPYJJs6IIlCGAz3GrbRoNU21jGGtTU18Pj4z09KK8 PPasB9NwR6rlRmFukQhQGaRFdjtttOEQUKsZWMqQocViRqlkFAp2w0Hs8RPTNmGPTa3WyuUxyclj f/nlzeHD5w8ezMCHz8KC4fMZoZAxN2cjpqaMiQkjEDBmZuwecUtLBkORNjZsShpaGAKUrFtYh9Pm 1hMBiYSBsx24uLSU3cDIIFnscRwRbJiiHTyLDfRKAo6QjcS5I0JhvkTS+csvl/Tvv2zoUJbBiQVN bHNia5PAWdacrY2DyB/cbW3NWFmx3I0IfiIuEjF2doyjYz0bSk9vaghQsm5qPULr02QQABcT/sWG iaexLylheZns5XL2ILfhrzgCwxmkCcsXGyKwkTnrGBHQK47AQCb2spUVvojp9eKL43v1WvrMM3a2 tiz7g45hhiMrRIgxTiLEJEcpMNtJBfATBjgIGnY3NkRQBFgbEWzIjfA40uAg2RBH0TQYJwKUrI2z 32it9Y4ArFdityKAHAsKGMzwlZ5euZEJv5ycMB8C4+LCsiEMWIgSsGSxRxwEDZZ8kiCVy+fPnds6 KGjqtGkhbdo8yakMy+kgbtQTZn5xMRvBT2ww/FHt+/fZtjg4MB4e+CaY3RBxc2NcXdlKEksf5j9n 8j9Z2TR1IyBAyboRQKdFNkUE4uOZO3eYu3eZ2FgmM5MlMvAaSBns7OzMboiDjmGcEgOZCB3YSIRI H08YNFrtrZs3rUUiTBVigZyfNOABA8omxrjuHmY4NhjgGLrMymJyc9ktO5vJyWE5Hc8VTG4THMyE hLDbEz5gnrSONL2+EKBkrS8kaT7GhgBoKzmZwaRd2IPRYGNyGgJUBQgIsJ2JoAHbGXHsDRA0Gk21 BSv0WQhUGhjd1TZO1UEE7xBQS3x8GG9vxs+PNcDpsqj67AB95kXJWp9o0ryaOgIYBoSxCTOT7EkE rA3OAk8FBTGYYRHThMH2bMYBgjhEErxJYO5f7EHZGI2EYII9XiOwkQi0HUrcTekyoGTdlHqD1sVA CEAlgCyA4TsIHZcvM9eusQY1NFyIAO3aMW3bsgTdYokJGvetWywy168zKSmspBMWxnTpwrRvzz7A iCthiwXHQBdknbKlZF0n2OhJRoQArObISObYMZamYS2CoDt2ZDCah9d/yB3wjiB+Gi02QPjmfMDx 5pGRwVy9yly5wmrcUOoHDsQiSWyEhsZGgJJ1Y/cALd9wCOBl/9w51mzE4BvoBm/3sKaJd0TzFjrq Ayk8AtPSWH8S7DHQCpkIbyRwI+nend1a8lOtPqjq41xK1vpAkebRpBAANeN1PiaG9esA48BahBLd uzf7dk+55ol6CkOvly6xbyTAEA6LEIsg62Mc0jBjrU9UtRaYmJJ1C+z0Zt1k0AocovfvZ6KiWDe7 iROZAQNYxYOGOiMAneTGDebgQQaLRIeGYs0RBmtuwFsGWjYNDYgAJesGBJsWZWgEYEfv3cvs28eq 0viAG3vwNYRpGuqJAEZoIYbAwRGUffEi+/B76SV2bPbJXcvrWZGWfDol65bc+82r7YcPs6YfLOuu XVlPBkgfjfa5B2b2KJsDpBEDzGFDuHBAGLl5kzW04U7Tty+D+acgZ9PQIAhQsm4QmGkhBkUABB0e zpw6xU6XgTf0CRNYB49GDVpFSXHSxfPRhen5Ei8Pdyyo1PDVkednJMffuZEhFWqkFo7+Xn5tQjz1 JAeBrP/7j/1CskMH1lfE17fhW9cCS6Rk3QI7vXk1GR/pQZ7+4QdWTp00iX03bwJBXXQ/ae87b2yM 23Ekom3btrdv3274Sl0/sHH75i1HM7XWmlwT+6e6DZr8xqKhlk/8SfxDKg5hZN061skPTpAvvEC9 axqgfylZNwDItAhDIoCxxE2bmJ49mXHj2G+mm0jQatQKicBMNG/evHPnzt3FlCMNGzQJ37/+3d2I zHa7fpttJ7LY9/GyoxG3bP9vx6vt7Jz09daB74wwPAAVu3VrZvZsdu4UGgyJAH/f/kNiTLdIA0XA GBE4e5aJiGC8vPTC1DUucl/HJZV5fDA1EBWJRDVmqwN22dTVur+1FdNYVzlYPdmju+vyT4fEGmGb BU87ikSYd2rghMD2XS33rIoozpXqrZ/hDQINZPRotgsw6ogZSGgwJAK8lV9/LxJZ9+vTq23bYEMW RPOmCOgbAQggK1eyI4rwz8P3GvoISqXy6NGj6Rk5Ah7j4eo0YMgQU1PWmUQmkx07fjI7M5fRajy8 XIYM6hERdetuTIIJT+vv7JBTVGLu4e/s6amMu5wlUYlLldZ2zm26DWzjLHhlyZLjx4/cvnMj5mpU bGJaiVyNaZsYE9vWHToGt3azInVW309Jij8XlVtcVDho0KBADI1qVRrZrYgr6bdjciwtTCdNmmRa rsJjxZnsqHNRscl5CqGlpZm5u6dJfr5MqRBNGD+YzbkirOjWNqP/mD5frpxSrnucO7B9/5SX5ZdP vxkcpFcTGDOrQA8BU48YwXpJ0mAwBHiXr92IuBSZl5c/ccK4kOAggxVEM6YI6BUBfCENt4TffmM/ dVm4UF9ZSySSl5csObptm0Kt6f30hD/XrbHFrHsMk5+Xs3j+pB0nUkzNbWY93fn7b99e9eM/K79e i+OvTp+UmpEk9gi1Cwyzv3M0XYr5pQvNbT1CJ7z76bynPnz9te3btp46uHHTn9svXY8Br8JLQyt0 6DpozKgxw3u3czcDwSpOhB/f/+6Ka+FnTvz8888vQALWStX5G75ZF7niu4NSSQEW1bXHh/JgdVlx 6oW/fvh195k7OVorFyc7+7YBacdO3S+QdEi6t0eg88nP6NCgkFHjX//qq1bl0BQf2Ltz4ozvr0Zs Dwn20xdcbD5wO8F8WK+9xjpKLlumz5xpXtUQKCwuyczO+WPDP++894lYIiEvfTRQBJo6AoWF2q++ 0q5apY2M1G9VFVrtmfdnfP/S+LXJklJ1ed5qWV7GkTlTP/9t2X/3tWq5Vsv+4ZOPPrSyd9oblylT x3/01gxzB+8P/o5MzJJqVTFH9qyycR0dn5jz+Ref4I4bEtz/89+OXksuUCnk4pLi3DuH35swaOzA Mf+mKiVsTir8l5qaZmVltXbt2vIiNSgF7VtlbW2dn59PDmYlJcz0c/7g+98uZEmVcplUKjmxasqg 1h6BHRepVBV1LUvZMdD/9eWv6yJz8MBugZnz7Tsx+oWrPLcvvtB+/rn2yhWDZE4zLUOAfUcyNzcf Pnwofhw4cIQ+zCgCxoEA5vmEAxkm+oBooNeAZa/6zptg267rplWXtDIlyVsqFfz7483Bvg7zxnoz fIzQld04FpbmQn43Dyczvj8jdLFgpDOHhPq6YHWCIDuXdsWZF1SKEq1SzVg6urywfNiQbmFedgIT UytrkWNw/7mvjOnxlNU3y/7IzynBcorIzd7ejq/7jQmPHQcEU+s2TqZSRyTm5MmE9i7mQlMzc3PL gc+9svTD1xfO6aurgeAUpVZbzc2axxMwajkWdtQrWhWZwRUHEjY+8afBYAiUC1qWlhaTJo0/evxk amq6wcqiGVME9IcAXKoxPxxZT0vvwWeIq5OHycG1d0okZWydX5R1dmv6Ux7O3m11PodUqlRCHuPI V7HkyFhbWZq2blW+6LiGh1rl47BCoXJq5Thrzpgwb1ZOKR8l5Jn5DZge2qVrxO4/ZOLycTm5HKZ0 9ZZAQ9dlYWtri6ef7pUZdfCbNz5asfKb735Y+9f+O6UObboMqk7WNgI+lqFRVOan1WokfKEtr+zB oP8APxzMX4geocFgCFR6XQYGBnh6epw5e85gZdGMKQL6Q4BM7Gmo5V9t2znbz25zddeN1DgQXsb1 uAsbzSYtsvJpW60BYFdVGcPyoN2ya2ypSQJ47pGIWsuITHjdHBgyj4bOd42ujLmbkEnkgecrAp9d GbHKp4881taupHAHe7sP3n3Fm5d9dMMPK1d8vuLLFStW/rx598XoNCnWRdetW7CFABW7U3koSS1P E1qGMvwnXzysNp2GRXZQc7zu0GAwBKq4yHfv1uXSpSiDlUUzpgjoDwGwGCb9wIQVhgke3QN7vT59 08pTSddLYq/l7/ru6vszfJ5qXVum4yjXlM9kS1WbEkqLqlnN8nBp9hVzx7E8QblLCE4RCatxNQiQ X8XcNrWy6jL1m81Hb969e+Xs0S1/rP34lRHSmMOr316m1VQpYKizpULDHM6rQEcSpSi6ZeEyii80 yOJkrDcIHlSgbBoMhkAVsvb28U66n2ywsmjGFAH9IQCFFO7VWMwbEy4bIpi3dQmY2jX+z6Qr72/K zQ53eTHUocwvRCdgsAfkalY2UZRGo4XizPljsGY2w9jZ2to5OUpS4n+ctWz/mSQZd67i/uZP1uze HjXv2//ZOrNuHgimPGasiLmXqThfIV7cPvzrib+/NrOwssEKkGUhIyN7/IR5/4VHm9u7+LbtNGDY mCmjBwS4++TkVZ8Ab8DCztLi/OM/nCIn3tl9I+LArW6vDLF00tMX59Uwx0yHIGsMIdBgMAQEb739 Dpe5SqXauXPvrJnTDFYczZgioCcEQA3wGMPs+JitSf8fLrIzMQn41qKMv/ddOH6p0KnH5JfHtbMV wvuaDZAcis6dv7h+/e83b0Z7+HTt/FTrs2dP79mz18PDw9LTx9naMj0tdf363+QK9dHjJ9KTk+cM 7pSTc//qtWs3r12Nioq4eObsjUSlW9iAmfPHeFjwiYoMIcVZm3E9s/BcZEz2vRuXI89fi75/6WZ8 bEKio719sYunrb2NJCvnpZfecLAW8LTSqEuXLl44f+nynWzGtf2A4SP7BOua5SIfp5yknORLkTnS nJhbEUePR4stg5996Zm29iZ4Kug//PMPK4PgGxms8ECDYRCoQtYFhYWnT4dPnzrZMGXRXCkC+kMA 1IDpTzHNHlgbkzfpObB8JhCoAkJVu/Ynm1j4vfP2FGcBr+I9VMNoCjZu/PfatVuOzu5FEvu+vTuJ S3KuXL4iLinx7NIjwNVZVlJy8tSpmJj4vPzC8aP6rfvmpeiIU2fCL0TeiI6Pjb2Xoer09HPTn38m 2KJyvI8vFHj1CM6Mvn7t2JGrMYkxsSmuncY4+LQtybhXWFAgDWrvGeDtLFeevnivsydPmpd0/GxE 5KVLV5MUHQaPXPjyWPtqCoqpl6cVT1h07d8zt+5du6By79Jj3JxpHZ3B1HqeEhBLPWBFnp072emc 8DUjDQZDgAc/ay7zixcj9u0/+ON3XxmsOJoxRUB/CEBq+Phjdu63yZOZHj0MMiMoBgpBRgw+Hi83 qrnaa8oCaxGzf+STnyBMiCHYQwbhBhvxU8CHbwa8MyrbjoT494CNq0UmXDI2H3asks0W+bJ7jGeq 1BiHLBvQLM/tIVmxI55wAalI9rBU9e4OLNW4Zg2by/DhTK9e9c6OZvBQBKpo1pciorp17UzRoggY BwLgrunT2fdufMeIdbwMEVgiFkKJflA5ACkLywKYGiWTn2xK1Ir1ceaRv5KDLKOzgnZlYLm3hgpX ScaK4BXZslRdlh75sQ8HndwekhXrWKKT7GGp6ocalKgjRxjMKYgPzTGNOA2GRKCSrOPi4lOSU/r3 62PI4mjeFAG9IoD5ObG4Isbf/viD/UamiQRDzPrfRJqmWw0MGOzZw07hBJsaH/0byo2yCba8capU TtalpdLt23cPGjTA28uzcSpCS6UI1A0BCCBPP83cucOaeFeuGM6Zr261a55nQf/B9y8HDrBr6WJm 1JkzGQeH5tnSptQqlqwxo9ihw0ehb40dPbwp1Y3WhSJQCwTgOQe+fvddJjqa+fFH5vhxdsiRBoMi kJjIfP89g3XUOndm3n6bulcbFGwu88pZ9yaMH0NnSW0Y0Gkp+kcAX59jVcBjx5jISMbVlXnmGXYS OBr0jkB6OrskMaYR9/NjlySG+lHd+1zvRdIMyxEQBAYGm5mZjhg2mDI1vSiMGAEM4mGk0dmZnU4I MyzfusXExuJLFaZVK7oCt366Ff55EJrw4pKTwy4NA5dqjCg22pLE+mmTceXC27Pv4MD+fapN7mVc baC1pQhUQQBLMm7bxsClzN+fXZQAHzpCV8V8T7pz2lHIaokAlpHCww8fKMLlA28tWAOhXz9m1CjG qvwr+VpmQ5PVHwG6BmP9MaQ5NEkErl9nX9hPn2a/bxw4kOnTh40QP40W4q1Rn24h7tnwYceSXdCm 791jnJzYFXkAY8W37/XJnp5bBwQoWdcBNHqKMSCAOfkwcwjsaywoA6cF2IagGxjaWFo3IMAYGtB4 dcR0K1i2/Nw51scGk9C2b89q03hNAU1Tg7rxuoWSdeNhT0tuGATgDgzDMCGBFVvB4BiKhNIKbcTT k7W13d2pgzDbDwAHHxZhS0tjn3BkUkNQs48PA2d2DCdSN+qGuVwfXgol68buAVp+gyGQnMw6YkPR Bn3DSMRoJIYfsSEiErFeDdhATw0lkojFWEdPAsdZrDCADx2xpheCZYMN2WG5Yagc2DC7aX4+S9ZZ Waz3NBRqCNNY+QVvIe3asQO2NDQNBChZN41+oLVoSATAUHjBx4gZFJL4ePY7muBgpm1bJiSE9XOA WkIYCqzNbfWoXrUVBMksIpmZmfFlITExsbi42M7Ork2bNr6+vj4+Pk5OTmQtc3YykIpQZcWvJ60M BGhuI+cCAbxq3L3L4oDXDjA1VkdD88HOwAGvHTQ0PQQoWTe9PqE1agAEsKYJ2cDUkGjxlQfZIALA ynZzYwkLCgkmaMaGn/UwMEtLS2NjY+PKAmHnhIQEExMTT0/PVq1apaWlIW5ra4t5Q7KysvATM0C5 urr6+fmBuL29vbFHHDyO6bPrCAwaCMkeTYPhjD0c0qHmY3VHiBuYKg8bFCG8UiB/SB/YdFZJr2OJ 9DQDIEDJ2gCg0iyNDgEoANig1WKDsxqRtrGpVOwen0TC1CV+3Njj02qoKCA7bFUJFFP0ZWRmpqWn p2dkYIdIdlZWqVQKnjU1MTEzNcVKBeb4rsHMDOzs2qqVhYXF1i1bYDWHhYW1DQ3Ny8vDQubFJSVY jxELPEIeUSgUcizjqFLhCMxtR0dHl1atcGIrFza4lm3lYMN2lkjYDbIG2BnGMmZZwoafEKChOJMN Tx3sIbagITiXbA2mvRjdhdGUKkzJuin1Bq1LU0AAYi5RbyFtI4I9uA8HiahdIW1rBYISbEJhialp iVZbotEUy+UF+fkF2dkFubkFeXnY8nNzSyUSyNB+/v6+AQE+MI9hLwcEuHJOhAzz4YcfgpdHDBvW r39/rvWFGRmp9++np6WlJien3L8PczslKUlSUmJuYQGWt7e3tynbbJ2c7FxcbEQiax7PSiq1Viis lEp2k8lEeN5Ipex7AyIQdsDIUOcJNeONgX522BSutCesAyXrJwSMJm95CMDlWFNaqklO1ty/r0lJ 0aSlqTIzYTgnZmUl5OUllJQkqNWxMlmmUmlpYhLg6Bjk6tra0zPI1zfIy8vP29sc3m/4lhI2OCxc 4mVBflpayiWSj9etU2k0Q3r2HIbpA2HF46kAcx5mMll8FnFEIJ3Dvi4sTMnMvJ+UlJiWlpSVlZib m1hYGA8zXKVyMDHxtrLysbHxtrf3atXKEw+Fdu2cQkLMIXS0aoXJWzHDKplkFZMBGWKhmJZ3UTRC iylZNwLotEjjQkBcWnovJiYuOjru7t1YbNHRifHxUDDcPTwgJ3v7+nq7uXk7OblbW9trtaYSiVAi MS0tNVEoTDQaISQUbGBnsDD2iCOCAAqGuKFWf3bzplStHuTqOhLCMegUegskY3A6IXdIFiB3cDfW ohUK1Vi9xspKaWnJ7q2tVdbWalvbYgxX5udnpKSkp6bCGIf+kgpTPD0d01k5QfsODGQlbyjfZQp4 YEAAfE6MC39aW4IAJWt6JVAEKhGAn0ZKSgq4LrUiwG0DerElnOqsrCywWVpiQxxaBIIDNjs7e2tr RxwkJjNYGHSMDfoDJ3mDbRHHXxGB+QxSxp5hFHL51zt25BcV9Q0NHY/PuPFXwtRIAHEZe/xEBMeJ 3IwNrI2CQOVkPLBs5BOqdmFReUCksJD9VVJUBNdAuVQK70A0QSqVYqgTcYxnoubu7u6Qvt3c3DCY iYAIt9ovvSCaJgKUrJtmv9BaGRwBeNTBZw6khj0JiIPmSITEEcBxmDmHONXBMiXuGRjc00v9sI75 d99/n5WZ2atfv0kjR+olT91MSkpK8OAps7PZQB5A8O+GWze0b7QLe5FIBFvbpiwgjoMIiJA49tUW d9R7JWmGtUSAknUtgaLJjBgBsiIiCbCdsYeXRUZGxv3794kjXVJSEvzqcnNz4bYRVBECywI0BJii Bmo8qrFq1ars7OzevXtPxMwbDRVA3HAiRKu5gObD7gZf47EEn0IvLy88lrBYOyJ4MkHzYVeSZJcT Y9cTI3tK4g3VXeXlULJuYMBpcY2AAAxkkNG9e/ewh8szIsnJyTAnwUrgYmIsg6TATfg4hVs7sXIF RYNVubHIGk8suAPioaW7h8WNxwaQYZ0OKwJ+QkKBy6A/HFpYZxbW4xsBoOGgwYChGdeAACVrelk0 KwTAPrCXoTtzARY0LGvydo8AjiZv91AAQM1Qb7Enkbp/dVJXCEHWa9asASH26NFj6tSpdc1Gb+cB PV1diChC0FLA47C7oYBjD10IERyBfQ3Q8ISD/A3VG3uig8OXXG8VohnpIEDJml4OxooAzEMiK5Px NC4CHgG/EIpBwJAaOIW812NPIg5NY81AkPWvv/4KY79z586zZs1qsj0BgobYjcde2ec+bIDlDcwh hpDnH4ZXdSNEASciOBehA5j17F9K1vUEkJ7eEAjANIbRRwKRnkHBoAwiucKUxh7SMz7/g7oaEhIC rbl1WUAkoAlPiIpvFH/77bfo6OhOnTrNmTOnIaDUaxmQTQA7dH9d+Ru9gLcWInlDaCIBcRjd6B3Y 49CXQNwkIE6171r2CSXrWgJFkzUmAjk5OTA/uRATEwPLDqYcGAEqKhFSsYfVDCOaDIURIiCjYY1Z 9UeWbexk/eDILZ6jkEqI9o2HKCxxokehv/Dq4+zsTLRv0l9k/hN9udY02V7WV8UoWesLSZqPfhCA MgAzDbc6CbjP8QIOwiUqM3mnRoQozlycRBpedK5nm9FYWNZ3796FDDJ79ux65tZ0TgdlQ4aC5K0r SUE2IcKUrkiFnxjABInD+oavN1HAyd7oetPQ+FOyNjTCNP+HIoBbuqAi4N0ZUeLmDNOMC1BLcTND YuZeqIljGZi6GSALy/qvv/66fv06JnKaN29eM2jRo5uAriTCNz41QkAcEw3itQnvQFC9wc4IkEq4 UO2RjE4n0xM2e6BqbCAl65bZ7w3dauIrBm4iATQNjwLcqJwFTd6aQdkYrcLMzhCaOdEZr8wNXd2G Kg9QbNu27dy5c8HBwS+//HJDFdvkyoGHOxl7gAJORiCwx+XBeZuwjiawt8sCtG9wOpzfWd9KiF3Y oIMTvevBmbvRVnwISj4K1dME5Y0FHyXrxkK+ZZULM0rX0/nOnTuQNcHLUC3By9hDykQEJjMEDUDD fXyBSFMWnevZi5SsCYDQvsmaDCQQKZyMIRPJG+QNNSy57AvM3Lw8yNzlLt8eHr4uLn7Ozn6Ojm54 2cLUK+Rzf0w3iI/7yeQq+EAfc8ByH+gjgpRGaJ5Tsq7n7UZPr44AhAu4BxCTmVhJeO0l8+sTp2Yy qwZ5pSWfNXM+XmSFlJYTQNabNm06ffp0aGjoa6+91nIaXsuWYi4qsVIJ725xfr44Lk4SHy9OSipJ TCzKyiouKCgpLS1kmGKhsJjPL2YYmVbrZG7uYW3tKRK529q2c3EJwIUFsibzkpONzKUFQseV5urK TlBONjKFbNPW1ihZ1/KyoclqQABGECRmvK7CTIaCQebOJ+sKYugMgUwhBAEES1Vxw0dEfYYvB8UU 9uOlS5fg3IK3+2HDhlFAqiAASsXiCWQVBawMiZ9kCkNcUiUlWSUl2ZiWlmEyVaoshSJLLs/D/N1Y okGlMlWrsaZOj6AgTI/lCSKGlY1zMa8WWVMClI1VzRDHxzvcagxkZQbMRwgHfJA4uBv7eiwPZIiu /H/woNDxLIgihwAAAABJRU5ErkJggg== --_004_SI2P153MB04412944658A25DB25666079BB249SI2P153MB0441APCP_-- From nobody Fri Oct 14 07:54:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpdvY566Jz4fsdF for ; Fri, 14 Oct 2022 07:54:33 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020018.outbound.protection.outlook.com [52.101.128.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpdvX2XvNz3bbS for ; Fri, 14 Oct 2022 07:54:32 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C9H6SLgHgFxyz91X4WHKHuK5qkuZSfJlBReXzBwRo8Oyp0kb+BccT0hqK32gKlvNZwTdPZQsRqYrCRZNrfLeCnVIc4tPAi0P7dQ+7tZU1saqf6BqDwjfN2AEL1dqDKufw5YCTEhB65dYt/mz9GRzr9kc6Lxf7/GWofYv2eMmENQQi3dCa8dWB8msya4SmK815X0GfBmLmqmcYob7q7cF8CzyOVR1kPgwsAJrQwzYF9gcU9k5+hd8Polm8GD/uXkX1un9HpUH+XLmi9NpzUtictTt9bk7oS/GPSONarQ7IaeF9+nw1pAfJk957ulBxDhrvfOw8xDFq/uGUauH/9SH1A== 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=ga4NxPOIVJopfCWbsurraYP7Onwj+tfWT/oQ9I+Trys=; b=ZadnfDJKrcI18iCmnfkKtXSdCi6kJH7dSVAiVqxAG0m+8+BlPHnKHnqWWBb7aMPi2K4NtMOIUN0+GoU0CnOm3SDtH/RFmMDF6uT7gFUbgDipbOTBT7hxu5ueT1oEzNzMQlE3VtCxzPgasG1m7AKPnDLuFOmohVPs9JYXHq4br35QrE3Xf0O3eWlLTkapRNm8DsmeclrKud9EcIxCN+NwcZBe70Ea8VsW1YqyNXMcJ9W5q+6Xl1L3Pipsohgvk5grcdDksABZkvIGkSIUjXKI0pleQ002w6rjGHrQge0mlbRAGLhprT7tlRrUurmeXwl1pfHLyR6lctwkPLrzhkxo+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ga4NxPOIVJopfCWbsurraYP7Onwj+tfWT/oQ9I+Trys=; b=a+J028maK3JOPjVpkst/7QHwGTLB4ReB5rrFVQCSUw4HOR62J9wVfX6mxz1TuqGR5hGfX0JyzDdnugsvlWZNg7eq8Y5IwMuJfA0G0bkquTq+vI4ZbnBjrG43sdzga1r9skrx0ozlaN+c3ofiYIHY8WpxY5JX58pI392dj4/d95k= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SI2P153MB0746.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fe::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.6; Fri, 14 Oct 2022 07:54:22 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8%3]) with mapi id 15.20.5746.011; Fri, 14 Oct 2022 07:54:22 +0000 From: Souradeep Chakrabarti To: Warner Losh CC: "freebsd-hackers@freebsd.org" , Wei Hu Subject: RE: allocating IRQ mentioned in _CRS of ACPI Thread-Topic: allocating IRQ mentioned in _CRS of ACPI Thread-Index: AdjfoFUyyvAv3mtwTL+ltqDHxzFqEgAAb7xA Date: Fri, 14 Oct 2022 07:54:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=35bd4fc7-674a-4bac-abcc-32b8c2a111fc;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-10-14T07:40:41Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0746:EE_ x-ms-office365-filtering-correlation-id: 5dfbb503-31b3-4373-7104-08daadb94e68 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XgfeYSFu9Vn4yORfZzIIRIMx1nL20ka9JPFvnEFkakGgg8FG8fRKDWT75uxFttf8drwGPNVDdf/j8WmgQDM5jUF592mOosBLq2cZ27745fkvBGWrEFi3QUlUfjwI1gZx5PK+akIFgLyn/10rCoSN4II1mohbyzLsYDebcuXqFtvI8pZzHEj0l2P/LBY6bjwGeZsd5V3wXUWbW5i5a2nQYYGEmKweMdfGHlLwpCs1oBCzyUwg6807eabn9m4dn2p8rMa3as+Bd0g2ojQ5d54ci+mWs7jFqz3ggHGElLpZ1no9oQz2q6ICznEnCCJUpXRRfuXlJD8ZVZHMPAEoYW0t34+CeksClBQZO0sk+97HsVRPwNu+4naY2RCfyWZujX/vjTK1SDj+L7aE5x8z6Avmr5u4gY0OHwq1wJ/Fwrb5stPNyb0WhcBVFOGvmuXf1387IZMgeVAMeiEncBjI6s1Q3XiNxZ3z4bNDYls1s1+ubtiLD69giDj+w4cSothDDLF6kAKg9jfd2h40qRibxtjMS1sXeMkMlEXQ5RTiEgt+yRLnlmKcx6zR46PXY8rlxLQMZrB0B4Y9is36ArxdvmZNU2sov+5SS0zUKLt+8cG9te9nTmjBfuYdac1O3knnzU8bym5TieoaBBX7sU0JwjoiqnUI6OUOr4Atlbv79yZ+RnKpmLZIA6AvlD5ctQ01fLVV38CWn/J3xwP3b/6TzFQ33amuoSRUYnGlVYiuLDYXQUAHe8lBaRJ6p05FJ0F3QXyzvdbpN/Lxr8Fgx/sa+2lcrH+bOOc6enfBwSYnAOdPAIs7asGeH2VIENx33Nt8Lu2y x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(346002)(39860400002)(396003)(376002)(366004)(136003)(451199015)(2940100002)(478600001)(6506007)(53546011)(9686003)(7696005)(26005)(76116006)(8936002)(55016003)(2906002)(82950400001)(122000001)(38100700002)(82960400001)(52536014)(5660300002)(64756008)(66446008)(66556008)(66946007)(10290500003)(38070700005)(4326008)(66476007)(41300700001)(8676002)(8990500004)(4744005)(316002)(83380400001)(71200400001)(107886003)(86362001)(186003)(6916009)(54906003)(33656002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LWkaJqZYJZv2nzqXIH8gzh5Vfhek9yYt49GqmfS+vYMnCoHDUphf6AIdUPf4?= =?us-ascii?Q?Rg6khCTETBLGrMdUbsoSXGWs/7aXhLe1P98MjXEGhzcLrs9SQa837quP/EMb?= =?us-ascii?Q?qIQI6uIL6iz9wutVB+R/+8KGWSybbSqnECimdDnIljEDA/KkOEYV3jHed1mU?= =?us-ascii?Q?wQirsjLa5eD4F/4EPdtLjzEhsGZsFQTvjuOIsNx6PHhYaaXisXxkiKx8ukPq?= =?us-ascii?Q?CnAKTZYtqoSJ4WmpKM2dpQOm5/idEsWxhVyvT7ghCESkL9b35z+jYMQRUIMn?= =?us-ascii?Q?KDGqVSM6hi9BjM4pjDdKxl+/dkq7azfuINR/BP6XdgVBEb8yBeQWFBGZtjjZ?= =?us-ascii?Q?MJtmeQDvIJ/knhXUrg0Rha91dhuNOkrvZEBnnUDO3eNwevYcwPkWXOW+yLf/?= =?us-ascii?Q?7lA+2k3nzfLsrm/P9z6AgBCnPQt2CNiFWiDBoVlJgLrsT1lpb5Lo7xmla9ZR?= =?us-ascii?Q?Vw+nmvDaFVHHoyVx3W8pTk4ulk72LsKzz+ilpEgVq+y3P15nYGBaYABDA5XC?= =?us-ascii?Q?XurgaaUZI0d8M+/+N/ghXKnuX4zqtKjJEn7iFclVwHHEwrV9/F1e+5VxpAaK?= =?us-ascii?Q?7q+WJW03cXKatUsE4b53oHHheaFh5kyboJobCOQnzRnlSOzgHfqrifb0EAOw?= =?us-ascii?Q?lDsk0BA+j82vo3Cks1fZZkgu9tb8jK6lGZCJZAS5M+nVI2cRLTDTqBVWQqJj?= =?us-ascii?Q?Zi4lNNeJeVQtwjXjiaziNaWwgpa3Z/5XMvdZxbpmszdLf7KB7eT4yzn4yx6/?= =?us-ascii?Q?oTWJTHu8MDXNPFFAo9zoklQAPcPkhcTJuH0Rtg655RQ6PVkW9zBYclsfCgLc?= =?us-ascii?Q?0n6liyWsOjszUpRVZ+Fve9JHCGqZh8D8iLtA1OB+Wm/zhlITgQbgMP1s7+zR?= =?us-ascii?Q?5vdjEjQvGgRAQ27Jqoa1UqCGcDgz6r4LbjpqVCnzhgoQattSjc0tzJozF5zp?= =?us-ascii?Q?OdQ4hYqxUEqA2QtSemjQKlNQLzKxfl7/zd02et3ppDxY1eSe+jZki9G/edSR?= =?us-ascii?Q?04sH1vEPh3pxVX84IoXZLpV+MPoB/eOedGKUAIJfxJy6EhyayRzJgF97+M81?= =?us-ascii?Q?0AVhfeL4H6EcSeIAYXzOM+hIQ7yFdgsBY19t4UmP0hozyPVFTKkNsyRnyh7O?= =?us-ascii?Q?wBx8C9TOb9UCto2Y5kEcz7zJUIJqp5TDrB45K2l062pFKah+/A37rN7+OXtH?= =?us-ascii?Q?vhI0OxKjcgfsRZ4LqI7rrvidL31ePrizaJp2OYuH7AQ1SpZ/KDp2fyMpAWlf?= =?us-ascii?Q?tAZBr1nT1BLBnthhLmFwurLP1gHgK069VzHnME4rPfBwkXoqr/pK4+wwzF5F?= =?us-ascii?Q?KRrbKTPX79c5n7cUfwJWH48OC5trG8m76msKHqZGw4u7AzjHtNXhC8Sl1jvB?= =?us-ascii?Q?uWLmmIcnuZGVnMIaMquynqtUjREmZmaAOOQv+eu20afmmSOA9nUJHEmyHAaV?= =?us-ascii?Q?Quw4EXgo+jPVtoPyH4lH/daga9HJNsoFy07LjVF+dzvZmquGhEqwzgnDwufH?= =?us-ascii?Q?eMUEV0Vp9LkUL2Mk85ATT+N0+pDiQ366S9ZeIR5s+EkSX8t6RjMOfD3WTw?= =?us-ascii?Q?=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5dfbb503-31b3-4373-7104-08daadb94e68 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2022 07:54:22.2055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 29jgonUNq6ff4bIwSZ5I+UzssLSKNQ4ZZMO06jsXn5/fp+pBZwtsd1uznCa6qfWhm7ytfmh8B+vSeorHlrCLgzweO2/Qo1qEVknk35PSgn8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0746 X-Rspamd-Queue-Id: 4MpdvX2XvNz3bbS X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=a+J028ma; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.18 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-10.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.18:from]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Last mail was having incorrect FreeBSD hacker alias. Replacing that with co= rrect one here. > -----Original Message----- > From: Souradeep Chakrabarti > Sent: Friday, October 14, 2022 1:19 PM > To: Warner Losh > Cc: hacker@freebsd.org; Wei Hu > Subject: allocating IRQ mentioned in _CRS of ACPI >=20 > Hi, > I would like to allocate IRQ to a device, mentioned in the _CRS of that d= evice in > ACPI table. > I have tried with bus_alloc_resource_any(), but it is failing as the pare= nt of that > device is not owning the IRQ. >=20 > Current ACPI topo for the device : > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for MMIO in _CRS)- > >VMBUS( it has SYS_RES_IRQ in it's _CRS). >=20 > How can I get here both SYS_RES_IRQ and SYS_RES_MEM allocated to VMBUS? >=20 > Thanks & Regards, > Souradeep From nobody Fri Oct 14 11:24:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MpkYK6RSCz4fFGg for ; Fri, 14 Oct 2022 11:24:05 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MpkYJ656Pz3sWB for ; Fri, 14 Oct 2022 11:24:04 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qt1-x835.google.com with SMTP id z8so3428150qtv.5 for ; Fri, 14 Oct 2022 04:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount.org; s=google; h=to:in-reply-to:references:message-id:date:subject:mime-version:from :content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=fuShmTObryoGMHfQN5lvWBg4cKQgv9V6aQixQz9lkfI=; b=lhRfyQ0/a/pILlGqm+daStyBzmGmd13x1/8/LrH7ur5JfDVKsAEX8z4pUzOU7kZxRe nfUWguiyJ3FUxYrVDUOCuK5gGBZ36G6R2/NrWFsrTvi9uoQKszSB5ou4PzPoUIISExev zKYm8h4OOaiwZVv8qxCDyFRtKfMtqCMMtLP037URFLLx32Sp/ubiwBHOqKZLhwwFUFzF HFA7DuZfLIG1TuAKS24TIe8/0VRxm7H4j44nRac/hbO5OYW1j1sVdHkhXTWE9vLzNxw5 DeIc3omnSMVeWuD/gQCIIRrRunfy7FVoSYXfpj8KC3dXtj7f4KoDjeiYOzfNVO1ZOfJz PgXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:references:message-id:date:subject:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=fuShmTObryoGMHfQN5lvWBg4cKQgv9V6aQixQz9lkfI=; b=mb8x8iQgsHAIRZ+BVnwKspS2P0Np+gmIDbRPRJsBtHMkMopeF9h4uthoKitNY8bKRF XuiX2TSS+kxhW9Qd1ZguaeSki6qNK7bBt8yLwggT5p14qkcRDXMrjvE9qiFXMKcaA3oP 3LYcJ/zMhEjj+p2UhHOckqu02XriKKt2oZ5YPZ8rRLG4xldAeSyciCblsoFBgN41+UaA ZA8dUl8dAEqox5ajQ8uWwYxczsW5sd8zKOTSEsjgzNQj4c7FvUP+tWANoB/+ySyvLfvR gX1HvVM/U3uTfAUOqK6N7VRYWHOqAcYY2e3a32ZtXaTqEZqn0G440EXcyXARiuOEbzc1 i/vg== X-Gm-Message-State: ACrzQf3HYotmGgPwdhwbt6vBH3t9K1zhRuMabnzBH24MA9pZutkBEGah +V5pQUuNwoEeT1MntTJqg673PibNVidmVPPp X-Google-Smtp-Source: AMsMyM7L85QA8AsNQtUw4L5+brLbjv5Wa3o9Pn28yQTb6evXfEZaejzfffvtuW0plDcNYQg40q7h1A== X-Received: by 2002:ac8:5b10:0:b0:39c:d63a:d88 with SMTP id m16-20020ac85b10000000b0039cd63a0d88mr3560037qtw.682.1665746642031; Fri, 14 Oct 2022 04:24:02 -0700 (PDT) Received: from smtpclient.apple (pool-68-161-195-218.nycmny.fios.verizon.net. [68.161.195.218]) by smtp.gmail.com with ESMTPSA id t26-20020a37ea1a000000b006b5cc25535fsm2159967qkj.99.2022.10.14.04.24.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 04:24:01 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C7629555-65B0-4DCE-906B-F530D6D37931 Content-Transfer-Encoding: 7bit From: Mark Saad List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: is this FreeBSD problem or HP switch Date: Fri, 14 Oct 2022 07:24:00 -0400 Message-Id: References: In-Reply-To: To: freebsd-hackers@freebsd.org X-Mailer: iPhone Mail (19G82) X-Rspamd-Queue-Id: 4MpkYJ656Pz3sWB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount.org header.s=google header.b="lhRfyQ0/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of nonesuch@longcount.org designates 2607:f8b0:4864:20::835 as permitted sender) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[longcount.org:s=google]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DKIM_TRACE(0.00)[longcount.org:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::835:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[longcount.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-C7629555-65B0-4DCE-906B-F530D6D37931 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Oct 13, 2022, at 10:11 PM, Zhenlei Huang wrote: >=20 > =EF=BB=BFSorry for missing CC >=20 >> Begin forwarded message: >>=20 >> From: Zhenlei Huang >> Subject: Re: is this FreeBSD problem or HP switch >> Date: October 14, 2022 at 10:08:13 AM GMT+8 >> To: Jason Bacon >>=20 >>=20 >>=20 >>> On Oct 14, 2022, at 8:11 AM, Jason Bacon wrote: >>>=20 >>>> On 10/13/22 17:48, Wojciech Puchar wrote: >>>> i have HP-2530-24G switch in home and 3 VLANs. >>>> there was no traffic on 2 of them, one vlan have full bandwitch traffic= from computer A to computer B - at 1000Mbit/s >>>> At this time ping from computer C to computer A (computer C have 100Mbi= t/s card) was random between 1 and 1000ms. >>>> Just limiting artifically speed to 950Mbit/s solved the problem. >>>> Is this because switch behaves that way or can it be a FreeBSD problem (= all computers runs FreeBSD) >>>=20 >>> I saw an issue some years ago where one of my FreeBSD servers was overwh= elming a Cisco switch while pushing files out to HTCondor nodes, causing it t= o drop packets. Our networks guru confirmed the problem by monitoring the s= witch. Since no handshaking was possible, I worked around it by throttling t= he interface on the FreeBSD box, using ipfw if I recall correctly. >>>=20 >>> --=20 >>> Life is a game. Play hard. Play fair. Have fun. >>>=20 >>>=20 >>=20 >>=20 >> Modern x86 hardware can easily saturate Gigabit network. Probably it is n= ot the issue of the box, or the OS ( FreeBSD in the context ). >> There's an old post about ICMP packet drops on the HPE community, https:/= /community.hpe.com/t5/aruba-provision-based/hp-procuvre-2530-icmp-packet-los= t/td-p/6347333 . Although I can not conclude it is the problem of switch, bu= t you can try connection the two FreeBSD box directly with crossover etherne= t cable and repeat the test. >>=20 >> Also the statistics reported by switch / OS are extremely useful in produ= ction ( when excluding some suspicious objects is not an option ). >>=20 >> Best regards, >> Zhenlei One other thing I stopped using hp switches in favor of fiber store=E2=80=99= s fs.com white box switches a few years ago . They are inexpensive and dece= nt enough , and Cisco like .=20 --- Mark Saad | nonesuch@longcount.org >=20 --Apple-Mail-C7629555-65B0-4DCE-906B-F530D6D37931 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Oct 13, 2022, at 10:11 PM, Zhenlei Huang <zlei.huang@gmail.com&= gt; wrote:

=EF=BB=BFSorry for missing CC

Begin forwarded message:
<= br class=3D"Apple-interchange-newline">
From: Zhenlei Huang <zlei.huang@gmail.com>
Su= bject: Re: is this FreeBSD p= roblem or HP switch
<= span style=3D"font-family: -webkit-system-font, Helvetica Neue, Helvetica, s= ans-serif; color:rgba(0, 0, 0, 1.0);" class=3D"">Date: October 14, 2022 at 10:08:13 AM GMT+8
To: Jason Bac= on <bacon4000@gmail.com= >



On Oct 14, 2022, at 8= :11 AM, Jason Bacon <ba= con4000@gmail.com> wrote:

On 10/13/22 17:48, Wojciech Puchar wrote:<= br class=3D"">
i have HP-2530-24G switch= in home and 3 VLANs.
there was no traffic on 2 of them, one v= lan have full bandwitch traffic from computer A to computer B - at 1000Mbit/= s
At this time ping from computer C to computer A (computer C h= ave 100Mbit/s card) was random between 1 and 1000ms.
Just limi= ting artifically speed to 950Mbit/s solved the problem.
Is thi= s because switch behaves that way or can it be a FreeBSD problem (all comput= ers runs FreeBSD)

I saw an issue s= ome years ago where one of my FreeBSD servers was overwhelming a Cisco switc= h while pushing files out to HTCondor nodes, causing it to drop packets. &nb= sp;Our networks guru confirmed the problem by monitoring the switch.  S= ince no handshaking was possible, I worked around it by throttling the inter= face on the FreeBSD box, using ipfw if I recall correctly.
--
Life is a game.  Play hard.  Play fa= ir.  Have fun.


=

Mode= rn x86 hardware can easily saturate Gigabit network. Probably it is not the i= ssue of the box, or the OS ( FreeBSD in the context ).
= There's an old post about ICMP packet drops on the HPE community, https://community.hpe.com/t5/aruba-p= rovision-based/hp-procuvre-2530-icmp-packet-lost/td-p/6347333 . Alt= hough I can not conclude it is the problem of switch, but you can try connec= tion the two FreeBSD box directly with crossover ethernet cable and repeat t= he test.

Also the s= tatistics reported by switch / OS are extremely useful in production ( when e= xcluding some suspicious objects is not an option ).
Best regards,
Zhenle= i

One other thing I stopped using hp switches in favor of fiber store=E2=80=99= s fs.com white box switches a few years ago .  They are inexpensive and= decent enough , and Cisco like . 


-= --
Mark Saad | nonesuch@longcount.org

= --Apple-Mail-C7629555-65B0-4DCE-906B-F530D6D37931-- From nobody Fri Oct 14 13:59:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mpp1R23qMz4fWpC for ; Fri, 14 Oct 2022 14:00:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mpp1P6vZBz41Bp for ; Fri, 14 Oct 2022 14:00:09 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 29EDxwCx071506; Fri, 14 Oct 2022 06:59:58 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 29EDxumV071505; Fri, 14 Oct 2022 06:59:56 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202210141359.29EDxumV071505@gndrsh.dnsmgr.net> Subject: Re: is this FreeBSD problem or HP switch In-Reply-To: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> To: Wojciech Puchar Date: Fri, 14 Oct 2022 06:59:56 -0700 (PDT) CC: freebsd-hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4Mpp1P6vZBz41Bp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[dnsmgr.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > i have HP-2530-24G switch in home and 3 VLANs. > there was no traffic on 2 of them, one vlan have full bandwitch traffic > from computer A to computer B - at 1000Mbit/s > At this time ping from computer C to computer A (computer C have 100Mbit/s > card) was random between 1 and 1000ms. > > Just limiting artifically speed to 950Mbit/s solved the problem. > > Is this because switch behaves that way or can it be a FreeBSD problem > (all computers runs FreeBSD) If infact your traffic from A to B is at the line rate of the interface from the switch to B (A gigabit ethernet port) you are creating a situation known as head of line blocking. With a store and forward switch your packets from A to C are going to attempt to "tail insert" in the output buffer of the port connected to B, depending on how full that buffer is your going to see random ping times and/or drops. This is not a FreeBSD problem, different switches may behave differently, mostly dependent on the size of output buffers. Is the traffic from A to B something that has some type of congestion algorithm? If it is TCP can you turn on ECN, and enable ECN in the switch? -- Rod Grimes rgrimes@freebsd.org From nobody Sun Oct 16 08:49:43 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mqv2W1Vvzz4fkTQ for ; Sun, 16 Oct 2022 08:49:55 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mqv2T40ztz45TN for ; Sun, 16 Oct 2022 08:49:53 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 29G8nimm064563 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Oct 2022 10:49:45 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1665910185; bh=FCBsDBkzV7jC/u1q2jeJa1W1Jt/QVLNSQ4Kr12eKFgw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dOuRag1n6nbv9OwHT/cvZ+1mSHvUeFftfNvmRD7r2lKh8trEqfQpRbFYQxdg/p/j2 YpxSDoX+t6b+EdZoN4eW73Sx3L5sEcXiqhm3SDQyA3p5L6LIe21YTiPvahLApJkB7N reiJaR0G8grXpijiyFh0E1qwZakRF/+BAIKrRAeM= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 29G8nioB025381; Sun, 16 Oct 2022 10:49:44 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 29G8nhe8025378; Sun, 16 Oct 2022 10:49:43 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 16 Oct 2022 10:49:43 +0200 (CEST) From: Wojciech Puchar To: Jason Bacon cc: freebsd-hackers@freebsd.org Subject: Re: is this FreeBSD problem or HP switch In-Reply-To: Message-ID: References: <586238fe-a9f-94b5-65b6-bc505551e9fb@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Mqv2T40ztz45TN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=dOuRag1n; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; HAS_XAW(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; DMARC_NA(0.00)[puchar.net]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> > > I saw an issue some years ago where one of my FreeBSD servers was > overwhelming a Cisco switch while pushing files out to HTCondor nodes, > causing it to drop packets. Our networks guru confirmed the problem by > monitoring the switch. Since no handshaking was possible, I worked around it > by throttling the interface on the FreeBSD box, using ipfw if I recall > correctly. > There is zero packet loss, just completely variable delays that make normal work hard. up to 1000ms From nobody Sun Oct 16 08:50:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mqv3P6KR4z4fkh0 for ; Sun, 16 Oct 2022 08:50:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mqv3P0Xzlz46Hj for ; Sun, 16 Oct 2022 08:50:40 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 29G8odoa064771 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 16 Oct 2022 10:50:39 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1665910239; bh=npL5L75JQMdPsp3JBqxIYJD81Qk+YogfA52Ke3iFxtA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uA0Dnqe3NYHRjzIPWuEeNdn09VHXCRddKIXdKqJpRdMAzkjC6X6i8I4sg852eg7W3 ANF7ozPHjrfVSThtsQTHkRPcEq+bE2qE6s8EZm/P9Dvkd41M9apdkxCTQn3qW9/DjY /dG/uYT4CNep7jMosqVOSqwbGP9jKBO4VyXdIhiw= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 29G8ocka025398; Sun, 16 Oct 2022 10:50:38 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 29G8ockE025395; Sun, 16 Oct 2022 10:50:38 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 16 Oct 2022 10:50:38 +0200 (CEST) From: Wojciech Puchar To: "Rodney W. Grimes" cc: freebsd-hackers@FreeBSD.org Subject: Re: is this FreeBSD problem or HP switch In-Reply-To: <202210141359.29EDxumV071505@gndrsh.dnsmgr.net> Message-ID: <45787d6b-6d1-a7ed-aff5-bebbc3d3d7fd@puchar.net> References: <202210141359.29EDxumV071505@gndrsh.dnsmgr.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Mqv3P0Xzlz46Hj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=uA0Dnqe3; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.42 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.92)[-0.919]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > going to see random ping times and/or drops. > > This is not a FreeBSD problem, different switches may behave differently, > mostly dependent on the size of output buffers. Thank you. this is what i thought it is, because just limiting (by upfw) traffic to even 98% of maximum solves the problem > > Is the traffic from A to B something that has some type of congestion > algorithm? If it is TCP can you turn on ECN, and enable ECN in the > switch? > > > -- > Rod Grimes rgrimes@freebsd.org > > From nobody Sun Oct 16 13:36:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr1Pf4TsYz4fFCZ for ; Sun, 16 Oct 2022 13:36:54 +0000 (UTC) (envelope-from yaroslaw.mashko@gmail.com) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr1Pd5lLKz3MVm for ; Sun, 16 Oct 2022 13:36:53 +0000 (UTC) (envelope-from yaroslaw.mashko@gmail.com) Received: by mail-vs1-xe2b.google.com with SMTP id d187so9175707vsd.6 for ; Sun, 16 Oct 2022 06:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=7abSjix+Gzz79mvI4F/ZfylecfXmrw3RgN626aoGI6I=; b=IOvuKtGAZflpyD+GYAKHuv32xrozJLgM7uDeVPqOLp4aeXpBUeS683WyL3X6tFpL/1 /hqgJ6mFKxDlToVmOh9wJwiDyFkoHuw4oKAhIvno6INb68ItW9WgD86ruzUp8WCBFPda ANKxWVuQ6rUGggSnDXJ0XSc2qbIT4kMBbsfbjPeqlIlX84RU6t1W/RGL828TLvoqf1jT 4ANdGzbdlyONPU7OZvaatUh8bMFVNPVRQU8uwRk2y/CFkM1lafQUCnYRQN+SIUIYxSi/ mQW+hvL+XrinQEOEdnwrnxdr9qEN2ACE6p8RWjX279m1MMRf9Ha1tqtEh8k9mzM0tkoG Vxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=7abSjix+Gzz79mvI4F/ZfylecfXmrw3RgN626aoGI6I=; b=TVKSo/DfX9/7eWxLGibRf9c5LiMcjj+Nc0A7m1lnPU+PxQ0mRb3MGIVBWjgM6Wws9q TEKBDnaMkFv1AQeF5KUwD7LM7ubR8M4AL+h+jzoDZV7P6nyZdgOgCnR4qxMSE2XL4LwA anoyZkX+Nv2ZypAZCLWmUeR58qT6GHYWBkv4h0T/QQYoCR/sv2HSrExDDyW0GQT7QnhV bLa/jgw2bGPRj+24sxr4LTnWcJVxHiSuaoAaMBp/Hwh8TgqRP3DSijIrYrNMDSUbasjw SZLPhrASv5hNA4DGB9tELxwFQRPqDz5qph2j5GeauGxlhDQtM8xxRnMBDpVfl1mte5Sn yvfg== X-Gm-Message-State: ACrzQf1gbphXXbRrjSUyVw2TovZBdhz8OMXKeSRKcoRhVt5dUy3KNwtc JGWBycqAJVJfe2LEryIEv2iQ6ibAaOx3d2k/FDZWQA9Wa4c= X-Google-Smtp-Source: AMsMyM5lZHdS83qhg0CmjtdLK8vermX8eMIhoA71oaKPwsy5o1DH7e5mgsjCnMHHi5r39yDHeUy8mWCxGk5AkantK6o= X-Received: by 2002:a05:6102:7c9:b0:3a7:6261:935 with SMTP id y9-20020a05610207c900b003a762610935mr2577810vsg.73.1665927412953; Sun, 16 Oct 2022 06:36:52 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?0K/RgNC+0YHQu9Cw0LIg0JzQsNGI0LrQvg==?= Date: Sun, 16 Oct 2022 16:36:41 +0300 Message-ID: Subject: I want some clarification on kqueue, EV_CLEAR flag To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000abb49a05eb26f393" X-Rspamd-Queue-Id: 4Mr1Pd5lLKz3MVm X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=IOvuKtGA; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaroslaw.mashko@gmail.com designates 2607:f8b0:4864:20::e2b as permitted sender) smtp.mailfrom=yaroslaw.mashko@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2b:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000abb49a05eb26f393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I learn how to manage events with a kqueue. I did some research and have a confusion with EV_CLEAR and EV_DISPATCH flags. So this message contains two questions. 1. I see that EV_DISPATCH flag stays with event no matter what steps do I take. The EV_ADD | EV_ENABLE leaves the EV_DISPATCH flag in. There seem that the only way to switch off EV_DISPATCH is to delete event completely. Is it the case? 2. I was confused after a look at the man pages for kqueue. EV_CLEAR section tells that the state gets reset. My thought were that EV_DISPATCH gets switched off. After that, I did read the /src/sys/kern/kern_event.c source file. The only state that I had found changed is data plus fflags fields. The was a confusing bit of manual. --=20 =D0=AF=D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0=B2 =D0=9C=D0=B0=D1=88=D0=BA=D0=BE +380 50 56 75 347 <+380+50+56+75+347> --000000000000abb49a05eb26f393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I learn how to manage= events with a kqueue. I did some research and have a confusion with EV_CLE= AR and EV_DISPATCH flags.

So this message contains= two questions.

1. I see that EV_DISPATCH flag sta= ys with event no matter what steps do I take. The EV_ADD | EV_ENABLE leaves= the EV_DISPATCH flag in.
There seem that the only way to switch = off EV_DISPATCH is to delete event completely. Is it the case?
2. I was confused after a look at the man pages for kqueue. EV= _CLEAR section tells that the state gets reset. My thought were that EV_DIS= PATCH gets switched off. After that, I did read the /src/sys/kern/kern_even= t.c source file. The only state that I had found changed is data plus fflag= s fields. The was a confusing bit of manual.

--
<= div dir=3D"ltr">
=D0=AF= =D1=80=D0=BE=D1=81=D0=BB=D0=B0=D0=B2 =D0=9C=D0=B0=D1=88=D0=BA=D0=BE

--000000000000abb49a05eb26f393-- From nobody Sun Oct 16 15:08:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr3RR5x7Xz4fQPf for ; Sun, 16 Oct 2022 15:08:35 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr3RR1bLxz3VDL for ; Sun, 16 Oct 2022 15:08:35 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wm1-x335.google.com with SMTP id y10so6865998wma.0 for ; Sun, 16 Oct 2022 08:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=JwBfmb0/ZrNi0xcX3o5A2tTBEGJBzjL6+rGeICu4pTg=; b=Oz3HhpQjfpSloM3oTkuhB6J229cKw01brM9qMnNFKIy5sH4iTySijBp8oDWg7Vck0a /Dad7rpSFSu4UHPB/2lVBb4yE7GOf2aDv6CxpNNtS5xMOXmxgI8Z9tv76JL+w/O6sDVX zfB1O7a9fyaLNlPhg2wPc3seHkNm3yJaXxdnZu+TtcpfudYGYe5P8VqJWOKTL9EN9cbk AoBJzoaDo8oqH1agOVp3CpNXoiAuA/nwx2/mXUJHjXblVedhgautO17ofFp0bNec9MPO O1NKp19/tybpPr81m6dpkKz8Z583yjP2jfwBtBoKoXg+b1hNDycf8BdDBDaVUSYgQrkD MhLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=JwBfmb0/ZrNi0xcX3o5A2tTBEGJBzjL6+rGeICu4pTg=; b=5dIyUZG91wtVIUQeGaaYcttYuMmfJLFDggyf5QYadgxA0iJ1EsiKd3z0sGcwchqeYU PXY7MghsEl0WOxKHrX7rbOZEVnBNp6MiaQeinCFDJs1Qt+fbR9nrVRqTh4+XkjnQBKy7 /3Gu9aLMngqv8460I2oLzo1UaG+juY6FtAINlBqeZqPitwDyr9zUxE0mFfTloIS+uifq lUSr0LBX2cSAL3LrgTHZIL6wrdZOrdJnkKeWal3qkehriz5sjz7p2ytrUHqQP+DNp+Lm nC0rt5caSDX9JERkVXGFh9zTswwLPlQ9farQGXxFwFrvn1yIl8NExl22bbnL3PDcaDVv JW0A== X-Gm-Message-State: ACrzQf3pT/W/WCWtRa7Uxvz0hqHwQ1EPVgojRUdWCcpFMXQ6cmnQXuL3 wmjkMZxEk2/DLmfB1O/7QMxJBX7h2dw= X-Google-Smtp-Source: AMsMyM6Y4ljGvS9pHbQ6MpX+HBrwiei7KFRqg59t3xwDJm8vrQmnd4/W3En0NYry3r8A+vhKT6nsTQ== X-Received: by 2002:a05:600c:1e17:b0:3c6:bc31:1f3d with SMTP id ay23-20020a05600c1e1700b003c6bc311f3dmr16608524wmb.52.1665932912119; Sun, 16 Oct 2022 08:08:32 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-263-217.w2-7.abo.wanadoo.fr. [2.7.103.217]) by smtp.gmail.com with ESMTPSA id t9-20020a05600c198900b003b4fe03c881sm13227644wmq.48.2022.10.16.08.08.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Oct 2022 08:08:31 -0700 (PDT) Message-ID: Date: Sun, 16 Oct 2022 17:08:30 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 To: freebsd-hackers Content-Language: en-US From: Paul Floyd Subject: AMD64 14.0-CURRENT memory layout changes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mr3RR1bLxz3VDL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Oz3HhpQj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::335 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::335:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hi I just noticed that the memory layout has changed for elf binaries running on amd64 (my last attempt to setup an i386 VM failed so I can't confirm if that also changed, and I'm not yet concerned by other platforms). Here's a procstat -v for ksh93 on 13.1 on the host machine > paulf> procstat -v 1456 > PID START END PRT RES PRES REF SHD FLAG TP PATH > 1456 0x200000 0x273000 r-- 70 343 30 16 CN--- vn /usr/local/bin/ksh93 > 1456 0x273000 0x3d1000 r-x 257 343 30 16 CN--- vn /usr/local/bin/ksh93 > 1456 0x3d1000 0x3dd000 r-- 11 0 1 0 CN--- vn /usr/local/bin/ksh93 > 1456 0x3dd000 0x3de000 rw- 1 0 1 0 CN--- vn /usr/local/bin/ksh93 > 1456 0x3de000 0x3e4000 rw- 6 0 1 0 C---- vn /usr/local/bin/ksh93 > 1456 0x3e4000 0x3ec000 rw- 5 5 1 0 C---- df > 1456 0x8003de000 0x8003e4000 r-- 6 28 364 120 CN--- vn /libexec/ld-elf.so.1 > 1456 0x8003e4000 0x8003fb000 r-x 23 28 364 120 CN--- vn /libexec/ld-elf.so.1 > 1456 0x8003fb000 0x8003fc000 r-- 1 0 1 0 CN--- vn /libexec/ld-elf.so.1 > 1456 0x8003fc000 0x800411000 rw- 19 19 1 0 CN--- df > 1456 0x800420000 0x800432000 r-- 13 33 352 176 CN--- vn /lib/libm.so.5 > 1456 0x800432000 0x800459000 r-x 20 33 352 176 CN--- vn /lib/libm.so.5 > 1456 0x800459000 0x80045a000 rw- 1 0 1 0 CN--- vn /lib/libm.so.5 > 1456 0x80045a000 0x80045b000 rw- 1 0 1 0 CN--- vn /lib/libm.so.5 > 1456 0x80045b000 0x8004df000 r-- 132 380 528 284 CN--- vn /lib/libc.so.7 > 1456 0x8004df000 0x80062b000 r-x 234 380 528 284 CN--- vn /lib/libc.so.7 > 1456 0x80062b000 0x800633000 r-- 8 0 1 0 CN--- vn /lib/libc.so.7 > 1456 0x800633000 0x800634000 rw- 1 0 1 0 CN--- vn /lib/libc.so.7 > 1456 0x800634000 0x80063b000 rw- 7 0 1 0 C---- vn /lib/libc.so.7 > 1456 0x80063b000 0x8008f5000 rw- 84 84 1 0 C---- df > 1456 0x800a00000 0x801200000 rw- 13 13 1 0 CN--- df > 1456 0x7fffdffff000 0x7ffffffdf000 --- 0 0 0 0 ----- gd > 1456 0x7ffffffdf000 0x7ffffffff000 rw- 11 11 1 0 C--D- df > 1456 0x7ffffffff000 0x800000000000 r-x 1 1 125 0 ----- ph Here the stack starts at 0x7ffffffdf000 And the same on 14.0 running on a 4Gbyte VirtualBox VM > paulf@freebsd:~/valgrind $ procstat -v 62770 > PID START END PRT RES PRES REF SHD FLAG TP PATH > 62770 0x200000 0x273000 r-- 115 488 4 2 CN--- vn /usr/local/bin/ksh93 > 62770 0x273000 0x3c7000 r-x 340 488 4 2 CN--- vn /usr/local/bin/ksh93 > 62770 0x3c7000 0x3d4000 r-- 13 0 2 0 C---- vn /usr/local/bin/ksh93 > 62770 0x3d4000 0x3d5000 rw- 1 0 2 0 C---- vn /usr/local/bin/ksh93 > 62770 0x3d5000 0x3da000 rw- 5 0 1 0 C---- vn /usr/local/bin/ksh93 > 62770 0x3da000 0x3e2000 rw- 5 5 1 0 ----- sw > 62770 0x80075d000 0x82073d000 --- 0 0 0 0 ----- gd > 62770 0x82073d000 0x82075d000 rw- 14 14 1 0 ---D- sw > 62770 0x8209c8000 0x8209c9000 r-x 1 1 28 0 ----- ph > 62770 0x8217b0000 0x8217c2000 rw- 16 16 1 0 ----- sw > 62770 0x822186000 0x822210000 r-- 138 496 104 54 CN--- vn /lib/libc.so.7 > 62770 0x822210000 0x82235e000 r-x 334 496 104 54 CN--- vn /lib/libc.so.7 > 62770 0x82235e000 0x822367000 r-- 9 0 2 0 C---- vn /lib/libc.so.7 > 62770 0x822367000 0x822368000 rw- 1 0 2 0 C---- vn /lib/libc.so.7 > 62770 0x822368000 0x82236f000 rw- 7 0 1 0 C---- vn /lib/libc.so.7 > 62770 0x82236f000 0x82259e000 rw- 20 20 1 0 ----- sw > 62770 0x823434000 0x823447000 r-- 19 59 4 2 CN--- vn /lib/libm.so.5 > 62770 0x823447000 0x82346f000 r-x 40 59 4 2 CN--- vn /lib/libm.so.5 > 62770 0x82346f000 0x823470000 rw- 1 0 1 0 C---- vn /lib/libm.so.5 > 62770 0x823470000 0x823471000 rw- 1 0 1 0 C---- vn /lib/libm.so.5 > 62770 0x823e0e000 0x823e3e000 rw- 16 16 1 0 ----- sw > 62770 0x824600000 0x824800000 rw- 11 11 1 0 ----- sw > 62770 0x8251a1000 0x8253a1000 rw- 1 1 1 0 ----- sw > 62770 0x825e00000 0x826200000 rw- 3 3 1 0 ----- sw > 62770 0x826a49000 0x826a61000 rw- 8 8 1 0 ----- sw > 62770 0x826e5c000 0x826e74000 rw- 14 14 1 0 ----- sw > 62770 0x827d6e000 0x827d86000 rw- 9 9 1 0 ----- sw > 62770 0x8288ba000 0x8288d2000 rw- 5 5 1 0 ----- sw > 62770 0x8296db000 0x8296f3000 rw- 3 3 1 0 ----- sw > 62770 0xeeeecc15000 0xeeeecc1b000 r-- 6 29 71 21 CN--- vn /libexec/ld-elf.so.1 > 62770 0xeeeecc1b000 0xeeeecc32000 r-x 23 29 71 21 CN--- vn /libexec/ld-elf.so.1 > 62770 0xeeeecc32000 0xeeeecc33000 r-- 1 0 1 0 C---- vn /libexec/ld-elf.so.1 > 62770 0xeeeecc33000 0xeeeecc35000 rw- 2 2 1 0 ----- sw > 62770 0x7ffffffff000 0x800000000000 --- 0 0 0 0 ----- gd ldrt is now mapped up at 0xeeeecc15000 and the user stack looks like it starts at 0x82073d000. This is causing me problems with Valgrind, which creates the guest stack at 0x7ffffffdf000. I haven't yet done any debugging of the problem but this causes Fatal error 'Cannot allocate red zone for initial thread' at line 395 in file /usr/src/lib/libthr/thread/thr_init.c (errno = 22) for elf binaries linked with libthr.so Can anyone point me to more information on this change? Phabricator for instance. Are there any syscalls that control where rtld gets loaded and/or where the stack base is located? Also is there a sysctl to disable this changed mapping, as a temporary workaround? A+ Paul From nobody Sun Oct 16 15:23:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr3nB3mWYz4fRk0 for ; Sun, 16 Oct 2022 15:23:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr3n95d6Nz3XcS for ; Sun, 16 Oct 2022 15:23:57 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x729.google.com with SMTP id d13so5355583qko.5 for ; Sun, 16 Oct 2022 08:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=ThvMBI6sisUhEnISi/GUPTsglHmecS8elyQqROFjxU8=; b=oc+9Ie7si2gEEOqG7FJ7RiUK8Ql1y+okrGXwzMtoPlblrpO2xON8yWWzH6caxtWhaN 7c+bkOPz2ALYhOE6hHZg2i2kYpIgI1C3vOsi9WroUXv+Pt99JOYr0M9h3YZDqT+OvaDI 0H/Hqdv3bwNNNtd0O9GK08Z1D2C9bJ+fbYfujerBnysu+llz9TbNUXrugRxfwRmp55bv lji7dX18/JUymMLw3EsomtzGLE41nhGpSxa3us5bZPiDw1gIMXQ1udJby2U0SROgrptb aV5LAe9rzP0yxZSXwKTj9VkmTGH9rQFb3W9yjAdDGkvjJDc98r+EYCY6fIZn+JDweT8J U2VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ThvMBI6sisUhEnISi/GUPTsglHmecS8elyQqROFjxU8=; b=ymKrK2UmZsFza+Vwx1Qddnzwz22voFPqcKzrJwNBAGiDP0SwV9d65HKVoQgZ5aXskf SyCprGrbQin/bCHOEl2FvMn/weXb4nCg7EubyFtH2zV9i8fKXqiXJiF2UxzQ4YqxsIVM lHkd0PoyGuIuj4R0VTJXj2rdysDkIw3p5/dTEM84Ajz45FyYjx6foR8TNvT/og9HTTRl MEwLnrWqqPVEBe1Vf6bziN3wk/0YnEyvJRBFnDAcRUDjjpgLGSms+aDf219oMwFsGCEt AB0tiMgDOiX0+u/vI/VkXaU+POGLK1XwtIpuWsjX/8/hJWuZ454aO9zV7NoIP9njS6PX 0BOA== X-Gm-Message-State: ACrzQf3+9EMpgXMpsN4VyG5sDR4b7D5tSJLy9euJVpVxPOlNJeXjMV7p dSZ6p7OZMPAuwCzkYD6bZW/LQlfj3AI= X-Google-Smtp-Source: AMsMyM4dZfwlpbWvLunelSjEvU1aPhsi0ZzUnTdRTJsJzWjDMDN5wLb1RCvzWNJX4yv0oYFF5MLHiw== X-Received: by 2002:a05:620a:2995:b0:6ee:e3a0:9fb8 with SMTP id r21-20020a05620a299500b006eee3a09fb8mr1123265qkp.165.1665933836463; Sun, 16 Oct 2022 08:23:56 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id k6-20020a378806000000b006ea5a9984d1sm7101566qkd.94.2022.10.16.08.23.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Oct 2022 08:23:54 -0700 (PDT) Date: Sun, 16 Oct 2022 11:23:52 -0400 From: Mark Johnston To: Paul Floyd Cc: freebsd-hackers Subject: Re: AMD64 14.0-CURRENT memory layout changes Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Mr3n95d6Nz3XcS X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=oc+9Ie7s; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::729 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::729:from]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 16, 2022 at 05:08:30PM +0200, Paul Floyd wrote: > Hi > > I just noticed that the memory layout has changed for elf binaries > running on amd64 (my last attempt to setup an i386 VM failed so I can't > confirm if that also changed, and I'm not yet concerned by other platforms). > > Here's a procstat -v for ksh93 on 13.1 on the host machine > > > paulf> procstat -v 1456 > > PID START END PRT RES PRES REF SHD FLAG TP PATH > > 1456 0x200000 0x273000 r-- 70 343 30 16 CN--- vn /usr/local/bin/ksh93 > > 1456 0x273000 0x3d1000 r-x 257 343 30 16 CN--- vn /usr/local/bin/ksh93 > > 1456 0x3d1000 0x3dd000 r-- 11 0 1 0 CN--- vn /usr/local/bin/ksh93 > > 1456 0x3dd000 0x3de000 rw- 1 0 1 0 CN--- vn /usr/local/bin/ksh93 > > 1456 0x3de000 0x3e4000 rw- 6 0 1 0 C---- vn /usr/local/bin/ksh93 > > 1456 0x3e4000 0x3ec000 rw- 5 5 1 0 C---- df > > 1456 0x8003de000 0x8003e4000 r-- 6 28 364 120 CN--- vn /libexec/ld-elf.so.1 > > 1456 0x8003e4000 0x8003fb000 r-x 23 28 364 120 CN--- vn /libexec/ld-elf.so.1 > > 1456 0x8003fb000 0x8003fc000 r-- 1 0 1 0 CN--- vn /libexec/ld-elf.so.1 > > 1456 0x8003fc000 0x800411000 rw- 19 19 1 0 CN--- df > > 1456 0x800420000 0x800432000 r-- 13 33 352 176 CN--- vn /lib/libm.so.5 > > 1456 0x800432000 0x800459000 r-x 20 33 352 176 CN--- vn /lib/libm.so.5 > > 1456 0x800459000 0x80045a000 rw- 1 0 1 0 CN--- vn /lib/libm.so.5 > > 1456 0x80045a000 0x80045b000 rw- 1 0 1 0 CN--- vn /lib/libm.so.5 > > 1456 0x80045b000 0x8004df000 r-- 132 380 528 284 CN--- vn /lib/libc.so.7 > > 1456 0x8004df000 0x80062b000 r-x 234 380 528 284 CN--- vn /lib/libc.so.7 > > 1456 0x80062b000 0x800633000 r-- 8 0 1 0 CN--- vn /lib/libc.so.7 > > 1456 0x800633000 0x800634000 rw- 1 0 1 0 CN--- vn /lib/libc.so.7 > > 1456 0x800634000 0x80063b000 rw- 7 0 1 0 C---- vn /lib/libc.so.7 > > 1456 0x80063b000 0x8008f5000 rw- 84 84 1 0 C---- df > > 1456 0x800a00000 0x801200000 rw- 13 13 1 0 CN--- df > > 1456 0x7fffdffff000 0x7ffffffdf000 --- 0 0 0 0 ----- gd > > 1456 0x7ffffffdf000 0x7ffffffff000 rw- 11 11 1 0 C--D- df > > 1456 0x7ffffffff000 0x800000000000 r-x 1 1 125 0 ----- ph > > Here the stack starts at 0x7ffffffdf000 > > And the same on 14.0 running on a 4Gbyte VirtualBox VM > > > paulf@freebsd:~/valgrind $ procstat -v 62770 > > PID START END PRT RES PRES REF SHD FLAG TP PATH > > 62770 0x200000 0x273000 r-- 115 488 4 2 CN--- vn /usr/local/bin/ksh93 > > 62770 0x273000 0x3c7000 r-x 340 488 4 2 CN--- vn /usr/local/bin/ksh93 > > 62770 0x3c7000 0x3d4000 r-- 13 0 2 0 C---- vn /usr/local/bin/ksh93 > > 62770 0x3d4000 0x3d5000 rw- 1 0 2 0 C---- vn /usr/local/bin/ksh93 > > 62770 0x3d5000 0x3da000 rw- 5 0 1 0 C---- vn /usr/local/bin/ksh93 > > 62770 0x3da000 0x3e2000 rw- 5 5 1 0 ----- sw > > 62770 0x80075d000 0x82073d000 --- 0 0 0 0 ----- gd > > 62770 0x82073d000 0x82075d000 rw- 14 14 1 0 ---D- sw > > 62770 0x8209c8000 0x8209c9000 r-x 1 1 28 0 ----- ph > > 62770 0x8217b0000 0x8217c2000 rw- 16 16 1 0 ----- sw > > 62770 0x822186000 0x822210000 r-- 138 496 104 54 CN--- vn /lib/libc.so.7 > > 62770 0x822210000 0x82235e000 r-x 334 496 104 54 CN--- vn /lib/libc.so.7 > > 62770 0x82235e000 0x822367000 r-- 9 0 2 0 C---- vn /lib/libc.so.7 > > 62770 0x822367000 0x822368000 rw- 1 0 2 0 C---- vn /lib/libc.so.7 > > 62770 0x822368000 0x82236f000 rw- 7 0 1 0 C---- vn /lib/libc.so.7 > > 62770 0x82236f000 0x82259e000 rw- 20 20 1 0 ----- sw > > 62770 0x823434000 0x823447000 r-- 19 59 4 2 CN--- vn /lib/libm.so.5 > > 62770 0x823447000 0x82346f000 r-x 40 59 4 2 CN--- vn /lib/libm.so.5 > > 62770 0x82346f000 0x823470000 rw- 1 0 1 0 C---- vn /lib/libm.so.5 > > 62770 0x823470000 0x823471000 rw- 1 0 1 0 C---- vn /lib/libm.so.5 > > 62770 0x823e0e000 0x823e3e000 rw- 16 16 1 0 ----- sw > > 62770 0x824600000 0x824800000 rw- 11 11 1 0 ----- sw > > 62770 0x8251a1000 0x8253a1000 rw- 1 1 1 0 ----- sw > > 62770 0x825e00000 0x826200000 rw- 3 3 1 0 ----- sw > > 62770 0x826a49000 0x826a61000 rw- 8 8 1 0 ----- sw > > 62770 0x826e5c000 0x826e74000 rw- 14 14 1 0 ----- sw > > 62770 0x827d6e000 0x827d86000 rw- 9 9 1 0 ----- sw > > 62770 0x8288ba000 0x8288d2000 rw- 5 5 1 0 ----- sw > > 62770 0x8296db000 0x8296f3000 rw- 3 3 1 0 ----- sw > > 62770 0xeeeecc15000 0xeeeecc1b000 r-- 6 29 71 21 CN--- vn /libexec/ld-elf.so.1 > > 62770 0xeeeecc1b000 0xeeeecc32000 r-x 23 29 71 21 CN--- vn /libexec/ld-elf.so.1 > > 62770 0xeeeecc32000 0xeeeecc33000 r-- 1 0 1 0 C---- vn /libexec/ld-elf.so.1 > > 62770 0xeeeecc33000 0xeeeecc35000 rw- 2 2 1 0 ----- sw > > 62770 0x7ffffffff000 0x800000000000 --- 0 0 0 0 ----- gd > > > ldrt is now mapped up at 0xeeeecc15000 and the user stack looks like it > starts at 0x82073d000. > > This is causing me problems with Valgrind, which creates the guest stack > at 0x7ffffffdf000. > > I haven't yet done any debugging of the problem but this causes > > Fatal error 'Cannot allocate red zone for initial thread' at line 395 in > file /usr/src/lib/libthr/thread/thr_init.c (errno = 22) > > for elf binaries linked with libthr.so > > Can anyone point me to more information on this change? Phabricator for > instance. It is related to some changes to randomize the base of the process stack, as we do for other components of the address space. See https://cgit.freebsd.org/src/commit/?id=1811c1e957ee1250b08b3246fc0db37ddf64b736 for example. In 14.0 randomization is enabled by default. > Are there any syscalls that control where rtld gets loaded and/or where > the stack base is located? No, their locations are randomized. There are sysctl knobs for controlling whether randomization is enabled or not. > Also is there a sysctl to disable this changed mapping, as a temporary > workaround? Setting kern.elf(64|32).aslr.stack to 0 should restore the old behaviour. It should also be possible to disable this on a per-process basis with proccontrol(1), but that doesn't appear to work, i.e., there is a bug. However, all randomization can be disabled this way, try "procstat -m aslr -s disable ksh93". From nobody Sun Oct 16 15:29:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr3vP0VsCz4fSBM for ; Sun, 16 Oct 2022 15:29:21 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4Mr3vN2wXYz3YhJ for ; Sun, 16 Oct 2022 15:29:20 +0000 (UTC) (envelope-from pauamma@gundo.com) Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id A684F4C0366; Sun, 16 Oct 2022 10:29:18 -0500 (CDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 16 Oct 2022 15:29:18 +0000 From: Pau Amma To: Paul Floyd Cc: freebsd-hackers Subject: Re: AMD64 14.0-CURRENT memory layout changes In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.8 Message-ID: <18733815c5cf1af1e313168629916ee5@gundo.com> X-Sender: pauamma@gundo.com Organization: The Cabal (TINC) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mr3vN2wXYz3YhJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=gundo.com; spf=pass (mx1.freebsd.org: domain of pauamma@gundo.com designates 75.145.166.65 as permitted sender) smtp.mailfrom=pauamma@gundo.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gundo.com,none]; R_SPF_ALLOW(-0.20)[+ip4:75.145.166.64/28:c]; RCVD_IN_DNSWL_MED(-0.20)[75.145.166.65:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[75.145.166.65:from]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[pauamma]; RCPT_COUNT_TWO(0.00)[2]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 2022-10-16 15:08, Paul Floyd wrote: > Hi > > I just noticed that the memory layout has changed for elf binaries > running on amd64 (my last attempt to setup an i386 VM failed so I > can't confirm if that also changed, and I'm not yet concerned by other > platforms). > > Here's a procstat -v for ksh93 on 13.1 on the host machine > >> [snipped] > > Here the stack starts at 0x7ffffffdf000 > > And the same on 14.0 running on a 4Gbyte VirtualBox VM > >> [snipped] > > ldrt is now mapped up at 0xeeeecc15000 and the user stack looks like > it starts at 0x82073d000. > > This is causing me problems with Valgrind, which creates the guest > stack at 0x7ffffffdf000. > > I haven't yet done any debugging of the problem but this causes > > Fatal error 'Cannot allocate red zone for initial thread' at line 395 > in file /usr/src/lib/libthr/thread/thr_init.c (errno = 22) > > for elf binaries linked with libthr.so > > Can anyone point me to more information on this change? Phabricator > for instance. > > Are there any syscalls that control where rtld gets loaded and/or > where the stack base is located? > > Also is there a sysctl to disable this changed mapping, as a temporary > workaround? Jumoing in with some quarterly reports I saw pass that may be related to either/both: - https://www.freebsd.org/status/report-2022-04-2022-06/#_shared_page_address_randomization (not sure this is about rtld) - https://www.freebsd.org/status/report-2021-07-2021-09/#_stack_gap_handling_improvements (this one mentions a switch-off sysctl). -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Sun Oct 16 17:51:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr73c0VYFz4fjSs; Sun, 16 Oct 2022 17:51:40 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr73b0kqbz3rGF; Sun, 16 Oct 2022 17:51:39 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vs1-xe2d.google.com with SMTP id k6so9525060vsc.8; Sun, 16 Oct 2022 10:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sxK6oqqPu5Ol/+0lvQQb486TkPrbd/nR/j3PEc89wpc=; b=ZvDB0N1uFEBI+FXd6sTcml7XKWx05YWd1QUthGf647nBWAw31EpdUn5TTNsR2mfVkz 8GL032D9ObegT8kgwNe/QFGsie9iXzoqgIMlUZGyF7by+zJj0IXaaRgJdrJ6pykaFNsk /6beaZjP9hZzRocJ64GM/tHzN9Cov8n6mkBYKzlhjL7HgUvHPty+2uAg3OO0pkTDI2Sh 7K7bRCuHZN6DqoZ2xtSoeDyDEl2kkaJziUP5BjE31vmh9GHKvX8tJzbYgLNxjkmbWwBE LkYtFmMeMo/vOas4XSZ7iyydcqGDN2YqQxG4nlD7Q+TR5W+BXyGfiDuqVYahKJlQVfDj I45g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sxK6oqqPu5Ol/+0lvQQb486TkPrbd/nR/j3PEc89wpc=; b=Frmukbhot5iY95kQxoxHBZ7gmsXipc3ijH5yJsZ5nt6mtv4XH764xfO8T3yqTQELJ8 GpkaBssurU1pW6tOUryxW8FjsLAOJrCm8ystv4n3WHQ/LOCGFpu4B4zeV3IDiahgmc2l gRygL9vKlKdbNu3Vq1M/CtyPVpTt4a29jeXyilwe7T9WY5loslX5ycAxuQFf9HfGv75S Ns37KlkLFAEZBJGz2qI3Q6xqGfdCuuwxzSSh4cpALcsfkPcGiTRccE4gXYkcdj7ZB2jv 85VNY+QNojHoQTL07Ekvf5ler/X5cK1vOJZKwmC66Xk/WKJ9bYAdE2LawQ4igWN5n4y+ T9fQ== X-Gm-Message-State: ACrzQf38opa/zn4yesMTHk7kFOuBCFKNcC/s7+uELyPdKknq43TszZ3Z shBefVMsyfY/NLa5zh4fm4ShAc+e18Wa7eFPhrTwzXyHHkyxH9lu X-Google-Smtp-Source: AMsMyM7rGNZVK6c6m3A/OtlWqEaMQ+L0yi0iNVkbGmt1/neZ5YDA1Oa+Rr+HMlyhGYkCN65emFoBW35C5WnkPrSVHEw= X-Received: by 2002:a67:b74a:0:b0:399:4161:9f94 with SMTP id l10-20020a67b74a000000b0039941619f94mr2494132vsh.1.1665942698019; Sun, 16 Oct 2022 10:51:38 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:8cd1:0:b0:319:151e:7726 with HTTP; Sun, 16 Oct 2022 10:51:37 -0700 (PDT) In-Reply-To: <86czbwryx0.fsf@ltc.des.no> References: <86h718sqdx.fsf@ltc.des.no> <86czbwryx0.fsf@ltc.des.no> From: grarpamp Date: Sun, 16 Oct 2022 13:51:37 -0400 Message-ID: Subject: Re: Putting OPIE to rest To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-questions@freebsd.org, des@des.no Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Mr73b0kqbz3rGF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZvDB0N1u; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2d as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org,freebsd-stable@freebsd.org,freebsd-questions@freebsd.org]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 9/15/22, Dag-Erling Sm=C3=B8rgrav wrote: > Neither HOTP nor TOTP require dedicated devices. > HOTP codes are sequential and can be pre-generated... Those aren't really their intended or advertised usage models, nor do common implementations support those modes. Is FreeBSD contributing and supplying ones that do? OPIE's model already intends for and supports no-device and printout. To emphasize and extend... https://lists.freebsd.org/archives/freebsd-current/2022-September/002573.ht= ml It should also be noted that the affected scope here is not just 'FreeBSD u= sers logging into FreeBSD shell', there are also applications out there that com= pile against and use FreeBSD's libopie, some of which are in ports some are not. OPIE does not exist as a port+package, thus re POLA for users, it should not be removed until such time as one is provided. Where is discussion on these. And why isn't every other 'old, outlived, non-hipster' pam authentication plugin being arbitrarily removed and non-portified, such as say tacacs, radius, krb, rhosts, etc. And if those pam are there, why then are hip OAUTH HOTP TOTP etc type thing= s not added, lib-ified, etc. From nobody Sun Oct 16 18:39:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mr87M0TL8z4fpSY for ; Sun, 16 Oct 2022 18:39:59 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mr87L0yCdz42QH for ; Sun, 16 Oct 2022 18:39:58 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id u10so15253509wrq.2 for ; Sun, 16 Oct 2022 11:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+GpzFtBW0yp5mgqkzsQyNmjh0r50GN0RZj71G2tMBaM=; b=SNk2gL+854Y30lSouVW3hdG0aTho6lZRmCSeLwq0q0ebOZGikq13w2QZ0aimRxJede wuUqPJpXTdGZNH7rWLM53hbYpQkF5Lm/4XyJLW1m9dmYOKg43FdzHdUFLe6vgUaGqHNW bHwiLCGIbtpjD63PbjqEu+LqrPCsWbjx8Vd18t5x+uBYhr6nyScH2OHTT38dXqv5qVVD E1BxF8cmoJGBu4iLAAI/4cm7lbX3SZ/v3b+TfRlfqovz0VGUBLEoI59xPINiCn0RpH+N o1EeIv1YRFUVikzqaVuYUh+nzMvrOKA1NyGVO3+evBS2zegV6JToDL/VAEv1J6bIxzON SwxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+GpzFtBW0yp5mgqkzsQyNmjh0r50GN0RZj71G2tMBaM=; b=SQlpeDFRPh17Sxg0ZkiiOD69rk90Nbxc4+8uGTyT7N7H4/EiqNgvWV1VDFF7yoTiFD aKbiuRjgzKhoDOQvMBUP6lsVHf4TbXhJ8V4sLkev8o4+A/fyesaGBjAVqi6AL1miYlBg k19h9uyZTJtx3j2YcXlVPXHQldWAUrNNp/jvdHSumjUkfhorpqUknmt1sCkmoPa+lX2F WBzPYnAdoYiC4ZBMuFbffjcBVOE6veudGU+jGinFNjxvuCPTPNdovyhUUh3riGSjjRb6 LjwmN2da3DKEBGH4qVsGcZkeJc814L4xmhf/Satgk+ljysJ0+qOKV3B7epKYaaTyLBbF XExg== X-Gm-Message-State: ACrzQf3cDKs3POjx/ywAhVI9W9dULCOcUJ2OveIqvDmyXDC3080QwQPW EFB8mB0CWvkpmraTZPGz/Un8PL9Mxws= X-Google-Smtp-Source: AMsMyM7tM6Nhl/+wnT1DSzBcl7W/0DAN6Maeeqw2PaRPzUzw35t2HzyUZ6KAB6t6fuWtkwOTdLEYKA== X-Received: by 2002:a5d:648c:0:b0:22e:63be:be09 with SMTP id o12-20020a5d648c000000b0022e63bebe09mr4182912wri.159.1665945595319; Sun, 16 Oct 2022 11:39:55 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-263-217.w2-7.abo.wanadoo.fr. [2.7.103.217]) by smtp.gmail.com with ESMTPSA id j10-20020a05600c190a00b003c6b7f5567csm24812011wmq.0.2022.10.16.11.39.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 16 Oct 2022 11:39:54 -0700 (PDT) Message-ID: Date: Sun, 16 Oct 2022 20:39:53 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: AMD64 14.0-CURRENT memory layout changes Content-Language: en-US To: freebsd-hackers References: <18733815c5cf1af1e313168629916ee5@gundo.com> From: Paul Floyd In-Reply-To: <18733815c5cf1af1e313168629916ee5@gundo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mr87L0yCdz42QH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SNk2gL+8; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 10/16/22 17:29, Pau Amma wrote: > Jumoing in with some quarterly reports I saw pass that may be related to > either/both: > - > https://www.freebsd.org/status/report-2022-04-2022-06/#_shared_page_address_randomization (not sure this is about rtld) > - > https://www.freebsd.org/status/report-2021-07-2021-09/#_stack_gap_handling_improvements (this one mentions a switch-off sysctl). Hi Pau Amma and Mark Thanks for the info. I now understand the problem. Valgrind needs to intercept sysctl(byname) kern.stacktop and return its own value. I'm already doing this for kern.usrstack. Without interception the guest is getting the stacktop of the host. The host obviously refuses to let the guest mmap over its own stack, resulting in an assert and guest crash. A+ Paul From nobody Mon Oct 17 02:09:52 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrL6V1xw9z4fTjm for ; Mon, 17 Oct 2022 02:09:54 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrL6T34ctz3qGG for ; Mon, 17 Oct 2022 02:09:53 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: by panix.netmeister.org (Postfix, from userid 1000) id E924285851; Sun, 16 Oct 2022 22:09:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2022; t=1665972592; bh=qlvtFyx8xCzQSEWjc9QzZuxLA1UCxRAbQgNFmOJBduY=; h=Date:From:To:Subject; b=IJjgxwyDn3AvoaBIbaOzh2JtW9nGygL/UxwYrXh4jfUxa8rGUkaXhX5BqwBKe00rS 8MLJXEqfYnnJkn7/AxxGCNgHp7+imbXmPJ14HMAUacumGfjQwrSmSY8r132qQsFpHH PLAYqn24R3CfTOSUQLtLWEXrdWH1ptGk4iuaOgSEdPBEs/wAFKfOe/Typ+BGtpfm4P lONnLWLnp0UwW9yLEEdI5ygNUnpNvP4AApe6Gv46Z+5pBpA1zGEOAKD529sat4x4Hs JpHAf1X/EUTkh+RPjzANmFK3nDO3elqUumLuH2lVooAaXRJ1JX7J9/U1KcmIAEQhl5 +vQEFc+jc88YQ== Date: Sun, 16 Oct 2022 22:09:52 -0400 From: Jan Schaumann To: freebsd-hackers@freebsd.org Subject: host unresponsive when setting time very far in the future Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 4MrL6T34ctz3qGG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netmeister.org header.s=2022 header.b=IJjgxwyD; dmarc=pass (policy=quarantine) header.from=netmeister.org; spf=pass (mx1.freebsd.org: domain of jschauma@netmeister.org designates 166.84.7.99 as permitted sender) smtp.mailfrom=jschauma@netmeister.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netmeister.org,quarantine]; R_SPF_ALLOW(-0.20)[+a:c]; R_DKIM_ALLOW(-0.20)[netmeister.org:s=2022]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[netmeister.org:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I've observed that trying to set the date _very_ far in the future causes my FreeBSD AWS instance to become unresponsive and requiring a forced reboot to come back. (I don't see an actual kernel panic, however.) # date -f "%s" 44093078356492799 Fri Dec 31 23:59:59 UTC 1397255999 succeeds, but any second more (i.e., into the year 1397256000), and the system locks up. After setting the date as above and waiting a few seconds does increment the seconds since epoch just fine into the year 1397256000: # date +%s 44093078356492850 # date Sat Jan 1 00:00:51 UTC 1397256000 so gettimeofday(2) has no problem with these numbers, but it seems that settimeofday(2) does tickles the kernel in a funny way? What's the significance of this particular year? If tm_year is a 32-bit entity, then I'd expect it to max out at epoch 67768036191676799 aka 12/31 23:59:59 2147485547, but that doesn't seem to be the case here. Any ideas (a) what this limit is, and (b) why the system doesn't handle it gracefully by e.g., returning EINVAL? -Jan From nobody Mon Oct 17 04:35:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrPLR6sNRz4fmlK for ; Mon, 17 Oct 2022 04:35:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrPLR1zFMz42HN for ; Mon, 17 Oct 2022 04:35:27 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-oi1-x234.google.com with SMTP id w196so10927135oiw.8 for ; Sun, 16 Oct 2022 21:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kX1ZosbsbppmgTBVsLMlS182r4Z76U6HIETyfVLAfnI=; b=a//WjBGEZedVKbyGQhek/IV6hzIt26XvUZVL9JAfY4LAaRK3aK2PJj46OBFRQaHN3H 47HVBeLPbLxC6dXJFkmvQaVB85z75Mm+NBCg8rw0tGkgBMV6WNYkBthqrkXiEirp6Wi2 lHCOafjP2+kv7nDiBAvMWnp/aLH6TbyqlzRu3bhK0jYWMZeQpvm3eiWEioKm5tznce+v ne67bjUGqNrmwtSdR1ZPJvxJTvwXQNSTNMqbcaab3qRntwa6bE2uwqAP2f9UblaQblbx i4+sGbsOQLdsSvQVl3E8uKSLJ2RbwaakJmOKeU8RvK7Kaz1K4CYcSAybWOFfkr1WdZui +gZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kX1ZosbsbppmgTBVsLMlS182r4Z76U6HIETyfVLAfnI=; b=OfS93WcJsUSU62nNw/yPOa82kI9TyZmYyHGUqBWNUS8GT8wDeHHlUOfMuhQW9a2vFv nHIuAuVF5cXemcZlycCOz5Z1DjrSoO/jvIIDZXdpjCnVkvIsZl7MhslxspYsHphHXMaV bEkmf9rqXwQ2WLeIJUgVpLza5L/0L7ftBiPLaoh8XNDB1WxmEZfQg7IDs0Y5ajYK1ZFw +HxyMxhqvutGeqXpBfcGLxx4n1hKueNTxfgRbHmyJAku55yxtf9hpisPJiC/XdmDTqfc TjpUFMpeHClL+sxQ902QAQa5oeqDM59YZnUPiyxMYQRQkpS9YhyI1weNeRz4zA8j6Jem AYQA== X-Gm-Message-State: ACrzQf2Oiv4hw2qm8FGBl1hoCDjHyE6o/LfdvX8iHIDSx3N0r7J7SPK9 nmtR4a0Dhg8ERkVMqmUYO6KICU3PzF9ar7EtUx/5FvuZdnU= X-Google-Smtp-Source: AMsMyM6P2X9RmJdHBjKFMSIgHnPqfMfokxrghH++qvmEcuDNqjR0r8Z0f/tBqzqEluN5wntHzqJMksbuVPQo3F92lMc= X-Received: by 2002:a05:6808:993:b0:354:c979:46f6 with SMTP id a19-20020a056808099300b00354c97946f6mr11802342oic.141.1665981326369; Sun, 16 Oct 2022 21:35:26 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Mon, 17 Oct 2022 06:35:14 +0200 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Jan Schaumann Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000292cde05eb33813b" X-Rspamd-Queue-Id: 4MrPLR1zFMz42HN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="a//WjBGE"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2607:f8b0:4864:20::234 as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.966]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::234:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000292cde05eb33813b Content-Type: text/plain; charset="UTF-8" Jan, On Mon, Oct 17, 2022, 04:10 Jan Schaumann wrote: > Hello, > > I've observed that trying to set the date _very_ far > in the future causes my FreeBSD AWS instance to become > unresponsive and requiring a forced reboot to come > back. (I don't see an actual kernel panic, however.) > A few questions that come to mind: - Which version of FreeBSD? - which architecture (I know nothing of AWS, perhaps that's implied)? - have you tried this on a different platform (a VM or real HW)? Out of curiosity: why? :-) One thing I'd do in a situation like this is display the numbers in hex, that may give you a clue. HTH Michael PS: make sure to keep the list included, this about the extent of what I can add here! > # date -f "%s" 44093078356492799 > Fri Dec 31 23:59:59 UTC 1397255999 > > succeeds, but any second more (i.e., into the year > 1397256000), and the system locks up. > > After setting the date as above and waiting a few > seconds does increment the seconds since epoch just > fine into the year 1397256000: > > # date +%s > 44093078356492850 > # date > Sat Jan 1 00:00:51 UTC 1397256000 > > so gettimeofday(2) has no problem with these numbers, > but it seems that settimeofday(2) does tickles the > kernel in a funny way? > > What's the significance of this particular year? If > tm_year is a 32-bit entity, then I'd expect it to max > out at epoch 67768036191676799 aka 12/31 23:59:59 > 2147485547, but that doesn't seem to be the case here. > > Any ideas (a) what this limit is, and (b) why the > system doesn't handle it gracefully by e.g., returning > EINVAL? > > -Jan > > --000000000000292cde05eb33813b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jan,=C2=A0

On Mon, Oct 17, 2022, 04:10 Jan Schaumann &l= t;jschauma@netmeister.org>= ; wrote:
Hello,

I've observed that trying to set the date _very_ far
in the future causes my FreeBSD AWS instance to become
unresponsive and requiring a forced reboot to come
back.=C2=A0 (I don't see an actual kernel panic, however.)

A few questio= ns that come to mind:
- Which version of FreeBSD?=C2= =A0
- which architecture (I know nothing of AWS, per= haps that's implied)?=C2=A0
- have you tried thi= s on a different platform (a VM or real HW)?=C2=A0
<= br>
Out of curiosity: why? :-)=C2=A0

One thing I'd do in a situation l= ike this is display the numbers in hex, that may give you a clue.=C2=A0

HTH=C2=A0
Michael=C2=A0
PS: make sure to keep the list i= ncluded, this about the extent of what I can add here!=C2=A0


# date -f "%s" 44093078356492799
Fri Dec 31 23:59:59 UTC 1397255999

succeeds, but any second more (i.e., into the year
1397256000), and the system locks up.

After setting the date as above and waiting a few
seconds does increment the seconds since epoch just
fine into the year 1397256000:

# date +%s
44093078356492850
# date
Sat Jan=C2=A0 1 00:00:51 UTC 1397256000

so gettimeofday(2) has no problem with these numbers,
but it seems that settimeofday(2) does tickles the
kernel in a funny way?

What's the significance of this particular year?=C2=A0 If
tm_year is a 32-bit entity, then I'd expect it to max
out at epoch 67768036191676799 aka 12/31 23:59:59
2147485547, but that doesn't seem to be the case here.

Any ideas (a) what this limit is, and (b) why the
system doesn't handle it gracefully by e.g., returning
EINVAL?

-Jan

--000000000000292cde05eb33813b-- From nobody Mon Oct 17 06:02:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrRHl6m06z4fx0G for ; Mon, 17 Oct 2022 06:03:15 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrRHl3GJsz46q6 for ; Mon, 17 Oct 2022 06:03:15 +0000 (UTC) (envelope-from michaelsprivate@gmail.com) Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-1322d768ba7so12226929fac.5 for ; Sun, 16 Oct 2022 23:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zd5Th1LGaXw8pM/KLuxoARm/IJ0TI9Q3WsSjNV/DN6w=; b=jXjqP1pW+2sKcGcceiuIWxxWZ8NKm3A75E5uD+/FmJfdql8v+JmI+tV7sXazhD82IP 7jbC32TCbxpspK8nDP00ZTH+FoIS80v07EePbw5C1gERdO7bKBfJ3BDvuyYFPn6E4+rY BzPPw2MF3sVGvrU+LNYtCTnhXcLQC/5ij645vtzCPFuewrlPeMwUExXXl6X/uLV97DbQ 84HUpz732JmtUtDG28VayPfz+L/GHUlCJ/Zrh4EzSSTEqQIVIzy0ya2Kc9RCSMAHTVkT nzklzGH69J2SH7x+/ojGoSKrr/U1/r8LS/Fse+gfwDVUr8QJttYZNWBvMXFbvTf0SRTn RRTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zd5Th1LGaXw8pM/KLuxoARm/IJ0TI9Q3WsSjNV/DN6w=; b=JLrPaYWUS8/XpE2cg+3sRxuT7bVp1haXgndeAoDKFNj+twImWtzBSKgeMdonotVkyY muYk7kOqpUUh0Tz7K0VXxesXDW6WeyW/wrFPLiW+b5WoM+Ur1BC1PLrTQ6UHxqOuS0ky qCG33j5t7xwXHHjgVe+7ebIhb3lI88N0qgaLUxZqk/cdrn0PkF8IGQDY2degeyyaq+JS 34d8BH4RuNSGvV0R4w3ldj3h188VJQWzjJRLtsYZjL1Td5C4xl88Fer6MkYQ2m+lTMom lsGHVFyOpsVI5mpaPmyJzjfXUDnIkTmY/PCZJOb9PaecxI5REPF4oVxLkOHSwcc2d5Bw Z9qQ== X-Gm-Message-State: ACrzQf1U7TNK6YQdPDoBKFTdclZoCBF3foJF5STA4BoHMoeWnzUuR4AF uC2kZ8NNDw4bhN/83M5wn7h3n+knOY5Fi4hd37wrOpIDOnWFWKn0 X-Google-Smtp-Source: AMsMyM4JLTmGttJ0hIn3gD+V4qq7ki6dgm8HMR0NXwCNIh7+GdLD2L5oRfDfQEKC8be/oHGsdeDUNcizVwOiYzOcJNU= X-Received: by 2002:a05:6870:d626:b0:132:9149:dc8a with SMTP id a38-20020a056870d62600b001329149dc8amr14017180oaq.141.1665986594492; Sun, 16 Oct 2022 23:03:14 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Michael Schuster Date: Mon, 17 Oct 2022 08:02:38 +0200 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Jan Schaumann Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MrRHl3GJsz46q6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jXjqP1pW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of michaelsprivate@gmail.com designates 2001:4860:4864:20::2f as permitted sender) smtp.mailfrom=michaelsprivate@gmail.com X-Spamd-Result: default: False [-3.86 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.86)[-0.865]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::2f:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N to answer myself: On Mon, Oct 17, 2022 at 6:35 AM Michael Schuster wrote: > > Jan, > > On Mon, Oct 17, 2022, 04:10 Jan Schaumann wrote: >> >> Hello, >> >> I've observed that trying to set the date _very_ far >> in the future causes my FreeBSD AWS instance to become >> unresponsive and requiring a forced reboot to come >> back. (I don't see an actual kernel panic, however.) > > > A few questions that come to mind: > - Which version of FreeBSD? > - which architecture (I know nothing of AWS, perhaps that's implied)? > - have you tried this on a different platform (a VM or real HW)? on AMD-based HW from 2020, running 13.1-RELEASE-p2, I could not duplicate OP's observation. regards > > Out of curiosity: why? :-) > > One thing I'd do in a situation like this is display the numbers in hex, that may give you a clue. > > HTH > Michael > PS: make sure to keep the list included, this about the extent of what I can add here! > >> >> # date -f "%s" 44093078356492799 >> Fri Dec 31 23:59:59 UTC 1397255999 >> >> succeeds, but any second more (i.e., into the year >> 1397256000), and the system locks up. >> >> After setting the date as above and waiting a few >> seconds does increment the seconds since epoch just >> fine into the year 1397256000: >> >> # date +%s >> 44093078356492850 >> # date >> Sat Jan 1 00:00:51 UTC 1397256000 >> >> so gettimeofday(2) has no problem with these numbers, >> but it seems that settimeofday(2) does tickles the >> kernel in a funny way? >> >> What's the significance of this particular year? If >> tm_year is a 32-bit entity, then I'd expect it to max >> out at epoch 67768036191676799 aka 12/31 23:59:59 >> 2147485547, but that doesn't seem to be the case here. >> >> Any ideas (a) what this limit is, and (b) why the >> system doesn't handle it gracefully by e.g., returning >> EINVAL? >> >> -Jan >> -- Michael Schuster http://recursiveramblings.wordpress.com/ recursion, n: see 'recursion' From nobody Mon Oct 17 11:12:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrZ8X3mrsz4fbM3 for ; Mon, 17 Oct 2022 11:12:28 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrZ8W3r1sz3Zns for ; Mon, 17 Oct 2022 11:12:27 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 29HBCGa9056967 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 17 Oct 2022 13:12:17 +0200 (CEST) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1666005137; bh=CGR2j29LAv5ekuboY/qj/E6J1L+F91Lc4P/WRfdMopU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LydW01sILdW4sxocd3zZY9rNwdpTzv/LcVGLmKjalBQJxshAEl+bXZmFvZOMJbGRr gRZuPCR5PRDnxtnNALqQow8VtYDgXXPPlfTJOJB2kCW8ddPGOT6bu6CUBlqabCdzCu 6ZliyYuEqGTEKtWHZr7B5JU8JvneOzm+NQHYA5qc= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 29HBCGsF030716; Mon, 17 Oct 2022 13:12:16 +0200 (CEST) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 29HBCGWa030713; Mon, 17 Oct 2022 13:12:16 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 17 Oct 2022 13:12:16 +0200 (CEST) From: Wojciech Puchar To: Jan Schaumann cc: freebsd-hackers@freebsd.org Subject: Re: host unresponsive when setting time very far in the future In-Reply-To: Message-ID: <5b763a17-e973-55f9-741a-f912e8fa93ab@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4MrZ8W3r1sz3Zns X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=LydW01sI; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > I've observed that trying to set the date _very_ far > in the future causes my FreeBSD AWS instance to become > unresponsive and requiring a forced reboot to come > back. (I don't see an actual kernel panic, however.) > > # date -f "%s" 44093078356492799 > Fri Dec 31 23:59:59 UTC 1397255999 hurry up or after 1.4 billion years my server will stop working. From nobody Mon Oct 17 12:38:45 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mrc465l1Sz4fqNN for ; Mon, 17 Oct 2022 12:38:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrc460kJHz3ZMw for ; Mon, 17 Oct 2022 12:38:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4Mrc456yLjzqHs for ; Mon, 17 Oct 2022 12:38:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 29HCcjOi034738 for ; Mon, 17 Oct 2022 12:38:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 29HCcjFc034737 for hackers@FreeBSD.org; Mon, 17 Oct 2022 12:38:45 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 47286] [request] [patch] make device probing verbose when using boot -v Date: Mon, 17 Oct 2022 12:38:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: grahamperrin@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666010326; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zFWHw1kCH4SmGKowc6oBkqZNhxEeGPQ8ScwLDKDjTH8=; b=Exkhzfl6conHPnkGzlOwxpoi2oQ8Zxd9oScpqZsKPC6iJ99f5CQLtCtIieFxO4WLGuPYfe ucR7wXkKfQyac96ie3+dhRfIjtkUhumY3yrKKBMjnKxRcMM/lrr7rnTI4+URN27LuqsOQV qdbTVfwrqwrsfNV/O0D5gBRAw3lkc8w8SZk6fmIz6qvS8RqZmqXdd6DFJXpXFzeWBO4YOj kFQo94EnzmGpB02w5k1a2aaBZ2Ugrh4cUXtSJT5YNxQUCenySuY7o7eMoLpjHJ34mq5xgf oOy0jhPjZsNy/mz+uOX7s9vUgulEYdZZw9uQcKDbf2iwnOFxLh3f90TopC8Yaw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666010326; a=rsa-sha256; cv=none; b=HaNuc8SrQiBwitP2gQhYa9wLU+w8/O8XwPdxGSDn2GsL+cItjN+bYqIIDXaK2TqYptCtAE U1WrY6fjETCwh0A4nmF5HLGi6ZL8mRDBqOuyKjw2ehWb07ZFfuisuAGjP2YZIiIdG028PN ZTwJme4RErUacAnhJLHgObFf3a18DCg1JnZkatBxYeMVlifHX/F8TsmDpslviWSwePZTkk VFmB+Mx/7DqyqKjNiIMtyPTT2xYE/vNjI1IxbHFM+lys7KmES9B70X2fbEu64mLRwLSIrs wclc+FUFBgUgPgMUzXZ4evZc62uhKQhcGtncQ/2UMZurc9LnwvPzzRJ1wW3mYQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D47286 Graham Perrin changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --- Comment #4 from Graham Perrin --- Keyword:=20 patch or patch-ready =E2=80=93 in lieu of summary line prefix:=20 [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk).=20 Keyword descriptions and search interface:=20 --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Mon Oct 17 13:08:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrckR0VJMz4fwMM for ; Mon, 17 Oct 2022 13:08:31 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrckQ27Lxz40MH for ; Mon, 17 Oct 2022 13:08:30 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-vs1-f50.google.com with SMTP id 63so11381293vse.2 for ; Mon, 17 Oct 2022 06:08:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WlSg3AiQTDkUocKExrITMxHTdEhEb5mt7nnpBYXCjAE=; b=SglHzuUXgWyNgmsp59hda8bDtTlD07v1VAoSPs6cJ0nhd7zdWBN/96+ecJLAhkhMZO +lm0DE4AiZiQG023vJh7emq5zK6isdHCZoS170O+4VaoyuJtLLHnnmDYSMuuvPl5j9t7 JUmzVn0vfBUzBUTNDz+p3JJS8jV+Bq5KfdNHVHBIj64GZaIBi1o67wpex2zNFMbufkD7 mZhrlf+ULJhJs9CBkqBWNJzfMAzfdZ7qux6cY72Imygz0BYTk1m6SBO3ZXr3aJBdy9T4 j34vybT8S7HA4XZOtcdthd9OAA3yuMJznNwVH3N3fMOHyAQSx/k1ozze6qXKlVuuHP2U Dt8Q== X-Gm-Message-State: ACrzQf1iBKE4WvRhbbVwtGxdByD4lYbHfFlSUR4sbH+cYIs3Ctv9eXsm XSuNAPAaccf+7yhKDCeBOoRElggJC0JYvMgAHi4= X-Google-Smtp-Source: AMsMyM4FhWjTVOzvU6uHNcjYz+cOrKryl+sBJMUwE6i1Zm8X0Xcyfw1ej2jqpMCxEXCpESjn5M/U4hv4mQvwsLnkVt4= X-Received: by 2002:a67:c30d:0:b0:3a7:1ba3:dd0 with SMTP id r13-20020a67c30d000000b003a71ba30dd0mr4380072vsj.76.1666012108321; Mon, 17 Oct 2022 06:08:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Mon, 17 Oct 2022 07:08:16 -0600 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Michael Schuster Cc: Jan Schaumann , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MrckQ27Lxz40MH 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.217.50 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_TO(0.00)[gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.50:from]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.50:from]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 17, 2022 at 12:03 AM Michael Schuster wrote: > > to answer myself: > > On Mon, Oct 17, 2022 at 6:35 AM Michael Schuster > wrote: > > > > Jan, > > > > On Mon, Oct 17, 2022, 04:10 Jan Schaumann wrote: > >> > >> Hello, > >> > >> I've observed that trying to set the date _very_ far > >> in the future causes my FreeBSD AWS instance to become > >> unresponsive and requiring a forced reboot to come > >> back. (I don't see an actual kernel panic, however.) > > > > > > A few questions that come to mind: > > - Which version of FreeBSD? > > - which architecture (I know nothing of AWS, perhaps that's implied)? > > - have you tried this on a different platform (a VM or real HW)? > > on AMD-based HW from 2020, running 13.1-RELEASE-p2, I could not > duplicate OP's observation. On 14.0-CURRENT there is a panic if you try to set past the year 10000 AD. The commit message suggests that limitation is intended to prevent overflows when the time gets converted into BCD, using a 16-bit year. And other code suggests it's a limitation that can't be easily lifted, because it's baked into the RTC hardware (for at least some RTC chips, anyway). But still, the panic ought to be converted into an EINVAL. The panics are in clock_ts_to_ct . -Alan From nobody Mon Oct 17 13:26:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mrd712G7Cz4fyBm for ; Mon, 17 Oct 2022 13:26:21 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrd703kYjz44Gn for ; Mon, 17 Oct 2022 13:26:20 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: by panix.netmeister.org (Postfix, from userid 1000) id 9BAFB85851; Mon, 17 Oct 2022 09:26:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2022; t=1666013179; bh=yKyWcaijA2wj8QdzcZ31nQHOF3GxIcy0MKVNLgmebhI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Lj+r9na/b743DjR8/xlQ9VO9frK8lWIbY941Y4Ed2ofQhlB43q/ru3fbighME0Uhe xA/1sceIGGHWqxLvmJhMYKF9QfXek7FNQBvbWgMP0dbQcNhpj82VBgKvM+zsXVGOVl F1iIcQQ7/9WSCyIYxxnP/vPt72uw2jI/IjLk+2/8NzesajKYcO0/74ga6eAL1G1QPV vRmntSeUR6c/i5optWmq9Y7KJm/BxEajc17MBm/TVXR+E9SmSgXomPHQoGkOBPI1cG VFse5VgBS39YQ9cTftDge+y5MwVl1k4YkOeByo2sn3OGAZrVLVTY8On4MHKP53NhsF XU6wFmco8lzag== Date: Mon, 17 Oct 2022 09:26:19 -0400 From: Jan Schaumann To: Michael Schuster Cc: FreeBSD Hackers Subject: Re: host unresponsive when setting time very far in the future Message-ID: Mail-Followup-To: Michael Schuster , FreeBSD Hackers References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Mrd703kYjz44Gn X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netmeister.org header.s=2022 header.b="Lj+r9na/"; dmarc=pass (policy=quarantine) header.from=netmeister.org; spf=pass (mx1.freebsd.org: domain of jschauma@netmeister.org designates 166.84.7.99 as permitted sender) smtp.mailfrom=jschauma@netmeister.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[netmeister.org,quarantine]; R_DKIM_ALLOW(-0.20)[netmeister.org:s=2022]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[netmeister.org:+]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Michael Schuster wrote: > On Mon, Oct 17, 2022, 04:10 Jan Schaumann wrote: > > I've observed that trying to set the date _very_ far > > in the future causes my FreeBSD AWS instance to become > > unresponsive and requiring a forced reboot to come > > back. (I don't see an actual kernel panic, however.) > > > > A few questions that come to mind: > - Which version of FreeBSD? > - which architecture (I know nothing of AWS, perhaps that's implied)? This was on AMI ami-00e91cb82b335d15f, from the official 13.0R announcement, amd64. > - have you tried this on a different platform (a VM or real HW)? No, I don't have those immediately available. But I just now tried on ami-0cf377776fddcf8ba, which is amd64 / 13.1R, where setting the date to 44093078356492800 succeeds. However, there the problem appears at 49282253052249598 epoch: # date -f "%s" 49282253052249598 Fri Dec 31 23:59:58 UTC 1561694399 # date -f "%s" 49282253052249599 Fri Dec 31 23:59:59 UTC 1561694399 [ reboots ~three seconds later ] I see a message in the logs that dhclient core dumped: Jan 1 00:00:14 freebsd kernel: pid 499 (dhclient), jid 0, uid 0: exited on signal 6 (core dumped) but that doesn't directly lead to the system rebooting. What's funny is is that after setting the date to 49282253052249598, it will continue to run just fine, even as the time advanced beyond the time at which it reboots when explicitly set. > Out of curiosity: why? :-) Exactly that: out of curiosity. :-) > One thing I'd do in a situation like this is display the numbers in hex, > that may give you a clue. In this case, I think the numbers point to the tm_year, as in both cases it's at the year end, it seems to me. -Jan From nobody Mon Oct 17 17:03:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrjyM28z6z4ZxdV for ; Mon, 17 Oct 2022 17:04:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrjyL1yMTz3c0F for ; Mon, 17 Oct 2022 17:04:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id e18so16967246edj.3 for ; Mon, 17 Oct 2022 10:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=X1SdIAuOwz51njV+UMn/na0NcpioucX9E6/mMNqLYxU=; b=it22lOkbh3U8mzHfWUaD6mZ/6J0P9nNzi313DDMRDupJQxRSE+2TIWmaxgTcwUJHql TowYQvNOf4HrnDI7rBsEutOm/EJ25JupGceHyByeER8XcsRBVKNVUeOYXO6/RRYtks8r cG/cXri9zNaSZYt2klrIsnrpXv4c8VpiXrIF8eP1ll6daKWXIkTVIeCiNjKaNe19A4Xb UxOYrVpCKr0jq/w3b5rHpsx7Q0ZUlIiyVmTX29b6y5D9mdP3Pj4PNefomWOdb6zYrF53 jcZCRPCqiYRUi7SVBe2A0TDJ32C35Q8qMw7M3h/bYq0m8G0XBrYoTY5IaGv1t9dz/FuF l2Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X1SdIAuOwz51njV+UMn/na0NcpioucX9E6/mMNqLYxU=; b=J37OaxNaDQ2fWGsVqAGk2nubqC7InlhyWWZiROkV6yQfpGg50pjjIe6aWXGOHzuKWL 3IzU/hsZnelYjtpvO33si1V5g1NvcwiKO0KKYPzzyeOTKDMXT1I1GxPvHqNtU3l+eBqC bLjsmQESxf4eIBMnkq5T9zsh8PJKEtAELdlrpZfa1WwDPZb5zv7N1hvrdvsc7LJfSh7w /+j74HClxbX/cozD91LME/V5FluqTRVJ7xcZ3/PuTS4+cdEKm+Gs56QaY4Lupkxm4x3M B8ODhXdISGH9Iqv6iwvdfcoGfLedypJuvtLdVypoOqbctLtrK8rZFnJYUJ4yjDbed3tf pijw== X-Gm-Message-State: ACrzQf2Y+Gf76NzjAMYvadnNp+aw7UeQ4hw2+5fpLAxCSlXeEpOvnnd6 dpdF/LEBOZHmNbAOTTXYRLN4IA8RVATfT83/IhVSU/U9U6bkEQ== X-Google-Smtp-Source: AMsMyM7RNvqCOGo2MGqpJjfs8DZWgtoWCRFRyTfRUudqIxT42vWiYJ/jK7vdO0mXsvrEyM4N+TWUagFhSRpb0ebCZJU= X-Received: by 2002:a05:6402:2687:b0:45d:3a94:348f with SMTP id w7-20020a056402268700b0045d3a94348fmr11147274edd.48.1666026248878; Mon, 17 Oct 2022 10:04:08 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 17 Oct 2022 11:03:57 -0600 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: Michael Schuster , FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000c05b6305eb3df67c" X-Rspamd-Queue-Id: 4MrjyL1yMTz3c0F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=it22lOkb; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000c05b6305eb3df67c Content-Type: text/plain; charset="UTF-8" On Mon, Oct 17, 2022 at 7:26 AM Jan Schaumann wrote: > Michael Schuster wrote: > > > On Mon, Oct 17, 2022, 04:10 Jan Schaumann > wrote: > > > > I've observed that trying to set the date _very_ far > > > in the future causes my FreeBSD AWS instance to become > > > unresponsive and requiring a forced reboot to come > > > back. (I don't see an actual kernel panic, however.) > > > > > > > A few questions that come to mind: > > - Which version of FreeBSD? > > - which architecture (I know nothing of AWS, perhaps that's implied)? > > This was on AMI ami-00e91cb82b335d15f, from the > official 13.0R announcement, amd64. > > > - have you tried this on a different platform (a VM or real HW)? > > No, I don't have those immediately available. > > But I just now tried on ami-0cf377776fddcf8ba, which > is amd64 / 13.1R, where setting the date to > 44093078356492800 succeeds. However, there the > problem appears at 49282253052249598 epoch: > > > # date -f "%s" 49282253052249598 > Fri Dec 31 23:59:58 UTC 1561694399 > # date -f "%s" 49282253052249599 > Fri Dec 31 23:59:59 UTC 1561694399 > [ reboots ~three seconds later ] > > I see a message in the logs that dhclient core dumped: > > Jan 1 00:00:14 freebsd kernel: pid 499 (dhclient), > jid 0, uid 0: exited on signal 6 (core dumped) > > but that doesn't directly lead to the system > rebooting. > > What's funny is is that after setting the date to > 49282253052249598, it will continue to run just fine, > even as the time advanced beyond the time at which it > reboots when explicitly set. > > > Out of curiosity: why? :-) > > Exactly that: out of curiosity. :-) > > > One thing I'd do in a situation like this is display the numbers in hex, > > that may give you a clue. > > In this case, I think the numbers point to the > tm_year, as in both cases it's at the year end, it > seems to me. > We do know that if the year (tm_year) overflows an int (32-bit signed), we'll have problems. It would be approximately year 2,147,483,648 (since I think the limitation is signed, not unsigned, but if unsigned it's 4294967296 instead). Anything beyond that we know definitely won't work. Why we fall short and "only" make it to year 1.561,694,399, I don't know the root cause of. It's not even a nice, round multiple of the above... Warner --000000000000c05b6305eb3df67c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 17, 2022 at 7:26 AM Jan S= chaumann <jschauma@netmeister= .org> wrote:
Michael Schuster <michaelsprivate@gmail.com> wrote:

> On Mon, Oct 17, 2022, 04:10 Jan Schaumann <jschauma@netmeister.org> wrote:=

> > I've observed that trying to set the date _very_ far
> > in the future causes my FreeBSD AWS instance to become
> > unresponsive and requiring a forced reboot to come
> > back.=C2=A0 (I don't see an actual kernel panic, however.) > >
>
> A few questions that come to mind:
> - Which version of FreeBSD?
> - which architecture (I know nothing of AWS, perhaps that's implie= d)?

This was on AMI ami-00e91cb82b335d15f, from the
official 13.0R announcement, amd64.

> - have you tried this on a different platform (a VM or real HW)?

No, I don't have those immediately available.

But I just now tried on ami-0cf377776fddcf8ba, which
is amd64 / 13.1R, where setting the date to
44093078356492800 succeeds.=C2=A0 However, there the
problem appears at 49282253052249598 epoch:


# date -f "%s" 49282253052249598
Fri Dec 31 23:59:58 UTC 1561694399
# date -f "%s" 49282253052249599
Fri Dec 31 23:59:59 UTC 1561694399
[ reboots ~three seconds later ]

I see a message in the logs that dhclient core dumped:

Jan=C2=A0 1 00:00:14 freebsd kernel: pid 499 (dhclient),
jid 0, uid 0: exited on signal 6 (core dumped)

but that doesn't directly lead to the system
rebooting.

What's funny is is that after setting the date to
49282253052249598, it will continue to run just fine,
even as the time advanced beyond the time at which it
reboots when explicitly set.

> Out of curiosity: why? :-)

Exactly that: out of curiosity. :-)

> One thing I'd do in a situation like this is display the numbers i= n hex,
> that may give you a clue.

In this case, I think the numbers point to the
tm_year, as in both cases it's at the year end, it
seems to me.

We do know that if the yea= r (tm_year) overflows an int (32-bit signed), we'll
have prob= lems. It would be approximately year=C2=A02,147,483,648 (since I think
the limitation is signed, not unsigned, but if unsigned it's=C2= =A04294967296 instead).
Anything beyond that we know definitely w= on't work. Why we fall short
and "only" make it to = year 1.561,694,399, I don't know the root
cause of. It's = not even a nice, round multiple of the above...=C2=A0

<= div>Warner
--000000000000c05b6305eb3df67c-- From nobody Mon Oct 17 18:05:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrlJh0ZGFz4b5M5 for ; Mon, 17 Oct 2022 18:05:08 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrlJg0rCwz3kTP for ; Mon, 17 Oct 2022 18:05:07 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: by panix.netmeister.org (Postfix, from userid 1000) id C75D085851; Mon, 17 Oct 2022 14:05:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2022; t=1666029906; bh=vkX+HjP6ttG7aLGuECzOG5ii3aDbJlwni8N49cjZGGg=; h=Date:From:To:Subject:References:In-Reply-To; b=0jkBzaxx3MIKc9giUTFwqSS50pgRsfvH8/mJI3Kbt49sVuKQPszGouK27PAt6UzQn PFbf0gzZm6jFWVD1s+CLpH1nxo69aD1I2PeY+3jDtf8SJeEmRH0j6my8BWDKzKQbH7 Zd9oUnOyu5ORpH4y5qqzC6tS5EuRVKsvLqgYvXRjSGm8z8pW4WY7vE/D8lP6U82qYP hdYHppiOiHxCQIvumINrC/rCuSUZEZAxDSN/uXmT/LvwXfrUpg/53ROWX1yRULeVsV RUTGtMawZo27kd0RfYOF6gzEx8HzsP5gChNj1N1SB/QE16qMyvXCSNB0AYix8Rrui1 czXNjhwEpE4Mw== Date: Mon, 17 Oct 2022 14:05:05 -0400 From: Jan Schaumann To: freebsd-hackers@freebsd.org Subject: Re: host unresponsive when setting time very far in the future Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4MrlJg0rCwz3kTP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netmeister.org header.s=2022 header.b=0jkBzaxx; dmarc=pass (policy=quarantine) header.from=netmeister.org; spf=pass (mx1.freebsd.org: domain of jschauma@netmeister.org designates 166.84.7.99 as permitted sender) smtp.mailfrom=jschauma@netmeister.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[netmeister.org,quarantine]; R_DKIM_ALLOW(-0.20)[netmeister.org:s=2022]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[netmeister.org:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > We do know that if the year (tm_year) overflows an int (32-bit signed), > we'll > have problems. It would be approximately year 2,147,483,648 (since I think > the limitation is signed, not unsigned, but if unsigned it's 4294967296 > instead). Right, though since tm_year is defined as "year ­ 1900", I'd expect to be able to reach 12/31 23:59:59 in 2,147,485,547, as on e.g., NetBSD and Linux: netbsd$ date -r 67768036191676799 Wed Dec 31 23:59:59 UTC 2147485547 linux$ date --date '@67768036191676799' Wed Dec 31 11:59:59 PM UTC 2147485547 But FreeBSD: freebsd$ date -r 67768036191676799 date: invalid time freebsd$ date -r 67767976233532799 Tue Dec 31 23:59:59 UTC 2147483647 Kinda unclear to me how FreeBSD ended up with a tm_year value that's not 1900 based here? > Anything beyond that we know definitely won't work. Why we fall short > and "only" make it to year 1.561,694,399, I don't know the root > cause of. It's not even a nice, round multiple of the above... Regardless of the root cause, though, I think something somewhere should return EINVAL before the system freaks out. :-) -Jan From nobody Mon Oct 17 18:42:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mrm7g6SPdz4f8fS for ; Mon, 17 Oct 2022 18:42:23 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrm7f71W3z3rZB for ; Mon, 17 Oct 2022 18:42:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-vs1-f51.google.com with SMTP id k6so12473294vsp.0 for ; Mon, 17 Oct 2022 11:42:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xQ7cCvcQvA+TaTjFwM28rdjfQ/oO/dSVwMp328i3A60=; b=hps+JD/2p7ajX+yJfGuT9CqhaPwUvqF6qdLghql7Vl0vI4g1XhNs5TMs1uBrVtkwlW ISAjiVg0jsYeiJv1+aomSPf0F/XgoIN+FdyC7dZIYbraWPPdZb5b5i8id+RcZrhpb0KE hEX6LCZJhIUR0bGxohN2cpgZnjc2jUqwI5Y6xZlwT4ZF54oPjNSZE+fh9zT9YBI602aa 38/+jagYgMBIOiJP3tbgdLXvlrnqPklONveucvRoPjl+p4eQa4tjgC3pVkQCqIWehjYj EAwAlRFvNucx/HUkU5noml3ZiC/IUWiVBi1BxFZPirndimkvNIQxrAFClIyeCdcHMWd4 mpgw== X-Gm-Message-State: ACrzQf2hXXIr2U8e1rkAGWodQNu7c3fWiEt0I6FOujtjIGrWvPkI1Ryn a1TZX2NipY8kBanmHvSk8t2AoWPtujEKOtmGhn5Wxts7f9I= X-Google-Smtp-Source: AMsMyM474NPBEB0bFimTaSr0giSmERsicaEhwTiEVxc16R7wAipqSrifxmY45GpYNte7IMLuSa6phJDnVKROCRdtH7s= X-Received: by 2002:a67:b303:0:b0:3a9:61e4:2769 with SMTP id a3-20020a67b303000000b003a961e42769mr4236280vsm.0.1666032141280; Mon, 17 Oct 2022 11:42:21 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Mon, 17 Oct 2022 12:42:09 -0600 Message-ID: Subject: Re: host unresponsive when setting time very far in the future To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Mrm7f71W3z3rZB 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.217.51 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.928]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.217.51:from]; DMARC_NA(0.00)[freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.217.51:from]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[asomers]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 17, 2022 at 12:05 PM Jan Schaumann wr= ote: > > Warner Losh wrote: > > > We do know that if the year (tm_year) overflows an int (32-bit signed), > > we'll > > have problems. It would be approximately year 2,147,483,648 (since I th= ink > > the limitation is signed, not unsigned, but if unsigned it's 4294967296 > > instead). > > Right, though since tm_year is defined as "year =C2=AD > 1900", I'd expect to be able to reach 12/31 23:59:59 > in 2,147,485,547, as on e.g., NetBSD and Linux: > > netbsd$ date -r 67768036191676799 > Wed Dec 31 23:59:59 UTC 2147485547 > > linux$ date --date '@67768036191676799' > Wed Dec 31 11:59:59 PM UTC 2147485547 > > But FreeBSD: > freebsd$ date -r 67768036191676799 > date: invalid time > freebsd$ date -r 67767976233532799 > Tue Dec 31 23:59:59 UTC 2147483647 > > Kinda unclear to me how FreeBSD ended up with a > tm_year value that's not 1900 based here? > > > Anything beyond that we know definitely won't work. Why we fall short > > and "only" make it to year 1.561,694,399, I don't know the root > > cause of. It's not even a nice, round multiple of the above... > > Regardless of the root cause, though, I think > something somewhere should return EINVAL before the > system freaks out. :-) > > -Jan Definitely. And the place that should do it is clock_ts_to_ct, where the assertions were added in git rev 90a79ac5765 . They should be converted from assertions into EINVALs. -Alan From nobody Mon Oct 17 19:11:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrmnS5CGmz4fCv3 for ; Mon, 17 Oct 2022 19:11:40 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: from panix.netmeister.org (panix.netmeister.org [166.84.7.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrmnS1399z3tlD for ; Mon, 17 Oct 2022 19:11:40 +0000 (UTC) (envelope-from jschauma@netmeister.org) Received: by panix.netmeister.org (Postfix, from userid 1000) id 706B285851; Mon, 17 Oct 2022 15:11:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=netmeister.org; s=2022; t=1666033899; bh=Jn0BBs4KEnD8aj5c0iu1qyRq3uJJwohp3lbGQjmbHL8=; h=Date:From:To:Subject:References:In-Reply-To; b=fLmFlEdqbKKipVJtMLEUG4oTSCqAHT6d8sjKDWKIMIjoNM6o+NW/ITr0kovHikNL7 gkz9p+IXx8xJoe21cuUH15bRyKtplNINq+RNiEVfqYhEr7V42WiNsqE5Ah8GQs5Q7F prsBQp8d5kpg5J2b243LWh0wg9dyeXgn17ji/tKZgfG4RmcnO3lHVqVIASk6MN+X1M atAz2C9Q7+NvxT9TAh+4c9ZdyAZU90D3ZwBUCtL7/o9Mp3mLhQkcA/VlxzLSMqEafe sL+B6kRMqog1zB7aET3KK8uuJQvmhcnZ3RjXjCc3auK5wQ3EN6x4wIZ797v2vcYibM y8CnV2BCqpZuA== Date: Mon, 17 Oct 2022 15:11:39 -0400 From: Jan Schaumann To: freebsd-hackers@freebsd.org Subject: Re: host unresponsive when setting time very far in the future Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4MrmnS1399z3tlD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netmeister.org header.s=2022 header.b=fLmFlEdq; dmarc=pass (policy=quarantine) header.from=netmeister.org; spf=pass (mx1.freebsd.org: domain of jschauma@netmeister.org designates 166.84.7.99 as permitted sender) smtp.mailfrom=jschauma@netmeister.org X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[netmeister.org,quarantine]; R_DKIM_ALLOW(-0.20)[netmeister.org:s=2022]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[netmeister.org:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Alan Somers wrote: > On Mon, Oct 17, 2022 at 12:05 PM Jan Schaumann wrote: > > Regardless of the root cause, though, I think > > something somewhere should return EINVAL before the > > system freaks out. :-) > Definitely. And the place that should do it is clock_ts_to_ct, where > the assertions were added in git rev 90a79ac5765 . They should be > converted from assertions into EINVALs. I've opened https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267157 for this. -Jan From nobody Mon Oct 17 22:33:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrsG00Mbcz4fw7b for ; Mon, 17 Oct 2022 22:33:12 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrsFz24PSz4JDn for ; Mon, 17 Oct 2022 22:33:11 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-qt1-x82d.google.com with SMTP id cr19so5418946qtb.0 for ; Mon, 17 Oct 2022 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=AeAYBitEidrB36GI8XYTy+Sn4BADB/+AvsV165b42+o=; b=FHI9Ry+TYbzSOt9gjCjM0m2m/8vDnQtnsi3kbz4dzwd9Vw+j5pyVzBNArdAQS4opFg IXywr3gXYdmsH3nQc4oJvC107qsvhLhjYT0NmXgxaEeXE8jAG23xgNH6C7cmLX3xSHzJ vEK/KkF3UOl2DGcI6o4DrzmPCdO563K/RoIxq03DFeF8599axbtzoHKDv46ySvqsHWKw z52yjzQ3pTkbEKAptYy46txgrUtA+Eg/ohuIInxE//jjUF0jW9SfCn0WHFOJAwK0B/bl heAofNuGQnYIQHxerXssqHmOxwkcV1T1uzt/G7tZRjDfHzZxOUJf5+UG7rsCFvqItixL jfMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=AeAYBitEidrB36GI8XYTy+Sn4BADB/+AvsV165b42+o=; b=QMA6nP1n2jOFNn3BzwOJdd9E5KOVl0qxZmhyTN1nCM5EgGZTQgQMPHnO9Kp9QePIAn Dfd9BXuwrShCNhdWq1XXhvZp9j2fvNZOKQoWwvv4faLq9kvYc7e13sbVpflRkjSLAU4/ Ekz5VX6hbru1zpcdCfOi45MtZnhAGL5NLn2JKZWIbly1h73effSFs4PWWTFreBykq26d dSc6qSdT2EvLEkB71dxiDTRc5TKKjtYQUgT/T1bW2TuOCn2i+jc1J3v5Oj7D4f5n/ojw qGvfjmHkmqu8R9QfBVHP2XD2vkzHrmURrZerGmtR9ELe6rfMudamg4j+3u49The3jvW4 tLfw== X-Gm-Message-State: ACrzQf0XeeoVzfi2g4RT8s/j678XYUoXWWercdFZ/9QKH6yZMPESm8Dn rA/tsKyKd+OJgReiykAU7RZtXxBMXf346w== X-Google-Smtp-Source: AMsMyM6CtkNzhfpnILOjgpX60Rg4stE1+vcKzPCBbfYvHiVAolyJv2W01DcbeicoBgiDf8u/X/jpaQ== X-Received: by 2002:ac8:7f06:0:b0:35c:f532:3346 with SMTP id f6-20020ac87f06000000b0035cf5323346mr10797683qtk.316.1666045990072; Mon, 17 Oct 2022 15:33:10 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id v21-20020a05620a441500b006cbe3be300esm899104qkp.12.2022.10.17.15.33.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2022 15:33:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: VFS mount rollback for virtio 9pfs From: Bakul Shah In-Reply-To: <3E450927-1932-412E-A568-A2F84582BD26@dons.net.au> Date: Mon, 17 Oct 2022 15:33:07 -0700 Cc: Felix Palmen , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C98D486-6A8F-4DF6-8AFF-F3B84E631A84@iitbombay.org> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> <3E450927-1932-412E-A568-A2F84582BD26@dons.net.au> To: Daniel O'Connor X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MrsFz24PSz4JDn X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=FHI9Ry+T; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2607:f8b0:4864:20::82d as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82d:from]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[bakul]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[iitbombay.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Oct 13, 2022, at 6:01 PM, Daniel O'Connor wrote: >=20 > It's come to my attention that someone else also ported this: > https://github.com/swills/virtfs-9p-kmod >=20 > I was wondering if you would be interesting in trying and seeing how = it fairs. Unfortunately I am not in a position to do a test poudriere = with it as yet. FWIW I played with swills port a few months ago. It worked on -12 but failed on -13 and -current (panics on kldload). I didn't investigate it further. Tested in bhyve. Note that bhyve on 13.1-stable does work with a linux guest: ubuntu# mount -t 9p -o trans=3Dvirtio,version=3D9p2000.L,rw,cache=3Dmmap = sharename /opt ubuntu# dd < largefile >/dev/null bs=3D1M count=3D1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.65227 s, 287 MB/s I took your port & copied relevant files to a -current tree (8cee2ebac54a). I had to hack a few things to compile[1]. kldload doesn't crash as with swills port but mount fails: # mount -t virtio -o trans=3Dvirtio sharename /mnt mount: sharename: Operation not supported by device Note that the same line works fine on -12, with swill's changes. Relevant bhyve line: -s 8,virtio-9p,sharename=3Dmydir \ Given that mount on ubuntu works seems the problem must be elsewhere and not 9p2000.L vs 9p2000.u (as you surmised in the original msg in this thread). I even changed code in the driver to unconditionally pass 9p2000.L but that didn't help. [1] Fixed up module Makefiles and had to add=20 #define SAVENAME 0x00000400 /* save pathname buffer */ to 9pfs/virtiofs_vnops.c As only this define from namei.h seemed to be somehow lost. From nobody Mon Oct 17 23:07:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mrt26459Lz4g0XX for ; Mon, 17 Oct 2022 23:07:58 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mrt255BHJz4Ljf for ; Mon, 17 Oct 2022 23:07:57 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-35ceeae764dso121952637b3.4 for ; Mon, 17 Oct 2022 16:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/08S024Hh6P0lXYpC+H/xKFNBsYTIurt9TVTyMM/vJI=; b=FVL280aF5/bFyf1n/qEQ0WbqA3qTzyFbTGD1ENPd4YC+8RYRC2ZJuNnUGGvbXJjC30 jhOlTyIOx9igLmE55oiYutf+AWMw6s0W/YCdV8+w73clU12wjROKxPxqoFN6nx8CkJZ2 6L4Mgl2F32I4fB2hq2f7LP3zP/njBpZ+ynhHCV7kdgZBXBzWu6vPgjujJB837ub6IhNQ PqoE3V6L7cZmmscyJb0zMAOXFHT5y6WQnIrz0urpSkG8LG0NEeJrZ4+r1XvCVngVLJ+p 1E4AHiv5Kpc67gNmqqHxrNiuXYQCwR/aA0mUGSHgjhN873zVOYUYbyOIfddMLrLgepbo lETg== X-Gm-Message-State: ACrzQf3aSdXjucgy7CNdvIXf0EdRnSNK5gdNj6hdWUJYJy1akriIFzct /gaXCe63E/fPK+52bovegzMQbjfA/GkYvUROs60= X-Google-Smtp-Source: AMsMyM6FfbkMeqXLlDn62Qt28iN31y7NsnF8U7SVeo7Nl+TwEAZcT5aVYnetqouJkimhK37o4Hq12fzk35Gnkdp82Go= X-Received: by 2002:a81:4f84:0:b0:358:1be1:8fd2 with SMTP id d126-20020a814f84000000b003581be18fd2mr142861ywb.32.1666048075688; Mon, 17 Oct 2022 16:07:55 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> <3E450927-1932-412E-A568-A2F84582BD26@dons.net.au> <0C98D486-6A8F-4DF6-8AFF-F3B84E631A84@iitbombay.org> In-Reply-To: <0C98D486-6A8F-4DF6-8AFF-F3B84E631A84@iitbombay.org> From: Navdeep Parhar Date: Mon, 17 Oct 2022 16:07:44 -0700 Message-ID: Subject: Re: VFS mount rollback for virtio 9pfs To: Bakul Shah Cc: "Daniel O'Connor" , Felix Palmen , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Mrt255BHJz4Ljf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-2.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.93)[-0.929]; FORGED_SENDER(0.30)[np@freebsd.org,nparhar@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.177:from]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[np@freebsd.org,nparhar@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.177:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Oct 17, 2022 at 3:33 PM Bakul Shah wrote: > > On Oct 13, 2022, at 6:01 PM, Daniel O'Connor wrote: > > > > It's come to my attention that someone else also ported this: > > https://github.com/swills/virtfs-9p-kmod > > > > I was wondering if you would be interesting in trying and seeing how it fairs. Unfortunately I am not in a position to do a test poudriere with it as yet. > > FWIW I played with swills port a few months ago. It worked on -12 but > failed on -13 and -current (panics on kldload). I didn't investigate > it further. Tested in bhyve. I tried the github.com/swills/virtfs-9p-kmod repository very recently and had better luck with it. I had to make these changes to the code to get it to compile on latest main: https://people.freebsd.org/~np/9pfs/ After that I was able to mount /usr/{src,obj} read-only in the FreeBSD VM. I've done a number of installworld/installkernel inside the VM since then without any apparent problems (except the warnings about read-only /usr/src during installkernel -- those have nothing to do with 9pfs) These are the entries in the vm.conf file on the host that export these directories (I use vm-bhyve): disk2_type="virtio-9p" disk2_dev="custom" disk2_name="src=/usr/src,ro" disk3_type="virtio-9p" disk3_dev="custom" disk3_name="obj=/usr/obj,ro" This is what I have in the VM's /etc/fstab: src /usr/src virtfs trans=virtio,ro,late 0 0 obj /usr/obj virtfs trans=virtio,ro,late 0 0 This in /etc/rc.conf in the VM: kld_list="virtio_9pfs" Regards, Navdeep > > Note that bhyve on 13.1-stable does work with a linux guest: > ubuntu# mount -t 9p -o trans=virtio,version=9p2000.L,rw,cache=mmap sharename /opt > ubuntu# dd < largefile >/dev/null bs=1M count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.65227 s, 287 MB/s > > I took your port & copied relevant files to a -current tree > (8cee2ebac54a). I had to hack a few things to compile[1]. kldload > doesn't crash as with swills port but mount fails: > > # mount -t virtio -o trans=virtio sharename /mnt > mount: sharename: Operation not supported by device > > Note that the same line works fine on -12, with swill's changes. > > Relevant bhyve line: > -s 8,virtio-9p,sharename=mydir \ > > Given that mount on ubuntu works seems the problem must be elsewhere > and not 9p2000.L vs 9p2000.u (as you surmised in the original msg in > this thread). I even changed code in the driver to unconditionally > pass 9p2000.L but that didn't help. > > [1] Fixed up module Makefiles and had to add > #define SAVENAME 0x00000400 /* save pathname buffer */ > to 9pfs/virtiofs_vnops.c > > As only this define from namei.h seemed to be somehow lost. > > > > > > From nobody Mon Oct 17 23:27:12 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrtSN2JWXz4g2SX for ; Mon, 17 Oct 2022 23:27:16 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrtSM2grLz4N1D for ; Mon, 17 Oct 2022 23:27:15 +0000 (UTC) (envelope-from bakul@iitbombay.org) Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-132fb4fd495so15013348fac.12 for ; Mon, 17 Oct 2022 16:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iitbombay-org.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wUTKYxZhZEIBLHGcAuTnyQTpapOLmcrLkpLTmVlsmM8=; b=oFs50UkDYzUK9mPuDrW4QYBDfGxr3rzpgeZanNUSjs5bXgHH752wRBfOEonb8ZNrVG QjYyMV1bTD7Monpq+E846UUcRuRm/2PoIqeneTzXB12j4zHlVa78/MhynhwVM4LVPnlD YMQs3GjaazSMgRQm6mQyJXouQIrCSrvfyIfab3YgFX/xM+iYn4S7LLNDYhdsIKS2snfx oPfLJpsvSNspIcx+R6M86ya/9VDjPuC9NKO6MV17IyMNGstw9jgER2j0+D90OzFB7L3o ZlMgb1H/bjm/B01e36T8b14rl7Hs2mSDyzpVxCyGvEisyLk/MRWu/aQMAbsxwfamC5fV dc3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wUTKYxZhZEIBLHGcAuTnyQTpapOLmcrLkpLTmVlsmM8=; b=av4FUiA0EPQ4F9i0BQOpTOYsYmmd6yhXPCGiI1hPH1pfq95w41vYe1BNModsVWIT0J 85yZgTshLS/9NSpGPpTgFZW4F34Y3mTxNZId4CTCi9/l+MmXW6pjCYm+5rKADg9zaWBJ 4NPrRaVLyZEYzv0Fns0YPa7eovRnRo+BUewToF+hluc1HWGVOBo+bPTj/cVlN4k2HvUr HQ1QkYjtADkGxWcUjiBmPv8h/quQkKeTdZiJmh/6i/wf21+BrtJKVcMxeOP1MTsTlbJ1 Q5iYYcza8WtZZmk7/w2Lg5B8CwHt5mrMSrj58uTXkBo+p01ZYLoGuPh7wj3Ztqqk6XxJ OK/Q== X-Gm-Message-State: ACrzQf3AFnoZVGYjyfeMMvv6fFl11byRTCgkdQ0NJCYEaB/arDGS3fxL 9gyv6usYK6QFll0G2L8cSBL3rQ== X-Google-Smtp-Source: AMsMyM7QBkF+C0lo5aH16R29pKbrguCDxI7NOK4oQTc0OcLs5QkGYUiBjpmeW43gchr/vaHOH8QIvA== X-Received: by 2002:a05:6870:d78c:b0:136:ddfe:bf16 with SMTP id bd12-20020a056870d78c00b00136ddfebf16mr54603oab.86.1666049233806; Mon, 17 Oct 2022 16:27:13 -0700 (PDT) Received: from smtpclient.apple (107-215-223-229.lightspeed.sntcca.sbcglobal.net. [107.215.223.229]) by smtp.gmail.com with ESMTPSA id y20-20020a4a6254000000b0047f89d8c7ebsm4780899oog.46.2022.10.17.16.27.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2022 16:27:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: VFS mount rollback for virtio 9pfs From: Bakul Shah In-Reply-To: Date: Mon, 17 Oct 2022 16:27:12 -0700 Cc: Daniel O'Connor , Felix Palmen , freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <2338B575-4804-4D2D-A4EF-9D234D71481A@iitbombay.org> References: <75ACE8B8-A41F-4742-95DA-3CFB3B97746A@dons.net.au> <20220714101214.sju2rpsngqjyuvsb@nexus.home.palmen-it.de> <20220715131656.f2epy732npgbgrf5@nexus.home.palmen-it.de> <20220715151509.d2v6kqkjsnrxtprj@nexus.home.palmen-it.de> <45451C7B-7A12-420F-B6B0-19F2FA98D056@dons.net.au> <20220718065304.cx2o24tshzgpxmqw@nexus.home.palmen-it.de> <3E450927-1932-412E-A568-A2F84582BD26@dons.net.au> <0C98D486-6A8F-4DF6-8AFF-F3B84E631A84@iitbombay.org> To: Navdeep Parhar X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MrtSM2grLz4N1D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=iitbombay-org.20210112.gappssmtp.com header.s=20210112 header.b=oFs50UkD; dmarc=none; spf=pass (mx1.freebsd.org: domain of bakul@iitbombay.org designates 2001:4860:4864:20::32 as permitted sender) smtp.mailfrom=bakul@iitbombay.org X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[iitbombay-org.20210112.gappssmtp.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::32:from]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[iitbombay-org.20210112.gappssmtp.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[bakul]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[iitbombay.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Oct 17, 2022, at 4:07 PM, Navdeep Parhar wrote: > > This is what I have in the VM's /etc/fstab: > src /usr/src virtfs trans=virtio,ro,late 0 0 > obj /usr/obj virtfs trans=virtio,ro,late 0 0 Thanks for listing this as it made me realize my mistake! I typed "-t virtio" and was too tired to notice I should've used "-t virtfs" with mount. Daniel's code works fine! # mount -t virtfs -o trans=virtio sharename /mnt $ dd < largefile > /dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 6.566231 secs (159692211 bytes/sec) From nobody Tue Oct 18 03:25:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MrzlZ00n9z4fZ9Z for ; Tue, 18 Oct 2022 03:25:46 +0000 (UTC) (envelope-from rickywu0421@gmail.com) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MrzlX6R1nz3QkH for ; Tue, 18 Oct 2022 03:25:44 +0000 (UTC) (envelope-from rickywu0421@gmail.com) Received: by mail-io1-xd31.google.com with SMTP id l127so10760487iof.12 for ; Mon, 17 Oct 2022 20:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=oJbE57uzjHax8tHpIosAtkTQsNRBwu91jNe/uPbikIU=; b=omRvuhRoIauKhWa82bB9tzefhwnES28CwUDIrR9GD7NXq4F3bIVM5gU+UT0x0kJa2+ 8cjf8dbZJFdvL7MyP41wheuj6rSSA3+fsJbRhbm1Itqu+P8tO16W7nUam57tGbvqjnGk 8leuHQPi4ztK9XFljYY/E9vlsXi5xJKl0HOSeEd+p6ItpBQeeXO3M4rrRXaITA1txQUU 7i0jGrE+ce4b0VpgUxKmPTGhtYqjMh8rtUsMJGNjxluogcRDpHD3pv956ANNOgzYpQa0 fFPEPJDgSQzMEGQkqSeWLO8PPZE/xq0yw3UePFydnMfzkvkE+mUjlb+VXmWI3POhyxKQ TU+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=oJbE57uzjHax8tHpIosAtkTQsNRBwu91jNe/uPbikIU=; b=DjNCfMbtLmJDQ3PlfOmiA+zWCAPFEu/FobVyTtm00IcwxY1x1JWF4bWoSf27WuD7WE 4RmJmhWu/I75QzCUPZPYu3kI3puR5aMd8YlKlkLglEntXB3YiC+UoBPLxg/323cupCIH UmBDu+fppTtYb+MCksNJFS9r62dx49pIM17cpoZJrNrUDHoDCHU+pbJwKgf2d8zsd7ib vT1XzwMOuh5oJitSY7WlYNj4aH283V2EarP1Gv2V1lq8WqX6Qa8SQYEZJ0tGnj0AjaLI zxr7WAJ/ASHqisdGLlKyy6V4Jwb7ZgoOvYeAwhpTyWpM+LByACA29y52NcJFuEgf07lN 2TOQ== X-Gm-Message-State: ACrzQf2TO1PUC+UDYkKwZxS19x77JHZDcgjIXus2ohLuH5nuvUTQjxaA CMKe/+pwvBeTKqqP3YA3DGXBhYkZyh26+8ul908pBI51LESLhg== X-Google-Smtp-Source: AMsMyM5oyHsIv5yvE0iFIxBfIQbbxEANul3iqaTrRjhrYQEC2C9PhPbY4+6rx98Rcx14yxUw7mE/6RN149DmO7EYy8M= X-Received: by 2002:a05:6602:1409:b0:6a4:cef3:ea7f with SMTP id t9-20020a056602140900b006a4cef3ea7fmr817334iov.41.1666063543937; Mon, 17 Oct 2022 20:25:43 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?5ZCz5oGp57ev?= Date: Tue, 18 Oct 2022 11:25:30 +0800 Message-ID: Subject: ifconfig(8) IEEE802.11 SSID format To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000b5b39905eb46a520" X-Rspamd-Queue-Id: 4MrzlX6R1nz3QkH X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=omRvuhRo; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rickywu0421@gmail.com designates 2607:f8b0:4864:20::d31 as permitted sender) smtp.mailfrom=rickywu0421@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d31:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --000000000000b5b39905eb46a520 Content-Type: text/plain; charset="UTF-8" Currently `ifconfig wlanX scan` will show SSID in hex when the scanned SSID is non-printable. And the non-printable character is when the character with value < 32 or value >= 126 in ifconfig(8)'s implementation. That leads to a problem that other languages using UTF-8 or other encoding will be treated as non-printable in ifconfig(8), thus not printed on screen. Here is the possible way to solve the problem: When a SSID is going to be printed, copy the byte stream (uint8_t *) into wide character stream (wchar_t *), and use libc iswprint(3) to check whether characters are printable or non-printable. I have tested this and it is workable when the locale is correctly set. --000000000000b5b39905eb46a520 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently `ifconfig wlanX=C2=A0scan` will show SSID in hex= when the scanned SSID is non-printable. And the non-printable character is= when the character with value < 32 or value >=3D 126 in ifconfig(8)&= #39;s implementation. That leads to a problem that other languages using UT= F-8 or other encoding will be treated as non-printable in ifconfig(8), thus= not printed on screen.=C2=A0

Here is the possible way t= o solve the problem:
When a SSID is going to be printed, copy the= byte stream (uint8_t *) into wide character stream (wchar_t *), and use li= bc iswprint(3) to check whether characters are printable or non-printable. = I have tested this and it is workable when the locale is correctly set.
--000000000000b5b39905eb46a520-- From nobody Tue Oct 18 07:17:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ms4vc66kRz4gHV4 for ; Tue, 18 Oct 2022 07:18:04 +0000 (UTC) (envelope-from rickywu0421@gmail.com) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ms4vb5LKQz3knf for ; Tue, 18 Oct 2022 07:18:03 +0000 (UTC) (envelope-from rickywu0421@gmail.com) Received: by mail-io1-xd2f.google.com with SMTP id b79so10891360iof.5 for ; Tue, 18 Oct 2022 00:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=JxG6BQ2cSx0BUaDnxqn3yfQd1HPBIY7Ke6/uNdw3Ahc=; b=phmCuF1Ig88kcRJxP2uSOGxFpsF+Y5JShPbmR4dShI7AYNjVU+lu43U6LtjMOoRaov xEq8uk71FANbwAyo68Azj9rnR3vgiGAfzjkyRpqd6c+SRtZvwCUnc2oEHcr2imAXH7XE AVPjowZCLUxIpxyDzYXMc4FsSxQgt7TDMf90nYM5JNgOUcvSbZeiHWt9uRSkvHOdSMxT iCJQwPD9uZvsD1lxLmcCc1w0+Xc4Fi/BFsA6SSbclugAgt6lsQmSKTXTGQSz+tDO/5Ch 9vXPiNd4k/TvY/VFqIBVwluQxFrHmC6FtabkjQfInt0IL4MqqcT/h4PHB1PHnWnI+5DG AbtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JxG6BQ2cSx0BUaDnxqn3yfQd1HPBIY7Ke6/uNdw3Ahc=; b=Q1bmN9A24GInbuIgKlhbGutXxkelubHwM0l/pIrxK43Z++jeCfkKp0pY4IU7Wdqovm LJRUk3QJ1Np9XxLFX9pLU/2TeuyvMtWDnIsdtht33pvMEVy1glUQkc5HeU1WtAd5wQjc nJLzVHI4Xpai7fxk/QEgqEDLiguwFkblSaz5hk2txASM7LK5RL9FLQNcXacgafQqCKk1 pJu+Z5TqDjNm1OCJEVzcLJV/yyXk0z9DjeRqTlbPWOH2aaC81H8MLnT32dKOf4+X+6+I YAz5pb2ZjJmWpAWP9X8Nit1SntxtDbq8NoqqskYKC2A+bPTTBImNjRcZfGNgEeaFVJTu OiPQ== X-Gm-Message-State: ACrzQf214n/KoP866CdP7RGXzH8cFzfeX8TRmZ0VlTMI9cPYuBbFMqF0 gEAZfsaFLn+vi7eY/prZwl5nRvk22Tpv87paNojl8lDiYwY= X-Google-Smtp-Source: AMsMyM50ZaTlVx+0k716aHS6SFnnOmejkFRsOd0UyL6xog5PlTsAJtL+iofP470t6w4HbfzWwHPZpvxKpk8ichTM9OE= X-Received: by 2002:a02:ca11:0:b0:363:7710:6248 with SMTP id i17-20020a02ca11000000b0036377106248mr1227712jak.320.1666077482673; Tue, 18 Oct 2022 00:18:02 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?5ZCz5oGp57ev?= Date: Tue, 18 Oct 2022 15:17:49 +0800 Message-ID: Subject: Re: ifconfig(8) IEEE802.11 SSID format To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000085ee1c05eb49e467" X-Rspamd-Queue-Id: 4Ms4vb5LKQz3knf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=phmCuF1I; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rickywu0421@gmail.com designates 2607:f8b0:4864:20::d2f as permitted sender) smtp.mailfrom=rickywu0421@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d2f:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N --00000000000085ee1c05eb49e467 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for not explaining the whole situation. The previous email was asking for everyone about how to solve the problem explained in it, and I also introduced a way to deal with it, which may or may not be adopted. =E5=90=B3=E6=81=A9=E7=B7=AF =E6=96=BC 2022=E5=B9=B4= 10=E6=9C=8818=E6=97=A5 =E9=80=B1=E4=BA=8C =E4=B8=8A=E5=8D=8811:25=E5=AF=AB= =E9=81=93=EF=BC=9A > Currently `ifconfig wlanX scan` will show SSID in hex when the scanned > SSID is non-printable. And the non-printable character is when the > character with value < 32 or value >=3D 126 in ifconfig(8)'s implementati= on. > That leads to a problem that other languages using UTF-8 or other encodin= g > will be treated as non-printable in ifconfig(8), thus not printed on > screen. > > Here is the possible way to solve the problem: > When a SSID is going to be printed, copy the byte stream (uint8_t *) into > wide character stream (wchar_t *), and use libc iswprint(3) to check > whether characters are printable or non-printable. I have tested this and > it is workable when the locale is correctly set. > --00000000000085ee1c05eb49e467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for not explaining the whole situation.

The previous email was asking for everyone about how to solve the pr= oblem explained in it, and I also introduced a way to deal with it, which m= ay or may not be adopted.

=E5=90=B3=E6=81=A9=E7=B7=AF <rickywu0421@gmail.com> =E6=96=BC 2022= =E5=B9=B410=E6=9C=8818=E6=97=A5 =E9=80=B1=E4=BA=8C =E4=B8=8A=E5=8D=8811:25= =E5=AF=AB=E9=81=93=EF=BC=9A
Curr= ently `ifconfig wlanX=C2=A0scan` will show SSID in hex when the scanned SSI= D is non-printable. And the non-printable character is when the character w= ith value < 32 or value >=3D 126 in ifconfig(8)'s implementation.= That leads to a problem that other languages using UTF-8 or other encoding= will be treated as non-printable in ifconfig(8), thus not printed on scree= n.=C2=A0

Here is the possible way to solve the problem:<= /div>
When a SSID is going to be printed, copy the byte stream (uint8_t= *) into wide character stream (wchar_t *), and use libc iswprint(3) to che= ck whether characters are printable or non-printable. I have tested this an= d it is workable when the locale is correctly set.
--00000000000085ee1c05eb49e467-- From nobody Tue Oct 18 11:48:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsBvM1297z4fMBm for ; Tue, 18 Oct 2022 11:48:15 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsBvL2bf4z41vx for ; Tue, 18 Oct 2022 11:48:14 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x430.google.com with SMTP id a3so23114260wrt.0 for ; Tue, 18 Oct 2022 04:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=QXY4zV2mivtjer2wTk4afF5d4lW2TAdcj9u2IQm3TpU=; b=BYY0Z1szIkWISrWq4n1gN+8XCkgbCGqYVuqlo4m0NWS1OD/zOTAxPEKQ5KIgB+w+0H WvEkHBETdYVSsKjaPkUC5d8de1JuxVqJCcw/yP2ZcukhR+8jxhVlByyVw6oOvX9lsmKv n6WhaMuNV9wyYDXcvlYIf+AezHSZ7ZmVpjyWtJ0zRqSgRZ82ZB/DM7K50LS8c0dxnQxL zKKdXUPu0Y7XzQizq20Xy2aE1ekv4vCrVK2BnGoVcMTSMubfeLcagaQ22qPavSCgB8EW OIJdCw8io5GQzeHnBQC68rDgmNUGgtWYYQ+r7HQQVIDZwmDAAT3mFXaL/V8OqSrCeOxe v/ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QXY4zV2mivtjer2wTk4afF5d4lW2TAdcj9u2IQm3TpU=; b=4JLTubdtkyQATdwk1oW/5JYiWM9DiQh4VjwACPxs3FyutZ0/DrDU0rgrr4zT8uOorN bkWsdTypSjTVdjVjD3YW3NUOTrR8+7CvFWRtwYFDxubPC4BZf7WqyGdQU+BITsxu7h6j ebeOmryjN83AMzECy8XHJOeQ/eqNI6sFNVEJJ5hxHrxuJTwGJBMUzNAvD5f2kuN/Ua0A 2N4e6wyKKrBy1kss467oBQm3Kp+xvQprcHGuAVCh1eMY4PGfVm/EsEalep1uv4Ex4HHf Vzn6YTuKXFbwkEJpLbiCId1ZGq3HgE2GyEoeeg162/kPI9eMf7z2d3at7RTTgsuICrGp uVVA== X-Gm-Message-State: ACrzQf25HsnA/kn5pWTkyRYQdzjHbOsAMkix3iJvIAHPDkWAaIQsFdpv Hq5tEmqTCt7OKDcIad3nXVthdrFmfGuKpA== X-Google-Smtp-Source: AMsMyM6goccUOvoaiTLZeSjzi69vq/cWicBBWtSFBXCuEfXZ2XP7PGn3a0Rk92CiSsOiS3vHLu940w== X-Received: by 2002:a5d:6504:0:b0:22e:44b0:4cf5 with SMTP id x4-20020a5d6504000000b0022e44b04cf5mr1589665wru.362.1666093692771; Tue, 18 Oct 2022 04:48:12 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-263-217.w2-7.abo.wanadoo.fr. [2.7.103.217]) by smtp.gmail.com with ESMTPSA id a19-20020a05600c225300b003a6a3595edasm13375664wmm.27.2022.10.18.04.48.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 04:48:12 -0700 (PDT) Message-ID: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> Date: Tue, 18 Oct 2022 13:48:11 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: AMD64 14.0-CURRENT memory layout changes To: freebsd-hackers References: Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MsBvL2bf4z41vx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=BYY0Z1sz; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::430 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.929]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::430:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hi Mark > Setting kern.elf(64|32).aslr.stack to 0 should restore the old > behaviour. It should also be possible to disable this on a per-process > basis with proccontrol(1), but that doesn't appear to work, i.e., there > is a bug. However, all randomization can be disabled this way, try > "procstat -m aslr -s disable ksh93". If I turn off all aslr then I do see that the memory map reverts to the same layout as I get in 13.1. But that doesn't solve my problems. I've also seen that sysctl kern.usrstack is no longer used. On 13.1 I see PID trylock CALL __sysctl(0x7fffffffd310,0x2,0x800267c88,0x7fffffffd328,0,0) PID trylock SCTL "kern.usrstack" PID trylock RET __sysctl 0 PID trylock CALL getrlimit(RLIMIT_STACK,0x7fffffffd318) PID trylock RET getrlimit 0 PID trylock CALL thr_self(0x800a12000) PID trylock RET thr_self 0 PID trylock CALL mmap(0x7fffdfffe000,0x1000,0,0x1000,0xffffffff,0) PID trylock RET mmap 140736951476224/0x7fffdfffe000 But on 14.0 I think that this is the mmap for rtld PID trylock CALL mmap(0,0x400000,0x3,0x15001002,0xffffffff,0) PID trylock RET mmap 34372321280/0x800c00000 PID trylock CALL thr_self(0x800a12000) PID trylock RET thr_self 0 then straight to mapping the stack PID trylock CALL mmap(0x7fffdfffe000,0x1000,0,0x1000,0xffffffff,0) PID trylock RET mmap 140736951476224/0x7fffdfffe000 How is 14.0 working out what address to use for the stack? (The above is with ASLR all off) A+ Paul From nobody Tue Oct 18 12:13:46 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsCSt3CsJz4fPmN for ; Tue, 18 Oct 2022 12:13:50 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsCSs4gtBz444Q for ; Tue, 18 Oct 2022 12:13:49 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id j16so23147622wrh.5 for ; Tue, 18 Oct 2022 05:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nCIDgIZw5NSJieAqogUNjp/sBkZ8qTbP6n4EznfYacM=; b=cyJ8LFjyXhXHCJjHdI6sxUcSoQMLwopdYfH4H2u8FHbC5K4VV0DgKgl+nxWRHoPBFa 9ayKiLTcU8zCZlugnKbsZ+VF51h9RHrkQqpvpk2LemGSJR4nzBptSBoMtvGwoc5RJq+x s4QDO0pXO0zpHDggbz9oMHUBXmzrGFPePBgEJd9TwwkQ84uvGE9J9prKE+7xgKukUM9+ GKccWY2K4lib7Pwm+tYu9pJ3bQcijE/0Q5KzPPQHXAAZ0iYD7IiB0T7OAHCWn36SUtcq fS/cbdjdHvp/9+7f0WxH9mLKSL6HqQ/dbuWW5SPJB0EIi/LhAdtlLIbJxDQLkYdjBTGe yxiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nCIDgIZw5NSJieAqogUNjp/sBkZ8qTbP6n4EznfYacM=; b=aZwD/lPSrrjCpK7/BueLyM9OXU9YTPYRrSu5tQBhmdpBNY+f0+XwcWAE5k/TtFNCVf zi8R9vzyKtxHkzEfqSTQw0SW0HxCeNLYi+EnhfZNou8xScNHWKaSak7Sbl7A1v1OoyRI 1opz94r7QKikoqmsEPRTd/LHfdboVM8lChb96dQ/7/+ks6OGkXbpaMPq0079V35NxzTM d+b60kAH/ZN6GbwUp8mLOL52s+OkFhb2+fxQVonLPyMSQn8PXXTSgbgNnENgwBuCpy0w 0Leo+vKdA/+zWC+WK9IyeR0QrVerHaZ96d1pa/WWO8vd2XNZ9+lftovvdkqwyais+sM3 9MnQ== X-Gm-Message-State: ACrzQf2V86ot1t+xKB+LB9B4Ltcq1RMt+JH+wbp201Nxxyf++mIqy4ve 6XTp4aHIorjenYqllKD/VFOrf+3wciNzBw== X-Google-Smtp-Source: AMsMyM5UA8yqldnO6BPveBdJEHO+ceUbpL2bx3oobDqcrQmoSBCBBejJLIYM5QIvDv9y8lDAkz6H0A== X-Received: by 2002:a5d:6d81:0:b0:22e:6070:3c04 with SMTP id l1-20020a5d6d81000000b0022e60703c04mr1584897wrs.442.1666095228266; Tue, 18 Oct 2022 05:13:48 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-263-217.w2-7.abo.wanadoo.fr. [2.7.103.217]) by smtp.gmail.com with ESMTPSA id o13-20020a5d670d000000b0022cd0c8c696sm11087334wru.103.2022.10.18.05.13.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 05:13:47 -0700 (PDT) Message-ID: <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> Date: Tue, 18 Oct 2022 14:13:46 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: AMD64 14.0-CURRENT memory layout changes Content-Language: en-US From: Paul Floyd To: freebsd-hackers References: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> In-Reply-To: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MsCSs4gtBz444Q X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=cyJ8LFjy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > > How is 14.0 working out what address to use for the stack? > (The above is with ASLR all off) Answering my own question: it's in auxv (from __thr_get_main_stack_base) /usr/include/sys/elf_common.h:#define AT_USRSTACKBASE 35 /* Top of user stack */ I haven't yet added this (or AT_USRSTACKLIM) to the client auxv that Valgrind synthesizes. I'm still not certain that will fix it - I would have expected __thr_get_main_stack_base to fallback to using sysctl. A+ Paul From nobody Tue Oct 18 15:03:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsHFR1TZRz4g1LX for ; Tue, 18 Oct 2022 15:04:11 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsHFQ4ctzz3PTj for ; Tue, 18 Oct 2022 15:04:10 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 29IF3v2S065277; Tue, 18 Oct 2022 08:04:03 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 18 Oct 2022 08:03:57 -0700 From: Chris To: =?UTF-8?Q?=E5=90=B3=E6=81=A9=E7=B7=AF?= Cc: freebsd-hackers@freebsd.org Subject: Re: ifconfig(8) IEEE802.11 SSID format In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <961834ad41c1ba148dccfa49b626f28c@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_7e578383209e9701761ffaee294473ce" X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4MsHFQ4ctzz3PTj X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_7e578383209e9701761ffaee294473ce Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-10-18 00:17, 吳恩緯 wrote: >> Currently `ifconfig wlanX scan` will show SSID in hex when the scanned >> SSID is non-printable. And the non-printable character is when the >> character with value < 32 or value >= 126 in ifconfig(8)'s implementation. >> That leads to a problem that other languages using UTF-8 or other encoding >> will be treated as non-printable in ifconfig(8), thus not printed on >> screen. >> >> Here is the possible way to solve the problem: >> When a SSID is going to be printed, copy the byte stream (uint8_t *) into >> wide character stream (wchar_t *), and use libc iswprint(3) to check >> whether characters are printable or non-printable. I have tested this and >> it is workable when the locale is correctly set. >> > Sorry for not explaining the whole situation. > > The previous email was asking for everyone about how to solve the problem > explained in it, and I also introduced a way to deal with it, which may or > may not be adopted. > > 吳恩緯 於 2022年10月18日 週二 上午11:25寫道： > Maybe a differential[1] or a pr[2] would be in order, so that others can profit from your work here? :-) --chris 1) https://reviews.freebsd.org 2) https://bugs.freebsd.org --=_7e578383209e9701761ffaee294473ce Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_7e578383209e9701761ffaee294473ce-- From nobody Tue Oct 18 15:36:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsHyN5db7z4g42s for ; Tue, 18 Oct 2022 15:36:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsHyM4x6Yz3Sq4 for ; Tue, 18 Oct 2022 15:36:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72f.google.com with SMTP id o2so8849432qkk.10 for ; Tue, 18 Oct 2022 08:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=j/YG/3kmmxpBlPISgffCXAOeG8u1coql6maM8s2w5Z8=; b=ftCMdza/ZJpb5x1AwXEP1uVWUDvTNwybl8o9byW+swaMnnklIjcjXdmVoS7JYBKIsX 40pBX/cIuhIfUjp/aNSRCbcyh7nfE+UeNlLPkRvfQZEKTZ52E3eIUUHEIXNLStJAgGE2 LtDTj2BKqH0h4J7kE0sO57aOXdlnZCrYxtWbuQAVuafrt/iXZC2ktTvdIZiQ6l7S1IHU UL0wk1hnfLh8AdLH5OehfGcVH9HBPeYvhhoPYHXjpJO4nN6x1qR68TgT9uhffst01m99 jsOJptTyFVhNzgGrm9Qj8DlvpVWhZorkRQ9OQpA4ePpROI9ZaGD2fi2Lf0YY2DiO6EIe MLXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=j/YG/3kmmxpBlPISgffCXAOeG8u1coql6maM8s2w5Z8=; b=SplPcxqRrD5siuKIL53+57fgvdAnAC6O8QHrk3FyuSLuRLz62RlY3phEeVNPvyIEnT ZrsdADcqqUcmy4htBLbCBoBZwifi4Yzmxyn+Jb4NvxNdZW5QhwI6zQSpNKvZCNwE7pZL Ma7p5OlgpXhhtEMoYEH9VOKZPBk2OlIcSxMkcnyTI1lAn192d5QEGMfgZajKmApHRchN 5fjBI8hFHxu45+QWKP/Ay9QlghOpNmMTycSaNTS6THwHJzSlQqZjR+f/fNoBTPfS09u7 6oVL6kxwGrDVEHqlscHrwvLP4HiNYFqO/My++9kprJXcjAlnkk1S9CkAxwU7AZIMPfbo h/ug== X-Gm-Message-State: ACrzQf1cMOhIkLiH626YyLrFU0zHpRNGTe3QBefoLNIIWjHH1X1qiFou LeJ6PZrGo8aw1tsUn2y4GXU= X-Google-Smtp-Source: AMsMyM5y6whY0M1ej8FlbIz4HunEmchsLt+StolgnsccgFRtDE8EqzGd/lnWMXjUE7wEUkRbAL8v1w== X-Received: by 2002:a05:620a:4015:b0:6ed:a8db:32c0 with SMTP id h21-20020a05620a401500b006eda8db32c0mr2345807qko.656.1666107371041; Tue, 18 Oct 2022 08:36:11 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id bz12-20020a05622a1e8c00b0039a1146e0e1sm2144667qtb.33.2022.10.18.08.36.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 08:36:10 -0700 (PDT) Date: Tue, 18 Oct 2022 11:36:07 -0400 From: Mark Johnston To: Paul Floyd Cc: freebsd-hackers Subject: Re: AMD64 14.0-CURRENT memory layout changes Message-ID: References: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> X-Rspamd-Queue-Id: 4MsHyM4x6Yz3Sq4 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="ftCMdza/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72f:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 18, 2022 at 02:13:46PM +0200, Paul Floyd wrote: > > > > > How is 14.0 working out what address to use for the stack? > > (The above is with ASLR all off) > > > Answering my own question: > > it's in auxv (from __thr_get_main_stack_base) > > > /usr/include/sys/elf_common.h:#define AT_USRSTACKBASE 35 /* Top > of user stack */ > > I haven't yet added this (or AT_USRSTACKLIM) to the client auxv that > Valgrind synthesizes. > > > I'm still not certain that will fix it - I would have expected > __thr_get_main_stack_base to fallback to using sysctl. I think this is a compatibility bug in elf_aux_info(). The values of AT_USRSTACKBASE and AT_USRSTACKLIM can never legitimately be zero, I think, so we can use that to test. diff --git a/lib/libc/gen/auxv.c b/lib/libc/gen/auxv.c index af59a2dda90a..2f043f8814cf 100644 --- a/lib/libc/gen/auxv.c +++ b/lib/libc/gen/auxv.c @@ -381,15 +381,21 @@ _elf_aux_info(int aux, void *buf, int buflen) break; case AT_USRSTACKBASE: if (buflen == sizeof(u_long)) { - *(u_long *)buf = usrstackbase; - res = 0; + if (usrstackbase != 0) { + *(u_long *)buf = usrstackbase; + res = 0; + } else + res = ENOENT; } else res = EINVAL; break; case AT_USRSTACKLIM: if (buflen == sizeof(u_long)) { - *(u_long *)buf = usrstacklim; - res = 0; + if (usrstacklim != 0) { + *(u_long *)buf = usrstacklim; + res = 0; + } else + res = ENOENT; } else res = EINVAL; break; From nobody Tue Oct 18 18:33:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsMvG0D0Dz4fB2M for ; Tue, 18 Oct 2022 18:33:46 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020022.outbound.protection.outlook.com [52.101.128.22]) (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 4MsMvF0XPNz3j7S for ; Tue, 18 Oct 2022 18:33:45 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RxtMmtFmMyHmfWanwGtMwpK+GVG1LBT3Ms7gPb7ayaDs1WdtyMp4XvIpgukMUQJdWcSUaev/2QK2wMO/gcYciaknwz+VWiXHBGbjEbkO4d+07Bgy9h1UiDOe4Dkw8ZgNSu0tR8lkmrfplaHwdsPSd+BinFoyCj6k3wz7iKFXmibXN/bBKzrb9hTweTe5z+UqrU9eP/so12cPpQwFkEZCuZ+ZyrfeKlFVtg4J2vzlbkBBCJCVacVDyLlWtYl/fT0A+cFwEOkir3Jp0vIB6LQauCcnjwq9yhLMhIP7zXLu09jqEWhckjdwTJRcalAQneq9wyWx2hr4lsqi5/QRxkgsmw== 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=Qte0qtWxHX96S/XbliSauZ6G/CfceGWQ/h/rtmWRFas=; b=S3c7ZSNXo2phHOFes+tEyzluSdMq2o+7XKbuSmqjutEdCJN3tPzTvv+TB53AyECKfo73KM9WwVE2ZA4t53AdW53U2oe14R65itrxSketq+1XqJPosycVl47e1u4XHBKyQO2vCq10i0lpdL484lNzGc9UtfTVlEBNcYb+PRHB8OUhyCIdtOIbX8S84i2tRF5BBtnRDNeqiTlcgSHw42FMdJNPvEu9iKrydPINp7De97XJLx5ukIBitsQLEU023tNWX1mf4x8EZp1BVsYEtDV+EMtEBzOchZsq4qL13WNS6eKAQf8jI/Lv9F4ET5wxklxbb4a27B+DVVRz45twsoOZzg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qte0qtWxHX96S/XbliSauZ6G/CfceGWQ/h/rtmWRFas=; b=Wf5O0IbhKiWO/RW4NovmzG/Pm12A7WrHrZl8fIyACDBLJ02NqBqbv+3Hdbx/9LoiNflOdKhnFR5yTonKC0vo71lnta4sJYKo3MMDkjrOCtp+arU0GK4b9/pq+CHdsD2DcGmDlhd/WZsssWr0DxvCIPH5YTB3NqO+oY9Iig9IcCU= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SI2P153MB0639.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fe::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.1; Tue, 18 Oct 2022 18:33:40 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8%3]) with mapi id 15.20.5746.017; Tue, 18 Oct 2022 18:33:39 +0000 From: Souradeep Chakrabarti To: Warner Losh CC: "freebsd-hackers@freebsd.org" , Wei Hu Subject: RE: allocating IRQ mentioned in _CRS of ACPI Thread-Topic: allocating IRQ mentioned in _CRS of ACPI Thread-Index: AdjfoFUyyvAv3mtwTL+ltqDHxzFqEgAAb7xAAN9yT5A= Date: Tue, 18 Oct 2022 18:33:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=35bd4fc7-674a-4bac-abcc-32b8c2a111fc;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-10-14T07:40:41Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0639:EE_ x-ms-office365-filtering-correlation-id: 73c0feb4-6e6a-45df-11c0-08dab137466e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9MUgbXfuioLjr8vuv3wEOjVVWGGu8NOSaet0hOTPRXt9+lvuh9ROTF6IPPf7Bs9F7yx4nEM2w3N4Rsp5UOm0VjG9w+87/JDeugW9jCBBMHDZBI+QrReNmTLbTJHtLd9jgADdA/21Nhdx4hPj3MBnqz7C5pnS+HI5ozJ576gMtRs/CaxIZs7PMdCQs5boPrib4JxHo0rpAU3dSsCS4iOZc1iNRy1gsQevSqeY/4eysFgpQFTRlSVkLnXSZG8S/Hj+dE1swycNuZY1gUzo8J1Jn4EkhnUFGRrRuIuBuq41yNUFqMOyiOqrQnTnpR2uVie5UWcAE3jipFf/I6r8YHdaQF+0eTBOhvMkHgscWrl1zhIkcqFSYpOnXSkD8ZPtn4X2jIWedR9Qwy6QsgSuhzbuCsoAsDM0XpV8nCIugPSkNcK9FujfuJCWrw0/keP5bqelGUa5rucOIQaq4pdPXXKn2x4JXTO0YRN+3v/l4A+mNE8UkA2KP9JY6ORomiV9rHqBKyciEv3+dlZNuNNdHsvOaHDKSY6qNczLmNNOc2hWDHE+2Xaxva58ln3fB4JCoRpeb+tB8khG88WLiY7VuomJ/oR2q0EunzAqSvDr3JKHLyEA7Or15PiPucAkmErTYUw+iBBm1LaenilILnEHdFgPLukHd0VnRINTKNR8yV7IwG/C4+CzCi2Ty92vtFdQnu2Tny+3gx2NS+Knz55AZRw2czE/LtfP14mLjApCPB3C+Rasr6NuBBBYYKmkLRqsN32i9fOsJdSL5Nu3LIU5/y84iEH08CEj/3+tj9CAFRAAQ4FI9wjwa1k6T9hKanL4aUo7 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(396003)(39860400002)(366004)(346002)(376002)(136003)(451199015)(316002)(6916009)(54906003)(478600001)(7696005)(107886003)(71200400001)(64756008)(66446008)(66946007)(76116006)(8676002)(4326008)(66476007)(66556008)(53546011)(6506007)(10290500003)(52536014)(41300700001)(82950400001)(82960400001)(33656002)(8936002)(5660300002)(2906002)(186003)(9686003)(26005)(8990500004)(38100700002)(122000001)(38070700005)(83380400001)(55016003)(86362001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?if3a7meaMAqmlwcOSue2l/oq1r5+V34E6g6S87X6DhR68UWh8qnvlEJ4Lm0t?= =?us-ascii?Q?b547lB/KFJGdyfv2cSb6KgvTP2UDz6hAumI69GakxSJQ8qF/LfydJPppZfcE?= =?us-ascii?Q?9qbdQgJpGSn+lXZFYChTnf82pfKsa3ufA+a+h910CFMFTwlO6qXZSHJJkvnR?= =?us-ascii?Q?BECd9/cQxqPjFyiN/4/RXhtk9DbpOif49/8DAB/iNYFn9FcerAa/4StEhd0j?= =?us-ascii?Q?DKOY7655aQS1kVWU+/L7UbNzTolCpwgf2id0NL01I/Muubbg6ap16/1hFu8O?= =?us-ascii?Q?0nhrOoXlwPDYEetFCtF+A78v0UeASMyD5dTzydKFILsvI13vF/mB9JwCh8NC?= =?us-ascii?Q?mTL5TZx8n8/bEsHmxDeyZa+PUrApdrq54jnS4vuDVhWOCWT691Y8LNt+6Hns?= =?us-ascii?Q?vey3pgSIQRLd1HC8OJvsZvNofD9ryD3eSU1RFvG9wUVlAzYY97ITgIeMvYLl?= =?us-ascii?Q?pMKZ/e1N67i22YbWCGLKkzbmS8XjBlklZTfgoXO1wrFT15slpIpioMQ9orBh?= =?us-ascii?Q?ifCv6377HFqENN0MRy9/TmOFGSdNZJfCaqIKg7NDPAcYnfJxTBU7+PUyOGao?= =?us-ascii?Q?O+jgpODH4BLKEEHF3mTIuqmYu53nStkqrAZTOYsdXddfXQraMJ78sP73dq01?= =?us-ascii?Q?JkeakHq29xaTMzNLG6NAfUAL53QCnDCZ7pyV8r7wLjxDD6Z6n/kvGr+YyHkJ?= =?us-ascii?Q?jiG3Q+D5ZSLWmN+tlVaCluJl299t0qioxEhlClPQpnScZfYQGzIIwLAc6+xp?= =?us-ascii?Q?zT8BqbjoJ9O/Xwe4b7a0YQNRzSde6em/MqGc8rNc4S2exqJmleahELJngfb1?= =?us-ascii?Q?fso13Ukvq0Rr3W4a+pmsbgwHykcxJEg7Hvwlvdj4/lEaQxDYYYqcBilbQtt9?= =?us-ascii?Q?8XP5MGUZAcSbFHuBpBfcUpvOPbUzNRkw87p8E5PW/CXzbcmpxFGZLdeu5oAC?= =?us-ascii?Q?8RyhIeh7lV4G318c7IREQz5siwlXp0CRSJLzr9mUiVm/W3cJo/svjsyAdFe0?= =?us-ascii?Q?1M+sdNVuGvq4DnZdrTX+7viQoUlCfYtpX8snoBWYNOvcYhzBYRRudW3wEHaZ?= =?us-ascii?Q?O5GP/Ff7k7gHsYb5twns1oQVcoR+DmERjSTZGwgKhwqxpbFJxinETsrsR6vv?= =?us-ascii?Q?VRZJiPqXutITCCKQjxj9A2tQA7iXhVZydZGGyPK6poB+jyDwBurB9voiJNs9?= =?us-ascii?Q?wQI29kUpuhVnKQQcz+BlLMMCx9h1Y4I45Qp+jSabQ413ODXqaauAN5hTJ4T4?= =?us-ascii?Q?XnZrvXXqO4Boz8ATZRQaM+IupzI8cMFIpd3VlVd6cBNGy9HNSFeNbNwOL1sI?= =?us-ascii?Q?j2gZ5Q086uazcpg+Qv/jBPIBKVZBL+eS9wYBnwpo0EW32kgePGIS0870V+Fn?= =?us-ascii?Q?HB6uVeBXQtnRJ+umbuz9TSeBQ7CMi5A7nmOOeWY+AkWNIB37Z9XMsh5BdXuZ?= =?us-ascii?Q?YZMjlJRO9dGbhTFW0wgn810VFNdiEpN9Z2Y1FfX02ss6XvPx9k7NzDBEdoXv?= =?us-ascii?Q?u5jUcklFgmfBablqujNOHba4fKrLPbtFTKjQpoSg4j8UhE3Gdc5Gw7ovSg?= =?us-ascii?Q?=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 73c0feb4-6e6a-45df-11c0-08dab137466e X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2022 18:33:38.8645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o6zzjzXBkudbPyPGLylfBFIF7KrkYGtcTN9oehVR08zega5XbYH5fq00IsIkgb37DFbMFnL2WJfTOP4e8LcRI+1wTe2PU4P4hJuNwpOdRdA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0639 X-Rspamd-Queue-Id: 4MsMvF0XPNz3j7S X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=Wf5O0Ibh; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.22 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-10.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.22:from]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, It will be a great help, if someone can help here with some idea. As it is blocking the FreeBSD on Hyper-V ARM64. Thanks & Regards, Souradeep > -----Original Message----- > From: Souradeep Chakrabarti > Sent: Friday, October 14, 2022 1:24 PM > To: 'Warner Losh' > Cc: freebsd-hackers@freebsd.org; Wei Hu > Subject: RE: allocating IRQ mentioned in _CRS of ACPI >=20 > Last mail was having incorrect FreeBSD hacker alias. Replacing that with = correct > one here. >=20 >=20 > > -----Original Message----- > > From: Souradeep Chakrabarti > > Sent: Friday, October 14, 2022 1:19 PM > > To: Warner Losh > > Cc: hacker@freebsd.org; Wei Hu > > Subject: allocating IRQ mentioned in _CRS of ACPI > > > > Hi, > > I would like to allocate IRQ to a device, mentioned in the _CRS of > > that device in ACPI table. > > I have tried with bus_alloc_resource_any(), but it is failing as the > > parent of that device is not owning the IRQ. > > > > Current ACPI topo for the device : > > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for MMIO in _CRS)- > > >VMBUS( it has SYS_RES_IRQ in it's _CRS). > > > > How can I get here both SYS_RES_IRQ and SYS_RES_MEM allocated to VMBUS? > > > > Thanks & Regards, > > Souradeep From nobody Tue Oct 18 21:01:28 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsR9n1XN2z4fWhy for ; Tue, 18 Oct 2022 21:01:33 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsR9m1p80z3y0w for ; Tue, 18 Oct 2022 21:01:32 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id bk15so25778254wrb.13 for ; Tue, 18 Oct 2022 14:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=4RHPDxpO3uoXxLxoTF1oijs5EcBvKfF2kX2mtOJNNt8=; b=QtHF9sIwlGIXNAISOOwN0KAaYjrJPm89AfoIGaFk0fEccnKVRkjN9+Kcm01EMyMsAK bVYm+v/cE4JvmdpuNmE2XzBhSUi7/1zeK+iSsYaLg0pG80UY9/yuffrI4qgdcCxRcUz+ IwuG+JMYyzkNZF822A9lH35IyysBsuKgzu81hdHBrAyUusPKRxAfGnZLBVfe8OtrWYQO RDk4rJsMAjjZR9KEe1Lk7uZqDsLhj5HOnNblflVt2Dnh5pRH/iOHWhwcDCOGXxQuOdV1 oRoedTpE74/xZkPM3iiKQ9Ope72HwzLHWKpJe/l7A24UAA6dbYyUViMv4b9byLudh+MJ 4Jng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4RHPDxpO3uoXxLxoTF1oijs5EcBvKfF2kX2mtOJNNt8=; b=mXVxGoI6YjGqBpqzD2/6B06ou8QrMhiH2DTlDR9MYJy8hIgjF+Uj3AGcA93yUMjZlZ DhJLRu//NTVYms5IfzKLv8gaDBLK7OPGZ45GKI9RzctibZQt/QxKYaVBm3/9ZDfdAh6R KNLTFlGIabc6PVAK8fnmY5rvxZewp8MVQe2jsfKLGBr6EJGmniO0LycfAmrh3Ih09BUh xQZRJbu+w54LkiMjGrEDQH4EYuUPjR1FUwBdDxf1ADsEfHBWiThPIm29aqBSQm3VCi26 ldJ4XIWAmyra3GZEaGauaC37JKK5K96KDe1M18bUFV4ABK6Gm+CXclA/OmU4uSjzJDFq mSEA== X-Gm-Message-State: ACrzQf14mSzJkWQgqElAS0LBsyszOOfnCdW/i3RYcNwz2vnrXHRecCof sxEuqcEXzTH6rA70xnbNtR9ISkJE4fU8IQ== X-Google-Smtp-Source: AMsMyM7W19WbW+TI0Qd4uIQQYxKGC+RH40hjpJduTxLrvy8rEItyZwYqtxSjJSGUzKvk+GKlFIpZGg== X-Received: by 2002:adf:efc5:0:b0:22e:4a6:2d5b with SMTP id i5-20020adfefc5000000b0022e04a62d5bmr3060296wrp.293.1666126889548; Tue, 18 Oct 2022 14:01:29 -0700 (PDT) Received: from [192.168.1.28] (lfbn-lyo-1-263-217.w2-7.abo.wanadoo.fr. [2.7.103.217]) by smtp.gmail.com with ESMTPSA id v16-20020a05600c445000b003a3170a7af9sm11547758wmn.4.2022.10.18.14.01.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 14:01:29 -0700 (PDT) Message-ID: <8a640196-c057-81f0-96be-45b340ffaa2e@gmail.com> Date: Tue, 18 Oct 2022 23:01:28 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2 Subject: Re: AMD64 14.0-CURRENT memory layout changes To: freebsd-hackers References: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MsR9m1p80z3y0w X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QtHF9sIw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::431 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N Hi Fixing the auxv slot did the trick < == 765 tests, 236 stderr failures, 30 stdout failures, 9 stderrB failures, 13 stdoutB failures, 0 post failures == --- > == 765 tests, 10 stderr failures, 1 stdout failure, 2 stderrB failures, 3 stdoutB failures, 0 post failures == (that's the regtest before and after results). I've pushed the changes upstream. Valgrind 3.20 is due out in the next couple of weeks. I'll bump the devel/valgrind port when that's done. A+ Paul From nobody Tue Oct 18 22:07:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsSdp05XPz4fwM6 for ; Tue, 18 Oct 2022 22:07:26 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsSdn0LWMz44hC for ; Tue, 18 Oct 2022 22:07:24 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qt1-x836.google.com with SMTP id g11so10623465qts.1 for ; Tue, 18 Oct 2022 15:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=jc6OfSYqD1RTzerqJjYOzzqZTI/A1jHwdyMAEYuptV0=; b=R4KV6cGZkB9s5IQj7gG8eti1+O2tRuZA6yfyKIw8A8Gkgn9ORaRgJXV7vmhcZCTQEc w2WvxaKePlNZVcjw25CXsWdDBjSgdtJsqnFIKKNhw1Kn58tEcUNAepI+5jMJfQeIHB4z TwAMWsgAvvAuuEJwQxh9G1xoRDSt8O4pLEWbVy5jsdm0mrIwS7RGCUDEGXp91/XPRB8r xwySkWQn9AlwDALYHQ/yM6mz6krb8CdYCFGIFFHLFt1jX/D0w+jdSn/FwXXlaGX1zECt A76s3X3na+vB67kysbWwyCx4YiGCttrEHz+g+eyEj9rqwbabeVeby+sM2sqF7YcAupTT +F8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jc6OfSYqD1RTzerqJjYOzzqZTI/A1jHwdyMAEYuptV0=; b=ym9Ct8oHtSjqUb5svH7m7Z1IW9YcvloQOoJnuMqBiWedN5ABCNm6zfBzuKCmFCGWra S56k/YBfSOrsP4ijjcf8AdKJhEtyUDaVR/T5WDUuXiV6Uu1b6Ea8PYidfccnyIQ/knI5 ZzBFauRRNv43rdoitXuY/1l9rem4hl803mvq23RFSozopcEfsTyCsU9zmNdo3a3HvZtk bMNeYMMeM5lMcLAdy9Yv8ONabQE9hlmElnm4ypKDnGOYAiOJA2NsidFqMetpUGt02YfD KdflkwdBWosbjCU+VpiDM3OGCb5Mjkfw31ScnOrp5aWrY+a+4ioMRluwZ3KgfVHmJXXJ 7VJA== X-Gm-Message-State: ACrzQf2xyrcGlyyCLutoEqAlSOmRJDxoZI0423Nm+RLbgpIxodFzwwV8 OKdua+Rh2h3DtZFRr4iAiHXYYw== X-Google-Smtp-Source: AMsMyM4Mv+VswQk9QviHStuE8m3QBOtPWQZJjSrqcw31jmQVs2RG8xW5EaBQPgVGzPaWKEe7Kgqllg== X-Received: by 2002:ac8:59c8:0:b0:39c:fb43:45ea with SMTP id f8-20020ac859c8000000b0039cfb4345eamr826497qtf.361.1666130843916; Tue, 18 Oct 2022 15:07:23 -0700 (PDT) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id y9-20020a05620a25c900b006ed61f18651sm3437101qko.16.2022.10.18.15.07.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Oct 2022 15:07:23 -0700 (PDT) Received: by mail-yb1-f180.google.com with SMTP id j7so18642342ybb.8; Tue, 18 Oct 2022 15:07:22 -0700 (PDT) X-Received: by 2002:a25:8b11:0:b0:6bc:fdf:ecef with SMTP id i17-20020a258b11000000b006bc0fdfecefmr3888666ybl.367.1666130842544; Tue, 18 Oct 2022 15:07:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Tomek CEDRO Date: Wed, 19 Oct 2022 00:07:11 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: proper python3 interpreter invocation To: FreeBSD Questions Mailing List , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MsSdn0LWMz44hC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=R4KV6cGZ; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::836) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::836:from,209.85.219.180:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N Hello world :-) Is Python 3 part of the base? What would be the most valid way to invoke a Python 3 script? Two options are possible: 1. #!/usr/bin/env python 2. #!/usr/bin/env python3 I am working on a mobile application in Python + Kivy that can be then converted into Android and iOS application. It works fine here on FreeBSD even in bare console (DRM KMS). I would like to build Android application on FreeBSD (I know iOS version needs macOS+XCode). For that I need Android NDK that is officially only provided for Windows, macOS and Linux. I did a modification to make it work on FreeBSD using Linux binaries. The goal is to create a FreeBSD Port for Android NDK (no official support / releases will be provided for our platform). But the patches are rejected at the upstream :-( https://github.com/android/ndk/issues/1780 https://github.com/android/ndk/issues/1781 https://github.com/android/ndk/issues/1785 This one is interesting in particular: https://github.com/android/ndk/issues/1785 Some of their scripts use `#!/usr/bin/env python3` and some use `#!/usr/bin/env python`. The ones using `python` does not work out of the box on FreeBSD.. so I wanted to unify the interpreter to use `python3` (or `python` whatever is best if there was any kind of sensible discussion). I know that I can create a Python VirtualEnv where python == python3. Also I can create a symlink /usr/local/bin/python3 -> /usr/local/bin/python but that customization will make system incoherent with other standard installations. Maybe I should simply create local patches when creating that port? Google not only does not and will not provide releases for FreeBSD but also rejects patches to make things work here. We are doomed to a local fork on purpose :-( What would be the proper approach on FreeBSD? Where am I wrong? Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Tue Oct 18 22:20:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsSwT2Sp7z4fyBP for ; Tue, 18 Oct 2022 22:20:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsSwS1l2Gz48lj for ; Tue, 18 Oct 2022 22:20:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82f.google.com with SMTP id bb5so10613231qtb.11 for ; Tue, 18 Oct 2022 15:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=0Z50cMez3Jqtmaaj0270ny9x8N6xuFfMNMmLAIkLwjE=; b=QXhAw2S9NivPMiU4zg+jjUT0L0OMXVvnmKjT7xSDvddvwxpMf8RoXQqAHHH98dpWtO b/8d43YFGnOAojxgYDjDObKnes4TS14ujdFpZWgKlDCSpRF8u0WWdCZNee18BbyNdhCY DDO7OfzLeuWcw0MksB6hARx/AvjWwelicQhVJ6cWemiug87vdgiLnMJkcWAbaEWL0bG+ 3IDWYAPaMuDA+6xS1cyeKN3nCUJNm6YJIIQyeQ9ASofNVfSTcfwsg0NnGMJvLuvHqImg OnmALp0kY5jkNTEKAcA23V0t3txcVjfb7jMfEvKoHUBhDpUn4NwV1eUS7g0v1PNxVr2L xzIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0Z50cMez3Jqtmaaj0270ny9x8N6xuFfMNMmLAIkLwjE=; b=LOsAYdp6tDbz/7UXgie8Es3o4A8bqBZrUWwkNz455UjXiY6Pa6Zg4PYuXCNfqkjbMC cboYCzVE2trjStSx8OPNh6m0/eHnS0zlEHt3MxyGgNbC0MjptHQzo4swsbaAxSb3Es7k ReBAJlxJ1aaLKx/5lImkKPnXHY3MDrrkdM6ItqlLVFe+iBPXTUhjmMFxZp+x7P5q6xhz P6evwjd29a5QyejEW/WVbEJDLQKLVP5Rb+8b1CLiEeZ+wQPB2os18X+szreyehwjc6PU 6T+kjQcGkQ7rwjug+iahZLFHvQiGb8noq/ciPxPhrsbRQ7lw45QuiIVgrrc3dACwGcc4 7gFQ== X-Gm-Message-State: ACrzQf1ZiBGDpdd48yJi0I2FvkBi4dN1DuCLmAWDKyrdPi8CoIO0DSwA ELGEzJaQznVOPVjs+yaS6K4= X-Google-Smtp-Source: AMsMyM5Iyk2crs5wkSKiBZ8fdSXPk8XSI6szkmjYaXk05hQcGfh1RQwjUVTh7wqFDnVERZuQyg0IQw== X-Received: by 2002:ac8:5854:0:b0:39c:dba4:6fa0 with SMTP id h20-20020ac85854000000b0039cdba46fa0mr4086957qth.175.1666131607661; Tue, 18 Oct 2022 15:20:07 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id p6-20020a05620a132600b006ee7923c187sm3222250qkj.42.2022.10.18.15.20.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Oct 2022 15:20:06 -0700 (PDT) Date: Tue, 18 Oct 2022 18:20:04 -0400 From: Mark Johnston To: Paul Floyd Cc: freebsd-hackers Subject: Re: AMD64 14.0-CURRENT memory layout changes Message-ID: References: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> <8a640196-c057-81f0-96be-45b340ffaa2e@gmail.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a640196-c057-81f0-96be-45b340ffaa2e@gmail.com> X-Rspamd-Queue-Id: 4MsSwS1l2Gz48lj X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QXhAw2S9; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::82f as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 18, 2022 at 11:01:28PM +0200, Paul Floyd wrote: > Hi > > Fixing the auxv slot did the trick Thanks for confirming, I committed that change. > < == 765 tests, 236 stderr failures, 30 stdout failures, 9 stderrB > failures, 13 stdoutB failures, 0 post failures == > --- > > == 765 tests, 10 stderr failures, 1 stdout failure, 2 stderrB > failures, 3 stdoutB failures, 0 post failures == > > (that's the regtest before and after results). > > I've pushed the changes upstream. > > Valgrind 3.20 is due out in the next couple of weeks. I'll bump the > devel/valgrind port when that's done. Nice. Thanks for all of the work you do on the Valgrind port! From nobody Wed Oct 19 12:50:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Msrtd5nsCz4fwvF for ; Wed, 19 Oct 2022 13:19:53 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) (using TLSv1.3 with cipher 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 "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsrtX6QZjz3GPD for ; Wed, 19 Oct 2022 13:19:48 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.16.1/8.16.1) with ESMTP id 29JCoK1s083469 for ; Wed, 19 Oct 2022 21:50:20 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <202210191250.29JCoK1s083469@sana.init-main.com> From: Takanori Watanabe To: freebsd-hackers@freebsd.org Subject: How can I get raw value of interrupt ACPI resource value in INTRNG? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <83467.1666183820.1@sana.init-main.com> Date: Wed, 19 Oct 2022 21:50:20 +0900 X-Rspamd-Queue-Id: 4MsrtX6QZjz3GPD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of takawata@init-main.com designates 210.138.194.104 as permitted sender) smtp.mailfrom=takawata@init-main.com X-Spamd-Result: default: False [-1.65 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.86)[-0.859]; SUBJECT_ENDS_SPACES(0.50)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:2497, ipnet:210.138.0.0/16, country:JP]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[takawata]; DMARC_NA(0.00)[init-main.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N I wrote ACPI Generic Event device driver, found at least in qemu. https://reviews.freebsd.org/D37032 This works fine for qemu, but I have problem about this. This driver receive interrupt and invoke "_EVT" method to process ACPI function, such as sending Notify to other ACPI device. This driver can handle multiple interrupt, though qemu use only one and the event cause is obtained from memory-mapped I/O by ACPI bytecode. To distingish each interrupts, the spec requires the driver invoke _EVT method with IRQ identifier. This IRQ identifier should be interrupt resource value encoded in _CRS data, and I believe it is available from rman_get_start(theResource), but I aware the resource value in dmesg and ACPI resource value that can be available from DSDT is not same. I look inside and found irq number mapping is done before setting resource by rman_set_resource and the raw value of the resource is hidden in subr_intr.c static function, it seems. How can I do to obtain raw ACPI IRQ resource value? From nobody Wed Oct 19 15:22:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MswGP389Fz4gHHD for ; Wed, 19 Oct 2022 15:52:13 +0000 (UTC) (envelope-from takawata@sana.init-main.com) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) (using TLSv1.3 with cipher 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 "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MswGL319qz3WpK for ; Wed, 19 Oct 2022 15:52:08 +0000 (UTC) (envelope-from takawata@sana.init-main.com) Received: from sana.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.16.1/8.16.1) with ESMTPS id 29JFMmbY084219 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 20 Oct 2022 00:22:48 +0900 (JST) (envelope-from takawata@sana.init-main.com) Received: (from takawata@localhost) by sana.init-main.com (8.16.1/8.16.1/Submit) id 29JFMm0t084218 for freebsd-hackers@freebsd.org; Thu, 20 Oct 2022 00:22:48 +0900 (JST) (envelope-from takawata) Date: Thu, 20 Oct 2022 00:22:48 +0900 From: Takanori Watanabe To: freebsd-hackers@freebsd.org Subject: Re: How can I get raw value of interrupt ACPI resource value in INTRNG? Message-ID: References: <202210191250.29JCoK1s083469@sana.init-main.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202210191250.29JCoK1s083469@sana.init-main.com> X-Rspamd-Queue-Id: 4MswGL319qz3WpK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of takawata@sana.init-main.com has no SPF policy when checking 210.138.194.104) smtp.mailfrom=takawata@sana.init-main.com X-Spamd-Result: default: False [-0.76 / 15.00]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_LONG(-0.97)[-0.967]; FORGED_SENDER(0.30)[takawata@init-main.com,takawata@sana.init-main.com]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:2497, ipnet:210.138.0.0/16, country:JP]; DMARC_NA(0.00)[init-main.com]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[takawata]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; FROM_NEQ_ENVFROM(0.00)[takawata@init-main.com,takawata@sana.init-main.com] X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 19, 2022 at 09:50:20PM +0900, Takanori Watanabe wrote: > I wrote ACPI Generic Event device driver, found at least in qemu. > > https://reviews.freebsd.org/D37032 > > This works fine for qemu, but I have problem about this. > This driver receive interrupt and invoke "_EVT" method to process > ACPI function, such as sending Notify to other ACPI device. > > This driver can handle multiple interrupt, though qemu use only one and > the event cause is obtained from memory-mapped I/O by ACPI bytecode. > To distingish each interrupts, the spec requires the driver > invoke _EVT method with IRQ identifier. > > This IRQ identifier should be interrupt resource value encoded in _CRS > data, and I believe it is available from rman_get_start(theResource), > but I aware the resource value in dmesg and ACPI resource value that > can be available from DSDT is not same. > > I look inside and found irq number mapping is done before setting > resource by rman_set_resource and the raw value of the resource is > hidden in subr_intr.c static function, it seems. > > How can I do to obtain raw ACPI IRQ resource value? intr_activate_irq called by bus_activate_resource sets the object containing irq raw value. I resolved myself. From nobody Wed Oct 19 17:39:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsyfG3ZSsz4gVTW for ; Wed, 19 Oct 2022 17:39:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsyfF1hjcz3pmN for ; Wed, 19 Oct 2022 17:39:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x62f.google.com with SMTP id ot12so41785299ejb.1 for ; Wed, 19 Oct 2022 10:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8lsUOQu9ZgSf+8JPAH408M0rKcnPxhQ3SUznBTf7+3A=; b=OBOW6qAD4HM2RQ4xsMdSDnEfC/lub9CCmJcMo8el8DKMbd64BpF29xbAjE4es2zQ3R yzn/P89xtO9Sp4Z6NGIzyJH0XmKrGChuo8eRGhoeBaRoJF/4gmv6i5t79+1mRP9P5TOR x/g34c7lPPcBKwZezgmXLCukvSOEuBvM46hlz6QGZidUz8qY/RHWpApZ8WHiK4eAJrOC W+DPRPFwQ8vLw/2YuUU/Z7GO7s4BHlx7OHoSAAewl0bH/QGiv3h+UMX2JAt9rhdZpCxt s14Axvxqpmj63EHHsOd6W5RyJJqKWWVocUuUBY6wpxBYAZj3se2muQmNWlxSFM2blK5R 4ytg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8lsUOQu9ZgSf+8JPAH408M0rKcnPxhQ3SUznBTf7+3A=; b=NgqrJp/qGBfUhL+LSRmTne4RXSfxfgOq4a22EGkuXC8R9bMbLr1DL+EKmmh3zX1eCS 7tDZVLMLGus1+8kpUNgrBZTPb3dM309ZqwD3PM3VGy3a1IMhVkSNWH0gu656U7i87bXl lkelKZt7NlLO2aQS/IurVB+jcD43M8cb2Bp+wD4R7CMSPuFMRnV0/A3PGVfFvAZQ/HVc wSQ71RpeYsmLTiq2FBafQviFBOCpnLGHWFPt7gHyE1iL9S7ZndW41zo7piHouXHZqZBW Meixcdqzuie5XY4Sc+nqzVT0AMzK/6RleVMOf36kpjoqHBnegKwqzRNDQKUfki5BC46d RhKQ== X-Gm-Message-State: ACrzQf2BRu7WKkSH3woClpUIJ51N10b/bwlv+FDDBDl2k31fVeHuAMey LhXxToJbHQ1L6KKiqQ37fNna9+GsdjjLeEWfQ9lEVg== X-Google-Smtp-Source: AMsMyM4UzpzQ3xF9wYydwPV13ySx2TaquSZnaM8WwXlrEDHzTtQlvVKTosBHdxE56E5oqVzJI2VCkgh6QcJ25QOB+Uk= X-Received: by 2002:a17:907:16a7:b0:78d:f586:e446 with SMTP id hc39-20020a17090716a700b0078df586e446mr7759671ejc.252.1666201171161; Wed, 19 Oct 2022 10:39:31 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 19 Oct 2022 11:39:19 -0600 Message-ID: Subject: Re: allocating IRQ mentioned in _CRS of ACPI To: Souradeep Chakrabarti Cc: "freebsd-hackers@freebsd.org" , Wei Hu Content-Type: multipart/alternative; boundary="000000000000ee990a05eb66b0a4" X-Rspamd-Queue-Id: 4MsyfF1hjcz3pmN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=OBOW6qAD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000ee990a05eb66b0a4 Content-Type: text/plain; charset="UTF-8" Sorry for the late reply... I've been busy with some things for work... I think you'll need to get the parent of vmbus to allow a pass through allocation. What bus is that currently? Warner On Tue, Oct 18, 2022 at 12:33 PM Souradeep Chakrabarti < schakrabarti@microsoft.com> wrote: > Hi, > It will be a great help, if someone can help here with some idea. > As it is blocking the FreeBSD on Hyper-V ARM64. > > Thanks & Regards, > Souradeep > > > -----Original Message----- > > From: Souradeep Chakrabarti > > Sent: Friday, October 14, 2022 1:24 PM > > To: 'Warner Losh' > > Cc: freebsd-hackers@freebsd.org; Wei Hu > > Subject: RE: allocating IRQ mentioned in _CRS of ACPI > > > > Last mail was having incorrect FreeBSD hacker alias. Replacing that with > correct > > one here. > > > > > > > -----Original Message----- > > > From: Souradeep Chakrabarti > > > Sent: Friday, October 14, 2022 1:19 PM > > > To: Warner Losh > > > Cc: hacker@freebsd.org; Wei Hu > > > Subject: allocating IRQ mentioned in _CRS of ACPI > > > > > > Hi, > > > I would like to allocate IRQ to a device, mentioned in the _CRS of > > > that device in ACPI table. > > > I have tried with bus_alloc_resource_any(), but it is failing as the > > > parent of that device is not owning the IRQ. > > > > > > Current ACPI topo for the device : > > > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for MMIO in _CRS)- > > > >VMBUS( it has SYS_RES_IRQ in it's _CRS). > > > > > > How can I get here both SYS_RES_IRQ and SYS_RES_MEM allocated to VMBUS? > > > > > > Thanks & Regards, > > > Souradeep > --000000000000ee990a05eb66b0a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the=C2=A0late reply... I've been busy w= ith some things for work...

I think you'll nee= d to get the parent of vmbus to allow a pass through allocation. What bus i= s that
currently?

Warner

On Tue, Oct = 18, 2022 at 12:33 PM Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:
Hi,
It will be a great help, if someone can help here with some idea.
As it is blocking the FreeBSD on Hyper-V ARM64.

Thanks & Regards,
Souradeep

> -----Original Message-----
> From: Souradeep Chakrabarti
> Sent: Friday, October 14, 2022 1:24 PM
> To: 'Warner Losh' <imp@bsdimp.com>
> Cc: f= reebsd-hackers@freebsd.org; Wei Hu <weh@microsoft.com>
> Subject: RE: allocating IRQ mentioned in _CRS of ACPI
>
> Last mail was having incorrect FreeBSD hacker alias. Replacing that wi= th correct
> one here.
>
>
> > -----Original Message-----
> > From: Souradeep Chakrabarti
> > Sent: Friday, October 14, 2022 1:19 PM
> > To: Warner Losh <imp@bsdimp.com>
> > Cc: hacke= r@freebsd.org; Wei Hu <weh@microsoft.com>
> > Subject: allocating IRQ mentioned in _CRS of ACPI
> >
> > Hi,
> > I would like to allocate IRQ to a device, mentioned in the _CRS o= f
> > that device in ACPI table.
> > I have tried with bus_alloc_resource_any(), but it is failing as = the
> > parent of that device is not owning the IRQ.
> >
> > Current ACPI topo for the device :
> > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for MMIO in _CRS)= -
> > >VMBUS( it has SYS_RES_IRQ in it's _CRS).
> >
> > How can I get here both SYS_RES_IRQ and SYS_RES_MEM allocated to = VMBUS?
> >
> > Thanks & Regards,
> > Souradeep
--000000000000ee990a05eb66b0a4-- From nobody Wed Oct 19 17:51:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Msyw63NcSz4gWwt for ; Wed, 19 Oct 2022 17:51:34 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2106.outbound.protection.outlook.com [40.107.117.106]) (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 4Msyw46f4Yz3vdJ for ; Wed, 19 Oct 2022 17:51:32 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DXOkx6A+Me7+B/dmshYi8mIBsBHjtfjXI0B3eQ24wMrLrTleKpitTTUqRrc61NW1Wxbvudfcph2PMARn9RYv647TEOKdGMCrzSmrz+xsADBTj3mkyCmFaz35zhGp26x7j3vh2QrA7U2EH1sO6RM7tYGUhsAPRi/PakPBLiD9aA9gclmfp7RC7JCfVJTYtqtkfaqgqyfBwibuF2HvC/0LrdTiSSDGav+MP/twtboHbdpmhLQTvJQMse+CZdTEqvHdn11ptNzMu3wi+FFp7eRiR83WKtq+PH6INDD6xovbP37zjsjW05+B0fK38VxgwKuC7Z4B/rzYhF3SB4aL9yPl8w== 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=js52DM5HcJRWwv7zO04S78VqQkhKc08s1xCh8ppHHKE=; b=nKip2uwJNmW9AUz/agHRuBCpgxYr2ht1wYFWKSnMuRdUbanlLe0vdUPxeI0A1TZRazrn2hD4TYSVlXeLUWsHBg7AV+XMeRpp/D359YTcf1+AAguIVOO0Az9940LdJ022NRddEQaqKXzlxJcMi+88JfjoyqfSRBwws+L4n5BW3irU9m/+B1FskjY5a66u1O8dnPYa+Rlfcld8HvsU96ip+rTZmXmESJElro5EnMS+YpXBIN6aVg1CYHq57MfEFCgsrOY0Y3OV5YraW99mpE8vh7dHepUtEL66rfU+U/VFl81P/ud6lbHtxBZvHt8myqeNDIZjqK04iaanWhYYU8JoDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=js52DM5HcJRWwv7zO04S78VqQkhKc08s1xCh8ppHHKE=; b=jE4cu9umW1ZS5KBInNDDaKICBeOuGteinsb+60yUxYQvf2K71QvDhImQZ6s2cvL/0MCbfq8T+3y0zk48ti9eVkKOlqUpz3uZ+X5mb1Ri8sHsLi0cSZfBk1d5BmxICRXAMQtSkyztdxT1FtkI6Y8mwvSRnW7+Gf4YX0/7YGbBgOY= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SI2P153MB0654.APCP153.PROD.OUTLOOK.COM (2603:1096:4:1fb::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5746.6; Wed, 19 Oct 2022 17:51:27 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8%3]) with mapi id 15.20.5746.017; Wed, 19 Oct 2022 17:51:26 +0000 From: Souradeep Chakrabarti To: Warner Losh CC: "freebsd-hackers@freebsd.org" , Wei Hu Subject: RE: [EXTERNAL] Re: allocating IRQ mentioned in _CRS of ACPI Thread-Topic: [EXTERNAL] Re: allocating IRQ mentioned in _CRS of ACPI Thread-Index: AdjfoFUyyvAv3mtwTL+ltqDHxzFqEgAAb7xAAN9yT5AAMHZ8gAAAS2Fw Date: Wed, 19 Oct 2022 17:51:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2e85f12c-a126-4809-8aaf-39c6a51c2946;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-10-19T17:47:44Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0654:EE_ x-ms-office365-filtering-correlation-id: cb78ab1d-9ed5-45c1-fed8-08dab1fa8b97 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eecSwLoGl3QFN5PPNnBrGDi8305cCOEAOeqpOny/sRmZglGia5wRkLi2h90YRL5axw7bD3xZxALsy4bsvGmSRBJ/YQFNcbWbPkuFF+CBOZrKbM/7LWYM+qQSkptXGUivtNbV42ZrlJw7MN4OCoOxn4NDE9YXlxAhjROGWZVuIzDU/+3E3k1XHK3W1RlhhpPkLpNUucVc6TE6n/dABFNJ0S32y/w+mLhfl8gaksI6X2O2mPXqC/Mntw5xhhYsBgsIa/FO9xBl1fQ3MzP4AKhBHCEFb9K7f6r5Yg2LZRxMugWvjYc0NAvtrbBoP8C4mE4emsre4R5GQOGRw6YGVqLogxTiNnML7Jxic3/jdsPpjkFFWR+L8L3whIYLMuj8DjGW3oTUwAMw/+DqOc642tje+H0fJz9TUsek/t1TpzG8BBYEg/mVCiXRnW0vnv8z6qM/eavWJK+ZJdRh1hefjBjwaa2iGuvtz+S9AWQAcBbyougZeeLr9VkX63rhKYnMYONi63N5SWdUoR3bvWrHf/nL5pCiFS8Yzkn5GsKT9kTwfSMkmmBso3zBiLpyJ6H+j70HYerfQ4HuWJ6ofoCEHOVwW2gETTPER4kEUVAJ/LVNRtNRmptTn8KEJFjuXbFV+dlot/5KBMaNR2bSKR6E5Ocjlw6OGyTD+CxnJguPEHPasBeEQ/eb5XZdIOUwd42GW+KwO01MkJbzoKEC2GL06JWGFBdATd6Glh1cxrBjZjeaR5KjGcX4UAc60bPoi/oBTY7ggkAqwJeV5Cr25uWO+VB1F5vGnUGjcme8OShJKOEIJ+r76sCRnX113N7WktGZzm9x x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(451199015)(186003)(7696005)(26005)(9686003)(6506007)(107886003)(83380400001)(53546011)(8990500004)(55016003)(5660300002)(6916009)(41300700001)(10290500003)(478600001)(9326002)(316002)(71200400001)(8936002)(52536014)(54906003)(76116006)(66476007)(4326008)(8676002)(66446008)(66556008)(66946007)(64756008)(2906002)(86362001)(33656002)(82960400001)(122000001)(99936003)(38070700005)(82950400001)(38100700002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TkxLOHJSajJPN0wwc3hSWUpETnN6c2ZCVUc2bnNJRGNuTWVmcHpSc0oxbWtq?= =?utf-8?B?QmszVExBdGNpQXA2NE5oNlNkY3hrdU9yTkFQWEFqTnFCdWFYM0JZdnBSbnBp?= =?utf-8?B?NTRNRWJiSVVRUDkwdlVFY1JmVXE5K0dSWnpCcjdHdVpJSWdlRXFLQjZ4Mm45?= =?utf-8?B?QmpvODlOU2g1eU9EcXRKNmp4VEpoejJ1L3hOWUtRNWQ5UDNWcjNvTWtHTkhw?= =?utf-8?B?blNaSkZrVmFJSUZXSnRuWW9PTUNZd2x6elIySC9TbXp5Z3B3RWVLU2R6RWNI?= =?utf-8?B?bm84MHpQZksvZ2s4aUJ5Q0FPUE1lZVh6T1BjemhiMlNsdzhvcmVPUldpdVZz?= =?utf-8?B?WVBnQm9MZkF4N1I2OTllTUlSbXNzdDFhZzlMY1QvT3FaNUp5eE1kVVZqQ2sy?= =?utf-8?B?c3FhNG5NaFJtN3RMaTJpMVN3bm5tSlFjemMvR1NTdWZPWkQ3TUJEakNUMVhq?= =?utf-8?B?dkpwOCtNYWw2eVVyUmlyd0FNVmQ3WkRWd2hsbkp6a0VTMTExZU40blZMT3pI?= =?utf-8?B?QWNScDlYOGM0bWQ2YlVNWnJDZlB2MnRxcTdjWk9nL2VOUnZIU2J5dFptS3Fo?= =?utf-8?B?RlFXcjY4UjdCcTR6ZHNYS2lCTVFpd0JJVlo5dFBINHo3Wk9KYjlXMy90Tzhw?= =?utf-8?B?U005dFZOU0J1U3hTVjR3Wmc4NnhXOWRTRXZNMXM5MXZDY281OWdTSDl6a05F?= =?utf-8?B?SjZiWkJZYmRqUDJSblZaZVBQZ0IxeERmRHN5RG9Yc1pjUS9WQno0aXZFcE4y?= =?utf-8?B?bFowWWdUbnVHS3llWUJaUktCMVFzUC9hak5MWkYwMWp3R0J3K0U3bTRQY1o0?= =?utf-8?B?QXJnQzBTWnFNK2tDKzhhUDlMNHA2YW5TQnlCcm1jU2FhM1hUYUt1R0lBdGRP?= =?utf-8?B?QnJtV0FPcTJUc0RPS1E5Yk9ZRFFYZlZuVmMrR3dzY3JsRWhoUlQ2cHdINDIz?= =?utf-8?B?WEI0SFZ3VENwTU8rSmNMaG9YeTdNZ3pYc00wa0dqUnRFZVRoZUhaaTQ1dU1i?= =?utf-8?B?RUJyNE1wNnhqek1SNXNRUHpJMVlLQTlHS0xta0xEOXV5NnZUVmNpRFZGZ3lM?= =?utf-8?B?dHBleitZOW9VN2hlcHZWUnRsSlRtd1RKaXN4K2lnb2oxd0lSM1lwbTRsLytn?= =?utf-8?B?VWVCUkgxZHMxb0N1T0EzZTE5SUtGcTFYWmcvNXdOeHZXTWpKQnM3bkhUL1ZL?= =?utf-8?B?NWp1VlRaM2pHeWZuVGxUTllDZERlalVqMHliK1dqMTgrNGJ3QzF2ckM5cXlp?= =?utf-8?B?UkVlV2ZvOVZHSmRHM0swS3huZ3BYamdFOG5WelVlWUJvQkZvcE5kZWEydExm?= =?utf-8?B?UEc3YSt2ZFRseFFsbXdoTFBQVUVYeXNqbk5uWmZEQkdLODB3VFFpR3FIWEJV?= =?utf-8?B?bk5kbDg2b3ZzS1VvM2dMRTk3enlSMTVKcjNRUVBDWWxXakdIZzVNNjNkUER2?= =?utf-8?B?U2srV0Q3QVBvSk5YZFZHN3M3OTlWK1FnSTJHUDF3ajR1bk1HRkg3aERWNnZk?= =?utf-8?B?ZkZ5aUV1Qm54N3kzSWIyWXAreE5DZi90dGxwLzNzTzF6cDBaZDJLVGpjSkhn?= =?utf-8?B?ZHdmd0NuendhTHIxS1ZDL3BPSXBPbDV5VzkzZ0E2MlhkQ3htVTJvK25ySUNW?= =?utf-8?B?RnZhQkFlU1g5cGxUczJzMVVKeEVYQWpOMUJMWXpTRXRYRUc0NUNmaGRSVEpR?= =?utf-8?B?YUZTcWM1VnNyaGUwWGQ5dnlpanhtczUrY1R6UzlLQlI3OElvWTc4QlhuSTNB?= =?utf-8?B?bnh2OWdhejk4cndiU0FTcm1qNTBiajFDdWJBNU1DTm5pMm1tYWJVWFh4YXNm?= =?utf-8?B?MVl4a0lrZlg1WHpvdnFnaXRzS3BEK1dJNVY2bFY2c0xiUUJzQzhaQzA4RTdJ?= =?utf-8?B?Q2FGb2R5ZnVUa0pRSUNvamNKcFFESFZpY1d4eWh6VHUxUmNLQk5PbmM4blhE?= =?utf-8?B?UHFIcjd4a0JaZm1xNnF2NkRWM3k2K1JJNWs0b1VOaUlScnNyUVByNmNYRndT?= =?utf-8?B?dGt1VndMN1dGL25UTGl4MWk5SUtRdGxXYlFYcHg2K0Znd2NUR3dsb0UvZkp5?= =?utf-8?B?aUp5Tm1JaWhYVlVGQU1FaCs0ckY4SDZacUYwUT09?= Content-Type: multipart/related; boundary="_004_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_"; type="multipart/alternative" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cb78ab1d-9ed5-45c1-fed8-08dab1fa8b97 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2022 17:51:26.7812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sq+B4L7ewIQNeR15xKLOFxRXvehUyhrQlVaWMFxTWByzyNiluvlqjmfyaxH2u8Z3+rg9gx340NoTbClwcfufIWUgsLw77jebU69JxwN/D5g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0654 X-Rspamd-Queue-Id: 4Msyw46f4Yz3vdJ X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=jE4cu9um; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.117.106 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-6.99 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.56)[-0.565]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; NEURAL_SPAM_LONG(0.48)[0.479]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.117.106:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FROM_EQ_ENVFROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.117.106:from] X-ThisMailContainsUnwantedMimeParts: N --_004_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_ Content-Type: multipart/alternative; boundary="_000_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_" --_000_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2FybmVyLA0KDQoNCjEpIFBDSSBtbWlvIHJlc291cmNlIGluIEhJRCAiQUNQSTAwMDQiLCB3 aGljaCBpcyBuZWVkZWQgYnkgdGhlIEZyZWVCU0QgZ3Vlc3QgZm9yIFNSSU9WIGRldmljZXMuDQoN Cg0KDQogICBEZXZpY2UgKFxfU0IuVk1PRCkgICAgPC0tIFRoaXMgaXMgY3VycmVudGx5IG93bmVk IGJ5IGFjcGlfc3lzY29udGFpbmVyIG1vZHVsZSBvbiBGcmVlQlNEDQoNCiAgICB7DQoNCiAgICAg ICAgTmFtZSAoX0hJRCwgIkFDUEkwMDA0IiAvKiBNb2R1bGUgRGV2aWNlICovKSAgLy8gX0hJRDog SGFyZHdhcmUgSUQNCg0KICAgICAgICBOYW1lIChfVUlELCBaZXJvKSAgLy8gX1VJRDogVW5pcXVl IElEDQoNCiAgICAgICAgTmFtZSAoX0NSUywgUmVzb3VyY2VUZW1wbGF0ZSAoKSAgLy8gX0NSUzog Q3VycmVudCBSZXNvdXJjZSBTZXR0aW5ncw0KDQogICAgICAgIHsNCg0KICAgICAgICAgICAgLi4u DQoNCiAgICAgICAgfQ0KDQogICAgICAgIENyZWF0ZURXb3JkRmllbGQgKF9DUlMsIFxfU0IuVk1P RC5fWTAwLl9NSU4sIE1JTjYpICAvLyBfTUlOOiBNaW5pbXVtIEJhc2UgQWRkcmVzcw0KDQogICAg ICAgIENyZWF0ZURXb3JkRmllbGQgKF9DUlMsIFxfU0IuVk1PRC5fWTAwLl9NQVgsIE1BWDYpICAv LyBfTUFYOiBNYXhpbXVtIEJhc2UgQWRkcmVzcw0KDQogICAgICAgIENyZWF0ZURXb3JkRmllbGQg KF9DUlMsIFxfU0IuVk1PRC5fWTAwLl9MRU4sIExFTjYpICAvLyBfTEVOOiBMZW5ndGgNCg0KICAg ICAgICBDcmVhdGVRV29yZEZpZWxkIChfQ1JTLCBcX1NCLlZNT0QuX1kwMS5fTUlOLCBNSU43KSAg Ly8gX01JTjogTWluaW11bSBCYXNlIEFkZHJlc3MNCg0KICAgICAgICBDcmVhdGVRV29yZEZpZWxk IChfQ1JTLCBcX1NCLlZNT0QuX1kwMS5fTUFYLCBNQVg3KSAgLy8gX01BWDogTWF4aW11bSBCYXNl IEFkZHJlc3MNCg0KICAgICAgICBDcmVhdGVRV29yZEZpZWxkIChfQ1JTLCBcX1NCLlZNT0QuX1kw MS5fTEVOLCBMRU43KSAgLy8gX0xFTjogTGVuZ3RoDQoNCiAgICAgICAgTWV0aG9kIChfSU5JLCAw LCBOb3RTZXJpYWxpemVkKSAgLy8gX0lOSTogSW5pdGlhbGl6ZQ0KDQogICAgICAgIHsNCg0KICAg ICAgICAgICAgTUlONiA9IE1HMkIgLyogXE1HMkIgKi8NCg0KICAgICAgICAgICAgTEVONiA9IE1H MkwgLyogXE1HMkwgKi8NCg0KICAgICAgICAgICAgTG9jYWwwID0gTUcyTCAvKiBcTUcyTCAqLw0K DQogICAgICAgICAgICBNQVg2ID0gKE1JTjYgKyBMb2NhbDAtLSkNCg0KICAgICAgICAgICAgTG9j YWwxID0gKEhNSUIgPDwgMHgxNCkNCg0KICAgICAgICAgICAgTG9jYWwyID0gKEhNSUwgPDwgMHgx NCkNCg0KICAgICAgICAgICAgTUlONyA9IExvY2FsMQ0KDQogICAgICAgICAgICBMRU43ID0gTG9j YWwyDQoNCiAgICAgICAgICAgIExvY2FsMCA9IExvY2FsMg0KDQogICAgICAgICAgICBNQVg3ID0g KE1JTjcgKyBMb2NhbDAtLSkNCg0KICAgICAgICB9DQoNCiAgICB9DQoNCg0KDQoyKSBWbWJ1cyBJ UlEgcmVzb3VyY2UgaW4gSElEICJWTUJ1cyIsIHdoaWNoIGlzIG5lZWRlZCB0byBnZXQgSHlwZXIt ViB2bWJ1cyBpbnRlcnJ1cHQgdG8gd29yayBvbiBndWVzdHMuDQoNCkRldmljZSAoXF9TQi5WTU9E LlZNQlMpICAgPC0tLSBjdXJyZW50bHkgb3duZWQgYnkgdm1idXNfcmVzIG1vZHVsZSBvbiBGcmVl QlNEDQoNCiAgICB7DQoNCiAgICAgICAgLi4uDQoNCiAgICAgICAgTmFtZSAoX0hJRCwgIlZNQnVz IikgIC8vIF9ISUQ6IEhhcmR3YXJlIElEDQoNCiAgICAgICAgTmFtZSAoX1VJRCwgWmVybykgIC8v IF9VSUQ6IFVuaXF1ZSBJRA0KDQogICAgICAgIC4uLg0KDQogICAgICAgIE5hbWUgKF9DUlMsIFJl c291cmNlVGVtcGxhdGUgKCkgIC8vIF9DUlM6IEN1cnJlbnQgUmVzb3VyY2UgU2V0dGluZ3MNCg0K ICAgICAgICB7DQoNCiAgICAgICAgICAgIEludGVycnVwdCAoUmVzb3VyY2VDb25zdW1lciwgRWRn ZSwgQWN0aXZlSGlnaCwgRXhjbHVzaXZlLCAsLCApDQoNCiAgICAgICAgICAgIHsNCg0KICAgICAg ICAgICAgICAgIDB4MDAwMDAwMTIsDQoNCiAgICAgICAgICAgIH0NCg0KICAgICAgICB9KQ0KDQog ICAgfQ0KDQoNCltEaWFncmFtICBEZXNjcmlwdGlvbiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZF0N Cg0KVG9kYXkgSSB3YXMgYWJsZSB0byBnZXQgYm90aCBJUlEgYW5kIE1NSU8gYWxsb2NhdGlvbiBz dWNjZXNzZnVsIHVzaW5nIGJlbG93IHNuaXBwZXQgaW4gdm1idXM6DQoNCg0KKyAgICAgICBkZXZp Y2VfdCBkZXYgPSAgZGV2Y2xhc3NfZ2V0X2RldmljZShkZXZjbGFzc19maW5kKCJ2bWJ1c19yZXMi KSwgMCk7DQoNCisgICAgICAgc2MtPmlyZXMgPSBidXNfYWxsb2NfcmVzb3VyY2VfYW55KGRldiwN Cg0KICAgICAgICAgICAgU1lTX1JFU19JUlEsICZzYy0+dmVjdG9yLCBSRl9BQ1RJVkUgfCBSRl9T SEFSRUFCTEUpOw0KDQoNClRoYW5rcyAmIFJlZ2FyZHMsDQogU291cmFkZWVwDQoNCkZyb206IFdh cm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxOSwg MjAyMiAxMTowOSBQTQ0KVG86IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8c2NoYWtyYWJhcnRpQG1p Y3Jvc29mdC5jb20+DQpDYzogZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnOyBXZWkgSHUgPHdl aEBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogYWxsb2NhdGluZyBJUlEg bWVudGlvbmVkIGluIF9DUlMgb2YgQUNQSQ0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuLi4g SSd2ZSBiZWVuIGJ1c3kgd2l0aCBzb21lIHRoaW5ncyBmb3Igd29yay4uLg0KDQpJIHRoaW5rIHlv dSdsbCBuZWVkIHRvIGdldCB0aGUgcGFyZW50IG9mIHZtYnVzIHRvIGFsbG93IGEgcGFzcyB0aHJv dWdoIGFsbG9jYXRpb24uIFdoYXQgYnVzIGlzIHRoYXQNCmN1cnJlbnRseT8NCg0KV2FybmVyDQoN Ck9uIFR1ZSwgT2N0IDE4LCAyMDIyIGF0IDEyOjMzIFBNIFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8 c2NoYWtyYWJhcnRpQG1pY3Jvc29mdC5jb208bWFpbHRvOnNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQu Y29tPj4gd3JvdGU6DQpIaSwNCkl0IHdpbGwgYmUgYSBncmVhdCBoZWxwLCBpZiBzb21lb25lIGNh biBoZWxwIGhlcmUgd2l0aCBzb21lIGlkZWEuDQpBcyBpdCBpcyBibG9ja2luZyB0aGUgRnJlZUJT RCBvbiBIeXBlci1WIEFSTTY0Lg0KDQpUaGFua3MgJiBSZWdhcmRzLA0KU291cmFkZWVwDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU291cmFkZWVwIENoYWtyYWJhcnRp DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNCwgMjAyMiAxOjI0IFBNDQo+IFRvOiAnV2FybmVy IExvc2gnIDxpbXBAYnNkaW1wLmNvbTxtYWlsdG86aW1wQGJzZGltcC5jb20+Pg0KPiBDYzogZnJl ZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPG1haWx0bzpmcmVlYnNkLWhhY2tlcnNAZnJlZWJzZC5v cmc+OyBXZWkgSHUgPHdlaEBtaWNyb3NvZnQuY29tPG1haWx0bzp3ZWhAbWljcm9zb2Z0LmNvbT4+ DQo+IFN1YmplY3Q6IFJFOiBhbGxvY2F0aW5nIElSUSBtZW50aW9uZWQgaW4gX0NSUyBvZiBBQ1BJ DQo+DQo+IExhc3QgbWFpbCB3YXMgaGF2aW5nIGluY29ycmVjdCBGcmVlQlNEIGhhY2tlciBhbGlh cy4gUmVwbGFjaW5nIHRoYXQgd2l0aCBjb3JyZWN0DQo+IG9uZSBoZXJlLg0KPg0KPg0KPiA+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogU291cmFkZWVwIENoYWtyYWJhcnRp DQo+ID4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE0LCAyMDIyIDE6MTkgUE0NCj4gPiBUbzogV2Fy bmVyIExvc2ggPGltcEBic2RpbXAuY29tPG1haWx0bzppbXBAYnNkaW1wLmNvbT4+DQo+ID4gQ2M6 IGhhY2tlckBmcmVlYnNkLm9yZzxtYWlsdG86aGFja2VyQGZyZWVic2Qub3JnPjsgV2VpIEh1IDx3 ZWhAbWljcm9zb2Z0LmNvbTxtYWlsdG86d2VoQG1pY3Jvc29mdC5jb20+Pg0KPiA+IFN1YmplY3Q6 IGFsbG9jYXRpbmcgSVJRIG1lbnRpb25lZCBpbiBfQ1JTIG9mIEFDUEkNCj4gPg0KPiA+IEhpLA0K PiA+IEkgd291bGQgbGlrZSB0byBhbGxvY2F0ZSBJUlEgdG8gYSBkZXZpY2UsIG1lbnRpb25lZCBp biB0aGUgX0NSUyBvZg0KPiA+IHRoYXQgZGV2aWNlIGluIEFDUEkgdGFibGUuDQo+ID4gSSBoYXZl IHRyaWVkIHdpdGggYnVzX2FsbG9jX3Jlc291cmNlX2FueSgpLCBidXQgaXQgaXMgZmFpbGluZyBh cyB0aGUNCj4gPiBwYXJlbnQgb2YgdGhhdCBkZXZpY2UgaXMgbm90IG93bmluZyB0aGUgSVJRLg0K PiA+DQo+ID4gQ3VycmVudCBBQ1BJIHRvcG8gZm9yIHRoZSBkZXZpY2UgOg0KPiA+IEFDUEkwLT5T Qi5WTU9EKEhJRCBBQ1BJMDAwNCwgaGFzIFNZU19SRVNfTUVNIGZvciBNTUlPIGluIF9DUlMpLQ0K PiA+ID5WTUJVUyggaXQgaGFzIFNZU19SRVNfSVJRIGluIGl0J3MgX0NSUykuDQo+ID4NCj4gPiBI b3cgY2FuIEkgZ2V0IGhlcmUgYm90aCBTWVNfUkVTX0lSUSBhbmQgU1lTX1JFU19NRU0gYWxsb2Nh dGVkIHRvIFZNQlVTPw0KPiA+DQo+ID4gVGhhbmtzICYgUmVnYXJkcywNCj4gPiBTb3VyYWRlZXAN Cg== --_000_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUlOO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SGkgV2FybmVyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjEpIFBDSSBtbWlvIHJlc291cmNlIGluIEhJRCAmcXVvdDtBQ1BJMDAwNCZxdW90 Oywgd2hpY2ggaXMgbmVlZGVkIGJ5IHRoZSBGcmVlQlNEIGd1ZXN0IGZvciBTUklPViBkZXZpY2Vz Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgRGV2aWNlIChcX1NCLlZN T0QpJm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLSBUaGlzIGlzIGN1cnJlbnRseSBvd25lZCBieSBh Y3BpX3N5c2NvbnRhaW5lciBtb2R1bGUgb24gRnJlZUJTRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm bmJzcDsgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTmFtZSAoX0hJRCwgJnF1b3Q7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1o aWdobGlnaHQ6eWVsbG93Ij5BQ1BJMDAwNDwvc3Bhbj4mcXVvdDsgLyogTW9kdWxlIERldmljZSAq LykmbmJzcDsgLy8gX0hJRDogSGFyZHdhcmUgSUQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbWUgKF9VSUQsIFplcm8pJm5ic3A7IC8vIF9VSUQ6 IFVuaXF1ZSBJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTmFtZSAoX0NSUywgUmVzb3VyY2VUZW1wbGF0ZSAoKSZuYnNwOyAvLyBfQ1JTOiBDdXJy ZW50IFJlc291cmNlIFNldHRpbmdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENyZWF0ZURXb3JkRmllbGQgKF9DUlMs IFxfU0IuVk1PRC5fWTAwLl9NSU4sIE1JTjYpJm5ic3A7IC8vIF9NSU46IE1pbmltdW0gQmFzZSBB ZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBDcmVhdGVEV29yZEZpZWxkIChfQ1JTLCBcX1NCLlZNT0QuX1kwMC5fTUFYLCBNQVg2KSZuYnNw OyAvLyBfTUFYOiBNYXhpbXVtIEJhc2UgQWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ3JlYXRlRFdvcmRGaWVsZCAoX0NSUywgXF9TQi5W TU9ELl9ZMDAuX0xFTiwgTEVONikmbmJzcDsgLy8gX0xFTjogTGVuZ3RoPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDcmVhdGVRV29yZEZpZWxkIChf Q1JTLCBcX1NCLlZNT0QuX1kwMS5fTUlOLCBNSU43KSZuYnNwOyAvLyBfTUlOOiBNaW5pbXVtIEJh c2UgQWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQ3JlYXRlUVdvcmRGaWVsZCAoX0NSUywgXF9TQi5WTU9ELl9ZMDEuX01BWCwgTUFYNykm bmJzcDsgLy8gX01BWDogTWF4aW11bSBCYXNlIEFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENyZWF0ZVFXb3JkRmllbGQgKF9DUlMsIFxf U0IuVk1PRC5fWTAxLl9MRU4sIExFTjcpJm5ic3A7IC8vIF9MRU46IExlbmd0aDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWV0aG9kIChfSU5JLCAw LCBOb3RTZXJpYWxpemVkKSZuYnNwOyAvLyBfSU5JOiBJbml0aWFsaXplPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBNSU42ID0gTUcyQiAvKiBcTUcyQiAqLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTEVONiA9IE1HMkwg LyogXE1HMkwgKi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvY2FsMCA9IE1HMkwgLyogXE1HMkwgKi88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BWDYgPSAoTUlONiArIExvY2FsMC0tKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTG9jYWwxID0gKEhNSUIgJmx0OyZsdDsgMHgxNCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExv Y2FsMiA9IChITUlMICZsdDsmbHQ7IDB4MTQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNSU43ID0gTG9j YWwxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMRU43ID0gTG9jYWwyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtM b2NhbDAgPSBMb2NhbDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BWDcgPSAoTUlONyArIExvY2FsMC0t KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Mikg Vm1idXMgSVJRIHJlc291cmNlIGluIEhJRCAmcXVvdDtWTUJ1cyZxdW90Oywgd2hpY2ggaXMgbmVl ZGVkIHRvIGdldCBIeXBlci1WIHZtYnVzIGludGVycnVwdCB0byB3b3JrIG9uIGd1ZXN0cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+RGV2aWNlIChcX1NCLlZNT0QuVk1CUykmbmJzcDsgJm5ic3A7Jmx0Oy0tLSBjdXJyZW50 bHkgb3duZWQgYnkgdm1idXNfcmVzIG1vZHVsZSBvbiBGcmVlQlNEPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5hbWUgKF9ISUQsICZxdW90OzxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdztt c28taGlnaGxpZ2h0OnllbGxvdyI+Vk1CdXM8L3NwYW4+JnF1b3Q7KSZuYnNwOyAvLyBfSElEOiBI YXJkd2FyZSBJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTmFtZSAoX1VJRCwgWmVybykmbmJzcDsgLy8gX1VJRDogVW5pcXVlIElEPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuLi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbWUgKF9DUlMsIFJl c291cmNlVGVtcGxhdGUgKCkmbmJzcDsgLy8gX0NSUzogQ3VycmVudCBSZXNvdXJjZSBTZXR0aW5n czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgezxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJydXB0IChSZXNvdXJjZUNvbnN1bWVyLCBFZGdlLCBBY3Rp dmVIaWdoLCBFeGNsdXNpdmUsICwsICk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDB4MDAwMDAwMTIsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB9KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxpbWcgd2lkdGg9IjU4NCIgaGVpZ2h0PSIyNjYiIHN0eWxl PSJ3aWR0aDo2LjA4MzNpbjtoZWlnaHQ6Mi43NzA4aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNy Yz0iY2lkOmltYWdlMDAxLnBuZ0AwMUQ4RTQxMS44MEVFQ0JFMCIgYWx0PSJEaWFncmFtCgpEZXNj cmlwdGlvbiBhdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCI+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRvZGF5IEkgd2FzIGFibGUgdG8gZ2V0IGJv dGggSVJRIGFuZCBNTUlPIGFsbG9jYXRpb24gc3VjY2Vzc2Z1bCB1c2luZyBiZWxvdyBzbmlwcGV0 IGluIHZtYnVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBkZXZpY2VfdCBkZXYgPSZuYnNwOyBkZXZjbGFzc19nZXRfZGV2aWNl KGRldmNsYXNzX2ZpbmQoJnF1b3Q7dm1idXNfcmVzJnF1b3Q7KSwgMCk7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNjLSZndDtpcmVzID0gYnVzX2FsbG9jX3Jlc291cmNlX2FueShkZXYsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU1lTX1JFU19JUlEsICZh bXA7c2MtJmd0O3ZlY3RvciwgUkZfQUNUSVZFIHwgUkZfU0hBUkVBQkxFKTs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhhbmtzICZh bXA7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwO1NvdXJhZGVlcDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBXYXJuZXIg TG9zaCAmbHQ7aW1wQGJzZGltcC5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBPY3RvYmVyIDE5LCAyMDIyIDExOjA5IFBNPGJyPg0KPGI+VG86PC9iPiBTb3VyYWRlZXAgQ2hh a3JhYmFydGkgJmx0O3NjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnOyBXZWkgSHUgJmx0O3dlaEBtaWNyb3NvZnQu Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBhbGxvY2F0aW5nIElS USBtZW50aW9uZWQgaW4gX0NSUyBvZiBBQ1BJPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBmb3IgdGhlJm5ic3A7bGF0ZSBy ZXBseS4uLiBJJ3ZlIGJlZW4gYnVzeSB3aXRoIHNvbWUgdGhpbmdzIGZvciB3b3JrLi4uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg eW91J2xsIG5lZWQgdG8gZ2V0IHRoZSBwYXJlbnQgb2Ygdm1idXMgdG8gYWxsb3cgYSBwYXNzIHRo cm91Z2ggYWxsb2NhdGlvbi4gV2hhdCBidXMgaXMgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y3VycmVudGx5PzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XYXJuZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgT2N0IDE4LCAyMDIyIGF0 IDEyOjMzIFBNIFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNjaGFr cmFiYXJ0aUBtaWNyb3NvZnQuY29tIj5zY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGksPGJyPg0KSXQgd2lsbCBiZSBhIGdyZWF0IGhlbHAsIGlmIHNvbWVvbmUgY2Fu IGhlbHAgaGVyZSB3aXRoIHNvbWUgaWRlYS48YnI+DQpBcyBpdCBpcyBibG9ja2luZyB0aGUgRnJl ZUJTRCBvbiBIeXBlci1WIEFSTTY0Ljxicj4NCjxicj4NClRoYW5rcyAmYW1wOyBSZWdhcmRzLDxi cj4NClNvdXJhZGVlcDxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7IEZyb206IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aTxicj4NCiZndDsgU2VudDogRnJp ZGF5LCBPY3RvYmVyIDE0LCAyMDIyIDE6MjQgUE08YnI+DQomZ3Q7IFRvOiAnV2FybmVyIExvc2gn ICZsdDs8YSBocmVmPSJtYWlsdG86aW1wQGJzZGltcC5jb20iIHRhcmdldD0iX2JsYW5rIj5pbXBA YnNkaW1wLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmZyZWVic2Qt aGFja2Vyc0BmcmVlYnNkLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmZyZWVic2QtaGFja2Vyc0BmcmVl YnNkLm9yZzwvYT47IFdlaSBIdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlaEBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+d2VoQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgU3Vi amVjdDogUkU6IGFsbG9jYXRpbmcgSVJRIG1lbnRpb25lZCBpbiBfQ1JTIG9mIEFDUEk8YnI+DQom Z3Q7IDxicj4NCiZndDsgTGFzdCBtYWlsIHdhcyBoYXZpbmcgaW5jb3JyZWN0IEZyZWVCU0QgaGFj a2VyIGFsaWFzLiBSZXBsYWNpbmcgdGhhdCB3aXRoIGNvcnJlY3Q8YnI+DQomZ3Q7IG9uZSBoZXJl Ljxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogU291cmFkZWVwIENoYWtyYWJhcnRpPGJyPg0K Jmd0OyAmZ3Q7IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNCwgMjAyMiAxOjE5IFBNPGJyPg0KJmd0 OyAmZ3Q7IFRvOiBXYXJuZXIgTG9zaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmltcEBic2RpbXAuY29t IiB0YXJnZXQ9Il9ibGFuayI+aW1wQGJzZGltcC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBD YzogPGEgaHJlZj0ibWFpbHRvOmhhY2tlckBmcmVlYnNkLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmhh Y2tlckBmcmVlYnNkLm9yZzwvYT47IFdlaSBIdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlaEBtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2VoQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4N CiZndDsgJmd0OyBTdWJqZWN0OiBhbGxvY2F0aW5nIElSUSBtZW50aW9uZWQgaW4gX0NSUyBvZiBB Q1BJPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0OyBJIHdv dWxkIGxpa2UgdG8gYWxsb2NhdGUgSVJRIHRvIGEgZGV2aWNlLCBtZW50aW9uZWQgaW4gdGhlIF9D UlMgb2Y8YnI+DQomZ3Q7ICZndDsgdGhhdCBkZXZpY2UgaW4gQUNQSSB0YWJsZS48YnI+DQomZ3Q7 ICZndDsgSSBoYXZlIHRyaWVkIHdpdGggYnVzX2FsbG9jX3Jlc291cmNlX2FueSgpLCBidXQgaXQg aXMgZmFpbGluZyBhcyB0aGU8YnI+DQomZ3Q7ICZndDsgcGFyZW50IG9mIHRoYXQgZGV2aWNlIGlz IG5vdCBvd25pbmcgdGhlIElSUS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ3VycmVu dCBBQ1BJIHRvcG8gZm9yIHRoZSBkZXZpY2UgOjxicj4NCiZndDsgJmd0OyBBQ1BJMC0mZ3Q7U0Iu Vk1PRChISUQgQUNQSTAwMDQsIGhhcyBTWVNfUkVTX01FTSBmb3IgTU1JTyBpbiBfQ1JTKS08YnI+ DQomZ3Q7ICZndDsgJmd0O1ZNQlVTKCBpdCBoYXMgU1lTX1JFU19JUlEgaW4gaXQncyBfQ1JTKS48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSG93IGNhbiBJIGdldCBoZXJlIGJvdGggU1lT X1JFU19JUlEgYW5kIFNZU19SRVNfTUVNIGFsbG9jYXRlZCB0byBWTUJVUz88YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyAmZ3Q7IFNv dXJhZGVlcDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_-- --_004_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=29025; creation-date="Wed, 19 Oct 2022 17:51:25 GMT"; modification-date="Wed, 19 Oct 2022 17:51:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAkgAAAEKCAYAAADpZqpVAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAHD2SURBVHhe7Z0HYBZF+saf9N4g1NATSgBB6b0q KAgKNrBhL1jOgu1Or/jXO7GcngV7V4qCIr0jvfcSOiGEhFBCek/2P89+O2Hz8QUILQm8P5jsfrNt dnZ25tl33p11MxQQBEEQBEEQinG3poIgCIIgCIKFCCRBEARBEAQnRCAJgiAIgiA4IQJJEARBEATB iUsikEaOHGkGsnTpUri5uZnzwuUHrzOvL8O+ffus2MsPKceCIAiXN2USSNdff31x46cDG4qKQFRU VLEIu1Bwf9zvpYbCgnk7fvx4K8Y1Fa2RZro//fRT7N27F3w5slGjRtaSio9dxF8q9PW7kPcQ79G3 337b+nV5w3vTVfnn+TOeeeEK3lfOy/nbObgS+PYHAAZX96hOV2kPCM77KG0/54vOB3twLmv2ZfZy 46quvxhpPFcuZTnn9XQ+94pS9zIfXNVbFa1tqKyU2YI0evRos/HToVu3btaS8mXPnj0YM2aM9evC wP1xv5caCgvm7bBhw6yYykFCQoI5rUzCqDzhvVOR7qHKhG7o+/fv77LhZvzs2bNdis9XX33VXO58 by9ZsqS4Xhs3bhwiIyNL7JsNEUWPXofB+R5lo302D1WPP/74afdzoeB56mPwnLp3724tcTT89vp8 wYIF1hIH9mV86Bk+fPglf4gQTs99992HOXPmWL9OMnbsWLOMCefHBetiY0Vif9ooi7q3b2evXJyV u7Na5jK9vv2JglOuZ38Ksu9Hq2t74LrOcD/2ePv+XK1PnPOhtKdIbq/Tr9e1V+bOv+3H5rlxW13Z 6XjCZfY84vG5TKdDH1dvo+P1bwb79s44551e1zk9peWP/Xz19TqXNHN9bq/3p/PKvn97Gk5XJhhH yxcD4+1psWPf9/Lly63Yk+hl9n3wGNzOji5XzudJXOUP4f50PIMruC1FwUsvvVRie87r/NNpcb6O Oi809nTY89GZ0soDOV2eu8J+js555gwbgEceeQR9+vTBd999Z8WWhA0E17OjywkbltNBwUJBQVFA eI1YPmbNmmX+dgXXYd6f64OaLg/6Wul8P9O1si+z578zHTp0MKe6vFH01KtXz5wnpzs3PvRwfeaB zkNn7OnQgfA87GVZn48d+zb2c3A+d/4urZw7Yy93DPb7jL91PjOcqbydDh7f+R7hOTDoa2o/D+dj cXu9jEGns7TyYIfllNfF+ZrwOt15553WL+FcuSACiReQFYnuWuGUhdf5RnYFL7z9SYWFRxeEfv36 YfHixeY84ROfXS1zGddxBQsIK0Hu017RETbkjOMyHptPiqerHAjPhcfX6XS1PgspK2u9Divo01VY TJNen+mwP93Z0fvQ++WNw8qOT7z2+LPFfq1Y8THP7deAeezq2vH8mEb7kzbzmTc4b1R7elzlD68r r5fe9osvvrCWnBnnNBOWMZ1/tMI475/YK8/SygTTymuln+pdNXC8BswnvW/ntJeWh7xOzhUYt3XV QJeWPzwH7k/H8ziuKkuWT1oMdDpefPFFa4nDasI4rsPyY7+OTB/zQlfMZ8pHzenKg+Z096EdbtOg QYMzHlPD/Xbp0gW33nqr2VjqtNthA8H17LzxxhumsDobtKDgea5evdqsJ3QjxuDc0DHPeI7niy7T LJdnulZne++SiRMnmueg7x+Wd+7rbOppwu24vauHA5YZff/oeoBpPRtOdw4sO7quZuB9frpyrtH3 h96O6zLtdvQ9wUBOV95Oh6syyHJnFyj6HtDH0nU6z5P1mF7Gc2U5smMvD65gvtsfBLhPnqtYpi8A KuPPGlUoeXVLBHUTmPGqAFprOVAXzQzO8+rmMbcjqjAY6kKa8xr7cs7r5ZznPngsHpNwGeOJPQ2c 8rcdnVYGPU/sx3PGvh+m1b7d2eDq/DSu8oz71+dT2rwdV2m35zVxPl/n47rah6v8I877JvZ1Xe1L 45wOO2VNMznTNsSe/67Oyb6+8/6c4br2a2A/1zPlIad63/Z17Wl2lX4Nz4Hnojnduq7yiuva0+4q L/R2rvZdWjl2lWf2fbs6TmnpduZ018M5Pc7nbD+ufZk+N+K8D+c80uh4rq+31XB7nUb7MV3loR1u w+X2wGO42s5VHupzspcljX19ztuPwcA4O/q8GDivseebndLincso96fz03kbe7rPdA72PLZTWjpI aflvT5N9nnBfpZU3poHruwoae3rsZctVWuzLXZ0H12faSjsPZ5zzkOdRWt4IZeO8fZD004jdVEv4 NOjqqc4Z56ew2rVrm1NuSwWsCoc5z6eWHj16mCZ1PgkxjsvKopLpI6PTyydCwv2qwmrOnw5tcue6 fHq0WwTs8MlAP2GW9rRcGqdLh86Xi4VOMwOfaEqD19UOrzuf6M4Wnf8XC319zjb/td/U2XCma1Ba HvLpkU/F5Ey+AaXlD89F7/tsyuuZ4BOvPb38beds8/FcykNpec66QB/T2fJjh0/UdisQ64TSyizz Xlvi3n333dPmvTPO9ZdzvjMNXIeBxy9L1xrTYa9HT1ePnela2Zc554NqgEsch8vtlhLWa4xXjexZ WZNKu7a8dtrar+vGstRZpZ0Dj8d7h/GurKanw/le4vWLj4+3fp2K8/W2w7rfno/MLzv2cuZcPp2p U6eONeeA52s//9Jg+uzr6evIssNz09eO9w6tWsL5c8F8kOLi4qw5B7GxsWfVGDrfcM6OvrzBKYjo QEiTN83qnKfAKUtl54xucFg4deN1JnRlwpvFVXcYCyz3pW8irlcWKPhK42wbcucG62zRadahNHMu r6sdXndnkXs6XFVC55pmVzAP7edRFvF2Js50DezHZdB5aPcTYPk4nW9AaZW0cwXNcD5i07nhZLB3 VZxtPp5vedA4d+uVdm8zfygQ7I2KblBdNe4677nMudvjTOiHKDZAbNRKuz/1elpUaiHF6bl229g5 07VyXlbavUv4gOvsjE14jjyOcz1uh3nPPGAd7ArmL8+fdSPLqy6fZ1NOT3cOLHuM47Qs+el8LzHt zuLkQmG/x1k+TydQnEWas9GBwZVgZj7a17GXAQoyCjOWc17H86kbhJNcEIFE9cxKShdITs+mMtKF yl7o6SNgrxy5b97QvDl40VlwWAD5tEKLUllhAWbFZS9oZS1Mp7vJ7I0DC+zpsOcZ84DpcnVjsMAz XzRsTLid3dqm4RO8/en7dD5QhMc724pc+3TYrWc8B16jM8E85nH4FK/ReVXWNLuC+2c+2fdfFs5k 8XS+BnaBfDZ5yDKt86m0yq+0/GHlR3+Js4H7cRYtzmifCft11JQlH8+nPLjCLpTt5cGO9qOx378M THNp9xvzng9EXMdV3ruC58Rt9EOO3s5+jfW56gcnHbSQ4tSVf0xZON21Ksu9q6GVgxY37s9ukWHZ 53GcewLs8FjMS1d5yG15vjoPmCcaXldtXSH28lGWc7DXracr57oM2+sR7p/HOdvrfy7wmDw3TpkG O/a08F7WFiauz3J0vuhywn2f6/0nuEAV5rNGXfhS+zYZz93pYO/fVTdVcf+uc3+puqlKbKfX0+jl 9nimw74PYk8bp/xth+vrNHFf+ng6uMK+H+dt7OdnR92ExetwG/52hU6vfZ88Vw1/249h368+T6Lz wn4cHcegKnhzqvetj+uMXl8HV+sQvT8d+FvjfG1dUdq2ZU0z89ZeJjT2fGLQ63B77scOl+s8tpfD 0s5dL9fbcWrHvpzBvh+9vj1OH9P5uutgzx/n8ldaudLHsW/PeX2eGvt6OtjXKS0fndHXSgd7ms+U 53bs+c9wuutrP4ZGp4P7cT6u3rd9O87b89B+bB3s14U451lp5UQfz3l7TWnnVtp2Z7pWzst0ujh1 XmY/Lufty+z5Y78fXS13Rue/PZRWnvS6dvQyHZh2nR862K+pPU9KS5f9mPZrTRhnT59zmbHjqszp 49vR52VfV5+D/Vo4H8fVdSKllYfS0NdMuHC48Y/K1CsGmiCpsu1dBlrdX+hxlE4Hn974JHe+T5iC IAjlCa1PSkSYFiRtOXFVz17u0CpHy7I9H1zljVB5uGA+SJUFVz4SLMQX0g9GEAThSsHZb5Scqy9a ZYYv/PR30b0mVF6uOIGkLTbawZOBBVosOYIgCGWHfj2jR48uUafS5+h0zuKXI9q/S7h8uOK62ARB EARBEM7EFWdBEgRBEARBOBMikARBEARBEJwQgSQIgiAIguCECCRBEARBEAQnRCAJgiAIgiA4IQJJ EARBEATBCRFIgiAIgiAITohAEgRBEARBcEIEkiAIgiAIghMikARBEARBEJwQgSQIgiAIguCECCRB EARBEAQnRCAJgiAIgiA4IQJJEARBEATBCRFIgiAIgiAITohAEgRBEARBcEIEkiAIgiAIghMikARB EARBEJwQgSQIgiAIguCECCRBEARBEAQnRCAJgiAIgiA4IQJJEARBEATBCRFIgiAIgiAITohAEgRB EARBcEIEkiAIgiAIghMikARBEARBEJwQgSQIgiAIguCECCRBEARBEAQnRCAJgiAIgiA4IQJJEARB EATBCRFIgiAIgiAITohAEgRBEARBcEIEkiAIgiAIghMikARBEARBEJwQgSSUI4Y1vbgYRunHKW1Z aVuUuv5pjuGKsq4vCIIgXFrcVEUtNbVQfhTGInH/Anz+0z7s3H0Qvdo1Re+OV+G3ueuRmZeB9Ew3 BNdsiltH3o+mwe7wsTYrxshA0rZVmDBpHhIy8lEAN7i7ecA3oCo6Db4H3VrWRLAXkJeXhw8/+hA7 1m2E4eGOBldfhWcefQxBgUGI2bENP/zwFWL3HoF/gB8G3DgItwwdjMLUKfhp4nYsWLwX4eEh+Pe/ /w0fH5WCwn2I37MQXzDNu/bh5psHY/jw4VaCyAkkxazGN19NRlyWJ9x9glC7ZiAaRnpi4cKjuPnG wRg4oLu1riAIglAREQuSUM4UwSjKNwXMhPHj8OFnX2HO8s1ISElHVm4Bso/vwu51M/HVzytw+Gi2 tY3mODYsmofvx87GzsQUpGVmIyc7B9nZGUg7Hoelv32Hhau2qLXUk4AKubn5yDwSg/XL5+GrX5ci u6DI3Ety/C7M+fkzzFm/H3HHMmAU5pvxMPLg5mZgxcqVGDNmjJlGB4VqWb7aXy5++WU85s6da8U7 iF+3GnPG/YgtCck4kZGFvPwCpByJxYaZX+CrT7/DijU7rTUFQRCECgstSIJQEejbu4cRULOp8ez/ fjPicqzI7DXGoh9HGl5VhhuLlu+yIh1kbPvSeHzEHUZ03xeNpfH5VqyDorTtxgfDrzLufPqvxrsr kq1YRfpaY+r3bxldhvzdWLM3ySgycozVf3xhPDOwk/H2jN1GXLa1no2PP/7YCAsLM9LT062Yk7Ru 3dp48MEHrV8Ovv7bC0a/BvWMn3elq707yEnaakx4tq1RL6Kn8e5HU61YQRAEoaIiFiShwpCekY3r u7XGf58eggjdl+bbDoGNb0ZB6kwY+UesSAdjnv0C/lXr4T+/jkbXCE8r1oFbUDT+8sMX8MnOwozR H1qxisC26NPnWvxnYBqef+sXPHbrrZg3fwmCH/gG93VvgLq+1no28vMti5ILioocVig7KYVAbGYe Uo6lIteK86neDENf+wD/eftR9OoaacUKgiAIFRURSEKFobDIQIC/QxnZC6a7bzUYhSlmV5ydBYez 8eP33+GNOwfhhv790O+663CdGdR8v/4YPOR5fPvlx0iJW2Jt4cC/Tlt0HDACUZt+xKzZ8dhZ1BFP Do1GtcCSIkujHiTK5E7ev297DL+2CX4YNRw39rkOAwYNwZ0jHsIr789GVpXmCKnTyFpTEARBqKiI QBIqDG5uSiQVnmqR0a8RcLmdAiWo/Lw8EOrvDQ8PT3h66uChfnsgvygcA2+8AXfffb21hQMjPwMH 9+5BcK26iG7ZGAG+7ti2LdFaeio8rIf64+7ulACFu7uHNXeSFt164OEnRqJDZHUEuOUiLTkJB/fv wZb1azF1ymzs3h1rrSkIgiBUVEQgCRUed0sZubmVLK49avrigQfvx39+nYRpM2ZgxsyZmFkcZmDm 9D8wbeoUPPPMc8hVYkqzZ+UsTPribaQOeAXPvdAPnapuxV8/+BUxB+nOfSpBnm6o7uWOpGy7eDOQ l5mK/NzsU0RSemEw/FoOwoc/TMTM2bMwecJP+PA/L+OBgVGY++2HWDV/nrWmIAiCUFERgSRUGNzd 3U3LjzNeXl4lpppn3r4HR08kYuR972N7uhVpIyd5P+aN+wjfff8Z1uc4BNKxP8dgyh+/Y3r4KPz9 5mboN/QhDBg0FM/VWYJH35yA+VuSzPXstAjwRO8gT3y1KQXxhY64zKRt+Orl23Bw1074BwU7Ii0+ /t+X6HntMKw6XADD0x/hdRrhmi7d0KtDG4RWbQHDPcxaUxAEQaioePxTYc0LwqWncB8S9ozHm+9M wMRJfyAhPg6Zhjuyml2NWl4bsXr+7/jHm19h964dSDgQi6TQ6sitH4UGnoBPjUaoFRIE/9Q9mDd5 IqZNm4bpM2ealqRZM2dj0eptOFEUgsZXdUCTiHB88PabeOOt9zBl0Ub4BgTg0duug6+vL3buO4iP PvsG82fMwop1S+Hl5412V7W0EgiEVfFGcFUDv//yG+ZPnYY5M6dj3tJNSA1ujuWrVuLg7h1IgQcS Iq9Cq0BvTJ2yEJMn/oF2dQswe/Ys/DJhAiaM/x1zNxzB1TffgZsG90S98EBr74IgCEJFRASSUM6k ISP1ELbuzEKjRlFo0Twa4TVrod7VbVHPJwWH4w7j8DEDLVs2R52I2giPaoI6kVGoS39qtwDUqlMT DcI8kXjoKAxPL3j5+sFPiR5/P3+EVquL6Ks7oO3VrVHbzw0bN6xBlnsImjS/Gtd3aYZ27drD29sH JzLykJhmoFX9MFSpEY6oJs1wTYtoR/IU3qFhCK9fG5kH4+Hm4QkPnwBUq1Uf7a4dino1wlC/VlVU rV0HtVq1RWSAF4oKilC1agg6RVdHZl4RcvLy4e7lj5CIFhh+7824umFVlLSFCYIgCBUNGUlbKEdY 9E51fL6UsPi7OXt/K0qLPyO8nc5lO0EQBKFCIQJJEARBEATBCXHSFgRBEARBcEIEkiAIgiAIghMi kARBEARBEJwQgSQIgiAIguCECCRBEARBEAQnRCAJgiAIgiA4IQJJEARBEATBCRFIgiAIgiAITohA EgRBEARBcEJG0hauaDIzM5GbmwsvLy8EBgae2+dFBEEQhMsOsSAJVzT79+/H6tWrERMTg4KCAitW EARBuNIRgSRc0Wzbtg0zZ87EypUrkZ+fb8UKgiAIVzoikIQrmqKiIhQWFprz0r0mCIIgaEQgCVc0 2mrk7+9vTgVBEASBiEASrmgokGhB8vb2FguSIAiCUIwIJOGKR4SRIAiC4IwIJOGKhm+u0Q+Jr/kL giAIgkYEknBFI11sgiAIgitEIAlXNBRHHCvV09PTihEEQRAEEUiCIAiCIAinIAJJuKLJy8szrUi+ vr7SxSYIgiAUIwJJuKKxO2mLQBIEQRA0IpCEKxoKJAYRR4IgCIIdEUjCFY2Pjw/8/Pzg4eFhxQiC IAgC4GbwFR5BuEJZv349UlNTER0djerVq8PdXZ4ZBEEQBBFIwhVOVlZWsZO2DBYpCIIgaEQgCYIg CIIgOCH9CYIgCIIgCE6IQBIEQRAEQXBCBJIgCIIgCIITIpAEQRAEQRCcEIEkCIIgCILghAgkQTgH 5OVPQRCEyxsRSIJQBt544w18+eWXp/80yRnEk2grQRCEio+MgyQIZYAjbjP89ttvVowzvJ3cUJSf jyMxy7HmQArSMzMRGBiC0Prt0CW6Gjw93a21BEEQhIqKCCRBKAMDBw5EZGQkPvzwQyvGNcf2b8Kv 77+FqfsykJmTihD/EAQ1GoS/PncrWtSrYq0lCIIgVFREIAlCGcjMzDS/18YP3JbK8XmYN30S7v+k Kn785AH0atcIu5fPwTd/eRCpz/2E26/viV5h1rqCIAhChUR8kIRKzFlq+zI+AthXd35+CAgIMMVR UVGRFXMqB+ZvRsz0jWjyxFDUjW5kxkW1rIuhI6OwdvJ2bP0z3owTBEEQKi5iQRIqAKoIGtnYtXkj 9uyPR3JmPjxUXF5OHsIbtETT1u0RGe7m2menIAPHDsRgyZoYpGYXmsLFPyQcVes0Rc1DG1C9VRuE Nq6HwuS1mLfkMGLjjqFJ/aq4rmM0Zi3eiuSsfBjubvD2CUT9a3qidYMq8Hf6Zu3evXuxbNky82O2 x48fR6tWrdCjRw9r6anMeP2vmPzbJLScuwV3VvNGuBmbhOzDY9Gy7w6MuPdW/P2l68xYQRAEoWLi 8U+FNS8I5QQ1ehoWzZyCmbPmYsXaLdixbTM2rFqC9XtTkIzq6NGqpos3x3JxaMsKzJ48ET/9MRur 1mzApo0bsPdgAg6n5mH926PgV6cR6rdrgZyESfjiu8V44833sXnVn2hVJxjfTZiBFes2Yuu2rdi2 fQfiUjwRXqM6alcLLGFaXbt2LT799FPs3r0b77//vvn1/yFDhlhLT2X63LlYsnk7nnrqSUR4eSix R3xQZAThw0++R+urItCrZ3szVhAEQaig0IIkCOVPkRGXdMJIPJ5m/VYU7jT+OupRI7JZL6OgoMCK PEnR/i+NZ+4fakR1GmlM33bEOJGRYxQWGUb2iXhj24wPjDqBXsbo0e9YK+ebkxH33KnUmK/RvMco Y17MISPN3G22ceTAauOlnvWNe//vU+On/WonNnjs/HzH9m3atDHuuusuc740/v7SC0bLyEZGakHJ /eTnJht160cbr/3jP1aMIAiCUFERHyShgpCL3QvH44NRD2Dw9X3Q49oBGD7inxj/+1wg/7C1Tkm+ f308jiMMt77+DLo3qYbQAB+4uyn5ExqByA434+mbhqJzo/qOld08zYlSUAhs0Ah3/etRXB1VG0Gm eccX1eo0xcP/uANJGzdh4dd/mOtqPDw84Onp2J5Tdd+Y86VRqBYXqnW8nCxebm5eUEJNJaLAihEE QRAqKiKQhHKnICsVuyZ9hN9mLsemo0B4rbpo3KgeatdqiICAECUs8qw1S/LLoj3wCw7DA9c1RpBD vygc4sWnan3c+ehItG7X1vytyc7JQ6OIKhjRKwpVi7dRuAchsveDKExJQOIGJcpKgT5Opx0kUuGv VJqfCicKimwO3waKCo7D3SMAbu6neQNOEARBqBCIQBLKnfTkZPz4f29id1Ywej78d3z8+ff4+ovP 8N7b/0L/Pp2Rk5NvrVmSw6r4ensAda3fDk6Kl4juPRDcgG+R2WUK4FlkIMjx0wa3q61CnhJAJ8yY c6W2tzsiVMI2ZuUj04pTZ4n8zE3w8K4Ld+9aVpwgCIJQURGBJJQ7qXlF+G53Dobf3gejBl8Ff29r AfLh41tY6qc5eoX6ID2nEFMyrIhSKLKJJm8PN8Rm5OPHg/nIsr+pb+QAxyfCzSMM3sEdrMhzo2Ww D1qH+GBKQhaO6960/KPIPDQF3qFt4R3U3IoUBEEQKioikIRyx0/pl04+hdh1NB87rTgUxWPC689g 8hffICA42PQDcubJV29E4dF9ePepj6D0VQmO712G95+5C69/Ow5zjluRCu8APyRv2YzfHvsnNsSd tO8Upe3GWw++Cb+GTdDz4Tus2FOx+yPZsYu46Gsbofl1dTHt9cnIPuboHsxKTMekf81E/RtaokGv JmacIAiCUHGR1/yFcsfTrRDh7oexds9BrFy9HfF7tmPDqrU4nOWPrfuPYPeeGFQLD8cBzxrwDAhC VR+HRSisYS0Upefg2K5t2LN3FzasXYu1K1dg5YolWB8Ti5QCX9Rp0QbNIuujpmWV+nXS7zgSuwcP 3NBW7Xc71qxfh3WrF2Ph4pXYmRSEPrcNxw19miPM0mN5h1Zjw4p5mDxvNbZs3oQJEyYgPT0dwUFB WKGOtXrjCbi5+yOi1slOO+9qIXD38sWeuUtw+Fgc9u7fisULl2HdXn/c+NBw9Lq6FkLk0UQQBKFC IwJJKHc8fb0R2bEJYlcvx+ZVqxGTmILjyUW49sHnEV6nDpJ2bUZGVhZO1LwKdSIi0CDQ6jJTgql5 VD31OwXzZs3Dlh17sSMmBgcTjqEguBEG3PcUBnZqirrFXXbA2LETEBRUiM++eAnLps7AmrXrsClm P5LSPNH7kVdxa8/WiPA92SWXF7cYq5cvwuQ/Y3Agdr9pQQoMDERS0mHs27cPew/6ICKiDlo0q2Zt YQDuYQgJa4j6RZuwcPMurFmzBhn57qh7w5N4pG9zVPflMJh2bylBEAShoiEjaQsVBueiyLfFHFFW vPrtWlQYLv2UXL1tdssttyhxk4SlS5eav0scs7T9q3Vc7L6YUt9qO2U7tX9RRYIgCJUCMfQLFQYK DXtwxNnizRhXlNxOBwclJYq3t3cJH6IS21hxp2Bfx0UolVPWteIFQRCECo9YkITLn6JEnDg0DZ9+ vx/vvv8VCvJz8NBDDyE7MxPd7hqBnj26oI61qiAIgiAQsSAJlz9GBnJSN2D2rKmoUaMWmjZtiqlT p2LG9GnYduAQ0q3VBEEQBEEjFiRBEARBEAQnxIIkCIIgCILghAgkQRAEQRAEJ0QgCYIgCIIgOCEC SRAEQRAEwQkRSIIgCIIgCE6IQBIEQRAEQXBCXvMXrliys7ORlZWFgoKC4m+s+fr6WksFQRCEKxkR SMJlTVFRUYnA4k5BlJaWZn5s9vDhw8jMzISXlxcaNGiA+vXrIzQ0FO7u7mbgJ0Kc5wVBEITLHxFI wmXN/v37sXPnTuzZswe7d+82A+NSU1NRu3ZtREdHm5ajxMRExMfHmx+y1WKJoWHDhiWmderIR0kE QRCuBEQgCZWeEydOmOKG4dChQ+Y0ISHBFEHsOvP394efn5/ZfcbA3xRFVapUQY0aNeDj44P09HSk pKSYISMjw+x+y8nJMUNubq4ZGJefn4/g4GBTXHHbWrVqmaFmzZrmlMcRBEEQKj8ikIRKAYUKu8Uo ejjVQYsaxtsDl7E7jMKF1h92ndWrV8+c1q1b17QSnQ5alLTY4lTPM563TEhICIKCgkyxpKc68DcD RZjzvHTRCYIgVA5EIAkVBvoIFRYWmsE+T4tObGys6TPEwC4yBnabcTmtOfwAbZMmTYpDVFSUaSG6 GFCA2dNhD/RpohhidxyFGEWZfUorE61Y9GeidUv7N+l5xguCIAjljwgkocJw4MAB7Nq1y/QTsvsM sQuNIkhbgPSUlqFq1aqZXWYUGJ6enqZliFOGiyU2eMvQ0ZvijFMd+JvdcEePHsXBgwdLdPnxN61P 7MoLDw9HZGQkGjVqZJ4Hpww8L1qgBEEQhPJHBJJwSaFAoBCKi4szhQOnFBHHjh2Dt7e3aX3R3VEB AQFm4HxYWJj5dpl9ylARLS60ftm7+uzz7A7kW3N6iAEddByFHkVfRESEaW2iMNShevXq1hEEQRCE i40IJOGCQ4dmCgK7f5CeUiRQJOkpA7vQWAwpCGhFsVuKzsZfqLJBQURRSEdyBu3jRAsT84VC0S4Q tWjUYpFWJu0DZfeFEgdxQRCEC4cIJOGcoJXEuZuJcWzg2djTZ4g+OZzqeTpa0zrSrFkz00+ocePG ZqC/EOMFB7SqaR8nTrX/FePz8vJMx3MKSA45QAFJaxPFJKcUTBSU2q9Jdz1qHydBEATh7BCBJJwT 9KmhvxDHGNK+Qjt27DCtRPSxoX+QDvSv4ZSvxdNfyFXjLc7JJ7E7qOvAOA4xwPzVXZPat4nzDBzD idYnOogzz/WUeU+fJwooyWdBEISzQwSSUCr67TF7I8xw5MgR800sdu3o7h171w99hDi1z+vRqYXz h75KrroqOc/A68bAOPo26WX2MZxofdK+TZxnkM+sCIIgnEQE0hUOG02+JZacnGwG+grxNwMbVrsj MQMbZ1o02M2jG1Yd2M3DQReF8oWWJPo20adJB3Z7Hj9+3Lx29FVyFejjRCFLEaWFrZ5nEOuTIAhX EiKQrgB09wz9hDhlYENJAcTGlG+V0d9Fv13GQKFEvyCOL0Q/Ifv4QvI2VeWFliReZ+3jxPm9e/ea gQLZbmFilxzn6efE31WrVjWFlB5GwR4uN0d6QRAEEUhXAOwis48rRN+hmJgYUwSxa4yiR/sKaZ8V Noi0KNBqoH2G9FQsCZUX3u4UzM6B8bQQ0tqku1S1YOZviilaD/XI5Lqc6EAfJ5YlQRCEywURSJcJ bNzYoOk3xvQ8/YX4dM8uEj2GEEeY1t0m7EZx9iNioFVAuPKgZVH7MDkHWp/oJM6g/ZoosvWUZYZD NdDipK1Q+i07CitBEITKhAikSgQbLw6oyK4Q+pPYp3y652v0nOp5BsK3ythI6aAbLnHKFcoKnb75 ORV2zXJKi5OeUkRRjNMPjW/Tccoyxnnt1E9Brgf51IKdU3bdCYIgVCREIFUw2N3BsW50oL8Qp2yY aA3SXR58xZuBzrf8tAX9gthVpscVYpcH5+XJXbiUsEzSgknrpbZmckqLJgU+h3rQb8/pwDJKyxMt lxRYDBRVep6BXbuCIAiXEhFIFQw+idNPiOML0VdIBz6x8ymbTtP0/6AA0kKI491wGX2EtM+QfSoI lwpWJ9qnSU/1PC2d2q+Jokn7OVFE8a07jpHFsuzs48QyTquniCRBEC4lIpDKAbu/kA58i4giiKKG bwsx0FeIQf9m94T+7IT+XhmnfMIWhMoAu31pDdWB9wK75jhP3yYOL2EfakL/5nJ2x3EoCYolPWVX MQPFlSAIwoVEBNJFgq/Us3KnzxC7wBg4T58hNgq6+0y/fs/vl1EcsRFgt4Pzh0ophAThcofdyAza z4nznPLeYRedHlKAQQ8xwO44Tps3b462bdua1idBEITzRQTSRYCVOl+rZ9CvTdv9hfSnONhFpgO7 zsRfSBBKh1Yku0+Ttr5ynvdW79698cADD6BPnz7WFoIgCOeOCKSLwCeffII//vjDfP25RYsWJfyF KIw4vpD2p6CPkD0IguAaXVVxqgOhfxPFE62xfHOOXdGCIAjniwikiwAtRuwSYMVNPyH6R1AUMbA7 QBCEiwPvOXZVC4IgnC8ikARBEARBEJyQRy1BEARBEAQnRCAJgiAIgiA4IQJJEARBEATBCRFIgiAI giAITohAEgRBEARBcEIEkiBUIvT3zYQrD7n2gnBpqYQCyXUFIRXHRUbyt9zhN8kGDhyI2bNnWzHC lQJH4B8wYAAWLlxoxVQ2Tl9/SPUiVEQq5ThIBUc2Y+faORi/PAUnUtIwaNBA9O/f31oqXCwyDsZg 4+olWLAnHb5FaQiq1wGt2nRB1+gwaw3hYsLvk/EbfZ9++ikee+wxK1YoL1h1XqrR7/k5FY7C/+23 3+Lee++tZKPus4lxQ1F+AQ6umIyZWxOQlJyC0JBQVGtxAwZ3bohAP09rLUGoOFTKLjYjOxmp8duw fsN6fPLJR5g2bZq1RLh4HMeqRfMwYfxMbNi6Fdu3b8b8yb9j5pRZOJQHFFprCRcPfkaD3xvjl+yF 8ocihd+GW7NmjRVz8fDz80PPnj0RERFRCT9JxPTm4tjBtRj70x9YtGQ1tu/cjvUrl+GP737Gqt2H kG2tJQgViUo/knazZs1w7bXX4uOPP7ZihAuOUYSsDf/AU58cxj63Plj41XAzev6/R2Lyiq0oemES /tUxHOE+UsUJVxYvjBqFX375BbEHDlRC4XLpMJLmYdHMHzDsy0j8/L8H0bddHZzYtxmf3dsPMXd8 gptuHoKhdd1FJAkVigtuQTqT3ro4euz8bqvS0lTWtJ7PuZ3LthcnL0+i98/p8vfnwzOsCjo8c6MZ R7oNb4mre0ZgzlvLkJXMZ0DhQlPaNabD7qWmqKj08sZ0nq48nm6ZnbNdr6Lg4+sLt9N8++18zqe0 bUvGX+L8OsfziV28B1t+2YSOL9+Kas0izLiw2qG44+9dsGf+XmyZtuuSn8qlZN++feYHyhcvXlzp yviVzEWxINHs/MMPP+DosXQE+LijW9eOGDTkFmspsHPnLowb/yuSj6TA29cD113XCT27t8Onn0/A vgMHUTs4AI2qhWFP0nHU7zMYVTxykbp5KfZluCE7PRsNr+6Bbtf3Q9MQWpCiMXhwH7z99puY9NX3 2HM4BRm5+Ur6+cAvrB6uGzIUreoHwcc8smpUshZj5rxtmLsoDh7uRXj55ZdRtWpVtegIUg8vwg+/ xmJbTCw6dGiLBx54wNzKQSayErbhp++nYN+JAhjeQQivEoCoJl5YszoZV7fqiNtv7Wete24ciz+I ueN/Rnx+EQ4kHEbr1q3w8EMPYe/KmVi0djtij6TBx8sTBf5RGHJjD7Rq6qhokBWLRbP/xJot+5Fh eKjzckOR4Yl6zdujU+9rEa1Oj/BCF0vJokRs/PNPzJi9Gifcg+HrE4CGDf3g5VOIDetz8OzT96Fu nZqOVQsL8XKbpigYdCcGvvE6+pqxZC1+GzcdI547hE0r3kSjBtWs+MpGEXIyk7B09ixs25+E1Mx8 eBiFyMsz0KzHUHRo1xqRVh46sOVkxgGsXb4Uc5dvR0a+m7qhChHWsBXqVKmOhnFLUWfY46heKxvx 2xfjp9/iEH/oMO68oS2iG9TEt5OWI8fDE4UFRQiLaIxWvW9CnyaB5m7t12rKlClYu3YtvLy8kJiY iIdUmWjTpo219EKRgqQd6zB+7Gwk5HrB3TsQtWr6o049TyxbehyDBw5Azx7tVJ7k4asvP8a2XbHw cPNCdMM6uPfBhxEQ6Eh3VnY2vvrmR8Tu2gKjqACNmrbAIw8/bHYPqsxC+sEtGPvDNOxPLTTvoepV 1b3e2AurViajY/uuGHJTH3M/9hzIT1iDSdOXIObAMeQXusHb2ws1WvVG/eS9qB9YiFp3PIxQpVEc MqUQuYc2YtLURdiTkIzcQpgNk7tPKNr2uRGd2zVGuJe5otrxBmxYux6TZhzEiRPHceeArvD28sGf a2JguBfgRKonmnbshmsH90CE2vnJxzCV9rwEvP3fb/D556znjmDIkCHmR3ILC/PVvecH/+Am+Mff HkCdiHC1fhEK8pKxfM5sbN4Vj+SMPHiouNzsfER2GogOnTsjurpjz878/vvv2LBhAzw9PZGUlIRH H30UrVq1spZaFB5AYuwy/DjxAPbHJaJH2yZo37IJpi/ahJyCbGRkuiGkdhMMuvd2NAxU+WdtVoyR gaSYdZgyYwmSsgpRaKhy7OYBv8CqaHf9rejQNBwBHta6irWzp2PdmrU4bLjjsCqPf3n2WTRrUAPL pk3CkphE5OVmo8irCqrXb4X7b+8JPx9PzPrfO/h5zEfouXArBtUORg1zT6koTJmMNtcuRJ9rb8B/ /3N7qVa4J554Anv37sXMmTPRtGlT7N6921oC0x9vzJgxJbZ955138NJLLxWLkbfeegsvvvii2TY1 btwY+fn5FfajxnTGb9CgAT755JNS80O4NFyUEpKTm4e9qgAv+Oq/qgGegc1HTlhLHGSlHMDmFWPx 0cTlWLBmB9JS+OX7XBxKOIRPPv4Yn339LXbGxWH/7lX4cdyP+HLs71i6LkYV7ljE7V2DmbPnYuzk jea+fH19sG/7DiyeMhXL1m3Hrj37EBsbi317diJm/XL88fN4LN+4D1nm2upmKTqB9LSjWLDgT7z7 7ruqYtRpy0NB7hEcPpygKr3P8NNPP1nxDk7s34kF47/G4nWbsHXXXsQqIbdv13asmj4G/3nzA0ye ttJa89zJy81BUlwsEhMS8IM6/ntvvYFdaxZg0bLV2Lx9Nw4cUOelnkQ2xRxCclquuU1u6j5MnTAF sxeuxpZd6txVBcB8OrBvJ9Yvm4e5UyZjx/Fc5KpTt99qu+ZNwfypk7Fi627s3rMXBw4ewo51czD1 h/fw/jtfq2tx3FrT0VStziyAr5uB9o4oixZw866HgswVqjHMseIqI4YSgblKvCQgPj5BlYEkHE6I x6H9G/DT+MmY/ec6az0Nc1K1vDlxmK/K3W9TFmBdzB6zAmcFzLxfs2gmxrzxL3OfHmrdvOwk7FPL Pv/sY7z33ieYPnOpul57VZwq03F7sWnNUsyYMA5r4lJO8cc4duyY6aQbExNjOmhv2rTJWnLhSNy0 GvN//RFLNm1DzG5VvuMOYc+2tVj6+wf479sfY9nKGHM9NjiHDydi+vdf49sxn2DB3oPILTjpgVZU mIf4nXPw5feT8M2ExaoBPVRs7UreE6PuoW+xaP1m6x6Kx95dW7Fq2scYre6habPW2AwUzIEsHI9d hZ9/+A3zl29Qooz5uw/796ltd2/Gb999hglffwn1uOLYRD3EJO5ahZ9++B1/rtqM7db6e/fuwe5t azD3t19V3bEKSSq55hZGOrIzj2Db1m0Y88nH+PqHcVi6djN27o8zu8x2b5iFWdOn4dfZ+1BYwnpG a1mOaqR3IenIEVM0btu2DVu3bnVMt8UgZkcsclU9qDGK8pGg8i0+/hASWb5UviQe2IyJv03F5JnL bOddEl77OFUXcr8UAZyeSg7yco7goHrA+vzTj/H+/z7BvCWrsG3PfnUdVT21bRmWz/8N3/6+HkdT HPXGSVKxbfkiTPhlJlZv2Y09e9U2qv6Mjd2L3Ts2YP7v47Fs4x4k2wyWacnJOBwfZ5bHzz/7DL// 8AU2LFmIxas3mdsfiN2HHUpAx+w9qvLNseFB9dAXk1OEzv7uOPmsEQj3gG4ozD+AwtyTgseZpUuX Ys6cOZgxY0axYNCWGIb58+erB+S3zXlyww03mHGF6sFOr8M8rCzwPOfNm2eetz4noZxQF+DiUJhn LH68k/HBV2OMiclWnEVB4mJj88S7jH4frjXm7yuwYh307tHd6DTwFmO3+Wu70a1dpNGw3QBj7Lo0 M8YwdhivvvyMEdl8mPmra/cuhqd63r+pz/3Gz8vjjczi3WUbxzf+btzdvK5xzxOvGlMSiqx4B9Om TTPUU5mxZ88eK+YkgwYNMvr27Wv9cjDz68+N68JDjC9W7TeOWnH5aYeMyS93NKJqtzFGjvrKir0w PDbyCcNXXZ7Hr29vvPDhJGNDvD5/wziYlGtk5KqZjJ3G5ml/M2pF3WiM+mi2cZBxxWQYK8f+03i8 TxPjoXGbjG3HS+bz013aGCPuuMeYa7s2BxZ9Zvx9cKQRUvNmY93GfVasul4FBUZ0vbrGq6++asWc 5PfffzW8faupfDy5fmWkoDDf2H3wqHEiLdMoUkWlID/bKEpdaXRs19G45bZHrbVOUpR9xEhc+LzR rv31xsCRnxvbT14ew0jbY0wb85wR7O1lrFq1xop00CK6sarxIo2Bj31pHLBdkt1Lfjae7lzTuOOz Bcafh/Kt2JIkJycbfn5+xjfffGPFXDi+eOFp48amTYyxu9PUneMg7cBq4/vHWhjVwrsb//tshhXr 4NdRDxiPDuxrvLU720izF638DCNj/d+M259423j8vfVWpIMpY/5n9KtZ1fhqbZyhi13uiVhj0qj2 RsOa7YznXv3BinVQmDjXmPLhXUZQvSHGh1O2GMdtt3De3tnGfQPaG106dFbXy7GgMH6a8c0bdxtB 9W8xvpy320ixrV90eLXx71s7GwN69zP+vTrZyMw/uTApKckIDgwworoOMf47aamRYsUbh74zXnvy LqNeq5eM7Jw8K7Ikr7zyitGwYcPiNJRGUVGBsffQMePYiXRz3fx8dbNmbzAGD+hndOsx9IzbJyYm Gj4+PsbYsWOtGNd069LJCKjd3Hj6/V+N/VnWPtMWG7O+esTwq3mfsWrdfkccUcfM2f2t8cg9dxjR vV8wFsVmG4XWIpJzZJ3xn5ubGHePet0Ysz7DcE6herg0qoRXMzrU8jWeeehB479TNhm51kqZOayn cngIk/++9R+jUe2axrH0TEdEMVlG85ZtjSeffrHUPBg5cqQxbty44uWNGzc2lEAy58n48eON66+/ 3lxun3eFeogx3N3dDSWerJiScBnzWAkxKhNznse2/9b7ZrpGjx5tREVFmcv69etn7pf7sP8mro7L 8+B6DJGRkSWWKcFnPP7446Weh3BpuHg2RncPdP3bSGyMycXEd0qO3bFpbQq++89mvHJ9bbRvaLPd KlS9hereQJT5Kxq5RhCuaRiM4W2CzBigKdy8AlGYvdX8VZiVhWo9BqPLG29icJta8C/enS/Coq/F O988DPfUJHz60vdWvANVGK25U1GF0po7SWp+IXalZSMl5aSlxDOoNm56+V28+e4zGDLgKiv2wlCQ nQGfiChEP/0NnhzeH60j9PkDtcO9EaDyaNPCjfjuH2Px1JejMXJkP9QpYTsPQMfhI/HEmy9h6uvv 4cBGR35pDmTlIu5ENnIyrQhFvR5D8PBb7+Pf/7gVEbVCrFgHReo+tls1NIxTcsLxo9JioDDnIBZ8 +ioeGNgFzZo0QlTLjuh1y2tYtX4dAv2cn7rVk31iCv777DhcdcdtuP/lexB98vIAQZFo2+tevHPn MDQIPzkEgrrfkJOVg0739Mfj/xqBuraiH9WuAx5760Gs+nwcdi5YZcWW5HRl9nw5kluAPanZyEjL Kb7OQfWuwR3/+h/eGv0QunZoaMU6uPHRHmjVtRG+fGYcclMd9lmSnVWId576BVdHh2HEI9dYsQ5S 1D20Wx0jLSXXYcFReIfWx5C/8R56Gjde19yKdbDgl5WYMm4THvj6TQzoFY0qtgLo1eg6jLj5Pjzb v3dxeid/PgdLF+zDyO/fxoBODRFiW9+tRns89Z+H0LtbLXz99P+QaUuzegBAXn4Bnrl7AJ4d2hXB VjxqD4dv9QbIPTpFXTzXec+6gtf19Kh7xziCZd//ByOH9ESLppGIbN4WPW58EbMXLkOg/5mtr67q JFdkqvJ1Y89r8M5fbkFdPysDgrohOGogco9NQ1HeMUecosgowpi/fIrg2lF4c/xodK/vW6JLwada G7z80+cwjidj+ntjWICtJQ5YHovyclDlhr/guqfexKP9msPbOqS/D1Ar3Ae6h0grgVN7jFQE87aU /CVz585F+/btT9vdxCEQyHfffYe//vWv59U1xX2wTCxZsgR33303Fi1aZJ6r/m2/3nTRYLcf42g9 Zncuu+/07wkTJrgsH+xGe/DBB4vLD4epYZy+zl26dDHP29W2wqXjInbCusE94ma0ztqLKrsmgM2z 2YwWrsO+1H1YHH4XmtcIgb1dISwQXqZYd1Dk5okAn5IiymCyjXRzPldVuu2b1MZdnWsh0Kfk6bh5 B6Jmx4fh6VWEuM2TrVgHLIil+Zy6KpRtrm6C+4d2xMx3n8U9g2/B8LtG4JGRT+HvH89HalAUajRu Ya15YchVFXbNqqG4qXdL1AsPKG4EiO46P5hegLHr9mPSO3/FM3fdhTtVY33bbVa4fZi6mR/FqH98 hqSYH5CbnujYyOL+ewaggWci3npgEG65bRjuue8h/GXUW/j5z0OocXV3+AYVNxMmVT3dzet3slkh eSgqzICHV7jK7JLXqDKRtns95r/9T/yyNQchV/XDAw89iqcfux+3DLoJNatVRX7BqQIpNTsfEzcn omOTCPSr62fFnqRaw2gM+cszqFLT4cdFWObyCorQtkE4rq/uVeKawrch6re+DamxS5B5bKcVWRJd mV4M+vXtgBs718WPL92HW4fchjvvuR+PP/08Rn+/Bh5KKFWp28Ba04Fv1GA0b9ga9Td8hhXJKUhl ZMFBpOwei2lGP9Ru2AYdHW5JxbRvG427B7XBlNFP4+6b1D109wg8+sRT+OenfyIzrAlqREVbazpY F5+KdQkZuLdbMzQMci5fbmh3w2D0vfNuNevIyWX7j2GvEl+P9GiI2nanGYvAqJtRrW4THNr8C4oK Tr5UYDb0Kl9rVQs1f5+8Lt5w9wqAUXDU+n0q7EI60xXJPLQbf771Gn5ZfQQejXvhngcewV8efwB3 DBmK+nUiVIN6ZoHENJ7NtS9Q6QkLDgDdrE7mgKqL/WooDXJc7SPfimM9B8zel4Jfxv2Mj54ZoeqP 23G7rj9uU/O334ERj72FCT9+juP7FltbnYRpKlChU6sm6HNVdSWKPK0lDjxs1bG/uxuCVcV1VJX/ k1JPzRUkwc1d1W/uToXFgi4F7LrWAsgVd955J7p3727Oc93atWub8+cKfX/on9StWzfz9/PPP28K Lv2badLQtykyMtKcv+666zB69OhiccbfBw8eNOftcPs9e/bghRdeKF6Xx6Qg0nTt2rXEcYTy4aIK JPXoggHt/RAdcRhfzjoE3ppHFkxDYtwOtBhxv7qhTm1YiL0a4F5OETLqyUevxGUBXm4ofahCf7MQ uqFkI8dy6aGCu1VA7birpwBnGrdujSeffQotwr2QmbQfMds2Yu2aVVi8cDFmzFyM7TsPWGteGOjz EKKewur5WhEuKFRpZzVfkJyEY4nxOBifgIQEKxyKw779R5GRHaieTK5HowYnG2py04h7cftN/RBe cBzx+3Zgy6b1WLlsGRbMXYxZ81ciLe2kFGIOtfbzRI7Kdofnl2YnjLx4ePq3VfnpcIOvjOzcGoMf vx6PWu374u4nXzSdO5995hk8/fQINGwQgRw6/TvB4sdmTRU9szFyxsPXG9WubqPyJkD9KlmA8/KL zOtWEndVrFW5c6MMPdmEXCra9+2DRx69Hw39c5Ecvxfbt2zAmpUrsGjBYkyftQQHDiZZaxKeTxia NWmBYT0zMWHBLuxKUecVuwsLf/kZDW+9B02iWzpWtdGsbRs88ZcnEF3FHRmJ6h7auglrV6t7SB1j xswl2LG7pJ8Ic53BT9VSp96lSvDUqYOwZidFVb5ay1D3hL/1+1RoYvW06oKS14Tk5rm4zlzNRR2h YQXKeuR0HNwfh+8++x5BTdtj2MgX8MrLL+O5Z5/FE088gBbRjVyWr3OFScm3+YQVc+rpmmS7uSMv Mx1ZSYcQf+gQDun6I0HNH4rHnv056NS5HW6+qbO1RUlY/0aGulsvwZROhJc7otQD7JqsIpz0SM1E QcZq9YBVFx4+pQugRo0aWXMn6dGjh6NeV4H+osOGDTPnCdNfkeGLFlpUOSOiqGJxEQWSgyZ3XY/w 9u0w+f8mqUY3B1N+P4SkzRn4x/Dq8DufcXOsm8HX0x1r40/g19gc5BeWrAWMwjxk7fkBhfluqNpw oBXrwFc90VT3dkeaaqxO4ti+IC+3+GbT5HuEwveqm/DR2ClYvHQJ5k6ZiM//+y88Paw1Vk38HLPG lXTqPl94/NIsXJoangZuaVwTf/9+Iqb/uQhLlMBZVhyWY/myJViyeAGmT5+Jlq2vhj17Mv0bo+9D f8fkBcuxZMEsTPz5G7z394fQsW4Ovvr7S0rEnhR8zIr+DUORlVeIuXEnu9OMpFWmtSO00QC4e1MI VE72pRVgSaoXRj3YH32j+dYRyUdRdiKKCnPU+Z96mwR5e2BQ/TCsUWVvkRIHJTFUmctDdmYGMvIK kGecLEs+qrwujzuBPw45dUvm7sPhnRMRWKMzfEObWJEl0WXSuWxeCHI8a6JOr/vw/R/zsJRl5rdx +Hj0S7i3fz1M+fjfWLNgnrUmcRy/ZusGGPjXB7Hyq/nYt2wj1mw/hu8mZOGVYZFo1/CUd6WQ51EF gdcMxZjx09Q9tBhz/vgFn773DzxxW0ssG/cx5k38xSFILFpV9cdVYb4YuyUBh5yNeHzLMCcLmVkq WAW7U80g1Pf3wrdbknE879SbpyhpBtKO7ESVBjeph6CTTx5nzldHQ+wKf6WOaB05UaIeUckrKkR+ nsNJ+7ASBbOPAA/f2ReDr7YeVNgtXXAYBQVZat9nrobLcu1Pt459Gee6hnrgiaeexBfz5mHJUnv9 YYWlf6o6ZLF6aPgrCtUW9lzV+6JbxJloUsUPHWoHYsbu4zisnw5yU3Bs5x/wqRoNv2qtVYTrdLsS DXYn7eHDhxen5eGHH8a4cePM+IoKR8OnpcsVrsSgUH5cdIEE7z6ICo5Gz4P/xpzV/8QE36uQEPkQ +Lxwqp1GxXl4wNNmm2VB9/Qs+YzOOJpAiX9IMHZP/R2fPfI3zN+ZbruBDeTELsYLd72HbL9QPPiW /ZV9oK56mhkU4oHxMZnYqR+4cg5j/Ot3Y9vyOQgILmmT+m3SdHTsMhh/7ktDkVcAqtVrjPbd++L6 bh0QHt4M+cb5fW7D+YY2X00+w2uobXtE46HXbsJfnxqNb6dtcbKRkTwk7lyBn//3D8zYshV2Y+/d wx/DI6NG46Cq171DaiKq+dXo1rsnOl99NeDVQOXeyQaOlU+P57oi+9gRLP3vLCsWWDFuM9bM2Yvu L/WGf1jpz+0Vnfq+7uih9N2U7SmIt+LSYlfgb7cMx8a12xEc6uh6sVOtVihefO8OrPphPL5+exxK PLMWJGPz/B/x0j0DMXreWmzKsOIVXv5+iBk7CTP/+j62pFmRip3LF+I/j32C7o/ehZZ9O1mxJfHl mDvqWnh7nyo+zrc9eO+dT3DtwPuwUT3eu6n7JaJRNDr16oPrOrdFYFBjFBjOneEKjwYIqzMMd3lO xc4p9+C7nWuQced/UTc4xKVVbfy439G5+1AsOZAFwzsQ1es3QYcefdG/a3tUqcp7qGQ+97utI266 /Sp8dO8rmLdqvyrNJ8k5tgMT3n0eo559Al/vSQezctjj16FLz7p4Z9izmLU23rTwFZO2FR+9OAZz 5sfi3o+eh1/ISUHPUaqZr46hCErCvOZ96CrPSV1PICy3AN/GZMHR6U8MZCVsx7Rxk1Xjnoi6QT64 Ltgd83elYKelo/KObcK/7x6BJTMWIyi0pL+fq0up0+jy2ltTwrRySABnWHbsU+KuhN1z79yD+MQD +MsTX2JvzqlHzk+Nw4JfxuDncd9gnRJ6+bZVTlcenQtkox4N0eq2aCx44zck73O8IZt1LBPjX52H iN5RiB4U7VIfUTDQ2kJ/nrOB3Vaff/45Ro4cWaJO5ZttFUU08ZyioqLMoQh0mjiMAYdwYH4SisLS rEzCpeOSjKSdtm8lFn7+IF6ZHYvaN76NR+55DLc3tcujAqQe349PPv8F//d/r6sKoyHe+PeneOT+ 3mjfrq3ZX/v3N/6NfiMeRIsgX/zz76/hX//3Bu4Ydg8mjP8R3a9pgRF33Ip1sYdNnyVPTw94GEUo KiiAp39d9LhpIHr2aI0q1tFIVuJubPhtDD5YlQp3L1/UDnZUjp6+wfjmq89g5GXj2Vf+hsi7HsJt davim09/xmMj/4L33xkFD0+O/3EMaelpfNkbeTU6YMC1PTC0q8O1/FyJ3b8PX372ObxUZfjtd9/h 2NGjeO6550zfk8yMDLRq0xZ3jbjXZs7OQpZ6Iv55nHqCjz+CXLWehxKXvMn4z8PDC74BQahavSY6 97sWTevXhm4Wopr1g7dHDl55fhji4pOQnJyCnOwsFPhVhV/j3hh1R1fUCdd+AaqI5O/BxK8mYdqc LQhq2gBBbmk4tDcN4ZFtcc/fnkKLQDeXjWJlIC12E1b89ik+W3UCfmE1EFElEP6qDAVUqY/Rb7wG L7c8PPnSq6jSazhuaq6W+7MSywfS92DsN79jxZZ9yPT0hp8S8u6FuXD38YVfaDiq16qDa/pej6sa 1ES4arPos9G4SVO0rl8Dd9w8CKv3JKBINVKFBVnIzXGDb3BD3PbkI7imUVUw52kBTd88Ab8v2YNt iUXIzkgxR4zv27evKs/dkJltwMO/Pe4d3gVNo+ylu+w88vjf8eXn3+OrMc8hJTUDR48mIyMzA0Ue 3iio0w33DOqO7i1O9e0wCguwf8YL+Ov/fkdClT4Y9dZXuKGBO7xcaPt33vsaL456BR/+d5TZMBxO Oob09HTTMpFXsyMG9+uBwZ3sT9CpSNy+Ft9+ORmxmXkwVHn28XCDe1E+PAJDVD1RDQ2jr0Kb3n0Q HeIFb7cTiN20GuN+moWDmQVwU/eCt7pXeazCvCwUIQzRnXpi4LABqK/adPf81diwZh0+/nojvvnm C/Tt1RN3PPsSru7fB61zF+O3KTH4z7vfYfOmDWaXWKv7H0en5o1hr7oOrJiOWZN+xpSEANQO9UeY EkNu7h4oLPJEsCo/N910A1rWLMKyn97BZ8uTUOBfFXWrh8Hf3UBo9Sh8/OG7OJqwD8+/8irCr70X A1rWRWSQG4yCHKRtGo9JS/Zh5xEDaSeOmQ0/nXk7d+6ArGw3eAZ2wP139UJkg2NI2D0PX/y8H2+8 +Tbq1KqOJ1/+G64ZNgKdA7dj09KNeHfMbPWQ9ytuGzoEfR/7C1r1VA9D1DWF8Vg6bxnmL9qMtFxV dlV5dFOBz84UW17evggMroKmrVujS5/uqK6u6+SJE7Fy9SpV/nJM35k+ffqYn0HJzMw0nZuH3Xc/ 2rV09sk8gfhtK/Du/41HdpWqCA7zQlFqKuLj3XDry8+gV6dmKG0UNYoH+hjdcccdZt3WpEkTfP31 18V+R66gIOJHnXXzNnbsWLMb7kzjIPHBdOfOnaaAOdNvpqt+/frFvkSn++3quDwPPZ5Tv379TGdv vYziidvIWEjli4tq7MITXL8eut33JFo2uBa3dW6K60qII2IoEVBo3mCDBw0yPx2Slp6hCjdwyy23 oFfPXmZFqo3YHdp3wPXX36Aa9Bz0v/5GjHrpKdxz7/WICvdSFUuuuZ8c9ajjEdYQNz78GPo5iSPi X6s+Otz7MHpFVUVVt2ykZuSoxioAV/W5Dfc99iyuu7aPaiAykVekngbV+i1bNsOdd92LhmFKnijx lJGZjsysPOT51sWtt/VD3/MUR6SwsAi5uapiTEtFr169zMHnsrKykJ2dreJzzZvrJLzx/eFf/Ro8 fPcN6NSsJjxVI5CTk2Ouy2mB4Y7A8Hpo3flaNKtZo1gckWHDh2DoDd0R4qbWV+tmZqQhPd8HNRq1 wsiH+6NGsTgi6gb1amw2zLf0b2Lme4ZqROt27I0+Q27D1ZY4uuhK+yIR3KApetz7ELrWD0WQkY20 7CJ4h9RDv3sewsjnRqFHt66q/GUgr9CwnaM646Bo3Hn3UAzp2wpBRTnIUdcuKysbhW6+qBl5DQYO vw+9oxziSJObm4+OvdrgluF9Uc27EAW5WUjPNFClQWsMeuQpdLfEkQN1vMJ85OflIkMJZFaet99+ u/lkmaIaF17n3NyCUq0bZaFHz8544L5bUcuPYkJdX1UeMnKK4BbSCPeNGIC2LsQRcXMrRKMWVZFb rQtCqnfEoEauxRFpfXVL3HX33agf4m0+gGRkOO6hAr966mGnP3qXEEfM6RDUiu6Nvzw+BK3qhcJd bcO3tDjOmrtfNbTuOQiDbuqP1qEUR9wmDA1a98EzI4eiRUQQPJTI4P3D8YgKvKuh85C7MPT2AWDv n5lEo1DdJ5nmAJx0TK5fr56qdzJNh22VC0hX92HLlq1Mx+VC1fDn5OWf4h1Wv0NnDL73HnSqrh7M 1PEyMrPNcuIZVA3R6sGtSngwPEJrq/rvEXRrUhNV1P2Wnl2o0l8LvW6/D48++wKu73cdsjJVOtUx Tu5fX3slklXZ4zW+9dZbzQY31bz2eea1LzK7twwlTHLNeuKWoUPRvWs3cxtHz2Oh2nc6QkPCzHOs EhqKDJUnxd3tHnXQrc91GHFTB1T1LEC+KsPZOSxXOchTZZUDbDa6qhOubt3OFEckryC/uDxynyyP ZppY96jAB4GS8GBhqBXVF48M74haVX1w4vgJJfBC0PGuR3Fd80amONJJcoZdaK+99lqx2Nm1a9dp xRGh2NAvNTDobjhab5g+V+KIcJkWQ+R0vyleOPikFjCn++3quDwPnT6KOfuyL7/80kyzUL5cAgsS d++sgF3FnSVM7qVW1Gd5TL7RcSI52bwxy6L6eQkCAwMREFB5/XiEM8PrXLduXTzwwIN4/fV/WbHn T3p6mnooyCq10ncF00JhUKXK+VmeinLTsPGD2/Czz22o1X0ERrV1bUfk8cpyT1zJlLV2PI/a9OJx lnXm2UJrDP12KHwu93IkI2lXHCr9x2orEjSXdujQAWlpaS79GUqDT37vv/8+nnnmGStGuHwo2XxR ID3yyCPmE/GF4vbbb8Ovv040/VTOFpa5zp07Y/ny5VbMuVGQtR83dnsR97w4EncN623FCoIgVH5E IF1AKIwmT55sfnqAfdVnC9fnuBctW576arRwGZC/DOuWTsSo1zfhzz8XokaNGmh91VWApyfue/dj 9G0RiVI+xXVW8LMKFOdlEeUsc3ybZvDgwVbM2UFhxTeF+DmbwABvZGelYsmyGNSsWRvPP/8YRo0a Za0pCIJQuRGBdIFgNp6vOfRC7EOogOSvUAJpEl57JwYhIaEoKMhDWkoKfAICcPd/3kfv6IalOqie iUtdZujbxjeE+L0uPz9/uLt7ICjYD8eOpqB377545ZUXrDUFQRAqNyKQBOGiUrKL7XJHRL4gCJcL IpAEQRAEQRCcOPvXXgRBEARBEK4QRCAJgiAIgiA4IQJJEARBEATBCRFIgiAIgiAITohAEgSh0iPv mgiCcKG57AQSv4IsrxkLwpUF73l+imLbtm1WjCAIwvlR7gKJg85df/311q/KwdKlS0t8wJDpZwWt g32ZRgs3e+B+Kgvjx4830ywIFZWFCxfil19+MQezFARBOF/KVSBRIMyZMwezZs2yYiov48aNM838 DP369Ssh+nie/OK1fR0+7fKL1G+//ba1VsVm2LBhGD16tCloBaEicuDAAaxdu9Yc5bugoMCKFQRB ODfKVSCNHTsWb7zxhjlPQUErhUZbXDhlo0whQcsM47T40JYYVxYoihJXy3kM5/W5Do9D7NsxnAt3 3nmnNefgvvvuM8URRYamUaNGpkh66aWXrJhTcbY6aXGi4zX2vCI8B32OnPKcdd7ZtyOlnS/juQ3z nfH8feutt+LTTz+11hCEikXVqlURGBiI/fv3Iz8/34oVBEE4N8pVINF6xK/fE4qI7777zpwnq1ev xuOPP24KCUIhwfVpfdmzZ4/ZaGtrDH/bxRWh8NLLydlaamjVoXCxb1tWKPz69OljzlO0cH92caTh udGyRPHhCi5bsmRJcVp4/jwPbte/f//i7SZOnGhOmWeEX2jXxyfDhw8vzjtup/OCabOfLy1EdvHI eMJl3bp1O2N6BaE8iYiIQJUqVcxyKwJJEITzpdwEkhYOWgBRQMyePbvYCkKxZLfEsPHW67ILi781 /B0XF2f9cjBmzBhrDnj11VexYMEC69eZSUhIsObOHooQbYXp0aMHXnzxRTOe+6KoKA1aaeLj461f J6Hgo0CkMNEwT/R5UABRCBHGMT8WL15c/JvWHg2tVzrvKET1Piis7PnKNPMa2NHnoWFeu0qvIJQ3 NWrUQGhoqFmHiEASBOF8KVcLkrNwoCCgFYQVHK1CdnFQVnSjr+H+zgaKNlpVdLfS2aL9iyg47Jaw 2rVrF1tiXMF01alTx/p1Egq+Bg0aWL9Oos+jS5cuxUKHcRREtBLp387n7wr6atAyp4Udg53TCTtB qGjUrFmzWCDl5eVZsYIgCOdGuQokZ+FAixHFBUXSI488YsWeP7R46DfLXIkROxQWFDpaKGmL1tlC iwsFiu7y4/4oNJy7AAkFGI/jSgjWq1fPFDDO6PPgNjwO98G80oKIx6GV52ygAKOg4/nagyBURmrV qoWwsDDznhInbUEQzpdyE0haONgFCBt9dvFQJNm7iM4Fu88Ru9jYtURo0bF35ZXmm6TTdy4w/exy 09Afir/tFikenwKMlidXsMuRDtH2bXgO+jwIhRD3TWsSoVDiubKL72zgdqdzEncF030mkSkI5UFQ UJBpQUpKSkJ2drYVKwiCcG6UqwWJDbx2LNawm41oi8j5oLuNKBy0kzT3S6sJxY9zlxIbf72N3u5c 0kGhx/PQDs88trZI6X3z+AyunLc1ztvYz4NQCFHsaQsUBQ+30Y7vZ4LbUaDp/TOc7jV+5o/9eIJQ 0QgJCYG7uzuSk5OtGEEQhHPDzSjHPhVaR2gR0X41Vxq0XmkLTmXo2mJ62e1nd4AXhIoE6xTeU88+ +yz69u1rdrkJgiCcC+VqQaIlglYk53GJrhTor1RZ/H7o28SGR8SRUJHhOEj03zt06BBSUlKsWEEQ hLJTrhYkQRCEC8nu3bvx1VdfmQ8d7I5u06aNtUQQBKFslKsFSRAE4UISGBKCBpGR5vhjJ1JTrVhB EISyIwJJEISKCY3brkJRkeugCPT2RoOICCQqgZR6/LgZ53Jd5+DqOIIgXNFIF5sgCBWPwkKAFiD6 EWVkABwZm4M/MnAZp4zjeEecMqh4IzcXO+PiMPiLL/Bi//54qG9fgK/8+/mpx0H1POjpCfj6OuaV mIKXF+DhAfj4OKb87e8P0Lk7ONixnSAIVyQikARBuDRkZgJ8/Z6iJyvLESh+KGA45XLOM7i5OUQM A4WLhvE66N96yqAEULLaT7vRo/Fkz5547rrrHOLJbhXSU1qONHo5g92yRHh8iqbAQCAgwCGaOM84 /g4KAkJD+bVcx/qCIFwWiEASBOHCQdGjRQ5DTo5jmp4OUwTpaW6uY5k9cD3G0ypEAUILDgPnafmx W3w4zynjGafjlWDhIJFdR47E4M6d8czttyM0JMSRLgoeWp94DM5rK5Se19YopoPWK51WxtHqREFE SxMD55kGiiXOM/A4WkRxfS7Tgb+ZRkEQKg0ikARBKDt2SwuhwDhxgt/14ReaSwb9cePwcH7rB6he 3SEmaHVhVxYtMJzyNwURxcZ5kK0E0MMPPoioxo1xx7BhiG7a1FpyjujuPp4frV9paY55xjHQKsbz PHDAkR9VqgARERy23xE4X6sWPxbnODdt7aJ1TM8LglDhEIEkCELZ2bsX2L4d2LGD79YDhw87GnyK AAogiqFq1RyBvyl8aEXRVh/ddcag5zllOE+KVJW2dcsWBCrhxe+z+fG45wurSQolCiBXU1qfGGh1 onN4UhJw7JgjHDkCHD3qEFUUgRydv1kzIDraEc5TEAqCcHEQgSQIwulhwx4XB/DjyZyy8afVw969 xG4ndi3RMqS7xmgZ4m9OLzFFSrjoz+dccthdSCuTq2DvdmSg5Y3dcvXr8wvVQMOGDquTWJUEodwR gSQIQknoLE0rCK0feqrnKZbYqLMRb9IEiIoC+FFnWkaEM0P/J3bF0QLHTyxxSqFEB292zXFK6xuD nmf3owgmQbjkiEASBOFkNxGdmdl1tm4dsHGjw2pEHxp2BbVsCTRv7hBE0mBfOOjDtHWrI983bQIO HnR0ObZuDbRrB1x1lUOQsvuR3ZOS94JwSRCBJAhXOrQIrVkDzJvnEEa0WFAQXX01QAdndgGxC41v Yem3x4QLB6tgXgO+LUeRSgteYiKwYQOwfr3Dh4m+XL17A336OOYFQbjoiEAShCsVdvUsW+awXtDZ mA0vu3VoMdJvYUnXWflAsXTokOPtOE7pBM8uTlr4+EZcx46OIGJVEC4aIpAE4UqCQohdODt3Ot4+ Y+NLiwV9ibp2dXTrSKNb8aBz/KpVDgsfrxeHS2BXJ/3A6NhdDo7wgnC5IwJJEK4U2LByTKLp04G1 ax2v3Q8dCvTq5ehGEyo+rK43bwZmzgQWLwZatAD69QM6dHC8RUgfJUEQLggikAThSoCWoqlTgWnT HL5F/AQHpxRJ9C8SKg90qGdXG4dboFBaudIhcEeOdDh0X4CxpARBEIEkCJc/s2c7rA20ILVv72hE 2aVW4QcoZNVUid7YYlV6qd8wY9fbli0OqxLfOOzeHeAHeumnJAjCeSECSRAuVyiIliwB/vzT4fTL bpghQxxvolUSjLx0pMWuxPKYFCQkZ6JuRG30Y5dSBSU3ORFxe7djc2I2PIuy4Ve1Eeo2bIroOhe5 C5MC6ddfHSN5t2rleNutQQNroSAI54IIJEG4HOFozfQz+vBDh5/KLbc4xjGqZBSmHkDs1L/ixR/3 4Lc5q9G8eXNs3boV5TJC9lmwacaPmDRuPOYeNhBYdAxeYdegQ59b8cKj1yHgYvu+s+vts88cQwNw eIaHH3YM2SAIwjkhAkkQLkfoiD12LNC5MzB4sOMzFpURowiFeZnw8AnCQw89hKVLlyImJqZCCqSi fR/ixf/FYFViS/z+1b0IC/bDtNefx9xVWxDy+iQ8c1UYql1s4x3HUaKfGX2TGjcG7rkHqFHDWigI QlkokzfftOmzkJGRYf0SBKFCokQEVq8G6ta9qOLodM9WXHZBnr3c3E1xRAIDA8uwT9frGUpwlcb5 pnfd57OQXuiJpg/fhKrBQfCAJ3rfHIWr2vtj6gerkXY021rzIsK32Ni9NnCgY/BPOnDzG3CCIJSZ MlmQ3nnvQwQFBaJHty5o3ryZFSsIQoWBXWtvv+3wP+Ir/BxM8CKSn5+PuXPnIiHxKDzcgIia4eh1 7bXw9na8GZej0jNv/kIcOXxMKZAiRNStjmv7dMLqtVuxY+c+eLkZaFStCo6mpsM3ohGq1amD/D3r kJRZgIysfASGVkPTDr3RtJoHnn76acyfNxtbt23Cro3rsHv/IaTnFjqsSV4haNzqajRrXAsB5pEV hQdwMHYvlq09hrTUFKUb+iCKzulGAYpytmL1+gRs23kU/n7euOWWW1SatXmnEMg7grXL1mJ33HHk efrD38cXtet4ITk5B/l5QRhyU99TrFijO7ZAQo+B6PbWaNzGzDBZhhmTpuP2p3KxZuGLiG56iaw5 /GYeu9tSU4Hrr3cM5SAIQpkok0Bav2kLVq9ag+PHkzF0yGBEN2tiLREEodzh5yr4RtPXXzsGfHz0 UWvBxSNTCbEnn3oKcydORF5hEbrePATfffoJQvg1f0Xy8aMY+dCt+G1BHLx9g3HPzW3xv/++gvc/ +hlvvzvGXP7s8FsQnxiLjIgWCI1qjbDtSnBlAykpKfANiUCLIX/DGw9eg3+88DwmTZyAhTN+wLjv f8OqTTuRnJMPA24wPKugfZ8bMeDG/ujasjZ8qE/yFmDJ/Ol49a2NWLx4gdILn6ksUXliZKMw+Xv8 99M1eOuDmcjKPIFDhw6hCj8WqyjMSUP8ih/w4Zd/YPH2ozACqiM8NAzNIw9h3p8HcCKzFfbv/AOe TmMO3diyKZrdMBijlECtWSye0jBj6u+45e4PsW7lr2ge3ciKv8iwWucHhkeNcpSFZ59VtX1JQScI wukpUxdbZKOGGKKEUUREbfz08wRkciwOQRAqBvwq/MKFjtGV27a1Ii8uAQEB+OKbbzDumcF49f5r 0e+tz+Ed6BBHJDTQAx+MbIihL7+GRz+Zik8//QzeAZF46eV/4pmnRiIgLBy9X/8YP87/BR3rFuL3 j/6H8Jtex/tf/46Ff36P5x7thq9eew2H9h9FaNVQ7I09hAeGvo7CJjfj71/8inlz5mD61Cn47cNH 4bf2J3zwl0cx5VA+stiT5t0T3W94D2PH/mh2zxXSiZm4+cGjygN44dWv8dqrL8KL35izcTzpOF57 6P8Q2GkYPpqzEisXTsXkSd9iUKMIVM8x4BvMLstTxUZCXqGqUN1Q0kYUDHfPMBTkxSvNkm/FXQIo hvjpGH5cODfX8eFhQRDKRJlHFPP19UX//teZ/fUzZsyxYgVBKHfYEPJ1b35HjV1JlwjKi+4PDkFI y/YY+/4qFOWcFALZ2R745aOt6NugCh4cpISFO7uxHNWOr58/fD3d0SEiHD7ujQDP6vBDNu7q2wIN qvsCHk0QWr0l0g6vVAIjHUa+Ejj+VVH9kefR79oOaF03FB5e3ggIDELVZj3xwFM3otM1AXjv+e9w /Ei6OoLjtbGwsFC4Ow+e6OboTqNwcianoBCrlSA7nu2JsGq+8PT2UfWeP3rf9xT+8o8X8OiI7nBz MRhjvqoTXRlp3NxUOgrVtUHp/k8XDQokWrr4aZmz7ywQBEFRZoFE/P39cMstN2Hu/IWIj0+wYgVB KFc41hG/As9Xuy/1R2brX4ua4RHwmjkGMWmZcEikZKQmLcUvCVcjolo9NHcasDu/oACeSlBUdS9w /EYgAvy90biGn/mbFLnxPJJVyEdeXgHCa1TF3ffeiNb1HFaq4ibfzQcNew1Hi3btsWbKt8jJSLUW UDfmlqoN6EPl7EsUGOiHm2/ugsPrZuG9l/6Jt95+Dx98OAY/TN+OrCpN0a5Pd7i7UELBHu4oUgfK s347MGAUZcLdMwRulmC7pNBBnxYylgtBEMrEOQkkEhUViTp1IrB46TIrRhCEcoUqgH5ITl1Gl4YQ tKwWhnubbsDkLQexhyohcRP2rPgR3rc8hoD6zR2rOUHdUmCJFzeKCTVf3BWmMIpOzheqZUFebuhQ BdDePyVlSk3At5ZaFqviS3ZnuasVXQ0N4LAEWQmwqBIWitf++hTqux/B3O8/xNtv/RtvjX5LCaXP Me6PlYg5lM2UWmufpJmfh3kuMdZvB7EozD0ET391/u6+VtwlxE+JTZ43rYuCIJSJcxZIpGOHdli1 aq31SxCEcoWNPb+rVk6+gREdo9DlheEY9/YixG5Kx+6NyZj8wQa8dmc9XNP43MSBXdN4q9M7kl2A cfuykHqqPlEiYAmyj6yHb5Ub4eZR/C6buY8gTzdTJDnj5uZ+qnXJOwAB7e7Au2PnYsuOHVi/dC7G fzsG/3r6emTvnI2PX3kORYWndpddW80feSp69nGb5Mpci7zUrfCrPgDunid9sy4ZfMWfgpNCSRCE MnFeAqle/XqIPRBn/RIEoVyhrwnHPuKr3cdVK32p8W2O6pF3oN2+7xC7/jWMPXYES6o/juZVQuBK GtCfkVYdH+tjuUVFhukr5OFxsitKv2QbGhKC0PCqyDy4Fx/d+zymL45FjrnEIu8Axr0+Bn9MWosH /vs0Qqs73kgj3koYDQoCdiXlYbmt/2vb7C+x8Of34O3rj2C1f01i4hHcPPQh/LpkO3zDqqNB8zbo 1e9G3DawF6Ii6uPo8ZJvr2l6PdIWOWnJmP/RomKFtP2PLVg9YyvaP9UX/tUu8udGXBEf7xBI9Etz YUETBKF0PP6psObPSC7N9zYKCgrw++9Tcc/dw6wYQRDKDTaEfLX78GHHh2gv6ejZVARu8HAPRFDi z5i2Yh5WpYSj061PYnDLEHgWjwuk1jNSsWz5Snz11TfYsiUGteu1Q9trGmPp0kWYMmUqateuDf86 9VEt0B8Jh+Lx1ddfq7qnEHPnL0BCXBxG9G2Do0cPYMPGjdiycQPWrl2NlYuXYvP+PNRq3Qt3PzQI EX5KaFlHZNddeFEiNh1OwbI1O3Fk12asW7McG2MOYNXmvdi9bz+qhoYivUZdhIQFIzPpKJ544kWE BXrAzcjG2lWrsHLFcqxatx1HUBNX9eqPG7pGKzFXUnAE1Q/H0QNHEbdyDY7mHMXOratVmrcjw78Z 7hx5mxKKXqZYu6RwNHUKIw4eWbWqFSkIwtlwXgLpREoKFi1aguF33GrFCIJQbrAh9PV1fLmfYokf p71kOFp+D48CRLYowOTpcfDya4i/vnIbqilxdNJUXaT+n8CPP/6CjRu3omq12kjNCkP3rm2QkX4U 69etN0frr9OuEyJrVkNOejoWLlqEnTv24nhyCm4a0ANj3nsCO1b/icVLVmDN5hjs3b0buxIL0Obm +zD8/tvRzE+/v+bA3dMDdTs1xeGYTdg4bw427NyPnbsPomabG1GlfnOkJ+5CqqrLspu0RJ1IJcxy 87F41W60jXBD9vFYzF+6GmuUSNoQm4dWfW/Ao08OQhUljk7ROt51USfADZ6pG/HL4q3YtXEFCmq3 Q6fBIzDs6uqmOHLIyEtAkcrnAwegnmAdH60dMMBRPgRBOGvKNFBkanrJz4ysXLka06bPxEcfvGPF CIJQrvB2/te/HF91v1U9uHTqdOkbRn4/jQ20kgLuHh4uBUGRWs5A6AfkwTfArDh2u7GrjVNWT3an bcZ5qGVF6hjONRf34+ZKuJgY5r7t25j7V1PDOiYdts2piisoKHT4LKlQcpvTHYPr0tHcfhzul/5P pW1xkThyBBgzxpH4/v2BLl2sBYIgnC3n5YO0avVadGh/aQakEwThLGBDPHy4ozuFI2ofPGgtuISY gsfT9CUqTRZQAHEkagaKI3ucuR3PQzXunOr19DKeo7u7hzlvD+zyKl2GnLqN6e9kOyZFjN7e01P9 Ntdx3uZ0x2DSnI/jfunFEbtZ58wBtm4FevYE2re3FgiCUBbOWSDt2bMXB+MOomePblaMIAgVgqZN ga5dAToef/utY/DIysilFhaXA/Q/mzLF8ZFaWo6uvrqchn0QhMrPOQmkrKxsTJr0B/r06YV6detY sYIgVBjYtXbzzcD27Q5rwvr15fb6v3AJYHclB4OcMQNYtw6oXh246y7A+r6cIAhlp8wCiV/nnjV7 rtnXPmigekIRBKHiwVfnKZL+9jcgJgb46CNg/nyH87Zw+bF/P/Dhh8Ds2Y7v8L38suNNRkEQzplz /pr/kJtuRPPmzawlgiBUSPj5kdhYYN48YM0aoGZN4PbbHV0vQuUnIQGYOhVYuhRo2BC47jrH1/uD y2FQSkG4zCiTQHrnvQ8RFBSIHt26iDgShMoERdKyZY6PltKKxAEl27RxBE/XAx8KFRi+wr9qFbB7 N5CZ6ehS69zZcT3F50gQLghlEkhTp89C757dXH4BWxCESsDatcDEiY7XwBs1Ajp2dIglNrD8wK37 eb3YKlxMMjKAEycco2Nv2+awCHp7Az16OMY5Cjj5eRVBEM6fMgkkQRAuEzZtcnTNLFrkGHG7d2+g WzfHvH57TN4iK3909cxxrVavdvgY7doFhIcDQ4c6rpntMymCIFw4RCAJwpUIR8XnN9toSdqyxfHm Ey0TbHhpVWJ3TWSktbJQLvB7ehs2OLpG+TZiWBhw1VUOHyNa/yiMxGokCBcNEUiCcKXDsXNoldi3 Dzh61CGe6NzNt6DY/VanjsOyVLu2+LdcTJj3HNiT4dAhh3hllyffSKQQql/fMcYVnbHlOgjCRUcE kiAIJ4mLc4yZRF8lCidaKapVA2rUcATOBwU53pJiYMNdgbri+B23zMxMcziSfCXyOEp2gEojg39F eu1dpc/sNmNISwOSkx0CKSnJMZ4RfY3oX9SihcOi17KlONMLwiVGBJIgCK5h482uHToEsxtu717H YJPNmgHNmwPR0UDjxo5uOd14UyzZwwWG1ZVz0N9wO6wE3V6VRob9+/cr3ZGG0NBQNG3aFA0aNED9 +vVVUsOV7lDCQ2F+d80W+OmRC4pKW4mgYb7SWrdjhyN/ab2jOIqKcuQpxRDzl9Y7QRDKDRFIgiCU Tm7uyUBxRL8YDkqoA7uCaFGqVcvRoLMbLiLCERh3ga0eWSoNu3fvxp49e8ygxdA+JTi8vLxQp04d 1KhRQyXrkPk7JCTE/CZaUlKSGccP39asWRMNGzY0BVO9evXMKX9TRPn6+lpHugAwr+jXxTyiVYhT DrdA3y++CcyuMn5pn4HdmLTG8fjsUmNQ6RYEofwQgSQIQtlgNxADfWQY+Pq59ltiKChwTDneEq01 /HAuu+Y45acv2G1HgcDgQpAUFhUh8fBhHEpIQIISFglqyvkj6phZ2dmmiPFW4sdH7dtHCQlfFbxV oBiqqcSRn58fJowfb1qEWrdujeYtWiitchzJyclIS09XWi8X+SqN7ILLU+nOVaFA/WY8rUtVVTqr q/1wXzWqV0d1FWpaoRhWmxx/iIFdZBRDtALxQ7EMjKNFir5COlAscsquPuYF96eDjHotCBUOEUiC IJwf9KfRvjP0W+I8pxQNXKb9lWx+S4aHB9IZlGhIV6IkXVVD6UoYpSmRckIJmRNKeJ1QQuOE2gdD sprPUmKEfkQNGzVCg8hI1G/QAA1oCVLzNe3DEyj++c9/Ik8JoOv79UMPftHeRopKZ/yBA0g4dAjx cXE4qOZpXToYG4tMJaB8lcCi2AoLC0OwFULCwxGqhExwUBAC1XEClFALVMIqQB3DDOo8gygSVbxp aeM8ux4pfui7pYUQLWzMA0EQKjwikARBuCiwYilSYqFIiZAiJUKKDh5EkRIiBUo80Sq0XwmpfUr8 7FOiZF9hIXYrkXFYiQ1/Ly9EVq2KJjVronGdOmiihFCTunXRUIkgX77qzg+z0vJEC41+y0vHKQGV q4TUvz79FAUq7trOndGva1eHRYtijdYtVnnsMiT8zXmKK1qSUlJwUKXvgBJL+1VaY1Ua9ytxtl/F 76X1Sa1fRaWvnhJ59ZXQqafSU1cJoDoqjQ1btkR4dDR82XWm4tyV+HOnb5MKlG70cLrwXlmCIFws RCAJgnBRyFDiaNfOndgTE4M9O3ZgN4Oa3793r9kNVjsiAvWVmKinxEW9WrVQLzwctQMDEaaqJG8l cjxV8Fb78FLCxUuJHU922TFQDFHscMrfnCcUOuwqU3FvbtmCbDXto0TWDfTvoQBidx/9eiiqtMBi lxcFFqtBlSZ2gxWqdQqUAMpXYsucqjQVqFAYEoI0dczDyclIVGIvIT7etEIlKrEXr6bsBlSpQTh9 nKKiHH5N9esX+zpFRUaab9MJglA5EIEkCMI5w7fHDiqxwC6qeCUYdOAbZfTp8VeCgMGPQQkOBv5m 9xVDFYbQUIQpAVKVy7Q1iGKHwoeB3VW09NAKREHEKou/uR7nGU8BxKkiT2377m+/ITk1Fd1btMBN /BQH19PiiOvSH4hTxnGey7WfEAPFEtNCIcXAecZz/+rYKWrfqVbgfEpKijmfrgKHGcjNzlZJzzHz IFvN07mcv+k4zvOuXbu26UxeSwlDOo0zcJ4O5YIgVAxEIAmCcFpYRfCVeQoATnUwxYESBnpe/2ag KOA3G/Xr9bSg6DfG6PR8MVFyCh/8739IUiKtixJHt9xwg2PBJSI9Pd0UjAzsSmTQwpHjNHFsJvo4 MX84DQoKMi1LwcHBZuBvLmPgvP7NKYcjEATh0iACSRAEUwTxFXgdaBnilG95JSYm4sCBA8Wv08fG xpqv2B87dgx8o6xJkybFISoqygzsXqK1pDxgmt9//30cOXIEXbt2xVB+s6wCQcHE4QmYj/bAPKWl iSKJwpJDFtStW9cUlhEREeY8xSW7JymUaG3im3r2qQgoQbhwiEASBMG0+rCB3rVrlznlWEOcj4uL M60bbKwperQViA04G20OxEiLiHMoz66iii6QKD45rAAFqPOUFiamm/luDm9gWaIYGMcuOw5D0Ihv 8tExnH5OasrAa8NlgiBcGEQgCcIVAhthWoLoM2QPtBCxGtDdOgwURbpbh91AFEL0neFUz1/QQRUv IBRIn3zyiSkoOnXqhDvuuMNaUjngdXLuztTdmOy+o4iipYm+TpyyO5PzjKclideG4pV+TvRt4lT7 PHHcKEEQzg4RSIJwGUHrhPYDYrD7BXGejSgbWd3QMtB5mI2q7s7hVM9X4cCOlQwKpC+//NK0grVt 2xb33HOPteTygIKI/kwUtrQyccpAKxOvMa13WuRy3Cjnee3rpP2d7PPlafkThIqGCCRBqGTwlqWV QQd2zTBQ6LCh1D4ttBZxSr8hjiJN35Xo6GjTR6hx48Zm4HxkZKS158sDjpD99ddfIyYmBm3atMGI ESOsJVcG7KLjNafPmC4LOrAc0CKo/ZrYdaoDf9PKxHJCS5TuKtWBv8XHSbiSEIEkCJWMo0ePmtYR e9i5c6dpQaCFgI0ffVO0fwqntAjRSqSde3WDxykbw8uJK10gsUrXoplBO9wzsEtO+zhRQNMCpbta WX5oaaxWrVqxj5MuPwyX4g1EQahIiEAShAoIu4n4xM+GTAc2YuxaoaDRvkG6e4Tz2lfI/lvPV1R/ oYsB844CaceOHWYX27333mstEQiFErtY6dfk3OWqu2Gd43WgkzgFFC1OHLdJ+zrp6ZVUzoTLHxFI glBOsKE6ceJEcWD3B6d8imfjxad9e6DvCRso+gXZu0YYaCGiOBIcFqQffvgBmzZtMj9W++CDD1pL hLOBZUz7N3HATwb+TkpKMq2XtDzSn4liiIFdcvbgSqjzN6e0WApCZUEEkiBcRPQr3Wy0daAw4ltH bHDsFiIGdntQKNGptmnTpqZ/kN1fiF0ewulhHk+cOBHLli1Ds2bN8OSTT1pLhAsBx7+idZNllb5O 2teNU5Zp+1t0ZlDz/K19nCiqOEYWhZYnu3oZ6POku3vZJNmDHfpAcR1OnYMgXGBEIAnCRYRP387j C23fvt30A6EIom8HRRCn9PvgPK1BfPombDC0n5AOwukRgXRxYZNB4W8PjKPw1y8KaL+mWCWa2C0c Z40kfuz4cdOPqQH9mujjpERTA/W7YbVqaFi1KmrRCqr2g1zrUzNZWY5PyrDcc+BRPz/zg8RKZZ38 BAyn3E6sU8IFRgSSIJwn7PriG0N2KxCfqNlFwSdldi3wqVqPH6TnGU9fIv2qtZ5686OqwjlDgTR2 7FgsWrQILVq0wPPPP28tES4F/GBvhroGmUrcZCQnI0M9GGTu3YsMdU+kq/skNSkJaSdOIF0tT1Hr pnl6Ik0JoDQ1n6Oao3AleCICA1FH3Q+11T3SUgmoSHVfBFMgqf2ioOBkoHjSgor3Tc2agBJbxUFt ixo1HAJKEMqICCRBEARBEAQnxF4vCIIgCILghAgkQRAEQRAEJ0QgCYIgCIIgOCECSRAEQRAEwQkR SIIgCIIgCE6IQBIEQRAEQXBCBJIgCIIgCIITIpAEQRAEQRCcEIEkCIIgCIJQAuD/AU44Huh2qR4q AAAAAElFTkSuQmCC --_004_PSAP153MB0536D3DC3F8C7E37CC121C2ECC2B9PSAP153MB0536APCP_-- From nobody Wed Oct 19 18:08:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MszHf6NXVz4gZ0G for ; Wed, 19 Oct 2022 18:08:30 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MszHf0yjyz3y3G for ; Wed, 19 Oct 2022 18:08:29 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qv1-xf2c.google.com with SMTP id mx8so11908817qvb.8 for ; Wed, 19 Oct 2022 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=uivXAbqw271scz+vsFjIiQM5xuVxMlJe6URPJdSu76o=; b=GL6DYydwf+uyL9kn+zr9CPEm2cg+aMyjIscjevf6pdICW20YR0RtN10MH8skbacg63 /EMyo3Ur0qHw/jZ4vW1nmTrl6gi3c78KTFgyCAyySEFi4WXcdKWxaajUcpylqhBT2ZNM MIRrCPb4bO5o4Zw7LB5ltSiqYHIbpDmHKS6g0xhMk8t4uPXe4UOLnlxbw5Uxz9B5oQhs uZ3ZGXgjn34/lbbvWnP5hG9nzQXPtQjvjVe2y1//SR4Vks58wimHPiHsFDiWGmyAoGdP wFMeAjLtorw3KuEyTd+bDE2pZBUE+NhoVaymu/5oxVwBiLKNILHrk7BV/1gCfftuxCp4 hnDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uivXAbqw271scz+vsFjIiQM5xuVxMlJe6URPJdSu76o=; b=d54Ux1LpEZ0L3u9Mx1SFGdab7ubI7iLm3JaKRhjTyhaDDXGpb5f/iltvOt3jsNdU4M VSw0Y4oJXxuJj96ISPzP728YNyfgYGqVdKryoah+FohRFS/Tp4fu3yMfQweSyGf8XEdp +v+gHdkKrylmSD8CDCAGCOmw9TXNlplySy+V9vav3YitfY4iZoGxPCEitbDx2sHm6Fo5 79wczjnRPHfaL4V/fqXzvr2QHcyxChYhjGFYbHmBxKHoIyB4IKPYV5bVsln6ZsOR5BbF b7z+E+71DiiGupTgEeW2mrWZRhcc8dt2sKJ4MS5a/VT+d9rPWMqYERg3IBbo6bJAi77p IB8A== X-Gm-Message-State: ACrzQf0k5BhWGqrJenXDEz2fSCwc6GoKQnxQ1CXb4nhOxeHjWEAzIzsW mz8zOtlgbQob2lz/Cd+H/pkc+g== X-Google-Smtp-Source: AMsMyM7CrxQGihMBadbgSd6II2yfnEuSxJRZq2XGHU3Lfdowl96V8R2FgNc69kTjw4ioOuzH/8KBMQ== X-Received: by 2002:a05:6214:29ef:b0:4b4:5d8c:637c with SMTP id jv15-20020a05621429ef00b004b45d8c637cmr7763621qvb.77.1666202909154; Wed, 19 Oct 2022 11:08:29 -0700 (PDT) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id j4-20020a05620a410400b006eef13ef4c8sm4165636qko.94.2022.10.19.11.08.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Oct 2022 11:08:28 -0700 (PDT) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-345528ceb87so175806407b3.11; Wed, 19 Oct 2022 11:08:28 -0700 (PDT) X-Received: by 2002:a81:84cb:0:b0:355:d2be:a314 with SMTP id u194-20020a8184cb000000b00355d2bea314mr7544880ywf.3.1666202907715; Wed, 19 Oct 2022 11:08:27 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Tomek CEDRO Date: Wed, 19 Oct 2022 20:08:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: proper python3 interpreter invocation To: FreeBSD Questions Mailing List , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4MszHf0yjyz3y3G X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=GL6DYydw; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::f2c) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from,209.85.128.176:received]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[cedro.info]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N Thank you everyone for the replies and hints! :-) 1. Python is not part of the base. Needs to be installed from ports (various versions available). 2. Safer invocation is `#!/usr/bin/env python3` to be sure that Python 3.x is involved. Metaport python can create /usr/local/bin/python as last resort. 3. Initial patches to Android NDK sent for review :-) https://android-review.googlesource.com/c/platform/ndk/+/2261302 https://android-review.googlesource.com/c/platform/ndk/+/2261303 https://android-review.googlesource.com/c/platform/ndk/+/2261304 This should enable using Linux binaries for build, for now, first step towards native package has been made, that should also enable scripted builds of Python + Kivy + Buildozer, work in progress :-) Thank you :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Thu Oct 20 10:43:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MtPMl5BN7z4gTRS for ; Thu, 20 Oct 2022 10:43:31 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from fry.fubar.geek.nz (fry.fubar.geek.nz [139.59.165.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4MtPMj6N1Jz3Xjl for ; Thu, 20 Oct 2022 10:43:29 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtpclient.apple (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235]) by fry.fubar.geek.nz (Postfix) with ESMTPSA id 908DA4E630; Thu, 20 Oct 2022 10:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; s=mail; t=1666262603; bh=yq3fGugMW3Ql/oEZWh0+dfaVPuAd/Nja2FdVsdnRWeU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Qxb8zLM8vxAdMv45A7unt5I+qbmJ0fK2fhgAr18QQD/EhdzBgjnftGUpTe3mC6E4o tiRhjxiHrBbXBwnTxLXwa2U5nw4gezxmq52444NNXdpadldn4v8JScV6Av0Btnco5p XI7sDfecdximGbNmhPrcxdjwRO2HjTd5gJy0zvKRNgyMh6bxt9+y6uJqxBu3QGZOgF AkKYzJzobuQH9xqcM1u5bVMMdDwxw7dxkid3RKqhFEWTSj97MU31hhwaha6YAx9lCp Lcr30JocVnbV5eqYpXfmKpiqD3ezaT2hgL30H0ggQ8w6HsWlYgh9WqtgLdTz6C3GvU 20OGd1iYoVo4HPkUSiEFpMZMOxtnKfo9j9IooEXIAD+rAZHlqx2pU5qBMDYaFaELH+ 6pIb9TxStKNfTLZ78g3A5itmBJyOG0xbnKgdG4piveR4JaSrvI7cmjgSBH4ppRV9CW SHGRJM3YRjKVCFgEbm2nz+2oKj9NAn5qgz4KEtVhQ+R6R5Z6omWuxsADQaGpmStRGM 6B/iiXhDEFyEQXbepZBMQXcOueF+FcEpV2E2MzI4QPvNz1/o0NSGIddvbpuDrq2Ckm +Kbe2toysS51E6glqR72MF8bjjGhc8/NoRrNWe1D8pc72N74w7LyAh+Bne1jZzwCKS 6WJroBIG44mQUGnQMzMpVEtA= From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8D832B57-8A2A-4CAC-96CA-1E8A51A498FD" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [EXTERNAL] allocating IRQ mentioned in _CRS of ACPI Date: Thu, 20 Oct 2022 11:43:23 +0100 In-Reply-To: Cc: Warner Losh , "freebsd-hackers@freebsd.org" , Wei Hu To: Souradeep Chakrabarti References: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4MtPMj6N1Jz3Xjl X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=fubar.geek.nz header.s=mail header.b=Qxb8zLM8; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=softfail (mx1.freebsd.org: 139.59.165.16 is neither permitted nor denied by domain of andrew@fubar.geek.nz) smtp.mailfrom=andrew@fubar.geek.nz X-Spamd-Result: default: False [0.30 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=mail]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_NO_TLS_LAST(0.10)[]; FREEFALL_USER(0.00)[andrew]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; ASN(0.00)[asn:14061, ipnet:139.59.160.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[fubar.geek.nz:+]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[fubar.geek.nz,none]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_8D832B57-8A2A-4CAC-96CA-1E8A51A498FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Based on my reading of the ACPI tables, and looking how Linux handles it = I don=E2=80=99t think the vmbus_res driver should be used. If the vmbus = driver was to attach to the =E2=80=9CVMBUS" _HID it would be able to = manage the interrupt directly. Ideally acpi_syscontainer would become a proper bus, but that would need = checking that existing drivers that depend on the current behaviour = still work. Andrew > On 19 Oct 2022, at 18:51, Souradeep Chakrabarti = wrote: >=20 > Hi Warner, > =20 > 1) PCI mmio resource in HID "ACPI0004", which is needed by the FreeBSD = guest for SRIOV devices. > =20 > Device (\_SB.VMOD) <-- This is currently owned by = acpi_syscontainer module on FreeBSD > { > Name (_HID, "ACPI0004" /* Module Device */) // _HID: Hardware = ID > Name (_UID, Zero) // _UID: Unique ID > Name (_CRS, ResourceTemplate () // _CRS: Current Resource = Settings > { > ... > } > CreateDWordField (_CRS, \_SB.VMOD._Y00._MIN, MIN6) // _MIN: = Minimum Base Address > CreateDWordField (_CRS, \_SB.VMOD._Y00._MAX, MAX6) // _MAX: = Maximum Base Address > CreateDWordField (_CRS, \_SB.VMOD._Y00._LEN, LEN6) // _LEN: = Length > CreateQWordField (_CRS, \_SB.VMOD._Y01._MIN, MIN7) // _MIN: = Minimum Base Address > CreateQWordField (_CRS, \_SB.VMOD._Y01._MAX, MAX7) // _MAX: = Maximum Base Address > CreateQWordField (_CRS, \_SB.VMOD._Y01._LEN, LEN7) // _LEN: = Length > Method (_INI, 0, NotSerialized) // _INI: Initialize > { > MIN6 =3D MG2B /* \MG2B */ > LEN6 =3D MG2L /* \MG2L */ > Local0 =3D MG2L /* \MG2L */ > MAX6 =3D (MIN6 + Local0--) > Local1 =3D (HMIB << 0x14) > Local2 =3D (HMIL << 0x14) > MIN7 =3D Local1 > LEN7 =3D Local2 > Local0 =3D Local2 > MAX7 =3D (MIN7 + Local0--) > } > } > =20 > 2) Vmbus IRQ resource in HID "VMBus", which is needed to get Hyper-V = vmbus interrupt to work on guests. > Device (\_SB.VMOD.VMBS) <--- currently owned by vmbus_res module on = FreeBSD > { > ... > Name (_HID, "VMBus") // _HID: Hardware ID > Name (_UID, Zero) // _UID: Unique ID > ... > Name (_CRS, ResourceTemplate () // _CRS: Current Resource = Settings > { > Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, = ,, ) > { > 0x00000012, > } > }) > } > =20 > > =20 > Today I was able to get both IRQ and MMIO allocation successful using = below snippet in vmbus: > =20 > + device_t dev =3D = devclass_get_device(devclass_find("vmbus_res"), 0); > + sc->ires =3D bus_alloc_resource_any(dev, > SYS_RES_IRQ, &sc->vector, RF_ACTIVE | RF_SHAREABLE); > =20 > =20 > Thanks & Regards, > Souradeep > =20 > From: Warner Losh =20 > Sent: Wednesday, October 19, 2022 11:09 PM > To: Souradeep Chakrabarti > Cc: freebsd-hackers@freebsd.org; Wei Hu > Subject: [EXTERNAL] Re: allocating IRQ mentioned in _CRS of ACPI > =20 > Sorry for the late reply... I've been busy with some things for = work... > =20 > I think you'll need to get the parent of vmbus to allow a pass through = allocation. What bus is that > currently? > =20 > Warner > =20 > On Tue, Oct 18, 2022 at 12:33 PM Souradeep Chakrabarti = > wrote: > Hi, > It will be a great help, if someone can help here with some idea. > As it is blocking the FreeBSD on Hyper-V ARM64. >=20 > Thanks & Regards, > Souradeep >=20 > > -----Original Message----- > > From: Souradeep Chakrabarti > > Sent: Friday, October 14, 2022 1:24 PM > > To: 'Warner Losh' > > > Cc: freebsd-hackers@freebsd.org = ; Wei Hu > > > Subject: RE: allocating IRQ mentioned in _CRS of ACPI > >=20 > > Last mail was having incorrect FreeBSD hacker alias. Replacing that = with correct > > one here. > >=20 > >=20 > > > -----Original Message----- > > > From: Souradeep Chakrabarti > > > Sent: Friday, October 14, 2022 1:19 PM > > > To: Warner Losh > > > > Cc: hacker@freebsd.org ; Wei Hu = > > > > Subject: allocating IRQ mentioned in _CRS of ACPI > > > > > > Hi, > > > I would like to allocate IRQ to a device, mentioned in the _CRS of > > > that device in ACPI table. > > > I have tried with bus_alloc_resource_any(), but it is failing as = the > > > parent of that device is not owning the IRQ. > > > > > > Current ACPI topo for the device : > > > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for MMIO in _CRS)- > > > >VMBUS( it has SYS_RES_IRQ in it's _CRS). > > > > > > How can I get here both SYS_RES_IRQ and SYS_RES_MEM allocated to = VMBUS? > > > > > > Thanks & Regards, > > > Souradeep --Apple-Mail=_8D832B57-8A2A-4CAC-96CA-1E8A51A498FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Based= on my reading of the ACPI tables, and looking how Linux handles it I = don=E2=80=99t think the vmbus_res driver should be used. If the vmbus = driver was to attach to the =E2=80=9CVMBUS" _HID it would be able to = manage the interrupt directly.

Ideally acpi_syscontainer would become a proper bus, but that = would need checking that existing drivers that depend on the current = behaviour still work.

Andrew

On 19 = Oct 2022, at 18:51, Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:

Hi Warner,
 
1) PCI mmio resource in HID "ACPI0004", which = is needed by the FreeBSD guest for SRIOV devices.
 
   Device = (\_SB.VMOD)    <-- This is currently owned by = acpi_syscontainer module on FreeBSD
   = {
        = Name (_HID, "ACPI0004" /* Module Device */)  // _HID: Hardware = ID
        = Name (_UID, Zero)  // _UID: Unique ID
        Name (_CRS, = ResourceTemplate ()  // _CRS: Current Resource Settings
        {
          &nb= sp; ...
        = }
        = CreateDWordField (_CRS, \_SB.VMOD._Y00._MIN, MIN6)  // _MIN: = Minimum Base Address
        CreateDWordField = (_CRS, \_SB.VMOD._Y00._MAX, MAX6)  // _MAX: Maximum Base = Address
        = CreateDWordField (_CRS, \_SB.VMOD._Y00._LEN, LEN6)  // _LEN: = Length
        = CreateQWordField (_CRS, \_SB.VMOD._Y01._MIN, MIN7)  // _MIN: = Minimum Base Address
        CreateQWordField = (_CRS, \_SB.VMOD._Y01._MAX, MAX7)  // _MAX: Maximum Base = Address
        = CreateQWordField (_CRS, \_SB.VMOD._Y01._LEN, LEN7)  // _LEN: = Length
        = Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
          &nb= sp; MIN6 =3D MG2B /* \MG2B */
          &nb= sp; LEN6 =3D MG2L /* \MG2L */
          &nb= sp; Local0 =3D MG2L /* \MG2L */
          &nb= sp; MAX6 =3D (MIN6 + Local0--)
          &nb= sp; Local1 =3D (HMIB << 0x14)
          &nb= sp; Local2 =3D (HMIL << 0x14)
          &nb= sp; MIN7 =3D Local1
          &nb= sp; LEN7 =3D Local2
   =         Local0 =3D Local2
          &nb= sp; MAX7 =3D (MIN7 + Local0--)
        }
    }
 
2) Vmbus IRQ resource in HID "VMBus", which is = needed to get Hyper-V vmbus interrupt to work on guests.
Device (\_SB.VMOD.VMBS)   <--- currently owned = by vmbus_res module on FreeBSD
   = {
        = ...
        = Name (_HID, "VMBus")  // _HID: Hardware ID
        Name (_UID, = Zero)  // _UID: Unique ID
        ...
        Name (_CRS, = ResourceTemplate ()  // _CRS: Current Resource Settings
        {
          &nb= sp; Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
          &nb= sp; {
          &nb= sp;     0x00000012,
          &nb= sp; }
        = })
    }
 
<image001.png>
 
Today I was able to get both IRQ and MMIO allocation = successful using below snippet in vmbus:
 
+       device_t dev =3D  = devclass_get_device(devclass_find("vmbus_res"), 0);
+       sc->ires =3D = bus_alloc_resource_any(dev,
          &nb= sp; SYS_RES_IRQ, &sc->vector, RF_ACTIVE | RF_SHAREABLE);
 
 
Thanks= & Regards,
 Souradeep
 
From: Warner Losh <imp@bsdimp.com> 
Sent: Wednesday, October 19, 2022 = 11:09 PM
To: Souradeep Chakrabarti = <schakrabarti@microsoft.com>
Cc: freebsd-hackers@freebsd.org; Wei Hu <weh@microsoft.com>
Subject: [EXTERNAL] Re: allocating = IRQ mentioned in _CRS of ACPI
 
Sorry for the late reply... I've been busy = with some things for work...
 
I = think you'll need to get the parent of vmbus to allow a pass through = allocation. What bus is that
currently?
 
Warner
 
On Tue, Oct 18, 2022 at 12:33 PM Souradeep = Chakrabarti <schakrabarti@microsoft.com> wrote:
Hi,
It will = be a great help, if someone can help here with some idea.
As= it is blocking the FreeBSD on Hyper-V ARM64.

Thanks & Regards,
Souradeep
> -----Original Message-----
> From: = Souradeep Chakrabarti
> Sent: Friday, October 14, 2022 = 1:24 PM
> To: 'Warner Losh' <imp@bsdimp.com>
> Cc: freebsd-hackers@freebsd.org; Wei Hu <weh@microsoft.com>> Subject: RE: allocating IRQ mentioned in _CRS of = ACPI
> 
> Last = mail was having incorrect FreeBSD hacker alias. Replacing that with = correct
> one here.
> 
> 
> > = -----Original Message-----
> > From: Souradeep = Chakrabarti
> > Sent: Friday, October 14, 2022 1:19 = PM
> > To: Warner Losh <imp@bsdimp.com>
> > Cc: hacker@freebsd.org; = Wei Hu <weh@microsoft.com>
> > Subject: = allocating IRQ mentioned in _CRS of ACPI
> >
> > Hi,
> > I would like to = allocate IRQ to a device, mentioned in the _CRS of
> = > that device in ACPI table.
> > I have tried = with bus_alloc_resource_any(), but it is failing as the
>= > parent of that device is not owning the IRQ.
> = >
> > Current ACPI topo for the device :
> > ACPI0->SB.VMOD(HID ACPI0004, has SYS_RES_MEM for = MMIO in _CRS)-
> > >VMBUS( it has SYS_RES_IRQ in = it's _CRS).
> >
> > How can I = get here both SYS_RES_IRQ and SYS_RES_MEM allocated to VMBUS?
> >
> > Thanks & Regards,
> > = Souradeep

= --Apple-Mail=_8D832B57-8A2A-4CAC-96CA-1E8A51A498FD-- From nobody Fri Oct 21 09:25:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MtzbN40p9z4fx9k; Fri, 21 Oct 2022 09:25:36 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MtzbN3LjVz3N6k; Fri, 21 Oct 2022 09:25:36 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666344336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SSWHsdNyW4P6abdSBASBod10O2bKf3hcWhbm7nPDq0M=; b=aPCJmbRsVajC+G0N67UcUIsB2EqeNEgJUgPhBJjIYyxOGJJqF6Oy0R1R7dBLdaUfptxV8e qvYIIyB+pBkspLovMt8cjSWS7IL4ILCaP23EVR2Zf8QCAeQ+mtoOm8ibVzICfN0QGTbRQO cSwMpdE3Wj32tZrgEsXZ/xrXSfrjS9jnUBf2p2sLRnXoemwRDGLsqaqXpFeYeyw66LCxvO k74uBKkPt+MIqMw++obg2x47XzX5YC81TvxjeFOAe1rmCfprez2FTBniAgLb3/JpPnUW6Z ICd/RTYqJJrrNYeeNfgg0T5+4qC2tofZ7nMajmAIvdQabDn3an5Vou4g7wfb2A== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 5D8571AE16; Fri, 21 Oct 2022 09:25:36 +0000 (UTC) Date: Fri, 21 Oct 2022 09:25:36 +0000 From: Lorenzo Salvadore To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2022 Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline; filename="report.txt" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666344336; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=SSWHsdNyW4P6abdSBASBod10O2bKf3hcWhbm7nPDq0M=; b=yBkHN650aLi8+BOX/ZPBuNy9WaV+mycbNYrw48QFpYlJPAeFQfUpV/ALQQ8pcA7AcKuYfd rnvoAFiwnrIwsZDCA8nvZJ8F5hdtSHH2CT/KIlRx6oo83t3MmzY3ffTcTUmAserNEMMsrY cYzYpmLkfYV4gJQMB8U+/3pxXPlBMjn92wdMfUcVaAQhYfVF8MHN3XSxCmKwsXKaYpztra 5eJGC6Zdeca0LvKR8iq6nr81wQLSnO1JodB9+/Mggep3MA8zJPathGytMcjhBMv6QT3Uek +PSa+ZgXqO8plmx5QEYHaX/YPHDtqOxZEqu5nMDfnjsAvMis6FON4ghvcur/Jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666344336; a=rsa-sha256; cv=none; b=RPCCkCn20k9L1I2SnfCJeIiYXivOBEE0ZKgL10SevrcIDj5buxWDKY2zxhGRykMgrq3BGt Nf4jSGRtWqPlHnitlNbQU4Wyg5D80Rtyw3EHgpp55GUg+Zhi9MwoLNBJPZvXwwt7Q5+rQb 1WgV37gsPUz2QCw5z4oe4qIZe8HBD/wtQPhVmQb7w+9uxTQc7UsK0wgLK9RH/XkTqK0Jzv LWIqwomZoW39yT841wnXv1w86qXWMW4p4ng1LxCpMjFiNEQcPeO5CQ2bEIkdNxacoDoEQB DGkLOmO55vTl7OuAMtOHclrXh1WXT9BuHNCy74soak7RvTAZ3jWZrS9zansV9w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N FreeBSD Quarterly Status Report Third Quarter 2022 Here is the third quarterly report for year 2022, with 24 reports included, which is slightly fewer than last quarter. I notice that in the past we had quarters with many more reports: often more than 30, sometimes even more than 40. Thus I would like to encourage all of you to submit reports: reports are useful to share your work, to find help, to have more eyes reviewing your changes, to have more people testing your software, to reach a wider audience whenever you need to tell something to all of the FreeBSD community and in many other cases. Please do not be shy and do not worry if you are not a native English speaker or if you are not proficient in AsciiDoc syntax: the quarterly team will be glad to help you in whatever you need. On the other hand, if you really do not have anything to report, then maybe you might like to join one of the interesting projects described below, or you might be inspired from one of them to do something new, thus having something to report in the future. We wish you all a pleasant read. Lorenzo Salvadore, on behalf of the status report team. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ A rendered version of this report is available here: https://www.freebsd.org/status/report-2022-07-2022-09/ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Table of Contents • FreeBSD Team Reports □ FreeBSD Core Team □ FreeBSD Foundation □ FreeBSD Release Engineering Team □ Cluster Administration Team □ Continuous Integration □ Ports Collection • Projects □ OpenStack on FreeBSD □ FreeBSD as a Tier 1 cloud-init Platform • Userland □ bhyve debug server enhancements □ Rewrite of pjdfstest □ Ongoing work on LLDB multiprocess debugging support □ DTrace: Instruction-level dynamic tracing • Kernel □ ENA FreeBSD Driver Update □ wtap(4) enhancement □ Intel wireless towards 11ac □ More wireless updates □ Enabling Snapshots on Filesystems Using Journaled Soft Updates • Architectures □ FreeBSD/Firecracker • Documentation □ Documentation Engineering Team • Ports □ Calendar-data: License added □ KDE on FreeBSD □ GCC: New maintainer, GCC 12.2 and more □ sysutils/lsof major upgrade • Third Party Projects □ Containers and FreeBSD: Pot, Potluck and Potman ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. Completed Items New Core Team Secretary All members of the Core Team express publicly their gratitude to Muhammad Moinur Rahman (bofh) for serving as the Core Team Secretary for the past two years. The Core Team approved Sergio Carlavilla (carlavilla) as the new Core Team secretary. Procedure to handle GDPR deletion request The Core Team has reviewed the procedure to handle GDPR deletions requests with help from Foundation lawysers. The document is currently being written and will be published after completion. New Privacy Policy The Core Team is working closely with the FreeBSD Foundation to update the Privacy Policy to properly align with current laws and practices found on similar websites such as ours. Bruce Evans memorial plaque The Core Team unanimously votes to allow the memorial plaque for Bruce Evans mentioning him as co-founder of FreeBSD. EuroBSDCon core team office hour On Friday, September 16, the new Core Team presented at EuroBSDcon 2022 Developer Summit. The Core Team introduced themselves and talked a bit about their plans for this term. There were discussions, Q & A, and suggestions from the attendees about the details. Commit bits Core approved reactivating the source commit bit for Konrad Witaszczyk (def@). Right now Konrad is working at Cambridge University, where he is responsible for developing CheriBSD. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Foundation Links: FreeBSD Foundation URL: https://www.FreeBSDFoundation.org Technology Roadmap URL: https://FreeBSDFoundation.org/blog/technology-roadmap/ Donate URL: https://www.FreeBSDFoundation.org/donate/ Foundation Partnership Program URL: https://www.FreeBSDFoundation.org/ FreeBSD-foundation-partnership-program FreeBSD Journal URL: https://www.FreeBSDFoundation.org/journal/ Foundation News and Events URL: https://www.FreeBSDFoundation.org/ news-and-events/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Fundraising Efforts First, I’d like to send a big thank you to everyone who gave a financial contribution to our efforts. We are 100% funded by your donations, so every contribution helps us continue to support FreeBSD in many ways, including some of the work funded and published in this status report. We support FreeBSD in five main areas. Software development is the largest area we fund with through staff developers and contractors who implement new features, support tier 1 platforms, review patches, and fix issues. You can find out some of the work we did under OS Improvements in this report. FreeBSD Advocacy is another area that we support to spread the word about FreeBSD at conferences, in presentations online and in-person, tutorials and how-to guides. We purchase and support hardware for the FreeBSD infrastructure that supports the work going on in the Project. Virtual and in-person events are organized by the Foundation to help connect and engage community members to share their knowledge and collaborate on projects. Finally, we provide legal support to the Project when needed and protect the FreeBSD trademarks. Our goal this year is to raise at a minimum $1,400,000 towards a spending budget of around $2,000,000. As we enter the last quarter of 2022, our donation total sits at $167,348, so we still need your help. If you haven’t made a donation this year, please consider making one at https://freebsdfoundation.org /donate/. We also have a Partnership Program for larger commercial donors. You can find out more at https://freebsdfoundation.org/our-donors/ freebsd-foundation-partnership-program/ OS Improvements During the second quarter of 2022, 300 src, 36 ports, and 13 doc tree commits were made that identified The FreeBSD Foundation as a sponsor. Some of that work has dedicated report entries. • FreeBSD as a Tier I cloud-init Platform • Intel wireless towards 11ac • LLDB multiprocess debugging support • OpenStack on FreeBSD • Snapshots on Filesystems Using Journaled Soft Updates The other sponsored work is challenging to concisely summarize. It varies from complex new features to various bug fixes spanning the src tree. Here is a small sample to give a flavor of last quarter’s work. • 240afd8 makefs: Add ZFS support This allows one to take a staged directory tree and create a file consisting of a ZFS pool with one or more datasets that contain the contents of the directory tree. This is useful for creating virtual machine images without using the kernel to create a pool; "zpool create" requires root privileges and currently is not permitted in jails. makefs -t zfs also provides reproducible images by using a fixed seed for pseudo-random number generation, used for generating GUIDs and hash salts. makefs -t zfs requires relatively little by way of machine resources. • 36f1526 Add experimental 16k page support on arm64 Add initial 16k page support on arm64. It is considered experimental, with no guarantee of compatibility with userspace or kernel modules built with the current 4k page size. Testing has shown good results in kernel workloads that allocate and free large amounts of memory as only a quarter of the number of calls into the VM subsystem are needed in the best case. • 1424f65 vm_pager: Remove the default pager It's unused now. Keep the OBJ_DEFAULT identifier, but make it an alias of OBJT_SWAP for the benefit of out-of-tree code. • a889a65 eventtimer: Fix several races in the timer reload code In handleevents(), lock the timer state before fetching the time for the next event. A concurrent callout_cc_add() call might be changing the next event time, and the race can cause handleevents() to program an out-of-date time, causing the callout to run later (by an unbounded period, up to the idle hardclock period of 1s) than requested. Bhyve Issue Support The Foundation contracted John Baldwin to dedicate time to Bhyve as issues arise, especially security issues. Here is a summary of his 2022q3 work on that contract. • bb31aee bhyve virtio-scsi: Avoid out of bounds accesses to guest requests. • 62806a7 bhyve virtio-scsi: Tidy warning and debug prints. • 7afe342 bhyve e1000: Sanitize transmit ring indices. • c94f30e bhyve: Validate host PAs used to map passthrough BARs. • 16bedf5 pci: Add helper routines to iterate over a device’s BARs. • baf753c bhyve: Support other schemes for naming pass-through devices. • fa46f37 bhyve e1000: Skip packets with a small header. • e7439f6 bhyve xhci: Cache the value of MaxPStreams when initializing an endpoint. RISC-V Improvements At the end of the quarter, the Foundation contracted Mitchell Horne to add and improve support for RISC-V hardware. Mitchell will also perform general maintenance such as fixing bugs, handling reports, providing review for new code changes, and improving source code legibility and documentation. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. You can read about CI activities this quarter in a dedicated entry. FreeBSD Advocacy and Education Much of our effort is dedicated to Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature and video tutorials, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are continuing to attend events both in person and virtual as well as planning the November Vendor Summit. In addition to attending and planning virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD. Check out some of the advocacy and education work we did last quarter: • Held a FreeBSD Workshop and Staffed a booth at Scale 19x in Los Angeles, CA on July 28-30. You can read more about our participation in the SCALE19X Conference Report • Sponsored and attended COSCUP, July 30-31, Taiwan • Attended the EuroBSDCon Developer Summit and sponsored and attended EuroBSDcon 2022, September 15-18, Vienna, Austria • Sponsored and Presented at the Rocky Mountain Celebration of Women in Computing, September 29-30, 2022. Slides from Deb’s presentation can be found here. • Published the FreeBSD Foundation Summer 2022 Update • Continued our participation in Google Summer of Code as both an admin and mentors. Interviews with some of the Google Summer of Code Students can be found here. • Introduced a new FreeBSD Resources page that allows for search by type of subject, type of content and difficulty level. • New Blog Posts: □ Guest Post: FreeBSD in Science □ Advocating for FreeBSD in 2022 and Beyond □ August Foundation Fundraising Update □ Sharing Dual-Licensed Drivers between Linux and FreeBSD • New and Updated How-To and Quick Guides: □ FreeBSD Quick Guide: Video Playback on FreeBSD □ Binary Package Management on FreeBSD We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at https:// www.FreeBSDfoundation.org/journal/. You can find out more about events we attended and upcoming events at https:// www.FreeBSDfoundation.org/news-and-events/. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to https://www.FreeBSDFoundation.org to find more about how we support FreeBSD and how we can help you! ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD Release Engineering Team Links: FreeBSD 12.4-RELEASE schedule URL: https://www.freebsd.org/releases/12.4R/ schedule/ FreeBSD 13.2-RELEASE schedule URL: https://www.freebsd.org/releases/13.2R/ schedule/ FreeBSD 14.0-RELEASE schedule URL: https://www.freebsd.org/releases/14.0R/ schedule/ FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ ISO-IMAGES/ Contact: FreeBSD Release Engineering Team, The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. During the third quarter of 2022, the Release Engineering Team continued providing weekly development snapshot builds for the main, stable/13, and stable/12 branches. Additionally, the schedules for the upcoming 12.4, 13.2, and 14.0 release cycles were published on the Project website. Sponsor: Rubicon Communications, LLC ("Netgate") Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Cluster Administration Team Links: Cluster Administration Team members URL: https://www.freebsd.org/administration /#t-clusteradm Contact: Cluster Administration Team FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications. In this quarter, the team has worked on the following: • Added additional storage to the CI system. It will help store more artifacts. • VuXML deployed in all official mirrors. It speeds up the pkg audit functionality. • A new (and additional) monitoring system is in place. • A few old and faulty machines were decommissioned. • Moved several services to newer hardware. • Regular cluster-wide software upgrades • Regular support for FreeBSD.org user accounts • Regular disk and parts support (and replacement) for all physical hosts and mirrors. Work in progress: • git infra: Add --filter support. • Work with the PowerPC team to improve the package builders, universal, and reference machines. • Site audit at our primary site: inventory of spares and other miscellanea occupying space in our cabinets. • Discussions with Juniper about a donation of new switches for our primary site. • Plan for a large scale network upgrade at our primary site. • Cluster refresh (more extended project). Most cluster machines are running FreeBSD 13-STABLE or 14-CURRENT as of 2022-09-30. Only a handful of machines are still on FreeBSD 12-STABLE. We are looking for an additional full mirror site (five servers) in Europe. See generic mirrored layout for our needs. Offers of additional single-server mirrors are always welcome too, especially in Europe. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Continuous Integration Links: FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci dev-ci Mailing List URL: https://lists.freebsd.org/subscription/dev-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system of the FreeBSD project. The CI system checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from those builds are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the code or adjust test infrastructure. During the third quarter of 2022, we continued working with the contributors and developers in the project to fulfill their testing needs and also keep collaborating with external projects and companies to improve their products and FreeBSD. Important completed tasks: • Expand the artifact storage space for adding more types of artifacts and longer retention period. • Present Testing/CI Status Update in EuroBSDcon 2022 Developer Summit • Add main-powerpc-images and main-powerpcspe-images Work in progress tasks: • Designing and implementing pre-commit CI building and testing (to support the workflow working group) • Designing and implementing use of CI cluster to build release artifacts as release engineering does • Testing and merging pull requests in the FreeBSD-ci repo • Simplifying CI/test environment setting up for contributors and developers • Setting up the CI stage environment and putting the experimental jobs on it • Organizing the scripts in freebsd-ci repository to prepare for merging to src repository • Updating documents on wiki Open or queued tasks: • Collecting and sorting CI tasks and ideas • Setting up public network access for the VM guest running tests • Implementing use of bare-metal hardware to run test suites • Adding drm ports building tests against -CURRENT • Planning to run ztest tests • Adding more external toolchain related jobs • Improving maturity of the hardware lab and adding more hardware for testing • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI) • Working with hosted CI providers to have better FreeBSD support Please see freebsd-testing@ related tickets for more WIP information, and don’t hesitate to join the effort! Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Collection Links: About FreeBSD Ports URL:https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/# ports-contributing FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/ Ports Management Team URL: https://www.freebsd.org/portmgr/ Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/ Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. Currently there are just over 30,500 ports in the Ports Tree. There are currently just under 2,800 open ports PRs of which 750 are unassigned. The last quarter saw 9,137 commits by 151 committers on the main branch and 589 commits by 61 committers on the 2022Q3 branch. Compared to two quarters ago, this means a slight increase in the number of ports, but also a slight increase in the number of (unassigned) ports PRs and a slight decrease in the number of commits made. In the last quarter, we welcomed Felix Palmen (zirias@) as a new ports committer, welcomed back Akinori MUSHA (knu@), and said goodbye to Olli Hauer (ohauer@). We also welcomed Luca Pizzamiglio (pizzamig@) as an official member of portmgr. Some large changes in the Ports Tree were made during the last quarter: • "Created by" lines have been removed from the top of each Makefile, as a lot of those were outdated. • WWW: has been moved from each pkg-descr into each Makefile as a variable; the below write-up is from Stefan Eßer (se@) who did the work: The description of a port’s functionality should end with the URL of a web page that provides further information, such as best practices for usage or configuration. This information can be displayed with pkg query -e for installed packages or pkg rquery -e for available packages. The URL used to be appended to the end of the ports' pkg-descr files, with the prefix "WWW: ", so that tools could extract the URL from the description. Over time, many of these URLs have become stale, since port updates generally change only the Makefile, not the pkg-descr file. By moving the definition of these URLs into the Makefiles, maintainers are more likely to update the URL along with other port changes, and tools have easier access to them. The URLs are now assigned to the WWW macro in the Makefile and can be queried with make -V WWW in the port directory. Tools that process the description contained in the package files still work because the "WWW: " lines at the end are generated from the WWW values in the Makefiles. During EuroBSDCon, portmgr@ had a discussion about improving the situation for kernel module packages. Various possibilities have been discussed. The following happened under the hood: • one new USES, "vala", was added. • The default version of Go got bumped to 1.19 • CMake is now a meta-port • Initial support for Qt 6 was added, at version 6.3.2 • Vim no longer installs a system-wide vimrc • A number of major ports got updated: □ pkg 1.18.4 □ Chromium 106.0.5249.91 □ Firefox 105.0.1 ☆ Firefox ESR 102.3.0 □ KDE Applications 22.8.1 □ KDE Frameworks 5.98 □ Rust 1.63.0 □ SDL 2.24.0 □ Xorg server 21.1.4 (overhaul) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. OpenStack on FreeBSD Links: OpenStack URL: https://www.openstack.org/ OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd Contact: Chih-Hsin Chang Contact: Li-Wen Hsu OpenStack is an open-source cloud operating system for different types of resources like virtual and bare-metal machines. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible to run OpenStack control plane on FreeBSD hosts. The goal of this project is to port key OpenStack components so that FreeBSD can function as an OpenStack host. Academic and industrial research groups have been evaluating CHERI-enabled Morello boards since mid-2022. A resource orchestration platform like OpenStack can improve the speed and cost of provisioning, managing, and recycling those boards. Starting in January 2022, Chih-Hsin Chang has been working to port several OpenStack components to run on FreeBSD, including: • Keystone (identity service) • Glance (image service) • Placement (resource tracking and inventory service) • Neutron (networking service) • Nova (compute service) Some of the items are still under heavy development. For instance, due to the design of Neutron, the DHCP servers are placed inside Linux network namespaces. It is necessary to find an alternative, e.g. vnet, on FreeBSD and adapt it. Most of the time the porting strategy is to make as small of an impact as possible by working around obstacles. But something like oslo.privsep deserves a true porting. oslo.privsep is rooted in Linux capabilities to do the privilege separation work. Right now we just bypassed any Linux capabilities-related operation inside oslo.privsep. So there is plenty of hackish spots in the source code and configurations currently. All of these along with the building and installation steps will be collected in the project repositories. In Q4 Chih-Hsin plans to focus on porting Neutron and Nova in order to complete the VM lifecycle operations. The highlights include: • DHCP integration • FreeBSD bridge driver/agent • Bhyve + Libvirt integration Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FreeBSD as a Tier 1 cloud-init Platform Links: cloud-init Website URL: https://cloud-init.io/ cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/ cloud-init ongoing refactorization URL: link:https://github.com/canonical/ cloud-init/blob/main/WIP-ONGOING-REFACTORIZATION.rst Contact: Mina Galić cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux is rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs. The project deliverables include completing an extraction of certain networking classes, implementing ifconfig(8) and login.conf(5) parsers, implementing IPv6 configuration, creating devd.conf(5) rules for Azure, and FreeBSD Handbook documentation about productionizing FreeBSD. On the way there, any BSD-related bugs found in modules and documentation will also be fixed. People interested in helping with the project can help with testing new features and fixes through net/cloud-init-devel, which will be updated on a weekly basis. Further, people with access to, and experience with, OpenBSD and NetBSD are also highly welcome to help. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Userland Changes affecting the base system and programs in it. bhyve debug server enhancements Links: link: Wiki project page link: Differential Contact: Bojan Novković The goal of this project was to enhance the functionality of bhyve’s debug server. Several existing features related to single-stepping are tied to Intel-specific VM mechanisms, which severely impairs bhyve’s debugging functionality on other x86 platforms. The first goal dealt with extending single-stepping support to AMD hosts. The second goal was to add support for hardware watchpoints using the guest OS’s hardware debugging registers. The project was carried out under Google’s Summer of Code program and was finished around the end of July. The project’s wiki also contains detailed documentation regarding several implemented mechanisms. The changes can be summarized as follows: • Support for placing software breakpoints inside virtual machines on AMD platforms, • Support for single-stepping virtual machines on AMD platforms, • Support for placing hardware watchpoints inside virtual machines on Intel and AMD platforms. Any feedback, comments and discussions are welcome and would be greatly appreciated. Sponsor: Google Summer of Code ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Rewrite of pjdfstest Links: Github URL: https://github.com/musikid/pjdfstest Blog URL: https://musikid.github.io/blog/rewrite-pjdfstest/ Contact: Alan Somers Back in 2007, Pawel Jakub Dawidek wrote pjdfstest, a POSIX file system conformance test tool. He originally wrote it to validate the port of ZFS to FreeBSD, but it has subsequently been used for other file systems and other operating systems. This year, Sayafdine Said rewrote it under Google’s sponsorship. The new version has several improvements: • More configurable, for better use with other file systems. • Much faster, largely thanks to said configurability. • Better test case isolation, making failure easy to debug. • No longer requires root privileges for all test cases. • Test cases can be run in a debugger. • More maintainable, less duplication. There are still a couple of lingering PRs to complete, but we expect to wrap those up and add pjdfstest to the ports collection soon. From there, it will be used both by /usr/tests for ZFS and UFS, and by external developers for other file systems. Sponsor: Google Summer of Code ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ongoing work on LLDB multiprocess debugging support Links: Moritz Systems Project Description URL: https://www.moritz.systems/blog/ multiprocess-support-for-lldb/ Progress Report 1 URL: https://www.moritz.systems/blog/ implementing-non-stop-protocol-compatibility-in-lldb/ Progress Report 2 URL: https://www.moritz.systems/blog/ full-multiprocess-support-in-lldb-server/ Contact: Kamil Rytarowski Contact: Michał Górny According to the upstream description, "LLDB is a next generation, high-performance debugger. It is built as a set of reusable components which highly leverage existing libraries in the larger LLVM Project, such as the Clang expression parser and LLVM disassembler." FreeBSD includes LLDB in the base system. The previous sponsored projects improved LLDB, to make it a credible debugger for the base system, although it still has a few limitations compared to the contemporary versions of GNU GDB. This project started in April 2022. It aims to implement full support for debugging multiple processes simultaneously. At the start of the project, LLDB featured very limited support for multiprocess debugging. Currently, the server is already able to monitor multiple processes using the multiprocess extension to the GDB Remote Serial Protocol. The work on implementing the client-side counterpart for this protocol is ongoing. Once the project is finished, LLDB will be able to trace an arbitrary number of forked processes simultaneously (equivalent to GDB’s detach-on-fork off). Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ DTrace: Instruction-level dynamic tracing Links: Wiki article URL: https://wiki.freebsd.org/SummerOfCode2022Projects/ InstructionLevelDynamicTracing Final code review URL: https://reviews.freebsd.org/D36851 Contact: Christos Margiolis Contact: Mark Johnston kinst is a new DTrace provider that allows for arbitrary kernel instruction tracing. The provider is currently implemented only for amd64, but we plan to port it to other architectures in the future as well. kinst probes are created on demand by libdtrace, and a probe can be created for nearly every instruction in the kernel. Probes take the form of: kinst::: where "module" is the kernel module containing the named function, "function" is the kernel function to be traced, and "offset" is the offset to a specific instruction. Omitting "offset" causes all instructions in the function to be traced. Omitting "module" causes DTrace to search all kernel modules for the function. For example, to trace the second instruction in amd64_syscall(), first determine the offset of the second instruction: # kgdb (kgdb) disas /r amd64_syscall Dump of assembler code for function amd64_syscall: 0xffffffff809256c0 <+0>: 55 push %rbp 0xffffffff809256c1 <+1>: 48 89 e5 mov %rsp,%rbp 0xffffffff809256c4 <+4>: 41 57 push %r15 The offset is 1. Then, to trace it: # dtrace -n 'kinst::amd64_syscall:1' A new "regs" keyword was also added to the D language, providing read-only access to CPU registers at the point where the probe fired. For example, to trace the contents of the frame pointer (register %rbp on amd64) when the kinst::amd64_syscall:1 probe fires: # dtrace -n 'kinst::amd64_syscall:1 {printf("0x%x", regs[R_RBP]);}' kinst works similarly to the FBT (function boundary tracing) provider in that it places a breakpoint on the target instruction and hooks into the kernel’s breakpoint handler. It is more powerful than FBT since it can be used to create probes at arbitrary points within a function, rather than at function boundaries. Because kinst has to be able to trace arbitrary instructions, it does not emulate most of them in software but rather causes the traced thread to execute a copy of the instruction before returning to the original code. Planned future work includes porting kinst to additional platforms, especially arm64 and riscv, and developing tooling that can use kinst to trace calls to inline functions using the kernel’s debugging symbols. Sponsor: Google, Inc. (GSOC 2022) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. ENA FreeBSD Driver Update Links: ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ ena/README.rst Contact: Michal Krawczyk Contact: David Arinzon Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: • Upstream of the ENA driver v2.6.0 and v2.6.1, included: □ Fix for the performance degradation after reset issue on 6-gen instances, □ Fix of the false netmap assertions with KASSERT enabled, □ Code cleanup and style fixes, □ Logging improvements, □ Fix to the retrieval of the ENI metrics. Sponsor: Amazon.com Inc ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ wtap(4) enhancement Links: Add sta, hostap and adhoc mode to wtap wlan simulator Contact: En-Wei Wu Contact: Li-Wen Hsu Contact: Bjoern A. Zeeb wtap(4) is a net80211(4) Wi-Fi simulator introduced by Monthadar Al Jaberi < monthadar@gmail.com> and Adrian Chadd in 2012. It originally supported 802.11s mesh mode and was used for verification. During the 2022 Google Summer of Code, En-Wei had been working on bringing sta, hostap, adhoc and monitor modes to it. The work also covers adding basic tests for net80211(4) with wtap(4), written in atf(7). For more details, please check the project wiki page. Sponsor: Google Summer of Code Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Intel wireless towards 11ac Links: Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/ Iwlwifi Contact: Bjoern A. Zeeb The ongoing project aims to support the latest Intel wireless chipsets on FreeBSD using LinuxKPI compat code backed by native net80211 and kernel code. In addition work is on the way to support 11n and 11ac standards in the LinuxKPI 802.11 compat code and fill gaps for mostly 11ac in the native net80211 wireless stack. For the Intel iwlwifi wireless driver there were no major updates in the last months. We updated the firmware to the latest publicly available version and fixed some of the most visible bugs. Work is also on the way to support the D3 power saving code. LinuxKPI compat code also got some improvements and fixes which at times were only observable on certain generations of iwlwifi chipsets. Changes in net80211 and LinuxKPI compat code for 11n and 11ac have little public visibility so far in order to not break basic support. Updates to constants based on newer 802.11 standards and other changes without user-visible effect were merged, and functional changes will follow in the coming months, initially hidden behind compile-time or runtime options. Improvements and updates were largely merged back to stable/13 for the benefit of the users tracking this branch and to help with more testing. For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages. Sponsor: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ More wireless updates Links: Bjoern’s Wireless Work In Progress landing page URL: https://people.freebsd.org /~bz/wireless/ Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw88 Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Rtw89 MediaTek mt76 status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Mt76 QCA ath11k status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Ath11k Contact: Bjoern A. Zeeb Currently development is mostly driven by Intel’s iwlwifi driver again (see other report). As the saying goes ''each one helps the other'' so has work on Realtek’s rtw89 driver helped find a bug in LinuxKPI bothering iwlwifi users. For this status report the topic is mostly more drivers, which do need more LinuxKPI support. Various work in progress: • Realtek’s rtw88 PCI is in-tree as-is and after a fruitful discussion with Hans Petter Selasky at EuroBSDCon work on LinuxKPI USB support for the rtw88 USB WiFi dongles will continue. • Realtek’s rtw89 driver was committed to main but is not connected to the build yet. Scanning already works but packets are not yet passing. Having the driver in-tree already eased testing for users having that chipset in order to identify more unimplemented LinuxKPI bits (some of which will help the other drivers as well) and reduced work for me. • The next drivers to probably hit the tree will be based on MediaTek’s mt76 driver (for 7921 and 7915) which I have compiling and started testing. • Based on requests I am also working on ath11k to support STA mode given some vendors seem to ship Laptops with those chips. While some of this clearly benefits from work sponsored by The FreeBSD Foundation for iwlwifi and newer standard support, a lot of this is just free-time work. If you are interested in any of these drivers I would greatly appreciate if some more hands would help with one or the other. This could be regularly testing updates to main, writing documentation and updating wiki pages, tracking PRs, trying out patches, helping with work on individual LinuxKPI bits with or without 802.11 work, or simply debugging problems with individual drivers and/or chipsets. If you are interested in helping with any one of the above, please drop me an email. For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages (as soon as they exist). ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Enabling Snapshots on Filesystems Using Journaled Soft Updates Links: Milestone 1 Core Changes URL: https://reviews.freebsd.org/D36491 Contact: Kirk McKusick This project will make UFS/FFS filesystem snapshots available when running with journaled soft updates. The UFS/FFS filesystem has the ability to take snapshots. Because the taking of snapshots was added after soft updates were written they were fully integrated with soft updates. When journaled soft updates were added in 2010, they were never integrated with snapshots. So snapshots cannot be used on filesystems running with journaled soft updates. Snapshots became less important with the support for ZFS on FreeBSD since ZFS can take snapshots quickly and easily. However there remain two instances where UFS snapshots are still important. The first is that they allow reliable dumps of live filesystems which avoids possibly hours of down time. The second is that they allow the running of background fsck. Similar to the need for scrub in ZFS, fsck needs to be run periodically to find undetected disk failures. Snapshots allow fsck to be run on live filesystems rather than needing to schedule down time to run it. This project has two milestones: 1. enable snapshots when running with journaled soft updates and ensure that they can be used for doing background dumps on a live filesystem. This milestone should be completed by the end of 2022. 2. extend fsck_ffs to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. This milestone is expected by Q3 of 2023. Sponsored by: The FreeBSD Foundation ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Architectures Updating platform-specific features and bringing in support for the new hardware platform. FreeBSD/Firecracker Links: Firecracker VM Contact: Colin Percival Firecracker is an open source "microVM" developed by Amazon Web Services; it is designed for the needs of "serverless" compute environments and has a particular focus on security and minimalism. Starting in June 2022, Colin Percival has been working to port FreeBSD to run in the Firecracker environment, with significant assistance from other FreeBSD developers. As of this quarterly report, a set of patches are pending review which collectively add the needed support to make FreeBSD functional in a patched version of Firecracker. In Q4 Colin intends to finish committing the relevant patches to FreeBSD, release a kernel and disk image so other FreeBSD users can experiment with Firecracker, and update and merge Firecracker patches which add PVH boot support (used by FreeBSD). This work has already produced "spinoff" benefits in revealing ways to speed up the FreeBSD boot process; due to its low overhead and minimal environment, Firecracker is an excellent context to work on this. This work is supported by Colin’s FreeBSD/EC2 Patreon. Sponsor: https://www.patreon.com/cperciva ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Documentation Noteworthy changes in the documentation tree, manual pages, or new external books/documents. Documentation Engineering Team Link: FreeBSD Documentation Project Link: FreeBSD Documentation Project Primer for New Contributors Link: Documentation Engineering Team Contact: FreeBSD Doceng Team The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter. During the last quarter: • 0mp@ stepped down as Doceng’s Secretary, fernape@ joined as the new Secretary. Doceng would like to thank 0mp@ for his service. • eadler@'s doc bit was taken in for safekeeping per his request. • A git commit message template was added for the doc repository. Items pending and in the discussion: • Remove outdated translations from the Website and Documentation portal. FreeBSD’s Documentation Project Primer The FDP was expanded with information on trademark handling. Porter’s Handbook: • The documentation on porting Haskell programs was updated. • The move of WWW from pkg-descr to Makefile was documented. • Qt 6-related documentation has been added following the import of the library in the ports framework. FreeBSD Translations on Weblate Link: Translate FreeBSD on Weblate Link: FreeBSD Weblate Instance Q3 2022 Status • 12 languages • 148 registered users □ Gasol Wu joined the Chinese translation team. □ Alvaro Felipe Calle joined the Spanish translation team. Languages • Chinese (Simplified) (zh-cn) (progress: 8%) • Chinese (Traditional) (zh-tw) (progress: 4%) • Dutch (nl) (progress: 1%) • French (fr) (progress: 1%) • German (de) (progress: 1%) • Indonesian (id) (progress: 1%) • Italian (it) (progress: 4%) • Norwegian (nb-no) (progress: 1%) • Persian (fa-ir) (progress: 3%) • Portuguese (pt-br) (progress: 16%) • Spanish (es) (progress: 15%) • Turkish (tr) (progress: 2%) We want to thank everyone who contributed, translating or reviewing documents. Please, promote this effort in your local user group, we always need more volunteers. FreeBSD Manual Pages Portal Contact: Sergio Carlavilla The Manual Pages Portal has been redesigned to use mandoc(1) for rendering. A portal preview is available. Feedback has been collected and addressed where possible. There are some remaining non-blocking issues. Doceng@ would like to move forward with the migration to this new portal. Thanks to all of those who reviewed it and provided feedback. FreeBSD Website Revamp - WebApps working group Contact: Sergio Carlavilla Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases: 1. Redesign of the Documentation Portal Create a new design, responsive and with global search. (Complete) 2. Redesign of the Manual Pages on web Scripts to generate the HTML pages using mandoc. (Complete) 3. Redesign of the Ports page on web Ports scripts to create an applications portal. (Work in progress) 4. Redesign of the FreeBSD main website New design, responsive and dark theme. (Not started) ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Calendar-data: License added Links GitHub calendar-data repository URL: https://github.com/freebsd/calendar-data Contact: Stefan Eßer Contact: Lorenzo Salvadore Contact: Warner Losh The port deskutils/calendar-data contains calendar files for the BSD calendar program and is maintained by se@. The data for this port lives in a GitHub repository, which at the moment is maintained mainly by salvadore@. About two years ago, the calendar files in the base repository were removed from there and a new repository was created on GitHub; see also this Phabricator review about the creation of the associated port. This improvement allows calendar files to be updated independently from the base system. Unfortunately, when the repository was created, it was forgotten to add a license to it. The issue has been solved this quarter with this pull request submitted by salvadore@ and merged by imp@. Since the data originally came from the src repository, the same licence applies. If in the past you have contributed to the calendar files with different licensing assumptions, please inform us so that we can license your contributions accordingly or remove them. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ KDE on FreeBSD Links: KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software from the KDE Community, along with dependencies and related software, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team (kde@) is part of desktop@ and x11@, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items that are important for the entire desktop stack. Qt6 Landed The big news in the KDE ports is not directly KDE-related. Qt6 has landed, which prepares us for the next generation of Qt-based applications. It is now possible to have USES=qt:6 to select the new Qt version. Some ports have been flavorized to make use of the new version. KDE itself is not affected: the upstream work on KDE Frameworks for Qt6 is not yet completed. Most of the KDE Frameworks will compile with Qt6, but that is not important for FreeBSD ports yet. With devel/qt6 you get Qt 6.4.0, released at the end of the quarter. KDE Stack KDE Gear releases happen every quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release every month as well. These (large) updates land shortly after their upstream release and are not listed separately. • KDE Frameworks 5 is now at version 5.98 (latest monthly release from September 2022). • KDE Gear is now version 22.08.1 (update for September 2022). • KDE Plasma is now version 5.24.6 (update for July 2022). Note that KDE Plasma 5.25 has been released upstream, but is waiting on fixes before it can land in the ports tree (for example, this KActivityManager bug in KDE’s bug-tracker). Related Ports • accessibility/qt5-speech now supports multiple backends, as well as no-backends, for speech synthesis. • devel/cmake was reorganized, so that devel/cmake is now a metaport that installs devel/cmake-core and the rest of the CMake suite. (Thanks to diizzy@) The CMake ports were also updated to version 3.24, with attendant changes in ports all over the tree. • net/qt5-network has improved compatibility with libressl. • x11/plasma-wayland-protocols was updated in advance of KDE Plasma Desktop updates in the next quarter. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GCC: New maintainer, GCC 12.2 and more Links: GCC Project URL: https://gcc.gnu.org GCC 11 release series URL: https://gcc.gnu.org/gcc-11/ GCC 12 release series URL: https://gcc.gnu.org/gcc-12/ Contact: Contact: Lorenzo Salvadore • salvadore@ adopted all existing ports corresponding to supported versions of gcc, namely: lang/gcc10, lang/gcc11, lang/gcc11-devel, lang/gcc12, lang/ gcc12-devel and lang/gcc13-devel. At the moment -devel ports are updated weekly, unless a build failure makes it impossible. Of course, in the latter case, the build failure is fixed and/or reported upstream as soon as possible. • GCC 12.2 has been released. Traditionally, FreeBSD waits for the release of the second minor version of GCC to use it as default GCC version, so that most of the software needing to be compiled with GCC has already been ported to the latest major version. Thus, work has started to update the default GCC version to version 12. Thank you very much to antoine@ who has already run the first exp-run and to all the contributors, maintainers and committers involved in the process. https://bugs.freebsd.org/bugzilla/ show_bug.cgi?id=2659548 • Discussion about LTO keeps going with many different points of view. If interested, you can read the latest contributions to the topic: lang/gcc11: Needs build time warning for /tmp consumption and lang/gcc11: build gets stuck. Reminder: LTO_BOOTSTRAP is an option enabled by default. If you build the port on your machine and its resources consumption is not acceptable, disabling this option will get you a lighter compilation. • jbeich@ submitted a patch to expose non-default -stdlib=libc++ support, which has been successfully committed to all relevant ports (gcc >= 11). link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265962 • diizzy@ refreshed the mirrors list in the MASTER_SITE_GCC variables, also removing ftp mirrors. The main GCC site is used as fallback. link: https:// reviews.freebsd.org/D36372 • Help is still needed with these three changes to work through with upstream GCC (requires expertise with the GCC sources and upstream, not with the ports framework): □ upstreaming lang/gcc11/patch-gets-no-more □ upstreaming lang/gcc11/patch-arm-unwind-cxx-support □ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ sysutils/lsof major upgrade Link: lsof project repo URL: https://github.com/lsof-org/lsof Contact: Larry Rosenman sysutils/lsof had a major upgrade to no longer look in /dev/kmem for data, and to use the userland API. This took a long time to hit the tree, but is finally done. It fixes lsof(8) to work with ZFS again for the first time since 13.0-RELEASE. This will make maintenance much easier going forward. To the kernel folks: if you make changes that break lsof, please submit a GitHub pull request to https://github.com/lsof-org/lsof. Please test any changes to the interfaces that lsof uses and make sure they still work. These all should be userland interfaces now, but please test. My thanks to Warner Losh , Mateusz Guzik , and Ed Maste for help getting this major change landed. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Third Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. Containers and FreeBSD: Pot, Potluck and Potman Links: Pot organization on github URL: https://github.com/bsdpot Contact: Luca Pizzamiglio (Pot) Contact: Stephan Lichtenauer (Potluck) Contact: Michael Gmelin (Potman) Pot is a jail management tool that also supports orchestration through Nomad. During the last quarter, pot 0.15.3 was released. It contains a number of improvements like mount-out to remove or unmount a previously mount-in folder or filesystem, signal and exec commands, better jail lifecycle handling, and many bug fixes. A new version of the Nomad driver, nomad-pot-driver 0.9.0, was also released with signal and exec support and stability fixes. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: a repository of pot flavours and complete container images for usage with pot and in many cases Nomad. Since the last status report, many changes were committed, including many fixes and improvements to core images like grafana, postgresql-patroni or loki. Additionally, all images have been rebuilt for FreeBSD 13.1 and 12.3 and to include the current quarterly versions of the packages being used. Last not least, Luca held the pot implementation and ecosystem talk How far a naive FreeBSD container implementation can go at EuroBSDCon 2022. As always, feedback and patches are welcome. From nobody Thu Oct 27 11:15:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MyjlB4vcxz4gyXC for ; Thu, 27 Oct 2022 11:15:18 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Myjl964nbz41n3 for ; Thu, 27 Oct 2022 11:15:17 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: by mail-wr1-x432.google.com with SMTP id v1so1567551wrt.11 for ; Thu, 27 Oct 2022 04:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=TQTwT/YHV1KHkJ2pPZQVjJ+Pz6AEj8DNM3Zj3bdACfo=; b=qoL7d+R1UFZHQrHWOCmM1Oon5oFL29JZ7wuvxzudyfJePLwPIj4lHj3VzfjeADZdol 6tPE5whoo3myE+I+F0o/acS45vbzeZyhAsdGeJbLuNHxsPAFlWtD2576ZddCj7gubeaX V5lKfB80/qzTyh4wkV3/h3Knr7v4A0mEEaHLECev/oUqflv5WZAB2j+9s2pskXAdg6Kx VMsAtH81s7w1E1CZvV+epxJFczVJ+V3vZ1lnBt6SEMgL+oVqGgI6C/ft1bZG4oyGEW7R +pq+jEOY3eKlaIekEzsOBS5lUFsRJ0x6WOacaumcvEuWjH5prUVNZVM+PGsz42OsCsee HJ1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TQTwT/YHV1KHkJ2pPZQVjJ+Pz6AEj8DNM3Zj3bdACfo=; b=4bFKa/J/D4aL6cVyDm/FnHJVwqFUEHKC3XbLFOedsoBTmKXCLpnxCwOrIRqI8K1lwK FX5jHTJWTUJOyW64u9A2gWwqjkamhdBkXC4knmhTDAExuh/BpWfSEQPbfDuajfBsy/hl RBCUnxRTDxNIM+gilo6ULwAPedVyO6hTVuL2CmvytPD2Oh19Kf2kxPBXBAOYGQyNMnaF Lg9QymQbsV82f7qsyWjJ0SX3tJTkBeZqnzbx2vW0x2ZjzXKqauCp2vXZ+w+PKzoj4Oyh c/XEuQDSMeTX5SPh37tlpaWkG5SwDmymN7TPnAhCI/gF0+aQw7iaXVMJSs/I1UONqFGt pB/w== X-Gm-Message-State: ACrzQf2AqMHOWUrJaqoaBCiqmu3FI6kllsKhH3gUoxRcvpFsDF4Fbag+ Io384DKU3MB7f8RxrVChYQ3d4R3KMig= X-Google-Smtp-Source: AMsMyM4oggq9ZIC68ZR9Z+F57+a577SF4dqunm8/hATvqqyap2xeMy0+DhW63BifETJjOkt6VeMldA== X-Received: by 2002:a5d:6d89:0:b0:236:7d7d:1e79 with SMTP id l9-20020a5d6d89000000b002367d7d1e79mr9790647wrs.673.1666869315940; Thu, 27 Oct 2022 04:15:15 -0700 (PDT) Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115]) by smtp.gmail.com with ESMTPSA id ay19-20020a05600c1e1300b003a1980d55c4sm4627532wmb.47.2022.10.27.04.15.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 04:15:15 -0700 (PDT) Message-ID: <068ed962-5556-32ea-d8c5-de328b1dc9ac@gmail.com> Date: Thu, 27 Oct 2022 13:15:14 +0200 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: AMD64 14.0-CURRENT memory layout changes To: freebsd-hackers References: <578a011d-0c3f-3f91-48ca-17999a6515a9@gmail.com> <259246b0-9592-3aa8-2a1a-52609ac5357c@gmail.com> <8a640196-c057-81f0-96be-45b340ffaa2e@gmail.com> Content-Language: en-US From: Paul Floyd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Myjl964nbz41n3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=qoL7d+R1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=paulf2718@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::432:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 10/19/22 00:20, Mark Johnston wrote: > > Nice. Thanks for all of the work you do on the Valgrind port! Final heads-up - Valgrind 3.20 is now available from ports. A+ Paul From nobody Thu Oct 27 19:26:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mywds2yVQz4frtj for ; Thu, 27 Oct 2022 19:26:25 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mywdr3X4zz3DTW for ; Thu, 27 Oct 2022 19:26:24 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: by mail-io1-xd30.google.com with SMTP id 63so2559342iov.8 for ; Thu, 27 Oct 2022 12:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:content-language:to:user-agent :mime-version:date:message-id:from:from:to:cc:subject:date :message-id:reply-to; bh=6kPuhlhSjkEmkLLjEgMGTlQzO8mN/RCDsJS7tXhkyCY=; b=ijB9Ao0P01mo9l66P+7/RnJiycaVltnyD/Hu8CskoDNJlwMZhsFcy/DQrbYAkbplMP KZorfiNCW/mR/3b4H3HCV27LdrPqxjZ3YW6NSbgC3qoTDXU5j4Uo0NQJ+mB2OoG6Y09F koY81jcyuHgU10RikGNa0CNd1LgXNDE2hFTu2dniwXKHdWLnXV20+gfD8DBev8lHCIQ6 qfcGBBR/2/yqy9S62MbSgTjuqkC8YXmgFhnEhjSbnS5z1O1SYhgxnt66qSm6HRN/TLFj nRe2RqAnTW6n108ZW/xe0W4rLmqKWhW9bL5La7h5NhTT/kRUmehU5abzGvPCOVqblnBS 8PAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:content-language:to:user-agent :mime-version:date:message-id:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6kPuhlhSjkEmkLLjEgMGTlQzO8mN/RCDsJS7tXhkyCY=; b=r8ubZCoaecKcW+BKe9fOsm1ySPOfnRLZd9c3cqD6Wy+pq/qhq9k3dsHpmdidpeHJI6 cTRMF7QetSgrV7UmFEwWY5CNqiRrVMlN+TOndwJL2T4fG/PveErx8rM5FcYsYlHUbReF uNyKu1cHiwfzqO0MxNPMn5eXarIcxED22Op8HADAMsFCjrlemp8nzQ3XAQfCM5MWRO7u qfRUCTl9eImH+twvOvuq/RIX77V3v2ZAaFp+oFbyzRZ5++6UUylVBteOaNZjPu80+9Tv zyMZ2uIuTFGWzkxbdrnRlG5pM5H8R9dG6VOlo235KU6PdpkcDGdzoHcdSU2fQsP//SVo q4KQ== X-Gm-Message-State: ACrzQf250L6b+OVYcoif0U8buY7xfhc9nyJ2apEmu311MiS+3z2B93gQ QuXzbzyH8j1TpoAg7poZRBcmWwKn/Rs= X-Google-Smtp-Source: AMsMyM7k72t187kmsIA20kmgR5PMlLxhvRSEiYABtyJpqyDKCwYtPkV7c++EpOKyqrHfnzCbj/GFrg== X-Received: by 2002:a05:6638:3391:b0:374:1739:3795 with SMTP id h17-20020a056638339100b0037417393795mr13493069jav.87.1666898782770; Thu, 27 Oct 2022 12:26:22 -0700 (PDT) Received: from [10.8.6.92] ([161.130.189.147]) by smtp.gmail.com with ESMTPSA id e1-20020a022101000000b00356744215f6sm909572jaa.47.2022.10.27.12.26.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 12:26:22 -0700 (PDT) From: Stephen Montgomery-Smith X-Google-Original-From: Stephen Montgomery-Smith Message-ID: Date: Thu, 27 Oct 2022 14:26:21 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 To: freebsd-hackers Content-Language: en-US Subject: Equivalent of Linux timezone in FreeBSD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mywdr3X4zz3DTW X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ijB9Ao0P; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of montgomerysmithstephen@gmail.com designates 2607:f8b0:4864:20::d30 as permitted sender) smtp.mailfrom=montgomerysmithstephen@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; MID_RHS_MATCH_TO(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d30:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N I am attempting to port code that uses an external variable called timezone, which is defined in the Linux file time.h as the number of seconds West of UTC for the current timezone. Is there an equivalent of this in FreeBSD or other BSDs? Is this the right group to ask this question? Thanks, Stephen From nobody Thu Oct 27 19:32:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mywnd5ydYz4fsyT for ; Thu, 27 Oct 2022 19:33:09 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mywnc3Zmfz3FST for ; Thu, 27 Oct 2022 19:33:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x629.google.com with SMTP id sc25so7531723ejc.12 for ; Thu, 27 Oct 2022 12:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nDGirRBdfgEkN04vPSI29LhaEhgLbUjsOBU2VTx8lFc=; b=BwwAauuhaMZYc8/bWDnFfJdHAi2APSG9MqTMlRf5W//m+iN8lOalIpjj74fmD7AfGr UhdcnDheq9kS9T8km6NuwPpFCtjVae6SZ7Bvjml2gV5BwSyTMbR3ie+TrxhPP/hzrBP+ HaXpOrZ79G0WeL/DLc4AEmJpNV1xQpnPG9BAJN0vHQosEZjIYY6BtvYYyfkEO6/jESXj t0JjZ+Se57tE+PdCthsOye/Wx2NATS32tXgUaqgl9xhBeEISWt8V7pIjf1m1ugDWuRDa Pj72CwgWR1mic1YNW2ayPu1m8PxnqKeSWXuNjB0Utu5XNv65BmTzR1H+Cu5SCVIdblWt vqWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nDGirRBdfgEkN04vPSI29LhaEhgLbUjsOBU2VTx8lFc=; b=WrYESziMhDkJkVbTUTcgs9d3fg/0FPs7T8Nh6j9G2YL6BomLpe5Q98bAGLt2nK4ZPw RRd73qYnXkMyq/bM5rEi1ZaUdmLE+vGacX9U4aeLjRrVyrf2vqb8/kVJD9uWyo59HQcz UsAD5Yg+5aA2PdHZJ8mitSGaGn0aJbIg2xhQHg/juHszei71+Q/E9vBc73UUdPiO2yJl llHPwaT7UM9m02PKBpy91A0eslRpknE2y7EM1p0HA67o4TGI/cR4OnRbojyV4W4veuV9 0Pqu//i1/PcuFIfSH+SuQsoPyd/OYE75ZlWxplGJULaI3QXIYrOklzFHx9jHTx9vgLaq ovBg== X-Gm-Message-State: ACrzQf1VrEXve0YOj0onyhsYhVDZj3tu7gVLFCCJDeUgZNkJco592IK6 +NpBNVIdHeEiaGNtgwj+jAS5ovEV3FVKCxJTTw1U2UEuie8= X-Google-Smtp-Source: AMsMyM6lEokFMKOyUqTz8jCUGazt+UhYm4Kr11dCysIKbG1TvUbfmTZYoZVocP4qog1e2Ex5caL5E9Oo/eNx4IQhHMw= X-Received: by 2002:a17:907:2710:b0:7ad:86f9:9bad with SMTP id w16-20020a170907271000b007ad86f99badmr6305008ejk.32.1666899187079; Thu, 27 Oct 2022 12:33:07 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 27 Oct 2022 13:32:55 -0600 Message-ID: Subject: Re: Equivalent of Linux timezone in FreeBSD To: Stephen Montgomery-Smith Cc: freebsd-hackers Content-Type: multipart/alternative; boundary="000000000000ec342605ec093583" X-Rspamd-Queue-Id: 4Mywnc3Zmfz3FST X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=BwwAauuh; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::629) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000ec342605ec093583 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 27, 2022 at 1:26 PM Stephen Montgomery-Smith < montgomerysmithstephen@gmail.com> wrote: > I am attempting to port code that uses an external variable called > timezone, which is defined in the Linux file time.h as the number of > seconds West of UTC for the current timezone. > Except it's not completely reliable on linux, since it's not a constant except for the few minutes around the current time.... You can't expect it to work around the cut-overs of daylight savings time, for example. > Is there an equivalent of this in FreeBSD or other BSDs? > getenv("TZ") will get the timezone for the current process. But what are you using this value for? Warner > Is this the right group to ask this question? > > Thanks, Stephen > > --000000000000ec342605ec093583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 27, 2022 at 1:26 PM Steph= en Montgomery-Smith <montgomerysmithstephen@gmail.com> wrote:
I am attempting to port code that uses an = external variable called
timezone, which is defined in the Linux file time.h as the number of
seconds West of UTC for the current timezone.

Except it's not completely reliable on linux, since it's not= a constant except for
the few minutes around the current time...= . You can't expect it to work around the
cut-overs of dayligh= t savings time, for example.
=C2=A0
Is there an equivalent of this in FreeBSD or other BSDs?

getenv("TZ") will get the timezone for the curr= ent process.

But what are you using this value for= ?

Warner
=C2=A0
Is this the right group to ask this question?

Thanks, Stephen

--000000000000ec342605ec093583-- From nobody Fri Oct 28 01:39:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mz4w73NdCz4gkSN for ; Fri, 28 Oct 2022 01:39:19 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mz4w62jtVz3k8x for ; Fri, 28 Oct 2022 01:39:18 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: by mail-il1-x135.google.com with SMTP id o13so2263163ilc.7 for ; Thu, 27 Oct 2022 18:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=FLjN6ATS5EP+2nxUj/fY14fV8H/HDe/uUbGIG6S2zWg=; b=pEiT2XMngUdQoTxA4uQmD7IOFRt7pXbXfXYl2V2yJE74/3CSeAsqg3/Z68q8X7F9U6 CQhb0IDwRyYBJcZKvWnKevYg/lL6bXx51nG93naK2YnHmxuAHt+buKd4k/A1ep4N9uvT IECgmj0I8ItfmifrNvKYuJlFKKUFffjd1MsfH2RZnhDy6YoOfMo0b+KzXMSfo8yZGEc5 z88bJs7pKVF5j6CI25L1TA/n1KrvNh7e2g15PlGNRS/vNKqZ6wG9JhMiUc0wW1Qmu7Xp yYDWHLkPwNnKPPYRYnv7CbayNfEj+3SBQrTqKTDy+PgFi3lPJlzcP1XktNwPbHWKWTCU ATEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FLjN6ATS5EP+2nxUj/fY14fV8H/HDe/uUbGIG6S2zWg=; b=d7j069nJD5BZzHdIQ+48iR+cJmMgzUEldNqMWmg+2z+zRLCg0NzpUqHQM9EUAKup0H Tqq9zL/5WboCD3GxurFmBNE+amEUXArzaSePokQr8mbPvfQZX7gYV8DK4oD5i6zOOMO4 NlE9hQP4W1Yd1Xo7ltt+mNw4mdngbFSExnDcL2AkIaeUBYcBf5qxQqIQz1ZNHl1wRvCW RUzuSjG/Bi6QJn78fKxE1aX7SwKFAhEzQj4ymyZucmXaDJ9pVE9DI5laqe86OAfY+cDA vvu5n/Z5aBuMP+Pp6+pEC+GJgm8+c3N6CLIt1RN2FSEUp9aRd/kh6BMvo2H+gXISeNoh eR8Q== X-Gm-Message-State: ACrzQf2LylQ3SC8dxBaf8q/IJxMMTslMb+vd1xOkJNg/bhBVWsGlAjkD GxHNuyiLwbeUaYcubHpS9xtCF62TB6c= X-Google-Smtp-Source: AMsMyM6DSIeJ/7Y+3WXSndg5mjm/HD8w2qgWj4nxytktGG+RUbOJvzKDU41c5d1tXap45LOlWrbIYg== X-Received: by 2002:a92:c24c:0:b0:300:331d:a762 with SMTP id k12-20020a92c24c000000b00300331da762mr11199889ilo.124.1666921157596; Thu, 27 Oct 2022 18:39:17 -0700 (PDT) Received: from [10.8.6.92] ([161.130.189.147]) by smtp.gmail.com with ESMTPSA id y13-20020a02950d000000b00363582c03dfsm1189770jah.85.2022.10.27.18.39.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 18:39:17 -0700 (PDT) From: Stephen Montgomery-Smith X-Google-Original-From: Stephen Montgomery-Smith Message-ID: <2b6cb2f9-79ec-576f-76ad-6b965e7cef86@FreeBSD.org> Date: Thu, 27 Oct 2022 20:39:15 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Equivalent of Linux timezone in FreeBSD Content-Language: en-US To: Warner Losh Cc: freebsd-hackers References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Mz4w62jtVz3k8x X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=pEiT2XMn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of montgomerysmithstephen@gmail.com designates 2607:f8b0:4864:20::135 as permitted sender) smtp.mailfrom=montgomerysmithstephen@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::135:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 10/27/22 14:32, Warner Losh wrote: > > > On Thu, Oct 27, 2022 at 1:26 PM Stephen Montgomery-Smith > > wrote: > > I am attempting to port code that uses an external variable called > timezone, which is defined in the Linux file time.h as the number of > seconds West of UTC for the current timezone. > > > Except it's not completely reliable on linux, since it's not a constant > except for > the few minutes around the current time.... You can't expect it to work > around the > cut-overs of daylight savings time, for example. > > Is there an equivalent of this in FreeBSD or other BSDs? > > > getenv("TZ") will get the timezone for the current process. > > But what are you using this value for? It is used inside https://pub.ist.ac.at/~schloegl/biosig/prereleases/biosig4octave-3.0.1.src.tar.gz - look in the file biosig4octave-3.0.1/src/mexSSAVE.cpp at line 205. Maybe I'll contact the author of the code. From nobody Fri Oct 28 21:34:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MzbRM3v7Tz4fxPl for ; Fri, 28 Oct 2022 21:34:39 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MzbRL5pG5z3J1m for ; Fri, 28 Oct 2022 21:34:38 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: by mail-il1-x12a.google.com with SMTP id h18so3619186ilq.9 for ; Fri, 28 Oct 2022 14:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=EK3XzMftu/03oMqtlm3CQCx+TAm5Nf9st+jCkSIlfNg=; b=SxnpGBT2ICnjYCmKrEhXLt53rFcTnBTa5lHPJRx12KR3LQI+ZTo/m8dMMuZ3kHoncJ csxl7D41xd66/93NxR3j+FUJJLeyHhZLoCdiw69RcvlgJwSDrmD67qrquVkfNvRxnVBK i6E6/fzas72DCqlV6hsTSzar0GfJ/JkRlKqDVjAyg1TGXWFsK7gp+WJ380FJpbQARTb3 b6pX3lajOI5w1sBG3ulXqIYa3PS032vy9T79upKkMG/EOBOwv9upZCQXJ6SHjY96fwek y3jdYvgcP/iaE0Hd45N2GllpPFkPEsIF0VehqZANvIpMbRtLFEK7q0ijKnGE248eIwR3 JTfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EK3XzMftu/03oMqtlm3CQCx+TAm5Nf9st+jCkSIlfNg=; b=QLLdQ3L/w9E/pj8BPzy30Rqg4k7+JHsooeR0IP+/jHsM8H8pubpr5Uu14WsjH/IUDb VJ8qVSz1ot2fd7v1COmzUf6kR2pMkV/bKoZ8XcvK0GNaJ+VyK5TupWtcKB5FeZC8FSon 0UFs//zsNImI5MDjBnp9ARD3ogKNii1G+Yxk4lBTMEzCPfFVR9esHcu/3NyXIWSIpoZw oIzN2D9h+pL3gMQN9LMYYIqrzHI18tJk0zF3iQUKbxnPXo0exMvo/WIkXMdGX/FrmC3O dK3RrMC3eLwsni/nh7TcK81ADoy0GsAq/CXuaFyPx5b2UkqwK+UTMPyem9PQFeeLxJ81 1SgA== X-Gm-Message-State: ACrzQf3jU3cL0qxLI1Fm4+aShdbgzONJWBhcPDIWqze+iUnzS+2Ccp6S keRx38z8UWvOQNNg7P/qcyuNFkZ8lWM= X-Google-Smtp-Source: AMsMyM7z/eg0hTGbat9YV7WHU1sw+fxM0emU9WAhKMJoiSCo11yr1ea0w483KXKjD01mErvbPF+3rQ== X-Received: by 2002:a05:6e02:d04:b0:300:8716:e7b1 with SMTP id g4-20020a056e020d0400b003008716e7b1mr701911ilj.231.1666992878072; Fri, 28 Oct 2022 14:34:38 -0700 (PDT) Received: from [10.8.4.34] ([161.130.189.159]) by smtp.gmail.com with ESMTPSA id c24-20020a023f58000000b0035a274c8030sm2153647jaf.44.2022.10.28.14.34.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 14:34:37 -0700 (PDT) From: Stephen Montgomery-Smith X-Google-Original-From: Stephen Montgomery-Smith Message-ID: <6610316d-7ebf-f914-4276-3add9fd74dea@FreeBSD.org> Date: Fri, 28 Oct 2022 16:34:36 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Equivalent of Linux timezone in FreeBSD To: Thomas Mueller , Warner Losh Cc: freebsd-hackers References: <20221028075511.554f12c8@tmu.ulm.sysgo.com> Content-Language: en-US In-Reply-To: <20221028075511.554f12c8@tmu.ulm.sysgo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MzbRL5pG5z3J1m X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SxnpGBT2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of montgomerysmithstephen@gmail.com designates 2607:f8b0:4864:20::12a as permitted sender) smtp.mailfrom=montgomerysmithstephen@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::12a:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 10/28/22 00:55, Thomas Mueller wrote: > On Thu, 27 Oct 2022 13:32:55 -0600, Warner Losh wrote: >> On Thu, Oct 27, 2022 at 1:26 PM Stephen Montgomery-Smith < >> montgomerysmithstephen@gmail.com> wrote: >> >>> I am attempting to port code that uses an external variable called >>> timezone, which is defined in the Linux file time.h as the number of >>> seconds West of UTC for the current timezone. >>> >> > > The timezone variable is part of the POSIX XSI option (X/Open System > Interfaces). As mentioned in the original post it contains the number > of seconds West of UTC for the current timezone. > > Excerpt from the standard text for tzset(): > #include > [XSI] extern int daylight; > extern long timezone; > [CX] extern char *tzname[2]; > void tzset(void); > [...] > [XSI] The tzset() function also shall set the external variable > daylight to 0 if Daylight Savings Time conversions should never be > applied for the timezone in use; otherwise, non-zero. The external > variable timezone shall be set to the difference, in seconds, between > Coordinated Universal Time (UTC) and local standard time. > > I suppose FreeBSD's tm_gmtoff field in "struct tm" is an equivalent. > Excellent. I replaced timezone with localtime(0)->tm_gmtoff. Thank you very much. From nobody Fri Oct 28 21:56:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MzbwX1Zsfz4g133 for ; Fri, 28 Oct 2022 21:56:28 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MzbwW2Gyzz3Mjk for ; Fri, 28 Oct 2022 21:56:27 +0000 (UTC) (envelope-from montgomerysmithstephen@gmail.com) Received: by mail-io1-xd32.google.com with SMTP id z3so5728098iof.3 for ; Fri, 28 Oct 2022 14:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=s76z5n+sfXGxoJOX3fMO3oIh6Z7kDldKT23cyTm+u8A=; b=JFTQjXV63eBbPsaYkA0slOO0Esja5+sBn3p2BNPv3bUdGnkzFdulDOrK3UQfgGGbdr zst7hg7nEELlvDxRO2FJdXpp+wLA/7nB/gYWvn6uxze1e25s8np/NLZ1GelML7f5CqKh FItOmhDK1yk8TfN09qyU6mOs0wP/rQ6NPSGaEpM4gw8sv8I92aXA8P16XkmN+BTJ+rO/ yKp5BX8IVj4Vh0Um2LjENeEOOpqbyAufueiNENm4utxDWNaVxi8JDm3Z3cXt9M7gcxDI 7xff/cHrfVog+qCpjuOFtIYXFqH7F8ZmyOFXzqgOwVJa9eQ48mCMFmIIxcY2RSIfvK5v urzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s76z5n+sfXGxoJOX3fMO3oIh6Z7kDldKT23cyTm+u8A=; b=YRcpQSNJM1w2MCodpc+EwULY1IrhZDAV4Ky+yaTTRSAwZTxrHgTpZds9plekbEtDhC Ga45qehVHwSlyG+8NGhP0uqE0/4X+nQoU37MK/81ahamHWFzaQIFVD/HKHf+9aPAEAZZ 0jSQ60V41IlTYvLaHwJlH8X76A3kWbxKLPWcK9qjYtAh+iOrE5hT8xqIbNZttDKXZlRK ZQY5VMVgNTyMRzlrVm+47NyZsx+UKMZvcrQpLTKauB24ieN0CbRCouQP9d+ry/dMAzQk LgwB1KOjB26xBU06vPHz8IiDV4Z84aECIXoYLfu9kdwxYm4U1D3lgkc3WwTHjYX+nQyh 6NQw== X-Gm-Message-State: ACrzQf3MH1suOEwaTJUa9fI+TasfBZPHM577cHgjGcJmrOu45BGxv08c tKq/hAei8e1kFGtc3FPuyMw= X-Google-Smtp-Source: AMsMyM69mRVSsIfu6F0sXOxgyvTOAOuzRmoNxrXlMfxo0GYWy5qx4dLlPqLzMCR0mukNuYbsghuH5w== X-Received: by 2002:a02:c00e:0:b0:373:5326:e14f with SMTP id y14-20020a02c00e000000b003735326e14fmr845491jai.168.1666994186461; Fri, 28 Oct 2022 14:56:26 -0700 (PDT) Received: from [10.8.4.34] ([161.130.189.159]) by smtp.gmail.com with ESMTPSA id d2-20020a023f02000000b0035678e2e175sm2111746jaa.50.2022.10.28.14.56.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Oct 2022 14:56:26 -0700 (PDT) From: Stephen Montgomery-Smith X-Google-Original-From: Stephen Montgomery-Smith Message-ID: Date: Fri, 28 Oct 2022 16:56:19 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Equivalent of Linux timezone in FreeBSD Content-Language: en-US To: Thomas Mueller , Warner Losh Cc: freebsd-hackers References: <20221028075511.554f12c8@tmu.ulm.sysgo.com> <6610316d-7ebf-f914-4276-3add9fd74dea@FreeBSD.org> In-Reply-To: <6610316d-7ebf-f914-4276-3add9fd74dea@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4MzbwW2Gyzz3Mjk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=JFTQjXV6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of montgomerysmithstephen@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=montgomerysmithstephen@gmail.com X-Spamd-Result: default: False [-3.93 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.94)[-0.939]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d32:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 10/28/22 16:34, Stephen Montgomery-Smith wrote: > On 10/28/22 00:55, Thomas Mueller wrote: >> On Thu, 27 Oct 2022 13:32:55 -0600, Warner Losh wrote: >>> On Thu, Oct 27, 2022 at 1:26 PM Stephen Montgomery-Smith < >>> montgomerysmithstephen@gmail.com> wrote: >>> >>>> I am attempting to port code that uses an external variable called >>>> timezone, which is defined in the Linux file time.h as the number of >>>> seconds West of UTC for the current timezone. >>> > >> >> The timezone variable is part of the POSIX XSI option (X/Open System >> Interfaces). As mentioned in the original post it contains the number >> of seconds West of UTC for the current timezone. >> >> Excerpt from  the standard text for tzset(): >>         #include >> [XSI]  extern int daylight; >>         extern long timezone; >> [CX]   extern char *tzname[2]; >>         void tzset(void); >>         [...] >> [XSI]  The tzset() function also shall set the external variable >>         daylight to 0 if Daylight Savings Time conversions should >> never be >>         applied for the timezone in use; otherwise, non-zero. The >> external >>         variable timezone shall be set to the difference, in seconds, >> between >>         Coordinated Universal Time (UTC) and local standard time. >> >> I suppose FreeBSD's tm_gmtoff field in "struct tm" is an equivalent. >> > > Excellent.  I replaced timezone with localtime(0)->tm_gmtoff. > > Thank you very much. Oops, I meant localtime(&zero)->tm_gmtoff, where zero is of type time_t. From nobody Sat Oct 29 13:48:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N013C4WfDz4fsg7 for ; Sat, 29 Oct 2022 13:48:39 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N013C04cqz3byx for ; Sat, 29 Oct 2022 13:48:39 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: by mail-qk1-x734.google.com with SMTP id 8so5148175qka.1 for ; Sat, 29 Oct 2022 06:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ajJTD37FZ21snlW9Vm6/lRbgpCfidL5NVNtIVEsgL0s=; b=i5dgB9MawAu28XILoqmZTQNPP16kytj/Wh9lkd/6C6Jj8LqTY+n4Duex1BViAnQN/F YZCNqgkVAIaVpHzy4R8aGv2FbPleWrcziCYTSUaiXXqlvjsF2AI+YB+KnzKXXFRrkm+6 G6VwzFEG1b5msRJuXqPKzW/QFTGiKe2Wa0UxKeFmFe9iFEsIoEImua3sXJgxHDey7+tG 5NI44wHJ2V+6hIaQTKKMorg0rnKwOSgWZx+KiHk/noYhgbFlekVZUvgXcvpOmOJVVxre yuTumSJH3V0PoXx3y35teWMU0QY4Kiq/YzLt8p3M77qjCfF+VwDnJW1gUqzj+XM0TnaI XcGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ajJTD37FZ21snlW9Vm6/lRbgpCfidL5NVNtIVEsgL0s=; b=4A1AwbFoDwD11u0JM3JIBDGtkKp6xPHD1L3TMIf0jNJUYF8TIkPynbjgwKPQqfgKpM gmQk3Yl1JgvzxpNdd+i9hBHXU5/1gFEfhdyg5ifeWM4ebo9d3bFOHqu1NWnzMZDnntQn k+bRkEAvmHeVwkpEZ6a8/m85SAMAWk1MQou/QSEEy0UVT7BNlhw8wGOJVbNjlnkV7rzk ZqH5Tmu5lInSAgELRWcpVUZRK6lFQkmgQfm8K6V1tg/SOrgiwOmvS0ioTr5jm9v5Xb6Z MzfXaMglN2w4dZ8P4auesUqst3gU/8bRnG37uPYxdErr5IHurf+XRc9GKx3IeXJu/ukn Fl1A== X-Gm-Message-State: ACrzQf0SRaSL/tM541t/6ahudvsoR1aUJgxXM0XnMcuXauKHG41ajH9p 7RMQ6j6j+wgFIq0VksCZ5ug88DgoOrFM+CGi5HDPrdpW2og= X-Google-Smtp-Source: AMsMyM5XHdkYenyUVnsTXkjwM6+PTgqBtJbvYYOt6FHveoIBEgPfXJO8g84wH/gI7wvUsSvZEPKWR9u33XF7mp42Eqc= X-Received: by 2002:ae9:eb01:0:b0:6fa:b07:35b5 with SMTP id b1-20020ae9eb01000000b006fa0b0735b5mr2955538qkg.747.1667051317994; Sat, 29 Oct 2022 06:48:37 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Stanislaw Adaszewski Date: Sat, 29 Oct 2022 15:48:01 +0200 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4N013C04cqz3byx X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=i5dgB9Ma; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of s.adaszewski@gmail.com designates 2607:f8b0:4864:20::734 as permitted sender) smtp.mailfrom=s.adaszewski@gmail.com X-Spamd-Result: default: False [-3.79 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.79)[-0.791]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::734:from]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Since for the moment there does not seem to be that much traction for integrating it upstream, I have created a separate Git repository: https://github.com/sadaszewski/freebsd-patch-geli-password-from-tpm2 which can somewhat intelligently patch any FreeBSD source tree and allows to build the TPM2-passphrase-aware bootloader and kernel. I hope this will facilitate use by people who actually want/need it. I will also start putting some unit tests in there, in particular for the TPM code using swtpm + libtss2-tcti-swtpm - hopefully in the future all of it can be mostly test-covered. Soon, I will also throw in some scripts that automate the TPM2 setup. Best regards, -- S. From nobody Sun Oct 30 14:01:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N0dHS3CBYz4gyNN for ; Sun, 30 Oct 2022 14:01:24 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N0dHR5p7xz3qs0 for ; Sun, 30 Oct 2022 14:01:23 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-qt1-x82a.google.com with SMTP id a27so2831260qtw.10 for ; Sun, 30 Oct 2022 07:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4slrcfI5YxJjZjaEe+R4F80vxgUyHbWJ36s5NXxXyeI=; b=hg3aD2lKElQ3Ih7utzxfk6SxtsnDee6EMZ2qPW/dQxIToQ53l+64BHCdQ/L5xzWDWk ITbHOzEtd72Em+9Yx+xn5q/npl3KN5dc3UI7t4FxGa9Qgqsc28TT6CHNtI1/VUCbcKUG lpAKpLGpkJV0dzz+1Sip7ONT5bJP34pGGuYPKQ86Qyoev5GOwDajDa/53u45UXii/Gpm qT8tN7sB82FK/T8LvWsDt+sG9QAQNXwqZpqhyoNCIc0D8LprfMyTlhQbBCcbTMX6XQeB Ejeybbn2U5UBKgJXxSpMhtbt8p9oB2N4RaVWQbz277DLAxLjp5AMhOy9Gk6M4JdvGzxI e3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4slrcfI5YxJjZjaEe+R4F80vxgUyHbWJ36s5NXxXyeI=; b=cNGQfPgYG5VNq3e29lUk2yyYeicj12EMdbu7rekjInZwvdVSpIfpMkaBA3B9MkDgQr ESw0mAtVf8DBCTAtpAgSG0HjmKBi2ZPe75DnorvvzK+deyRojoyxqfer57iVK/QlTUJg nvJPzJorc1iPEPn8ujHXaYLKAkVPfSKH+Jirq7/Exf9CZBtTQSSFgC3lSSFLPEIB0k79 HO9XTltjFXdQwwhcChaPvE0FUMCC2GtH5+d83yySPGyS/0DtiZBpZ6eGhNU5SinqXEjp 5H7SBTuiVg4vSeiirldlSwQP2Z60JeLphNzJKDHJrTO4XCGnrTKFE1qW3RIhOTDFtHCp 3GgA== X-Gm-Message-State: ACrzQf1QILlNwI295KaeveOizK8vzawv58B1NXq6gIWqwGUf+tiG29AP 5DPIvGVJMq5Uw2fovj1dE9+1/6Jp0Q+/LA== X-Google-Smtp-Source: AMsMyM5MN+H4PoByh9RNMxfGl6I2qfh1ljvi8h3aqE+MHp+GU1cnxJLwt0pkHxIP3aJVOZRV/+28Wg== X-Received: by 2002:a05:622a:1212:b0:39c:bece:df15 with SMTP id y18-20020a05622a121200b0039cbecedf15mr6936277qtx.124.1667138482532; Sun, 30 Oct 2022 07:01:22 -0700 (PDT) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com. [209.85.219.169]) by smtp.gmail.com with ESMTPSA id az42-20020a05620a172a00b006bb87c4833asm2932819qkb.109.2022.10.30.07.01.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 07:01:21 -0700 (PDT) Received: by mail-yb1-f169.google.com with SMTP id o70so11098981yba.7 for ; Sun, 30 Oct 2022 07:01:21 -0700 (PDT) X-Received: by 2002:a5b:402:0:b0:6bc:b975:9dbf with SMTP id m2-20020a5b0402000000b006bcb9759dbfmr8362718ybp.437.1667138480980; Sun, 30 Oct 2022 07:01:20 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Tomek CEDRO Date: Sun, 30 Oct 2022 15:01:09 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Stanislaw Adaszewski Cc: FreeBSD Hackers Content-Type: multipart/alternative; boundary="000000000000f34c2305ec40ec80" X-Rspamd-Queue-Id: 4N0dHR5p7xz3qs0 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=hg3aD2lK; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::82a) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from,209.85.219.169:received]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; DKIM_TRACE(0.00)[cedro.info:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[cedro.info]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-ThisMailContainsUnwantedMimeParts: N --000000000000f34c2305ec40ec80 Content-Type: text/plain; charset="UTF-8" Hey there Staszek! :-) Long time no see :-) Good to see you here in the FreeBSD world :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info --000000000000f34c2305ec40ec80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey there Staszek! :-)

Long time no see :-)

Good to see you here in the FreeBSD world :-)

Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
--000000000000f34c2305ec40ec80-- From nobody Tue Nov 1 23:26:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N25l81tldz4gLyT for ; Tue, 1 Nov 2022 23:27:00 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N25l73ks7z3nck for ; Tue, 1 Nov 2022 23:26:59 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 80183FBF831 for ; Tue, 1 Nov 2022 23:26:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667345218; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=0CP+bywlFkw/YYCrMFTdl4p0eyDooKuJ8u4V5Sso9+g=; b=KR3vEfK4hkM/96AJruTxJ6BrP1D5V6FPMsTItaFIKLq/raH4q8Y0xIdjIEKEXMH8 CT6d4GVLaBPVZbedle1A6qb9VF0NMZXv7i5xGyR5xwecSU9i06/mA/ITrxHZxNqcsfW d2sKaymyoGRM6IYGotMkMr60xWtHkBqXqJ/oxhhRaoxfOrS1MgepXAMn4CB6VBi8yRn lcfEH7iRR7R5C4DBd+DaDmxFHFFAW60raC4KszISlYy9j5xRfP6+jp/Ndbwl3ZvnbDW 5doNlLcNGVji/ktagTEJaFYRcBJA7prKbKFWDZnpbH6bwqSOs3Jl3xgRlfaGQoXKmpW xMtt+NfO0A== Date: Wed, 2 Nov 2022 00:26:58 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: Subject: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N25l73ks7z3nck X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=KR3vEfK4; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, Since the release of the "Statement on FreeBSD development process"[1], what has practically changed? In OpenBSD, AFAIK, absolutely no code goes into the project without at least 1 other people reviewing it and approving it. This can be seen with the "OK" in the commits. What has changed in FreeBSD since the statement? Thanks. Kind regards. [1]: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html From nobody Wed Nov 2 12:56:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2Rjl3zKXz4h6WC for ; Wed, 2 Nov 2022 12:56:59 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020014.outbound.protection.outlook.com [52.101.128.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2Rjk3lpqz47JZ; Wed, 2 Nov 2022 12:56:58 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NbR9jHLOLHs7xrvTxDTyxdUgIH1Dv1Not1dgiGMVH40pNwT9MXpw3oht4wikTydYYfKAKAt9bSMCggiEPzeXaY4pUfTTLDJ+jrsmBbF9P+/kE2i/+fGMwkYcskxhLfv/nimPQ0QXEflqB/6jhK/R35CkTGU05G6db9Bx3+/lR3zcFjmTDB96Wn+W6eYi1WVSljZRnVyIStCGAUu9rrEMU1CzbZ3hEQd9VHf8oeRseq1Vrogawg+koEQbffLjFKI+2kMaNpfqnrgIJn/gGLixgR4K+8woZEWUODKqtoBh21002n1wrB1HfMbLx4sftR5HhMJVXurAD+D/a5scYaj2cQ== 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=1LtY6oMwOYL7cuTR9Z7fH8qPjq8O6HwD199wYIKZe8c=; b=ioCFHiWFyVR+lLFzWtwplMQmmM4V4lJuxZdoQzDhU1K8cCmsbm/OiJEORZyUtuWK/I7RqCwwGDUVjrdBbU3OkuCCP0T/C2OMQp/4azHJHnbLkxqmZOxgUxp7qixrgswOtMNFtpdDRnxePEi4Aa68ZWq45XVDFECYDAoiXSOcGwJhCtrYYjGcWsY0kEaXZUor7uoVzybhSO3kWu+LPljM6deeEneggeZj5O6N/Hh3orTKXnboxBNhFE49r2EKsKGRiSL0i9ftVG9CqTmMs4hHKAZIUSwOj+e3n2F3qX7yypGvXjDPFvik9FZIWHcvWD2sC08xWLmJkmhhmIuQOCVvMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1LtY6oMwOYL7cuTR9Z7fH8qPjq8O6HwD199wYIKZe8c=; b=ZeNKeGZkeOogpUYKeN2AOyrGdQSfBrEhAZDfK8VoMT/OVvCcAUUmI/IrSPrRayKdL6d4oFKbTKktfgm1foMzHCdlEQCAnBYEnhZSv3qAL0xI327cN0fAyQZYXJJgKzU2ssDI0o3Y8POqEvSRbSwZEfwj1w1LllZi/oCFBtAiZMA= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SEZP153MB0661.APCP153.PROD.OUTLOOK.COM (2603:1096:101:90::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.0; Wed, 2 Nov 2022 12:56:52 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8%3]) with mapi id 15.20.5813.004; Wed, 2 Nov 2022 12:56:52 +0000 From: Souradeep Chakrabarti To: Andrew Turner , Warner Losh , Andrew Turner CC: Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: pcib msix allocation in arm64 Thread-Topic: pcib msix allocation in arm64 Thread-Index: AdjuufO6ycLtH5MCR8mZtsYiDG7SfA== Date: Wed, 2 Nov 2022 12:56:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=0dfe8a2a-870e-4e0e-abf5-7be9ecd10bf8;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-11-02T12:51:53Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SEZP153MB0661:EE_ x-ms-office365-filtering-correlation-id: 6ab5e211-b2f2-4aac-72c3-08dabcd1b644 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KkQChINR0LmKPuKQVx3vdQVkmRF+WepVQGVWzXjrtNtaLDwjezKtbCYffXQG0AcH/K73u/4YAIwoxb3yUdnMmkYWtmyPDHEa6MSKfB2ef678lCFLRYDH9XArMzNktCLe6bs6OnHqC526GFu2aTN0EL2i+hCSxPxWMuw+LIcO19VuaxKfgDYnkRGEJ4bvd28g9NcBQ1ShTuEJ46494fNUMM8+Hj07XlgXvF4rjAiibTZVIdhESXh7q+5O2FF4awr42lSgtohUkdIgUDy/onTz5q/GPhEzDwO4rg8NTEMgfAGG4k+uSR9cY9QA3pMjJIiTWaW3eFNdoye4W4hRxIHdaHQOqojRiq+h4jxw3z7FQTeKThrJufp9UmxtIUvWbqEcP24+28N1GVHy5s003C62u80s7b9eHFtZSNFdRwDWpsO69OX77xaAUKg3jhNfxwlmVxXDkeK8SkjmmLWnTGlhPGOESqtDlLQQXaZbbgTibKQZ1+jW3hC9Mw5/3rKYkXREuEJjMuBLfyfrvcAjGgerGixwGRG6Rgr1xCZEKZQWvpJwMsadsAlclXYR+IaSFnl6GNfGjXDA2ERXaZwBgvifffG1o+dC0oRA7Buj6Jn0HF58owD1JiIGENvHSWF6f6u4h6AMrSM7zdnH5m3X/A6UusosM1iKfUvv2TC6YuvKuC3cxI5R0Cryidgi3qs4gKQzm7N3nFuT3gP86KXYFJTf41ofAYQsZVQBrbSJm4WdVhZUYoGTPeYdZiCqMDxGNx7aykhzU4G/5BQuytwT9Z7Hurua/i1PM7gp/hzRtfGD4fHNzdiNTMLJUoC8kwcPTDD+ x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(346002)(366004)(396003)(39860400002)(136003)(451199015)(33656002)(38070700005)(55016003)(86362001)(4744005)(82960400001)(82950400001)(122000001)(38100700002)(316002)(64756008)(76116006)(66946007)(66476007)(66556008)(8676002)(6506007)(7696005)(71200400001)(478600001)(54906003)(110136005)(10290500003)(186003)(2906002)(8936002)(5660300002)(52536014)(66446008)(4326008)(8990500004)(26005)(9686003)(41300700001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?I5OBW2RV2Z7Fzk8ZOjJvMw5sG6wtnIWBAVTVOqibRLH02f8RolSGOe9CafNM?= =?us-ascii?Q?FdYbqFbW5DKfybMevfVaT5agmmK3U59UPJ9u09h28ZYjlqIJeE+pYxvi4Sp5?= =?us-ascii?Q?dwm0/sGF6ErLwo4Dy8LYos3pIdZP7yUrhxgEGzvRI531ulxWjDulqvnPc007?= =?us-ascii?Q?iznLlQjgqwHE8hj8xUOpehQw7Wn7hVQodSMRtWJpAPA73TvWNq5ilfyM7z5n?= =?us-ascii?Q?5eUenkJOuI8sCsKhjbfjvUIP8eTkQC8rxSoV1Sps0/SqlptriQ9uRKMRV8Zj?= =?us-ascii?Q?id2pzycoU8Ts5sKH02SHlPX5bMT4brqVrDSmiQVcaHoy2OuzTguJlRKDNacf?= =?us-ascii?Q?rBB+vBQtV7sZEouCVFHQih8eM8uAACq4i4whzTxeB1ztxS74LNvsbLxqh/99?= =?us-ascii?Q?91QEPcgbfAXcsf0VrvpxcxlUJza/WC3VJW5VM3s5VnTUxwsEMCTsa6mVV2Wj?= =?us-ascii?Q?qLGPdMvs6i1/PVn6zG1/vWUUQMrgEVbdk8ijMVSJ/+wWm6uUkif6kjzLP+q6?= =?us-ascii?Q?6EL1qFwodYvOXMHazKVrSddZUWnsrIhTBFUP/QL8jj2SLUrR050ifjptJayi?= =?us-ascii?Q?P+NQxqe7Koo1yvZ/Aa+RzorGyECDBCLqPB8HR4yuUWq6zvPYnTWQXZcPrinZ?= =?us-ascii?Q?HubwZVeEEa7LR/fm5exyq0qZXaIhtzpw6LWi1kTS5JcptSO/MsmoLm20lrdS?= =?us-ascii?Q?DdnQBFtnunRe3Y08CghiQFc8X7yq2GfgYntXhE8kDk8usPiyl5sgx8btAi3J?= =?us-ascii?Q?uOcjahw+EuNtZESE1Aiu31nnyOoHuLaJanmk3i+EHBqNtXTakaFh0X1+33L/?= =?us-ascii?Q?4lfF5HQN/+EvcZwwa1CZwubXYRAUMgOD1kvXT7BD0MCX51t2G4WmgeVDsFaP?= =?us-ascii?Q?Zb2lT+4VuPhRwKg6VEcNo7kZeDVSF69eaawOfQPZe4Sd9b66bUZsfLJKz33A?= =?us-ascii?Q?P/KCZFFmTzB6i+NgIn4vfT/+qG92hUza0icQaKAYzmKxYYZrN2Pv9MEoz8ks?= =?us-ascii?Q?1/Ih31cgNkoUTIRZndmnDTsN3Dzn6dQFAvTVkEIa/Xkmktk5jwvCzuD9T7/9?= =?us-ascii?Q?lf8Yd2yL1B7qhRK2MSaZ8nGfFdQfadcXF7fr+uIt311AkLLw0Orxukdalt5b?= =?us-ascii?Q?K4jVST1/BSRkSJ4dEwLx7EZXAf6toAXi6dHckpzAd6D4fW+oGu+Di4SoQMzX?= =?us-ascii?Q?zmn+EwL7QBk1YryIFQl0Cg+VmjmgwqA0SK7sHN2NG38oGYBkgtZNatFNXKD8?= =?us-ascii?Q?70KqcoWXN869XBYXRbmQ/ckyFcHdxUdVOsrk+x8Eg8WkpQ5hVckFRI28ge12?= =?us-ascii?Q?PQng1aN7BJavhGbnoVc7207aTCpxtvCKYyv21xtw6EdO7NC18xQ+/nuDUfuk?= =?us-ascii?Q?wuR18QOqBmc2FDRMnIWskl7YzPdrZwspT6P5N4l++/6K4Yyw7f1qP2AYSeUx?= =?us-ascii?Q?twzUIVJVHAwfx3EGwjcgEDdhDmxEWXI74nrdhpf+/SLdL34ggejZh0jVraAR?= =?us-ascii?Q?RM/38Tmk3tok3dh5KooQdKTUzLnUyNx8oMuC?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6ab5e211-b2f2-4aac-72c3-08dabcd1b644 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2022 12:56:51.8160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: X3IOk2DjX2rX5Qns8Ow1+uK5b0zDU9Eq9kqdvR/z56b2D1FkKKXLgfH7YYzGDeryp4NLkacbmYlcaLTlvglq+EM4vf1+yLiVPpEhjR7OJEg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZP153MB0661 X-Rspamd-Queue-Id: 4N2Rjk3lpqz47JZ X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=ZeNKeGZk; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.14 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-10.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.14:from]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I can see in x86 nexus.c has implemented pcib_alloc_msix using nexus_alloc_= msix(). Which calls msix_alloc() for msix allocation. But in case of arm64 I don't find similar pcib_alloc_msix implementation in= nexus.c . So, on arm64 what is correct way to get allocate msix ? Thanks & Regards, Souradeep From nobody Wed Nov 2 13:24:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2SKD71lnz4h96D for ; Wed, 2 Nov 2022 13:24:16 +0000 (UTC) (envelope-from bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz) Received: from e2i251.smtp2go.com (e2i251.smtp2go.com [103.2.140.251]) (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 4N2SK96pPnz3CNN for ; Wed, 2 Nov 2022 13:24:13 +0000 (UTC) (envelope-from bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1667396353; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=k+TRGyPuspNBNciy7OhIOd1ZzeEiuR1wDmJ94SBrE0U=; b=LKdl+K40 M5v0kvzbmwpp+jX51Oq3QtRFbswfzpfHuPg/Hamb5/f71tjs1ZPCZ02Rz/7BQKKyvEL6yHSmyYAwz Y9TDvHdpMc/HM7UNJAaL8OHunc2+Did8ipv1OZWnYF1ZccwbFGGEVwgS9DQln99KID/+Ifz4Wjx6o DzpnIH22L66InOpSaSZl1oh05sDnIdY2C2zkRHCyzr5GnDlVHEOAoVSZqaxdHUn9Fn6KcdwG6BzEN hleZYJWine+qiKi88WBQPQjUkonTisMYsxi4yniRv9DZkjUyLf1WYJ/CqeoQ0czCS0k8NT26vW9RL D+4k49T/Kxz1Ni8RTXbYrV+92A==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1667395453; h=from : subject : to : message-id : date; bh=k+TRGyPuspNBNciy7OhIOd1ZzeEiuR1wDmJ94SBrE0U=; b=P6Etno7kYAanHYWf2oAOD0o3er4mEjzOOa5TxKWVvcasnOaPpJjmx7wBMO2Lt4zDeBxYe UolCD9pStfE7NNBcy69q/g/QNcPnbR4zwp3+bZ77wenpKn7bfkImF+SnleE7UqbnU2KY5Dv CdNpuz83B01v30Xur0MSRlM6KGY5L0kAg20E8cP0QykV0Tw1sW/umPAwewdb8tZcYfMwzdP 3adF8zmrK7sRRnc/7cKUVA7+ABUdjMxZBITWhzPOiwXvH5LepQQ0xXUdEHSghhsLY9UcKIx 3PB8faNt0qMXLtK919bVU567L9VxG/M4txz9aQN2b68zvWugvG2VHNBq7K7A== Received: from [10.139.162.187] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1oqDix-Y8PGYE-5D; Wed, 02 Nov 2022 13:24:07 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1oqDiw-4Xpot5-36; Wed, 02 Nov 2022 13:24:06 +0000 Received: from smtpclient.apple (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 28B958A83; Wed, 2 Nov 2022 13:24:02 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: pcib msix allocation in arm64 From: Andrew Turner In-Reply-To: Date: Wed, 2 Nov 2022 13:24:01 +0000 Cc: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> References: To: Souradeep Chakrabarti X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Smtpcorp-Track: 1oqDiw4bpot536.Yr90Pn5oTkb2w Feedback-ID: 790814m:790814amQcrys:790814sI1eae75bD X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: 4N2SK96pPnz3CNN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b=LKdl+K40; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=P6Etno7k; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of "bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz" designates 103.2.140.251 as permitted sender) smtp.mailfrom="bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz" X-Spamd-Result: default: False [-3.86 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.959]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz]; RCVD_IN_DNSWL_MED(-0.20)[103.2.140.251:from]; R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22]; R_DKIM_ALLOW(-0.20)[smtpservice.net:s=mgy720.a1-4.dyn,fubar.geek.nz:s=s790814]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.zdmhwepc30=69ay6p1uptyl=iftnfeedlg@em790814.fubar.geek.nz]; RCVD_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[smtpservice.net:+,fubar.geek.nz:+]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 2 Nov 2022, at 12:56, Souradeep Chakrabarti = wrote: >=20 > Hi, > I can see in x86 nexus.c has implemented pcib_alloc_msix using = nexus_alloc_msix(). > Which calls msix_alloc() for msix allocation. >=20 > But in case of arm64 I don't find similar pcib_alloc_msix = implementation in nexus.c . > So, on arm64 what is correct way to get allocate msix ? For an arm64 system with ACPI it is most likely handled in = generic_pcie_acpi_release_msix. For FDT it can depend on which PCI = driver is used. In either case it will call into intr_release_msix that then calls into = the MSI controller to allocate the vectors. For a GICv3 driver it will = either be gicv3_its_alloc_msix if you have an ITS device, or = gic_v3_alloc_msix if using MBI ranges. On ACPI we don=E2=80=99t currently support MBI ranges, although it looks = like this could be handled by the existing gicv2m driver. This driver = should already work as a child of the GICv3, however it appears to be = FDT only, so will need some work to add ACPI support. Andrew From nobody Wed Nov 2 20:50:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2fDT66mVz4gtkJ for ; Wed, 2 Nov 2022 20:50:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2fDR5Dy2z4K8p for ; Wed, 2 Nov 2022 20:50:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A2Kob3V062412 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Nov 2022 21:50:38 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667422238; bh=tvArad2Zb0YIc/tCvCw5vxpDXk+Ae+Q8FyNSjaQ7KW0=; h=Date:From:To:Subject; b=CeyB1Y88058WIbkFD5smaap39RJKdDzFsPY3jQiqrWvdDpOf/f5pxW1X+KYLs/MUz 6T1k70qltL3dH1FeWbeersGff1ttR6wPQ7xBojUj/9U2euyyNCoKLnGMX5bzeXnOs1 esJxnjCY53X06V71Lb3vwF0WIFuf82vGCfVhbJH4= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A2KobdO016356; Wed, 2 Nov 2022 21:50:37 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A2KobqN016353; Wed, 2 Nov 2022 21:50:37 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 2 Nov 2022 21:50:37 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: SSD - trim fails Message-ID: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4N2fDR5Dy2z4K8p X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=CeyB1Y88; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[puchar.net]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N i have laptop with such SSD drive ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S1K1NSAF415536 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 244198MB (500118192 512 byte sectors) everything works very good as long as i don't do trim when trying trim - for example cleaning all drive with trim -f /dev/ada0 i'm getting (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 00 00 40 00 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error any ideas what is a problem? From nobody Wed Nov 2 22:27:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2hNl17T6z4h66t for ; Wed, 2 Nov 2022 22:28:07 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from apac01-obe.outbound.protection.outlook.com (mail-eastasiaazon11020024.outbound.protection.outlook.com [52.101.128.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2hNj5z4Vz3Lts for ; Wed, 2 Nov 2022 22:28:05 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iJ5lspnJwlI+rF67BaLMkoQHtJU6h+cn5gTcdq/IGNxP9DLElQ85ZODthyGthllKyBzSgdv+Jp3gvFzBsUrC1NjbVgwAsFtzRDxOZHdTRxMM2JPqLWc8TJZX1WPUWJVAWF7j9eLX2YofkVDn2wektZx3+2wprLUM6/bwzE6cwOftjjUPeU9g8jLPnC1/Q6UZOjxE1/dej485uFIKpe6iyctGhagFisacIZDUxg2jVS4HtaL8RKL3zOKQ8zCxw2mJbLW+Ux6p2/A7Ywk3T+acp1zpytAMVCFgrZVHLqMqH7iOjjksXjaAnCq09GQTsM3/S5aMb44Fwxi4Mmcd7Zaq3A== 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=9S+8zNGqus6EouT84AWpIzcFgsuhsXLaWhWAjipsNqk=; b=dRZCxEn55vP+7MgYbbLcldgCyKryOSsaJFMxfBzNUkuKoor9N7uK30l6GJacH/y6cFV4BEujNeuWMHslmHjxRLk8X9Il+rdR6RgjffMNGbH2I549L1Q9vajEVj1JNc5wICoNa5ezeSWqotwEquvzt4AWo8ShP4hrcdBwfwCM3Ee5fKqih/kDfFHJUtP88sojRMDH+vWc5nvqFyj14eoGeBWIieM9bq5SuJq/6rtYqRNl2XsOQ5aUU6NqtkzVQucnL50pJNbnIdPqIM1srFXbOvfMSQ+/BSkSuZv4zcg72XHKz1JqCxjrkZktqEe5uQ4bl7FQFavRFVkCpdFQZExwxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9S+8zNGqus6EouT84AWpIzcFgsuhsXLaWhWAjipsNqk=; b=E2JXd6vwqvmH+g93D1+h/LJ2IWn8B35+QQxhDXoUZph5CaiX7gioR4VwrpPcX1t/2CnoR7IonAkMJ6SpvAOk2drnJTcxcS9NWERD60YcBxHVSKzBi/tyfkR/xhdTPgPVqBnGForQutBZR1K4XgZwjY+VN+YaR/fv4Ix9TNXSuBY= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by KL1P15301MB0436.APCP153.PROD.OUTLOOK.COM (2603:1096:820:20::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.0; Wed, 2 Nov 2022 22:27:53 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::f35b:6c4a:fd92:c6f8%3]) with mapi id 15.20.5813.007; Wed, 2 Nov 2022 22:27:53 +0000 From: Souradeep Chakrabarti To: Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] Re: pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] Re: pcib msix allocation in arm64 Thread-Index: AdjuufO6ycLtH5MCR8mZtsYiDG7SfAABGsiAABKVwCA= Date: Wed, 2 Nov 2022 22:27:53 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> In-Reply-To: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=605251bb-299c-4422-9878-b98f847e8b93;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-11-02T22:16:09Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|KL1P15301MB0436:EE_ x-ms-office365-filtering-correlation-id: e077059d-6700-4a17-01e5-08dabd217bcb x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d3jlDYz+zPmMvnflb6hKP0+pOqOLg3mf2FvqDCADDtV1oov3AKWz9C+RxXEgIarpQH+LbYxqyLmtnQ0ED2w+8Hdx3A9dpIoZ8mfS0zk5KGIMp17Atqg3sh1YiOZmNbn6h5yf/58E9IZV1d4dS01gIkJf446xb1bxrN31mhkNcX1xW6AdodwUEAIdHaUGGR1LZIBffLZEbmVdPCFgE9ooythuaOQmx01wevBGmk4bS/qktlYQvDpip/N47o61fLSdsSilPQ8WK22JprQxyQnBUsrid3HhdpEEGMqvYSylcCQkNhX4NtgppC5LK1CitbbQg/eWktnVM8iX8paHgXw5IeERTZrfdIAQgMV+2NquiCHhvcA8ml/VsSWmate4pySBiW1/cIBjff70oyKaRbyaeBa7l8v6Dco0iP4AmDPcSpeevcqnnG+jNtX4xvhrFe1r+uNYvWsMSmN4DzAQtcZV+B4OAmGIAff5mmhSNT8vWUCW110TNbLJQt2Zg1qYE29uNF2Y7AzefJzPA0F2CZQx7YDA7Ea6ngOLZ9kpXAx95coluKIlf6Km58sje/cb0O1kuqsnuDE4L6VWnLQVtKRV4IlVEAeMw4cZZN9oyzL4iC6Nv/DiZA/EaFs60LOXldMilUG3670RmstyX3zjM16Xea/eQYY7daBGAP3BH0FZMNl6DlD//oyr3UPl787n8qBJNpS4d+5Gn0raeSDpVqcE/bhJ6XsHAPiFQXF0U9FGApaoccq8/UQaP7KN00/CNvo2nSvahwrbZBlbRmJJhECiR1x1ZyLaDwoUU9Rw/ui0DqAqjAlwgxPqhuQqV4JK9Ws5 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(451199015)(6916009)(38070700005)(52536014)(8936002)(5660300002)(33656002)(54906003)(86362001)(4326008)(316002)(8676002)(64756008)(66946007)(76116006)(66446008)(66556008)(66476007)(41300700001)(26005)(9686003)(6506007)(7696005)(53546011)(83380400001)(82960400001)(82950400001)(10290500003)(55016003)(186003)(71200400001)(38100700002)(478600001)(122000001)(8990500004)(2906002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cHVRczlGdzdzMzlvcEkwRzhtMGQ2dEFhZDIvdWJDaGJWRTUzVFlkOHd3TFE4?= =?utf-8?B?aGlKdkkxaUMrajIvR0N5UnFhNjJZV2Noc3dWTElBTmVCM1gwVVRPcnk2Y1BL?= =?utf-8?B?VDZnL2JPL0FkYTVkMWtuL0o4U09tL2lyaThCY25LVVRpQm9EWEp0cmtOMXFl?= =?utf-8?B?L1RHYjJ5U0F2R0lGRmpCQ3lsbHRuQ2M3OUZqZ1Nld3dGaW1WVVU3Z1dPZEJ4?= =?utf-8?B?TndDVUkvU2UyYlBTc0REUG9ManlJN3dVQTNCQnVESVo2WEhnZVBORExnYTlQ?= =?utf-8?B?ZVVuWXRQbGZidEhyZm5aL25JTXVGZXc4S3NCMHB1a2t5blczTEFMZldtY0Nx?= =?utf-8?B?bkJIUWVzOVIrcWxKc3huWEc0OW55eUFsb3pveWZoQ3BjN29aUGNtOTRCMEFw?= =?utf-8?B?U2VTdHIrRjl6S1NaVnQ3V0Z0OStXRlptMEFFL0VGZHM3ZUJkUHMwWmxzVnh3?= =?utf-8?B?Q3VEMGpqRE5Bdy85QjhhRmVFZkwySUg1Yk5pSE5YOUE1OG9oOHpQZnRSall0?= =?utf-8?B?ZFJjMmhJeUJpTUJnUVdpMVdzMzhNZURTS2RBTVZQU2wvZWw4dFBBeTlQOU9T?= =?utf-8?B?d2dDNWxKWXU3M3ptVFpyVy9oanRUWnZjZTlsUGUwMEg0SXg0OEJwS3cyc3Vp?= =?utf-8?B?NlpIMTRJcGxTNzdiLzN4V3JvQ0RYUFl6aGR6QUhJMU84NEpYNm9LSWNZOCs2?= =?utf-8?B?amtLb2JLaVIvQWpubXBFaytHeTdNOWUzeDY2a2toUXQrNWR2U25wK2pGQnJu?= =?utf-8?B?RG91N3N4V1JkNWsrbml6Ujc1cndnVThPdnN6L2V3RmNTbnFEME1TZGxsQXFT?= =?utf-8?B?UlpBa1Q2SzdpV3U5MlY5UU5OZTVxeE9rRVFwbnZ5VTdhc2VvU1dEWUlwMml2?= =?utf-8?B?UjZBYk1SM2R4T2x2M2JaQytuakx1TENyZVN1UUZlY21VNEdFZ2xrQXhqRXow?= =?utf-8?B?Y3Z2eS9JdGxOMG5iUi8yQ1JtM2NnTlNsN3VJamZ2SFc2VEVYdkRrVkx4cTZ0?= =?utf-8?B?Tlk5bHFKZnVQTjBnY0lWT0JMSVRtZDMzRXRuSk9xb1FNVkZJaGcvOC9HTzh1?= =?utf-8?B?S2JJVmwydnVYS3RNYUlkSVl4UFZ0Mm9IV3FwZFFHM2xtdFdWckZ3R3E0YlVx?= =?utf-8?B?S1VrZTI4dVE1angyaFRQdnpZcUJCaTk3dEUvWEl4R3VyVnRYeitFUVd1bW5l?= =?utf-8?B?NU1walhWd29JK0NuemszOHh1cmhWSlVnZ1RyNGFRNGNOSzR5ck9UdzR0STlM?= =?utf-8?B?bFk3bnIweFJoZEJCQzZScm81VmRCenBwczEwOURPNDhjN2Y5MGoybklnRFZw?= =?utf-8?B?eXpFQ0tmSWJaQlBpeVFrRXhRU2REeG1tK3dvblVqWGQ3amdwSk1DQjJxM0ho?= =?utf-8?B?dWVPODlBVTJDVFd3QmZHblFPZHhLL1pydGpiSUpkTFdZZ1gvNVhhWEFNMExv?= =?utf-8?B?VEx3MDVINlA4UkhtbUllTzlNSkNzYVVNUUxSSHZrYXMwR2duRDJZMXFxT2o0?= =?utf-8?B?M0QxdEFiSzJEZHdqNm5MUWFkakQ1VDF5bTNJMW1xcFJyalpUOTJvL3o5ZWlj?= =?utf-8?B?enk1QnBnSkdKNExWQ1cxYnh6SzNSb01KWitrMkIrbEdwVVZnWmVpWlNsT3NC?= =?utf-8?B?NlVaQ04zTTRtQ0Q1bGU2K0FQL2NSWlk5VUdHTWFkYk54dUdGa2tWdGtaek9l?= =?utf-8?B?QlhTT1ZzYmUraXcyeDA4QkdweE1vZ2g2TDJjeFpTSTlIN2srOUExbHRsbmlk?= =?utf-8?B?Wk1NbFJpOHRaVFdaTy9EUTlHd1ZuMkYyRStsTmZZZVFEQ3BKd1c4NlNxVHVI?= =?utf-8?B?cEVvYUtzNWt6SkhmUTZUVk1YQTNHMXJ1M1YzUWZFYlN1QUh3eHA2WEIxWHdx?= =?utf-8?B?OVFwWjJBOU9veW1KVVJpdmEzd01WeVpOeTNhM05HTHVETUlVQ3VFbm41SXFx?= =?utf-8?B?cWZDY3NTRjQrdnY0N1I3bEtSS3dLeUxFWlp2QzZIemdobldtMmpweXB6cTNC?= =?utf-8?B?aE9YNzFTTnh4bnZqYWtOaWpiK0duOEJaYk80Z0RPajRnN2gxMnJvZUFBR1R0?= =?utf-8?B?dEdzQ3NzTkRzL0NYRTBqTVFpRFBtckZQQ3NEQT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e077059d-6700-4a17-01e5-08dabd217bcb X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2022 22:27:53.4507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NK9VpQ8+HxbTlbZZy+kKsGbxqf5x4Wz34KA3EEdyZUZMyZFZDVF7QoOM9I8o9XkAn0OJvmlYQ3VFBxq72cqBWUiFAM7QCurKWZkUbCJdsNU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0436 X-Rspamd-Queue-Id: 4N2hNj5z4Vz3Lts X-Spamd-Bar: --------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=E2JXd6vw; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=reject) header.from=microsoft.com; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.24 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com X-Spamd-Result: default: False [-9.90 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.24:from]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-ThisMailContainsUnwantedMimeParts: N SGkgQW5kcmV3LA0KVGhhbmtzIGZvciB0aGUgcmVwbHkuIFJlZ2FyZGluZyBnZW5lcmljX3BjaWVf YWNwaV9hbGxvY19tc2l4KCApLCBpdCBjYW4gYmUgY2FsbGVkIGlmIHRoZQ0KUENJIGRldmljZSBp cyBjaGlsZCBvZiB0aGUgZ2VuZXJpYyBwY2liICggRFJJVkVSX01PRFVMRShwY2liLCBhY3BpLCBn ZW5lcmljX3BjaWVfYWNwaV9kcml2ZXIsIDAsIDApIC4gDQpCdXQgaWYgdGhlIFBDSSBkZXZpY2Ug aXMgY29tbXVuaWNhdGluZyB3aXRoIGEgZGlmZmVyZW50IHBjaWIgZHJpdmVyIChsaWtlIHZtYnVz X3BjaWIpLA0KaW4gdGhhdCBjYXNlIGRvIHdlIG5lZWQgdG8gaW1wbGVtZW50IGFsbCB0aGVzZSBm dW5jdGlvbnMgb2YgcGNpX2hvc3RfZ2VuZXJpY19hY3BpLmMgPw0KDQpPciB0aGVyZSBhcmUgc29t ZSB3YXlzIHRvIHJldXNlIHRoZW0/DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQW5kcmV3IFR1cm5lciA8YW5kcmV3QGZ1YmFyLmdlZWsubno+DQo+IFNlbnQ6IFdlZG5l c2RheSwgTm92ZW1iZXIgMiwgMjAyMiA2OjU0IFBNDQo+IFRvOiBTb3VyYWRlZXAgQ2hha3JhYmFy dGkgPHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tPg0KPiBDYzogV2FybmVyIExvc2ggPGltcEBi c2RpbXAuY29tPjsgV2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT47IGZyZWVic2QtDQo+IGhhY2tl cnNARnJlZUJTRC5vcmcNCj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogcGNpYiBtc2l4IGFsbG9j YXRpb24gaW4gYXJtNjQNCj4gDQo+IA0KPiA+IE9uIDIgTm92IDIwMjIsIGF0IDEyOjU2LCBTb3Vy YWRlZXAgQ2hha3JhYmFydGkgPHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToN Cj4gPg0KPiA+IEhpLA0KPiA+IEkgY2FuIHNlZSBpbiB4ODYgbmV4dXMuYyBoYXMgaW1wbGVtZW50 ZWQgcGNpYl9hbGxvY19tc2l4IHVzaW5nDQo+IG5leHVzX2FsbG9jX21zaXgoKS4NCj4gPiBXaGlj aCBjYWxscyBtc2l4X2FsbG9jKCkgZm9yIG1zaXggYWxsb2NhdGlvbi4NCj4gPg0KPiA+IEJ1dCBp biBjYXNlIG9mIGFybTY0IEkgZG9uJ3QgZmluZCBzaW1pbGFyIHBjaWJfYWxsb2NfbXNpeCBpbXBs ZW1lbnRhdGlvbiBpbg0KPiBuZXh1cy5jIC4NCj4gPiBTbywgb24gYXJtNjQgd2hhdCBpcyBjb3Jy ZWN0IHdheSB0byBnZXQgYWxsb2NhdGUgbXNpeCA/DQo+IA0KPiBGb3IgYW4gYXJtNjQgc3lzdGVt IHdpdGggQUNQSSBpdCBpcyBtb3N0IGxpa2VseSBoYW5kbGVkIGluDQo+IGdlbmVyaWNfcGNpZV9h Y3BpX3JlbGVhc2VfbXNpeC4gRm9yIEZEVCBpdCBjYW4gZGVwZW5kIG9uIHdoaWNoIFBDSSBkcml2 ZXIgaXMNCj4gdXNlZC4NCj4gDQo+IEluIGVpdGhlciBjYXNlIGl0IHdpbGwgY2FsbCBpbnRvIGlu dHJfcmVsZWFzZV9tc2l4IHRoYXQgdGhlbiBjYWxscyBpbnRvIHRoZSBNU0kNCj4gY29udHJvbGxl ciB0byBhbGxvY2F0ZSB0aGUgdmVjdG9ycy4gRm9yIGEgR0lDdjMgZHJpdmVyIGl0IHdpbGwgZWl0 aGVyIGJlDQo+IGdpY3YzX2l0c19hbGxvY19tc2l4IGlmIHlvdSBoYXZlIGFuIElUUyBkZXZpY2Us IG9yIGdpY192M19hbGxvY19tc2l4IGlmIHVzaW5nIE1CSQ0KPiByYW5nZXMuDQo+IA0KPiBPbiBB Q1BJIHdlIGRvbuKAmXQgY3VycmVudGx5IHN1cHBvcnQgTUJJIHJhbmdlcywgYWx0aG91Z2ggaXQg bG9va3MgbGlrZSB0aGlzIGNvdWxkDQo+IGJlIGhhbmRsZWQgYnkgdGhlIGV4aXN0aW5nIGdpY3Yy bSBkcml2ZXIuIFRoaXMgZHJpdmVyIHNob3VsZCBhbHJlYWR5IHdvcmsgYXMgYQ0KPiBjaGlsZCBv ZiB0aGUgR0lDdjMsIGhvd2V2ZXIgaXQgYXBwZWFycyB0byBiZSBGRFQgb25seSwgc28gd2lsbCBu ZWVkIHNvbWUgd29yayB0bw0KPiBhZGQgQUNQSSBzdXBwb3J0Lg0KPiANCj4gQW5kcmV3DQoNCg== From nobody Thu Nov 3 04:28:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N2rNL1GcBz4gs3r for ; Thu, 3 Nov 2022 04:28:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N2rNK1sRyz3mKf for ; Thu, 3 Nov 2022 04:28:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667449695; bh=cuESWokoYcfpnjoTEwemmLJl/klH7JDZqcWuMKEQNOA=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=ZJ9icdChFfBXANHa5ApLX2EYQKcyFcZBbQGhRXWg3my6B0MGuTKRABkUdIHYQfY/cIkKF5etjgiscolcmLaCEvaR6s5F2mSnsDT5FWJo04Cok7dC7F9Ak5rxADLHn8t8n/OACn6NKqd2lwJs3ayfpLzAKwvEhMlQ8Ak7c0UzBRJr5gmHmNJWsHPM1pGfTiEj5PmDEvP3m1sx+DUNtNMrF7RXPQHRfiRqunQ5DT1YGWDP/MlOGS6UzVWd7xyJoinW6UmpDJVw4FRhL0yHtYy1siqdFCnS40r1Jymu6rnpkMLAELVxtq2bKuEPNoH3A866eT1QIsekdcK6C8hrOjgFvQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1667449695; bh=/QVEiwVbX/V817zYl9TXysER9LL4mylTiZ8mRUP22ob=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Ug1Ey+LqgJJ92tA+42NgjxTusfIRs+2bZ1PNzUw7+htAlfSqF/DdgKbcY2yhhhv3SwQcPJmESZUNVjHmNsd4r8uH6kOWR2lI3sFvLS8TP40P6mVkMWg42ChQEp2dBl8549noLtNQWZatctulcPkYulofz/mXDQKWVKNCpP7roCdZtPw/sfyo3PGMCkonEqv/B5KDnfhA0B9pqTwAyBJTFjjKZXnEK7TaeIef0McLsj8YVzsd74p1RrS04S9UxRyMVz1I9N3Ms+iK3GEyfSCGXlC8hzDdv1169dQCXRhVPA2HA42I1b8p48F5KYfrlWuBqqcrEDxEc0hk/PSYngmMKg== X-YMail-OSG: haJHAp4VM1m58mcAoPV1Rjc4uNTdUJkbbpiDKYdzX0KreTfn0JwHzCqniMtUMtI 6liM2RwdNNc4r7HrmxieSYnrwECH7unoPmt0wuU4QzutRJhOjPmY79ty3cmMK9kYQ7XTj6Ms3Jbd g4uwwu4zDYssPwZrl2iZW5qENK_.eI7XDuXN8MMg_yMYN1ar4zGPE_TDfIhC0gKzxhOLjF9cyi6L 5tLiIbSI3L38kZdUX32nddcjhF_aY8JYuODT4Kl1Q40vgXaXQTP9o5N2tJZmOUXNoaqoa5fBxAAP YJovq55yaBgD.4gynMaWwBBFF9TcZg1ISiL0hy.mK.AKv.rj7kfkgRdxaABFpLqVz29jU9fR6xh6 wnOpe0roYzF2ly0b79VciO4ghsN2PvIO.DUFmpmJCl8XY1GGHhdgl41uGL8oqYPrhgwgVuKh_.8o ViPBiF8VKKkF7gIdEeZny9bWq7pDyVcO0ve7ovm7TfwYLjz9X_NR_fl.dEu0wJKA7uZLMaZHlqpT JHakgRll97RCNywhPIbgCiyufRGQFYJnaWL7SKmaNCn_.w4rZqbfkalVPJ8itRLEmJJU5paJOOKF yhqbkBbDF5R.uLxOSTldqRCGquV4B7l.lOt2rBvwJudXFPgRz25rhiijGLFZNVHf4OOClx9fQL7y xGXhR4Opm5bPphpbmk86TjIdLdLYpDPxQkaezgfkHZ12Sh11EF9LQqd2wcr0MAe.NNhW612VqGJs kjG1BDobSQzfW0kpvEDBjflAvLIRqrWpD.QwWoXf0Awi0YIRuY_w55.VYBuOPEDPmHiwYZaAu3Jt A1mENbKpoTaxwav4WapnjGN6Rii2NjOj7iDmw3FCBl6uiTwTXZT8XchzAal.RlFBvPZ.uPq9Iumf qfdRkcz5sgMb10kNknm8MggOk7R2aFObSP0KpqTA5Q0Ys1AbGsGhM5jadIB9X5fThkc54m_75Xp_ wA7HGJtix5JQJHJPDhwg5SzmL2KF9iP9wCIHWBVTh11OAYoOdGT3XP2KUdFtb0syuhWMJLnYkW8_ F6M0tK1ELtD6KJRUDsqsjMtnc_osOWqO9OePWpW3CBPEGA.9YC76xypqJVHl3c.pKjNvLn3E4jBf UeR_fHaBwl8Ttn32wS.OyRmtuUhN.RMhcrSAVsfI0K0youmJjqDdhtQDJgLEinkmv8hDbR3BhD0q XvHJJbEOFT1VzFwueejMpwFy09QO6yqNXPucCF1VtPto0voNvn04mU.IWK.h_taHLcAMByp7H3P4 ZREZ3t5Dafyj02msEOde.s7KDclxO4Fl85N6g.oLF1.uDgLKmm9omoykLlKGzBUMuCD06_0UM0Xb n4QOpwO5MVSBSBZmg9F0_nxlaTx51OmHpcU3SGSmfs8axm1t1fD6tRo.7zcNHv9FHDOktUcUtsp0 32bL4YVGae5FxZl0xSoqn3lSLGBMCRNohKmJxQj21vkDFjBvUJVRJxxqpGQrWcrCeJkChnweUIeL qKWQ1eIaV82Ct9RqSh4veb7j5NRDTqK7y3As2JckKMJtVhsuxO6ahoa_lWpv96imF9zr9pe_avDf BGCzzyBk0YEl4bzNIrUjUAQJFJFTWhDzj1pm9.QwqOdRcyAZG2BjvJcT8Xp.0pfGHJl2oincivbn AHWtfqVZpgq_6kVEkLVvMerQYN6bbWsHPNL5vjgnJj0DKz7gOgCl9NJW8wrytYNU4_auK.PcykPc AccNOx_myfg_rZxLcibaWnVH8DMyebamReyqvl3TBvJopx0KuJqUbwxibUlWNQxge2slodzh7vpl 2BQgzjSED251zMsNwuX7mBf9tij_UpVhemOiNyA3zhU7lnZ65RxYVPA6iROL0vnOzN4hT2tC_rYy 99hu5S.7wyYO7kgJyJeITF7YoeEDHli8wh1VDN3tg7WuSIdbQALi9v_a2GVqB2BedjF42OHzYP7s nj8Day1V7tjb04HsKS..2.7mIJmgqDtUpFnroDVUHlYFrD87kl5c.gQLdxvVQyT.4fABMM4q0iFN lOazTUmPSmWCTf6zvZjLhcxuAF3OVhiCqLn2UDDXn1P6yJtT1EPm3b5vUhE1a3QHLNSK1XHAgF16 kWROrEOp9Mewg7zCHVMYMW7ujZbzC6SdkapJDvQmaF928xsXrOb8CfOZoiMSoxRId0Yk9jiShW7Z q9y_5aTHpx48FUiSuK5YWR9wazNiF5yKdpTqVdIDeMwME6I65JKLq99UazxsGm8qOcPYa3hzlfKW tMp0Ng_W9oSK8JNzZJ9.uZ6qF0z5Fx5Mkv7kfY0E6iRt9qMfDiU.NO3npXKSE8w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 3 Nov 2022 04:28:15 +0000 Received: by hermes--production-ne1-6bcfb7fb87-qqz4t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a081e930c0de70863a1468b7f14857dd; Thu, 03 Nov 2022 04:28:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: A FreeBSD DTB content handling question, via an example that currently crashes Message-Id: Date: Wed, 2 Nov 2022 21:28:07 -0700 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3696.120.41.1.1) References: X-Rspamd-Queue-Id: 4N2rNK1sRyz3mKf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=ZJ9icdCh; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.45 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; NEURAL_HAM_SHORT(-0.97)[-0.971]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from] X-ThisMailContainsUnwantedMimeParts: N The following setup for a question is based on the RPi* support code in the kernel, code that leads to crashes for RPi* DTB's from over more than the last year. The question is really more general and the RPi* is an example. There is for the RPi* support: static int bcm_sdhci_attach(device_t dev) { . . . sc->sc_dma_ch =3D bcm_dma_allocate(BCM_DMA_CH_ANY); if (sc->sc_dma_ch =3D=3D BCM_DMA_CH_INVALID) goto fail; . . . where: static struct bcm_dma_softc *bcm_dma_sc =3D NULL; . . . int bcm_dma_allocate(int req_ch) { struct bcm_dma_softc *sc =3D bcm_dma_sc; . . . mtx_lock(&sc->sc_mtx); . . . and bcm_dma_sc is made non-NULL via bcm_dma_probe/bcm_dma_attach (not shown). This used to not crash when the RPi* .dtb's used the order: QUOTE > dma@7e007000 { > compatible =3D "brcm,bcm2835-dma"; > . . . > mmc@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . END QUOTE so the brcm,bcm2835-dma happened to be probed and attached before brcm,bcm2835-sdhci was probed and attached. However, since sometime after the 2021-08-05 RPi* firmware release, the more modern RPi* .dtb content has had the order: QUOTE > mmc@7e300000 { > compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; > . . . > dma@7e007000 { > compatible =3D "brcm,bcm2835-dma"; > . . . END QUOTE This leads to the bcm_dma_allocate in bcm_sdhci_attach doing, in effect: struct bcm_dma_softc *sc =3D NULL; . . . mtx_lock(&sc->sc_mtx); because the bcm_dma_probe/bcm_dma_attach does not happen first. Result: crash. (But just avoiding the crash locally, would not be sufficient overall.) (I failed to find any DTB specification material indicating an ordering requirement for such things. If I'm wrong, point me at it.) Does FreeBSD have any principles that cover handling DTB content for both potential orders for such things? If yes, what is it? Are there good examples around to follow? =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Nov 3 12:50:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N33XW2T7Pz4gws4 for ; Thu, 3 Nov 2022 12:51:07 +0000 (UTC) (envelope-from bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz) Received: from e2i251.smtp2go.com (e2i251.smtp2go.com [103.2.140.251]) (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 4N33XT6ZhHz3V0d for ; Thu, 3 Nov 2022 12:51:04 +0000 (UTC) (envelope-from bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1667480764; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=qvxsBb4OXAS/daAE19v34ervw9SeLWtPWFDvJEnpoB8=; b=vTmyU8jd EERO5NcaQPfSEos2cnhFc8nnPHPtOTqfCcnFN2wk1QsYOqGu9iqhfsa2QWYPnGaxyREKAInbD10RM yiVfjsKTAwC8txK8KUbI0dsKkyNB9798g2QcwULLhZbtqj+ek2rUUgVSfHVQvgUkb2tf1kPqv6SLP RyMCAdr3n10+pFKgTczLOYIPbU5fBq7ry2Np2tZdKF4gQpucjFy/XLQ2YgE9YEhQ6t/aB4758rQah 7C4Y2ZEOqwcZoxAkLu0pEDFgbjwzlfSKtnwMAAoOMpVOha2nt56uiNBLdufP1Sv4/vMbxDWyLdvFv 4shmz154MF5nX12vZZ+uRAUr2g==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1667479864; h=from : subject : to : message-id : date; bh=qvxsBb4OXAS/daAE19v34ervw9SeLWtPWFDvJEnpoB8=; b=ge7Z1rViKAArbfu9VmjoGj+01RmiJ0cy8eye7f2thFgVJwKnaWI44s3hBKbow7iQlCOr8 n1yrPrKMcS7rK1qRPsWPJk6bxguzt5IOqFQFp7VevYUt3d7vICCD6Tr689ACIJi5Upk9crT a6BCkQYd45k0tZh9xkryhtpgZt1jsa4RvOo0fqXH5biNir7JXdrOQPkEvUvrNU5e+xEWU08 EqyKTLNPV7fVM/VuqgS+Xrsw88FM/ONVwDxPHd5QzOj8OdMOmdO+crbdTK97bO7pghq/Ol3 2pbFVzmfD9ILK4M/xLlq2C25bWNAgkbDNDT9kQbcMx54PqYRQ6SBJhbnEBNw== Received: from [10.139.162.187] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1oqZgP-Y8PHaa-KE; Thu, 03 Nov 2022 12:50:57 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1oqZgP-4XfowD-1O; Thu, 03 Nov 2022 12:50:57 +0000 Received: from smtpclient.apple (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 264F39152; Thu, 3 Nov 2022 12:50:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [EXTERNAL] pcib msix allocation in arm64 From: Andrew Turner In-Reply-To: Date: Thu, 3 Nov 2022 12:50:53 +0000 Cc: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> To: Souradeep Chakrabarti X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Smtpcorp-Track: 1oqZge4bfowD1O.Y2kzP6gvSXqIi Feedback-ID: 790814m:790814amQcrys:790814sNwJM4lss3 X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: 4N33XT6ZhHz3V0d X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b=vTmyU8jd; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=ge7Z1rVi; dmarc=pass (policy=none) header.from=fubar.geek.nz; spf=pass (mx1.freebsd.org: domain of "bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz" designates 103.2.140.251 as permitted sender) smtp.mailfrom="bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz" X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_LONG(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; MV_CASE(0.50)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz]; RCVD_IN_DNSWL_MED(-0.20)[103.2.140.251:from]; R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22]; R_DKIM_ALLOW(-0.20)[smtpservice.net:s=mgy720.a1-4.dyn,fubar.geek.nz:s=s790814]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.5ifi7mpc30=t8uhswtnaitc=ay9tx06eyt@em790814.fubar.geek.nz]; RCVD_COUNT_THREE(0.00)[4]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[smtpservice.net:+,fubar.geek.nz:+]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi Souradeep, For the vmbus_pcib driver you=E2=80=99ll need to implement the = pcib_alloc_msi, pcib_release_msi, and the msix versions, and = pcib_map_msi. For alloc and release you can just call into the same intr_* function as = pci_host_generic_acpi.c. You=E2=80=99ll need to pass in the xref for the = interrupt controller. It needs to be the xref the MSI controller = registered. For the GICv2m it=E2=80=99s ACPI_MSI_XREF. For pcib_map_msi I am unsure if the current code is valid on arm64. If = not you=E2=80=99ll need to call intr_map_msi. Andrew > On 2 Nov 2022, at 22:27, Souradeep Chakrabarti = wrote: >=20 > Hi Andrew, > Thanks for the reply. Regarding generic_pcie_acpi_alloc_msix( ), it = can be called if the > PCI device is child of the generic pcib ( DRIVER_MODULE(pcib, acpi, = generic_pcie_acpi_driver, 0, 0) .=20 > But if the PCI device is communicating with a different pcib driver = (like vmbus_pcib), > in that case do we need to implement all these functions of = pci_host_generic_acpi.c ? >=20 > Or there are some ways to reuse them? >=20 >> -----Original Message----- >> From: Andrew Turner >> Sent: Wednesday, November 2, 2022 6:54 PM >> To: Souradeep Chakrabarti >> Cc: Warner Losh ; Wei Hu ; = freebsd- >> hackers@FreeBSD.org >> Subject: [EXTERNAL] Re: pcib msix allocation in arm64 >>=20 >>=20 >>> On 2 Nov 2022, at 12:56, Souradeep Chakrabarti = >> wrote: >>>=20 >>> Hi, >>> I can see in x86 nexus.c has implemented pcib_alloc_msix using >> nexus_alloc_msix(). >>> Which calls msix_alloc() for msix allocation. >>>=20 >>> But in case of arm64 I don't find similar pcib_alloc_msix = implementation in >> nexus.c . >>> So, on arm64 what is correct way to get allocate msix ? >>=20 >> For an arm64 system with ACPI it is most likely handled in >> generic_pcie_acpi_release_msix. For FDT it can depend on which PCI = driver is >> used. >>=20 >> In either case it will call into intr_release_msix that then calls = into the MSI >> controller to allocate the vectors. For a GICv3 driver it will either = be >> gicv3_its_alloc_msix if you have an ITS device, or gic_v3_alloc_msix = if using MBI >> ranges. >>=20 >> On ACPI we don=E2=80=99t currently support MBI ranges, although it = looks like this could >> be handled by the existing gicv2m driver. This driver should already = work as a >> child of the GICv3, however it appears to be FDT only, so will need = some work to >> add ACPI support. >>=20 >> Andrew >=20 From nobody Thu Nov 3 20:21:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3FWl4jHHz4gf1J for ; Thu, 3 Nov 2022 20:21:07 +0000 (UTC) (envelope-from dan@langille.org) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3FWk5rCVz3GQY for ; Thu, 3 Nov 2022 20:21:06 +0000 (UTC) (envelope-from dan@langille.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6078932008FE for ; Thu, 3 Nov 2022 16:21:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 03 Nov 2022 16:21:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=langille.org; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1667506863; x=1667593263; bh=2ovtuWn6ZP OAhA5BaPHMMFMqohJK8rCzbHI564kkqKA=; b=at2rc+/y0y2Sgo03jEYr3PtCRc 2t5uPZhse5iVND8ZCmOKw97wK4zqByylyjIBtkvoPbnut/m1muSu8JDEv3vy6u6c csoFyTQZRzhoeavq3vJRPEh2zTbXjGw/LlbGXz2vtgB+t2OFem/hSjP4YJaLgaux mlfVvzJGp+l7AjoQmGIDiUHP41RptpvvrEHRj5/KI4mMJ1eytuuChXc2wYRCccPH d/FbDgjV14Wd8xJZ8aIVvgAR+071vJSes7jpES0qblAHFN1hWGmQVXipmJr8K0rf Gt73Gcz1lEcmHAxb0txWBW+ZcED2kpi+s2wMg49q/eWIxKrlV6TeoF/zZf4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1667506863; x=1667593263; bh=2ovtuWn6ZPOAhA5BaPHMMFMqohJK 8rCzbHI564kkqKA=; b=og8kajft6Lf5O3kS3IqfkV96dXteE+qtyIpacG3vQMi8 DjgtiGY3C2SyfAPvkI2bq0QUTySiIrd23uT2TdWHsBWWbIKNhOZTdmrPHvtGeGca krPBUX1JXsCeWOLojSprALIXmeh7X93ughIEm3yvhfBr2g1bIrttYoANR4/HNiTC 2V1gvGuJOlVtwoHg2xyxUdYlsjj89km9m5R9fOZfQIxTb7y/B9HIs0h5OT3F1SjB r1OWtO1g5BBOqOVNgL7U/6gcNwfzwRq5LCEt5KeUkS6KyKfu4UNEH4BkxOlfwV61 SkzyG2qJBAHKXe3XegaihTj8gZYzNhPAZhlSDrvphw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudelgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeffrghnucfn rghnghhilhhlvgcuoegurghnsehlrghnghhilhhlvgdrohhrgheqnecuggftrfgrthhtvg hrnhepudfgteeggfeuiedugfekgedvvdffjeffgfelhfehheejgfevieeuffehkeehvddv necuffhomhgrihhnpehfrhgvvggsshgurdhorhhgpdhlrghnghhilhhlvgdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurghnsehl rghnghhilhhlvgdrohhrgh X-ME-Proxy: Feedback-ID: ifbf9424e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 3 Nov 2022 16:21:03 -0400 (EDT) Subject: Re: What is the status of the FreeBSD development process now? To: Freebsd Hackers References: From: Dan Langille Message-ID: Date: Thu, 3 Nov 2022 16:21:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.58 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1ABD1A43ED9931C86AC0C01" Content-Language: en-US X-Rspamd-Queue-Id: 4N3FWk5rCVz3GQY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=langille.org header.s=fm3 header.b="at2rc+/y"; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=og8kajft; dmarc=pass (policy=none) header.from=langille.org; spf=pass (mx1.freebsd.org: domain of dan@langille.org designates 64.147.123.20 as permitted sender) smtp.mailfrom=dan@langille.org X-Spamd-Result: default: False [-4.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[langille.org,none]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; R_DKIM_ALLOW(-0.20)[langille.org:s=fm3,messagingengine.com:s=fm3]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEFALL_USER(0.00)[dan]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[langille.org:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------D1ABD1A43ED9931C86AC0C01 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit iio7@tutanota.com wrote on 11/1/22 7:26 PM: > In OpenBSD, AFAIK, absolutely no code goes into the project without at least 1 other people reviewing it and approving it. This can be seen with the "OK" in the commits. This has been shown to be false: https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html Sorry, I can't help you with your questions. Best wishes. -- Dan Langille dan@langille.org : https://langille.org/ --------------D1ABD1A43ED9931C86AC0C01 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit iio7@tutanota.com wrote on 11/1/22 7:26 PM:
In OpenBSD, AFAIK, absolutely no code goes into the project without at least 1 other people reviewing it and approving it. This can be seen with the "OK" in the commits.
This has been shown to be false: https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html

Sorry, I can't help you with your questions. Best wishes.

--
Dan Langille
dan@langille.org : https://langille.org/
--------------D1ABD1A43ED9931C86AC0C01-- From nobody Thu Nov 3 22:02:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3HnS2jJmz4gsQ5 for ; Thu, 3 Nov 2022 22:03:08 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3HnR1dCTz3Rgx for ; Thu, 3 Nov 2022 22:03:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x630.google.com with SMTP id k2so8941469ejr.2 for ; Thu, 03 Nov 2022 15:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YwiRIh55ZlDuxZ5N1/YRebK6E0ryuoi9Xig5LMwYUkk=; b=Vfn4TGU4djRsSKg4qhoObqsvjSPOz7b3BEYNuG1c5/A8kG+8TbFCzlSMW03Eq+fZj/ 5O5siKtTBOjBibQH84nG9a14wl40a4bfFr47fISPp5kbNimOUu3feaLvPeIjqBaeGF4z +XHhbhRLEph0VimfHNGqOqUGN3PQG/7umCO8bzOPOaqPJg3bVik3VxNWdMzstzQpq+Oz L350SkFM7Br50zwyhOe548sB06yysWDMW5oZTtaPGtH+d+SoiVdIt2tOBQ5UhJqRqhB2 eyoy94lM7cppfs7ezHvryDHh9/on7NLSsrCOA3heSMK5AbBP+S3S56txB27zwFsWN1kv MTBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YwiRIh55ZlDuxZ5N1/YRebK6E0ryuoi9Xig5LMwYUkk=; b=UKvzUCOhkSd512TNmV9D3BNTosVBqopmtadUZfENoO2fEEFAkuRq7jQS3qxodUf5nJ d7PdiQgOPlg/3piSgQjuYK5gZeVutNRuad/+ssLnbETBgbfe9svdNK81zbKp/s8qLd8G JKLawN/z7Bp5pT/aDRCwf6IPQztbuaOEG1agn9PmOBcnbwF54mLH7zWWcgyzXA8Ckwkk jVDUyvjmIFeZoei8sZYNGxGuOu+UCvTl3/OB4BnBlgsRBoMOZRYH/2kPdcEsZC+IpZFb WZmMZgk7t2pgdIxaHe8FsWdjUjjv72KyLTD0/tOwWwk0xWV7EiUNN+zxyj9VrnMABgXi 77xg== X-Gm-Message-State: ACrzQf21NNJ9yYTIiDxRoSLQ216uGYkd860zSYFIfWizPyGe5DMLvA/C VhZnKrWmsCC3U+0unN2M55xCx4dKAdD4JQatswdh0WqEBL4= X-Google-Smtp-Source: AMsMyM6HCHyLzifwrSTItMkpEVRhXSUY/6WYVrbHMMoiyV3rN3zfeu3TL8w0UxvM4DeQoEfXHHwiyjoZN28FEjtVT2E= X-Received: by 2002:a17:906:3b17:b0:7ad:b645:9e3e with SMTP id g23-20020a1709063b1700b007adb6459e3emr28094032ejf.140.1667512985491; Thu, 03 Nov 2022 15:03:05 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> In-Reply-To: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> From: Warner Losh Date: Thu, 3 Nov 2022 16:02:54 -0600 Message-ID: Subject: Re: SSD - trim fails To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000028b2f605ec981fe1" X-Rspamd-Queue-Id: 4N3HnR1dCTz3Rgx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Vfn4TGU4; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::630) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --00000000000028b2f605ec981fe1 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar wrote: > i have laptop with such SSD drive > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x > device > ada0: Serial Number S1K1NSAF415536 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 244198MB (500118192 512 byte sectors) > > > everything works very good as long as i don't do trim > > when trying trim - for example cleaning all drive with trim -f /dev/ada0 > i'm getting > > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > > > any ideas what is a problem? > The drive is reporting that it supports SDM. However, it's returning a weird error code when fed the DSM we're sending it. First, it could be a bug in how it does queued DSM requests. Normally one can queue up a bunch of trim requests on newer drives. Perhaps this one gets cranky. Next, maybe the drive is lying the size of the DSM it will support, but again, this is a weird message to report a request that's too long with. Maybe it doesn't support queued DSM, despite all appearances to the contrary from its identify tables. Try setting the trem method to DSM_TRIM: # sysctl kern.cam.ada.0.delete_method=DSM_TRIM should do the trick. At the very least, that will change the command we send so if it can't handle that, then the error message will change. I suspect this may clear up the problem. There's a few other things it can be, but if it is only trim commands that suffer from this, then they are quite unlikely. Warner --00000000000028b2f605ec981fe1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 2, 2022 at 2:51 PM Wojcie= ch Puchar <wojtek@puchar.net>= ; wrote:
i have = laptop with such SSD drive

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <SAMSUNG SSD SM841N 2.5 7mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x =
device
ada0: Serial Number S1K1NSAF415536
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte sectors)


everything works very good as long as i don't do trim

when trying trim - for example cleaning all drive with trim -f /dev/ada0 i'm getting

(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 =
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error


any ideas what is a problem?

The drive = is reporting that it supports SDM. However, it's returning a weird erro= r code
when fed the DSM we're sending it.

First, it could be a bug in how it does queued DSM requests. Normally= one can queue
up a bunch of trim requests on newer drives. Perha= ps this one gets cranky.

Next, maybe the drive is = lying the size of the DSM it will support, but again, this is a weird
=
message to report a request that's too long with.

Maybe it doesn't support queued DSM, despite all appearances t= o the contrary from its
identify tables. Try setting the trem met= hod to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM=
should do the trick. At the very least, that will change the com= mand we send so if it can't
handle that, then the error messa= ge will change. I suspect this may clear up the problem.

There's a few other things it can be, but if it is only trim com= mands that suffer from this, then
they are quite unlikely.
<= div>
Warner
--00000000000028b2f605ec981fe1-- From nobody Thu Nov 3 22:09:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3Hwq00VHz4gtZK for ; Thu, 3 Nov 2022 22:09:31 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3Hwn5KcPz3Ssj for ; Thu, 3 Nov 2022 22:09:29 +0000 (UTC) (envelope-from diizzy@FreeBSD.org) Received: (Authenticated sender: daniel.engberg@pyret.net) by mail.gandi.net (Postfix) with ESMTPA id 812121C0006; Thu, 3 Nov 2022 22:09:24 +0000 (UTC) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Thu, 03 Nov 2022 23:09:24 +0100 From: Daniel Engberg To: Warner Losh Cc: Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: SSD - trim fails In-Reply-To: References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> Message-ID: X-Sender: diizzy@FreeBSD.org Content-Type: multipart/alternative; boundary="=_794d1166e47ca039a330a748619f286a" X-Rspamd-Queue-Id: 4N3Hwn5KcPz3Ssj X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:4b98:dc4:8::225 is neither permitted nor denied by domain of diizzy@FreeBSD.org) smtp.mailfrom=diizzy@FreeBSD.org X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4b98:dc4:8::225:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[diizzy]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[freebsd.org]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_794d1166e47ca039a330a748619f286a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-11-03 23:02, Warner Losh wrote: > On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar > wrote: > >> i have laptop with such SSD drive >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> ada0: ACS-2 ATA SATA 3.x >> device >> ada0: Serial Number S1K1NSAF415536 >> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada0: Command Queueing enabled >> ada0: 244198MB (500118192 512 byte sectors) >> >> everything works very good as long as i don't do trim >> >> when trying trim - for example cleaning all drive with trim -f >> /dev/ada0 >> i'm getting >> >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain >> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 >> 01 00 >> 00 00 40 00 00 00 00 00 00 >> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error >> >> any ideas what is a problem? > > The drive is reporting that it supports SDM. However, it's returning a > weird error code > when fed the DSM we're sending it. > > First, it could be a bug in how it does queued DSM requests. Normally > one can queue > up a bunch of trim requests on newer drives. Perhaps this one gets > cranky. > > Next, maybe the drive is lying the size of the DSM it will support, but > again, this is a weird > message to report a request that's too long with. > > Maybe it doesn't support queued DSM, despite all appearances to the > contrary from its > identify tables. Try setting the trem method to DSM_TRIM: > # sysctl kern.cam.ada.0.delete_method=DSM_TRIM > should do the trick. At the very least, that will change the command we > send so if it can't > handle that, then the error message will change. I suspect this may > clear up the problem. > > There's a few other things it can be, but if it is only trim commands > that suffer from this, then > they are quite unlikely. > > Warner There are a number of SSDs from Samsung that have TRIM disabled so maybe this also falls into that category? https://bugzilla.kernel.org/show_bug.cgi?id=201693#c87 Best regards, Daniel --=_794d1166e47ca039a330a748619f286a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

On 2022-11-03 23:02, Warner Losh wrote:

 

On Wed, Nov 2, 2022 at 2:51 PM Wojc= iech Puchar <woj= tek@puchar.net> wrote:
i have laptop with such SS= D drive

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: &= lt;SAMSUNG SSD SM841N 2.5 7mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x
d= evice
ada0: Serial Number S1K1NSAF415536
ada0: 600.000MB/s transf= ers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabledada0: 244198MB (500118192 512 byte sectors)


everything = works very good as long as i don't do trim

when trying trim - fo= r example cleaning all drive with trim -f /dev/ada0
i'm getting
=
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada= 0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorre= ctable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more= tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEM= ENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:= 0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): R= etrying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_= QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00<= br />(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
= (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahci= ch0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
00 0= 0 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable= parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries= remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. A= CB: 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CA= M status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retryin= g command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED= DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(= ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error

=
any ideas what is a problem?
 
The drive is reporting that it supports SDM. However, it's returning a= weird error code
when fed the DSM we're sending it.
 
First, it could be a bug in how it does queued DSM requests. Normally = one can queue
up a bunch of trim requests on newer drives. Perhaps this one gets cra= nky.
 
Next, maybe the drive is lying the size of the DSM it will support, bu= t again, this is a weird
message to report a request that's too long with.
 
Maybe it doesn't support queued DSM, despite all appearances to the co= ntrary from its
identify tables. Try setting the trem method to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM
should do the trick. At the very least, that will change the command w= e send so if it can't
handle that, then the error message will change. I suspect this may cl= ear up the problem.
 
There's a few other things it can be, but if it is only trim commands = that suffer from this, then
they are quite unlikely.
 
Warner

There are a number of SSDs from Samsung that have TRIM disabled so maybe= this also falls into that category?

htt= ps://bugzilla.kernel.org/show_bug.cgi?id=3D201693#c87

Best regards,

Daniel


--=_794d1166e47ca039a330a748619f286a-- From nobody Thu Nov 3 22:12:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3J060wBhz4gtKG for ; Thu, 3 Nov 2022 22:12:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3J052NDfz3V3D for ; Thu, 3 Nov 2022 22:12:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id a13so5215492edj.0 for ; Thu, 03 Nov 2022 15:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s/j9r/E6UEVnyJs6/vHz8/E+zD/XOHlhHbFn5tSeTYk=; b=cDgti50/Tiqs2TOAFa/cAA5OcwODehgCQV3kKMIrf/L/Zzh0X4A808n8pcWcfCT5ky d3IMJG2qJOn+HCWkCj+65/iLpLTHSAdBx4BR3+qirnPOnNsJ1FcAiYsbsSI2IuXoKeRx xbe3yuhcC/W3ftl+WTHmAO3/37OKpLDyE0r6gSYhVMbq0vkaO7Vi/X8YdlEJXtxiRw/8 N/IZTI6velPoy0KF+IbkfJOrY6P3AqP1H/apGajUWiceFfyfJMQKZ/A/fbZVfDPBkZOO JT5abhBs9FYL6nhWkOTy4VvQSoUqo8toV6O0k/9NjgcU/KHqJcUOi70BiU4bTEDkCgCt Oufw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s/j9r/E6UEVnyJs6/vHz8/E+zD/XOHlhHbFn5tSeTYk=; b=eWHE7jqvuqjVMDW1cy3yqLYvPgfSZyMj24emnIc0+46J8FkwtziXCcQSByw3OMAJlQ SX6lC0uC0A5jYyTpPoewwduzwiPf8XH/vD1yIEiSJumeBIg3HVIa9DZP3oi321ZCDrM6 vjy93+JhNzVgtf6kbMsdd3Lz4F3qMTD/werfDVNWoJM9TUfozradk2t3djef6a7Ry9t5 vee5aCzOlMoAuo4OIrvA0VvBBcLEHnbKS8AQksRJ4gnpHLP7Es+gIy0npf4J2IOAIJrW 7v+UgUuMyR0IWhs1//0jxOa1Z2APibwQgfDXXD7s1rgSn5GD4Bf3oMtlmLQQQ+IzckM+ IXGQ== X-Gm-Message-State: ACrzQf1X95AoBobbgn2vdVtnVjccMra2ivzeNZYisifq/UYAnAt20JUW B1XlMS/GTMjq8HD+KsYKqxSq3+lpAS88fO7b46/0jw== X-Google-Smtp-Source: AMsMyM4lDM/930RauEgiwLJrVIOBdAhS99tLwL8P2HckmUFBe98GcvZjAnACsm2/klaaBSsSYsgmlhuP5/KV2KPpaXU= X-Received: by 2002:aa7:c859:0:b0:463:4b54:16a8 with SMTP id g25-20020aa7c859000000b004634b5416a8mr25488487edt.136.1667513538783; Thu, 03 Nov 2022 15:12:18 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 16:12:07 -0600 Message-ID: Subject: Re: SSD - trim fails To: Daniel Engberg Cc: Wojciech Puchar , freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000002340ac05ec9840db" X-Rspamd-Queue-Id: 4N3J052NDfz3V3D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="cDgti50/"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000002340ac05ec9840db Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 4:09 PM Daniel Engberg wrote: > On 2022-11-03 23:02, Warner Losh wrote: > > > > On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar wrote: > > i have laptop with such SSD drive > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x > device > ada0: Serial Number S1K1NSAF415536 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 244198MB (500118192 512 byte sectors) > > > everything works very good as long as i don't do trim > > when trying trim - for example cleaning all drive with trim -f /dev/ada0 > i'm getting > > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain > (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00 > 00 00 40 00 00 00 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error > > > any ideas what is a problem? > > > The drive is reporting that it supports SDM. However, it's returning a > weird error code > when fed the DSM we're sending it. > > First, it could be a bug in how it does queued DSM requests. Normally one > can queue > up a bunch of trim requests on newer drives. Perhaps this one gets cranky. > > Next, maybe the drive is lying the size of the DSM it will support, but > again, this is a weird > message to report a request that's too long with. > > Maybe it doesn't support queued DSM, despite all appearances to the > contrary from its > identify tables. Try setting the trem method to DSM_TRIM: > # sysctl kern.cam.ada.0.delete_method=DSM_TRIM > should do the trick. At the very least, that will change the command we > send so if it can't > handle that, then the error message will change. I suspect this may clear > up the problem. > > There's a few other things it can be, but if it is only trim commands that > suffer from this, then > they are quite unlikely. > > Warner > > There are a number of SSDs from Samsung that have TRIM disabled so maybe > this also falls into that category? > > https://bugzilla.kernel.org/show_bug.cgi?id=201693#c87 > Likely. I haven't checked Linux's block list for this yet. Warner --0000000000002340ac05ec9840db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 3, 2022 at 4:09 PM Daniel= Engberg <diizzy@freebsd.org&g= t; wrote:

On 2022-11-03 23:02, Warner Los= h wrote:

=C2=A0

On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar <wojtek@p= uchar.net> wrote:
i have laptop with such SSD drive

ada0 a= t ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <SAMSUNG SSD SM841N 2.5 7= mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x
device
ada0: Serial Number = S1K1NSAF415536
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192byt= es)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte= sectors)


everything works very good as long as i don't do t= rim

when trying trim - for example cleaning all drive with trim -f /= dev/ada0
i'm getting

(ada0:ahcich0:0:0:0): Retrying command,= 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MA= NAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0= :0): CAM status: Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Re= trying command, 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUE= UED DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(a= da0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
(ada0:ahc= ich0:0:0:0): Retrying command, 3 more tries remain
(ada0:ahcich0:0:0:0):= SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
00 00 40 00 00 00= 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC err= or
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
(ada0:= ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
00= 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: Uncorrectable= parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command, 3 more tries r= emain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: = 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status= : Uncorrectable parity/CRC error
(ada0:ahcich0:0:0:0): Retrying command,= 3 more tries remain
(ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MA= NAGEMENT. ACB: 64 01 00
00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0= :0): CAM status: Uncorrectable parity/CRC error


any ideas what i= s a problem?
=C2=A0
The drive is reporting that it supports SDM. However, it's returni= ng a weird error code
when fed the DSM we're sending it.
=C2=A0
First, it could be a bug in how it does queued DSM requests. Normally = one can queue
up a bunch of trim requests on newer drives. Perhaps this one gets cra= nky.
=C2=A0
Next, maybe the drive is lying the size of the DSM it will support, bu= t again, this is a weird
message to report a request that's too long with.
=C2=A0
Maybe it doesn't support queued DSM, despite all appearances to th= e contrary from its
identify tables. Try setting the trem method to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM
should do the trick. At the very least, that will change the command w= e send so if it can't
handle that, then the error message will change. I suspect this may cl= ear up the problem.
=C2=A0
There's a few other things it can be, but if it is only trim comma= nds that suffer from this, then
they are quite unlikely.
=C2=A0
Warner

There are a number of SSDs from Samsung that have TRIM disabled so maybe= this also falls into that category?

https://bugzilla.kernel.org/show_bug.cgi?id=3D201693#c87=


Likely. I haven't checked Li= nux's block list for this yet.

Warner=C2=A0
--0000000000002340ac05ec9840db-- From nobody Fri Nov 4 00:47:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3MQq0Ww3z4hCYR for ; Fri, 4 Nov 2022 00:47:15 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3MQn2q1Sz3kYG for ; Fri, 4 Nov 2022 00:47:13 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 021B1FBF92E for ; Fri, 4 Nov 2022 00:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667522831; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=Nwq0OlFUY5bR5CinpdC7TN51K72yw/OLX1WMCzkHL8o=; b=b4aci28JlbR5wgG05p5B6ryM8PpKVbQna+R9iZbl5fzn3f5YLjzxAytQBN99OOnn xTPsJqqC7dl1wd08ZXH7X2Ff8iheztvq5qeFz9lsKSm2PG1wuPz43k1nwc6DSKY402y DItpvRas2XJGyzbDUDXHw/5rgL7d63HZpV1A0S6z2fun3BPZNjZU6GPJ2VX6GFsdqm9 g5k2Tl1tddH2KraXLcUcfMCxI028ivtcRhLWVu1ck15IOqlDvoYu3R4XZZld1wWNPyq NOw9qeTQx55FOrva9egxvTJIos9hfmNuPQIe4ew08avfl4i/fDmP7XAcX0wZpUKeMpU nS+Ouck/FQ== Date: Fri, 4 Nov 2022 01:47:11 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N3MQn2q1Sz3kYG X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=b4aci28J; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-2.00 / 15.00]; FAKE_REPLY(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> In OpenBSD, AFAIK, absolutely no code goes into the project without >> at least 1 other people reviewing it and approving it. This can be >> seen with the "OK" in the commits. > This has been shown to be false: > > https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html I have just replied to that. It's wrong. Take a look at the OpenBSD commit logs. https://lists.freebsd.org/archives/freebsd-questions/2022-November/002211.html We're not talking about ports, the issue is related to the kernel and base, etc. Kind regards. From nobody Fri Nov 4 00:58:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3Mgq2zDhz4hDmG for ; Fri, 4 Nov 2022 00:58:31 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3Mgp20WPz3lsT for ; Fri, 4 Nov 2022 00:58:30 +0000 (UTC) (envelope-from instructionset@gmail.com) Received: by mail-yb1-xb33.google.com with SMTP id n130so4193517yba.10 for ; Thu, 03 Nov 2022 17:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MEpBYXMq/TvhcXbI+XFZpPS0Y+KhudwaBn3tcvrGBDY=; b=Ye2W6Xy69iUpDHqIQF7XCKCPesQO1mVhVw8SEC8PNhafIeGZdnpK+uIfp7LTYGeVsa YU+NKrh0AKmEhDZZdZ2JOhwMKJGL8lHzUOcQLVEyTTa3ENQ5lfHR03jSzeRu3J7zrKjT 67vn75ZKjuURigIEk+h/ZY0fPDEFBkVsIEuVkAi0UK8cY6ABAJMWjUdNfHn6sJDIm5DM 5nY5txdXJsGYEkRnSyId+iWLMqkqw92EW71Vpzf+TFRg2280AG/Z5iY1MdddzGgG3LqV kBV6RWWQmBouACxxV8X8BT0xJ2mZtC8GnBq3hOnZbVu7it9qiJFJb092NoQ0W6VdOqZf 0wKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MEpBYXMq/TvhcXbI+XFZpPS0Y+KhudwaBn3tcvrGBDY=; b=76IfYhZS8gQQHVcOJY3qZny9p/0W3pNp6klDGs2MhQK+EJ24ENO2ijwKe30aNGVera 8VufG0IDX9f1pGNzr+Vu/+SmyoH76DM0C4jJVJAQiBLxGi/akVcs/AzM2dWKAFHdzW6N WFnPO8iEel5E4qR2o2k3qdORhsyv32mW2Bd0EgSoI7GINOApfP+7Txn0jiaucIa7JZdc +mmNt4HDJhcFtPnTPqPqxjaTKYxtGlFPfqzfaY/xB+tCq9KCXUeqewpV/jGea716JarH R/BfAhHlXETyvk60bteISp58ayZcWQf0MlGlgPYzFJDhZ2nueQ9rIJ2A2pIXsoqKQ2Cv KdnQ== X-Gm-Message-State: ACrzQf2Fd6ngqULJM6YNWzANXaGV9BxQm/XZmV+PVG0SMaE4587UKIMc 59sEXsWmCMyyq5g9whoWyNB1d1e3fjpDkiuNl3cZrUD8/6g= X-Google-Smtp-Source: AMsMyM5HJRVyR8iutnrVhzs6OHDoW3vc16kRNg3PwFhlZZyIaaeyG9Y0k+Aa+O/Etkjh1mPXr8+A7Qygll2xTxL5YKo= X-Received: by 2002:a25:ceca:0:b0:6cc:6794:d3e0 with SMTP id x193-20020a25ceca000000b006cc6794d3e0mr27391685ybe.224.1667523508697; Thu, 03 Nov 2022 17:58:28 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Bill Sorenson Date: Thu, 3 Nov 2022 19:58:19 -0500 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: iio7@tutanota.com Cc: Freebsd Hackers Content-Type: multipart/alternative; boundary="00000000000063ff3205ec9a92eb" X-Rspamd-Queue-Id: 4N3Mgp20WPz3lsT X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ye2W6Xy6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of instructionset@gmail.com designates 2607:f8b0:4864:20::b33 as permitted sender) smtp.mailfrom=instructionset@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b33:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000063ff3205ec9a92eb Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022, 7:47 PM wrote: > >> In OpenBSD, AFAIK, absolutely no code goes into the project without > >> at least 1 other people reviewing it and approving it. This can be > >> seen with the "OK" in the commits. > > > This has been shown to be false: > > > > > https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html > > I have just replied to that. It's wrong. Take a look at the > OpenBSD commit logs. > > > https://lists.freebsd.org/archives/freebsd-questions/2022-November/002211.html > > We're not talking about ports, the issue is related to the kernel and > base, etc. > > Kind regards. > I follow the FreeBSD commits pretty regularly and I see reviewers. Have you looked? > --00000000000063ff3205ec9a92eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 3, 2022, 7:47 PM <iio7@tutanota.com> wrote:
>> In OpenBSD, AFAIK, absolutely no code goes into the project= without
>> at least 1 other people reviewing it and approving it. This can be=
>> seen with the "OK" in the commits.

> This has been shown to be false:
>
> https:= //lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html

I have just replied to that. It's wrong. Take a look at the
OpenBSD commit logs.

https://lis= ts.freebsd.org/archives/freebsd-questions/2022-November/002211.html

We're not talking about ports, the issue is related to the kernel and base, etc.

Kind regards.


I follow= the FreeBSD commits pretty regularly and I see reviewers. Have you looked?=


--00000000000063ff3205ec9a92eb-- From nobody Fri Nov 4 01:32:09 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3NQg43pLz4hJ9X for ; Fri, 4 Nov 2022 01:32:11 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3NQf6kR6z3pXM for ; Fri, 4 Nov 2022 01:32:10 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id E59C2FBF932 for ; Fri, 4 Nov 2022 01:32:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667525529; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=srxNPGnAwlXFtlaaOUIleaAqGb1E9nLrG4TVFupQ+SM=; b=v+Yq0RStOGmg2lzwONuXUgCJU1eBaji6fnsN7s8TdUHjCjSMjNDSAhzMvQYomyvp kPaC5FwMUkQkvdkNJ+km4ASrrgE6eXyr1k6a3NSWqfTwftOto7lONxM36ViuZ54jI85 0v4inOCp0zm6o5CtyKyNIDRf0l+cd2vWywe1DlQvlS08FcRcv3q7Z/ilM6op2VKu3hs OlG9016bEds48/NL5pICqMQ9TkNuBSeS+hAz3ww4O5sMakDqYtypiXNtrQiPKw6O5aW 6hoQ/13Tv9kwmGbHiCcaQe6GEkIzjbkUzS3P5fKA//tSrGG13QlaetcZML8gFQBDtuF DvvOdiErKw== Date: Fri, 4 Nov 2022 02:32:09 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: In-Reply-To: References: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N3NQf6kR6z3pXM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=v+Yq0RSt; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > I follow the FreeBSD commits pretty regularly and I see reviewers. Have you looked? > Yes. The problem is not about seeing regular reviews, the problem when it doesn't happen. Core made a statement about a change in that regard [1], I haven't been able to confirm or see that anything has changed. [1]: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html From nobody Fri Nov 4 01:32:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3NRb0DYvz4hJ2S for ; Fri, 4 Nov 2022 01:32:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3NRZ1K6Wz3qbw for ; Fri, 4 Nov 2022 01:32:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x533.google.com with SMTP id v17so5614635edc.8 for ; Thu, 03 Nov 2022 18:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SUfPh3kpGcQskDO7pXRAJb6VAlZcz9YXD3FiPwmeta0=; b=7T3Ig4zcA1fenWHwrqVqqq8Hs6rIPxrsICzOUxChYdCRBxYGgx07VgEP5H694cyCII nAOAjISiG+M6xsJ1jo12YMLDsa5CQ9wiSuVEfXBEzy57bBJW9Ts0MQqtVzcv0TM8c780 Cm6yOQ+QkFdagOZCiF++xlcm65RDdoQeuiiHtKhLrdAwUmY1LRE5Dbf1giDC0GaXsInV KrTeg76MLPjz1sfkCWda5LE/DYj5TU8CqayPjhcMb6FfO1dQNG3UgJSyeKwIFNF+cE4W 0kcM6piIF75vNGhLmtWunOEIUuLHnEKPArgXQoQgWFsSjFHVkxV2Wo6jiRfF1kmodsFp S+qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SUfPh3kpGcQskDO7pXRAJb6VAlZcz9YXD3FiPwmeta0=; b=XLfKbn4swPL+muXuezpX3pRhuSWUBLOfBpJj2LSZnvSG+Y1uzjpWBJY9GHSLEZYfo1 82w0ZN/1YH5JOzse2UL+f6HwTICmx2ePtuRWCYZ96ueKL0i3vH89wmQTj+VUp3gOfFj3 YOhnQNWl2XklCDDNCy5R7jyi8QaJsSSGTn5HeKUrzmTMUskVT1+D8L7kHY7wwWEBbxaR vV3SrYkKkINZH9Lhmz3pHRzmWIzY5PalMxNlfb94dZfLUnf/Ih/lONgl9IauQqLsrQjb +lPp0PmnY34CaNOZUrmLurplgpDcXXKpYmv9FIe7idalOfftVaXui/RpLUTwLyYVMFzP WSIw== X-Gm-Message-State: ACrzQf02ZcssQoTjgeyIV6iLm47BNjoty3gE56wvCxQS6YahLFP8wKFa VN3qliXcGqfXUB4exOwAch4fnJTDHHVTEaqfirWdlA== X-Google-Smtp-Source: AMsMyM5y3CYBIGE4aHdOQngaC9/VqF57HrPVVEoRc82EfQg1P8OHcQs3+Zu+WgpYZLKbgB4mPZu2W0XrpZ+FvwJ1fcU= X-Received: by 2002:a05:6402:5c9:b0:446:fb0:56bb with SMTP id n9-20020a05640205c900b004460fb056bbmr33884550edx.173.1667525576666; Thu, 03 Nov 2022 18:32:56 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 19:32:45 -0600 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: iio7@tutanota.com Cc: Freebsd Hackers Content-Type: multipart/alternative; boundary="000000000000a6c6ae05ec9b0da1" X-Rspamd-Queue-Id: 4N3NRZ1K6Wz3qbw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=7T3Ig4zc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::533) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000a6c6ae05ec9b0da1 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 6:47 PM wrote: > >> In OpenBSD, AFAIK, absolutely no code goes into the project without > >> at least 1 other people reviewing it and approving it. This can be > >> seen with the "OK" in the commits. > > > This has been shown to be false: > > > > > https://lists.freebsd.org/archives/freebsd-questions/2022-November/002192.html > > I have just replied to that. It's wrong. Take a look at the > OpenBSD commit logs. > Many, but not all, have the OK tag. My quick grep over the last 1000 commits I have in my tree suggests about 50%: % git log -1000 | grep -i ok | wc 524 2048 13689 which is the 1000 commits ending around May 1, 2022 this year (the last time I pulled an OpenBSD tree on the machine I have handy). > We're not talking about ports, the issue is related to the kernel and > base, etc. > Many, but not all, FreeBSD commits have a reviewer these days, and the main exceptions are trivial spelling errors, build botches and other similar things. A quick grep suggests of FreeBSD suggests similar numbers: % git log -1000 | grep 'Review' | wc 555 2163 22658 vs % git log -1000 HEAD~20000 | grep 'Review' | wc 319 1220 10577 which is in the time period a few months before the email in your original email. For both OpenBSD and FreeBSD this undercounts the number of commits that had a review that wasn't documented, or used a non-standard form to document, or (in FreeBSD) submitted by was reviewed by the committer, but no 'Reviewed by' was added to the commit because it was believed to be implicit (it is, but that's hard to grep). So it appears that the numbers are currently about the same and that different methods may give slightly different results because of the inconsistent marking of the tree. Because marking is inconsistent, and some actually reviewed changes go undocumented, it is really hard to say that one project is better than the others. Warner --000000000000a6c6ae05ec9b0da1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 3, 2022 at 6:47 PM <iio7@tutanota.com> wrote:
>> In OpenBSD, AF= AIK, absolutely no code goes into the project without
>> at least 1 other people reviewing it and approving it. This can be=
>> seen with the "OK" in the commits.

> This has been shown to be false:
>
> https://lists.fre= ebsd.org/archives/freebsd-questions/2022-November/002192.html

I have just replied to that. It's wrong. Take a look at the
OpenBSD commit logs.

Many, but not all,= have the OK tag. My quick grep over the last 1000
commits I have= in my tree suggests about 50%:
% git log -1000 | grep -i ok | wc=
=C2=A0 =C2=A0 =C2=A0524 =C2=A0 =C2=A02048 =C2=A0 13689
wh= ich is the 1000 commits ending around May 1, 2022 this year (the
= last time I pulled an OpenBSD tree on the machine I have handy).
= =C2=A0
We're= not talking about ports, the issue is related to the kernel and
base, etc.

Many, but not all, FreeBSD c= ommits have a reviewer these days, and
the main exceptions are tr= ivial spelling errors, build botches and other
similar things.

A quick grep suggests of FreeBSD suggests similar nu= mbers:

% git log -1000 | grep 'Review' | w= c
=C2=A0 =C2=A0 =C2=A0555 =C2=A0 =C2=A02163 =C2=A0 22658
v= s
%=C2=A0 git log -1000 HEAD~20000 | grep 'Review' | wc
=C2=A0 =C2=A0 =C2=A0319 =C2=A0 =C2=A01220 =C2=A0 10577

which i= s in the time period a few months before the email in your original
email.

<= div class=3D"gmail_quote">For both OpenBSD and FreeBSD this undercounts the= number of commits
that had a review that w= asn't documented, or used a non-standard form
to document, or (in FreeBSD) submitted by was reviewed by the commit= ter,
but no 'Reviewed by' was added= to the commit because it was believed to
b= e implicit (it is, but that's hard to grep).

So it appears that the numbers a= re currently about the same and that different
methods may give slightly different results because of the inconsistent= marking
of the tree. Because marking is in= consistent, and some actually reviewed changes
go undocumented, it is really hard to say that one project is better th= an the others.

Warner
--000000000000a6c6ae05ec9b0da1-- From nobody Fri Nov 4 01:34:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3NTp1GD8z4hJQB for ; Fri, 4 Nov 2022 01:34:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3NTn2msQz3rY7 for ; Fri, 4 Nov 2022 01:34:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x62f.google.com with SMTP id f5so9778704ejc.5 for ; Thu, 03 Nov 2022 18:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bNv0Tiosm+3n7YUy3iWUKGorwej7EPhFgU84h9KlxsA=; b=Rs2ECPqsxpZWd89Uwoxz2mnakG2iOhfjocJtGyy2IAIjZ6vHf2w03QcpVAJegw8BDl nL7QkblDaXGzKdHI+OtK1a57LDZmz5zL2yxsrItVRzyPmxlHA7D0rOR2sdYdABRnyUvR jTAlkvdr2tkKGV8idBWZ61j89d+YTB5f8HJFg4KHYol+1Ru/ieNBskQXlzzs+ZPV1uKY EGo4qmIHtQdHe6PJJ8nTXqe6cj52DsjmOPITY6isJFDQoMlWICgIpjXRhgzEVu2U03Nq xJLBb7W8LsH0n6cLZTJKGhZfL8f/YMqRCsblM/3kfVl8h8q5i3/o7sKmpoZBmcAHqvmS 1EBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bNv0Tiosm+3n7YUy3iWUKGorwej7EPhFgU84h9KlxsA=; b=XeNqy2qq+tECmxXmujW++SUZkB+FujPv0QhREe4QUitBs5F0PRw4s4qRDuW9/BlFh/ VWDybNY7F7usXsc0ZMwaLN5A++t59Y1IPvJYu6jgWa40AdIiCNXAK2VFfLrJZ5K40srK 5NJ2/DbkoBetf5pIUc1Yi8A5i4p68zJ3Jxgn24m0HAvIsJG77Etfkw1E8s2aalvheXGV 0C2ce90Wa3hDMyJbjRYIUXPTVhduFAYl0hDjy3TzJAIEk07SUb2YpSWtL9fodqhGnv4E L45inLVfkjPIn+5e9B1JM8AMxPiJrNSXiIQy6tmEo+OzbeBBYcOerIapRhgdXQ7I+AlH q+LA== X-Gm-Message-State: ACrzQf1D/1VEB8WM6IaJcAn4ngmshoDsI9CpLZQL+KgyOKrd9h5p4uXm +OJtWmla7BvwGg7V0JAJsN2KAhOu9ydB5ReYYSumDELxp7Y= X-Google-Smtp-Source: AMsMyM51X2feeXU8PgghhVjPF+q61AMjTs4eC/qpAa/aYS877hxwlC7Nz2dcUWWKLx/t264wlb7siOxGWXzFrHvK0AM= X-Received: by 2002:a17:907:2710:b0:7ad:86f9:9bad with SMTP id w16-20020a170907271000b007ad86f99badmr32595073ejk.32.1667525692035; Thu, 03 Nov 2022 18:34:52 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 19:34:41 -0600 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: iio7@tutanota.com Cc: Freebsd Hackers Content-Type: multipart/alternative; boundary="000000000000872a3505ec9b1465" X-Rspamd-Queue-Id: 4N3NTn2msQz3rY7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Rs2ECPqs; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000872a3505ec9b1465 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022 at 7:32 PM wrote: > > > > I follow the FreeBSD commits pretty regularly and I see reviewers. Have > you looked? > > > Yes. The problem is not about seeing regular reviews, the problem when it > doesn't > happen. > > Core made a statement about a change in that regard [1], I haven't been > able to > confirm or see that anything has changed. > > [1]: > https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html According to my data, reviews are up significantly since that email. I'm guessing you haven't been able to confirm anything has changed because you've not actually looked for data, since it's trivially easy to find that data. Warner --000000000000872a3505ec9b1465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 3, 2022 at 7:32 PM <iio7@tutanota.com> wrote:


> I follow the FreeBSD commits pretty regularly and I see reviewers. Hav= e you looked?
>
Yes. The problem is not about seeing regular reviews, the problem when it d= oesn't
=C2=A0happen.

Core made a statement about a change in that regard [1], I haven't been= able to
=C2=A0confirm or see that anything has changed.

[1]: https://lists.freebsd= .org/pipermail/freebsd-hackers/2021-March/057127.html
=
According to my data, reviews are up significantly=C2=A0sinc= e that email.

I'm guessing you haven't bee= n able to confirm anything has changed because
you've not act= ually looked for data, since it's trivially easy to find that data.

Warner
--000000000000872a3505ec9b1465-- From nobody Fri Nov 4 01:39:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3Nb313Ptz4hJmG for ; Fri, 4 Nov 2022 01:39:27 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3Nb23hnxz3sZ9 for ; Fri, 4 Nov 2022 01:39:26 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id A28BCFBF947 for ; Fri, 4 Nov 2022 01:39:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667525964; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=hv2finUEf8Y0fS1aFpYSVyeLbkleXdzfJw4A8WOZStw=; b=j088302a+dpRazhD3WDoyfD7kMbj5/bKq/aLs0TQUlk55JwgLJKh8z3U71HeoEbo d6MQOY0jggUIYY8f747tkC3lXsZbO9nq2RHcAx1QqxrD0lFlFApeBLk9jea9jhvU6Ql qC9cuxhPPBv8CJiTmQ2AUfKhcdfE4pjGlsxNEdCuJUQpAABYHHOL1u7PU65nJEvsRNI FrlFb5KT0tMWAHbgpPjP4Rp+QETPkNXg2eJma2UA8xTTAmEFsDyp3Emci/dAPGL8pke 2xz3mYO01X9YOrDtwtGZrZGeQuCPro2vQkD+CwvVdLExdXdV/WoQYZAocUsY3mNIdJ9 evoXLjzCBw== Date: Fri, 4 Nov 2022 02:39:24 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: In-Reply-To: References: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4N3Nb23hnxz3sZ9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=j088302a; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Nov 4, 2022, 01:34 by imp@bsdimp.com: > According to my data, reviews are up significantly=C2=A0since that email. > > I'm guessing you haven't been able to confirm anything has changed becaus= e > you've not actually looked for data, since it's trivially easy to find th= at data. > No, I have looked. I never said that I didn't find anything. However, what = I was suspecting to find was a set of rules put in place to prevent anything like= the wireguard issue from happening again. I guess my expectations were too high. Sure, things has improved, but witho= ut a clear set of rules - like ALL commits must be reviewed before going into = the kernel, base, etc. - the same problem can happen again. Kind regards. From nobody Fri Nov 4 01:59:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3P2l15jFz4gcHB for ; Fri, 4 Nov 2022 01:59:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3P2k1jWMz3vHg for ; Fri, 4 Nov 2022 01:59:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ej1-x636.google.com with SMTP id t25so9832802ejb.8 for ; Thu, 03 Nov 2022 18:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7UPe7N2bnJ4yG4C0ZeYJJZcoK9zGfrvJdbJUskZwH4M=; b=66uV8vdcOqs72po1OUnFeJmidTzMmNOimYfn1GHSaOUxao4BFW4GuEAPIP3Pt0n3yD 49RN5vwnbY3S0/UflDbHxsLo/u9k8/069FTZ64SoflVsc0iT4IMCCXZm7GgY8w8/7Dww B+D7Zs6Km6MnL1bfsicTuzblf3ZIPos4p1U13UUtmLC2G5PD4Q4cZnnJSJvjCMdJNACv rCkrPhQ9TZQFOpLlQL74xsLjyXf8aoTThiOEuKicQfzIfYiY7t2cvyfevWRoZkyKH3Km BS3dnWHua7YugSSRCwJhbCWXhCMWYB+A7f4IpomoF19XP00dvxLqUvNuJUEcKzSLkV9Y ETkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7UPe7N2bnJ4yG4C0ZeYJJZcoK9zGfrvJdbJUskZwH4M=; b=TsO0UaFlY70IGJ5pAJ3ujdvVxG5j37KvSZ8WEo9ajiGprOZ7ROHoMt48kx1Nv5fT/g GIO/bJNfK5kM/RqKKDthKhE0ekE3/evdtj0ImZSMJngWMk3bGJqKeVqidbLO3NPstlJJ Zmv0qxSGDnqjvAIvkrfntsCwiK+OaLVGYzE/Ih9dBwIEGi8QBoTym5JUQvuNfuejZ6ea 7pq4eRXAQUVxi9IoWq617bso8lHn7Hy10d4To26vpvnbVQy8Q3jq38WqPbGEsFMHhs74 YhSaDTDct91lwk68qdmamW/216TLbQN7lTCcMJKS1cWueiuNWzmdbWNI7oWPeYQYYDVy hALg== X-Gm-Message-State: ACrzQf1iJMAMNiWPCSHClfGDAYoH6J8C+dS705eZ8TurGhypvjOiAnbz TsMI5MjX2hFDg/A0LtztFZdMtJyayifd1UHEVVCpUqNfFNQ= X-Google-Smtp-Source: AMsMyM7Vt43QCQ9t1ASTGBQJPRpwMKSgdLAkfqwar7QDA5L4S6W8TOnXwyKK/YUpe4kNw08Rrauhwly0wewNHl449CQ= X-Received: by 2002:a17:907:d02:b0:7a3:de36:b67 with SMTP id gn2-20020a1709070d0200b007a3de360b67mr31384191ejc.451.1667527196899; Thu, 03 Nov 2022 18:59:56 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 3 Nov 2022 19:59:45 -0600 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: iio7@tutanota.com Cc: Freebsd Hackers Content-Type: multipart/alternative; boundary="00000000000039915d05ec9b6e98" X-Rspamd-Queue-Id: 4N3P2k1jWMz3vHg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=66uV8vdc; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::636) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000039915d05ec9b6e98 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 3, 2022, 7:39 PM wrote: > Nov 4, 2022, 01:34 by imp@bsdimp.com: > > > According to my data, reviews are up significantly since that email. > > > > I'm guessing you haven't been able to confirm anything has changed > because > > you've not actually looked for data, since it's trivially easy to find > that data. > > > No, I have looked. I never said that I didn't find anything. However, what > I was > suspecting to find was a set of rules put in place to prevent anything > like the > wireguard issue from happening again. > Your expectations are off. You need to look at the data. I guess my expectations were too high. Sure, things has improved, but > without > a clear set of rules - like ALL commits must be reviewed before going into > the > kernel, base, etc. - the same problem can happen again. > Now I know you are trolling... Nobody that's has done engineering for any length of time would expect reviews to catch all problems. That's at best wishful thinking and at worst a horribly toxic management culture. What has happened is that there is more review, the commits are generally much much smaller and more people are reading the commits after the fact. I half jokingly told a coworker recently the fastest way to find a problem in my code is to commit it since so many people read it, I get feedback right away. Again, these things are present in the data. There are way more tests than being committed than before. There is more CI coverage than before. There are efforts to greatly expand that. The layered approach gies a long way towards catching issues like this than before. Thinking promulgating some simplistic rule change is at best overly simplistic think and disingenuous trolling at worst. Warner Kind regards. > > > > > --00000000000039915d05ec9b6e98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 3, 2022, 7:39 PM <iio7@tutanota.com> wrote:
Nov 4, 2022, 01:34 by imp@bsdimp.com:

> According to my data, reviews are up significantly=C2=A0since that ema= il.
>
> I'm guessing you haven't been able to confirm anything has cha= nged because
> you've not actually looked for data, since it's trivially easy= to find that data.
>
No, I have looked. I never said that I didn't find anything. However, w= hat I was
suspecting to find was a set of rules put in place to prevent anything like= the
wireguard issue from happening again.

Your expectations are off. You need t= o look at the data.

I guess my expectations were too high. Sure, things has improved, but witho= ut
a clear set of rules - like ALL commits must be reviewed before going into = the
kernel, base, etc. - the same problem can happen again.

Now I know you are t= rolling...

Nobody that&#= 39;s has done engineering for any length of time would expect reviews to ca= tch all problems. That's at best wishful thinking and at worst a horrib= ly toxic management culture.

What has happened is that there is more review, the commits are genera= lly much much smaller and more people are reading the commits after the fac= t. I half jokingly told a coworker recently the fastest way to find a probl= em in my code is to commit it since so many people read it, I get feedback = right away.

Again, these= things are present in the data.=C2=A0 There are way more tests than being = committed than before. There is more CI coverage than before. There are eff= orts to greatly expand that. The layered approach gies a long way towards c= atching issues like this than before. Thinking promulgating some simplistic= rule change is at best overly simplistic think and disingenuous trolling a= t worst.

Warner

Kind regards.




--00000000000039915d05ec9b6e98-- From nobody Fri Nov 4 03:45:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3RNG6vm8z4grBH for ; Fri, 4 Nov 2022 03:45:18 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3RNG07klz44Fc for ; Fri, 4 Nov 2022 03:45:17 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk1-xa30.google.com with SMTP id e16so1756064vkm.9 for ; Thu, 03 Nov 2022 20:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Bm/uUO+n36SlRrSY26oDqowL3O0MuA8ExdISWJGMM68=; b=ByXUbvKiZm7v+nApSH2VkO3kP9pumMnQjpCOpFGlI6SKvqGTb0qPAzV4kGQliHgTrZ Dcn/cfg/kNBbzWHR1NRVXBvV/zDhcwxZ0u16/yD/iKeVAY390/t6UVJ9Vw/Nfww2lA3w oUKK5J31dFsU8s+qBM6uD0AU8p+Ag0UjJL8hTdizm5CtsIenDXKzAk/FQtJtAoe/bWMw LiKp9VjGlp9RAnatFZ0Bl/l0RpAjFFxQDlO2OOTnclqkReC4ivElhQztMMgeKuwT81FL JiHt7/KiUI/qTHwmIpNoEMrX5ogMV99Zz9VfQymHcOJ0r/yC33n6WkGG9eBNkDrFNI1F madg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Bm/uUO+n36SlRrSY26oDqowL3O0MuA8ExdISWJGMM68=; b=6fnd109UrxLSbK9lp3H5UsjYjyF+R5OFlJIHB5+eOmF3r0JY2HYBqaRjp2tYUR8g8y xLjVHV2YJuqAJEEp8EuTD3DAo7qEzvpOUWNuyNLnhcwiyQL0dNbBm1+PxRUayM0d1gUY VvV7yuXg5/lapXOz9n0fsax2MsivGPIe6YkZhqjMTUz0/1caCf0LOICT4s92HTu42Bb3 L5yzeXE5CQ7mStDl4MewoxdYoMaZ9EC3oB7p+9RCO3M3YJfrR5lA4F6sbSudTvRfc4FD qEeFgZCWxkOWEHU4mQ62T2rMTGuDOQLDwq1dFRPx4nuv9YFsAEQKjcB91yytmXV4ww2Z gxdg== X-Gm-Message-State: ACrzQf1Do+RbXC8wLW7CK183X9TScI7xkf1XKUSzEQrIknHFk8WoCYT/ x094MTBmh2BWnSaW7huN0F1+X1HC5FmFxrLnVt1ZvCkg/GIqh6ZbBd4= X-Google-Smtp-Source: AMsMyM6JIG7Gon6mW84BpQysCGVoi0L/pwmU6zM5z9LyoyPa2uYrHnUfLhBbJI0eVPiQ4F8AECz3QCyYhlvkfB6FgZQ= X-Received: by 2002:a1f:3011:0:b0:3b8:7d0d:d570 with SMTP id w17-20020a1f3011000000b003b87d0dd570mr8313981vkw.31.1667533516862; Thu, 03 Nov 2022 20:45:16 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:5d11:0:b0:324:d963:1eff with HTTP; Thu, 3 Nov 2022 20:45:16 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Thu, 3 Nov 2022 23:45:16 -0400 Message-ID: Subject: Re: What is the status of the FreeBSD development process now? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4N3RNG07klz44Fc X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=ByXUbvKi; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::a30 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a30:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > ALL commits must be reviewed before going into the Some cryptocurrencies have feature that a transaction does not occur until M out of N sign off with crypto. Good version control systems should begin to offer that as a feature that repos can enable. Doesn't mean the tx is any good, but does make it go through a given set of reviews. Unfortunately FreeBSD still does not accept any donations via cryptocurrency. Nor has FreeBSD community yet participated in any crypto crowd funded code dev/bug/doc etc bounties. The world is moving there, others are already making good use of them, best get on that, have fun :) From nobody Fri Nov 4 03:51:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3RWv5PdSz4grsW for ; Fri, 4 Nov 2022 03:51:55 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3RWt4s4Kz47Ng for ; Fri, 4 Nov 2022 03:51:54 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 2A43plm0071639 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 3 Nov 2022 23:51:52 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Thu, 3 Nov 2022 23:51:47 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: George Mitchell In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=10.0 tests=HELO_NO_DOMAIN, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4N3RWt4s4Kz47Ng X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:c]; MIME_GOOD(-0.10)[text/plain]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On 11/3/22 23:45, grarpamp wrote: > [...] > Unfortunately FreeBSD still does not > accept any donations via cryptocurrency. > Nor has FreeBSD community yet participated in any > crypto crowd funded code dev/bug/doc etc bounties. > The world is moving there, others are already making > good use of them, best get on that, have fun :) Honestly, this seems to me simply to be good policy on the part of the foundation (not accepting donations via crypto). There's no apparent benefit as far as I can see, and the extreme volatility of all existing cryptocurrencies by itself strikes me as an excellent reason to continue the current policy. -- George From nobody Fri Nov 4 05:07:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3TCB4PSsz4h1xl; Fri, 4 Nov 2022 05:07:34 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3TC947X3z4HXY; Fri, 4 Nov 2022 05:07:33 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk1-xa2a.google.com with SMTP id b81so1822485vkf.1; Thu, 03 Nov 2022 22:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mmneHoHvh1iu/dd0nnsRo8VnQ3awLpoe3eHB+oVYwZI=; b=fPBT4HLf1hueCWyXvjvDtrunv1iiSwRcCt//AIO0Rx89kF1TmqsQpvXAv2CjwkBjVu UEf2K/ruFBgRmpzKyhyriQxaY+0HcK1waSAc9jX5HvAd1I7Yb0swp45Xz7xFDs7u5t9W dAknPr6Ynq/tPZbtku5DFHXPBcz27Has0FHT0Z/hBTjnRiybXSjb2T1+E+V80rmVlIue OMZ5uIi+tAeS/bvK38fsc5pA9ATS1cDdXZxLgwBbkUIp/GzrSMm4nF4a6JGMGZ6fmESY 4vSEznbRwBXvK0OH5VANFf1kHBuixig5/9RzJTxjR2yiROxcGwnSM3G1DLhhY2gTV9Cv 8llw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mmneHoHvh1iu/dd0nnsRo8VnQ3awLpoe3eHB+oVYwZI=; b=Xhs8R79uyQXJKDA3nBPgFM3RKXjvSUao+TbAuJyNPTK4z6+wPUZWjQODACi86Y+Ubz gg1v1bJT7MHvZ8K7LKs4KfYJCXcAOJ74C4vYzc7jcDORarsZ3vX0W0tJvGUkEnNjqCue UzF0gBYlJqB73r7aPr9/2gaakJgmFpdcEdlA3pU3tEsqYCtkLdov0cu7rvLwVX7T+juR E7+x1RY0HlGVAcDpkFdumdbH16J+lyqKzay+DVycGuT9b60pBOfia6CFt7JfR6j1wKT1 qcz1K+cRUSM7B5NROKlbk8r+64qjZsnquvNuqyubDopo5Jm0JmYRWhNKTrgcKZVEB8Uq G4Uw== X-Gm-Message-State: ACrzQf2+eKrGvz0KoaN0neV2u+/zN/S1hnFQSNUvla4v8ZRiJejjUjIR 2d4NblevZ3F4/IrvbhPr1LtM/t5Gq9Y49P3UXwcm+IEKz7bJr9hhc1w= X-Google-Smtp-Source: AMsMyM5FUVypLtAjl9SFjPfBNEkUX1mhALEWTm+RwVSOTs2JzAL0uORbSEBjElFXdNaENSBjDlqEuECkbCnon/OA4Nc= X-Received: by 2002:a1f:3011:0:b0:3b8:7d0d:d570 with SMTP id w17-20020a1f3011000000b003b87d0dd570mr8372390vkw.31.1667538452447; Thu, 03 Nov 2022 22:07:32 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:5d11:0:b0:324:d963:1eff with HTTP; Thu, 3 Nov 2022 22:07:31 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Fri, 4 Nov 2022 01:07:31 -0400 Message-ID: Subject: Re: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) To: freebsd-hackers@freebsd.org Cc: questions@freebsd.org, info@freebsdfoundation.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4N3TC947X3z4HXY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=fPBT4HLf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::a2a as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2a:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,questions@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N >> Unfortunately FreeBSD still does not >> accept any donations via cryptocurrency. >> Nor has FreeBSD community yet participated in any >> crypto crowd funded code dev/bug/doc etc bounties. >> The world is moving there, others are already making >> good use of them, best get on that, have fun :) > [seems to be] good policy on the part of > the foundation (not accepting donations via crypto). No, they've probably never even given it serious consideration, let alone any consultation or demo, nor set any 'policy' on it. Is it really good 'policy' to flat out ignore the growing $1 - $3 Trillion mktcap base of potential donors? No! Donors who by the very nature of opensource crypto recognize the power of opensource upon which it must and does stand, but who hardly yet have any opensource OS they could donate to. Let alone one that might ever reach out and collab through noting: "The Power To Serve... use and HODL... Crypto" ;) Do you really think getting BSD running on phones and devices to put secure open wallets and scalable servers, services, trade engines, analytics, blogs, etc on would not attract any funding at all? That having more cryptocurrencies and such tools in ports and packages would not attract users and funding? That no devs would post or collect bounties? That no hardware funds would ever magically appear on doorsteps in response to request? And whatever else... Ever hear of Sean's Outpost or Pineapple Fund? Wake up to the possibilities mate :) > no apparent benefit as far as I can see youtube search: benefits of cryptocurrency Do you even wallet with coins, ever tx, bro? Hardly one can see without first trying that. > extreme volatility Typical anti argument, lol. Don't like to hodl or spend in the economy, no worries, just sell it for Fiat and close your eyes to any upside. Nevermind that all your beloved Fiats are horribly volatile straight down the purchasing power crapper compared to even gold, some Fiats of which haven't even been in existance as long as crypto has, many of which will die while crypto lives on, improves, and adopts. https://fee.org/ https://mises.org/ FreeBSD foundation has already lost tens of percent on Fiat to inflation, and if invested, to central bank, tax, friction, graft, stripe, and other nonsense. http://www.shadowstats.com/alternate_data/inflation-charts https://archive.org/details/TheCreatureFromJekyllIslandByG.EdwardGriffin Wake up. From nobody Fri Nov 4 14:56:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3kH32QbVz4gyhL for ; Fri, 4 Nov 2022 14:56:47 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3kH05MMGz44Cw for ; Fri, 4 Nov 2022 14:56:44 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A4EuZZB097272 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Nov 2022 15:56:36 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667573796; bh=XYfCTnS3osCgAx18HrDhSzilct3DTjBrBJMhppBgPqo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gB+GXaMmXopvUGuMoRUo8XMSm6kGJ8PVNaB0HKRGVzI1ir/kzrSDCOFW7l3jGNTSM iycyXfiB0sNl11m6IRRIBFOESw9PgB6HR+PUraLWXmDTmDeq4KkMJBcZL1ApYhqESO Ldb3eW2EXcXE/9G77d2qKiFUNKB6ElldUNUg0abI= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A4EuZCO026340; Fri, 4 Nov 2022 15:56:35 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A4EuZnI026337; Fri, 4 Nov 2022 15:56:35 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Fri, 4 Nov 2022 15:56:35 +0100 (CET) From: Wojciech Puchar To: George Mitchell cc: freebsd-hackers@freebsd.org Subject: Re: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) In-Reply-To: Message-ID: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N3kH05MMGz44Cw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=gB+GXaMm; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_RCPT(0.00)[freebsd]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> [...] >> Unfortunately FreeBSD still does not >> accept any donations via cryptocurrency. >> Nor has FreeBSD community yet participated in any >> crypto crowd funded code dev/bug/doc etc bounties. >> The world is moving there, others are already making >> good use of them, best get on that, have fun :) > Honestly, this seems to me simply to be good policy on the part of > the foundation (not accepting donations via crypto). There's no > apparent benefit as far as I can see, and the extreme volatility of > all existing cryptocurrencies by itself strikes me as an excellent > reason to continue the current policy. -- George > > Why? Accept and instantly change to something else. Let's clear things up. Crypto currencies are really worth nothing. Just people do believe they are worth something. It represent no real value. Classic currencies are really worth nothing. Just people do believe they are worth something. It represent value equal heat of combustion - if you have papers. Or zero if just in bank. The only difference is that classic currencies are enforced by law. Crypto are not. So you shouldn't differentiate, just then convert to currency or some other good you need. To avoid risks - do it at the day when crypto currency is transferred. From nobody Fri Nov 4 15:00:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3kN31fMJz4h02d for ; Fri, 4 Nov 2022 15:01:07 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3kN22VXNz4594 for ; Fri, 4 Nov 2022 15:01:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (097-081-026-048.res.spectrum.com [97.81.26.48]) by colo1.denninger.net (Postfix) with ESMTP id A3F9F2110A8 for ; Fri, 4 Nov 2022 11:01:00 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (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 denninger.net (Postfix) with ESMTPSA id 49DAA2FBD2F for ; Fri, 4 Nov 2022 11:01:00 -0400 (EDT) Message-ID: <82a624a0-b56a-200e-c879-06535c0741ff@denninger.net> Date: Fri, 4 Nov 2022 11:00:57 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) Content-Language: en-US To: freebsd-hackers@freebsd.org References: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> From: Karl Denninger In-Reply-To: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070802060801010806040603" X-Rspamd-Queue-Id: 4N3kN22VXNz4594 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.90 / 15.00]; SIGNED_SMIME(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[karl]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; SUBJECT_HAS_QUESTION(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This is a cryptographically signed message in MIME format. --------------ms070802060801010806040603 Content-Type: multipart/alternative; boundary="------------x9AX6HR6aFhncFAVBz2eWuje" --------------x9AX6HR6aFhncFAVBz2eWuje Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/4/2022 10:56, Wojciech Puchar wrote: >>> [...] >>> Unfortunately FreeBSD still does not >>> accept any donations via cryptocurrency. >>> Nor has FreeBSD community yet participated in any >>> crypto crowd funded code dev/bug/doc etc bounties. >>> The world is moving there, others are already making >>> good use of them, best get on that, have fun :) >> Honestly, this seems to me simply to be good policy on the part of >> the foundation (not accepting donations via crypto).  There's no >> apparent benefit as far as I can see, and the extreme volatility of >> all existing cryptocurrencies by itself strikes me as an excellent >> reason to continue the current policy.                    -- George >> >> > Why? Accept and instantly change to something else. > > Let's clear things up. > > Crypto currencies are really worth nothing. Just people do believe > they are worth something. It represent no real value. > > Classic currencies are really worth nothing. Just people do believe > they are worth something. It represent value equal heat of combustion > - if you have papers. Or zero if just in bank. > > The only difference is that classic currencies are enforced by law. > Crypto are not. > > So you shouldn't differentiate, just then convert to currency or some > other good you need. To avoid risks - do it at the day when crypto > currency is transferred. > IMHO this is at its foundation a political statement; one who has crypto something and wishes to donate to FreeBSD can trivially exchange it for "classic currency" and donate the classic currency.   Indeed you so-state in your first line in that there is no reason the person who wishes to make the donation cannot simply remove the entire point of debate by "instantly changing it to something else", in this case dollars. One thing I do like about FreeBSD is that it has mostly stayed out of said political debates, which is IMHO a good thing. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------x9AX6HR6aFhncFAVBz2eWuje Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 11/4/2022 10:56, Wojciech Puchar wrote:
[...]
Unfortunately FreeBSD still does not
accept any donations via cryptocurrency.
Nor has FreeBSD community yet participated in any
crypto crowd funded code dev/bug/doc etc bounties.
The world is moving there, others are already making
good use of them, best get on that, have fun :)
Honestly, this seems to me simply to be good policy on the part of
the foundation (not accepting donations via crypto).  There's no
apparent benefit as far as I can see, and the extreme volatility of
all existing cryptocurrencies by itself strikes me as an excellent
reason to continue the current policy.                    -- George


Why? Accept and instantly change to something else.

Let's clear things up.

Crypto currencies are really worth nothing. Just people do believe they are worth something. It represent no real value.

Classic currencies are really worth nothing. Just people do believe they are worth something. It represent value equal heat of combustion - if you have papers. Or zero if just in bank.

The only difference is that classic currencies are enforced by law. Crypto are not.

So you shouldn't differentiate, just then convert to currency or some other good you need. To avoid risks - do it at the day when crypto currency is transferred.

IMHO this is at its foundation a political statement; one who has crypto something and wishes to donate to FreeBSD can trivially exchange it for "classic currency" and donate the classic currency.   Indeed you so-state in your first line in that there is no reason the person who wishes to make the donation cannot simply remove the entire point of debate by "instantly changing it to something else", in this case dollars.

One thing I do like about FreeBSD is that it has mostly stayed out of said political debates, which is IMHO a good thing.

--
Karl Denninger
karl@denninger.net
The Market Ticker
[S/MIME encrypted email preferred]
--------------x9AX6HR6aFhncFAVBz2eWuje-- --------------ms070802060801010806040603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DbowggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBxIwggT6oAMCAQICEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQsFADB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlk YTEZMBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENB MSUwIwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBMB4XDTIyMDYyOTE2MTYz NloXDTI3MDYyODE2MTYzNlowOjELMAkGA1UEBhMCVVMxEjAQBgNVBAgMCVRlbm5lc3NlZTEX MBUGA1UEAwwOS2FybCBEZW5uaW5nZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvW ZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B 3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTgy+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYI XgVVPgfZZrbJJb5HWOQpvvhILpPCD3xsYJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMi WapsatKm8mxuOOGOEBhAoTVTwUHlMNTg6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMb NQm1mWREQhw3axgGLSntjjnznJr5vsvXSYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZM qa20JLAF1YagutDiMRURU23iWS7bA9tMcXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5 CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1l y+5ZOZbxBAZZMod4y4b4FiRUhRI97r9lCxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY 2BlA7ExM8XShMd9bRPZrNTokPQPUCWCgCdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEE MDAuMCwGCCsGAQUFBzABhiBodHRwOi8vb2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNV HRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCGSAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBD bGllbnQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNV HSMEgcIwgb+AFF3AXsKnjdPND5+bxVECGKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQ MA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5 c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lz dGVtcyBMTEMgMjAxNyBDQYITAORIioIQzl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJs QGRlbm5pbmdlci5uZXQwDQYJKoZIhvcNAQELBQADggIBAKquc7cu0xc8FNtAQauZvocDzWQj 7HG9YvMbWnMi+ckhiA3rdW5NwWg0HBhBho1YlnqV+ntCVE2L8ezohHWm+KAdfXgpraL86Vsn 3ywNlZu/3COMpo2ALuHln8YQtH3Y8ebvzKMdlf2b5WB+7mOFIxXIr4AnNOLKCkq5ZhzC6JW6 Jvw3P0csiGa3UrfatYID5NvPgkaQvEgimEjG3psZqwQTL2Wxohvw783PrDt3wS0XeNhvQ61g 3QJFZKuv+bmGH3YBSPo1t6NUGAr+JozX5lDihB8JGkBt/NwdYec49a08uL0BbPaAJ7NjuIPG 7Y0Ak7PXZT37yx/Zla9PzLMJFgbelOkaatdzbblMZPDEVZ27l4lGMmV83Lm3YP17sdAyS/Wp mav7WmJUkQ9iuIKzSpdc82i9Mfujl1vbBtwtkHNPPtKuulIFM4ZwrPKjlVdLqTSqD8m9yHEi Y0PuAooq63OpJWF6hvMaiIPBWEAVIaDW9uG0MshLl9DnHnMyrJTfuC33Z9mOGMz7dRBjJd5Y W02xAzYnUuEBOpj+LQv5R8XIFMHFXktqEKvQrXeM2RU+PcZqKOBkTktxBLn3NI5VfA15Jk0c 5V5XcOqo3p2hvrwvXrinrb2pEREnoqmfrkXT3zOq5Y6ryRH8u734lGEF0dILXzoV4PM7XFit oTePoEjmMYIFBDCCBQACAQEwgZEwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGEx GTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTEl MCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQQISAsbzIfg9AV1t33FSCanO XWNfMA0GCWCGSAFlAwQCAwUAoIICQzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0yMjExMDQxNTAwNTlaME8GCSqGSIb3DQEJBDFCBEDggZm5Wt6P3MzB2Cg2 27C4r+WiEQuwW88FkwMWhBHDBlz4RgZEMN/U9UwnCuy72mgV/9WG38tKC7tiktuzG62mMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaIGCSsGAQQBgjcQBDGBlDCBkTB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEZ MBcGA1UECgwQQ3VkYSBTeXN0ZW1zIExMQzEYMBYGA1UECwwPQ3VkYSBTeXN0ZW1zIENBMSUw IwYDVQQDDBxDdWRhIFN5c3RlbXMgTExDIDIwMTcgSW50IENBAhICxvMh+D0BXW3fcVIJqc5d Y18wgaQGCyqGSIb3DQEJEAILMYGUoIGRMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9y aWRhMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMg Q0ExJTAjBgNVBAMMHEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0ECEgLG8yH4PQFdbd9x Ugmpzl1jXzANBgkqhkiG9w0BAQEFAASCAgA0rZ/6C+uA5jkBm3xmGLZdEbwsHHOUARfLv0xu u0bcNKQlUaA/7NjCoOxY+k0+HHrBHQcgR38Hvxc7L7MVr+wPpez8B/fDZCzf5diAt1i23E4g zlFNH6EuqKAfO2J4Gt6r1QThGjjpc2CVMExVv5zj/QU2AnayWwgNc+mfzH1K8k9jcfnzGB75 UfrNqzyAo2LRKgSFVH/aFKqqviNX7atkntD2obGoQjX+Jt6PsxWmHb7sXsm3BbfTtRU7u/AD RUCp8W5A4SJZTVQtaN9xNUm9ONT6BJXg/zPUpsOPgXjXGL6P7WGUWfjyXRFseC/CXyFBoyms InYp1tG5Br/cClgD3/Tt3/WySRO14mSR1uYD3JpFMtqXNsK1QB9ATUTb+B3gpAuJnWbOS73E BULrFDSM+ervy9r0GZT0c5gGtaFP6i5Eh0K3NYD9Xpix5eh2FhUoQPs01OB7/ZYZP9ZFqho+ NWZPyS0RJECoNq4IUCISYptG4nA1aCqnH0YFHfitJDw4h+lurPeOUQKeyfqHR7F7jCpbbNP1 bcEAVAk0hf4eTQgsjYpOc1oOxoU5rGW0DJkrpNh1C5Y0+BBzate++NYWFWtHTeqSPrh4MFsK TnfFgJnRn4EIi7rBc99aV0oBOPnY1AYeYlzZuFKVJc581NYBDE1U96Iqy48XMNdZMTxt3wAA AAAAAA== --------------ms070802060801010806040603-- From nobody Fri Nov 4 16:16:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3m383HZrz4h89K for ; Fri, 4 Nov 2022 16:16:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3m380RtZz3FVX for ; Fri, 4 Nov 2022 16:16:35 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 2A4GGMIB051094; Fri, 4 Nov 2022 09:16:28 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Fri, 04 Nov 2022 09:16:22 -0700 From: Chris To: Wojciech Puchar Cc: George Mitchell , freebsd-hackers@freebsd.org Subject: Re: Crypto Donations In-Reply-To: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> References: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_46431b91701cf5d56b860645d7a28f49" X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4N3m380RtZz3FVX X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; TAGGED_RCPT(0.00)[freebsd]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_46431b91701cf5d56b860645d7a28f49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-11-04 07:56, Wojciech Puchar wrote: >>> [...] >>> Unfortunately FreeBSD still does not >>> accept any donations via cryptocurrency. >>> Nor has FreeBSD community yet participated in any >>> crypto crowd funded code dev/bug/doc etc bounties. >>> The world is moving there, others are already making >>> good use of them, best get on that, have fun :) >> Honestly, this seems to me simply to be good policy on the part of >> the foundation (not accepting donations via crypto). There's no >> apparent benefit as far as I can see, and the extreme volatility of >> all existing cryptocurrencies by itself strikes me as an excellent >> reason to continue the current policy. -- George >> >> > Why? Accept and instantly change to something else. > > Let's clear things up. > > Crypto currencies are really worth nothing. Just people do believe they are > worth > something. It represent no real value. > > Classic currencies are really worth nothing. Just people do believe they are > worth > something. It represent value equal heat of combustion - if you have papers. > Or > zero if just in bank. You're spot on here. In fact it has a name: fiat. IOW it's a *perceived* value. When the US dropped gold and silver certificates back in the 60's. US currency was no longer backed by the gold and silver bullion then stored in Fort Knox. Its actual value was then reduced to no more than the paper it was printed on, or what others *believed* it was worth. You decide. ;-) > > The only difference is that classic currencies are enforced by law. Crypto > are not. > > So you shouldn't differentiate, just then convert to currency or some other > good > you need. To avoid risks - do it at the day when crypto currency is > transferred. --=_46431b91701cf5d56b860645d7a28f49 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_46431b91701cf5d56b860645d7a28f49-- From nobody Fri Nov 4 22:14:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N3w0j70f4z4gtvx for ; Fri, 4 Nov 2022 22:15:01 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N3w0h53Gnz3vcq for ; Fri, 4 Nov 2022 22:15:00 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id D1F89FBF8DA for ; Fri, 4 Nov 2022 22:14:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667600097; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=pVBd5Dqp9kT4Wk8oY8SYebcFfq7XrL5jBYP1YzUThkI=; b=YFLTPNxg7ROBt0sagBRNkrO4Oj4tRTkZYdhajnTXxv15A3k7BAMBvvGtyW7jjY3W pJEiXeiSqnmOWcnUxbjG7alYEprUFDQxkyim/nZ8QfJqcueMlOoL7uzihyuKTzqzEbC PldjmAn9D9AYPytdYMXho/mESwirEGttA2aY9ZptszXYtj0zPEtb43mB3Idi2jQh1k/ IUEfzkmkzM8SVA05+oECaFmjLTVbaL6KMRbxVXOJqNaYZvjWQJPDO+LAmniP1zkwwFz 42GL9I6HyMnjoixn4rY+3CKZFYlcD/3F7QMYHgPwkqXHvXfvMJcgH9AZPv/Z1betVc+ KiDiWVjvKw== Date: Fri, 4 Nov 2022 23:14:57 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: In-Reply-To: References: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4N3w0h53Gnz3vcq X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=YFLTPNxg; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-3.00 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Nov 4, 2022, 01:59 by imp@bsdimp.com: >> I guess my expectations were too high. Sure, things has improved, but wi= thout >> a clear set of rules - like ALL commits must be reviewed before going i= nto the >> kernel, base, etc. - the same problem can happen again. >> > > Now I know you are trolling... > > Nobody that's has done engineering for any length of time would expect re= views to catch all problems. That's at best wishful thinking and at worst a= horribly toxic management culture. > You're putting words in my mouth. I never said that reviews would catch all= problems, what I am saying is that we *need* to learn from past mistakes by having fixed = rules. > What has happened is that there is more review, the commits are generally= much much smaller and more people are reading the commits after the fact. = I half jokingly told a coworker recently the fastest way to find a problem = in my code is to commit it since so many people read it, I get feedback rig= ht away. > > Again, these things are present in the data.=C2=A0 There are way more tes= ts than being committed than before. There is more CI coverage than before.= There are efforts to greatly expand that. The layered approach gies a long= way towards catching issues like this than before. Thinking promulgating s= ome simplistic rule change is at best overly simplistic think and disingenu= ous trolling at worst. > It's great that things have improved, but without a clear set of rules, suc= h that nothing gets into the current branch from a committer that hasn't been reviewed by = at least another developer, the problem will just repeat itself. All we need is a "l= ow", people feeling off, life happening, etc., and reviewing gets slacked. I would rather say, anyone who has done engineering for any length of time = knows that without clear rules and guidelines and some kind of "safety" system to implement su= ch rules, all guaranties are out the window. All it takes is that when someone has made a commit, someone else has to lo= ok it through, provide an "OK", and then it can get into current, without the "OK", it sta= ys out of current. This is not a guarantee, but at least something like the wireguard problem,= would most likely be prevented in the future. Since things have improved, it shouldn't be too difficult to make it a cond= ition. Cheers. From nobody Sat Nov 5 02:48:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N423y1DWjz4hRY3 for ; Sat, 5 Nov 2022 02:48:14 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N423x2YvZz3YcZ for ; Sat, 5 Nov 2022 02:48:13 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 1BC93FBF94C for ; Sat, 5 Nov 2022 02:48:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667616491; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=/a8lglxcSfh6YZ6xJA2DNZChgaYHfLydxx3sa6dhIr8=; b=cDstjNss3RdRwy478R4WRwarjYymN0OirXQBSoy90optlG8eTHkYlBk9th3OyCAO 86UUQ/ckAjGeLfz6XRcUzu1W2+v98NvtIFaOFJziZ8Q48eqNRYfdDwktW+b8hB0FZCL pSGNVpTtfR/1bB5uYRh9u3AMxUfZslwo91z/RDAB14uShpvsVc9hLNLLbXmO4EHO1/0 FOeotkjofwVVTTDaftM1whWLlcpyMRA9Hs32cMB2GnfH9C/iboNUbHD9ZP7m2hTdZ89 +6emslOr7UU2uOJUY4VY+tgEsyxmMHU1FZxLZen2PerScMOiBgCJy4/wJwuf4ZKvzAz zyORSwVNFg== Date: Sat, 5 Nov 2022 03:48:11 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers Message-ID: Subject: Re: What is the status of the FreeBSD development process now? List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N423x2YvZz3YcZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=cDstjNss; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-1.91 / 15.00]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.91)[-0.914]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N As a follow-up I have asked the question on tech@ for OpenBSD. For anyone interested, the procedure is as I mentioned, that all commits are reviewed, even those without an "OK" marked in the commit. https://marc.info/?l=openbsd-tech&m=166761184217787&w=2 Cheers. From nobody Sat Nov 5 04:56:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N44w81ZWWz4gjL1 for ; Sat, 5 Nov 2022 04:56:40 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N44w71mPVz3m5s for ; Sat, 5 Nov 2022 04:56:39 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: by mail-vk1-xa30.google.com with SMTP id i15so3614933vka.0 for ; Fri, 04 Nov 2022 21:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=OsunGp7/aB9DaFu+xaTwyo0NiAIV1+HfRdfqUWcW7AY=; b=mTW3oB39Wq20IDVDYEKwgoClkIp2aXO3vx1z9gwcLdftAajXKYprEzRB03AZN+0erD bniNlz/WvVfQ467FN4IYShOkRitZWnWFfOFgZkV/ZA2j7IQvCM7kFtlCLNHE8EbrZBom 4rjRxyKpdEqvbDQhsO8jS1oFQpJZaUdygGx+6gcoGBnBt7fdnZq4PcyGGA/qwrv0Hv+2 EI+3kiGNNleLDeYaxTeGrVvndHg/PEXIT4xcNZ11ujbM8oLUlYNihr8BzPNFzZDLrESg E73qhy2K9/Y1r5PBOabbHkuzWwThbFkzrAzAB4rufh0NfYAFXnOxX7cKLaAa+l3AfHXv vpeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OsunGp7/aB9DaFu+xaTwyo0NiAIV1+HfRdfqUWcW7AY=; b=J/K7mCd7lGYmkynoTUp+58LlkR94oDYvTeFx3BxOppt7kfVh8LPGpPl1kiG1SS6fjU dIRidpTDsOYwr4pdPVsZAx3SIJTAySJQDeZe5aDdxUkoxyagieSGyXPRidL5mCFsNGx+ 8C4E1bfGD7Jws5ctI3gjhM8jwsY0/5KYS0dqMoT6dpcwr17nwggE0NgOfd5OL0lqNqg9 RskGLCLKF+G+XpjC1EGVJV2/sb6xfR1aaHE9gOgxt5npOa+NMH05/+v+tskcti67KCS6 N16KkLAVQ0wI/6ZQdGIO/1h77v5ClxXEowPcNX5+dI/LY4XnwDFcTAcl3HRpiSy3yL76 H8YQ== X-Gm-Message-State: ACrzQf0WpQ7eKU0cElBy/ehbBYoYLSS7jcMGzx50hnrhCH4XYPkpraGz Pq/3FX0590pkrSjec9Ly0HQaBXwBj24= X-Google-Smtp-Source: AMsMyM7wEVUK/r30FaTpKzc2HRi/+OU9+A31rxxkbCXDNPrJQxxszTsHy3vTLfQRWuosljxxNB/0MA== X-Received: by 2002:a1f:280a:0:b0:3b7:82e4:f3a1 with SMTP id o10-20020a1f280a000000b003b782e4f3a1mr4946627vko.17.1667624197689; Fri, 04 Nov 2022 21:56:37 -0700 (PDT) Received: from [192.168.2.15] ([71.181.93.158]) by smtp.gmail.com with ESMTPSA id a17-20020a67eb11000000b003a7d2bec130sm154644vso.28.2022.11.04.21.56.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Nov 2022 21:56:37 -0700 (PDT) Message-ID: <53d29778-ce06-22c6-40a8-5023443f976f@gmail.com> Date: Sat, 5 Nov 2022 00:56:14 -0400 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: What is the status of the FreeBSD development process now? Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: Theron In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4N44w71mPVz3m5s X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mTW3oB39; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of theron.tarigo@gmail.com designates 2607:f8b0:4864:20::a30 as permitted sender) smtp.mailfrom=theron.tarigo@gmail.com X-Spamd-Result: default: False [-1.39 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.61)[0.607]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a30:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On 11/4/22 18:14, iio7@tutanota.com wrote: > It's great that things have improved, but without a clear set of rules, such that nothing > gets into the current branch from a committer that hasn't been reviewed by at least > another developer, the problem will just repeat itself. > All it takes is that when someone has made a commit, someone else has to look it through, > provide an "OK", and then it can get into current, without the "OK", it stays out of current. > > This is not a guarantee, but at least something like the wireguard problem, would most likely > be prevented in the future. It's not clear that you have any suggested solution for the "problem" as you have defined it.  The wireguard commit was signed off by an independent reviewer, for what that was worth.  It wasn't the exact version that was committed, but in largely the same problematic state.  Whether the committer could have committed something substantially different from the contents of the review thus circumventing the review process was not the problem in this case. Furthermore, the newly added module presented a vulnerability *when loaded*; this was not an introduction of a vulnerability in existing configurations of systems running current.  It's simply not reasonable to expect current to remain thoroughly stable and secure after blindly enabling newly landed features and to do so on a production system is highly irresponsible.  Review of current is ongoing from time of committed features to feature-freeze for the bugfix-only review period and eventual release. From nobody Sat Nov 5 08:43:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N49y75XkJz4h9FJ for ; Sat, 5 Nov 2022 08:43:43 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N49y658RHz449v for ; Sat, 5 Nov 2022 08:43:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A58hX5o060217 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Nov 2022 09:43:33 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667637814; bh=mv2V8Aq3L0lq9RvhSc94wlNCO+qmrbA6Er2/Z+1MH84=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AZmDKZwufKT6fOqGDi3z67YN9QHSsGG8K3UNeO1aMEqKSpd2DkN9Ue3B6fi0Sde5s r47tG7d0ttGjRcHnAPX2tECcTRjX7Ic0UXw4XBiqpmb4ifW0BsSfrLKcCYahPpHf23 lIrRdl54wTNrq7iVKiQcYcrXykTEln+bXNB46r6s= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A58hWCA032440; Sat, 5 Nov 2022 09:43:32 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A58hWOL032437; Sat, 5 Nov 2022 09:43:32 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sat, 5 Nov 2022 09:43:32 +0100 (CET) From: Wojciech Puchar To: Karl Denninger cc: freebsd-hackers@freebsd.org Subject: Re: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) In-Reply-To: <82a624a0-b56a-200e-c879-06535c0741ff@denninger.net> Message-ID: <29f403f-dc93-51a4-1945-39ac97218e48@puchar.net> References: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> <82a624a0-b56a-200e-c879-06535c0741ff@denninger.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="3974694515-1471159027-1667637812=:32436" X-Rspamd-Queue-Id: 4N49y658RHz449v X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=AZmDKZwu; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-2.50 / 15.00]; CTYPE_MIXED_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[puchar.net]; SUBJECT_HAS_QUESTION(0.00)[] X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3974694515-1471159027-1667637812=:32436 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > day when crypto currency is transferred. > > IMHO this is at its foundation a political statement; one who has crypto something and wishes to donate to FreeBSD can trivially > exchange it for "classic currency" and donate the classic currency.   Indeed you so-state in your first line in that there is no > reason the person who wishes to make the donation cannot simply remove the entire point of debate by "instantly changing it to > something else", in this case dollars. > > One thing I do like about FreeBSD is that it has mostly stayed out of said political debates, which is IMHO a good thing. You are right. But if some fool will come and tell you: i will give XXX bitcoins for you? They you ask to convert to dollars. He say no, he want to give you bitcoins. You refuse or get that bitcoins and exchange it? Of course, using this bitcoins needs some work to convert it. But if it's not small amount of value they it's worth it. --3974694515-1471159027-1667637812=:32436-- From nobody Sat Nov 5 08:45:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4B0x5cyfz4h9GN for ; Sat, 5 Nov 2022 08:46:09 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4B0x0Cw5z453N for ; Sat, 5 Nov 2022 08:46:08 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A58joCI061006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Nov 2022 09:45:50 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667637951; bh=LlNGRJLlqpq0hYDdAX+XgZWiJnw6Dd5Fdk8WLkGZHw0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YGfFKB5x+8/1o0/luFh+1eB+HZUHxPNl0BgmINmZoOIuvGHJfEq/OnDUOaK9qoQk+ qcS6YHrBjfOUIL4QfH001ewKQOkYoOfh5Ax64+HoUTl5m873QW2WflS9lKMT7Cy4Ob vr6nNMsOk0o4P2xZx/xh1zytlgJNMlhOHHAYRzaI= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A58jos6032464; Sat, 5 Nov 2022 09:45:50 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A58jnAu032461; Sat, 5 Nov 2022 09:45:49 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sat, 5 Nov 2022 09:45:49 +0100 (CET) From: Wojciech Puchar To: Chris cc: George Mitchell , freebsd-hackers@freebsd.org Subject: Re: Crypto Donations In-Reply-To: Message-ID: References: <93b6c160-966d-d17d-fafa-2fe554b651c2@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N4B0x0Cw5z453N X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=YGfFKB5x; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TAGGED_RCPT(0.00)[freebsd]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> zero if just in bank. > You're spot on here. In fact it has a name: fiat. IOW it's a *perceived* > value. > When the US dropped gold and silver certificates back in the 60's. US > currency was > no longer backed by the gold and silver bullion then stored in Fort Knox. Its > actual > value was then reduced to no more than the paper it was printed on, or what > others > *believed* it was worth. You decide. ;-) > Right. You described the difference between currencies and money. Money is silver or gold. By the way - In USA dollars are ILLEGALLY forced to be national currency, against US constitution that clearly says that you cannot force anyone to take payment for debts with anything else than silver or gold. From nobody Sun Nov 6 07:58:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4mw942xMz4hlBm for ; Sun, 6 Nov 2022 07:59:05 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4mw808Y4z3dCb for ; Sun, 6 Nov 2022 07:59:03 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A67wshm063624 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Nov 2022 08:58:54 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667721535; bh=GYK0g1uobCppQp9boN0wrnTWfe7Y1ud0wTdy5TKK+54=; h=Date:From:To:Subject; b=D8ckv2f/wSBDSna55u2ioQo4gZDtVZeq+7fQwcm82SGTjNpYUOzRBW2wL6SbUIEY5 g4rYL6x4UEifqrmDATjHNriBdNbuhstw+LsUd3Bo+SZ/3jcL760scYS61MAIATfjxt RAlKFO86zdUtJDY5F88pFfzpPkDxVyK4Ur+J4cb8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A67wsBx036952 for ; Sun, 6 Nov 2022 08:58:54 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A67wrPk036949 for ; Sun, 6 Nov 2022 08:58:53 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Nov 2022 08:58:53 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: FreeBSD financing Message-ID: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4N4mw808Y4z3dCb X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b="D8ckv2f/"; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I looked at FreeBSD site and see this year very low financing (year still not ended but is close) relative to former years. And no Juniper listed. I remember some time ago FreeBSD switched to clang because of Juniper pressure that said they have constant law problems because of GNU general communist licence. Which was logical. but now i read that Juniper have "alternative" JunOS based on linux. Is GNU general communist licence no longer a problem for Juniper? From nobody Sun Nov 6 08:34:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4nj64KH6z4hpXq for ; Sun, 6 Nov 2022 08:34:34 +0000 (UTC) (envelope-from saifi.khan@nishan.io) Received: from s411.sureserver.com (s411.sureserver.com [192.252.151.33]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4nj53bfMz3j2Z for ; Sun, 6 Nov 2022 08:34:33 +0000 (UTC) (envelope-from saifi.khan@nishan.io) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=nishan.io; h=message-id :reply-to:from:to:subject:date:mime-version:in-reply-to :references:content-type:content-transfer-encoding; s=dkim; bh=5 gNbQn8dwEGrTtkw5nkrkkIaenm4C3ZtIFC+S2qn+P8=; b=VGj/91bQyZ9zrDpnw 57pmj1pdf8P1Q+SyKYiCwNSi+Np4VdBKedBI3ZIGawSNZFwB2nSFPFs98edTcoDQ LM+Z4dAcKPkdxIoyWTrYSKaD0839tgWRSt4wZjNT+TfAJmq9QkByaefM+4LM7a60 vuCUp7ck2PLT7LKmmArz+DpuH8= Received: (qmail 21466 invoked by uid 1900); 6 Nov 2022 08:34:31 -0000 Message-ID: <20221106083431.21465.qmail@s411.sureserver.com> Reply-To: "=?utf-8?Q?Saifi=20Khan?=" From: "=?utf-8?Q?Saifi=20Khan?=" To: freebsd-hackers@freebsd.org Subject: =?utf-8?B?UmU6IEZyZWVCU0QgZmluYW5jaW5n?= Date: Sun, 06 Nov 2022 08:34:31 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Mailer: WebMail 2.55.13.14 X-Suremail-Sender: 103_199_139_48 X-Originating-Email: saifi.khan@nishan.io In-Reply-To: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> References: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4N4nj53bfMz3j2Z X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nishan.io header.s=dkim header.b="VGj/91bQ"; dmarc=none; spf=pass (mx1.freebsd.org: domain of saifi.khan@nishan.io designates 192.252.151.33 as permitted sender) smtp.mailfrom=saifi.khan@nishan.io X-Spamd-Result: default: False [0.40 / 15.00]; SUBJ_EXCESS_BASE64(1.50)[]; FROM_EXCESS_QP(1.20)[]; REPLYTO_EXCESS_QP(1.20)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+exists:192.252.151.33.s411.smtp-spf.sureserver.com]; R_DKIM_ALLOW(-0.20)[nishan.io:s=dkim]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[nishan.io:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; HAS_REPLYTO(0.00)[saifi.khan@nishan.io]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[nishan.io]; REPLYTO_EQ_FROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:8739, ipnet:192.252.144.0/20, country:BG] X-ThisMailContainsUnwantedMimeParts: N > -------Original Message------- > From: Wojciech Puchar > To: freebsd-hackers@freebsd.org > > And no Juniper listed. I remember some time ago FreeBSD switched to clang > because of Juniper pressure that said they have constant law problems > because of GNU general communist licence. Which was logical. > > but now i read that Juniper have "alternative" JunOS based on linux. Is > GNU general communist licence no longer a problem for Juniper? > @Wojciech GNU General Public License (GPLv2) is a free software license. You may be frustrated but GPL has consistently delivered ! Your choice of biased words is matched by your lack of understanding of co-opetition in technology markets, Linux kernel being the exemplar. NetBSD project was pressured by Wasabi. FreeBSD project was pressured by Juniper (as you write) and many other corps. LLVM-CLang was alll pumped up by Apple etc. Does that mean when waved dollars each project becomes a dancing queen (aka exploited) ? warm regards Saifi. From nobody Sun Nov 6 09:29:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4pwf3D8Mz4ghN6 for ; Sun, 6 Nov 2022 09:29:38 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4pwd1dsZz3qTP for ; Sun, 6 Nov 2022 09:29:37 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4N4pwV4dCrz6fmj; Sun, 6 Nov 2022 10:29:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :subject:subject:from:from:content-language:references:date:date :message-id:received; s=bjowvop61wgh; t=1667726968; x= 1669541369; bh=MzZELnq1KiBXAWzJV+Fl9nJDlmEKjZI2gVeE2saoJxc=; b=S F3VGMscMPU8s2OfrkXZrYxSdw40029E6srngjlt/MSU5QVFyPLUrUNN42Upp0kPo oOyBWkNEQphI4N3ph2WwAdabiQgDgdhCBROtdU4eEAKw6+GolA7VfXh0uX48JzZF ttiqiC4/2vohRq+kbCZXVh+6kWEBKNk1grUrI2ji58W3Yd9lEB8JYa2xS76y0AaA ByqeBs2K4QK+CROp+4uYPDalDIwKYPyrWoRa07OnD1oMw7er/60XdftDyllp6d/D 3EENn7g5tIgl0EFnFJlKgazhjktleNxXbfKbMksbjrgb6ksrYNwNPYgNt2ntqGHb 8SXxqQYAfAMpnanSHvH1w== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id mv5bJbvlCYsS; Sun, 6 Nov 2022 10:29:28 +0100 (CET) Message-ID: Date: Sun, 6 Nov 2022 10:29:27 +0100 To: Wojciech Puchar , freebsd-hackers@freebsd.org References: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> Content-Language: en-US From: Guido Falsi Subject: Re: FreeBSD financing In-Reply-To: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N4pwd1dsZz3qTP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="S F3VGMs"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-2.00 / 15.00]; MISSING_MIME_VERSION(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[madpilot.net:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 06/11/22 08:58, Wojciech Puchar wrote: > I looked at FreeBSD site and see this year very low financing (year > still not ended but is close) relative to former years. AFAIK most donations happen in the last few weeks of the year, so the fact that the donation counter is relatively low in November is no indication. As far as I can remember it's always been like that. I don't have hard data on this, except my own memory and remembering various articles on the internet in the past year declaring the project dead based on donation count at similar times, when the counter jumped towards the end of the year. There are also some reasons why donations arrive at end of year. Only at that time big donors (and smaller ones too) have an idea IF they have money to donate, and IF they will be able to reap the fiscal advantage such donations can give. So any such worries should be postponed and reviewed around December, 31st. -- Guido Falsi From nobody Sun Nov 6 15:04:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4yMJ55Pnz4hNMh for ; Sun, 6 Nov 2022 15:04:44 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4yMH1k5hz3XRZ for ; Sun, 6 Nov 2022 15:04:42 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A6F4ceq025527 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Nov 2022 16:04:39 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667747079; bh=HfSCmea5DLHJxe0rchKQRNINWMRFVwOdOC4rweN3/mo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eyPp/jNglwT3KG5bWX9aegIYbPEenRnDyP0X3sxjyy/IC8nDgdjwoJokp11KApEpg kAo/CWXFMtMVgPanFz+Huki5SQknWHc6kEDr9kyA9cnuYJAyPnaC8JbPKNXy8+hAI4 in10baHfJrmM6VgifAQmrd7npaouE70k7BROEzsU= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A6F4cA8038145; Sun, 6 Nov 2022 16:04:38 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A6F4beg038142; Sun, 6 Nov 2022 16:04:38 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Nov 2022 16:04:37 +0100 (CET) From: Wojciech Puchar To: Saifi Khan cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD financing In-Reply-To: <20221106083431.21465.qmail@s411.sureserver.com> Message-ID: References: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> <20221106083431.21465.qmail@s411.sureserver.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N4yMH1k5hz3XRZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b="eyPp/jNg"; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > > @Wojciech GNU General Public License (GPLv2) is a free software license. You may be frustrated but GPL has consistently delivered ! No. Free means free. Doesn't need any extra requirements From nobody Sun Nov 6 15:05:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N4yNM0xpvz4hNSV for ; Sun, 6 Nov 2022 15:05:39 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N4yNL3TsNz3YCT for ; Sun, 6 Nov 2022 15:05:38 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A6F5aMp026600 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Nov 2022 16:05:36 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667747137; bh=oE4qvrwMbLnu+IZdcwF+6ZqrZ4T4PY0bKEHtxmjI+6Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TxeXZYokJ6JVU1DdRdeWQiZsBRcOiKe9kPbdezgZdQcGIHlOmmIaAr4Ix+ML18NMw ryHWB+7vJaFzvA/Dk+CQYhS6+qzWA06vh4zjVkrF51Jukz4LJGppAD3hxkkgi/p8kk 2hcbPYnucqIVIXlUAwwz2WWx2tlCLyLshm4OLUuc= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A6F5a0f038162; Sun, 6 Nov 2022 16:05:36 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A6F5aKU038159; Sun, 6 Nov 2022 16:05:36 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Nov 2022 16:05:36 +0100 (CET) From: Wojciech Puchar To: Guido Falsi cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD financing In-Reply-To: Message-ID: <69ea9af3-27e4-af24-1f72-fba089be992f@puchar.net> References: <8166ec14-ba84-cae4-d481-eb4ddb141d@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N4yNL3TsNz3YCT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=TxeXZYok; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx:c]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> I looked at FreeBSD site and see this year very low financing (year >> still not ended but is close) relative to former years. > > AFAIK most donations happen in the last few weeks of the year, so the > fact that the donation counter is relatively low in November is no > indication. As far as I can remember it's always been like that. > That was my first idea. Wish there will be uranium sponsors this year. Or maybe plutonium (>1 million dollars) ;) From nobody Sun Nov 6 21:16:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N56ct1FjWz4h8LP; Sun, 6 Nov 2022 21:17:02 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N56cs2C9Dz3Lcc; Sun, 6 Nov 2022 21:17:01 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id BB0E3FBF9FE; Sun, 6 Nov 2022 21:16:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667769418; s=s1; d=tutanota.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=W1sE1s0qsi5dW3NUB9g4wwj04c3zBKCrg7oUG+Ap258=; b=oEhYCtjVWBOAJmcUD/nZAtU23UrHH8qf76LSUfEoyTNdwWz+j+b9UmuNDrgu5koX gVBRtfc8nGQz1xl7VmBju/8Nlx15G3f+yL65Ui7YLtBLPZuvUjebKpQgWHde1Bzf3u6 nn/pQEeCMbS0ebgy8IN06HE2tsT1kWCjDEPbun/r7/0NbtXP5XXe320P5Yi2pszMukW 0wZjUU/HLT58d6nMsclqT3g2H+/WNLA1KoYob0eUFBCLlbk6mReNUr+Iq3aPE7Rz1e9 tw9fHCWCOHiDFGnfEedX2QLwjHHn4chzBBLAfW52kio1AErjCHR8VSOV/WiNDJ5lKGZ gzmkH0tTBQ== Date: Sun, 6 Nov 2022 22:16:58 +0100 (CET) From: iio7@tutanota.com To: Freebsd Hackers , Freebsd Questions Message-ID: Subject: Thank you for the kind and helpful community List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4N56cs2C9Dz3Lcc X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=oEhYCtjV; dmarc=pass (policy=quarantine) header.from=tutanota.com; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_NO_DN(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I just want to say thank you to the FreeBSD core team, the FreeBSD developers, and the FreeBSD community in general for everyone's patience and for providing a friendly, helpful and inviting community. It is hard to find elsewhere. I apologize if I in any way came across as being impolite in my questions about the code commit procedure and status in FreeBSD, that was NOT my intent. Thank you. Kind regards. From nobody Sun Nov 6 22:44:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N58Z111Btz4hLGv for ; Sun, 6 Nov 2022 22:44:41 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N58Z00ccHz3lWk for ; Sun, 6 Nov 2022 22:44:39 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A6MiZEt022863 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Nov 2022 23:44:35 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667774676; bh=9WvrN7I8W+xPMvhE9PQt0Wr3ccHnl3uYjo6W7w2t9N4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=AWQU+sZ60Cqz3sySakuQeeDWq6neFb8+grUEZdCCGXY6p3pFhooLOp3YP46nF+4pU lCspMfEjhv1rsVViIYwQaCc0VA2cuMcIN7bqhX/8W7I6fSFyxKdZN/Bm8O/cJ+O+MQ zkhNxv3gxOd1f/kUdGX/bw86AlOt2WBiUcxWbTV0= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A6MiZuh039420; Sun, 6 Nov 2022 23:44:35 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A6MiYRF039417; Sun, 6 Nov 2022 23:44:34 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Nov 2022 23:44:34 +0100 (CET) From: Wojciech Puchar To: Warner Losh cc: freebsd-hackers@freebsd.org Subject: Re: SSD - trim fails In-Reply-To: Message-ID: <16589dc-a890-579-c523-db92be5335ce@puchar.net> References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N58Z00ccHz3lWk X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=AWQU+sZ6; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > Next, maybe the drive is lying the size of the DSM it will support, but again, this is a weird > message to report a request that's too long with. > > Maybe it doesn't support queued DSM, despite all appearances to the contrary from its > identify tables. Try setting the trem method to DSM_TRIM: > # sysctl kern.cam.ada.0.delete_method=DSM_TRIM > should do the trick. At the very least, that will change the command we send so if it can't this works. but not from /boot/loader.conf i put it in /etc/rc at beginning so it for sure is done before doing first trim. thank you From nobody Sun Nov 6 22:47:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N58ds6QWWz4hLXV for ; Sun, 6 Nov 2022 22:48:01 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N58dr6vkmz3nRJ for ; Sun, 6 Nov 2022 22:48:00 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A6MlwNM024809 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 6 Nov 2022 23:47:59 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667774879; bh=Wa8Op6A5HwfXG9QyhOvOM6j3myZm8aeyTp4M71s6gbE=; h=Date:From:To:Subject; b=QAFQDlleQgz5e2+v0kL9t05SFd621G9tl7Qtiv9U3/nJcEVqqLGT+MuUA9Pa+wtN8 vgHXY5ie0x2PtaOewZmIoFVtd85c8co1/hcaY2F6WdFaWmHUyLRxpEEHHzzQiXGSuW QPqR04dJ78CZVoDIghDzxEuZrysxYwgDDYDRaqZ8= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A6MlwvO039442 for ; Sun, 6 Nov 2022 23:47:58 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A6MlwLq039439 for ; Sun, 6 Nov 2022 23:47:58 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Sun, 6 Nov 2022 23:47:58 +0100 (CET) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: NVIDIA driver problem Message-ID: <43149b5f-8b83-c59-757e-4b4282fb63bc@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Rspamd-Queue-Id: 4N58dr6vkmz3nRJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=QAFQDlle; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[puchar.net]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N i have one on laptop build nvidia-driver-390 it loads fine (kldload nvidia-modeset.ko) nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.154 Wed Jun 22 04:42:19 UTC 2022 i configured Xorg as for a guide. no xorg.conf in xorg.conf.d file nvidia-driver.conf https://forums.freebsd.org/threads/howto-setup-xorg-with-nvidias-driver.52311/ Xorg doesn't start. It loads nvidia driver for Xorg but just says no screen found. How can i diagnose a problem? From nobody Mon Nov 7 03:40:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5H7706SMz4gkh0 for ; Mon, 7 Nov 2022 03:40:19 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5H763VS1z4GxK for ; Mon, 7 Nov 2022 03:40:18 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 2A73e4Ru053844; Sun, 6 Nov 2022 19:40:11 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sun, 06 Nov 2022 19:40:03 -0800 From: Chris To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Subject: Re: NVIDIA driver problem In-Reply-To: <43149b5f-8b83-c59-757e-4b4282fb63bc@puchar.net> References: <43149b5f-8b83-c59-757e-4b4282fb63bc@puchar.net> User-Agent: UDNSMS/17.0 Message-ID: X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_7465a00404583dab6490f401eaad3f76" X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4N5H763VS1z4GxK X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-ThisMailContainsUnwantedMimeParts: N --=_7465a00404583dab6490f401eaad3f76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-11-06 14:47, Wojciech Puchar wrote: > i have one on laptop > > build nvidia-driver-390 > > it loads fine (kldload nvidia-modeset.ko) > > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms > 390.154 Wed Jun 22 04:42:19 UTC 2022 > > > i configured Xorg as for a guide. no xorg.conf > > in xorg.conf.d file nvidia-driver.conf > > https://forums.freebsd.org/threads/howto-setup-xorg-with-nvidias-driver.52311/ > > Xorg doesn't start. It loads nvidia driver for Xorg but just says no screen > found. > > How can i diagnose a problem? The first place to start is /var/log/Xorg.0.log. It should dump some pretty informative information that should explain why Xorg(1) doesn't think it find a screen. :-) Almost all my rigs use the Nvidia driver. I have found that only sometimes I must also add the BusID: BusID "PCI:0:13:0" Otherwise after loading nvidia, X seems to do it's job. Here's mine, in case it provides any help: # /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf Section "Device" Identifier "Card0" Driver "nvidia" # BusID "PCI:0:13:0" EndSection --chris --=_7465a00404583dab6490f401eaad3f76 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_7465a00404583dab6490f401eaad3f76-- From nobody Mon Nov 7 21:01:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5kFH5g15z4gNLS for ; Mon, 7 Nov 2022 21:02:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5kFG4DsLz4Cr2 for ; Mon, 7 Nov 2022 21:02:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ed1-x535.google.com with SMTP id f7so19551151edc.6 for ; Mon, 07 Nov 2022 13:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y5bKVrEZavtsaBAa4oX+uI717O9Vozn4qBcLzWnB4wg=; b=Xk1sd5B6uuTJs8mYAZfFKLVcqQLGtGIliAJ9fSv9McKJR72+71mNcqYnUVHnU5D4pQ ifm8V6iwN55rjhxwf90plvRnXU/zlbZkxZv1hVXKw8SRhrbqQSmFso3zPLjC6oaJdFXw UbHwYt28hHHr0odB6XpxN/89kPI79zJZK0sBh2TAtaG6J6z+EfIsG4TeFbqUjYC5hZlB IQ4Y5XCLLzOwswqgI/kzv/35oeeUQG+RtBsFQbP3zCStNnPyT2A34v5fxke7w1D8d3pH Npzui7JH2JjlCSy+YxzijnbsOf0/Tdyv13gXd9R3/8VCtV4tbKqGOBt7IvxGV8YTMTnj 4XaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y5bKVrEZavtsaBAa4oX+uI717O9Vozn4qBcLzWnB4wg=; b=BPt7tb5X8Ys57snpjfiQ2AIA487c93EBAcderzJBQC1e5D768clpWIPui55iiwfdYR YL5eYiC11NkO/WddehUlpX+ypcRCXVpSWSK8ZEjPL8y7dLqFZidEeEaVQWqQvBYJ27l4 nt16WTJ3iIk04vHj97Bqqm7mrywKYm/YzMIgjt4Lj8Llyun+RY/kyJ1ed5Xtes549NpT BeZltODJfPCzmkWhasIjfYQrr+nm9qlgTcJ9oerRwlof5iBgvZhLOoq/zK3Z4Jv9bwaA B3Y7qLdAW0S45OQ4Y8poELtjCJovgdMoMo622jX5kyfrDRXiQ39M+dhfrdOjsW/R75Kw U5pw== X-Gm-Message-State: ANoB5pmfqDXJxhUFBGlhxPqJkEPUoxlJWjXrWswlM2Z5gmmPm1HjisUi /zFdXLFo8rs0vS/aSLaAHoP/Z0o7RJfnGw3TFo5G/yWzxLE= X-Google-Smtp-Source: AA0mqf7x3K9GonhUjqAlx+SzpCIWjBmNgWsT4LsdrzNET1jHJNh/hsC33qFG0HfrIXgg0En6zFZouecJYewv2frsJfg= X-Received: by 2002:a50:9e42:0:b0:466:94e3:5ec9 with SMTP id z60-20020a509e42000000b0046694e35ec9mr1866886ede.173.1667854929055; Mon, 07 Nov 2022 13:02:09 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <8a5a1943-6b3-92fd-17c-473c5b13436@puchar.net> <16589dc-a890-579-c523-db92be5335ce@puchar.net> In-Reply-To: <16589dc-a890-579-c523-db92be5335ce@puchar.net> From: Warner Losh Date: Mon, 7 Nov 2022 14:01:58 -0700 Message-ID: Subject: Re: SSD - trim fails To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000095693605ece7bc26" X-Rspamd-Queue-Id: 4N5kFG4DsLz4Cr2 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Xk1sd5B6; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::535) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::535:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000095693605ece7bc26 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 6, 2022 at 3:44 PM Wojciech Puchar wrote: > > Next, maybe the drive is lying the size of the DSM it will support, but > again, this is a weird > > message to report a request that's too long with. > > > > Maybe it doesn't support queued DSM, despite all appearances to the > contrary from its > > identify tables. Try setting the trem method to DSM_TRIM: > > # sysctl kern.cam.ada.0.delete_method=DSM_TRIM > > should do the trick. At the very least, that will change the command we > send so if it can't > > > this works. but not from /boot/loader.conf > i put it in /etc/rc at beginning so it for sure is done before doing first > trim. > Can you file a bug for this? Also, I'm thinking that maybe this should be the default for these drives, so if you could send me a camcontrol identify for it? Warner --00000000000095693605ece7bc26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 6, 2022 at 3:44 PM Wojcie= ch Puchar <wojtek@puchar.net>= ; wrote:
> Ne= xt, maybe the drive is lying the size of the DSM it will support, but again= , this is a weird
> message to report a request that's too long with.
>
> Maybe it doesn't support queued DSM, despite all appearances to th= e contrary from its
> identify tables. Try setting the trem method to DSM_TRIM:
> # sysctl kern.cam.ada.0.delete_method=3DDSM_TRIM
> should do the trick. At the very least, that will change the command w= e send so if it can't


this works. but not from /boot/loader.conf
i put it in /etc/rc at beginning so it for sure is done before doing first =
trim.

Can you file a bug for this?

Also, I'm thinking that maybe this should be the d= efault for these drives, so if you could
send me a camcontrol ide= ntify for=C2=A0 it?

Warner=C2=A0
--00000000000095693605ece7bc26-- From nobody Mon Nov 7 22:05:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5lfl2Gmmz4gWMM for ; Mon, 7 Nov 2022 22:05:51 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5lfj5RvTz5VKD for ; Mon, 7 Nov 2022 22:05:49 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2A7M5VMT003515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Nov 2022 23:05:31 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1667858731; bh=ZusW63v4mV69sR1ZXVfejLdOiVmmWqUy3en66SQba5w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XkfvVaRNXjLN2DGTaRxYsEMdczyTmsAJ/dl+WbQc2HPkETejt4VKCgP5JtofMw/6o mtYZQufI8GHCvp6JDHGC+jYLYxaXdXMp27XA6QKCDkqTVLmjJ73IIIQRtYP1CmAJce hj1cjb8PCxT53LhyzkA0EKK/1WC9t028hyGIJ97k= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2A7M5UCQ044978; Mon, 7 Nov 2022 23:05:30 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2A7M5UMX044975; Mon, 7 Nov 2022 23:05:30 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Mon, 7 Nov 2022 23:05:30 +0100 (CET) From: Wojciech Puchar To: Chris cc: freebsd-hackers@freebsd.org Subject: Re: NVIDIA driver problem In-Reply-To: Message-ID: <5d1ea4a-9de3-f34b-ad36-b944689be5f7@puchar.net> References: <43149b5f-8b83-c59-757e-4b4282fb63bc@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4N5lfj5RvTz5VKD X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=XkfvVaRN; dmarc=none; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[puchar.net]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N >> >> Xorg doesn't start. It loads nvidia driver for Xorg but just says no screen >> found. >> >> How can i diagnose a problem? > The first place to start is /var/log/Xorg.0.log. > It should dump some pretty informative information that should explain why > Xorg(1) > doesn't think it find a screen. :-) I looked and there is no really any information except no screen found. > Almost all my rigs use the Nvidia driver. I have found that only sometimes I > must > also add the BusID: > BusID "PCI:0:13:0" > Otherwise after loading nvidia, X seems to do it's job. Here's mine, in case > it > provides any help: > I will try > # /usr/local/etc/X11/xorg.conf.d/driver-nvidia.conf > Section "Device" > Identifier "Card0" > Driver "nvidia" > # BusID "PCI:0:13:0" > EndSection > > --chris From nobody Mon Nov 7 23:06:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5n181gnvz4gfTM; Mon, 7 Nov 2022 23:06:52 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5n180lhDz5Yyx; Mon, 7 Nov 2022 23:06:52 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667862412; h=from:from:reply-to:subject:subject:date:date: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=luk7Mdps3nMx07GokwpzHYNjuyHedey6f4FIDF5q4Gs=; b=rUROUC+0ytZFRIa7n2D8K9VaJIR8HYKoje9yQxGK1el5EK8FHoAVGt1cqKAtJ7XuxNZrPD iftv1Af4NmDgNA6UUKLt4zwk6NlVh/kaEun6+RkgOLWn5apIYz4JSHTGjK/89T4OC3ccQY jpMdmUqj0HyYfYD3oEaYSH73kabUhYRD5uIfaTU/P+ut4EcUFic1BzaitbgVXMZ+GFXAVq 9U5iM9UXGT7nyEP+qmD2+XbTFG8UB/tMJP4ZHEfOFY8tDf1EdU9zBt+593uVxad+39aJeY sMAHtNAxg8vgmNvmQvlaMr7Gpb5nWqr6lwVV2p71rrUQNTEpGgz0A+HUKa9RMQ== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4N5n1746ChzfXf; Mon, 7 Nov 2022 23:06:51 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <405b675d-6385-63b8-c8d9-f4e4603cbd09@freebsd.org> Date: Mon, 7 Nov 2022 23:06:49 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: Thank you for the kind and helpful community Content-Language: en-GB To: iio7@tutanota.com References: Cc: FreeBSD hackers , FreeBSD questions From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------DdqhmQGu60qmBgXe2SFa0a3k" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667862412; h=from:from:reply-to:subject:subject:date:date: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=luk7Mdps3nMx07GokwpzHYNjuyHedey6f4FIDF5q4Gs=; b=SvxUnU/xWsL9Du91KNReU4G8iBDMNN0U9BC1kyWU3mLgAsW7e6PBtNMpE+ItDooXYj8GP2 w88Ih6Cuxp8KIXVdJGE287Y6KI8SQjngZcqLz90BSlH51PzFCwnVUKhkXBG0WEiT+//9eP 1oUWHi//Zu9IqKJbjJjyqsha8Pm+SjxFYLfTspYv5z0C4T9G73p/+1Nh/Kpb4p6cA7ud+x qnhrU9gvqNN2G7fWI/DvM7DnOydgZ+P8bR/07l+gErnb3pMrhbOVEGp8kDsqHV7j1Aeglj xBMTLLRkRPViw/yl5ogcPz6yBdp0EPOh2pWt/0AhWSv6ZylrLonBoORFBOWHLg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667862412; a=rsa-sha256; cv=none; b=cqYxijBV/jRvfm9YP91Dv4UJuVzeMKF9wPiCFMyJv8m2QPvrGteii2QkfAHrcj/xCdGCko XcDKdG/QbsXRhxPu8Xz6WP394KPlqPuEzolz38kITT2HbCLPE87LrJXEeQ63CtIoGY260f AGPHqP+oSLqQlGxgzOA2XQU/uCSQcTq1A0hKdrp19ah9qcjeLVkO2TCvSS87X0VlcdaKlw 4j/+8yne0Q7gjZ7ThQQp9JAH8vKe4Ctqwli+7Ap5QLburCPsvjx6xMHc+0P4xd5HHQApxK 3iqLkgtBUxLrMU4DAz9kjoa85XV1DZ/LweWg9+DoNs/msWbXQeDYe1FqG/4OAQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DdqhmQGu60qmBgXe2SFa0a3k Content-Type: multipart/mixed; boundary="------------2ysmJttz0D4u3DdztGOdj6Ts"; protected-headers="v1" From: Graham Perrin To: iio7@tutanota.com Cc: FreeBSD hackers , FreeBSD questions Message-ID: <405b675d-6385-63b8-c8d9-f4e4603cbd09@freebsd.org> Subject: Re: Thank you for the kind and helpful community References: In-Reply-To: --------------2ysmJttz0D4u3DdztGOdj6Ts Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMDYvMTEvMjAyMiAyMToxNiwgaWlvN0B0dXRhbm90YS5jb20gd3JvdGU6DQo+IEkganVz dCB3YW50IHRvIHNheSB0aGFuayB5b3UgdG8gdGhlIEZyZWVCU0QgY29yZSB0ZWFtLCB0aGUg RnJlZUJTRA0KPiBkZXZlbG9wZXJzLCBhbmQgdGhlIEZyZWVCU0QgY29tbXVuaXR5IGluIGdl bmVyYWwgZm9yIGV2ZXJ5b25lJ3MgcGF0aWVuY2UNCj4gYW5kIGZvciBwcm92aWRpbmcgYSBm cmllbmRseSwgaGVscGZ1bCBhbmQgaW52aXRpbmcgY29tbXVuaXR5LiBJdCBpcw0KPiBoYXJk IHRvIGZpbmQgZWxzZXdoZXJlLg0KPg0KPiBJIGFwb2xvZ2l6ZSBpZiBJIGluIGFueSB3YXkg Y2FtZSBhY3Jvc3MgYXMgYmVpbmcgaW1wb2xpdGUgaW4gbXkNCj4gcXVlc3Rpb25zIGFib3V0 IHRoZSBjb2RlIGNvbW1pdCBwcm9jZWR1cmUgYW5kIHN0YXR1cyBpbiBGcmVlQlNELCB0aGF0 DQo+IHdhcyBOT1QgbXkgaW50ZW50Lg0KPg0KPiBUaGFuayB5b3UuDQo+DQo+IEtpbmQgcmVn YXJkcy4NCg0KDQpUaGFuayB5b3UuDQoNCkZvciByZWZlcmVuY2UsIGhlcmUncyBhbiBlbWFp bCB0aGF0IHByb2JhYmx5IGZhaWxlZCB0byByZWFjaCB0aGUgDQphZGRyZXNzZWUg4oCTIGl0 IHdhcyBuZWl0aGVyIHJldHVybmVkIHRvIHNlbmRlciwgbm9yIGFyY2hpdmVkOiANCjxodHRw czovL3dpa2kuZnJlZWJzZC5vcmcvR3JhaGFtUGVycmluL2VtYWlsP2FjdGlvbj1BdHRhY2hG aWxlJmRvPWdldCZ0YXJnZXQ9TWVzc2FnZS1JRCthMmI0ODczMS02MmMwLWQyZTYtMTM2OS1k ZTQyMGQwMTVmYjYuZW1sPiANCihtZXNzYWdlL3JmYzgyMiwgLmVtbCBmcm9tIFRodW5kZXJi aXJkKS4NCg0KUERGIGFsdGVybmF0aXZlOiANCjxodHRwczovL3dpa2kuZnJlZWJzZC5vcmcv R3JhaGFtUGVycmluL2VtYWlsP2FjdGlvbj1BdHRhY2hGaWxlJmRvPXZpZXcmdGFyZ2V0PU1l c3NhZ2UtSUQrYTJiNDg3MzEtNjJjMC1kMmU2LTEzNjktZGU0MjBkMDE1ZmI2LnBkZj4uDQoN CktpbmQgcmVnYXJkcw0KR3JhaGFtDQo= --------------2ysmJttz0D4u3DdztGOdj6Ts-- --------------DdqhmQGu60qmBgXe2SFa0a3k Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmNpj4kFAwAAAAAACgkQt2dIb0oY1AuU QQ//XGcDzALN1CXZEJDVj+5zlE7XuxM87OjBE5/fAyEZUlAgLvxpjdj+5NBX8Pm42YJ5TQvEUXR0 bg1mXiiCZJVRNUBd/bPgIblyLFd7lY4ecCVCJuhxP2gF3B3LsyDtJz+DJBYIUDKbm3xT5AfiLfkp kBNqZkmRoJhgqry+LzrtuhOFu6aeMNNLe0/GY0ugxmTqMUoxIU9+YubslIBBCgFHP30x7BOE4ZKQ p9mzWr6GocIpe9PHWgNTGOtUU4PA+ArqDlabVYLgMlN5XxKCXgBkjAT1d3IgT/sI4SL7qyMqenTK h5lML7dWA204RWxiJgWWAiuFTFrFfGVpM4avBql4xgZG3U4O2/8MZxUFiaUGa9D6pM0pGgUEynPi K+1558E5V6Hin/SqIi/pNaZ7t7yY987xviXXycQvpbf1NNn6DjmpEQPwMjWXQgzigucQ5qiC28Gz y7umA5M4j/vcE2fBiRht3JdPJ5JzP9CWFqijvHA9jvh8psr39MtZi159LRm0AfRmvUVM9hzDJz+g xfwlRl6W6t7Ie1BvDskcvFHGwbApAOh6dVfzsUZYFVvPOCUnjtAeb6WhfPHa1H5vVCmX+cXuuL8D KnfSIuAe6or6pXYkcVXEISASLGst6bx8i6zSwa8qMBXRa8cWqDe14WcZiObr0/8lqGKNMW/ECzrv NMw= =GWoe -----END PGP SIGNATURE----- --------------DdqhmQGu60qmBgXe2SFa0a3k-- From nobody Tue Nov 8 02:35:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N5sfM1hhQz4h5RH; Tue, 8 Nov 2022 02:35:55 +0000 (UTC) (envelope-from iio7@tutanota.com) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N5sfL2mcCz3bHd; Tue, 8 Nov 2022 02:35:54 +0000 (UTC) (envelope-from iio7@tutanota.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tutanota.com header.s=s1 header.b=ctiezpyC; spf=pass (mx1.freebsd.org: domain of iio7@tutanota.com designates 81.3.6.162 as permitted sender) smtp.mailfrom=iio7@tutanota.com; dmarc=pass (policy=quarantine) header.from=tutanota.com Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w1.tutanota.de (Postfix) with ESMTP id 9EE94FBF9F9; Tue, 8 Nov 2022 02:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1667874951; s=s1; d=tutanota.com; h=From:From:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=wbwtVGj2jfwozYHUsNsLhIKyQYspe7RHkqSi1gEd+lM=; b=ctiezpyCFeVerxQEt5Z/mpprdhD9Rd3vkNlH7Xz/maqeZjgUV/LcMdG4slkVpYte 9ML5++5PmTrTKgEouDZhARR90W7h1mjb3j2THAZzoXjbO2hw5pp8BaUjBAlLiYlBv6N yilb/VeE7s45ddRS1gKtq57Rf2sdxxEsSnEaBFhHBLOkp1TnN7nXYYmObS7rxJCRXYG CMbo+BLz3zx2y4/yw2Kr3gQCMbCZVsbRrfr6oKUzXLA/jnO9Yyq9nWbgFm7mcRoW5Xq 7L2ke9AFXTBK4/vGtpj8d5EU4GaCTeua8HbQsP1nYkLawTWaao+leQClKUBrriY3JbX KTVKLRXspw== Date: Tue, 8 Nov 2022 03:35:51 +0100 (CET) From: iio7@tutanota.com Cc: FreeBSD hackers , FreeBSD questions Message-ID: In-Reply-To: <405b675d-6385-63b8-c8d9-f4e4603cbd09@freebsd.org> References: <405b675d-6385-63b8-c8d9-f4e4603cbd09@freebsd.org> Subject: Re: Thank you for the kind and helpful community List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4N5sfL2mcCz3bHd X-Spamd-Bar: / X-Spamd-Result: default: False [-0.56 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.81)[-0.808]; DMARC_POLICY_ALLOW(-0.50)[tutanota.com,quarantine]; NEURAL_SPAM_MEDIUM(0.24)[0.245]; R_DKIM_ALLOW(-0.20)[tutanota.com:s=s1]; R_SPF_ALLOW(-0.20)[+ip4:81.3.6.160/28]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24679, ipnet:81.3.0.0/18, country:DE]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org]; FROM_NO_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tutanota.com:+]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Nov 7, 2022, 23:06 by grahamperrin@freebsd.org: > On 06/11/2022 21:16, iio7@tutanota.com wrote: > >> I just want to say thank you to the FreeBSD core team, the FreeBSD >> developers, and the FreeBSD community in general for everyone's patience >> and for providing a friendly, helpful and inviting community. It is >> hard to find elsewhere. >> >> I apologize if I in any way came across as being impolite in my >> questions about the code commit procedure and status in FreeBSD, that >> was NOT my intent. >> >> Thank you. >> >> Kind regards. >> > > > Thank you. > > For reference, here's an email that probably failed to reach the addresse= e =E2=80=93 it was neither returned to sender, nor archived: (message/rfc822, .eml from T= hunderbird). > > PDF alternative: . > Thank you very much! > Kind regards > Graham > From nobody Tue Nov 8 14:42:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N69mb585Hz4XLh2; Tue, 8 Nov 2022 14:42:23 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N69mb3Mbkz3QjV; Tue, 8 Nov 2022 14:42:23 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 2A8Eg7SX005233 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 8 Nov 2022 09:42:12 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: <620a28b1-4c54-3eb5-2869-f8ecc86345aa@m5p.com> Date: Tue, 8 Nov 2022 09:42:06 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: FreeBSD Security Advisory FreeBSD-SA-22:13.zlib To: freebsd-security@freebsd.org References: <20220830235803.BEF1110B7E@freefall.freebsd.org> Content-Language: en-US From: George Mitchell Cc: FreeBSD Hackers In-Reply-To: <20220830235803.BEF1110B7E@freefall.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=10.0 tests=HELO_NO_DOMAIN,NICE_REPLY_A, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mattapan.m5p.com X-Rspamd-Queue-Id: 4N69mb3Mbkz3QjV X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[freebsd]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US] X-ThisMailContainsUnwantedMimeParts: N On 8/30/22 19:58, FreeBSD Security Advisories wrote: > [four extremely delayed security notifications] It appears they all got hung up in mail queues on the machine named mlmmj.nyi.freebsd.org, arriving on that machine on August 9 in three cases and August 30 in the fourth. Fortunately, notifications from the daily security run on my machine alerted me, though I was quite puzzled at the time to not see corresponding messages from the mailing list. Their delayed arrival now makes me suspect that this was not an intentional policy decision. Does anyone know what's up? -- George From nobody Tue Nov 8 14:56:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6B4S18fYz4XNgV; Tue, 8 Nov 2022 14:56:08 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 4N6B4R0jJgz3j1M; Tue, 8 Nov 2022 14:56:07 +0000 (UTC) (envelope-from rb@gid.co.uk) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk; dmarc=none Received: from smtpclient.apple (gw.br-thn-01.caladan.net.uk [80.71.4.65] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 2A8Eu5Gn091971; Tue, 8 Nov 2022 14:56:05 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-22:13.zlib From: Bob Bishop In-Reply-To: <620a28b1-4c54-3eb5-2869-f8ecc86345aa@m5p.com> Date: Tue, 8 Nov 2022 14:56:05 +0000 Cc: "freebsd-security@freebsd.org" , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <28957C58-7FD0-42DE-9395-13C02BB59240@gid.co.uk> References: <20220830235803.BEF1110B7E@freefall.freebsd.org> <620a28b1-4c54-3eb5-2869-f8ecc86345aa@m5p.com> To: George Mitchell X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org,freebsd-security@FreeBSD.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[gid.co.uk]; TAGGED_RCPT(0.00)[freebsd]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4N6B4R0jJgz3j1M X-ThisMailContainsUnwantedMimeParts: N Hi, > On 8 Nov 2022, at 14:42, George Mitchell = wrote: >=20 > On 8/30/22 19:58, FreeBSD Security Advisories wrote: >=20 > > [four extremely delayed security notifications] >=20 > It appears they all got hung up in mail queues on the machine named > mlmmj.nyi.freebsd.org, arriving on that machine on August 9 in three > cases and August 30 in the fourth. Fortunately, notifications from > the daily security run on my machine alerted me, though I was quite > puzzled at the time to not see corresponding messages from the mailing > list. Their delayed arrival now makes me suspect that this was not > an intentional policy decision. Does anyone know what's up? > -- George Similarly several hundred messages from bugzilla-noreply@FreeBSD.org = that hit my inbox this morning. -- Bob Bishop rb@gid.co.uk From nobody Tue Nov 8 16:01:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6CXD27xVz4YM2Q; Tue, 8 Nov 2022 16:01:48 +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 4N6CXD1P7Qz3qdw; Tue, 8 Nov 2022 16:01:48 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667923308; h=from:from:reply-to:subject:subject:date:date: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=QRradMcfGu5vSbVxcVitjZpfHvX//vniZuvBso2CU0U=; b=Kd0DfWU96wgZ5VdmxU9k58bSHfA5a5+05x7z9D0n4Q4pm+sYAGu/GexNVk+tvJ021Ye/F8 PxnYEsEy3+HG10nAJVB5gch1xzo0oSxX2a6KwFr9MIxtKcjzljqVbOhpZNBxz2ngL/kT7z KJR3P/r3f1jOp6k92x6BBQtteb2uysvd9/L+zcnNMXrd3n3TZKzzqVT7DiVrjj94oI0BmJ x0RqoWLazM8VmUWK/O82bPQhsvNpvtfUpZgNBa+U+AGWVHTedQ6NYB/4HKt1a02G8p5vng ZZ+If6zmIHydCRgDi6OUticLzN/muwCgIKoWXr7hDNontGtuOxi/vuu/zgEH2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667923308; h=from:from:reply-to:subject:subject:date:date: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=QRradMcfGu5vSbVxcVitjZpfHvX//vniZuvBso2CU0U=; b=wDvaxEl70LYSSP4G+JOlidVzUns10tMyY/Fn3Oymdro4bkp4apQ4hbMIAidwKGd4rxtu38 mAyqfoJOHBSjHHK4rH7/TaEyWblujZAheoo24VW+VjXlyH9vcnsWo1ruOpFFfAuBC0ORFq w3lyn+Hw3gNQ1dCAFKMC8JdmM2DzxzrA/OX0RTHBDkb5AupLbH6FNLbJ0HLBgDXiZBW4+l /966XduFOVdgp3EZCvxHV+DMUR2AxS/r6bVPj9lCOhhN9CA0VrnKxk+3lGtopMgnXHnjL3 d4fwkSVqPbF+4DhhjpMEoS/P/0v/uD/SmeVzBSTztCTw0vCIrABGnvTtya1w2w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667923308; a=rsa-sha256; cv=none; b=jn4ffRHezXPCwYO81eUplsSdYx1n64wNjdmC1SK7ovwU6C5ft3+0FNwJyy0wIUp//Uw8ww /3U/cDKlD7O0MpCbNAOzCH1ZAc9+jSwPC9BGKlhQX+olAlIqkX3GG/04Nrwiph+MAXIpHo Y266szc57KNbN5J++FyMzX1BaJLR7DApdlxZVXSQzePBLGFlZDhLjpilmxzBQ1DuxQzlK+ ZvQfAmu5Rr36GylTr2M1yiTq4hE6XYSMZNu7l+Jlzc//3FfDIE2+BjkT0lmo8u150HKfxn AzA3heHHw1EG14aUT1LfdYRJBcNOzg1KvOg62wR/GEiIDQp/KuDUJL9YtghGJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4N6CXC6r7Fz111f; Tue, 8 Nov 2022 16:01:47 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id BA8741B4747; Tue, 8 Nov 2022 17:01:45 +0100 (CET) Date: Tue, 8 Nov 2022 17:01:45 +0100 From: Baptiste Daroussin To: Bob Bishop Cc: George Mitchell , "freebsd-security@freebsd.org" , FreeBSD Hackers Subject: Re: FreeBSD Security Advisory FreeBSD-SA-22:13.zlib Message-ID: <20221108160145.xcoacbo7ohdxyyc3@aniel.nours.eu> References: <20220830235803.BEF1110B7E@freefall.freebsd.org> <620a28b1-4c54-3eb5-2869-f8ecc86345aa@m5p.com> <28957C58-7FD0-42DE-9395-13C02BB59240@gid.co.uk> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28957C58-7FD0-42DE-9395-13C02BB59240@gid.co.uk> X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 08, 2022 at 02:56:05PM +0000, Bob Bishop wrote: > Hi, > > > On 8 Nov 2022, at 14:42, George Mitchell wrote: > > > > On 8/30/22 19:58, FreeBSD Security Advisories wrote: > > > > > [four extremely delayed security notifications] > > > > It appears they all got hung up in mail queues on the machine named > > mlmmj.nyi.freebsd.org, arriving on that machine on August 9 in three > > cases and August 30 in the fourth. Fortunately, notifications from > > the daily security run on my machine alerted me, though I was quite > > puzzled at the time to not see corresponding messages from the mailing > > list. Their delayed arrival now makes me suspect that this was not > > an intentional policy decision. Does anyone know what's up? > > -- George > > Similarly several hundred messages from bugzilla-noreply@FreeBSD.org that hit my inbox this morning. We were hit by a bug fixed in https://www.postfix.org/announcements/postfix-3.7.3.html Mails which have been piling have been flushed today. Best regards, Bapt From nobody Tue Nov 8 16:11:35 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6ClW6b68z4YNfd for ; Tue, 8 Nov 2022 16:11:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6ClW4Th6z3tvZ for ; Tue, 8 Nov 2022 16:11:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667923895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gODry2t4/h9wr4m9AXdbvvoVTc2VUOSml99I547vVPM=; b=oow/VpXos1KOQ6zAvcf4/8HIDluCwyphPbVcuTpPc0jOkcelwvbVrlZulBE1TEIgulZGtd bvQ/LMZ4RuSYF/yhzZ6iYNFTZeG6lAOoGeDW3nCPoIh4Ef5VKYE2z+uhQz7H2h+zGirV7G 7Enw3DQ0L1bCSpmSQMFBh7ErOSdCOAJa6U+WBuvr16DW8gqxGCRfvoW9RTLB3bT080KjmQ IaUHnQunD3l/UjQdBzbjXEoAm4Uqg40KZPuGkOG81Wzo33MegSmbxz2kCZK8rFD0kxzWOm IsiIoA1DJcTz38X9hRh2J3Gx8qf02Q5wJhPTyA9bqM/9okdz4Z8xrMysD3zG+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667923895; a=rsa-sha256; cv=none; b=UNmkRqzf88Qdx2o5ubXV0UPDUfvPpIJGMrONWnTSOwI3gvl0JUvLXkLL1VscY+S1P3Vwlf TLgfIZTTMzZvaNLM3MejCezGongpzA+QMHJgIFAI6cjuLHHgEW5Q0wmM4QdZkqjMmQ9GYZ e0KxDPA0Cp0sEl6E0X2j/tZNIKP+fF8NGmC7EOfHRSDjYCBYVk3TVOvdwXkA+hOo1kSBm3 A6TBzz3yvF3BYhC4VSRYhJJK8t3AOaB6tsDFDPS/6K6oCRNIqe+M8Twzg3WHxhLZd5+uaY rC0j6ify1KZIuDao4HlJ3gP8FfCYK9+MPVEoLZRgx4wYOYRrxGh+013YMyY3ig== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4N6ClW3YP7zp6w for ; Tue, 8 Nov 2022 16:11:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 2A8GBZi5022511 for ; Tue, 8 Nov 2022 16:11:35 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2A8GBZG6022510 for hackers@FreeBSD.org; Tue, 8 Nov 2022 16:11:35 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 47286] [request] make device probing verbose when using boot -v Date: Tue, 08 Nov 2022 16:11:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fernape@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D47286 Fernando Apestegu=C3=ADa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fernape@FreeBSD.org Summary|[request] [patch] make |[request] make device |device probing verbose when |probing verbose when using |using boot -v |boot -v --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Nov 8 17:13:29 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6F6y1Hftz4Yb3j for ; Tue, 8 Nov 2022 17:13:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6F6x6p6Nz46vD for ; Tue, 8 Nov 2022 17:13:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1667927610; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=20ZxhQJ9ONynKhMyI1PkDN1TUdzzP+3G5EKscr7m2rI=; b=sGsj1mcN6bXBvcM9562212xt6Uk0J4+R8ZxbI9AX7vvqtufgBmEmQA94SIjAKjSDiG8Emr eNCnPf5kw1EZfS8MrSfPwBM+vQGSVqJ2nrnuNCM3Fs5BiC9zDe2vPI5W7pTO1pq58EHkW6 gz6lcbfyE4q1lwxv+5UcnVBXkKpWd4bIWf2H2b++MqtWckQTqXerNrJHBCqu+4BZppcJsA GN4k15pqckFmDQF9V86PCfvppn2DLXEfcssTY0uAtFrMGr8OSsSg1Hr5FDPPreOJu+Wo45 4g/ByhRWKM1qq5c/ireIc6mn0lM/NujueXqw5SYKqtcKeVaAewSEwV5LYAtj+g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1667927610; a=rsa-sha256; cv=none; b=KVKBnQte7GhMz8fQCBjLFImjctGBynik/1/3WWSszUgEEBU8Q2/kshxB1KMdI98V/9urEZ iEPnrI61e8RogY6CV95UZFXzmdT19L8Zi34Fij1LMiYrzfsfPGYHMIUK21dEB/YgLM+ahp Xik0rrfAKHsdEow/hOPZrGsirj+2H+IX9BDGbZoDKRs9/41gXUMYDcIJvnOzg6i+VuE63O 5er1f5ETOo+TsD9Jc6xFhARrPd6KxPfK/MxULWVcGXfhnikK95BiIGwLmPpNYk1cEbzYc7 Mc+xNJRDAlvfKYwf9KPhcnBN/oJbNLY9zlq6w0e66I1MzpVo9+3JTw5C1gzyHg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4N6F6x5s9qzqkL for ; Tue, 8 Nov 2022 17:13:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 2A8HDTwX034636 for ; Tue, 8 Nov 2022 17:13:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2A8HDTHW034635 for hackers@FreeBSD.org; Tue, 8 Nov 2022 17:13:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: hackers@FreeBSD.org Subject: [Bug 47286] [request] make device probing verbose when using boot -v Date: Tue, 08 Nov 2022 17:13:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: fernape@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: fernape@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D47286 Fernando Apestegu=C3=ADa changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed Assignee|bugs@FreeBSD.org |fernape@FreeBSD.org Resolution|--- |FIXED --- Comment #5 from Fernando Apestegu=C3=ADa --- Closing. vwe@ is not an src committer anymore. In addition, there are other messages when booting in verbose mode. --=20 You are receiving this mail because: You are on the CC list for the bug.= From nobody Tue Nov 8 20:38:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N6Kgv6JK3z4YX5j for ; Tue, 8 Nov 2022 20:38:51 +0000 (UTC) (envelope-from dan@langille.org) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N6Kgt3dLlz3C83 for ; Tue, 8 Nov 2022 20:38:50 +0000 (UTC) (envelope-from dan@langille.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=langille.org header.s=fm1 header.b="f fDhGr9"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=T60uB+lQ; spf=pass (mx1.freebsd.org: domain of dan@langille.org designates 64.147.123.21 as permitted sender) smtp.mailfrom=dan@langille.org; dmarc=pass (policy=none) header.from=langille.org Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E835B32009AD for ; Tue, 8 Nov 2022 15:38:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 08 Nov 2022 15:38:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=langille.org; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1667939928; x= 1668026328; bh=LUfNXBN/wMKPm+oTpEA7hTls7E8D24Zg4XXUsEWvY7g=; b=f fDhGr9rBUzSC/S08vBUbKNz9vQINxzWZqmsWFjNZ3Rtw+LD4fROu9i6RcJeG6BCm kJ4CRnZqn97tTwwpOl3Z8lwZc3jG+DKbPH0Lcz4wOM9RaQVYAjI3Ed+5vIihc0OC 783LbsCFH0x0hSm2qQEKB+z6weNaSrycNso0YTUhYXkaq7jJHQBa2KBBt4RM+gfo l8HgVOorhK089L+5pxMpdjhxXOVpgiHapgZDR5RBLmS0lEn/dmQvNAKaMUH8UUn4 2WAecBC+UosxpkPESLdJO1JA45uqYbKEYwcMW+gxHRM0WMDpyZ6ziSnqgJMXw/LT ACEm8aODe/5u5HexXl2dA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1667939928; x=1668026328; bh=L UfNXBN/wMKPm+oTpEA7hTls7E8D24Zg4XXUsEWvY7g=; b=T60uB+lQ14n1qW79Y dkBM32SrSEr83X6cSXKwKIajsNQS/cKMpREElVLvnR5vUID90FIqHtMquCa4qtom 8iJXv4AqoyLPz+npBTEcNTvb/ZdVCjrPOItJChIO9H0ahGCAmRf9SLaf7/u7eQRn h9Evy9pGwBfJdmZZIYtNhi5zlmNb7uvwXr7cjGxtUaL75eQm+57JpoHiyDS5MASf XNPYyVTr+jD+RAc9AeMtlkX6Pg4ONsH/mOxsPr1J549scsb/HWt31hzi2h5dZISq mM342anAuGBVvXSznM8CdMs+bKatjQmQ/klXhmGQ2q+sgWU83uhoicWkkLXUucVi DVlAA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepffgrnhcu nfgrnhhgihhllhgvuceouggrnheslhgrnhhgihhllhgvrdhorhhgqeenucggtffrrghtth gvrhhnpeelveehvedutdduueejhfejtdeihfegkeeutdevhefhhfehtdekffdvieegteei udenucffohhmrghinhepfhhrvggvsghsugdrohhrghdpphhoshhtfhhigidrohhrghdplh grnhhgihhllhgvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepuggrnheslhgrnhhgihhllhgvrdhorhhg X-ME-Proxy: Feedback-ID: ifbf9424e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 8 Nov 2022 15:38:48 -0500 (EST) Subject: Re: FreeBSD Security Advisory FreeBSD-SA-22:13.zlib To: FreeBSD Hackers References: <20220830235803.BEF1110B7E@freefall.freebsd.org> <620a28b1-4c54-3eb5-2869-f8ecc86345aa@m5p.com> <28957C58-7FD0-42DE-9395-13C02BB59240@gid.co.uk> <20221108160145.xcoacbo7ohdxyyc3@aniel.nours.eu> From: Dan Langille Message-ID: <29dcbc26-3628-ad3c-3a11-890604f22454@langille.org> Date: Tue, 8 Nov 2022 15:38:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.58 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 In-Reply-To: <20221108160145.xcoacbo7ohdxyyc3@aniel.nours.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[langille.org,none]; R_DKIM_ALLOW(-0.20)[langille.org:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[langille.org:+,messagingengine.com:+]; RCVD_COUNT_THREE(0.00)[4]; MID_RHS_MATCH_FROM(0.00)[]; FREEFALL_USER(0.00)[dan]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4N6Kgt3dLlz3C83 X-ThisMailContainsUnwantedMimeParts: N Baptiste Daroussin wrote on 11/8/22 11:01 AM: > On Tue, Nov 08, 2022 at 02:56:05PM +0000, Bob Bishop wrote: >> Hi, >> >>> On 8 Nov 2022, at 14:42, George Mitchell wrote: >>> >>> On 8/30/22 19:58, FreeBSD Security Advisories wrote: >>> >>>> [four extremely delayed security notifications] >>> It appears they all got hung up in mail queues on the machine named >>> mlmmj.nyi.freebsd.org, arriving on that machine on August 9 in three >>> cases and August 30 in the fourth. Fortunately, notifications from >>> the daily security run on my machine alerted me, though I was quite >>> puzzled at the time to not see corresponding messages from the mailing >>> list. Their delayed arrival now makes me suspect that this was not >>> an intentional policy decision. Does anyone know what's up? >>> -- George >> Similarly several hundred messages from bugzilla-noreply@FreeBSD.org that hit my inbox this morning. > We were hit by a bug fixed in > https://www.postfix.org/announcements/postfix-3.7.3.html > > Mails which have been piling have been flushed today. This explains why some of my hosts had updates waiting for them and some of them did not. :) -- Dan Langille dan@langille.org : https://langille.org/ From nobody Thu Nov 10 06:18:02 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N7BTv4jsdz4f6dR for ; Thu, 10 Nov 2022 06:18:11 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N7BTq2nRhz4LNW for ; Thu, 10 Nov 2022 06:18:07 +0000 (UTC) (envelope-from crb@chrisbowman.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=chrisbowman-com.20210112.gappssmtp.com header.s=20210112 header.b=TPtWNgZI; spf=none (mx1.freebsd.org: domain of crb@chrisbowman.com has no SPF policy when checking 2607:f8b0:4864:20::430) smtp.mailfrom=crb@chrisbowman.com; dmarc=none Received: by mail-pf1-x430.google.com with SMTP id b29so975588pfp.13 for ; Wed, 09 Nov 2022 22:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=1u5FFgpFHIanLOnqo/0YLkw7LmUspUZpj3eTML268i4=; b=TPtWNgZIDh/3AhhIWU5a6gM+B3aPtZ9WJ/hf90gwXqZlUsSiQPuqzmk7F28fnCfmev YFq1zJyc1DP4CqyxjPcfW1eZQ/PeENPNAaFEPAepLBWzZK/k/Df2pokjfI5ryH7DGLSj +fH7+LzBXyv08qKDKPLKRkgiWNJexyPj4OOyBMOw0GuINZ/+iqoERVsuqwRtf4TXmPx6 ujkj46kxFug/rQJToBfhkC/G53H1ppKYQdNneI4rz6VvbsXiBaFpGg2AHiQzOKJLKi/X AZt2iyeYXPquAq/q15C4Q79VRrIAcTYnryHeU/JIajmKkHrZ9HmGKR7FH5YYeduEpKtU GXvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1u5FFgpFHIanLOnqo/0YLkw7LmUspUZpj3eTML268i4=; b=JygACxsiBLBK35e+Zvbp3eGoTU8m/UJ/w0GqhZxKq11z8id+Th56Ph5CVud/Eu6iOO LAprpr4hWhqWLnAW7rEjdIWjOlsViIrwmED4Oi/gZ4uYxElI7QvgjEAtZ9oeoY/B1Joi KDU6Qhbkl97MwH4C0PrKyr11DfNNrT88+LSC849nfv3KhxOey2QBLs0JR1WkjE2srbp7 rjfgD1yiI4wyHU4cNeCDqWYPUPJF8nXRaUFoog4IYgmW97fvebjwToN+Twd1ZJgIehFt 9liJoQkY1NEB02xAUKa0DqcDVqXLVOPZQAUDIBckXRxgMY2ut1gK++n/s0QwRtdSpEMA olaA== X-Gm-Message-State: ACrzQf1VFxwVNAl+Mf41izUerE84pZtlLJxa84L0mcYUJr8Xhls3Za17 2TX7uL0zEFQPG4Nw0T0rtXi4W90u+M4dZigz X-Google-Smtp-Source: AMsMyM5Z6WpLnCsG/FBBdTvsAsjt43MXCWTSJ90b4PReQ7w62EQcTB+qhSLkB1IwCfk3J/Qp3A84ow== X-Received: by 2002:a65:5206:0:b0:462:644c:87ff with SMTP id o6-20020a655206000000b00462644c87ffmr1889856pgp.552.1668061085100; Wed, 09 Nov 2022 22:18:05 -0800 (PST) Received: from smtpclient.apple ([2600:1700:5430:10b1:f53e:9382:8311:a0f0]) by smtp.gmail.com with ESMTPSA id iw3-20020a170903044300b00186c3727294sm10160163plb.270.2022.11.09.22.18.04 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2022 22:18:04 -0800 (PST) From: Christopher Bowman Content-Type: multipart/alternative; boundary="Apple-Mail=_2483E1C2-56D4-4603-A76A-F869C386CB20" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: I could use some help Message-Id: Date: Wed, 9 Nov 2022 22:18:02 -0800 To: hackers@freebsd.org X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[chrisbowman-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::430:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[chrisbowman-com.20210112.gappssmtp.com:+]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[chrisbowman.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4N7BTq2nRhz4LNW X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_2483E1C2-56D4-4603-A76A-F869C386CB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK I=E2=80=99m really confused and I could use some help: 13.0 runs fine on my Xilinx Zynq based board (DIgilent Arty Z20). = However when I compile 13.1 release it doesn=E2=80=99t boot. The kernel = stops during boot as follows: Using DTB from loaded file '/boot/dtb/zynq-artyz7.dtb'. Loading DTB overlays: 'artyz7_ssd_overlay.dtb' /boot/dtb/overlays/artyz7_ssd_overlay.dtb size=3D0x1a1 Kernel entry at 0x17a00200... Kernel args: (null) applying DTB overlay '/boot/dtb/overlays/artyz7_ssd_overlay.dtb' WARNING: Cannot find freebsd,dts-version property, cannot check DTB = compliance ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 .The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-STABLE #22 n248064-ce9c3848ff3: Wed Nov 9 22:04:45 PST = 2022 crb@eclipse.ChrisBowman.com:/usr/obj/usr/src/arm.armv7/sys/ARTYZ7 = arm FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) CPU Features:=20 Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk Optional instructions:=20 UMULL, SMULL, SIMD(ext) LoUU:2 LoC:2 LoUIS:2=20 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory =3D 536866816 (511 MB) avail memory =3D 515162112 (491 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: unblocking device. random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 l2cache0: mem 0xf8f02000-0xf8f02fff irq 8 on = simplebus1 l2cache0: cannot allocate IRQ, not using interrupt l2cache0: Part number: 0x3, release: 0x8 l2cache0: L2 Cache enabled: 512KB/32B 8 ways gic0: mem = 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1 gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 mp_tmr0: mem 0xf8f00200-0xf8f0021f irq 29 on = simplebus1 Timecounter "MPCore" frequency 50000000 Hz quality 800 mp_tmr1: mem 0xf8f00600-0xf8f0061f irq 36 on = simplebus1 Event timer "MPCore" frequency 50000000 Hz quality 1000 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 uart0: mem 0xe0000000-0xe0000fff irq 9 on simplebus1 uart0: console (-1,n,8,1) zy7_qspi0: mem 0xe000d000-0xe000dfff = irq 13 on simplebus1 zy7_qspi0: must have ref-clock property device_attach: zy7_qspi0 attach returned 6 cgem0: mem = 0xe000b000-0xe000bfff irq 15 on simplebus1 miibus0: on cgem0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: Ethernet address: 56:99:3e:50:9a:8e sdhci_fdt0: mem = 0xe0100000-0xe0100fff irq 17 on simplebus1 sdhci_fdt0: 1 slot(s) allocated mmc0: on sdhci_fdt0 zy7_devcfg0: mem 0xf8007000-0xf80070ff irq 28 on = simplebus1 Timecounters tick every 1.000 msec sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0202 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The controller register dumps continue for a while and then I get: mmc0: CMD7 failed, RESULT: 1 Release APs Trying to mount root from ufs:/dev/mmcsd0s2a [rw]... mountroot: waiting for device /dev/mmcsd0s2a... Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Trying to mount root from ufs:mmcsd0s2a []... mountroot: waiting for device mmcsd0s2a... Mounting from ufs:mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=3Drw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot>=20 If I replace the kernel with a 13.0 kernel, it boots just fine. So I go and do a git bisect between release/13.0.0 and release/13.1.0 and I get the following: git bisect start '--first-parent' # status: waiting for both good and bad commits # good: [ea31abc261ffc01b6ff5671bffb15cf910a07f4b] 13.0: update to = RELEASE git bisect good ea31abc261ffc01b6ff5671bffb15cf910a07f4b # status: waiting for bad commit, 1 good commit known # bad: [fc952ac2212b121aa6eefc273f5960ec3e0a466d] Update in preparation = of 13.1-RELEASE git bisect bad fc952ac2212b121aa6eefc273f5960ec3e0a466d # skip: [4c44dbde5491516eba8725dc51d39c1dcc817472] MFC jail: Handle a = parent jail when a child is added to it git bisect skip 4c44dbde5491516eba8725dc51d39c1dcc817472 # good: [476f87219f408343846254743c7189076be80c04] wpi: Fix a lock leak = in an error path in wpi_run() git bisect good 476f87219f408343846254743c7189076be80c04 # bad: [05bf7d68c56830e52dee14dc87c07d6716e8195e] aesni: Fix an = out-of-bounds read in AES_GCM_decrypt() git bisect bad 05bf7d68c56830e52dee14dc87c07d6716e8195e # good: [014ae00ef6edca2687d618e0bda138086a1e1230] date: Capitalize = seconds string in synopses git bisect good 014ae00ef6edca2687d618e0bda138086a1e1230 # bad: [08d995ca8f6f1008a10e4bf4d924824c040f842a] swapoff_one(): only = check free pages count manually turning swap off git bisect bad 08d995ca8f6f1008a10e4bf4d924824c040f842a # bad: [81b6dba1a08b031bdf7463c1704d27ae1e0daa0f] ktls: Fix assertion = for TLS 1.0 CBC when using non-zero starting seqno. git bisect bad 81b6dba1a08b031bdf7463c1704d27ae1e0daa0f # bad: [67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1] net80211: add a = driver-private pointer to struct ieee80211_node git bisect bad 67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1 # good: [109330155000bfec215ee39148254d2a0b628798] module(9): Document = that evhand can be NULL git bisect good 109330155000bfec215ee39148254d2a0b628798 # bad: [4c8e29637456bbbe709425f691f637914658009f] LinuxKPI: add = module_pci_driver() and pci_alloc_irq_vectors() git bisect bad 4c8e29637456bbbe709425f691f637914658009f # bad: [4a03ae8d17ddf3d3b57ca281000fd98e200b92cc] nfscl: Fix use after = free for forced dismount git bisect bad 4a03ae8d17ddf3d3b57ca281000fd98e200b92cc # bad: [de957de097857fabb69a59a9ba36276c5e735de5] bhyve: Fix the = WITH_BHYVE_SNAPSHOT build git bisect bad de957de097857fabb69a59a9ba36276c5e735de5 # bad: [5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391] hwpmc: initialize = arm64 counter/interrupt state git bisect bad 5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391 # bad: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling of = reserves in zone_import() git bisect bad ce9c3848ff369467749f59fd24f8b9f1241e725c # good: [d5ebaa6f8f850bb6f6273f01386832efcb295827] uma: Improve = M_USE_RESERVE handling in keg_fetch_slab() git bisect good d5ebaa6f8f850bb6f6273f01386832efcb295827 # first bad commit: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix = handling of reserves in zone_import() If I do git log ce9c3848ff369467749f59fd24f8b9f1241e725c it does seem = that d5ebaa6f8f850bb6f6273f01386832efcb295827 is the previous commit and = that it works just fine but ce9c3848ff369467749f59fd24f8b9f1241e725c = doesn=E2=80=99t boot. It=E2=80=99s literally the same file system and = DTB, the only difference is the kernel installed. What=E2=80=99s confusing to me is that looking at = ce9c3848ff369467749f59fd24f8b9f1241e725c I can=E2=80=99t see how that = commit would result in my kernel hanging while booting. I=E2=80=99m clearly not an expert and I=E2=80=99m not sure I used git = bisect right but I think I did. Maybe I need to be on stable/13 when I = bisect? I don=E2=80=99t know and if anyone could give me some pointers I=E2=80=99m= happy to do some leg work but I=E2=80=99ve about come to the end of my = road trying to figure out what=E2=80=99s blocking me. Thanks in advance, Christopher= --Apple-Mail=_2483E1C2-56D4-4603-A76A-F869C386CB20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OK = I=E2=80=99m really confused and I could use some help:

13.0 runs fine on my Xilinx Zynq based = board (DIgilent Arty Z20).  However when I compile 13.1 release it = doesn=E2=80=99t boot.  The kernel stops during boot as = follows:

Using DTB from loaded file = '/boot/dtb/zynq-artyz7.dtb'.


Loading DTB overlays: 'artyz7_ssd_overlay.dtb'


/boot/dtb/overlays/artyz7_ssd_overlay.dtb = size=3D0x1a1

Kernel entry at = 0x17a00200...


Kernel args: = (null)


applying DTB overlay = '/boot/dtb/overlays/artyz7_ssd_overlay.dtb'


WARNING: Cannot find freebsd,dts-version property, cannot = check DTB compliance
---<<BOOT>>---
Copyright (c) = 1992-2021 The FreeBSD Project.
Copyright (c) 1979, = 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
.The Regents of the University of California. All rights = reserved.
FreeBSD is a registered trademark of The = FreeBSD Foundation.
FreeBSD 13.0-STABLE #22 = n248064-ce9c3848ff3: Wed Nov  9 22:04:45 PST 2022
    crb@eclipse.ChrisBowman.com:/usr/obj/usr/src/arm.armv7/sys/= ARTYZ7 arm
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe)
CPU: ARM Cortex-A9 = r3p0 (ECO: 0x00000000)
CPU = Features: 
  Multiprocessing, Thumb2, = Security, VMSAv7, Coherent Walk
Optional = instructions: 
  UMULL, SMULL, = SIMD(ext)
LoUU:2 LoC:2 LoUIS:2 
Cache level 1:
 32KB/32B 4-way data = cache WB Read-Alloc Write-Alloc
 32KB/32B = 4-way instruction cache Read-Alloc
real memory =  =3D 536866816 (511 MB)
avail memory =3D = 515162112 (491 MB)
FreeBSD/SMP: Multiprocessor = System Detected: 2 CPUs
random: unblocking = device.
random: entropy device external = interface
ofwbus0: <Open Firmware Device = Tree>
simplebus0: <Flattened device tree = simple bus> on ofwbus0
simplebus1: <Flattened = device tree simple bus> on ofwbus0
l2cache0: = <PL310 L2 cache controller> mem 0xf8f02000-0xf8f02fff irq 8 on = simplebus1
l2cache0: cannot allocate IRQ, not using = interrupt
l2cache0: Part number: 0x3, release: = 0x8
l2cache0: L2 Cache enabled: 512KB/32B 8 = ways
gic0: <ARM Generic Interrupt Controller> = mem 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1
gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs = 96
mp_tmr0: <ARM MPCore Timers> mem = 0xf8f00200-0xf8f0021f irq 29 on simplebus1
Timecounter "MPCore" frequency 50000000 Hz quality = 800
mp_tmr1: <ARM MPCore Timers> mem = 0xf8f00600-0xf8f0061f irq 36 on simplebus1
Event = timer "MPCore" frequency 50000000 Hz quality 1000
cpulist0: <Open Firmware CPU Group> on = ofwbus0
cpu0: <Open Firmware CPU> on = cpulist0
cpu1: <Open Firmware CPU> on = cpulist0
uart0: <Cadence UART> mem = 0xe0000000-0xe0000fff irq 9 on simplebus1
uart0: = console (-1,n,8,1)
zy7_qspi0: <Zynq Quad-SPI = Flash Controller> mem 0xe000d000-0xe000dfff irq 13 on = simplebus1
zy7_qspi0: must have ref-clock = property
device_attach: zy7_qspi0 attach returned = 6
cgem0: <Cadence CGEM Gigabit Ethernet = Interface> mem 0xe000b000-0xe000bfff irq 15 on simplebus1
miibus0: <MII bus> on cgem0
rgephy0:= <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 0 on = miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, = 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, = auto
rgephy1: <RTL8169S/8110S/8211 1000BASE-T = media interface> PHY 1 on miibus0
rgephy1: =  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto
cgem0: = Ethernet address: 56:99:3e:50:9a:8e
sdhci_fdt0: = <Zynq-7000 generic fdt SDHCI controller> mem 0xe0100000-0xe0100fff = irq 17 on simplebus1
sdhci_fdt0: 1 slot(s) = allocated
mmc0: <MMC/SD bus> on = sdhci_fdt0
zy7_devcfg0: <Zynq devcfg block> = mem 0xf8007000-0xf80070ff irq 28 on simplebus1
Timecounters tick every 1.000 msec
sdhci_fdt0-slot0: Controller timeout
sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: =  0x00008901
sdhci_fdt0-slot0: Blk size: = 0x00005008 | Blk cnt:  0x00000001
sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: = 0x00000013
sdhci_fdt0-slot0: Present: =  0x01ff0202 | Host ctl: 0x00000001
sdhci_fdt0-slot0: Power:    0x0000000f | Blk gap: =  0x00000000
sdhci_fdt0-slot0: Wake-up: =  0x00000000 | Clock:    0x00004007
sdhci_fdt0-slot0: Timeout:  0x00000006 | Int stat: = 0x00000001
sdhci_fdt0-slot0: Int enab: 0x01ff00fb | = Sig enab: 0x01ff00fa
sdhci_fdt0-slot0: AC12 err: = 0x00000000 | Host ctl2:0x00000000
sdhci_fdt0-slot0: = Caps:     0x69ec0080 | Caps2:   =  0x00000000
sdhci_fdt0-slot0: Max curr: = 0x00000001 | ADMA err: 0x00000000
sdhci_fdt0-slot0: = ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_fdt0-slot0: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_fdt0-slot0: Controller timeout
sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = REGISTER DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: =  0x00008901
sdhci_fdt0-slot0: Blk size: = 0x00005008 | Blk cnt:  0x00000001
sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: = 0x00000013
sdhci_fdt0-slot0: Present: =  0x01ff0000 | Host ctl: 0x00000001
sdhci_fdt0-slot0: Power:    0x0000000f | Blk gap: =  0x00000000
sdhci_fdt0-slot0: Wake-up: =  0x00000000 | Clock:    0x00004007
sdhci_fdt0-slot0: Timeout:  0x00000006 | Int stat: = 0x00000001
sdhci_fdt0-slot0: Int enab: 0x01ff00fb | = Sig enab: 0x01ff00fa
sdhci_fdt0-slot0: AC12 err: = 0x00000000 | Host ctl2:0x00000000
sdhci_fdt0-slot0: = Caps:     0x69ec0080 | Caps2:   =  0x00000000
sdhci_fdt0-slot0: Max curr: = 0x00000001 | ADMA err: 0x00000000
sdhci_fdt0-slot0: = ADMA addr:0x00000000 | Slot int: 0x00000000
sdhci_fdt0-slot0: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The controller register = dumps continue for a while and then I get:

mmc0: CMD7 failed, = RESULT: 1
Release APs
Trying = to mount root from ufs:/dev/mmcsd0s2a [rw]...
mountroot: waiting for device /dev/mmcsd0s2a...
Mounting from ufs:/dev/mmcsd0s2a failed with error = 19.
Trying to mount root from ufs:mmcsd0s2a = []...
mountroot: waiting for device = mmcsd0s2a...
Mounting from ufs:mmcsd0s2a failed = with error 19.

Loader variables:
  = vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a
  = vfs.root.mountfrom.options=3Drw

Manual root filesystem = specification:
  <fstype>:<device> = [options]
      Mount <device> = using filesystem <fstype>
    =   and with the specified (optional) option list.

    eg. = ufs:/dev/da0s1a
        = zfs:zroot/ROOT/default
        = cd9660:/dev/cd0 ro
        =   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 = /)

  ? =               List valid disk boot = devices
  .           =     Yield 1 second (for background tasks)
  <empty line>    Abort manual = input

mountroot> 

If I replace the kernel with a 13.0 = kernel, it boots just fine.

So I go and do a git bisect between release/13.0.0 and = release/13.1.0

and I get the following:

git bisect start = '--first-parent'
# status: waiting for both good and bad = commits
# good: = [ea31abc261ffc01b6ff5671bffb15cf910a07f4b] 13.0: update to = RELEASE
git = bisect good ea31abc261ffc01b6ff5671bffb15cf910a07f4b
# = status: waiting for bad commit, 1 good commit known
# bad: = [fc952ac2212b121aa6eefc273f5960ec3e0a466d] Update in preparation of = 13.1-RELEASE
git bisect bad = fc952ac2212b121aa6eefc273f5960ec3e0a466d
# skip: = [4c44dbde5491516eba8725dc51d39c1dcc817472] MFC jail: Handle a parent = jail when a child is added to it
git bisect skip = 4c44dbde5491516eba8725dc51d39c1dcc817472
# good: = [476f87219f408343846254743c7189076be80c04] wpi: Fix a lock leak in an = error path in wpi_run()
git bisect good = 476f87219f408343846254743c7189076be80c04
# bad: = [05bf7d68c56830e52dee14dc87c07d6716e8195e] aesni: Fix an out-of-bounds = read in AES_GCM_decrypt()
git bisect bad = 05bf7d68c56830e52dee14dc87c07d6716e8195e
# good: = [014ae00ef6edca2687d618e0bda138086a1e1230] date: Capitalize seconds = string in synopses
git bisect good = 014ae00ef6edca2687d618e0bda138086a1e1230
# bad: = [08d995ca8f6f1008a10e4bf4d924824c040f842a] swapoff_one(): only check = free pages count manually turning swap off
git = bisect bad 08d995ca8f6f1008a10e4bf4d924824c040f842a
# bad: = [81b6dba1a08b031bdf7463c1704d27ae1e0daa0f] ktls: Fix assertion for TLS = 1.0 CBC when using non-zero starting seqno.
git = bisect bad 81b6dba1a08b031bdf7463c1704d27ae1e0daa0f
# bad: = [67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1] net80211: add a = driver-private pointer to struct ieee80211_node
git = bisect bad 67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1
# good: = [109330155000bfec215ee39148254d2a0b628798] module(9): Document that = evhand can be NULL
git bisect good = 109330155000bfec215ee39148254d2a0b628798
# bad: = [4c8e29637456bbbe709425f691f637914658009f] LinuxKPI: add = module_pci_driver() and pci_alloc_irq_vectors()
git = bisect bad 4c8e29637456bbbe709425f691f637914658009f
# bad: = [4a03ae8d17ddf3d3b57ca281000fd98e200b92cc] nfscl: Fix use after free for = forced dismount
git bisect bad = 4a03ae8d17ddf3d3b57ca281000fd98e200b92cc
# bad: = [de957de097857fabb69a59a9ba36276c5e735de5] bhyve: Fix the = WITH_BHYVE_SNAPSHOT build
git bisect bad = de957de097857fabb69a59a9ba36276c5e735de5
# bad: = [5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391] hwpmc: initialize arm64 = counter/interrupt state
git bisect bad = 5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391
# bad: = [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling of reserves = in zone_import()
git bisect bad = ce9c3848ff369467749f59fd24f8b9f1241e725c
# good: = [d5ebaa6f8f850bb6f6273f01386832efcb295827] uma: Improve M_USE_RESERVE = handling in keg_fetch_slab()
git bisect good = d5ebaa6f8f850bb6f6273f01386832efcb295827
# first bad commit: = [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling of reserves = in zone_import()

If I do git log = ce9c3848ff369467749f59fd24f8b9f1241e725c it does seem = that d5ebaa6f8f850bb6f6273f01386832efcb295827 is the previous = commit and that it works just fine but ce9c3848ff369467749f59fd24f8b9f1241e725c doesn=E2=80=99t = boot.  It=E2=80=99s literally the same file system and DTB, the = only difference is the kernel installed.

What=E2=80=99s confusing to me is that = looking at ce9c3848ff369467749f59fd24f8b9f1241e725c I can=E2=80=99t see = how that commit would result in my kernel hanging while = booting.

I=E2=80=99m clearly not an expert and I=E2=80=99m not = sure I used git bisect right but I think I did.  Maybe I need to be = on stable/13 = when I bisect?

I don=E2=80=99t know and if anyone could give me some = pointers I=E2=80=99m happy to do some leg work but I=E2=80=99ve about = come to the end of my road trying to figure out what=E2=80=99s blocking = me.

Thanks in advance,
Christopher
= --Apple-Mail=_2483E1C2-56D4-4603-A76A-F869C386CB20-- From nobody Thu Nov 10 09:50:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N7HC35wkyz4XLC1 for ; Thu, 10 Nov 2022 09:50:39 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2114.outbound.protection.outlook.com [40.107.117.114]) (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 4N7HBz2fzyz3l0M for ; Thu, 10 Nov 2022 09:50:35 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=gBCGqC9p; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.117.114 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a4A2mbe+HVGBuRpWraLIB9F5742Wmbyka66QuU/aEut9X/wIG/v1sCvfFv1fcVmobRac71O+QyRueb7wpu6xpEJpt4auMICZ8yrqY+qkikUF47JHHVlnBTpiqOtIjNwAtFy8UngTSV0bq1FTB7lf+8AaWlqFE6FtovISiZlYz4FFGuf+fAnU0VylYUYFwOpr2EoijDPEFP1SN5Rb7Gnr+/NJQEYkcblNBoRvHTt/MeDPfcjrESehgLVim+DDxtLKAJV6lK3WsRXVg1Ikl3noX9ZzoJlxr8S/24VEsXfDNAevTJHfe+QwiJ4a10mvXSpMCU+/eqvV0M9Pjms5gefseg== 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=TT4wKzXJJVHOFs7nPsnzCeBvoYGfQSsExwGR4bvsjUE=; b=IlAdhK806n7AGvaDjj3Cn+8xP15wl1JksvOLT26SwweI2NVu6q/XT0nxkKp+l52yZUC1x9bbCufhgzc6bwf3ssO5iiTehEwnVHRA8w3ZvHg+expbLjjpTAuCoDkVi5Adl84Vx0bpcw6OIgN5WnpBLRuWhSRLG+ABDH9GyJYMpO/SR0kLKk0ThWYyzosJgZzqXhnR6lXBq09L/IbKqJUyGhvMDBhWUGEo+Oeavu6dLsVB1j4UwqQ2vDjYDMBbD2HxThFkHlHyqdkAwzzwuGRQIZ/hK58DL4uGoOK6Z31e7zj6V8b0zjPgPZi8QEJtRp3Rgwo7c4ekzG804z7gtYGKNg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TT4wKzXJJVHOFs7nPsnzCeBvoYGfQSsExwGR4bvsjUE=; b=gBCGqC9piX7Rk9pVQCUEiQfDFdLMZD7NdkMAiJuKYdS3LRMKwn+nDGCykBs070U3gBEc5YnXgO6f5s91HcS9LfPmb0BRD9p8NnQI1FAdJAXsZPiB7U+DFaQ0C44OtzVpHSM7Oaa66YuimRTnX6qIjG11TzMt7FJHYGEcqbDDecs= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by PUZP153MB0697.APCP153.PROD.OUTLOOK.COM (2603:1096:301:e6::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.2; Thu, 10 Nov 2022 09:50:23 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%7]) with mapi id 15.20.5834.002; Thu, 10 Nov 2022 09:50:23 +0000 From: Souradeep Chakrabarti To: Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK431MhQ Date: Thu, 10 Nov 2022 09:50:22 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> In-Reply-To: <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ab148fee-181b-4470-92e7-040225231c6b;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-11-10T07:56:13Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|PUZP153MB0697:EE_ x-ms-office365-filtering-correlation-id: 062547e0-cefa-4b72-cdf1-08dac300fc66 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZBbs8KXEXkE619sr80IXqQdJhZbGxF5OYedWQMioyfaD8/5MXKnFI4fp0sFO1QTlk2lONcZrIlNBTPZjNH41aP/BVyTmTVrBqhPdpgpbMLoVVSvXneSeV7kTFCVADE3UtDdKwTKPoJrwxs4cFWYZMW6Q+9FuaWBxd5QLs+JA2KgcJ7K0q0NtSHeC8cMSFAWZM0jMfJ4u/z+Sioh+4ZZNcxh0lPKiobc0pd6CRyGtq6BiiDYpQPbG18f3KsFxiWYQHESnea07YJxfMOQ4Xc8uiSF/6OFxMjBv5Ur6vA3XcMwteKilZbsRvpJPZf1+IhpRpX0ofCfpkry25Sp3FBdc/VuAgHMDqFAFtF1H1yTlrmZqL9atEGU2HX2RlhNiycuZxaXVGUS/IVK6O6AFG6r9GoUZpBPW9N5mThL/ORaTGIMGCa2P2PfftGkxlk8VFrD9FcEuidGfEQr/6zbNyXuJPMyqLtQaMWSffLpYy9j+r3umOnU9poQE13II5f9ll0xTYChGbqJA18hXaYo0IEDRSllg4hUysOJhuKfPS5JhDlID1WCASaorQVPVblOWh3eJnESp+RknZLMz4PnvYxgdVRYMHBrV5jUI8hS29ksVDjUthY9AXgM7BSZR7pG0GxCmy+vxrSc3SpjQSZh/0lS/YydVNGgk3tE4vo+4CQ5Lw3lsTvWjMVq2/WCRuifmZXTGLY/4ObWgzvRPhuMmg5nRVFDGCcZ1MrYrHy7tTW5ymO/gZSvOcaM1Ed2sA6R0V7zaeG0me5piHMvLZg/BJ7UDb1ZMS6t2lCjZrd7IxCi8vVgOGs25aqLb3QXdy6rAl1I3 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(376002)(396003)(39860400002)(346002)(366004)(451199015)(54906003)(41300700001)(478600001)(86362001)(4326008)(55016003)(71200400001)(6506007)(2906002)(82950400001)(53546011)(33656002)(38100700002)(82960400001)(38070700005)(66946007)(122000001)(26005)(83380400001)(10290500003)(316002)(52536014)(9686003)(186003)(64756008)(66446008)(8676002)(76116006)(6916009)(66556008)(66476007)(8990500004)(7696005)(5660300002)(8936002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bzVVNThrSEJZTEpVYlVDMGkzU0V2aU4raXlLOWpTRkJFRDBoeTBoWkxrdk5K?= =?utf-8?B?RDJ1UStmQXovclJkdEllWFdSNVZiMHJlUTNYOEFPc3RSY1JRN2FMRWxKNHhQ?= =?utf-8?B?SkcvTm1yR0tyVGdQMGI2cUlkbnpaTTRONFEzWUd1YTNscjAvMHFhZ3dkbDZa?= =?utf-8?B?MTd4dnpGbUQ0UmtpdHo1UCtlMi9ZZmhpVUkxTUNDdlI3bGxReFBoZkQ4N25z?= =?utf-8?B?c1Badi9JalN5amtRbnUvSkl3ckVnSzBnMjhSTStINWtLMGtoL1dVdHRsMmNp?= =?utf-8?B?M25XZzZmTXRBaFFiM3NLT25IeFh0VnAyUWQyaTF2d2FBWi9JYzFEdzlrQjBv?= =?utf-8?B?SHByN01OZFVuNlZNMk5QV0ljKzh5eGR0Ym5FU0x2OHc0ZWZzT1p5TWVyR2xH?= =?utf-8?B?RzlkK2xEV1JMcDRQejJubjl6U245NUZWSHJvWWtOWm8wbm00OXF1cjNoV0lQ?= =?utf-8?B?dGs0VUZPSXNpUk1DTEJxQllQbEFlQXFxVXgxYncxZjRET2pkb0RRS3hQbE1x?= =?utf-8?B?ZkkwL3QyUXlZSkIxeEVPWU5JQmp0K2c3RHpRUjNkV2pSbjU4NTNyNVlnbTg5?= =?utf-8?B?eGQ3b0ZnVGswbEY5bklYVXB5UklwR3FGUmhzSGRHcHcvYXZsbTZZUGY2Z1RX?= =?utf-8?B?cms5ZEJybHZScU5UU3NlUDJURkdPK2l4U2JVL28rMTBhNjhqOTVGVzZlcytO?= =?utf-8?B?a1VjVWlzUW1WdkxJeU1TdjRrcWV1cHlRd0JqT2tnNXkyUnRaWTB1NjkyVWhM?= =?utf-8?B?ZytSUlNCQTJtd1hnd3ZDcG0vODhSUDVFZGtsRjQ0T25WWXNUdmV0ZGRNaElz?= =?utf-8?B?SVhyQm54NE5CMWtnbUNRcFQ5THErTU5IQTQ2VjJoY0V0QTVJbEp2UXdZcnkr?= =?utf-8?B?Zm1vSzZLcVNva1JnYVRoeFFVdkkyWVpsWEpFK3krVWZVUVg0d3ZKemVzeFhp?= =?utf-8?B?cVNjYTdpSXRJRnhOcG5Xb2lremJOVkVLRHZSa0J6NXlSejY0cXptK09MTDRk?= =?utf-8?B?cFQyTW1ISlpoK1Bzd1NVMGRyZGZacFZKMHNpRDBRMmo3UTRVNHZjY2tsQ0ww?= =?utf-8?B?N2FJOUNBTzI5Vnl5Tit2ZXRhSzhMd2h5MW8vZHJPWEhuZmZxdHhtY0xhR0hy?= =?utf-8?B?RmtKU29YT3Z3OUl6ZktVY1pLakt2cDJ6b3BIUU5BT2FadnJwcVFUY3lYVmdQ?= =?utf-8?B?OS95YldKYUZoNjdKTEdaTUtZY2NHRkNxalRmeHFSM080ZmFiQ0NNVUIyK1dx?= =?utf-8?B?UWRTbE1aMTZzbFJMSm5sYTVjTE5HOUxkMk9zRStnZGZscGVCeGxNNy9ROC9j?= =?utf-8?B?TEk2T2x6UnBTcmlVcHlqaWh4SHlQUC9XQm5RZVViSmx2T2dhTnpSZjlham9B?= =?utf-8?B?TWdSVlo4VEtsWC9HdkM2VXM0LzE2cjBic0lOZ0JtUkVsQmk3SzE1cWdhS21l?= =?utf-8?B?OVJtZ2NVZkF4MExicTBFTVQ3eHM5dWhjMEVscEJCaS8zazFtYWhYMUJMNUhK?= =?utf-8?B?a1lTSnNobGhxSW5hVGxMWVZ4R01yTUdHR29jNzJGam05VUV0a1JqQzZmekJR?= =?utf-8?B?UkhORm5lNCtZYTlNVjl1MzhtM3hPQ1ZvSWo3WDMzRVVuVnBWNGNHZzd4WVJt?= =?utf-8?B?WlpKdERwN0x6b1BmendjZXlxbHg2VTJ1TkZEUjJDb0g2QmZlMW40emlUbFZi?= =?utf-8?B?eXM0bGNrVVdzdU9JdEx3eW5uaTg1Q1o4WU1yekFOTUpuenZzRzV1YVFQcTJ1?= =?utf-8?B?RjhIdktTUWtwTEdJY0MyMzBnSE9yLy9ldjFNT2JvdWl3ckQxMFN5d3Z1RldH?= =?utf-8?B?MTFpazQ4Rm5ZVVd0em5UTS82a2JPNXFjbmsxZVM5QWlQK0x2cytqOGJFWmV5?= =?utf-8?B?SWl4VjhVM0pwdHJHL0ZqT0dkUC8rSXFMd0xuV3FXQkRWNjE2cHlOeUg4Z0RE?= =?utf-8?B?Um8yeFJwbjdFN3pDb2ZiM2drUldmUStYaTBXU245REthekNDenNaTm1ob2dP?= =?utf-8?B?S1pNUm84dFpPODFOY3ovSmJ0MUZsUkRBSDlwOUdZQzVXNjFRbXN1cFgwZFpq?= =?utf-8?B?RFBRM3o1Q3hXb2NNaUd4V2hHR1JLTGk1ckpyQT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 062547e0-cefa-4b72-cdf1-08dac300fc66 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2022 09:50:22.8202 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FpPMII0Off7xSOJp815ITD4o9bLsqyl0gxkkYjdc9tf5/nZJQGGs5j27xpzAYAdQhvGg/fwc1NxV7BHu58NQgTwBRJ2sUEJ7Gmxc0rSqXFA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PUZP153MB0697 X-Spamd-Bar: --------- X-Spamd-Result: default: False [-9.90 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.117.114:from]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.117.114:from] X-Rspamd-Queue-Id: 4N7HBz2fzyz3l0M X-ThisMailContainsUnwantedMimeParts: N DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgVHVybmVy IDxhbmRyZXdAZnViYXIuZ2Vlay5uej4NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDMsIDIw MjIgNjoyMSBQTQ0KPiBUbzogU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3JhYmFydGlAbWlj cm9zb2Z0LmNvbT4NCj4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47IFdlaSBIdSA8 d2VoQG1pY3Jvc29mdC5jb20+OyBmcmVlYnNkLQ0KPiBoYWNrZXJzQEZyZWVCU0Qub3JnDQo+IFN1 YmplY3Q6IFJlOiBbRVhURVJOQUxdIHBjaWIgbXNpeCBhbGxvY2F0aW9uIGluIGFybTY0DQo+IA0K PiBIaSBTb3VyYWRlZXAsDQo+IA0KPiBGb3IgdGhlIHZtYnVzX3BjaWIgZHJpdmVyIHlvdeKAmWxs IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBwY2liX2FsbG9jX21zaSwNCj4gcGNpYl9yZWxlYXNlX21z aSwgYW5kIHRoZSBtc2l4IHZlcnNpb25zLCBhbmQgcGNpYl9tYXBfbXNpLg0KPiANCj4gRm9yIGFs bG9jIGFuZCByZWxlYXNlIHlvdSBjYW4ganVzdCBjYWxsIGludG8gdGhlIHNhbWUgaW50cl8qIGZ1 bmN0aW9uIGFzDQo+IHBjaV9ob3N0X2dlbmVyaWNfYWNwaS5jLiBZb3XigJlsbCBuZWVkIHRvIHBh c3MgaW4gdGhlIHhyZWYgZm9yIHRoZSBpbnRlcnJ1cHQNCj4gY29udHJvbGxlci4gSXQgbmVlZHMg dG8gYmUgdGhlIHhyZWYgdGhlIE1TSSBjb250cm9sbGVyIHJlZ2lzdGVyZWQuIEZvciB0aGUgR0lD djJtDQo+IGl04oCZcyBBQ1BJX01TSV9YUkVGLg0KPiANCltTb3VyYWRlZXBdIA0KSSBoYXZlIHVz ZWQgZm9sbG93aW5nIGluIHZtYnVzX3BjaWIuYyA6DQpyZXQgPSBpbnRyX2FsbG9jX21zaXgocGNp YiwgZGV2LCBBQ1BJX01TSV9YUkVGLCBpcnEpOw0KQnV0IGl0IGlzIGZhaWxpbmcgaW4gcGljX2xv b2t1cCgpIHdpdGggRVNSQ0ggYnkgbm90IGZpbmRpbmcgcGljIHdpdGggQUNQSV9NU0lfWFJFRi4N CkRvIEkgbmVlZCB0byBkbyBhbnl0aGluZyBmb3IgcGljX2xvb2t1cCgpIHRvIGJlIHN1Y2Nlc3Nm dWw/DQoNCj4gRm9yIHBjaWJfbWFwX21zaSBJIGFtIHVuc3VyZSBpZiB0aGUgY3VycmVudCBjb2Rl IGlzIHZhbGlkIG9uIGFybTY0LiBJZiBub3QgeW914oCZbGwNCj4gbmVlZCB0byBjYWxsIGludHJf bWFwX21zaS4NCj4gDQo+IEFuZHJldw0KPiANCj4gPiBPbiAyIE5vdiAyMDIyLCBhdCAyMjoyNywg U291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gd3Jv dGU6DQo+ID4NCj4gPiBIaSBBbmRyZXcsDQo+ID4gVGhhbmtzIGZvciB0aGUgcmVwbHkuIFJlZ2Fy ZGluZyBnZW5lcmljX3BjaWVfYWNwaV9hbGxvY19tc2l4KCApLCBpdA0KPiA+IGNhbiBiZSBjYWxs ZWQgaWYgdGhlIFBDSSBkZXZpY2UgaXMgY2hpbGQgb2YgdGhlIGdlbmVyaWMgcGNpYiAoDQo+IERS SVZFUl9NT0RVTEUocGNpYiwgYWNwaSwgZ2VuZXJpY19wY2llX2FjcGlfZHJpdmVyLCAwLCAwKSAu DQo+ID4gQnV0IGlmIHRoZSBQQ0kgZGV2aWNlIGlzIGNvbW11bmljYXRpbmcgd2l0aCBhIGRpZmZl cmVudCBwY2liIGRyaXZlcg0KPiA+IChsaWtlIHZtYnVzX3BjaWIpLCBpbiB0aGF0IGNhc2UgZG8g d2UgbmVlZCB0byBpbXBsZW1lbnQgYWxsIHRoZXNlIGZ1bmN0aW9ucyBvZg0KPiBwY2lfaG9zdF9n ZW5lcmljX2FjcGkuYyA/DQo+ID4NCj4gPiBPciB0aGVyZSBhcmUgc29tZSB3YXlzIHRvIHJldXNl IHRoZW0/DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog QW5kcmV3IFR1cm5lciA8YW5kcmV3QGZ1YmFyLmdlZWsubno+DQo+ID4+IFNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMiwgMjAyMiA2OjU0IFBNDQo+ID4+IFRvOiBTb3VyYWRlZXAgQ2hha3JhYmFy dGkgPHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tPg0KPiA+PiBDYzogV2FybmVyIExvc2ggPGlt cEBic2RpbXAuY29tPjsgV2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT47DQo+ID4+IGZyZWVic2Qt IGhhY2tlcnNARnJlZUJTRC5vcmcNCj4gPj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogcGNpYiBt c2l4IGFsbG9jYXRpb24gaW4gYXJtNjQNCj4gPj4NCj4gPj4NCj4gPj4+IE9uIDIgTm92IDIwMjIs IGF0IDEyOjU2LCBTb3VyYWRlZXAgQ2hha3JhYmFydGkNCj4gPj4+IDxzY2hha3JhYmFydGlAbWlj cm9zb2Z0LmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGksDQo+ID4+PiBJIGNhbiBz ZWUgaW4geDg2IG5leHVzLmMgaGFzIGltcGxlbWVudGVkIHBjaWJfYWxsb2NfbXNpeCB1c2luZw0K PiA+PiBuZXh1c19hbGxvY19tc2l4KCkuDQo+ID4+PiBXaGljaCBjYWxscyBtc2l4X2FsbG9jKCkg Zm9yIG1zaXggYWxsb2NhdGlvbi4NCj4gPj4+DQo+ID4+PiBCdXQgaW4gY2FzZSBvZiBhcm02NCBJ IGRvbid0IGZpbmQgc2ltaWxhciBwY2liX2FsbG9jX21zaXgNCj4gPj4+IGltcGxlbWVudGF0aW9u IGluDQo+ID4+IG5leHVzLmMgLg0KPiA+Pj4gU28sIG9uIGFybTY0IHdoYXQgaXMgY29ycmVjdCB3 YXkgdG8gZ2V0IGFsbG9jYXRlIG1zaXggPw0KPiA+Pg0KPiA+PiBGb3IgYW4gYXJtNjQgc3lzdGVt IHdpdGggQUNQSSBpdCBpcyBtb3N0IGxpa2VseSBoYW5kbGVkIGluDQo+ID4+IGdlbmVyaWNfcGNp ZV9hY3BpX3JlbGVhc2VfbXNpeC4gRm9yIEZEVCBpdCBjYW4gZGVwZW5kIG9uIHdoaWNoIFBDSQ0K PiA+PiBkcml2ZXIgaXMgdXNlZC4NCj4gPj4NCj4gPj4gSW4gZWl0aGVyIGNhc2UgaXQgd2lsbCBj YWxsIGludG8gaW50cl9yZWxlYXNlX21zaXggdGhhdCB0aGVuIGNhbGxzDQo+ID4+IGludG8gdGhl IE1TSSBjb250cm9sbGVyIHRvIGFsbG9jYXRlIHRoZSB2ZWN0b3JzLiBGb3IgYSBHSUN2MyBkcml2 ZXINCj4gPj4gaXQgd2lsbCBlaXRoZXIgYmUgZ2ljdjNfaXRzX2FsbG9jX21zaXggaWYgeW91IGhh dmUgYW4gSVRTIGRldmljZSwgb3INCj4gPj4gZ2ljX3YzX2FsbG9jX21zaXggaWYgdXNpbmcgTUJJ IHJhbmdlcy4NCj4gPj4NCj4gPj4gT24gQUNQSSB3ZSBkb27igJl0IGN1cnJlbnRseSBzdXBwb3J0 IE1CSSByYW5nZXMsIGFsdGhvdWdoIGl0IGxvb2tzIGxpa2UNCj4gPj4gdGhpcyBjb3VsZCBiZSBo YW5kbGVkIGJ5IHRoZSBleGlzdGluZyBnaWN2Mm0gZHJpdmVyLiBUaGlzIGRyaXZlcg0KPiA+PiBz aG91bGQgYWxyZWFkeSB3b3JrIGFzIGEgY2hpbGQgb2YgdGhlIEdJQ3YzLCBob3dldmVyIGl0IGFw cGVhcnMgdG8gYmUNCj4gPj4gRkRUIG9ubHksIHNvIHdpbGwgbmVlZCBzb21lIHdvcmsgdG8gYWRk IEFDUEkgc3VwcG9ydC4NCj4gPj4NCj4gPj4gQW5kcmV3DQo+ID4NCg0K From nobody Thu Nov 10 15:22:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N7QZB2VXpz4XN09 for ; Thu, 10 Nov 2022 15:22:42 +0000 (UTC) (envelope-from andyf@andyit.com.au) Received: from alpine.spintel.net.au (alpine.spintel.net.au [203.23.236.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N7QZ94X4yz3Cld for ; Thu, 10 Nov 2022 15:22:41 +0000 (UTC) (envelope-from andyf@andyit.com.au) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of andyf@andyit.com.au has no SPF policy when checking 203.23.236.77) smtp.mailfrom=andyf@andyit.com.au; dmarc=none Received: from drunkfish.andyit.com.au (unknown [202.87.175.55]) by alpine.spintel.net.au (Postfix) with ESMTPS id ED3D24C2BD9 for ; Fri, 11 Nov 2022 02:22:38 +1100 (AEDT) Received: from [172.22.2.22] (mater.andyit.com.au [172.22.2.22]) by drunkfish.andyit.com.au (8.16.1/8.16.1) with ESMTPS id 2AAFMct3005258 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 11 Nov 2022 01:22:38 +1000 (AEST) (envelope-from andyf@andyit.com.au) Message-ID: Date: Fri, 11 Nov 2022 01:22:39 +1000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 To: "freebsd-hackers+unsubscribe@FreeBSD.org" Content-Language: en-AU From: Andy Farkas Subject: anything Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[203.23.236.77:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:18390, ipnet:203.23.236.0/24, country:AU]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[andyit.com.au]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4N7QZ94X4yz3Cld X-ThisMailContainsUnwantedMimeParts: N -andyf From nobody Fri Nov 11 19:07:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N87WH1RZGz4fgs7 for ; Fri, 11 Nov 2022 19:07:39 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sgaapc01on2131.outbound.protection.outlook.com [40.107.215.131]) (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 4N87WG1RYGz482Q for ; Fri, 11 Nov 2022 19:07:38 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=Ewar6cut; arc=pass ("microsoft.com:s=arcselector9901:i=1"); spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.215.131 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gEDVMWP3o58ZlMd9ikIeleqvFp8fPEJGZsYkiwBEcAcbPC8KM/u+VG5kB7Tj11OmQ3ayn0OxV1quKwW9+B5NQfvCcZYgPSHn6AiowBahKz0UoLbHWS9Wikn6fOy6n26MAKPpZGdWskJmH3twoCMpFDYISxBUzRV5+09H5sQBQzZE5Mumq1CraMeygmUxE4OqlYJ18/7UAQ5MCRrKyDqDqxtEiIGTMJs83/G34zk/NhB/tO0fB6r1TLPUx/71AFrP7HMDp5hkKEvya0LQsE9ZOIdoAE8lD0MwyGehMg3h0WfeZrU+FX1XzT61MUQ8Ki1DdZX4odxHVR83Ud2iXISv4Q== 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=VccMeqCEh0omBNnLcCItHlh+phSY4JWqn6QOhylHYVU=; b=S/WMkMKxhmjgNi+zOamFqdghWrEMqjcXdC2xhwjcWOPxPT4epNnWhxI6CEZ05xrHP8DRIbWu17dLagz2TC62wB25etWH0ygdRQXx3xyRYZliLpQXjeSOr1GRDM4lLxsxkpFDfMX9tvIMzl2FrScWkVbybinbquRnV/kHnzDDaY4y+OBMrj0+NG52IO9HLue7FfirQmDTf35b4TBoZdalopGr7lDjFwCrsvctmEYQodv+BWYAm/GGoe1McBq0XFcmfLMvf488n4isuT6jscweCnT+IPJeEpp9T7I0GY2NIQSlmQXl+NJ5bv219PB+FxFANawCPpyiGR6cjaIlrR80gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VccMeqCEh0omBNnLcCItHlh+phSY4JWqn6QOhylHYVU=; b=Ewar6cutLzPCzSS/fOQgcbr1A5Fbo1hi82XqpDplcTvPG8w/ugqob+NlzssAT30kDsAdfMd4LOvdjkLpYzHxpI5BQWXu/3iDBSk3xLrXnu4EGrUF7G842NUUNC5qYNTmsUo58Je83qW7EJwzj/GVUUEkK9FRWa3kJGFJPMyRn5g= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SI2P153MB0508.APCP153.PROD.OUTLOOK.COM (2603:1096:4:12d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.2; Fri, 11 Nov 2022 19:07:31 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%9]) with mapi id 15.20.5834.005; Fri, 11 Nov 2022 19:07:31 +0000 From: Souradeep Chakrabarti To: Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK431MhQgAJLyNA= Date: Fri, 11 Nov 2022 19:07:31 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ab148fee-181b-4470-92e7-040225231c6b;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-11-10T07:56:13Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0508:EE_ x-ms-office365-filtering-correlation-id: 15c407e8-ae3a-4e98-caef-08dac417fbd6 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2ZXecpD0mtnNCJbisPJOxseLfJ8wTTGib/eJGFlI5t6OElWA1UHfiKR769WDjswkhHSQXWD/zPoTjKImJZynWlUz38mqqOPooOSfIWX3GSKSjJuqsiM7Hd3a7Yqt4xEQmwXvX3cC6nAnUYqsswwYZONiTLH0bOE5dKSk8SJKj+vqmiP9NQh2HGdcXYP58WxnYk+dzR1PKC2WQ6qGGlslhd1deMqprKy9vXxL1Ui26Ym4DHRphrgAbnhN1hBPTjdVnv0RMHfjWu6ue1gOjBl1lHj49F00CyqDcuY5qjy8vxup4Qlsgxxe10VIBgy4xYfiJ6ym1m+jM3YfF2XrRPTBbtpxxGyUF17PfFHHOPrZ/LCIpzQTYy0btodT8OeuZsWz6q1qPZ3sKpQC/4EMe3ViM8cjzM+qD+7blfYYZluHc6XiEgGfXlsYQkApuvOTYQswjpwG8tGH0XAlxgi3jzb6WBqgDZvub7a61KC4vUj/q88SUI+P1iOA9VRqXNfERnZM/myVl2sm3b804vJPoPnLQMHtemQZb058PiiwU83mKrhMEYaJbVpG9VL+bhqY0g03TP4u35IwNTJOVA0q5m8Xv3EY0/YEXdygfB1MRfW4XmhkklLO3npdILjrb3FmqdkH7drBiLCOlQeQFEIIdBwGx6DcIDwMQuNFNBntRJgCoE51KobQeGV+PztbGWo6mJCTxAeZUojIFG/cgawH+0tw840QlgYCpPTwbLmN5vzCFkPnhJmTd5+OisBwMdwubtin9UgL0hjwIK3cIqq9af0Rn9DZbUL5ZNaQ+turU35saULRXughECNwIzAMUpbFta9q x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(451199015)(33656002)(8990500004)(38070700005)(86362001)(54906003)(122000001)(83380400001)(53546011)(55016003)(2906002)(5660300002)(7696005)(82950400001)(6506007)(82960400001)(186003)(9686003)(26005)(38100700002)(76116006)(10290500003)(71200400001)(6916009)(8676002)(4326008)(64756008)(66446008)(52536014)(316002)(66946007)(66556008)(66476007)(478600001)(8936002)(41300700001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?alB6cnJFOFhpQ2RJdkdYK1E5L0E5UXhuZG9yQkV1dHVRSVNwOG4xUlczUTVI?= =?utf-8?B?UGloaWJFbzJ2MVcvdEprYXdLSmVRY0tFbExPaXZaeHhhQWhvUWllUS9GeERr?= =?utf-8?B?Rm1RUmR1c3VLSFZHUDJpdFNJc1JMVkhOdU9PSDVMcHpqZWhZTVU2WG1GOUZo?= =?utf-8?B?Vy8yTCtkWDdRM1llRldjbHAzSlNQZGhmNHZ1R0ZoV3NnVU5oeGJkUnZzcXFr?= =?utf-8?B?WFdZTXN0MDNNOFY3ZDhOSWNDa3E1d09aMFppbWRFUW15UTB2OG5WckU0V3Vn?= =?utf-8?B?Ym9vRFAzOGtPK3RyN05aamd4ajN6T1lFM1U0UlFsTk54cDNFOEdoYnVHcmJW?= =?utf-8?B?dkJ0aytGMUw3QnEvckswa1k5VlE5YUFTTzRtN3FSVlZiaW52RXRMM0l0bTdD?= =?utf-8?B?Zm1ab3RKdTJNSG5aK2U3NElLbmwydld4YTZiM3Z5QnlZOFIxTEFsU1d4LzRH?= =?utf-8?B?K2lXaks4WE5paUZranVUZFYwNlBUVENzdWNpL0hrSzB1WDVXRXNjcjFRTEFV?= =?utf-8?B?RXdXTEE4Yng5T0d2Vmw3NDJLK1o1N3pzREVDNHBxMkozWkJxOHlSb3ZQcXJo?= =?utf-8?B?TFB4V0VDY3BNbWFQcS9mV0tCYk84WWFuMFpIK251R1RYNkRyZjNoSzB3MDFY?= =?utf-8?B?dXR5UWpiQjlGclF5bDFaWVFPZHFYQTQwK2xKaTBZSW1xQkptRVg2V01YdkJB?= =?utf-8?B?UWZiZHR2dXFYN1BaRTc1YUFsci91UGF3cFlhKzRLTWx3R285NUFWaEVxQlJ1?= =?utf-8?B?UVd6cGpTOGcxMnc3bXJGck56b29KZmlDR29jdkRJUzlCcmt1Sml3c0QvR0Rs?= =?utf-8?B?ZEV6S3RhWUVvVnhrcjV0bUp4Tk12SFRybFFZTjdGOWYxbHlzZVYzbERmVnpO?= =?utf-8?B?cGFzZ2RHT2VoYkRCOU1kUk9PVjVsTjZCWWJ6SjhTUllUSXdzZkVDMC9jUHR6?= =?utf-8?B?VmE4OFNuTFhEWlVFK3BGamVGTThRRm9iUWlXYjJHOWdWOXdiZmdGTmtFYTE1?= =?utf-8?B?N2NxY0NhcEttZGl5TTZ6TEp4NGRJSlNwaUpzQlMzZWMwRXVjYzFKanloSk1W?= =?utf-8?B?aC9QWlExd2wrSEs0amtJZmhGblBIODFJdmVjRThQRUErZkkvMm1xK2twWkF2?= =?utf-8?B?VVR3Ykh3WGU4a2FndE1BSnRFckt6N2Z3WTd2Z3BDRVJ2NG9pUEhzaldzUXJr?= =?utf-8?B?bG80Ukt6VTk0Q0JYSmJiQjZrKzVObkVhaUxtcU1JczR0V3lLdExMd3EybmF5?= =?utf-8?B?QUNLdktuVHVzelZsclBqZjVOMFFzcXE2aFRtUytKODBEOXBYY3YzZ0ZmcmVu?= =?utf-8?B?WVNQV3YySU1SU090aVVHVlRCR3RaNTFOYlpLc1lDc2JyVnZGTjdTZlBLU3Fh?= =?utf-8?B?ZlcxRi9aOVNNOG1NbXhuZmNzQS9Pc3N6ZDI3eUZtWDk0R1AzeGZvcXI2TUVj?= =?utf-8?B?SWVZM1p6bFpVaWlxVHo1V1pXQ2YzendwUVNLeEE0UHRpVk1aL3hkY0M4eG5R?= =?utf-8?B?TTFSa1Jjc3gzVHFQeW5ITzk1djNydzkxWkZDeXFzcjFLa0R3VjN6VUFIMXIx?= =?utf-8?B?SGpVQ0diYVM2THJibWJpRjZ6Ky9McVVoRmEvTFArclJyOGpndjlwakQzbytH?= =?utf-8?B?ZkFSQjk5VFBUbkREUlUwVWdaeFdxellkOEJsSVAxU05tUk9UL3paTlluNThu?= =?utf-8?B?ZXd6Tkpyc2c0VTZmTkhnbFJ0RkdUdWM2OG1yTmFCL2tUdkphSmU0REhhRDhr?= =?utf-8?B?WHpuUEoweFg5dWFySWhtN0VVYUZZSmR6M2VSZE5NMnVibUdnSzcvekVGd0po?= =?utf-8?B?ajdxT05sMVlmQ3d5aXJlS2RZL2FnNURpclRHeVd4d3V4THhsY2FOQ09WVnMv?= =?utf-8?B?ZFlpbGZwcGd6c0lVdm5ZeTZPOXEzT0lyTnpwMmJtbzVMTWZkQk4veGJKeDNX?= =?utf-8?B?Z3cwUE1TakxCSlJxQkJFN1hNd3NTUnVRSGlPZ1hNSTA5Umt5SkZsNkZZUzdL?= =?utf-8?B?SzF1L0x6STlmYmIyZ0lJeUVKM2N4bjBlVCtWMy9PK1JuZmxBeksvb1A5ME9X?= =?utf-8?B?b3l2eFlTSTJIZ2FpWDRZNjFXMUgxd0JHaDlKdz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 15c407e8-ae3a-4e98-caef-08dac417fbd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2022 19:07:31.4327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E8JVyma/D5xoPAbSNn3aw+xBUi7uyVoMcE5uWJAbbb7y5wJuComeHXbsW5ffCI09tyYZvYjdkk+M6MVeRjp/f0fsyZUFuL0ckNgEMPaSru8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0508 X-Spamd-Bar: --------- X-Spamd-Result: default: False [-9.90 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MIME_BASE64_TEXT(0.10)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.215.131:from]; RCVD_IN_DNSWL_NONE(0.00)[40.107.215.131:from]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4N87WG1RYGz482Q X-ThisMailContainsUnwantedMimeParts: N DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTb3VyYWRlZXAgQ2hh a3JhYmFydGkNCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDIyIDM6MjAgUE0NCj4g VG86IEFuZHJldyBUdXJuZXIgPGFuZHJld0BmdWJhci5nZWVrLm56Pg0KPiBDYzogV2FybmVyIExv c2ggPGltcEBic2RpbXAuY29tPjsgV2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT47IGZyZWVic2Qt DQo+IGhhY2tlcnNARnJlZUJTRC5vcmcNCj4gU3ViamVjdDogUkU6IFtFWFRFUk5BTF0gcGNpYiBt c2l4IGFsbG9jYXRpb24gaW4gYXJtNjQNCj4gDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBBbmRyZXcgVHVybmVyIDxhbmRyZXdAZnViYXIuZ2Vl ay5uej4NCj4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMywgMjAyMiA2OjIxIFBNDQo+ID4g VG86IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8c2NoYWtyYWJhcnRpQG1pY3Jvc29mdC5jb20+DQo+ ID4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47IFdlaSBIdSA8d2VoQG1pY3Jvc29m dC5jb20+Ow0KPiBmcmVlYnNkLQ0KPiA+IGhhY2tlcnNARnJlZUJTRC5vcmcNCj4gPiBTdWJqZWN0 OiBSZTogW0VYVEVSTkFMXSBwY2liIG1zaXggYWxsb2NhdGlvbiBpbiBhcm02NA0KPiA+DQo+ID4g SGkgU291cmFkZWVwLA0KPiA+DQo+ID4gRm9yIHRoZSB2bWJ1c19wY2liIGRyaXZlciB5b3XigJls bCBuZWVkIHRvIGltcGxlbWVudCB0aGUgcGNpYl9hbGxvY19tc2ksDQo+ID4gcGNpYl9yZWxlYXNl X21zaSwgYW5kIHRoZSBtc2l4IHZlcnNpb25zLCBhbmQgcGNpYl9tYXBfbXNpLg0KPiA+DQo+ID4g Rm9yIGFsbG9jIGFuZCByZWxlYXNlIHlvdSBjYW4ganVzdCBjYWxsIGludG8gdGhlIHNhbWUgaW50 cl8qIGZ1bmN0aW9uDQo+ID4gYXMgcGNpX2hvc3RfZ2VuZXJpY19hY3BpLmMuIFlvdeKAmWxsIG5l ZWQgdG8gcGFzcyBpbiB0aGUgeHJlZiBmb3IgdGhlDQo+ID4gaW50ZXJydXB0IGNvbnRyb2xsZXIu IEl0IG5lZWRzIHRvIGJlIHRoZSB4cmVmIHRoZSBNU0kgY29udHJvbGxlcg0KPiA+IHJlZ2lzdGVy ZWQuIEZvciB0aGUgR0lDdjJtIGl04oCZcyBBQ1BJX01TSV9YUkVGLg0KPiA+DQo+IFtTb3VyYWRl ZXBdDQo+IEkgaGF2ZSB1c2VkIGZvbGxvd2luZyBpbiB2bWJ1c19wY2liLmMgOg0KPiByZXQgPSBp bnRyX2FsbG9jX21zaXgocGNpYiwgZGV2LCBBQ1BJX01TSV9YUkVGLCBpcnEpOyBCdXQgaXQgaXMg ZmFpbGluZyBpbg0KPiBwaWNfbG9va3VwKCkgd2l0aCBFU1JDSCBieSBub3QgZmluZGluZyBwaWMg d2l0aCBBQ1BJX01TSV9YUkVGLg0KPiBEbyBJIG5lZWQgdG8gZG8gYW55dGhpbmcgZm9yIHBpY19s b29rdXAoKSB0byBiZSBzdWNjZXNzZnVsPw0KPiANCltTb3VyYWRlZXBdIA0KSSBmb3VuZCBvdXQg dGhlIHJlYXNvbiBoZXJlIHBpY19sb29rdXAoKSBmb3IgQUNQSV9NU0lfWFJFRiBpcyBmYWlsaW5n LCBhcw0Kd2UgYXJlIG5vdCBjYWxsaW5nIGludHJfbXNpX3JlZ2lzdGVyKCkgYnV0IGludHJfcGlj X3JlZ2lzdGVyKCkgaXMgZ2V0dGluZyBjYWxsZWQgZm9yIHRoZSBQQ0lCLg0KVGhpcyBpcyBiZWNh dXNlIHdlIGRvbid0IGhhdmUgSVRTIGltcGxlbWVudGVkIGluIEh5cGVyLVYuIEluc3RlYWQsIEh5 cGVyLVYgaXMgcHJlc2VudGluZyB0aGUNCk1TSS9NU0ktWCBhcyBTUEkgYmVjYXVzZSBvZiBpdCdz IG93biBsaW1pdGF0aW9uLg0KTGludXggaGFzIHNvbHZlZCBpdCB1c2luZyBjdXN0b20gaXJxY2hp cCBkcml2ZXIgdG8gaGFuZGxlIGl0LiANCkJ1dCBJIGFtIG5vdCBzdXJlIGhvdyB0byBhZGRyZXNz IGl0IGluIEZyZWVCU0QuIA0KQ2FuIHlvdSBwbGVhc2UgcG9pbnQgbWUgb3V0IHNvbWV0aGluZyBo ZXJlPw0KPiA+IEZvciBwY2liX21hcF9tc2kgSSBhbSB1bnN1cmUgaWYgdGhlIGN1cnJlbnQgY29k ZSBpcyB2YWxpZCBvbiBhcm02NC4gSWYNCj4gPiBub3QgeW914oCZbGwgbmVlZCB0byBjYWxsIGlu dHJfbWFwX21zaS4NCj4gPg0KPiA+IEFuZHJldw0KPiA+DQo+ID4gPiBPbiAyIE5vdiAyMDIyLCBh dCAyMjoyNywgU291cmFkZWVwIENoYWtyYWJhcnRpDQo+ID4gPiA8c2NoYWtyYWJhcnRpQG1pY3Jv c29mdC5jb20+DQo+ID4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gSGkgQW5kcmV3LA0KPiA+ID4gVGhh bmtzIGZvciB0aGUgcmVwbHkuIFJlZ2FyZGluZyBnZW5lcmljX3BjaWVfYWNwaV9hbGxvY19tc2l4 KCApLCBpdA0KPiA+ID4gY2FuIGJlIGNhbGxlZCBpZiB0aGUgUENJIGRldmljZSBpcyBjaGlsZCBv ZiB0aGUgZ2VuZXJpYyBwY2liICgNCj4gPiBEUklWRVJfTU9EVUxFKHBjaWIsIGFjcGksIGdlbmVy aWNfcGNpZV9hY3BpX2RyaXZlciwgMCwgMCkgLg0KPiA+ID4gQnV0IGlmIHRoZSBQQ0kgZGV2aWNl IGlzIGNvbW11bmljYXRpbmcgd2l0aCBhIGRpZmZlcmVudCBwY2liIGRyaXZlcg0KPiA+ID4gKGxp a2Ugdm1idXNfcGNpYiksIGluIHRoYXQgY2FzZSBkbyB3ZSBuZWVkIHRvIGltcGxlbWVudCBhbGwg dGhlc2UNCj4gPiA+IGZ1bmN0aW9ucyBvZg0KPiA+IHBjaV9ob3N0X2dlbmVyaWNfYWNwaS5jID8N Cj4gPiA+DQo+ID4gPiBPciB0aGVyZSBhcmUgc29tZSB3YXlzIHRvIHJldXNlIHRoZW0/DQo+ID4g Pg0KPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPj4gRnJvbTogQW5kcmV3 IFR1cm5lciA8YW5kcmV3QGZ1YmFyLmdlZWsubno+DQo+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAyLCAyMDIyIDY6NTQgUE0NCj4gPiA+PiBUbzogU291cmFkZWVwIENoYWtyYWJhcnRp IDxzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gPiA+PiBDYzogV2FybmVyIExvc2ggPGlt cEBic2RpbXAuY29tPjsgV2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT47DQo+ID4gPj4gZnJlZWJz ZC0gaGFja2Vyc0BGcmVlQlNELm9yZw0KPiA+ID4+IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IHBj aWIgbXNpeCBhbGxvY2F0aW9uIGluIGFybTY0DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+PiBPbiAy IE5vdiAyMDIyLCBhdCAxMjo1NiwgU291cmFkZWVwIENoYWtyYWJhcnRpDQo+ID4gPj4+IDxzY2hh a3JhYmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gPiA+PiB3cm90ZToNCj4gPiA+Pj4NCj4gPiA+Pj4g SGksDQo+ID4gPj4+IEkgY2FuIHNlZSBpbiB4ODYgbmV4dXMuYyBoYXMgaW1wbGVtZW50ZWQgcGNp Yl9hbGxvY19tc2l4IHVzaW5nDQo+ID4gPj4gbmV4dXNfYWxsb2NfbXNpeCgpLg0KPiA+ID4+PiBX aGljaCBjYWxscyBtc2l4X2FsbG9jKCkgZm9yIG1zaXggYWxsb2NhdGlvbi4NCj4gPiA+Pj4NCj4g PiA+Pj4gQnV0IGluIGNhc2Ugb2YgYXJtNjQgSSBkb24ndCBmaW5kIHNpbWlsYXIgcGNpYl9hbGxv Y19tc2l4DQo+ID4gPj4+IGltcGxlbWVudGF0aW9uIGluDQo+ID4gPj4gbmV4dXMuYyAuDQo+ID4g Pj4+IFNvLCBvbiBhcm02NCB3aGF0IGlzIGNvcnJlY3Qgd2F5IHRvIGdldCBhbGxvY2F0ZSBtc2l4 ID8NCj4gPiA+Pg0KPiA+ID4+IEZvciBhbiBhcm02NCBzeXN0ZW0gd2l0aCBBQ1BJIGl0IGlzIG1v c3QgbGlrZWx5IGhhbmRsZWQgaW4NCj4gPiA+PiBnZW5lcmljX3BjaWVfYWNwaV9yZWxlYXNlX21z aXguIEZvciBGRFQgaXQgY2FuIGRlcGVuZCBvbiB3aGljaCBQQ0kNCj4gPiA+PiBkcml2ZXIgaXMg dXNlZC4NCj4gPiA+Pg0KPiA+ID4+IEluIGVpdGhlciBjYXNlIGl0IHdpbGwgY2FsbCBpbnRvIGlu dHJfcmVsZWFzZV9tc2l4IHRoYXQgdGhlbiBjYWxscw0KPiA+ID4+IGludG8gdGhlIE1TSSBjb250 cm9sbGVyIHRvIGFsbG9jYXRlIHRoZSB2ZWN0b3JzLiBGb3IgYSBHSUN2MyBkcml2ZXINCj4gPiA+ PiBpdCB3aWxsIGVpdGhlciBiZSBnaWN2M19pdHNfYWxsb2NfbXNpeCBpZiB5b3UgaGF2ZSBhbiBJ VFMgZGV2aWNlLA0KPiA+ID4+IG9yIGdpY192M19hbGxvY19tc2l4IGlmIHVzaW5nIE1CSSByYW5n ZXMuDQo+ID4gPj4NCj4gPiA+PiBPbiBBQ1BJIHdlIGRvbuKAmXQgY3VycmVudGx5IHN1cHBvcnQg TUJJIHJhbmdlcywgYWx0aG91Z2ggaXQgbG9va3MNCj4gPiA+PiBsaWtlIHRoaXMgY291bGQgYmUg aGFuZGxlZCBieSB0aGUgZXhpc3RpbmcgZ2ljdjJtIGRyaXZlci4gVGhpcw0KPiA+ID4+IGRyaXZl ciBzaG91bGQgYWxyZWFkeSB3b3JrIGFzIGEgY2hpbGQgb2YgdGhlIEdJQ3YzLCBob3dldmVyIGl0 DQo+ID4gPj4gYXBwZWFycyB0byBiZSBGRFQgb25seSwgc28gd2lsbCBuZWVkIHNvbWUgd29yayB0 byBhZGQgQUNQSSBzdXBwb3J0Lg0KPiA+ID4+DQo+ID4gPj4gQW5kcmV3DQo+ID4gPg0KDQo= From nobody Fri Nov 11 20:10:41 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N88wF75mqz4ftHG for ; Fri, 11 Nov 2022 20:10:53 +0000 (UTC) (envelope-from bT.43g9herc30=mb0c0bam51bh=hchst2t53z@em790814.fubar.geek.nz) Received: from e2i342.smtp2go.com (e2i342.smtp2go.com [103.2.141.86]) (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 4N88wF4DZKz4LcF for ; Fri, 11 Nov 2022 20:10:52 +0000 (UTC) (envelope-from bT.43g9herc30=mb0c0bam51bh=hchst2t53z@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1668198352; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=A6b4bXG0CJ7gIdEnMheEsN7oA2MfddOJhE/l5fGDG58=; b=xtCxtopm ruMWpvCfGPvRrlATWouBFnfjBybbKaiHARTWuS5Ppsy80N+LpPY4HX6cTKN1nCUu3Rag7laEolndo aS4EGC22QzCOUejEYkMR4L7nxHso2Ra1uVBn+PvQ0NTLTFTU/bb+GlQg1n+H1OpIp0MUwpIsX/FYR AC2aH7xnbNJ4trgwwEzoOIF9uUVG/jsW/IWZKnT6Pc7HEz9+24qefyABxeZQuJIQc24/t+us5OzB1 xq/vigzLUX5QMbQjiwMr9hugwHV1+vN9YHRm5dHb3gJkK0CBjrxb/dc2vQfdcZ3LztKBcY2hxYd56 Gnd5C6f+muO91xDy+yoiXwI1/g==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1668197452; h=from : subject : to : message-id : date; bh=A6b4bXG0CJ7gIdEnMheEsN7oA2MfddOJhE/l5fGDG58=; b=JWy6po59OGk39KpljL6y09LL65OoQyTuy+RyvCrtw7QdV27oHNxNPKA+qr+1IUoBibVg5 68wS53/xUUbTqC7mTgFAHBq56eZDy0E5ioDMGwJLXHDsmtvpSwRWpAYit0kGJAkoXq6Nx/z E9ITthKAjr1TZsfpKgYikFx4eyyb9EA5TDfWbGlu601R/UPUvPEUyKx2qZ2Ylb+ZyLsaON4 V+erFm1mnNqomqN+//ImKbJEBFp5ShpgZITioEaSay5vwQC/9fvxF5E9sSEoQ9Gsmh0bt2E Hy6BV3pHjToJYLnKKyGTfn/S/TgCEoPv/8qi3YATpbIKOm9E9Ey9jrI1kMRA== Received: from [10.139.162.187] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1otaMR-TRjzqm-FB; Fri, 11 Nov 2022 20:10:47 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1otaMR-4XobWr-0s; Fri, 11 Nov 2022 20:10:47 +0000 Received: from smtpclient.apple (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 884D69AE8; Fri, 11 Nov 2022 20:10:42 +0000 (UTC) From: Andrew Turner Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C72BF360-FA1E-44BC-ABBC-1D9F0B37BFF7" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [EXTERNAL] pcib msix allocation in arm64 Date: Fri, 11 Nov 2022 20:10:41 +0000 In-Reply-To: Cc: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" To: Souradeep Chakrabarti References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Smtpcorp-Track: 1otauR4boPWr0s.PnxFYr1ZTENGC Feedback-ID: 790814m:790814amQcrys:790814sNwJM4lss3 X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Rspamd-Queue-Id: 4N88wF4DZKz4LcF X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US] X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C72BF360-FA1E-44BC-ABBC-1D9F0B37BFF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Nov 2022, at 19:07, Souradeep Chakrabarti = wrote: >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Souradeep Chakrabarti >> Sent: Thursday, November 10, 2022 3:20 PM >> To: Andrew Turner > >> Cc: Warner Losh >; Wei Hu = >; freebsd- >> hackers@FreeBSD.org >> Subject: RE: [EXTERNAL] pcib msix allocation in arm64 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Andrew Turner >>> Sent: Thursday, November 3, 2022 6:21 PM >>> To: Souradeep Chakrabarti >>> Cc: Warner Losh ; Wei Hu ; >> freebsd- >>> hackers@FreeBSD.org >>> Subject: Re: [EXTERNAL] pcib msix allocation in arm64 >>>=20 >>> Hi Souradeep, >>>=20 >>> For the vmbus_pcib driver you=E2=80=99ll need to implement the = pcib_alloc_msi, >>> pcib_release_msi, and the msix versions, and pcib_map_msi. >>>=20 >>> For alloc and release you can just call into the same intr_* = function >>> as pci_host_generic_acpi.c. You=E2=80=99ll need to pass in the xref = for the >>> interrupt controller. It needs to be the xref the MSI controller >>> registered. For the GICv2m it=E2=80=99s ACPI_MSI_XREF. >>>=20 >> [Souradeep] >> I have used following in vmbus_pcib.c : >> ret =3D intr_alloc_msix(pcib, dev, ACPI_MSI_XREF, irq); But it is = failing in >> pic_lookup() with ESRCH by not finding pic with ACPI_MSI_XREF. >> Do I need to do anything for pic_lookup() to be successful? >>=20 > [Souradeep]=20 > I found out the reason here pic_lookup() for ACPI_MSI_XREF is failing, = as > we are not calling intr_msi_register() but intr_pic_register() is = getting called for the PCIB. > This is because we don't have ITS implemented in Hyper-V. Instead, = Hyper-V is presenting the > MSI/MSI-X as SPI because of it's own limitation. > Linux has solved it using custom irqchip driver to handle it.=20 > But I am not sure how to address it in FreeBSD.=20 > Can you please point me out something here? We currently only support SPIs in the GICv3 driver under FDT. To teach = the ACPI attachment to support them you=E2=80=99ll need to set = sc->gic_mbi_start and sc->gic_mbi_end in sys/arm64/arm64/gic_v3_acpi.c = to the correct value from the ACPI tables before calling gic_v3_attach. = After this returns successfully you can then call intr_msi_register. See gic_v3_fdt.c for how we do it under FDT. Andrew= --Apple-Mail=_C72BF360-FA1E-44BC-ABBC-1D9F0B37BFF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Nov 2022, at 19:07, Souradeep Chakrabarti <schakrabarti@microsoft.com> wrote:




-----Original Message-----
From: Souradeep Chakrabarti
Sent: Thursday, = November 10, 2022 3:20 PM
To: Andrew Turner <andrew@fubar.geek.nz>
Cc: Warner Losh = <imp@bsdimp.com>; = Wei Hu <weh@microsoft.com>; freebsd-
hackers@FreeBSD.org
Subject: RE: [EXTERNAL] pcib msix allocation in arm64




-----Original = Message-----
From: Andrew Turner <andrew@fubar.geek.nz>
Sent: Thursday, = November 3, 2022 6:21 PM
To: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Cc: Warner = Losh <imp@bsdimp.com>; Wei Hu <weh@microsoft.com>;
freebsd-
hackers@FreeBSD.org
Subject: Re: [EXTERNAL] = pcib msix allocation in arm64

Hi = Souradeep,

For the vmbus_pcib driver = you=E2=80=99ll need to implement the pcib_alloc_msi,
pcib_release_msi, and the msix versions, and pcib_map_msi.

For alloc and release you can just call into = the same intr_* function
as pci_host_generic_acpi.c. = You=E2=80=99ll need to pass in the xref for the
interrupt = controller. It needs to be the xref the MSI controller
registered. For the GICv2m it=E2=80=99s ACPI_MSI_XREF.

[Souradeep]
I have = used following in vmbus_pcib.c :
ret =3D = intr_alloc_msix(pcib, dev, ACPI_MSI_XREF, irq); But it is failing in
pic_lookup() with ESRCH by not finding pic with = ACPI_MSI_XREF.
Do I need to do anything for pic_lookup() = to be successful?

[Souradeep] 
I found out the reason here = pic_lookup() for ACPI_MSI_XREF is failing, as
we are not calling = intr_msi_register() but intr_pic_register() is getting called for the = PCIB.
This is = because we don't have ITS implemented in Hyper-V. Instead, Hyper-V is = presenting the
MSI/MSI-X as SPI because of it's own limitation.
Linux has solved it using custom = irqchip driver to handle it. 
But I am not sure how to address = it in FreeBSD. 
Can you please point me out = something here?

We currently only support SPIs in the GICv3 driver = under FDT. To teach the ACPI attachment to support them you=E2=80=99ll = need to set sc->gic_mbi_start and sc->gic_mbi_end in = sys/arm64/arm64/gic_v3_acpi.c to the correct value from the ACPI tables = before calling gic_v3_attach. After this returns successfully you = can then call intr_msi_register.

See gic_v3_fdt.c for how we do it under = FDT.

Andrew
= --Apple-Mail=_C72BF360-FA1E-44BC-ABBC-1D9F0B37BFF7-- From nobody Sat Nov 12 17:28:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8jH156xXz4hJWL for ; Sat, 12 Nov 2022 17:29:01 +0000 (UTC) (envelope-from mandyliscious4@gmail.com) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N8jH03v0gz4Mkt for ; Sat, 12 Nov 2022 17:29:00 +0000 (UTC) (envelope-from mandyliscious4@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="Q7/bgWhG"; spf=pass (mx1.freebsd.org: domain of mandyliscious4@gmail.com designates 2607:f8b0:4864:20::102c as permitted sender) smtp.mailfrom=mandyliscious4@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pj1-x102c.google.com with SMTP id m6-20020a17090a5a4600b00212f8dffec9so7223478pji.0 for ; Sat, 12 Nov 2022 09:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:to:message-id:thread-topic:subject:from :date:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fKRbdZBKdPBO8n4TRwB01Vu34PeN5LnHtkPH+RFCBbQ=; b=Q7/bgWhG1biF4mTWfJysmlTJan+nItInJxDEf4d2dPb1dCw0U7CfPbt7SKEuRUku0P sPdUfvSxpN1i5xgosn4cDlHXVee6nEKvQjHAbkuFd1HLmCCjiRATtVEnEUUAP0JF7yjC ueLN5567ryu0hS260MNp5GeCCJVatK3VgrBsQHPmvUMeOFc2Rr00/DsY0NueZX21nHuU SIhiZFsdJU431OwSC+2k1x9OgxfmNgk+la5id7RtBSlyUZ54Z5v8NHN4cOPwUA04P3dC /LHCHlD/SaOZWcS/107k8PpYpZXwdCgFFSJWMJsKzJl7/mRzH4sIiD1IpIVEZvMtbZpg tAxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:message-id:thread-topic:subject:from :date:mime-version:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fKRbdZBKdPBO8n4TRwB01Vu34PeN5LnHtkPH+RFCBbQ=; b=nQ+OmfoTVT+CwyuTevxfhKtz2u3Yc1DNEpmQ1nYOvp8Z0uhvjUbSsaTv5Jn462K0MY qlbT/0TQCKxW5749VoqdJxUrMGnL0NSg/TwGREZ2FMwus0kUPpH1IzDsJkqjO7YiQW1y mPAajyAvPs/sVScFKF1E/0hGoMoKmw+u6hR+bvMTuy71PDupGYEq8sdvPDqYZT8YFZK6 SBYJ9SfKZqItKRe45ZIGKFHbHaCBcIn4bRCIkNnX1pxvdgvdJe0OqbxLJ5h4fvMnwKUB esYk4KyzzmcciaZGqPmi+UofghRgrvjdvK2gwZDWE3O3NPqxMnt15IbxGgSEgF2DhWra et/w== X-Gm-Message-State: ANoB5pn0vAvB9WIvEZEqBsUt6c7fDLgQGAh7uoZN5irpeGnIa/EWEX5h p8pL2HkLf1mT47Gf82XzxPrTpAUWWYJiAg== X-Google-Smtp-Source: AA0mqf6V4a/HRn6lCtwF+aN8l5Y3i0dPJbBDpHKP/IJmq5OKOBk0diNh9Kg8fF7RNLPbbjoZP/O66Q== X-Received: by 2002:a17:902:c20c:b0:186:9c32:79d9 with SMTP id 12-20020a170902c20c00b001869c3279d9mr7743743pll.47.1668274138648; Sat, 12 Nov 2022 09:28:58 -0800 (PST) Received: from DESKTOP-J7J41K6 ([2600:6c5a:a00:27e1:4834:8179:c9c3:cb70]) by smtp.gmail.com with ESMTPSA id 132-20020a62188a000000b00571dda13fafsm1432889pfy.163.2022.11.12.09.28.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Nov 2022 09:28:58 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Sat, 12 Nov 2022 12:28:55 -0500 From: Amanda Wallace Subject: RE: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) Thread-Topic: RE: Crypto Donations (was: Re: What is the status of the FreeBSD development process now?) Message-ID: <2357934F-3901-4C33-A3B6-CD09FF05791A@hxcore.ol> To: "freebsd-hackers@freebsd.org" , Karl Denninger Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.69 / 15.00]; FAKE_REPLY(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MIME_HTML_ONLY(0.20)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::102c:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; SUBJECT_HAS_QUESTION(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:~]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4N8jH03v0gz4Mkt X-ThisMailContainsUnwantedMimeParts: N

Ka= rl Derringer, Thank you for clearing that up for us. I do appreciate th= e difference in you=E2=80=99re perception and there by

walked in a daily setting, from the perception of others in this field= of intelligence, computational thinking.

No, ther= e is no real value in currency, period. Only, there are values to a crypto = or federal currencies, because the

big money hot h= eads just want to see how much all of us will fall down the rabbit hole. An= d, also the criminal activity,

it=E2=80=99s all go= verned by the same big shots.

 

Anyways, Thank You ALL at FREEBSD.ORG<= /o:p>

I have learned and became to be familiar = with certain developmental/programs/apps, in which you have written

about in the forum?=C2=A0 Well, the emails I receive.

<= p class=3DMsoNormal> 

Sincerely,

A.J.W.

 

<= p class=3DMsoNormal>Sent from Mail for Windows

 

From: = Karl Denninger
Sent: Friday, November 4, 2022 11:00 AM
= To: freebsd-hackers@free= bsd.org
Subject: Re: Crypto Donations (was: Re: What is the s= tatus of the FreeBSD development process now?)

 

On 11/4/2022 10:56, Wojcie= ch Puchar wrote:

[...]
Unfortunately FreeBSD still does not
accept any don= ations via cryptocurrency.
Nor has FreeBSD community yet participated i= n any
crypto crowd funded code dev/bug/doc etc bounties.
The world = is moving there, others are already making
good use of them, best get o= n that, have fun :)

Honestly, this seems to me simply to be good poli= cy on the part of
the foundation (not accepting donations via crypto).&= nbsp; There's no
apparent benefit as far as I can see, and the extreme = volatility of
all existing cryptocurrencies by itself strikes me as an = excellent
reason to continue the current policy.    = ;            &n= bsp;   -- George

Why? Accept and instantly change to= something else.

Let's clear things up.

Crypto currencies a= re really worth nothing. Just people do believe they are worth something. I= t represent no real value.

Classic currencies are really worth noth= ing. Just people do believe they are worth something. It represent value eq= ual heat of combustion - if you have papers. Or zero if just in bank.
<= br>The only difference is that classic currencies are enforced by law. Cryp= to are not.

So you shouldn't differentiate, just then convert to cu= rrency or some other good you need. To avoid risks - do it at the day when = crypto currency is transferred.

IMHO this is= at its foundation a political statement; one who has crypto something and = wishes to donate to FreeBSD can trivially exchange it for "classic cur= rency" and donate the classic currency.   Indeed you so-stat= e in your first line in that there is no reason the person who wishes to ma= ke the donation cannot simply remove the entire point of debate by "in= stantly changing it to something else", in this case dollars.

On= e thing I do like about FreeBSD is that it has mostly stayed out of said po= litical debates, which is IMHO a good thing.

-- Karl Denninger
karl@denninger.net=
The Market Ticker
[S/M= IME encrypted email preferred]

 

= From nobody Sat Nov 12 19:40:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N8mCZ2JZGz4flZq for ; Sat, 12 Nov 2022 19:41:14 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N8mCY4mWFz3kNC for ; Sat, 12 Nov 2022 19:41:13 +0000 (UTC) (envelope-from s.adaszewski@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=bBTVLWfF; spf=pass (mx1.freebsd.org: domain of s.adaszewski@gmail.com designates 2607:f8b0:4864:20::f33 as permitted sender) smtp.mailfrom=s.adaszewski@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-xf33.google.com with SMTP id mi9so5564563qvb.8 for ; Sat, 12 Nov 2022 11:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=CYBy11FTHGl+Ww0eI7dAy5kPKkmVGvEXK7xLPJe8mgc=; b=bBTVLWfFpx8tXt5ObuthqEQ4zFuFeJKsHA948mNF5w36ogm5CoyvhUsCw64ZS8rPdN A8+Ydy8caJkT3SaT24vrJgSNmGHgJW0unJUwqSzk12zFQ1Sov37fkeADToJP4iVVzIIx 1uYFm+G315QJ6+/ZmjseOmJpMSmGBAVa4EbT88ywqAvOcwHu/E0wohQ+AbusvnT4w+J6 HC4m6gA2ni/8rEzmBXxZsmj+Msb9urQ6CL0r6sZ2ta5B7hB65uL48RM4fTpqdgPnjOqt HF+LUHOl8bkDfCtIzpUD+1pjyjf/g5HIHhIcW/1VTgFbDe7tG6TS7Zga0a5U2G4KnJOb BqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=CYBy11FTHGl+Ww0eI7dAy5kPKkmVGvEXK7xLPJe8mgc=; b=YdufHi7D5mn7VI5jLpanZQRTnsY5JNrWuJHKBl9eQJXmGLx2eJX+xddl6nRa3QQMb+ IKl/xmYgsnvngXpXFG7xX+pACfEa5LOj1cC4pYSMQlYAEktwTJu7y2j1vep+KVmouSNp xYD0BxKuH5uGIQL87v2q59zTm5H9bhmB2G+uTJL/FLzN17rh0NM12iH1OJNjADimdAhm 0DZMU+IaEAeOJUulWivDZKH6Og4KEJS2Ln3zkKKvtCOGTQi9YP03vcy4H6W38CIlP8xG Cub/cq+x68tVtohm67nja2iDqT4zjNgrv7KbeY/pPCenybOG17dUXzX+OKSatemgmBFd 597Q== X-Gm-Message-State: ANoB5pmYtYGOga2gF6VvIX/kweOHUC8HMGuWUjk0j90S1MryztGpqJ35 7vWHAGCKDJSMLfOOTnb9Fzq9iWU80J0RVZ35+FLrWWcTpKo= X-Google-Smtp-Source: AA0mqf6qoYVKAwQqIlWCenSlws/0lAadVDlG0cl8qyn1qyIebZBr5YZWJXwySi4EIKuS5uOX6bML2TGvycb3a5lGdxg= X-Received: by 2002:a0c:e841:0:b0:4bb:de25:e988 with SMTP id l1-20020a0ce841000000b004bbde25e988mr6973152qvo.131.1668282073028; Sat, 12 Nov 2022 11:41:13 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Stanislaw Adaszewski Date: Sat, 12 Nov 2022 20:40:37 +0100 Message-ID: Subject: EFI loader - GELI secrets in memory exposed on exit() ? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f33:from]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; HAS_WP_URI(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4N8mCY4mWFz3kNC X-ThisMailContainsUnwantedMimeParts: N Dear All, Could someone with FreeBSD EFI loader knowledge please confirm my impression that currently the memory is not cleared in any way upon a call to exit() / efi_exit() in the EFI loader? This means that if the loader (for whatever reason) exits instead of booting, the next UEFI boot entry might be able to read any secrets left over on the heap (i.e. GELI passphrase / key)? Would adding explicit_bzero() before efi_main.c:44 [1] address this and other such "cold boot" concerns? This scenario is particularly clumsy because for "resets" the Platform Reset Mitigation can be engaged (and does engage by default if TPM is owned) but a simple "exit" from an UEFI app is different. For example multiple UEFI apps can simply run one after another from the UEFI Shell, clearly without zero-ing out all of the physical memory. Thoughts? Thank you for your time and consideration. PS. The work on automatically booting GELI-encrypted installs using TPM2 using more standard TPM provisioning (Shrared Storage Key) is almost finished [3]. It works quite beautifully and actually allows to store the key instead of the passphrase which is faster (avoids computation) and also largely avoid messy use of environment variables AND EFI variables for config are no longer used, instead relying on files in /efi/freebsd/gkut2. GKUT2 stands for GELI Key Using TPM2. The question above is clearly related to GKUT2 in particular. [1] https://github.com/freebsd/freebsd-src/blob/main/stand/efi/loader/efi_main.c#L44 [2] https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf [3] https://github.com/sadaszewski/freebsd-patch-geli-password-from-tpm2/tree/decrypt Best regards, -- Stanislaw From nobody Sun Nov 13 19:20:30 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9MjJ2Ckkz4dKdB for ; Sun, 13 Nov 2022 19:20:36 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9MjG74rRz4649 for ; Sun, 13 Nov 2022 19:20:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=QWtN6vky; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::136 as permitted sender) smtp.mailfrom=markjdb@gmail.com; dmarc=none Received: by mail-il1-x136.google.com with SMTP id d3so4824264ils.1 for ; Sun, 13 Nov 2022 11:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=uV1vjXwLY+zdHEOlKO4J9VE5WVOSTyQwKN0YeAiQZy4=; b=QWtN6vkyrrA+3JxMquIJri6svVp3eflbpSYpMJmwCU9X7uxF5IsrLFrTYL6AAeJHjt t96oF9ciWx6+kh1rqqwYQkMLB5PA28wouV7Pr+ACxI0RjsPHZq5u4aFR6MDYUAjjcpz8 pgHGQ1nh9SupSvQlqd7J5W55T7qi9PFoREpf1qAkYOsDOyLEjTOesUG9kO2GE32jM2Bq CyROQTd/HOZzW7zTSLiatFqgQ16X91+SNUEV5dAX63Tgft+/2ftEa1W6uD7rPqP2AjqD F2/1kVRxejod8zYdrt5rgopJjxAhPO6bZnxy8Cr9kHcBemtT/X9uXOaDvnmnPQAV9dmA ZrbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uV1vjXwLY+zdHEOlKO4J9VE5WVOSTyQwKN0YeAiQZy4=; b=evSir/jSFJmpnyf5Fiawc1FJJrRUSomJUtd4h4kE8PkVcccfQjkTPJzPHX8QKbhXVj vaMCKrDW8ATIsOm6GPFnBmlDw9s9CiOaVzanDjvc6I2y1Uc2Lm4VOaQwYl13/kYg5Cqf qracH4G2FwnW+5loPPtlsj7fAQc1p37pFHBp1NsecoWTSF/Uz1GKS/S7HT0Q32cxsl/3 pcjrgZycR+g7VJrLpNqjwmCb7AdQwXnbECVJaBcDh+UrEckKGa4S1wmwUMu6jsAwag4P ZJI0VrN1ooclhi3LlwF3Uv6oF4ahDGAOqqEllAD7hhmz1JpPmj1lKBpJqwmZBY9mcqCB izzg== X-Gm-Message-State: ANoB5pmNMYlsSC6AsHwhBwuH93/Sy5AmCThEpglzW51Ikx3XGPaNCxPQ S/X0s2pBNk1dSADPnTFD5sYB6HDtyYU= X-Google-Smtp-Source: AA0mqf6dL6rHvPPZ75KGmHy3S2M5xqiatLv5bcY/pXAsLgGrWKpFdL33q2KDu08rTr2sUJd+/ZjfEQ== X-Received: by 2002:a05:6e02:1ba8:b0:302:4675:6223 with SMTP id n8-20020a056e021ba800b0030246756223mr4146088ili.3.1668367234036; Sun, 13 Nov 2022 11:20:34 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id g3-20020a056602150300b006a129b10229sm3174830iow.31.2022.11.13.11.20.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Nov 2022 11:20:33 -0800 (PST) Date: Sun, 13 Nov 2022 14:20:30 -0500 From: Mark Johnston To: Christopher Bowman Cc: hackers@freebsd.org Subject: Re: I could use some help Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spamd-Result: default: False [0.30 / 15.00]; MID_RHS_NOT_FQDN(0.50)[]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::136:from]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4N9MjG74rRz4649 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 09, 2022 at 10:18:02PM -0800, Christopher Bowman wrote: > OK I’m really confused and I could use some help: > > 13.0 runs fine on my Xilinx Zynq based board (DIgilent Arty Z20). However when I compile 13.1 release it doesn’t boot. The kernel stops during boot as follows: > > Using DTB from loaded file '/boot/dtb/zynq-artyz7.dtb'. > > > Loading DTB overlays: 'artyz7_ssd_overlay.dtb' > > > /boot/dtb/overlays/artyz7_ssd_overlay.dtb size=0x1a1 > > > Kernel entry at 0x17a00200... > > > Kernel args: (null) > > > applying DTB overlay '/boot/dtb/overlays/artyz7_ssd_overlay.dtb' > > > WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance > ---<>--- > Copyright (c) 1992-2021 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > .The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-STABLE #22 n248064-ce9c3848ff3: Wed Nov 9 22:04:45 PST 2022 > crb@eclipse.ChrisBowman.com:/usr/obj/usr/src/arm.armv7/sys/ARTYZ7 arm > FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) > CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) > CPU Features: > Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk > Optional instructions: > UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:2 LoUIS:2 > Cache level 1: > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 4-way instruction cache Read-Alloc > real memory = 536866816 (511 MB) > avail memory = 515162112 (491 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > random: unblocking device. > random: entropy device external interface > ofwbus0: > simplebus0: on ofwbus0 > simplebus1: on ofwbus0 > l2cache0: mem 0xf8f02000-0xf8f02fff irq 8 on simplebus1 > l2cache0: cannot allocate IRQ, not using interrupt > l2cache0: Part number: 0x3, release: 0x8 > l2cache0: L2 Cache enabled: 512KB/32B 8 ways > gic0: mem 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1 > gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 > mp_tmr0: mem 0xf8f00200-0xf8f0021f irq 29 on simplebus1 > Timecounter "MPCore" frequency 50000000 Hz quality 800 > mp_tmr1: mem 0xf8f00600-0xf8f0061f irq 36 on simplebus1 > Event timer "MPCore" frequency 50000000 Hz quality 1000 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpu1: on cpulist0 > uart0: mem 0xe0000000-0xe0000fff irq 9 on simplebus1 > uart0: console (-1,n,8,1) > zy7_qspi0: mem 0xe000d000-0xe000dfff irq 13 on simplebus1 > zy7_qspi0: must have ref-clock property > device_attach: zy7_qspi0 attach returned 6 > cgem0: mem 0xe000b000-0xe000bfff irq 15 on simplebus1 > miibus0: on cgem0 > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > rgephy1: PHY 1 on miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > cgem0: Ethernet address: 56:99:3e:50:9a:8e > sdhci_fdt0: mem 0xe0100000-0xe0100fff irq 17 on simplebus1 > sdhci_fdt0: 1 slot(s) allocated > mmc0: on sdhci_fdt0 > zy7_devcfg0: mem 0xf8007000-0xf80070ff irq 28 on simplebus1 > Timecounters tick every 1.000 msec > sdhci_fdt0-slot0: Controller timeout > sdhci_fdt0-slot0: ============== REGISTER DUMP ============== > sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: 0x00008901 > sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 > sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 > sdhci_fdt0-slot0: Present: 0x01ff0202 | Host ctl: 0x00000001 > sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 > sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 > sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa > sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 > sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_fdt0-slot0: =========================================== > sdhci_fdt0-slot0: Controller timeout > sdhci_fdt0-slot0: ============== REGISTER DUMP ============== > sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 > sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 > sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 > sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 > sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 > sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 > sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 > sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa > sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 > sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_fdt0-slot0: =========================================== > > The controller register dumps continue for a while and then I get: > > mmc0: CMD7 failed, RESULT: 1 > Release APs > Trying to mount root from ufs:/dev/mmcsd0s2a [rw]... > mountroot: waiting for device /dev/mmcsd0s2a... > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > Trying to mount root from ufs:mmcsd0s2a []... > mountroot: waiting for device mmcsd0s2a... > Mounting from ufs:mmcsd0s2a failed with error 19. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/mmcsd0s2a > vfs.root.mountfrom.options=rw > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:zroot/ROOT/default > cd9660:/dev/cd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> > > If I replace the kernel with a 13.0 kernel, it boots just fine. > > So I go and do a git bisect between release/13.0.0 and release/13.1.0 > > and I get the following: > > git bisect start '--first-parent' > # status: waiting for both good and bad commits > # good: [ea31abc261ffc01b6ff5671bffb15cf910a07f4b] 13.0: update to RELEASE > git bisect good ea31abc261ffc01b6ff5671bffb15cf910a07f4b > # status: waiting for bad commit, 1 good commit known > # bad: [fc952ac2212b121aa6eefc273f5960ec3e0a466d] Update in preparation of 13.1-RELEASE > git bisect bad fc952ac2212b121aa6eefc273f5960ec3e0a466d > # skip: [4c44dbde5491516eba8725dc51d39c1dcc817472] MFC jail: Handle a parent jail when a child is added to it > git bisect skip 4c44dbde5491516eba8725dc51d39c1dcc817472 > # good: [476f87219f408343846254743c7189076be80c04] wpi: Fix a lock leak in an error path in wpi_run() > git bisect good 476f87219f408343846254743c7189076be80c04 > # bad: [05bf7d68c56830e52dee14dc87c07d6716e8195e] aesni: Fix an out-of-bounds read in AES_GCM_decrypt() > git bisect bad 05bf7d68c56830e52dee14dc87c07d6716e8195e > # good: [014ae00ef6edca2687d618e0bda138086a1e1230] date: Capitalize seconds string in synopses > git bisect good 014ae00ef6edca2687d618e0bda138086a1e1230 > # bad: [08d995ca8f6f1008a10e4bf4d924824c040f842a] swapoff_one(): only check free pages count manually turning swap off > git bisect bad 08d995ca8f6f1008a10e4bf4d924824c040f842a > # bad: [81b6dba1a08b031bdf7463c1704d27ae1e0daa0f] ktls: Fix assertion for TLS 1.0 CBC when using non-zero starting seqno. > git bisect bad 81b6dba1a08b031bdf7463c1704d27ae1e0daa0f > # bad: [67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1] net80211: add a driver-private pointer to struct ieee80211_node > git bisect bad 67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1 > # good: [109330155000bfec215ee39148254d2a0b628798] module(9): Document that evhand can be NULL > git bisect good 109330155000bfec215ee39148254d2a0b628798 > # bad: [4c8e29637456bbbe709425f691f637914658009f] LinuxKPI: add module_pci_driver() and pci_alloc_irq_vectors() > git bisect bad 4c8e29637456bbbe709425f691f637914658009f > # bad: [4a03ae8d17ddf3d3b57ca281000fd98e200b92cc] nfscl: Fix use after free for forced dismount > git bisect bad 4a03ae8d17ddf3d3b57ca281000fd98e200b92cc > # bad: [de957de097857fabb69a59a9ba36276c5e735de5] bhyve: Fix the WITH_BHYVE_SNAPSHOT build > git bisect bad de957de097857fabb69a59a9ba36276c5e735de5 > # bad: [5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391] hwpmc: initialize arm64 counter/interrupt state > git bisect bad 5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391 > # bad: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling of reserves in zone_import() > git bisect bad ce9c3848ff369467749f59fd24f8b9f1241e725c > # good: [d5ebaa6f8f850bb6f6273f01386832efcb295827] uma: Improve M_USE_RESERVE handling in keg_fetch_slab() > git bisect good d5ebaa6f8f850bb6f6273f01386832efcb295827 > # first bad commit: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling of reserves in zone_import() > > If I do git log ce9c3848ff369467749f59fd24f8b9f1241e725c it does seem that d5ebaa6f8f850bb6f6273f01386832efcb295827 is the previous commit and that it works just fine but ce9c3848ff369467749f59fd24f8b9f1241e725c doesn’t boot. It’s literally the same file system and DTB, the only difference is the kernel installed. > > What’s confusing to me is that looking at ce9c3848ff369467749f59fd24f8b9f1241e725c I can’t see how that commit would result in my kernel hanging while booting. It's indeed a bit hard to see why commit ce9c3848ff369467749f59fd24f8b9f1241e725c might cause an sdhci command timeout. I suspect the commit itself is innocent, but happens to uncover a problem elsewhere by changing the order in which page allocations are distributed to different consumers. At the time of the command timeouts, the kernel is still running on a single CPU so the order in which pages are allocated should be fairly deterministic and thus consistent across multiple boots. One thing you can try is to take a releng/13.1 tree and revert just ce9c3848ff369467749f59fd24f8b9f1241e725c, and/or take releng/13.0 and apply just that commit. It would be useful to know whether either of the resulting kernels can boot successfully. Could you also please post your kernel configuration (ARTYZ7) somewhere, together with a dmesg of a successful boot? From nobody Sun Nov 13 22:48:02 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9SJl25J3z4hM7r for ; Sun, 13 Nov 2022 22:48:07 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9SJl05ZFz3Q8M for ; Sun, 13 Nov 2022 22:48:07 +0000 (UTC) (envelope-from crb@chrisbowman.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x42e.google.com with SMTP id k22so9480874pfd.3 for ; Sun, 13 Nov 2022 14:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=d4dm/NwI/REtSZJS5itVdp4nOehqBK3xtXooMvHvaPw=; b=eZZvmC+RC9IYhZjOclFy30nS9jjtZTMvOe+pFZT04doRd/FzzNoeZ7FgWR38dWIb2I iSARvcruFddLvwOB/DauPKg4vLydYqLmrXOBSOFZ2S6WaMm8qaEeZSgWOb96OaG0EgOO LoOO+vTwPRKt2pF+q4P20SUcaa9ER7SoKUXm0qglxfiz/VBSyxGdOouYnchTfRhEj2FI 468p6xtWMaQ3Fkj6f5ztxFeHfDNCdtF85iP+bBxJUok251JhS717jyi1GFCpA+zgPF/p QXpD2db8WNBdaZLOC6CsrI/6aw0UXC05O2GJbVDOCstq/NZL4LW9qBepn+RHHMc2SmCl yhdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=d4dm/NwI/REtSZJS5itVdp4nOehqBK3xtXooMvHvaPw=; b=KBXZe6RTIMP7iC209303MBfEVS+PixQXGq8QbsUQfoJ5dkuKSMa+Wte4nMmWzZMR1K OHf1uGVFMnPjNOuioB/DPlUqhYF9rL4kArb0fUfOnK3ER3dbKYFIkT/yn7c8LEGKSqNr iozrwsp3wH1fNDb4q7g+oE5fQVDidrgiJeFccS8H2nPv0BZlbn0yKKfmu1v/caar8bUS Y2vOhfv+Rr7SKrcXW9qwL+I2J1w+TIXAxDtDeBwHs9NoOW2gNMYl50ltvnwaBNdxh7od lyYdgZho9i1pPpA8QxJ4HpYkfgAs/mzidSTZkN+bka4CeY24IInqaicRSXOhGzYHxdK4 XXbw== X-Gm-Message-State: ANoB5plcqk81Hp0kh+e+AwGRD9GmA164f70xhU/GTPopCqAR3GWo42KI DzLvDkt71L8XhAxV2eVGgXVU9QMSbtRRIReU4gU= X-Google-Smtp-Source: AA0mqf63kQ7CqBC4Ht67e0XCC8zFq03e8PtHmdVWZiYA8QIroKFfUqACE637tUaKpTZSFhzipkO/QQ== X-Received: by 2002:aa7:8595:0:b0:563:312d:745b with SMTP id w21-20020aa78595000000b00563312d745bmr11470210pfn.69.1668379684894; Sun, 13 Nov 2022 14:48:04 -0800 (PST) Received: from smtpclient.apple ([2600:1700:5430:10b1:e42b:72ee:232a:2ce1]) by smtp.gmail.com with ESMTPSA id c19-20020a621c13000000b0056cc538baf0sm5194434pfc.114.2022.11.13.14.48.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2022 14:48:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: I could use some help From: Christopher Bowman In-Reply-To: Date: Sun, 13 Nov 2022 14:48:02 -0800 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C07A058-977C-4F2E-8B41-01EBAB4FF24B@chrisbowman.com> References: To: Mark Johnston X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4N9SJl05ZFz3Q8M X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Nov 13, 2022, at 11:20 AM, Mark Johnston wrote: >=20 > On Wed, Nov 09, 2022 at 10:18:02PM -0800, Christopher Bowman wrote: >> OK I=E2=80=99m really confused and I could use some help: >>=20 >> 13.0 runs fine on my Xilinx Zynq based board (DIgilent Arty Z20). = However when I compile 13.1 release it doesn=E2=80=99t boot. The kernel = stops during boot as follows: >>=20 >> Using DTB from loaded file '/boot/dtb/zynq-artyz7.dtb'. >>=20 >>=20 >> Loading DTB overlays: 'artyz7_ssd_overlay.dtb' >>=20 >>=20 >> /boot/dtb/overlays/artyz7_ssd_overlay.dtb size=3D0x1a1 >>=20 >>=20 >> Kernel entry at 0x17a00200... >>=20 >>=20 >> Kernel args: (null) >>=20 >>=20 >> applying DTB overlay '/boot/dtb/overlays/artyz7_ssd_overlay.dtb' >>=20 >>=20 >> WARNING: Cannot find freebsd,dts-version property, cannot check DTB = compliance >> ---<>--- >> Copyright (c) 1992-2021 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> .The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 13.0-STABLE #22 n248064-ce9c3848ff3: Wed Nov 9 22:04:45 PST = 2022 >> crb@eclipse.ChrisBowman.com:/usr/obj/usr/src/arm.armv7/sys/ARTYZ7 = arm >> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git = llvmorg-11.0.1-0-g43ff75f2c3fe) >> CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) >> CPU Features:=20 >> Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk >> Optional instructions:=20 >> UMULL, SMULL, SIMD(ext) >> LoUU:2 LoC:2 LoUIS:2=20 >> Cache level 1: >> 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc >> 32KB/32B 4-way instruction cache Read-Alloc >> real memory =3D 536866816 (511 MB) >> avail memory =3D 515162112 (491 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> random: unblocking device. >> random: entropy device external interface >> ofwbus0: >> simplebus0: on ofwbus0 >> simplebus1: on ofwbus0 >> l2cache0: mem 0xf8f02000-0xf8f02fff irq 8 = on simplebus1 >> l2cache0: cannot allocate IRQ, not using interrupt >> l2cache0: Part number: 0x3, release: 0x8 >> l2cache0: L2 Cache enabled: 512KB/32B 8 ways >> gic0: mem = 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1 >> gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 >> mp_tmr0: mem 0xf8f00200-0xf8f0021f irq 29 on = simplebus1 >> Timecounter "MPCore" frequency 50000000 Hz quality 800 >> mp_tmr1: mem 0xf8f00600-0xf8f0061f irq 36 on = simplebus1 >> Event timer "MPCore" frequency 50000000 Hz quality 1000 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> cpu1: on cpulist0 >> uart0: mem 0xe0000000-0xe0000fff irq 9 on simplebus1 >> uart0: console (-1,n,8,1) >> zy7_qspi0: mem 0xe000d000-0xe000dfff = irq 13 on simplebus1 >> zy7_qspi0: must have ref-clock property >> device_attach: zy7_qspi0 attach returned 6 >> cgem0: mem = 0xe000b000-0xe000bfff irq 15 on simplebus1 >> miibus0: on cgem0 >> rgephy0: PHY 0 on = miibus0 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >> rgephy1: PHY 1 on = miibus0 >> rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto >> cgem0: Ethernet address: 56:99:3e:50:9a:8e >> sdhci_fdt0: mem = 0xe0100000-0xe0100fff irq 17 on simplebus1 >> sdhci_fdt0: 1 slot(s) allocated >> mmc0: on sdhci_fdt0 >> zy7_devcfg0: mem 0xf8007000-0xf80070ff irq 28 on = simplebus1 >> Timecounters tick every 1.000 msec >> sdhci_fdt0-slot0: Controller timeout >> sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: 0x00008901 >> sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 >> sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 >> sdhci_fdt0-slot0: Present: 0x01ff0202 | Host ctl: 0x00000001 >> sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 >> sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 >> sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa >> sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 >> sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >> sdhci_fdt0-slot0: Controller timeout >> sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 >> sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 >> sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 >> sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 >> sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 >> sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 >> sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa >> sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 >> sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>=20 >> The controller register dumps continue for a while and then I get: >>=20 >> mmc0: CMD7 failed, RESULT: 1 >> Release APs >> Trying to mount root from ufs:/dev/mmcsd0s2a [rw]... >> mountroot: waiting for device /dev/mmcsd0s2a... >> Mounting from ufs:/dev/mmcsd0s2a failed with error 19. >> Trying to mount root from ufs:mmcsd0s2a []... >> mountroot: waiting for device mmcsd0s2a... >> Mounting from ufs:mmcsd0s2a failed with error 19. >>=20 >> Loader variables: >> vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a >> vfs.root.mountfrom.options=3Drw >>=20 >> Manual root filesystem specification: >> : [options] >> Mount using filesystem >> and with the specified (optional) option list. >>=20 >> eg. ufs:/dev/da0s1a >> zfs:zroot/ROOT/default >> cd9660:/dev/cd0 ro >> (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) >>=20 >> ? List valid disk boot devices >> . Yield 1 second (for background tasks) >> Abort manual input >>=20 >> mountroot>=20 >>=20 >> If I replace the kernel with a 13.0 kernel, it boots just fine. >>=20 >> So I go and do a git bisect between release/13.0.0 and release/13.1.0 >>=20 >> and I get the following: >>=20 >> git bisect start '--first-parent' >> # status: waiting for both good and bad commits >> # good: [ea31abc261ffc01b6ff5671bffb15cf910a07f4b] 13.0: update to = RELEASE >> git bisect good ea31abc261ffc01b6ff5671bffb15cf910a07f4b >> # status: waiting for bad commit, 1 good commit known >> # bad: [fc952ac2212b121aa6eefc273f5960ec3e0a466d] Update in = preparation of 13.1-RELEASE >> git bisect bad fc952ac2212b121aa6eefc273f5960ec3e0a466d >> # skip: [4c44dbde5491516eba8725dc51d39c1dcc817472] MFC jail: Handle a = parent jail when a child is added to it >> git bisect skip 4c44dbde5491516eba8725dc51d39c1dcc817472 >> # good: [476f87219f408343846254743c7189076be80c04] wpi: Fix a lock = leak in an error path in wpi_run() >> git bisect good 476f87219f408343846254743c7189076be80c04 >> # bad: [05bf7d68c56830e52dee14dc87c07d6716e8195e] aesni: Fix an = out-of-bounds read in AES_GCM_decrypt() >> git bisect bad 05bf7d68c56830e52dee14dc87c07d6716e8195e >> # good: [014ae00ef6edca2687d618e0bda138086a1e1230] date: Capitalize = seconds string in synopses >> git bisect good 014ae00ef6edca2687d618e0bda138086a1e1230 >> # bad: [08d995ca8f6f1008a10e4bf4d924824c040f842a] swapoff_one(): only = check free pages count manually turning swap off >> git bisect bad 08d995ca8f6f1008a10e4bf4d924824c040f842a >> # bad: [81b6dba1a08b031bdf7463c1704d27ae1e0daa0f] ktls: Fix assertion = for TLS 1.0 CBC when using non-zero starting seqno. >> git bisect bad 81b6dba1a08b031bdf7463c1704d27ae1e0daa0f >> # bad: [67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1] net80211: add a = driver-private pointer to struct ieee80211_node >> git bisect bad 67efa8b29930f12dae2bf237fa7c2ce1dafbd6b1 >> # good: [109330155000bfec215ee39148254d2a0b628798] module(9): = Document that evhand can be NULL >> git bisect good 109330155000bfec215ee39148254d2a0b628798 >> # bad: [4c8e29637456bbbe709425f691f637914658009f] LinuxKPI: add = module_pci_driver() and pci_alloc_irq_vectors() >> git bisect bad 4c8e29637456bbbe709425f691f637914658009f >> # bad: [4a03ae8d17ddf3d3b57ca281000fd98e200b92cc] nfscl: Fix use = after free for forced dismount >> git bisect bad 4a03ae8d17ddf3d3b57ca281000fd98e200b92cc >> # bad: [de957de097857fabb69a59a9ba36276c5e735de5] bhyve: Fix the = WITH_BHYVE_SNAPSHOT build >> git bisect bad de957de097857fabb69a59a9ba36276c5e735de5 >> # bad: [5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391] hwpmc: initialize = arm64 counter/interrupt state >> git bisect bad 5c2e6d9610f1b3f1d7c5d69b925212a7b1fd9391 >> # bad: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: Fix handling = of reserves in zone_import() >> git bisect bad ce9c3848ff369467749f59fd24f8b9f1241e725c >> # good: [d5ebaa6f8f850bb6f6273f01386832efcb295827] uma: Improve = M_USE_RESERVE handling in keg_fetch_slab() >> git bisect good d5ebaa6f8f850bb6f6273f01386832efcb295827 >> # first bad commit: [ce9c3848ff369467749f59fd24f8b9f1241e725c] uma: = Fix handling of reserves in zone_import() >>=20 >> If I do git log ce9c3848ff369467749f59fd24f8b9f1241e725c it does seem = that d5ebaa6f8f850bb6f6273f01386832efcb295827 is the previous commit and = that it works just fine but ce9c3848ff369467749f59fd24f8b9f1241e725c = doesn=E2=80=99t boot. It=E2=80=99s literally the same file system and = DTB, the only difference is the kernel installed. >>=20 >> What=E2=80=99s confusing to me is that looking at = ce9c3848ff369467749f59fd24f8b9f1241e725c I can=E2=80=99t see how that = commit would result in my kernel hanging while booting. >=20 > It's indeed a bit hard to see why commit > ce9c3848ff369467749f59fd24f8b9f1241e725c might cause an sdhci command > timeout. I suspect the commit itself is innocent, but happens to > uncover a problem elsewhere by changing the order in which page > allocations are distributed to different consumers. At the time of = the > command timeouts, the kernel is still running on a single CPU so the > order in which pages are allocated should be fairly deterministic and > thus consistent across multiple boots. >=20 > One thing you can try is to take a releng/13.1 tree and revert just > ce9c3848ff369467749f59fd24f8b9f1241e725c, and/or take releng/13.0 and > apply just that commit. It would be useful to know whether either of > the resulting kernels can boot successfully. >=20 > Could you also please post your kernel configuration (ARTYZ7) = somewhere, > together with a dmesg of a successful boot? Mark, If I checkout release/13.1.0 and revert the commit in question = then my kernel boots. I wasn=E2=80=99t able to checkout releng/13.1 as = I get the following: crb@eclipse:142> git checkout releng/13.1 M sys/vm/uma_core.c Already on 'releng/13.1' Your branch is up to date with 'origin/releng/13.1=E2=80=99. I think that=E2=80=99s just me being incompetent with git. I can add the commit to release/13.1.0 if you would still like My kernel is essentially identical to the in-tree ZEDBOARD config with the name changed. I can post it if truly desired. Please find the dmesg output for 13.1 release below. Thanks Christopher crb@artyz7:51> dmesg=20 Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-RELEASE #1 n250148-fc952ac2212-dirty: Sun Nov 13 14:29:58 = PST 2022 crb@eclipse.ChrisBowman.com:/usr/obj/usr/src/arm.armv7/sys/ARTYZ7 = arm FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) CPU Features:=20 Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk Optional instructions:=20 UMULL, SMULL, SIMD(ext) LoUU:2 LoC:2 LoUIS:2=20 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory =3D 536866816 (511 MB) avail memory =3D 515440640 (491 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: unblocking device. random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 l2cache0: mem 0xf8f02000-0xf8f02fff irq 8 on = simplebus1 l2cache0: cannot allocate IRQ, not using interrupt l2cache0: Part number: 0x3, release: 0x8 l2cache0: L2 Cache enabled: 512KB/32B 8 ways gic0: mem = 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1 gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 mp_tmr0: mem 0xf8f00200-0xf8f0021f irq 29 on = simplebus1 Timecounter "MPCore" frequency 50000000 Hz quality 800 mp_tmr1: mem 0xf8f00600-0xf8f0061f irq 36 on = simplebus1 Event timer "MPCore" frequency 50000000 Hz quality 1000 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 uart0: mem 0xe0000000-0xe0000fff irq 9 on simplebus1 uart0: console (-1,n,8,1) zy7_qspi0: mem 0xe000d000-0xe000dfff = irq 13 on simplebus1 zy7_qspi0: must have ref-clock property device_attach: zy7_qspi0 attach returned 6 cgem0: mem = 0xe000b000-0xe000bfff irq 15 on simplebus1 miibus0: on cgem0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: Ethernet address: 72:11:aa:7b:e3:52 sdhci_fdt0: mem = 0xe0100000-0xe0100fff irq 17 on simplebus1 sdhci_fdt0: 1 slot(s) allocated mmc0: on sdhci_fdt0 zy7_devcfg0: mem 0xf8007000-0xf80070ff irq 28 on = simplebus1 Timecounters tick every 1.000 msec mmcsd0: 32GB at mmc0 = 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/mmcsd0s2a [rw]... Release APs Warning: no time-of-day clock registered, system time will not be set = accurately lo0: link state changed to UP cgem0: link state changed to DOWN cgem0: cgem_mediachange: could not set ref clk0 to 125000000. cgem0: link state changed to UP From nobody Sun Nov 13 23:37:56 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9TQK1lGgz4hSWr for ; Sun, 13 Nov 2022 23:38:01 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9TQJ6kvLz3kP1 for ; Sun, 13 Nov 2022 23:38:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-il1-x129.google.com with SMTP id o13so4998218ilc.7 for ; Sun, 13 Nov 2022 15:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=rQVM+tC/j0+dqCMxz39isNw4X4TXWAhDMdrfAbFXLLE=; b=AkJ+qwqxgZ0HfvK8pauEWeOw+mVVIkYNMwBSy7RR9n7rXatYLJB86wNf8l+7PVnaDM fsSTh5qYJGdMm0w+Db+D2zeeKgaihs8EV4d1JkJ9U6j/hYZEzSh6D7oDRdsui/qD46Wo jFnVhqDcsSW5nHeEkMydtm92ciBkUq0kNG0xrOTmqLaKxgXM2+Yscq/tw8ozjb0KBvxy rmHSEP/qJKaM5XJ+2g59PDzlPbBh8hjXb9dgskZ6q+DkXehuAXc5KVnhHXUDuPRN3dom v4AVToDHO2aTQFM3VBa4Fr5MEAVTEvS/RQ/vAEbKOjjPnHlGbWaADaQiGNxDFgoKABZS g5nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rQVM+tC/j0+dqCMxz39isNw4X4TXWAhDMdrfAbFXLLE=; b=biDIIJI9UCElEiA3BS7/pha64D24BQUk1DgVLNTDLS28m5ZgZ/OHNxMUHJPhA68OVn ujhs6/V9eJUDmmytTTHkfduakbTW2orVLokzt7Y7N7hAGZt00Xk2Mzk2DdRGI94Jwcye 0Vu48zKhNpgksWqKBkTbN007JCDUk6Ko3KtAZ1tYauUosDQ5VFRb5a5hmWjkFk6g55WB EOKvzNSTa3NFuR7kl5j5JjJvxU8jp3nMyqEzQt6gEpln3fp3+O9DKqJblciAxWo8A7jw ybaEHAoyxjYbewJ5NTWLVHGhd2EIeQhPVz9qB24zgHVLqeLslEVGGurxgxAEKUVx6w6E ec0A== X-Gm-Message-State: ANoB5pnrYZu1GUha08gGr83WpmPj1/gQF3VQzL2OLRcCkAu/uwJmbok6 MkxDOmpCFDuB8goSc07q55Y= X-Google-Smtp-Source: AA0mqf6Y+M5BHVgl7e3I1c9YFpieCvCUD9bd2NvRVSmMVxXE5WgVrxLVizpOXLsqmLP6AHM3pMhOMQ== X-Received: by 2002:a92:de4e:0:b0:300:9b70:1954 with SMTP id e14-20020a92de4e000000b003009b701954mr5096042ilr.52.1668382679408; Sun, 13 Nov 2022 15:37:59 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id c3-20020a92d3c3000000b003024b62725dsm2034784ilh.22.2022.11.13.15.37.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Nov 2022 15:37:58 -0800 (PST) Date: Sun, 13 Nov 2022 18:37:56 -0500 From: Mark Johnston To: Christopher Bowman Cc: hackers@freebsd.org Subject: Re: I could use some help Message-ID: References: <5C07A058-977C-4F2E-8B41-01EBAB4FF24B@chrisbowman.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5C07A058-977C-4F2E-8B41-01EBAB4FF24B@chrisbowman.com> X-Rspamd-Queue-Id: 4N9TQJ6kvLz3kP1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Nov 13, 2022 at 02:48:02PM -0800, Christopher Bowman wrote: > > > > On Nov 13, 2022, at 11:20 AM, Mark Johnston wrote: > > It's indeed a bit hard to see why commit > > ce9c3848ff369467749f59fd24f8b9f1241e725c might cause an sdhci command > > timeout. I suspect the commit itself is innocent, but happens to > > uncover a problem elsewhere by changing the order in which page > > allocations are distributed to different consumers. At the time of the > > command timeouts, the kernel is still running on a single CPU so the > > order in which pages are allocated should be fairly deterministic and > > thus consistent across multiple boots. > > > > One thing you can try is to take a releng/13.1 tree and revert just > > ce9c3848ff369467749f59fd24f8b9f1241e725c, and/or take releng/13.0 and > > apply just that commit. It would be useful to know whether either of > > the resulting kernels can boot successfully. > > > > Could you also please post your kernel configuration (ARTYZ7) somewhere, > > together with a dmesg of a successful boot? > > Mark, > If I checkout release/13.1.0 and revert the commit in question then my kernel boots. I wasn’t able to checkout releng/13.1 as I get the following: > > crb@eclipse:142> git checkout releng/13.1 > M sys/vm/uma_core.c > Already on 'releng/13.1' > Your branch is up to date with 'origin/releng/13.1’. > > I think that’s just me being incompetent with git. It's because sys/vm/uma_core.c is modified in your local copy, and to check out releng/13.1 needs to modify uma_core.c. You can remove that local modification with "git checkout -f sys/vm/uma_core.c && git checkout releng/13.1", or just "git checkout -f releng/13.1", though the latter will discard any other uncommitted modifications you might have in your tree. I'm not sure what release/13.1.0 is though, that branch doesn't appear to exist in the official git repo. If it points to the same commit as releng/13.1, then ok. > I can add the commit to release/13.1.0 if you would still like > > My kernel is essentially identical to the in-tree ZEDBOARD config > with the name changed. I can post it if truly desired. > > Please find the dmesg output for 13.1 release below. > Thanks > Christopher Ok, nothing really stands out to me. It looks like mmcsd_attach() is running, but before it can discover any partitions it issues a command that times out, so we'll have to dig in a bit more. Could you please try booting a problematic kernel with the hw.mmc.debug and hw.sdhci.debug tunables set to "3", and share the resulting output up until the hang? It might be pretty verbose. Separately, I wonder if you could try booting a problematic kernel with the kern.maxphys tunable set to 131072. Does it change anything? From nobody Mon Nov 14 03:07:38 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9Z4X6pRrz4fjWh for ; Mon, 14 Nov 2022 03:07:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9Z4X00fgz4551 for ; Mon, 14 Nov 2022 03:07:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="NOU+N/P+"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668395274; bh=lSLW8jKZp9E2x7wAdSld5LaaZYZZbh89U7TlNAOsPB4=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=NOU+N/P+eD4LEv4Lt/ObNWq7JdBB0Q6+ffBt8XqAspCclOALGbCgzTJ9HhDebNGQ5ngZDHhYXbNKzlaGDA6KdvYTF8OyXwcSBdma1uT9+479cWm87WZTJjJHFnFw9KR75LPrTqKb+c2O1KFEkfw3/t70vnv2/gEpknkqUymx6neWl+0F176hqA6QCbirGvMBps6i1FcqUGhnTxOcj7B1No2fJpWGIzRqQymTVs3foZWJnQ/jYSQFqSUA3V9thSaJYtjChMQVJiT/NIXgnMiMuF93fqtpDQRQvcNso8+c1mPx1WJWNz2NP8bys5PjmZU+pKprk2f9XFNjDtkRYIcD/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668395274; bh=MMLGsmEv7mqPABz6+usy+qnpi1FsIQvH6sxZ5BwsZ3g=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=MRuDUlJgKqAMqpz2aFxsce78AF6CGs8DTsjYKICI49sThckf4gumDcC54T4sOyaOFprzKwPiPILhXHuk2NxCBKy3p/Lxmk7XbCvdGSEFCbWu1TddOCm4CJSbDWETF3Pqy8XvOPThhT56RqHtrNLpOHOsY3lMXNkYjGH4oLumrNWs9Ar2PAhgbp/bNeigMas9IHurEHmmmpzZuKYDPj7Nm474RWyovVqC+4+roNndIhIoq4JuWkiaOcDQlpFWU0Y6xYsCxl4Wdgxm83qHxYHrHHdsKxkxT7YO1w18KjEWNx6FYQp/z9ZkEzbFOtB75cycG5q9WFYhZ9Mh3qd35V5Idg== X-YMail-OSG: Xz871ZkVM1nponxkM.riKv0AJvW4SyVevT_AQKnspHFgGRe9pDA1dihMvaOhxQp 10paF2t6WP64fzootfBonhhPkVs_F0uKcD8N0G9Sk.IpqlC.NbHKO4esejc6iZGxPP9ygU61NUj_ TKmrJ.nAVtMUs8XEt9XeKrZRmLQVMdImq2kN.3K8rygqz2OppbnoXnis8yJ1dd.wOQNlcZ6R_IFv jp_p8rSwmNmTbnjFwmLtUElg63Zxz48QiKAi4PjS2O70scAEyqdR3YYQjm2_DcUqrfpkSjwgY4GJ eAcdxRktrkHoQu1Z92Cu7iV5PsTS7WKHbq2URDxzEBZuqoQfOyjw7A1NdXJNxQ4UnKOWyV9bGFNe e18Khi86GNDi50hbHViU4YMgQro7.wPvlJS4H5nchgJdE3yOAiR2NiXdmME0C5y_9MmZQvf0YhXP IABjm6sc9JL6UC67lpzDdDj2Ihe7X0WR1t0yCNhw.d1H7gMfPBU6CzRGMGDJp8JstT1QZXblNCnC YqSa6QVax0vVBx1.KYUwBVnnM5b7q79LFYLFj89NtnU9QjD2gctjEsT0xbdZO06MgM9i.wq4yJde iROEXfefLSKCnkqU_RzqldWZbwNQCrsdqT18K3Xo9dhNWoFNtwh.BYPJknecK9IcDDGHNe7B7W7d 69ai6lP5g0LcxFIqHOsYQE_Iury1.hekzITapUCiXWISpmgyq5MtY9LOtO1jl0k0kvj6XeSgbdhC q5u7H_8V1F_IVqRqcyoObEjAr.jylt11ntSMeMeMxA30GWpaCYIwFWYaHrpoFgZ9ByeaWXhdvCMm D0M_QCDkAttNFHY2QKkT8To6Nwa_SoOervW4U4sFpiQyiCtewEnvvsgs78BETr1xKJ3vQVSy3GkI NoJYineEjcZthFxs7Wq8qb0OMYjvr6NiLAe.HN57EwYByGrKyObscu13rsGTNsyGwIQcP8235CBU ZTzM1rq3n6TaJTcPRRtLu0cQgcuGNJQ2lycI_HM_Scu3yR5d6hoOgN0zBSgNmmnIJ_S2HCyuUmeF _o3n1fUKrfzbI1JkS.fyVi1735u8WxEFUzyeZSZL9Ny8.NRVPYFsmNFWylIM6_IWu2pqe13QNrh1 RBH9uej_82XIm8onK1PZEnT470t6UFAdt5U3gVJkj0vvO87UwbV2._M0lavaLjX1kyzc8pIlGWDv f5lEgkWOtx4k._w4QIDmfgGqqb.WzBpIieIt5IQqRzKh1ZPhnyFrOYShrqJYPNi_3CHSsLyJbYzn Ms_1VwXAmgMFU6NmjTBr.6EQO4npsBQJDDxU.XrdFzFiYH4N1_PjGeB7PMJbwySUKJHyNdZJ0hjc 9uGO2fOx1DU.ikkK2Cll6DIMh7m3eGraC83l51Jdvdk4Gjpp_E3beOXK1MLnjXGAPWJuzVHUC_5w b1UO_Gpa6QzbAYR9UpbAhyKkuqee02kPTgD85ihpvmJaADYCkFp7AcPS7VzgHp3uG7u_ChDJDfw. DlZWMMik_4fN_1Gm4r7k2OsLW3vodeXuBlUVkJ816_W_zhlrwAsVh8_N5R_isF6wJfnq8aFkG6OY IUCAtj5imqRxGuEpgWuh0BTD6p6WyqwipaFyeMxCOYo6m5z1U3AtOMUVG75QfrKAsycN2T1aSvLC LJEJ0CwaE525G_qmsrVj.KaY8sPQrQEQem6SNT9debKtP2JoAv49nAG9ODsqpEMPH.6UFO1RjdcA rQmYyA5llgKcm6El76vfkvMqQOt9NiyVVnOZx74DK5TJNkHFHXTk2ugDorFQwiIj0de.s8ifjy7h ugwgaY7SS9M845bmpr1Jac1qCeVFjoE_HjPT8mm09K4.ZIshrTg7Fvt8kvG.slMC.hMTRjFrCoBP ONLpk4s_wk1edg72vkQejWCWNAlH9lLOGznrxRrPKnT.bTMMU1hsOSjnWF2UqCxQ.C4JJNMyhrmG 3bwvULkBTs9jKzq2QtrKhBsP9sUMO._zaJCj5WDgB9ZLohkzoAhsVdZ69wm7LKqDNZQ2qhL8HzL. Sl2m78GDXN64o.1fhSgDGa2D.qbpO4i6QGZyn75k8wbC1zgLsLWujWF9DGdOnLKpy6U1uaB9jxaa _gAKQ7zR1peiN69BWFDsCFKsTACvyq5nBexARCZ_3TlQOfArxIENq5k5o1lDRG__dCsEj8ZTFQkb AE3noNmt_qoVgkVEf1FdDKsSjyjol5YRF2GZ9K2FAOMPW0hreijRs4ngaOzzG8Oc4ZoemdKBFDEw vv.aRyfNmG1n7X6hZeTElDN0d1Vi7gjkL41VfjGoJyQtCI.fuuDjqc6zp1ox5c2UOqCZS85J7gqb SWTFAp.w- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Nov 2022 03:07:54 +0000 Received: by hermes--production-bf1-5878955b5f-dvp8b (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bfa0bde806384276466be9aee19bed93; Mon, 14 Nov 2022 03:07:50 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: I could use some help Message-Id: <8F50D6A9-0BC2-4BCF-9E1B-D7C9F4C42F0A@yahoo.com> Date: Sun, 13 Nov 2022 19:07:38 -0800 Cc: crb@chrisbowman.com To: Mark Johnston , FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <8F50D6A9-0BC2-4BCF-9E1B-D7C9F4C42F0A.ref@yahoo.com> X-Spamd-Result: default: False [-1.36 / 15.00]; NEURAL_HAM_SHORT(-0.86)[-0.863]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4N9Z4X00fgz4551 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Mark Johnston wrote on Date: Sun, 13 Nov 2022 23:37:56 UTC : > On Sun, Nov 13, 2022 at 02:48:02PM -0800, Christopher Bowman wrote: > >=20 > >=20 > . . . > > Mark, > > If I checkout release/13.1.0 and revert the commit in question then = my kernel boots. I wasn=E2=80=99t able to checkout releng/13.1 as I get = the following: > . . .. >=20 > I'm not sure what release/13.1.0 is though, that branch doesn't appear > to exist in the official git repo. If it points to the same commit as > releng/13.1, then ok. >=20 > . . . release/13.1.0 is a tag visible on: https://cgit.freebsd.org/src/refs/tags as (not showing links' various URLs): release/13.1.0 src-release/13.1.0.tar.gz src-release/13.1.0.zip Glen = Barber It also can be referenced via the notation: https://cgit.freebsd.org/src/tag/?h=3Drelease/13.1.0 which shows: (the "tagged object" link's URL takes one to the commit) tag name release/13.1.0 (9f95e64031fa41c6f812fdfc13156442b61791ba) tag date 2022-05-12 15:48:43 +0000 tagged by Glen Barber tagged object commit fc952ac221... download src-release/13.1.0.tar.gz src-release/13.1.0.zip Tag 13.1-RELEASE from fc952ac2212b121aa6eefc273f5960ec3e0a466d Approved by: re (implicit) -----BEGIN PGP SIGNATURE----- = iQIzBAABCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmJ9LHQACgkQAxRYpUeP = 4pO8ig/+Oieu1bp9Dq8tDCzcaI0hNIYwSikKJ30WbOHFG4yZVkXieVhcLQ8JhEZf = LiwtqdxcZF8y8/WJ+m7gPDlesot+ndwhC3Amevc14qiWyxblAF4l6KZq9isxLKaa = RTV4AtmwRzEw4uQMV4jOY2Y7Ov0BG3GtEXvQxh0NMjvLgrTRrQ/gZ5a41Q9JYjaM = Kz4lYCAZ6s6+ovQ68HDGtzw4mLbdso/qB/sqw0Al1FLzh6FB9XlQSfXlnQI2v8lW = twQbaU3ss/epWQNfczZlkiBEEh6t0sc3ZwXB8bJnDuRUmQwGsqgpZK2teZ+kQ+DU = fl7+TvfXPpvAwmE06iJqiEX6liQkf/vBTScvJe3PJdxWB6jJmPj7FhXJBCodZveu = L+L5LgHmjtAuUp+AiuP9iJKBFeBpCsaXQn46I/IRu32UQhP7CF+CM6VEjVVQk3O/ = j7SCdxgCN5XZ2eBMha34EXdFjH4tB0vNPHMll582XqDz0Wh9nS79CI64zuXpyKxK = F3CjUqzbTsvoJB5zqigj4C576uyXuLalGIcfBRc6Wq2UfnKjf4SXCGziqE7CguUc = 6JBBqOCglomhkOF0Z9U3lW9ej8mSPrVrpPFSSArc4ZqJ1c1An8+qhqAYCkd39jwd = JvZnyejoWFn+X76uFUa+qTshYzEvxvepuS9PwHJ4qLeGNAybbzo=3D =3DNuUv -----END = PGP SIGNATURE----- =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Nov 14 06:11:49 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9f8n4bzhz4h8tG for ; Mon, 14 Nov 2022 06:11:53 +0000 (UTC) (envelope-from crb@chrisbowman.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9f8n2Ss1z4LJn for ; Mon, 14 Nov 2022 06:11:53 +0000 (UTC) (envelope-from crb@chrisbowman.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x530.google.com with SMTP id h193so9395119pgc.10 for ; Sun, 13 Nov 2022 22:11:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisbowman-com.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+2ghBlfP/aFgOTojizr2Rb9TPYlWR99aEBCBdo+5xxM=; b=KR9EEmHiNS5oOPHcYWJ7XIRpUJOthNNLWyxe8GbCC3SIpQHGTWEKVGZyhwsP7DvbRp fMhruvfpCPIensNXss/o+QfqL1Y5QTgV+3pXh+iAO6DvEoQQ55EDLOsl8g7kWJRtt9Hf ZsclMw5O5VTVKtyxkIEv9UrtALzomrRye36sWkae09TWNy8Y7FYQTcwpmkRyF0eW9KvQ ccOlX7ypMFunQPDVxx/y3B5A3Ly59eF36svB1Q3IEkogV12sb79sGVwLKmk/SxjQNv+c VIqn7dNGDJ1y0jg0nAzgy88UDZdAwCo13Fj8ugmE1VEsJkteV8QB3nBe3X00NOmAljhy n46Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+2ghBlfP/aFgOTojizr2Rb9TPYlWR99aEBCBdo+5xxM=; b=SRtaSr/vOFKwNi/jWryukkJX6jHjK1L1qXcNy0h/yTcMEGARsXqpJiK1BoycaTl04z YXs7dtEOTHWiabjGBDkeF+hBxgsgata1KazsADRm1OtycpGZpuA49aYkwwhYczGfvALw EBDIlxBLwpmNC9jr7bJHwFYK8TXXSmfzbR+K/ciL96ScIc8rz2DQzunr/Un3kn5KiSHg amBLaG03QDFQCFHK/2iUudQJlczDK6AHVoP9vt++W36RwSZ9MJVEs/Q/38sdJZerEVEk SjOk1r9uwL4BjJFndEmGV+GPm8thOxX33S4erB6ouVddGEdzDs9CUZo6a4vuySw0XyYW tQbA== X-Gm-Message-State: ANoB5pk4gw+UhkUJ7kdLE5gTYnr7UNOO2gwrNNS1JVtiuFJOts4p+d7A AGOCZpzLfSbSUXqnOefzq3O9xfrDIcQxgx8P350= X-Google-Smtp-Source: AA0mqf6zDQK1yJeSzRvLWKNfPuSBsLyV7Nui2qef5kHSeICEVO6utWh4H7eX7iB/dW4+C/2+60103Q== X-Received: by 2002:a63:5065:0:b0:470:3fc1:5ed0 with SMTP id q37-20020a635065000000b004703fc15ed0mr10973705pgl.370.1668406311595; Sun, 13 Nov 2022 22:11:51 -0800 (PST) Received: from smtpclient.apple ([2600:1700:5430:10b1:dc4a:86a0:a15e:5090]) by smtp.gmail.com with ESMTPSA id m19-20020a170902f21300b00186b8752a78sm6350461plc.80.2022.11.13.22.11.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2022 22:11:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: I could use some help From: Christopher Bowman In-Reply-To: Date: Sun, 13 Nov 2022 22:11:49 -0800 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C07A058-977C-4F2E-8B41-01EBAB4FF24B@chrisbowman.com> To: Mark Johnston X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4N9f8n2Ss1z4LJn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Nov 13, 2022, at 3:37 PM, Mark Johnston wrote: >=20 > On Sun, Nov 13, 2022 at 02:48:02PM -0800, Christopher Bowman wrote: >>=20 >>=20 >>> On Nov 13, 2022, at 11:20 AM, Mark Johnston = wrote: >>> It's indeed a bit hard to see why commit >>> ce9c3848ff369467749f59fd24f8b9f1241e725c might cause an sdhci = command >>> timeout. I suspect the commit itself is innocent, but happens to >>> uncover a problem elsewhere by changing the order in which page >>> allocations are distributed to different consumers. At the time of = the >>> command timeouts, the kernel is still running on a single CPU so the >>> order in which pages are allocated should be fairly deterministic = and >>> thus consistent across multiple boots. >>>=20 >>> One thing you can try is to take a releng/13.1 tree and revert just >>> ce9c3848ff369467749f59fd24f8b9f1241e725c, and/or take releng/13.0 = and >>> apply just that commit. It would be useful to know whether either = of >>> the resulting kernels can boot successfully. >>>=20 >>> Could you also please post your kernel configuration (ARTYZ7) = somewhere, >>> together with a dmesg of a successful boot? >>=20 >> Mark, >> If I checkout release/13.1.0 and revert the commit in question = then my kernel boots. I wasn=E2=80=99t able to checkout releng/13.1 as = I get the following: >>=20 >> crb@eclipse:142> git checkout releng/13.1 >> M sys/vm/uma_core.c >> Already on 'releng/13.1' >> Your branch is up to date with 'origin/releng/13.1=E2=80=99. >>=20 >> I think that=E2=80=99s just me being incompetent with git. >=20 > It's because sys/vm/uma_core.c is modified in your local copy, and to > check out releng/13.1 needs to modify uma_core.c. You can remove that > local modification with "git checkout -f sys/vm/uma_core.c && git > checkout releng/13.1", or just "git checkout -f releng/13.1", though = the > latter will discard any other uncommitted modifications you might have > in your tree. >=20 > I'm not sure what release/13.1.0 is though, that branch doesn't appear > to exist in the official git repo. If it points to the same commit as > releng/13.1, then ok. >=20 >> I can add the commit to release/13.1.0 if you would still like >>=20 >> My kernel is essentially identical to the in-tree ZEDBOARD config >> with the name changed. I can post it if truly desired. >>=20 >> Please find the dmesg output for 13.1 release below. >> Thanks >> Christopher >=20 > Ok, nothing really stands out to me. It looks like mmcsd_attach() is > running, but before it can discover any partitions it issues a command > that times out, so we'll have to dig in a bit more. >=20 > Could you please try booting a problematic kernel with the = hw.mmc.debug > and hw.sdhci.debug tunables set to "3", and share the resulting output > up until the hang? It might be pretty verbose. >=20 > Separately, I wonder if you could try booting a problematic kernel = with > the kern.maxphys tunable set to 131072. Does it change anything? release/13.1.0 and release/13.0.0 are the tags that signify the version = used to build the release. I don=E2=80=99t see any significant difference in booting a kernel with = kern.maxphys=3D131072 in the loader. It boots fine, not sure what I = should be looking for. checking my src tree: crb@eclipse:157> git show commit c3c13035ef270dcf0d24d2d847dd590edc535ed0 (HEAD -> releng/13.1, = origin/releng/13.1) adding these:=20 hw.mmc.debug=3D3 hw.sdhci.debug=3D3 gives following boot log: U-Boot SPL 2022.04 (Jun 28 2022 - 22:54:35 -0700) Silicon version:.3 Trying to boot from MMC1 spl_load_image_fat_os: error reading image system.dtb, err - -2 U-Boot 2022.04 (Jun 28 2022 - 22:54:35 -0700) CPU: Zynq 7z020 Silicon: v3.1 Model: Zynq ARTY Z7 Development Board DRAM: ECC disabled 512 MiB Core: 12 devices, 11 uclasses, devicetree: board Flash: 0 Bytes NAND: 0 MiB MMC: mmc@e0100000: 0 Loading Environment from FAT... *** Error - No Valid Environment Area = found *** Warning - bad env area, using default environment In: serial@e0000000 Out: serial@e0000000 Err: serial@e0000000 Net: =20 ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 1, interface rgmii-id Warning: ethernet@e000b000 (eth0) using random MAC address - = de:93:c2:23:18:3f eth0: ethernet@e000b000 Hit any key to stop autoboot: 0=20 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC .7.8Scanning disk mmc@e0100000.blk... Found 3 disks No EFI system partition DFU alt info setting: done DFU entities configuration failed! (partition table does not match dfu_alt_info?) BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootarm.efi 1399152 bytes read in 95 ms (14 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootarm.efi Consoles: EFI console =20 Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm EFI loader, Revision 1.1 Command line arguments: l Image base: 0x1d96a000 EFI version: 2.90 EFI Firmware: Das U-Boot (rev 8226.1024) Console: efi (0x1000) Load Path: /efi\boot\bootarm.efi Load Device: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x3f,= 0x20000) Trying ESP: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(1,0x01,0,0x3f,= 0x20000) Setting currdev to disk0p1: Trying: = /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,0x01,0,0x200= 3f,0x3b523c1) Setting currdev to disk0p2: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local .cLoading kernel... /boot/kernel/kernel text=3D0x1b4 text=3D0x525600 text=3D0x10257c = data=3D0x713d0 data=3D0x0+0x40000 syms=3D[0x4+0x6eb00+0x4+0xc5023] Loading configured modules... /boot/dtb/zynq-artyz7.dtb size=3D0x3804 /etc/hostid size=3D0x25 /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 3 seconds...=20 Booting [/boot/kernel/kernel] in 2 seconds...=20 Booting [/boot/kernel/kernel] in 1 second...=20 Booting [/boot/kernel/kernel]... =20 Using DTB from loaded file '/boot/dtb/zynq-artyz7.dtb'. Loading DTB overlays: 'artyz7_ssd_overlay.dtb' /boot/dtb/overlays/artyz7_ssd_overlay.dtb size=3D0x1a1 Kernel entry at 0x17a00200... Kernel args: (null) applying DTB overlay '/boot/dtb/overlays/artyz7_ssd_overlay.dtb' WARNING: Cannot find freebsd,dts-version property, cannot check DTB = compliance ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 .The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-RELEASE-p3 releng/13.1-n250169-c3c13035ef2 ARTYZ7 arm FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git = llvmorg-13.0.0-0-gd7b669b3a303) CPU: ARM Cortex-A9 r3p0 (ECO: 0x00000000) CPU Features:=20 Multiprocessing, Thumb2, Security, VMSAv7, Coherent Walk Optional instructions:=20 UMULL, SMULL, SIMD(ext) LoUU:2 LoC:2 LoUIS:2=20 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory =3D 536866816 (511 MB) avail memory =3D 515162112 (491 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: unblocking device. random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 l2cache0: mem 0xf8f02000-0xf8f02fff irq 8 on = simplebus1 l2cache0: cannot allocate IRQ, not using interrupt l2cache0: Part number: 0x3, release: 0x8 l2cache0: L2 Cache enabled: 512KB/32B 8 ways gic0: mem = 0xf8f01000-0xf8f01fff,0xf8f00100-0xf8f001ff on simplebus1 gic0: pn 0x39, arch 0x1, rev 0x2, implementer 0x43b irqs 96 mp_tmr0: mem 0xf8f00200-0xf8f0021f irq 29 on = simplebus1 Timecounter "MPCore" frequency 50000000 Hz quality 800 mp_tmr1: mem 0xf8f00600-0xf8f0061f irq 36 on = simplebus1 Event timer "MPCore" frequency 50000000 Hz quality 1000 cpulist0: on ofwbus0 cpu0: on cpulist0 cpu1: on cpulist0 uart0: mem 0xe0000000-0xe0000fff irq 9 on simplebus1 uart0: console (-1,n,8,1) zy7_qspi0: mem 0xe000d000-0xe000dfff = irq 13 on simplebus1 zy7_qspi0: must have ref-clock property device_attach: zy7_qspi0 attach returned 6 cgem0: mem = 0xe000b000-0xe000bfff irq 15 on simplebus1 miibus0: on cgem0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: Ethernet address: de:93:c2:23:18:3f sdhci_fdt0: mem = 0xe0100000-0xe0100fff irq 17 on simplebus1 sdhci_fdt0-slot0: 50MHz HS 8bits VDD: 3.3V VCCQ: 3.3V DRV: B DMA = removable sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00007200 | Blk cnt: 0x00000000 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000032 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000006 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00000007 sdhci_fdt0-slot0: Timeout: 0x0000000e | Int stat: 0x00000000 sdhci_fdt0-slot0: Int enab: 0x027f003b | Sig enab: 0x00000000 sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0: 1 slot(s) allocated sdhci_fdt0-slot0: Card inserted mmc0: on sdhci_fdt0 zy7_devcfg0: mem 0xf8007000-0xf80070ff irq 28 on = simplebus1 Timecounters tick every 1.000 msec sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D7 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D11 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D0 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D2 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D1 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D9 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D3 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D12 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D3 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D14 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D9 sdhci_fdt0-slot0: Divider 64 for freq 390625 (base 50000000) sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D0 mmc0: Probing bus sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D2 mmc0: REQUEST: CMD0 arg 0 flags 0x40 sdhci_fdt0-slot0: CMD0 arg 0 flags 0x40 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0000 flags 0000 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x40 sdhci_fdt0-slot0: Resp: 0000 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD0 RESULT: 0 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D2 mmc0: REQUEST: CMD8 arg 0x1aa flags 0x75 sdhci_fdt0-slot0: CMD8 arg 0x1aa flags 0x75 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x08 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x75 sdhci_fdt0-slot0: Resp: 0x1aa 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD8 RESULT: 0 mmc0: SD 2.0 interface conditions: OK mmc0: REQUEST: CMD55 arg 0 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x15 sdhci_fdt0-slot0: Resp: 0x120 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD55 RESULT: 0 mmc0: REQUEST: CMD41 arg 0 flags 0x61 sdhci_fdt0-slot0: CMD41 arg 0 flags 0x61 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x29 flags 0x02 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x61 sdhci_fdt0-slot0: Resp: 0x40ff8000 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD41 RESULT: 0 mmc0: SD probe: OK (OCR: 0x40ff8000) sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D8 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D2 mmc0: REQUEST: CMD0 arg 0 flags 0x40 sdhci_fdt0-slot0: CMD0 arg 0 flags 0x40 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0000 flags 0000 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x40 sdhci_fdt0-slot0: Resp: 0000 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD0 RESULT: 0 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D2 mmc0: Current OCR: 0x00ff8000 mmc0: REQUEST: CMD8 arg 0x1aa flags 0x75 sdhci_fdt0-slot0: CMD8 arg 0x1aa flags 0x75 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x08 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x75 sdhci_fdt0-slot0: Resp: 0x1aa 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD8 RESULT: 0 mmc0: REQUEST: CMD55 arg 0 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x15 sdhci_fdt0-slot0: Resp: 0x120 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD55 RESULT: 0 mmc0: REQUEST: CMD41 arg 0x40ff8000 flags 0x61 sdhci_fdt0-slot0: CMD41 arg 0x40ff8000 flags 0x61 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x29 flags 0x02 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x61 sdhci_fdt0-slot0: Resp: 0x40ff8000 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD41 RESULT: 0 mmc0: REQUEST: CMD55 arg 0 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x15 sdhci_fdt0-slot0: Resp: 0x120 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD55 RESULT: 0 mmc0: REQUEST: CMD41 arg 0x40ff8000 flags 0x61 sdhci_fdt0-slot0: CMD41 arg 0x40ff8000 flags 0x61 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x29 flags 0x02 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x61 sdhci_fdt0-slot0: Resp: 0xc0ff8000 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD41 RESULT: 0 mmc0: Probing cards mmc0: REQUEST: CMD2 arg 0 flags 0x67 sdhci_fdt0-slot0: CMD2 arg 0 flags 0x67 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x02 flags 0x09 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x67 sdhci_fdt0-slot0: Resp: 0x3574453 0x48333247 0x80882126 0x60014600 sdhci_fdt0-slot0: result: 0 mmc0: CMD2 RESULT: 0 mmc0: New card detected (CID 03574453483332478088212660014600) mmc0: REQUEST: CMD3 arg 0 flags 0x75 sdhci_fdt0-slot0: CMD3 arg 0 flags 0x75 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x03 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x75 sdhci_fdt0-slot0: Resp: 0xaaaa0520 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD3 RESULT: 0 mmc0: REQUEST: CMD9 arg 0xaaaa0000 flags 0x67 sdhci_fdt0-slot0: CMD9 arg 0xaaaa0000 flags 0x67 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x09 flags 0x09 sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x67 sdhci_fdt0-slot0: Resp: 0x400e0032 0xdb790000 0xedc87f80 0xa404000 sdhci_fdt0-slot0: result: 0 mmc0: CMD9 RESULT: 0 mmc0: New card detected (CSD 400e0032db790000edc87f800a404000) mmc0: REQUEST: CMD13 arg 0xaaaa0000 flags 0x15 sdhci_fdt0-slot0: CMD13 arg 0xaaaa0000 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x0d flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x15 sdhci_fdt0-slot0: Resp: 0x700 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD13 RESULT: 0 mmc0: REQUEST: CMD7 arg 0xaaaa0000 flags 0x1d sdhci_fdt0-slot0: CMD7 arg 0xaaaa0000 flags 0x1d dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0x1b sdhci_fdt0-slot0: Interrupt 0x3 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x1d sdhci_fdt0-slot0: Resp: 0x700 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD7 RESULT: 0 mmc0: REQUEST: CMD55 arg 0xaaaa0000 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0xaaaa0000 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Interrupt 0x1 sdhci_fdt0-slot0: sdhci_finish_command: called, err 0 flags 0x15 sdhci_fdt0-slot0: Resp: 0x920 0000 0000 0000 sdhci_fdt0-slot0: result: 0 mmc0: CMD55 RESULT: 0 mmc0: REQUEST: CMD51 arg 0 flags 0x35 data 8 sdhci_fdt0-slot0: CMD51 arg 0 flags 0x35 dlen 8 dflags 0x2 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Starting command opcode 0x33 flags 0x3a sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00060000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0202 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD51 RESULT: 1 mmc0: REQUEST: CMD55 arg 0xaaaa0000 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0xaaaa0000 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD55 RESULT: 1 mmc0: REQUEST: CMD55 arg 0xaaaa0000 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0xaaaa0000 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD55 RESULT: 1 mmc0: REQUEST: CMD55 arg 0xaaaa0000 flags 0x15 sdhci_fdt0-slot0: CMD55 arg 0xaaaa0000 flags 0x15 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x37 flags 0x1a sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0xaaaa0000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD55 RESULT: 1 mmc0: ACMD51 failed, RESULT: 4 mmc0: Error reading SCR 4 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: CMD7 failed, RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: CMD7 failed, RESULT: 1 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D0 mmc0: setting transfer rate to 50.000MHz (HS400 with enhanced strobe = timing) mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: REQUEST: CMD7 arg 0 flags 0 sdhci_fdt0-slot0: CMD7 arg 0 flags 0 dlen 0 dflags 0 sdhci_fdt0-slot0: Starting command opcode 0x07 flags 0000 sdhci_fdt0-slot0: Controller timeout sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER = DUMP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_fdt0-slot0: Sys addr: 0x00000000 | Version: 0x00008901 sdhci_fdt0-slot0: Blk size: 0x00005008 | Blk cnt: 0x00000001 sdhci_fdt0-slot0: Argument: 0x00000000 | Trn mode: 0x00000013 sdhci_fdt0-slot0: Present: 0x01ff0000 | Host ctl: 0x00000001 sdhci_fdt0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 sdhci_fdt0-slot0: Wake-up: 0x00000000 | Clock: 0x00004007 sdhci_fdt0-slot0: Timeout: 0x00000006 | Int stat: 0x00000001 sdhci_fdt0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fa sdhci_fdt0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_fdt0-slot0: Caps: 0x69ec0080 | Caps2: 0x00000000 sdhci_fdt0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_fdt0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_fdt0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D mmc0: CMD7 RESULT: 1 mmc0: CMD7 failed, RESULT: 1 Release APs Trying to mount root from ufs:/dev/mmcsd0s2a [rw]... mountroot: waiting for device /dev/mmcsd0s2a... Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Trying to mount root from ufs:mmcsd0s2a []... mountroot: waiting for device mmcsd0s2a... Mounting from ufs:mmcsd0s2a failed with error 19. Loader variables: vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a vfs.root.mountfrom.options=3Drw Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:zroot/ROOT/default cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot>=20 Christopher= From nobody Mon Nov 14 09:34:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4N9kfc4WWLz4d7XM for ; Mon, 14 Nov 2022 09:34:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4N9kfb3FL8z3Gnh for ; Mon, 14 Nov 2022 09:34:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=VGvjgKv9; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668418469; bh=ZvoqJnroVU94IvV20zoBOyF3dhKpqrH8zl1NcgrmMEE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=VGvjgKv9LNSDfb2RNxZSMgBbHtWkNsNK3pHCAHXhijbwySfZuvZlwsUf2w3yiKVbDSDHy3B14LevTa+jLeTzbGd7u02ZE3VX/O4ZMFzlayQseA/16W44ZfSmhZyUDfgMEv5s7iWdq/s90IjQMm2ykmJ18XbBD9PLjamOxtYG2UTKVzg4YaWijJBpFTvdRO24T5Cio2b4H5ctmcEcfUzqZ2qkPM5+xCgrTx8VolGQCbUTOLGHsxpZg7acd2LK7QD8PjveeG3K2lCXUh4Nk1Sh2lvCp0Wuq7FrxgfBhy7J3ftZVCVsVmgBuoigOOQDXlxm6Zq5YwBhBFbnVt91/gvSwQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1668418469; bh=5cVA/e3aWCtIcFTqF6X0/BWveNOO+dxFgwZ2PimNq7Y=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pPDbsYyKnNaHFFCa8Vx64X2bJMA8etoGQ4DGXrSJKdKp+gCkNt6q+WAhXVp0zrR4fOWhD/JuPmF3YFJgr/ck0VAbeKxUjlf7LJPyKV9SiPXXuan9BmCkGztq7wrzZLoM/t57eoBvFMmNQplobbtOGNM540jxwLiJ0WKcvlyVA5YwQF5VL08S4u2M+IYOHeEov0cofd8rCI/Fd/SPGDY+7Jp+ZsaAvbGBmoAEr58AGi3xukAaV4V28SOklBbcpFhS5gcDz1Y12Pr39HwbE8BZigcio+d2Qmezlg3md4Nm5dxdGHtKRTmTzz+4GYXw+mjpvqVlAWhUFq8bJBP1xaZifQ== X-YMail-OSG: VnVpV.oVM1kpMssm8cTA6x9TarngwkvHjqpZ0jRMuBW9RgEofEhW4ptixdfO0nY ncXQLp0QFvMKmTHedALE5ek3A3HEo63epnced4I9nmNBVohqBhaaWgwfB_HD.9We5GOrAcTZlM1R U7jOA4LBxqs5S14vA8a3vS3zmX027r9.mdbyuEMo.bACUqog28TWW5BzfMwthCz5_m9WGF1N3Azh bI5cgnUhMaoNkUpgiNAOU9Yh4liBWb0Eg9iXQ6PB2msE_hqPqg5AgUaAL8EdgB3wE2Z1dIlpdYPZ BPQMgxmKQDDMBFxZZuwk7mnfY_UR.94aEnW._7X2Fw_i_S2N4VqaHIIDF8KiIL3zfgWMzcuurpSF fi9svzODsZsnYQRR6cb1eSt8K.BPLKVMDTAXNBfk6FmuCKPLXVuHwy4dIyXiszISGs0wfSeDGAAt Pp60jAqb.zb_nRoOXoVHXCzvGziDH9TdvXHjdB5u0SIjJ.KTKCllAyfOtQX8.L35nGN7V53cpBut MOAjIKbwoSYJgW8WI9yM4ICS6xJzq2d9q3ZEH4o.CqOY0yMWeCkfIFXZOpsgdG9RKqE_WYxZbCRv fDKxSINU6ZWhbkgarrRseApYqFHDS.aJv72sa.srikYNzyuyxRpbkR4rSP7x6jn76Ax8aYyD2S_u RJo9cTtwwho7Nn4twFnY8a0W.lfuaFRzTAY4w5a2hCe6FCGMurR.xb6VH8sJvH40OgEOThbEorfD MSUKp_DWU6sqjlyxCXyuNwXoQqLVg.yDxNb3fYFjZFyN1GTHgZRgywoJV734tzfQMGYkYpkK.fSX y67DXkg9eZtN3jWpc_qjv6E9E1SInLDmLPKIM2SQg9JCZg2RhWCPhnoZcyQJJqOvxrUder5jq4.f X2c94NMzf8Si4xWnChTKtbUUTD91fFwoAs3LFEenLtKVZB6khDnojct6toeu44UHIYYAQkrZmp4W QYl4rVKLB1nBkiQUQStTmCxvWTgzvMlg3Wef96mlgsiIbj__n2gj4WJWuyDyDvD_chdPIwhsiJTm oolpUyIOJeRJhN7r7SjLkKVC06cORsjKZ6UQl.dHkyfod5iRGhJNAV8n8e_UT_DFcIbv5B1JQFBf VQQjNkqKB1SGdYZ94kdcm3LfqCHjqDBFdCFHa.LQLysQql_Ofd0hQJB5VZ9qCnKb8I41VDbSZtFw LY72oAVAiwBremMVEWqbAXtz0xEVuJNwKxRQx6S5Mw3LJRTobL6NoSeKL79.VIAYxG3ZqTXoYPnd 8cyKoN6F_RNK5Z8MFSWvJ3Fl2NomO25CUZW4_ZX4dNpwBUtwrJEyV7HAR5bYAiZ30o.f24i8pMon WS_0C0zENbxI5ZA2Qm6nc8iRnSNciJpgkJkmnE1STgOQu68dctlrGCRNHQ095TUKl7criaNjnUSj Kss7.qctSQgbxbvKFwcOIcvIEe9aKFdjHKvb8Ju.ARUeD_CARxvPD7WWRebkyERt.mc8JbuQiboe M3RYeDBfOSGjXseK47MNiVBeeqLlou53udcKqPJ5uBoJ0wIwU90Z_NWEvzOygK1D0CBgKKGuL.Kj 5APkYLbfCjDQq4uGzUXR3HX_cgLWgemz4eXnx5T3qTtuk3w5FFtyikbPSELJwNlS424.fz3qu4Af Ezanj2O827Fy_8ktXHR0oTxd0usZfL3vu6hHsKg8WrNOrdu4IcYiUtTMLbDyOyvmvyH1jEBQX23d nZw_pUW_ILYYNgw1o3V4dp8UU1tELSBrsSSf9V5mrI3dtmWixcZZZdjKy7JgT7nMTwZOJpq8g2yi Y9MQjjniFQBxkUqtIWwH93ij9Xts8GX.723WloeAXRZ8SLiUGAof0ziVEex8BZkWFoV2HrlU5nyb bVbLrHKoGunFlkcAAG9Iwh0DqgS_0F2OW2JI.xrpeoObHg_ITIxl6mk0VMQNPY1voAzXXJTX6uLa KJzdOTV0CCo995SGxBDSzHXEP6Ej80n9zhWuNpV..KOHPweAWJUIAkZKIBYuvP6kuls3XgRmf2IJ rj8EgAgsZqFSLHAy9XDpElXzxaB6xxkxiONnCz3Zv2gsxGKvFYE4l9nBAnTMQqjdPdoYtsj8eD4n uGsWY1qRftxsS_1rMxBAIKLJtv7b8x9OOeSdRvwS1OitrZ5OMeD6CJlp71Uvkk4xuHQ6hxho3erA EatPx2f0md4HtFXOko4g29qTLDO.tfJX6CcLVDGnP.3bpZ16G4kBqz20CxjslcPVRtqQKAGERxwy UtUouXCNCvSUfyRwqbNlBFF9YeO.wzh7wE8Nfnr9W8mABdU31gjVape2UpVPFOn3txa.0XPqf75t nP2xhWQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Mon, 14 Nov 2022 09:34:29 +0000 Received: by hermes--production-bf1-5878955b5f-kkjj4 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c755d50069d4ce5586cddd925e6d76e2; Mon, 14 Nov 2022 09:34:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: I could use some help From: Mark Millard In-Reply-To: <8F50D6A9-0BC2-4BCF-9E1B-D7C9F4C42F0A@yahoo.com> Date: Mon, 14 Nov 2022 01:34:13 -0800 Cc: Mark Johnston Content-Transfer-Encoding: quoted-printable Message-Id: <269A1184-D943-42AB-9B4C-0E6D93178139@yahoo.com> References: <8F50D6A9-0BC2-4BCF-9E1B-D7C9F4C42F0A@yahoo.com> To: crb@chrisbowman.com, FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spamd-Result: default: False [0.08 / 15.00]; NEURAL_SPAM_SHORT(0.58)[0.577]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.148:from]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-Rspamd-Queue-Id: 4N9kfb3FL8z3Gnh X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N My understanding is that HS400 and HS200 requires "tuining the phase" to be supported and this involves CMD21 to generate test patterns used for the tuning process. = https://lists.freebsd.org/archives/freebsd-hackers/2022-November/001648.ht= ml reports: mmc0: CMD7 RESULT: 1 mmc0: CMD7 failed, RESULT: 1 sdhci_fdt0-slot0: sdhci_generic_write_ivar: var=3D0 mmc0: setting transfer rate to 50.000MHz (HS400 with enhanced strobe = timing) mmc0: REQUEST: CMD7 arg 0 flags 0 but shows not even one CMD21: no actual tuning for HS400 (or HS200) was done. An old quote of mine was: QUOTE HS400 needs CMD21 use for synchronizing the command responses on the CMD line to the CLK (a temporary use of HS200 mode to do the tuning). . . . But there is more context that I should have referenced: For HS400, when Enhanced Strobe is disabled, the CMD-out line (from device to host) has no matching strobe to go with it in any fixed signal-timing relationship from what I've read. . . . (Data Out and CRC Response always are synced to the Strobe.) END QUOTE This issue exists on Rock64 and in an exchange about that Andriy Gapon wrote: QUOTE On 2021-Dec-10, at 02:35, Andriy Gapon wrote: > On 10/12/2021 11:51, Kornel Dul=C4=99ba wrote: >> On Thu, Dec 9, 2021 at 11:54 PM Mark Millard = wrote: >>> Note the "tuned phase to 245" as part of that. >> Yep, it looks like in Linux they're doing some custom tuning logic >> specific to this controller. >> FreeBSD only executes generic tuning code, which apparently is not = enough. >=20 >=20 > AFAICS, we do not have any support for setting clock phases at all. END QUOTE I came to the same conclusion that there is not such thing as generic tuning involved and there is no support for any specific controller for the tuning needed for HS200 and HS400. (There is also a Drive Strength setting involved for HS200 --and HS400 has possibly one more Drive Strength alternative by count. More missing support?) I eventually got into the JEDEC standard and wrote . . . QUOTE Looking some more, it looks like the Tuning-Process-Completed-No loop for HS200 in JESD84-B51 that can involve CMD21 is implicitly always there to allow adjusting implicit parameters. Otherwise, nothing changes: CMD21 use of itself does not adjust anything. . . . In fact there is a sequence of steps listed in another place about the concept-explanation that is explicit about: Sampling Control Block of Host is incremented by one step. in the looping (along with comparisons to a known tuning block pattern). . . . It also does report that any other implementation may be used: it is just an example for illustration. Possibly using the center of an observed valid window is mentioned. So I would expect that any time there is not a device-specific definition for how to do the adjustment for the loop, HS200 and HS400 should be disabled for lack of device specific driver software to support the activity. JESD84-B51 does not define any specific method of adjustment of itself as far as I can tell: there is no general/default technique. END QUOTE This traced back to FreeBSD using null_tune and null_return, which were (from old notes): static int null_retune(device_t brdev __unused, device_t reqdev __unused, bool reset __unused) { return (0); } static int null_tune(device_t brdev __unused, device_t reqdev __unused, bool hs400 __unused) { return (0); } e.MMC support can be made operational (with a speed tradeoff) by just not picking to use HS200 or HS400 so that the tune/return activity is not involved. I use a patch for that to allow the Rock64 to use its user-replacable e.MMC . (I've no other context where I use e.MMC these days.) QUOTE What I've done in my patch is analogous to what the the code shown after the #define SDHCI_CAP_MODES_TUNING above does, translated to fit the mmc's pre-existing code structure. END QUOTE My patch to main [so: 14] looks like (some whitespace details may not survive): # git -C /usr/main-src/ diff sys/dev/mmc/ diff --git a/sys/dev/mmc/mmc.c b/sys/dev/mmc/mmc.c index 5fce6cbf47a1..ff6896f35678 100644 --- a/sys/dev/mmc/mmc.c +++ b/sys/dev/mmc/mmc.c @@ -59,6 +59,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -1512,6 +1513,8 @@ mmc_timing_to_string(enum mmc_bus_timing timing) static bool mmc_host_timing(device_t dev, enum mmc_bus_timing timing) { + kobjop_desc_t kobj_desc; + kobj_method_t *kobj_method; int host_caps; =20 host_caps =3D mmcbr_get_caps(dev); @@ -1543,14 +1546,37 @@ mmc_host_timing(device_t dev, enum = mmc_bus_timing timing) case bus_timing_mmc_ddr52: return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_DDR52)); case bus_timing_mmc_hs200: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); case bus_timing_mmc_hs400: - return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || - HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); case bus_timing_mmc_hs400es: - return (HOST_TIMING_CAP(host_caps, MMC_CAP_MMC_HS400 | - MMC_CAP_MMC_ENH_STROBE)); + /* + * Disable eMMC modes that require use of + * MMC_SEND_TUNING_BLOCK_HS200 to set things up if = either the + * tune or re-tune method is the default NULL = implementation. + */ + kobj_desc =3D &mmcbr_tune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) + return (false); + kobj_desc =3D &mmcbr_retune_desc; + kobj_method =3D = kobj_lookup_method(((kobj_t)dev)->ops->cls, NULL, + kobj_desc); + if (kobj_method =3D=3D &kobj_desc->deflt) { + return (false); + } + + /* + * Otherwise track the host capabilities. + */ + if (timing =3D=3D bus_timing_mmc_hs200) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS200_180)); + if (timing =3D=3D bus_timing_mmc_hs400) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_120) || + HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400_180)); + if (timing =3D=3D bus_timing_mmc_hs400es) + return (HOST_TIMING_CAP(host_caps, = MMC_CAP_MMC_HS400 | + MMC_CAP_MMC_ENH_STROBE)); } =20 #undef HOST_TIMING_CAP =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Nov 15 20:47:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBdY659qJz4hjmy for ; Tue, 15 Nov 2022 20:47:54 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBdY553XZz4TSw for ; Tue, 15 Nov 2022 20:47:53 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=UeIvYorD; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="c yyUvop"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.20 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2AF5032006F2 for ; Tue, 15 Nov 2022 15:47:51 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 15 Nov 2022 15:47:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t= 1668545270; x=1668631670; bh=AiUmPzR9HPICP508IeZFbJyrSOEMNOtTsHw 2X8t5lfQ=; b=UeIvYorDOEtEATJ48pzYMwFf3xTuj3K7KPdnJxOnCmcyVGWfggS oO3J9r22sUysVqrVtOGS+GXfmuHDWND5dwgDl6XEIMIqEF0NdcPmG9/JgEsF5rK5 7wh4zqOc6DpgulpEc+mzO+/5TTYn4ecCtkzwt2pZCBf6wQ8VoSd+SmVPQ+U0s16t LvYErDbGTe0Qk0xZVnJDi06ev38NLAhMbgo6uEafvohfNTb0YwllJsZ/CjM5CJ/k dkxialbEEcpvqOVglPPKIfrHcnuyZwA3fw/uADD2qB7d17hIvT0I18CT2nNBBTS9 tBlmv8LPluthvf6QikolcGPWntsKPwnhM7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668545270; x= 1668631670; bh=AiUmPzR9HPICP508IeZFbJyrSOEMNOtTsHw2X8t5lfQ=; b=c yyUvopgJyAENnSRNGKGwGNVosM0l5V0NibUlMjWM2jUaAbfxcg7/sdlpDzL4YUZw j/Ic8waXDondpr10CqUFLvDNhQctDgu4czygUjYCF6/w6oxkDvSRVdXn2dRdQqQC qf9W4mzofatOQ/2px2niOTlJqlX+siRBGBoumfCbltXSJcCTFyOndlyugPvjFYZy f+WUCnrV07R+SAea3bzG9cnwMoWLP+mMSmHBQGcQR6VuprGytuT/R2MiD5poL6Fr KYpiFPC7RV5GwLkadTnHkG3fO3xySFiuEUtvIUAHP5N7jaW71IsyKzvniAsxystO Ommzt+gjxlmaGijsjFS6w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgeeggddugedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesthdtredttd dtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgrthht vghrnhepveduffeivdfffffghfegfeejfefftdeiteehteekfefhvdefgfettdeuheegff eunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhho ihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 15 Nov 2022 15:47:50 -0500 (EST) Date: Tue, 15 Nov 2022 20:47:48 +0000 From: void To: freebsd-hackers@freebsd.org Subject: pf options in kernel Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.02 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.92)[-0.924]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.20:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4NBdY553XZz4TSw X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N Hi, Is there any advantage to having device pf options PF_DEFAULT_TO_DROP built into the kernel, over having "set block-policy drop" in /etc/pf.conf and "pf_enable="YES"" in /etc/rc.conf?0 tia, From nobody Tue Nov 15 20:53:19 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBdgd6Hl6z4hkHQ for ; Tue, 15 Nov 2022 20:53:33 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBdgc3fgGz4VVb for ; Tue, 15 Nov 2022 20:53:32 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of bsd-lists@bsdforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@bsdforge.com Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 2AFKrJTi032687 for ; Tue, 15 Nov 2022 12:53:25 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 15 Nov 2022 12:53:19 -0800 From: Chris To: freebsd-hackers@freebsd.org Subject: Re: pf options in kernel In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <956b5ca1d8632e9a497cec80969096e0@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_9969d2ecb9fe82f79c4e0fa74b2f18a7" X-Rspamd-Queue-Id: 4NBdgc3fgGz4VVb X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; MIME_UNKNOWN(0.10)[application/pgp-keys]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; local_wl_ip(0.00)[24.113.41.81]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; FROM_HAS_DN(0.00)[] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_ip X-ThisMailContainsUnwantedMimeParts: N --=_9969d2ecb9fe82f79c4e0fa74b2f18a7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 2022-11-15 12:47, void wrote: > Hi, > > Is there any advantage to having > > device pf > options PF_DEFAULT_TO_DROP > > built into the kernel, over having > > "set block-policy drop" in /etc/pf.conf and "pf_enable="YES"" in > /etc/rc.conf?0 six of one, or a half dozen of the other. IOW no, not really. :-) > > tia, --=_9969d2ecb9fe82f79c4e0fa74b2f18a7 Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_9969d2ecb9fe82f79c4e0fa74b2f18a7-- From nobody Tue Nov 15 21:00:48 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBdr45MhJz4hl7j for ; Tue, 15 Nov 2022 21:00:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBdr44pqKz4WYW; Tue, 15 Nov 2022 21:00:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668546052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GAZIbAs0YUIh8latk5TFJ2psWtmBNiIX00SsyOK6IyA=; b=AgrDUDimMmrExOww96PIovxZZSqRFXEseJz0eO0WpjHkuLrHcPxvx83tuY3ATODf9DLSOt /mzI4dH/b6Qxv1YpHO2Vv07jNV98AAQyHE6JT3hVCnqyDg0eoy1XUJOhdisAX7zJVwgoRq cvFfBK6FMuxVh63wSKpkWWj1E8R811ugpCAGm1LyOdGq6PhRT3hrNOwQmM59NyT51d+T1U BQ73jVLO2LkV5fNwgrmAhaJaMdeGRLasq2vorGLxps6ptZM597xGtuLuPWSNA/VRgOAZ2o 7ifDAgM/EWFwPX7WMl/jRjavP+swDnBNhcY4q7lv5cndyItFEvFWmrTrju3/cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668546052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GAZIbAs0YUIh8latk5TFJ2psWtmBNiIX00SsyOK6IyA=; b=N8YL+D2SYuiOv/vWcIZGnmiFQ21NEMNpsJNcsnsrtJS84U1OgK9RVjwW6RClhH6wGiTkIX r+aMsNYc8YmV8QBvt2IVcUEXOYIY1st1Q6cuRgB/3Sq/xy6K8qNAOm5WPiL9CRhdPWQOj+ qQAnX17+zHa8ekxM+TJyO2DN6pDeDD6nwm/CviqO74TzR6gRD23lSgXg9RwFJFubg6lKnL VE4GWEZKmvM50WCJx+fKTHfaoQNiMUPlycl0F1Xp06atGaHE/aclv7nJJMjMMB2FVw3+0Q et+rQcuWhNhp0im27j1jvk8x7gIRbEq6G0TMnnWq1rdBXexYxM1uRPBNJ9GZ3Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668546052; a=rsa-sha256; cv=none; b=sv8igpVB7AVJz05gjX0IWMPU0lu8Z3Ay93PR3q8k9bU/3Ew84k1n3QxD0XKk+mAeg7yf0t 3nVokF0KypTKADFe50suepjp1p/I+vsm44qkixJTFaTuBv/RHVJqRmgcf76ppFJSdiGm6q UZa2JSLUTxit4vxmV0ExWekj+SykbdtqjF4wH7MPz3x4dMqXHlGX8LwIOB/Wmbzn2FyxqJ tFY2KQGtvrtbOt82R8jGtuyDtR3TC4KajPljKC+T/WTVIr1blV00CIKbEORIl1AJ3IM70Q Xy7mSo1aLmFMfn4/z9rM8v4JV5w4GeGeoNRfq/4v2fcdE9k/ZbKXAiB2KpfDEw== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NBdr431tVzhsm; Tue, 15 Nov 2022 21:00:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id B75EC3D47F; Tue, 15 Nov 2022 22:00:49 +0100 (CET) From: Kristof Provost To: void Cc: freebsd-hackers@freebsd.org Subject: Re: pf options in kernel Date: Tue, 15 Nov 2022 22:00:48 +0100 X-Mailer: MailMate (1.14r5918) Message-ID: <066FCA78-CDC6-4178-AAE1-6F9FD8A665CB@FreeBSD.org> In-Reply-To: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On 15 Nov 2022, at 21:47, void wrote: > Is there any advantage to having > device pf > options PF_DEFAULT_TO_DROP > > built into the kernel, over having > > "set block-policy drop" in /etc/pf.conf and "pf_enable=3D"YES"" in /etc= /rc.conf?0 > Configure this in your pf.conf file, not as a kernel option. There=E2=80=99s at least one known bug with PF_DEFAULT_TO_DROP: https://b= ugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237477 As a general rule you should avoid custom kernel options whenever it=E2=80= =99s remotely possible. Kristof From nobody Tue Nov 15 21:02:50 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBdtP5TDGz4hlGg for ; Tue, 15 Nov 2022 21:02:53 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBdtP4x07z4XZx; Tue, 15 Nov 2022 21:02:53 +0000 (UTC) (envelope-from otis@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668546173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y0oiZFPYI6oq0xs+lQjamrdcByafcbbIfboN59PE8d4=; b=BFZ6LPKpoBpUQmsPuSlZZJZfylO0MLJO4m6j9OLfNCN568l69xnhidE3MDc82o0OJDsHQ9 Y8pF6XQ/oGBz5elCxOnbvka95jRZQpchdnxyInPwOkKHO4drZ25ayhvYr89+ROqO7OGSS6 26N2h+IGilS6blRTDA6lv/jNCKjI9a/MW6x9ETUDSSCGttuqxPA/56NETZcKZOeMCfzU0M 7FvCUWEXFGzzugfqSh+K6iZnP6i+VX7WWiBLEQ65YsvvSU0EKfk9cRCHqamtXzCloyx0Qj uZwHOa/ymtIMjtNEfhGcp4ZaZFhw/vHBBHq8LI/9wO8j9n7LtidfYZ78y3cZLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668546173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y0oiZFPYI6oq0xs+lQjamrdcByafcbbIfboN59PE8d4=; b=bl1YCGywho8TpegybX9RaE9bMZToeLtEvJjmQAK/Ks5MGGcxgOiJOpqJPwuZtUCtKPrCQR Moq0cOg586crZrXHuKoxRAYDzJ0TmxjrE+t40cJcsPsJklil1prJ32r6w5A3S6v9lga3I7 7Si3QQwmUDhlwkiIDD27alvEerxvQbcNxqlhF/zZwKtTJCTlpS97gm5zpOyjG/Jdkm6HfZ G4DQJAiIA6LmWS4xWpD40Fu1DPPocUIxQwKTxPHV02/BaETFO6ALFiExTMbwONR4c4eRFf crgvz+Sip2pBp3spDtvBE8V2Djafe866Mc1DLvdB7ziZVjybwLvvwKqIJMikhA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668546173; a=rsa-sha256; cv=none; b=Q/uSQOv2tZqP2sO8Z7pWHPEtGRvIpS1AtpcTIEo2IuQZSug8hadTBRJ1tSkNYyZXF2KqbZ Hz9wVNR0PKTpTddryMhptieAwCktT9/72W4xVYEUxcPr5EdVhMgfz2vk/FolJ5H8fn7Gvm saD3yxIRsXU4mGgnWdCvQTzXWBuF6lKfP/UiIT5LdptM/xGuC1bAevCmHI0aDx7KZCe1gA DZ+59moNPxrP/VDyxK0zs1Vtrj6s18/HBrWTtZaahb3tBuLK41f+4QELufyoQobtEl1E7N gkK5bpaRR9uf0Eaah9ElHYytHGQJRJ7oFfKTmaRxMze79/2RNHCBSsBFdUZHFw== Received: from ns2.wilbury.net (ns2.wilbury.net [92.60.51.55]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "svc.wilbury.net", Issuer "R3" (verified OK)) (Authenticated sender: otis) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NBdtP3JwdzjMw; Tue, 15 Nov 2022 21:02:53 +0000 (UTC) (envelope-from otis@FreeBSD.org) Received: from smtpclient.apple (gw-upc.owhome.net [188.167.168.254]) (Authenticated sender: juraj@lutter.sk) by svc.wilbury.net (Postfix) with ESMTPSA id 288AF45D323; Tue, 15 Nov 2022 22:02:51 +0100 (CET) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: pf options in kernel From: Juraj Lutter In-Reply-To: <956b5ca1d8632e9a497cec80969096e0@bsdforge.com> Date: Tue, 15 Nov 2022 22:02:50 +0100 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <96B5F854-DD69-478C-BAE0-2E753AA7B8D7@FreeBSD.org> References: <956b5ca1d8632e9a497cec80969096e0@bsdforge.com> To: Chris X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on ns2.wilbury.net X-ThisMailContainsUnwantedMimeParts: N > On 15 Nov 2022, at 21:53, Chris wrote: >=20 > On 2022-11-15 12:47, void wrote: >> Hi, >> Is there any advantage to having >> device pf >> options PF_DEFAULT_TO_DROP >> built into the kernel, over having >> "set block-policy drop" in /etc/pf.conf and "pf_enable=3D"YES"" in = /etc/rc.conf?0 >=20 > six of one, or a half dozen of the other. IOW no, not really. :-) The difference is that when pf is being enabled in rc.conf, there is a = time window when the system is =E2=80=9Cunprotected=E2=80=9D, while when pf is built into = kernel with PF_DEFAULT_TO_DROP, the system is not exposed to, potentially, hostile network environment = (as the rules are loaded as part of rc sequence, but you must explicitly allow = traffic). otis =E2=80=94 Juraj Lutter otis@FreeBSD.org From nobody Tue Nov 15 23:13:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBhmq6jBLz4dL4n for ; Tue, 15 Nov 2022 23:13:15 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBhmq3g3Fz3MDs; Tue, 15 Nov 2022 23:13:15 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 2AFND6WQ072717; Tue, 15 Nov 2022 15:13:12 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Tue, 15 Nov 2022 15:13:05 -0800 From: Chris To: Juraj Lutter Cc: freebsd-hackers@freebsd.org Subject: Re: pf options in kernel In-Reply-To: <96B5F854-DD69-478C-BAE0-2E753AA7B8D7@FreeBSD.org> References: <956b5ca1d8632e9a497cec80969096e0@bsdforge.com> <96B5F854-DD69-478C-BAE0-2E753AA7B8D7@FreeBSD.org> User-Agent: UDNSMS/17.0 Message-ID: <0c6e5a22fc822005d2fae06d9bb6e8c9@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: multipart/mixed; boundary="=_69f512c07b479520845cb677deaf091c" X-Rspamd-Queue-Id: 4NBhmq3g3Fz3MDs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --=_69f512c07b479520845cb677deaf091c Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-11-15 13:02, Juraj Lutter wrote: >> On 15 Nov 2022, at 21:53, Chris wrote: >> >> On 2022-11-15 12:47, void wrote: >>> Hi, >>> Is there any advantage to having >>> device pf >>> options PF_DEFAULT_TO_DROP >>> built into the kernel, over having >>> "set block-policy drop" in /etc/pf.conf and "pf_enable="YES"" in >>> /etc/rc.conf?0 >> >> six of one, or a half dozen of the other. IOW no, not really. :-) > > The difference is that when pf is being enabled in rc.conf, there is a time > window when the > system is “unprotected”, while when pf is built into kernel with > PF_DEFAULT_TO_DROP, > the system is not exposed to, potentially, hostile network environment (as > the rules > are loaded as part of rc sequence, but you must explicitly allow traffic). Your "window of vulnerability" is limited to when the (your) network comes active. Loading pf(4) and its rules ahead of that will greatly mitigate any potential problem. I have servers with both "in conf" && "in kernel" option that are always under heavy attack. The difference is almost imperceptible. The convenience with using the out-of-kernel option, is that I don't require rebuilding/installing a kernel to make any changes. --chris > > otis > > — > Juraj Lutter > otis@FreeBSD.org --=_69f512c07b479520845cb677deaf091c Content-Transfer-Encoding: 7bit Content-Type: application/pgp-keys; name=0xBDE49540.asc Content-Disposition: attachment; filename=0xBDE49540.asc; size=5028 -----BEGIN PGP PUBLIC KEY BLOCK----- mQENBGDTzGEBCADHlXdS4V57s2soaEK2wi3o9rr9zo7to/giBSxCpFYJxOnPkL5A 2ibbvflrL8sWvAczx47wgDS7iIhzICBBRdnXtcFGnoeeriV27LSn+PcpnIB+DaWZ xe+6TDC0Z0JUJ7qDTjUBFzhnQGYlrVvc4WbnWTjJaB1LEwgIX8JqX5S3SX0/oXgs +OtqDuENZ4/a5te5xPnspTv/5NJHjqYGxjHP0Vw0KjRKS1AoJ1SBPSMQV5373AX9 5NzFS+CjqeQhjfHFPeRajQ8t4T6eqhKA7LtKMO1egeAwNehk9ZoEqEBT2+ojuKUd oSuzqvhhx+eUIYLFqoPSzMKR+YbStzergsbnABEBAAG0KUNocmlzIEh1dGNoaW5z b24gPGNocmlzaEB1bHRpbWF0ZWRucy5uZXQ+iQFrBBABCABVBgsJBwgDAgQVCAoC AxYCAQIZAQIbAwIeARgYaGtwczovL2tleXMub3BlbnBncC5vcmcWIQQGJAsyyBlk cuwsSYsYdR58veSVQAUCYNQl+wUJA8LAmgAKCRAYdR58veSVQN3NB/sFTeXrZeDk ml/dshET8QbkOPgXlnibk8+Mauf+y9LjS9WT7R8EmqhK7T7aw115JQ1RWTM6kpQM jyDBjYF7piJEpNKI9YDeSnODKir1fWQqm9+wd68wAKGvV4m8kg9uOHCvXG4J++MG zDFH+PuGVxKirFnaz46DpS0Zw7wTtjNiNFvCooYov3IeYGfqcchd3hwBuXgWLexZ vI8JW7lL9oXl7B/wcbSxg9rwy6/QLYGg6sEtYRcFYyvQWefSMJaLWjU/pZN2iSxM lXm55iZv1BXHupfeD1ldRiGs6ejrcpa8+U1ju291WbLzcIsU8IDljeW9/WB2dLFT hJmY1wRk158AtB5DaHJpcyA8YnNkLWxpc3RzQGJzZGZvcmdlLmNvbT6JAWgEEAEI AFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9y ZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCaAAoJEBh1Hny95JVA aI0H/AlJAOfc5TcMKa479Itw31mwccKb+u0DPN9Gkm/RfWIBjeqqozxCM8G8jVFr dt/J6KmBO3dQtRZHlXdD57RAfDDl5Vm3uws0s+UIFOxMiua/YxyuDcKLsE8Bjkzx z+vuJ8f6cg4WlygPr3bo3l81AOuU/wOsTrNkQvVJxgATlooATSVxs0yNn2uoso9f nhMGUYsmT4c35JYh0k6Lq7Z2LS+ELipMTQ7M7iCWSP1O/zSEvPD4NBo52xCvjLka KcL4fRl7UN+6ouwGr5aUn83tztE/IR0AK45gFvL5yxI4g/zm1t3j2+hhhW1pBU8w uQWkD2DyLTWy7xs1uVF5m1ojHp60H0NocmlzIDxrbm90QHRhY29tYXdpcmVsZXNz Lm5ldD6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5 cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX7BQkDwsCa AAoJEBh1Hny95JVA5m8H/iENaTD4j5QHfaHfiDIdxGx36GnETyRK0vAzr2b6pzG+ 7VHNCm4ZfuMsXDJ1ZD8fjTipvg0f4w31xCQI0NgNdAqudBqE075Jwcr9pE9j8VN1 Nvejto01cgLHODbLPhokrkFz1K023VjCdy5RaVuCZ6ajTif7Kq+BEOE8TumYx4ly zdhnh/9ICohqfVvEMh347wI36D7HuezHB773hOsHdqTy9T+0Qu0Vu+wud45MUy1f vRF11OkJFtKL0bh4yMSGVY1xte1Mt/qC6rd43TDtAW3ekw1o/exh764kp7XXQsmP wwe4Y040PZafcygJlEW9bBtjjxKnzDTvqeb5dMi6d7a0GENocmlzIDxvaWRldkBz dW5vcy5pbmZvPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgECGwMCHgEYGGhrcHM6 Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUefL3klUAFAmDUJfsF CQPCwJoACgkQGHUefL3klUB74wf8DSvT36bYZp7oqZ+35HNhTekJ2dbTzUhauF0S +Z9R1AGnNnINgua75CyQGdNCIgcZxo4qG9sePl7SllQ9i0qhmiw0mzmvky8bAZQV V/2Coc1C/81b+PI19VczYrbZC20jApsnbAIkKZgSh9XQoiLd3meY7G2lX2k6CXYL xSeBEh+N3BU8vLxExm82U71Qzm43u0kA1TlbTSqpBvg/tfAzTCsYQLSlB6b4ZL2W D6U7b7ZYF5oZNonVNWSHxpjUN3Evkta9xWS2+cgYQdlP1/ku5w5ZWwzmYG7awh0J /YuSNIp6Ks6D/PSBduu6XbH+FJHaXmq+ZCKpNBh5EKH+GhOfq7QfQ2hyaXMgPHBv cnRtYXN0ZXJAYnNkZm9yZ2UuY29tPokBaAQQAQgAUgYLCQcIAwIEFQgKAgMWAgEC GwMCHgEYGGhrcHM6Ly9rZXlzLm9wZW5wZ3Aub3JnFiEEBiQLMsgZZHLsLEmLGHUe fL3klUAFAmDUJfwFCQPCwJoACgkQGHUefL3klUC3GggAo4Y+hslaoV7Namp7qWYZ Vei4ZwPfsYW7/HtmFORSGV8C8xR+LSkwzN1Hc7Qxvwv+DXuk7Hzd1Ag/xe8XhbNG /NMrXENY/8ym9TRbxtrBIhQyhkyShSUT+N+g16GRNZKuNL2MOIHc/RCS/YyyaTtu TzIxFbP7Gb2LO1LiiZsFVOGirHfxyiww7CAm3HXY2K4smOiKs6swZMpStVy3dd6A BcB1LPGs3ywDglFfKCRbVmjsPgsi61r4kUBVO6ML7lAmPDXLXOa+7iAtBN479QxC MVeH3Y3SMrvu61Vyf1xL79rIznU3u8C34zfxqsoIV0zCZe2YDLbFfLhZYqatYYEo e7QjImNocmlzLmgiIDxjaHJpcy5oQHVsdGltYXRlZG5zLm5ldD6JAWgEEAEIAFIG CwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3BzOi8va2V5cy5vcGVucGdwLm9yZxYh BAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8BQkDwsCaAAoJEBh1Hny95JVAkUEH /jkzYrRh7muqoebwEgVeULzPbAs/nYJm9SMME2ypB2FS8kusO7lE+33UJO7PhHkJ 0nJ+tPfP8UV+fCzVjKjabzpvUGuiMWKRZEK9xNoxwi/epOrRw87msHA2LPqEob+F sVh09Nc58s75koUgSYp5h0FjsLK0+fwsQ6PtTfpY5W6JJVJRQnMwGKk5czrukBSM 79kJvphgul2xuzqo5K7rM98dL75AwCJmJZnbyXpUJIhtY/G01nURupBiQGgNixYs Zeo6OR669TFrMRWxueXtlHD0WaX7JNSlR5uyzpVaDCH0Kxa6ozmZtD+a6dAXg630 zbLGHg51JIm38Uvi1i47Jaa0KCJILlIuIENvbW11bmljYXRpb25zIiA8ZG5zQGRu c3dhdGNoLmNvbT6JAWgEEAEIAFIGCwkHCAMCBBUICgIDFgIBAhsDAh4BGBhoa3Bz Oi8va2V5cy5vcGVucGdwLm9yZxYhBAYkCzLIGWRy7CxJixh1Hny95JVABQJg1CX8 BQkDwsCaAAoJEBh1Hny95JVAABoH/iOWA+9BKxLIAIFgW2nxTFDrGvbxXL/mVSFt SOInKX8UqqfLCcikfpWLsj2D7mg5rKFMCu+31UYYlnrXl4YY1qruq0vh41L72qNy yHYol+xW4BSbZXf2q2ph7+lnPsFoodw7acVun5F8M8NH0roo5AOSbgRlK69ZFIcq fDEJdtk4oul7pqGArdeTCCdrSaeR3zrRN8P0PDOkGKSdlpeOE6XHnbbmAPZIhr/9 KsSpX1BGyipda3k5kOB4TsGVo+cRJMkK+GMpsZ+lJ7ZzRbjHbC+b52TiAIjMtXCK 3A3LrDUeMoJwvRKoO1tzquF6HqHJSg0ArZOvAB3BHlwUyUtA/o25AQ0EYNPMYQEI ANFpucNRdYEOubTNluoK97N9JmDb0WRXPPow+3XfBom6ZBSrWqNBgqDbjxSsLB00 QXbA8EB5W/Oolp/0epwEtgNAxyKVPowE/un+rY1PqvGjeAR4gBhY9Za1Lg1Q3vnR /WzsY7RIQCqhWUbfdGn1u6r/EgTBVrwUp4U/3ggfSz/PcUt4pUhlgxfYvjSjOgEZ wbqaQIwWud11FKMARNAUJzvJL/fDGeKLMvgRUwynIDGzCq7e67hhEEo5jwkZ0gEl 8RxXHKFuYkbb/q7rpdifXYYT6QCFlEZhiRbtH5Us7kgKuRD2XUFEQnN4U/rxuydH 4XOP6iOhiZfYnK/y9HBeRCMAEQEAAYkBPAQYAQgAJgIbDBYhBAYkCzLIGWRy7CxJ ixh1Hny95JVABQJg1CYkBQkDwsDDAAoJEBh1Hny95JVApBsH/iEg2ANRkHByfXB+ sH3PMf2Jsg5NSuj8OiNeKKGGIKCJkSAPjtv5rvKLNcvIcTR5Vnhr0e6AteFcK2te iFWDmj0QuFoQNvIOHQ3nHBPSpai2Ubq12nvYfg4bYK28AMi4xPMssgQ8awFgAI2V k9okq5XwC0Cc1MGhupEWYYSaFLIDQvFvRRSw1Lyc/W3SKa4d2dgesIPnB/rdv0Zq u8ftsSmurKxA2hQeNIcn06Ew7AbWUIjFX/bDXJlg/3Sj/spU2ur23TmaADBKhT5P DvfdaFTkk0SBfpN1j2S0DNXBHSrWvRp15zZmU4hwELiUY/H2/j/XpOGV3Q0i2iob 1hJ30C8= =aMQi -----END PGP PUBLIC KEY BLOCK----- --=_69f512c07b479520845cb677deaf091c-- From nobody Wed Nov 16 00:58:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NBl6l41zjz4fq2k for ; Wed, 16 Nov 2022 00:58:55 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NBl6k45wxz3mfq for ; Wed, 16 Nov 2022 00:58:54 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b="x jI+LRr"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=M03yekMc; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.26 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E14C45C0223 for ; Tue, 15 Nov 2022 19:58:53 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 15 Nov 2022 19:58:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1668560333; x= 1668646733; bh=S15iRpWNQyohcUf0GmFXozCobm55DM6royVh17DuGac=; b=x jI+LRr3YUzBP10jtbg/UtgVhkMMKN58oFGImw2HV/pQQ77ux6UT6tDKP2SkqS7NB fVG+huDDdTnpE5TS5FEprbjQkZ/EufnLMg+09/U88Nsanka+mTwlFzh+YEl9ZJZm FL67BzsMMp1x8HKTh9edP5rguAC3laA62NAWIp7GQfOKDKdvVBh8h2rK5x97ikwd wh5o+wUqfPU42vDR3nLh3ETBASh3XA/OvU98vQaD93SGc2njy529S3w1NDmtR24Z Mcc86k0u4aq08e/6E+YNoKePf9UlWWs9MKM0ZkuMapJB8BxN4OeTat7UfFc47ujA 80WjvSzb4wA9vz3HPXM7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1668560333; x=1668646733; bh=S 15iRpWNQyohcUf0GmFXozCobm55DM6royVh17DuGac=; b=M03yekMcoX7BdkWjm VIhaozt4sRJx7TmUvSOHkQoM7jJdWjjSZOvXMzZGPfmzFQ5AqM8Mw1HfEFfau8s0 tDnaOfOFe7wE/JMc3L+39iEdnxb7humZ0yKimc3e2ooSAYo3FcuStrKVmKHGU+fT r3N9KYPlPlf3vtBIF0prGpga2x0XGBuv0ORe3zjvFjvkdnXVBLTry8I5sTgXIrnQ b/mT2PlTYe0VNRlzvwgP3Pp8cmd81BAucb7NEx9RpEFuIrG2XklBpy0JC9iUcgSm swJKkIJ2mDqUb9KBKkZzjGiGp7+6wm+fosBSYMmMgcg48H90HxfOWyJxW1DYcfa4 jNiPw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrgeehgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtugfgjgesthekre dttddtjeenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhephfehkeevtddthfelfeefleduhedtgefhhedufeduteeftdfghfefudefhe ejhfejnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 15 Nov 2022 19:58:53 -0500 (EST) Date: Wed, 16 Nov 2022 00:58:51 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: pf options in kernel Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <066FCA78-CDC6-4178-AAE1-6F9FD8A665CB@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <066FCA78-CDC6-4178-AAE1-6F9FD8A665CB@FreeBSD.org> X-Spamd-Result: default: False [-3.37 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; NEURAL_HAM_SHORT(-0.17)[-0.173]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.26:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.26:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4NBl6k45wxz3mfq X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Tue, Nov 15, 2022 at 10:00:48PM +0100, Kristof Provost wrote: >Configure this in your pf.conf file, not as a kernel option. > >There’s at least one known bug with PF_DEFAULT_TO_DROP: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237477 Thanks, noted. >As a general rule you should avoid custom kernel options whenever it’s >remotely possible. I've always thought having a kernel trimmed to only what is required, from a security standpoint, diminishes the attack surface. Is this not the case? -- From nobody Wed Nov 16 11:40:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC1Ld683Zz4hgBQ for ; Wed, 16 Nov 2022 11:40:09 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC1Ld57Btz49wC; Wed, 16 Nov 2022 11:40:09 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668598809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NiNhrpJQGIBdhgkz3TSmdrJ6sviSXGgNcvcSBkUyeTM=; b=DPnu5xhLVTEeH7rxF3najWOfVIIz99N94pDXxcaapjn1ucV7XCB4WTUc5hVRaZqFzn+HxE J/u4raFbB3vJWfXspiFq7/lpJx+bSlgE/LCmGHywhgoezUbHo7Yr1h8BgrE1WuZEjdQk8w YfeBIRBLePazF/9xCI7m3SwkD5Xy2dHZgM/USNL3dfiUx3aNoYkPMLRmiNQJuHvDq0ES/C lsOmEijdMhZFCmfJbfL7Uck4JQQdUpXzSVUTDYB9cYaQFZOuj1teDHaMt67RDU0d8oyWIv PbqmGddoBUYeeNwsQoX/2TA2rQu/W4TAytiEnYkgSGDrqIAJ1/abO/+Lzy5Osg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668598809; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NiNhrpJQGIBdhgkz3TSmdrJ6sviSXGgNcvcSBkUyeTM=; b=C/3Rp18JvBcaurKStF+FQZ25OIASZ+B3efr7Oc73TiATVg+Ypelr8DSu5D63J+WQdGU9nc BxyTpLHO4ikB34q0+5MnYGwc1tyZCYBXUskHHj/fqFr4nc3FF2kOZQIMvnscqydf1vZofJ sQrPWZzdVUB5aZaZVukSise/AKvK4SO7AOC95Uix4qJF82t12Yi7XtZTGwpiBgVWdul4Bt u/tsGSSi5RsShjkzrxYDxoWGfPBVlLM34vihPEipGUMwJFiviiLJ84kWszV7dAO7P+asnZ EzSG/bTm08V+cmAE5JZelgaXYcWPtN/oJ/eW9FTNN78oYw1yC0lflJHVCTc1Hg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668598809; a=rsa-sha256; cv=none; b=qWYwQW0Qk78UdET7Bz5uTxLxpgFgjdIXdwq5C8S42xdD0szuPUe3BG3heWlB2lVhyd27WK Kjw6j31np49SR9xuGfQ9DObAmpXdjIXgIRVvMqAw7x0zYpN8q/HrpVEoatSfh6OjcGctMD O1y3tT8A4MmlqDsbA6HZgFteKERpRAMnWXSiQursaw9rDvn8Hko6iRRxhjywz0UTXmZ9k6 WE9WLwN9Wq7Z525KRQCOww42Yp4hjeC0Sjz3gHNeqp0rqhWMoslPKssrUcRlbTL1wRXu7S GTo5Ca5HCEc3zlFuyiZnZ3NVHyE9Go58i9nhTZKlB/U8LgaF1DSPDvHx1Rnz4w== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NC1Ld3LFhz10q3; Wed, 16 Nov 2022 11:40:09 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 8B22C3E2D8; Wed, 16 Nov 2022 12:40:07 +0100 (CET) From: Kristof Provost To: void Cc: freebsd-hackers@freebsd.org Subject: Re: pf options in kernel Date: Wed, 16 Nov 2022 12:40:03 +0100 X-Mailer: MailMate (1.14r5918) Message-ID: In-Reply-To: References: <066FCA78-CDC6-4178-AAE1-6F9FD8A665CB@FreeBSD.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On 16 Nov 2022, at 1:58, void wrote: > On Tue, Nov 15, 2022 at 10:00:48PM +0100, Kristof Provost wrote: >> Configure this in your pf.conf file, not as a kernel option. >> >> There=E2=80=99s at least one known bug with PF_DEFAULT_TO_DROP: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237477 > > Thanks, noted. > >> As a general rule you should avoid custom kernel options whenever it=E2= =80=99s remotely possible. > > I've always thought having a kernel trimmed to only what is required, f= rom a security standpoint, diminishes the attack surface. Is this not the= case? > No, you just end up running a unique configuration not tested by anyone e= lse. The defaults are the defaults for a reason. Only deviate from them if you= understand both why the default is what it is and why it doesn=E2=80=99t= work for your use case. Kristof From nobody Wed Nov 16 16:17:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NC7Vm2T3Lz4fgLb for ; Wed, 16 Nov 2022 16:17:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NC7Vl412cz3Bsf for ; Wed, 16 Nov 2022 16:17:35 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.210.175 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-pf1-f175.google.com with SMTP id z26so17932831pff.1 for ; Wed, 16 Nov 2022 08:17:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E13ZRVr0TLneavbvD7NQit/HgXxRWqFF0yjoh/FPuCw=; b=qDuW2bPWnKKGIhgnWGroQ7T1+dfth9UCALcOY0Jkh810NfJGvuTC/b30hYYSvSuLIc 2P0petDPRwnaFICuMvXtBkXbFrPjmc1eqDVVcrGINLNMYbiLwPYupmieFEGi4Xm8zzfx G6Pp9vqGyZmbIjDpyZrHpV6ZCJzemVA+itMe043dO+2G7+Fo/fwsEr1Cpi9UFDfhg6UB U9C5kddasX48CW4hWZezUbkYB72Y1HCotB8PltNVtKB0eeaB8U5Gx3MFieiS04jmKzzL cRkWsRHv+ES8ZHca41YuoLuaA0bf5CXnCvRfnwEFXBVkQeJvDfODVpbILWfFe6rr5ryv tEDw== X-Gm-Message-State: ANoB5pmV+zDzGtiU3+a/kboK/r7knr2N9do2I3/Q8pM1jG5QspAOMOXe 9CrPnkmNuxXj/E2Cl1PH58T+MRFC2GqyT94RX9k4iPXSsJg= X-Google-Smtp-Source: AA0mqf6GchU00FkkGrafOuMmkHhz8hvnItnyUH14Fkm/ximscRo8u9pFyoHAvNoqDTFa2viJr4K3LX/f92myUcZCF2U= X-Received: by 2002:a63:501e:0:b0:464:85db:29c with SMTP id e30-20020a63501e000000b0046485db029cmr21069203pgb.600.1668615453124; Wed, 16 Nov 2022 08:17:33 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202111260909.1AQ99LY2023877@gndrsh.dnsmgr.net> In-Reply-To: From: Ed Maste Date: Wed, 16 Nov 2022 11:17:21 -0500 Message-ID: Subject: Re: Retiring WITHOUT_CXX To: "Bjoern A. Zeeb" Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_LONG(-1.00)[-0.996]; NEURAL_HAM_SHORT(-0.99)[-0.990]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.210.175:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.175:from]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NC7Vl412cz3Bsf X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N Reviving an old thread, On Fri, 26 Nov 2021 at 14:06, Bjoern A. Zeeb wrote: > > I used to disable [C++ support] in my images but started to need devd > and that is really the only reason its there currently > > #WITHOUT_CXX= # devd needs it Now that libc++ is in /lib we don't need to force devd to be statically linked, and I've opened a review to make that change: https://reviews.freebsd.org/D37409 This will save about 1MB. I've also refreshed the WITHOUT_CXX retirement review, in https://reviews.freebsd.org/D33108 WITHOUT_CXX currently turns off all of these options: CLANG LLD LLDB LLVM_BINUTILS GOOGLETEST OFED OPENMP PMC TESTS and avoids building these binaries: devd dtc kyua rs users zfsd From nobody Thu Nov 17 10:10:32 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NCbK24MZvz4hkZc; Thu, 17 Nov 2022 10:10:46 +0000 (UTC) (envelope-from droidbittin@gmail.com) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NCbK15YyCz4FdV; Thu, 17 Nov 2022 10:10:45 +0000 (UTC) (envelope-from droidbittin@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="OF87s/2Q"; spf=pass (mx1.freebsd.org: domain of droidbittin@gmail.com designates 2607:f8b0:4864:20::431 as permitted sender) smtp.mailfrom=droidbittin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x431.google.com with SMTP id b185so1302888pfb.9; Thu, 17 Nov 2022 02:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=au/bdHBlDQ7qWhjgRo4kGOUKMU92CfZOTlpwsBlHf04=; b=OF87s/2QhAbzDAbuyeHTcRQ87wGCFWruhNDmkORb7sNlpRpis1L7haINBXGqBnHS1T h/6UiAc26nTbCB13KYaFedLIheC4N53jMSzjq6PBwVuPmlxAElvMTW4ktO4E7upkLOjP jYWwNGlNrn3jG8mtoPxog8pRntfbnBVH2psHIf3VpnfK7Jz/Z7jdxUv63LGyVEuVK8+6 mCtrUVWJgjsoUg5I7TQktxf+SLMeJELmk3xQxZ7KHY+cnoYkViS2uE5hR62b7FFQbdbE dRYdQhWxwlYYFpVoDzPzuy+HrWa6u6BvWX7Rr/rJtd5+EdxLUSPfn1CsNAaBJZejQE5+ NM8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=au/bdHBlDQ7qWhjgRo4kGOUKMU92CfZOTlpwsBlHf04=; b=sBDCLUpuIUVzrpeRhJPvEemfujmCWAI+ZgJ+POhdIdYXeieuMWb+PanZTlcUpEToSZ c55i3bXOjRrNidk0HtirEoLbRewGjJkxooaQdFQdj8oL0mTrE0mxiGi076+nOncAs5NQ q77oJdjzeWBeqKWH79YAMVMtOf+KLpwocMxqeeWpJZFm/zOqgASF0Gf/ky8rfigM2yOt 1MdWvI5Ecva90Bq60TansFU0spVBxWcf5vIM7PG3WSdfDJj0+Js8QL7sBNODYUQFFSd+ VDwfClFwr17WgbARre1jaNG8qRfO8VBmErd4FowBHJGC3uPvpu+VELQI+lgJnqwM6szq n6Hg== X-Gm-Message-State: ANoB5pktJE9u7YSkj0BTacPMHzPzV9mnF3+8AT0/LFQk1sBpCwAJpuSi b40si+2hX9Ed8domMD4nXqdk210mDP4SHj1FAf3qq1mzdq35kw== X-Google-Smtp-Source: AA0mqf4Qz6w6CZZKZdNm4y+FdEbvC982QxnW+lYwZ8kFf/vSpSK0RfnU3rVNopq0Mt7iInSt51FEC1uVs++XSUsDAw4= X-Received: by 2002:a63:180c:0:b0:476:848f:1ecd with SMTP id y12-20020a63180c000000b00476848f1ecdmr1355948pgl.589.1668679844102; Thu, 17 Nov 2022 02:10:44 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Luna Jernberg Date: Thu, 17 Nov 2022 11:10:32 +0100 Message-ID: Subject: Re: FreeBSD Quarterly Status Report - Third Quarter 2022 To: Lorenzo Salvadore , freebsd-announce@freebsd.org, Luna Jernberg Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.90)[-0.904]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::431:from]; MLMMJ_DEST(0.00)[freebsd-announce@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org,freebsd-stable@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[freebsd.org,gmail.com]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[6]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4NCbK15YyCz4FdV X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Was read in BSD Now today: https://www.bsdnow.tv/481 On Fri, Oct 21, 2022 at 11:26 AM Lorenzo Salvadore wrote: From nobody Fri Nov 18 21:20:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDV783BpTz4hL8v for ; Fri, 18 Nov 2022 21:20:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDV782jTQz3sbR for ; Fri, 18 Nov 2022 21:20:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668806420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=eN+Mswm1rg1Q3ixbUfiMyYytDIjVwECg+8DHszrnPDQ=; b=RpBXVZxJC+0rviRv9Bi09+xszNH/ciR3X43I5sIt9gL0ewjirWQEd/Cmxv4WiDMFgH9m4G 5m3kIC2x753LHCzzw68Rv8CmMjqsIs63I8FgkXdAqgFewh7JqxSuiynKfxfW68f27CMJYc RAu3IZ3EFtvSPaqLhHA6N3U/URDz31rOvh+l9dUOWYobbtQe+YSiysOHkBf14B4iaYQ8KE +GJHjN+1Xa7n9AQTvd18yambCePhsektt011cYDIp9AVac2IKc8EfR19A90ETssIUb9irl sq8vDpTu5uOKbcZ4WF1THSKWysyz8nmtY77PgrGzC+Op7cY1bhdePRKE8d0dJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1668806420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=eN+Mswm1rg1Q3ixbUfiMyYytDIjVwECg+8DHszrnPDQ=; b=bBiveIaGvil5etwG8ZEE0C91QE5Y8EK5y4JugmTfjmt3/Rn7TmojlRRkiBz/4mUJv6t3az pelbK9qMuqdKaP9xONnSkNCb1A95H6WKFpBZGnqGkctYeuEGG0RBiuVe+zmD0h1dchGX1U 1OpLARehEzdh9Rtw5ACGdkm5hAESVTh8Sc/Dbu2YvFhp1CeoOBTEnQTpLiEwKmq6wb4HKu l9yv1fQpEa14vaXmQ3d4UFLOfiQRBk34SgaYjGCwOao5BRc3bgxa39xq67+LWUlpIYen7M V8oNs7xnRy4cG9T+rEbMHTniL+O1Y7wrfe3nIjWd1tgBwYxWI6fxmfVOPEfeSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1668806420; a=rsa-sha256; cv=none; b=off4IzmyHbg8G7YrwS0qhCXnze8Dr5HoSG3UxfvcEt3nUsUxEcWU948CK3PA2nLcDuqZqQ sZG5jpsE9qWB5L7GNyt5LKZe9N0H3RWGW27WF8hLPdFniBLtsjxZ9luV6IYjWfVUWNhuTm h1eRFvZiyrseZqHVKy+sVyeucVuFrwsKNlX3hzN8zAKjxtxlRhSj0UhBgN38dmu0QlO/+D oagKKiEp51FQ0JmzLfD3hnfhFyviocgIp1//lZ9pGaaPZFuqATmiBcLcZHwckM5htgy1fu aTlm5yv3TEgk9h1zrjkame2Zz+9edvIKpJPKl5T3TinufHG0HINJBEUVCbjqZw== Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NDV780vvHz1418 for ; Fri, 18 Nov 2022 21:20:20 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 76F418D4A238 for ; Fri, 18 Nov 2022 21:20:17 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D37005C3A876 for ; Fri, 18 Nov 2022 21:20:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id pgnXeFVDs-zg for ; Fri, 18 Nov 2022 21:20:15 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D2DBD5C3A830 for ; Fri, 18 Nov 2022 21:20:15 +0000 (UTC) Date: Fri, 18 Nov 2022 21:20:15 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-hackers@Freebsd.org Subject: After ogin/assword characters typed are munched away until prompt? Message-ID: <91827rpq-6o4r-os1-61r1-ppo7son174rs@mnoonqbm.arg> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-ThisMailContainsUnwantedMimeParts: N Hi, it's been bothering for ages just never wrote the email and I find it lately when using serial consoles (bhyve nmdm or physical often over USB) a lot. In the old days you would enter username and password and keep typing your first command and it would work. These days everything I type after password before I get my prompt (rough estimate) while motd is scrolling .. is lost. I often find myself with half a command name "not found". Where are those characters lost to (or thrown away) that are typed in? Anyone any ideas? /bz -- Bjoern A. Zeeb r15:7 From nobody Fri Nov 18 21:55:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NDVvh64lDz4hRGK for ; Fri, 18 Nov 2022 21:55:28 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NDVvh0Q4jz41BN; Fri, 18 Nov 2022 21:55:28 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none Received: from kent.sdaoden.eu (kent.sdaoden.eu [192.0.2.2]) by sdaoden.eu (Postfix) with ESMTPS id 021A216059; Fri, 18 Nov 2022 22:55:19 +0100 (CET) Received: by kent.sdaoden.eu (Postfix, from userid 1000) id D73E8ACBD2; Fri, 18 Nov 2022 22:55:18 +0100 (CET) Date: Fri, 18 Nov 2022 22:55:18 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: "Bjoern A. Zeeb" Cc: freebsd-hackers@Freebsd.org Subject: Re: After ogin/assword characters typed are munched away until prompt? Message-ID: <20221118215518.XKaZf%steffen@sdaoden.eu> In-Reply-To: <91827rpq-6o4r-os1-61r1-ppo7son174rs@mnoonqbm.arg> References: <91827rpq-6o4r-os1-61r1-ppo7son174rs@mnoonqbm.arg> User-Agent: s-nail v14.9.24-347-gca602905a7 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4NDVvh0Q4jz41BN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Bjoern A. Zeeb wrote in <91827rpq-6o4r-os1-61r1-ppo7son174rs@mnoonqbm.arg>: |Hi, | |it's been bothering for ages just never wrote the email and I find it |lately when using serial consoles (bhyve nmdm or physical often over USB) |a lot. | |In the old days you would enter username and password and keep typing |your first command and it would work. | |These days everything I type after password before I get my |prompt (rough estimate) while motd is scrolling .. is lost. | |I often find myself with half a command name "not found". | |Where are those characters lost to (or thrown away) that are typed in? They are likely discarded in a mode-switch drain? I once had an user report which, granted, is userspace, fix was + /* As a special case, simulate EOF via EOT (which can happen + * via type-ahead as when typing "yes\n^@" during sleep of + * $ sleep 5; mail -s byjove $LOGNAME */ + if(*cbufp == '\0' && (n_psonce & n_PSO_INTERACTIVE) && + !(n_pstate & n_PS_ROBOT)) + *cbuf = '\x04'; |Anyone any ideas? Other than that not. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobody Mon Nov 21 18:42:44 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGGV21c6rz4hCRH for ; Mon, 21 Nov 2022 18:42:50 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGGV2162Fz3jRn for ; Mon, 21 Nov 2022 18:42:50 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669056170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=a41y3icpBbQYEkPCLmfpLFabi7/CH30JvUnmwPO+MxE=; b=afMUW5prvRPJ3tXaYf6aGb9X1c7j5STuhDqMbPj2MsA16+Ptxn3NuQB5HdZ5CzDJVZ6rp7 BBtbLRMgy0n93wlSyUkfTR8jLE9L4UcS+tVLGG5fqKmnkRZXjtrcmaR56QztYfjlyuCR6K jXVHJbp2TihCP6cl+aKGJpZvaYnKFrT17jkp5Y8kDoTemByowdhky1lCLG8VgXOnQuBm1U Wbi1JrwRbbQS07x5RZYh9YKxKOuBpVmAOc707zyY1EGohukmjTH8fCCi8qWMzW2e/pIR45 2M/lGp5sCBqi92VzckYuxvQTlX7wBk5qAlx3rNhK/Pa4uJj7IP/EEIDz9Drzng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669056170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=a41y3icpBbQYEkPCLmfpLFabi7/CH30JvUnmwPO+MxE=; b=wgGG72qvb6XHCYs9u4wk147091zD1vunsgxbciqCyvi2Yl1urAWdyub+BxaUjAszk+Buuw HI2TgWtsYC9WCCaHQr10bUChCBQOoavr3DK5DUR2/NLn7SxDRvFpVCUE2CsptxNR1gz3OX OTgvFh87xcBYl5RT1iQiKCST1TpJP8lBWjERaKPNJWUagEzMzjvR75lzZPjzjfjgkJbchy cUoTR3YaicQKzqlbaMRoVqEa+9BuJlT0I0jCJW1IStjtihiwr0IAlHFSfZ1nuZr3aGJITT mpQCkv3fW9T/qojUIQcbRLhlt6ZWeEtV7DEBnLVnFUQ5O6ICJDqD3+tR3RwiNA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669056170; a=rsa-sha256; cv=none; b=FD+s7fH70wLb/FqlUbBBO2vKu9g5mLUehSUG9+hV2iNn0U+GvIKbj4565I4Iw3NFHdt0vx waJFMS5u89nW/7x9lpc7UYLJvRthmlKo75qdYFP3j39xXTvXHykW4FBscv/OlC+FR8K9gg T9Dx8fbI9t12/VmC4Low3ptuVomdhyLg7aV5feaGDG6u2pgrsNE3CkaC4bdM3jkegvnStJ 7rXWavAiuOgvga2GHYz1NUTk5eT1qis/e1IJ/CRuQA9YN036loJzOt1kp89DX7iAZ44YzP MvhHxvFz/4dmejx05Ix4cRGo3Sv2yyQ4tCKqdOA+hC8kzS+Rdki5svNKa9zaYw== Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NGGV16Wvpz1KnS for ; Mon, 21 Nov 2022 18:42:49 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 086B38D4A212 for ; Mon, 21 Nov 2022 18:42:47 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5B3E85C3A833 for ; Mon, 21 Nov 2022 18:42:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id 9BQZGBK9Lihi for ; Mon, 21 Nov 2022 18:42:45 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9319C5C3A830 for ; Mon, 21 Nov 2022 18:42:45 +0000 (UTC) Date: Mon, 21 Nov 2022 18:42:44 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-hackers@freebsd.org Subject: Can we "pause" in loader and ddb>? Message-ID: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-ThisMailContainsUnwantedMimeParts: N Hi, having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans go loud on a test-laptop which makes one wonder if we can avoid that. Note -- I assume also on real HW though that's less likely observered here. For example I am sitting in a 4 vCPU bhyve current in ddb> and two threads are at 100% on the base system. Do we need to heat up the planet doing that or are there alternatives? I haven't looke dta the code in ages and I assume we need to poll in these situations on the console and for interactivity often enough? Can we "pause"? And why would two [v]CPUs be at 100% and not just one as I would expect all but one to be stopped? /bz -- Bjoern A. Zeeb r15:7 From nobody Mon Nov 21 19:06:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGH1n2qZ9z4hGQB for ; Mon, 21 Nov 2022 19:06:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGH1n0YhSz3lkD; Mon, 21 Nov 2022 19:06:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf30.google.com with SMTP id d13so2921471qvj.8; Mon, 21 Nov 2022 11:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=3iCaF2xYga9UuFFzymJ2tueolh9FbZSFPVWoRGhAZp0=; b=fd3N61C0XOQjZlrLmmbs29VPoR15d9SAaEMjaZgJMoFqVaA08MYzJ7yaq3uwNBz7W6 XRVh3tBRXM1DzNonZlnOBJZXo050EH0NtxTAkg6l8/Ss6t1qGRchc9ex+pSp5IWxqveF UaathFnW8l4/kcczTMgHryVcCK6jnOJpE3+1yWNb6C+I0e3fVhL8XB2bfWi3Krghb67E qM0guJHcd5GEi1OYPitzlDBY1SKftrFHBULVPDuZoUSQje+PKqAdZzPu6Cag0FVwtA2i YwMw9/TTmwoM6G7CKlE6IZTMSYC9tyNlO1I/QOEsewVrht+Phf0bXxRglPpsELvDnw7h mcog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3iCaF2xYga9UuFFzymJ2tueolh9FbZSFPVWoRGhAZp0=; b=Rl/wMKO2d1Bf/AjhN6vE7NgQhSKw3hAiwygayICJ26LHEF0DFRx0DGbgL707vxUonB xSy/9aqO/sFIKFMcH4cR3/igIG/f8PwGtDClH61/5x9zkEflfOGNpiaol0Wu1YMxUT/d qEh/pyCh2LeWxT5Xuamj/HHOnTM7jAJmM12YS0NvY5WbdDFuW8C+IBx8Pgy8hR4MOD82 iVb+rKqjZcPMpgvpZruSJwK+tSFV+RaeQ9zTaJcxmZvxk5Zvfq1dvEVii3i4fNzNtfPf kLiwKKi1xOIcMJ/L/ovpesxgKHNxs0lMwhvHVlxRONTPZ6E35qw5u+XsNS/+3giixzix eNhw== X-Gm-Message-State: ANoB5pkvbYANaPg7AM+8qCrGRd4+HB6LGpHdRgyA45uyGPTjt3aULPOr UqmwauADM9johvHJ9ipAvAVPPlcPujw= X-Google-Smtp-Source: AA0mqf7YbFOeiTu5sc4nWQU2YUYha/h5XFTDxhBKYXzBX3beDqeW2F48/o6mCV3SIYyhMyUyIZK4Pg== X-Received: by 2002:ad4:53c5:0:b0:4bb:7171:a3ee with SMTP id k5-20020ad453c5000000b004bb7171a3eemr6201918qvv.88.1669057611165; Mon, 21 Nov 2022 11:06:51 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id bp34-20020a05620a45a200b006fb0e638f12sm8900043qkb.4.2022.11.21.11.06.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 11:06:50 -0800 (PST) Date: Mon, 21 Nov 2022 14:06:47 -0500 From: Mark Johnston To: "Bjoern A. Zeeb" Cc: freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4NGH1n0YhSz3lkD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 21, 2022 at 06:42:44PM +0000, Bjoern A. Zeeb wrote: > Hi, > > having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans > go loud on a test-laptop which makes one wonder if we can avoid that. > Note -- I assume also on real HW though that's less likely observered > here. > > For example I am sitting in a 4 vCPU bhyve current in ddb> and two > threads are at 100% on the base system. Do we need to heat up the > planet doing that or are there alternatives? I haven't looke dta the > code in ages and I assume we need to poll in these situations on the > console and for interactivity often enough? Can we "pause"? And why > would two [v]CPUs be at 100% and not just one as I would expect all but > one to be stopped? When DDB is active, one CPU is going to be spinning in cncheckc() waiting for input, and the others will be in cpustop_handler(). For the latter, there is an option to use MWAIT/MONITOR to pause the CPU instead of calling pause in a loop, but bhyve hides the MWAIT/MONITOR CPU capability from guests (I'm not sure exactly why), so they just execute "pause" in a loop, which won't help the apparent CPU usage. Note that when the kernel panics, cpustop_handler() will execute "hlt", which should result in a vmexit if you started bhyve with -H, and you'll see only one vCPU thread consuming 100% when sitting at the DDB prompt. But when you enter DDB without a panic, we need some mechanism to resume the stopped CPUs when exiting DDB. From nobody Mon Nov 21 19:37:36 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGHjP50zjz4hLFJ for ; Mon, 21 Nov 2022 19:37:45 +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 4NGHjN5l8mz3rGL; Mon, 21 Nov 2022 19:37:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 2ALJbahE059118 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 21 Nov 2022 21:37:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 2ALJbahE059118 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 2ALJbaUa059117; Mon, 21 Nov 2022 21:37:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 21 Nov 2022 21:37:36 +0200 From: Konstantin Belousov To: Mark Johnston Cc: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on tom.home X-Rspamd-Queue-Id: 4NGHjN5l8mz3rGL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 21, 2022 at 02:06:47PM -0500, Mark Johnston wrote: > On Mon, Nov 21, 2022 at 06:42:44PM +0000, Bjoern A. Zeeb wrote: > > Hi, > > > > having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans > > go loud on a test-laptop which makes one wonder if we can avoid that. > > Note -- I assume also on real HW though that's less likely observered > > here. > > > > For example I am sitting in a 4 vCPU bhyve current in ddb> and two > > threads are at 100% on the base system. Do we need to heat up the > > planet doing that or are there alternatives? I haven't looke dta the > > code in ages and I assume we need to poll in these situations on the > > console and for interactivity often enough? Can we "pause"? And why > > would two [v]CPUs be at 100% and not just one as I would expect all but > > one to be stopped? > > When DDB is active, one CPU is going to be spinning in cncheckc() > waiting for input, and the others will be in cpustop_handler(). For the > latter, there is an option to use MWAIT/MONITOR to pause the CPU instead > of calling pause in a loop, but bhyve hides the MWAIT/MONITOR CPU > capability from guests (I'm not sure exactly why), so they just execute > "pause" in a loop, which won't help the apparent CPU usage. We do not want the guest thread eating CPU time in MWAIT, it is the host scheduler that should decide that there is nothing to do and schedule idle thread. In other words, MWAIT should be emulated, perhaps by revoking the monitoring page on MONITOR, and waking up the MWAIT-ing thread on write to the armed range. Additional complication is that the range to arm is usually equal to the cache line, doing dumb emulation by interpreting any write to the monitor page might be too harsh. There is also non-trivial cooperation with atomic interrupt delivery. These complexities are perhaps the reason to not enable M* for guests. > > Note that when the kernel panics, cpustop_handler() will execute "hlt", > which should result in a vmexit if you started bhyve with -H, and you'll > see only one vCPU thread consuming 100% when sitting at the DDB prompt. > But when you enter DDB without a panic, we need some mechanism to resume > the stopped CPUs when exiting DDB. From nobody Mon Nov 21 20:30:57 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGJts2FRnz4hSN9 for ; Mon, 21 Nov 2022 20:31:01 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGJts0KPvz3xKs; Mon, 21 Nov 2022 20:31:01 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x832.google.com with SMTP id cg5so8023071qtb.12; Mon, 21 Nov 2022 12:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=Wu+PaxPZE10JjWlddd6SC/LeePG0sUs/7EJce0fCLT0=; b=UdkHjKNG3tDvla1oEzXB1wsk1szVDasIiwttIdYMeLX98PwEq65chi625/4erG1t9D Qm9Oz1ED3Riki50RKbyx5gdcqIslNUYet68oBymcp2UjanxFwMj+PR77ky4IVvFSGp/s pPwiMtFY5Jmot/bhDMhDpeFZhWuHL9nbrm245LR/gcMUd/tzHimI7rMSBmZLWAU1pE3z k652AoW8niNUsVEHJtTD71b+qLaAiLcxhcmo/skH3iNYL9D9t3/o68I7qibQvFy3EJbI niziOl3NGqu2lUaGCZqd8/toA2NqUUZIPKv3e4geDNtDLOOrKyrnxjzPaazOSYOoAQ3+ PMcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Wu+PaxPZE10JjWlddd6SC/LeePG0sUs/7EJce0fCLT0=; b=2A47ZUiXBIzDU3rLdasymyqcIgYuI1gLr2nGL0Gt6x0yoyCl4oUkBQGeHDFWnZDxx/ PCaGNL8LfsMjOUOqzwffOcYrxa3OUpYZ79G4DDRSouPjboRYlBCZ9+VQvfPlxLRn6SVp r9mkoSp0YWT9E6zGxcbscptYAowjfxf+bNJygx1Z0HLsUsZ+nhgXCofQuf6nchmyarVU zguMWBRxv3Lz083vPHwANMeQUQOLVWdeJeaKf/kzW9BSXBd3Ikrec0ibxDDUhlt8gOW4 kmbIFX/qsxxxa9bYFWPlLR0QxI23yxK1uQs6+7c7jQ+RS5+myFE05HI42xGi/mvBT8ZX 5eQQ== X-Gm-Message-State: ANoB5pnXXvc3ix+kfRGc16o2G4DMjF45mc3Ly8ccznyOAvug5xdfWhwp RIHKQnOirCBzoQrsbDdk6vRO7BZKr/s= X-Google-Smtp-Source: AA0mqf4H880+sKv/GcgwBwKwmG2AlgtGEVf46XeWVlyHc3VFug7A9eopn0hMucgnzgqL7IX1HiOa+g== X-Received: by 2002:ac8:44c9:0:b0:3a5:7f82:b083 with SMTP id b9-20020ac844c9000000b003a57f82b083mr1979224qto.561.1669062660213; Mon, 21 Nov 2022 12:31:00 -0800 (PST) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id i23-20020ac87657000000b0038d9555b580sm7134401qtr.44.2022.11.21.12.30.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 12:30:59 -0800 (PST) Date: Mon, 21 Nov 2022 15:30:57 -0500 From: Mark Johnston To: Konstantin Belousov Cc: "Bjoern A. Zeeb" , freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4NGJts0KPvz3xKs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Nov 21, 2022 at 09:37:36PM +0200, Konstantin Belousov wrote: > On Mon, Nov 21, 2022 at 02:06:47PM -0500, Mark Johnston wrote: > > On Mon, Nov 21, 2022 at 06:42:44PM +0000, Bjoern A. Zeeb wrote: > > > Hi, > > > > > > having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans > > > go loud on a test-laptop which makes one wonder if we can avoid that. > > > Note -- I assume also on real HW though that's less likely observered > > > here. > > > > > > For example I am sitting in a 4 vCPU bhyve current in ddb> and two > > > threads are at 100% on the base system. Do we need to heat up the > > > planet doing that or are there alternatives? I forgot to mention: in this situation my "solution" is to attach gdb to the running VM, which I usually want to do anyway. This causes all vCPU threads to pause. > > > I haven't looke dta the > > > code in ages and I assume we need to poll in these situations on the > > > console and for interactivity often enough? Can we "pause"? And why > > > would two [v]CPUs be at 100% and not just one as I would expect all but > > > one to be stopped? > > > > When DDB is active, one CPU is going to be spinning in cncheckc() > > waiting for input, and the others will be in cpustop_handler(). For the > > latter, there is an option to use MWAIT/MONITOR to pause the CPU instead > > of calling pause in a loop, but bhyve hides the MWAIT/MONITOR CPU > > capability from guests (I'm not sure exactly why), so they just execute > > "pause" in a loop, which won't help the apparent CPU usage. > We do not want the guest thread eating CPU time in MWAIT, it is the host > scheduler that should decide that there is nothing to do and schedule > idle thread. > > In other words, MWAIT should be emulated, perhaps by revoking the monitoring > page on MONITOR, and waking up the MWAIT-ing thread on write to the armed > range. > > Additional complication is that the range to arm is usually equal to the cache > line, doing dumb emulation by interpreting any write to the monitor page > might be too harsh. > > There is also non-trivial cooperation with atomic interrupt delivery. > > These complexities are perhaps the reason to not enable M* for guests. I see. Maybe instead we could allow stopped CPUs to execute "hlt" with interrupts disabled, and when exiting DDB, the last CPU resumes all of the others by raising NMIs. Then only one vCPU thread will be consuming host CPU time when in DDB. > > Note that when the kernel panics, cpustop_handler() will execute "hlt", > > which should result in a vmexit if you started bhyve with -H, and you'll > > see only one vCPU thread consuming 100% when sitting at the DDB prompt. > > But when you enter DDB without a panic, we need some mechanism to resume > > the stopped CPUs when exiting DDB. > From nobody Mon Nov 21 21:55:00 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGLlt0yrzz4hdFP for ; Mon, 21 Nov 2022 21:55:06 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGLls5c4cz45vm; Mon, 21 Nov 2022 21:55:05 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669067705; h=from:from:reply-to:subject:subject:date:date: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=UjOHjnp9qH4XH1h+RpaXuUfV9vp3wkxllHHGPELKwDc=; b=HiWjjl7U+Jo5D/wMNAyD4Po4WwgbiXiwEWTKVKn36x7AxKZ45tggZvKZlH0vFa1jazqB/e 3mh5rublDVBUVCI95dunx9eXku5s4C1t4P8zVb069R+24d7cKZfgbOW+dl3NIiU8Ljyuyr zFVoYVTltBSTa5MBvM5dnaskznxKwgL3M6oybCACaUAnC37M+xrA5Iu3j07naMVEd7DE/J 87bjaqF2OCjHABxZB5ud4bas+PfhtUPXHSpM+Faz57OtwvrxYisroxqYH42XRvhdNAIA6M fiqMo0fuiFjnlxBqW19a4WUOUov8YPog0wnq8BUIm8FijRkaVVrYhK9Hy2nMEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669067705; h=from:from:reply-to:subject:subject:date:date: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=UjOHjnp9qH4XH1h+RpaXuUfV9vp3wkxllHHGPELKwDc=; b=bg7t+odx6gWjHZsa3XOB+nM7PMkTLqguxMgTJs2SLvqSrS2XVbUEkg0a2DZzX3F0X5DD0s HDOopuLgcT0qNTs7ZjEOwK7TfN2dyL6toRwm0uqTdFA6eWHPAFWwtJg7U7xci5nwPZSFEp SJ5VPoCBSbB/ei6UWM7t9U0cu3OTvllUC1nbwjQErd5BUNYRHVgoxQDnE+GCKzVNKaSNM9 V3DIN9rpBA8yzGXIzOs4gUo4KrhILxWfx5sGC9z1yeNd/R0uxENmmhcUNXHCvJ55R37A16 g+gtKA5k8wvFSHc0VjsKAcIML/KylBHkVlQ3rnBn2YN49JaEaHtEPYBxaPOcVQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669067705; a=rsa-sha256; cv=none; b=dPW1KA1cOBbZAZBSHQM4ERzurkdg0rWr6ziUJDmyeTUOVYqjNwk7h0QL1puJ0zhMaNUEtJ epVfgTbR007BzwMvoOVo2M1IY1na7/gQNOvIK7aE/RqrmaEI070famyy5082WpyNd9tfbw L68CdsYaf27ygBR4LkAN9k6SATypUXZ8dQhb4QsS1KPDiQbfqIkmLIyrNeSabFRfg+QDA2 D9f1N1gBehbD3i6Zwa/g4f3nC2N6XsPzRY8dDZphRuX9NHBsPGC0ygapmEAHNa/XemyKc5 j1o9o4lcHPtUkzke/sRQlcrW0ETLuWAyguitM57g5kYfXjgVV1/t7s3epKrrVg== Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NGLls34k0z1N9r; Mon, 21 Nov 2022 21:55:05 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D78CA8D4A212; Mon, 21 Nov 2022 21:55:03 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2BEDA5C3A833; Mon, 21 Nov 2022 21:55:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id gY8tRPk51fRH; Mon, 21 Nov 2022 21:55:01 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4C6955C3A830; Mon, 21 Nov 2022 21:55:01 +0000 (UTC) Date: Mon, 21 Nov 2022 21:55:00 +0000 (UTC) From: "Bjoern A. Zeeb" To: Mark Johnston cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? In-Reply-To: Message-ID: <94p665qn-nr81-89rp-8rr3-61r348q14s3@serrofq.bet> References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-ThisMailContainsUnwantedMimeParts: N On Mon, 21 Nov 2022, Mark Johnston wrote: Hi, > On Mon, Nov 21, 2022 at 09:37:36PM +0200, Konstantin Belousov wrote: >> On Mon, Nov 21, 2022 at 02:06:47PM -0500, Mark Johnston wrote: >>> On Mon, Nov 21, 2022 at 06:42:44PM +0000, Bjoern A. Zeeb wrote: >>>> Hi, >>>> >>>> having a VM sitting (a) in loader prompt or (b) in ddb> makes the fans >>>> go loud on a test-laptop which makes one wonder if we can avoid that. >>>> Note -- I assume also on real HW though that's less likely observered >>>> here. >>>> >>>> For example I am sitting in a 4 vCPU bhyve current in ddb> and two >>>> threads are at 100% on the base system. Do we need to heat up the >>>> planet doing that or are there alternatives? > > I forgot to mention: in this situation my "solution" is to attach gdb to > the running VM, which I usually want to do anyway. This causes all vCPU > threads to pause. > >>>> I haven't looke dta the >>>> code in ages and I assume we need to poll in these situations on the >>>> console and for interactivity often enough? Can we "pause"? And why >>>> would two [v]CPUs be at 100% and not just one as I would expect all but >>>> one to be stopped? >>> >>> When DDB is active, one CPU is going to be spinning in cncheckc() >>> waiting for input, and the others will be in cpustop_handler(). For the >>> latter, there is an option to use MWAIT/MONITOR to pause the CPU instead >>> of calling pause in a loop, but bhyve hides the MWAIT/MONITOR CPU >>> capability from guests (I'm not sure exactly why), so they just execute >>> "pause" in a loop, which won't help the apparent CPU usage. >> We do not want the guest thread eating CPU time in MWAIT, it is the host >> scheduler that should decide that there is nothing to do and schedule >> idle thread. >> >> In other words, MWAIT should be emulated, perhaps by revoking the monitoring >> page on MONITOR, and waking up the MWAIT-ing thread on write to the armed >> range. >> >> Additional complication is that the range to arm is usually equal to the cache >> line, doing dumb emulation by interpreting any write to the monitor page >> might be too harsh. >> >> There is also non-trivial cooperation with atomic interrupt delivery. >> >> These complexities are perhaps the reason to not enable M* for guests. > > I see. Maybe instead we could allow stopped CPUs to execute "hlt" with > interrupts disabled, and when exiting DDB, the last CPU resumes all of > the others by raising NMIs. Then only one vCPU thread will be consuming > host CPU time when in DDB. > >>> Note that when the kernel panics, cpustop_handler() will execute "hlt", >>> which should result in a vmexit if you started bhyve with -H, and you'll >>> see only one vCPU thread consuming 100% when sitting at the DDB prompt. >>> But when you enter DDB without a panic, we need some mechanism to resume >>> the stopped CPUs when exiting DDB. Nonwithstanding, the problem also is loader and the problem probably also is on a bare metal so focusing on bhyve is certainly a partial win but only part of the solution whihc ideally works in both situations. -- Bjoern A. Zeeb r15:7 From nobody Tue Nov 22 07:20:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NGbJJ6ss9z4j8hj for ; Tue, 22 Nov 2022 07:20:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NGbJJ3XYGz3NS1; Tue, 22 Nov 2022 07:20:32 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 2AM7KNdk009826 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Nov 2022 08:20:23 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1669101623; bh=78nvKl+fVJl3bVylMqXdheYlslM5M8zX9sDV13lO7Z4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QUIFv7zWv618RvQqdH0ncakeFPgD3ZLfZnyBxEH0leJsDwfviKHLe0xrfxumae6GV gH2LCFfzgSCiGhUnwab6MsqYDcJ840P6RIcdzT/SFr55q4xMBB3cTgQc7J9r54vdhE 8o+H9KLZf8x+eqqmMQJzRUjs2jOKWQ3Ylskrjj4M= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 2AM7KMOs023107; Tue, 22 Nov 2022 08:20:22 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 2AM7KM0s023104; Tue, 22 Nov 2022 08:20:22 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Tue, 22 Nov 2022 08:20:22 +0100 (CET) From: Wojciech Puchar To: "Bjoern A. Zeeb" cc: freebsd-hackers@freebsd.org Subject: Re: Can we "pause" in loader and ddb>? In-Reply-To: Message-ID: <4791ff8c-923d-3fbd-1ca0-f8f920b34e@puchar.net> References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4NGbJJ3XYGz3NS1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > Note -- I assume also on real HW though that's less likely observered > here. > > For example I am sitting in a 4 vCPU bhyve current in ddb> and two > threads are at 100% on the base system. Do we need to heat up the > planet doing that or are there alternatives? You are of course talking about real problem but could you please not smuggle ecoideology in the same time. Maybe you wrote it that way just as joke but please don't. > code in ages and I assume we need to poll in these situations on the > console and for interactivity often enough? Can we "pause"? And why > would two [v]CPUs be at 100% and not just one as I would expect all but > one to be stopped? > > /bz > > -- > Bjoern A. Zeeb r15:7 > > From nobody Mon Nov 28 17:18:23 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLXHl2JVVz4jPnm for ; Mon, 28 Nov 2022 17:18:43 +0000 (UTC) (envelope-from laurent@nilio.ca) Received: from nilio.ca (nilio.ca [165.22.232.54]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLXHk294Wz40nR for ; Mon, 28 Nov 2022 17:18:42 +0000 (UTC) (envelope-from laurent@nilio.ca) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of laurent@nilio.ca has no SPF policy when checking 165.22.232.54) smtp.mailfrom=laurent@nilio.ca; dmarc=none Received: from smtpclient.apple (modemcable167.247-179-173.mc.videotron.ca [173.179.247.167]) by nilio.ca (Postfix) with ESMTPSA id ED7D18516D; Mon, 28 Nov 2022 17:18:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD financing From: Laurent Jean In-Reply-To: Cc: freebsd-hackers@freebsd.org Date: Mon, 28 Nov 2022 12:18:23 -0500 Message-Id: References: To: Wojciech Puchar X-Mailer: iPhone Mail (20A362) X-Spamd-Result: default: False [-1.59 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ASN(0.00)[asn:14061, ipnet:165.22.224.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[nilio.ca]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NLXHk294Wz40nR X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Freedom is subjective. FreeBSD probably has no issue integrating LLVM into their OS because it sati= sfies their idea of freedom, the freedom to reuse the software any way you l= ike it. GCC=E2=80=99s idea of freedom is that any improvements to the software shoul= d be made available freely. This is fine for a project like FreeBSD, but it becomes a problem for the co= mpanies that use it, not just to Juniper. I don=E2=80=99t believe that FreeBSD did it for corporate pressure, but simp= ly because using LLVM is seen as an improvement in itself, to the distributi= on and its associated freedom. FreeBSD wouldn=E2=80=99t be very free if they *expected* donations for their= improvements, although donations likely have an impact on priorities of the= project. Laurent > Le 6 nov. 2022 =C3=A0 10:05, Wojciech Puchar a =C3=A9c= rit : >=20 > =EF=BB=BF >> @Wojciech GNU General Public License (GPLv2) is a free software license. Y= ou may be frustrated but GPL has consistently delivered ! > No. Free means free. Doesn't need any extra requirements From nobody Mon Nov 28 17:42:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLXqY6mdPz4jSLF for ; Mon, 28 Nov 2022 17:42:49 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLXqY4DvWz4BKK for ; Mon, 28 Nov 2022 17:42:49 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4NLXqQ0YsWz6hNQ; Mon, 28 Nov 2022 18:42:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1669657360; x= 1671471761; bh=WVgSsEQxLDf3/6kChf+/boyBtqaWZfCQNkaRqUXVG0M=; b=J 1TLrFilRSH7F18WFrmM34TI7p9GQ5YIHI3t+rM8kmTM7QwDl0Ln4514a/ZODPW3V wMl42NASet0bqnzo93dbXRCWn/LiRtpTnl8zt4gekVvKThk1iuu+VR34HjuXFjUF MgDc5Kb1Xt4XhfVPvXrx0Wejio2qKaubPOHUMBZDnxDAZSHEN159pvwBWaPyZXvx s/vDA2qvor+E/0VaZkT2fwaIyE+Tz2sygqz9qCYLilAFswCmOGovyLwlxAJBwMbw o7IJuOude0tmFAUUm8jbSszQKJg33is7O/e3uSqQ6en8cyi4V+1O2mIO3edCY4ts ikHX1RvfAtHKOISFUCpIw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id RiJBri0ff2CK; Mon, 28 Nov 2022 18:42:40 +0100 (CET) Message-ID: Date: Mon, 28 Nov 2022 18:42:39 +0100 Subject: Re: FreeBSD financing To: Laurent Jean , Wojciech Puchar Cc: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Guido Falsi In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NLXqY4DvWz4BKK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 28/11/22 18:18, Laurent Jean wrote: > Freedom is subjective. Just to nitpick, the english language has a problem with the word "free" meaning two completely different things. for completeness: free as "you don't have to pay for it", is a completely different concept from free as "with no strings attached". My language (and all the ones deriving from Latin, Latin included) have separate words for those meanings, for example (libero/libre -> no strings attached, gratis -> without paying) I suspect that the word "free" has caused a lot of misunderstanding in this area. -- Guido Falsi From nobody Mon Nov 28 17:54:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLY5Z28cJz4jTtM for ; Mon, 28 Nov 2022 17:54:58 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLY5Y6rj3z4FCP for ; Mon, 28 Nov 2022 17:54:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Authentication-Results: mx1.freebsd.org; none Received: from critter.freebsd.dk (unknown [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 6BF3A89284; Mon, 28 Nov 2022 17:54:55 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 2ASHstTB016942 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 28 Nov 2022 17:54:55 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 2ASHsraQ016941; Mon, 28 Nov 2022 17:54:53 GMT (envelope-from phk) Message-Id: <202211281754.2ASHsraQ016941@critter.freebsd.dk> To: Guido Falsi cc: Laurent Jean , Wojciech Puchar , freebsd-hackers@freebsd.org Subject: Re: FreeBSD financing In-reply-to: From: "Poul-Henning Kamp" References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16939.1669658093.1@critter.freebsd.dk> Date: Mon, 28 Nov 2022 17:54:53 +0000 X-Rspamd-Queue-Id: 4NLY5Y6rj3z4FCP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N -------- Guido Falsi writes: > I suspect that the word "free" has caused a lot of misunderstanding in > this area. You simplify far too much: Free (as in: gratis) beer, is never free (as in: no strings attached) At the very least, you owe one back... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From nobody Mon Nov 28 17:57:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLY8v3W5rz4jVCx for ; Mon, 28 Nov 2022 17:57:51 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLY8v2dzsz4G6x for ; Mon, 28 Nov 2022 17:57:51 +0000 (UTC) (envelope-from mad@madpilot.net) Authentication-Results: mx1.freebsd.org; none Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4NLY8t0jzTz6f8l; Mon, 28 Nov 2022 18:57:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1669658268; x= 1671472669; bh=Bxa9PbHjmTG5ysZ6rGfLagXl9Z9ceAul0XDwYr1j5ck=; b=g 55Q8hsJR65dW0ozJ3/R3Q1l7khCwSMY9QWaESnllv/9hcqdj4XZFKRgMdvSgY7bK Q9jfqgh8H5fLg2APcOFoeD6Blk6TFhw1Li9/ILbDw77Zqi/Fekc0TbBvQwRa4gQ+ g4xpB588LlKRsOIW5LvZyLZFTyIRFYHdHVqIGFc/Qt+Qa1cjnnw8ooVvzu9QTGbc FzmDZLiFtDkZzFn/dGKES+Gta0EOoSNuKdIl5uSHke5JBBh6xfFjsZ1ZDGk+67Ez H6qC/JGH3dBBivOg50MMfSeLXHK/HPLoJbHxsnkOgjuHvTqD//SlCqItY+FJ2YTC Yok4oXHOqidR2rlAhKeAg== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id AqEWfiMW067D; Mon, 28 Nov 2022 18:57:48 +0100 (CET) Message-ID: <0f2ca171-93b6-d622-bbca-c3b938a8c81e@madpilot.net> Date: Mon, 28 Nov 2022 18:57:47 +0100 Subject: Re: FreeBSD financing Content-Language: en-US To: Poul-Henning Kamp Cc: Laurent Jean , Wojciech Puchar , freebsd-hackers@freebsd.org References: <202211281754.2ASHsraQ016941@critter.freebsd.dk> From: Guido Falsi In-Reply-To: <202211281754.2ASHsraQ016941@critter.freebsd.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NLY8v2dzsz4G6x X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org On 28/11/22 18:54, Poul-Henning Kamp wrote: > -------- > Guido Falsi writes: > >> I suspect that the word "free" has caused a lot of misunderstanding in >> this area. > > You simplify far too much: > > Free (as in: gratis) beer, is never free (as in: no strings attached) > > At the very least, you owe one back... > Well yes, actually nothing in life ever comes with really really no strings attached. But I was referring to grammatical meaning strictly now :) -- Guido Falsi From nobody Tue Nov 29 00:56:37 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NLkS72V1Sz4jRD7 for ; Tue, 29 Nov 2022 00:56:39 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NLkS71yJZz3xtT for ; Tue, 29 Nov 2022 00:56:39 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669683399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5b9uTAI5LydhYvKab39ZLNR93CkqdyriFapYz4JxFdw=; b=mC+JT3vRsCeUgQqd245DrhzwlWNb4+O2zPZaoZhNDTqzG7IMfhYbXgkBRX3nmTdhfOrmgG 36qehdOBx1NfjMldlueGw90EJxsDBKoFa2UR2KXDdNLHRcHM+KGLczmY4gTOyTVwfmdid2 iHAO4YdEWb2IC/S/f6fYsfByyfK3tEQK+ZFZiT238fQ9+SRwfKsIu1TuUlG1vWshu4fFUP JJseDEoTHt36st6By4U3WfUROVeDyVCElXzQmqkBut6iDZxzN9tdg2qPD9hncZszu7MSyn SGWazvDqZNzpu7BFB8jxtkMfqEKm8g8XeUTsRIZCZYRaF9OSR2tz1MvdrhgZPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669683399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5b9uTAI5LydhYvKab39ZLNR93CkqdyriFapYz4JxFdw=; b=lw/ITd8LBDmsgyzMvKelS2mB+9CafFW6kiXUN/9WIb/AN/OT6DuDn6h99F9jSrVivzT+Ap OXJJEo7Aa7smqxfepEVZX2x8AmzYVmOeqQe3mHZ5wbIFEtVTum4VKnC6bSDQHoAsFphFCg yH4kQTNhkCaKm9dBWPZk/MdiM/S/zPHZHS40AkHQhr0uqq5BeXOQsTOjWG7Okog9SokuMT dcxn16qOOcErnC7Jnx8/8CbNcY3TGYHgdM2l83keILaMuGUdU7TGz7OTTtVwoFx3ih/dQn xPEkA4Ltp/admsQqT5MH+f6C3uE4eMzi/3bIMtInpbjwKQgFQxPuUpBegAzIJw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669683399; a=rsa-sha256; cv=none; b=gXJLFjIFxrj6mpEFgDKb84be2DLUJK6RaC662NAUzRcbHbolLeDPwMWCAQbrJWk7Uq4guI /ZzDGhi7A9v26ehYgphNV2ZiPWp5p521l+OCn1L5403Dbe8yUTPwqT+ycSCfraAIW9YVDd Orjzy6jkHrRkG+qWdrfZJ3PYtgyBTLUKXPAZgodKCQ0NmOUGuV7kTGhxwOzZD4nYCC+ZXp n5uUptKeFARRptM3gF7h25NNqXt7zPf5a3BhEn0ii4LdG59om8rJ+E9VvkF9e32VNtDDh/ +4kaviaT4xYYst3ZhVDjHQAdFz84cICOSp0J3fgdm6cvbO9Td43V4kCGCzHaew== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NLkS66XxvzJ3p for ; Tue, 29 Nov 2022 00:56:38 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <89b6e216-3d90-ec2a-a84a-386d29cb4a00@freebsd.org> Date: Tue, 29 Nov 2022 00:56:37 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: FreeBSD financing Content-Language: en-GB To: freebsd-hackers@freebsd.org References: <202211281754.2ASHsraQ016941@critter.freebsd.dk> From: Graham Perrin Organization: FreeBSD In-Reply-To: <202211281754.2ASHsraQ016941@critter.freebsd.dk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------KpBA20LnI8TXnXQOcSNMZdTD" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------KpBA20LnI8TXnXQOcSNMZdTD Content-Type: multipart/mixed; boundary="------------rb1p9uyTtNbxwkYDXWqCU0Sf"; protected-headers="v1" From: Graham Perrin To: freebsd-hackers@freebsd.org Message-ID: <89b6e216-3d90-ec2a-a84a-386d29cb4a00@freebsd.org> Subject: Re: FreeBSD financing References: <202211281754.2ASHsraQ016941@critter.freebsd.dk> In-Reply-To: <202211281754.2ASHsraQ016941@critter.freebsd.dk> --------------rb1p9uyTtNbxwkYDXWqCU0Sf Content-Type: multipart/alternative; boundary="------------0yqS8eN89czyL0sTCBtsCzDM" --------------0yqS8eN89czyL0sTCBtsCzDM Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjgvMTEvMjAyMiAxNzo1NCwgUG91bC1IZW5uaW5nIEthbXAgd3JvdGU6DQo+IOKApiBG cmVlIChhcyBpbjogZ3JhdGlzKSBiZWVyLCBpcyBuZXZlciBmcmVlIChhcyBpbjogbm8gc3Ry aW5ncyBhdHRhY2hlZCkNCj4NCj4gQXQgdGhlIHZlcnkgbGVhc3QsIHlvdSBvd2Ugb25lIGJh Y2suLi4NCkkgb3dlIEphbiBLb3VtIGEgcGludCBvZiBiZWVyLiBBdCBsZWFzdCANCjxodHRw czovL2ZyZWVic2Rmb3VuZGF0aW9uLm9yZy9vdXItZG9ub3JzL2Rvbm9ycy8/ZG9uYXRpb25U eXBlPXBhcnRuZXJzJmRvbmF0aW9uWWVhcj0yMDIyPg0K --------------0yqS8eN89czyL0sTCBtsCzDM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 28/11/2022 17:54, Poul-Henning Kamp= wrote:
=E2=80=A6 Free (as in: grati=
s) beer, is never free (as in: no strings attached)

At the very least, you owe one back...
I owe Jan Koum a pint of beer. At least
--------------0yqS8eN89czyL0sTCBtsCzDM-- --------------rb1p9uyTtNbxwkYDXWqCU0Sf-- --------------KpBA20LnI8TXnXQOcSNMZdTD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOFWMUFAwAAAAAACgkQt2dIb0oY1Avv Pg/8C0e5yH/WyCXxjQKAvbz9klDETZ07LZKkyonKanf+WnejV4RkH2Qv7EBuGVQFEosCaUTKacwE P2SjBUcBAX52Ys5EI7gH3VffUmBnJkrKZS7OhN4gcD/RpMFbrbsA1xszYwNMu64BtF4kDrB4bkLx EHklWaqW81ej0zNCCdifb/XQylumX5yty5LKaJFmn8muhkRbGkqjTxG4Y9WGcZ8MINLQPTWHqjGs tirY1O2L009FxeCvj2AvtFcAGWZvTqn1m+Ri4CrRWISnZoUTG0TNLOOqFnl7IBrM2Az5m4EWQGzp HN088CKp8A69H2iYxVPKI1w45swGmua+4SYIUdbTyoklDtaTZ83BOrxYMvMwuN2bwSQkL89g7vFd GAtbvtF2lBPS1s+A7BCRDm08KLLZR1lCzI6OY5xchHrEm/WNAre1iguzozWcnz38SEVvkob3A+oS xez3eb21e2Mnav2c1Ke5m0fzrxB6JZaywItdm3a63KfuowI/VDDElNYCqvL7b/0wNzC5yc61TDkf JTwPc42FYdbf7IVfGl9UeW/I/a39pTztfAOxTboVCG1AJvz55/nwTC8//+6nl5x5wwyoO+Dqu6Ae R8g9oLqJXaFyyJQdR88mvDtp3wX3YHsQ4RpTlrc/euViHtq5gmaeBY+ZdNOY7MFlUvwDRd/4FMfq THw= =72VA -----END PGP SIGNATURE----- --------------KpBA20LnI8TXnXQOcSNMZdTD-- From nobody Tue Nov 29 21:41:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NMG593hB1z4hb2J for ; Tue, 29 Nov 2022 21:42:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NMG57753cz3htC for ; Tue, 29 Nov 2022 21:42:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=teF9G2fc; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669758122; bh=8dnELgyGB5GSk9Z3ficYNuN3kWItFVNy22dpLYGe6I8=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=teF9G2fcgnqWJtbvQhcuWuuaWn7LNIwYa07OmjrdWgWtz8oiFsGjQtk9DdMspTdCn4h3OVj7oqOp11Xp39GwLZPcvMaoR+WFsrD2sR6oNf1lxXzH5h+1/L9CSSVQLvbPtAbzOgOq9PyiDhETgfz+ULaYinNwaWkVi0foXZosvRcJ0H8XHWMqEERQQuU6gBzmIr90Nh5NrPLBq0NfDpCbfowSIU2htkynRxSxIiPFekG/CSct2TIe/XtX5CDA20ULaP75vEpSZfDG5T2kkCH1BdsrrwRqMG2G+6QZ1HXPZ2EYpYqNwl8Pn1EcZiQtjOvfacVE2rGBLIoJeRkoHVfUew== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669758122; bh=jd2eN1YJyso6wfMjYYtbZD8S355MY7N+80FNd4tgEEX=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=cQL49uA4LbaX6xSAKrfrd2jaYccjZrDgv2J2RCZPDVaBbAxLnL2xQY33Ub/KHvwTnm3eUc98QjXxJl8jAvCOM2liL5ULwNdI2eVQU00FyyO3gVDf6SpW4epFoYk3VozKBB+gHTWY1CnDkSUk6z2zEh/Txf9CZTySO1YNWY3CvxNfFt/dtwuaX6Uh/Pbtl1CjV5dm6SnjyKZp08ibaEx2apntZWSWWuOkIPOBl3A4dhGN/vUlkXNg+DFQOlpgjH3pCvsP1XhereZT8qTI2wcsXKYUZ2+9ypkv6qFYX1xclHgNqAGbSWkdmaa5Vlxessbjaj2pVDp4MBBJHfePuzZwpQ== X-YMail-OSG: eBZJn44VM1mKTRRzNJ6gTJ2d11W2cFgUNpuvvaQPapPhJ60IeZ4NlanJlEgdLNr eNUIlNloRlaoZa41YKBawg5kwSiaCmCUwirjwDDlNEx3nEvHfpFqAt43C5zFbKjFzAcasbFXB4ld oOLbpLrXXGKR8w4LDI8bKN0yBFRCiS3hC62z3Cik5.17KU2D3H9kJXL2.GFPxG.ntudE3eniAQ2U yvQojkr2JCrh4C4HllhCkRzQpRoFOktZeacaO5a9LuNoPho67lBoY_du48bi2W4LRK3.3tDFdGO4 jWzz9m02nw0HjRs97YJ.CPS58tS74hRTR55SaCw0ioDmAcSwbPWid3_czcK6_dWjxjOyq.YPD26j Lrwl41yLTv.FrLZWS0z25btnbMylpfRMWvTKgSvuCBY9c3Gt6agcmaBPlH1b0kLQGSJaDRxM3DO9 ftNzYNIE8Np16nqTYbFEol6L2JM4zL8ab2JveVdQ9OxfyGAga.X2UmgDY_r1myolCA0izYHwuexL WrnW4ybI9.DRkJjcECYei7v81hTLg48shEcgAB2H4BYsy129_hVyYtJ.xjjaVL0zfsNZUBuczuH4 x8ICtnLvRRyMa1Ut9ZyImNbdS1AoEEucr4YjPmEVocXYm7mTC89RaWnz1qopjXdaBx9ftybVnOJx 4Q96a0chHG93OZ0pgk9lpvgfqzy9mgKiOkLJs7ZQQKWP9Nh7CZdrrLIyP62ogTi2boGHaMP0nDOD PVoVyGCmV0WiJ.ig_aw2ne0OQuQMYDjwavYdtsh7D48nIHAMzXwvE3W00fujXbtXdnOMkWKprJ0_ TS7AjxkSlIWIUNZUi3M_h_ZWnMMZ2eOExqI7msPzKVqWxTbH24A1Sj0x8Yghm945.EZK.pfdt3zc 4ARM85xHamzVef3DX6mMRh1bZxl8PFr1r9zU9t8qZfn89P0q2_103mOml9EEYhmjlFCqo2aVwmNZ ihCreOpQPlojZuoUruZMOfQZMLELcKsAxpxGhTet_Q18WVh9yRHN3sLYAYlVVaC01wdiiuSsBjq3 bvp7FBlVAo7D6oHpnHSp4Ao7KI5G751zw3Ej3v4rUDFz.Kn50rzuEMz63PgVOm_3M3XuD6JIGRh8 8bcuqbaNrB2rWa4BIzCo5IMqqyqPKek0Jk0oTWbaIchDDsYFVwXUNzQZw3BmCivsVzI81oiZ1UkW K_xCSA7mV2UhCPbFDHmoL0ExFyWrOsJAKlS9Jx64IU87l9hq_h4PjH8xkDaLeL0_2C.zMYbSJXQs S1PBRefFIWxS73cnNJoQsAE6.cDTy1ho5BSOlOLIj5yqrjq1oVEyIdiJDlqSL6OyujA464njPCnl o8Lml4nydL8xP.AXNy_5uqUvlMven6MlRzt2OxASO9zp8h6WndpXwfuRkW8VrhUqM8xfntZ_o.2C A9NypysBOFVs4.qtWor9v7Oi_VntdQ97MsWRdv9J5VX8NqWqpO_hMhJQ8lkQvXuZlJIPXH06q6IJ 0OrHajndVMIHDVdBxNwoDDmXMU9crN4mHocCg5B_qdsLM7pE8ruUx0EjdsDHVYa76RigAZnrl1B9 RQmIoBpi1zbholzf83Vpt.Oz9_lerNOXfzt7KvTBGm5WoyQn1Mi7CbNdMnF3eqHLlPtgYu43Eu36 pVva3V2PbSJeXiphLw2aWaySOgPptxpfKjhKqkRGc7P6UD4gQ7wMzetDPOsY.AcjS6F_fEUV.8LP 9183KdDtlca03Yd_OEv2FcDMtEHkCCJghLmHY5OOwinSzsPbl9UMCoifwG0S.g.sFU4EVMJwxV3e enh41ZaLR_0YqZIMH4yHRBZNj6h2LFi_7C5ze0.BB6eBIZdC3nguSM7atlPeU_.09xJJzP.1jmqa hBze8pxYv_qFdpKl3wcoJ7TcqLBLf_BeHcG2w9H43YAQE8HwDz9Z6oVfupg.8k2L948Ahjjf0wzK Si77accAmq_Ygp8L1Zo95SCkCRQnLc_NidB3FbqESJTbS5nU4H76551_XRdZeuKoSmvXxKt98EOW i0.uNl0BhcaRQQKBMruUuH.osECsKKtq6yDFPSs5nU7jmExDeMo9YPvr3vsGSVW2Xs99HkED2k4F dyljV776YcgxdyrNavRtkF1Fq66eEiBdmQm0RM2hKdAeYB8fuQH0sXxxvQ5RydbUuKfzD_ieqRAf O7VVNTQg9.fMLkBi7EeAEzvCbHx3jHvchS4a.gCLCdWjO8dzxXSRbNvkERmf8LfcpnAN3IN1MwLi TCdGDB4dio.vDA1c4jIP4tNA5Rhr.loBVlCj6n_WOW25a0RtrGfkTvm9mbLRK3e8NKF9arlyhwB0 NHA-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Tue, 29 Nov 2022 21:42:02 +0000 Received: by hermes--production-ne1-6bcfb7fb87-s7whx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 47ea081a711854af8b3b75d44077443f; Tue, 29 Nov 2022 21:41:59 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Question(s) related to "cylinder checksum failed" during "cp" of huge files (RPi4B EDK2 UEFI/ACPI context) Message-Id: <438C7F0B-DFB5-4BB3-BEC5-63FD6FFA7879@yahoo.com> Date: Tue, 29 Nov 2022 13:41:47 -0800 To: "mckusick@freebsd.org" , FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <438C7F0B-DFB5-4BB3-BEC5-63FD6FFA7879.ref@yahoo.com> X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.148:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4NMG57753cz3htC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N The later included question(s) are only intended to gather background information that might help gather evidence for why certain failure reports are generated in a particular (somewhat odd) RPi4B context. I'm not suggesting any problems with the cylinder checks themselves. If I do a: # cp -aRx larger-than-RAM.tar = larger-than-RAM.tar.copied_via_RPi4B_C0T_Rev_1.5 in a UFS context with a file like, for example, -rw-r--r-- 1 root wheel 27707039744 Nov 28 19:11:23 2022 = larger-than-RAM.tar I eventually get messages like the following before the system completely fails during the attempted copy (I've been testing only 13.1-STABLE so far): UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 92, cgp: 0x0 !=3D = bp: 0x43bc4552 . . . UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 107, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 123, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 155, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 219, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 347, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 236, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 94, cgp: 0x0 !=3D = bp: 0x43bc4552 . . . UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 99, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 100, cgp: 0x0 !=3D = bp: 0x8b9e9592 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 101, cgp: 0x0 !=3D = bp: 0x43bc4552 . . . UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 293, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 295, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 296, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 298, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 302, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 310, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 326, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 358, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 55, cgp: 0xffffffff = !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 183, cgp: 0x0 !=3D = bp: 0x43bc4552 UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 72, cgp: 0xffffffff = !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 297, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 298, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 299, cgp: = 0xffffffff !=3D bp: 0x544dd2da UFS /dev/ufs/rootfs (/) cylinder checksum failed: cg 300, cgp: = 0xffffffff !=3D bp: 0x544dd2da . . . (That such messages happen, may make for better validation that media I/O is well supported in the kernel for specific contexts than has historically been the case. This may be an example of that.) (Note: My use of "-aRx" is habitual, not special to causing the messages.) I've not seen problems during basic normal operation but that might just be a context that might take a long time to have a significant probability of observing such a failure. The "cp" activity above never has completed in this recent testing. Are the above messages likely to be based on the cylinder validation updates of fairly recent times? Or are they from code for which the checks would have been involved long before such changes as far as such "cp" activity goes? (I've been guessing that the tests involved are fairly new.) Is there anything about, say, when the checks happen vs. not relative to other activity happens during a "cp" that might be important to gathering or reporting evidence? (There might be other questions that I should ask but did not manage to think of.) It seems unlikely that I'll get to the point of being able to point at specific source code that has problems. But it would be nice to have presented more/better evidence if I can gather some. Notes: The oddity with the context is using EDK2 UEFI/ACPI instead of U-Boot/DeviceTree. What is reported here only happens with UEFI/ACPI. An apparently separate problem happens for U-Boot and can happen after the above kind of messages for UEFI/ACPI if the system manages to run long enough. The only media is a USB3 SSD in my testing. I first got such messages via use of: FreeBSD-13.1-STABLE-arm64-aarch64-RPI-20221123-b51ee7ac252c-253133.img but I also got such via my somewhat older builds that have some past experimental patches for ACPI and DMA range handling that I'd been using for some time, but mostly in a ZFS context for UEFI/ACPI as far as on-going use was concerned. (I've reverted to U-Boot for that on-going-use ZFS environment that I do not want corrupted.) What started this was getting access to a 8 GiByte RPi4B that no longer has the DMA size restrictions that the original parts had (a "C0T" part instead of a "B0T" at the end of the part identification printed on the SOC top). I was testing and comparing vs. old "B0T" parts, repeating old experiments that had originally shown the ACPI support did not work for the "B0T" parts. I'd not run such tests in some time and all the failures seem to be new types of evidence. My normal builds had patches that, prior to this, I thought were handling the "B0T" DMA range limitation associated with XHCI, as presented via ACPI. Part of what I had intended was to see if the behavior still looked good for the new "C0T" RPi4B and if things were well behaved without the patches (for official FreeBSD builds). Instead I found failures spanning into the old type of tests done on a "B0T" RPi4B. I had not thought to rerun the tests as the cylinder related tests were being added. Too bad. This possibly could have been noticed earlier. So far, I've not seen problems via U-Boot/DeviceTree. So that is what I now use in every context I do not want corrupted (avoiding likely needing regeneration from scratch). (My ZFS use is for bectl use, not redundancy.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Dec 1 00:00:04 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NMx5w64ksz4jQcT; Thu, 1 Dec 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NMx5w5ZWWz4QKg; Thu, 1 Dec 2022 00:00:04 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669852804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=ZngjG/xRhlT6jgyMsmSzmMnS+gIFuEXN7E7QQqBPpS0=; b=qHTy1uuO2HsLqajxw0/OyiUERNfOyNDVMcWDWzU2rFl89zK2X/+wgPdWfJ2fV1AnisF+2L kjbCOH783P+kF1KSQUkkqXFKQUpI8XwY4UBwWbfee9uEiKiCIbhzEmnmeEKU8q+v7+IUfm jVapqhO0CyPsKlI1BZpJ/cTpnHTKy3yYryRk6H0+wwug/wvD4iVkrfnLPRMNsbJ8nA2fTI vH9VVON6FlsceRMlbly6KAxlLPsTp3NrE8Y68cKNK31tO8TkCat7NdQqGp6jTNo0UFvuTY NLPCia+gslifSkZ4FmPzJUXBkh++nV4I0v7o8sBTwtrwO1tyPF6PcT/ei6YtbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669852804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=ZngjG/xRhlT6jgyMsmSzmMnS+gIFuEXN7E7QQqBPpS0=; b=t8MjWok9TlqtFN0GcZ7n0FmZMhZUCwP1EWbQZlQ4kbm/qnUNuB62VnZAJMhdFDuYIAPMDU QmAXit0p5j1jNFjyE7IZm/YigPjoiM3HCb5RuEB1cI9KgHVhdG8MNj9R5AWpQZHBSBkF01 9NAN5alHiZecbKaTONQN5B7U24Xbdw5rKJGYJhX2+TknBvpnnBELoGDO/T4dNAPEZkxycY yfzyn+z029SpgkiL0y+ZvNfBjjSeOT955q/hKfmROFHhWSQDfFyhPJPLpj6eKh3/itwROe 62B1YtDRIy1xTQbu4yGhuFKKd0hpkBNNBOXJtgAQMysDkTaAOORkeUcbDpvOqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669852804; a=rsa-sha256; cv=none; b=n3HEiCHKQ3+ZLuMMyOQSRwcAmpVK3EpPVRiZilpFe9VmQ0w6VIc3npXo4D2ufxFcWS4tha YMtfFkylQd3ZwtsytQ4saLWTZM1TmYvj8NlaD3UIQpbMpki1yAPftwNjpvf52dWVxnoKBz QPdNn9FRPvJfZ3X8JYSeRx4uy8UNGih/vE79puPp/r4OgEztRk2vACRU+b0yyvYdyDzHLF IZRbdYxCcQay5xX66J4QaPag/dLgKu2nxfSDSsB9QGzMdVdv/+GumD9TZlsgMAb6gvm1Q5 kbpSC5hl0Igef3OamRhKJGsDd+NA2Gk4L3j33mQ+yvfLEcGQbeCk21ej9e66Yg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id ABEFB24CD; Thu, 1 Dec 2022 00:00:04 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: Call for 2022Q4 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org Message-Id: <20221201000004.ABEFB24CD@freefall.freebsd.org> Date: Thu, 1 Dec 2022 00:00:04 +0000 (UTC) From: Lorenzo Salvadore X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is December, 31st 2023 for work done since the last round of Quarterly Reports: October 2022 - December 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q4 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Thu Dec 1 08:35:59 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NN8YJ4K5Nz4jmFx for ; Thu, 1 Dec 2022 08:36:04 +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 4NN8YJ3Mfkz4Fw0 for ; Thu, 1 Dec 2022 08:36:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669883764; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pjrT5sCaI37NifSPCy9TI/s/2NzPDREa/P8Kj8vqXNw=; b=koup97iBgp7CmVLsB8Z80KoTBoFFfiN39kyDCL/+MJVciTqpWzI75+SPpbMlsC7H0jfqvo tMoleCIhjxojwlIS1DMOs6m0yiCKClSc4PTLLMby7NmerGN/f2deRm1K/LUSfMdtJjX/8W szn81jhjOGAFttwIDNt0Mmlw/KS7OtFZ5wTAYLRY7s12g0OPukASw7d2yXa9U5LElp4RO+ JobOgfHgRDWMKjInZyHJEdko1QCGHv31S1Kvyygqi8vOhety7hdAmzmbwMvXOKEtg9kL/E lDKVgIiCki1wvG97TBw9QM5vJD5xrbCVvfBt4C1zErCfkYQZmxKEe++lONCh5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669883764; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=pjrT5sCaI37NifSPCy9TI/s/2NzPDREa/P8Kj8vqXNw=; b=j24ZpA9Y3HAxkCmaXXHDfozwPHMGxihTCgFOlyhac1zYPaZEz/71NqDNl9sOUEwQ+2/WGP KFreIc30wG+m8TdKfghwj7d22JXBVCJxdSVArjYoDOUybS75hUnyUwYYWDmeOjzZVXl9F3 dh/2+W6dE4HX9WngkW5L4JHAnBoS+6n+0vGtIcbIurAIoXlAoWzK4QJKK2qM41Yr5lU6jW OGTxS0GiilkP/9pvtJC5xf8Igke1xyqEJg+uio+LQvD6Pr3cjybHL8xVVWdUocJ+sR5+mB isSmYQl1ZXXgmVAjSe+q1bC0GfHViH6VOvaf5D3Pf+5I37ysy61QAigetmBBsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669883764; a=rsa-sha256; cv=none; b=A9FchhjyfPNC6/VBqkjWOQNgsLIBfthdWs6x6t7Of6e11CQHlB/6bNO79xqOYIQel35+X3 BwM3WkftuhDiyNLo0mgagaoAanhidt8p2ZsjOK0SmeZzK0MMJNGq0clMyee4P9eezjj49u m74Dqo4BBKClLpfd2VQOJbKUXT+V1HkY7Gqs3Liatn5qI3XCirIGAoxQyoStXUsS6vLOHk IP+uOrU1/spU+CRm31edLCRT4hr81NhCHy870xTqbIwC4tcXIxOUQee+KXRmCKiU91ybwf bHuiO2lPMR7XL2EXk3IhFqpZG4EpEKV5zAORfXVy0Ec1T7ZkszaCw5EcMi7i2A== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NN8YJ1k3Kz1KQF for ; Thu, 1 Dec 2022 08:36:04 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id E4B26738A2; Thu, 1 Dec 2022 09:35:59 +0100 (CET) Date: Thu, 1 Dec 2022 09:35:59 +0100 From: Baptiste Daroussin To: hackers@freebsd.org Subject: devctl_notify system is inconsistent Message-ID: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-ThisMailContainsUnwantedMimeParts: N Hello, After the addition of netlink(4) by melifaro@, I started working on a new genetlink(4) module, to send kernel notification to the userland via netlink. The goal is to be able to have multiple consumers without the need of devd to be running. The goal is also to be able subscribe to the events the consumer is willing to receive. https://reviews.freebsd.org/D37574 I also added a hook to devctl_notify to make sure all its event got sent via nlsysevent. (https://reviews.freebsd.org/D37573) It works great and so far I am happy with it. on thing I figured out it is: the "system" argment of devctl_notify is inconsistent: Upper case vs lower case "kern" vs "kernel" I intent to fix the following way: Create a new function similar to devctl_notify but with the first argument being an enum. Make the current devctl_notify convert its first argument into that enum and yell if an unkwown "system" is passed. (and probably declare devctl_notify deprecated) Then fix the inconsistencies: all upper case as it seems the most wildly use case s/kern/kernel/g WDYT? Best regards, Bapt From nobody Thu Dec 1 11:54:22 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNDyg6CnTz4hyVq for ; Thu, 1 Dec 2022 11:54:51 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on20700.outbound.protection.outlook.com [IPv6:2a01:111:f400:feae::700]) (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 4NNDyf6qbfz3NL6 for ; Thu, 1 Dec 2022 11:54:50 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=TtrG0hj2; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 2a01:111:f400:feae::700 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=etPhZgXmyU4EuiF0C9OqSGV0BFb1mjOkpyKmhm9jQgNs693tl7pyuXLr0uaFLxI2NBSeDIQtFrEivkdRTjk7hYglqzgjFV5nB3oAPu9Feb1sG34ll1+DcJciTzUniruoD9JqM/A1lk2e4wjMM6pJ2fo0Ztq1Md5BE7ihp41I0YNP6umbwxN8bfe8rXQxIiw3+YCrgDbF10WtdItFqmIonZwWtSxFiFkEcqhb0qOazDgMSp7Jx4KTxyOyHRh5t4rkz+EZhXc9jIBtBAzUnNANOio6B+ADHMk17nOZ6/Xu86QXgz0UrkZyh56+mpNwRSYX4++oUDQk+WMHDwIe4sbe5g== 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=FXEx+QwWkoIYSM87F19Vc8nqMafPCZ4ACkOdeSNmeRs=; b=gJlM59SB178jlvM1sn2rmeQOt15l2905X9AUr4iqWOJFi9ykRhhVeegUnwR2IBWbbF0TV3SRK8QFge7h4lBuPyNXjQcHGS1p1QOW2CMNaF22z7a0o+2D6Hh35If8zv0IXLynv6liVcP10rw42LeELC0mQv3uxRgneJKA6pGPS8zDc60Olo52obaglUbCn9iITyylb6K4VybZ44bMxJzZqAFmioogwHda5P62SOanvUIpQmOCw6T/DD86MG1jgDitsiIQPbbjNMiI5tCvVqFSAXrbS909p7PUHC07OyyCovOJM7IEiPkBc07uzJz/EhjInoCNjWpz7BP68/XZAw0X4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FXEx+QwWkoIYSM87F19Vc8nqMafPCZ4ACkOdeSNmeRs=; b=TtrG0hj28on/K2lRFKS3zHADoQY015LHn7REReCk3PP1hkjIsRPgdxKA9tl7JY9UPGXa26BFvSXenmJPUw4UPNeLzP1bVNk/6n1hFcPWTYzfHOsrFq6De8qUSaHD4U7P6BWzYfwyFq81xV8tYDxEBQ/oquJvPCRHwZyJ66cCbCk= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by KL1P15301MB0433.APCP153.PROD.OUTLOOK.COM (2603:1096:820:2e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5901.4; Thu, 1 Dec 2022 11:54:24 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%9]) with mapi id 15.20.5901.008; Thu, 1 Dec 2022 11:54:23 +0000 From: Souradeep Chakrabarti To: Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK5ZC9Og Date: Thu, 1 Dec 2022 11:54:22 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> In-Reply-To: <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cb7f752c-268d-41e0-9b42-84d4b73decbb;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-12-01T11:09:47Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|KL1P15301MB0433:EE_ x-ms-office365-filtering-correlation-id: cde01b5b-c049-4340-df0f-08dad392c9b3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vZ2kbUfNjYaUmiuP+BuuRexnzZeyDV1BjKZLF5GSKNtqWHCFgM6LGtMqwQC6HTIfS7M/l7kY8+aX0ZZk1xIa/giWWe7vTpPSr8mW+RUkkzwfbooEl89VKSRZYPhVYuEJYYdkiEncM3FL05Jl7lqEWSyA8idma/HHVTG+QBYN1oQ1pJh/KVuJyPA0HhdfZoy/CKztdo4+DeR1vOW8P4EGRA+tQdSKdnf9/j+9waZwhOK4+nvzeEEF51GNzluU4IwHDOvceSNkoXuCvhdHH2Jx5YuhQe33y2+4FRdXOv1ZVEfetRfymK0uZH3nJdCElDC3fwalJ8eje0gccHirqzYPs+r9mWvhkXpJ5NuhdLgXDsM9/8QUPi5lFnxRi5PuR2mJC8BQ2/c3jNIJR+PxnWtyiEh85wu15ZdeVYzQd9mTB6NXIxtNUqTR++6+07tI6mMY96PzN7D+4CpGdV2IXF5aM4KSROALyxBYxgH5lviABhNH34W6yRuGQAOtyQdypZlj0BfO1T8uQ4G9ceCRki3Yu9eOFhq72quGffTEhE3/L0rKo3ChvM2dJziTK/b2Pe2jjU3rr3nMznhSiaC5oRyHLcW2QEEf8w4X9cUnssJx3lgSNCYSEh/wMFutVCtnWk3D+G4VPFHm1GuIAMCgH3bbO3tF0E12KtFi+6scOkR4YOTpdQdZgcFOX3A7YB2F9nSTBptlLjagRadnSvdgz1fuhYf+LZ1HMgU0Tb8v2kLyt44uz/uECTaeRoSpEY2hr/78 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(39860400002)(376002)(396003)(346002)(366004)(451199015)(122000001)(38100700002)(66476007)(71200400001)(41300700001)(82960400001)(10290500003)(54906003)(316002)(8676002)(6916009)(5660300002)(82950400001)(478600001)(8936002)(52536014)(66446008)(66946007)(83380400001)(66556008)(4326008)(64756008)(76116006)(33656002)(38070700005)(2906002)(55016003)(7696005)(53546011)(8990500004)(186003)(6506007)(86362001)(9686003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eUU4ejFvUElueG5EVld6MkFkSnJjOC9SRFc2WmJ4YzNyZ2NydWh6K05xa3V6?= =?utf-8?B?eTV2WWh3UHM0OHpoclJZMHBEN2pJTVc2aFBjaG9UVVhzVzZKSWVxZXBSbmls?= =?utf-8?B?NlpmUXdtVHZ2bGVBcmN6VEhWektTUmhBNlV6QnlFK1piMkI0SkRYNjY3Q3lY?= =?utf-8?B?QWRDNm1OVTlyUUlmcjdRZ1dKdlBGMzFiM3VFTnduNXpleEYrUWpCSTFrQi9y?= =?utf-8?B?bnFwSGhxaUFpWmk5bjhxNHNaNm05YWw0OGNLOHB0Rm5uTk43elp0R0JPVC84?= =?utf-8?B?U1NMQ01JbmRORkM0bmQyZ2JraHJYVkNFelFodTA2bUMxelpQVGFZWTYwd2E2?= =?utf-8?B?MUtxcXJEQ05wRkpZeE96R0tnd0V5YjFPMTVIck04dkJUSlRFMmRUWUkreExL?= =?utf-8?B?RXZlcklKZXNvQTJWQmdySnQ5a3NZU1pxZU82dFVIWXpBQzdwWDd0SWs2NVR6?= =?utf-8?B?WUVCdzhWSnd6empjV3dmek0rZzJnclZmMjNkQXZ1VFZBL3gycXk1bStVWVNJ?= =?utf-8?B?YmJzWmp2dU5qWk1mVjNSSHNCYmJFejIydExtSkpiQ2E0Q1VQZGtZNTl2am96?= =?utf-8?B?STdpalNsL0p4aFJwN21Ca2tCaGxhT2hoVTA4NTh4YUVVdk1zYS84bUJWWHJ6?= =?utf-8?B?N0R1d2VrZ0pVUUNIL1FseGhkK1dtbHNyekE2OW83V1pRVGtWQ0tXR3JtbkpC?= =?utf-8?B?b3dPR05CcjJvdkFuZjNLTHVwM0R2VS82SU9EVnFudWpWNGhRMVRNMHQ0ejRa?= =?utf-8?B?T1NWUkdSWjBVSVRqSVBYdWxrS0c3L1RIT2R3K1RHTmF6aUVJbU5naVdPUVlP?= =?utf-8?B?Mm9NRHc5SkUwTHFuelVza1pORHA2VGJXcDNFWmZaaWtkZmw4aG04bGQrM3Yr?= =?utf-8?B?WSs3TTBxVlVJZGNXL2o3cGVHclU2MkhXcFQ2UmI5d0pZMHMrREdlZ016RjNa?= =?utf-8?B?c0pZU0swUjRJaWE1bEliQnU0NERXekdxdC9PWkVGZGZBKzU3Yjl3VVgwbXk4?= =?utf-8?B?WnFxZWkyMlNDdE15aHBUZStuSW83aml5c3VheUpTUDFwbURDbUQrbmRHY0ph?= =?utf-8?B?Yks5ZlE3ZUE1bGxWczVMcFltRlVpNXQ5L0pSd2hOSVVQVHJhQXdkT0xMZk84?= =?utf-8?B?ckxxbVF1RzRpRDE5RnAxa3RCTUdzaWRyMXI0eld4QmRPdEQyTGFFeDA1SXpS?= =?utf-8?B?d2JGNnZDZmNuUHBFV0duTXV4dFYyRmoxVHNFdTZ3dUFQbkNBa2hrQ3Nlclh2?= =?utf-8?B?UlBlTFhKTmtNbDdJSU1TeXhsOTZKQ1VKMUlLdkJkbi9NNzl0WWZ5V1pKS2sw?= =?utf-8?B?MXRncnpHR1l2UVNmSzRFNjZiQVBkUmJMdTFweHlBamh1RGg0bHRWeHJhQVdP?= =?utf-8?B?RElhOFl1Ty9UYVZ1N1RKMHozaEwrV2gyUG5TeGoyNUc2VUNCUFFGcWNGVW1N?= =?utf-8?B?WXU2UzF5ckJmbW1hend4SjJ5NlM1dUJramJkeFA1NUVHdUVKTnluZTRVUDl1?= =?utf-8?B?ODNZTHpPazFFOXNZZFg0cjVlTXF5UXhDTDE2aFV4Wk5ESklsTmV4cTNrR2V3?= =?utf-8?B?ZytaeVVBeHNKd0hSL0E1VEhuZDJDQlB4aEVKTkJJNmhSZFA2U0RtR0kyUzZM?= =?utf-8?B?c1gzRld5R3V2MDYxSG9HaHBRYjNJdi9ieWZJQW1XajRYamp3dzNQelNpMndv?= =?utf-8?B?NEpDeTd2bXpPUWtIODJMbW5oYmU4aXBmVmMwVmhLZlpWMkxVM1ROeVBwN0Vh?= =?utf-8?B?Vk96MG5oR0I3QnVodHlzNitNTGRDVjNNR1Z1blJyNGFvTm91ZVJYaGU1UFFa?= =?utf-8?B?UTRwaUx3Yk9zQk8rbndVSXRPUFEzcTJCbnpSQTNBS2libkhtaGxRZDAxOUo0?= =?utf-8?B?djJDM0FaZ29HditoOG0zSnFOZVZ4Z3o4dE9wc0NQMXdhRmdUSXZ3TXl3YlJI?= =?utf-8?B?NFdudVppckxaTDBrdEpiZnB3RTMxcGUrV0tLSnl5eEFGRzh6R0NxSDU1ZUJN?= =?utf-8?B?WGphNHJYL25mSlN6RUdqVVN0SG92Ym1oRTBlUG15ZzV3RXpYdE43L2NIblN0?= =?utf-8?B?VUkxb01wbW9wRnFwNS9zamVsdUhGTkI5OWpJMTZ4eXdsWWV6eHFtYzVCMWgr?= =?utf-8?Q?UElzpGjm1/ZF09oz2HhyVvV9K?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cde01b5b-c049-4340-df0f-08dad392c9b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2022 11:54:22.8912 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FY47+mIv11HYQ2BEaTVzkiPnrJUAbesmuwBIAQ4vowR/1tQzMPJLuDEwI/Fk09F/0Z8aebuRSJCTAy+KYmIGvXC49acAWU8drUJDr8CdNyI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1P15301MB0433 X-Spamd-Result: default: False [-9.88 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4NNDyf6qbfz3NL6 X-Spamd-Bar: --------- X-ThisMailContainsUnwantedMimeParts: N DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgVHVybmVy IDxhbmRyZXdAZnViYXIuZ2Vlay5uej4NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDMsIDIw MjIgNjoyMSBQTQ0KPiBUbzogU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3JhYmFydGlAbWlj cm9zb2Z0LmNvbT4NCj4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47IFdlaSBIdSA8 d2VoQG1pY3Jvc29mdC5jb20+OyBmcmVlYnNkLQ0KPiBoYWNrZXJzQEZyZWVCU0Qub3JnDQo+IFN1 YmplY3Q6IFJlOiBbRVhURVJOQUxdIHBjaWIgbXNpeCBhbGxvY2F0aW9uIGluIGFybTY0DQo+IA0K PiBIaSBTb3VyYWRlZXAsDQo+IA0KPiBGb3IgdGhlIHZtYnVzX3BjaWIgZHJpdmVyIHlvdeKAmWxs IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBwY2liX2FsbG9jX21zaSwNCj4gcGNpYl9yZWxlYXNlX21z aSwgYW5kIHRoZSBtc2l4IHZlcnNpb25zLCBhbmQgcGNpYl9tYXBfbXNpLg0KPiANCj4gRm9yIGFs bG9jIGFuZCByZWxlYXNlIHlvdSBjYW4ganVzdCBjYWxsIGludG8gdGhlIHNhbWUgaW50cl8qIGZ1 bmN0aW9uIGFzDQo+IHBjaV9ob3N0X2dlbmVyaWNfYWNwaS5jLiBZb3XigJlsbCBuZWVkIHRvIHBh c3MgaW4gdGhlIHhyZWYgZm9yIHRoZSBpbnRlcnJ1cHQgY29udHJvbGxlci4NCj4gSXQgbmVlZHMg dG8gYmUgdGhlIHhyZWYgdGhlIE1TSSBjb250cm9sbGVyIHJlZ2lzdGVyZWQuIEZvciB0aGUgR0lD djJtIGl04oCZcw0KPiBBQ1BJX01TSV9YUkVGLg0KW1NvdXJhZGVlcF0gDQpJIGFtIGN1cnJlbnRs eSBzcGVjaWZ5aW5nIGdpY19tYmlfc3RhcnQgYW5kIGdpY19tYmlfZW5kIHdpdGggU1BJIHN0YXJ0 IGFuZCBlbmQgbnVtYmVyLCBpbiBnaWNfdjNfYWNwaV9hdHRhY2goKSBhbmQgDQpJIGNhbiBzZWUg bXkgaW50cl9hbGxvY19tc2koKSBhbmQgaW50cl9tYXBfbXNpKCkgYXJlIHdvcmtpbmcuIEJ1dCB0 aGVuIG1seCBkcml2ZXIgaXMNCmdldHRpbmcgc3R1Y2sgYXQgQ1JFQVRFX0VRIC4gDQoNCm1seDVf Y29yZTA6IFdBUk46IHdhaXRfZnVuYzo5Njc6KHBpZCAwKTogQ1JFQVRFX0VRKDB4MzAxKSB0aW1l b3V0LiBXaWxsIGNhdXNlIGEgbGVhayBvZiBhIGNvbW1hbmQgcmVzb3VyY2UNCm1seDVfY29yZTA6 IFdBUk46IG1seDVfc3RhcnRfZXFzOjU4ODoocGlkIDApOiBmYWlsZWQgdG8gY3JlYXRlIGFzeW5j IEVRIC02MA0KbWx4NV9jb3JlMDogRVJSOiBtbHg1X2xvYWRfb25lOjExNTc6KHBpZCAwKTogRmFp bGVkIHRvIHN0YXJ0IHBhZ2VzIGFuZCBhc3luYyBFUXMNCm1seDVfY29yZTA6IFdBUk46IHdhaXRf ZnVuYzo5Njc6KHBpZCAwKTogTUFOQUdFX1BBR0VTKDB4MTA4KSB0aW1lb3V0LiBXaWxsIGNhdXNl IGEgbGVhayBvZiBhIGNvbW1hbmQgcmVzb3VyY2UNCm1seDVfY29yZTA6IEVSUjogcmVjbGFpbV9w YWdlczo0NDQ6KHBpZCAwKTogZmFpbGVkIHJlY2xhaW1pbmcgcGFnZXMNCm1seDVfY29yZTA6IFdB Uk46IG1seDVfcmVjbGFpbV9zdGFydHVwX3BhZ2VzOjU3NDoocGlkIDApOiBmYWlsZWQgcmVjbGFp bWluZyBwYWdlcyAoLTYwKQ0KbWx4NV9jb3JlMDogRVJSOiBpbml0X29uZToxNjQ0OihwaWQgMCk6 IG1seDVfbG9hZF9vbmUgZmFpbGVkIC02MA0KDQoNCmdpY192M19hY3BpX2F0dGFjaCggKQ0KLS0N Ci0tDQozMjMgICAgIHNjLT5naWNfbWJpX3N0YXJ0ID0gNjQ7DQozMjQgICAgIHNjLT5naWNfbWJp X2VuZCA9IDkyMDsNCjMyNQ0KMzI2ICAgICBlcnIgPSBnaWNfdjNfYXR0YWNoKGRldik7DQozMjcg ICAgIGlmIChlcnIgIT0gMCkNCjMyOCAgICAgICAgIGdvdG8gZXJyb3I7DQozMjkNCjMzMCAgICAg c2MtPmdpY19waWMgPSBpbnRyX3BpY19yZWdpc3RlcihkZXYsIEFDUElfSU5UUl9YUkVGKTsNCjMz MSAgICAgaWYgKHNjLT5naWNfcGljID09IE5VTEwpIHsNCjMzMiAgICAgICAgIGRldmljZV9wcmlu dGYoZGV2LCAiY291bGQgbm90IHJlZ2lzdGVyIFBJQ1xuIik7DQozMzMgICAgICAgICBlcnIgPSBF TlhJTzsNCjMzNCAgICAgICAgIGdvdG8gZXJyb3I7DQozMzUgICAgIH0NCjMzNiAgICAgZXJyID0g aW50cl9tc2lfcmVnaXN0ZXIoZGV2LCBBQ1BJX01TSV9YUkVGKTsNCjMzNyAgICAgaWYgKGVycikg ew0KMzM4ICAgICAgICAgZGV2aWNlX3ByaW50ZihkZXYsICJjb3VsZCBub3QgcmVnaXN0ZXIgTVNJ XG4iKTsNCjMzOSAgICAgfQ0KMzQwICAgICBpZiAoaW50cl9waWNfY2xhaW1fcm9vdChkZXYsIEFD UElfSU5UUl9YUkVGLCBhcm1fZ2ljX3YzX2ludHIsIHNjLA0KMzQxICAgICAgICAgR0lDX0xBU1Rf U0dJIC0gR0lDX0ZJUlNUX1NHSSArIDEpICE9IDApIHsNCjM0MiAgICAgICAgIGVyciA9IEVOWElP Ow0KMzQzICAgICAgICAgZ290byBlcnJvcjsNCjM0NCAgICAgfQ0KV2UgZG9uJ3QgaGF2ZSBTUEkg cmFuZ2UgbWVudGlvbmVkIGluIEFDUEkgRFNEVCwgc28gSSBuZWVkIHRvIHNwZWNpZnkgaXQgbWFu dWFsbHkgaW4gdGhlIGNvZGUuDQpJdCBsb29rcyBsaWtlIE1TSSBpbnRlcnJ1cHQgaXMgbm90IGNv bWluZyB0byB0aGUgbWx4LiANCklzIHRoZXJlIGFueSBpbnRlcnJ1cHQgcmVtYXBwaW5nIGJsb2Nr ZWQgYnkgRnJlZUJTRCBrZXJuZWwgaGVyZT8NCg0KPiANCj4gRm9yIHBjaWJfbWFwX21zaSBJIGFt IHVuc3VyZSBpZiB0aGUgY3VycmVudCBjb2RlIGlzIHZhbGlkIG9uIGFybTY0LiBJZiBub3QgeW91 4oCZbGwNCj4gbmVlZCB0byBjYWxsIGludHJfbWFwX21zaS4NCj4gDQo+IEFuZHJldw0KPiANCj4g PiBPbiAyIE5vdiAyMDIyLCBhdCAyMjoyNywgU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3Jh YmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gd3JvdGU6DQo+ID4NCj4gPiBIaSBBbmRyZXcsDQo+ID4g VGhhbmtzIGZvciB0aGUgcmVwbHkuIFJlZ2FyZGluZyBnZW5lcmljX3BjaWVfYWNwaV9hbGxvY19t c2l4KCApLCBpdA0KPiA+IGNhbiBiZSBjYWxsZWQgaWYgdGhlIFBDSSBkZXZpY2UgaXMgY2hpbGQg b2YgdGhlIGdlbmVyaWMgcGNpYiAoDQo+IERSSVZFUl9NT0RVTEUocGNpYiwgYWNwaSwgZ2VuZXJp Y19wY2llX2FjcGlfZHJpdmVyLCAwLCAwKSAuDQo+ID4gQnV0IGlmIHRoZSBQQ0kgZGV2aWNlIGlz IGNvbW11bmljYXRpbmcgd2l0aCBhIGRpZmZlcmVudCBwY2liIGRyaXZlcg0KPiA+IChsaWtlIHZt YnVzX3BjaWIpLCBpbiB0aGF0IGNhc2UgZG8gd2UgbmVlZCB0byBpbXBsZW1lbnQgYWxsIHRoZXNl IGZ1bmN0aW9ucyBvZg0KPiBwY2lfaG9zdF9nZW5lcmljX2FjcGkuYyA/DQo+ID4NCj4gPiBPciB0 aGVyZSBhcmUgc29tZSB3YXlzIHRvIHJldXNlIHRoZW0/DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQW5kcmV3IFR1cm5lciA8YW5kcmV3QGZ1YmFyLmdl ZWsubno+DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMiwgMjAyMiA2OjU0IFBNDQo+ ID4+IFRvOiBTb3VyYWRlZXAgQ2hha3JhYmFydGkgPHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29t Pg0KPiA+PiBDYzogV2FybmVyIExvc2ggPGltcEBic2RpbXAuY29tPjsgV2VpIEh1IDx3ZWhAbWlj cm9zb2Z0LmNvbT47DQo+ID4+IGZyZWVic2QtIGhhY2tlcnNARnJlZUJTRC5vcmcNCj4gPj4gU3Vi amVjdDogW0VYVEVSTkFMXSBSZTogcGNpYiBtc2l4IGFsbG9jYXRpb24gaW4gYXJtNjQNCj4gPj4N Cj4gPj4NCj4gPj4+IE9uIDIgTm92IDIwMjIsIGF0IDEyOjU2LCBTb3VyYWRlZXAgQ2hha3JhYmFy dGkNCj4gPj4+IDxzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gPj4gd3JvdGU6DQo+ID4+ Pg0KPiA+Pj4gSGksDQo+ID4+PiBJIGNhbiBzZWUgaW4geDg2IG5leHVzLmMgaGFzIGltcGxlbWVu dGVkIHBjaWJfYWxsb2NfbXNpeCB1c2luZw0KPiA+PiBuZXh1c19hbGxvY19tc2l4KCkuDQo+ID4+ PiBXaGljaCBjYWxscyBtc2l4X2FsbG9jKCkgZm9yIG1zaXggYWxsb2NhdGlvbi4NCj4gPj4+DQo+ ID4+PiBCdXQgaW4gY2FzZSBvZiBhcm02NCBJIGRvbid0IGZpbmQgc2ltaWxhciBwY2liX2FsbG9j X21zaXgNCj4gPj4+IGltcGxlbWVudGF0aW9uIGluDQo+ID4+IG5leHVzLmMgLg0KPiA+Pj4gU28s IG9uIGFybTY0IHdoYXQgaXMgY29ycmVjdCB3YXkgdG8gZ2V0IGFsbG9jYXRlIG1zaXggPw0KPiA+ Pg0KPiA+PiBGb3IgYW4gYXJtNjQgc3lzdGVtIHdpdGggQUNQSSBpdCBpcyBtb3N0IGxpa2VseSBo YW5kbGVkIGluDQo+ID4+IGdlbmVyaWNfcGNpZV9hY3BpX3JlbGVhc2VfbXNpeC4gRm9yIEZEVCBp dCBjYW4gZGVwZW5kIG9uIHdoaWNoIFBDSQ0KPiA+PiBkcml2ZXIgaXMgdXNlZC4NCj4gPj4NCj4g Pj4gSW4gZWl0aGVyIGNhc2UgaXQgd2lsbCBjYWxsIGludG8gaW50cl9yZWxlYXNlX21zaXggdGhh dCB0aGVuIGNhbGxzDQo+ID4+IGludG8gdGhlIE1TSSBjb250cm9sbGVyIHRvIGFsbG9jYXRlIHRo ZSB2ZWN0b3JzLiBGb3IgYSBHSUN2MyBkcml2ZXINCj4gPj4gaXQgd2lsbCBlaXRoZXIgYmUgZ2lj djNfaXRzX2FsbG9jX21zaXggaWYgeW91IGhhdmUgYW4gSVRTIGRldmljZSwgb3INCj4gPj4gZ2lj X3YzX2FsbG9jX21zaXggaWYgdXNpbmcgTUJJIHJhbmdlcy4NCj4gPj4NCj4gPj4gT24gQUNQSSB3 ZSBkb27igJl0IGN1cnJlbnRseSBzdXBwb3J0IE1CSSByYW5nZXMsIGFsdGhvdWdoIGl0IGxvb2tz IGxpa2UNCj4gPj4gdGhpcyBjb3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBleGlzdGluZyBnaWN2Mm0g ZHJpdmVyLiBUaGlzIGRyaXZlcg0KPiA+PiBzaG91bGQgYWxyZWFkeSB3b3JrIGFzIGEgY2hpbGQg b2YgdGhlIEdJQ3YzLCBob3dldmVyIGl0IGFwcGVhcnMgdG8gYmUNCj4gPj4gRkRUIG9ubHksIHNv IHdpbGwgbmVlZCBzb21lIHdvcmsgdG8gYWRkIEFDUEkgc3VwcG9ydC4NCj4gPj4NCj4gPj4gQW5k cmV3DQo+ID4NCg0K From nobody Thu Dec 1 14:44:15 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNJkG1Wpgz4jNj9 for ; Thu, 1 Dec 2022 14:44:22 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500o.mail.yandex.net (forward500o.mail.yandex.net [37.140.190.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNJkF5xPXz40dF; Thu, 1 Dec 2022 14:44:21 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Authentication-Results: mx1.freebsd.org; none Received: from myt6-870ea81e6a0f.qloud-c.yandex.net (myt6-870ea81e6a0f.qloud-c.yandex.net [IPv6:2a02:6b8:c12:2229:0:640:870e:a81e]) by forward500o.mail.yandex.net (Yandex) with ESMTP id A1FBF94105A; Thu, 1 Dec 2022 17:44:17 +0300 (MSK) Received: by myt6-870ea81e6a0f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id FiT2qwCYhGk1-Mpq82FMb; Thu, 01 Dec 2022 17:44:17 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1669905857; bh=95HCStpixel8e4ewFx6d+rfK3F7y68XdKyCmDLbmeDs=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=Bq6bUWmvVOwsbZs4qC5xT0THNwYJSBx4Xhxjzir7Iy1KqmWflTeKWLpyiT49vF1iH TNaJsl+7S7T1NeewTXPTjrzojuZWQ9laChdi1Mhs8FQ0Js4/6pl2Rr1hcPQdQE6Sbf rPuSqizNcqd3aUdMLZp0tvCIxVJSyHJHSx48jQUs= Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: devctl_notify system is inconsistent From: "Alexander V. Chernikov" In-Reply-To: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> Date: Thu, 1 Dec 2022 14:44:15 +0000 Cc: hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <93B61739-04EF-4C68-9C91-516AA8FA4418@ipfw.ru> References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Rspamd-Queue-Id: 4NNJkF5xPXz40dF X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:13238, ipnet:37.140.128.0/18, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 1 Dec 2022, at 08:35, Baptiste Daroussin wrote: >=20 > Hello, >=20 > After the addition of netlink(4) by melifaro@, I started working on a = new > genetlink(4) module, to send kernel notification to the userland via = netlink. >=20 > The goal is to be able to have multiple consumers without the need of = devd to be > running. >=20 > The goal is also to be able subscribe to the events the consumer is = willing to > receive. >=20 > https://reviews.freebsd.org/D37574 >=20 > I also added a hook to devctl_notify to make sure all its event got = sent via > nlsysevent. (https://reviews.freebsd.org/D37573) >=20 > It works great and so far I am happy with it. on thing I figured out = it is: > the "system" argment of devctl_notify is inconsistent: > Upper case vs lower case > "kern" vs "kernel" >=20 > I intent to fix the following way: > Create a new function similar to devctl_notify but with the first = argument being > an enum. I don=E2=80=99t have enough domain knowledge here, but generally, one of = the important changes in generic netlink was to move away from the = enum-like identifiers shared across the modules to strings. Having a single enum for the subsystem names would be hard for the = third-part module authors as they have to guess/compete for the numbers. I=E2=80=99d advocate for leaving them as strings (maybe with enforcing = some naming rules). =20 > Make the current devctl_notify convert its first argument into that = enum and > yell if an unkwown "system" is passed. (and probably declare = devctl_notify > deprecated) >=20 > Then fix the inconsistencies: all upper case as it seems the most = wildly use > case > s/kern/kernel/g >=20 > WDYT? >=20 > Best regards, > Bapt >=20 From nobody Thu Dec 1 14:45:32 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNJls175nz4jNgn for ; Thu, 1 Dec 2022 14:45:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNJls0hhCz41ZJ for ; Thu, 1 Dec 2022 14:45:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id ud5so4745177ejc.4 for ; Thu, 01 Dec 2022 06:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LlJ2WkHhX6HPDDD4Z/U7Z0wQwTxiFO35qiqqFh7joRU=; b=wpXB12c4R72+BtdYuZiLiVDc9+bzdoswL2qJ8QRL+wWDUl2TDIb3huCKsPmDGha6wL ctP6h66uLai8y9vT8sODJIQ//YGiIJRfwwKT+ebvqnPl7zTMQOZWK3Gh7j5/GTEKJVUw vHm9lVzEpf0obUJjnJQyMPHMYxMkogs5Np/DoGaXZ7pCt0zfx1cjObNI3lwZoQ45e041 6Ecajchbbpicj27LDRX2g83R0YkmMv3DyC9LLaOKB0ctXrBJ1uzltRUi1eNZ6/rTSWyV 8IAhnYwXWcttsSKAnq2kNvVyI+qz8iT6eLNcAwKltaj70/hdzGoeO5Te42IMd0ZSbSrS mr1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LlJ2WkHhX6HPDDD4Z/U7Z0wQwTxiFO35qiqqFh7joRU=; b=TyGhLIjXjSSECi0hF7uavMxeTFSEn3DFOsob7vLy1GKzQC17nfAZAgXTdXA8Z3PDGF TEg3T1WyYXlX/vm3Cs0seuSpWhJ8FFMjHt50u0iV0w3+Flxpl6/OLaywxCeLYEhKm5j0 dM3tloWHgC/CK38u0RUrUitY/FHzPCenCJs1K0dJip7djaOK+h0q1B0X40ar5k/Kz/EH vqgkn0NIBp+oYTpbpnB2MjFce/oq2Fawf80h+V4V8KHHNy8Vmp1VIZPzZNuGZuUZdjMG cPVDwuIQhsDveifx+8L+VB2oNakrGyMFer5hB0i+AvBNy9feliuekRNmOQZd5ktY69kx /7Ng== X-Gm-Message-State: ANoB5plZ6H3yJFoJhK+fCFIHCUqwcCDviqqCUcsGqfRQE3yQyFHbVLp+ 5ytt2YX4r3h05iEe2vMH9RwODJ1ro5zKx7vuFE/ajhtW5nqnJA== X-Google-Smtp-Source: AA0mqf5tbHVEb7z+2v6U5FbFHjnVbT2aUiqR9sPIqeSERu7vxZ427vXAAmL5kkmNve9UcAJar79O27xXeoOHWffmT5U= X-Received: by 2002:a17:906:c40b:b0:7ae:1e53:95b2 with SMTP id u11-20020a170906c40b00b007ae1e5395b2mr55300285ejz.333.1669905943529; Thu, 01 Dec 2022 06:45:43 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> In-Reply-To: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> From: Warner Losh Date: Thu, 1 Dec 2022 07:45:32 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: Baptiste Daroussin Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000092a94a05eec546f4" X-Rspamd-Queue-Id: 4NNJls0hhCz41ZJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000092a94a05eec546f4 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin wrote: > Hello, > > After the addition of netlink(4) by melifaro@, I started working on a new > genetlink(4) module, to send kernel notification to the userland via > netlink. > > The goal is to be able to have multiple consumers without the need of devd > to be > running. > > The goal is also to be able subscribe to the events the consumer is > willing to > receive. > > https://reviews.freebsd.org/D37574 > > I also added a hook to devctl_notify to make sure all its event got sent > via > nlsysevent. (https://reviews.freebsd.org/D37573) > You're connecting it at the wrong level: it will miss all device events. devctl_notify is used by everything except newbus's device attach, detach and nomatch events, so none of those events will make it through. > It works great and so far I am happy with it. on thing I figured out it is: > the "system" argment of devctl_notify is inconsistent: > Upper case vs lower case > "kern" vs "kernel" > They are consistent. With one exception that I deprecated in 13.x to be removed in 14.x. I documented all of them at the time in devd.conf. I think I'll go ahead and complete the deprecation. > I intent to fix the following way: > Create a new function similar to devctl_notify but with the first argument > being > an enum. > I'm a pretty hard no on the enum. I rejected doing it that way when I wrote devd years ago. These have always been strings, and need to continue to always be strings, or we're forever modifying devd(8) when we add a new one and introducing yet another opportunity for mismatch. I don't think this is a good idea at all. There's been users of devd in the past that are loadable modules that pass their own system name in that devd.conf files would then process. Having an enum with enforcement would just get in the way of this. I have toyed with the idea of having a centralized list in bus.h that's a bunch of #defines, ala old-school X11 resources (which this is very very loosely based on), but it didn't seem worth the effort. > Make the current devctl_notify convert its first argument into that enum > and > yell if an unkwown "system" is passed. (and probably declare devctl_notify > deprecated) > I don't think this buys us anything. devctl_notify cannot possibly know about all the possible subsystems, so this is likely doomed to high maintenance that would be largely ineffective. Then fix the inconsistencies: all upper case as it seems the most wildly use > case > s/kern/kernel/g > > WDYT? > I wouldn't worry about the upper vs lower case. All the documented ones are upper case, except kernel. There's no harm it being one exception since changing it will break user's devd.conf setups. I got enough feedback when I changed "kern" to "kernel" last year for power events. And as far as I know, I've documented all the events that are generated today. Warner --00000000000092a94a05eec546f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 1, 2022 at 1:36 AM Baptis= te Daroussin <bapt@freebsd.org&g= t; wrote:
Hello,=

After the addition of netlink(4) by melifaro@, I started working on a new genetlink(4) module, to send kernel notification to the userland via netlin= k.

The goal is to be able to have multiple consumers without the need of devd = to be
running.

The goal is also to be able subscribe to the events the consumer is willing= to
receive.

https://reviews.freebsd.org/D37574

I also added a hook to devctl_notify to make sure all its event got sent vi= a
nlsysevent. (https://reviews.freebsd.org/D37573)

You're connecting it at the wrong level: it will= miss all device events. devctl_notify
is used by everything exce= pt newbus's device attach, detach and nomatch
events, so none= of those events will make it through.
=C2=A0
It works great and so far I am happy with it. on thing I figured out it is:=
the "system" argment of devctl_notify is inconsistent:
Upper case vs lower case
"kern" vs "kernel"

= They are consistent. With one exception that I deprecated in 13.x to be
removed in 14.x. I documented all of them at the time in devd.conf. = I think
I'll go ahead and complete the deprecation.
=C2=A0
I intent to fix the following way:
Create a new function similar to devctl_notify but with the first argument = being
an enum.

I'm a pretty hard no on th= e enum. I rejected doing it that way when I wrote devd
years ago.= These have always been strings, and need to continue to always be
strings, or we're forever modifying devd(8) when we add a new one and= introducing
yet another opportunity for mismatch. I don't th= ink this is a good idea at all.

There's b= een users of devd in the past that are loadable modules that pass their
own system name in that devd.conf files would then process. Having a= n enum with
enforcement would just get in the way of this.<= /div>

I have toyed with the idea of having a centralized= list in bus.h that's a bunch of
#defines, ala old-school X11= resources (which this is very very loosely based on),
but it did= n't seem worth the effort.
=C2=A0
Make the current devctl_notify convert its first argument into that enum an= d
yell if an unkwown "system" is passed. (and probably declare devc= tl_notify
deprecated)

I don't think this buys= us anything. devctl_notify cannot possibly know about all
the po= ssible subsystems, so this is likely doomed to high maintenance that would<= /div>
be largely ineffective.

Then fix the inconsistencies: all upper case a= s it seems the most wildly use
case
s/kern/kernel/g

WDYT?

I wouldn't worry about the up= per vs lower case. All the documented ones are
upper case, except= kernel. There's no harm it being one exception since changing
it will break user's devd.conf setups. I got enough feedback when I c= hanged
"kern" to "kernel" last year for power= events. And as far as I know, I've documented
all the events= that are generated today.
=C2=A0
Warner
=
--00000000000092a94a05eec546f4-- From nobody Thu Dec 1 14:53:02 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNJwX2KPqz4jPZN for ; Thu, 1 Dec 2022 14:53:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNJwW1qySz43YW for ; Thu, 1 Dec 2022 14:53:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=CHPifMcS; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::52d) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ed1-x52d.google.com with SMTP id r26so2659604edc.10 for ; Thu, 01 Dec 2022 06:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=retr01UsymxG6x8MR7LPFF/Y+62pJvKyBdsJc/lGKBQ=; b=CHPifMcS9xaeaWnrXRWN3yE4DP49ZYIBAFVtbBYd4UEGY+UMHdxXayVo0G4AYexk0x rgRbCdzva3kSCJXQub1SFIXeSeW9Bj4QeiqbslDl/lATJFgVzyYXmjaXDy2GKpN3Bt5u iM949b/vQRT0clxHvHR+ZZU2lolQg28yUeYInnLMVft4OFoXfnaogkNSY6/g2mUPbF1F oPOfaQf2bPBeq7UzGLKSLK/3xMwWK+ky/J8GVDz5f7bZGkcj2dJvGtx72h7jRHtbh5R6 zQsHi8ndhlHFcr5jCOpjtjLGQpRVoP0z+40H/D2nxoiDSY8Jy+51+PQv97cwiLgGe0M8 rrdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=retr01UsymxG6x8MR7LPFF/Y+62pJvKyBdsJc/lGKBQ=; b=wRsBzXmlssYZhZ9vpyYGjo5wfZvrxk2c5YUQC7bxYYrq5cdy4Rj4Pc3S/oTsl0J++Z lMGPihJCzTQ/UfDh+0awDYtZXn+zheDQNdIidThF054vlwsm8ChkZynDxXELOlcbf/sD Z9TWtBeFvQ/tVdzo2uxi67qLLBrKbzcfsNVc83Kt7zwIa0noQplC1EbQhEt6mWuRNi9L Ruas0d2To61+o5kihZJ06F94/ZaLgoJehiKUAP/mpj70In3iNR6SJAnNvjehToHNLIPF S8WFd4MtdYJCAffY/c5QhTytWqg8cnnToGriXk+AjguK734bJ6PW7koBufszBTz+i4Y7 7lSw== X-Gm-Message-State: ANoB5pkCiApIdgVcz8djdDy1HukTy9hmL8GA4JHJFeO7ndiOlbU+iiPL vJMq6EAcCX+Wt5ZvBSKyrF2ECJQF7DNcC2YOdP4LPcsIZUh5MA== X-Google-Smtp-Source: AA0mqf5EMibD9ZQ1mCYYBHgA0oahdk0UIxm3ndrtccGdNHt+Ad8Sq9vCIgPA2XUVWy4pfQq51soxFsYb2yCbwXpqoSY= X-Received: by 2002:aa7:d85a:0:b0:46b:81a8:1ff6 with SMTP id f26-20020aa7d85a000000b0046b81a81ff6mr11457563eds.174.1669906393773; Thu, 01 Dec 2022 06:53:13 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Thu, 1 Dec 2022 07:53:02 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: Baptiste Daroussin Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000068db3905eec561c1" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52d:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-Rspamd-Queue-Id: 4NNJwW1qySz43YW X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000068db3905eec561c1 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 7:45 AM Warner Losh wrote: > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > wrote: > >> "kern" vs "kernel" >> > > They are consistent. With one exception that I deprecated in 13.x to be > removed in 14.x. I documented all of them at the time in devd.conf. I think > I'll go ahead and complete the deprecation. > I've created https://reviews.freebsd.org/D37582 to do the deed. Though thinking about it now, there's no 'whining' in about the old one being used, so users may be surprised by it. I may need to create another transition tool in devd for this. Warner --00000000000068db3905eec561c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 1, 2022 at 7:45 AM Warner= Losh <imp@bsdimp.com> wrote:
On Thu, Dec 1,= 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org> wrote:
"kern" vs "kernel"

They are consistent. With one exception = that I deprecated in 13.x to be
removed in 14.x. I documented all= of them at the time in devd.conf. I think
I'll go ahead and = complete the deprecation.

I've created https://re= views.freebsd.org/D37582 to do the deed.

Thoug= h thinking about it now, there's no 'whining' in about the old = one being used,
so users may be surprised by it. I may need to cr= eate another transition tool in devd
for this.

Warner
--00000000000068db3905eec561c1-- From nobody Thu Dec 1 14:59:05 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNK3H0Ws5z4jQLZ for ; Thu, 1 Dec 2022 14:59:07 +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 4NNK3H020Qz44Mt; Thu, 1 Dec 2022 14:59:07 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669906747; h=from:from:reply-to:subject:subject:date:date: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=PQjblWP087F3X3sMkqL5Xzp/exCueikAunF9hdxTwRg=; b=SJIZ/hOEZG0Sl8v2wbKA9fx8BE6dXQbg9pqTiPZTQOIeE93yTkXuGK0OencY9cgklRg2vn ER2aXGl9rIpID67GLxRjyIS80MZ2Sfd/0CAUFpe0KefvGAXArZ0/tlrbvy+hwMjK7qdlil XqDgqz7Kwk4Pi5lXjYhqaNDVnD34plQT83TvwIOlhCNWyl3aAfA0sRYs/OUftWUoqjWQ7u xoYwD2QL8TxpuSAqHhrxShzr3t5vsLggjhyW5Bm4DvQjOrxb4s+4BXp8yVLF8H+W6pvCpY o1w8A1XQKicauyrG9M/gl2l6bMnXJJM3+cwD6kHCrpJ8jgPX9kFKs7660uk13w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669906747; h=from:from:reply-to:subject:subject:date:date: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=PQjblWP087F3X3sMkqL5Xzp/exCueikAunF9hdxTwRg=; b=VLm7hFMdXN6uQygBTlXIGpYC6YO8NHH5Q+EDMwM+j0b0nHW9/ziYx1VfmpZwTx4la4Whop AELgA674lO8LsEA8WzjCRVBRi6vlea4h7vSKn4F5M4Mh8Pu4jkp3+4IClumeRSKBxUcPTX gDDYZvpMBjDQaEq37ZEVKrzlxyVcl4tfoIc7VO1ZrXpNAS2z0Nwz0hRZ+oLBuZZj4bR+4M wPSsNhBOf4x41gVy/KE5YdnAkYlQy+5shh/GvZtgccStIx/ffeltvVKwnkmFZDPc8t+iH4 YoAJ+2Pz8gECxo7+4KnRAsC3c7Byv+gL/VL7HfNtZfBn9rXSMa3ymvcXZ/glOw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669906747; a=rsa-sha256; cv=none; b=Xg0bPI7txhvADjO2va6Zz1ZQ7PP0AgkFHJOCagWXSAo28JFCRumrchwlEQHwbkAtz7TNGW cvUTocU9itTCCDqEeGo1N3bxf8SpOf93KWQANjBHg/to0gO7Wjt2nkmEnNADYjZV7tIqFb mVNlMz/LsLwiMge/GXFh7RZGm/GqJnjwTFQApyugTgVGdYoo7cWHjhyIr+bFGZDRVREv0T zLMvVndnCqKWGIz1qoM3KV0GQ1S3wVsr0jmZK5TwnkTwuf8rFFjsHtL0ytIYiCpWarVcvF aLIK8mK5BdvNN0Jabpirglx7MKWBxZVOQ4ukiLofuaWuFL/3xoF40uRukQ8X7w== Received: from aniel.nours.eu (nours.eu [176.31.115.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NNK3G5T1Qz1QqC; Thu, 1 Dec 2022 14:59:06 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 57C61129F44; Thu, 1 Dec 2022 15:59:05 +0100 (CET) Date: Thu, 1 Dec 2022 15:59:05 +0100 From: Baptiste Daroussin To: Warner Losh Cc: hackers@freebsd.org Subject: Re: devctl_notify system is inconsistent Message-ID: <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin wrote: > > > Hello, > > > > After the addition of netlink(4) by melifaro@, I started working on a new > > genetlink(4) module, to send kernel notification to the userland via > > netlink. > > > > The goal is to be able to have multiple consumers without the need of devd > > to be > > running. > > > > The goal is also to be able subscribe to the events the consumer is > > willing to > > receive. > > > > https://reviews.freebsd.org/D37574 > > > > I also added a hook to devctl_notify to make sure all its event got sent > > via > > nlsysevent. (https://reviews.freebsd.org/D37573) > > > > You're connecting it at the wrong level: it will miss all device events. > devctl_notify > is used by everything except newbus's device attach, detach and nomatch > events, so none of those events will make it through. Where should I hook to get the device events? > > > > It works great and so far I am happy with it. on thing I figured out it is: > > the "system" argment of devctl_notify is inconsistent: > > Upper case vs lower case > > "kern" vs "kernel" > > > > They are consistent. With one exception that I deprecated in 13.x to be > removed in 14.x. I documented all of them at the time in devd.conf. I think > I'll go ahead and complete the deprecation. > > > > I intent to fix the following way: > > Create a new function similar to devctl_notify but with the first argument > > being > > an enum. > > > > I'm a pretty hard no on the enum. I rejected doing it that way when I wrote > devd > years ago. These have always been strings, and need to continue to always be > strings, or we're forever modifying devd(8) when we add a new one and > introducing > yet another opportunity for mismatch. I don't think this is a good idea at > all. > > There's been users of devd in the past that are loadable modules that pass > their > own system name in that devd.conf files would then process. Having an enum > with > enforcement would just get in the way of this. > > I have toyed with the idea of having a centralized list in bus.h that's a > bunch of > #defines, ala old-school X11 resources (which this is very very loosely > based on), > but it didn't seem worth the effort. That is fine with me and actually I do need the string name to register as group name, that I didn't want to trash the strings away. But I need a way to list them all. > > > > Make the current devctl_notify convert its first argument into that enum > > and > > yell if an unkwown "system" is passed. (and probably declare devctl_notify > > deprecated) > > > > I don't think this buys us anything. devctl_notify cannot possibly know > about all > the possible subsystems, so this is likely doomed to high maintenance that > would > be largely ineffective. > > Then fix the inconsistencies: all upper case as it seems the most wildly use > > case > > s/kern/kernel/g > > > > WDYT? > > > > I wouldn't worry about the upper vs lower case. All the documented ones are > upper case, except kernel. There's no harm it being one exception since > changing > it will break user's devd.conf setups. I got enough feedback when I changed > "kern" to "kernel" last year for power events. And as far as I know, I've > documented > all the events that are generated today. > > Warner Note that if you think nlsysevent is a bad idea, I will just forget about it. Best regards, Bapt From nobody Thu Dec 1 15:38:37 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNKx64vxDz4jWCx for ; Thu, 1 Dec 2022 15:38:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNKx64MN4z4B74 for ; Thu, 1 Dec 2022 15:38:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x536.google.com with SMTP id e13so2854220edj.7 for ; Thu, 01 Dec 2022 07:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4towKsbf7wvyXPsUuhe9LSfTWI9K2qaDmggDI+pF5LE=; b=lo9Om4zymhom4h6s4c19ecTdXHTSRdEY8TeWjDE1m9HTfPCML1t9IlC9jBsL2G04iy sE5LsbevqkDZ0dCoeHlk3AIkp5Pyt37AcxMcnPF/KyQx0M3IYY92ND6W1pzAcYBbXE3q Q6W+YpvMvP8LV2anxWJ++DBx3nkiQ96tDiYgdGv7A5yaks22tDVnwY3+8Zch9zhVKH0G dBaWFzjxvdphMFZjCCv14xKRhayMERteFt+2Zhgrqm0uZqf7F5LhOMO9shfDnXvfODQl W0fnoSoAokwvOYBczN/OpUITHq8M7ahfWBVQbrbwSKC/lYXBIpv94gMLRP6RaBM4i2Nw bgcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4towKsbf7wvyXPsUuhe9LSfTWI9K2qaDmggDI+pF5LE=; b=RzBviDNa6TTPgdZ7jKoUBUsBGJ09KB/HeghAW4pUew/GOYBxrBj0ABgLuwhkpFqUlO A/LfiSDorqFxdoL5Movig+oHX3hiVz2WWy+COAqKaNHrtlSBfc4cg5vi4FqVc8uk6aYC mdNJLjBLqAiHSlcF2hnRVmVPh2XahefqVfrZEsiZnwG3jPDqWzsz+C11VhbwqOP0KgZ7 /Jm7FO5PCOcYcYXVXfJW6TwNjdGaj/QOfeatkSH05MedqpL2KXuWD6/QMWffqaD4hUGo 4ZrwjKL+rzNJzuzPmsFrGso6h5XhnrMjRnq7RRwSnGvnZwgv9fGq5/4wjDewEhyE3AaA xHIQ== X-Gm-Message-State: ANoB5pkUB9TBNauUaRUnxw2K8On0mjB0lwjNg9Qngo6dnqmCRqPzSZqd WxeI5smm0vE+lb3Gh5+D/M5RyGhFBl2mj1gunGDFJuwEZy5Gig== X-Google-Smtp-Source: AA0mqf5qAllMaL5gQER2VWpmIKdKVJCkd4od2iPEIXKJo8OhCE2roH9ZozJ32hmvexArQ7WT/TFovamnLYgacuMlMzI= X-Received: by 2002:a05:6402:48d:b0:461:c3d9:c6a3 with SMTP id k13-20020a056402048d00b00461c3d9c6a3mr42946609edv.154.1669909129068; Thu, 01 Dec 2022 07:38:49 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> In-Reply-To: <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> From: Warner Losh Date: Thu, 1 Dec 2022 08:38:37 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: Baptiste Daroussin Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000721fab05eec604c2" X-Rspamd-Queue-Id: 4NNKx64MN4z4B74 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000721fab05eec604c2 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin wrote: > On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > wrote: > > > > > Hello, > > > > > > After the addition of netlink(4) by melifaro@, I started working on a > new > > > genetlink(4) module, to send kernel notification to the userland via > > > netlink. > > > > > > The goal is to be able to have multiple consumers without the need of > devd > > > to be > > > running. > > > > > > The goal is also to be able subscribe to the events the consumer is > > > willing to > > > receive. > > > > > > https://reviews.freebsd.org/D37574 > > > > > > I also added a hook to devctl_notify to make sure all its event got > sent > > > via > > > nlsysevent. (https://reviews.freebsd.org/D37573) > > > > > > > You're connecting it at the wrong level: it will miss all device events. > > devctl_notify > > is used by everything except newbus's device attach, detach and nomatch > > events, so none of those events will make it through. > > Where should I hook to get the device events? > Either you need to drop down a level to where the formated events are queued, or you'll need to add something in devaddq() to deal with the events. These are a slightly different format than the devctl_notify() events because the latter was added later and I didn't want to cope with transitioning the old formatted messages to the new at that time (silly me). > > > > > > > It works great and so far I am happy with it. on thing I figured out > it is: > > > the "system" argment of devctl_notify is inconsistent: > > > Upper case vs lower case > > > "kern" vs "kernel" > > > > > > > They are consistent. With one exception that I deprecated in 13.x to be > > removed in 14.x. I documented all of them at the time in devd.conf. I > think > > I'll go ahead and complete the deprecation. > > > > > > > I intent to fix the following way: > > > Create a new function similar to devctl_notify but with the first > argument > > > being > > > an enum. > > > > > > > I'm a pretty hard no on the enum. I rejected doing it that way when I > wrote > > devd > > years ago. These have always been strings, and need to continue to > always be > > strings, or we're forever modifying devd(8) when we add a new one and > > introducing > > yet another opportunity for mismatch. I don't think this is a good idea > at > > all. > > > > There's been users of devd in the past that are loadable modules that > pass > > their > > own system name in that devd.conf files would then process. Having an > enum > > with > > enforcement would just get in the way of this. > > > > I have toyed with the idea of having a centralized list in bus.h that's a > > bunch of > > #defines, ala old-school X11 resources (which this is very very loosely > > based on), > > but it didn't seem worth the effort. > > That is fine with me and actually I do need the string name to register as > group > name, that I didn't want to trash the strings away. > > But I need a way to list them all. > We have no current mechanism to do that. We could add something that would register / deregister them with a sysinit + call to something in kern_devctl.c which could do the trick (and also deal with the ordering issues), though having netlink(4) as a loadable modules might be an interesting case to get right. If we did that, we could return a 'token' that you'd use to call a new version of devctl_notify(), perhaps with some glue for legacy users (or perhaps not: we change kernel interfaces all the time, and could just rename it and convert everything in the tree). > > > > > > Make the current devctl_notify convert its first argument into that > enum > > > and > > > yell if an unkwown "system" is passed. (and probably declare > devctl_notify > > > deprecated) > > > > > > > I don't think this buys us anything. devctl_notify cannot possibly know > > about all > > the possible subsystems, so this is likely doomed to high maintenance > that > > would > > be largely ineffective. > > > > Then fix the inconsistencies: all upper case as it seems the most wildly > use > > > case > > > s/kern/kernel/g > > > > > > WDYT? > > > > > > > I wouldn't worry about the upper vs lower case. All the documented ones > are > > upper case, except kernel. There's no harm it being one exception since > > changing > > it will break user's devd.conf setups. I got enough feedback when I > changed > > "kern" to "kernel" last year for power events. And as far as I know, I've > > documented > > all the events that are generated today. > > > > Warner > > > Note that if you think nlsysevent is a bad idea, I will just forget about > it. > I love the idea. I got over any resistance I had when melifaro@ moved things into kern_devctl.c and we talked through the issues at that time. I've been hoping that someone would replace the hacky thing I did with a 'routing socket'-like interface (I never could figure out hose to do it so many years ago w/o gross hacks). netlink(4) has finally provided a way to do it that doesn't get the routing code all jumbled up for this. I just have some specific issues with your proposal. In hindsight, I should have led with that in my first message :). Warner --000000000000721fab05eec604c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 1, 2022 at 7:59 AM Baptis= te Daroussin <bapt@freebsd.org&g= t; wrote:
On Thu= , Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote:
> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org> wrote:
>
> > Hello,
> >
> > After the addition of netlink(4) by melifaro@, I started working = on a new
> > genetlink(4) module, to send kernel notification to the userland = via
> > netlink.
> >
> > The goal is to be able to have multiple consumers without the nee= d of devd
> > to be
> > running.
> >
> > The goal is also to be able subscribe to the events the consumer = is
> > willing to
> > receive.
> >
> > https://reviews.freebsd.org/D37574
> >
> > I also added a hook to devctl_notify to make sure all its event g= ot sent
> > via
> > nlsysevent. (https://reviews.freebsd.org/D37573) > >
>
> You're connecting it at the wrong level: it will miss all device e= vents.
> devctl_notify
> is used by everything except newbus's device attach, detach and no= match
> events, so none of those events will make it through.

Where should I hook to get the device events?

Either you need to drop down a level to where the formated events ar= e queued,
or you'll need to add something in devaddq() to dea= l with the events. These are
a slightly different format than the= devctl_notify() events because the latter was
added later and I = didn't want to cope with transitioning the old formatted messages
=
to the new at that time (silly me).
=C2=A0
>
>
> > It works great and so far I am happy with it. on thing I figured = out it is:
> > the "system" argment of devctl_notify is inconsistent:<= br> > > Upper case vs lower case
> > "kern" vs "kernel"
> >
>
> They are consistent. With one exception that I deprecated in 13.x to b= e
> removed in 14.x. I documented all of them at the time in devd.conf. I = think
> I'll go ahead and complete the deprecation.
>
>
> > I intent to fix the following way:
> > Create a new function similar to devctl_notify but with the first= argument
> > being
> > an enum.
> >
>
> I'm a pretty hard no on the enum. I rejected doing it that way whe= n I wrote
> devd
> years ago. These have always been strings, and need to continue to alw= ays be
> strings, or we're forever modifying devd(8) when we add a new one = and
> introducing
> yet another opportunity for mismatch. I don't think this is a good= idea at
> all.
>
> There's been users of devd in the past that are loadable modules t= hat pass
> their
> own system name in that devd.conf files would then process. Having an = enum
> with
> enforcement would just get in the way of this.
>
> I have toyed with the idea of having a centralized list in bus.h that&= #39;s a
> bunch of
> #defines, ala old-school X11 resources (which this is very very loosel= y
> based on),
> but it didn't seem worth the effort.

That is fine with me and actually I do need the string name to register as = group
name, that I didn't want to trash the strings away.

But I need a way to list them all.

We h= ave no current mechanism to do that. We could add something that would
register / deregister them with a sysinit=C2=A0+ call to something in= kern_devctl.c which
could do the trick (and also deal with the o= rdering issues), though having netlink(4)
as a loadable modules m= ight be an interesting case to get right.

If we di= d that, we could return a 'token' that you'd use to call a new = version of
devctl_notify(), perhaps with some glue for legacy use= rs (or perhaps not: we change
kernel interfaces all the time, and= could just rename it and convert everything in the
tree).
<= div>
>
>
> > Make the current devctl_notify convert its first argument into th= at enum
> > and
> > yell if an unkwown "system" is passed. (and probably de= clare devctl_notify
> > deprecated)
> >
>
> I don't think this buys us anything. devctl_notify cannot possibly= know
> about all
> the possible subsystems, so this is likely doomed to high maintenance = that
> would
> be largely ineffective.
>
> Then fix the inconsistencies: all upper case as it seems the most wild= ly use
> > case
> > s/kern/kernel/g
> >
> > WDYT?
> >
>
> I wouldn't worry about the upper vs lower case. All the documented= ones are
> upper case, except kernel. There's no harm it being one exception = since
> changing
> it will break user's devd.conf setups. I got enough feedback when = I changed
> "kern" to "kernel" last year for power events. And= as far as I know, I've
> documented
> all the events that are generated today.
>
> Warner


Note that if you think nlsysevent is a bad idea, I will just forget about i= t.

I=C2=A0love the idea. I got over any= resistance I had when melifaro@ moved
things into kern_devctl.c = and we talked through the issues at that time.
I've been hopi= ng that someone would replace the hacky thing I did with
a 'r= outing socket'-like interface (I never could figure out hose to do it s= o
many years ago w/o gross hacks). netlink(4) has finally provide= d a way
to do it that doesn't get the routing code all jumble= d up for this.

I just have some specific issues wi= th your proposal. In hindsight, I should
have led with that in my= first message :).

Warner
--000000000000721fab05eec604c2-- From nobody Thu Dec 1 15:47:45 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNL7g1H3qz4jXJR for ; Thu, 1 Dec 2022 15:47:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NNL7f3Y7tz4D6x for ; Thu, 1 Dec 2022 15:47:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=MRDHl9HQ; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62e) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x62e.google.com with SMTP id b2so5165695eja.7 for ; Thu, 01 Dec 2022 07:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7eYwex6RXfnU4XLZZD2HgApD7pLThNUWN57zKCyYjIU=; b=MRDHl9HQU+diCbdnUGOSiLVuENvl30vE2a9P/ofXfx5tEOWW1xgmgOz985ajocngAo yYNlXABD9rzQvKC3y9zi07GMyP/mJr+KlGRhHkbj6J3eu3dQoBmILNIFy0BoV9T+bWUT VxmeYd2lAEe7q9IQC5vHXsqaocHjk3yF+OoEY8YLTdSzw2QEWzlHQqJVGoxS4R9U2yTa yIUAeOUFzqbp2YPc537yi422S2uOdOmfhYX0UdfAbiCTu0c6nH1OA/wzLRrFGb+Xa0xn OPDFuGkMGmGHI1WJfF7hRrM28cQ0FjEc3YyejOnL5L7/jYMSApoQUrnyv+SlLVursQR8 suVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7eYwex6RXfnU4XLZZD2HgApD7pLThNUWN57zKCyYjIU=; b=AVbXlCEySiY1MjaIuRs459fgYHBRJuLAt4oxsJxnwM1GC0L6VWZTIHVW9MXIlDIqnN A0YHbgT/gVIKvudyWauYWCNpv5w63zG/U0lP0rjDUQjRDfFBv9Qq413Z/5n3c2O8Ljsj y21Kuun49wVOMQR4t18+GoJ2qcUbLzRBGtOLi225pTvI0KJPOjg6iGkW7SDXYpd4f6yA vZbpdya1SugDmiJC90riErNqzMGnqkkHSc1o1WBApXXF8iuq0gTXIklyGmy2zw+PVTRX JBFGjXHOfKVLrnopk/jSxFG2fj3ulfzTi2XGtFK+hUr30ugpiiwzLsyIdu9MFWJ4ekXa sqMw== X-Gm-Message-State: ANoB5pk2oivukzqUThjGZApk5ybqSThijRFT5AiaRYxglxAZmWM62hw6 GX4qBdQATYscVcBKDJJecNeORUimGt3qLsd6F+c2Y1r5fwBBFA== X-Google-Smtp-Source: AA0mqf5PrcyBZ56yYu+xyAnn4Pyph7KRo7RkXLMRjXxOgKIfDLr+65dcsOCYWclGfRc0lmsHSHZMChDm1kWT+sb+m7E= X-Received: by 2002:a17:906:c40b:b0:7ae:1e53:95b2 with SMTP id u11-20020a170906c40b00b007ae1e5395b2mr55523584ejz.333.1669909676444; Thu, 01 Dec 2022 07:47:56 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Thu, 1 Dec 2022 08:47:45 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: Baptiste Daroussin Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000012687f05eec625ee" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NNL7f3Y7tz4D6x X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000012687f05eec625ee Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 7:53 AM Warner Losh wrote: > > > On Thu, Dec 1, 2022 at 7:45 AM Warner Losh wrote: > >> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin >> wrote: >> >>> "kern" vs "kernel" >>> >> >> They are consistent. With one exception that I deprecated in 13.x to be >> removed in 14.x. I documented all of them at the time in devd.conf. I >> think >> I'll go ahead and complete the deprecation. >> > > I've created https://reviews.freebsd.org/D37582 to do the deed. > > Though thinking about it now, there's no 'whining' in about the old one > being used, > so users may be surprised by it. I may need to create another transition > tool in devd > for this. > https://reviews.freebsd.org/D37584 is the other one that converts 'kern' to 'kernel' in devd rules on the fly (issuing a warning for 14.x and older, but an error for 15.x and newer) . Warner --00000000000012687f05eec625ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 1, 2022 at 7:53 AM Warner= Losh <imp@bsdimp.com> wrote:
=


On Thu, Dec 1, 2022 at 7:45 AM Warner Losh <imp@bsdimp.com> wrote:<= /div>
On Thu, Dec 1= , 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org> wrote:
"kern" vs "kernel"<= br>

They are consistent. With one exception= that I deprecated in 13.x to be
removed in 14.x. I documented al= l of them at the time in devd.conf. I think
I'll go ahead and= complete the deprecation.

I've created https://reviews.freebsd.org/D37582 to do the deed.
<= br>
Though thinking about it now, there's no 'whining'= ; in about the old one being used,
so users may be surprised by i= t. I may need to create another transition tool in devd
for this.=

https://reviews.freebsd.org/D37584 is the other = one that converts 'kern' to 'kernel' in devd rules
on the fly (issuing a warning for 14.x and older, but an error for 15.x a= nd newer) .

Warner
--00000000000012687f05eec625ee-- From nobody Thu Dec 1 17:40:43 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNNdp6wHhz4jnHl for ; Thu, 1 Dec 2022 17:40:46 +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 4NNNdp6TCyz4X2p; Thu, 1 Dec 2022 17:40:46 +0000 (UTC) (envelope-from bapt@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669916446; h=from:from:reply-to:subject:subject:date:date: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=5tqXQkAAKUrPWxGZzC1Rwf0Y3loJcTxG1fmpU01afWY=; b=m0gJPa7nNjWH86S8/b3zi9+e+QYc+bA9bJc8K/9aiFo2FOCn3YiVuQkDW/aIy1yfril7NO Kyhk/yDWByW4CPoS+gzgpST4DE2Eidvufz365ITDpkDzwU18VQE05tVM5mJycZ3YagbZca HEYa3kBlV4e5Wi1Uq2jLNCrdJWUYe8yYpqrOk4WqUqGeiCnWFsOuOXPQbDzcYV1nuEePZu Fq3xIC50ofgurMsjFHG+0Q0dcY8naSFWE0P7YUrs+BRPS9DJaZLKzVpnw5GQdKmD2979Ws v9LQk0lr/MqXIW5NVRcSNXNqEgkz/D2pLwtH4LtULOwCLJwDY6YisekORwkn8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669916446; h=from:from:reply-to:subject:subject:date:date: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=5tqXQkAAKUrPWxGZzC1Rwf0Y3loJcTxG1fmpU01afWY=; b=vDIl4VBk/6Cg8DLf3kOYotC/uoc3Tni14ovObFbv4MZWISPaGiNx3N92RvRlYw6ef344D1 bDCXAsC+2zjW78CHoUowGqx51A6QmrVMGN6AyhzXd1KIW02t6b9FnTZjlpED7sEu0Mtnpv l5fJGXrQZ+I8pY0bhLyqqkQjakr16o619fBNfgufwIdyLpSqFtD5uy/WFzuNmpdmaW5A1J m0LYBZa+1VKkzjed8h8Yh4lzIxdSwli/Ic+QNXW7wJxoPk4s0bTv61aQHs8nwrUSKlpMjz GaTTLR0D3JGzoCbhYf/ypZWCa4GcKQO8ioaaQb2cXbkJbeqFt9iDvqkz4BsRTg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669916446; a=rsa-sha256; cv=none; b=Y9MCOXjaWHSqIgxQa40aPT6ilnIa37ZASuRZasXxhevkYIZthPhQl3gtwerO/PltC6665v JX1j08pfoPHGyF1A7NTaCGWCmG+/+RF/byUdy1MNzL04sYtZkbOwASjgmh7WsuXL7InOVt UCDJHkiqPudec4rfP9EjWswg0TvZfy6zVywIL7N5ugRt1V0Gmd5bqbCKHrh06KXPTjGeFu 23XcGbhp1HY95HJqEngDa3l3AMjfech3UKJ/tGgvcRlU33qrrCssLndBs1IGvo+wP0vcxO ekxXgdy8jMHX+q2ZW3Lncg/LOz4WhQWnwXT29gQgu8wnzPnbVg6+NcqqRmL5tQ== Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NNNdp3z5BzGMm; Thu, 1 Dec 2022 17:40:46 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id B021C12AFE0; Thu, 1 Dec 2022 18:40:43 +0100 (CET) Date: Thu, 1 Dec 2022 18:40:43 +0100 From: Baptiste Daroussin To: Warner Losh Cc: hackers@freebsd.org Subject: Re: devctl_notify system is inconsistent Message-ID: <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote: > On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin wrote: > > > On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > > > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > > wrote: > > > > > > > Hello, > > > > > > > > After the addition of netlink(4) by melifaro@, I started working on a > > new > > > > genetlink(4) module, to send kernel notification to the userland via > > > > netlink. > > > > > > > > The goal is to be able to have multiple consumers without the need of > > devd > > > > to be > > > > running. > > > > > > > > The goal is also to be able subscribe to the events the consumer is > > > > willing to > > > > receive. > > > > > > > > https://reviews.freebsd.org/D37574 > > > > > > > > I also added a hook to devctl_notify to make sure all its event got > > sent > > > > via > > > > nlsysevent. (https://reviews.freebsd.org/D37573) > > > > > > > > > > You're connecting it at the wrong level: it will miss all device events. > > > devctl_notify > > > is used by everything except newbus's device attach, detach and nomatch > > > events, so none of those events will make it through. > > > > Where should I hook to get the device events? > > > > Either you need to drop down a level to where the formated events are > queued, > or you'll need to add something in devaddq() to deal with the events. These > are > a slightly different format than the devctl_notify() events because the > latter was > added later and I didn't want to cope with transitioning the old formatted > messages > to the new at that time (silly me). > > > > > > > > > > > > It works great and so far I am happy with it. on thing I figured out > > it is: > > > > the "system" argment of devctl_notify is inconsistent: > > > > Upper case vs lower case > > > > "kern" vs "kernel" > > > > > > > > > > They are consistent. With one exception that I deprecated in 13.x to be > > > removed in 14.x. I documented all of them at the time in devd.conf. I > > think > > > I'll go ahead and complete the deprecation. > > > > > > > > > > I intent to fix the following way: > > > > Create a new function similar to devctl_notify but with the first > > argument > > > > being > > > > an enum. > > > > > > > > > > I'm a pretty hard no on the enum. I rejected doing it that way when I > > wrote > > > devd > > > years ago. These have always been strings, and need to continue to > > always be > > > strings, or we're forever modifying devd(8) when we add a new one and > > > introducing > > > yet another opportunity for mismatch. I don't think this is a good idea > > at > > > all. > > > > > > There's been users of devd in the past that are loadable modules that > > pass > > > their > > > own system name in that devd.conf files would then process. Having an > > enum > > > with > > > enforcement would just get in the way of this. > > > > > > I have toyed with the idea of having a centralized list in bus.h that's a > > > bunch of > > > #defines, ala old-school X11 resources (which this is very very loosely > > > based on), > > > but it didn't seem worth the effort. > > > > That is fine with me and actually I do need the string name to register as > > group > > name, that I didn't want to trash the strings away. > > > > But I need a way to list them all. > > > > We have no current mechanism to do that. We could add something that would > register / deregister them with a sysinit + call to something in > kern_devctl.c which > could do the trick (and also deal with the ordering issues), though having > netlink(4) > as a loadable modules might be an interesting case to get right. > > If we did that, we could return a 'token' that you'd use to call a new > version of > devctl_notify(), perhaps with some glue for legacy users (or perhaps not: > we change > kernel interfaces all the time, and could just rename it and convert > everything in the > tree). > > > > > > > > > > Make the current devctl_notify convert its first argument into that > > enum > > > > and > > > > yell if an unkwown "system" is passed. (and probably declare > > devctl_notify > > > > deprecated) > > > > > > > > > > I don't think this buys us anything. devctl_notify cannot possibly know > > > about all > > > the possible subsystems, so this is likely doomed to high maintenance > > that > > > would > > > be largely ineffective. > > > > > > Then fix the inconsistencies: all upper case as it seems the most wildly > > use > > > > case > > > > s/kern/kernel/g > > > > > > > > WDYT? > > > > > > > > > > I wouldn't worry about the upper vs lower case. All the documented ones > > are > > > upper case, except kernel. There's no harm it being one exception since > > > changing > > > it will break user's devd.conf setups. I got enough feedback when I > > changed > > > "kern" to "kernel" last year for power events. And as far as I know, I've > > > documented > > > all the events that are generated today. > > > > > > Warner > > > > > > Note that if you think nlsysevent is a bad idea, I will just forget about > > it. > > > > I love the idea. I got over any resistance I had when melifaro@ moved > things into kern_devctl.c and we talked through the issues at that time. > I've been hoping that someone would replace the hacky thing I did with > a 'routing socket'-like interface (I never could figure out hose to do it so > many years ago w/o gross hacks). netlink(4) has finally provided a way > to do it that doesn't get the routing code all jumbled up for this. > > I just have some specific issues with your proposal. In hindsight, I should > have led with that in my first message :). > > Warner Here is my new proposal: What about: 1. I add a static list of systems in sys/devctl.h something like enum { DEVCTL_SYSTEM_ACPI = 0, DEVCTL_SYSTEM_AEON = 1, ... DEVCTL_SYSTEM_ZFS = 19 }; static const char *devctl_systems[] = { "ACPI", "AEON", ... "ZFS", }; this way we have a list of official freebsd's systems. We don't change the devctl_notify interface and in the kernel we change the devctl_notify("ZFS" into devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],... This is not too intrusive, and breaks none of the existing code 2. I also hook devadq using the same interface as I already have done, but all the attach,detach,nomatch become an event (only in nlsysevent) in the "DEVICE" system, the "SUBSYSTEM" is the current what of devaddq The type is changed into: + -> ATTACH - -> DETACH anythingelse -> NOMATCH and the reste of the current line becomes the data so from nlsysvent point of view this is exactly the same kind of events as the one hooked in devctl_notify. 3. in nlsysevent we have one category one can subscribe per known systems. All other "systems" falls into a new category named "extra" "vendor" or "other" from the consumer point of view the name of the system is anyway contained in the message itself, so the category it is subscribed to can differ. This way, I should be able to get ALL the events in a consistent way. I should be compatible with people who uses devctl_notify in their custom kernel modules. Sounds easy enough without the requirement of complexifying kern_devctl.c with a registration of extra systems. What do you think? Best regards, Bapt From nobody Thu Dec 1 21:20:17 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNTWH5Lqpz4jMhK for ; Thu, 1 Dec 2022 21:20:27 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from HK2P15301CU002-vft-obe.outbound.protection.outlook.com (mail-eastasiaazlp170100000.outbound.protection.outlook.com [IPv6:2a01:111:f403:c400::]) (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 4NNTWG2PmHz3PNJ; Thu, 1 Dec 2022 21:20:26 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=VPj2RsLs; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 2a01:111:f403:c400:: as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XJ9OWwquDCef4k295lYhzOdLTVVr6r1zEvKlOXLGVnuLqOYL7fBkX0mb5tEc/TvC1RDbKIvadzNTgWMRoWXhhpRtujxK0GnfALVoEFUh6mziMVyP+MFbdzUtiRwm/7NvXJMoLNnjUFVGJbyfA+sXtPrch8J2cUD+uH1r/jaHoRz3pk+RHU6vkCbpH02CD+sz0av5sesY0Dqt1QydSg8PtjctQoo+TKPa+cskJ4WP5ilOpYHgTgL/nvsDATnMT3gUuCDOrfpduhKuZcXjiyxSBiC6iVpA8llBL6J7anS9LTYuF5m70Ux/cV2nCcfSDzwf/WLU1cUOWIfCT8mkg2X4Eg== 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=QssSjc2NGKcoDO/78Auys713nqfguKjtgztpND/5PvA=; b=JGjD1WFqK4d4CAEw1qB1PE3+bUmtZZZUoOtLVNBUR8/alfrjAZgUPs1WLaQ0FInbSEFW72SK6gl4rNFtUsqUH1jNJDm/o3JoMDYCa4eW0xNj93TjaE00DH98Kfa2maFphgEMqOMRmYFvaNELravmG+npTAf/HiaRxbYHipc0lKcigW/XiwMQVg+utTG/VAywMFkkjIaWDdIKPux5CUN3Mba47fsuEZPf3nBGTzBfedQ2YiMb96gYAYrK7rL2CIcEy7WMMZtPfXy+OSC/7zxC0j9nKzyN1jletNKumvvr/sZRK5fK1iA5Ivv+wEGhMyu5wex6r0C/BSdglFwIDE9WZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QssSjc2NGKcoDO/78Auys713nqfguKjtgztpND/5PvA=; b=VPj2RsLs1gX+gEr4TnOBjkYEg+BqWTxQ5HGhn4PL6TDi/TTaU1fGg8Qn+rS/v8QS1Gi4CvhSt1y5/TWqp2CSsQCfF5ZcQRxCej/Rw6ZcTTWJqEOOtP5qaAsEaoZVk8v/YZQRVU1FhNx5ed6slic7fGKRCnaGNnUdyVwGCQ1abJo= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SEZP153MB0648.APCP153.PROD.OUTLOOK.COM (2603:1096:101:99::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5901.4; Thu, 1 Dec 2022 21:20:18 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%9]) with mapi id 15.20.5901.008; Thu, 1 Dec 2022 21:20:18 +0000 From: Souradeep Chakrabarti To: Andrew Turner , Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK5ZC9OggACqbLA= Date: Thu, 1 Dec 2022 21:20:17 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cb7f752c-268d-41e0-9b42-84d4b73decbb;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-12-01T11:09:47Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SEZP153MB0648:EE_ x-ms-office365-filtering-correlation-id: 7839d693-26a1-4f4c-738e-08dad3e1d842 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sclPC24hUCciT6Ql5Cmt+EtUd6ysV7CqYLP5numzeuvELTbQDG//llzoOgPUbB48WWRCtKwAHEbw0yQNe1GZHa1nUvMA8eODrF33wn7pHiX+n/TKGT9jgEVk+cpY1fUZM3KRZTY6BLoALUl4DawA2IOopclclH90viJvWYdFNOasJaDiv4sK83TbLgTcusPsBVYVgJpFuBv3ZlNRleOX8rOO5pcaM7SG1uRARnP0G5WoQjGxN/Qi2xtIeXIitGqcWzw3WKXpjwSUwaXww+POMnB6nVMdXQTMGlDWwv6axeIonw2Tv23f+Yvtm9+lESt5Rp77ylocMiWXG7FYyMBnA0TNu9HjFLXE3RPmzV4rCvbmWGVyxWcH99rjo2NlbgetdAdBsbH7uF8twF/7//M7jRFnjE5ScQ/HBeJ0MyYn/eAreBbkm58FRnttVYe/gfI+WSdSDdCqUIatmZUnuRrj+o0HcMvkuTw9FpOuvb7MDNJZEd9jGTHHbLrfBcfWaiFZ2ZTITSlqWOQ5ktUd/87lLBhzUhbGzePDWg8iXuG3/z7v107y2As+PPX0AB3nusvp6KyxWmGgD0zzkz+w1TIcXDGiKdN9+NEN/lpIQIh0e0gDqqlZ+4ptvPzEbVojr/Gp06cahKotGE5d+yw5JWAR0Xl6+FZnToe/SF1Tfw5C2ERMFkstflBX3xGAuFvoXhSIoTyTRy9L4i9zmDHu6PambunqvidmCbzLh4pozdFwsJ8bsJzUvfh8OUUGvNI2F/69 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(39860400002)(376002)(396003)(346002)(136003)(451199015)(82950400001)(38070700005)(55016003)(82960400001)(86362001)(54906003)(33656002)(316002)(10290500003)(110136005)(478600001)(2906002)(8990500004)(5660300002)(4326008)(66556008)(66476007)(66946007)(8676002)(76116006)(66446008)(41300700001)(71200400001)(64756008)(52536014)(38100700002)(83380400001)(6506007)(122000001)(2940100002)(8936002)(9686003)(7696005)(53546011)(26005)(186003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cVN1K0xkTTlWTUdsWS9uelFwdUJ3VnFuaTkvOXBNSlBDOHRwNWpDOWxPTWVG?= =?utf-8?B?RmNxNWc0TjVUYjBnQUx0UXRNbVpJYjVHOS9FdXVsOHhoSy94RHI3NjQ1MU93?= =?utf-8?B?RHJGeGNud2YzZ2ZmcHlhRkZpeTFIZUNBZ01EYmtaSDVpVDZhY0ZwSmJPcVoz?= =?utf-8?B?eWVPV0EwSlY2aERwRXJNb3djL1JpbTZTQzhGOVNDb0tla0JnU2VYWGc4T2VU?= =?utf-8?B?d01HWGpnbFpwdjYyTjdFclMzNWUvbUdNTXY2MjVxY0NIc3MwKzhQa1NlU3p3?= =?utf-8?B?NTN4b2NJNkFYSEZhdEE1TWZFdmhmVkNQNXRrZURhNWFITGNwdlJaZGxnQU81?= =?utf-8?B?VkUwVXkrQXdFVWJvbENBZi9tWUtKVHpCbWQ4cGVjZndINmJCeDk1QTlSUEZt?= =?utf-8?B?WUkxSU9tZ0dXY1BJTFpDNUVVT3FyZ05xYTFGR3RlYWpYV0o0TUFmWGdNeitD?= =?utf-8?B?QXJINENqWVp5Zy9NVVFTVHhLVnpUeGxSaWxIMnRrc2p2eGM4MCttVHVtUldr?= =?utf-8?B?YWtwT1pXT0E4Tjg1NzFKNXJCdHVyUE5aK0VKNGd1UG5BSUtOaHRDZUR0bExY?= =?utf-8?B?KzErSFdwaXY1Nkh4ZEpoOUk3RUNkWGNXU0M5eU9JMFZjMTZlcFJITUZpZWd1?= =?utf-8?B?UXhOWUF4RG5nY3NZZDJ3MmE4dDhqTHBVS0piU3l5NkMwZ1FUUWhnMEphSmtx?= =?utf-8?B?VmdpWXBXQXpPcHB5bmJBbXJoSWZMVCtpVTRmdWFlNjRBRzZNbE1EOG1TL1pu?= =?utf-8?B?dXZrVlpZbXFVTSt0cy9YV3h4c1oycnhHbi9SNWN1VTJHL3Q3MFgyY1ozZ0xq?= =?utf-8?B?RDhlTU1UbzlUQ093Rmh5MGduMEFmZjVRRHBuemx2dVo2NVV2TkVqak5jcW41?= =?utf-8?B?eDZFVlBGdGoyVXBnU29sbWRhS09SUWhZWnVxYU5MbVJub2FvK2Rlakxxemt0?= =?utf-8?B?SVBIT295endGS1o2ZTA5L0ViWDIyakttTUtJdXVDcmJjMUQ2ZnZBUWh0Ymxo?= =?utf-8?B?Y2RucDhlaGllRjk3TmswTVJlVlU4ODlNelZjREorbzh5YWFDdnAxQkxON3gr?= =?utf-8?B?ZUwyYjUrNkZwWGh3bzF0Z01XTVl0NVlMOUJZMDkxVkJjREZxQk0vaytxdGRx?= =?utf-8?B?WEdQQWI3amdydURYTHdETkFzTVVEMW1TZENzSTFmTHB1c2ZjYzR0Q21wbUtX?= =?utf-8?B?QWd2TnZ1M3d2TWIxZk9aUUdPRHlxV013SDVVdHNBMk5mUXlSWFVmUCtJZlk5?= =?utf-8?B?UlhlLzg2UDNRa0VNczZ3bE43dnprakRuRjdJQ0htQk8rQW00MVM4WlE4RHVR?= =?utf-8?B?aVpReGg2dG5yeVR5YzVzdGdjbjJwWVg4akYzQkxzenoxTTEvZHdwQ01rTlBx?= =?utf-8?B?TWU5SmlqSk9kbGJTbWc3YnJYN2NDRkZnV2h3cy94aGFacTFlN25NUE5sMmNF?= =?utf-8?B?eWp3M0ZVM2YySGZpOTVjZ2xtLzlsbU5VL2czQzF2U1FHS21QV0RQVDF5WGQz?= =?utf-8?B?TnVEZlNHM2dYN1NaWWZZYVJLMExPYk42QzR5M0RqR0ovYVlnb2oyVTc0UlBv?= =?utf-8?B?SDdHb3NZTGNWUzVzRUhZUGwwcUV0WC9SdzY5SmNadUpVdVhiRUVNQlVySDZp?= =?utf-8?B?bkRobTl6aXd0Z0J4Ny9tZzl3Z0pLWFlEZDVkSDBibVU1QVFjZkIrdFIveVFP?= =?utf-8?B?N2dXM0V2VjZsb1B4THlUdjBlOS84ZkYrMXBmdW9zWGVYWm5ZT0x6anRxU0Ro?= =?utf-8?B?RUJ0Y0JXQWRmL2lNTldZd2I4WW9Fdm1CT2duWE9lQ3piZGRKN3BlbGRZQVZG?= =?utf-8?B?RWdoZCtyS2MzUEFvK2xJbmZjcDdvQkQxeUkwTTF4RlJLOWIvRWVnU1JnVFlx?= =?utf-8?B?NXRqVWc1TXJKUXdreUZ3ekFQR1ZBSjhNdjZlYlorNEhUWEVlRTdpd1FkbnIz?= =?utf-8?B?Q0hHN25wNDhPOXUwcVZpWk5xR0JYNldCd2J1NDJFUXdOOE9wUkhCVS9VSTBp?= =?utf-8?B?bDZvR1lzQXdSNVB0SEoyRzhwcWtQYUJFUjQvTllEWk5FSEFibFNRL2wvdTZS?= =?utf-8?B?MlJsaGN2NlRFQ0l0TDNqYmpaL3h6TE9WdW90dz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7839d693-26a1-4f4c-738e-08dad3e1d842 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2022 21:20:17.5250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p3WJxcDgcfqrZW6Plyk17SnIGmdsFmjuE8nRZ8NfSYBvw5xHv9J5vt5T/gm36KJRl2wc3qlh3qDiUXQZ765tsH+t/DGB+l8n5DhmAGC8PhI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZP153MB0648 X-Spamd-Result: default: False [-9.90 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f403:c000::/51]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; TO_DN_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4NNTWG2PmHz3PNJ X-Spamd-Bar: --------- X-ThisMailContainsUnwantedMimeParts: N DQpBZGRpbmcgQW5kcmV3Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aQ0KPiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMSwgMjAy MiA1OjI0IFBNDQo+IFRvOiBBbmRyZXcgVHVybmVyIDxhbmRyZXdAZnViYXIuZ2Vlay5uej4NCj4g Q2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47IFdlaSBIdSA8d2VoQG1pY3Jvc29mdC5j b20+OyBmcmVlYnNkLQ0KPiBoYWNrZXJzQEZyZWVCU0Qub3JnDQo+IFN1YmplY3Q6IFJFOiBbRVhU RVJOQUxdIHBjaWIgbXNpeCBhbGxvY2F0aW9uIGluIGFybTY0DQo+IA0KPiANCj4gDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQW5kcmV3IFR1cm5lciA8YW5k cmV3QGZ1YmFyLmdlZWsubno+DQo+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDMsIDIwMjIg NjoyMSBQTQ0KPiA+IFRvOiBTb3VyYWRlZXAgQ2hha3JhYmFydGkgPHNjaGFrcmFiYXJ0aUBtaWNy b3NvZnQuY29tPg0KPiA+IENjOiBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+OyBXZWkgSHUg PHdlaEBtaWNyb3NvZnQuY29tPjsNCj4gZnJlZWJzZC0NCj4gPiBoYWNrZXJzQEZyZWVCU0Qub3Jn DQo+ID4gU3ViamVjdDogUmU6IFtFWFRFUk5BTF0gcGNpYiBtc2l4IGFsbG9jYXRpb24gaW4gYXJt NjQNCj4gPg0KPiA+IEhpIFNvdXJhZGVlcCwNCj4gPg0KPiA+IEZvciB0aGUgdm1idXNfcGNpYiBk cml2ZXIgeW914oCZbGwgbmVlZCB0byBpbXBsZW1lbnQgdGhlIHBjaWJfYWxsb2NfbXNpLA0KPiA+ IHBjaWJfcmVsZWFzZV9tc2ksIGFuZCB0aGUgbXNpeCB2ZXJzaW9ucywgYW5kIHBjaWJfbWFwX21z aS4NCj4gPg0KPiA+IEZvciBhbGxvYyBhbmQgcmVsZWFzZSB5b3UgY2FuIGp1c3QgY2FsbCBpbnRv IHRoZSBzYW1lIGludHJfKiBmdW5jdGlvbg0KPiA+IGFzIHBjaV9ob3N0X2dlbmVyaWNfYWNwaS5j LiBZb3XigJlsbCBuZWVkIHRvIHBhc3MgaW4gdGhlIHhyZWYgZm9yIHRoZSBpbnRlcnJ1cHQNCj4g Y29udHJvbGxlci4NCj4gPiBJdCBuZWVkcyB0byBiZSB0aGUgeHJlZiB0aGUgTVNJIGNvbnRyb2xs ZXIgcmVnaXN0ZXJlZC4gRm9yIHRoZSBHSUN2Mm0NCj4gPiBpdOKAmXMgQUNQSV9NU0lfWFJFRi4N Cj4gW1NvdXJhZGVlcF0NCj4gSSBhbSBjdXJyZW50bHkgc3BlY2lmeWluZyBnaWNfbWJpX3N0YXJ0 IGFuZCBnaWNfbWJpX2VuZCB3aXRoIFNQSSBzdGFydCBhbmQgZW5kDQo+IG51bWJlciwgaW4gZ2lj X3YzX2FjcGlfYXR0YWNoKCkgYW5kIEkgY2FuIHNlZSBteSBpbnRyX2FsbG9jX21zaSgpIGFuZA0K PiBpbnRyX21hcF9tc2koKSBhcmUgd29ya2luZy4gQnV0IHRoZW4gbWx4IGRyaXZlciBpcyBnZXR0 aW5nIHN0dWNrIGF0IENSRUFURV9FUSAuDQo+IA0KPiBtbHg1X2NvcmUwOiBXQVJOOiB3YWl0X2Z1 bmM6OTY3OihwaWQgMCk6IENSRUFURV9FUSgweDMwMSkgdGltZW91dC4gV2lsbCBjYXVzZQ0KPiBh IGxlYWsgb2YgYSBjb21tYW5kIHJlc291cmNlDQo+IG1seDVfY29yZTA6IFdBUk46IG1seDVfc3Rh cnRfZXFzOjU4ODoocGlkIDApOiBmYWlsZWQgdG8gY3JlYXRlIGFzeW5jIEVRIC02MA0KPiBtbHg1 X2NvcmUwOiBFUlI6IG1seDVfbG9hZF9vbmU6MTE1NzoocGlkIDApOiBGYWlsZWQgdG8gc3RhcnQg cGFnZXMgYW5kIGFzeW5jIEVRcw0KPiBtbHg1X2NvcmUwOiBXQVJOOiB3YWl0X2Z1bmM6OTY3Oihw aWQgMCk6IE1BTkFHRV9QQUdFUygweDEwOCkgdGltZW91dC4gV2lsbA0KPiBjYXVzZSBhIGxlYWsg b2YgYSBjb21tYW5kIHJlc291cmNlDQo+IG1seDVfY29yZTA6IEVSUjogcmVjbGFpbV9wYWdlczo0 NDQ6KHBpZCAwKTogZmFpbGVkIHJlY2xhaW1pbmcgcGFnZXMNCj4gbWx4NV9jb3JlMDogV0FSTjog bWx4NV9yZWNsYWltX3N0YXJ0dXBfcGFnZXM6NTc0OihwaWQgMCk6IGZhaWxlZCByZWNsYWltaW5n DQo+IHBhZ2VzICgtNjApDQo+IG1seDVfY29yZTA6IEVSUjogaW5pdF9vbmU6MTY0NDoocGlkIDAp OiBtbHg1X2xvYWRfb25lIGZhaWxlZCAtNjANCj4gDQo+IA0KPiBnaWNfdjNfYWNwaV9hdHRhY2go ICkNCj4gLS0NCj4gLS0NCj4gMzIzICAgICBzYy0+Z2ljX21iaV9zdGFydCA9IDY0Ow0KPiAzMjQg ICAgIHNjLT5naWNfbWJpX2VuZCA9IDkyMDsNCj4gMzI1DQo+IDMyNiAgICAgZXJyID0gZ2ljX3Yz X2F0dGFjaChkZXYpOw0KPiAzMjcgICAgIGlmIChlcnIgIT0gMCkNCj4gMzI4ICAgICAgICAgZ290 byBlcnJvcjsNCj4gMzI5DQo+IDMzMCAgICAgc2MtPmdpY19waWMgPSBpbnRyX3BpY19yZWdpc3Rl cihkZXYsIEFDUElfSU5UUl9YUkVGKTsNCj4gMzMxICAgICBpZiAoc2MtPmdpY19waWMgPT0gTlVM TCkgew0KPiAzMzIgICAgICAgICBkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCByZWdpc3Rl ciBQSUNcbiIpOw0KPiAzMzMgICAgICAgICBlcnIgPSBFTlhJTzsNCj4gMzM0ICAgICAgICAgZ290 byBlcnJvcjsNCj4gMzM1ICAgICB9DQo+IDMzNiAgICAgZXJyID0gaW50cl9tc2lfcmVnaXN0ZXIo ZGV2LCBBQ1BJX01TSV9YUkVGKTsNCj4gMzM3ICAgICBpZiAoZXJyKSB7DQo+IDMzOCAgICAgICAg IGRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IHJlZ2lzdGVyIE1TSVxuIik7DQo+IDMzOSAg ICAgfQ0KPiAzNDAgICAgIGlmIChpbnRyX3BpY19jbGFpbV9yb290KGRldiwgQUNQSV9JTlRSX1hS RUYsIGFybV9naWNfdjNfaW50ciwgc2MsDQo+IDM0MSAgICAgICAgIEdJQ19MQVNUX1NHSSAtIEdJ Q19GSVJTVF9TR0kgKyAxKSAhPSAwKSB7DQo+IDM0MiAgICAgICAgIGVyciA9IEVOWElPOw0KPiAz NDMgICAgICAgICBnb3RvIGVycm9yOw0KPiAzNDQgICAgIH0NCj4gV2UgZG9uJ3QgaGF2ZSBTUEkg cmFuZ2UgbWVudGlvbmVkIGluIEFDUEkgRFNEVCwgc28gSSBuZWVkIHRvIHNwZWNpZnkgaXQgbWFu dWFsbHkNCj4gaW4gdGhlIGNvZGUuDQo+IEl0IGxvb2tzIGxpa2UgTVNJIGludGVycnVwdCBpcyBu b3QgY29taW5nIHRvIHRoZSBtbHguDQo+IElzIHRoZXJlIGFueSBpbnRlcnJ1cHQgcmVtYXBwaW5n IGJsb2NrZWQgYnkgRnJlZUJTRCBrZXJuZWwgaGVyZT8NCj4gDQo+ID4NCj4gPiBGb3IgcGNpYl9t YXBfbXNpIEkgYW0gdW5zdXJlIGlmIHRoZSBjdXJyZW50IGNvZGUgaXMgdmFsaWQgb24gYXJtNjQu IElmDQo+ID4gbm90IHlvdeKAmWxsIG5lZWQgdG8gY2FsbCBpbnRyX21hcF9tc2kuDQo+ID4NCj4g PiBBbmRyZXcNCj4gPg0KPiA+ID4gT24gMiBOb3YgMjAyMiwgYXQgMjI6MjcsIFNvdXJhZGVlcCBD aGFrcmFiYXJ0aQ0KPiA+ID4gPHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tPg0KPiA+IHdyb3Rl Og0KPiA+ID4NCj4gPiA+IEhpIEFuZHJldywNCj4gPiA+IFRoYW5rcyBmb3IgdGhlIHJlcGx5LiBS ZWdhcmRpbmcgZ2VuZXJpY19wY2llX2FjcGlfYWxsb2NfbXNpeCggKSwgaXQNCj4gPiA+IGNhbiBi ZSBjYWxsZWQgaWYgdGhlIFBDSSBkZXZpY2UgaXMgY2hpbGQgb2YgdGhlIGdlbmVyaWMgcGNpYiAo DQo+ID4gRFJJVkVSX01PRFVMRShwY2liLCBhY3BpLCBnZW5lcmljX3BjaWVfYWNwaV9kcml2ZXIs IDAsIDApIC4NCj4gPiA+IEJ1dCBpZiB0aGUgUENJIGRldmljZSBpcyBjb21tdW5pY2F0aW5nIHdp dGggYSBkaWZmZXJlbnQgcGNpYiBkcml2ZXINCj4gPiA+IChsaWtlIHZtYnVzX3BjaWIpLCBpbiB0 aGF0IGNhc2UgZG8gd2UgbmVlZCB0byBpbXBsZW1lbnQgYWxsIHRoZXNlDQo+ID4gPiBmdW5jdGlv bnMgb2YNCj4gPiBwY2lfaG9zdF9nZW5lcmljX2FjcGkuYyA/DQo+ID4gPg0KPiA+ID4gT3IgdGhl cmUgYXJlIHNvbWUgd2F5cyB0byByZXVzZSB0aGVtPw0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4+IEZyb206IEFuZHJldyBUdXJuZXIgPGFuZHJld0BmdWJh ci5nZWVrLm56Pg0KPiA+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMiwgMjAyMiA2OjU0 IFBNDQo+ID4gPj4gVG86IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8c2NoYWtyYWJhcnRpQG1pY3Jv c29mdC5jb20+DQo+ID4gPj4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47IFdlaSBI dSA8d2VoQG1pY3Jvc29mdC5jb20+Ow0KPiA+ID4+IGZyZWVic2QtIGhhY2tlcnNARnJlZUJTRC5v cmcNCj4gPiA+PiBTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBwY2liIG1zaXggYWxsb2NhdGlvbiBp biBhcm02NA0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pj4gT24gMiBOb3YgMjAyMiwgYXQgMTI6NTYs IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aQ0KPiA+ID4+PiA8c2NoYWtyYWJhcnRpQG1pY3Jvc29mdC5j b20+DQo+ID4gPj4gd3JvdGU6DQo+ID4gPj4+DQo+ID4gPj4+IEhpLA0KPiA+ID4+PiBJIGNhbiBz ZWUgaW4geDg2IG5leHVzLmMgaGFzIGltcGxlbWVudGVkIHBjaWJfYWxsb2NfbXNpeCB1c2luZw0K PiA+ID4+IG5leHVzX2FsbG9jX21zaXgoKS4NCj4gPiA+Pj4gV2hpY2ggY2FsbHMgbXNpeF9hbGxv YygpIGZvciBtc2l4IGFsbG9jYXRpb24uDQo+ID4gPj4+DQo+ID4gPj4+IEJ1dCBpbiBjYXNlIG9m IGFybTY0IEkgZG9uJ3QgZmluZCBzaW1pbGFyIHBjaWJfYWxsb2NfbXNpeA0KPiA+ID4+PiBpbXBs ZW1lbnRhdGlvbiBpbg0KPiA+ID4+IG5leHVzLmMgLg0KPiA+ID4+PiBTbywgb24gYXJtNjQgd2hh dCBpcyBjb3JyZWN0IHdheSB0byBnZXQgYWxsb2NhdGUgbXNpeCA/DQo+ID4gPj4NCj4gPiA+PiBG b3IgYW4gYXJtNjQgc3lzdGVtIHdpdGggQUNQSSBpdCBpcyBtb3N0IGxpa2VseSBoYW5kbGVkIGlu DQo+ID4gPj4gZ2VuZXJpY19wY2llX2FjcGlfcmVsZWFzZV9tc2l4LiBGb3IgRkRUIGl0IGNhbiBk ZXBlbmQgb24gd2hpY2ggUENJDQo+ID4gPj4gZHJpdmVyIGlzIHVzZWQuDQo+ID4gPj4NCj4gPiA+ PiBJbiBlaXRoZXIgY2FzZSBpdCB3aWxsIGNhbGwgaW50byBpbnRyX3JlbGVhc2VfbXNpeCB0aGF0 IHRoZW4gY2FsbHMNCj4gPiA+PiBpbnRvIHRoZSBNU0kgY29udHJvbGxlciB0byBhbGxvY2F0ZSB0 aGUgdmVjdG9ycy4gRm9yIGEgR0lDdjMgZHJpdmVyDQo+ID4gPj4gaXQgd2lsbCBlaXRoZXIgYmUg Z2ljdjNfaXRzX2FsbG9jX21zaXggaWYgeW91IGhhdmUgYW4gSVRTIGRldmljZSwNCj4gPiA+PiBv ciBnaWNfdjNfYWxsb2NfbXNpeCBpZiB1c2luZyBNQkkgcmFuZ2VzLg0KPiA+ID4+DQo+ID4gPj4g T24gQUNQSSB3ZSBkb27igJl0IGN1cnJlbnRseSBzdXBwb3J0IE1CSSByYW5nZXMsIGFsdGhvdWdo IGl0IGxvb2tzDQo+ID4gPj4gbGlrZSB0aGlzIGNvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIGV4aXN0 aW5nIGdpY3YybSBkcml2ZXIuIFRoaXMNCj4gPiA+PiBkcml2ZXIgc2hvdWxkIGFscmVhZHkgd29y ayBhcyBhIGNoaWxkIG9mIHRoZSBHSUN2MywgaG93ZXZlciBpdA0KPiA+ID4+IGFwcGVhcnMgdG8g YmUgRkRUIG9ubHksIHNvIHdpbGwgbmVlZCBzb21lIHdvcmsgdG8gYWRkIEFDUEkgc3VwcG9ydC4N Cj4gPiA+Pg0KPiA+ID4+IEFuZHJldw0KPiA+ID4NCg0K From nobody Fri Dec 2 10:44:14 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NNqLt42ckz4j4RD for ; Fri, 2 Dec 2022 10:44:22 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from HK2P15301CU002-vft-obe.outbound.protection.outlook.com (mail-eastasiaazon11020020.outbound.protection.outlook.com [52.101.128.20]) (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 4NNqLs1DTTz4Fq4; Fri, 2 Dec 2022 10:44:21 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=QIPPWpeD; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.20 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kV5tlBCoGOAykNJ77pGk0zdF0bVhthZIbJ7wbAbhpVyG/mSCsWx4OOedeuo2bx4d91rqrJrmhm6zZf2QlBWuww0skB+VGzjywDHmh7ppJJ81HY4mpzes0rDJMIXUJmGjPIaWvDnAK77WDdu3nf+NFsnNGyFMT0Zrf1y8Fljg9Mu9mxSSGzmGlI3pr7A1JDCNLnEh+YaDOE3RAk9Xb1vHOgyX0n3bbtbiSPNwbKb74uBBt97y3x6VMEkVQX6LurNw5CjKuFj+I7p9gn13Lq+ODCuzDk94GCBLJmLB8wwarGHrdhDVGKV6F0PDWJwwGGRJugf/2yYfqxkb+7rTQIb6eg== 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=nJqJNKkBY+rMBuLDXQ1//sucsKcA5m3ugRGZVy/WqnA=; b=cPfgTsPiNAfAGozinQYy4qJuivLGoEb5Thb0u0o2To6mEx4U5seAWiJpW1RXrJql0jM1sVzsSNlXOin0sVcrFSVIEvaW9U0/zLJdnR/OHWReLBU9snoHcmlhsWdx+Rct8O5s38KApt19rKB0u36Hc3qVO26AoJLxUZVRbnKIzO3RFnKQGoEGoJq1+P0tjJ8Yd/yaN/gFQKAW5v+IQmGp2OtuGJpaZvc38RCkvGlSXdk+9daxuODR0X/4WFo4ZXHwaysEIHeUW0qFaxrw1ZCFE1qvUAE1p+VWSFF9nPkPbQ6pZklY5byQyw3roBsVFLhLFf5UGA2g3U/bcylrX76MMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nJqJNKkBY+rMBuLDXQ1//sucsKcA5m3ugRGZVy/WqnA=; b=QIPPWpeDJPv/8i+MxS40+MJ+UcGCX9XprG5lTcSbhv0tnFc92pFgvZUL8wMR3wd7dLJuMU2O5vu+WPbVbn8t5KAbZM2z9jPUbe8cSI5O+i1iSOyxUJfqY+uZ6FtO7nSkBoE8K4CldYqr4Fwy+sLlBb7gUSVrl/hNjtUpZG45noA= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by SI2P153MB0412.APCP153.PROD.OUTLOOK.COM (2603:1096:4:f2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5901.8; Fri, 2 Dec 2022 10:44:15 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%9]) with mapi id 15.20.5901.008; Fri, 2 Dec 2022 10:44:15 +0000 From: Souradeep Chakrabarti To: Andrew Turner , Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" , Li-Wen Hsu Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK5ZC9OggACqbLCAAKS1EA== Date: Fri, 2 Dec 2022 10:44:14 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=cb7f752c-268d-41e0-9b42-84d4b73decbb;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-12-01T11:09:47Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|SI2P153MB0412:EE_ x-ms-office365-filtering-correlation-id: 5a3fbcb3-b4f4-4dee-63f2-08dad45227ca x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HqQKIlJtmEW8wxRxw8sPL6n57J5nK6yUUxfmbp4BDfOqkfaNeY0571Tp5uXdqKTwZXA9PPRy6vTAyvAqenhB29GCD4PmWMYJFpX8ckJ3G9rQd3AjrWOjMnBoYYb9h4K36ESN/EF9Wd+AMhPN/Z0hiOVNC8YOLT9Dg+k1bU82Owu1GbCwL0BoWlDvSMQiv4u2r7+Bg298LuIoBzdcRIpnI867VSNDs6XTaqtx/7+KnDFjckzVopX4foOpoJkunDWRjyoK0fshM/twTomWhdrB090/Zj+uRFnUbljsRLcVsM2sA1oRwlVZEmobn6nKG0RqqtN+HNc2kFCpDEpSuoqRRRmJqegCLb3WBAiUJSYIj9qqmLmkpJtTXhn77NOTUJPl2j0GAFHqDev/E7d8cTVDmlBxBDnwl1njiO03MVvbIj3bY4nB61A7XBN3dMuJVtUVK/RC9f4UQE70xwtxVO/2YNb8isyFYwEMJbfy9hXKIurP317eY3UEHfc3un8BujZsHJ+KvPBbfVwmn7gU1RbaK7B+ipfgRSac0Ig9B5bYMf0vzLoQf82Y3ZHdt877+XQxOM3L8YrINVka3GA6HVNDeKCJstF+Toy0+nBzNr5dW8Zixl+fDLE/jciEbONlQZlKZ04i6er2wnj0l2fvYCh7c5YBOp99zO/b8Y7xTpSlUP3ytucxEjuK0/qh7Ef0A7QpkM+tQFNVLb7RP10acgyJUCrkKYzvouLCIhsKC+KFqcIJC0jhbAgs7z/1jsLO+n7B x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(366004)(396003)(39860400002)(346002)(376002)(451199015)(38100700002)(122000001)(82950400001)(9686003)(33656002)(55016003)(82960400001)(38070700005)(86362001)(54906003)(26005)(316002)(110136005)(186003)(10290500003)(71200400001)(478600001)(7696005)(53546011)(6506007)(5660300002)(52536014)(8936002)(2906002)(83380400001)(4326008)(66446008)(66476007)(66946007)(8676002)(76116006)(64756008)(41300700001)(8990500004)(66556008);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U2RWUHRDOVZOVHFjR3Q0UWZoNG5FMmd5a0JBdnp5ejlER0ZLcEt0R2N3ZUVZ?= =?utf-8?B?dFRveDQ0eVRwOWY1QnFTSURaa01wTHpRL1BXOUIwczkvUmMxL1NqcUlHRWVQ?= =?utf-8?B?LzF1TmpMRFhOOHQxek5pZmczZnBqYSticG5iTVViU1ZHa0tZak1uSjExeTVz?= =?utf-8?B?RjZrcFJHa1FaS1hDMmxjcmc5OUthR2xldHJCb24zUEV4ZVRTME9oR05mU3pO?= =?utf-8?B?eGFTL3U5Yjcva0NoMmsyRXZPUVF5SVlTQTAxRWhxTkcyUlRQU0hJbkVybVEw?= =?utf-8?B?T2EvNVRZUnFxVTJBTUpOaVExSnBaZDVrRExETFlJbE9GOUlKNWZicm1iQzIz?= =?utf-8?B?d1ltTk9BTnhoN1hOQUJDS1YyKzlNcUpPWDJ0QWtYRjBJZEM5ZkJlWmJReGJj?= =?utf-8?B?ZUhheFMyYmFyZXBSSis4amoxWHdQdFJiV3ZTb3pXWTRxMHZmMjlkWm9oWEJR?= =?utf-8?B?dlZ2bkdHZ3hvVXZOMVR3Nk9uVnliZnJ3Z0tqSURadEtuMmlNeldhdXFJNFpR?= =?utf-8?B?SWNlWCtoeHY0NVQ1VEM1Z2xDNDlGRHdaeDd1R3E1SjNxblFnZ1UxbXZlK01X?= =?utf-8?B?aEV1STNIRFJ4dHdUbFA1OEJzS284dUhtYlVwYUQ4VEc2c2l2VXkxMDEvVVhE?= =?utf-8?B?Nk12QUNwUWpFTUNzcWhYSi9URUErbko0ZjJnRWZZRTZ5NTEwTU9iVENJMFRt?= =?utf-8?B?RFE4OUhHUDZyaW8xZDllNllBajg1Vk80UFpzNEViMGVIMVBvM3phN2R4Uyta?= =?utf-8?B?cFg0MzAvNHppd1FRQnh0VkNpVktZckJ1V2lzY0dOSTdIajBtNHZkNHJKL0s1?= =?utf-8?B?V0lZaWdpYUNsNVpvb1dDV2hhY0NrUWtVc3JyRndGSVdXK3YwbkJJMy94OURI?= =?utf-8?B?dU9FajA1eXR6UHdhS2dSMU1FRXFTWVR6dlVicHl2eDVwL0lxMVBPbllHcU85?= =?utf-8?B?SVZ5cUZSb2gyUjdIUGFQdnhIRVpvdG13eUFQekZiMUR2UUZyRHVrL3FFTk1M?= =?utf-8?B?NUg2Z2tBcFg3Uyt6WkJNU1Q5MGFaa0xhdFVNb3c4WDFxTzBKbE5JaSt1UkJF?= =?utf-8?B?RUZZNkFpd1E3cGNBWFVEUG9hRmxTb3AwUk5YelI3V1Y0Y0FITnFKMng5Zlp3?= =?utf-8?B?NXNiaXRUMzZvdW1YZng0RW0xNXZ2NEpHNVpvYnpoRVcweVhWUHBQYTJNSjNN?= =?utf-8?B?ZDAvditRa2tFV1AzQ2VLUVpIa2xXMVJZWm81cHZ6eEdxdWtWMnBFcmpERElW?= =?utf-8?B?SXM5QlN4RU94R21NZ2tzSlc2bjcyN3BVT09JNW1oMk9KUDljY00ycy9heG9G?= =?utf-8?B?Qk84elJkWDE0Vy9PVGUxcEYxKzFjUmFJVDlxMXRCNUlhc3dFaWw5cm9PYWFQ?= =?utf-8?B?Y3IwSkdkeWR6OEsvcjFBY1JPejMrSnZsMUVMNGpwS0xEeG93MXZCVVN1Ni9S?= =?utf-8?B?cHRaV1ZlY2tIcTRRbkc4NndOaktEc1kvVzU4a1dLZ1Y3NitmT1BETDhYK05u?= =?utf-8?B?a2VJOUEwazF5UTdVL1BnWnp5Y1ZBcEQzVVIyTzJ0MTdEcHNsWmtvUWFHN3Z0?= =?utf-8?B?OHBqSStwc2ZtdVFJNnJ2OE4vam0yeTc3L0hleDRCc1Z0WVZsbU53dW5meUJ3?= =?utf-8?B?M1M1dmpHWk9rMGc3dlZtelRvSGo3YXZXeFVOcVFMb2hpUHkyUHMxajdwUC9l?= =?utf-8?B?KzdZVEp4MmNwdUwveVlDaWphQnpKRVFBUEdZZmRBMUpySkgvQk0yT1VyWUdn?= =?utf-8?B?eVU1akxIT01OakxGY2JlbkZhR3FUVjhkOFA1YjNFbkJibXYwWjdVQ0lmVUJk?= =?utf-8?B?RU5uekt4YzZnSVRmOG9URGhvQ0N5OFR1UVpuRi9yeUlzZ1phRCs1MHFXb3Nh?= =?utf-8?B?YWZ6dVpPVDh5TmlMSVBJb2RNYWl6WFdKODkxRXFDWXZJc1BNdWRIcE91dkhK?= =?utf-8?B?cTBoSytmWnBtSmd2U25rY3lPQ2NSTXpLU1kwbmVITnFBNlg5alo4VzFXOWJy?= =?utf-8?B?Qy9TT1JIcnhzemM5QWhiNGRLMTZFeEN4Y0FuNWF4NEltc2QwOVppOWMxZTJu?= =?utf-8?B?ZGRpSlE3WFFvaVY5RkFrWnpwZmNwZ29BWU4wZz09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 5a3fbcb3-b4f4-4dee-63f2-08dad45227ca X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2022 10:44:14.6251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HDqoi2wKvUc+wqeTJxRwWcAT3KKBdZyw2pGSFboPaunOq8vgMLNMcgV4S7zzF5dhlAUSGVq92GdlVwAWYnuz47B3HtPT7AiHPqvlNp/kVM8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2P153MB0412 X-Spamd-Result: default: False [-9.90 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.20:from]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[6]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4NNqLs1DTTz4Fq4 X-Spamd-Bar: --------- X-ThisMailContainsUnwantedMimeParts: N DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTb3VyYWRlZXAgQ2hh a3JhYmFydGkNCj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAyLCAyMDIyIDI6NTAgQU0NCj4gVG86 IEFuZHJldyBUdXJuZXIgPGFuZHJld0BmdWJhci5nZWVrLm56PjsgQW5kcmV3IFR1cm5lcg0KPiA8 YW5kcmV3QGZyZWVic2Qub3JnPg0KPiBDYzogV2FybmVyIExvc2ggPGltcEBic2RpbXAuY29tPjsg V2VpIEh1IDx3ZWhAbWljcm9zb2Z0LmNvbT47IGZyZWVic2QtDQo+IGhhY2tlcnNARnJlZUJTRC5v cmcNCj4gU3ViamVjdDogUkU6IFtFWFRFUk5BTF0gcGNpYiBtc2l4IGFsbG9jYXRpb24gaW4gYXJt NjQNCj4gDQo+IA0KPiBBZGRpbmcgQW5kcmV3Lg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aQ0KPiA+IFNlbnQ6IFRodXJz ZGF5LCBEZWNlbWJlciAxLCAyMDIyIDU6MjQgUE0NCj4gPiBUbzogQW5kcmV3IFR1cm5lciA8YW5k cmV3QGZ1YmFyLmdlZWsubno+DQo+ID4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNvbT47 IFdlaSBIdSA8d2VoQG1pY3Jvc29mdC5jb20+Ow0KPiBmcmVlYnNkLQ0KPiA+IGhhY2tlcnNARnJl ZUJTRC5vcmcNCj4gPiBTdWJqZWN0OiBSRTogW0VYVEVSTkFMXSBwY2liIG1zaXggYWxsb2NhdGlv biBpbiBhcm02NA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gRnJvbTogQW5kcmV3IFR1cm5lciA8YW5kcmV3QGZ1YmFyLmdlZWsubno+ DQo+ID4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMywgMjAyMiA2OjIxIFBNDQo+ID4gPiBU bzogU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3JhYmFydGlAbWljcm9zb2Z0LmNvbT4NCj4g PiA+IENjOiBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+OyBXZWkgSHUgPHdlaEBtaWNyb3Nv ZnQuY29tPjsNCj4gPiBmcmVlYnNkLQ0KPiA+ID4gaGFja2Vyc0BGcmVlQlNELm9yZw0KPiA+ID4g U3ViamVjdDogUmU6IFtFWFRFUk5BTF0gcGNpYiBtc2l4IGFsbG9jYXRpb24gaW4gYXJtNjQNCj4g PiA+DQo+ID4gPiBIaSBTb3VyYWRlZXAsDQo+ID4gPg0KPiA+ID4gRm9yIHRoZSB2bWJ1c19wY2li IGRyaXZlciB5b3XigJlsbCBuZWVkIHRvIGltcGxlbWVudCB0aGUNCj4gPiA+IHBjaWJfYWxsb2Nf bXNpLCBwY2liX3JlbGVhc2VfbXNpLCBhbmQgdGhlIG1zaXggdmVyc2lvbnMsIGFuZCBwY2liX21h cF9tc2kuDQo+ID4gPg0KPiA+ID4gRm9yIGFsbG9jIGFuZCByZWxlYXNlIHlvdSBjYW4ganVzdCBj YWxsIGludG8gdGhlIHNhbWUgaW50cl8qDQo+ID4gPiBmdW5jdGlvbiBhcyBwY2lfaG9zdF9nZW5l cmljX2FjcGkuYy4gWW914oCZbGwgbmVlZCB0byBwYXNzIGluIHRoZSB4cmVmDQo+ID4gPiBmb3Ig dGhlIGludGVycnVwdA0KPiA+IGNvbnRyb2xsZXIuDQo+ID4gPiBJdCBuZWVkcyB0byBiZSB0aGUg eHJlZiB0aGUgTVNJIGNvbnRyb2xsZXIgcmVnaXN0ZXJlZC4gRm9yIHRoZQ0KPiA+ID4gR0lDdjJt IGl04oCZcyBBQ1BJX01TSV9YUkVGLg0KPiA+IFtTb3VyYWRlZXBdDQo+ID4gSSBhbSBjdXJyZW50 bHkgc3BlY2lmeWluZyBnaWNfbWJpX3N0YXJ0IGFuZCBnaWNfbWJpX2VuZCB3aXRoIFNQSSBzdGFy dA0KPiA+IGFuZCBlbmQgbnVtYmVyLCBpbiBnaWNfdjNfYWNwaV9hdHRhY2goKSBhbmQgSSBjYW4g c2VlIG15DQo+ID4gaW50cl9hbGxvY19tc2koKSBhbmQNCj4gPiBpbnRyX21hcF9tc2koKSBhcmUg d29ya2luZy4gQnV0IHRoZW4gbWx4IGRyaXZlciBpcyBnZXR0aW5nIHN0dWNrIGF0IENSRUFURV9F USAuDQo+ID4NCj4gPiBtbHg1X2NvcmUwOiBXQVJOOiB3YWl0X2Z1bmM6OTY3OihwaWQgMCk6IENS RUFURV9FUSgweDMwMSkgdGltZW91dC4NCj4gPiBXaWxsIGNhdXNlIGEgbGVhayBvZiBhIGNvbW1h bmQgcmVzb3VyY2UNCj4gPiBtbHg1X2NvcmUwOiBXQVJOOiBtbHg1X3N0YXJ0X2Vxczo1ODg6KHBp ZCAwKTogZmFpbGVkIHRvIGNyZWF0ZSBhc3luYw0KPiA+IEVRIC02MA0KPiA+IG1seDVfY29yZTA6 IEVSUjogbWx4NV9sb2FkX29uZToxMTU3OihwaWQgMCk6IEZhaWxlZCB0byBzdGFydCBwYWdlcyBh bmQNCj4gPiBhc3luYyBFUXMNCj4gPiBtbHg1X2NvcmUwOiBXQVJOOiB3YWl0X2Z1bmM6OTY3Oihw aWQgMCk6IE1BTkFHRV9QQUdFUygweDEwOCkgdGltZW91dC4NCj4gPiBXaWxsIGNhdXNlIGEgbGVh ayBvZiBhIGNvbW1hbmQgcmVzb3VyY2UNCj4gPiBtbHg1X2NvcmUwOiBFUlI6IHJlY2xhaW1fcGFn ZXM6NDQ0OihwaWQgMCk6IGZhaWxlZCByZWNsYWltaW5nIHBhZ2VzDQo+ID4gbWx4NV9jb3JlMDog V0FSTjogbWx4NV9yZWNsYWltX3N0YXJ0dXBfcGFnZXM6NTc0OihwaWQgMCk6IGZhaWxlZA0KPiA+ IHJlY2xhaW1pbmcgcGFnZXMgKC02MCkNCj4gPiBtbHg1X2NvcmUwOiBFUlI6IGluaXRfb25lOjE2 NDQ6KHBpZCAwKTogbWx4NV9sb2FkX29uZSBmYWlsZWQgLTYwDQo+ID4NCj4gPg0KPiA+IGdpY192 M19hY3BpX2F0dGFjaCggKQ0KPiA+IC0tDQo+ID4gLS0NCj4gPiAzMjMgICAgIHNjLT5naWNfbWJp X3N0YXJ0ID0gNjQ7DQo+ID4gMzI0ICAgICBzYy0+Z2ljX21iaV9lbmQgPSA5MjA7DQo+ID4gMzI1 DQo+ID4gMzI2ICAgICBlcnIgPSBnaWNfdjNfYXR0YWNoKGRldik7DQo+ID4gMzI3ICAgICBpZiAo ZXJyICE9IDApDQo+ID4gMzI4ICAgICAgICAgZ290byBlcnJvcjsNCj4gPiAzMjkNCj4gPiAzMzAg ICAgIHNjLT5naWNfcGljID0gaW50cl9waWNfcmVnaXN0ZXIoZGV2LCBBQ1BJX0lOVFJfWFJFRik7 DQo+ID4gMzMxICAgICBpZiAoc2MtPmdpY19waWMgPT0gTlVMTCkgew0KPiA+IDMzMiAgICAgICAg IGRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IHJlZ2lzdGVyIFBJQ1xuIik7DQo+ID4gMzMz ICAgICAgICAgZXJyID0gRU5YSU87DQo+ID4gMzM0ICAgICAgICAgZ290byBlcnJvcjsNCj4gPiAz MzUgICAgIH0NCj4gPiAzMzYgICAgIGVyciA9IGludHJfbXNpX3JlZ2lzdGVyKGRldiwgQUNQSV9N U0lfWFJFRik7DQo+ID4gMzM3ICAgICBpZiAoZXJyKSB7DQo+ID4gMzM4ICAgICAgICAgZGV2aWNl X3ByaW50ZihkZXYsICJjb3VsZCBub3QgcmVnaXN0ZXIgTVNJXG4iKTsNCj4gPiAzMzkgICAgIH0N Cj4gPiAzNDAgICAgIGlmIChpbnRyX3BpY19jbGFpbV9yb290KGRldiwgQUNQSV9JTlRSX1hSRUYs IGFybV9naWNfdjNfaW50ciwgc2MsDQo+ID4gMzQxICAgICAgICAgR0lDX0xBU1RfU0dJIC0gR0lD X0ZJUlNUX1NHSSArIDEpICE9IDApIHsNCj4gPiAzNDIgICAgICAgICBlcnIgPSBFTlhJTzsNCj4g PiAzNDMgICAgICAgICBnb3RvIGVycm9yOw0KPiA+IDM0NCAgICAgfQ0KPiA+IFdlIGRvbid0IGhh dmUgU1BJIHJhbmdlIG1lbnRpb25lZCBpbiBBQ1BJIERTRFQsIHNvIEkgbmVlZCB0byBzcGVjaWZ5 DQo+ID4gaXQgbWFudWFsbHkgaW4gdGhlIGNvZGUuDQo+ID4gSXQgbG9va3MgbGlrZSBNU0kgaW50 ZXJydXB0IGlzIG5vdCBjb21pbmcgdG8gdGhlIG1seC4NCj4gPiBJcyB0aGVyZSBhbnkgaW50ZXJy dXB0IHJlbWFwcGluZyBibG9ja2VkIGJ5IEZyZWVCU0Qga2VybmVsIGhlcmU/DQo+ID4NCj4gPiA+ DQo+ID4gPiBGb3IgcGNpYl9tYXBfbXNpIEkgYW0gdW5zdXJlIGlmIHRoZSBjdXJyZW50IGNvZGUg aXMgdmFsaWQgb24gYXJtNjQuDQo+ID4gPiBJZiBub3QgeW914oCZbGwgbmVlZCB0byBjYWxsIGlu dHJfbWFwX21zaS4NCj4gPiA+DQo+ID4gPiBBbmRyZXcNCj4gPiA+DQo+ID4gPiA+IE9uIDIgTm92 IDIwMjIsIGF0IDIyOjI3LCBTb3VyYWRlZXAgQ2hha3JhYmFydGkNCj4gPiA+ID4gPHNjaGFrcmFi YXJ0aUBtaWNyb3NvZnQuY29tPg0KPiA+ID4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IEhpIEFu ZHJldywNCj4gPiA+ID4gVGhhbmtzIGZvciB0aGUgcmVwbHkuIFJlZ2FyZGluZyBnZW5lcmljX3Bj aWVfYWNwaV9hbGxvY19tc2l4KCApLA0KPiA+ID4gPiBpdCBjYW4gYmUgY2FsbGVkIGlmIHRoZSBQ Q0kgZGV2aWNlIGlzIGNoaWxkIG9mIHRoZSBnZW5lcmljIHBjaWIgKA0KPiA+ID4gRFJJVkVSX01P RFVMRShwY2liLCBhY3BpLCBnZW5lcmljX3BjaWVfYWNwaV9kcml2ZXIsIDAsIDApIC4NCj4gPiA+ ID4gQnV0IGlmIHRoZSBQQ0kgZGV2aWNlIGlzIGNvbW11bmljYXRpbmcgd2l0aCBhIGRpZmZlcmVu dCBwY2liDQo+ID4gPiA+IGRyaXZlciAobGlrZSB2bWJ1c19wY2liKSwgaW4gdGhhdCBjYXNlIGRv IHdlIG5lZWQgdG8gaW1wbGVtZW50IGFsbA0KPiA+ID4gPiB0aGVzZSBmdW5jdGlvbnMgb2YNCj4g PiA+IHBjaV9ob3N0X2dlbmVyaWNfYWNwaS5jID8NCj4gPiA+ID4NCj4gPiA+ID4gT3IgdGhlcmUg YXJlIHNvbWUgd2F5cyB0byByZXVzZSB0aGVtPw0KPiA+ID4gPg0KPiA+ID4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IEFuZHJldyBUdXJuZXIgPGFuZHJld0Bm dWJhci5nZWVrLm56Pg0KPiA+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyLCAyMDIy IDY6NTQgUE0NCj4gPiA+ID4+IFRvOiBTb3VyYWRlZXAgQ2hha3JhYmFydGkgPHNjaGFrcmFiYXJ0 aUBtaWNyb3NvZnQuY29tPg0KPiA+ID4gPj4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNv bT47IFdlaSBIdSA8d2VoQG1pY3Jvc29mdC5jb20+Ow0KPiA+ID4gPj4gZnJlZWJzZC0gaGFja2Vy c0BGcmVlQlNELm9yZw0KPiA+ID4gPj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogcGNpYiBtc2l4 IGFsbG9jYXRpb24gaW4gYXJtNjQNCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPj4+IE9uIDIg Tm92IDIwMjIsIGF0IDEyOjU2LCBTb3VyYWRlZXAgQ2hha3JhYmFydGkNCj4gPiA+ID4+PiA8c2No YWtyYWJhcnRpQG1pY3Jvc29mdC5jb20+DQo+ID4gPiA+PiB3cm90ZToNCj4gPiA+ID4+Pg0KPiA+ ID4gPj4+IEhpLA0KPiA+ID4gPj4+IEkgY2FuIHNlZSBpbiB4ODYgbmV4dXMuYyBoYXMgaW1wbGVt ZW50ZWQgcGNpYl9hbGxvY19tc2l4IHVzaW5nDQo+ID4gPiA+PiBuZXh1c19hbGxvY19tc2l4KCku DQo+ID4gPiA+Pj4gV2hpY2ggY2FsbHMgbXNpeF9hbGxvYygpIGZvciBtc2l4IGFsbG9jYXRpb24u DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBCdXQgaW4gY2FzZSBvZiBhcm02NCBJIGRvbid0IGZpbmQg c2ltaWxhciBwY2liX2FsbG9jX21zaXgNCj4gPiA+ID4+PiBpbXBsZW1lbnRhdGlvbiBpbg0KPiA+ ID4gPj4gbmV4dXMuYyAuDQo+ID4gPiA+Pj4gU28sIG9uIGFybTY0IHdoYXQgaXMgY29ycmVjdCB3 YXkgdG8gZ2V0IGFsbG9jYXRlIG1zaXggPw0KPiA+ID4gPj4NCj4gPiA+ID4+IEZvciBhbiBhcm02 NCBzeXN0ZW0gd2l0aCBBQ1BJIGl0IGlzIG1vc3QgbGlrZWx5IGhhbmRsZWQgaW4NCj4gPiA+ID4+ IGdlbmVyaWNfcGNpZV9hY3BpX3JlbGVhc2VfbXNpeC4gRm9yIEZEVCBpdCBjYW4gZGVwZW5kIG9u IHdoaWNoDQo+ID4gPiA+PiBQQ0kgZHJpdmVyIGlzIHVzZWQuDQo+ID4gPiA+Pg0KPiA+ID4gPj4g SW4gZWl0aGVyIGNhc2UgaXQgd2lsbCBjYWxsIGludG8gaW50cl9yZWxlYXNlX21zaXggdGhhdCB0 aGVuDQo+ID4gPiA+PiBjYWxscyBpbnRvIHRoZSBNU0kgY29udHJvbGxlciB0byBhbGxvY2F0ZSB0 aGUgdmVjdG9ycy4gRm9yIGENCj4gPiA+ID4+IEdJQ3YzIGRyaXZlciBpdCB3aWxsIGVpdGhlciBi ZSBnaWN2M19pdHNfYWxsb2NfbXNpeCBpZiB5b3UgaGF2ZQ0KPiA+ID4gPj4gYW4gSVRTIGRldmlj ZSwgb3IgZ2ljX3YzX2FsbG9jX21zaXggaWYgdXNpbmcgTUJJIHJhbmdlcy4NCj4gPiA+ID4+DQo+ ID4gPiA+PiBPbiBBQ1BJIHdlIGRvbuKAmXQgY3VycmVudGx5IHN1cHBvcnQgTUJJIHJhbmdlcywg YWx0aG91Z2ggaXQgbG9va3MNCj4gPiA+ID4+IGxpa2UgdGhpcyBjb3VsZCBiZSBoYW5kbGVkIGJ5 IHRoZSBleGlzdGluZyBnaWN2Mm0gZHJpdmVyLiBUaGlzDQo+ID4gPiA+PiBkcml2ZXIgc2hvdWxk IGFscmVhZHkgd29yayBhcyBhIGNoaWxkIG9mIHRoZSBHSUN2MywgaG93ZXZlciBpdA0KPiA+ID4g Pj4gYXBwZWFycyB0byBiZSBGRFQgb25seSwgc28gd2lsbCBuZWVkIHNvbWUgd29yayB0byBhZGQg QUNQSSBzdXBwb3J0Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEFuZHJldw0KPiA+ID4gPg0KW1NvdXJh ZGVlcF0gDQpPbmUgbW9yZSBxdWVzdGlvbiBoZXJlLCB3aGVuIGVuYWJsaW5nIElPTU1VIG9wdGlv biBpbiBhcm02NCwgSSBhbSBnZXR0aW5nIG11bHRpcGxlIA0KY29tcGlsYXRpb24gZXJyb3JzLiBI YXMgRnJlZUJTRCBiZWVuIGNvbXBpbGVkIHdpdGggSU9NTVUgZm9yIGFybTY0Pw0KSW4gZmlsZSBp bmNsdWRlZCBmcm9tIGlvbW11X2lmLmM6MzE6DQouL2lvbW11X2lmLmg6MTczOjMzOiBlcnJvcjog dW5rbm93biB0eXBlIG5hbWUgJ3BjZWxsX3QnDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHBjZWxsX3QgKmNlbGxzLCBpbnQgbmNlbGxzKTsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgXg0KLi9pb21tdV9pZi5oOjE3NjozOTogZXJyb3I6IHVua25vd24gdHlwZSBuYW1l ICdwY2VsbF90Jw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwY2VsbF90 ICpjZWxscywgaW50IG5jZWxscykNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgXg0KMiBlcnJvcnMgZ2VuZXJhdGVkLg0KL2RhdGFkcml2ZS9zYW5kYm94My9zcmMvc3lzL2Fy bTY0L2lvbW11L3NtbXVfZmR0LmM6MjA4OjExOiBlcnJvcjogdG9vIG1hbnkgYXJndW1lbnRzIHBy b3ZpZGVkIHRvIGZ1bmN0aW9uLWxpa2UgbWFjcm8gaW52b2NhdGlvbiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMCwgMCwgQlVTX1BBU1NfSU5URVJSVVBUICsgQlVTX1BBU1NfT1JERVJfTUlE RExFKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBe ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgL2RhdGFkcml2ZS9zYW5kYm94My9zcmMvc3lzL3N5 cy9idXMuaDo4MjY6OTogbm90ZTogbWFjcm8gJ0VBUkxZX0RSSVZFUl9NT0RVTEUnIGRlZmluZWQg aGVyZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAjZGVmaW5lIEVBUkxZX0RSSVZFUl9NT0RVTEUobmFtZSwgYnVzbmFtZSwgZHJpdmVy LCBldmgsIGFyZywgcGFzcykgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgL2RhdGFkcml2ZS9zYW5kYm94My9zcmMvc3lzL2Fy bTY0L2lvbW11L3NtbXVfZmR0LmM6MjA3OjE6IGVycm9yOiB0eXBlIHNwZWNpZmllciBtaXNzaW5n LCBkZWZhdWx0cyB0byAnaW50JyBbLVdlcnJvciwtV2ltcGxpY2l0LWludF0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFQVJMWV9EUklWRVJfTU9EVUxFKHNtbXUsIHNpbXBsZWJ1cywgc21tdV9mZHRfZHJp dmVyLCBzbW11X2ZkdF9kZXZjbGFzcywgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQo= From nobody Fri Dec 2 23:34:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NP8Rw6gD0z4jgCP for ; Fri, 2 Dec 2022 23:34:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NP8Rv5THfz4YTc for ; Fri, 2 Dec 2022 23:34:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=SFWvxBMg; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670024088; bh=ARh77kr9UTEjmy7gNZ+9bgK6u5oQ3snnQcLdpnWbJ24=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=SFWvxBMgHpgIl8KEENY2H4fSRXByNJxWYLktPyZLRCAKitPp94OKXmxkuTPABffx56tfs/HoLkyE6jy/DaVnLDyGd8z5jHz3A4ijjAanLWmaDYnBGKwsLc4rK/v6NWbgA9tMJ1zwqrcMB4hnNMlxqgjwPofdszbRbfmmZldv58z0p0vsBkKKtvoxz9q/PYLSOGWO2r3kt1iM9dKxOdwmfgT4MKw6q1A8HlfEITgda+ZxkgfFohOf+H8FAKNHviTFRa+9zQTsKWIm08ijOB93PPQ3O8d7kRldWTY7z1+lsJqUEcdp89w1mC2kdLv6bPYohU+6wRIxzzVEKaKrqny4/A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670024088; bh=z3TFDX0oFmXHc8btBHgNrnxaNdtZozQnt1itqdMfDOp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=kXY31ELuUWdcx8oSTAaW++ri5Dq5aYChqUla5mnhRymniptNrz6liNog7aH4W17vBISOR73jbMWjKJ714aOjjWobjjWujhqPcM/WjbRTsJ6J57FLpzwA1Up665MkahTYSHxOEkiuCOhW+HWN/vP8D4uOhWg0R/ovZK3wtUinbYHXbLdZm33Oqv/JwTMRsM8I8TFaZTsZ6/VL67z4NdZ6ZcG/RvF+iUtLYgLbN1GSoiGsPA7zvUzWCORo0MPcob9mUKuUT3WmQvJvHr1Vikx+77M88///7oDHKKFv1wzRtJdgtN5PvmoxVQaX/vgpJU+fKuGPhaXMQhOW3CLTx9f5Iw== X-YMail-OSG: G_0DpPwVM1nMF8FabBaLpndkbfjc0NjOY.cI7VSh7UoSze2E.e6hxbllDX_4Krl KTH2D100HHYQ8N1SNAZCSXw8rxcs1UmoBWYzquV7cwejq3lMd3iwWZkHm19YExv_cv1BUu93fdwr B9BPMk9OzCRFxgvhE3v2uDqZW82jCG2i3vvCl4hkePiYHCEg3xwvGfxf0lUByZSp62tHrImxjaFe DlVH2x9brt5E7oFHFH6j8ZG313DVZgzlLYG0I3JMK9JLqeV8fv1twBXy0STGtobvIqdGffb1OdrH Mggb5JdDCY3NPqG93p1XlntLIgIR.nEpPOGj4OzmAOS4MvaAorUYww5tSXkclArJXKDQyWcRv6wh .wIuu5OYeC3KU9pc3KCcz1IJgesuZg4HHp.JNKKB9Vgu9NCpgcTUR1KxtrC2nTM1Rp.Hopox4dOC uqgzQTjt0Io3XqB5ZJXWaYZuS8RTv6pTNiDXy3W0Hwqo1BSp1UTJO04OJp.tQq1iUOuLp43iPt1D XVkdj.APj_g2DiqSYEamSellYliZr8yIVpPQwO33THrPnF8vHerXUJJUJcpiM0JHp2NJSvkg0IFM uvgNis9CqhJUX6.g.4I0hSNdG4BOPeHY.AkO3VAWODq3LQxg35lmYMdZmGiqtkqZTknjRRkvx1ex HIoUIDSgBivYYha6BVAF37fr4nfYdSxGwfoUpxQVkYWTc.Xi6JEJlpEImIX4gVRTE0UbT.X5QlMI 5zky0yAam1MbTJdIi_qSzvxp6yto604Sm.H3VqqNNSdAy6gTC6WmC7pRHjHOwDGRR7EhN6EpjpSN AsFEND2JM1PtC2c5j7r2fFkJAcw.xT4XxkS_1wtm3vxrpEq2uZ47P6EZwQTGGu4B1cfG8P9ZLhSH Fm9WdF2NEVSyOyb6uv9R5f0UUDt8EZ8V8RumE2FEZhyKERixqMvT5ekFnWssBqGceNiZOyINcqxX SQSd6lyExU44Tv9vsnVKDb1EjMQqyU7GvRM8fXQOjkdXide.FPxWCLfYAXJfHetHFIh6FQQ0pPys SaJmrXqCU.T2zCAEDBBql6p3LrjtGlzSKZcYv_lSIKTJEJCKB7MwWxWZDZrlasa8WbBdsn69zK.R _yTzJ7H_VcZtLzrGUY.bq5xQVE6hTZKeLxQfNioswcDZehSb2l5iTZVhc6.K_li7M1Wbo6bDwl16 D2lOBwO31zMGmGAGTYGsvM9l5RyEGAtZiQ05JKGsRTuTkEwknhvhnSysR_69QUoncsx39J7u3qmp vpi7KSMhHZ6JffLFjS5c7fzGVZ3KU4l0HRkz9tTUiLpxXR0S0Rh_a7uyc5eBCrq28m7KAQmszQf5 Y47Kzy6JV7sH005FmhaqQ.vnU7kdtu_Cg_ZDvlUqd.ko5oUet9FeD3xLSLxXYbKqyPKYuq6_3w_p NMgw.Aw0gh1kvBRQThjdsUf8xCFkK6YiG81c.HG4c74gzorIxMDYGM7VG5qQccKqf1onsi_qZe.9 Sqn9hjPGPou58cgOy1suHuCkbif.UkxlJ4g7_bEXsAKrYPlhLb7qg0sx2twPw3O_iKX949SD3tQU FUUbxo_oqJBALFBdCRttL1nFFaomIBhSU2MCToTMZ8uE7eVaPl3obrxWxME3rl14G8_1PEys9CWi D8B25sYQqoiEuTM03HAAZDtAsVjndcLqINZDeJAVoU4Gm5A3CeOmnW2O6nzxPMkQLpKtFXGYVfii 6ncBcVdxrFmov9.2bdFnbaDJt0NoqU_d1INFh3TgSYeVgKbvRR3SXonm8.H9T_r6t8z5jiv1PsIH IS319BQf1oUTcw6oY1AylMHXHXyjmIDthxlN8CZjjTTneU.kaZj3iOwfjdkkVdYBVKpQdqULyzxn piW5fC9SRwd6QTTKIUOMrXBb.zweEXKMxvJRxRuvVeDExDaT7L8kx8O7ITQlf4HH3ImEmlP0W4zr OnLUPRs.lXo2mZQopSXN70ECaS2FWTelPIYaLmUjZu11vYtjOZsesmgFhmjpQyRkOw_3ReAFR_.I 16LkeCmqV670Ijwd7aRQKuOxvbnCNWVjNDhQm2P6PGbhlxXL3qCpzwpRJsp4DZ.iKNcHTG58NoPX x5nJzOX53aYrRkaT61I2LPgdPq1RZPIl8jAHscfsj0M7CG_4YsmJ67EBVyJ0r0j7xPsayXYkgleE .24DsXwFowB2r2HecSZF1DiiczGP15HBcrsXjLKhI0yikU3btm36WrQHgepEM6HY87URFaN3dBmC amWgMHj2O2fr2FzueNEHkeMqvFtw7E.54boD9QC.lOFcYFf9S8yXoOzWadQtEiiuZJAgHnabwSMk E X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Fri, 2 Dec 2022 23:34:48 +0000 Received: by hermes--production-bf1-5458f64d4-2b7vw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a2add2a49fb2038e614f303f4cefd114; Fri, 02 Dec 2022 23:34:42 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Does the RPi* DMA code in the kernel handle the distinctions between the 3 kinds of DMA engines? Message-Id: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119@yahoo.com> Date: Fri, 2 Dec 2022 15:34:24 -0800 To: freebsd-arm , FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <18DF2CDD-3BC2-4100-9B8E-3BFD08F1F119.ref@yahoo.com> X-Spamd-Result: default: False [-1.12 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_SPAM_SHORT(0.37)[0.374]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from] X-Rspamd-Queue-Id: 4NP8Rv5THfz4YTc X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Does the RPi* DMA code in the kernel handle the distinctions between the 3 kinds of DMA engines? The engine types are named: DMA engine (30-bit DMA addressing: 1 GiByte, 256-bit burst space) DMA lite engine (only 128 bit burst space, no YLENGTH, TDMODE, S_STRIDE, D_STRIDE registsers, only 16 bits for DMA length (?_TXFR_LEN XLENGTH), no SRC_IGNORE or DEST_IGNORE modes, only about half the bandwidth of type DMA, uses ENABLE Regsiter 31:28 "PAGELITE" instead of 27:24 "PAGE" to control the "1G SDRAM ram page" used) DMA4 engine (not the same as dma4 of specific engines dma0..dma15; different register map offset pattern after ??_CB, more register map offsets than the other DMA types, 40 address bits with 40:32 in ??_SRCI/??_DESTI 7:0, ??_CB bits 31:0 are for Control Block Address 36:5, higher performance via "uncoupled read/write design", write burst capable, directly accesses the BCM2711 35-bit address bus so bypasses the paginging registers that are used for types DMA and DMA lite) The specific instances of engines (channels) have types: dma0 ..dma6 : Always type DMA (so far?) dma7 ..dma10: Always type DMA lite (so far?) dma11..dma14: Not the same for BCM2711: For BCM2711, type DMA4 Otherwise, type DMA lite (so far?) BCM2711 specific note: dma11 "is additionally able to access the PCIe interface". For reference, the live device tree for the BCM2711 has (examples from an 8 GiByte RPi4B): dma@7e007000 { compatible =3D "brcm,bcm2835-dma"; reg =3D <0x7e007000 0x00000b00>; interrupts =3D <0x00000000 0x00000050 0x00000004 = 0x00000000 0x00000051 0x00000004 0x00000000 0x00000052 0x00000004 = 0x00000000 0x00000053 0x00000004 0x00000000 0x00000054 0x00000004 = 0x00000000 0x00000055 0x00000004 0x00000000 0x00000056 0x00000004 = 0x00000000 0x00000057 0x00000004 0x00000000 0x00000057 0x00000004 = 0x00000000 0x00000058 0x00000004 0x00000000 0x00000058 0x00000004>; interrupt-names =3D "dma0", "dma1", "dma2", = "dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x000007f5>; phandle =3D <0x0000000b>; }; . . . dma@7e007b00 { compatible =3D "brcm,bcm2711-dma"; reg =3D <0x00000000 0x7e007b00 0x00000000 = 0x00000400>; interrupts =3D <0x00000000 0x00000059 0x00000004 = 0x00000000 0x0000005a 0x00000004 0x00000000 0x0000005b 0x00000004 = 0x00000000 0x0000005c 0x00000004>; interrupt-names =3D "dma11", "dma12", "dma13", = "dma14"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x00003000>; phandle =3D <0x00000040>; }; Note: dma15 "is exclusively used by the VPU" and I ignore it here. I ask, in part, because of: #define BCM_DMA_CH_MAX 12 that is used via the likes of: struct bcm_dma_ch sc_dma_ch[BCM_DMA_CH_MAX]; and: for (i =3D 0; i < BCM_DMA_CH_MAX; i++) { But the BCM2711 only has 0..10 defined for brcm,bcm2835-dma in its device live device tree, although brcm,dma-channel-mask allows avoiding what is missing. 11..14 are defined in brcm,bcm2711-dma instead --but the code makes no use of it, given the brcm,bcm2835-dma's brcm,dma-channel-mask. But/also, the brcm,bcm2835-dma's brcm,dma-channel-mask includes examples of both "DMA engine" and "DMA lite engine", so still leading to some distinctions that should be made. So far, I've not been able to identify code/data making any distinctions for the likes of dma7..dma14 beyond what brcm,dma-channel-mask completely avoids. Note: So far as I can tell, the PCIe bus-mastering that is associated with the XHCI in the BCM2711 is separate from the above. The "B0T" BCM2711 parts have a 3 GiByte limitation just for this PCIe bus-mastering(/XHCI) and the "C0T" BCM2711 parts no longer are limited to a subset of the available RAM for PCIe bus-mastering(/XHCI). Examples from 8 GiByte RPi4B's: dma-ranges =3D <0x02000000 0x00000004 0x00000000 = 0x00000000 0x00000000 0x00000000 0xc0000000>; vs. dma-ranges =3D <0x02000000 0x00000004 0x00000000 = 0x00000000 0x00000000 0x00000002 0x00000000>; So, XHCI related bounce buffering could be avoided on=20 "C0T" parts. For BCM2711 "B0T" vs. "C0T" there is also emmc2bus with: dma-ranges =3D <0x00000000 0xc0000000 0x00000000 = 0x00000000 0x40000000>; (so: matching the soc dma-ranges, other than the #of = cells for holding the 1st addr) vs. dma-ranges =3D <0x00000000 0x00000000 0x00000000 = 0x00000000 0xfc000000>; (so not matching the soc dma-ranges) emmc2bus contains: emmc2@7e340000 { compatible =3D "brcm,bcm2711-emmc2"; . . . which looks to mean that the dma_ranges for brcm,bcm2711-emmc2 changed to not match the soc dma-ranges. I've not noticed any code/data that would track this change. I do not know the implications of the difference for what FreeBSD's code does --or if FreeBSD ever tries to use the brcm,bcm2711-emmc2 . =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Dec 3 15:49:46 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPZ5Y5F2Nz4jhWG; Sat, 3 Dec 2022 15:50:25 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPZ5X6WxCz3r8R; Sat, 3 Dec 2022 15:50:24 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Nv2dOyQA; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x534.google.com with SMTP id d14so5215992edj.11; Sat, 03 Dec 2022 07:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lFqUQWco0ipAdIQ8BXFbnfngQQ8dhXJpHuhHvMzk0O0=; b=Nv2dOyQAiZsJ0pxXJoraVYGOZ22j1Gvqpml7Vf0TnEHzOZoAwAQgUGk17w8oknwx75 wpVgTa2MH/m1K2nV65GwJsBuylPr/1yehu00VodUnQ47u7gSZXGTfyElviv7pnQyNQzq Kbv1Q1hPj9lPbTNyGOd0dji4aAOjtKzJBXTTrs88yviVHdg3NJKAbhpdAO74Jnzzw3Sn LwLyHeIZg5Eu28rffyRRjV4KafS6UxUeVZCPXG97Wc+Rr2S79iRLomFMeR5zFCrpwfwX y0GWb/sQ5d4sXhTWhWE+vsNna4G7W4lHJ3eigXvs1Y+ON9Mg2trO+fQMNSTboQdkv2f6 teWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lFqUQWco0ipAdIQ8BXFbnfngQQ8dhXJpHuhHvMzk0O0=; b=vl15HnXiS7sfsfB8pyTYLlh1O3R2N9ZCnOXyQfdO7LYDsOgwZalWaPLwT5jR0b+hrA kVBSuIC06omCE9KDqy6ItRFIPnClF66rq2G5M3dW+rEFZyq/j2DWZe8YO9vCgzJ/n2HL 1bjmGc4cHvKpWbbsc6fWmcrDesrJmOVWoYe9lE2nWbp83wH8KMURfD5DBXEp0oyANnYS RJ46Bd7YCMzciZJTC7WcaqrCM7YyJmCiaMEX9Dd43jYWbY0wCQ988xzpWgTSiUoWfumu QiXGh2sw/VttFL7Ot11FZRjWGYFkJgCjJZBb3/crxPBAK0nS03uiHgMBaTqmcJEZnLxx MYYg== X-Gm-Message-State: ANoB5plK8gyWGUMzKmW/mQhp+HPryM3OM7MJ2FgjSOTGa30ArC+NuMVL 9B+vg1H8QmbR6EMwyaBmjaqsiHDFGTsdNZzMd/pX72BQ4VnUcA== X-Google-Smtp-Source: AA0mqf67mmWXG47JHj/DXMug92/gtdy3se0PgctfMZkFzGdEoLQ/q2X0V+qiDKVmTZwi5XpCmelo5J+KNqoMh459LpM= X-Received: by 2002:a05:6402:5483:b0:468:d5a9:cb4b with SMTP id fg3-20020a056402548300b00468d5a9cb4bmr53240050edb.409.1670082622496; Sat, 03 Dec 2022 07:50:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Sat, 3 Dec 2022 16:49:46 +0100 Message-ID: Subject: How to use the framebuffer as primary video device instead of the nvidia passed-through graphic card in a bhyve/linux vm To: freebsd-x11+help@freebsd.org, FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000075a67d05eeee695a" X-Spamd-Result: default: False [-0.43 / 15.00]; URI_COUNT_ODD(1.00)[9]; HTTP_TO_IP(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.57)[0.571]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::534:from]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[help]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-x11@freebsd.org,freebsd-virtualization@freebsd.org,hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NPZ5X6WxCz3r8R X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N --00000000000075a67d05eeee695a Content-Type: text/plain; charset="UTF-8" Hello to everyone. what Im trying to do is to set the framebuffer video adapter as primary graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti card that I have passed through. What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the secondary the nvidia. I tried different Xorg configurations,but what I've got is that Xorg failed to display some errors. So,the controller that you see below should be used as primary inside the ubuntu vm : 00:1d.0 VGA compatible controller: Device fb5d:40fb while the ones you see below as secondary : 08:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) 08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Controller (rev a1) 08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (rev a1) 08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Controller (rev a1) The script that I use to launch the vm is the following : #!/bin/sh setxkbmap it vms="$(ls /dev/vmm/*)" vncs="$(ps ax | awk '/vncviewer [0]/{print $6}')" for vm in $vms; do session="${vm##*/}" echo "bhyve session = $session" echo "vnc session = $vncs" if ! printf '%s\n' "${vncs}" | grep "${session}"; then printf 'VNC session not found,destroying ghost vms\n' bhyvectl --vm=$session --destroy else printf 'Found VNC session %s\n' "${session},no ghost vms found,not destroying them" fi done vmdisk1=`geom disk list | awk '/^Geom name: /{d=$NF} /^ *ident: (2015020204055E)/ && d{print d}'` echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1" mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2' bhyve -S -c sockets=1,cores=2,threads=2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bootindex=1 \ -s 3,virtio-blk,/dev/$vmdisk4 \ -s 4,virtio-blk,/dev/$vmdisk2 \ -s 8:0,passthru,2/0/0 \ -s 8:1,passthru,2/0/1 \ -s 8:2,passthru,2/0/2 \ -s 8:3,passthru,2/0/3 \ -s 10,virtio-net,tap19 \ -s 11,virtio-9p,sharename=/ \ -s 29,fbuf,tcp=0.0.0.0:5919,w=1600,h=950,wait \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 For sure ,on /boot/loader.conf I've added : /boot/loader.conf pptdevs="2/0/0 2/0/1 2/0/2 2/0/3" As I said before,I tried two xorg conf files to achieve the goal. On the first one I tried to add only the framebuffer,like this : Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "vnc" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" Identifier "Card0" Driver "modesetting" BusID "PCI:0:29:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection but it didn't work. This is the log file that shows the errors reported : https://pastebin.ubuntu.com/p/Gv7wgsDR4K/ I have also removed the xorg.conf file,but it didn't work either. This is the log file that shows the errors reported : https://pastebin.ubuntu.com/p/wNcfQTByQm/ Can someone give me some suggestions that can help me to understand where the mistake is,please,thanks. -- Mario. --00000000000075a67d05eeee695a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to everyone.

what Im trying to do is to set the framebuffer video adapter as primary=20 graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti=20 card that I have passed through. What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the=20 secondary the nvidia. I tried different Xorg configurations,but what I'= ve got is that Xorg failed to display some errors. So,the controller that you see below should be used as primary inside the ubuntu vm :

00:1d.0 VGA compatible =
controller: Device fb5d:40fb

while the ones you see below as secondary :

08:00.0 VGA compatible controller: NVIDIA Corporatio=
n TU102 [GeForce RTX 2080 Ti] (rev a1)
08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Contro=
ller (rev a1)
08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (r=
ev a1)
08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Con=
troller (rev a1)

The script that I use to launch the vm is the following :

#!/bin/sh
setxkbmap it
vms=3D"$(ls /dev/vmm/*)"
vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')"

for vm in $vms; do
                session=3D"${vm##*/}"
                echo "bhyve session =3D $session"
                echo "vnc session =3D $vncs"
                if ! printf '%s\n' "${vncs}" | grep "=
;${session}"; then
                                printf 'VNC session not found,destroyin=
g ghost vms\n'
                                bhyvectl --vm=3D$session --destroy         =
                 =20
                else
                                printf 'Found VNC session %s\n' &qu=
ot;${session},no ghost vms found,not destroying them"
                fi
done

vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (20=
15020204055E)/ && d{print d}'`
echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1"

mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2'

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bo=
otindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 29,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,=
h=3D950,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19


For sure ,on /boot/loade=
r.conf I've added :

/boot/loader.conf

pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3"


As I said before,I tried=
 two xorg conf files to achieve the goal. On the
first one I tried to add only the framebuffer,like this :

Section =
"Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:29:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection


bu=
t it didn't work. This is the log file that shows the errors reported :=
 https=
://pastebin.ubuntu.com/p/Gv7wgsDR4K/
I have also removed the xorg.conf file,but it di=
dn't work either. This is the log file that shows the errors reported :=



ht=
tps://pastebin.ubuntu.com/p/wNcfQTByQm/


Can someone give me some=
 suggestions that can help me to understand where the mistake is,please,tha=
nks.
--
Mario.
--00000000000075a67d05eeee695a-- From nobody Sat Dec 3 16:34:30 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPb4z1cGdz4jmsM; Sat, 3 Dec 2022 16:34:59 +0000 (UTC) (envelope-from corvink@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 4NPb4z1FLWz400b; Sat, 3 Dec 2022 16:34:59 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670085299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=gVhNxPWsOVbu19wMlXAQ+/v4B+DYFy+uy8+uufO6NKs=; b=R4zt9ah/Z2WNALTnr45aDDJTCGZSlCs7LQAMVD63DUG4iwEXNWuw2JUQHSujASOuWOH7p9 ed6URTIyp9xkMSobDblow5FW9TIJpyVZ6L9sgAgsAN5ai2GRXXyRZsb8KaJPkJFWmLusJn lSjZGLoFVPodLb/NgacbOCaJmVuPb8Lx91z41sxYAOz18iS5xQJq0+BPiQASS/jqhauQsA NJzyX2FImMZ/G0jHL8gDqK91ArW5EXYwfQQvy/TlC2/n32LU+yvcMvxirllqiQKROjqylH yAS55xcI+ELKZIEAMVQxIMbuXB5QrvsZjKwdhDnv5952+BmtQ9tO1lu6ixaSsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670085299; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=gVhNxPWsOVbu19wMlXAQ+/v4B+DYFy+uy8+uufO6NKs=; b=jCBROBVyLOSR1QXKo5w+wEyQpPWfV7f7re+jS/IkPDnPraoSpS145BqRB0TprpA5Kq/Lp7 feDQeiFvQVdvuNXAM21KwaX29G/gfF2SOWdYTdgFEJQTgHTOcz6Iqq5TidnspvR4bx2OBH K0wUdtiYlvLyYn+6DPdl+3j1+ftSEodIfRVjEM9/H5OlzhLuhwwyOedP7gWENl2qnNa7ce 9k7qM+ej3M4i6jIIaXZvqy0+d3nPwKSSHhOPafODnT6VxbBXVg4YPc33YGcx4KFvoLuLF8 5btpFzNAXfAmFQ5HmBW6qX/70Frot1rhwlwLNjdCPL5YkjXjQd2+xzKDeWEJHw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670085299; a=rsa-sha256; cv=none; b=tOKqHa5UNgMKQz1CUv+zdLzVEXUfksCRPFBttKDoBjTeq1D2P/9ixa27Y9z5Yr91P5RSVy 9XMwbOFWexmsB1z1SCgwuiXdXxnfLBMtdmYMmHIHMzmM2JgkCwmWPuQYwJhDPkiKqqrDcJ INGA3QzUIgY8au9Auhrc8UJXZc5zDnOHAJhkouxsef11Khitjae1R9HN19zPxXJQt1SJT/ ASvJiIFidf/YLboO6ebJN4l8h+lVpua2KY5Ug/JZtWylmR/fImYPvY8RiQslPmjwwLXIud wFsC+jqkYoOhzt1uLMfPrOXRMoK2ZwLd9LV5bCSB03Zw0Cp3mm0+iSjvFz2Ewg== Received: from [IPv6:::1] (unknown [IPv6:2a02:3031:201:1635:2b94:5382:8b33:1405]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NPb4y2Nvyz17jG; Sat, 3 Dec 2022 16:34:58 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Date: Sat, 03 Dec 2022 17:34:30 +0100 From: =?ISO-8859-1?Q?Corvin_K=F6hne?= To: virtualization@freebsd.org, Mario Marietto , freebsd-x11+help@freebsd.org, FreeBSD virtualization , hackers@freebsd.org Subject: =?US-ASCII?Q?Re=3A_How_to_use_the_framebuffer_?= =?US-ASCII?Q?as_primary_video_device_instead?= =?US-ASCII?Q?_of_the_nvidia_passed-through_g?= =?US-ASCII?Q?raphic_card_in_a_bhyve/linux_vm?= User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <2E8B4BF7-A39E-4B93-820D-FC66F8C2F94B@FreeBSD.org> Autocrypt: addr=corvink@FreeBSD.org; keydata= mQINBGNjZaIBEADDTrDNf+0pwiuRPBdClcnZW83dH1UhuOi0u+A1J2SatEBbNaFVtXXAavewCTuy V/ZbNidjlhq3R/pWyiKjFKvs5dj7PMCw+3z2D5OWpMdHg7TrB+fbdFPOEsu0zQVKNaO+pSKCfN0R e0m7bL3wuvl7PXvBufRwA3Guo1P4j3TXWaEkuso7VupTvE25zVGg9ONHrGOjA9RUy+Yg4Se3NLgt UdjBgA21SBQTDvRQV4fDmVenlwvWeE0Xm8FcDcpQb6sJTihaDku78mi3Ux1HCk7rTcepVEB0xIB6 qmFxv0sLlDmVv6Z6qg1y/Q5m23Pgz60o3TulMPV4F+3Itm8ifU+wgVSzBZbD29GYkd7LKqMkFbhv fSBk+5db3vbYY5OD//+LTM5AV7e2AhXuXMvG1UNBqXqSJTTSy6KZz+qmPQO0zos0dq46p8o82lKi BEGD2Hu0p+u0OyV+MmRYo1NIBFVbOPXp2MvUVl5II0UIJ3+N9gLBmfGA+HEpVO8PnvdoT/5NQ7m8 JK1rQHzjiDub/iDPAYMqKH4C0eZ/7zO0fuY5FeRNtuNtpH1Bw/+7/5RJH7bcKkfGHHEp15FJUrGH gWNydoDLB9QBprwQc8FEldDXBjzOMXIgh6FGKLNu6DswvIPGy6M3u7DXwDakCXz+c9Ym0oFihLzZ xWntrsxdswD/CwARAQABtCNDb3J2aW4gS8O2aG5lIDxjb3J2aW5rQEZyZWVCU0Qub3JnPokCVAQT AQoAPhYhBIL0UpWt5trfx9lPRthU2lYxXgJqBQJjY2WiAhsDBQkJZgGABQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJENhU2lYxXgJq98MQAIIWdelHsf146A/4Ykw0+0rqL3/Gep3JeLy4Jkg3SFjC M3hfOj1Iws5/hRSVAS944H5saptF8d398YqeuVeI93RIakpYkLbWCov8OwgfQnwjdaG2H47y189Z 4XLSgKy8FpoYUsisN+giAcX2L+CoR7jzGE3jbB4HTZneZ1HUvR3swT8EvBLSYJd71mHe4fDrdLrF gHdayOm3F7+mHpOlANQpa1EmSMLoGpc8F1OGltt8hFaaNlunZ8oQk++1FdLXj6BtSpZ4njEK+msD f5p7u+2un3VfvvnKeDJbddPDlyYOIkiPKQfz7OEQig1Bc0GkWt6GRANitwz5agTo0ZImj7dUm9JF aFQZYNWvF1Ng2RsiOZM2WQjXY0g0LTTsOK5Xs4X1cdaCttvKW+5m9s4OZslF2FMXL26kBTKBfX/F QBAQgyoyImbJN2/yLQhtnrXVYSVDH1ceAZ5mAzr7f3+Vo3wXCykzqAT/g3Nkchk3QsQE56tmqgX4 iXp5xxCmgRbHudv9GKUmnd1RTK+QGclaD4AkHKiyDznuS++YOdndQH5t6Nalx8W+duSIo9QE8M7u 1Y9vmvbIUOkN79WDnH6xFuSRcZQUPpHHSn9mJEid5VWDx6ZPOENHQgv8FmSr+5UmR1qmFmWLUX/f Vw2B/pkliePGWTzq6JhLJJlBHR0osOqruQINBGNjZaIBEAC4V8zlnLa957NAFPmOuW6cL1W1/E3p MtoxNYMaZmOtEDaOLV645qfie2XXh2Bn44hzN3vZ3ZaWV9FKipGTxCTNL6Im6o8ghKX4cIBiACeS bcAcIdsxCGnFLO46lPm7NYbGGfU532A8QfvpYeO4ue8H+qNWw9lWXCU1djoPwbo9McfyJ7CA3reT 9wgPO4/nAo1StfeiYvkOWoxYwpiNstzUZMmd6dRCJhDtHyy639VB2YsvhyLYVB9yQdv5M2VPk2q+ oodiTK/uZvaoubsIqkVlL/fqBdx+bZOG6eSogqTjTLFN5S6EjL4usCY1Vv19uDhWwuvADuMChu3j PNm4PC8pI6O4DPiWAqt+Aw4WDfKM2ie8JqzCtUXf/Iv+aSiMhNMT0qGn+Ybq98yWXs1k67M7Pheu rWO2hfYtMQJtpHYHqz3T7VC0F4bAPl3rDRL4PJ2Vr9eoo5upVPbZN1JXAA5oEX7coA1BQz/18LlT BhNmHk2wsi5omYZOnBoZelA7kpNx/8zc2zanOnO7NW0dJLq/o4GlfP56UFV8I1MWNyI351BAkIJy Thrjv7aMxLhpNny6uYoms7X2oWf2R//QIMA/0jkqsGirksV4CW+7xhuQVwxGIHR2JskZYaPSjJaX TvoGxu/+SwqT00xnF64ZvwDUGiw7yB70s/LolEOZ/5JqgQARAQABiQI8BBgBCgAmFiEEgvRSla3m 2t/H2U9G2FTaVjFeAmoFAmNjZaICGwwFCQlmAYAACgkQ2FTaVjFeAmrhSw/+NqYqv6oHppWZ7hpt +2Df+qIw2kOgvo0ecU8orastt7OfiJpRzlDFPK2nhok5t4+1PZCi4jcR5Ub22Ddy4O00FOCRAq70 haA+cNNiZ0XlD5cDv+CxmT0NkD337ls5wz8zyOX7n7Z4jG8ghiJEkcLQbyp2qYaggKrz2sGWKUjB yS7jySRCotPOO+0W6Iz2dw9215ZQ1F3uZwdRlpXA7ypzUBEvIJxc563fFuPetbZAIavGMT844hov sMXW2Q/MS3HI03USkgeVaqANbSOUFAdt2tgTrvUw/vXBckp4T+vATNdQH0WieBIX4nRQQ6SjfmaI 82QxJuJjb5NJ6bgS+HPIUH8J1Iw958y/Rs5svzKW+/YYoZBDuhtbAeoJdiy7a7wtK6pBv+xMdpmK LBgVVXOeX6sucwJ/K68tb5aOmbuPLAaIoKgm/9IF8dqiI23JoM2ZhpYZjpVMpakGIxV6R4Kp2hrq C4oNpuVLJ7LQSMuocXduguvWYdYvVXSdpC1Ed+fLtFXA0h5fhDqHFDCDM2CgQX2DfzXe/rV7vChm 61fQYn+85md1vPiefnsaunEh3+cbcFfIshNmIRfAKwA2//75eqgBuC2D5ZIr93LsEUCcabnQZdaZ KGSo/ruWNZdPyjj/b6MhAifkoFFrkN4/dwIqYIev8wMbh3+7dcZIRza0foM= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----6U2JCXSDZKQSLVE05FUH4M8CDP1MWU"; protocol="application/pgp-signature"; micalg="pgp-sha512" X-ThisMailContainsUnwantedMimeParts: N ------6U2JCXSDZKQSLVE05FUH4M8CDP1MWU Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=----D9Z2G0TV1R1H3IMXZUCKA7G3Y7ATBL ------D9Z2G0TV1R1H3IMXZUCKA7G3Y7ATBL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On December 3, 2022 4:49:46 PM GMT+01:00, Mario Marietto wrote: >Hello to everyone=2E > >what Im trying to do is to set the framebuffer video adapter as primary >graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti card >that I have passed through=2E What I want to do really is to use both the >graphic adapters,but the primary should be the framebuffer and the >secondary the nvidia=2E I tried different Xorg configurations,but what I'= ve >got is that Xorg failed to display some errors=2E So,the controller that = you >see below should be used as primary inside the ubuntu vm : > >00:1d=2E0 VGA compatible controller: Device fb5d:40fb > >while the ones you see below as secondary : > >08:00=2E0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce >RTX 2080 Ti] (rev a1) >08:00=2E1 Audio device: NVIDIA Corporation TU102 High Definition Audio >Controller (rev a1) >08:00=2E2 USB controller: NVIDIA Corporation TU102 USB 3=2E1 Host >Controller (rev a1) >08:00=2E3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C >UCSI Controller (rev a1) > > >The script that I use to launch the vm is the following : > >#!/bin/sh >setxkbmap it >vms=3D"$(ls /dev/vmm/*)" >vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')" > >for vm in $vms; do > session=3D"${vm##*/}" > echo "bhyve session =3D $session" > echo "vnc session =3D $vncs" > if ! printf '%s\n' "${vncs}" | grep "${session}"; then > printf 'VNC session not >found,destroying ghost vms\n' > bhyvectl --vm=3D$session --destroy > else > printf 'Found VNC session %s\n' >"${session},no ghost vms found,not destroying them" > fi >done > >vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: >(2015020204055E)/ && d{print d}'` >echo "TOSHIBA External USB 3=2E0 1=2E8 TB ; $vmdisk1" > >mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2' > >bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >-s 0,hostbridge \ >-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,bootin= dex=3D1 \ >-s 3,virtio-blk,/dev/$vmdisk4 \ >-s 4,virtio-blk,/dev/$vmdisk2 \ >-s 8:0,passthru,2/0/0 \ >-s 8:1,passthru,2/0/1 \ >-s 8:2,passthru,2/0/2 \ >-s 8:3,passthru,2/0/3 \ >-s 10,virtio-net,tap19 \ >-s 11,virtio-9p,sharename=3D/ \ >-s 29,fbuf,tcp=3D0=2E0=2E0=2E0:5919,w=3D1600,h=3D950,wait \ >-s 30,xhci,tablet \ >-s 31,lpc \ >-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \ >vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 > >For sure ,on /boot/loader=2Econf I've added : > >/boot/loader=2Econf > >pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3" > >As I said before,I tried two xorg conf files to achieve the goal=2E On th= e >first one I tried to add only the framebuffer,like this : > > >Section "Files" > ModulePath "/usr/lib/xorg/modules" > FontPath "/usr/share/fonts/X11/misc" > FontPath "/usr/share/fonts/X11/cyrillic" > FontPath "/usr/share/fonts/X11/100dpi/:unscaled" > FontPath "/usr/share/fonts/X11/75dpi/:unscaled" > FontPath "/usr/share/fonts/X11/Type1" > FontPath "/usr/share/fonts/X11/100dpi" > FontPath "/usr/share/fonts/X11/75dpi" > FontPath "built-ins" >EndSection > >Section "Module" > Load "vnc" > Load "glx" >EndSection > > >Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" >EndSection > >Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/input/mice" > Option "ZAxisMapping" "4 5 6 7" > >EndSection > >Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName "Monitor Model" >EndSection > >Section "Device" > Identifier "Card0" > Driver "modesetting" > BusID "PCI:0:29:0" > >EndSection > >Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 1 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 4 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 15 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 24 > EndSubSection >EndSection > > >but it didn't work=2E This is the log file that shows the errors >reported : https://pastebin=2Eubuntu=2Ecom/p/Gv7wgsDR4K/ >I have also removed the xorg=2Econf file,but it didn't work either=2E Thi= s >is the log file that shows the errors reported : > > >https://pastebin=2Eubuntu=2Ecom/p/wNcfQTByQm/ > >Can someone give me some suggestions that can help me to understand >where the mistake is,please,thanks=2E > >--=20 >Mario=2E Try to assign a lower pci slot number to the framebuffer device than to th= e nvidia gpu in your bhyve command=2E --=20 Best regards, Corvin ------D9Z2G0TV1R1H3IMXZUCKA7G3Y7ATBL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On December 3, 2022 4:4= 9:46 PM GMT+01:00, Mario Marietto <marietto2008@gmail=2Ecom> wrote:
Hello to everyone=2E

what Im trying to do is to set the framebuffer video adapter as primary=20 graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti=20 card that I have passed through=2E What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the=20 secondary the nvidia=2E I tried different Xorg configurations,but what I'v= e got is that Xorg failed to display some errors=2E So,the controller that you see below should be used as primary inside the ubuntu vm :

00:1d=2E0 VGA compatib=
le controller: Device fb5d:40fb

while the ones you see below as secondary :

08:00=2E0 VGA compatible controller: NVIDIA Corpora=
tion TU102 [GeForce RTX 2080 Ti] (rev a1)
08:00=2E1 Audio device: NVIDIA Corporation TU102 High Definition Audio Con=
troller (rev a1)
08:00=2E2 USB controller: NVIDIA Corporation TU102 USB 3=2E1 Host Controll=
er (rev a1)
08:00=2E3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI =
Controller (rev a1)

The script that I use to launch the vm is the following :

#!/bin/sh
setxkbmap it
vms=3D"$(ls /dev/vmm/*)"
vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')"

for vm in $vms; do
                session=3D"${vm##*/}"
                echo "bhyve session =3D $session"
                echo "vnc session =3D $vncs"
                if ! printf '%s\n' "${vncs}" | grep "${session}"; then
                                printf 'VNC session not found,destroying g=
host vms\n'
                                bhyvectl --vm=3D$session --destroy        =
                  =20
                else
                                printf 'Found VNC session %s\n' "${session=
},no ghost vms found,not destroying them"
                fi
done

vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (20150=
20204055E)/ && d{print d}'`
echo "TOSHIBA External USB 3=2E0 1=2E8 TB ; $vmdisk1"

mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2'

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,bootind=
ex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 29,fbuf,tcp=3D0=2E0=2E0=2E0:5919<=
/a>,w=3D1600,h=3D950,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19


For sure ,on /boot/load=
er=2Econf I've added :


Section=
 "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:29:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection


b=
ut it didn't work=2E This is the log file that shows the errors reported : =
ht=
tps://pastebin=2Eubuntu=2Ecom/p/Gv7wgsDR4K/
I have also removed the xorg=2Econf file,=
but it didn't work either=2E This is the log file that shows the errors rep=
orted :


https://pastebin=2Eubuntu=2Ecom/p/wNcfQTByQm/


Can someone give me som=
e suggestions that can help me to understand where the mistake is,please,th=
anks=2E
--
Mario=2E

Try to assign a lower pci slot number= to the framebuffer device than to the nvidia gpu in your bhyve command=2E<= br>
-- =
Best regards,
Corvin
------D9Z2G0TV1R1H3IMXZUCKA7G3Y7ATBL-- ------6U2JCXSDZKQSLVE05FUH4M8CDP1MWU Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQJBBAABCgArJBxDb3J2aW4gS8O2aG5lIDxjb3J2aW5rQEZyZWVCU0Qub3JnPgUC Y4t6lgAKCRDYVNpWMV4Cau6XEADAvqdR3fbxTsQ+eGtggydEmtwwWdtd75Sltyiv e5ZMdCiYFzqm+runAOECOSy2+PGiOQqShYOaSgA5bfKm/Gz7IyWZeocq6Pw78RvB 9PRpbsoAxji4Wlxp4By9Bqps99niT30a7h8oi4PB+dmsKY3HKz4tpiB8SP/hzU0h WTeKBFqgDNxAMDuzNp9lxK6rTqvleVvhavwahkNfg8fFuSU3agmYz//qwQ6SpCUS psOx9967ypAXfAm8KTiL1JhxJrqOmTI28Bj3Vc7ekZkg8uh5hvaKpdAN6N3DRGbr LJ5SSjADItcFNpZvEum/3rCY5nYoYCHQ5xuzdJ7IdPlWnamczNKtqcPiQZwM15ya Nk8Xq+duIUPbnPUlKuf2+Z/cuLwlFXqN+x+UTTRxMhwmzyKJkoLadc24CACmBN5a 0Iifs5CRxGjcEIamgAgzMEAiEkEvT4Id067687DjDeVpUPLXKtWMBzvJYqduaRIE NSj6rdIBcLFMm9YTxTyAyp54Y+Tw9z7mKQnGiCOoqijsChAq29SQ61p6+8PAZNh2 tQXzJ2z6lWSaT8wCkjUCub5XL6ManPJy2YdN8UsKiWlT8hDjJtyw3SWfTudMQ53r 0kLH8mKxDpERsk8hwB/TSbk0hWwM4l0HiLV6Hw3stpqzNE+750DSHPV/5C7eUbIZ xfXiVg== =0LcV -----END PGP SIGNATURE----- ------6U2JCXSDZKQSLVE05FUH4M8CDP1MWU-- From nobody Sat Dec 3 18:14:29 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPdJY3yprz4j2ZQ; Sat, 3 Dec 2022 18:15:09 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPdJY1RyBz49Bk; Sat, 3 Dec 2022 18:15:09 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x631.google.com with SMTP id fy37so18512708ejc.11; Sat, 03 Dec 2022 10:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iuGcZT2pzJVCu7zu6+KGlleD2uMnERat+5avNTDcCxY=; b=QMevgMxYNZlD0L0sLmHTsYynTgkBL69SOylFtPd6fr0o5WaV49wsCV3ZfXIdNxS7kH YgYxkupmNwe12AO79Dt57SBrH+K1l0hRHQKJ1zfaoMJrAWvJYxK7WWFgEgKbztvqYJDn dfsJ1IKYMqEt8b2rFcy49mtZ3zDg4PZr7mCJPpon/ZMutxeQMogGOMQxmaem5qxo4sMi FxUDxj0vpdYKEsptviXxZ6ofZ/jKTECbaN5ijop2j7h0b6FE6KXWfumESs4kT7kqpVHZ Pe1AKKGt79TGPjC4onaFcYQ0MxtGA7OyL0mdCN2NSJUXh5cZnDHmThskK0p1kg8PTUXW xlSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iuGcZT2pzJVCu7zu6+KGlleD2uMnERat+5avNTDcCxY=; b=EbnqGDQdjUdljP1qqSrLOogrpL5u7gBdHbE0mHT/G4nAvh3FU3nOAgXp48TrLdQe90 aHC6iyq9UdmrGWeXnEgCiB6M/a4Z6rO0WDEo4+Kgr7XzHHaS1epHKS1lqL29nm25GWVK aoZY/2xgSdxtuIEPKtnGZrWYtzfKauU062jwQPcaRQ19Bf7Z6KdUtTSDXqZzO/VJQT4H 6ckOS7yRM3s0h33M4hKRCzfsEcKK38+pDbItvyZEtpBTrlumhC8zRTiztIVMBnDyZW1+ vJDdX4tPyHZ/ZFySlIq5Pz/EsQfaD+AbGBc2s+RIbHAISBoEV2owYrtCK6CdNY/lOa3P Olsg== X-Gm-Message-State: ANoB5plv6YDNClXTw4df73X6bqpxJbbDNkYCfquADZCgDXvUDy9iZ97K XuIDHe/yCHS9uoInbv0pD1T2AMbPYFQSb2oH+Gl0sg1fJ943IA== X-Google-Smtp-Source: AA0mqf5aMhV5NjqxoygsJ5D+r8HzKDEqXE+Fm12KayIjlxsmyi44mvng5O6qi1PPX6HHfcs968J9UtQ8ADXLAReQ7OY= X-Received: by 2002:a17:906:7848:b0:7ad:b286:72da with SMTP id p8-20020a170906784800b007adb28672damr65392471ejm.152.1670091306232; Sat, 03 Dec 2022 10:15:06 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2E8B4BF7-A39E-4B93-820D-FC66F8C2F94B@FreeBSD.org> In-Reply-To: <2E8B4BF7-A39E-4B93-820D-FC66F8C2F94B@FreeBSD.org> From: Mario Marietto Date: Sat, 3 Dec 2022 19:14:29 +0100 Message-ID: Subject: Re: How to use the framebuffer as primary video device instead of the nvidia passed-through graphic card in a bhyve/linux vm To: =?UTF-8?Q?Corvin_K=C3=B6hne?= Cc: virtualization@freebsd.org, freebsd-x11+help@freebsd.org, FreeBSD virtualization , hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000cf23f05eef06ff9" X-Rspamd-Queue-Id: 4NPdJY1RyBz49Bk X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[help]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000000cf23f05eef06ff9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ok. I tried like this,but it didn't work : bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bootindex= =3D1 \ -s 3,virtio-blk,/dev/$vmdisk4 \ -s 4,virtio-blk,/dev/$vmdisk2 \-s 7,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h=3D95= 0,wait \ -s 8:0,passthru,2/0/0 \ -s 8:1,passthru,2/0/1 \ -s 8:2,passthru,2/0/2 \ -s 8:3,passthru,2/0/3 \ -s 10,virtio-net,tap19 \ -s 11,virtio-9p,sharename=3D/ \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 I tried specifying the bus ID of the framebuffer and I have used this xorg.conf file : Section "Files" ModulePath "/usr/lib/xorg/modules" FontPath "/usr/share/fonts/X11/misc" FontPath "/usr/share/fonts/X11/cyrillic" FontPath "/usr/share/fonts/X11/100dpi/:unscaled" FontPath "/usr/share/fonts/X11/75dpi/:unscaled" FontPath "/usr/share/fonts/X11/Type1" FontPath "/usr/share/fonts/X11/100dpi" FontPath "/usr/share/fonts/X11/75dpi" FontPath "built-ins" EndSection Section "Module" Load "vnc" Load "glx" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/input/mice" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" EndSection Section "Device" Identifier "Card0" Driver "modesetting" BusID "PCI:0:7:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection The error reported has been : https://ibb.co/1KX2h26 https://ibb.co/Cv5FffB thanks. Il giorno sab 3 dic 2022 alle ore 17:34 Corvin K=C3=B6hne ha scritto: > On December 3, 2022 4:49:46 PM GMT+01:00, Mario Marietto < > marietto2008@gmail.com> wrote: >> >> Hello to everyone. >> >> what Im trying to do is to set the framebuffer video adapter as primary >> graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti car= d >> that I have passed through. What I want to do really is to use both the >> graphic adapters,but the primary should be the framebuffer and the >> secondary the nvidia. I tried different Xorg configurations,but what I'v= e >> got is that Xorg failed to display some errors. So,the controller that y= ou >> see below should be used as primary inside the ubuntu vm : >> >> 00:1d.0 VGA compatible controller: Device fb5d:40fb >> >> while the ones you see below as secondary : >> >> 08:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX= 2080 Ti] (rev a1) >> 08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Con= troller (rev a1) >> 08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller= (rev a1) >> 08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI = Controller (rev a1) >> >> >> The script that I use to launch the vm is the following : >> >> #!/bin/sh >> setxkbmap it >> vms=3D"$(ls /dev/vmm/*)" >> vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')" >> >> for vm in $vms; do >> session=3D"${vm##*/}" >> echo "bhyve session =3D $session" >> echo "vnc session =3D $vncs" >> if ! printf '%s\n' "${vncs}" | grep "${session}"; then >> printf 'VNC session not found,destroying= ghost vms\n' >> bhyvectl --vm=3D$session --destroy >> else >> printf 'Found VNC session %s\n' "${sessi= on},no ghost vms found,not destroying them" >> fi >> done >> >> vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (201= 5020204055E)/ && d{print d}'` >> echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1" >> >> mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2' >> >> bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >> -s 0,hostbridge \ >> -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bootind= ex=3D1 \ >> -s 3,virtio-blk,/dev/$vmdisk4 \ >> -s 4,virtio-blk,/dev/$vmdisk2 \ >> -s 8:0,passthru,2/0/0 \ >> -s 8:1,passthru,2/0/1 \ >> -s 8:2,passthru,2/0/2 \ >> -s 8:3,passthru,2/0/3 \ >> -s 10,virtio-net,tap19 \ >> -s 11,virtio-9p,sharename=3D/ \ >> -s 29,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h=3D950,wait \ >> -s 30,xhci,tablet \ >> -s 31,lpc \ >> -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ >> vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 >> >> For sure ,on /boot/loader.conf I've added : >> >> /boot/loader.conf >> >> pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3" >> >> As I said before,I tried two xorg conf files to achieve the goal. On the >> first one I tried to add only the framebuffer,like this : >> >> >> Section "Files" >> ModulePath "/usr/lib/xorg/modules" >> FontPath "/usr/share/fonts/X11/misc" >> FontPath "/usr/share/fonts/X11/cyrillic" >> FontPath "/usr/share/fonts/X11/100dpi/:unscaled" >> FontPath "/usr/share/fonts/X11/75dpi/:unscaled" >> FontPath "/usr/share/fonts/X11/Type1" >> FontPath "/usr/share/fonts/X11/100dpi" >> FontPath "/usr/share/fonts/X11/75dpi" >> FontPath "built-ins" >> EndSection >> >> Section "Module" >> Load "vnc" >> Load "glx" >> EndSection >> >> >> Section "InputDevice" >> Identifier "Keyboard0" >> Driver "kbd" >> EndSection >> >> Section "InputDevice" >> Identifier "Mouse0" >> Driver "mouse" >> Option "Protocol" "auto" >> Option "Device" "/dev/input/mice" >> Option "ZAxisMapping" "4 5 6 7" >> >> EndSection >> >> Section "Monitor" >> Identifier "Monitor0" >> VendorName "Monitor Vendor" >> ModelName "Monitor Model" >> EndSection >> >> Section "Device" >> Identifier "Card0" >> Driver "modesetting" >> BusID "PCI:0:29:0" >> >> EndSection >> >> Section "Screen" >> Identifier "Screen0" >> Device "Card0" >> Monitor "Monitor0" >> SubSection "Display" >> Viewport 0 0 >> Depth 1 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 4 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 8 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 15 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 16 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 24 >> EndSubSection >> EndSection >> >> >> but it didn't work. This is the log file that shows the errors reported = : https://pastebin.ubuntu.com/p/Gv7wgsDR4K/ >> I have also removed the xorg.conf file,but it didn't work either. This i= s the log file that shows the errors reported : >> >> >> https://pastebin.ubuntu.com/p/wNcfQTByQm/ >> >> Can someone give me some suggestions that can help me to understand wher= e the mistake is,please,thanks. >> >> -- >> Mario. >> > > Try to assign a lower pci slot number to the framebuffer device than to > the nvidia gpu in your bhyve command. > -- > Best regards, > Corvin > --=20 Mario. --0000000000000cf23f05eef06ff9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ok. I tried like this,but it didn't work :
<= div>
bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m=
 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bo=
otindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 7,fbuf,tcp=3D0.0=
.0.0:5919,w=3D1600,h=3D950,wait \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19

I tried specifying the bus ID of the framebuffer and I ha= ve used this xorg.conf file :

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:7:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection
The error reported has been :


thanks.

Il giorno sab 3 dic 2022 alle ore 17:34 Corvin K= =C3=B6hne <corvink@freebsd.org> ha scritto:
On December 3, 2022 4:49:46 PM GMT+01:00,= Mario Marietto <marietto2008@gmail.com> wrote:
Hello to everyone.

what Im trying to do is to set the framebuffer video adapter as primary=20 graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti=20 card that I have passed through. What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the=20 secondary the nvidia. I tried different Xorg configurations,but what I'= ve got is that Xorg failed to display some errors. So,the controller that you see below should be used as primary inside the ubuntu vm :

00:1d.0 VGA compatible controller: Device fb5d:40f=
b

while the ones you see below as secondary :

08:00.0 VGA compatible controller: NVIDI=
A Corporation TU102 [GeForce RTX 2080 Ti] (rev a1)
08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Contro=
ller (rev a1)
08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (r=
ev a1)
08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Con=
troller (rev a1)

The script that I use to launch the vm is the following :

#!/bin/sh
setxkbmap it
vms=3D"$(ls /dev/vmm/*)"
vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')"

for vm in $vms; do
                session=3D"${vm##*/}"
                echo "bhyve session =3D $session"
                echo "vnc session =3D $vncs"
                if ! printf '%s\n' "${vncs}" | grep "=
;${session}"; then
                                printf 'VNC session not found,destroyin=
g ghost vms\n'
                                bhyvectl --vm=3D$session --destroy         =
                 =20
                else
                                printf 'Found VNC session %s\n' &qu=
ot;${session},no ghost vms found,not destroying them"
                fi
done

vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (20=
15020204055E)/ && d{print d}'`
echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1"

mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2'

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bo=
otindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 29,fbuf,tcp=3D0.0.0.0:=
5919,w=3D1600,h=3D950,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19


For sure ,on /boot/loade=
r.conf I've added :

/boot/loader.conf

pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3"


As I said before,I tried=
 two xorg conf files to achieve the goal. On the
first one I tried to add only the framebuffer,like this :

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:29:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection


bu=
t it didn't work. This is the log file that shows the errors reported :=
 https://pastebin.ubuntu.com/p/Gv7wgsDR4K/
I have also rem=
oved the xorg.conf file,but it didn't work either. This is the log file=
 that shows the errors reported :


https://pastebin.ubuntu.co=
m/p/wNcfQTByQm/


Can someone give me some=
 suggestions that can help me to understand where the mistake is,please,tha=
nks.
--
Mario.

Try to assign a lower pci slot number = to the framebuffer device than to the nvidia gpu in your bhyve command.
=
--
Best regards,
Corvin


--
Mario.
--0000000000000cf23f05eef06ff9-- From nobody Sun Dec 4 01:26:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPpt40KPYz4k0F1; Sun, 4 Dec 2022 01:26:20 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPpt26mnVz3qkC; Sun, 4 Dec 2022 01:26:18 +0000 (UTC) (envelope-from grarpamp@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=j6Nj0hpw; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=grarpamp@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-xe2e.google.com with SMTP id b189so2159839vsc.10; Sat, 03 Dec 2022 17:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=686NIf1KIBcl9er/S5vKPY7QqZKJCo2i9rFrcKo6W6c=; b=j6Nj0hpwLA5tI7O8V/AZy//pv7jCZ9Nn5xWpTpeFuwjnlk+z4+pUfLNazRNn+oR/nT 2l1jYCwQw41fsRSySzbAu1dscw7mvvtoQRZilTkp3FbXlxGNG+z19v55sNhadH9EDYml W00QT7nbs85Id4ggxK7m7YnMdHQAgv5kICsRiuFBrk3GJphPe9hggWJKddDIBXkhK3d2 z9mW2Ag6QTJpmiLRFC5hUWrTCjHSj3Np81rimbflr2ITjCo7rprPag2Qh0h79/g79my5 MuMOWLYZ7JNP5cz6k0kbGjfKqKm7XBaZpYgzcjsZmp/glwPnTCHwXrlh1Y9vxRKMES0h /Lnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=686NIf1KIBcl9er/S5vKPY7QqZKJCo2i9rFrcKo6W6c=; b=qCp9Dme7PgKn1s1f95tB0T2FttAkSYYv9rD2cmL1sPrLWcd+Nrfd0aNaYvBSvhN/U8 zvTYgDiVy8TSLouaKsXDs5UbU5AGCFi7+IKbTf+1ouUkazq5nIDr9jakwz6LqVNB8Vvy 1vWuhn4QOx6Is92On5JBCR+saOqkZP/grP0P1Srifl7xOzjrYtDtl/ZzySvg0icAj4Iz yE4rR3iz6PcClrBlPlGt+s9yuqShICvsbrtZ9hkauvwQaF3u/pqmHsg7Pi14A0mQ6vmH Nt3z3umxQrWJD5LirvVMQKKVVx/eD24z0fDI8irMEsy+2p0g9Z1dAxzFVqxFv1YnX+bQ 3/Bw== X-Gm-Message-State: ANoB5pmEKPZmxFtZgKN5oUZeRwJk3gx4JGe0w2/0rW1bC9zlUAn+MwGr K6EwlPqtYJFHij5oXEt70+VZ7BiNgURQyFFveJDa5a3qvZzO1ZgAUDY= X-Google-Smtp-Source: AA0mqf4obSX09BCQpTbBN5nwz/5dDkzqpUNmZYTgL0N2t67hzWDHbeUEA3IO4i68GU2SEJKvm30y0Fb7BWVPbNUyWSw= X-Received: by 2002:a05:6102:502:b0:3b0:df43:87af with SMTP id l2-20020a056102050200b003b0df4387afmr8751071vsa.1.1670117177359; Sat, 03 Dec 2022 17:26:17 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:acc2:0:b0:32b:33ff:fbc3 with HTTP; Sat, 3 Dec 2022 17:26:16 -0800 (PST) In-Reply-To: References: From: grarpamp Date: Sat, 3 Dec 2022 20:26:16 -0500 Message-ID: Subject: Re: CA's TLS Certificate Bundle in base = BAD To: freebsd-security@freebsd.org Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.986]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2e:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org,freebsd-questions@freebsd.org,freebsd-hackers@freebsd.org,freebsd-current@freebsd.org,freebsd-pkg@freebsd.org]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4NPpt26mnVz3qkC X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Again, FreeBSD should not be including the bundle in base, if users choose to, they can get it from ports or packages or wherever else. Including such bundles exposes users worldwide to massive risks. You need to do more gpg attestation, pubkey pinning [1], tofu, and cert management starting from empty file... and quit trusting bundles of hundreds of random CA's, all of which are entities who have zero duty or care to the user, and often exist/corrupt/break to present evil [2] ... [1] https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPU= BLICKEY.3 FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option, thus they're incapable of securely fetching packages, iso's, etc from servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys for users to get, verify, and pin out of band. Even pubkeys were swapped ou= t on FreeBSD servers without announcing for users if any exploit or loss occu= rred there or for some other reason. That's all bad news :( But can be fixed :) [2] https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addr= esses-government-connections https://www.msn.com/en-us/news/technology/mysterious-company-with-governmen= t-ties-plays-key-internet-role/ar-AA13RwPh https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4= /m/etbBho-VBQAJ Major Web Browsers Drop Mysterious Authentication Company After Ties To US Military Contractor Exposed TrustCor Systems vouches for the legitimacy of websites. But its physical address is a UPS Store in Toronto. Mysterious company with government ties plays key internet role An offshore company that is trusted by the major web browsers and other tech companies to vouch for the legitimacy of websites has connections to contractors for U.S. intelligence agencies and law enforcement, according to security researchers, documents and interviews. Google=E2=80=99s Chrome, Apple=E2=80=99s Safari, nonprofit Firefox and othe= rs allow the company, TrustCor Systems, to act as what=E2=80=99s known as a root certificate authority, a powerful spot in the internet=E2=80=99s infrastructure that guarantees websites are not fake, guiding users to them seamlessly. The company=E2=80=99s Panamanian registration records show that it has the identical slate of officers, agents and partners as a spyware maker identified this year as an affiliate of Arizona-based Packet Forensics, which public contracting records and company documents show has sold communication interception services to U.S. government agencies for more than a decade. One of those TrustCor partners has the same name as a holding company managed by Raymond Saulino, who was quoted in a 2010 Wired article as a spokesman for Packet Forensics. Saulino also surfaced in 2021 as a contact for another company, Global Resource Systems, that caused speculation in the tech world when it briefly activated and ran more than 100 million previously dormant IP addresses assigned decades earlier to the Pentagon. The Pentagon reclaimed the digital territory months later, and it remains unclear what the brief transfer was about, but researchers said the activation of those IP addresses could have given the military access to a huge amount of internet traffic without revealing that the government was receiving it. The Pentagon did not respond to a request for comment on TrustCor. TrustCor also did not respond to a request for comment. [Minutes before Trump left office, millions of the Pentagon=E2=80=99s dorma= nt IP addresses sprang to life] TrustCor=E2=80=99s products include an email service that claims to be end-to-end encrypted, though experts consulted by The Washington Post said they found evidence to undermine that claim. A test version of the email service also included spyware developed by a Panamanian company related to Packet Forensics, researchers said. Google later banned all software containing that spyware code from its app store. A person familiar with Packet Forensics=E2=80=99 work confirmed that it had used TrustCor=E2=80=99s certificate process and its email service, MsgSafe,= to intercept communications and help the U.S. government catch suspected terrorists. =E2=80=9CYes, Packet Forensics does that,=E2=80=9D the person said, speakin= g on the condition of anonymity to discuss confidential practices. Packet Forensics counsel Kathryn Temel said the company has no business relationship with TrustCor. She declined to say whether it had had one previously. The latest discovery shows how the technological and business complexities of the internet=E2=80=99s inner workings can be leveraged to a= n extent that is rarely revealed. Concerns about root certificate authorities, though, have come up before. In 2019, a security company controlled by the government of the United Arab Emirates that had been known as DarkMatter applied to be upgraded to top-level root authority from intermediate authority with less independence. That followed revelations about DarkMatter hacking dissidents and even some Americans; Mozilla denied it root power. In 2015, Google withdrew the root authority of the China Internet Network Information Center (CNNIC) after it allowed an intermediate authority to issue fake certificates for Google sites. With Packet Forensics, a paper trail led to it being identified by researchers twice this year. Mostly known for selling interception devices and tracking services to authorities, the company is four months into a $4.6 million Pentagon contract for =E2=80=9Cdata processing, hosting and related services.=E2=80=9D In the earlier spyware matter, researchers Joel Reardon of the University of Calgary and Serge Egelman of the University of California at Berkeley found that a Panamanian company, Measurement Systems, had been paying developers to include code in a variety of innocuous apps to record and transmit users=E2=80=99 phone numbers, email addresses and exact locations. They estimated that those apps were downloaded more than 60 million times, including 10 million downloads of Muslim prayer apps. Measurement Systems=E2=80=99 website was registered by Vostrom Holdings, according to historic domain name records. Vostrom filed papers in 2007 to do business as Packet Forensics, according to Virginia state records. Measurement Systems was registered in Virginia by Saulino, according to another state filing. After the researchers shared their findings, Google booted all apps with the spy code out of its Play app store. Tremel said that =E2=80=9Ca company previously associated with Packet Forensics was a customer of Measurement Systems at one time=E2=80=9D but th= at there was no ownership stake. When Reardon and Egelman looked deeper at Vostrom, they found it had registered the domain name TrustCor.co, which directed visitors to the main TrustCor site. TrustCor has the same president, agents and holding-company partners listed in Panamanian records as Measurement Systems. A firm with the same name as one of the holding companies behind both TrustCor and Measurement Systems, Frigate Bay Holdings, filed papers to dissolve this March with the secretary of state in Wyoming, where it was formed. The papers were signed by Saulino, who listed his title as manager. He could not be reached for comment. TrustCor has issued more than 10,0000 certificates, many of them for sites hosted with a dynamic domain name service provider called No-IP, the researchers said. That service allows websites to be hosted with constantly changing Internet Protocol addresses. Because root authority is so powerful, TrustCor can also give others the right to issue certificates. Certificates for websites are publicly viewable so that bad ones should be exposed sooner or later. There have been no reports so far that the TrustCor certificates have been used inappropriately, for example by vouching for impostor websites. The researchers speculated that the system is only used against high-value targets within short windows of time. The person familiar with Packet Forensics=E2=80=99 operati= ons agreed said that was in fact how it has been used. =E2=80=9CThey have this position of ultimate trust, where they can issue encryption keys for any arbitrary website and any email address,=E2=80=9D Egelman said. =E2=80=9CIt=E2=80=99s scary this is being done by some shady = private company.=E2=80=9D The leadership page of the TrustCor=E2=80=99s website lists just two men, identified as co-founders. Though that page does not say so, one of them died months ago, and the other=E2=80=99s LinkedIn profile says he left= as chief technology officer in 2019. That man declined to comment. The website site lists a contact phone number in Panama, which has been disconnected, and one in Toronto, where a message had not been returned after more than a week. The email contact form on the site doesn=E2=80=99t work. The physical address in Toronto given in its auditor= =E2=80=99s report, 371 Front St. West, houses a UPS Store mail drop. TrustCor adds another layer of mystery with its outside auditing firm. Instead of using a major accounting firm that rates the safety of internet infrastructure companies, TrustCor selected one called Princeton Audit Group, which gives its address as a residential townhouse in Princeton, N.J. In addition to TrustCor=E2=80=99s certificate power, the firm offers what purports to be end-to-end encrypted email, MsgSafe.io. But researchers said the email is not encrypted and can be read by the company, which has pitched it to a variety of groups worried about surveillance. MsgSafe has touted its security to a variety of potential customers, including Trump supporters upset that Parler had been dropped by app stores in January 2021, and to users of encrypted mail service Tutanota who were blocked from signing on to Microsoft services. =E2=80=9CCreate your free end-to-end encrypted email today with over 40 domains to choose from and are guaranteed to work with Microsoft Teams,=E2=80=9D the company tweeted in August. Reardon sent test messages over MsgSafe that appeared unencrypted in transmission, meaning MsgSafe could read them at will. Egelman ran the same test with the same result. Jon Callas, a cryptography expert at the Electronic Frontier Foundation, also tested the system at The Post=E2=80=99s request and said t= hat MsgSafe generated and kept the private key for his account, so that it could decrypt anything he sent. =E2=80=9CThe private key has to be under the person=E2=80=99s control to be end-to-end,=E2=80=9D Callas explained. Packet Forensics first drew attention from privacy advocates a dozen years = ago. In 2010, researcher Chris Soghoian attended an invite-only industry conference nicknamed the Wiretapper=E2=80=99s Ball and obtained a Packet Forensics brochure aimed at law enforcement and intelligence agency customers. The brochure was for a piece of hardware to help buyers read web traffic that parties thought was secure. But it wasn=E2=80=99t. =E2=80=9CIP communication dictates the need to examine encrypted traffic at will,=E2=80=9D the brochure read, according to a report in Wired that quote= d Saulino as a Packet Forensics spokesman. =E2=80=9CYour investigative staff will collect its best evidence while users are lulled into a false sense of security afforded by web, e-mail or VOIP encryption,=E2=80=9D the brochure added. The brochure told customers they could use a decryption key provided by a court order or a =E2=80=9Clook-alike key.=E2=80=9D Researchers thought at the time that the most likely way the box was being used was with a certificate issued by an authority for money or under a court order that would guarantee the authenticity of an impostor communications site. They did not conclude that an entire certificate authority itself might be compromised. Obtaining trusted root certificate authority takes time and money for the infrastructure and for the audit that browsers require, experts say. Each browser has slightly different requirements. At Mozilla=E2=80=99s Firefox, the process takes two years and includes crowdsourced and direct vetting as well as an audit. But all of that typically focuses on formal statements of technological steps, rather than mysteries of ownership and intent. The person familiar with Packet Forensics said the big tech companies probably were unwitting participants in the TrustCor play: =E2=80=9CMost people aren=E2=80=99t paying attention.=E2=80=9D =E2=80=9CWith enough money, you or I could become a trusted root certificat= e authority,=E2=80=9D said Daniel Schwalbe, vice president of technology at w= eb data tracker DomainTools. Mozilla currently recognizes 169 root certificate authorities, including three from TrustCor. The case gives new focus to problems with that system, in which critical tech companies outsource their trust to third parties with their own agendas. =E2=80=9CYou can=E2=80=99t bootstrap trust, it has to come from somewhere,= =E2=80=9D Reardon said. =E2=80=9CRoot certificate authorities are the kernel of trust from wh= ich it is all built on. And it will always be shaky, because it will always involve humans, committees and decision-making.=E2=80=9D Reardon and Egelman alerted Google, Mozilla and Apple to their research on TrustCor in April. They said they have heard little back. Google did not respond to a request for comment. Mozilla said it would say more after reviewing details from the researchers= . Major Web Browsers Drop Mysterious Authentication Company After Ties To US Military Contractor Exposed This week several major web browsers quickly severed ties with a mysterious software company used to certify the security of websites, three weeks after the Washington Post exposed its connections to a US military contractor, the Post reports. TrustCor Systems provided 'certificates' to browsers to Mozilla Firefox and Microsoft Edge, which vouched for the legitimacy of said websites. "Certificate Authorities have highly trusted roles in the internet ecosystem and it is unacceptable for a CA to be closely tied, through ownership and operation, to a company engaged in the distribution of malware," said Mozilla's Kathleen Wilson in an email to browser security experts. "Trustcor=E2=80=99s responses via their Vice President of= CA operations further substantiates the factual basis for Mozilla=E2=80=99s concerns." According to TrustCor's Panamanian (!?) registration records, the company has the same slate of officers, agents and officers as Arizona-based Packet Forensics, which has sold communication interception services to the U.S. government for over a decade. One of those contracts listed the =E2=80=9Cplace of performance=E2=80= =9D as Fort Meade, Md., the home of the National Security Agency and the Pentagon=E2=80=99s Cyber Command. The case has put a new spotlight on the obscure systems of trust and checks that allow people to rely on the internet for most purposes. Browsers typically have more than a hundred authorities approved by default, including government-owned ones and small companies, to seamlessly attest that secure websites are what they purport to be. -WaPo Also of concern, TrustCor's small staff in Canada lists its place of operation at a UPS Store mail drop, according to company executive Rachel McPherson, who says she told their Canadian staffers to work remotely. She also acknowledged that the company has 'infrastructure' in Arizona as well. McPherson says that ownership in TrustCor was transferred to employees despite the fact that some of the same holding companies had invested in both TrustCor and Packet Forensics. Various technologists in the email discussion said they found TrustCor to be evasive when it came to basic facts such as legal domicile and ownership - which they said was not appropriate for a company responsible for root certificate authority that verifies a secure 'https' website is not an imposter. The Post report built on the work of two researchers who had first located the company=E2=80=99s corporate records, Joel Reardon of the University of Calgary and Serge Egelman of the University of California at Berkeley. Those two and others also ran experiments on a secure email offering from TrustCor named MsgSafe.io. They found that contrary to MsgSafe=E2=80=99s public claims, emails sent through its system were not end-to-end encrypted and could be read by the company. McPherson said the various technology experts had not used the right version or had not configured it properly. -WaPo In a previous case which illustrates the importance of trusting root-level authorities - a security company controlled by the United Arab Emirates, DarkMatter, applied in 2019 to have top-level root authority from their status as an intermediate authority with less independence. The request followed revelations that DarkMatter had hacked dissidents and even some Americans - after which Mozilla denied it root power. "Received email from DDNS no-IP, they offering free TrustCor Standard DV SSL certificate." "Free, comes complete with spyveillance and exploit, lol." "Imagine that even the most trusted CA's are actually rogue!" From nobody Sun Dec 4 02:05:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPqlf2T45z4hqsc; Sun, 4 Dec 2022 02:05:50 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPqld6t7jz3xdL; Sun, 4 Dec 2022 02:05:49 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 2B425LHr005113 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Dec 2022 18:05:21 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 2B425LoN005112; Sat, 3 Dec 2022 18:05:21 -0800 (PST) (envelope-from sgk) Date: Sat, 3 Dec 2022 18:05:21 -0800 From: Steve Kargl To: grarpamp Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org Subject: Re: CA's TLS Certificate Bundle in base = BAD Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4NPqld6t7jz3xdL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Dec 03, 2022 at 08:26:16PM -0500, grarpamp wrote: > there or for some other reason. That's all bad news :( But can be fixed :) > It looks like the FreeBSD mailing list software stripped your attachment with your patch. Can you try sending it again with the patch in-line? -- steve From nobody Sun Dec 4 02:44:55 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPrcp6WsWz4hwrC; Sun, 4 Dec 2022 02:44:58 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPrcp6437z43hM; Sun, 4 Dec 2022 02:44:58 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670121898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J/kYN5WtcAGBw19XPuaAnc6JHiAz2NH644md2dTU80I=; b=Ge0UdghnZpRay7eOWRxgjG4h+n5lT/RzghDCVZw8BdjOAPKquXNjoGBCDciJfJO/9ayKli eYt5Lv0+By4cclQTO/at0toM3oya12yabkBosatez4MXyK97Bc15hOJ07cSrd4yKVj+q0v wVIZhVbI5G3YWqDR5Nk6f2pxZ9b82SLZsMEqwXbrOP7u5XTi0idpfEslbx0VekaBiEeWHF c12t4D1IzItiwDZnOb+BMGM82K4Ecy1k6ZekuXOv+zJajvZKocIGrUOo0BfIS97pd5lQ6o WP9fQmv41VD2AE6AtMYjTQ9WiSSLY741r+ph8PqH8+G/KnEehrqFODYJ9l7Dfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670121898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J/kYN5WtcAGBw19XPuaAnc6JHiAz2NH644md2dTU80I=; b=QHHM78h/W2+pkeqzu5ysxeAxmvZEiN73Npy+8QYrWooa2uQyJ/VBrO+Xb/0RNCE+wbNG9o piCsgwIoP8Pfzt0hv37J+J8iuXbGtVN+K7efZKjUbUVcfahhUK2kHSSeTYa69rBv0tZjUe QoiJcuSqYL4aNurOsy7tq57aIhLvmKPshF2Ue31SEBYe4MX/fUbf88uRZ2Wxpef8hj1HZW fO78QEXYVBpOaKbeFHjoAAIIGzLPZitm+Tbpz8yV8cO6VeXwuB3tjyd/mFtb7NLpdqLQU7 ESpCEUYjPb7G7fjvT71IAIgLe9z7j5y8xWe/SFAmZaaz6qjqf75l5CjFgXV1LA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670121898; a=rsa-sha256; cv=none; b=xwskyS9EgQne2qcEYCaYtHxkmPYtyu9osR24WkG5ixcHI0oNjNAIj2V0p8c73cb/elK4xe Wa4+z8rwSF51q6cDtkCfUtZeQQxApGKa5VjgBhjb2sGCP+GzXdpPEHdQ2NHOofYOmJ0yCl YtuHE3wwjEWwkpwqxdU48fcxmX3HggNBjllEH+JfUZ576HKJNu/chlCCIVs7SRd0NrSUcn vcG/MtJMBojargGXD2ANfpZT3/lwxJGRiVmqav5mon3AD48D1BpC9ZTCJiOcd+8t5585e1 yJUgGonr15Zth4QG5oFsEG7EtXNaNc1F6FHPHXAW4d9Vlx3uwkIgNb6d9RtDDg== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NPrcn6ktRzLLF; Sun, 4 Dec 2022 02:44:57 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <1a9c360a-195a-14f2-7c22-6fdd668aa5cc@freebsd.org> Date: Sun, 4 Dec 2022 02:44:55 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: CA's TLS Certificate Bundle in base = BAD To: grarpamp Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org, freebsd-security@freebsd.org References: Content-Language: en-GB From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------DZ1HHh8wOH3EbeKhDixHtHhU" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------DZ1HHh8wOH3EbeKhDixHtHhU Content-Type: multipart/mixed; boundary="------------c1EQBIrLvyNIvY0maI9pzRMI"; protected-headers="v1" From: Graham Perrin To: grarpamp Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org, freebsd-security@freebsd.org Message-ID: <1a9c360a-195a-14f2-7c22-6fdd668aa5cc@freebsd.org> Subject: Re: CA's TLS Certificate Bundle in base = BAD References: In-Reply-To: --------------c1EQBIrLvyNIvY0maI9pzRMI Content-Type: multipart/alternative; boundary="------------1Ig5uKkPBzAjJHbGvg3OjSV7" --------------1Ig5uKkPBzAjJHbGvg3OjSV7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Z3JhcnBhbXAsIHBsZWFzZSByZWZyYWluIGZyb20gYWRkcmVzc2luZyBzbyBtYW55IGxpc3Rz Lg0KDQpTbyBtYW55IGlzOg0KDQoqIGdlbmVyYWxseSBwb29yIG5ldGlxdWV0dGUNCiogY29u dHJhcnkgdG8gcnVsZXMgb2YgdGhlIHJvYWQgaW4gdGhlIEZyZWVCU0QgSGFuZGJvb2suDQoN CjxodHRwczovL2RvY3MuZnJlZWJzZC5vcmcvZW4vYm9va3MvaGFuZGJvb2svYm9vay8jZXJl c291cmNlcy1jaGFydGVycz4NCg== --------------1Ig5uKkPBzAjJHbGvg3OjSV7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
grarpamp, please refrain from addressing so many lists.

So many is:

* generally poor netiquette
* contrary to rules of the road in the= FreeBSD Handbook.

<https://docs.freebsd.org/en/books/handbook/book/#eresources-charter= s>
--------------1Ig5uKkPBzAjJHbGvg3OjSV7-- --------------c1EQBIrLvyNIvY0maI9pzRMI-- --------------DZ1HHh8wOH3EbeKhDixHtHhU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOMCacFAwAAAAAACgkQt2dIb0oY1Asu bBAAjFHnzRhKyZP5BdgDlM+iDPBKAr9ZnBwryBrklZMXUwJ8XllvqRztUpD9adT5BZmvyqdKmu7X ElXHbkjlpzxtJ8CgE9BTzgjz8KtpCnJw6b+h1XdEs3VoU9zJecqxLnIn4wDBuf4EYqeBk6ZzB/e/ 1F34TyFBg8YHM2qVPp+/f4PyFwNFHsAhganeM6tyIGafw82CnKXnGAgO+z54ov0oEcMIgdXumdQX 1oKTlz958j/SqMJAgDkznDP9990s5lsQCp7dU1T217efI7dIgbQP7J4kKMawclCy3eoPhy8j0T2x 0hCF3HogTZ4mvcjyonboxbF93saONviEUEkLX/SYItZ0hkxEqJYS0hdLFS75BKP0ltsQ6HbeHRLF idsDwIgLb7T5X410EZZGljZ14NplWbbqM0CnJwXnGMNbq1aJV8vxneRaS4HxI6zTcqcSauE67b8p Jset3DvwoTQSn9Cgrr2qlUxukvusw40dVOy5kq5/7aZPnqVmwtOX7MYI3vgaKhqkPPWRwzzwaL74 3yLCdaJ0Oh/z7vTK38rtXdEjTyDtrdkJOBWRJ19xoZOjbwt72oGt+KJWnBUJRfnmESkBg0YjfSPv qKXIfFIGsTFz+ej+UZWM4LjIRn8ALkotzn0TznbTPNb88SWC3uTk+w88Py0Ac0PqeEqVWxvRn8Se 5K0= =LO7a -----END PGP SIGNATURE----- --------------DZ1HHh8wOH3EbeKhDixHtHhU-- From nobody Sun Dec 4 06:16:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPxKT0wBJz4jT2V for ; Sun, 4 Dec 2022 06:17:01 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mr85p00im-ztdg06021201.me.com (mr85p00im-ztdg06021201.me.com [17.58.23.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPxKS58qWz4WWM for ; Sun, 4 Dec 2022 06:17:00 +0000 (UTC) (envelope-from gordon@tetlows.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetlows.org; s=sig1; t=1670134619; bh=wVaLjZc+H7aC5nF+TF4Y+bffPGR0jwjMsHIppMvSeho=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=qqIicwSEkmH2HqLBB69h+CcOgIZUJorpc0DsawV3ezBdaMtAyGw4w/azWzztNBJUS 0ryvA1UYRgdPPJtmEwBik1/hciCGNOCcwkOS+kmql9hU8ZYm52GTzTQi4K1HtXtNZ4 fxTmwrg4bhWdjzgtcIi40NsDHrmPIRfnbaaoW0Lhu5D+xnMuLvwSUpGxp6CDkpj6NZ PmzjvXR2NcjdD3A4GCd2zglolyhv1lhI3mArJBe1f9FtuO9xsrL/NWxMX2uf7Velsc acSg9bdhyAg+e6fgh+dSEqmLpHdZ9+UMktAawPE5ip/iqPWMT7lubBQ18Rwj6DizpP Wp8ETyJLRnpRQ== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06021201.me.com (Postfix) with ESMTPSA id 7B33D320795; Sun, 4 Dec 2022 06:16:58 +0000 (UTC) From: Gordon Tetlow Message-Id: <3FD4E3F3-EAAB-41E9-9381-D98971A9B928@tetlows.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: CA's TLS Certificate Bundle in base = BAD Date: Sat, 3 Dec 2022 22:16:45 -0800 In-Reply-To: Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, freebsd-pkg@freebsd.org To: grarpamp References: X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Proofpoint-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt X-Proofpoint-ORIG-GUID: JdfdEwSXJIZROAN6ZP9MzHqHobNhHuNt X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.138,18.0.816,17.11.62.513.0000000_definitions?= =?UTF-8?Q?=3D2022-01-18=5F01:2020-02-14=5F02,2022-01-18=5F01,2021-12-02?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 adultscore=0 clxscore=1030 phishscore=0 malwarescore=0 spamscore=0 mlxlogscore=385 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2212040058 X-Rspamd-Queue-Id: 4NPxKS58qWz4WWM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 3, 2022, at 5:26 PM, grarpamp wrote: >=20 > Again, FreeBSD should not be including the bundle in base, if users > choose to, they can get it from ports or packages or wherever else. > Including such bundles exposes users worldwide to massive risks. > You need to do more gpg attestation, pubkey pinning [1], tofu, and > cert management starting from empty file... and quit trusting bundles = of > hundreds of random CA's, all of which are entities who have zero duty > or care to the user, and often exist/corrupt/break to present evil [2] = ... >=20 > [1] > = https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d > = https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDP= UBLICKEY.3 >=20 > FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple = option, > thus they're incapable of securely fetching packages, iso's, etc from > servers in re [2]. Nor does FreeBSD even post sigs over its servers = pubkeys > for users to get, verify, and pin out of band. Even pubkeys were = swapped out > on FreeBSD servers without announcing for users if any exploit or loss = occurred > there or for some other reason. That's all bad news :( But can be = fixed :) Key pinning is a bad idea that 100% will cause outages. As a thought experiment, let's suppose I (as the Security Officer) use = the system you propose and require users to pin specific keys on our = publicly available servers. Now let's further suppose that the project = is compromised such that we believe those certificates might be in the = hands of the attacker, but we aren't sure. I'm now stuck between a rock = and hard place. Should I rotate the pinned certificate? In your proposed = system, rotating that pinned certificate will cause massive downstream = failures for all users. Since we aren't sure, maybe I'll leave the = existing certificate in place, because I don't want to cause those = outages since I'm not sure it's a problem. In the publicly trusted CA system, I can easily rotate the certificate = even if I don't believe it was compromised. It incentivizes better = behavior. Also, please don't lecture me on the problems with the = publicly trusted CA system: I'm very familiar with them. That said, it's = the system we have and I have no interest in trying to tilt at that = particular windmill. In any event, nothing is preventing you from doing this on your own as = the system ships with the tools to do so. Recognize the project has a = need for cryptographic agility and ability to change certificates = whenever we need to. Running our own root CA infrastructure necessary to = provide a similar level of assurance to a professionally run CA is = non-trivial and I don't believe we as a project are in a position (or = interested) in taking on such a burden. Gordon= --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Dec 3, = 2022, at 5:26 PM, grarpamp <grarpamp@gmail.com> = wrote:

Again, = FreeBSD should not be including the bundle in base, if users
choose to, they can get it from ports or = packages or wherever else.
Including such bundles exposes users worldwide to massive = risks.
You need to do more gpg = attestation, pubkey pinning [1], tofu, and
cert = management starting from empty file... and quit trusting bundles = of
hundreds of random CA's, = all of which are entities who have zero duty
or care to the user, and often = exist/corrupt/break to present evil [2] ...

[1]
https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpub= key.d
https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_P= INNEDPUBLICKEY.3

FreeBSD pkg(8) (aka, = and: fetch(3)) don't even support this simple option,
thus they're incapable of securely fetching = packages, iso's, etc from
servers = in re [2]. Nor does FreeBSD even post sigs over its servers = pubkeys
for users to get, = verify, and pin out of band. Even pubkeys were swapped out
on FreeBSD servers without announcing for = users if any exploit or loss occurred
there = or for some other reason. That's all bad news :( But can be fixed = :)

Key pinning is a bad idea = that 100% will cause outages.

As a thought = experiment, let's suppose I (as the Security Officer) use the system you = propose and require users to pin specific keys on our publicly available = servers. Now let's further suppose that the project is compromised such = that we believe those certificates might be in the hands of the = attacker, but we aren't sure. I'm now stuck between a rock and hard = place. Should I rotate the pinned certificate? In your proposed system, = rotating that pinned certificate will cause massive downstream failures = for all users. Since we aren't sure, maybe I'll leave the existing = certificate in place, because I don't want to cause those outages since = I'm not sure it's a problem.

In the publicly = trusted CA system, I can easily rotate the certificate even if I don't = believe it was compromised. It incentivizes better behavior. Also, = please don't lecture me on the problems with the publicly trusted CA = system: I'm very familiar with them. That said, it's the system we have = and I have no interest in trying to tilt at that particular = windmill.

In any event, nothing is preventing = you from doing this on your own as the system ships with the tools to do = so. Recognize the project has a need for cryptographic agility and = ability to change certificates whenever we need to. Running our own root = CA infrastructure necessary to provide a similar level of assurance to a = professionally run CA is non-trivial and I don't believe we as a project = are in a position (or interested) in taking on such a = burden.

Gordon
= --Apple-Mail=_FDFA50E6-4E04-4D5A-B496-04FE5C561A0F-- From nobody Sun Dec 4 06:33:33 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NPxhp0vynz4jWnN; Sun, 4 Dec 2022 06:33:46 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NPxhm2ngdz4bPB; Sun, 4 Dec 2022 06:33:44 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp; dmarc=none Received: from kalamity.joker.local (123-1-88-210.area1b.commufa.jp [123.1.88.210]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2B46XXAo082514; Sun, 4 Dec 2022 15:33:34 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 4 Dec 2022 15:33:33 +0900 From: Tomoaki AOKI To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org Subject: Re: CA's TLS Certificate Bundle in base = BAD Message-Id: <20221204153333.675a324591300db93dc11089@dec.sakura.ne.jp> In-Reply-To: References: Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-1.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.86)[-0.860]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_SPF_NA(0.00)[no SPF record]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NPxhm2ngdz4bPB X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Hi. IMHO, bundling certs on base should be mandatory, at least for freebsd.org ones. Without them, how can users download initial certs from ports safely, and without annoying warnings? Maybe limiting initially-bundled certs for freebsd.org ones only on base itself, and forcibly install pkgs ones on install (bundled in all install media, and upgradable later with pkg or rebuilding with ports) could be better. On Sat, 3 Dec 2022 20:26:16 -0500 grarpamp wrote: > Again, FreeBSD should not be including the bundle in base, if users > choose to, they can get it from ports or packages or wherever else. > Including such bundles exposes users worldwide to massive risks. > You need to do more gpg attestation, pubkey pinning [1], tofu, and > cert management starting from empty file... and quit trusting bundles of > hundreds of random CA's, all of which are entities who have zero duty > or care to the user, and often exist/corrupt/break to present evil [2] ... > > [1] > https://github.com/curl/curl/blob/master/docs/cmdline-opts/pinnedpubkey.d > https://github.com/curl/curl/blob/master/docs/libcurl/opts/CURLOPT_PINNEDPUBLICKEY.3 > > FreeBSD pkg(8) (aka, and: fetch(3)) don't even support this simple option, > thus they're incapable of securely fetching packages, iso's, etc from > servers in re [2]. Nor does FreeBSD even post sigs over its servers pubkeys > for users to get, verify, and pin out of band. Even pubkeys were swapped out > on FreeBSD servers without announcing for users if any exploit or loss occurred > there or for some other reason. That's all bad news :( But can be fixed :) > > > [2] > https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections > https://www.msn.com/en-us/news/technology/mysterious-company-with-government-ties-plays-key-internet-role/ar-AA13RwPh > https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/etbBho-VBQAJ > > Major Web Browsers Drop Mysterious Authentication Company After Ties > To US Military Contractor Exposed > > TrustCor Systems vouches for the legitimacy of websites. But its > physical address is a UPS Store in Toronto. > > Mysterious company with government ties plays key internet role > > An offshore company that is trusted by the major web browsers and > other tech companies to vouch for the legitimacy of websites has > connections to contractors for U.S. intelligence agencies and law > enforcement, according to security researchers, documents and > interviews. > Google’s Chrome, Apple’s Safari, nonprofit Firefox and others allow > the company, TrustCor Systems, to act as what’s known as a root > certificate authority, a powerful spot in the internet’s > infrastructure that guarantees websites are not fake, guiding users to > them seamlessly. > The company’s Panamanian registration records show that it has the > identical slate of officers, agents and partners as a spyware maker > identified this year as an affiliate of Arizona-based Packet > Forensics, which public contracting records and company documents show > has sold communication interception services to U.S. government > agencies for more than a decade. > One of those TrustCor partners has the same name as a holding company > managed by Raymond Saulino, who was quoted in a 2010 Wired article as > a spokesman for Packet Forensics. > Saulino also surfaced in 2021 as a contact for another company, Global > Resource Systems, that caused speculation in the tech world when it > briefly activated and ran more than 100 million previously dormant IP > addresses assigned decades earlier to the Pentagon. The Pentagon > reclaimed the digital territory months later, and it remains unclear > what the brief transfer was about, but researchers said the activation > of those IP addresses could have given the military access to a huge > amount of internet traffic without revealing that the government was > receiving it. > The Pentagon did not respond to a request for comment on TrustCor. > TrustCor also did not respond to a request for comment. > [Minutes before Trump left office, millions of the Pentagon’s dormant > IP addresses sprang to life] > TrustCor’s products include an email service that claims to be > end-to-end encrypted, though experts consulted by The Washington Post > said they found evidence to undermine that claim. A test version of > the email service also included spyware developed by a Panamanian > company related to Packet Forensics, researchers said. Google later > banned all software containing that spyware code from its app store. > A person familiar with Packet Forensics’ work confirmed that it had > used TrustCor’s certificate process and its email service, MsgSafe, to > intercept communications and help the U.S. government catch suspected > terrorists. > “Yes, Packet Forensics does that,” the person said, speaking on the > condition of anonymity to discuss confidential practices. > Packet Forensics counsel Kathryn Temel said the company has no > business relationship with TrustCor. She declined to say whether it > had had one previously. > The latest discovery shows how the technological and business > complexities of the internet’s inner workings can be leveraged to an > extent that is rarely revealed. > Concerns about root certificate authorities, though, have come up before. > In 2019, a security company controlled by the government of the United > Arab Emirates that had been known as DarkMatter applied to be upgraded > to top-level root authority from intermediate authority with less > independence. That followed revelations about DarkMatter hacking > dissidents and even some Americans; Mozilla denied it root power. > In 2015, Google withdrew the root authority of the China Internet > Network Information Center (CNNIC) after it allowed an intermediate > authority to issue fake certificates for Google sites. > With Packet Forensics, a paper trail led to it being identified by > researchers twice this year. Mostly known for selling interception > devices and tracking services to authorities, the company is four > months into a $4.6 million Pentagon contract for “data processing, > hosting and related services.” > In the earlier spyware matter, researchers Joel Reardon of the > University of Calgary and Serge Egelman of the University of > California at Berkeley found that a Panamanian company, Measurement > Systems, had been paying developers to include code in a variety of > innocuous apps to record and transmit users’ phone numbers, email > addresses and exact locations. They estimated that those apps were > downloaded more than 60 million times, including 10 million downloads > of Muslim prayer apps. > Measurement Systems’ website was registered by Vostrom Holdings, > according to historic domain name records. Vostrom filed papers in > 2007 to do business as Packet Forensics, according to Virginia state > records. Measurement Systems was registered in Virginia by Saulino, > according to another state filing. > After the researchers shared their findings, Google booted all apps > with the spy code out of its Play app store. > Tremel said that “a company previously associated with Packet > Forensics was a customer of Measurement Systems at one time” but that > there was no ownership stake. > When Reardon and Egelman looked deeper at Vostrom, they found it had > registered the domain name TrustCor.co, which directed visitors to the > main TrustCor site. TrustCor has the same president, agents and > holding-company partners listed in Panamanian records as Measurement > Systems. > A firm with the same name as one of the holding companies behind both > TrustCor and Measurement Systems, Frigate Bay Holdings, filed papers > to dissolve this March with the secretary of state in Wyoming, where > it was formed. The papers were signed by Saulino, who listed his title > as manager. He could not be reached for comment. > TrustCor has issued more than 10,0000 certificates, many of them for > sites hosted with a dynamic domain name service provider called No-IP, > the researchers said. That service allows websites to be hosted with > constantly changing Internet Protocol addresses. > Because root authority is so powerful, TrustCor can also give others > the right to issue certificates. > Certificates for websites are publicly viewable so that bad ones > should be exposed sooner or later. There have been no reports so far > that the TrustCor certificates have been used inappropriately, for > example by vouching for impostor websites. The researchers speculated > that the system is only used against high-value targets within short > windows of time. The person familiar with Packet Forensics’ operations > agreed said that was in fact how it has been used. > “They have this position of ultimate trust, where they can issue > encryption keys for any arbitrary website and any email address,” > Egelman said. “It’s scary this is being done by some shady private > company.” > The leadership page of the TrustCor’s website lists just two men, > identified as co-founders. Though that page does not say so, one of > them died months ago, and the other’s LinkedIn profile says he left as > chief technology officer in 2019. That man declined to comment. > The website site lists a contact phone number in Panama, which has > been disconnected, and one in Toronto, where a message had not been > returned after more than a week. The email contact form on the site > doesn’t work. The physical address in Toronto given in its auditor’s > report, 371 Front St. West, houses a UPS Store mail drop. > TrustCor adds another layer of mystery with its outside auditing firm. > Instead of using a major accounting firm that rates the safety of > internet infrastructure companies, TrustCor selected one called > Princeton Audit Group, which gives its address as a residential > townhouse in Princeton, N.J. > In addition to TrustCor’s certificate power, the firm offers what > purports to be end-to-end encrypted email, MsgSafe.io. But researchers > said the email is not encrypted and can be read by the company, which > has pitched it to a variety of groups worried about surveillance. > MsgSafe has touted its security to a variety of potential customers, > including Trump supporters upset that Parler had been dropped by app > stores in January 2021, and to users of encrypted mail service > Tutanota who were blocked from signing on to Microsoft services. > “Create your free end-to-end encrypted email today with over 40 > domains to choose from and are guaranteed to work with Microsoft > Teams,” the company tweeted in August. > Reardon sent test messages over MsgSafe that appeared unencrypted in > transmission, meaning MsgSafe could read them at will. Egelman ran the > same test with the same result. > Jon Callas, a cryptography expert at the Electronic Frontier > Foundation, also tested the system at The Post’s request and said that > MsgSafe generated and kept the private key for his account, so that it > could decrypt anything he sent. > “The private key has to be under the person’s control to be > end-to-end,” Callas explained. > Packet Forensics first drew attention from privacy advocates a dozen years ago. > In 2010, researcher Chris Soghoian attended an invite-only industry > conference nicknamed the Wiretapper’s Ball and obtained a Packet > Forensics brochure aimed at law enforcement and intelligence agency > customers. > The brochure was for a piece of hardware to help buyers read web > traffic that parties thought was secure. But it wasn’t. > “IP communication dictates the need to examine encrypted traffic at > will,” the brochure read, according to a report in Wired that quoted > Saulino as a Packet Forensics spokesman. “Your investigative staff > will collect its best evidence while users are lulled into a false > sense of security afforded by web, e-mail or VOIP encryption,” the > brochure added. > The brochure told customers they could use a decryption key provided > by a court order or a “look-alike key.” > Researchers thought at the time that the most likely way the box was > being used was with a certificate issued by an authority for money or > under a court order that would guarantee the authenticity of an > impostor communications site. > They did not conclude that an entire certificate authority itself > might be compromised. > Obtaining trusted root certificate authority takes time and money for > the infrastructure and for the audit that browsers require, experts > say. > Each browser has slightly different requirements. At Mozilla’s > Firefox, the process takes two years and includes crowdsourced and > direct vetting as well as an audit. > But all of that typically focuses on formal statements of > technological steps, rather than mysteries of ownership and intent. > The person familiar with Packet Forensics said the big tech companies > probably were unwitting participants in the TrustCor play: “Most > people aren’t paying attention.” > “With enough money, you or I could become a trusted root certificate > authority,” said Daniel Schwalbe, vice president of technology at web > data tracker DomainTools. > Mozilla currently recognizes 169 root certificate authorities, > including three from TrustCor. > The case gives new focus to problems with that system, in which > critical tech companies outsource their trust to third parties with > their own agendas. > “You can’t bootstrap trust, it has to come from somewhere,” Reardon > said. “Root certificate authorities are the kernel of trust from which > it is all built on. And it will always be shaky, because it will > always involve humans, committees and decision-making.” > Reardon and Egelman alerted Google, Mozilla and Apple to their > research on TrustCor in April. They said they have heard little back. > Google did not respond to a request for comment. > Mozilla said it would say more after reviewing details from the researchers. > > > Major Web Browsers Drop Mysterious Authentication Company After Ties > To US Military Contractor Exposed > > This week several major web browsers quickly severed ties with a > mysterious software company used to certify the security of websites, > three weeks after the Washington Post exposed its connections to a US > military contractor, the Post reports. > > TrustCor Systems provided 'certificates' to browsers to Mozilla > Firefox and Microsoft Edge, which vouched for the legitimacy of said > websites. > > "Certificate Authorities have highly trusted roles in the internet > ecosystem and it is unacceptable for a CA to be closely tied, through > ownership and operation, to a company engaged in the distribution of > malware," said Mozilla's Kathleen Wilson in an email to browser > security experts. "Trustcor’s responses via their Vice President of CA > operations further substantiates the factual basis for Mozilla’s > concerns." > > According to TrustCor's Panamanian (!?) registration records, the > company has the same slate of officers, agents and officers as > Arizona-based Packet Forensics, which has sold communication > interception services to the U.S. government for over a decade. > > One of those contracts listed the “place of performance” as Fort > Meade, Md., the home of the National Security Agency and the > Pentagon’s Cyber Command. > > The case has put a new spotlight on the obscure systems of trust > and checks that allow people to rely on the internet for most > purposes. Browsers typically have more than a hundred authorities > approved by default, including government-owned ones and small > companies, to seamlessly attest that secure websites are what they > purport to be. -WaPo > > Also of concern, TrustCor's small staff in Canada lists its place of > operation at a UPS Store mail drop, according to company executive > Rachel McPherson, who says she told their Canadian staffers to work > remotely. She also acknowledged that the company has 'infrastructure' > in Arizona as well. > > McPherson says that ownership in TrustCor was transferred to employees > despite the fact that some of the same holding companies had invested > in both TrustCor and Packet Forensics. > > Various technologists in the email discussion said they found TrustCor > to be evasive when it came to basic facts such as legal domicile and > ownership - which they said was not appropriate for a company > responsible for root certificate authority that verifies a secure > 'https' website is not an imposter. > > The Post report built on the work of two researchers who had first > located the company’s corporate records, Joel Reardon of the > University of Calgary and Serge Egelman of the University of > California at Berkeley. Those two and others also ran experiments on a > secure email offering from TrustCor named MsgSafe.io. They found that > contrary to MsgSafe’s public claims, emails sent through its system > were not end-to-end encrypted and could be read by the company. > > McPherson said the various technology experts had not used the > right version or had not configured it properly. -WaPo > > In a previous case which illustrates the importance of trusting > root-level authorities - a security company controlled by the United > Arab Emirates, DarkMatter, applied in 2019 to have top-level root > authority from their status as an intermediate authority with less > independence. The request followed revelations that DarkMatter had > hacked dissidents and even some Americans - after which Mozilla denied > it root power. > > > "Received email from DDNS no-IP, they offering free TrustCor Standard > DV SSL certificate." > "Free, comes complete with spyveillance and exploit, lol." > "Imagine that even the most trusted CA's are actually rogue!" > > -- Tomoaki AOKI From nobody Sun Dec 4 09:40:25 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NQ1s30kPLz4jwl4; Sun, 4 Dec 2022 09:41:11 +0000 (UTC) (envelope-from corvink@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 4NQ1s30S00z3QPJ; Sun, 4 Dec 2022 09:41:11 +0000 (UTC) (envelope-from corvink@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670146871; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=t1/Ygguzvm9+aQHR+aMJxctEXO21jqeYxYZq/Z0HvT4=; b=CYAoYFfqdozTV/wxRDCPZW9pTRmZtag+TmJsGrSZHmzRopeA5/pkWhFyryhcAyEAUNqGty AdJpyht3t6pRa6+y0JWo9gNpLRziYHcMQUhrXX9K4IuXYUwSCL9cCOWOZ+ppiid0pRP4OB jQe071D5zWGKt/xGOIvGxIKddRqv2hwkl9eQi/duz5GRw2Q6q2on9T0K67dp7n+vfXkJFc aqPtMxWGJILh0F5fYxBg/gpFws7alIGBaAHXN5+Bbse6uVcsZ7uOV05HYVgHMv1+snTAnG aHyHhFvKSlhKBxa6/P2BAr0hWP6LC3mAQcDl0QDCCPDyGxx/iFCPc9PkkPUYvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670146871; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=t1/Ygguzvm9+aQHR+aMJxctEXO21jqeYxYZq/Z0HvT4=; b=evkgQHTskZQqQW6RBnyKneT814RbMU6PNChnNG4EkAv4PmZyfMhfU8j/cPaN5dpNlZsX2/ ALO6NJjQV5dFAW4Wattah9zlxA+KOQ280/dQgZaFJKs0rU/RM4hxlsz41ggnJuov5kFcAG Epnsy02WfakrsmvHJkO21HNEDFsqF1WKuDfxQlPyEIvbjsNIL1ob9Sm0rWWbrZKK6WqhG1 xDTp2am7/GWFhLehXtCiIwfimbhEpodDVghgrgqt/YqVE3Z3ac0xyJSe3JHGX7jPPbYceT wozYMG7R3wY8J7Y8o/n/mffnHoeud1D0gHANtRrN5BZQW5JgGdHi2JFmPy2gRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670146871; a=rsa-sha256; cv=none; b=fG0ogEf+Ik8/7Mz5IrukPcUKk5tUy20MtSTVVLN4WyjZjfNKXb9WFfIFoAt72KzLC4C8pY M0WGalrsa0PLuGLGn+zz1NKaZospS88+UQetUXUd5HUaCXlB3S/6OxD+qtQ3czEtpxsNaP tIg76dUKxaMTkQYPgcuMQCmrYylPRcWX+E397p7DjQpO8NuLf8lCx/K0o/K04VzU4A6rGQ SHDnx9QUAZvTK1sh6vBDp+0twbTj3nH0hG1SpfU6zLJ8GiG/vF34Qh/ewKUqfRMVvgoaQX jdP+GEs4CpY8s4gtpAyH+xFdgjrD6juEeCRZ3vA8iDdiiqq6rtQNxu8pgRNeOg== Received: from [IPv6:::1] (p2003000601dfc6751d51642e08063309.dip0.t-ipconnect.de [IPv6:2003:6:1df:c675:1d51:642e:806:3309]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: corvink) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NQ1rx6sr0zSBc; Sun, 4 Dec 2022 09:41:05 +0000 (UTC) (envelope-from corvink@FreeBSD.org) Date: Sun, 04 Dec 2022 10:40:25 +0100 From: =?ISO-8859-1?Q?Corvin_K=F6hne?= To: Mario Marietto , =?ISO-8859-1?Q?Corvin_K=F6hne?= CC: virtualization@freebsd.org, freebsd-x11+help@freebsd.org, FreeBSD virtualization , hackers@freebsd.org Subject: =?US-ASCII?Q?Re=3A_How_to_use_the_framebuffer_?= =?US-ASCII?Q?as_primary_video_device_instead?= =?US-ASCII?Q?_of_the_nvidia_passed-through_g?= =?US-ASCII?Q?raphic_card_in_a_bhyve/linux_vm?= User-Agent: K-9 Mail for Android In-Reply-To: References: <2E8B4BF7-A39E-4B93-820D-FC66F8C2F94B@FreeBSD.org> Message-ID: Autocrypt: addr=corvink@FreeBSD.org; keydata= mQINBGNjZaIBEADDTrDNf+0pwiuRPBdClcnZW83dH1UhuOi0u+A1J2SatEBbNaFVtXXAavewCTuy V/ZbNidjlhq3R/pWyiKjFKvs5dj7PMCw+3z2D5OWpMdHg7TrB+fbdFPOEsu0zQVKNaO+pSKCfN0R e0m7bL3wuvl7PXvBufRwA3Guo1P4j3TXWaEkuso7VupTvE25zVGg9ONHrGOjA9RUy+Yg4Se3NLgt UdjBgA21SBQTDvRQV4fDmVenlwvWeE0Xm8FcDcpQb6sJTihaDku78mi3Ux1HCk7rTcepVEB0xIB6 qmFxv0sLlDmVv6Z6qg1y/Q5m23Pgz60o3TulMPV4F+3Itm8ifU+wgVSzBZbD29GYkd7LKqMkFbhv fSBk+5db3vbYY5OD//+LTM5AV7e2AhXuXMvG1UNBqXqSJTTSy6KZz+qmPQO0zos0dq46p8o82lKi BEGD2Hu0p+u0OyV+MmRYo1NIBFVbOPXp2MvUVl5II0UIJ3+N9gLBmfGA+HEpVO8PnvdoT/5NQ7m8 JK1rQHzjiDub/iDPAYMqKH4C0eZ/7zO0fuY5FeRNtuNtpH1Bw/+7/5RJH7bcKkfGHHEp15FJUrGH gWNydoDLB9QBprwQc8FEldDXBjzOMXIgh6FGKLNu6DswvIPGy6M3u7DXwDakCXz+c9Ym0oFihLzZ xWntrsxdswD/CwARAQABtCNDb3J2aW4gS8O2aG5lIDxjb3J2aW5rQEZyZWVCU0Qub3JnPokCVAQT AQoAPhYhBIL0UpWt5trfx9lPRthU2lYxXgJqBQJjY2WiAhsDBQkJZgGABQsJCAcDBRUKCQgLBRYD AgEAAh4BAheAAAoJENhU2lYxXgJq98MQAIIWdelHsf146A/4Ykw0+0rqL3/Gep3JeLy4Jkg3SFjC M3hfOj1Iws5/hRSVAS944H5saptF8d398YqeuVeI93RIakpYkLbWCov8OwgfQnwjdaG2H47y189Z 4XLSgKy8FpoYUsisN+giAcX2L+CoR7jzGE3jbB4HTZneZ1HUvR3swT8EvBLSYJd71mHe4fDrdLrF gHdayOm3F7+mHpOlANQpa1EmSMLoGpc8F1OGltt8hFaaNlunZ8oQk++1FdLXj6BtSpZ4njEK+msD f5p7u+2un3VfvvnKeDJbddPDlyYOIkiPKQfz7OEQig1Bc0GkWt6GRANitwz5agTo0ZImj7dUm9JF aFQZYNWvF1Ng2RsiOZM2WQjXY0g0LTTsOK5Xs4X1cdaCttvKW+5m9s4OZslF2FMXL26kBTKBfX/F QBAQgyoyImbJN2/yLQhtnrXVYSVDH1ceAZ5mAzr7f3+Vo3wXCykzqAT/g3Nkchk3QsQE56tmqgX4 iXp5xxCmgRbHudv9GKUmnd1RTK+QGclaD4AkHKiyDznuS++YOdndQH5t6Nalx8W+duSIo9QE8M7u 1Y9vmvbIUOkN79WDnH6xFuSRcZQUPpHHSn9mJEid5VWDx6ZPOENHQgv8FmSr+5UmR1qmFmWLUX/f Vw2B/pkliePGWTzq6JhLJJlBHR0osOqruQINBGNjZaIBEAC4V8zlnLa957NAFPmOuW6cL1W1/E3p MtoxNYMaZmOtEDaOLV645qfie2XXh2Bn44hzN3vZ3ZaWV9FKipGTxCTNL6Im6o8ghKX4cIBiACeS bcAcIdsxCGnFLO46lPm7NYbGGfU532A8QfvpYeO4ue8H+qNWw9lWXCU1djoPwbo9McfyJ7CA3reT 9wgPO4/nAo1StfeiYvkOWoxYwpiNstzUZMmd6dRCJhDtHyy639VB2YsvhyLYVB9yQdv5M2VPk2q+ oodiTK/uZvaoubsIqkVlL/fqBdx+bZOG6eSogqTjTLFN5S6EjL4usCY1Vv19uDhWwuvADuMChu3j PNm4PC8pI6O4DPiWAqt+Aw4WDfKM2ie8JqzCtUXf/Iv+aSiMhNMT0qGn+Ybq98yWXs1k67M7Pheu rWO2hfYtMQJtpHYHqz3T7VC0F4bAPl3rDRL4PJ2Vr9eoo5upVPbZN1JXAA5oEX7coA1BQz/18LlT BhNmHk2wsi5omYZOnBoZelA7kpNx/8zc2zanOnO7NW0dJLq/o4GlfP56UFV8I1MWNyI351BAkIJy Thrjv7aMxLhpNny6uYoms7X2oWf2R//QIMA/0jkqsGirksV4CW+7xhuQVwxGIHR2JskZYaPSjJaX TvoGxu/+SwqT00xnF64ZvwDUGiw7yB70s/LolEOZ/5JqgQARAQABiQI8BBgBCgAmFiEEgvRSla3m 2t/H2U9G2FTaVjFeAmoFAmNjZaICGwwFCQlmAYAACgkQ2FTaVjFeAmrhSw/+NqYqv6oHppWZ7hpt +2Df+qIw2kOgvo0ecU8orastt7OfiJpRzlDFPK2nhok5t4+1PZCi4jcR5Ub22Ddy4O00FOCRAq70 haA+cNNiZ0XlD5cDv+CxmT0NkD337ls5wz8zyOX7n7Z4jG8ghiJEkcLQbyp2qYaggKrz2sGWKUjB yS7jySRCotPOO+0W6Iz2dw9215ZQ1F3uZwdRlpXA7ypzUBEvIJxc563fFuPetbZAIavGMT844hov sMXW2Q/MS3HI03USkgeVaqANbSOUFAdt2tgTrvUw/vXBckp4T+vATNdQH0WieBIX4nRQQ6SjfmaI 82QxJuJjb5NJ6bgS+HPIUH8J1Iw958y/Rs5svzKW+/YYoZBDuhtbAeoJdiy7a7wtK6pBv+xMdpmK LBgVVXOeX6sucwJ/K68tb5aOmbuPLAaIoKgm/9IF8dqiI23JoM2ZhpYZjpVMpakGIxV6R4Kp2hrq C4oNpuVLJ7LQSMuocXduguvWYdYvVXSdpC1Ed+fLtFXA0h5fhDqHFDCDM2CgQX2DfzXe/rV7vChm 61fQYn+85md1vPiefnsaunEh3+cbcFfIshNmIRfAKwA2//75eqgBuC2D5ZIr93LsEUCcabnQZdaZ KGSo/ruWNZdPyjj/b6MhAifkoFFrkN4/dwIqYIev8wMbh3+7dcZIRza0foM= List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary="----RVWP21E210Y1WYVOOQ949O2E7KPGYQ"; protocol="application/pgp-signature"; micalg="pgp-sha512" X-ThisMailContainsUnwantedMimeParts: N ------RVWP21E210Y1WYVOOQ949O2E7KPGYQ Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=----H6FBY8VGI8VXKDMZYDEM5KZVWOX61O ------H6FBY8VGI8VXKDMZYDEM5KZVWOX61O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On December 3, 2022 7:14:29 PM GMT+01:00, Mario Marietto wrote: >ok=2E I tried like this,but it didn't work : > >bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >-s 0,hostbridge \ >-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,bootin= dex=3D1 \ >-s 3,virtio-blk,/dev/$vmdisk4 \ >-s 4,virtio-blk,/dev/$vmdisk2 \-s 7,fbuf,tcp=3D0=2E0=2E0=2E0:5919,w=3D160= 0,h=3D950,wait \ >-s 8:0,passthru,2/0/0 \ >-s 8:1,passthru,2/0/1 \ >-s 8:2,passthru,2/0/2 \ >-s 8:3,passthru,2/0/3 \ >-s 10,virtio-net,tap19 \ >-s 11,virtio-9p,sharename=3D/ \ >-s 30,xhci,tablet \ >-s 31,lpc \ >-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \ >vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 > >I tried specifying the bus ID of the framebuffer and I have used this >xorg=2Econf file : > >Section "Files" > ModulePath "/usr/lib/xorg/modules" > FontPath "/usr/share/fonts/X11/misc" > FontPath "/usr/share/fonts/X11/cyrillic" > FontPath "/usr/share/fonts/X11/100dpi/:unscaled" > FontPath "/usr/share/fonts/X11/75dpi/:unscaled" > FontPath "/usr/share/fonts/X11/Type1" > FontPath "/usr/share/fonts/X11/100dpi" > FontPath "/usr/share/fonts/X11/75dpi" > FontPath "built-ins" >EndSection > >Section "Module" > Load "vnc" > Load "glx" >EndSection > > >Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" >EndSection > >Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/input/mice" > Option "ZAxisMapping" "4 5 6 7" > >EndSection > >Section "Monitor" > Identifier "Monitor0" > VendorName "Monitor Vendor" > ModelName "Monitor Model" >EndSection > >Section "Device" > Identifier "Card0" > Driver "modesetting" > BusID "PCI:0:7:0" > >EndSection > >Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor "Monitor0" > SubSection "Display" > Viewport 0 0 > Depth 1 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 4 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 8 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 15 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 16 > EndSubSection > SubSection "Display" > Viewport 0 0 > Depth 24 > EndSubSection >EndSection > >The error reported has been : > >https://ibb=2Eco/1KX2h26 >https://ibb=2Eco/Cv5FffB > >thanks=2E > >Il giorno sab 3 dic 2022 alle ore 17:34 Corvin K=C3=B6hne >ha scritto: > >> On December 3, 2022 4:49:46 PM GMT+01:00, Mario Marietto < >> marietto2008@gmail=2Ecom> wrote: >>> >>> Hello to everyone=2E >>> >>> what Im trying to do is to set the framebuffer video adapter as primar= y >>> graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti c= ard >>> that I have passed through=2E What I want to do really is to use both = the >>> graphic adapters,but the primary should be the framebuffer and the >>> secondary the nvidia=2E I tried different Xorg configurations,but what= I've >>> got is that Xorg failed to display some errors=2E So,the controller th= at you >>> see below should be used as primary inside the ubuntu vm : >>> >>> 00:1d=2E0 VGA compatible controller: Device fb5d:40fb >>> >>> while the ones you see below as secondary : >>> >>> 08:00=2E0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce= RTX 2080 Ti] (rev a1) >>> 08:00=2E1 Audio device: NVIDIA Corporation TU102 High Definition Audio= Controller (rev a1) >>> 08:00=2E2 USB controller: NVIDIA Corporation TU102 USB 3=2E1 Host Cont= roller (rev a1) >>> 08:00=2E3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C U= CSI Controller (rev a1) >>> >>> >>> The script that I use to launch the vm is the following : >>> >>> #!/bin/sh >>> setxkbmap it >>> vms=3D"$(ls /dev/vmm/*)" >>> vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')" >>> >>> for vm in $vms; do >>> session=3D"${vm##*/}" >>> echo "bhyve session =3D $session" >>> echo "vnc session =3D $vncs" >>> if ! printf '%s\n' "${vncs}" | grep "${session}"; then >>> printf 'VNC session not found,destroyi= ng ghost vms\n' >>> bhyvectl --vm=3D$session --destroy >>> else >>> printf 'Found VNC session %s\n' "${ses= sion},no ghost vms found,not destroying them" >>> fi >>> done >>> >>> vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (2= 015020204055E)/ && d{print d}'` >>> echo "TOSHIBA External USB 3=2E0 1=2E8 TB ; $vmdisk1" >>> >>> mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2' >>> >>> bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >>> -s 0,hostbridge \ >>> -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,boo= tindex=3D1 \ >>> -s 3,virtio-blk,/dev/$vmdisk4 \ >>> -s 4,virtio-blk,/dev/$vmdisk2 \ >>> -s 8:0,passthru,2/0/0 \ >>> -s 8:1,passthru,2/0/1 \ >>> -s 8:2,passthru,2/0/2 \ >>> -s 8:3,passthru,2/0/3 \ >>> -s 10,virtio-net,tap19 \ >>> -s 11,virtio-9p,sharename=3D/ \ >>> -s 29,fbuf,tcp=3D0=2E0=2E0=2E0:5919,w=3D1600,h=3D950,wait \ >>> -s 30,xhci,tablet \ >>> -s 31,lpc \ >>> -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \ >>> vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 >>> >>> For sure ,on /boot/loader=2Econf I've added : >>> >>> /boot/loader=2Econf >>> >>> pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3" >>> >>> As I said before,I tried two xorg conf files to achieve the goal=2E On= the >>> first one I tried to add only the framebuffer,like this : >>> >>> >>> Section "Files" >>> ModulePath "/usr/lib/xorg/modules" >>> FontPath "/usr/share/fonts/X11/misc" >>> FontPath "/usr/share/fonts/X11/cyrillic" >>> FontPath "/usr/share/fonts/X11/100dpi/:unscaled" >>> FontPath "/usr/share/fonts/X11/75dpi/:unscaled" >>> FontPath "/usr/share/fonts/X11/Type1" >>> FontPath "/usr/share/fonts/X11/100dpi" >>> FontPath "/usr/share/fonts/X11/75dpi" >>> FontPath "built-ins" >>> EndSection >>> >>> Section "Module" >>> Load "vnc" >>> Load "glx" >>> EndSection >>> >>> >>> Section "InputDevice" >>> Identifier "Keyboard0" >>> Driver "kbd" >>> EndSection >>> >>> Section "InputDevice" >>> Identifier "Mouse0" >>> Driver "mouse" >>> Option "Protocol" "auto" >>> Option "Device" "/dev/input/mice" >>> Option "ZAxisMapping" "4 5 6 7" >>> >>> EndSection >>> >>> Section "Monitor" >>> Identifier "Monitor0" >>> VendorName "Monitor Vendor" >>> ModelName "Monitor Model" >>> EndSection >>> >>> Section "Device" >>> Identifier "Card0" >>> Driver "modesetting" >>> BusID "PCI:0:29:0" >>> >>> EndSection >>> >>> Section "Screen" >>> Identifier "Screen0" >>> Device "Card0" >>> Monitor "Monitor0" >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 1 >>> EndSubSection >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 4 >>> EndSubSection >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 8 >>> EndSubSection >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 15 >>> EndSubSection >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 16 >>> EndSubSection >>> SubSection "Display" >>> Viewport 0 0 >>> Depth 24 >>> EndSubSection >>> EndSection >>> >>> >>> but it didn't work=2E This is the log file that shows the errors repor= ted : https://pastebin=2Eubuntu=2Ecom/p/Gv7wgsDR4K/ >>> I have also removed the xorg=2Econf file,but it didn't work either=2E = This is the log file that shows the errors reported : >>> >>> >>> https://pastebin=2Eubuntu=2Ecom/p/wNcfQTByQm/ >>> >>> Can someone give me some suggestions that can help me to understand wh= ere the mistake is,please,thanks=2E >>> >>> -- >>> Mario=2E >>> >> >> Try to assign a lower pci slot number to the framebuffer device than to >> the nvidia gpu in your bhyve command=2E >> -- >> Best regards, >> Corvin >> > > >--=20 >Mario=2E I'm unfamiliar with X but according to your logs it looks like it selects = the framebuffer device as primary graphics in the first place: (--) PCI:*(0@0:7:0) =2E=2E=2E (--) PCI: (0@0:8:0) =2E=2E=2E --=20 Best regards, Corvin ------H6FBY8VGI8VXKDMZYDEM5KZVWOX61O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On December 3, 2022 7:1= 4:29 PM GMT+01:00, Mario Marietto <marietto2008@gmail=2Ecom> wrote:
ok=2E I tried like this,but it didn't work :
bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m =
4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,bootind=
ex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 7,fbuf,tcp=3D0=2E0=2E0=2E0:5919,w=3D1600,h=3D950,wait \
-s 8:0,passthr=
u,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19

I tried specifying the bus ID of the framebuffer and I h= ave used this xorg=2Econf file :

=
Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:7:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection
The error reported has been :
thanks=2E

=
Il giorno sab 3 dic 2022 alle ore 17:= 34 Corvin K=C3=B6hne <corvink@f= reebsd=2Eorg> ha scritto:
On December 3, 2022 4:49= :46 PM GMT+01:00, Mario Marietto <marietto2008@gmail=2Ecom> wrote:
Hello to everyone=2E

what Im trying to do is to set the framebuffer video adapter as primary=20 graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti=20 card that I have passed through=2E What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the=20 secondary the nvidia=2E I tried different Xorg configurations,but what I'v= e got is that Xorg failed to display some errors=2E So,the controller that you see below should be used as primary inside the ubuntu vm :

00:1d=2E0 VGA compatible controller: Device fb5d:=
40fb

while the ones you see below as secondary :

08:00=2E0 VGA compatible controller: NV=
IDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1)
08:00=2E1 Audio device: NVIDIA Corporation TU102 High Definition Audio Con=
troller (rev a1)
08:00=2E2 USB controller: NVIDIA Corporation TU102 USB 3=2E1 Host Controll=
er (rev a1)
08:00=2E3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI =
Controller (rev a1)

The script that I use to launch the vm is the following :

#!/bin/sh
setxkbmap it
vms=3D"$(ls /dev/vmm/*)"
vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')"

for vm in $vms; do
                session=3D"${vm##*/}"
                echo "bhyve session =3D $session"
                echo "vnc session =3D $vncs"
                if ! printf '%s\n' "${vncs}" | grep "${session}"; then
                                printf 'VNC session not found,destroying g=
host vms\n'
                                bhyvectl --vm=3D$session --destroy        =
                  =20
                else
                                printf 'Found VNC session %s\n' "${session=
},no ghost vms found,not destroying them"
                fi
done

vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (20150=
20204055E)/ && d{print d}'`
echo "TOSHIBA External USB 3=2E0 1=2E8 TB ; $vmdisk1"

mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2'

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210=2Eimg,bootind=
ex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 29,fbuf,tcp=3D0=
=2E0=2E0=2E0:5919,w=3D1600,h=3D950,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE=2Efd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19


For sure ,on /boot/load=
er=2Econf I've added :

/boot/loader=2Econf

pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3"


As I said before,I trie=
d two xorg conf files to achieve the goal=2E On the
first one I tried to add only the framebuffer,like this :

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:29:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection


b=
ut it didn't work=2E This is the log file that shows the errors reported : =
https://pastebin=2Eubuntu=2Ecom/p/Gv7wgsDR4K=
/
I have a=
lso removed the xorg=2Econf file,but it didn't work either=2E This is the l=
og file that shows the errors reported :


https://pastebi=
n=2Eubuntu=2Ecom/p/wNcfQTByQm/


Can someone give me som=
e suggestions that can help me to understand where the mistake is,please,th=
anks=2E
--
Mario=2E

Try to assign a lower pci slot number= to the framebuffer device than to the nvidia gpu in your bhyve command=2E<= br>
--
Best regards,
Corvin<= /div>

I'm unfamiliar with X but according to your logs it looks l= ike it selects the framebuffer device as primary graphics in the first plac= e:


(--) PCI:*(0@0:7:0) =2E=2E=2E
(--) PCI: (0@0:8:0) =2E=2E= =2E

--
Best regards,
Corvin
------H6FBY8VGI8VXKDMZYDEM5KZVWOX61O-- ------RVWP21E210Y1WYVOOQ949O2E7KPGYQ Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQJBBAABCgArJBxDb3J2aW4gS8O2aG5lIDxjb3J2aW5rQEZyZWVCU0Qub3JnPgUC Y4xrCQAKCRDYVNpWMV4CarxeD/sG7n++0ZdYzXBzRqMy1wkbQ7aKRyUXfavw4rRi Ac76xISHv7uWKh0gk0MJgZ9TF3++NzVL4zSie2tLDLUEuWX42ZuEFyfTZuAk/KpJ zLR0AbHbYrNA+uu5+itdq6AXaVT1ViRzx5+DiUmb/m7CthTk/OO2gCs3wuIwzfYp 1jmrfLr6dYJ0aSK5oB7j1cY5SeaRTjQ6i69Y1znp7s7ScpzaECaKlt0FEdaGSQXu 2yuJ231o2zv4Gtx5GVZOmC8qu5l8Pm031NRIX/+fsed0qZc+FAempR1MdlVVcz+S XsZjaDJnhH/LQlCu7QAgO2L9BeECq2Dxuf2H6DoXPY2FWgtD+3NruB6xKSWDXMer IOmLnbVnn3rkHs6aquIwLIeHHVgVE8yGckRjoeMaPWCZJIlG5U2mH4OLemZapRXJ ZxG56XZV06qW/4F0Lhxjz6RyW/KEp8xFHmWjyOcpaJce3HhAl2rNLXtxv8rVOi8a VBGx9GiDajn+Xq17xhwrTsrzppTjLfFq0bXnfL0gcnMkASbXnrHxrMUCYGPzzHTS 2OhwxfmlqMhpFK4TN77qcLIM3SijQTt7WYlMYaRacVrbNs2VuXihqgppA6T4Wmys 9lONeuePJAIsRnYo1fuAezC371QlKPzSlLoxs85gx5bcn5bVzNOkVDacACQiAF61 k0rLww== =6qaz -----END PGP SIGNATURE----- ------RVWP21E210Y1WYVOOQ949O2E7KPGYQ-- From nobody Sun Dec 4 13:33:33 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NQ71y12sfz4jG5t; Sun, 4 Dec 2022 13:34:14 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NQ71x3M42z43vg; Sun, 4 Dec 2022 13:34:13 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id gu23so21915376ejb.10; Sun, 04 Dec 2022 05:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i5fYoJiF2Hgy3m0ltKAAffb3X+hx1t/9T8h5wKgQx1g=; b=auvWGFLbqif1PeIzJ8rCbE2YHLlJXY0Tor33qFvpBUTefmjCsp/0j9BavIhPTlOIng 8utHLoLRZPFoMXfXPYhVcw0pL8UDhP57e2rhGh2WchiVbjSrUemEyCYtxDj84gPQgJa4 TL/e3YJ/WKwI4In7pbrZkfmBsrvNTlwkCZr5ZIzn0MP4aBR4W1fxUxwUe0XNhsTCJBsj 5JmF8gZLwrUdUNNElM/cxHcS3zGf/n6Sn5zu/xukXqj1vvDWwBvuYxNCyP3IMqmTaSVn 1tpWMxtMEkE4aZoSQx2FMrDqBYHp7/5XbNMnIViEM24+8x5la9ViqmP4ZnTX2TibLPDU qV5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i5fYoJiF2Hgy3m0ltKAAffb3X+hx1t/9T8h5wKgQx1g=; b=ewPV+afN/0nxUlxChhBR31eQBfEX+r4laD/OlwZWcMt6Lmu20eb73clKNBlHPqBORx YlQVViGyythTlWnopz0ZFIsc+fzDBo99Q2+CC6wDrX5SHyb/EQ17wOZAFvVcFcjK7Mqi Td8PcYyaHQbMgVq98IkZpMeUhRHbMTqqnWC7jaOpMbI8WXI/IS51GtqkN8HVCb6ECnSb WkPg7BieqDJdSFQQsCgCL6aPhMYouyPmOJFFQ00/3GKvKUsgwrbkPQC133CAPFSjTlGG 93EnizNZO3LpHRjlmN87VdvKK8Qa3q19DPm6ClweETTpUlC4y2nrT0zIiGkXnsxojL6W 8+9g== X-Gm-Message-State: ANoB5pnYEoas+mX7OGGMHkZjovOEj6p4sTCIzbYO3C848b7cua9AB+Lr bLp4ldELMvCD3sou+w7oR73h1Cw3PhriBqHi4il/SpzLpik/uA== X-Google-Smtp-Source: AA0mqf7kJ8pmZURY/o3QAobG8wZqapyaRqgUu/pJhLCRrMmyo2F9k6XCFPAvfKzICdr9JP2rXyVAHiI1XRWyMEEXTjA= X-Received: by 2002:a17:906:c08:b0:7bf:99a6:95aa with SMTP id s8-20020a1709060c0800b007bf99a695aamr27813941ejf.7.1670160850159; Sun, 04 Dec 2022 05:34:10 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2E8B4BF7-A39E-4B93-820D-FC66F8C2F94B@FreeBSD.org> In-Reply-To: From: Mario Marietto Date: Sun, 4 Dec 2022 14:33:33 +0100 Message-ID: Subject: Re: How to use the framebuffer as primary video device instead of the nvidia passed-through graphic card in a bhyve/linux vm To: =?UTF-8?Q?Corvin_K=C3=B6hne?= Cc: virtualization@freebsd.org, FreeBSD virtualization , hackers@freebsd.org, freebsd-x11@freebsd.org Content-Type: multipart/alternative; boundary="000000000000310e4a05ef00a048" X-Rspamd-Queue-Id: 4NQ71x3M42z43vg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000310e4a05ef00a048 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. I know,but it does not work. If I use ONLY the framebuffer argument,it works : the desktop manager is loaded within the vm window,but if between the bhyve parameters I declare the framebuffer AND the nvidia slots,on the vm window I see the blinking pointer because the output is redirected to the screen that I have attached to the nvidia HDMI connector. The problem is that at the moment I can't use that monitor,since I'm using my PC in a different room. I made an experiment : I have excluded all the parameters that may be used in my old Ubuntu installation by installing Ubuntu (22.10) from scratch and between the bhyve parameters I have added both the framebuffer and the 4 nVidia slots. bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 1,ahci-cd,/mnt/$vmdisk1'p2'/bhyve/iso/Linux/ubuntu-22.10-desktop-amd64.iso \ -s 7:0,fbuf,tcp=3D0.0.0.0:5916,w=3D1600,h=3D950,wait \ -s 8:0,passthru,2/0/0 \ -s 8:1,passthru,2/0/1 \ -s 8:2,passthru,2/0/2 \ -s 8:3,passthru,2/0/3 \ -s 10,virtio-net,tap16 \ -s 11,virtio-9p,sharename=3D/ \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ vm0:16 < /dev/null & sleep 2 && vncviewer 0:16 When I choose "try and install Ubuntu" I see the blinking pointer because the output is redirected to the screen that I can't use. But if I choose "safe graphics" maybe it makes the magic. Below you can see what are the parameters used by Ubuntu to display the installer even if between the bhyve parameters I have used the framebuffer and the nVidia adapters. https://ibb.co/L9JqQbL Instead below you can see what are the parameters used by Ubuntu to display the installer if between the bhyve parameters I use both the framebuffer and the nVidia adapters but without choosing "safe graphics" on the ubuntu boot menu. https://ibb.co/wNJxxkV As you can see,the parameter that makes the difference is called "nomodeset". So,I presume that in a certain ubuntu configuration file I should add that parameter.... Il giorno dom 4 dic 2022 alle ore 10:41 Corvin K=C3=B6hne ha scritto: > On December 3, 2022 7:14:29 PM GMT+01:00, Mario Marietto < > marietto2008@gmail.com> wrote: >> >> ok. I tried like this,but it didn't work : >> >> bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >> -s 0,hostbridge \ >> -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bootind= ex=3D1 \ >> -s 3,virtio-blk,/dev/$vmdisk4 \ >> -s 4,virtio-blk,/dev/$vmdisk2 \-s 7,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h= =3D950,wait \ >> -s 8:0,passthru,2/0/0 \ >> -s 8:1,passthru,2/0/1 \ >> -s 8:2,passthru,2/0/2 \ >> -s 8:3,passthru,2/0/3 \ >> -s 10,virtio-net,tap19 \ >> -s 11,virtio-9p,sharename=3D/ \ >> -s 30,xhci,tablet \ >> -s 31,lpc \ >> -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ >> vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 >> >> I tried specifying the bus ID of the framebuffer and I have used this >> xorg.conf file : >> >> Section "Files" >> ModulePath "/usr/lib/xorg/modules" >> FontPath "/usr/share/fonts/X11/misc" >> FontPath "/usr/share/fonts/X11/cyrillic" >> FontPath "/usr/share/fonts/X11/100dpi/:unscaled" >> FontPath "/usr/share/fonts/X11/75dpi/:unscaled" >> FontPath "/usr/share/fonts/X11/Type1" >> FontPath "/usr/share/fonts/X11/100dpi" >> FontPath "/usr/share/fonts/X11/75dpi" >> FontPath "built-ins" >> EndSection >> >> Section "Module" >> Load "vnc" >> Load "glx" >> EndSection >> >> >> Section "InputDevice" >> Identifier "Keyboard0" >> Driver "kbd" >> EndSection >> >> Section "InputDevice" >> Identifier "Mouse0" >> Driver "mouse" >> Option "Protocol" "auto" >> Option "Device" "/dev/input/mice" >> Option "ZAxisMapping" "4 5 6 7" >> >> EndSection >> >> Section "Monitor" >> Identifier "Monitor0" >> VendorName "Monitor Vendor" >> ModelName "Monitor Model" >> EndSection >> >> Section "Device" >> Identifier "Card0" >> Driver "modesetting" >> BusID "PCI:0:7:0" >> >> EndSection >> >> Section "Screen" >> Identifier "Screen0" >> Device "Card0" >> Monitor "Monitor0" >> SubSection "Display" >> Viewport 0 0 >> Depth 1 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 4 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 8 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 15 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 16 >> EndSubSection >> SubSection "Display" >> Viewport 0 0 >> Depth 24 >> EndSubSection >> EndSection >> >> The error reported has been : >> >> https://ibb.co/1KX2h26 >> https://ibb.co/Cv5FffB >> >> thanks. >> >> Il giorno sab 3 dic 2022 alle ore 17:34 Corvin K=C3=B6hne >> ha scritto: >> >>> On December 3, 2022 4:49:46 PM GMT+01:00, Mario Marietto < >>> marietto2008@gmail.com> wrote: >>>> >>>> Hello to everyone. >>>> >>>> what Im trying to do is to set the framebuffer video adapter as primar= y >>>> graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti c= ard >>>> that I have passed through. What I want to do really is to use both th= e >>>> graphic adapters,but the primary should be the framebuffer and the >>>> secondary the nvidia. I tried different Xorg configurations,but what I= 've >>>> got is that Xorg failed to display some errors. So,the controller that= you >>>> see below should be used as primary inside the ubuntu vm : >>>> >>>> 00:1d.0 VGA compatible controller: Device fb5d:40fb >>>> >>>> while the ones you see below as secondary : >>>> >>>> 08:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce R= TX 2080 Ti] (rev a1) >>>> 08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio C= ontroller (rev a1) >>>> 08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controll= er (rev a1) >>>> 08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCS= I Controller (rev a1) >>>> >>>> >>>> The script that I use to launch the vm is the following : >>>> >>>> #!/bin/sh >>>> setxkbmap it >>>> vms=3D"$(ls /dev/vmm/*)" >>>> vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')" >>>> >>>> for vm in $vms; do >>>> session=3D"${vm##*/}" >>>> echo "bhyve session =3D $session" >>>> echo "vnc session =3D $vncs" >>>> if ! printf '%s\n' "${vncs}" | grep "${session}"; then >>>> printf 'VNC session not found,destroyi= ng ghost vms\n' >>>> bhyvectl --vm=3D$session --destroy >>>> else >>>> printf 'Found VNC session %s\n' "${ses= sion},no ghost vms found,not destroying them" >>>> fi >>>> done >>>> >>>> vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (2= 015020204055E)/ && d{print d}'` >>>> echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1" >>>> >>>> mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2' >>>> >>>> bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ >>>> -s 0,hostbridge \ >>>> -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,booti= ndex=3D1 \ >>>> -s 3,virtio-blk,/dev/$vmdisk4 \ >>>> -s 4,virtio-blk,/dev/$vmdisk2 \ >>>> -s 8:0,passthru,2/0/0 \ >>>> -s 8:1,passthru,2/0/1 \ >>>> -s 8:2,passthru,2/0/2 \ >>>> -s 8:3,passthru,2/0/3 \ >>>> -s 10,virtio-net,tap19 \ >>>> -s 11,virtio-9p,sharename=3D/ \ >>>> -s 29,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h=3D950,wait \ >>>> -s 30,xhci,tablet \ >>>> -s 31,lpc \ >>>> -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ >>>> vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 >>>> >>>> For sure ,on /boot/loader.conf I've added : >>>> >>>> /boot/loader.conf >>>> >>>> pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3" >>>> >>>> As I said before,I tried two xorg conf files to achieve the goal. On t= he >>>> first one I tried to add only the framebuffer,like this : >>>> >>>> >>>> Section "Files" >>>> ModulePath "/usr/lib/xorg/modules" >>>> FontPath "/usr/share/fonts/X11/misc" >>>> FontPath "/usr/share/fonts/X11/cyrillic" >>>> FontPath "/usr/share/fonts/X11/100dpi/:unscaled" >>>> FontPath "/usr/share/fonts/X11/75dpi/:unscaled" >>>> FontPath "/usr/share/fonts/X11/Type1" >>>> FontPath "/usr/share/fonts/X11/100dpi" >>>> FontPath "/usr/share/fonts/X11/75dpi" >>>> FontPath "built-ins" >>>> EndSection >>>> >>>> Section "Module" >>>> Load "vnc" >>>> Load "glx" >>>> EndSection >>>> >>>> >>>> Section "InputDevice" >>>> Identifier "Keyboard0" >>>> Driver "kbd" >>>> EndSection >>>> >>>> Section "InputDevice" >>>> Identifier "Mouse0" >>>> Driver "mouse" >>>> Option "Protocol" "auto" >>>> Option "Device" "/dev/input/mice" >>>> Option "ZAxisMapping" "4 5 6 7" >>>> >>>> EndSection >>>> >>>> Section "Monitor" >>>> Identifier "Monitor0" >>>> VendorName "Monitor Vendor" >>>> ModelName "Monitor Model" >>>> EndSection >>>> >>>> Section "Device" >>>> Identifier "Card0" >>>> Driver "modesetting" >>>> BusID "PCI:0:29:0" >>>> >>>> EndSection >>>> >>>> Section "Screen" >>>> Identifier "Screen0" >>>> Device "Card0" >>>> Monitor "Monitor0" >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 1 >>>> EndSubSection >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 4 >>>> EndSubSection >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 8 >>>> EndSubSection >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 15 >>>> EndSubSection >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 16 >>>> EndSubSection >>>> SubSection "Display" >>>> Viewport 0 0 >>>> Depth 24 >>>> EndSubSection >>>> EndSection >>>> >>>> >>>> but it didn't work. This is the log file that shows the errors reporte= d : https://pastebin.ubuntu.com/p/Gv7wgsDR4K/ >>>> I have also removed the xorg.conf file,but it didn't work either. This= is the log file that shows the errors reported : >>>> >>>> >>>> https://pastebin.ubuntu.com/p/wNcfQTByQm/ >>>> >>>> Can someone give me some suggestions that can help me to understand wh= ere the mistake is,please,thanks. >>>> >>>> -- >>>> Mario. >>>> >>> >>> Try to assign a lower pci slot number to the framebuffer device than to >>> the nvidia gpu in your bhyve command. >>> -- >>> Best regards, >>> Corvin >>> >> >> > I'm unfamiliar with X but according to your logs it looks like it selects > the framebuffer device as primary graphics in the first place: > > > (--) PCI:*(0@0:7:0) ... > (--) PCI: (0@0:8:0) ... > > -- > Best regards, > Corvin > --=20 Mario. --000000000000310e4a05ef00a048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I know,but it does no= t work. If I use ONLY the framebuffer argument,it works : the desktop manag= er is loaded within the vm window,but if between the bhyve parameters I dec= lare the framebuffer AND the nvidia slots,on the vm window I see the blinki= ng pointer because the output is redirected to the screen that I have attac= hed to the nvidia HDMI connector. The problem is that at the moment I can&#= 39;t use that monitor,since I'm using my PC in a different room.
I made an experiment : I have excluded all the parameters that may= be used in my old Ubuntu installation by installing Ubuntu (22.10) from sc= ratch and between the bhyve parameters I have added both the framebuffer an= d the 4 nVidia slots.

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 1,ahci-cd,/mnt/$vmdisk1'p2'/bhyve/iso/Linux/ubuntu-22.10-des= ktop-amd64.iso \
-s 7:0,fbuf,tcp=3D0.0= .0.0:5916,w=3D1600,h=3D950,wait \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap16 \
-s 11,virtio-9p,sharename=3D/ \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:16 < /dev/null & sleep 2 && vncviewer 0:16

W= hen I choose "try and install Ubuntu" I see the blinking pointer = because the output is redirected to the screen that I can't use. But if= I choose "safe graphics" maybe it makes the magic. Below you can= see what are the parameters used by Ubuntu to display the installer even i= f between the bhyve parameters I have used the framebuffer and the nVidia a= dapters.


Instead below you can se= e what are the parameters used by Ubuntu to display the=20 installer if between the bhyve parameters I use both the=20 framebuffer and the nVidia adapters but without choosing "safe graphic= s" on the ubuntu boot menu.


As yo= u can see,the parameter that makes the difference is called "nomodeset= ". So,I presume that in a certain ubuntu configuration file I should a= dd that parameter....


Il giorno dom 4 dic 2022 alle ore 10:41 Corvin K=C3=B6hne <corvink@freebsd.org<= /a>> ha scritto:
On December 3, 2022 7:14:29 PM GMT+01:0= 0, Mario Marietto <marietto2008@gmail.com> wrote:
ok. I tried like this,but it didn't work :
<= div>
bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m=
 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bo=
otindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 7,fbuf,tcp=3D0.0=
.0.0:5919,w=3D1600,h=3D950,wait \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19

I tried specifying the bus ID of the framebuffer and I ha= ve used this xorg.conf file :

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:7:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection
The error reported has been :

Il giorno sa= b 3 dic 2022 alle ore 17:34 Corvin K=C3=B6hne <corvink@freebsd.org> ha scritto:
=
On December 3, 2022 4:49:46 PM GMT+01:00, Mario Marietto <<= a href=3D"mailto:marietto2008@gmail.com" target=3D"_blank">marietto2008@gma= il.com> wrote:
Hello to everyone.

what Im trying to do is to set the framebuffer video adapter as primary=20 graphic card on my bhyve-ubuntu vm instead of the nvidia RTX 2080 ti=20 card that I have passed through. What I want to do really is to use both the graphic adapters,but the primary should be the framebuffer and the=20 secondary the nvidia. I tried different Xorg configurations,but what I'= ve got is that Xorg failed to display some errors. So,the controller that you see below should be used as primary inside the ubuntu vm :

00:1d.0 VGA compatible controller: Device fb5d:40f=
b

while the ones you see below as secondary :

08:00.0 VGA compatible controller: NVIDI=
A Corporation TU102 [GeForce RTX 2080 Ti] (rev a1)
08:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Contro=
ller (rev a1)
08:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (r=
ev a1)
08:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Con=
troller (rev a1)

The script that I use to launch the vm is the following :

#!/bin/sh
setxkbmap it
vms=3D"$(ls /dev/vmm/*)"
vncs=3D"$(ps ax | awk '/vncviewer [0]/{print $6}')"

for vm in $vms; do
                session=3D"${vm##*/}"
                echo "bhyve session =3D $session"
                echo "vnc session =3D $vncs"
                if ! printf '%s\n' "${vncs}" | grep "=
;${session}"; then
                                printf 'VNC session not found,destroyin=
g ghost vms\n'
                                bhyvectl --vm=3D$session --destroy         =
                 =20
                else
                                printf 'Found VNC session %s\n' &qu=
ot;${session},no ghost vms found,not destroying them"
                fi
done

vmdisk1=3D`geom disk list | awk '/^Geom name: /{d=3D$NF} /^ *ident: (20=
15020204055E)/ && d{print d}'`
echo "TOSHIBA External USB 3.0 1.8 TB ; $vmdisk1"

mount -t ufs /dev/$vmdisk1'p2' /mnt/$vmdisk1'p2'

bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bo=
otindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/dev/$vmdisk2 \
-s 8:0,passthru,2/0/0 \
-s 8:1,passthru,2/0/1 \
-s 8:2,passthru,2/0/2 \
-s 8:3,passthru,2/0/3 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename=3D/ \
-s 29,fbuf,tcp=3D0.0.0.0:=
5919,w=3D1600,h=3D950,wait \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 && vncviewer 0:19


For sure ,on /boot/loade=
r.conf I've added :

/boot/loader.conf

pptdevs=3D"2/0/0 2/0/1 2/0/2 2/0/3"


As I said before,I tried=
 two xorg conf files to achieve the goal. On the
first one I tried to add only the framebuffer,like this :

Section "Files"
    ModulePath   "/usr/lib/xorg/modules"
    FontPath     "/usr/share/fonts/X11/misc"
    FontPath     "/usr/share/fonts/X11/cyrillic"
    FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
    FontPath     "/usr/share/fonts/X11/Type1"
    FontPath     "/usr/share/fonts/X11/100dpi"
    FontPath     "/usr/share/fonts/X11/75dpi"
    FontPath     "built-ins"
EndSection

Section "Module"
    Load  "vnc"
    Load  "glx"
EndSection


Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "kbd"
EndSection

Section "InputDevice"
    Identifier  "Mouse0"
    Driver      "mouse"
    Option        "Protocol" "auto"
    Option        "Device" "/dev/input/mice"
    Option        "ZAxisMapping" "4 5 6 7"

EndSection

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
   Identifier  "Card0"
   Driver      "modesetting"
   BusID       "PCI:0:29:0"

EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     4
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     8
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     15
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection


bu=
t it didn't work. This is the log file that shows the errors reported :=
 https://pastebin.ubuntu.com/p/Gv7wgsDR4K/
I have also rem=
oved the xorg.conf file,but it didn't work either. This is the log file=
 that shows the errors reported :


https://pastebin.ubuntu.co=
m/p/wNcfQTByQm/


Can someone give me some=
 suggestions that can help me to understand where the mistake is,please,tha=
nks.
--
Mario.

Try to assign a lower pci slot number = to the framebuffer device than to the nvidia gpu in your bhyve command.
=
--
Best regards,
Corvin


I'm unfamiliar with X but according to your logs it looks = like it selects the framebuffer device as primary graphics in the first pla= ce:


(--) PCI:*(0@0:7:0) ...
(--) PCI: (0@0:8:0) ...

--
Best regards,
Corvin
=


--
Mario.
--000000000000310e4a05ef00a048-- From nobody Mon Dec 5 15:13:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NQnBn1zSnz4jx0l for ; Mon, 5 Dec 2022 15:14:09 +0000 (UTC) (envelope-from bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz) Received: from e2i580.smtp2go.com (e2i580.smtp2go.com [103.2.142.68]) (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 4NQnBl0Kdbz3lJQ for ; Mon, 5 Dec 2022 15:14:06 +0000 (UTC) (envelope-from bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=smtpservice.net header.s=mgy720.a1-4.dyn header.b=Hr3jXmt+; dkim=pass header.d=fubar.geek.nz header.s=s790814 header.b=fmOGsBwW; spf=pass (mx1.freebsd.org: domain of "bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz" designates 103.2.142.68 as permitted sender) smtp.mailfrom="bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz"; dmarc=pass (policy=none) header.from=fubar.geek.nz DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=mgy720.a1-4.dyn; x=1670254146; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=iMn7UlAV99bCnI7RLFVmzrnZWK/9p2Mm5FfD3mUPq+U=; b=Hr3jXmt+ 76qcz2Hl5xqPpau38nlgpUbfWIyxFPmJOQ6dCGE82SiHMjmP55rPwjuXDNzXQDMrXZkEA3/xxutwU 7PYhyfJmu4OYU6bb7MQkyhc6F0Vtuq9YJLJrzqygPIh8/0hIqRn9J+uOlPnEkAohaHcJqQ904XOp0 ZPJ2Y2Awnyshn6JBAvA0A6CoWeMCtENzBXqu5e92srAftI6E8sOZXyjECvaRZv4C+dPB0rIQ1oZFF TXX+cKLDxYVtcxS0Hx7GATvwG7L6gRSoxIE+vaFYhlvQiCvzpjz7tH+FEacafKythUaCv+sTRuiMJ m87N+8rKmjY0O3A+5T5rk7jTBw==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fubar.geek.nz; i=@fubar.geek.nz; q=dns/txt; s=s790814; t=1670253246; h=from : subject : to : message-id : date; bh=iMn7UlAV99bCnI7RLFVmzrnZWK/9p2Mm5FfD3mUPq+U=; b=fmOGsBwW3fSQWlEisTyE0ELTmh5xumDT1F3+3u66CtpoqU3QWUGXWg6WIzfi1r7zzvpms FvvfjTAB3sHxWXkUDfeCV9SDhxv/oQJ939AHFNi41TfkURjQ/fbQ2VK1tgDTF5I2jJSQExz hm3HgczIjCP4YGT49M6stPev+XsRJItAA+PHinw6Y+li+HXvlhQLv7SGLIh9I3fQ9l1TR9e hH4GmgbblCQBixdiucnrbTL3L0mjPTAW11d37dew5kglh835uNxdpbQosfvWcZfN3+E+loe XL3L5tO2+O6ymdXqx/jckWHZwq6smnOez4ITp1gOknQaqFFuy1Bt1ICQOL9A== Received: from [10.176.58.103] (helo=SmtpCorp) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2-S2G) (envelope-from ) id 1p2DAP-qt4FoL-Lc; Mon, 05 Dec 2022 15:14:01 +0000 Received: from [10.162.55.164] (helo=morbo.fubar.geek.nz) by smtpcorp.com with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96-S2G) (envelope-from ) id 1p2DAP-9ESiyE-1I; Mon, 05 Dec 2022 15:14:01 +0000 Received: from smtpclient.apple (cpc91214-cmbg18-2-0-cust234.5-4.cable.virginm.net [81.102.75.235]) by morbo.fubar.geek.nz (Postfix) with ESMTPSA id 3049C1C57F; Mon, 5 Dec 2022 15:13:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [EXTERNAL] pcib msix allocation in arm64 From: Andrew Turner In-Reply-To: Date: Mon, 5 Dec 2022 15:13:56 +0000 Cc: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <877E8C1E-5CEA-44B6-ABC0-0C54D5B69A58@fubar.geek.nz> References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> To: Souradeep Chakrabarti X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Smtpcorp-Track: 1p2Dje9ESiyE1m.Mtq7ghInHyq7a Feedback-ID: 790814m:790814amQcrys:790814sNwJM4lss3 X-Report-Abuse: Please forward a copy of this message, including all headers, to X-Spamd-Result: default: False [-3.76 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.858]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[fubar.geek.nz,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; FORGED_SENDER(0.30)[andrew@fubar.geek.nz,bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz]; RCVD_IN_DNSWL_MED(-0.20)[103.2.142.68:from]; R_SPF_ALLOW(-0.20)[+ip4:103.2.140.0/22]; R_DKIM_ALLOW(-0.20)[fubar.geek.nz:s=s790814]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_PERMFAIL(0.00)[smtpservice.net:s=mgy720.a1-4.dyn]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:23352, ipnet:103.2.140.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_MIXED(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_NEQ_ENVFROM(0.00)[andrew@fubar.geek.nz,bT.g127yoxc30=wsbnoru7raxx=48uxcsirsf@em790814.fubar.geek.nz]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[smtpservice.net:~,fubar.geek.nz:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[103.2.142.68:from]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NQnBl0Kdbz3lJQ X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N > On 1 Dec 2022, at 11:54, Souradeep Chakrabarti = wrote: >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: Andrew Turner >> Sent: Thursday, November 3, 2022 6:21 PM >> To: Souradeep Chakrabarti >> Cc: Warner Losh ; Wei Hu ; = freebsd- >> hackers@FreeBSD.org >> Subject: Re: [EXTERNAL] pcib msix allocation in arm64 >>=20 >> Hi Souradeep, >>=20 >> For the vmbus_pcib driver you=E2=80=99ll need to implement the = pcib_alloc_msi, >> pcib_release_msi, and the msix versions, and pcib_map_msi. >>=20 >> For alloc and release you can just call into the same intr_* function = as >> pci_host_generic_acpi.c. You=E2=80=99ll need to pass in the xref for = the interrupt controller. >> It needs to be the xref the MSI controller registered. For the GICv2m = it=E2=80=99s >> ACPI_MSI_XREF. > [Souradeep]=20 > I am currently specifying gic_mbi_start and gic_mbi_end with SPI start = and end number, in gic_v3_acpi_attach() and=20 > I can see my intr_alloc_msi() and intr_map_msi() are working. But then = mlx driver is > getting stuck at CREATE_EQ .=20 >=20 > mlx5_core0: WARN: wait_func:967:(pid 0): CREATE_EQ(0x301) timeout. = Will cause a leak of a command resource > mlx5_core0: WARN: mlx5_start_eqs:588:(pid 0): failed to create async = EQ -60 > mlx5_core0: ERR: mlx5_load_one:1157:(pid 0): Failed to start pages and = async EQs > mlx5_core0: WARN: wait_func:967:(pid 0): MANAGE_PAGES(0x108) timeout. = Will cause a leak of a command resource > mlx5_core0: ERR: reclaim_pages:444:(pid 0): failed reclaiming pages > mlx5_core0: WARN: mlx5_reclaim_startup_pages:574:(pid 0): failed = reclaiming pages (-60) > mlx5_core0: ERR: init_one:1644:(pid 0): mlx5_load_one failed -60 >=20 >=20 > gic_v3_acpi_attach( ) > -- > -- > 323 sc->gic_mbi_start =3D 64; > 324 sc->gic_mbi_end =3D 920; > 325 > 326 err =3D gic_v3_attach(dev); > 327 if (err !=3D 0) > 328 goto error; > 329 > 330 sc->gic_pic =3D intr_pic_register(dev, ACPI_INTR_XREF); > 331 if (sc->gic_pic =3D=3D NULL) { > 332 device_printf(dev, "could not register PIC\n"); > 333 err =3D ENXIO; > 334 goto error; > 335 } > 336 err =3D intr_msi_register(dev, ACPI_MSI_XREF); > 337 if (err) { > 338 device_printf(dev, "could not register MSI\n"); > 339 } > 340 if (intr_pic_claim_root(dev, ACPI_INTR_XREF, arm_gic_v3_intr, = sc, > 341 GIC_LAST_SGI - GIC_FIRST_SGI + 1) !=3D 0) { > 342 err =3D ENXIO; > 343 goto error; > 344 } > We don't have SPI range mentioned in ACPI DSDT, so I need to specify = it manually in the code. > It looks like MSI interrupt is not coming to the mlx.=20 > Is there any interrupt remapping blocked by FreeBSD kernel here? Do you see the expected interrupt in arm_gic_v3_intr? If so it would be = useful to trace it though intr_isrc_dispatch. If no it may be because = the interrupt is not being triggered, or is masked. Andrew= From nobody Mon Dec 5 20:26:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NQw7J6t39z4jR8Z for ; Mon, 5 Dec 2022 20:26:36 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on20705.outbound.protection.outlook.com [IPv6:2a01:111:f400:feae::705]) (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 4NQw7J3RcSz3lkx for ; Mon, 5 Dec 2022 20:26:36 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WaSSmHXvtpsgFQSN/yndMOoYlZ6pG92IwyXnX08AVgbuuzYmsG4HqOs7dJ3f1GkAo1c7lDxYxzx6CY5e7Ox5EBg8T3lbeAAnwTI4ZKGYZyc2id0SGus1PzOYprIfMcXr8LQQkf2bR+uh5SR3eCDjFZcJFYYudmQKK3jPK8XeDfkPu8aBuWZxY5+AfBwz+ozY8pbVaL5XkmOUzU3HiU9GvYmrPiJdcBchBCNU3B1+t3yLziVcKZYXd+W1PewcpBNLt4MhH3ES5CvYNBoyrsfSyTUkfUCnY1cFxtNaRbxiMFy/HulncMc8h7LI4+o1Z3ZZtWAWvuH3VMvGyDvvVEFKew== 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=xy11WXt7WNZPS5pwsI7Fj3Ke++K4Tm1DmjZ1wISqsKo=; b=UbqhZb5Guqy7ZsShJDHvhYcqMiOoTIHBg3QhPhM3mcbMpLzo8KTxAKU04QoHcBWYw7tyIhzyq7jkg4Z9/zZqr0V/mgJfY45ISUEjBe+sCN4yBA90fynrmZBp3fkygH/xWSeXJeWRF4fgAjv1FH7+VhWzVl13qkxvHEYX4nPr/5S/t0ZXS5to5nSG18gWW/3+q2/iOttxJ0+VuCKHZZVjZ3prdzAFFMXaaXDGsJ/7SoUW6w1rIWNWsLOSF7MZCDq4d2G/UpjLwTlJjt5AzS+LVqCPLQ2j3+YF2ytJYtZN8ZDa3FLBzEntFqP5998KqGmSFGj063XRn3rVRslZJyPycQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xy11WXt7WNZPS5pwsI7Fj3Ke++K4Tm1DmjZ1wISqsKo=; b=GQuulkeSy/oCPJDKMAxJ9XykkQKIS99+HlT3aVdNq5cgsj3OUswDmwt9ofa7MsPjsnAU4GvuB/Qhi2DIrHqma2Xw0zRaCyNOOXguZqL3Fd+yO6XVRd9DfPw5SL6PhSABv8S1W63p8GHY4qScF6OqXZkDKivLqCU+VhldG+R4QeU= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by PSAP153MB0454.APCP153.PROD.OUTLOOK.COM (2603:1096:301:90::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5924.3; Mon, 5 Dec 2022 20:26:30 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::a551:8649:2ead:ce53%8]) with mapi id 15.20.5924.004; Mon, 5 Dec 2022 20:26:30 +0000 From: Souradeep Chakrabarti To: Andrew Turner CC: Warner Losh , Wei Hu , "freebsd-hackers@FreeBSD.org" Subject: RE: [EXTERNAL] pcib msix allocation in arm64 Thread-Topic: [EXTERNAL] pcib msix allocation in arm64 Thread-Index: AQHY74L1rP0eJIPY3Ee6pTYdK5o1bK5ZC9OggAaNiQCAAFcWsA== Date: Mon, 5 Dec 2022 20:26:29 +0000 Message-ID: References: <146F5D18-6366-4953-A8D9-61FE7EC67F71@fubar.geek.nz> <947DBD67-6443-480F-82DA-2BDDF44C3D03@fubar.geek.nz> <877E8C1E-5CEA-44B6-ABC0-0C54D5B69A58@fubar.geek.nz> In-Reply-To: <877E8C1E-5CEA-44B6-ABC0-0C54D5B69A58@fubar.geek.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9706347d-d18d-419b-ad8f-9ef88a8b3f88;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-12-05T20:25:37Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|PSAP153MB0454:EE_ x-ms-office365-filtering-correlation-id: 3f254d49-977f-488a-4b0a-08dad6fefded x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lbR3ZBawaj7JiZc4uZ17x++zTBL+WB2OHGzjrqxjNZcJB/GvO1PYdncISiu70r5s6kK+hcvgweas5m9O3B2B4uRS/P5LQVcxGhuv+C8pp6Rzm1at1LHWcROFFcPegUlQVLzo42c9SRibVwC1H0eLLlzTDJLaFrCjv1EbSBoQkgf6dT4CKSN1XLZKf4hPY2zLIrVbUhh5ssD8vxtz0wjg2wuH9s6zhGCsEFQO9b/XN/dUpnh0uRoyxbsZ7msIGEJp9d6TX+I0gSG3VujRG12XX380xHjCoyg3EJGuwA0MzGYWfHV+aDEw/HADXYwHi8s/LahsKYgrNx40KoU8jOqbHE2H5POwQ123Q6oNwPFJZF/vMWJlx0+RaboJSycCBfgxJezcHRld+Fg2JTxajPVE3tyDZYdAxblvCD44PH/YwhIHik2V81+Jq7sBP4Z/8oeoW2cABNrQr8ZbqxFqfDImIKHLB8sZ0Vh63wQ0tLLG+Kp19f2/XYIVya4NMtE9vRAeDccdKzDiVYCRVpb1VL5sxOawMy8NGsmh8gHJo+BW/Uhy2sNCLdhOzNVpwy3rGDhaK1FncPnah6cT7vJ/hpkWJaQcQrJQ4rvKntNPD5CXxW2gixB2kpTfh0dMIezi+j3BySr1qKma52/hjXinKyP6xNbmu6Csxh7l+RVsUI7MbD9knpKB54pjkhu+KDIv4/Y+j9BmIy/iSW5f9JUhtu8nVri8s14gjYfgQb/XyNiKQ0bxnbffe77yIeYQ8yRQSajd x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(346002)(366004)(376002)(396003)(136003)(451199015)(76116006)(4326008)(2906002)(8676002)(33656002)(38070700005)(478600001)(38100700002)(55016003)(26005)(53546011)(6506007)(9686003)(71200400001)(66946007)(7696005)(10290500003)(66556008)(66476007)(66446008)(64756008)(8990500004)(122000001)(5660300002)(83380400001)(54906003)(52536014)(8936002)(6916009)(86362001)(41300700001)(316002)(186003)(82950400001)(82960400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VWlOYmozT0hXc2VMb3praHhwQnpGczdiZzhZVTNKRTJqWGsyN0kydHRMUEo5?= =?utf-8?B?NURXYkdZQVU2Z2pNU3IzMkliSHc4cGEyMVdkTkVWNFlhUStuM2RoWWtxWGY5?= =?utf-8?B?YWlPZTRNRFIxUDlZSmZtVW5SKzVqbnR0eGJFUGRFRm5qZXJmdUV4NUxPQjZi?= =?utf-8?B?QW9BUUttNHY5aW1DWVk5Wnh4VkZCTWxTWURmRk9LSVFBZ0xraFFHczNEZEVh?= =?utf-8?B?TkxXZFJpelpPT3JMdTY0cFlFdXlXaDVvU3ZnajRTd24vL0kydCtFZWx0TDQ1?= =?utf-8?B?a25rYXFzelEyakdrd2xIeVU3UlFNdkgwUktBT1VNYW5WSkJBMGptRVRmUGhw?= =?utf-8?B?SUlrMzlwZGV1TjlPeTVNVTVtdUtsU3g3ZWt5aFVwT0x3c1RXUkdEZ2lpSTIz?= =?utf-8?B?SklhUEIrYnBSVnlhd0hFUUovQUpZMW1HRm02ZW1NVUg5b2JnN2hNVnEyeEJB?= =?utf-8?B?OGREOVkxQWZEOWkvZFpCQ1RWZytGcHIyaGJNK0ZjTmlMS1hzYkVVWklaS29j?= =?utf-8?B?TVJxWEM1WlF6VnlyclQybVRITFBtQXBiWkRhU0xQRDl1eWQ5YWk3UFI0QjJX?= =?utf-8?B?aU5tbUVXVmk5MXdoQWhTS3VCcktCd0kyL3R1RWhTaWt0L0R1b3RFWDhqRkto?= =?utf-8?B?TEtWTG1OMGNod0RCaGdZQ0Z5MzBaWDVoUEtTSVFxVEFQZzRKMXp6S2wxeDBE?= =?utf-8?B?dEI2QTZCaTcxQ0dtQ3Q5Skd4SDBOMFVRdzFkc2ljY2s1ZFMvTUpXR3RPc0RP?= =?utf-8?B?VmlESXM5eU01VlVkQkJ5VmVyVEhUMVF0NjNYeC9GTTBOUHdYVkZRTUpWVW80?= =?utf-8?B?eGZjbUlIeGtuNHRxeG4rWDdRcTdlRnVzOVFlSy9SdWExNzhaOVVmRWVscXlC?= =?utf-8?B?YjZRaVdYUVRZUUg2WGo1N3FjbG55cU00SXk3SmdvV0ZJS2MzM2NobEJoNW93?= =?utf-8?B?VTc3U0VhUVhMaHNUNGkwKytJK1NYcWE1aHhqc29iYXhmQVdnVndKNVRmUzhj?= =?utf-8?B?SkpKME5wNUExMzFFV1o5bmxjVXdERDJKcmhianE1NkRldEd4aXZ4ejd4YVFG?= =?utf-8?B?R2dqSm1Gci9YVGt2ZkJJVVEwcHFWQTBUaldRRzdrMThBbzY1L3hTKzNrb3Yv?= =?utf-8?B?QjZZa3dZMzROb0NWZlNSN2t4R0NhUlY4NXhqaCttZkxFbXRYYUlMTHRaOSt2?= =?utf-8?B?RWt3WEYvTHRTd0ZvMitzN1NaZFUrMDFWaEQyc1lJV2JLZU16MDl2a3BNajhy?= =?utf-8?B?Z1V5aWp1V1ByclVxVExCOXlQanlqZWdtZ0drUjhvc2NOclV2bTdYUmE5aUhs?= =?utf-8?B?cVBCWmhXSVp3K1N1OVBIYlFMOGFCSDU1UXpDMGhiRS9vOFliNXIzMXU0WlEx?= =?utf-8?B?a2dtcGxvSUdML2NTS2U0elcraTFBQmI2dXZNd2Y4cFh3YnlQaTMrSEU2WHQ5?= =?utf-8?B?VVdSdU5xVWtKMnp5ckpCNk04dVA3a29UUmFOdXFzbXBCcVVzTG9qOG9mTk9l?= =?utf-8?B?SWV3ekZWcDBSRmZucGJJbFlZblVoUXVuZndrOXkwNktiT0FDVmdkTEt5VzV5?= =?utf-8?B?MTNrSXdsWitHbmtIR2ozdGRnU1Y1R1V4SVg3V3g4bWo0UXdYbTVTTlpmOHIw?= =?utf-8?B?M1VnZUE4M2NFSmtpd1FadEUraWxRMzZqMW54cGNyK0lZTk1ZbnVyMXlLVVZu?= =?utf-8?B?a2RDZE1qL3d0b1NUd3RFYUVCZDV4WksyaSsrN3d3QVFGZUtaK2JUSjZpQmJB?= =?utf-8?B?SHdwenZUakRLWHZiZmJIOFc5R0VoK0Z0N2lXeVdBQlVteTM5ZHVtNVIvT0k3?= =?utf-8?B?UHYwSTM5ZFg1cjdZYkhLaE5TYTF1M2Mwd0QvYW45K0c2Z0sxUWdOTjFaYkcx?= =?utf-8?B?ZWpud0pHcVZmKzNPTEJQR3gvNy9FT1Y1RmhtVDNYV3JncWVxMjBJV2VuRDFl?= =?utf-8?B?VDh2eXp1R1dZSkNLcUVCd2podm1xWjllbGdWWDdLU25Kbk9OZWRCakRtLzkz?= =?utf-8?B?SGxlemRiVmZCSnBtK0ViemlqT0pXZitydG5yYUJEMDIrTWd0bkt5Q1lnMy9x?= =?utf-8?B?VEliREEzdHhWRzMzbE1nd21UVUpEQ09JQXZiQT09?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3f254d49-977f-488a-4b0a-08dad6fefded X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2022 20:26:29.6126 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bHcdTuFXlRldPh27o1nRWLDeBrm0cFlBGNJXdE2Kb0kwga2omSP4to+F4PCk0QMLAsuWiFV9LlzUlY7LUSDmQHbSwoYuW14cHNftTCfLkzA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0454 X-Rspamd-Queue-Id: 4NQw7J3RcSz3lkx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmRyZXcgVHVybmVy IDxhbmRyZXdAZnViYXIuZ2Vlay5uej4NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciA1LCAyMDIy IDg6NDQgUE0NCj4gVG86IFNvdXJhZGVlcCBDaGFrcmFiYXJ0aSA8c2NoYWtyYWJhcnRpQG1pY3Jv c29mdC5jb20+DQo+IENjOiBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+OyBXZWkgSHUgPHdl aEBtaWNyb3NvZnQuY29tPjsgZnJlZWJzZC0NCj4gaGFja2Vyc0BGcmVlQlNELm9yZw0KPiBTdWJq ZWN0OiBSZTogW0VYVEVSTkFMXSBwY2liIG1zaXggYWxsb2NhdGlvbiBpbiBhcm02NA0KPiANCj4g DQo+IA0KPiA+IE9uIDEgRGVjIDIwMjIsIGF0IDExOjU0LCBTb3VyYWRlZXAgQ2hha3JhYmFydGkg PHNjaGFrcmFiYXJ0aUBtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBBbmRyZXcgVHVy bmVyIDxhbmRyZXdAZnViYXIuZ2Vlay5uej4NCj4gPj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVy IDMsIDIwMjIgNjoyMSBQTQ0KPiA+PiBUbzogU291cmFkZWVwIENoYWtyYWJhcnRpIDxzY2hha3Jh YmFydGlAbWljcm9zb2Z0LmNvbT4NCj4gPj4gQ2M6IFdhcm5lciBMb3NoIDxpbXBAYnNkaW1wLmNv bT47IFdlaSBIdSA8d2VoQG1pY3Jvc29mdC5jb20+Ow0KPiA+PiBmcmVlYnNkLSBoYWNrZXJzQEZy ZWVCU0Qub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbRVhURVJOQUxdIHBjaWIgbXNpeCBhbGxvY2F0 aW9uIGluIGFybTY0DQo+ID4+DQo+ID4+IEhpIFNvdXJhZGVlcCwNCj4gPj4NCj4gPj4gRm9yIHRo ZSB2bWJ1c19wY2liIGRyaXZlciB5b3XigJlsbCBuZWVkIHRvIGltcGxlbWVudCB0aGUNCj4gPj4g cGNpYl9hbGxvY19tc2ksIHBjaWJfcmVsZWFzZV9tc2ksIGFuZCB0aGUgbXNpeCB2ZXJzaW9ucywg YW5kIHBjaWJfbWFwX21zaS4NCj4gPj4NCj4gPj4gRm9yIGFsbG9jIGFuZCByZWxlYXNlIHlvdSBj YW4ganVzdCBjYWxsIGludG8gdGhlIHNhbWUgaW50cl8qIGZ1bmN0aW9uDQo+ID4+IGFzIHBjaV9o b3N0X2dlbmVyaWNfYWNwaS5jLiBZb3XigJlsbCBuZWVkIHRvIHBhc3MgaW4gdGhlIHhyZWYgZm9y IHRoZSBpbnRlcnJ1cHQNCj4gY29udHJvbGxlci4NCj4gPj4gSXQgbmVlZHMgdG8gYmUgdGhlIHhy ZWYgdGhlIE1TSSBjb250cm9sbGVyIHJlZ2lzdGVyZWQuIEZvciB0aGUgR0lDdjJtDQo+ID4+IGl0 4oCZcyBBQ1BJX01TSV9YUkVGLg0KPiA+IFtTb3VyYWRlZXBdDQo+ID4gSSBhbSBjdXJyZW50bHkg c3BlY2lmeWluZyBnaWNfbWJpX3N0YXJ0IGFuZCBnaWNfbWJpX2VuZCB3aXRoIFNQSSBzdGFydA0K PiA+IGFuZCBlbmQgbnVtYmVyLCBpbiBnaWNfdjNfYWNwaV9hdHRhY2goKSBhbmQgSSBjYW4gc2Vl IG15DQo+ID4gaW50cl9hbGxvY19tc2koKSBhbmQgaW50cl9tYXBfbXNpKCkgYXJlIHdvcmtpbmcu IEJ1dCB0aGVuIG1seCBkcml2ZXIgaXMgZ2V0dGluZw0KPiBzdHVjayBhdCBDUkVBVEVfRVEgLg0K PiA+DQo+ID4gbWx4NV9jb3JlMDogV0FSTjogd2FpdF9mdW5jOjk2NzoocGlkIDApOiBDUkVBVEVf RVEoMHgzMDEpIHRpbWVvdXQuDQo+ID4gV2lsbCBjYXVzZSBhIGxlYWsgb2YgYSBjb21tYW5kIHJl c291cmNlDQo+ID4gbWx4NV9jb3JlMDogV0FSTjogbWx4NV9zdGFydF9lcXM6NTg4OihwaWQgMCk6 IGZhaWxlZCB0byBjcmVhdGUgYXN5bmMNCj4gPiBFUSAtNjANCj4gPiBtbHg1X2NvcmUwOiBFUlI6 IG1seDVfbG9hZF9vbmU6MTE1NzoocGlkIDApOiBGYWlsZWQgdG8gc3RhcnQgcGFnZXMgYW5kDQo+ ID4gYXN5bmMgRVFzDQo+ID4gbWx4NV9jb3JlMDogV0FSTjogd2FpdF9mdW5jOjk2NzoocGlkIDAp OiBNQU5BR0VfUEFHRVMoMHgxMDgpIHRpbWVvdXQuDQo+ID4gV2lsbCBjYXVzZSBhIGxlYWsgb2Yg YSBjb21tYW5kIHJlc291cmNlDQo+ID4gbWx4NV9jb3JlMDogRVJSOiByZWNsYWltX3BhZ2VzOjQ0 NDoocGlkIDApOiBmYWlsZWQgcmVjbGFpbWluZyBwYWdlcw0KPiA+IG1seDVfY29yZTA6IFdBUk46 IG1seDVfcmVjbGFpbV9zdGFydHVwX3BhZ2VzOjU3NDoocGlkIDApOiBmYWlsZWQNCj4gPiByZWNs YWltaW5nIHBhZ2VzICgtNjApDQo+ID4gbWx4NV9jb3JlMDogRVJSOiBpbml0X29uZToxNjQ0Oihw aWQgMCk6IG1seDVfbG9hZF9vbmUgZmFpbGVkIC02MA0KPiA+DQo+ID4NCj4gPiBnaWNfdjNfYWNw aV9hdHRhY2goICkNCj4gPiAtLQ0KPiA+IC0tDQo+ID4gMzIzICAgICBzYy0+Z2ljX21iaV9zdGFy dCA9IDY0Ow0KPiA+IDMyNCAgICAgc2MtPmdpY19tYmlfZW5kID0gOTIwOw0KPiA+IDMyNQ0KPiA+ IDMyNiAgICAgZXJyID0gZ2ljX3YzX2F0dGFjaChkZXYpOw0KPiA+IDMyNyAgICAgaWYgKGVyciAh PSAwKQ0KPiA+IDMyOCAgICAgICAgIGdvdG8gZXJyb3I7DQo+ID4gMzI5DQo+ID4gMzMwICAgICBz Yy0+Z2ljX3BpYyA9IGludHJfcGljX3JlZ2lzdGVyKGRldiwgQUNQSV9JTlRSX1hSRUYpOw0KPiA+ IDMzMSAgICAgaWYgKHNjLT5naWNfcGljID09IE5VTEwpIHsNCj4gPiAzMzIgICAgICAgICBkZXZp Y2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCByZWdpc3RlciBQSUNcbiIpOw0KPiA+IDMzMyAgICAg ICAgIGVyciA9IEVOWElPOw0KPiA+IDMzNCAgICAgICAgIGdvdG8gZXJyb3I7DQo+ID4gMzM1ICAg ICB9DQo+ID4gMzM2ICAgICBlcnIgPSBpbnRyX21zaV9yZWdpc3RlcihkZXYsIEFDUElfTVNJX1hS RUYpOw0KPiA+IDMzNyAgICAgaWYgKGVycikgew0KPiA+IDMzOCAgICAgICAgIGRldmljZV9wcmlu dGYoZGV2LCAiY291bGQgbm90IHJlZ2lzdGVyIE1TSVxuIik7DQo+ID4gMzM5ICAgICB9DQo+ID4g MzQwICAgICBpZiAoaW50cl9waWNfY2xhaW1fcm9vdChkZXYsIEFDUElfSU5UUl9YUkVGLCBhcm1f Z2ljX3YzX2ludHIsIHNjLA0KPiA+IDM0MSAgICAgICAgIEdJQ19MQVNUX1NHSSAtIEdJQ19GSVJT VF9TR0kgKyAxKSAhPSAwKSB7DQo+ID4gMzQyICAgICAgICAgZXJyID0gRU5YSU87DQo+ID4gMzQz ICAgICAgICAgZ290byBlcnJvcjsNCj4gPiAzNDQgICAgIH0NCj4gPiBXZSBkb24ndCBoYXZlIFNQ SSByYW5nZSBtZW50aW9uZWQgaW4gQUNQSSBEU0RULCBzbyBJIG5lZWQgdG8gc3BlY2lmeSBpdA0K PiBtYW51YWxseSBpbiB0aGUgY29kZS4NCj4gPiBJdCBsb29rcyBsaWtlIE1TSSBpbnRlcnJ1cHQg aXMgbm90IGNvbWluZyB0byB0aGUgbWx4Lg0KPiA+IElzIHRoZXJlIGFueSBpbnRlcnJ1cHQgcmVt YXBwaW5nIGJsb2NrZWQgYnkgRnJlZUJTRCBrZXJuZWwgaGVyZT8NCj4gDQo+IERvIHlvdSBzZWUg dGhlIGV4cGVjdGVkIGludGVycnVwdCBpbiBhcm1fZ2ljX3YzX2ludHI/IElmIHNvIGl0IHdvdWxk IGJlIHVzZWZ1bCB0bw0KPiB0cmFjZSBpdCB0aG91Z2ggaW50cl9pc3JjX2Rpc3BhdGNoLiBJZiBu byBpdCBtYXkgYmUgYmVjYXVzZSB0aGUgaW50ZXJydXB0IGlzIG5vdA0KPiBiZWluZyB0cmlnZ2Vy ZWQsIG9yIGlzIG1hc2tlZC4NCltTb3VyYWRlZXBdIA0KVGhhbmtzIGZvciB0aGUgaGVscC4gTG9v a3MgbGlrZSB0aGUgcHJvYmxlbSBpcyBmcm9tIHRoZSBoYXJkd2FyZSBzaWRlLCBub3QgZnJvbSBP UyBzaWRlLg0KSXQgc2VlbXMgdG8gYmUgd29ya2luZyBpbiBBenVyZS4gDQo+IA0KPiBBbmRyZXcN Cg== From nobody Tue Dec 6 04:27:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NR6nz0qyYz4jgtv for ; Tue, 6 Dec 2022 04:27:19 +0000 (UTC) (envelope-from yonas.yanfa@gmail.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NR6ny1Pbxz3MNL for ; Tue, 6 Dec 2022 04:27:18 +0000 (UTC) (envelope-from yonas.yanfa@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=hskPIZ+e; spf=pass (mx1.freebsd.org: domain of yonas.yanfa@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=yonas.yanfa@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62e.google.com with SMTP id m18so1776645eji.5 for ; Mon, 05 Dec 2022 20:27:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=HJfE8aQ+KFisCNb7x0TMDbpI4snMLAaNqaEcYzcrgCM=; b=hskPIZ+enSOEqgQhVgvHnV/bOZ5UvDBY9Ndy1Pmj9R/vmdf3exrEFkHl8iUSeqoe8Y 8jBBZiNv771jxRU6BlrhLucP65R1hKG445XzzwebKIfxQfNHIdc48Y0+ik7bo847niEo O35YFTpMFofsIvZ9lWW2Z/l3tWlBTe3N6fQewh/sQnGmlC9xEUfDsClaKrR8Ix0wN2HP 4r7a6lwTS+uRmGTMR8jYgo5oydPZaCzD3eHqai5JMqYmz2OeW5mHR8l7+kcXyAeqY7U0 KvMpcMha9WmvO+RPCDZ3pfM5xf/IHwzigfnZIsvzVp1TiL7H1Jv0P67IXDm6fld3n/IF ifJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=HJfE8aQ+KFisCNb7x0TMDbpI4snMLAaNqaEcYzcrgCM=; b=KNIgq8MVKiMXH1l9uAMmWo1PTOfazBsyRObU0N90HboIVBtacBydrPVz+hjYluQrj6 tgXcMN/A/ks2ATxs/jOZPyGmrsq9PlA7gTjgEFS2CRA9O/9nszpJaFscujSFLBNdPUx2 RfOIZuEGwrkOL/blX9vko0HvOesZUDaE3CXX7RJPWcrRfZVxdeE82TW+lVUqv/en6cpV agzg++ffIxOrB/Br+PVlUfgr460fX8mX/Z73ci72TxB+KkNfAOWlPWzjTzYGFkQU8ajP Aq4Di83nYiuPf1bXNs0aA4sJdJiYNsbb7MxEZUxv/4HQwEmXrSJCo6tMUlyB/x1Pels6 nPbQ== X-Gm-Message-State: ANoB5pkh/olSrlemQ3uGRCCyWsxM0fcuS22ePJqRwMWUlei3TbIbuCva AhUxYpHLRATcwrpYvyK/GHObqh9Z4CuP+Q== X-Google-Smtp-Source: AA0mqf6BDfHT81gOqSaX1uom4h8sUSQOFTGfmRSNAjHIU5Hk329lIQrhkdnXDi1EcdfTqWSmLytDMw== X-Received: by 2002:a17:906:4bcc:b0:7be:6ab8:4ccc with SMTP id x12-20020a1709064bcc00b007be6ab84cccmr36083224ejv.713.1670300835705; Mon, 05 Dec 2022 20:27:15 -0800 (PST) Received: from [10.16.0.5] (93-190-138-166.hosted-by-worldstream.net. [93.190.138.166]) by smtp.gmail.com with ESMTPSA id u10-20020a170906c40a00b007c0cd272a06sm4239215ejz.225.2022.12.05.20.27.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Dec 2022 20:27:15 -0800 (PST) Message-ID: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> Date: Mon, 5 Dec 2022 23:27:13 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 To: freebsd-hackers@FreeBSD.org Content-Language: en-US From: Yonas Yanfa Subject: Add BLAKE3 hash to ISO checksums Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.89)[-0.888]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62e:from]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4NR6ny1Pbxz3MNL X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi, Can we please add BLAKE3 hashes to https://www.freebsd.org/releases/13.1R/signatures ? On first run, BLAKE3 runs at the same speed as SHA-512. On my system, the second run is 17x faster. I recommend using https://crates.io/crates/b3sum $ for hash in b3sum sha256sum sha512sum ; time $hash FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in    5.05 secs      fish           external    usr time  834.12 millis    4.53 millis  829.58 millis    sys time  666.34 millis    0.44 millis  665.90 millis 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in    7.46 secs    fish           external    usr time    7.13 secs  287.00 micros    7.13 secs    sys time    0.31 secs  146.00 micros    0.31 secs 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in    4.84 secs    fish           external    usr time    4.61 secs  274.00 micros    4.61 secs    sys time    0.18 secs  140.00 micros    0.18 secs $ for hash in b3sum sha256sum sha512sum ; time $hash FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in  280.16 millis    fish           external    usr time  852.65 millis  316.00 micros  852.34 millis    sys time   86.98 millis  166.00 micros   86.81 millis 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in    7.39 secs    fish           external    usr time    7.17 secs  343.00 micros    7.17 secs    sys time    0.21 secs  181.00 micros    0.21 secs 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 FreeBSD-13.1-RELEASE-amd64-disc1.iso ________________________________________________________ Executed in    4.84 secs    fish           external    usr time    4.57 secs  363.00 micros    4.57 secs    sys time    0.23 secs  192.00 micros    0.23 secs Cheers, Yonas From nobody Tue Dec 6 05:18:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NR8cf2MP6z4jsrT for ; Tue, 6 Dec 2022 05:49:22 +0000 (UTC) (envelope-from takawata@sana.init-main.com) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) (using TLSv1.3 with cipher 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 "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NR8cd2pxwz3lJ4 for ; Tue, 6 Dec 2022 05:49:18 +0000 (UTC) (envelope-from takawata@sana.init-main.com) Authentication-Results: mx1.freebsd.org; none Received: from sana.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.16.1/8.16.1) with ESMTPS id 2B65IV5l083919 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 6 Dec 2022 14:18:31 +0900 (JST) (envelope-from takawata@sana.init-main.com) Received: (from takawata@localhost) by sana.init-main.com (8.16.1/8.16.1/Submit) id 2B65IVrf083918; Tue, 6 Dec 2022 14:18:31 +0900 (JST) (envelope-from takawata) Date: Tue, 6 Dec 2022 14:18:31 +0900 From: Takanori Watanabe To: Pat Maddox , freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Message-ID: References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> X-Rspamd-Queue-Id: 4NR8cd2pxwz3lJ4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:2497, ipnet:210.138.0.0/16, country:JP] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: > On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: > > >> > >> I have a newly-built system with an ASUS Prime Z590M-Plus and Intel > >> 10900k > >> with onboard graphics (UHD 630, according to intel). > >> > >> I specifically chose a 10th gen processor because I believed it was > >> well- > >> supported by 13.1+. Unfortunately I can’t even install 13.1 > >> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant- > >> install-i-just-get-a-little-white-box-and-a-mouse- > >> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd > >> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) > >> > >> I have successfully installed > >> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. > >> > >> When I run `kldload i915kms`, the screen just goes black. > >> > >> I have never used graphics before on FreeBSD, so I’m not sure where > >> to > >> begin diagnosing. I did as much research as I could upfront, but have > >> run into > >> this obstacle. > >> > >> I’ll be content to run 14.0-CURRENT because I can still create 13.1 > >> jails. How about logging in from remote and load kernel module? This is my example. https://github.com/freebsd/drm-kmod/issues/159 From nobody Tue Dec 6 06:18:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NR9G32Nwdz4jxCn for ; Tue, 6 Dec 2022 06:18:19 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NR9G22VXqz3p4Z for ; Tue, 6 Dec 2022 06:18:18 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 62BA83200A09; Tue, 6 Dec 2022 01:18:16 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 06 Dec 2022 01:18:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670307495; x= 1670393895; bh=X224PaVM/dEtumZj4N0BnniZUdWYM8VR4XLUEI3MP+I=; b=R k7JfYabdPILYfVOVdB+PCiwl4KvPow2kKoX6T3Zp83uw4Hz88b7nAbhes1C8qzk7 zzZs73JTjZaPuWkjlFnZ1C/gNYg6VW8r/Hsw9jFqcZLCmBFhrUUk/6z/FmnsfglN niO8R8qFQsCNm+bg8ObDiRxsGT2NHbzff7cwbxAy2JeWSGBFn0T8Op1SgCVqN6lI ul+S9cWIsly3ZD3Kv4RYZoFpbyfb5wST6Dv+u3LFL033yCE/5PYdN7ldJcPkwhZu P77G2poYOImdnj0O9rwgjygQSTJZ9OrTDtBbqHYaniCJZrjwngYGZlH5p3rmC1hm 9qlaGo+8oVESLqHu5syrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670307495; x= 1670393895; bh=X224PaVM/dEtumZj4N0BnniZUdWYM8VR4XLUEI3MP+I=; b=N yYFD4B/0G6Bn8L1lwwf6B4yCfhATyoOE2pS8iBXjbYq9qyVAcX77zXYUDrE9raBD IMDuVJUag0cyvG3732jyK5TMYqlHPl0QlYOUwlo/N41qciQn5dSWQmaha8N/sv7y nhvnT/1PjZq/8QSGK5MvOqrsZf+oxfLI1eQFXaydNpd930+sSicgwQNC+KeyixqX U4PpB+Ac/6YMPshk7bMLN7/BimXIZnVDxaVtPnTkE59K2oOFDQo9icsuxvGHG7zq 9hyrTAge3ksTjTelhB2p+Mkw4oZiUD6Xkxsj8nPq4q+LsjePVjvglZiEE/U6gPRu Hvj9382LtEUg899Hu/6aQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffoffkjghfgggtgfesthekmhdtredtjeenucfhrhhomhepfdfrrght ucforgguughogidfuceophgrthesphgrthhmrgguughogidrtghomheqnecuggftrfgrth htvghrnhephfejgfdtjedvtdekkeelleeguefhledtfeettdefueffvedvkefggffhleff hfehnecuffhomhgrihhnpehurhhluggvfhgvnhhsvgdrtghomhdpfhhrvggvsghsugdroh hrghdpghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepphgrthesphgrthhmrgguughogidrtghomh X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Dec 2022 01:18:15 -0500 (EST) From: "Pat Maddox" To: "Takanori Watanabe" Cc: freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Date: Mon, 05 Dec 2022 22:18:13 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> In-Reply-To: References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4NR9G22VXqz3p4Z X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5 Dec 2022, at 21:18, Takanori Watanabe wrote: > On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: >> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: >> >>>> >>>> I have a newly-built system with an ASUS Prime Z590M-Plus and Intel >>>> 10900k >>>> with onboard graphics (UHD 630, according to intel). >>>> >>>> I specifically chose a 10th gen processor because I believed it was >>>> well- >>>> supported by 13.1+. Unfortunately I can’t even install 13.1 >>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant- >>>> install-i-just-get-a-little-white-box-and-a-mouse- >>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd >>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) >>>> >>>> I have successfully installed >>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. >>>> >>>> When I run `kldload i915kms`, the screen just goes black. >>>> >>>> I have never used graphics before on FreeBSD, so I’m not sure >>>> where >>>> to >>>> begin diagnosing. I did as much research as I could upfront, but >>>> have >>>> run into >>>> this obstacle. >>>> >>>> I’ll be content to run 14.0-CURRENT because I can still create >>>> 13.1 >>>> jails. > > How about logging in from remote and load kernel module? > This is my example. > https://github.com/freebsd/drm-kmod/issues/159 When I do that, the screen still goes black, but kldload does return in my remote terminal. This is in /var/log/messages: https://gist.github.com/patmaddox/1a2b7bb8769cf1251beb514a9646a69e From nobody Tue Dec 6 07:08:40 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRBNF4Rl1z4k4M0 for ; Tue, 6 Dec 2022 07:08:45 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRBND6TY0z400x for ; Tue, 6 Dec 2022 07:08:44 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=patmaddox.com header.s=fm3 header.b="c cP5Uoq"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="f PE3YvO"; spf=pass (mx1.freebsd.org: domain of pat@patmaddox.com designates 64.147.123.24 as permitted sender) smtp.mailfrom=pat@patmaddox.com; dmarc=none Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 872C93200918; Tue, 6 Dec 2022 02:08:43 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 06 Dec 2022 02:08:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670310523; x= 1670396923; bh=RwVMM8lrCzOKSxU/2yyAoUffeH49/vPhJNB3K/zOhHo=; b=c cP5Uoqa+aDbqN81wd0R3TwA9MkMOvnzlbeIuhCtnVaQFbprnS4SKrde1Tf+axvdm U/8UZeo3EAf7R+FEobDn22+oxy9Pqz+E3+dFwcNknsU+MwYUDgTQfB/HcvmlCNr2 iGbfdjyOZ/HTleUQFWOMjzL6pUjO6/culfwYO6XvPHLiEpPSyU/jMdRyQe6sLS27 yP1LBGS+QHLgDC19T8aNND4qSjTNQivaF5nuQYZafh153o6fMCxo8mZhmNNkU6yF 1QafezklUN6G5HipvJaLozYi1gQCIw5VvfwrKJ/2g9ln1bTtpRV+K9tSuRjDHUJY nc0OaHplD6OgvzVBPBIWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670310523; x= 1670396923; bh=RwVMM8lrCzOKSxU/2yyAoUffeH49/vPhJNB3K/zOhHo=; b=f PE3YvOXkZtam4VpBCAcAEGR3FtFtkpTavxIWxUYcfq7G9h0oIww66/Sq1+N8laQG Fz52Md2Buend5ZVrRZem9/oosBmrflRlVL5xDHEH5UjeYVXMNOeqvZEWIBqXOIpR dCMdRW7ssbWoG1Uu0y9eVamPvpKAkqH087LMSiHkllKJdmCpRLXneBjR84f/aOPg jJxiC/dHbUokVM8qFdWBRpn18FlFUOgluMgIiMVrxnhjWkZaFOJGp0ZmSwtyHyUd ZfrbYpj/sut9eVaVxxNrqyVkTFtmJNuvzgtuQ+3NAmBAHBKjWautMFIs0bB0DjTq 6YaTnslBaTnuMBk11hvsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffokfgjfhggtgfgsehtqhhmtdertdejnecuhfhrohhmpedfrfgr thcuofgrugguohigfdcuoehprghtsehprghtmhgrugguohigrdgtohhmqeenucggtffrrg htthgvrhhnpeehgedtveeggfdtfedvveekieejfeefieeggedvudfhfeeluddvueegfeet iedvvdenucffohhmrghinhepuhhrlhguvghfvghnshgvrdgtohhmpdhfrhgvvggsshgurd horhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehprghtsehprghtmhgrugguohigrdgtohhm X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Dec 2022 02:08:42 -0500 (EST) From: "Pat Maddox" To: "Takanori Watanabe" Cc: freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Date: Mon, 05 Dec 2022 23:08:40 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> In-Reply-To: <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-4.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[patmaddox.com:s=fm3,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.24]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.24:from]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[patmaddox.com]; FREEFALL_USER(0.00)[pat]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[patmaddox.com:+,messagingengine.com:+]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.24:from] X-Rspamd-Queue-Id: 4NRBND6TY0z400x X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N On 5 Dec 2022, at 22:18, Pat Maddox wrote: > On 5 Dec 2022, at 21:18, Takanori Watanabe wrote: > >> On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: >>> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: >>> >>>>> >>>>> I have a newly-built system with an ASUS Prime Z590M-Plus and = >>>>> Intel >>>>> 10900k >>>>> with onboard graphics (UHD 630, according to intel). >>>>> >>>>> I specifically chose a 10th gen processor because I believed it = >>>>> was >>>>> well- >>>>> supported by 13.1+. Unfortunately I can=E2=80=99t even install 13.1= >>>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/can= t- >>>>> install-i-just-get-a-little-white-box-and-a-mouse- >>>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd= >>>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) >>>>> >>>>> I have successfully installed >>>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. >>>>> >>>>> When I run `kldload i915kms`, the screen just goes black. >>>>> >>>>> I have never used graphics before on FreeBSD, so I=E2=80=99m not su= re = >>>>> where >>>>> to >>>>> begin diagnosing. I did as much research as I could upfront, but = >>>>> have >>>>> run into >>>>> this obstacle. >>>>> >>>>> I=E2=80=99ll be content to run 14.0-CURRENT because I can still cre= ate = >>>>> 13.1 >>>>> jails. >> >> How about logging in from remote and load kernel module? >> This is my example. >> https://github.com/freebsd/drm-kmod/issues/159 > > When I do that, the screen still goes black, but kldload does return = > in my remote terminal. This is in /var/log/messages: = > https://gist.github.com/patmaddox/1a2b7bb8769cf1251beb514a9646a69e Well, I don=E2=80=99t know if this has anything to do with anything, but = when = I run `pkg install drm-kmod` it lists all of these intel bits: gpu-firmware-intel-kmod-broxton: 20220511 gpu-firmware-intel-kmod-coffeelake: 20220511 gpu-firmware-intel-kmod-elkhartlake: 20220511 gpu-firmware-intel-kmod-geminilake: 20220511 gpu-firmware-intel-kmod-icelake: 20220511 gpu-firmware-intel-kmod-kabylake: 20220511 gpu-firmware-intel-kmod-rocketlake: 20220511 gpu-firmware-intel-kmod-skylake: 20220511 gpu-firmware-intel-kmod-tigerlake: 20220511 My 10th gen i9 is a =E2=80=9Ccomet lake=E2=80=9D - not in the list. I=E2=80= =99m not sure = if it should be covered by a different one, but it is interesting that = it=E2=80=99s absent. drm-kmod has a bunch of references to cometlake: = https://github.com/freebsd/drm-kmod/search?q=3Dcometlake But drm-kmod-firmware does not: = https://github.com/freebsd/drm-kmod-firmware/search?q=3Dcometlake I did make an effort to support a cometlake flavor: = https://github.com/patmaddox/drm-kmod-firmware/commit/20570f61ee927e19d5f= d6303f94eac00aa2f3bfd But it didn=E2=80=99t work, which is no surprise, because I have no idea = what = I=E2=80=99m doing when it comes to kernel drivers. Does the fact that cometlake is absent from the list mean 1) it was an = oversight 2) it=E2=80=99s not supported 3) nothing at all? Pat From nobody Tue Dec 6 07:16:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRBY202YWz4k4yt for ; Tue, 6 Dec 2022 07:16:22 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRBY14qV0z41HX for ; Tue, 6 Dec 2022 07:16:21 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf30.google.com with SMTP id s14so9837092qvo.11 for ; Mon, 05 Dec 2022 23:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JTr7LjKVBriwz71YhKv3Rx/VODp0vMCKlWceiI0X7LA=; b=NagmXwCCq5LOd7vaXAiQL6We/340kJKJCOa/Nhbuk9U6GImuu7YvkeAUgFexs/o2LN 5NM7pBUV3tCLnAlPJatXSM1MARgPCjkAmZT+3Tv8PvR1do3NMglXtTwi2IdTHXpBCxp9 v8zyIQSPxHvG15KVSfMF/RCQr9h8QSFW4daViNvb9cPwwdTBv/quop/x4L8gEgCjQIrN n30s+qf0yC0hnCvcSqHviiEs9uEOowEz5gsSvzMJgqJmYear0qTG7epvXPt6okpQQuff vj19j3Xbl8qL/siyykWh1dc35+B6C9S5gv2j2p6/g8IucdELg5K+1qTKeAnW18ZFExqo 1Y7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JTr7LjKVBriwz71YhKv3Rx/VODp0vMCKlWceiI0X7LA=; b=A53zGUCSaHtLDyTQdKsI/8XY0hd9KAhLEsAKZam14ZHHGPN2ehiGz8Ry3A0AHj4lzv rWK2ZDHZxG4ZO2ujOgQK5aH1sPdscfCM9CaEbSlJpJzKcUehosSXE2E1VstQrM9yLzuC 2jcGThFQv4TDPqb7J1OuBA+uPbB/ErRrQx5n+Yj6O3AiA6n8HR3kpkpPO1AGpeAj6ayJ bytJ9leV2C/QM9OZ979az9elKP/dHX1zrmuxJ4FxeslQOpshRMyhc+Cd1v0xXgU531RN wBi6sdQkFL16omiyXs0t0umE1XzOF84V9QPDSFE5Vae7091tfryRG00/UadZyOKp1P/d reXg== X-Gm-Message-State: ANoB5pkK/ev7CgLIwS0HfdpjeHWpmFrFf7tGbTIXeEO9ir2wcBGiGwZN 2NZxJnAXv1NhEuhCSvs3Zm+L+0KkIEaW4T6C X-Google-Smtp-Source: AA0mqf47gXx1+cin2O2r2BGLjpdpRnw5Xig4c2d9o+EYyD6+4+y0nlJ0zAw1Hra9wx7ihUGSph6lXQ== X-Received: by 2002:a05:6214:1046:b0:4c7:9c7:e6a9 with SMTP id l6-20020a056214104600b004c709c7e6a9mr30736483qvr.96.1670310980457; Mon, 05 Dec 2022 23:16:20 -0800 (PST) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id q23-20020a37f717000000b006cbc00db595sm13648733qkj.23.2022.12.05.23.16.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Dec 2022 23:16:19 -0800 (PST) Received: by mail-yb1-f175.google.com with SMTP id y135so12953558yby.12 for ; Mon, 05 Dec 2022 23:16:19 -0800 (PST) X-Received: by 2002:a25:dac5:0:b0:6f2:8dd5:da7e with SMTP id n188-20020a25dac5000000b006f28dd5da7emr50132658ybf.330.1670310979344; Mon, 05 Dec 2022 23:16:19 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> In-Reply-To: <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> From: Tomek CEDRO Date: Tue, 6 Dec 2022 08:16:07 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: kldload i915kms screen goes black To: Pat Maddox Cc: Takanori Watanabe , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4NRBY14qV0z41HX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Dec 5 22:14:30 beastie14 kernel: drmn drmn0: drm_WARN_ON(!IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) && !IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)) Dec 5 22:14:30 beastie14 kernel: Dec 5 22:14:30 beastie14 kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). Dec 5 22:14:30 beastie14 kernel: [drm] Got stolen memory base 0x0, size 0x0 Dec 5 22:14:30 beastie14 kernel: drmn0: could not load firmware image 'i915/kbl_dmc_ver1_04.bin' Dec 5 22:14:30 beastie14 kernel: drmn0: [drm] Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. At first glance it looks there is no support yet for this chipset.. detection and firmware upload fails.. it needs to be added.. at least in the FreeBSD port or even the Linux upstream? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Tue Dec 6 07:25:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRBmB1K3mz4k61R for ; Tue, 6 Dec 2022 07:26:02 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRBmB0B2Hz42wM for ; Tue, 6 Dec 2022 07:26:02 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; none Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id D7D0F32009F8; Tue, 6 Dec 2022 02:25:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 06 Dec 2022 02:26:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670311559; x= 1670397959; bh=HQhI/2/0DrzyGQngb8hJsRqaaMwosrL2bDLPu2qMAjw=; b=v MLMqI/mjwl+OEZ7KNAMhjMmPGUYh7eirsxEYAEaEkBmNlYcvO3nakhd7c24w51JR jmPVN+sryAfjVKww7SEnfikoQyGmv7BJIg+96V4iRWhXApzyL2sDoxCxz9sU+jRG Nzpg4H7U67hLIeJ94E74ShR4+SxJz+7uZFJkHzdTgMhEjLSRoi/IDe6o4pqj2Mdi 8zEqbbeWxpbJXojuOq5TYBUmxbnOCQP5GajpnWFmcRLigd9NBRaaLSmGvRZe3Ttb i1IjsAYaqNMHNq8ExAPo4i2kcGt+Bg8Kwy3ZDiBqEpBbE5Mzl/eyuUdjyl23EnSC MaPzMrPEnynseKnuZOgwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670311559; x= 1670397959; bh=HQhI/2/0DrzyGQngb8hJsRqaaMwosrL2bDLPu2qMAjw=; b=e dxJSWVX6WkmB9KBJkNdMYuhqxkYLHWTF7lYUIUXPP1s+CDbCucZRtYZ+UcAkjWVm mJPjDse7cUzvl8p7oA9jEUBHHM5G111K5X8vFx2lFGGqOy0PoDFMXAfhPU8PBDS6 YGCPbxGH+/xzz/diPUy5QbdfYLWQLNHUyoRz3PHxqQSqDizTXX4B49jseN+KlLuI LFKvKpGEEqUsOR/7CEKdg6x3HkMwh4htYpSkP5gb68MPLjygQjT7WN2lluGKPYgB MUAgh5e+4kqaWsxF43EcvbS1gW/CLQUwhSLijJbFdSztSEd3k1VqwVSGpU39i9FX fY51sYHOU/Z40SrxpIKlA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffokfgjfhggtgfgsehtqhhmtdertdejnecuhfhrohhmpedfrfgr thcuofgrugguohigfdcuoehprghtsehprghtmhgrugguohigrdgtohhmqeenucggtffrrg htthgvrhhnpefhveektdefgeefvdeutdeivddtvdekgffggeeffedtteegleegiefhtdeu uefhgeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhphhhorhhonhhigidrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehprght sehprghtmhgrugguohigrdgtohhm X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Dec 2022 02:25:58 -0500 (EST) From: "Pat Maddox" To: "Tomek CEDRO" Cc: "Takanori Watanabe" , freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Date: Mon, 05 Dec 2022 23:25:56 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <39466BCD-265A-43B5-BC04-D21AD54FE459@patmaddox.com> In-Reply-To: References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NRBmB0B2Hz42wM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5 Dec 2022, at 23:16, Tomek CEDRO wrote: > Dec 5 22:14:30 beastie14 kernel: drmn drmn0: > drm_WARN_ON(!IS_PLATFORM(dev_priv, INTEL_TIGERLAKE) && > !IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)) > Dec 5 22:14:30 beastie14 kernel: > Dec 5 22:14:30 beastie14 kernel: [drm] Unable to create a private > tmpfs mount, hugepage support will be disabled(-19). > Dec 5 22:14:30 beastie14 kernel: [drm] Got stolen memory base 0x0, = > size 0x0 > Dec 5 22:14:30 beastie14 kernel: drmn0: could not load firmware image > 'i915/kbl_dmc_ver1_04.bin' > Dec 5 22:14:30 beastie14 kernel: drmn0: [drm] Failed to load DMC > firmware i915/kbl_dmc_ver1_04.bin. Disabling runtime power management. > > At first glance it looks there is no support yet for this chipset.. > detection and firmware upload fails.. it needs to be added.. at least > in the FreeBSD port or even the Linux upstream? I think it would need to be in the port (here=E2=80=99s my misguided effo= rt: = https://github.com/patmaddox/drm-kmod-firmware/commit/20570f61ee927e19d5f= d6303f94eac00aa2f3bfd) It appears that comet lake has been in linux upstream for a few years: = https://www.phoronix.com/news/Intel-Comet-Lake-Linux-Add Pat From nobody Tue Dec 6 07:48:06 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRCFm6fqGz4k8t7 for ; Tue, 6 Dec 2022 07:48:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRCFm3FZmz46P5 for ; Tue, 6 Dec 2022 07:48:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1670312890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T4LLdsoMBjj+O9uOl5jkV5zTKVWQ5lIbrNQGG8+egg4=; b=Srsy9sjAuaByn22oLQf0LAbFhlBBi2ceAiAN6van1Rd+LOfDvSA+bdOGf/lZiUN9yeAF5I KJVtz0c+BoYp53GNA2qFwtY7uxZfbjHPSnUzqOAq9z7isob+cT1SdHK7c1x0F1AThrkRGK Gyw0pmIm/PCa4/h6Wht+OQlx+Ic4BuY= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 6fedb759 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 6 Dec 2022 07:48:10 +0000 (UTC) Date: Tue, 6 Dec 2022 08:48:06 +0100 From: Emmanuel Vadot To: "Pat Maddox" Cc: "Takanori Watanabe" , freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Message-Id: <20221206084806.ce2f32457cc27eed15f09648@bidouilliste.com> In-Reply-To: <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> <553FF6AA-4786-4DEA-9C4B-B2F28914BF72@patmaddox.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NRCFm3FZmz46P5 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, 05 Dec 2022 23:08:40 -0800 "Pat Maddox" wrote: > On 5 Dec 2022, at 22:18, Pat Maddox wrote: >=20 > > On 5 Dec 2022, at 21:18, Takanori Watanabe wrote: > > > >> On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: > >>> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: > >>> > >>>>> > >>>>> I have a newly-built system with an ASUS Prime Z590M-Plus and=20 > >>>>> Intel > >>>>> 10900k > >>>>> with onboard graphics (UHD 630, according to intel). > >>>>> > >>>>> I specifically chose a 10th gen processor because I believed it=20 > >>>>> was > >>>>> well- > >>>>> supported by 13.1+. Unfortunately I can?t even install 13.1 > >>>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/can= t- > >>>>> install-i-just-get-a-little-white-box-and-a-mouse- > >>>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd > >>>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) > >>>>> > >>>>> I have successfully installed > >>>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. > >>>>> > >>>>> When I run `kldload i915kms`, the screen just goes black. > >>>>> > >>>>> I have never used graphics before on FreeBSD, so I?m not sure=20 > >>>>> where > >>>>> to > >>>>> begin diagnosing. I did as much research as I could upfront, but=20 > >>>>> have > >>>>> run into > >>>>> this obstacle. > >>>>> > >>>>> I?ll be content to run 14.0-CURRENT because I can still create=20 > >>>>> 13.1 > >>>>> jails. > >> > >> How about logging in from remote and load kernel module? > >> This is my example. > >> https://github.com/freebsd/drm-kmod/issues/159 > > > > When I do that, the screen still goes black, but kldload does return=20 > > in my remote terminal. This is in /var/log/messages:=20 > > https://gist.github.com/patmaddox/1a2b7bb8769cf1251beb514a9646a69e >=20 > Well, I don?t know if this has anything to do with anything, but when=20 > I run `pkg install drm-kmod` it lists all of these intel bits: >=20 > gpu-firmware-intel-kmod-broxton: 20220511 > gpu-firmware-intel-kmod-coffeelake: 20220511 > gpu-firmware-intel-kmod-elkhartlake: 20220511 > gpu-firmware-intel-kmod-geminilake: 20220511 > gpu-firmware-intel-kmod-icelake: 20220511 > gpu-firmware-intel-kmod-kabylake: 20220511 > gpu-firmware-intel-kmod-rocketlake: 20220511 > gpu-firmware-intel-kmod-skylake: 20220511 > gpu-firmware-intel-kmod-tigerlake: 20220511 >=20 > My 10th gen i9 is a ?comet lake? - not in the list. I?m not sure=20 > if it should be covered by a different one, but it is interesting that=20 > it?s absent. It's because Comet Lake uses the same GPU as the previous generation so you need to install gpu-firmware-intel-kmod-kabylake as noted in : Dec 5 22:14:30 beastie14 kernel: drmn0: could not load firmware image 'i915/kbl_dmc_ver1_04.bin' ^^^ > drm-kmod has a bunch of references to cometlake:=20 > https://github.com/freebsd/drm-kmod/search?q=3Dcometlake >=20 > But drm-kmod-firmware does not:=20 > https://github.com/freebsd/drm-kmod-firmware/search?q=3Dcometlake >=20 > I did make an effort to support a cometlake flavor:=20 > https://github.com/patmaddox/drm-kmod-firmware/commit/20570f61ee927e19d5f= d6303f94eac00aa2f3bfd >=20 > But it didn?t work, which is no surprise, because I have no idea what=20 > I?m doing when it comes to kernel drivers. >=20 > Does the fact that cometlake is absent from the list mean 1) it was an=20 > oversight 2) it?s not supported 3) nothing at all? >=20 > Pat >=20 --=20 Emmanuel Vadot From nobody Tue Dec 6 07:53:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRCMX3ZLRz4k995 for ; Tue, 6 Dec 2022 07:53:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRCMX1YS7z49SV for ; Tue, 6 Dec 2022 07:53:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1670313190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5pf2OKANG9bfpIgw9irnLQEIRfy0G7bHZEjmzLOT9hQ=; b=DBT9IkMs/65h/2wPB6yQ6xgzq7CqnEITaqugpTNDmOfXhHQczOFb7e5h83EYxEmIkv6zNM hO0yk3AYuP3S0mJ0GQcpsSo2I2bKzOCN5vzFi7fMyRhUx67P+7YtR3oONa5Fhp/tf3QJ0m gaDYfLjFf6/C2KrAPdvmJXfL5nSMvpU= Received: from skull.home.blih.net (lfbn-lyo-1-2174-135.w90-66.abo.wanadoo.fr [90.66.97.135]) by mx.blih.net (OpenSMTPD) with ESMTPSA id bf7f6b2e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 6 Dec 2022 07:53:10 +0000 (UTC) Date: Tue, 6 Dec 2022 08:53:10 +0100 From: Emmanuel Vadot To: "Pat Maddox" Cc: "Takanori Watanabe" , freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Message-Id: <20221206085310.78d00157b35f9b334f8652c0@bidouilliste.com> In-Reply-To: <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4NRCMX1YS7z49SV X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, 05 Dec 2022 22:18:13 -0800 "Pat Maddox" wrote: > On 5 Dec 2022, at 21:18, Takanori Watanabe wrote: >=20 > > On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: > >> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: > >> > >>>> > >>>> I have a newly-built system with an ASUS Prime Z590M-Plus and Intel > >>>> 10900k > >>>> with onboard graphics (UHD 630, according to intel). > >>>> > >>>> I specifically chose a 10th gen processor because I believed it was > >>>> well- > >>>> supported by 13.1+. Unfortunately I can?t even install 13.1 > >>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant- > >>>> install-i-just-get-a-little-white-box-and-a-mouse- > >>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd > >>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) > >>>> > >>>> I have successfully installed > >>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. > >>>> > >>>> When I run `kldload i915kms`, the screen just goes black. > >>>> > >>>> I have never used graphics before on FreeBSD, so I?m not sure=20 > >>>> where > >>>> to > >>>> begin diagnosing. I did as much research as I could upfront, but=20 > >>>> have > >>>> run into > >>>> this obstacle. > >>>> > >>>> I?ll be content to run 14.0-CURRENT because I can still create=20 > >>>> 13.1 > >>>> jails. > > > > How about logging in from remote and load kernel module? > > This is my example. > > https://github.com/freebsd/drm-kmod/issues/159 >=20 > When I do that, the screen still goes black, but kldload does return in=20 > my remote terminal. This is in /var/log/messages:=20 > https://gist.github.com/patmaddox/1a2b7bb8769cf1251beb514a9646a69e >=20 Please try to boot with hw.dri.__drm_debug=3D0x1FF in loader.conf With only one screen, no dock if it's a laptop. If it's a desktop and you have multiple screen, please try with all (especially if some are 4k/8k try with smaller resolution screen). Thanks, --=20 Emmanuel Vadot From nobody Tue Dec 6 08:02:53 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRCZp72Lcz4kBby for ; Tue, 6 Dec 2022 08:02:58 +0000 (UTC) (envelope-from pat@patmaddox.com) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRCZp5h5Mz4D3r for ; Tue, 6 Dec 2022 08:02:58 +0000 (UTC) (envelope-from pat@patmaddox.com) Authentication-Results: mx1.freebsd.org; none Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2AC68320046E; Tue, 6 Dec 2022 03:02:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 06 Dec 2022 03:02:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=patmaddox.com; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670313776; x= 1670400176; bh=bT77B8o4r1fwcbkkh/vVZnVjKAHuaD+70Ww9GUGWLzA=; b=R D4y8ZRI9kV3olwcHa6vT7uuPQjobPNjmlF/H2dq2eKAmNayrXQ3nNg62iyd5ASCL jyRXaFjmh5PH2kx4UQqJAXxEE8T6rPW9H66qhRjotaf4bzNzyJk8ol4JTze9p/iT oM105o69n9zufaFS/yBrgidJ6Mqfv778LtW5mHDaJXWf/piYZ0UxRJRJjlKJdHeG BzIzxQ5ROTXgLAu2PvAK0IDO6UTMiWqKSShvYi8GSkTL1A2qwYAbXPGtzzgcBYAd I472Qxibc2Y26m1Gw3gB7SSE5ut1IUjpHY2dzyqJgk40ZHT4GT088OFS2vrhaYnS ORcYGvL2aNYrh9D/xL79w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1670313776; x= 1670400176; bh=bT77B8o4r1fwcbkkh/vVZnVjKAHuaD+70Ww9GUGWLzA=; b=i lFOg9hn3jVQtgCTMMzRPmP2I00Y5G8v8677dlj0T/UEA2HOVTgPlxTacQCu2T6EJ m8TgF5MwcGXAVQO4UTxR5buy/lgOIC/CkXcFzDxQc9TDWPJfL+hIL7tQQhbrEQNW LBLXMoMw/PtfHFTjz2q6TudMUCc+feAAI1bNsg0QRbI3mtFSYhV3UkCle2rzwkKb /k3VzB9eqGBADXgGIi/LMtCxqZYOoJ52+wkWNxP1BkE7CXCj4fF0S5qzu0p62wFV WrhyQv/QMJYVoJ0kbkCpfQT5wkXe6TrfJ+Ryh2onEvo3N8N6/vbGHKPz45CQslCC 6nUQKxjP0RGXtzB3/QOCA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudehgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffokfgjfhggtgfgsehtkehmtdertdejnecuhfhrohhmpedfrfgr thcuofgrugguohigfdcuoehprghtsehprghtmhgrugguohigrdgtohhmqeenucggtffrrg htthgvrhhnpefhjefgtdejvddtkeekleelgeeuhfeltdeftedtfeeuffevvdekgffghfel fffhheenucffohhmrghinhepuhhrlhguvghfvghnshgvrdgtohhmpdhfrhgvvggsshgurd horhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehprghtsehprghtmhgrugguohigrdgtohhm X-ME-Proxy: Feedback-ID: i8b6c40f9:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Dec 2022 03:02:55 -0500 (EST) From: "Pat Maddox" To: "Emmanuel Vadot" Cc: "Takanori Watanabe" , freebsd-hackers@freebsd.org Subject: Re: kldload i915kms screen goes black Date: Tue, 06 Dec 2022 00:02:53 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <20221206085310.78d00157b35f9b334f8652c0@bidouilliste.com> References: <2CFF7511-C45A-4986-8881-2A68DC52F555@patmaddox.com> <3EE88B08-395F-47A1-B25B-E89C2B076654@patmaddox.com> <19286A43-0F72-4DA3-AF92-60E8BD11F7D7@patmaddox.com> <20221206085310.78d00157b35f9b334f8652c0@bidouilliste.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4NRCZp5h5Mz4D3r X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5 Dec 2022, at 23:53, Emmanuel Vadot wrote: > On Mon, 05 Dec 2022 22:18:13 -0800 > "Pat Maddox" wrote: > >> On 5 Dec 2022, at 21:18, Takanori Watanabe wrote: >> >>> On Mon, Dec 05, 2022 at 09:43:17PM -0800, Pat Maddox wrote: >>>> On 5 Dec 2022, at 20:55, Chen, Alvin W wrote: >>>> >>>>>> >>>>>> I have a newly-built system with an ASUS Prime Z590M-Plus and >>>>>> Intel >>>>>> 10900k >>>>>> with onboard graphics (UHD 630, according to intel). >>>>>> >>>>>> I specifically chose a 10th gen processor because I believed it >>>>>> was >>>>>> well- >>>>>> supported by 13.1+. Unfortunately I can?t even install 13.1 >>>>>> (https://urldefense.com/v3/__https://forums.freebsd.org/threads/cant- >>>>>> install-i-just-get-a-little-white-box-and-a-mouse- >>>>>> cursor.87334/__;!!LpKI!iRRMC3ef9hbS1NKXTBUoIDxlVz9pU_m1Jocnzh2Tlxfd >>>>>> s5SnkbHHXEM4iKqU7weuEiObV8rfJXfY$ [forums[.]freebsd[.]org]) >>>>>> >>>>>> I have successfully installed >>>>>> FreeBSD-14.0-CURRENT-amd64-20221201-d1f3abc89250-259495. >>>>>> >>>>>> When I run `kldload i915kms`, the screen just goes black. >>>>>> >>>>>> I have never used graphics before on FreeBSD, so I?m not sure >>>>>> where >>>>>> to >>>>>> begin diagnosing. I did as much research as I could upfront, but >>>>>> have >>>>>> run into >>>>>> this obstacle. >>>>>> >>>>>> I?ll be content to run 14.0-CURRENT because I can still create >>>>>> 13.1 >>>>>> jails. >>> >>> How about logging in from remote and load kernel module? >>> This is my example. >>> https://github.com/freebsd/drm-kmod/issues/159 >> >> When I do that, the screen still goes black, but kldload does return >> in >> my remote terminal. This is in /var/log/messages: >> https://gist.github.com/patmaddox/1a2b7bb8769cf1251beb514a9646a69e >> > > Please try to boot with hw.dri.__drm_debug=0x1FF in loader.conf > With only one screen, no dock if it's a laptop. > If it's a desktop and you have multiple screen, please try with all > (especially if some are 4k/8k try with smaller resolution screen). > Here’s the output with kabylake driver installed, and that loader.conf entry: https://gist.github.com/patmaddox/098bb58d4a3231b436b5946c1e0e4801 It’s a desktop with a single 1920x1080 display. I’m plugged into HDMI now instead of DisplayPort. Pat From nobody Tue Dec 6 15:42:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRPnL0sdkz4jxp2 for ; Tue, 6 Dec 2022 15:42:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRPnK0zBPz3xbf for ; Tue, 6 Dec 2022 15:42:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=0nLEuVVF; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::636) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x636.google.com with SMTP id vp12so7159981ejc.8 for ; Tue, 06 Dec 2022 07:42:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vfs0th5G5ygOP6InekKfi4NXiOZayllV8MKs7oMBUKg=; b=0nLEuVVF/zcl5sPDb6LKlsUppyujdFkNrd/n38sa/ZngdVgZFkNz01lsX+HuqxWlty QqyQnqk5Ku+7aEeMqurUxfHB92W6d3S/6o3RhlyDqrG0vyeCaFfF4C1myn1nzMXCUWG5 XhIraRCHhCB83KVjbzNanlG6hFPBrmNxFTt1t+6rCEg6Eh4pduR2igeXKCo61Evyy5sW 9kdeOuslt+guUnjs7TqdqaimD/plIZvOlnEI8kP6Tpb7wG00uDNAirgeuY4iew3hXv9j tZdgUaTu2ucGE3acrsWqE+00FWoZYudSGC0HZQkwORTQaoCy6LP2YSmOzuBwbdzjebGc jP4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vfs0th5G5ygOP6InekKfi4NXiOZayllV8MKs7oMBUKg=; b=KDsxFMIMSzLTCz8ohld05ygJjmoop0l3A83WD38g/0nqw57HLfo1wC7/tBfd7TLsbu GOxvfs9SotgWYoWSRrx/SAjqt0FgbqEafdifuuXtiIkWhJnms/BR1Mqn0Y8X3ZZDzapR sgC2gGQBpqs3ig2JaKI36FHtxW7/Sy/R1nYTShA0dYxa/gUMyrUPX9sYst7WcLPXXd3r bjr8P9rZaaOSkhToPn5O7KSODJC/X9MifzKSWCefxe+6rinc7NHUrjoyqZSDkbvrubSo oshTrq83EYSdBHQWfsYYWnmA5seSpx37L7DeGpmy2TyVbZ5D8jBNdWKLnyz6w8JX2rWF +n4A== X-Gm-Message-State: ANoB5pn6fy69+Zz3NoGIjZmWb4yowf0dQqeTyboHkDXRs+SlXEg9RI6B FTWUqxGju5cRi6O/ZdHOI/Pc+Hi6SwCg/UGnDsdtHw+O4ACEsg== X-Google-Smtp-Source: AA0mqf4QEUhlpqswFouAKq8CvDTfQtPo1Ae7wZxPPzQa4fzLNIH7hwR97hNWzOVDnDW5WKIg7zu3gEpdS2g7OH/dnLU= X-Received: by 2002:a17:906:c2d3:b0:7c1:535:f2fb with SMTP id ch19-20020a170906c2d300b007c10535f2fbmr4548766ejb.252.1670341363310; Tue, 06 Dec 2022 07:42:43 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> In-Reply-To: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> From: Warner Losh Date: Tue, 6 Dec 2022 08:42:31 -0700 Message-ID: Subject: Re: Add BLAKE3 hash to ISO checksums To: Yonas Yanfa Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000009d3f5c05ef2aa71a" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::636:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NRPnK0zBPz3xbf X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000009d3f5c05ef2aa71a Content-Type: text/plain; charset="UTF-8" On Mon, Dec 5, 2022 at 9:27 PM Yonas Yanfa wrote: > Hi, > > Can we please add BLAKE3 hashes to > https://www.freebsd.org/releases/13.1R/signatures ? > > On first run, BLAKE3 runs at the same speed as SHA-512. On my system, > the second run is 17x faster. > > I recommend using https://crates.io/crates/b3sum At the very least, we'd need a b3sum port to integrate this into the release building work flow. Warner > > > $ for hash in b3sum sha256sum sha512sum ; time $hash > FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end > 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 5.05 secs fish external > usr time 834.12 millis 4.53 millis 829.58 millis > sys time 666.34 millis 0.44 millis 665.90 millis > > 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 7.46 secs fish external > usr time 7.13 secs 287.00 micros 7.13 secs > sys time 0.31 secs 146.00 micros 0.31 secs > > 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 > > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 4.84 secs fish external > usr time 4.61 secs 274.00 micros 4.61 secs > sys time 0.18 secs 140.00 micros 0.18 secs > > $ for hash in b3sum sha256sum sha512sum ; time $hash > FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end > 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 280.16 millis fish external > usr time 852.65 millis 316.00 micros 852.34 millis > sys time 86.98 millis 166.00 micros 86.81 millis > > 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 7.39 secs fish external > usr time 7.17 secs 343.00 micros 7.17 secs > sys time 0.21 secs 181.00 micros 0.21 secs > > 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 > > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in 4.84 secs fish external > usr time 4.57 secs 363.00 micros 4.57 secs > sys time 0.23 secs 192.00 micros 0.23 secs > > > Cheers, > Yonas > > > --0000000000009d3f5c05ef2aa71a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 5, 2022 at 9:27 PM Yonas = Yanfa <yonas.yanfa@gmail.com> wrote:
Hi,=

Can we please add BLAKE3 hashes to
https://www.freebsd.org/releases/13.1R/signatures ?

On first run, BLAKE3 runs at the same speed as SHA-512. On my system,
the second run is 17x faster.

I recommend using https://crates.io/crates/b3sum
=
At the very least, we'd need a b3sum port to integrate t= his into the release building work flow.

Warner
=C2=A0


$ for hash in b3sum sha256sum sha512sum ; time $hash
FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end
5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0=C2=A0=C2=A0 5.05 secs=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fish= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0 834.12 millis=C2=A0=C2=A0=C2=A0 4.53 mill= is=C2=A0 829.58 millis
=C2=A0=C2=A0=C2=A0 sys time=C2=A0 666.34 millis=C2=A0=C2=A0=C2=A0 0.44 mill= is=C2=A0 665.90 millis

697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0=C2=A0=C2=A0 7.46 secs=C2=A0=C2=A0=C2=A0 fish=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0=C2=A0=C2=A0 7.13 secs=C2=A0 287.00 micros= =C2=A0=C2=A0=C2=A0 7.13 secs
=C2=A0=C2=A0=C2=A0 sys time=C2=A0=C2=A0=C2=A0 0.31 secs=C2=A0 146.00 micros= =C2=A0=C2=A0=C2=A0 0.31 secs

259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8= db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0=C2=A0=C2=A0 4.84 secs=C2=A0=C2=A0=C2=A0 fish=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0=C2=A0=C2=A0 4.61 secs=C2=A0 274.00 micros= =C2=A0=C2=A0=C2=A0 4.61 secs
=C2=A0=C2=A0=C2=A0 sys time=C2=A0=C2=A0=C2=A0 0.18 secs=C2=A0 140.00 micros= =C2=A0=C2=A0=C2=A0 0.18 secs

$ for hash in b3sum sha256sum sha512sum ; time $hash
FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end
5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0 280.16 millis=C2=A0=C2=A0=C2=A0 fish=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0 852.65 millis=C2=A0 316.00 micros=C2=A0 8= 52.34 millis
=C2=A0=C2=A0=C2=A0 sys time=C2=A0=C2=A0 86.98 millis=C2=A0 166.00 micros=C2= =A0=C2=A0 86.81 millis

697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0=C2=A0=C2=A0 7.39 secs=C2=A0=C2=A0=C2=A0 fish=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0=C2=A0=C2=A0 7.17 secs=C2=A0 343.00 micros= =C2=A0=C2=A0=C2=A0 7.17 secs
=C2=A0=C2=A0=C2=A0 sys time=C2=A0=C2=A0=C2=A0 0.21 secs=C2=A0 181.00 micros= =C2=A0=C2=A0=C2=A0 0.21 secs

259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8= db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in=C2=A0=C2=A0=C2=A0 4.84 secs=C2=A0=C2=A0=C2=A0 fish=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external
=C2=A0=C2=A0=C2=A0 usr time=C2=A0=C2=A0=C2=A0 4.57 secs=C2=A0 363.00 micros= =C2=A0=C2=A0=C2=A0 4.57 secs
=C2=A0=C2=A0=C2=A0 sys time=C2=A0=C2=A0=C2=A0 0.23 secs=C2=A0 192.00 micros= =C2=A0=C2=A0=C2=A0 0.23 secs


Cheers,
Yonas


--0000000000009d3f5c05ef2aa71a-- From nobody Tue Dec 6 21:02:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRXtD57Tlz4jvnV for ; Tue, 6 Dec 2022 21:02:28 +0000 (UTC) (envelope-from yonas.yanfa@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRXtD35tGz4cGN for ; Tue, 6 Dec 2022 21:02:28 +0000 (UTC) (envelope-from yonas.yanfa@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-wm1-x32c.google.com with SMTP id ay14-20020a05600c1e0e00b003cf6ab34b61so15312899wmb.2 for ; Tue, 06 Dec 2022 13:02:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=BBh7h6zjSPXc2x43dPfIeThDuV+uQE57kq1JUZWmAGs=; b=DgtUntzVLlc7sp0C+zFns739smnXBRT+agRbuIh5dXmTvEUh6FetROdiH9NAjMkhxN 5fcJDvmku1QKKpNH1C+i8wwXACc727HZ0ERkRno/b8sysCKfrb9NIB+Q/tMKPFugvlUU SvT30dO+cLBEi7P2f/8nnYvC+Q/C4LM8PRaOUZrzuuNkHrJFoB70NQW35YZN6/mv0ft3 0popBSQo+dVaoV64Rmgxa2g/suw0paOURaNp5+Lk4Hxfiu+uRADZpxPn1/Xeu2X0fhr6 rNgoh42UxDEqofPBsHbXnZO3P59g1qaNZ7Ty/qD0tp5jcRtEEwUVTAEizrGgFxDwghbs iboQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=BBh7h6zjSPXc2x43dPfIeThDuV+uQE57kq1JUZWmAGs=; b=ngcoBMCIbjNz1PVuKt8lnPRi4TWDwbn4c7QlxmyaFA/CLxhwSQtjgyhGTmbq8v3KlK PDydzpgeE3ALHvneUgzZbT3/s4T15PznNcoZ6CIm0Xc6fK4ZiVH8Ona3l7m8BY8sL4LO bMfRdll4ZzqtKq9M3l3T6wD/PBGJ42F0lT6uexEJykMRJx44+x4gkN9X6EUX+j3FV5rP QNh/tQV3zFaOhtENXQD8PgHIiGRcuReTQ9yd61RwsULe+8D2ljWPGN5zFufh09UKqawr itGhtmW34qIf3Ia5ylpBc1x8+jDad7xnkGL1406yn5qc2tSDHaKX5oAPWs0PKzxxB/DN GQ0g== X-Gm-Message-State: ANoB5pnqhE6lO7HScwV9y0UHdo9GFEZSbpcE7QtIkvA/1wE11LBM7va+ f+odKhrpZ8x0b6Z8hDcwtnz1SRwqyHxFKg== X-Google-Smtp-Source: AA0mqf6w810QE4OPfwSjq2HLR4F9ucQ8VjWy459fPklm8urNuNieOfEJzPIMuP2gBh5EAhwDvaqxDg== X-Received: by 2002:a05:600c:502b:b0:3a5:cb0e:8242 with SMTP id n43-20020a05600c502b00b003a5cb0e8242mr64753125wmr.188.1670360544836; Tue, 06 Dec 2022 13:02:24 -0800 (PST) Received: from [10.19.0.2] (93-190-138-188.hosted-by-worldstream.net. [93.190.138.188]) by smtp.gmail.com with ESMTPSA id k15-20020a05600c1c8f00b003c6c3fb3cf6sm24432822wms.18.2022.12.06.13.02.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Dec 2022 13:02:24 -0800 (PST) Content-Type: multipart/alternative; boundary="------------pYeTV4ifdYtZo0O5X2FpBrJE" Message-ID: Date: Tue, 6 Dec 2022 16:02:21 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: Add BLAKE3 hash to ISO checksums To: Warner Losh Cc: freebsd-hackers@freebsd.org References: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> Content-Language: en-US From: Yonas Yanfa In-Reply-To: X-Rspamd-Queue-Id: 4NRXtD35tGz4cGN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------pYeTV4ifdYtZo0O5X2FpBrJE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Added 2022-05-26 03:54:06 : https://www.freshports.org/sysutils/b3sum Yonas On 2022-12-06 10:42 a.m., Warner Losh wrote: > > > On Mon, Dec 5, 2022 at 9:27 PM Yonas Yanfa wrote: > > Hi, > > Can we please add BLAKE3 hashes to > https://www.freebsd.org/releases/13.1R/signatures ? > > On first run, BLAKE3 runs at the same speed as SHA-512. On my system, > the second run is 17x faster. > > I recommend using https://crates.io/crates/b3sum > > > At the very least, we'd need a b3sum port to integrate this into the > release building work flow. > > Warner > > > > $ for hash in b3sum sha256sum sha512sum ; time $hash > FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end > 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in    5.05 secs      fish           external >     usr time  834.12 millis    4.53 millis  829.58 millis >     sys time  666.34 millis    0.44 millis  665.90 millis > > 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in    7.46 secs    fish           external >     usr time    7.13 secs  287.00 micros    7.13 secs >     sys time    0.31 secs  146.00 micros    0.31 secs > > 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 > > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in    4.84 secs    fish           external >     usr time    4.61 secs  274.00 micros    4.61 secs >     sys time    0.18 secs  140.00 micros    0.18 secs > > $ for hash in b3sum sha256sum sha512sum ; time $hash > FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end > 5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in  280.16 millis    fish           external >     usr time  852.65 millis  316.00 micros  852.34 millis >     sys time   86.98 millis  166.00 micros   86.81 millis > > 697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40 > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in    7.39 secs    fish           external >     usr time    7.17 secs  343.00 micros    7.17 secs >     sys time    0.21 secs  181.00 micros    0.21 secs > > 259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2 > > FreeBSD-13.1-RELEASE-amd64-disc1.iso > > ________________________________________________________ > Executed in    4.84 secs    fish           external >     usr time    4.57 secs  363.00 micros    4.57 secs >     sys time    0.23 secs  192.00 micros    0.23 secs > > > Cheers, > Yonas > > --------------pYeTV4ifdYtZo0O5X2FpBrJE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Added 2022-05-26 03:54:06 : https://www.freshports.org/sysutils/b3sum

Yonas


On 2022-12-06 10:42 a.m., Warner Losh wrote:


On Mon, Dec 5, 2022 at 9:27 PM Yonas Yanfa <yonas.yanfa@gmail.com> wrote:
Hi,

Can we please add BLAKE3 hashes to
https://www.freebsd.org/releases/13.1R/signatures ?

On first run, BLAKE3 runs at the same speed as SHA-512. On my system,
the second run is 17x faster.

I recommend using https://crates.io/crates/b3sum

At the very least, we'd need a b3sum port to integrate this into the release building work flow.

Warner
 


$ for hash in b3sum sha256sum sha512sum ; time $hash
FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end
5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in    5.05 secs      fish           external
    usr time  834.12 millis    4.53 millis  829.58 millis
    sys time  666.34 millis    0.44 millis  665.90 millis

697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in    7.46 secs    fish           external
    usr time    7.13 secs  287.00 micros    7.13 secs
    sys time    0.31 secs  146.00 micros    0.31 secs

259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in    4.84 secs    fish           external
    usr time    4.61 secs  274.00 micros    4.61 secs
    sys time    0.18 secs  140.00 micros    0.18 secs

$ for hash in b3sum sha256sum sha512sum ; time $hash
FreeBSD-13.1-RELEASE-amd64-disc1.iso ; end
5240012f644cd660f6570823b5fb0090b0cf0b269b1c1e0563c98af26ed2becd
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in  280.16 millis    fish           external
    usr time  852.65 millis  316.00 micros  852.34 millis
    sys time   86.98 millis  166.00 micros   86.81 millis

697d81653fa246b921ddfcf1d15562c55249cc727b11fa3e47f470e2cf2b6a40
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in    7.39 secs    fish           external
    usr time    7.17 secs  343.00 micros    7.17 secs
    sys time    0.21 secs  181.00 micros    0.21 secs

259e034731c1493740a5a9f2933716c479746360f570312ea44ed9b7b59ed9131284c5f9fe8db13f8f4e10f312033db1447ff2900d65bfefbf5cfb3e3b630ba2
FreeBSD-13.1-RELEASE-amd64-disc1.iso

________________________________________________________
Executed in    4.84 secs    fish           external
    usr time    4.57 secs  363.00 micros    4.57 secs
    sys time    0.23 secs  192.00 micros    0.23 secs


Cheers,
Yonas


--------------pYeTV4ifdYtZo0O5X2FpBrJE-- From nobody Tue Dec 6 22:36:49 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NRZz80z83z4k6mN; Tue, 6 Dec 2022 22:36:52 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NRZz72FFJz3KDy; Tue, 6 Dec 2022 22:36:51 +0000 (UTC) (envelope-from grarpamp@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="HN/icL32"; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::a2f as permitted sender) smtp.mailfrom=grarpamp@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-xa2f.google.com with SMTP id l17so2322837vkk.3; Tue, 06 Dec 2022 14:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y0KieX0vs/awEVLTg3SpdLfcwwMini+bi41hP4Was8A=; b=HN/icL32n9he4YFawBuV4Ia4jmEeqijFeerVwvD1vv6TUBy+mDb0i5HX34IJrPHPhJ kTSI7kbqaZiO9dOVE7uJMUgk9sKcbbLJHbcohbm30R0ZR5PCP2rgeFfbmOLtRzMsacPg vsVBiT297Y1yKzm3cakc6kgJymgK+YrZhvcT82pFFo/eJrIEwOhek1nrE3pF5yWiZ58p lRXKMl5F6O1p7712TsgEBHpcJ1LDVPy2Wwo03ww5UXLHVWl3doM/dsPECgiXtAN7sDDE k2VvlY/DLZ5x+30poxan8a197JxJXT47WjfpWwGMKr+PNqE+mEPxuTNISV779O3ytK47 zE7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y0KieX0vs/awEVLTg3SpdLfcwwMini+bi41hP4Was8A=; b=qEeVWzK3CcNv1yQBD26m9vVwU55oTNRRnUTkBLag+Le04mWG7cXHmsBlj6uSuUZneG F77x/6YQYPTvATJtEIGQj00HQHWSg2rF43/vcB9P7Owx7BTSt/RehkalRc4r9/PMSdIZ 4d68WlmW1IdUWbTqcBK+45AAVeGq4Td2/Oug+1kPj6fWZ+rshDlN8QYlAwqFFsdLvlVR mvM3wdynOceB5K7v6NbRKP6yCk3uygh6nyw60UDRPY3Rxd7+4o628zPQzAAsJJk73PcT K4n1ypxMesHyTI8Ih+zebBaTNcJ8FgV0EMY1Rn2mZ+7uKmH71yLPzINngGnuZtG4y4jg d3Iw== X-Gm-Message-State: ANoB5pn1Zpb3VM7zRrc9PvSqOwh5ix1tYbTw7jK+SRbDrg/UW8Bg3HnU PWMHvub2TpKUHPojhypI9Zq2mvr0Ie8WeD7Mi9HxfJyPMfp074CeF6k= X-Google-Smtp-Source: AA0mqf6c9KdwqQ6v9cur5hbMLaJFOaGGJ5UQBPghF3HGFZ+jXmBjEa+ZdO0ADzkgC2MumHZRcjQYjFCRckwldUUCpWA= X-Received: by 2002:a1f:bfd2:0:b0:3bc:99b5:21b with SMTP id p201-20020a1fbfd2000000b003bc99b5021bmr13448280vkf.24.1670366210107; Tue, 06 Dec 2022 14:36:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a59:acc2:0:b0:32b:33ff:fbc3 with HTTP; Tue, 6 Dec 2022 14:36:49 -0800 (PST) In-Reply-To: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> References: <6d973f68-7904-5c23-6c6b-73a76e0a4ef5@gmail.com> From: grarpamp Date: Tue, 6 Dec 2022 17:36:49 -0500 Message-ID: Subject: Re: Add BLAKE3 hash to ISO checksums To: freebsd-hackers@freebsd.org Cc: freebsd-security@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.83 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.83)[-0.827]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org,freebsd-security@freebsd.org]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2f:from]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4NRZz72FFJz3KDy X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N > On first run, BLAKE3 runs at the same speed as SHA-512. > On my system, the second run is 17x faster. > for hash in b3sum sha256sum sha512sum > Executed in 5.05 secs > Executed in 7.46 secs > Executed in 4.84 secs > for hash in b3sum sha256sum sha512sum > Executed in 280.16 millis > Executed in 7.39 secs > Executed in 4.84 secs Any given hash function will take the same time for the same data. Something in the system or test setup is likely returning any "17x" difference or lack thereof... ie caching. Until that outlier difference is investigated and identified, any speed differences between hash functions wouldn't necessarily be reason to add or drop any of them. Use ramdisk on dedicated or non-busy testbeds, specify exact cpu model if testing cpu features or desiring others to scale results to their own cpu's, average results across multiple runs, don't publish outliers unless exploring degenerate edge cases, etc. > I recommend using https://crates.io/crates/b3sum The actual reference implementation source code is here... https://github.com/BLAKE3-team/BLAKE3 > Can we please add BLAKE3 hashes to > https://www.freebsd.org/releases/13.1R/signatures ? Two well chosen hash functions should be enough to cover a break in one, and a third seems a bit overkill. FreeBSD doesn't really use or embed them much and it can swap out broken algos faster than entities in the world that may have hardcoded them in non-modular things. https://en.wikipedia.org/wiki/Cryptographic_hash_function https://en.wikipedia.org/wiki/Cryptography If choosing crypto algos, the obvious will be one that are recognized by crypto standards bodies, competitions, and communities worldwide, and are in wide growing adopted use as a result of those processes. Some of them may be listed starting from the above links. Then whatever alternative competitors based on reviewed security estimates, speed, family isolation by both authorship and algorithm approach, cross platform, multi-thread, simplicity, programmability, arbitrage of threat model/actor/geopolitic, Post-Quantum, etc chosen from among the different algos. FreeBSD's current choice of sha-256 and sha-512 do fail some of those differentiators, thus it is probably reasonable to consider swapping one of them out. More of the leading competitors reference crypto implementations could be added to FreeBSD ports and packages for people to play with. There are also some dedicated all-in-one multi-hashing apps that volunteers could also make ports of. Tools like 'openssl dgst' already do include some, and there are crypto libraries for Python, etc. From nobody Wed Dec 7 21:42:24 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NS9kF4Mfdz4jvZW for ; Wed, 7 Dec 2022 21:42:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NS9kD4S4Cz3vSB for ; Wed, 7 Dec 2022 21:42:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=GitM+0bf; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.66.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670449362; bh=lZq2+/+6CEjGzdHchUUJHZp1nf1dJ04iaVcLRbNvrn8=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=GitM+0bfJ23Bu+xA7oNjsNydGovZSDFQ3pkSkmWQU8tSwBl9dcjexljx205l58U0bL27cklpBnJtmd8TcKZOKUVav7+eP9CO2JH62WlwqoQmQS4Js3XWTmmskW1XOtDgxPQdC3u8L5sgl0SrW6F2bQlyxxexMDD0TnTspFSStF0DF9TMY4p6cbhqvO8IzZdFOMh2icnFn9kKF2C8rmpJwVpbg8r7hYHTo9qW6NXJldVtPrpPgRWXbj0C5r5J3gsF7zBOy6mpk6conSB5hYV+h8ES654WrwoLJEqiQsQnXMvs5tHvZeNcACYgeJxGEuKSWqJtes5ZYsr97OZqYdxdcQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670449362; bh=sSrOW6tHQZw+ZS9f2tw8E8s2zxZ5z8tAUtkMOZp2ZMZ=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=FQ7PVoyLKgXizdgslZqhD8A5nzSAx9MjY7uF/07FCo6kK4Kc5Xd2uYxZqDI4BrnhHjIsUyo1xjm2Z79F8ZtxgxsSNjSubCvuIbBp/RoRCgRTZGQKYePut5KMbEnzru+Ulgn1ultaLYNPG5ConmfvutITCh52If78qFKZfswbiLGOH9m1gtX1JTWSw2BU7wubO+x3l7L+jZyshqN/N7YwWIK62AlRkL8/FcfODCJBAjQykRjvlDbFUFFMyhMY1rc7OUTEb/2eZkXSBd7NkPXqDNZXd2hhOxbSfnHwPgEGn60sjj3ZFhwhKR1qyTmtdMqjShmA9BF/lKD+osqHPXqj2A== X-YMail-OSG: oOlFPF0VM1mkzTOEbwZtjCZDuTy_I0LL_rpjEp6dic7Dm8hX3N87VzMw_djmrf. Iaqfn62SExIRqPrrZO8y8v3DGGaFa6wVG0AQ__DZGWn30p4.rK5HefN53yiC7ijEz6iSO0ETqoN7 JQDz8m5rXr8au.FhEivMjxv9eXo2tVulQD3aYR6cy5U5O.HL2iZ31EUTdizD59XGnam.h4bYcFWD 4Cu2Ci190ydmuyKVP0YTJqAt5wi.2IZPE1pCwUGq2E442HatLlqMUnbIJxldUFhbNi9amzIcTeLJ swNB_Nr38jBgdsw1MdifDyEpsDkiJQnoovkgMWqfC.md52Li1OkvO0Kx4Qgb1VASAjEyqVHFyJRH JZ0jUUUNeK2CF3cx8l02mJISLCqJuD6mShnCkJ0PzVYTW0WsQqFIfa6W4Kxgs_KbWK2WzR6e1QOm TvgT0pvdJmRW.J7y40eYIoH_lJjL9stLT7qW390ZqY5D0frogJfpVT0fbunvvaIReGboUd0izKJE wqqUyHBe5brDwNnur.omT3sGiB7LXZfacntaJJAi8XlrFTibNM.5zQI3wdIjvh4WM.zyxG1zSsdX ItMuwpl13EqtZ4n1BWGwHMgmT6BXQ7BATwP8ZibUYdArtMD_kr581.mNS5aMcE1.2BjMQ9ah.rTo 2dDOtlS8D0z8XgdRvECzrGl_29nwXhwGX9dMN1sWwH3bYbKQijG4yA6vdA9tRZnGl4UaAkB480ra sBYfQekdoynE6_ZXwCC.U7T4Yy0L83SFRBpObzsVWF4ICqwbJL70_39Qkl6s90irQYy0WDQ5P4Ev IhMM874i3A9AOJLei7.2nryPZriDDpGiHZz2lD.DnvvIggc8D57JCTYrsS7A1yXqkOWCheJi59nn j4arzL5Tj3mDYqY8.PeohdAHoXERUQb4I.J.80zfpZlZadKPiiy.i0sy3POgGN4VMjiegH3rDO0m aMq_D_EKeyiaMILUp9FoYnFFbQURCvqotzvBxzZF0mO5BmMVVkZvidjVFTaqcYqEuhQDfZuyiDUW 5S3arsN3qb2owAYbWn8hx0Yx0PcJIOFwztQN3OHpnLCOmDbsq2wzLi76bnvXKePi854Yc1UUh_yo Ip_LDq76TWKLiZjFOhnPoT_PD_gjw2cYMKWWJSN1FVTrX3oYpfiL0yshpxeaugV8n7Xsb7q.hZhs .0VNxGrVqmPSXuyokeGpu2JycE7BRM75TX1vDWajBhHM9Pxf6Dd4cU7OTsq872tclbUMWQFVDh17 9WDzV3kxK5YCFJCJjB8GBB1E2c.sTXqo9rUbv7mNoUOyFs23x6aB1XiDJcJdyuVYeF49XX2pP1f. fVo3kpHjtTLoDBqj5xMFAau3t.Pc8bMve9y8kKhPXQXam6PbHLMkF28J4eJcsCYbOj11YnP6Yyrl MoqP.g2fKcUf1SMs7RZiW2GXAri3eZKWFNWDqYDrHDXIWp59fvG_jeI1EDHwA4hic6OmRIlUJ8lQ 3SOqIGYb1eZdf_apGJnCeSC9IsDK7ohYtI8zj5Yxl2zyfklhJfSg91EWkuJ81jxYnJndcbBFjhpX dqzEegjrQIpFDxgNhOjDsBRoRbuH_5VuHfvKw_50PVr4T6Wxjph6ciUJyi1MqE9a20LS2NSn545Z yDFYRKZDlvT5xJ95bgDYnJHwiDr3_WwbVkQVnWjbzrqWa8txeW_pfd4fPUMtSkRPZTTSBX6gU3le v9zkEsN62_.ilvMSciuN8lVg6mcI0JVQkbEUfiVKfPGbXK6S54i_kClA4_SV43SFxHyPUn.Vlind AAFakuIhJE.GJgUlMQq6Qd4V3m3VsKkwcU_xyStVYb0GuaT7uPZcD7s.O_fgKfbeODKRIIEYB7.s CQjIwepUuoMEWqAAsF87FNcKr_MBEE6TpM6JNCJP9eJGvEafvUWhG9_.hHUSJp4tbSLQ7XId4U39 nnzbxyMgHJ8dHDXbKgcSFlx3p63lCVkr7EywutGbRerZHwd3GRvvnwdm6gSXgZePzpPwnTFpqTUO qsd7S7IcigP4Nodyf.6rZe4AM0PJoHdqOwGCWB10YcSNV.GUUSWHvGhnc5ZlE95sPiS2NYlD5Wfi B0O.VR8cSzVZECPpvvRFYYxkYYRfFEmzb1h9py_FIe8IzaC4wDfP..FeQAFMcHGmD9mhVL12mtYe rvypLOH6QyXf_mb2kkTfRPcREas4PMoyEbUVUuEAFHzmo9lm04ZeSvDerlE_t.0tBD6crtyF9H9i Yn9cku4KB7ckJ6JfEC6C1Yjte8siN0jf3Fa6V_Y6wwxCJJkuT5LvINiNTeXPbOmM6wNlQuVw0f1w BLek- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 7 Dec 2022 21:42:42 +0000 Received: by hermes--production-ne1-7b69748c4d-kwzvj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 02bdea0e3b1d6f54655dbe7fa386c183; Wed, 07 Dec 2022 21:42:36 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: A possibly unintended consequence of the kernel's alloc_bounce_zone implementation? Message-Id: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F@yahoo.com> Date: Wed, 7 Dec 2022 13:42:24 -0800 Cc: freebsd-arm To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <21DE5CB7-76DF-4FC9-8EE9-2FC0F216C72F.ref@yahoo.com> X-Spamd-Result: default: False [-2.43 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.93)[-0.931]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from] X-Rspamd-Queue-Id: 4NS9kD4S4Cz3vSB X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I was doing some exploratory investigation of getting a "C0T" RPi4B that does not have the PCIe block wrapper logic messed up --in order to avoid much of the bounce zone usage that adds to the challenged memory/RAM-caching subsystem involved. I ended up noticing an odd property of the alloc_bounce_zone implementation when I tried to have a larger hw.busdma zone show up. (This was before trying to get beyond 4 GiBytes.) To simplify the description below, I use examples of extreme conditions that are simple to describe. A) Presume that the sequence of calls to alloc_bounce_zone never had an incompatible alignment. (dmat->lowaddr is the point here.) B) Concentrate on two ordering properties across the calls: B1) The various dmat->lowaddr arrive in a strictly decreasing order vs. B2) The various dmat->lowaddr arrive in increasing order (B1) will produce a hw.busdma zone for each distinct value of dmat->lowaddr . (B2) will produce one hw.busdma zone with the smallest dmat->lowaddr being used for all the bounce activity. (The smallest could potentially be rather small.) It turned out that the RPi4B basically had its smallest dmat->lowaddr in the 2nd alloc_bounce_zone call so all later alloc_bounce_zone calls used that zone. (The actual size was relevant to me only because of the investigation involved.) This wording is slightly simplified from the actual context but should be suggestive enough. (I changed ">=" to "==" for my investigative activity, making the results be more like (B1), but independent of dmat->lowaddr arrival order. The zone order ends up being a permutation of (B1)'s order.) Are there any consequence of (B1) vs. (B2) big enough to make the existing implementation somewhat of a problem? Since (B1) can happen anyway (so: is a valid result), should the order dependency of alloc_bounce_zone's behavior be removed to avoid (B2) type results? === Mark Millard marklmi at yahoo.com From nobody Fri Dec 9 15:25:47 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NTFGj5WhSz4jY8m for ; Fri, 9 Dec 2022 15:26:05 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward500p.mail.yandex.net (forward500p.mail.yandex.net [77.88.28.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NTFGg74xBz4Hpx; Fri, 9 Dec 2022 15:26:03 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=uTPf6XPa; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 77.88.28.110 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru; dmarc=none Received: from vla5-91e5293da019.qloud-c.yandex.net (vla5-91e5293da019.qloud-c.yandex.net [IPv6:2a02:6b8:c18:3e1f:0:640:91e5:293d]) by forward500p.mail.yandex.net (Yandex) with ESMTP id 16E39F01550; Fri, 9 Dec 2022 18:26:00 +0300 (MSK) Received: by vla5-91e5293da019.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id wPcD1p1ZA8c1-7htvkttE; Fri, 09 Dec 2022 18:25:59 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1670599559; bh=YqNTFgv7SelG/Re2Dms4R8TM25cZ5pLEp0PYkMqVsr4=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=uTPf6XPacDLYqWlhWJDiGHJvcDmdlgdVEXkUij42TyEjZsumSqgZAcJ8bQuH9Eju6 jb6zc61T3sRh68MHhj7xw3bydAnz2a5W1MeI8kU0iN9rHRT2FxbufMUF/lsbQg15T0 VOvw6HaKbYYVFCLBcMt+VafmriRvsu2ooXmmKjWA= Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: devctl_notify system is inconsistent From: "Alexander V. Chernikov" In-Reply-To: <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> Date: Fri, 9 Dec 2022 15:25:47 +0000 Cc: Warner Losh , hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> To: Baptiste Daroussin X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:77.88.28.0/24]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:13238, ipnet:77.88.0.0/18, country:RU]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[ipfw.ru:+]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEFALL_USER(0.00)[melifaro]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[ipfw.ru]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[77.88.28.110:from] X-Rspamd-Queue-Id: 4NTFGg74xBz4Hpx X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N > On 1 Dec 2022, at 17:40, Baptiste Daroussin wrote: >=20 > On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote: >> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin = wrote: >>=20 >>> On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: >>>> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin = >>> wrote: >>>>=20 >>>>> Hello, >>>>>=20 >>>>> After the addition of netlink(4) by melifaro@, I started working = on a >>> new >>>>> genetlink(4) module, to send kernel notification to the userland = via >>>>> netlink. >>>>>=20 >>>>> The goal is to be able to have multiple consumers without the need = of >>> devd >>>>> to be >>>>> running. >>>>>=20 >>>>> The goal is also to be able subscribe to the events the consumer = is >>>>> willing to >>>>> receive. >>>>>=20 >>>>> https://reviews.freebsd.org/D37574 >>>>>=20 >>>>> I also added a hook to devctl_notify to make sure all its event = got >>> sent >>>>> via >>>>> nlsysevent. (https://reviews.freebsd.org/D37573) >>>>>=20 >>>>=20 >>>> You're connecting it at the wrong level: it will miss all device = events. >>>> devctl_notify >>>> is used by everything except newbus's device attach, detach and = nomatch >>>> events, so none of those events will make it through. >>>=20 >>> Where should I hook to get the device events? >>>=20 >>=20 >> Either you need to drop down a level to where the formated events are >> queued, >> or you'll need to add something in devaddq() to deal with the events. = These >> are >> a slightly different format than the devctl_notify() events because = the >> latter was >> added later and I didn't want to cope with transitioning the old = formatted >> messages >> to the new at that time (silly me). >>=20 >>=20 >>>>=20 >>>>=20 >>>>> It works great and so far I am happy with it. on thing I figured = out >>> it is: >>>>> the "system" argment of devctl_notify is inconsistent: >>>>> Upper case vs lower case >>>>> "kern" vs "kernel" >>>>>=20 >>>>=20 >>>> They are consistent. With one exception that I deprecated in 13.x = to be >>>> removed in 14.x. I documented all of them at the time in devd.conf. = I >>> think >>>> I'll go ahead and complete the deprecation. >>>>=20 >>>>=20 >>>>> I intent to fix the following way: >>>>> Create a new function similar to devctl_notify but with the first >>> argument >>>>> being >>>>> an enum. >>>>>=20 >>>>=20 >>>> I'm a pretty hard no on the enum. I rejected doing it that way when = I >>> wrote >>>> devd >>>> years ago. These have always been strings, and need to continue to >>> always be >>>> strings, or we're forever modifying devd(8) when we add a new one = and >>>> introducing >>>> yet another opportunity for mismatch. I don't think this is a good = idea >>> at >>>> all. >>>>=20 >>>> There's been users of devd in the past that are loadable modules = that >>> pass >>>> their >>>> own system name in that devd.conf files would then process. Having = an >>> enum >>>> with >>>> enforcement would just get in the way of this. >>>>=20 >>>> I have toyed with the idea of having a centralized list in bus.h = that's a >>>> bunch of >>>> #defines, ala old-school X11 resources (which this is very very = loosely >>>> based on), >>>> but it didn't seem worth the effort. >>>=20 >>> That is fine with me and actually I do need the string name to = register as >>> group >>> name, that I didn't want to trash the strings away. >>>=20 >>> But I need a way to list them all. >>>=20 >>=20 >> We have no current mechanism to do that. We could add something that = would >> register / deregister them with a sysinit + call to something in >> kern_devctl.c which >> could do the trick (and also deal with the ordering issues), though = having >> netlink(4) >> as a loadable modules might be an interesting case to get right. >>=20 >> If we did that, we could return a 'token' that you'd use to call a = new >> version of >> devctl_notify(), perhaps with some glue for legacy users (or perhaps = not: >> we change >> kernel interfaces all the time, and could just rename it and convert >> everything in the >> tree). >>=20 >>>=20 >>>>=20 >>>>> Make the current devctl_notify convert its first argument into = that >>> enum >>>>> and >>>>> yell if an unkwown "system" is passed. (and probably declare >>> devctl_notify >>>>> deprecated) >>>>>=20 >>>>=20 >>>> I don't think this buys us anything. devctl_notify cannot possibly = know >>>> about all >>>> the possible subsystems, so this is likely doomed to high = maintenance >>> that >>>> would >>>> be largely ineffective. >>>>=20 >>>> Then fix the inconsistencies: all upper case as it seems the most = wildly >>> use >>>>> case >>>>> s/kern/kernel/g >>>>>=20 >>>>> WDYT? >>>>>=20 >>>>=20 >>>> I wouldn't worry about the upper vs lower case. All the documented = ones >>> are >>>> upper case, except kernel. There's no harm it being one exception = since >>>> changing >>>> it will break user's devd.conf setups. I got enough feedback when I >>> changed >>>> "kern" to "kernel" last year for power events. And as far as I = know, I've >>>> documented >>>> all the events that are generated today. >>>>=20 >>>> Warner >>>=20 >>>=20 >>> Note that if you think nlsysevent is a bad idea, I will just forget = about >>> it. >>>=20 >>=20 >> I love the idea. I got over any resistance I had when melifaro@ moved >> things into kern_devctl.c and we talked through the issues at that = time. >> I've been hoping that someone would replace the hacky thing I did = with >> a 'routing socket'-like interface (I never could figure out hose to = do it so >> many years ago w/o gross hacks). netlink(4) has finally provided a = way >> to do it that doesn't get the routing code all jumbled up for this. >>=20 >> I just have some specific issues with your proposal. In hindsight, I = should >> have led with that in my first message :). >>=20 >> Warner >=20 > Here is my new proposal: >=20 > What about: >=20 > 1. I add a static list of systems in sys/devctl.h something like >=20 > enum { > DEVCTL_SYSTEM_ACPI =3D 0, > DEVCTL_SYSTEM_AEON =3D 1, > ... > DEVCTL_SYSTEM_ZFS =3D 19 > }; >=20 > static const char *devctl_systems[] =3D { > "ACPI", > "AEON", > ... > "ZFS", > }; >=20 > this way we have a list of official freebsd's systems. > We don't change the devctl_notify interface >=20 > and in the kernel we change the devctl_notify("ZFS" into > devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],... >=20 > This is not too intrusive, and breaks none of the existing code >=20 > 2. I also hook devadq using the same interface as I already have done, = but > all the attach,detach,nomatch become an event (only in nlsysevent) in = the > "DEVICE" system, > the "SUBSYSTEM" is the current what of devaddq >=20 > The type is changed into: > + -> ATTACH > - -> DETACH > anythingelse -> NOMATCH > and the reste of the current line becomes the data >=20 > so from nlsysvent point of view this is exactly the same kind of = events as the > one hooked in devctl_notify. >=20 > 3. in nlsysevent we have one category one can subscribe per known = systems. > All other "systems" falls into a new category named "extra" "vendor" = or "other" >=20 > from the consumer point of view the name of the system is anyway = contained in > the message itself, so the category it is subscribed to can differ. >=20 > This way, I should be able to get ALL the events in a consistent way. > I should be compatible with people who uses devctl_notify in their = custom kernel > modules. >=20 > Sounds easy enough without the requirement of complexifying = kern_devctl.c with a > registration of extra systems. >=20 > What do you think? My 2 cents: I=E2=80=99d look at the groups from the customer (e.g. userland API = POV). IMHO, fine-grained groups serves 2 purposes. The first is limiting the amount of notifications the app has to deal = with. The second is moving filtering from the application to the kernel, so the app doesn=E2=80=99t need to check the = event=E2=80=99s subsystem. Note that the second part loses its value if = the app subscribes for more than one group. It is also worth noting that _some_ notifications, like ifnet event, may = be high-volume, so it can be desirable to have a way to filter them out. For example, it can be implemented as a fixed number of broad group = categories (=E2=80=9Cnet=E2=80=9D, =E2=80=9Cdevice=E2=80=9D, =E2=80=9Cfs=E2= =80=9D, =E2=80=9Cpower=E2=80=9D, =E2=80=9Cvendor=E2=80=9D) and each = subsystem picks one it belongs to. It can be potentially extended with an ability to register custom groups = if so desired. I wouldn=E2=80=99t say the existing KPI consisting of a single = devctl_notify() is set in stone. I=E2=80=99d actually vote to have a new = function/set of functions, as the notifications are no longer limited to = the devices, as devctl suggests. For example (just to illustrate the point): group_id =3D unotify_get_group(=E2=80=9Cpower=E2=80=9D) # gets existing = or registers new group in the netlink subsystem unotify_broadcast(group_id, =E2=80=9CACPI=E2=80=9D, =E2=80=A6) unotify_free_group(group_id) >=20 > Best regards, > Bapt >=20 From nobody Sat Dec 10 05:09:49 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NTbYR42LTz4kbwj for ; Sat, 10 Dec 2022 05:10:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NTbYQ3X8Rz3K5y for ; Sat, 10 Dec 2022 05:10:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=gmQHyZ+T; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2a00:1450:4864:20::62d) smtp.mailfrom=wlosh@bsdimp.com; dmarc=none Received: by mail-ej1-x62d.google.com with SMTP id fc4so15930723ejc.12 for ; Fri, 09 Dec 2022 21:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EPD++tWuKduFjcMLO8Vx9AuJUvycQ2HVvplnWn/c16Q=; b=gmQHyZ+Ti8vxrSJts/KyvSRSsnqNyG7oHVE7qqhNmB+4jvmNOMBMsx6YfdU5FtuahE rqlHi07EdaNizj6YrSOSnR4cRhhKGYWFZPkdGr89nRVIxJMzTrrp5bOVNtkWJM5/5WpQ bdba+sqdemYRuqRjd1XXn1rhXrU81aQNugUNhoMnptOpiUOLFNwa/otQ9wUqMdALm7Q5 gjvWZkxRV0pQOrS5r7cx/DCpXCPAXbDcgmSZwaetneLyU6J+wPHShRtYg+NrUxoil/yp zyUvcLQvkNF5kzWg4/wUSDxutjCwmddOcFbBq+Nv7/n6L6Lcq4kAHsiwJm+mr69FP3VR Qdjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EPD++tWuKduFjcMLO8Vx9AuJUvycQ2HVvplnWn/c16Q=; b=KGb9c41rVPmWtMSx88ufpanR+avaeYfhHWl4hSyfcWGa4CJ/a5+xFpHp/42gMX8sE7 Fo123FN2fRZFYnBeihLM91czOgTMhDO4GTg8+bau5jw83m70I7XBZcBRPDkENdQZWKtK cEnlPFlYopZRaJ9Xf+Ra+miwzT4CrtdYxSSgfmr806cd2qry1ar+HfCzcmG0XXAgmVvv yM2S8dCFxYldLArv4cVBd6e9ojll0XTL7pWcsmdyNNuFIqxnMYKxUWlWSuZ9cL8vYGzz 7SxV0tGMPRgJhx5TkSDqBkruih7W6zvfMfH+970cXFxrz5he+O+6t2+jcJqmo4lpHuzu 7Rng== X-Gm-Message-State: ANoB5pn0bZVi+nq6CkVJ6HCnZp0nB7uFCKKs8gWN1KAE+0uFZetZ+CKt fmaz0ny2poKopW/fUAhQx9zabpJt7m7VYBi9Fe13mwb049+9fw== X-Google-Smtp-Source: AA0mqf6DCNbS4EMNvqzYMfpA5+qUFBQV1SIkZUUnoX5VaeQLiBekG7yhRyB3+O0RxsyHaoQcxPt0nq2OmcImCPARkLA= X-Received: by 2002:a17:906:f84d:b0:7b9:631b:7dfb with SMTP id ks13-20020a170906f84d00b007b9631b7dfbmr62325151ejb.32.1670649001014; Fri, 09 Dec 2022 21:10:01 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> In-Reply-To: <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> From: Warner Losh Date: Fri, 9 Dec 2022 22:09:49 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: Baptiste Daroussin Cc: hackers@freebsd.org Content-Type: multipart/alternative; boundary="0000000000004012d805ef7248a6" X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62d:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NTbYQ3X8Rz3K5y X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000004012d805ef7248a6 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 1, 2022 at 10:40 AM Baptiste Daroussin wrote: > On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote: > > On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin > wrote: > > > > > On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > > > > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > After the addition of netlink(4) by melifaro@, I started working > on a > > > new > > > > > genetlink(4) module, to send kernel notification to the userland > via > > > > > netlink. > > > > > > > > > > The goal is to be able to have multiple consumers without the need > of > > > devd > > > > > to be > > > > > running. > > > > > > > > > > The goal is also to be able subscribe to the events the consumer is > > > > > willing to > > > > > receive. > > > > > > > > > > https://reviews.freebsd.org/D37574 > > > > > > > > > > I also added a hook to devctl_notify to make sure all its event got > > > sent > > > > > via > > > > > nlsysevent. (https://reviews.freebsd.org/D37573) > > > > > > > > > > > > > You're connecting it at the wrong level: it will miss all device > events. > > > > devctl_notify > > > > is used by everything except newbus's device attach, detach and > nomatch > > > > events, so none of those events will make it through. > > > > > > Where should I hook to get the device events? > > > > > > > Either you need to drop down a level to where the formated events are > > queued, > > or you'll need to add something in devaddq() to deal with the events. > These > > are > > a slightly different format than the devctl_notify() events because the > > latter was > > added later and I didn't want to cope with transitioning the old > formatted > > messages > > to the new at that time (silly me). > > > > > > > > > > > > > > > > > It works great and so far I am happy with it. on thing I figured > out > > > it is: > > > > > the "system" argment of devctl_notify is inconsistent: > > > > > Upper case vs lower case > > > > > "kern" vs "kernel" > > > > > > > > > > > > > They are consistent. With one exception that I deprecated in 13.x to > be > > > > removed in 14.x. I documented all of them at the time in devd.conf. I > > > think > > > > I'll go ahead and complete the deprecation. > > > > > > > > > > > > > I intent to fix the following way: > > > > > Create a new function similar to devctl_notify but with the first > > > argument > > > > > being > > > > > an enum. > > > > > > > > > > > > > I'm a pretty hard no on the enum. I rejected doing it that way when I > > > wrote > > > > devd > > > > years ago. These have always been strings, and need to continue to > > > always be > > > > strings, or we're forever modifying devd(8) when we add a new one and > > > > introducing > > > > yet another opportunity for mismatch. I don't think this is a good > idea > > > at > > > > all. > > > > > > > > There's been users of devd in the past that are loadable modules that > > > pass > > > > their > > > > own system name in that devd.conf files would then process. Having an > > > enum > > > > with > > > > enforcement would just get in the way of this. > > > > > > > > I have toyed with the idea of having a centralized list in bus.h > that's a > > > > bunch of > > > > #defines, ala old-school X11 resources (which this is very very > loosely > > > > based on), > > > > but it didn't seem worth the effort. > > > > > > That is fine with me and actually I do need the string name to > register as > > > group > > > name, that I didn't want to trash the strings away. > > > > > > But I need a way to list them all. > > > > > > > We have no current mechanism to do that. We could add something that > would > > register / deregister them with a sysinit + call to something in > > kern_devctl.c which > > could do the trick (and also deal with the ordering issues), though > having > > netlink(4) > > as a loadable modules might be an interesting case to get right. > > > > If we did that, we could return a 'token' that you'd use to call a new > > version of > > devctl_notify(), perhaps with some glue for legacy users (or perhaps not: > > we change > > kernel interfaces all the time, and could just rename it and convert > > everything in the > > tree). > > > > > > > > > > > > > > Make the current devctl_notify convert its first argument into that > > > enum > > > > > and > > > > > yell if an unkwown "system" is passed. (and probably declare > > > devctl_notify > > > > > deprecated) > > > > > > > > > > > > > I don't think this buys us anything. devctl_notify cannot possibly > know > > > > about all > > > > the possible subsystems, so this is likely doomed to high maintenance > > > that > > > > would > > > > be largely ineffective. > > > > > > > > Then fix the inconsistencies: all upper case as it seems the most > wildly > > > use > > > > > case > > > > > s/kern/kernel/g > > > > > > > > > > WDYT? > > > > > > > > > > > > > I wouldn't worry about the upper vs lower case. All the documented > ones > > > are > > > > upper case, except kernel. There's no harm it being one exception > since > > > > changing > > > > it will break user's devd.conf setups. I got enough feedback when I > > > changed > > > > "kern" to "kernel" last year for power events. And as far as I know, > I've > > > > documented > > > > all the events that are generated today. > > > > > > > > Warner > > > > > > > > > Note that if you think nlsysevent is a bad idea, I will just forget > about > > > it. > > > > > > > I love the idea. I got over any resistance I had when melifaro@ moved > > things into kern_devctl.c and we talked through the issues at that time. > > I've been hoping that someone would replace the hacky thing I did with > > a 'routing socket'-like interface (I never could figure out hose to do > it so > > many years ago w/o gross hacks). netlink(4) has finally provided a way > > to do it that doesn't get the routing code all jumbled up for this. > > > > I just have some specific issues with your proposal. In hindsight, I > should > > have led with that in my first message :). > > > > Warner > > Here is my new proposal: > > What about: > > 1. I add a static list of systems in sys/devctl.h something like > > enum { > DEVCTL_SYSTEM_ACPI = 0, > DEVCTL_SYSTEM_AEON = 1, > ... > DEVCTL_SYSTEM_ZFS = 19 > }; > > static const char *devctl_systems[] = { > "ACPI", > "AEON", > ... > "ZFS", > }; > > this way we have a list of official freebsd's systems. > We don't change the devctl_notify interface > > and in the kernel we change the devctl_notify("ZFS" into > devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],... > > This is not too intrusive, and breaks none of the existing code > So what happens if you see one not in the list? > 2. I also hook devadq using the same interface as I already have done, but > all the attach,detach,nomatch become an event (only in nlsysevent) in the > "DEVICE" system, > the "SUBSYSTEM" is the current what of devaddq > > The type is changed into: > + -> ATTACH > - -> DETACH > anythingelse -> NOMATCH > and the rest of the current line becomes the data > This is fine. I kinda think it might not be terrible to expose this to devd and have it cope, but that's a zero sum for not a lot of gain. so from nlsysvent point of view this is exactly the same kind of events as > the > one hooked in devctl_notify. > Sure. > 3. in nlsysevent we have one category one can subscribe per known systems. > All other "systems" falls into a new category named "extra" "vendor" or > "other" > So all events that match elements of the array are 'system' and the others are something else? > from the consumer point of view the name of the system is anyway contained > in > the message itself, so the category it is subscribed to can differ. > Right. No data is lost... > This way, I should be able to get ALL the events in a consistent way. > I should be compatible with people who uses devctl_notify in their custom > kernel > modules. > Yea. > Sounds easy enough without the requirement of complexifying kern_devctl.c > with a > registration of extra systems. > Yea, I kinda prefer that... Unless we add too many new systems. It's still extra work to add one, but likely not enough extra to be worth the automation. > What do you think? > Not bad. Warner --0000000000004012d805ef7248a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 1, 2022 at 10:40 AM Bapti= ste Daroussin <bapt@freebsd.org&= gt; wrote:
On Th= u, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote:
> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin <bapt@freebsd.org> wrote:
>
> > On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote:
> > > On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > After the addition of netlink(4) by melifaro@, I starte= d working on a
> > new
> > > > genetlink(4) module, to send kernel notification to the= userland via
> > > > netlink.
> > > >
> > > > The goal is to be able to have multiple consumers witho= ut the need of
> > devd
> > > > to be
> > > > running.
> > > >
> > > > The goal is also to be able subscribe to the events the= consumer is
> > > > willing to
> > > > receive.
> > > >
> > > > https://reviews.freebsd.org/D37574
> > > >
> > > > I also added a hook to devctl_notify to make sure all i= ts event got
> > sent
> > > > via
> > > > nlsysevent. (https://reviews.freebsd.org/D3757= 3)
> > > >
> > >
> > > You're connecting it at the wrong level: it will miss al= l device events.
> > > devctl_notify
> > > is used by everything except newbus's device attach, det= ach and nomatch
> > > events, so none of those events will make it through.
> >
> > Where should I hook to get the device events?
> >
>
> Either you need to drop down a level to where the formated events are<= br> > queued,
> or you'll need to add something in devaddq() to deal with the even= ts. These
> are
> a slightly different format than the devctl_notify() events because th= e
> latter was
> added later and I didn't want to cope with transitioning the old f= ormatted
> messages
> to the new at that time (silly me).
>
>
> > >
> > >
> > > > It works great and so far I am happy with it. on thing = I figured out
> > it is:
> > > > the "system" argment of devctl_notify is inco= nsistent:
> > > > Upper case vs lower case
> > > > "kern" vs "kernel"
> > > >
> > >
> > > They are consistent. With one exception that I deprecated in= 13.x to be
> > > removed in 14.x. I documented all of them at the time in dev= d.conf. I
> > think
> > > I'll go ahead and complete the deprecation.
> > >
> > >
> > > > I intent to fix the following way:
> > > > Create a new function similar to devctl_notify but with= the first
> > argument
> > > > being
> > > > an enum.
> > > >
> > >
> > > I'm a pretty hard no on the enum. I rejected doing it th= at way when I
> > wrote
> > > devd
> > > years ago. These have always been strings, and need to conti= nue to
> > always be
> > > strings, or we're forever modifying devd(8) when we add = a new one and
> > > introducing
> > > yet another opportunity for mismatch. I don't think this= is a good idea
> > at
> > > all.
> > >
> > > There's been users of devd in the past that are loadable= modules that
> > pass
> > > their
> > > own system name in that devd.conf files would then process. = Having an
> > enum
> > > with
> > > enforcement would just get in the way of this.
> > >
> > > I have toyed with the idea of having a centralized list in b= us.h that's a
> > > bunch of
> > > #defines, ala old-school X11 resources (which this is very v= ery loosely
> > > based on),
> > > but it didn't seem worth the effort.
> >
> > That is fine with me and actually I do need the string name to re= gister as
> > group
> > name, that I didn't want to trash the strings away.
> >
> > But I need a way to list them all.
> >
>
> We have no current mechanism to do that. We could add something that w= ould
> register / deregister them with a sysinit + call to something in
> kern_devctl.c which
> could do the trick (and also deal with the ordering issues), though ha= ving
> netlink(4)
> as a loadable modules might be an interesting case to get right.
>
> If we did that, we could return a 'token' that you'd use t= o call a new
> version of
> devctl_notify(), perhaps with some glue for legacy users (or perhaps n= ot:
> we change
> kernel interfaces all the time, and could just rename it and convert > everything in the
> tree).
>
> >
> > >
> > > > Make the current devctl_notify convert its first argume= nt into that
> > enum
> > > > and
> > > > yell if an unkwown "system" is passed. (and p= robably declare
> > devctl_notify
> > > > deprecated)
> > > >
> > >
> > > I don't think this buys us anything. devctl_notify canno= t possibly know
> > > about all
> > > the possible subsystems, so this is likely doomed to high ma= intenance
> > that
> > > would
> > > be largely ineffective.
> > >
> > > Then fix the inconsistencies: all upper case as it seems the= most wildly
> > use
> > > > case
> > > > s/kern/kernel/g
> > > >
> > > > WDYT?
> > > >
> > >
> > > I wouldn't worry about the upper vs lower case. All the = documented ones
> > are
> > > upper case, except kernel. There's no harm it being one = exception since
> > > changing
> > > it will break user's devd.conf setups. I got enough feed= back when I
> > changed
> > > "kern" to "kernel" last year for power e= vents. And as far as I know, I've
> > > documented
> > > all the events that are generated today.
> > >
> > > Warner
> >
> >
> > Note that if you think nlsysevent is a bad idea, I will just forg= et about
> > it.
> >
>
> I love the idea. I got over any resistance I had when melifaro@ moved<= br> > things into kern_devctl.c and we talked through the issues at that tim= e.
> I've been hoping that someone would replace the hacky thing I did = with
> a 'routing socket'-like interface (I never could figure out ho= se to do it so
> many years ago w/o gross hacks). netlink(4) has finally provided a way=
> to do it that doesn't get the routing code all jumbled up for this= .
>
> I just have some specific issues with your proposal. In hindsight, I s= hould
> have led with that in my first message :).
>
> Warner

Here is my new proposal:

What about:

1. I add a static list of systems in sys/devctl.h something like

enum {
=C2=A0DEVCTL_SYSTEM_ACPI =3D 0,
=C2=A0DEVCTL_SYSTEM_AEON =3D 1,
=C2=A0...
=C2=A0DEVCTL_SYSTEM_ZFS =3D 19
};

static const char *devctl_systems[] =3D {
=C2=A0 "ACPI",
=C2=A0 "AEON",
=C2=A0 ...
=C2=A0 "ZFS",
};

this way we have a list of official freebsd's systems.
We don't change the devctl_notify interface

and in the kernel we change the devctl_notify("ZFS" into
devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],...

This is not too intrusive, and breaks none of the existing code

So what happens if you see one not in the list?
=C2=A0
2. I also hook devadq using the same interface as I already have done, but<= br> all the attach,detach,nomatch become an event (only in nlsysevent) in the "DEVICE" system,
the "SUBSYSTEM" is the current what of devaddq

The type is changed into:
+ -> ATTACH
- -> DETACH
anythingelse -> NOMATCH
and the rest of the current line becomes the data

=
This is fine. I kinda think it might not be terrible to expose t= his to devd and have it cope, but that's a zero sum for not a lot of ga= in.

s= o from nlsysvent point of view this is exactly the same kind of events as t= he
one hooked in devctl_notify.

Sure.
=C2=A0
3. in nlsysevent we have one category one can subscribe per known systems.<= br> All other "systems" falls into a new category named "extra&q= uot; "vendor" or "other"

So all events that match elements of the array are 'system' a= nd the others are something else?
=C2=A0
from the consumer point of view the name of the system is anyway contained = in
the message itself, so the category it is subscribed to can differ.

Right. No data is lost...
=C2=A0
This way, I should be able to get ALL the events in a consistent way.
I should be compatible with people who uses devctl_notify in their custom k= ernel
modules.

Yea.=C2=A0
=C2=A0
Sounds easy enough without the requirement of complexifying kern_devctl.c w= ith a
registration of extra systems.

Yea, I k= inda prefer that... Unless we add too many new systems. It's still extr= a work to add one, but likely not enough extra to be worth the automation.<= /div>
=C2=A0
What do you think?

Not bad.
<= br>
Warner=C2=A0
--0000000000004012d805ef7248a6-- From nobody Sat Dec 10 05:13:11 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NTbdJ63GVz4kcN2 for ; Sat, 10 Dec 2022 05:13:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NTbdJ3YnVz3LGm for ; Sat, 10 Dec 2022 05:13:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x630.google.com with SMTP id gh17so16013113ejb.6 for ; Fri, 09 Dec 2022 21:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rYQE57+RDTI9/saLqypmDwmpunM/SGjT9YvuFtntVQ0=; b=0Z+DqEmLKFk44sv0YNm5fi240j1oJafN3Cv5ikJ2tBkDNEEi9V1sQz5XfWshPw3Aax 1TkotzysDctZGlQQyiW/lrABWkRrrQVp5z7ROLtI2sW5DmW7a9AoVpzi6e4G2jvd4VTp thRmMy/VRDSnohzq8uTTNd1bXBTa7LsTj5pmsvLOcXfc6KL2zjDK6iij+qnQBUpLBnAV VARj33KFqkpXhHW18nEml6sMhw5hinRVtikFoPSBBMBVL1G4aY2BYoNYbpObF0MPVFJD cIC0AccAerRym7bIDOLUxr1wb1Rn7ktyvrT7xJW8kXxrRkv7dllr2a2S6rLLIOdmBp7x FGnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rYQE57+RDTI9/saLqypmDwmpunM/SGjT9YvuFtntVQ0=; b=Gdgut5A3jvSH119eUplhvlqnObYUlSZW6atjB8VuGVj7M4ntB0ReMcb12HHKg6GeW1 Cjqwsh8ZqPr/ltAl9UCMus7OHK5cDCbG2uVQZ1iV4SV86yIX6IBaQDw+cqYr2PESjy24 PRZ9hlMuiubQRWYZj/5VLC/L2yYfAW7FgERMxroqUSpXlgFgBgTUaZVnkVsllCT2yo0j 88nurnJ3o4jo2nQ7I1s9ceQbLaaJqxWjTFjSbQ5IhjZsUk0q9DhiHealt/ZNB2wE1FY6 e/AjffoLaME1xqYFf1J+NoIUDdN8VhmxkiTJgike1hwwaa7crJ2Tzig+cnNM7ito/y86 KAOw== X-Gm-Message-State: ANoB5pkFBifWORnSZ89QU+ci2fGwkHExw/xesYTxBUPO7eYNpCTmUZiC ZlMRuhGABbkeBkKE01QCZ40b4pS/68r0l9KmalZh66xwH66E4A== X-Google-Smtp-Source: AA0mqf6Ocj1dQa8T7GVOiI960cvOxTRcSl5USUpyXr3Ee30bB2W+OAwLBTzsYn5OAdBjP1LeweOICJY2zZjMpU9ZJgs= X-Received: by 2002:a17:906:5a0c:b0:7c0:faca:4d5e with SMTP id mx12-20020a1709065a0c00b007c0faca4d5emr12432272ejc.140.1670649202442; Fri, 09 Dec 2022 21:13:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <20221201083559.xx3v5jn7sf44rfmv@aniel.nours.eu> <20221201145905.ua2jlh25usqrqjy4@aniel.nours.eu> <20221201174043.5yqtfbs6p63bdgqp@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Fri, 9 Dec 2022 22:13:11 -0700 Message-ID: Subject: Re: devctl_notify system is inconsistent To: "Alexander V. Chernikov" Cc: Baptiste Daroussin , hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000419eab05ef7254b6" X-Rspamd-Queue-Id: 4NTbdJ3YnVz3LGm X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000419eab05ef7254b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 9, 2022 at 8:26 AM Alexander V. Chernikov wrote: > > > > On 1 Dec 2022, at 17:40, Baptiste Daroussin wrote: > > > > On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote: > >> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin > wrote: > >> > >>> On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: > >>>> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin > >>> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> After the addition of netlink(4) by melifaro@, I started working on > a > >>> new > >>>>> genetlink(4) module, to send kernel notification to the userland vi= a > >>>>> netlink. > >>>>> > >>>>> The goal is to be able to have multiple consumers without the need = of > >>> devd > >>>>> to be > >>>>> running. > >>>>> > >>>>> The goal is also to be able subscribe to the events the consumer is > >>>>> willing to > >>>>> receive. > >>>>> > >>>>> https://reviews.freebsd.org/D37574 > >>>>> > >>>>> I also added a hook to devctl_notify to make sure all its event got > >>> sent > >>>>> via > >>>>> nlsysevent. (https://reviews.freebsd.org/D37573) > >>>>> > >>>> > >>>> You're connecting it at the wrong level: it will miss all device > events. > >>>> devctl_notify > >>>> is used by everything except newbus's device attach, detach and > nomatch > >>>> events, so none of those events will make it through. > >>> > >>> Where should I hook to get the device events? > >>> > >> > >> Either you need to drop down a level to where the formated events are > >> queued, > >> or you'll need to add something in devaddq() to deal with the events. > These > >> are > >> a slightly different format than the devctl_notify() events because th= e > >> latter was > >> added later and I didn't want to cope with transitioning the old > formatted > >> messages > >> to the new at that time (silly me). > >> > >> > >>>> > >>>> > >>>>> It works great and so far I am happy with it. on thing I figured ou= t > >>> it is: > >>>>> the "system" argment of devctl_notify is inconsistent: > >>>>> Upper case vs lower case > >>>>> "kern" vs "kernel" > >>>>> > >>>> > >>>> They are consistent. With one exception that I deprecated in 13.x to > be > >>>> removed in 14.x. I documented all of them at the time in devd.conf. = I > >>> think > >>>> I'll go ahead and complete the deprecation. > >>>> > >>>> > >>>>> I intent to fix the following way: > >>>>> Create a new function similar to devctl_notify but with the first > >>> argument > >>>>> being > >>>>> an enum. > >>>>> > >>>> > >>>> I'm a pretty hard no on the enum. I rejected doing it that way when = I > >>> wrote > >>>> devd > >>>> years ago. These have always been strings, and need to continue to > >>> always be > >>>> strings, or we're forever modifying devd(8) when we add a new one an= d > >>>> introducing > >>>> yet another opportunity for mismatch. I don't think this is a good > idea > >>> at > >>>> all. > >>>> > >>>> There's been users of devd in the past that are loadable modules tha= t > >>> pass > >>>> their > >>>> own system name in that devd.conf files would then process. Having a= n > >>> enum > >>>> with > >>>> enforcement would just get in the way of this. > >>>> > >>>> I have toyed with the idea of having a centralized list in bus.h > that's a > >>>> bunch of > >>>> #defines, ala old-school X11 resources (which this is very very > loosely > >>>> based on), > >>>> but it didn't seem worth the effort. > >>> > >>> That is fine with me and actually I do need the string name to > register as > >>> group > >>> name, that I didn't want to trash the strings away. > >>> > >>> But I need a way to list them all. > >>> > >> > >> We have no current mechanism to do that. We could add something that > would > >> register / deregister them with a sysinit + call to something in > >> kern_devctl.c which > >> could do the trick (and also deal with the ordering issues), though > having > >> netlink(4) > >> as a loadable modules might be an interesting case to get right. > >> > >> If we did that, we could return a 'token' that you'd use to call a new > >> version of > >> devctl_notify(), perhaps with some glue for legacy users (or perhaps > not: > >> we change > >> kernel interfaces all the time, and could just rename it and convert > >> everything in the > >> tree). > >> > >>> > >>>> > >>>>> Make the current devctl_notify convert its first argument into that > >>> enum > >>>>> and > >>>>> yell if an unkwown "system" is passed. (and probably declare > >>> devctl_notify > >>>>> deprecated) > >>>>> > >>>> > >>>> I don't think this buys us anything. devctl_notify cannot possibly > know > >>>> about all > >>>> the possible subsystems, so this is likely doomed to high maintenanc= e > >>> that > >>>> would > >>>> be largely ineffective. > >>>> > >>>> Then fix the inconsistencies: all upper case as it seems the most > wildly > >>> use > >>>>> case > >>>>> s/kern/kernel/g > >>>>> > >>>>> WDYT? > >>>>> > >>>> > >>>> I wouldn't worry about the upper vs lower case. All the documented > ones > >>> are > >>>> upper case, except kernel. There's no harm it being one exception > since > >>>> changing > >>>> it will break user's devd.conf setups. I got enough feedback when I > >>> changed > >>>> "kern" to "kernel" last year for power events. And as far as I know, > I've > >>>> documented > >>>> all the events that are generated today. > >>>> > >>>> Warner > >>> > >>> > >>> Note that if you think nlsysevent is a bad idea, I will just forget > about > >>> it. > >>> > >> > >> I love the idea. I got over any resistance I had when melifaro@ moved > >> things into kern_devctl.c and we talked through the issues at that tim= e. > >> I've been hoping that someone would replace the hacky thing I did with > >> a 'routing socket'-like interface (I never could figure out hose to do > it so > >> many years ago w/o gross hacks). netlink(4) has finally provided a way > >> to do it that doesn't get the routing code all jumbled up for this. > >> > >> I just have some specific issues with your proposal. In hindsight, I > should > >> have led with that in my first message :). > >> > >> Warner > > > > Here is my new proposal: > > > > What about: > > > > 1. I add a static list of systems in sys/devctl.h something like > > > > enum { > > DEVCTL_SYSTEM_ACPI =3D 0, > > DEVCTL_SYSTEM_AEON =3D 1, > > ... > > DEVCTL_SYSTEM_ZFS =3D 19 > > }; > > > > static const char *devctl_systems[] =3D { > > "ACPI", > > "AEON", > > ... > > "ZFS", > > }; > > > > this way we have a list of official freebsd's systems. > > We don't change the devctl_notify interface > > > > and in the kernel we change the devctl_notify("ZFS" into > > devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],... > > > > This is not too intrusive, and breaks none of the existing code > > > > 2. I also hook devadq using the same interface as I already have done, > but > > all the attach,detach,nomatch become an event (only in nlsysevent) in t= he > > "DEVICE" system, > > the "SUBSYSTEM" is the current what of devaddq > > > > The type is changed into: > > + -> ATTACH > > - -> DETACH > > anythingelse -> NOMATCH > > and the reste of the current line becomes the data > > > > so from nlsysvent point of view this is exactly the same kind of events > as the > > one hooked in devctl_notify. > > > > 3. in nlsysevent we have one category one can subscribe per known > systems. > > All other "systems" falls into a new category named "extra" "vendor" or > "other" > > > > from the consumer point of view the name of the system is anyway > contained in > > the message itself, so the category it is subscribed to can differ. > > > > This way, I should be able to get ALL the events in a consistent way. > > I should be compatible with people who uses devctl_notify in their > custom kernel > > modules. > > > > Sounds easy enough without the requirement of complexifying > kern_devctl.c with a > > registration of extra systems. > > > > What do you think? > My 2 cents: > > I=E2=80=99d look at the groups from the customer (e.g. userland API POV).= IMHO, > fine-grained groups serves 2 purposes. > The first is limiting the amount of notifications the app has to deal wit= h. Yea, that breaks devd. It assumes it can 'catch up' on events that happened before it got around to running and registering. > The second is moving filtering from the > application to the kernel, so the app doesn=E2=80=99t need to check the e= vent=E2=80=99s > subsystem. Note that the second part loses its value if the app subscribe= s > for more than one group. > It is also worth noting that _some_ notifications, like ifnet event, may > be high-volume, so it can be desirable to have a way to filter them out. > For example, it can be implemented as a fixed number of broad group > categories (=E2=80=9Cnet=E2=80=9D, =E2=80=9Cdevice=E2=80=9D, =E2=80=9Cfs= =E2=80=9D, =E2=80=9Cpower=E2=80=9D, =E2=80=9Cvendor=E2=80=9D) and each subs= ystem > picks one it belongs to. > It can be potentially extended with an ability to register custom groups > if so desired. > I wouldn=E2=80=99t say the existing KPI consisting of a single devctl_not= ify() is > set in stone. I=E2=80=99d actually vote to have a new function/set of fun= ctions, as > the notifications are no longer limited to the devices, as devctl suggest= s. > I'm not sure I see the value in kernel filtering. The data rates are low. The number of apps is also low, so the savings is tiny today. > For example (just to illustrate the point): > group_id =3D unotify_get_group(=E2=80=9Cpower=E2=80=9D) # gets existing o= r registers new > group in the netlink subsystem > unotify_broadcast(group_id, =E2=80=9CACPI=E2=80=9D, =E2=80=A6) > unotify_free_group(group_id) > I see no value in this with the current base of consumers / producers. It sounds cool, but at the present time the data rates are so low that the extra complexity of filtering in the kernel likely would dwarf doing it in userland. Warner > > > > Best regards, > > Bapt > > > > --000000000000419eab05ef7254b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 9, 2022 at 8:26 AM Alexan= der V. Chernikov <melifaro@ipfw.ru> wrote:

> On 1 Dec 2022, at 17:40, Baptiste Daroussin <bapt@FreeBSD.org> w= rote:
>
> On Thu, Dec 01, 2022 at 08:38:37AM -0700, Warner Losh wrote:
>> On Thu, Dec 1, 2022 at 7:59 AM Baptiste Daroussin <bapt@freebsd.org> wrote: >>
>>> On Thu, Dec 01, 2022 at 07:45:32AM -0700, Warner Losh wrote: >>>> On Thu, Dec 1, 2022 at 1:36 AM Baptiste Daroussin <bapt@freebsd.org><= br> >>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> After the addition of netlink(4) by melifaro@, I start= ed working on a
>>> new
>>>>> genetlink(4) module, to send kernel notification to th= e userland via
>>>>> netlink.
>>>>>
>>>>> The goal is to be able to have multiple consumers with= out the need of
>>> devd
>>>>> to be
>>>>> running.
>>>>>
>>>>> The goal is also to be able subscribe to the events th= e consumer is
>>>>> willing to
>>>>> receive.
>>>>>
>>>>> https://reviews.freebsd.org/D37574
>>>>>
>>>>> I also added a hook to devctl_notify to make sure all = its event got
>>> sent
>>>>> via
>>>>> nlsysevent. (https://reviews.freebsd.org/D375= 73)
>>>>>
>>>>
>>>> You're connecting it at the wrong level: it will miss = all device events.
>>>> devctl_notify
>>>> is used by everything except newbus's device attach, d= etach and nomatch
>>>> events, so none of those events will make it through.
>>>
>>> Where should I hook to get the device events?
>>>
>>
>> Either you need to drop down a level to where the formated events = are
>> queued,
>> or you'll need to add something in devaddq() to deal with the = events. These
>> are
>> a slightly different format than the devctl_notify() events becaus= e the
>> latter was
>> added later and I didn't want to cope with transitioning the o= ld formatted
>> messages
>> to the new at that time (silly me).
>>
>>
>>>>
>>>>
>>>>> It works great and so far I am happy with it. on thing= I figured out
>>> it is:
>>>>> the "system" argment of devctl_notify is inc= onsistent:
>>>>> Upper case vs lower case
>>>>> "kern" vs "kernel"
>>>>>
>>>>
>>>> They are consistent. With one exception that I deprecated = in 13.x to be
>>>> removed in 14.x. I documented all of them at the time in d= evd.conf. I
>>> think
>>>> I'll go ahead and complete the deprecation.
>>>>
>>>>
>>>>> I intent to fix the following way:
>>>>> Create a new function similar to devctl_notify but wit= h the first
>>> argument
>>>>> being
>>>>> an enum.
>>>>>
>>>>
>>>> I'm a pretty hard no on the enum. I rejected doing it = that way when I
>>> wrote
>>>> devd
>>>> years ago. These have always been strings, and need to con= tinue to
>>> always be
>>>> strings, or we're forever modifying devd(8) when we ad= d a new one and
>>>> introducing
>>>> yet another opportunity for mismatch. I don't think th= is is a good idea
>>> at
>>>> all.
>>>>
>>>> There's been users of devd in the past that are loadab= le modules that
>>> pass
>>>> their
>>>> own system name in that devd.conf files would then process= . Having an
>>> enum
>>>> with
>>>> enforcement would just get in the way of this.
>>>>
>>>> I have toyed with the idea of having a centralized list in= bus.h that's a
>>>> bunch of
>>>> #defines, ala old-school X11 resources (which this is very= very loosely
>>>> based on),
>>>> but it didn't seem worth the effort.
>>>
>>> That is fine with me and actually I do need the string name to= register as
>>> group
>>> name, that I didn't want to trash the strings away.
>>>
>>> But I need a way to list them all.
>>>
>>
>> We have no current mechanism to do that. We could add something th= at would
>> register / deregister them with a sysinit + call to something in >> kern_devctl.c which
>> could do the trick (and also deal with the ordering issues), thoug= h having
>> netlink(4)
>> as a loadable modules might be an interesting case to get right. >>
>> If we did that, we could return a 'token' that you'd u= se to call a new
>> version of
>> devctl_notify(), perhaps with some glue for legacy users (or perha= ps not:
>> we change
>> kernel interfaces all the time, and could just rename it and conve= rt
>> everything in the
>> tree).
>>
>>>
>>>>
>>>>> Make the current devctl_notify convert its first argum= ent into that
>>> enum
>>>>> and
>>>>> yell if an unkwown "system" is passed. (and = probably declare
>>> devctl_notify
>>>>> deprecated)
>>>>>
>>>>
>>>> I don't think this buys us anything. devctl_notify can= not possibly know
>>>> about all
>>>> the possible subsystems, so this is likely doomed to high = maintenance
>>> that
>>>> would
>>>> be largely ineffective.
>>>>
>>>> Then fix the inconsistencies: all upper case as it seems t= he most wildly
>>> use
>>>>> case
>>>>> s/kern/kernel/g
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> I wouldn't worry about the upper vs lower case. All th= e documented ones
>>> are
>>>> upper case, except kernel. There's no harm it being on= e exception since
>>>> changing
>>>> it will break user's devd.conf setups. I got enough fe= edback when I
>>> changed
>>>> "kern" to "kernel" last year for power= events. And as far as I know, I've
>>>> documented
>>>> all the events that are generated today.
>>>>
>>>> Warner
>>>
>>>
>>> Note that if you think nlsysevent is a bad idea, I will just f= orget about
>>> it.
>>>
>>
>> I love the idea. I got over any resistance I had when melifaro@ mo= ved
>> things into kern_devctl.c and we talked through the issues at that= time.
>> I've been hoping that someone would replace the hacky thing I = did with
>> a 'routing socket'-like interface (I never could figure ou= t hose to do it so
>> many years ago w/o gross hacks). netlink(4) has finally provided a= way
>> to do it that doesn't get the routing code all jumbled up for = this.
>>
>> I just have some specific issues with your proposal. In hindsight,= I should
>> have led with that in my first message :).
>>
>> Warner
>
> Here is my new proposal:
>
> What about:
>
> 1. I add a static list of systems in sys/devctl.h something like
>
> enum {
> DEVCTL_SYSTEM_ACPI =3D 0,
> DEVCTL_SYSTEM_AEON =3D 1,
> ...
> DEVCTL_SYSTEM_ZFS =3D 19
> };
>
> static const char *devctl_systems[] =3D {
>=C2=A0 "ACPI",
>=C2=A0 "AEON",
>=C2=A0 ...
>=C2=A0 "ZFS",
> };
>
> this way we have a list of official freebsd's systems.
> We don't change the devctl_notify interface
>
> and in the kernel we change the devctl_notify("ZFS" into
> devctl_notify(devctl_systems[DEVCTL_SYSTEM_ZFS],...
>
> This is not too intrusive, and breaks none of the existing code
>
> 2. I also hook devadq using the same interface as I already have done,= but
> all the attach,detach,nomatch become an event (only in nlsysevent) in = the
> "DEVICE" system,
> the "SUBSYSTEM" is the current what of devaddq
>
> The type is changed into:
> + -> ATTACH
> - -> DETACH
> anythingelse -> NOMATCH
> and the reste of the current line becomes the data
>
> so from nlsysvent point of view this is exactly the same kind of event= s as the
> one hooked in devctl_notify.
>
> 3. in nlsysevent we have one category one can subscribe per known syst= ems.
> All other "systems" falls into a new category named "ex= tra" "vendor" or "other"
>
> from the consumer point of view the name of the system is anyway conta= ined in
> the message itself, so the category it is subscribed to can differ. >
> This way, I should be able to get ALL the events in a consistent way.<= br> > I should be compatible with people who uses devctl_notify in their cus= tom kernel
> modules.
>
> Sounds easy enough without the requirement of complexifying kern_devct= l.c with a
> registration of extra systems.
>
> What do you think?
My 2 cents:

I=E2=80=99d look at the groups from the customer (e.g. userland API POV). I= MHO, fine-grained groups serves 2 purposes.
The first is limiting the amount of notifications the app has to deal with.=

Yea, that breaks devd. It assumes it can &= #39;catch up' on events that happened before it got around to running a= nd registering.
=C2=A0
The second is moving filtering from the
application to the kernel, so the app doesn=E2=80=99t need to check the eve= nt=E2=80=99s subsystem. Note that the second part loses its value if the ap= p subscribes for more than one group.
It is also worth noting that _some_ notifications, like ifnet event, may be= high-volume, so it can be desirable to have a way to filter them out.
For example, it can be implemented as a fixed number of broad group categor= ies (=E2=80=9Cnet=E2=80=9D, =E2=80=9Cdevice=E2=80=9D, =E2=80=9Cfs=E2=80=9D,= =E2=80=9Cpower=E2=80=9D, =E2=80=9Cvendor=E2=80=9D) and each subsystem pick= s one it belongs to.
It can be potentially extended with an ability to register custom groups if= so desired.
I wouldn=E2=80=99t say the existing KPI consisting of a single devctl_notif= y() is set in stone. I=E2=80=99d actually vote to have a new function/set o= f functions, as the notifications are no longer limited to the devices, as = devctl suggests.

I'm not sure I see= the value in kernel filtering. The data rates are low. The number of apps = is also low, so the savings is tiny today.
=C2=A0
For example (just to illustrate the= point):
group_id =3D unotify_get_group(=E2=80=9Cpower=E2=80=9D) # gets existing or = registers new group in the netlink subsystem
unotify_broadcast(group_id, =E2=80=9CACPI=E2=80=9D, =E2=80=A6)
unotify_free_group(group_id)

I see no v= alue in this with the current base of consumers / producers. It sounds cool= , but at the present time the data rates are so low that the extra complexi= ty of filtering in the kernel likely would dwarf doing it in userland.

Warner
=C2=A0
>
> Best regards,
> Bapt
>

--000000000000419eab05ef7254b6-- From nobody Mon Dec 12 02:59:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NVmZC10gxz4jT4x for ; Mon, 12 Dec 2022 02:59:47 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NVmZ96g3Qz4WTR for ; Mon, 12 Dec 2022 02:59:45 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7364F19073 for ; Mon, 12 Dec 2022 03:59:35 +0100 (CET) Received: from shipon.lysator.liu.se (shipon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) (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 mail.lysator.liu.se (Postfix) with ESMTPSA id 71E6219072 for ; Mon, 12 Dec 2022 03:59:35 +0100 (CET) Date: Mon, 12 Dec 2022 03:59:34 +0100 From: Andreas Kempe To: freebsd-hackers@freebsd.org Subject: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.890]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NVmZ96g3Qz4WTR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello everyone, I updated my laptop running geli + UFS to FreeBSD 12.4 and this prevented my computer from booting. Booting failed with the EFI loader not finding my boot disk. Since I can't recall when I last updated my EFI loader, it might have broken before 12.4. Searching the bugtracker, I found bug [1] which seemed relevant so I cherry-picked e417249016efcca73c9edad21b94b1315bc44601 to releng/12.4 and it applied cleanly without any conflict. After the cherry-pick, the loader would once again boot my system. Would it be possible to get this fix imported to the releng/12.4 branch? Best regards, Andreas Kempe [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282 From nobody Mon Dec 12 03:08:58 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NVmp16vkwz4jVml for ; Mon, 12 Dec 2022 03:10:01 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-251.nys.biz.rr.com [24.97.5.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NVmp14b08z4Xdq for ; Mon, 12 Dec 2022 03:10:00 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; none X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from smtpclient.apple (d138.guest.wifi.crossfamilyweb.com [10.1.8.138]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 2BC39dR8070438 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 12 Dec 2022 03:09:40 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d138.guest.wifi.crossfamilyweb.com [10.1.8.138] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Date: Sun, 11 Dec 2022 22:08:58 -0500 Message-Id: References: Cc: freebsd-hackers@freebsd.org In-Reply-To: To: Andreas Kempe X-Mailer: iPhone Mail (20B110) X-Rspamd-Queue-Id: 4NVmp14b08z4Xdq X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N One would hope. This is now the third time this has been reported. At least.= I even personally wrote a draft en for it (for 13.1). And 2 other ENs yet t= o see a release, also with bugs and patches and fixes committed to -CURRENT > On Dec 11, 2022, at 10:00 PM, Andreas Kempe wrote: >=20 > =EF=BB=BFHello everyone, >=20 > I updated my laptop running geli + UFS to FreeBSD 12.4 and this > prevented my computer from booting. Booting failed with the EFI loader > not finding my boot disk. Since I can't recall when I last updated my > EFI loader, it might have broken before 12.4. >=20 > Searching the bugtracker, I found bug [1] which seemed relevant so I > cherry-picked e417249016efcca73c9edad21b94b1315bc44601 to releng/12.4 > and it applied cleanly without any conflict. After the cherry-pick, > the loader would once again boot my system. >=20 > Would it be possible to get this fix imported to the releng/12.4 > branch? >=20 > Best regards, > Andreas Kempe >=20 > [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264282 >=20 From nobody Mon Dec 12 03:29:18 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NVnDX4klzz4jYb0 for ; Mon, 12 Dec 2022 03:29:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NVnDX36M7z4b6s for ; Mon, 12 Dec 2022 03:29:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52a.google.com with SMTP id d14so11049473edj.11 for ; Sun, 11 Dec 2022 19:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NVM/jmJWYmH1NWgZleNIXTQRC/UsAQRyIH10EFD5hEU=; b=st+Ww7PD/4wwkr3xWQE2C9CvoMryVW2C6AWOZPPaxlfc/oqfnQwoOkdcRGpw41dfCr xQ9qfnEOGb0diIBVFJ812bL3YxKZ70yxFUJez/cl4MjzRH56AIoREK5F5ntYHBVvufS5 Ync5ZGyuphlWzES7oR8evi4u1NTVE0NSRD+Q3rZzijhm3fAYCnMdYhfACg2KclcoEFWl cyz27hIE+GziMNlVFHzKWtu2oxfa/jtynmhcMAIVLHoNEu0Z5Avpdw/usdO5N4iMIKW3 4hn7GsVHckPY0SNw08DOgOG99NLag2h2THtQpeeVUA55lEViqe8TtZ5L2wrw6dzWola9 t/MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NVM/jmJWYmH1NWgZleNIXTQRC/UsAQRyIH10EFD5hEU=; b=cbxiI02E6msMo//nqXNPo1d5330IkJjXOT7YZD+TFHRV77cKzvHjclHkPy78rhy70P pbqeuinNW0faT8mBdwLDCgsp3pBN5aAJSmku5CHmSs5+GsqGBhFLSIvPNzq7cbnWYnF+ 2wZtUyEdmEdAn6Jco57HkssXHoFdVM6OolCvp3L/PIk9OJWPfEKI7vK70ApNnjBXmGV9 nei4YnMbStrK0C4UMoY0FVFxhomPMt095F1//TwnySSxfMykq2d+8LtsEgcWlC2dHoGd v3Qfa+kj8qdebATokC7+aNKEMLCzyrIiQrN6vgSx/AkYIjw8nTKvGqB01rj/A26PaOfD jOgg== X-Gm-Message-State: ANoB5plUeuBwlaVqpLw4qyEAp0/DK0jpgO0t+RSD6lkM74rY1dWNiUm4 fwm7qHBel8K5Bpbd5fVOmn7D39emo4IK6qKPWBKP6eW/lNHyiQ== X-Google-Smtp-Source: AA0mqf65tx8qPy8y/shBDxlc+HClcoXeYiV1IpmBh7L9XBhBf9CwPN497G1LVMUj/7iacIjTD/+wS3Zgw6o04L/5zIY= X-Received: by 2002:a50:c012:0:b0:46c:8a01:748e with SMTP id r18-20020a50c012000000b0046c8a01748emr18487140edb.48.1670815769604; Sun, 11 Dec 2022 19:29:29 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 11 Dec 2022 20:29:18 -0700 Message-ID: Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available To: David Cross Cc: Andreas Kempe , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006ecc8505ef991caf" X-Rspamd-Queue-Id: 4NVnDX36M7z4b6s X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006ecc8505ef991caf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 11, 2022, 8:10 PM David Cross wrote: > One would hope. This is now the third time this has been reported. At > least. I even personally wrote a draft en for it (for 13.1). And 2 other > ENs yet to see a release, also with bugs and patches and fixes committed = to > -CURRENT > EN s are hard to do as a developer. We do very few of them. Since they are hard, I just don't bother. That needs to change... Warner > On Dec 11, 2022, at 10:00 PM, Andreas Kempe wrote: > > > > =EF=BB=BFHello everyone, > > > > I updated my laptop running geli + UFS to FreeBSD 12.4 and this > > prevented my computer from booting. Booting failed with the EFI loader > > not finding my boot disk. Since I can't recall when I last updated my > > EFI loader, it might have broken before 12.4. > > > > Searching the bugtracker, I found bug [1] which seemed relevant so I > > cherry-picked e417249016efcca73c9edad21b94b1315bc44601 to releng/12.4 > > and it applied cleanly without any conflict. After the cherry-pick, > > the loader would once again boot my system. > > > > Would it be possible to get this fix imported to the releng/12.4 > > branch? > > > > Best regards, > > Andreas Kempe > > > > [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264282 > > > > > --0000000000006ecc8505ef991caf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Dec 11, 2022, 8:10 PM David Cross <david@crossfamilyweb.com> wrote= :
One would hope. This is now the t= hird time this has been reported. At least. I even personally wrote a draft= en for it (for 13.1). And 2 other ENs yet to see a release, also with bugs= and patches and fixes committed to -CURRENT


EN = s are hard to do as a developer. We do very few of them. Since they are har= d, I just don't bother. That needs to change...
=
Warner=C2=A0

<= div dir=3D"auto">
> On Dec 11, 2022, at 10:00 PM, Andreas Kempe <kempe@lysator.liu.se= > wrote:
>
> =EF=BB=BFHello everyone,
>
> I updated my laptop running geli + UFS to FreeBSD 12.4 and this
> prevented my computer from booting. Booting failed with the EFI loader=
> not finding my boot disk. Since I can't recall when I last updated= my
> EFI loader, it might have broken before 12.4.
>
> Searching the bugtracker, I found bug [1] which seemed relevant so I > cherry-picked e417249016efcca73c9edad21b94b1315bc44601 to releng/12.4<= br> > and it applied cleanly without any conflict. After the cherry-pick, > the loader would once again boot my system.
>
> Would it be possible to get this fix imported to the releng/12.4
> branch?
>
> Best regards,
> Andreas Kempe
>
> [1]: https://bugs.freebsd.= org/bugzilla/show_bug.cgi?id=3D264282
>


--0000000000006ecc8505ef991caf-- From nobody Mon Dec 12 17:07:27 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NW7Nn077Qz4kp0X for ; Mon, 12 Dec 2022 17:07:53 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4NW7Nm2knwz3PPy for ; Mon, 12 Dec 2022 17:07:52 +0000 (UTC) (envelope-from jamie@catflap.org) Authentication-Results: mx1.freebsd.org; none X-Catflap-Envelope-From: X-Catflap-Envelope-To: freebsd-hackers@FreeBSD.org Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id 2BCH7S9u064359; Mon, 12 Dec 2022 17:07:28 GMT (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id 2BCH7Rk0064358; Mon, 12 Dec 2022 17:07:27 GMT (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> Date: Mon, 12 Dec 2022 17:07:27 +0000 Organization: Dyslexic Fish To: imp@bsdimp.com, david@crossfamilyweb.com Cc: kempe@lysator.liu.se, freebsd-hackers@FreeBSD.org Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available References: In-Reply-To: User-Agent: Heirloom mailx 12.4 7/29/08 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Mon, 12 Dec 2022 17:07:29 +0000 (GMT) X-Rspamd-Queue-Id: 4NW7Nm2knwz3PPy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > EN s are hard to do as a developer. We do very few of them. Since they are > hard, I just don't bother. That needs to change... What are ENs? And is there a better way? Anything to get my bug reports looked at... ! cheers, Jamie From nobody Mon Dec 12 18:18:03 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NW8xp3J2jz4kwWZ for ; Mon, 12 Dec 2022 18:18:06 +0000 (UTC) (envelope-from pauamma@freebsd.org) Received: from mail.gundo.com (gibson.gundo.com [75.145.166.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4NW8xp1CwQz3pYn for ; Mon, 12 Dec 2022 18:18:06 +0000 (UTC) (envelope-from pauamma@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from webmail.gundo.com (variax.gundo.com [75.145.166.70]) by mail.gundo.com (Postfix) with ESMTP id 66CCF4C4523; Mon, 12 Dec 2022 12:18:03 -0600 (CST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Date: Mon, 12 Dec 2022 18:18:03 +0000 From: Pau Amma To: Jamie Landeg-Jones Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Reply-To: pauamma@freebsd.org In-Reply-To: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> References: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> User-Agent: Roundcube Webmail/1.4.8 Message-ID: X-Sender: pauamma@freebsd.org Organization: The FreeBSD Project Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NW8xp1CwQz3pYn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7922, ipnet:75.144.0.0/13, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 2022-12-12 17:07, Jamie Landeg-Jones wrote: > Warner Losh wrote: > >> EN s are hard to do as a developer. We do very few of them. Since they >> are >> hard, I just don't bother. That needs to change... > > What are ENs? And is there a better way? Anything to get my bug reports > looked at... ! Errata Notes. As I understand, these are for software bugs or documentation errors that got into a -RELEASE version but aren't security-related. -- #BlackLivesMatter #TransWomenAreWomen #AccessibilityMatters #StandWithUkrainians English: he/him/his (singular they/them/their/theirs OK) French: il/le/lui (iel/iel and ielle/ielle OK) Tagalog: siya/niya/kaniya (please avoid sila/nila/kanila) From nobody Mon Dec 12 20:30:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWCv75Tq0z4Y4BZ for ; Mon, 12 Dec 2022 20:30:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWCv73bzmz49r9 for ; Mon, 12 Dec 2022 20:30:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52e.google.com with SMTP id a16so14770590edb.9 for ; Mon, 12 Dec 2022 12:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yNXVUJ9d9cmo34KfA/LPb/aZS4HwbxBNASXG/YTB7cs=; b=RLhvFWUy8r8cfqsjEqe6AHl+AwJtqI9hPMGWFo8vUYESxGhfvcOzi0eT9/zkbQ8q2r hEBn/hFAnp7MUbGiTzbuKm4/d80TvETCg1yqoJusi8HfrrNhcwp2sgRlx4vriShMV3bz u35Q6aB3ORcXNMhsH1GZs1cPwlySogwT3bg24hIOxz9REQm2/+GDYUMJ2EBK7Y6E1LU3 K6ojYwR2dQnETFuHFLXYWuNxM59bZfyFseVMWnD38PmVwetlJ+9akmECVWr+K6NJpPMu rg+rmCK6fO2W9bxgTGz+x2AF2Q6yMaE5wiGeX4Qna/Isu3BdumCpWdmPmbsyAvvnxEOe Aotw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yNXVUJ9d9cmo34KfA/LPb/aZS4HwbxBNASXG/YTB7cs=; b=mrHat1aSsU6QxGUcNdswHZ5k6kuVSzEwmvP3t4Hm9qT4j7nXE859IjHGD/AVVfx3Ip ON3Xk9ONeVaEMhMVFoiIQ9Pure84+mBhMdaA68GDoUeezAZug9B3RlJYllJMEMsy5Ib7 UjUUJZe++878c0e0iza/Qsd05yhZ8GvbW3ZQPCyA0u9xA4YlfR9RtCN4BTYi+JlLV78j PrtKUKTBKEogoq6vjTft2Jkk+IVPBs8Q88iTM/CVykHfM2qia3/EENFAFMSfwBYguI4c x8rYKrI3m67REj/Kxak5FkebFtYIjRR0Spv1s7jHd9Lt18CnFjPzI1gKNKUH6AYBf/3d Mvgg== X-Gm-Message-State: ANoB5plrGNDTo6UlFYM48/RMDQTgZzPYKJT3H3xhCL5QeROqrwZ51jTN 9eyvqBShp6/qZw8c2O34LDVX8aBnOvmEFTNDH/pIW0uke+X4KQ== X-Google-Smtp-Source: AA0mqf5gGBU8fBCxX5lQM4eGMTe2arAxSB4V7+zeXPrYpP7ZVRkJu3igTynlfERis1pLiBacqkQHBdkVUjGGQERXxKI= X-Received: by 2002:aa7:d85a:0:b0:46b:81a8:1ff6 with SMTP id f26-20020aa7d85a000000b0046b81a81ff6mr38147993eds.174.1670877058186; Mon, 12 Dec 2022 12:30:58 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> In-Reply-To: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> From: Warner Losh Date: Mon, 12 Dec 2022 13:30:47 -0700 Message-ID: Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available To: Jamie Landeg-Jones Cc: David Cross , kempe@lysator.liu.se, FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000084519605efa76118" X-Rspamd-Queue-Id: 4NWCv73bzmz49r9 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000084519605efa76118 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 12, 2022, 10:07 AM Jamie Landeg-Jones wrote: > Warner Losh wrote: > > > EN s are hard to do as a developer. We do very few of them. Since they > are > > hard, I just don't bother. That needs to change... > > What are ENs? And is there a better way? Anything to get my bug reports > looked at... ! > ENs are Engineering Notices. They are done by the security officer for non security related critical fixes. It's the only way to update the release branch once the release is done. I haven't found the docs on how to request them. Warner cheers, Jamie > --00000000000084519605efa76118 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2022, 10:07 AM Jamie Landeg-Jones <= jamie@catflap.org> wrote:
Warner Losh <imp@bsdimp.com> wrote= :

> EN s are hard to do as a developer. We do very few of them. Since they= are
> hard, I just don't bother. That needs to change...

What are ENs? And is there a better way? Anything to get my bug reports
looked at... !

ENs are Engineering Notices. They are done by the security of= ficer for non security related critical fixes. It's the only way to upd= ate the release branch once the release=C2=A0is done. I haven't found t= he docs on how to request=C2=A0them.=C2=A0

Warner


cheers, Jamie
--00000000000084519605efa76118-- From nobody Tue Dec 13 04:15:01 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NWQBc52qXz4jkFf for ; Tue, 13 Dec 2022 04:15:04 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NWQBc4cPsz43Jj for ; Tue, 13 Dec 2022 04:15:04 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670904904; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5UCqdCQYKBzl5W31KzwLX0Cs6YXFeSImob1R475la3s=; b=qBQ6CmDZlX/xWQmsWfItuWTyhhdGhbyX1i9z302BHcIY5MljrvZM89Y3Z30pN/pevp5as5 oQ5lrvAVVQqwnkNFAmr9M0vxM2MLBA5GwO0RYf109CILgxLO4lwPjWSZEC9jfX/3rI+nuK WRtUd+tItin1Tyj6GKUUmS7HJfClE3ijWGiqxPW/t9GpMzPLd/nNdweU5WUwmDGmrr37Vx 40wEqLPKzeuAFLF/hz8a/ID5RLhLbVIviWiqabdj4lGL/isUw++p8nfV1/0AN7a8AZEk4y qWq4wen3g/Ri+KkRRZsECpS9nYupLWCQzDzVX5TbOhT/ZtmcAAmvBD9yPitt0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670904904; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5UCqdCQYKBzl5W31KzwLX0Cs6YXFeSImob1R475la3s=; b=b9LF6/7zdRuybUtSBLzZUAJvnxoNHGhI0Gpuy/dT8NNfhVAjV6VyE30zp5jMU1sphLd39C ttBAIQZ4d6Jb6rw2dvFgaCO9+Abx2kAMYqcK48z/UYgZFucaxWCoYskrN8QGk3UrCszigt KRLIATu8jsrOm91RtCSTFfN4gCUHsDA0tNPhI6cFDptvrisoDnPhNyCzfcLYhEyBw230bE gvl/0zSIFGII234yNBqMlndnBu2RWTDNX2+XPTtikYIKGKQJNAM29iI+n7bg/LxHUWMVle ZHQDOdHrrXFmHOBVxa2GWndYwL0h5DsE94WWWcrSTgSvGH7SQzowyAWqPnwpzA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670904904; a=rsa-sha256; cv=none; b=YFjzlOIeGZsJopF/gRL91voAv6U7Jp+uPM7yQNCi8SQ37hdsPSXIgV7gl9FFVpr32SSt1D aff2KLoK6WjYdJI9nyEcoXgWims03KlwKPEYDe9TLSMtxUX/Zc0waXTlh3py2rzLuqItXx Q7ijxvKP5p7awmgKMODuGzdE/+yJZ6YSx5Mybrp5YNhV+d/d7U4mkPGsbjlAIouRQktFiD 6oXVcl4QOFobgpu8Kms4cv4elM0tFC+88h1WutDcm+8aMOVjOKqqzjv1+XaQjdxrFuhS+5 EZ1Hdjm9OUDEm35sPfj2QZNDjoaWcNWXDuutbhLNe/Q5tbk3FCW0Fxg2hmJtvg== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NWQBc2S3jz1629 for ; Tue, 13 Dec 2022 04:15:04 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: Date: Tue, 13 Dec 2022 04:15:01 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: EN documentation (was: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available) To: freebsd-hackers@freebsd.org References: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> Content-Language: en-GB From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xIkzlTZofC7ZqgHsRnGA3jk0" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xIkzlTZofC7ZqgHsRnGA3jk0 Content-Type: multipart/mixed; boundary="------------DKGDY588aV0HGoeld6GtVNfC"; protected-headers="v1" From: Graham Perrin To: freebsd-hackers@freebsd.org Message-ID: Subject: EN documentation (was: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available) References: <202212121707.2BCH7Rk0064358@donotpassgo.dyslexicfish.net> In-Reply-To: --------------DKGDY588aV0HGoeld6GtVNfC Content-Type: multipart/alternative; boundary="------------62cIlUhU00u4mzW0vnlUz0YS" --------------62cIlUhU00u4mzW0vnlUz0YS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTIvMTIvMjAyMiAyMDozMCwgV2FybmVyIExvc2ggd3JvdGU6DQo+DQo+IOKApiBkb25l IGJ5IHRoZSBzZWN1cml0eSBvZmZpY2VyIGZvciBub24gc2VjdXJpdHkgcmVsYXRlZCBjcml0 aWNhbCANCj4gZml4ZXMuIEl0J3MgdGhlIG9ubHkgd2F5IHRvIHVwZGF0ZSB0aGUgcmVsZWFz ZSBicmFuY2ggb25jZSB0aGUgDQo+IHJlbGVhc2XCoGlzIGRvbmUuIEkgaGF2ZW4ndCBmb3Vu ZCB0aGUgZG9jcyBvbiBob3cgdG8gcmVxdWVzdMKgdGhlbS4NCg0KDQolIGdyZXAgLWkgLVIg ImVycmF0YSBub3RpY2UiIC91c3IvZG9jDQovdXNyL2RvYy9kb2N1bWVudGF0aW9uL2NvbnRl bnQvZXMvYXJ0aWNsZXMvZnJlZWJzZC1yZWxlbmcvX2luZGV4LnBvOm1zZ2lkIA0KIlBvc3Qt UmVsZWFzZSBFcnJhdGEgTm90aWNlcyINCuKApg0KDQpGcmVlQlNEIFJlbGVhc2UgRW5naW5l ZXJpbmcg4pa2IA0KPGh0dHBzOi8vZG9jcy5mcmVlYnNkLm9yZy9lbi9hcnRpY2xlcy9mcmVl YnNkLXJlbGVuZy8jcmVsZW5nLXdyYXB1cC1lbj4gDQpsZWFkcyB0byBhIHRlbXBsYXRlLg0K DQpQbGVhc2Ugbm90ZTogdGhpcyBpcyAvbm90LyB0byBzdWdnZXN0IHRoYXQgYSBub3RpY2Us IHBhdGNoIGFuZC9vciANCmNoZXJyeS1waWNrIHRvIHN0YWJsZS8xMiAvd2lsbC8gb2NjdXIg Zm9yIGJ1ZyByZXBvcnQgMjY0MjgyLg0KDQo= --------------62cIlUhU00u4mzW0vnlUz0YS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 12/12/2022 20:30, Warner Losh wrote= :

=E2=80=A6 done by the security officer for non security related c= ritical fixes. It's the only way to update the release branch once the release=C2=A0is done. I haven't found the docs on how to request=C2=A0them.=C2=A0


% grep -i -R "errata notice" /usr/doc
/usr/doc/documentation/content/es/articles/freebsd-releng/_index.po:msgid= "Post-Release Errata Notices"
=E2=80=A6

FreeBSD Release Engineering =E2=96=B6 <https://docs.freebsd.org/en/= articles/freebsd-releng/#releng-wrapup-en> leads to a template.

Please note: this is not to suggest that a notice, patch and/or cherry-pick to stable/12 will occur for bug report 264282.

--------------62cIlUhU00u4mzW0vnlUz0YS-- --------------DKGDY588aV0HGoeld6GtVNfC-- --------------xIkzlTZofC7ZqgHsRnGA3jk0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOX/EUFAwAAAAAACgkQt2dIb0oY1AuR Ew/9FBT0d0d7CffxIXe91oAzj0Uj/xyNeXxigmzUzxEMlOmjr371jcZeSXxVqUwU34giYA1U/N/X yWrIdfzaFuL9Dzj7l/d44iMwlwDdTU/zuYnOkeTECmS6/rRaEWupMSUguyymDkInUXhlk/4Q7ffb 1X3LKGHoJi/xBSnK9AFbCvCuZ29WepnaK1Q90tzBsNouSLKJ6Az6U52UiPK/r3fyIjMiQ5VQI/Fx +4RTC6NA3C1pO7x4eZJiLLT6Rwjo2cbPHM0up5OjUPgkW3NwM+UWRJjjHYFYXcw+ie3SG4TY1Wvk PYG4eG7q6NcqHHjyBqREZRj16unapOY3bAlwkH4fA/g6nG6ewdmHUlQFniFcO3krO0IYwpaUk4HI YUpJ11ezLIxUXNlAzDjme4p8mhdFE+qdlOuPYdqqz9/Zk6cY3byMj/wle+gNzVzvLmqPKMwKrvKR SzsdrPYDJo9nVPaLRtBa+HYsbW4hrJpMiRTlCeXpZcByMvGlE25Dh1yfcAuhl3QEh748S30+THgZ 8gaHQfY3mKm0TK1b5Ppdr2KAmpUYAK0y+HT5mZshrfD4U+rqvbvo6GRrRhof0hK/Dzk3jTeg9Y9R aexwZbbmJfBwlCEtsh+Mq/UAjTZy4CZTEWl41XJp6Ztasi40WfNsbyj+xWCJpsjHtMrUtbXJod1e Y20= =XcIv -----END PGP SIGNATURE----- --------------xIkzlTZofC7ZqgHsRnGA3jk0-- From nobody Wed Dec 14 17:10:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXMMW2sdDz4k5K7 for ; Wed, 14 Dec 2022 17:11:03 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXMMV3pkPz3PRl for ; Wed, 14 Dec 2022 17:11:02 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id D4C0D1EDEC for ; Wed, 14 Dec 2022 18:10:52 +0100 (CET) Received: from claptrap.lysator.liu.se (claptrap.lysator.liu.se [IPv6:2001:6b0:17:f0a0::fa]) (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 mail.lysator.liu.se (Postfix) with ESMTPSA id D33F61EEAE for ; Wed, 14 Dec 2022 18:10:52 +0100 (CET) Date: Wed, 14 Dec 2022 18:10:51 +0100 From: Andreas Kempe To: FreeBSD Hackers Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NXMMV3pkPz3PRl X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote: > On Sun, Dec 11, 2022, 8:10 PM David Cross wrote: > > > One would hope. This is now the third time this has been reported. At > > least. I even personally wrote a draft en for it (for 13.1). And 2 other > > ENs yet to see a release, also with bugs and patches and fixes committed to > > -CURRENT > > > > > EN s are hard to do as a developer. We do very few of them. Since they are > hard, I just don't bother. That needs to change... > If ENs are difficult to do, would it at least be possible to add a notice under Late-Breaking News with a warning? To me, having a system that won't boot is a quite nasty surprise. Best regards, Andreas Kempe From nobody Wed Dec 14 19:51:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXQy95c7zz4kQJN for ; Wed, 14 Dec 2022 19:52:49 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-251.nys.biz.rr.com [24.97.5.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXQy85Gs3z3yml for ; Wed, 14 Dec 2022 19:52:48 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; none X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from smtpclient.apple (d138.guest.wifi.crossfamilyweb.com [10.1.8.138]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 2BEJqVPP046377 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 14 Dec 2022 19:52:31 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d138.guest.wifi.crossfamilyweb.com [10.1.8.138] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Date: Wed, 14 Dec 2022 14:51:51 -0500 Message-Id: <87CE4889-12C3-4058-8C75-1A4646486EFF@crossfamilyweb.com> References: Cc: FreeBSD Hackers In-Reply-To: To: Andreas Kempe X-Mailer: iPhone Mail (20B110) X-Rspamd-Queue-Id: 4NXQy85Gs3z3yml X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N I wrote draft ENs for these already. Give me a few and I=E2=80=99ll send th= em on again > On Dec 14, 2022, at 12:11 PM, Andreas Kempe wrote: >=20 > =EF=BB=BFOn Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote: >>> On Sun, Dec 11, 2022, 8:10 PM David Cross wro= te: >>>=20 >>> One would hope. This is now the third time this has been reported. At >>> least. I even personally wrote a draft en for it (for 13.1). And 2 other= >>> ENs yet to see a release, also with bugs and patches and fixes committed= to >>> -CURRENT >>>=20 >>=20 >>=20 >> EN s are hard to do as a developer. We do very few of them. Since they ar= e >> hard, I just don't bother. That needs to change... >>=20 >=20 > If ENs are difficult to do, would it at least be possible to add a > notice under Late-Breaking News with a warning? To me, having a system > that won't boot is a quite nasty surprise. >=20 > Best regards, > Andreas Kempe >=20 From nobody Wed Dec 14 20:07:31 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXRHG0S50z4kSH9 for ; Wed, 14 Dec 2022 20:07:38 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXRHD39pRz41Zj for ; Wed, 14 Dec 2022 20:07:36 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se; dmarc=pass (policy=none) header.from=lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id BDBF31F253 for ; Wed, 14 Dec 2022 21:07:32 +0100 (CET) Received: from claptrap.lysator.liu.se (claptrap.lysator.liu.se [IPv6:2001:6b0:17:f0a0::fa]) (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 mail.lysator.liu.se (Postfix) with ESMTPSA id BBFCB1F2E4 for ; Wed, 14 Dec 2022 21:07:32 +0100 (CET) Date: Wed, 14 Dec 2022 21:07:31 +0100 From: Andreas Kempe To: FreeBSD Hackers Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Message-ID: References: <87CE4889-12C3-4058-8C75-1A4646486EFF@crossfamilyweb.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87CE4889-12C3-4058-8C75-1A4646486EFF@crossfamilyweb.com> X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NXRHD39pRz41Zj X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 14, 2022 at 02:51:51PM -0500, David Cross wrote: > > On Dec 14, 2022, at 12:11 PM, Andreas Kempe wrote: > > > > On Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote: > >>> On Sun, Dec 11, 2022, 8:10 PM David Cross wrote: > >>> > >>> One would hope. This is now the third time this has been reported. At > >>> least. I even personally wrote a draft en for it (for 13.1). And 2 other > >>> ENs yet to see a release, also with bugs and patches and fixes committed to > >>> -CURRENT > >>> > >> > >> > >> EN s are hard to do as a developer. We do very few of them. Since they are > >> hard, I just don't bother. That needs to change... > >> > > > > If ENs are difficult to do, would it at least be possible to add a > > notice under Late-Breaking News with a warning? To me, having a system > > that won't boot is a quite nasty surprise. > > > > I wrote draft ENs for these already. Give me a few and I’ll send them on again > Thank you! I misinterpreted you as your drafts having been rejected. Best regards, Andreas Kempe From nobody Thu Dec 15 00:00:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXXRW6GPzz4kvMS; Thu, 15 Dec 2022 00:00:07 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXXRW4m9Dz3DLD; Thu, 15 Dec 2022 00:00:07 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671062407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=; b=MyaLeE2NjIoxeYRIDJrsbaDkcL1F++31V9UdCFyiUurQa6ZK/7OxY2q/l8pDomrJFzFSgX /1kUe0KP7V4dc6Ls8RKGGSZ3DWXhsVp49hqN/xFoYAQedJABCaEwfCJl1ChhPGiZsynKXp uXOybQnnsx0uaHsyl46o2BgmwXQK/BIKK87Cf/LCvHXalx2toAF7xtNh7IDdfcGYdyJi8U OQC+Ttn4wD62iXOkgGKK8ngzhZQr2vafKVLFjxp/Ddspur6nXgaeQJgeqmmkt4CO9JM0zw utAPwSRchLcTVnCrzeyKnYFVtvj/se+xPPz4LFZXJ6WUJGjfoW5OF/JqyGgP8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671062407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=; b=R2ppKQJNd/U3d9Vzo9KxA4VJfye9HM1eYkADr42vJI5BdeurIc217u+aW+emBRNYQlMwm8 de2Dk5daMDVK9B2entc7Yt0qLWGEGGiTYwfJvqJlbUTtxmi0Ab8frcQlm2BU51JoWQXd9Q MlxLKUnAVAakwNBYL/OpiMHBesly+mEcLD8RrOQ5OEfGE5eyqcUQTW6rs7TkUb7a/z2VIX GJBXeT24uWjpBu3lyG5nHwqHIeibSjwxcFflL4yxIcfIDI2KyvIAmKm+lggioCxbBKqLSV 6Z/G0be50pKLwBH980PdfQrBrkbupN0fLLIfx3lEF+wWjuUKVidWPf7PvLkp5A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671062407; a=rsa-sha256; cv=none; b=UfI6XBOv0Pvad2WB7yfniCM6gc7KyDdC0Ppd6YXJJbUx8FyTVLvObChXAhvSCol8DB+PwM Hs2RFrNJn4jvgsJRb1Ct8exHPadraCypHjVgts5uIYs26Ga1LCFPB/cdBtOG4IIobv2f22 c7Ybsy1IX5906ubn2QeuS5JH3LefiF3saJqBOaExrRhbttNWHJLzwwFjDYS9XE7gyQWw9j 3FUzqc7O3XjDDALvx7U4Ic4HXozMXXjvqf+bjnooVxx0McIhtUmNGIsuCQ7gMJAEsq2W9k oF4/kT61neDT5aDX+lfu9lGY4bkT/N3uimm9dGZYG4SspihYRAMGLxs+lr9rWg== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 4A92EADB6; Thu, 15 Dec 2022 00:00:07 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [2 WEEKS LEFT REMINDER] Call for 2022Q4 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org Message-Id: <20221215000007.4A92EADB6@freefall.freebsd.org> Date: Thu, 15 Dec 2022 00:00:07 +0000 (UTC) From: Lorenzo Salvadore X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is December, 31st 2022 for work done since the last round of Quarterly Reports: October 2022 - December 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q4 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Thu Dec 15 01:10:54 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NXZ2B4FZnz4l3WM for ; Thu, 15 Dec 2022 01:11:46 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-251.nys.biz.rr.com [24.97.5.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NXZ2B0mqmz3N1G for ; Thu, 15 Dec 2022 01:11:45 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; none X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from smtpclient.apple (d138.guest.wifi.crossfamilyweb.com [10.1.8.138]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 2BF1BYrl084858 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 15 Dec 2022 01:11:35 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d138.guest.wifi.crossfamilyweb.com [10.1.8.138] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Cross List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Date: Wed, 14 Dec 2022 20:10:54 -0500 Message-Id: References: Cc: FreeBSD Hackers In-Reply-To: To: Andreas Kempe X-Mailer: iPhone Mail (20B110) X-Rspamd-Queue-Id: 4NXZ2B0mqmz3N1G X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N The drafts never made it out, doesn=E2=80=99t seem there is a distinction th= ere > On Dec 14, 2022, at 3:08 PM, Andreas Kempe wrote: >=20 > =EF=BB=BFOn Wed, Dec 14, 2022 at 02:51:51PM -0500, David Cross wrote: >>>> On Dec 14, 2022, at 12:11 PM, Andreas Kempe wrot= e: >>>=20 >>> =EF=BB=BFOn Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote: >>>>> On Sun, Dec 11, 2022, 8:10 PM David Cross w= rote: >>>>>=20 >>>>> One would hope. This is now the third time this has been reported. At >>>>> least. I even personally wrote a draft en for it (for 13.1). And 2 oth= er >>>>> ENs yet to see a release, also with bugs and patches and fixes committ= ed to >>>>> -CURRENT >>>>>=20 >>>>=20 >>>>=20 >>>> EN s are hard to do as a developer. We do very few of them. Since they a= re >>>> hard, I just don't bother. That needs to change... >>>>=20 >>>=20 >>> If ENs are difficult to do, would it at least be possible to add a >>> notice under Late-Breaking News with a warning? To me, having a system >>> that won't boot is a quite nasty surprise. >>>=20 >>=20 >> I wrote draft ENs for these already. Give me a few and I=E2=80=99ll send= them on again >>=20 >=20 > Thank you! I misinterpreted you as your drafts having been rejected. >=20 > Best regards, > Andreas Kempe >=20 From nobody Thu Dec 15 21:46:10 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NY5Qx1hF5z4dJsC for ; Thu, 15 Dec 2022 21:46:33 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Received: from mail.dcrosstech.com (rrcs-24-97-5-251.nys.biz.rr.com [24.97.5.251]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.dcrosstech.com", Issuer "DCrossTech.com LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NY5Qv32S6z4Ldc for ; Thu, 15 Dec 2022 21:46:29 +0000 (UTC) (envelope-from david@crossfamilyweb.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of david@crossfamilyweb.com designates 24.97.5.251 as permitted sender) smtp.mailfrom=david@crossfamilyweb.com; dmarc=none X-Virus-Scanned: amavisd-new at dcrosstech.com Received: from [10.1.7.155] (d155.p9.wifi.dcrosstech.com [10.1.7.155]) (authenticated bits=0) by mail.dcrosstech.com (8.15.2/8.15.2) with ESMTPSA id 2BFLkAug041440 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 15 Dec 2022 21:46:12 GMT (envelope-from david@crossfamilyweb.com) X-Authentication-Warning: mail.priv.dcrosstech.com: Host d155.p9.wifi.dcrosstech.com [10.1.7.155] claimed to be [10.1.7.155] Content-Type: multipart/mixed; boundary="------------r8DW6W0TvfBIovosGKrxkk0C" Message-ID: <30730b82-9c37-3e12-0bc5-78b02df269a4@crossfamilyweb.com> Date: Thu, 15 Dec 2022 16:46:10 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: FreeBSD 12.4: EFI: geli + UFS won't boot - fix available Content-Language: en-US From: "David E. Cross" To: Andreas Kempe Cc: FreeBSD Hackers References: In-Reply-To: X-Spamd-Result: default: False [-2.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:11351, ipnet:24.97.0.0/16, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[david]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_XAW(0.00)[]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[crossfamilyweb.com]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4NY5Qv32S6z4Ldc X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------r8DW6W0TvfBIovosGKrxkk0C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/14/22 20:10, David Cross wrote: > The drafts never made it out, doesn’t seem there is a distinction there > >> On Dec 14, 2022, at 3:08 PM, Andreas Kempe wrote: >> >> On Wed, Dec 14, 2022 at 02:51:51PM -0500, David Cross wrote: >>>>> On Dec 14, 2022, at 12:11 PM, Andreas Kempe wrote: >>>> On Sun, Dec 11, 2022 at 08:29:18PM -0700, Warner Losh wrote: >>>>>> On Sun, Dec 11, 2022, 8:10 PM David Cross wrote: >>>>>> >>>>>> One would hope. This is now the third time this has been reported. At >>>>>> least. I even personally wrote a draft en for it (for 13.1). And 2 other >>>>>> ENs yet to see a release, also with bugs and patches and fixes committed to >>>>>> -CURRENT >>>>>> >>>>> >>>>> EN s are hard to do as a developer. We do very few of them. Since they are >>>>> hard, I just don't bother. That needs to change... >>>>> >>>> If ENs are difficult to do, would it at least be possible to add a >>>> notice under Late-Breaking News with a warning? To me, having a system >>>> that won't boot is a quite nasty surprise. >>>> >>> I wrote draft ENs for these already. Give me a few and I’ll send them on again >>> >> Thank you! I misinterpreted you as your drafts having been rejected. >> >> Best regards, >> Andreas Kempe >> > Sorry for the previous top-posting.  I will get better. Anyway, here are the 3 draft ENs I wrote earlier, submitted 8/30/2022.  All 3 were actually reported by other people (I just happened to hit them independently), all 3 had patches submitted and were in GIT in -CURRENT. While all 3 affect 'nonstandard' options (geli root disk isn't standard, compiling with other options isn't standard), all of these things are supposed to work, and the patches involved are trivial.  The geli one itself is such a HUGE problem it has to be addressed IMO.  When I wrote these drafts 12.4 wasn't a thing, so they need to be updated.  Also there are sections that need to be corrected also, I was trying to do the heavy lift of describing the problem, workarounds, impact, etc.  Things like the specific patches need to come from git after merges/etc. --------------r8DW6W0TvfBIovosGKrxkk0C Content-Type: text/plain; charset=UTF-8; name="libstand.txt" Content-Disposition: attachment; filename="libstand.txt" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KRnJlZUJTRC1FTi1FUlJBVEFfVEVNUExBVEUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVycmF0YSBOb3RpY2UKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo ZSBGcmVlQlNEIFByb2plY3QKClRvcGljOgoKQ2F0ZWdvcnk6ICAgICAgIGNvcmUKTW9kdWxl OiAgICAgICAgIGxvYWRlcgpBbm5vdW5jZWQ6ICAgICAgMjAyMi1YWC1YWApDcmVkaXRzOgpB ZmZlY3RzOiAgICAgICAgRnJlZUJTRCAxMy4xCkNvcnJlY3RlZDogICAgICA/Pz8/CgpGb3Ig Z2VuZXJhbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgRnJlZUJTRCBFcnJhdGEgTm90aWNlcyBh bmQgU2VjdXJpdHkKQWR2aXNvcmllcywgaW5jbHVkaW5nIGRlc2NyaXB0aW9ucyBvZiB0aGUg ZmllbGRzIGFib3ZlLCBzZWN1cml0eQpicmFuY2hlcywgYW5kIHRoZSBmb2xsb3dpbmcgc2Vj dGlvbnMsIHBsZWFzZSB2aXNpdAo8VVJMOmh0dHBzOi8vc2VjdXJpdHkuRnJlZUJTRC5vcmcv Pi4KCkkuICAgQmFja2dyb3VuZAoKZ2VsaSBpcyBhbiBlbmNycHl0aW9uIGNvbXBvbmVudCBv ZiB0aGUgR0VPTSBzdWJzeXN0ZW0gb2YgRnJlZUJTRCB0aGF0CmFsbG93cyBwYXJ0aXRpb25z IG9yIGRpc2tzIHRvIGJlIGVuY3J5cHRlZC4gIEJvdGggdGhlIGtlcm5lbCBhbmQgbG9hZGVy KDgpCmhhdmUgc3VwcG9ydCB0byBhbGxvdyBib290aW5nIGZyb20gZW5jcnlwdGVkIGRpc2tz IGFuZCBwcm9tcHRpbmcgZm9yIGEKcGFzc3dvcmQgYXQgYm9vdCB0aW1lLgoKSUkuICBQcm9i bGVtIERlc2NyaXB0aW9uCgpBIGNoYW5nZSB0byBsaWJzdGFuZCgzKSBzb21ldGltZSBiZXR3 ZWVuIDEzLjAgYW5kIDEzLjEgcHJldmVudHMgbG9hZGVyIGZyb20KcmVjb2duaXppbmcgdGhl IHBhcnRpdGlvbiBhZnRlciB0aGUgYnVpbHQgaW4gZ2VsaSBkcml2ZXIgaGFzIGF0dGFjaGVk IHRoZQpwYXJ0aXRpb24gLCBwcmV2ZW50aW5nIGF1dG8gYm9vdGluZyBvZiBlbmNyeXB0ZWQg cm9vdCBwYXJ0aXRpb25zLgoKVGhpcyBidWcgd2FzIHRyYWNrZWQgYXQ6Cmh0dHBzOi8vYnVn cy5mcmVlYnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjY0MjgyCgoKSUlJLiBJ bXBhY3QKClN5c3RlbXMgcnVubmluZyAxMy4xIHdpdGggZW5jcnlwdGVkIHJvb3QgZGlza3Mg d2lsbCBub3QgYXV0b2Jvb3QuCgpJVi4gIFdvcmthcm91bmQKClN5c3RlbXMgYWZmZWN0ZWQg bWF5IHJldmVydCB0byBsb2FkZXIoOCkgZnJvbSAxMy4wLiAgQWRkaXRpb25hbGx5CnNldHRp bmcgY3VycmRldiBhbmQgcm9vdGRldiB0byB0aGUgY29ycmVjdCBwYXJ0aXRpb24gbWFudWFs bHkgd2lsbAphbGxvdyBib290aW5nIG9mIHRoZSBzeXN0ZW0uCgpTeXN0ZW1zIHdpdGhvdXQg Z2VsaSByb290IGRpc2sgZW5jcnlwdGlvbiBhcmUgdW5hZmZlY3RlZC4KClYuICAgU29sdXRp b24KClBBVENICgpVcGdyYWRlIHlvdXIgc3lzdGVtIHRvIGEgc3VwcG9ydGVkIEZyZWVCU0Qg c3RhYmxlIG9yIHJlbGVhc2UgLyBzZWN1cml0eQpicmFuY2ggKHJlbGVuZykgZGF0ZWQgYWZ0 ZXIgdGhlIGNvcnJlY3Rpb24gZGF0ZS4KW1hYIE5lZWRzIHJlYm9vdD8gTWVudGlvbiBwbGVh c2VdCgpQZXJmb3JtIG9uZSBvZiB0aGUgZm9sbG93aW5nOgoKMSkgVG8gdXBkYXRlIHlvdXIg c3lzdGVtIHZpYSBhIGJpbmFyeSBwYXRjaDoKClN5c3RlbXMgcnVubmluZyBhIFJFTEVBU0Ug dmVyc2lvbiBvZiBGcmVlQlNEIG9uIHRoZSBhbWQ2NCwgaTM4Niwgb3IKKG9uIEZyZWVCU0Qg MTMgYW5kIGxhdGVyKSBhcm02NCBwbGF0Zm9ybXMgY2FuIGJlIHVwZGF0ZWQgdmlhIHRoZQpm cmVlYnNkLXVwZGF0ZSg4KSB1dGlsaXR5OgoKIyBmcmVlYnNkLXVwZGF0ZSBmZXRjaAojIGZy ZWVic2QtdXBkYXRlIGluc3RhbGwKCioqKiBSZWJvb3QgbmVlZGVkIHRvIHZhbGlkYXRlIGZp eCAqKioKCjIpIFRvIHVwZGF0ZSB5b3VyIHN5c3RlbSB2aWEgYSBzb3VyY2UgY29kZSBwYXRj aDoKClRoZSBmb2xsb3dpbmcgcGF0Y2hlcyBoYXZlIGJlZW4gdmVyaWZpZWQgdG8gYXBwbHkg dG8gdGhlIGFwcGxpY2FibGUKRnJlZUJTRCByZWxlYXNlIGJyYW5jaGVzLgoKYSkgRG93bmxv YWQgdGhlIHJlbGV2YW50IHBhdGNoIGZyb20gdGhlIGxvY2F0aW9uIGJlbG93LCBhbmQgdmVy aWZ5IHRoZQpkZXRhY2hlZCBQR1Agc2lnbmF0dXJlIHVzaW5nIHlvdXIgUEdQIHV0aWxpdHku CgpbRnJlZUJTRCAxMy4xXQojIGZldGNoIGh0dHBzOi8vc2VjdXJpdHkuRnJlZUJTRC5vcmcv cGF0Y2hlcy9FTi1YWDpYWC9YWFhYLnBhdGNoCiMgZmV0Y2ggaHR0cHM6Ly9zZWN1cml0eS5G cmVlQlNELm9yZy9wYXRjaGVzL0VOLVhYOlhYL1hYWFgucGF0Y2guYXNjCiMgZ3BnIC0tdmVy aWZ5IFhYWFgucGF0Y2guYXNjCgpiKSBBcHBseSB0aGUgcGF0Y2guICBFeGVjdXRlIHRoZSBm b2xsb3dpbmcgY29tbWFuZHMgYXMgcm9vdDoKCiMgY2QgL3Vzci9zcmMKIyBwYXRjaCA8IC9w YXRoL3RvL3BhdGNoCgo8Zm9yIGEgdXNlcmxhbmQgdXRpbGl0eTo+CgpjKSBSZWNvbXBpbGUg dGhlIG9wZXJhdGluZyBzeXN0ZW0gdXNpbmcgYnVpbGR3b3JsZCBhbmQgaW5zdGFsbHdvcmxk IGFzCmRlc2NyaWJlZCBpbiA8VVJMOmh0dHBzOi8vd3d3LkZyZWVCU0Qub3JnL2hhbmRib29r L21ha2V3b3JsZC5odG1sPi4KClZJLiAgQ29ycmVjdGlvbiBkZXRhaWxzCgpUaGlzIGlzc3Vl IGlzIGNvcnJlY3RlZCBieSB0aGUgY29ycmVzcG9uZGluZyBHaXQgY29tbWl0IGhhc2ggb3Ig U3VidmVyc2lvbgpyZXZpc2lvbiBudW1iZXIgaW4gdGhlIGZvbGxvd2luZyBzdGFibGUgYW5k IHJlbGVhc2UgYnJhbmNoZXM6CgpCcmFuY2gvcGF0aCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSGFzaCAgICAgICAgICAgICAgICAgICAgIFJldmlzaW9uCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0Kc3RhYmxlLzEzLyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFhYWFhYWFhY WFhYWCAgICBzdGFibGUvMTMtblhYWFhYWApyZWxlbmcvMTMuMS8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgWFhYWFhYWFhYWFhYICByZWxlbmcvMTMuMS1uWFhYWFhYCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KCkZvciBGcmVlQlNEIDEzIGFuZCBsYXRlcjoKClJ1biB0aGUgZm9sbG93 aW5nIGNvbW1hbmQgdG8gc2VlIHdoaWNoIGZpbGVzIHdlcmUgbW9kaWZpZWQgYnkgYQpwYXJ0 aWN1bGFyIGNvbW1pdDoKCiMgZ2l0IHNob3cgLS1zdGF0IDxjb21taXQgaGFzaD4KCk9yIHZp c2l0IHRoZSBmb2xsb3dpbmcgVVJMLCByZXBsYWNpbmcgTk5OTk5OIHdpdGggdGhlIGhhc2g6 Cgo8VVJMOmh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9zcmMvY29tbWl0Lz9pZD1OTk5OTk4+ CgpUbyBkZXRlcm1pbmUgdGhlIGNvbW1pdCBjb3VudCBpbiBhIHdvcmtpbmcgdHJlZSAoZm9y IGNvbXBhcmlzb24gYWdhaW5zdApuTk5OTk5OIGluIHRoZSB0YWJsZSBhYm92ZSksIHJ1bjoK CiMgZ2l0IHJldi1saXN0IC0tY291bnQgLS1maXJzdC1wYXJlbnQgSEVBRAoKVklJLiBSZWZl cmVuY2VzCgo8b3RoZXIgaW5mbyBvbiB0aGUgcHJvYmxlbT4KCjxVUkw6aHR0cHM6Ly9idWdz LmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD1YWFhYWFg+CgpUaGUgbGF0 ZXN0IHJldmlzaW9uIG9mIHRoaXMgYWR2aXNvcnkgaXMgYXZhaWxhYmxlIGF0CjxVUkw6aHR0 cHM6Ly9zZWN1cml0eS5GcmVlQlNELm9yZy9hZHZpc29yaWVzL0ZyZWVCU0QtRU4tWFg6WFgu WFhYWFguYXNjPgo= --------------r8DW6W0TvfBIovosGKrxkk0C Content-Type: text/plain; charset=UTF-8; name="llvm.txt" Content-Disposition: attachment; filename="llvm.txt" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KRnJlZUJTRC1FTi1FUlJBVEFfVEVNUExBVEUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVycmF0YSBOb3RpY2UKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo ZSBGcmVlQlNEIFByb2plY3QKClRvcGljOgoKQ2F0ZWdvcnk6ICAgICAgIGNvcmUKTW9kdWxl OiAgICAgICAgIExMVk0KQW5ub3VuY2VkOiAgICAgIDIwMjItWFgtWFgKQ3JlZGl0czoKQWZm ZWN0czogICAgICAgIFVuc3VyZT8gIDEzLjEgZGVmaW5pdGVseSwgYnVnIHJlcG9ydCByZWZl cmVuY2VzIDEyLngKCQlidXQgdW5zdXJlIGlmIHRoYXQgbWFkZSBpdCB0byBhIC1SRUxFQVNF CkNvcnJlY3RlZDogICAgICAyMDIyLVhYLVhYIFhYOlhYOlhYIFVUQyAoc3RhYmxlLzEzLCAx My4xLVNUQUJMRSkKICAgICAgICAgICAgICAgIDIwMjItWFgtWFggWFg6WFg6WFggVVRDIChy ZWxlbmcvMTMuMSwgMTMuMS1SRUxFQVNFLXBYWCkKICAgICAgICAgICAgICAgIDIwMjItWFgt WFggWFg6WFg6WFggVVRDIChyZWxlbmcvMTMuMCwgMTMuMC1SRUxFQVNFLXBYWCkKICAgICAg ICAgICAgICAgIDIwMjItWFgtWFggWFg6WFg6WFggVVRDIChzdGFibGUvMTIsIDEyLjMtU1RB QkxFKQogICAgICAgICAgICAgICAgMjAyMi1YWC1YWCBYWDpYWDpYWCBVVEMgKHJlbGVuZy8x Mi4zLCAxMi4zLVJFTEVBU0UpCgpGb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiByZWdhcmRpbmcg RnJlZUJTRCBFcnJhdGEgTm90aWNlcyBhbmQgU2VjdXJpdHkKQWR2aXNvcmllcywgaW5jbHVk aW5nIGRlc2NyaXB0aW9ucyBvZiB0aGUgZmllbGRzIGFib3ZlLCBzZWN1cml0eQpicmFuY2hl cywgYW5kIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMsIHBsZWFzZSB2aXNpdAo8VVJMOmh0dHBz Oi8vc2VjdXJpdHkuRnJlZUJTRC5vcmcvPi4KCkkuICAgQmFja2dyb3VuZAoKTExWTSBpcyBh IHRoaXJkIHBhcnR5IGNvbXBpbGVyIHRoYXQgaXMgZGlzdHJpYnV0ZWQgYXMgcGFydCBvZiBi YXNlLgpGcmVlQlNEIHVzZXMgdGhpcyBjb21waWxlciB0byBjb252ZXJ0IHNvdXJjZSBjb2Rl IHRvIHN5c3RlbSBvYmplY3QgY29kZSAKZm9yIHRoZSBrZXJuZWwsIGxpYnJhcmllcywgc3lz dGVtIHV0aWxpdGllcywgYW5kIHBvcnRzLgoKQVZYIGlzIGEgc2V0IG9mIGluc3RydWN0aW9u cyBvbiBJbnRlbCBwcm9jZXNzb3JzIHRoYXQgc3BlZWQgY2VydGFpbgp2ZWN0b3IgY29tcHV0 aW5nIG9wZXJhdGlvbnMuICBBVlgtNTEyIGlzIGEgc3BlY2lmaWMgdmVyc2lvbiBvZiB0aGVz ZQppbnN0cnVjdGlvbnMgYXZhaWxhYmxlIG9uIHNwZWNpZmljIENQVXMuCgpJSS4gIFByb2Js ZW0gRGVzY3JpcHRpb24KCkZyZWVCU0QgYW5kIExMVk0gYWxsb3cgdmFyaW91cyBvcHRpb25z IHRvIGJlIHNldCB0byB0YWlsb3IgdGhlIHN5c3RlbSAKdG8gc3BlY2lmaWMgZW52aXJvbm1l bnRzIGJ5IHNldHRpbmcgYnVpbGQgcGFyYW1ldGVycyB0aGF0IGFmZmVjdCBsaW5raW5nLApv cHRpbWl6YXRpb24sIGFuZCB0YXJnZXQgQ1BVLiAgVGhlIHZlcnNpb24gb2YgTExWTSBpbmNs dWRlZCB3aXRoIApGcmVlQlNEIDEzLjEgKGFuZCBtYXliZSAxMi54PykgaW5jbHVkZXMgYSBi dWcgd2l0aCBjZXJ0YWluIHRhcmdldCBDUFVzCnVzaW5nIEFWWC01MTIgaW5zdHJ1Y3Rpb25z IHRoYXQgY2F1c2VzIHRoZSBjb21waWxlciB0byBlbnRlciBhbiBpbmZpbml0ZQpsb29wLCBl dmVudHVhbGx5IHRlcm1pbmF0aW5nIHdoZW4gaXQgaGFzIHVzZWQgYWxsIGF2YWlsYWJsZSBt ZW1vcnkuCgpJSUkuIEltcGFjdAoKV2hlbiBjb21waWxpbmcgY2VydGFpbiBsaWJyYXJpZXMg b3IgYXBwbGljYXRpb25zIHdpdGggdGhlIHN5c3RlbSBMTFZNIAppbiAxMy4xIChhbmQgbWF5 YmUgMTIueD8pIHRoZSBjb21waWxlciB3aWxsIGhhbmcuCgpJVi4gIFdvcmthcm91bmQKClJl bW92aW5nIHRoZSBDUFVUWVBFIG9wdGlvbiBmcm9tIC9ldGMvbWFrZS5jb25mLCBvciBieSBz ZXR0aW5nIGl0IHRvIGEKQ1BVVFlQRSB0aGF0IGRvZXMgbm90IGhhdmUgQVZYNTEyIHdpbGwg cHJldmVudCB0aGUgaW5maW5pdGUgbG9vcC4KClNldHRpbiB0aGUgQ1BVVFlQRSBpcyBhIG5v bi1kZWZhdWx0IHNldHRpbmcsIHN5c3RlbXMgdXNpbmcgZGVmYXVsdApjb25maWd1cmF0aW9u cyBhcmUgdW5hZmZlY3RlZC4KClYuICAgU29sdXRpb24KClBhdGNoIGZyb20gOiBodHRwczov L2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI2NDM5NAoKVXBn cmFkZSB5b3VyIHN5c3RlbSB0byBhIHN1cHBvcnRlZCBGcmVlQlNEIHN0YWJsZSBvciByZWxl YXNlIC8gc2VjdXJpdHkKYnJhbmNoIChyZWxlbmcpIGRhdGVkIGFmdGVyIHRoZSBjb3JyZWN0 aW9uIGRhdGUuCltYWCBOZWVkcyByZWJvb3Q/IE1lbnRpb24gcGxlYXNlXQoKUGVyZm9ybSBv bmUgb2YgdGhlIGZvbGxvd2luZzoKCjEpIFRvIHVwZGF0ZSB5b3VyIHN5c3RlbSB2aWEgYSBi aW5hcnkgcGF0Y2g6CgpTeXN0ZW1zIHJ1bm5pbmcgYSBSRUxFQVNFIHZlcnNpb24gb2YgRnJl ZUJTRCBvbiB0aGUgYW1kNjQsIGkzODYsIG9yCihvbiBGcmVlQlNEIDEzIGFuZCBsYXRlcikg YXJtNjQgcGxhdGZvcm1zIGNhbiBiZSB1cGRhdGVkIHZpYSB0aGUKZnJlZWJzZC11cGRhdGUo OCkgdXRpbGl0eToKCiMgZnJlZWJzZC11cGRhdGUgZmV0Y2gKIyBmcmVlYnNkLXVwZGF0ZSBp bnN0YWxsCltYWCBOZWVkcyByZWJvb3Q/IE1lbnRpb24gcGxlYXNlXQoKMikgVG8gdXBkYXRl IHlvdXIgc3lzdGVtIHZpYSBhIHNvdXJjZSBjb2RlIHBhdGNoOgoKVGhlIGZvbGxvd2luZyBw YXRjaGVzIGhhdmUgYmVlbiB2ZXJpZmllZCB0byBhcHBseSB0byB0aGUgYXBwbGljYWJsZQpG cmVlQlNEIHJlbGVhc2UgYnJhbmNoZXMuCgphKSBEb3dubG9hZCB0aGUgcmVsZXZhbnQgcGF0 Y2ggZnJvbSB0aGUgbG9jYXRpb24gYmVsb3csIGFuZCB2ZXJpZnkgdGhlCmRldGFjaGVkIFBH UCBzaWduYXR1cmUgdXNpbmcgeW91ciBQR1AgdXRpbGl0eS4KCltGcmVlQlNEIDEzLjFdCgpi KSBBcHBseSB0aGUgcGF0Y2guICBFeGVjdXRlIHRoZSBmb2xsb3dpbmcgY29tbWFuZHMgYXMg cm9vdDoKCiMgY2QgL3Vzci9zcmMKIyBwYXRjaCA8IC9wYXRoL3RvL3BhdGNoCgo8Zm9yIGEg dXNlcmxhbmQgdXRpbGl0eTo+CgpjKSBSZWNvbXBpbGUgdGhlIG9wZXJhdGluZyBzeXN0ZW0g dXNpbmcgYnVpbGR3b3JsZCBhbmQgaW5zdGFsbHdvcmxkIGFzCmRlc2NyaWJlZCBpbiA8VVJM Omh0dHBzOi8vd3d3LkZyZWVCU0Qub3JnL2hhbmRib29rL21ha2V3b3JsZC5odG1sPi4KClZJ LiAgQ29ycmVjdGlvbiBkZXRhaWxzCgpUaGlzIGlzc3VlIGlzIGNvcnJlY3RlZCBieSB0aGUg Y29ycmVzcG9uZGluZyBHaXQgY29tbWl0IGhhc2ggb3IgU3VidmVyc2lvbgpyZXZpc2lvbiBu dW1iZXIgaW4gdGhlIGZvbGxvd2luZyBzdGFibGUgYW5kIHJlbGVhc2UgYnJhbmNoZXM6CgpC cmFuY2gvcGF0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGFzaCAgICAgICAgICAg ICAgICAgICAgIFJldmlzaW9uCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0Kc3RhYmxlLzEzLyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFhYWFhYWFhYWFhYWCAgICBzdGFibGUvMTMtblhY WFhYWApyZWxlbmcvMTMuMS8gICAgICAgICAgICAgICAgICAgICAgICAgICAgWFhYWFhYWFhY WFhYICByZWxlbmcvMTMuMS1uWFhYWFhYCnJlbGVuZy8xMy4wLyAgICAgICAgICAgICAgICAg ICAgICAgICAgICBYWFhYWFhYWFhYWFggIHJlbGVuZy8xMy4wLW5YWFhYWFgKc3RhYmxlLzEy LyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgclhYWFhYWApyZWxlbmcvMTIuMy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByWFhYWFhYCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkZv ciBGcmVlQlNEIDEzIGFuZCBsYXRlcjoKClJ1biB0aGUgZm9sbG93aW5nIGNvbW1hbmQgdG8g c2VlIHdoaWNoIGZpbGVzIHdlcmUgbW9kaWZpZWQgYnkgYQpwYXJ0aWN1bGFyIGNvbW1pdDoK CiMgZ2l0IHNob3cgLS1zdGF0IDxjb21taXQgaGFzaD4KCk9yIHZpc2l0IHRoZSBmb2xsb3dp bmcgVVJMLCByZXBsYWNpbmcgTk5OTk5OIHdpdGggdGhlIGhhc2g6Cgo8VVJMOmh0dHBzOi8v Y2dpdC5mcmVlYnNkLm9yZy9zcmMvY29tbWl0Lz9pZD1OTk5OTk4+CgpUbyBkZXRlcm1pbmUg dGhlIGNvbW1pdCBjb3VudCBpbiBhIHdvcmtpbmcgdHJlZSAoZm9yIGNvbXBhcmlzb24gYWdh aW5zdApuTk5OTk5OIGluIHRoZSB0YWJsZSBhYm92ZSksIHJ1bjoKCiMgZ2l0IHJldi1saXN0 IC0tY291bnQgLS1maXJzdC1wYXJlbnQgSEVBRAoKRm9yIEZyZWVCU0QgMTIgYW5kIGVhcmxp ZXI6CgpSdW4gdGhlIGZvbGxvd2luZyBjb21tYW5kIHRvIHNlZSB3aGljaCBmaWxlcyB3ZXJl IG1vZGlmaWVkIGJ5IGEgcGFydGljdWxhcgpyZXZpc2lvbiwgcmVwbGFjaW5nIE5OTk5OTiB3 aXRoIHRoZSByZXZpc2lvbiBudW1iZXI6CgojIHN2biBkaWZmIC1jTk5OTk5OIC0tc3VtbWFy aXplIHN2bjovL3N2bi5mcmVlYnNkLm9yZy9iYXNlCgpPciB2aXNpdCB0aGUgZm9sbG93aW5n IFVSTCwgcmVwbGFjaW5nIE5OTk5OTiB3aXRoIHRoZSByZXZpc2lvbiBudW1iZXI6Cgo8VVJM Omh0dHBzOi8vc3Zud2ViLmZyZWVic2Qub3JnL2Jhc2U/dmlldz1yZXZpc2lvbiZyZXZpc2lv bj1OTk5OTk4+CgpWSUkuIFJlZmVyZW5jZXMKCjxvdGhlciBpbmZvIG9uIHRoZSBwcm9ibGVt PgoKPFVSTDpodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dp P2lkPVhYWFhYWD4KClRoZSBsYXRlc3QgcmV2aXNpb24gb2YgdGhpcyBhZHZpc29yeSBpcyBh dmFpbGFibGUgYXQKPFVSTDpodHRwczovL3NlY3VyaXR5LkZyZWVCU0Qub3JnL2Fkdmlzb3Jp ZXMvRnJlZUJTRC1FTi1YWDpYWC5YWFhYWC5hc2M+Cg== --------------r8DW6W0TvfBIovosGKrxkk0C Content-Type: text/plain; charset=UTF-8; name="userboot.txt" Content-Disposition: attachment; filename="userboot.txt" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0KRnJlZUJTRC1FTi1FUlJBVEFfVEVNUExBVEUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVycmF0YSBOb3RpY2UKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo ZSBGcmVlQlNEIFByb2plY3QKClRvcGljOgoKQ2F0ZWdvcnk6ICAgICAgIGNvcmUKTW9kdWxl OiAgICAgICAgIGJoeXZlCkFubm91bmNlZDogICAgICAyMDIyLVhYLVhYCkNyZWRpdHM6CkFm ZmVjdHM6ICAgICAgICAxMy4xCkNvcnJlY3RlZDogICAgICAyMDIyLVhYLVhYIFhYOlhYOlhY IFVUQyAoc3RhYmxlLzEzLCAxMy4xLVNUQUJMRSkKICAgICAgICAgICAgICAgIDIwMjItWFgt WFggWFg6WFg6WFggVVRDIChyZWxlbmcvMTMuMSwgMTMuMS1SRUxFQVNFLXBYWCkKCkZvciBn ZW5lcmFsIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBGcmVlQlNEIEVycmF0YSBOb3RpY2VzIGFu ZCBTZWN1cml0eQpBZHZpc29yaWVzLCBpbmNsdWRpbmcgZGVzY3JpcHRpb25zIG9mIHRoZSBm aWVsZHMgYWJvdmUsIHNlY3VyaXR5CmJyYW5jaGVzLCBhbmQgdGhlIGZvbGxvd2luZyBzZWN0 aW9ucywgcGxlYXNlIHZpc2l0CjxVUkw6aHR0cHM6Ly9zZWN1cml0eS5GcmVlQlNELm9yZy8+ LgoKSS4gICBCYWNrZ3JvdW5kCgpiaHl2ZSBpcyB0aGUgRnJlZUJTRCBoeXBlcnZpc29yLCBs b2FkZXIgaXMgdGhlIEZyZWVCU0QgYm9vdCBsb2FkZXIsCnVzZXJib290LnNvIGlzIGEgdmVy c2lvbiBvZiBsb2FkZXIgdGhhdCBydW5zIGluIHVzZXJsYW5kIGFzIHBhcnQgb2YgdGhlIApi aHl2ZWxvYWQgcHJvY2VzcyB0byBzZXR1cCB0aGUgYmh5dmUgZW52aXJvbmVtbnQgZm9yIGV4 ZWN1dGluZyBhIEZyZWVCU0QKZ3Vlc3Qgb3BlcmF0aW5nIHN5c3RlbSB1bmRlciBiaHl2ZS4K CkJJTkRfTk9XIGlzIGEgc3lzdGVtIGhhcmRlbmluZyBzZXR0aW5nIHRoYXQgbWFrZXMgY2Vy dGFpbiB0eXBlcyBvZgptZW1vcnkgY29ycnVwdGlvbiBtb3JlIGRpZmZpY3VsdC4KCklJLiAg UHJvYmxlbSBEZXNjcmlwdGlvbgoKQ29tcGlsaW5nIHRoZSB3b3JsZCB3aXRoIEJJTkRfTk9X IChhIG5vbi1kZWZhdWx0IG9wdGlvbikgcmVzdWx0cyBpbiBhCnZlcnNpb24gb2YgdXNlcmJv b3Quc28gdGhhdCB3aWxsIG5vdCBsaW5rIHdpdGggYmh5dmVsb2FkLCBwcmV2ZW50aW5nCnNl dHVwIGFuZCBleGVjdXRpb24gb2YgRnJlZUJTRCBiYXNlZCBndWVzdCBvcGVyYXRpbmcgc3lz dGVtcyB3aXRoIHRoZQpiaHl2ZSBWTS4KCklJSS4gSW1wYWN0CgpTeXN0ZW1zIHRoYXQgY2hv b3NlIHRoaXMgaGFyZGVuaW5nIG9wdGlvbiBhcmUgdW5hYmxlIHRvIHJ1biB0aGUgZGVmYXVs dAp0eXBlIG9mIEZyZWVCU0QgVk0gdW5kZXIgYmh5dmUuCgpJVi4gIFdvcmthcm91bmQKCk11 bHRpcGxlIHdvcmthcm91bmRzIGV4aXN0LgogYSkgUmVtb3ZpbmcgQklORF9OT1cgZnJvbSBz eXN0ZW0gYnVpbGQgb3B0aW9ucyBpbiBzcmMuY29uZiBhbmQgcmVidWlsZGluZwogYikgdXNp bmcgVUVGSSBiYXNlZCBiaHl2ZSBWTXMgKG5vdCBhdmFpbGFibGUgb24gYWxsIGhhcmR3YXJl KQogYykgdXNpbmcgYSBkaWZmZXJlbnQgdmVyc2lvbiBvZiB1c2VyYm9vdC5zbyB2aWEgdGhl IC1sIG9wdGlvbiB0bwogICAgYmh5dmVsb2FkLiAgRm9yIGV4YW1wbGUgb25lIHNhdmVkIGlu IGFuIGFsdGVybmF0ZSBsb2NhdGlvbiBhZnRlciBhIGJ1aWxkCiAgICB3aXRob3V0IEJJTkRf Tk9XCgpWLiAgIFNvbHV0aW9uCgpBcHBseSBwYXRjaCBmcm9tOgpodHRwczovL2J1Z3MuZnJl ZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI2MjkyMAoKVXBncmFkZSB5b3Vy IHN5c3RlbSB0byBhIHN1cHBvcnRlZCBGcmVlQlNEIHN0YWJsZSBvciByZWxlYXNlIC8gc2Vj dXJpdHkKYnJhbmNoIChyZWxlbmcpIGRhdGVkIGFmdGVyIHRoZSBjb3JyZWN0aW9uIGRhdGUu CgpEb2VzIG5vdCBuZWVkIHJlYm9vdC4KClBlcmZvcm0gb25lIG9mIHRoZSBmb2xsb3dpbmc6 CgoxKSBUbyB1cGRhdGUgeW91ciBzeXN0ZW0gdmlhIGEgYmluYXJ5IHBhdGNoOgoKU3lzdGVt cyBydW5uaW5nIGEgUkVMRUFTRSB2ZXJzaW9uIG9mIEZyZWVCU0Qgb24gdGhlIGFtZDY0LCBp Mzg2LCBvcgoob24gRnJlZUJTRCAxMyBhbmQgbGF0ZXIpIGFybTY0IHBsYXRmb3JtcyBjYW4g YmUgdXBkYXRlZCB2aWEgdGhlCmZyZWVic2QtdXBkYXRlKDgpIHV0aWxpdHk6CgojIGZyZWVi c2QtdXBkYXRlIGZldGNoCiMgZnJlZWJzZC11cGRhdGUgaW5zdGFsbApbWFggTmVlZHMgcmVi b290PyBNZW50aW9uIHBsZWFzZV0KCjIpIFRvIHVwZGF0ZSB5b3VyIHN5c3RlbSB2aWEgYSBz b3VyY2UgY29kZSBwYXRjaDoKClRoZSBmb2xsb3dpbmcgcGF0Y2hlcyBoYXZlIGJlZW4gdmVy aWZpZWQgdG8gYXBwbHkgdG8gdGhlIGFwcGxpY2FibGUKRnJlZUJTRCByZWxlYXNlIGJyYW5j aGVzLgoKYSkgRG93bmxvYWQgdGhlIHJlbGV2YW50IHBhdGNoIGZyb20gdGhlIGxvY2F0aW9u IGJlbG93LCBhbmQgdmVyaWZ5IHRoZQpkZXRhY2hlZCBQR1Agc2lnbmF0dXJlIHVzaW5nIHlv dXIgUEdQIHV0aWxpdHkuCgpbRnJlZUJTRCAxMy4xXQojIGZldGNoIGh0dHBzOi8vc2VjdXJp dHkuRnJlZUJTRC5vcmcvcGF0Y2hlcy9FTi1YWDpYWC9YWFhYLnBhdGNoCiMgZmV0Y2ggaHR0 cHM6Ly9zZWN1cml0eS5GcmVlQlNELm9yZy9wYXRjaGVzL0VOLVhYOlhYL1hYWFgucGF0Y2gu YXNjCiMgZ3BnIC0tdmVyaWZ5IFhYWFgucGF0Y2guYXNjCgpiKSBBcHBseSB0aGUgcGF0Y2gu ICBFeGVjdXRlIHRoZSBmb2xsb3dpbmcgY29tbWFuZHMgYXMgcm9vdDoKCiMgY2QgL3Vzci9z cmMKIyBwYXRjaCA8IC9wYXRoL3RvL3BhdGNoCgo8Zm9yIGEgdXNlcmxhbmQgdXRpbGl0eTo+ CgpjKSBSZWNvbXBpbGUgdGhlIG9wZXJhdGluZyBzeXN0ZW0gdXNpbmcgYnVpbGR3b3JsZCBh bmQgaW5zdGFsbHdvcmxkIGFzCmRlc2NyaWJlZCBpbiA8VVJMOmh0dHBzOi8vd3d3LkZyZWVC U0Qub3JnL2hhbmRib29rL21ha2V3b3JsZC5odG1sPi4KClZJLiAgQ29ycmVjdGlvbiBkZXRh aWxzCgpUaGlzIGlzc3VlIGlzIGNvcnJlY3RlZCBieSB0aGUgY29ycmVzcG9uZGluZyBHaXQg Y29tbWl0IGhhc2ggb3IgU3VidmVyc2lvbgpyZXZpc2lvbiBudW1iZXIgaW4gdGhlIGZvbGxv d2luZyBzdGFibGUgYW5kIHJlbGVhc2UgYnJhbmNoZXM6CgpCcmFuY2gvcGF0aCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSGFzaCAgICAgICAgICAgICAgICAgICAgIFJldmlzaW9u Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0Kc3RhYmxlLzEzLyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFhYWFhYWFhYWFhYWCAgICBzdGFibGUvMTMtblhYWFhYWApyZWxlbmcvMTMuMS8g ICAgICAgICAgICAgICAgICAgICAgICAgICAgWFhYWFhYWFhYWFhYICByZWxlbmcvMTMuMS1u WFhYWFhYCnJlbGVuZy8xMy4wLyAgICAgICAgICAgICAgICAgICAgICAgICAgICBYWFhYWFhY WFhYWFggIHJlbGVuZy8xMy4wLW5YWFhYWFgKc3RhYmxlLzEyLyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgclhYWFhYWApyZWxlbmcv MTIuMy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByWFhYWFhYCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCkZvciBGcmVlQlNEIDEzIGFuZCBs YXRlcjoKClJ1biB0aGUgZm9sbG93aW5nIGNvbW1hbmQgdG8gc2VlIHdoaWNoIGZpbGVzIHdl cmUgbW9kaWZpZWQgYnkgYQpwYXJ0aWN1bGFyIGNvbW1pdDoKCiMgZ2l0IHNob3cgLS1zdGF0 IDxjb21taXQgaGFzaD4KCk9yIHZpc2l0IHRoZSBmb2xsb3dpbmcgVVJMLCByZXBsYWNpbmcg Tk5OTk5OIHdpdGggdGhlIGhhc2g6Cgo8VVJMOmh0dHBzOi8vY2dpdC5mcmVlYnNkLm9yZy9z cmMvY29tbWl0Lz9pZD1OTk5OTk4+CgpUbyBkZXRlcm1pbmUgdGhlIGNvbW1pdCBjb3VudCBp biBhIHdvcmtpbmcgdHJlZSAoZm9yIGNvbXBhcmlzb24gYWdhaW5zdApuTk5OTk5OIGluIHRo ZSB0YWJsZSBhYm92ZSksIHJ1bjoKCiMgZ2l0IHJldi1saXN0IC0tY291bnQgLS1maXJzdC1w YXJlbnQgSEVBRAoKRm9yIEZyZWVCU0QgMTIgYW5kIGVhcmxpZXI6CgpSdW4gdGhlIGZvbGxv d2luZyBjb21tYW5kIHRvIHNlZSB3aGljaCBmaWxlcyB3ZXJlIG1vZGlmaWVkIGJ5IGEgcGFy dGljdWxhcgpyZXZpc2lvbiwgcmVwbGFjaW5nIE5OTk5OTiB3aXRoIHRoZSByZXZpc2lvbiBu dW1iZXI6CgojIHN2biBkaWZmIC1jTk5OTk5OIC0tc3VtbWFyaXplIHN2bjovL3N2bi5mcmVl YnNkLm9yZy9iYXNlCgpPciB2aXNpdCB0aGUgZm9sbG93aW5nIFVSTCwgcmVwbGFjaW5nIE5O Tk5OTiB3aXRoIHRoZSByZXZpc2lvbiBudW1iZXI6Cgo8VVJMOmh0dHBzOi8vc3Zud2ViLmZy ZWVic2Qub3JnL2Jhc2U/dmlldz1yZXZpc2lvbiZyZXZpc2lvbj1OTk5OTk4+CgpWSUkuIFJl ZmVyZW5jZXMKCjxvdGhlciBpbmZvIG9uIHRoZSBwcm9ibGVtPgoKPFVSTDpodHRwczovL2J1 Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPVhYWFhYWD4KClRoZSBs YXRlc3QgcmV2aXNpb24gb2YgdGhpcyBhZHZpc29yeSBpcyBhdmFpbGFibGUgYXQKPFVSTDpo dHRwczovL3NlY3VyaXR5LkZyZWVCU0Qub3JnL2Fkdmlzb3JpZXMvRnJlZUJTRC1FTi1YWDpY WC5YWFhYWC5hc2M+Cg== --------------r8DW6W0TvfBIovosGKrxkk0C-- From nobody Thu Dec 15 22:29:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NY6Nj6JLDz4gd2Y for ; Thu, 15 Dec 2022 22:29:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NY6Nj09Hmz4QQJ for ; Thu, 15 Dec 2022 22:29:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=FKxZ+wAY; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671143379; bh=DgXuMQRoeymP0ya+NHRQuyaaR8WAeIYaSXPV09z2scE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=FKxZ+wAYbVc6RxPNKL6vIwNRL4ek3pBmg/pynXS6nVVyDtaKpev80w/lHD35mNJ36P28mgvZAaAzHnXuk9zCinEd55h3kYW78KEMk+AYjXNbv5AeyDmeO6cUtBhtTb3DObNRxyVXyWeJGGMoTa+o5gSmKfhwiPcwadIplLNDKPYJ00qfse+ITn+zj50JG6j1swXPT4j1rbGewg0r05Cfjr6CMEeWFF/n4E5EjTcydhHfSCpenQzIhkuCGjnLepX05aR53m2dOFn7fHVEZ0yAl8Dgobx725YxawlXvF72stzjJohzV+3+JkiNRpFeHydCJ8FWWWTuygJEo+TePN2rhQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1671143379; bh=mj2q+/CQz/5g7lNDvvKqLuFYBviMpekvpeD/XN+99Lu=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=Xm0s8+RIkca4Q02gvA/jfcCYVMELSAkB0WkXGtJGeZ4DLhTBkP1i422qu4nPMrvG5alM8fIUhQtPxZN2ChkkRliIFxtD48h5+iHLxMKj0NS3M6/O3H1RNFDzJd+C9l/YragqmjOu1v/FtDLKwh08Il9CiZ8kJVoSSbokEVd2fz3SFy6PFkdPkj+7YFNHJV47+idoW5vgmAS+C7eVW7yRGpODuZmazrAGM9w40RO3bQaHuAc87HuO2hA4yRtygYQp434J1LyW0UDCA4+5LhaZi7lXbTpP6WIGSPRuTr0ZzxMXTOHy+Ly5akWQPRCWM8pftIEtxcmvj1OU2MTu2nud5g== X-YMail-OSG: M7qrLWAVM1kNrQ264tenYvV.l.5Z5Cp7eCiHX_PwCSexhgx9dYIeGAe4g80f4MX kfLxSPKSDomYzU340fp6spUySPx6pr_5ygeZPfWgkREGjBZkKaaum2PYvShU5xO9O7nQDg0S.6dv 22DO_EL_6OyCuQ5sNyGBaoim2T_bBn_6iDFq9UEjW7W5sPu4vMY__1pk73bV.0qgT0HBGP58FPBi j_oXwwRQyk6rLgXcD.OSgubCNPyebiWHovPV7IK1GoiwOPk7R0XID1EKTr.uwRPc3aQiIiOS8ZB_ VUvRRc3T9HJXee77yvlUqGFmKTV1F5EaMZ5otjskp_YGkKtvJJv0oxrUdhM71QrKPDmiaPjUVO.6 11E7tU1emvu7jMSHeE_M7GzdJh46Ttqc_fqlDBKqPb.ptmU7ktPb9LRoyImAmtVQBZSRz7y4dvN. ERyJHpPMhPTmVLWHGTlOODBOkiPpTHJqhd_4QqWo.5MlhSNJMWluCka4M4XSTfIYLWhIYiKCSJuO PQP3AbW6FaQEXEroSPN_lt29cdK2iiUOlcTKMvV75PtznK_P2x_zIIV.ItgME0NgRYgqpiiYz2jQ AcuHdn8oN71Zq8Rgom6ljZ63z4gUGEirobJ9A.l3TnKFgVFjg0cJb4HQ_jiB93FUNBc6BbfF97Wg BUTb_LKw7HasKaGRS8On48Pg7KGj4I9jCmUIkGOg0ZO_v7y.sSeZXtsqjobIu5EGEi8AAchsl8W9 st3wl.GbB4E1VwH_4Yf4sCiXtmKh1fmwJm.Knlzu1Pr465vEy1ySRKSOvOtkfl8Uyk0nhlMKkL3u Ip6a7FR_hV5SYki8VD2YcuxtfsS8oxqWt4aHEuKo0ToQXdklWVNSsMEQkgozQlHg01H7ig2fnN2M Hy5T38E5ROX0Ijdy0QTxshqqjG.yOj9Hg1fzChsABSLMJ40UJ_SebTFsdtYD3ltxdYSxm1IuFYIT TRwczIyL1YP3Raa5CQvuZAZTi1skcDQq_yWXfKiW3gPRLV5Pk28MLm4meZIgAW4M.fwVBVwFQasO oyWlFfmyy6jU5GMydMe2vqJHUvqvuBjFugD2uXQth93uM_5oq6c.PlNpYeKgtESa0ef04sXvy8nc V7bT1FBeQntOMeoWkeHcMfsDYatmYxLsHDLbTfn0aDYx5gDCKP_BhZ7iZ_19wsRJ.t7D3P4IzTQ6 VDAk5PNtIMEGwPlAfo7_A2PQD9mUpIA9K0kbINGmTQhaz2xQpV2ZZOMgvBQfr6Tpda6Wa5KJ9TMG dcNHNX3eBo_x8yFzECA.l1tYKnN2m40w1gCLeyoZsuILHy9pbaCTq30i4JGN9Dl_AQQVo0cN5sRd qtW8HyEMJpS.gitx8Bxezp6HT9CUlc5aiahiq_ESgT39vsE8RgJ7Q7F5el7sq3nJrz85iefUbCq4 zNt6k_1WLAUcsnFv5RcxYxb7FwVidmyaOORcyBqUwCW9uhqYEka9BL30cEcUOWt9WrYMLMQ1.6JL K6vyVKfztDgTEIjipsUr_Sl9LchMxtSquBjFufCjlBwtKNaD.thT7ruMtNs_tjIkDldGOGL1EmDA 9_Of4d7bPSp_SfSuNK2_JHG.JnrK.36VtNs42uHcFkbD3zySurOORgg3uLtqDCyfhBKwSf49Vpt4 KfFHTXWWE4V6VuO1dw4_yG5kpUcNWNnIoj_bQbHAxYB7HwQh5lDZogrj.9U7oYooMk12ZrNCYIHh d1dsLB7eMLRcgUGEsJ20AhvHU59WWnm7U2V55QoTXJVMll02WbJ6SKPPDM0b2YIZ2SeKDawIDCj7 kl7avFnzPtDDbObmjU.HqKPyKpLALgg3zvfok8nk4QeYRKyaceUZFWW8CdlXtx5JlBKQBix935vl dh93grnG_0u8F_QHWlywf0GZptTIkpwTVH8LX6WWKlBoSjcYxf9gCKQBy1PuQgRfCKLyAiFGg5_2 CUcyx0tfPeXT_z249md93hDzM0mx5KGPO679fcNxE_P5D9xPFwCSU4hKcvQtltWSajL1TrIjlXho BKOiwoD5Or_e89NDjDDiWMms5sF.7jgbf16ruwOleu1KrpD7M85XCiV77FkirMsvBeDMhcWi_zvT bYDiky0jL_W1j7M7..xPIyDB1yjRjX6bbLYWNDRbl8lt23mDFXCUgNkABOnp3jFyMkJUHI7mEWG1 UiOMVHSo5QtGZd0yEm2.J_i0bdTdm4bCu_txu5z3Y4wNVXMfm1mWGk5B7GIH1IeM4V7JA_gi4.24 h.gxqnKul7Uwmy.UMYbFQFyMEG0Uf3ozEn8NZp1XYfNfuDvTKf5KB.o.kPw-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Thu, 15 Dec 2022 22:29:39 +0000 Received: by hermes--production-bf1-5458f64d4-97x65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cf0927698f4f8aeb6ac951de83ea1ebf; Thu, 15 Dec 2022 22:29:34 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Question: device_t related code vs. FDT's lack of define before use/reference requirements: is there a normal FreeBSD technique to deal with such? Message-Id: <49DA69A2-EB65-4BF6-8234-90A22983B965@yahoo.com> Date: Thu, 15 Dec 2022 14:29:21 -0800 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.200.110.1.12) References: <49DA69A2-EB65-4BF6-8234-90A22983B965.ref@yahoo.com> X-Spamd-Result: default: False [-2.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.990]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.84:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4NY6Nj09Hmz4QQJ X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N While the RPi4B's provide the example here, as far as I can tell, nothing here need be RPi* specific: the question is more general for FDT involvement in the device_t related activity. Modern RPi4B live FDT's have the sequencing: mmc@7e300000 { compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; . . . dmas =3D <0x0000000c 0x0000000b>; . . . }; . . . . . . Note: the brcm,bcm2835-mmc related attach attempts to use the = later dma@7e007000 . . . instance of brcm,bcm2835-dma. (Note the 0x0000000c phandle = referenced is . . . defined below as well: reference before definition.) . . . The result is a kernel crash from a bad dereference of = bcm_dma_sc->sc_mtx . . . (really sc=3Dbcm_dma_sc then later sc->sc_mtx). . . . dma@7e007000 { compatible =3D "brcm,bcm2835-dma"; . . . interrupt-names =3D "dma0", "dma1", "dma2", = "dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x000007f5>; phandle =3D <0x0000000c>; }; . . . mmcnr@7e300000 { compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; . . . dmas =3D <0x0000000c 0x0000000b>; dma-names =3D "rx-tx"; . . . }; How is the device_t related probing and attachment of FreeBSD devices supposed to work for such a FDT ordering of the information? Are there one or more identified ways of handling such? Or does FreeBSD effectively require define before use/reference in FDT's in general? =20 The code happened to not fail back when the RPi* firmware happened to have the FDT sequencing (phandle 0x0000000b for this example): dma@7e007000 { compatible =3D "brcm,bcm2835-dma"; . . . interrupt-names =3D "dma0", "dma1", "dma2", = "dma3", "dma4", "dma5", "dma6", "dma7", "dma8", "dma9", "dma10"; #dma-cells =3D <0x00000001>; brcm,dma-channel-mask =3D <0x000007f5>; phandle =3D <0x0000000b>; }; . . . mmc@7e300000 { compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; . . . dmas =3D <0x0000000b 0x0000000b>; dma-names =3D "rx-tx"; . . . }; mmcnr@7e300000 { compatible =3D "brcm,bcm2835-mmc", = "brcm,bcm2835-sdhci"; . . . dmas =3D <0x0000000b 0x0000000b>; dma-names =3D "rx-tx"; . . . }; (which happens to be: define before use/reference). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Dec 16 01:11:56 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NYB0g1nnfz4jk8D; Fri, 16 Dec 2022 01:12:35 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NYB0f3K7wz4brQ; Fri, 16 Dec 2022 01:12:34 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=KGsZeDix; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x62a.google.com with SMTP id kw15so2679463ejc.10; Thu, 15 Dec 2022 17:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=PBmZn10ZrN4xHot1gs1KpCzU0/He1drW0qRShKJmELQ=; b=KGsZeDixsE4BvNehvST3HuSWu8b1JRgNZnwPWA8LzWsCdQweGJOVIRjoDGLlXLoy8X Qol7ifzFkD+n0tI4+xdVT1DTw+DTHcm/zfIMDEDxzBC3WbDM1yx2KCOobe2d9DiUpfsj eQ1XVBM7tYHo7ocUvrhhnYGJ+juuIhdfdCIE9WCW1ndssPE81y5JfYV40Z4gEfhviKmg 6UnIAmkQYUIFwOYD6A2ogIqbvHGFuUXWaQpIJMhaAgXIv5QzFmz2FMHzNpaD6qqyd//w y2g2v8UJ5YvIhyWl9LjxNYm1PJXiWgIxu6GvNGMAezQOT2bFaY5tFIHPMG5iiw6j/EEM WwmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PBmZn10ZrN4xHot1gs1KpCzU0/He1drW0qRShKJmELQ=; b=nPGRUPezLMd5amvVQ0XrwMS+1uNCR/eHwsUc+iZ6KbeR8rxM/+3z6DjiTjJUPKKu/r fBPkTYXYSlontgR0WKozizromhg2QTr2mP2m8rAtSqLZG543BQER/80hlkNgkXSHAs6O H8hxJ0HgFGxUG7zDSUzJ32EDrTwK25hjGNJYTCtej/SJQDYoudikH4bkNCSk10NVi4C3 I5dFapIA4MB4MVQ+Av0QPO/lrMKFR74Lwxvqk0eeVW4Ao+u6OK6jNm8NI+0VNJxUwyLT MH8Nvgb2DrTRKVgWbSt3C17TklSTX45xzufDf50P+jn1YUbXnIwpZ6i+73798FNoF8/o C+Og== X-Gm-Message-State: AFqh2kpiA9CXIKPI/xUZoUfwyAeWEVpBrSH++68bF552ivbmylk96Q/R T4MZpybyt5y4MKiU/p5+ldMFchdiGdEbQneyOWXqB+Sy0ye17g== X-Google-Smtp-Source: AMrXdXtsHanNyv8AaYcfgNIV3f1jnyqsLDpwAkohOXuuZacxx8VxuXQ2Okm4lIh7KiGVtXCamtIIyMF4+Z6DlkAz0EI= X-Received: by 2002:a17:907:c298:b0:7e4:12bd:da33 with SMTP id tk24-20020a170907c29800b007e412bdda33mr14478ejc.434.1671153152487; Thu, 15 Dec 2022 17:12:32 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Fri, 16 Dec 2022 02:11:56 +0100 Message-ID: Subject: snd_hda_intel 0000:00:08.1: failed to bind 0000:00:07.0 (ops i915_audio_component_bind_ops [i915]): -17 To: FreeBSD virtualization , hackers@freebsd.org, freebsd-x11+help@freebsd.org, virtualization@freebsd.org, =?UTF-8?Q?Corvin_K=C3=B6hne?= Content-Type: multipart/alternative; boundary="00000000000004f5c605efe7aa56" X-Spamd-Result: default: False [-2.83 / 15.00]; HTTP_TO_IP(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.83)[-0.828]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62a:from]; TAGGED_RCPT(0.00)[help]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-virtualization@freebsd.org,hackers@freebsd.org,freebsd-x11@freebsd.org,virtualization@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NYB0f3K7wz4brQ X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000004f5c605efe7aa56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello to everyone. I get the following error message when I try to passthru my intel graphic card (00:02.0 Display controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] (rev 02)) to a Linux VM : bhyve: Warning: Unable to reuse host address of Graphics Stolen Memory. GPU passthrough might not work properly. bhyve: gvt_d_setup_opregion: Unable to get OpRegion base and length bhyve: gvt_d_init: Unable to setup OpRegion device emulation initialization error: Operation not supported by device Can someone explain to me how to fix it ? I'm running FreeBSD 13.1. Actually on my PC there are 3 graphics cards : a) CoffeeLake-S GT2 [UHD Graphics 630] b) two nvidia graphic cards : 1) GTX 1060 2) RTX 2080 ti on the BIOS I'm using the GTX 1060 as default graphic card and I've disabled the CSM mode. on FreeBSD I have attached two monitors on the GTX 1060 in twin mode,using this xorg.conf file : https://pastebin.ubuntu.com/p/3tGnNQBDBR/ Instead,these are the config file used on FreeBSD : 1) /boot/loader.conf pptdevs=3D"0/2/0 2/0/0 2/0/1 2/0/2 2/0/3" 2) Linux bhyve vm : bhyve -S -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \ -s 0,hostbridge \ -s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.img,bootindex=3D1= \ -s 3,virtio-blk,/dev/$vmdisk4 \ -s 4,virtio-blk,/dev/$vmdisk2 \ -s 5,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h=3D950,wait \ -s 7:0,passthru,0/2/0 \ -s 10,virtio-net,tap19 \ -s 11,virtio-9p,sharename=3D/ \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd \ vm0:19 < /dev/null & sleep 2 && vncviewer 0:19 where : 0/2/0 : 00:02.0 Display controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] (rev 02) 1/0/0 : 01:00.0 VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 3GB] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GP106 High Definition Audio Controller (rev a1) 2/0/0 : 2:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) 02:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Controller (rev a1) 02:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (rev a1) 02:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Controller (rev a1) This log can be of interest. It explains more in detail the reasons why my Intel IGPU is assigned to a Linux guest OS,but it does not work (the screen remains black). LOG FILE : [ 2.970719] i915 0000:00:07.0: [drm] VT-d active for gfx access [ 2.970874] Console: switching to colour dummy device 80x25 [ 2.970945] i915 0000:00:07.0: [drm] Transparent Hugepage mode =E2=80=98huge=3Dwithin_size=E2=80=99 [ 2.971316] i915 0000:00:07.0: BAR 6: can=E2=80=99t assign [??? 0x00000000 = flags 0x20000000] (bogus alignment) [ 2.971319] i915 0000:00:07.0: [drm] Failed to find VBIOS tables (VBT) [ 3.060611] i915 0000:00:07.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 3.060868] [drm] [nvidia-drm] [GPU ID 0x00000008] Loading driver [ 3.060819] snd_hda_intel 0000:00:08.1: bound 0000:00:07.0 (ops i915_hdcp_component_ops [i915]) [ 3.060948] ------------[ cut here ]------------ [ 3.060949] WARNING: CPU: 3 PID: 307 at sound/hda/hdac_component.c:196 hdac_component_master_bind+0x9a/0x110 [snd_hda_core] [ 3.060957] Modules linked in: nls_iso8859_1 nvidia_drm(PO+) nvidia_modeset(PO) chromeos_pstore(-) i915(+) nvidia(PO) drm_buddy ttm snd_hda_codec_hdmi snd_hda_intel intel_rapl_msr intel_rapl_common snd_intel_dspcfg drm_display_helper snd_intel_sdw_acpi snd_hda_codec cec snd_usb_audio snd_hda_core crct10dif_pclmul snd_usbmidi_lib rc_core ghash_clmulni_intel snd_hwdep aesni_intel crypto_simd cryptd dr m_kms_helper snd_seq_midi rapl joydev input_leds snd_pcm snd_seq_midi_event fb_sys_fops nvidiafb syscopyarea vgastate ucsi_ccg(+) 9pnet _virtio sysfillrect fb_ddc typec_ucsi sysimgblt typec video mac_hid 9pnet i2c_algo_bit snd_rawmidi serio_raw snd_seq snd_seq_device snd _timer snd hid_cmedia soundcore v4l2loopback(O) videodev mc msr parport_pc ppdev lp ramoops pstore_blk binfmt_misc drm parport reed_sol omon pstore_zone efi_pstore qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid virtio_net net_failover failover i2c_nvidia_g pu crc32_pclmul xhci_pci psmouse xhci_pci_renesas [ 3.060990] i2c_ccgx_ucsi virtio_blk [ 3.060992] CPU: 3 PID: 307 Comm: systemd-udevd Tainted: P O 5.19.0-26-generic #27-Ubuntu [ 3.060993] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 13.0 11/10/2020 [ 3.060994] RIP: 0010:hdac_component_master_bind+0x9a/0x110 [snd_hda_core] [ 3.061026] Code: ef e8 0a 37 44 d5 85 c0 78 79 48 8d 7b 18 e8 cd 24 38 d4 31 c0 48 83 c4 08 5b 41 5d 5d 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc <0f> 0b b8 ea ff ff ff 48 89 de 4c 89 ef 89 45 ec e8 91 4a bb d4 48 [ 3.061035] RSP: 0018:ffffaaed8034f818 EFLAGS: 00010246 [ 3.061049] RAX: 0000000000000000 RBX: ffff97bf51d3fa48 RCX: 0000000000000000 [ 3.061070] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 3.061071] RBP: ffffaaed8034f830 R08: 0000000000000000 R09: 0000000000000000 [ 3.061072] R10: 0000000000000000 R11: 0000000000000000 R12: ffff97bf4b649700 [ 3.061072] R13: ffff97bf40c540d0 R14: 0000000000000002 R15: ffff97bf4fdfa2f8 [ 3.061073] FS: 00007f8128a058c0(0000) GS:ffff97bf7bd80000(0000) knlGS:0000000000000000 [ 3.061074] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.061075] CR2: 00005555fc5f4a40 CR3: 00000001022f2002 CR4: 00000000003706e0 [ 3.061076] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3.061077] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 3.061078] Call Trace: [ 3.061079] [ 3.061081] try_to_bring_up_aggregate_device+0x87/0x120 [ 3.061084] __component_add+0xba/0x1a0 [ 3.061086] component_add_typed+0x12/0x30 [ 3.061088] intel_hdcp_component_init+0x75/0x110 [i915] [ 3.061201] intel_modeset_init_nogem+0x17f/0x340 [i915] [ 3.061275] i915_driver_probe+0x1d4/0x490 [i915] [ 3.061332] ? drm_privacy_screen_get+0x16d/0x190 [drm] [ 3.061357] ? acpi_dev_found+0x64/0x80 [ 3.061360] i915_pci_probe+0x56/0x150 [i915] [ 3.061415] local_pci_probe+0x47/0x90 [ 3.061418] pci_call_probe+0x55/0x190 [ 3.061419] pci_device_probe+0x84/0x120 [ 3.061423] really_probe+0x1df/0x3b0 [ 3.061424] __driver_probe_device+0x12c/0x1b0 [ 3.061426] driver_probe_device+0x24/0xd0 [ 3.061427] __driver_attach+0xe0/0x210 [ 3.061429] ? __device_attach_driver+0x130/0x130 [ 3.061430] bus_for_each_dev+0x90/0xe0 [ 3.061434] driver_attach+0x1e/0x30 [ 3.061435] bus_add_driver+0x187/0x230 [ 3.061436] driver_register+0x8f/0x100 [ 3.061438] __pci_register_driver+0x62/0x70 [ 3.061440] i915_pci_register_driver+0x23/0x30 [i915] [ 3.061501] i915_init+0x3e/0xf2 [i915] [ 3.061562] ? 0xffffffffc32a1000 [ 3.061564] do_one_initcall+0x5e/0x240 [ 3.061566] do_init_module+0x50/0x210 [ 3.061569] load_module+0xb7d/0xcd0 [ 3.061571] __do_sys_finit_module+0xc4/0x140 [ 3.061572] ? __do_sys_finit_module+0xc4/0x140 [ 3.061574] __x64_sys_finit_module+0x18/0x30 [ 3.061575] do_syscall_64+0x5b/0x90 [ 3.061577] ? __x64_sys_mmap+0x33/0x70 [ 3.061578] ? do_syscall_64+0x67/0x90 [ 3.061579] ? ext4_llseek+0x60/0x120 [ 3.061581] ? ksys_lseek+0x92/0xe0 [ 3.061583] ? exit_to_user_mode_prepare+0x30/0xb0 [ 3.061585] ? syscall_exit_to_user_mode+0x26/0x50 [ 3.061587] ? _ *x64_sys_lseek+0x18/0x30 [ 3.061588] ? do_syscall_64+0x67/0x90 [ 3.061589] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 3.061591] RIP: 0033:0x7f8128916c4d [ 3.061593] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 83 f1 0d 00 f7 d8 64 89 01 48 [ 3.061594] RSP: 002b:00007ffe4526c108 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 3.061596] RAX: ffffffffffffffda RBX: 00005555fc6f17b0 RCX: 00007f8128916c4d [ 3.061596] RDX: 0000000000000000 RSI: 00007f8128ac8458 RDI: 0000000000000019 [ 3.061597] RBP: 00007f8128ac8458 R08: 0000000000000000 R09: 00007ffe4526c230 [ 3.061598] R10: 0000000000000019 R11: 0000000000000246 R12: 0000000000020000 [ 3.061598] R13: 00005555fc60a580 R14: 0000000000000000 R15: 00005555fc6f4020 [ 3.061600] [ 3.061600] =E2=80=94[ end trace 0000000000000000 ]=E2=80=94 [ 3.= 061608] snd_hda_intel 0000:00:08.1: adev bind failed: -22 [ 3.366340] nvidia-gpu 0000:00:08.3: i2c timeout error e0000000 [ 3.366345] ucsi_ccg 0-0008: i2c_transfer failed -110 [ 3.366347] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110 [ 3.366349] ucsi_ccg: probe of 0-0008 failed with error -110 [ 3.426012] tsc: Refined TSC clocksource calibration: 3597.416 MHz [ 3.426024] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33daca713ae, max_idle_ns: 440795269098 ns [ 3.459296] clocksource: Switched to clocksource tsc [ 3.548873] loop0: detected capacity change from 0 to 8 [ 3.549210] Dev loop0: unable to read RDB block 8 [ 3.549215] loop0: unable to read partition table [ 3.549218] loop0: partition table beyond EOD, truncated [ 3.707526] i915 0000:00:07.0: [drm] failed to retrieve link info, disabling eDP [ 3.707815] i915 0000:00:07.0: [drm] [ENCODER:94:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it [ 3.707821] i915 0000:00:07.0: [drm] [ENCODER:111:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it [ 3.707824] i915 0000:00:07.0: [drm] [ENCODER:121:DDI D/PHY D] is disabled/in DSI mode with an ungated DDI clock, gate it [ 4.194609] process =E2=80=98/usr/bin/anydesk= =E2=80=99 started with executable stack [ 4.401745] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if yo u need this. [ 4.854484] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:00:08.0 on minor 1 [ 4.856763] [drm] Initialized i915 1.6.0 20201103 for 0000:00:07.0 on minor 0 [ 4.861400] ------------[ cut here ]------------ [ 4.861405] i915 0000:00:07.0: drm_WARN_ON(acomp->base.ops || acomp->base.dev ) [ 4.861429] WARNING: CPU: 2 PID: 307 at drivers/gpu/drm/i915/display/intel_audio.c:1261 i915_audio_component_bind+0x4b/0x130 [i915] [ 4.861554] Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat n f_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink bridge stp llc overlay nls_iso8859_1 nvidia_drm(PO) nvid ia_modeset(PO) i915(+) nvidia(PO) drm_buddy ttm snd_hda_codec_hdmi snd_hda_intel intel_rapl_msr intel_rapl_common snd_intel_dspcfg drm* display_helper snd_intel_sdw_acpi snd_hda_codec cec snd_usb_audio snd_hda_core crct10dif_pclmul snd_usbmidi_lib rc_core ghash_clmulni_i ntel snd_hwdep aesni_intel crypto_simd cryptd drm_kms_helper snd_seq_midi rapl joydev input_leds snd_pcm snd_seq_midi_event fb_sys_fops nvidiafb syscopyarea vgastate ucsi_ccg 9pnet_virtio sysfillrect fb_ddc typec_ucsi sysimgblt typec video mac_hid 9pnet i2c_algo_bit snd _rawmidi serio_raw snd_seq snd_seq_device snd_timer snd hid_cmedia soundcore v4l2loopback(O) videodev mc msr parport_pc ppdev lp ramoop s pstore_blk binfmt_misc drm parport reed_solomon [ 4.861595] pstore_zone efi_pstore qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid virtio_net net_failover failover i 2c_nvidia_gpu crc32_pclmul xhci_pci psmouse xhci_pci_renesas i2c_ccgx_ucsi virtio_blk [ 4.861605] CPU: 2 PID: 307 Comm: systemd-udevd Tainted: P W O 5.19.0-26-generic #27-Ubuntu [ 4.861607] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 13.0 11/10/2020 [ 4.861607] RIP: 0010:i915_audio_component_bind+0x4b/0x130 [i915] [ 4.861682] Code: 8b 5f 50 48 85 db 0f 84 e8 00 00 00 e8 5e bf 10 d2 48 c7 c1 f8 94 1c c3 48 89 da 48 c7 c7 7a 19 1b c3 48 89 c6 e8 8a 89 5e d2 <0f> 0b b8 ef ff ff ff 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff c3 [ 4.861683] RSP: 0018:ffffaaed8034f7b0 EFLAGS: 00010246 [ 4.861685] RAX: 0000000000000000 RBX: ffff97bf40a91990 RCX: 0000000000000000 [ 4.861686] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 4.861686] RBP: ffffaaed8034f7c8 R08: 0000000000000000 R09: 0000000000000000 [ 4.861687] R10: 0000000000000000 R11: 0000000000000000 R12: ffff97bf40c460d0 [ 4.861688] R13: ffff97bf4fdf8000 R14: ffff97bf51d3fa48 R15: ffff97bf4ba5f340 [ 4.861689] FS: 00007f8128a058c0(0000) GS:ffff97bf7bd00000(0000) knlGS:0000000000000000 [ 4.861690] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.861694] CR2: 00005555fc6f6228 CR3: 00000001022f2004 CR4: 00000000003706e0 [ 4.861695] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4.861695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4.861696] Call Trace: [ 4.861697] [ 4.861700] component_bind+0x63/0x120 [ 4.861705] component_bind_all+0xae/0x140 [ 4.861707] hdac_component_master_bind+0x3a/0x110 [snd_hda_core] [ 4.861715] try_to_bring_up_aggregate_device+0x87/0x120 [ 4.861716] __component_add+0xba/0x1a0 [ 4.861718] component_add_typed+0x12/0x30 [ 4.861719] intel_audio_init+0x43/0xf0 [i915] [ 4.861795] intel_display_driver_register+0x39/0x60 [i915] [ 4.861867] i915_driver_probe+0x25b/0x490 [i915] [ 4.861921] ? drm_privacy_screen_get+0x16d/0x190 [drm] [ 4.861954] ? acpi_dev_found+0x64/0x80 [ 4.861958] i915_pci_probe+0x56/0x150 [i915] [ 4.862081] local_pci_probe+0x47/0x90 [ 4.862085] pci_call_probe+0x55/0x190 [ 4.862087] pci_device_probe+0x84/0x120 [ 4.862088] really_probe+0x1df/0x3b0 [ 4.862091] __driver_probe_device+0x12c/0x1b0 [ 4.862092] driver_probe_device+0x24/0xd0 [ 4.862093] __driver_attach+0xe0/0x210 [ 4.862095] ? __device_attach_driver+0x130/0x130 [ 4.862096] bus_for_each_dev+0x90/0xe0 [ 4.862098] driver_attach+0x1e/0x30 [ 4.862099] bus_add_driver+0x187/0x230 [ 4.862100] driver_register+0x8f/0x100 [ 4.862102] __pci_register_driver+0x62/0x70 [ 4.862104] i915_pci_register_driver+0x23/0x30 [i915] [ 4.862164] i915_init+0x3e/0xf2 [i915] [ 4.862223] ? 0xffffffffc32a1000 [ 4.862225] do_one_initcall+0x5e/0x240 [ 4.862228] do_init_module+0x50/0x210 [ 4.862231] load_module+0xb7d/0xcd0 [ 4.862233] __do_sys_finit_module+0xc4/0x140 [ 4.862234] ? __do_sys_finit_module+0xc4/0x140 [ 4.862236] __x64_sys_finit_module+0x18/0x30 [ 4.862237] do_syscall_64+0x5b/0x90 [ 4.862239] ? __x64_sys_mmap+0x33/0x70 [ 4.862240] ? do_syscall_64+0x67/0x90 [ 4.862241] ? ext4_llseek+0x60/0x120 [ 4.862244] ? ksys_lseek+0x92/0xe0 [ 4.862246] ? exit_to_user_mode_prepare+0x30/0xb0 [ 4.862248] ? syscall_exit_to_user_mode+0x26/0x50 [ 4.862250] ? __x64_sys_lseek+0x18/0x30 [ 4.862251] ? do_syscall_64+0x67/0x90 [ 4.862252] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4.862255] RIP: 0033:0x7f8128916c4d [ 4.862256] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 83 f1 0d 00 f7 d8 64 89 01 48 [ 4.862257] RSP: 002b:00007ffe4526c108 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.862259] RAX: ffffffffffffffda RBX: 00005555fc6f17b0 RCX: 00007f8128916c4d [ 4.862260] RDX: 0000000000000000 RSI: 00007f8128ac8458 RDI: 0000000000000019 [ 4.862261] RBP: 00007f8128ac8458 R08: 0000000000000000 R09: 00007ffe4526c230 [ 4.862262] R10: 0000000000000019 R11: 0000000000000246 R12: 0000000000020000 [ 4.862262] R13: 00005555fc60a580 R14: 0000000000000000 R15: 00005555fc6f4020 [ 4.862264] [ 4.862264] =E2=80=94[ end trace 0000000000000000 ]=E2=80=94 [ 4.862269] snd_hda_intel 0000:00:08.1: failed to bind 0000:00:07.0 (ops i915_audio_component_bind_ops [i915]): -17 [ 4.862344] snd_hda_intel 0000:00:08.1: adev bind failed: -17 [ 4.862345] i915 0000:00:07.0: [drm] *ERROR* failed to add audio component (-17) --=20 Mario. --00000000000004f5c605efe7aa56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello to everyone.

I get= the following error message when I try to passthru my intel graphic card (= 00:02.0 Display controller: Intel Corporation CoffeeLake-S GT2 [UHD Graphic= s 630] (rev 02)) to a Linux VM :

= bhyve: Warning: Unable to reuse host address of Graphics Stolen Memory. GPU= passthrough might not work properly.
bhyve: gvt_d_setup_opregion: Unable to get OpReg= ion base and length
bhyve: gvt_d_init: Unable to setup OpRegion
device emulation initialization error: Operation not supported by devic= e

Can someone explain to me h= ow to fix it ? I'm running FreeBSD 13.1.

A= ctually on my PC there are 3 graphics cards :

a) <= span style=3D"font-family:monospace">CoffeeLake-S GT2 [UHD Graphics 630]

b) two nvidia graphic cards :

1) GTX 1060
2) RTX 2080 ti
=
on the BIOS I'm using the GTX 1060 as default graphic ca= rd and I've disabled the CSM mode.

on Free= BSD I have attached two monitors on the GTX 1060 in twin mode,using this xo= rg.conf file :


Instead,these are the config file used on = FreeBSD :

1) /boot/loader.conf

pptdevs=3D"0/2/0 2/0/0 2/0/1 2/0/2 2/0/3"

2) Linux bhyve vm :

bhyve -S= -c sockets=3D1,cores=3D2,threads=3D2 -m 4G -w -H -A \
-s 0,hostbridge \=
-s 2,virtio-blk,/mnt/$vmdisk1'p2'/bhyve/img/Linux/ubuntu2210.im= g,bootindex=3D1 \
-s 3,virtio-blk,/dev/$vmdisk4 \
-s 4,virtio-blk,/de= v/$vmdisk2 \
-s 5,fbuf,tcp=3D0.0.0.0:5919,w=3D1600,h=3D950,wait \
-s 7:0= ,passthru,0/2/0 \
-s 10,virtio-net,tap19 \
-s 11,virtio-9p,sharename= =3D/ \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share= /uefi-firmware/BHYVE_UEFI_CODE.fd \
vm0:19 < /dev/null & sleep 2 = && vncviewer 0:19

where :

0/2/0 :
=C2=A0
00:02.0 Display con= troller: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] (rev 02)

1/0/0 :

= 01:00.0 = VGA compatible controller: NVIDIA Corporation GP106 [GeForce GTX 1060 3GB] = (rev a1)
<= span style=3D"font-family:arial black,sans-serif">
<= div>01:00.1 Audio device: NVIDIA Corporation GP106 High Defin= ition Audio Controller (rev a1)
=
2/0/0 :
=
2:00.0 VGA compatible controller: NVIDIA Corporation TU10= 2 [GeForce RTX 2080 Ti] (rev a1)=C2=A0

=
02:00.1 Audio device: NVIDIA Corporation T= U102 High Definition Audio Controller (rev a1)=C2=A0

02:00.2 USB controller: NVIDIA Corp= oration TU102 USB 3.1 Host Controller (rev a1)=C2=A0

02:00.3 Serial bus controller: NVID= IA Corporation TU102 USB Type-C UCSI Controller (rev a1)

This log can be of interest. It=20 explains more in detail the reasons why my Intel IGPU is assigned to a Linu= x guest=20 OS,but it does not work (the screen remains black).

LOG FILE :

[ 2.970719] i915 0000:00:07.0: [drm] VT-d active for gfx access
[ 2.970874] Console: switching to colour dummy device 80x25
[ 2.970945] i915 0000:00:07.0: [drm] Transparent Hugepage mode =E2=80=98hug= e=3Dwithin_size=E2=80=99
[ 2.971316] i915 0000:00:07.0: BAR 6: can=E2=80=99t assign [??? 0x00000000 = flags 0x20000000] (bogus alignment)
[ 2.971319] i915 0000:00:07.0: [drm] Failed to find VBIOS tables (VBT)
[ 3.060611] i915 0000:00:07.0: [drm] Finished loading DMC firmware i915/kbl= _dmc_ver1_04.bin (v1.4)
[ 3.060868] [drm] [nvidia-drm] [GPU ID 0x00000008] Loading driver
[ 3.060819] snd_hda_intel 0000:00:08.1: bound 0000:00:07.0 (ops i915_hdcp_c= omponent_ops [i915])
[ 3.060948] ------------[ cut here ]------------
[ 3.060949] WARNING: CPU: 3 PID: 307 at sound/hda/hdac_component.c:196 hdac= _component_master_bind+0x9a/0x110 [snd_hda_core]
[ 3.060957] Modules linked in: nls_iso8859_1 nvidia_drm(PO+)=20 nvidia_modeset(PO) chromeos_pstore(-) i915(+) nvidia(PO) drm_buddy ttm
snd_hda_codec_hdmi snd_hda_intel intel_rapl_msr intel_rapl_common=20 snd_intel_dspcfg drm_display_helper snd_intel_sdw_acpi snd_hda_codec
cec snd_usb_audio snd_hda_core crct10dif_pclmul snd_usbmidi_lib rc_core=20 ghash_clmulni_intel snd_hwdep aesni_intel crypto_simd cryptd dr
m_kms_helper snd_seq_midi rapl joydev input_leds snd_pcm=20 snd_seq_midi_event fb_sys_fops nvidiafb syscopyarea vgastate ucsi_ccg(+) 9pnet
_virtio sysfillrect fb_ddc typec_ucsi sysimgblt typec video mac_hid=20 9pnet i2c_algo_bit snd_rawmidi serio_raw snd_seq snd_seq_device snd
_timer snd hid_cmedia soundcore v4l2loopback(O) videodev mc msr=20 parport_pc ppdev lp ramoops pstore_blk binfmt_misc drm parport reed_sol
omon pstore_zone efi_pstore qemu_fw_cfg ip_tables x_tables autofs4=20 hid_generic usbhid hid virtio_net net_failover failover i2c_nvidia_g
pu crc32_pclmul xhci_pci psmouse xhci_pci_renesas
[ 3.060990] i2c_ccgx_ucsi virtio_blk
[ 3.060992] CPU: 3 PID: 307 Comm: systemd-udevd Tainted: P O 5.19.0-26-gene= ric #27-Ubuntu
[ 3.060993] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 13.0 11/10/2020
[ 3.060994] RIP: 0010:hdac_component_master_bind+0x9a/0x110 [snd_hda_core]<= br> [ 3.061026] Code: ef e8 0a 37 44 d5 85 c0 78 79 48 8d 7b 18 e8 cd 24 38=20 d4 31 c0 48 83 c4 08 5b 41 5d 5d 31 d2 31 c9 31 f6 31 ff c3
cc cc cc cc <0f> 0b b8 ea ff ff ff 48 89 de 4c 89 ef 89 45 ec e8 91 4= a bb d4 48
[ 3.061035] RSP: 0018:ffffaaed8034f818 EFLAGS: 00010246
[ 3.061049] RAX: 0000000000000000 RBX: ffff97bf51d3fa48 RCX: 00000000000000= 00
[ 3.061070] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000000= 00
[ 3.061071] RBP: ffffaaed8034f830 R08: 0000000000000000 R09: 00000000000000= 00
[ 3.061072] R10: 0000000000000000 R11: 0000000000000000 R12: ffff97bf4b6497= 00
[ 3.061072] R13: ffff97bf40c540d0 R14: 0000000000000002 R15: ffff97bf4fdfa2= f8
[ 3.061073] FS: 00007f8128a058c0(0000) GS:ffff97bf7bd80000(0000) knlGS:0000= 000000000000
[ 3.061074] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.061075] CR2: 00005555fc5f4a40 CR3: 00000001022f2002 CR4: 00000000003706= e0
[ 3.061076] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000= 00
[ 3.061077] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000004= 00
[ 3.061078] Call Trace:
[ 3.061079]
[ 3.061081] try_to_bring_up_aggregate_device+0x87/0x120
[ 3.061084] __component_add+0xba/0x1a0
[ 3.061086] component_add_typed+0x12/0x30
[ 3.061088] intel_hdcp_component_init+0x75/0x110 [i915]
[ 3.061201] intel_modeset_init_nogem+0x17f/0x340 [i915]
[ 3.061275] i915_driver_probe+0x1d4/0x490 [i915]
[ 3.061332] ? drm_privacy_screen_get+0x16d/0x190 [drm]
[ 3.061357] ? acpi_dev_found+0x64/0x80
[ 3.061360] i915_pci_probe+0x56/0x150 [i915]
[ 3.061415] local_pci_probe+0x47/0x90
[ 3.061418] pci_call_probe+0x55/0x190
[ 3.061419] pci_device_probe+0x84/0x120
[ 3.061423] really_probe+0x1df/0x3b0
[ 3.061424] __driver_probe_device+0x12c/0x1b0
[ 3.061426] driver_probe_device+0x24/0xd0
[ 3.061427] __driver_attach+0xe0/0x210
[ 3.061429] ? __device_attach_driver+0x130/0x130
[ 3.061430] bus_for_each_dev+0x90/0xe0
[ 3.061434] driver_attach+0x1e/0x30
[ 3.061435] bus_add_driver+0x187/0x230
[ 3.061436] driver_register+0x8f/0x100
[ 3.061438] __pci_register_driver+0x62/0x70
[ 3.061440] i915_pci_register_driver+0x23/0x30 [i915]
[ 3.061501] i915_init+0x3e/0xf2 [i915]
[ 3.061562] ? 0xffffffffc32a1000
[ 3.061564] do_one_initcall+0x5e/0x240
[ 3.061566] do_init_module+0x50/0x210
[ 3.061569] load_module+0xb7d/0xcd0
[ 3.061571] __do_sys_finit_module+0xc4/0x140
[ 3.061572] ? __do_sys_finit_module+0xc4/0x140
[ 3.061574] __x64_sys_finit_module+0x18/0x30
[ 3.061575] do_syscall_64+0x5b/0x90
[ 3.061577] ? __x64_sys_mmap+0x33/0x70
[ 3.061578] ? do_syscall_64+0x67/0x90
[ 3.061579] ? ext4_llseek+0x60/0x120
[ 3.061581] ? ksys_lseek+0x92/0xe0
[ 3.061583] ? exit_to_user_mode_prepare+0x30/0xb0
[ 3.061585] ? syscall_exit_to_user_mode+0x26/0x50
[ 3.061587] ? _x64_sys_lseek+0x18/0x30
[ 3.061588] ? do_syscall_64+0x67/0x90
[ 3.061589] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 3.061591] RIP: 0033:0x7f8128916c4d
[ 3.061593] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48=20 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c
24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 83 f1 0d 00 f7 d8 6= 4 89 01 48
[ 3.061594] RSP: 002b:00007ffe4526c108 EFLAGS: 00000246 ORIG_RAX: 000000000= 0000139
[ 3.061596] RAX: ffffffffffffffda RBX: 00005555fc6f17b0 RCX: 00007f8128916c= 4d
[ 3.061596] RDX: 0000000000000000 RSI: 00007f8128ac8458 RDI: 00000000000000= 19
[ 3.061597] RBP: 00007f8128ac8458 R08: 0000000000000000 R09: 00007ffe4526c2= 30
[ 3.061598] R10: 0000000000000019 R11: 0000000000000246 R12: 00000000000200= 00
[ 3.061598] R13: 00005555fc60a580 R14: 0000000000000000 R15: 00005555fc6f40= 20
[ 3.061600]
[ 3.061600] =E2=80=94[ end trace 0000000000000000 ]=E2=80=94
[ 3.061608] snd_hda_intel 0000:00:08.1: adev bind failed: -22
[ 3.366340] nvidia-gpu 0000:00:08.3: i2c timeout error e0000000
[ 3.366345] ucsi_ccg 0-0008: i2c_transfer failed -110
[ 3.366347] ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
[ 3.366349] ucsi_ccg: probe of 0-0008 failed with error -110
[ 3.426012] tsc: Refined TSC clocksource calibration: 3597.416 MHz
[ 3.426024] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33daca= 713ae, max_idle_ns: 440795269098 ns
[ 3.459296] clocksource: Switched to clocksource tsc
[ 3.548873] loop0: detected capacity change from 0 to 8
[ 3.549210] Dev loop0: unable to read RDB block 8
[ 3.549215] loop0: unable to read partition table
[ 3.549218] loop0: partition table beyond EOD, truncated
[ 3.707526] i915 0000:00:07.0: [drm] failed to retrieve link info, disablin= g eDP
[ 3.707815] i915 0000:00:07.0: [drm] [ENCODER:94:DDI B/PHY B] is disabled/i= n DSI mode with an ungated DDI clock, gate it
[ 3.707821] i915 0000:00:07.0: [drm] [ENCODER:111:DDI C/PHY C] is disabled/= in DSI mode with an ungated DDI clock, gate it
[ 3.707824] i915 0000:00:07.0: [drm] [ENCODER:121:DDI D/PHY D] is disabled/= in DSI mode with an ungated DDI clock, gate it
[ 4.194609] process =E2=80=98/usr/bin/anydesk=E2=80=99 started with executa= ble stack
[ 4.401745] bridge: filtering via arp/ip/ip6tables is no longer=20 available by default. Update your scripts to load br_netfilter if yo
u need this.
[ 4.854484] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:00:08.0 on= minor 1
[ 4.856763] [drm] Initialized i915 1.6.0 20201103 for 0000:00:07.0 on minor= 0
[ 4.861400] ------------[ cut here ]------------
[ 4.861405] i915 0000:00:07.0: drm_WARN_ON(acomp->base.ops || acomp->= base.dev)
[ 4.861429] WARNING: CPU: 2 PID: 307 at=20 drivers/gpu/drm/i915/display/intel_audio.c:1261=20 i915_audio_component_bind+0x4b/0x130 [i915]
[ 4.861554] Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack=20 ipt_REJECT nf_reject_ipv4 xt_tcpudp nft_compat nft_chain_nat n
f_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c=20 nfnetlink bridge stp llc overlay nls_iso8859_1 nvidia_drm(PO) nvid
ia_modeset(PO) i915(+) nvidia(PO) drm_buddy ttm snd_hda_codec_hdmi=20 snd_hda_intel intel_rapl_msr intel_rapl_common snd_intel_dspcfg drm display_helper snd_intel_sdw_acpi snd_hda_codec cec snd_usb_audio=20 snd_hda_core crct10dif_pclmul snd_usbmidi_lib rc_core ghash_clmulni_i
ntel snd_hwdep aesni_intel crypto_simd cryptd drm_kms_helper=20 snd_seq_midi rapl joydev input_leds snd_pcm snd_seq_midi_event=20 fb_sys_fops
nvidiafb syscopyarea vgastate ucsi_ccg 9pnet_virtio sysfillrect fb_ddc=20 typec_ucsi sysimgblt typec video mac_hid 9pnet i2c_algo_bit snd
_rawmidi serio_raw snd_seq snd_seq_device snd_timer snd hid_cmedia=20 soundcore v4l2loopback(O) videodev mc msr parport_pc ppdev lp ramoop
s pstore_blk binfmt_misc drm parport reed_solomon
[ 4.861595] pstore_zone efi_pstore qemu_fw_cfg ip_tables x_tables=20 autofs4 hid_generic usbhid hid virtio_net net_failover failover i
2c_nvidia_gpu crc32_pclmul xhci_pci psmouse xhci_pci_renesas i2c_ccgx_ucsi = virtio_blk
[ 4.861605] CPU: 2 PID: 307 Comm: systemd-udevd Tainted: P W O 5.19.0-26-ge= neric #27-Ubuntu
[ 4.861607] Hardware name: FreeBSD BHYVE/BHYVE, BIOS 13.0 11/10/2020
[ 4.861607] RIP: 0010:i915_audio_component_bind+0x4b/0x130 [i915]
[ 4.861682] Code: 8b 5f 50 48 85 db 0f 84 e8 00 00 00 e8 5e bf 10 d2 48=20 c7 c1 f8 94 1c c3 48 89 da 48 c7 c7 7a 19 1b c3 48 89 c6 e8
8a 89 5e d2 <0f> 0b b8 ef ff ff ff 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f= 6 31 ff c3
[ 4.861683] RSP: 0018:ffffaaed8034f7b0 EFLAGS: 00010246
[ 4.861685] RAX: 0000000000000000 RBX: ffff97bf40a91990 RCX: 00000000000000= 00
[ 4.861686] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000000= 00
[ 4.861686] RBP: ffffaaed8034f7c8 R08: 0000000000000000 R09: 00000000000000= 00
[ 4.861687] R10: 0000000000000000 R11: 0000000000000000 R12: ffff97bf40c460= d0
[ 4.861688] R13: ffff97bf4fdf8000 R14: ffff97bf51d3fa48 R15: ffff97bf4ba5f3= 40
[ 4.861689] FS: 00007f8128a058c0(0000) GS:ffff97bf7bd00000(0000) knlGS:0000= 000000000000
[ 4.861690] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4.861694] CR2: 00005555fc6f6228 CR3: 00000001022f2004 CR4: 00000000003706= e0
[ 4.861695] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000= 00
[ 4.861695] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000004= 00
[ 4.861696] Call Trace:
[ 4.861697]
[ 4.861700] component_bind+0x63/0x120
[ 4.861705] component_bind_all+0xae/0x140
[ 4.861707] hdac_component_master_bind+0x3a/0x110 [snd_hda_core]
[ 4.861715] try_to_bring_up_aggregate_device+0x87/0x120
[ 4.861716] __component_add+0xba/0x1a0
[ 4.861718] component_add_typed+0x12/0x30
[ 4.861719] intel_audio_init+0x43/0xf0 [i915]
[ 4.861795] intel_display_driver_register+0x39/0x60 [i915]
[ 4.861867] i915_driver_probe+0x25b/0x490 [i915]
[ 4.861921] ? drm_privacy_screen_get+0x16d/0x190 [drm]
[ 4.861954] ? acpi_dev_found+0x64/0x80
[ 4.861958] i915_pci_probe+0x56/0x150 [i915]
[ 4.862081] local_pci_probe+0x47/0x90
[ 4.862085] pci_call_probe+0x55/0x190
[ 4.862087] pci_device_probe+0x84/0x120
[ 4.862088] really_probe+0x1df/0x3b0
[ 4.862091] __driver_probe_device+0x12c/0x1b0
[ 4.862092] driver_probe_device+0x24/0xd0
[ 4.862093] __driver_attach+0xe0/0x210
[ 4.862095] ? __device_attach_driver+0x130/0x130
[ 4.862096] bus_for_each_dev+0x90/0xe0
[ 4.862098] driver_attach+0x1e/0x30
[ 4.862099] bus_add_driver+0x187/0x230
[ 4.862100] driver_register+0x8f/0x100
[ 4.862102] __pci_register_driver+0x62/0x70
[ 4.862104] i915_pci_register_driver+0x23/0x30 [i915]
[ 4.862164] i915_init+0x3e/0xf2 [i915]
[ 4.862223] ? 0xffffffffc32a1000
[ 4.862225] do_one_initcall+0x5e/0x240
[ 4.862228] do_init_module+0x50/0x210
[ 4.862231] load_module+0xb7d/0xcd0
[ 4.862233] __do_sys_finit_module+0xc4/0x140
[ 4.862234] ? __do_sys_finit_module+0xc4/0x140
[ 4.862236] __x64_sys_finit_module+0x18/0x30
[ 4.862237] do_syscall_64+0x5b/0x90
[ 4.862239] ? __x64_sys_mmap+0x33/0x70
[ 4.862240] ? do_syscall_64+0x67/0x90
[ 4.862241] ? ext4_llseek+0x60/0x120
[ 4.862244] ? ksys_lseek+0x92/0xe0
[ 4.862246] ? exit_to_user_mode_prepare+0x30/0xb0
[ 4.862248] ? syscall_exit_to_user_mode+0x26/0x50
[ 4.862250] ? __x64_sys_lseek+0x18/0x30
[ 4.862251] ? do_syscall_64+0x67/0x90
[ 4.862252] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 4.862255] RIP: 0033:0x7f8128916c4d
[ 4.862256] Code: 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48=20 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c
24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 83 f1 0d 00 f7 d8 6= 4 89 01 48
[ 4.862257] RSP: 002b:00007ffe4526c108 EFLAGS: 00000246 ORIG_RAX: 000000000= 0000139
[ 4.862259] RAX: ffffffffffffffda RBX: 00005555fc6f17b0 RCX: 00007f8128916c= 4d
[ 4.862260] RDX: 0000000000000000 RSI: 00007f8128ac8458 RDI: 00000000000000= 19
[ 4.862261] RBP: 00007f8128ac8458 R08: 0000000000000000 R09: 00007ffe4526c2= 30
[ 4.862262] R10: 0000000000000019 R11: 0000000000000246 R12: 00000000000200= 00
[ 4.862262] R13: 00005555fc60a580 R14: 0000000000000000 R15: 00005555fc6f40= 20
[ 4.862264]
[ 4.862264] =E2=80=94[ end trace 0000000000000000 ]=E2=80=94
[ 4.862269] snd_hda_intel 0000:00:08.1: failed to bind 0000:00:07.0 (ops i9= 15_audio_component_bind_ops [i915]): -17
[ 4.862344] snd_hda_intel 0000:00:08.1: adev bind failed: -17
[ 4.862345] i915 0000:00:07.0: [drm] ERROR failed to add audio com= ponent (-17)

--
Mario.
--00000000000004f5c605efe7aa56-- From nobody Fri Dec 16 22:26:45 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NYkHd5jSqzZpXv; Fri, 16 Dec 2022 22:27:25 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NYkHc2Yxbz4862; Fri, 16 Dec 2022 22:27:24 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=PFnWf8u7; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-x533.google.com with SMTP id i9so5570124edj.4; Fri, 16 Dec 2022 14:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=p3Swbp/nSYfH+f4q07r9ouLZ9SxpuUQvLxkCb7wGRaw=; b=PFnWf8u74D4FOBMAwnpj1rDV3sRV7K1tMrnguVqQL0wLvC9qIwbFRMrOB+AmlkO2+Y thFiUPZ+ZVt9Y8A1zg6CmlRmIrnHGRYLY2LG/HdDYjye7rXVGZSgltJgMhSZQ+AaDpXI dXwuYPdYLpUzMDeIMQxccAkBkJkwbQl1HZ4/jFl2A/17rYI9S1FtpWtnHGVkgMjeL+wS JdMxMDERTsAQm4QGx5/Y+zDbUK9RAlBGfdG90XzfNPAekSbKTmki/SHluPE8OboMuP77 Ldzkbsv+wdjixCP6Tvt779Mavr/6vyDvBcb5j0+b8/kiI9NBp0kFc2vxrja7YGQVdZxq zJRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=p3Swbp/nSYfH+f4q07r9ouLZ9SxpuUQvLxkCb7wGRaw=; b=lkgW+op6pQmqecQ6gMqJ2yXd7GI5Rxgv82EognxFSldVbTnrbLNoziZfhIy2S7nh+G 6cNNVvr5taesyHM0vyfCUrE3QIe+CabGi0UZX8N0CwKkTp3C7XbzzVKU0oxZqcOMuH6/ q61/qMKIjPR1BmrZiD64wo1Nzd5VA6r1ij7yOmcx3OawCd0xzKSh9uIOS3R6utPxb434 SCnC3gztOgradYUqYrkL37ze7L4zmK87M3EbL6h8WdRdZNLsV0iWVTecmCH3em93HrCL dWITaRwx1QzizIrIj2PzTYFLTM90xo80NbSCX6mqdYobn6i6wqWrOkWl1YN/GRnClBTX w0fw== X-Gm-Message-State: ANoB5pkrg7D/n4/qt4RB6DYWZaaUjLqigEfiq5IjocZ2PD8Z45pF0WYU jtETDTiSvenc7xvm04KXqG+R+j3pSivCfFC+0ywwCzJHWJvCMA== X-Google-Smtp-Source: AA0mqf5XS0T/C0f2vLMhPgzpv92OQ9Pv3MRZtVnGL88DabfLHqe/vQo0IrfJih7cWxdWtLJ+EKWBBVPFFfwLgDbDduU= X-Received: by 2002:a05:6402:5483:b0:468:d5a9:cb4b with SMTP id fg3-20020a056402548300b00468d5a9cb4bmr72361027edb.409.1671229642166; Fri, 16 Dec 2022 14:27:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Fri, 16 Dec 2022 23:26:45 +0100 Message-ID: Subject: How to use a gop or vbios rom for my Intel gpu card model Intel UHD 630 To: FreeBSD virtualization , hackers@freebsd.org, virtualization@freebsd.org, =?UTF-8?Q?Corvin_K=C3=B6hne?= , Peter Grehan , Graham Perrin Content-Type: multipart/alternative; boundary="00000000000028d84c05eff97985" X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.961]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[freebsd-virtualization@freebsd.org,hackers@freebsd.org,virtualization@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::533:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4NYkHc2Yxbz4862 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --00000000000028d84c05eff97985 Content-Type: text/plain; charset="UTF-8" Hello FreeBSD Virtualization team, I'm trying to boot my intel gpu model UHD 630 adding a GOP driver or a VBIOS rom directly between the bhyve parameters like this : -s 7:0,passthru,0/2/0,rom=UHD-Graphics-630-vbios.rom because I've read that it can be done,according with your documentation : https://reviews.freebsd.org/D26209?id=76277 Anyway,I'm not able to find the proper rom file. I went on the nvidia forum and I've been helped by an nvidia developer that explained to me how the generic situation for this user case is. He is not a bhyve developer,so the information that he gave to me isn't enough for me to understand what I should do. You can read our discussion here : https://forums.developer.nvidia.com/t/im-failing-trying-to-configure-the-framebuffer-as-default-graphic-adapter-and-the-nvidia-geforce-rtx-2080-ti-as-prime-render-offload/236365/23 We haven't reached a conclusion yet,so I would like to have some clarifications from you. He says that there is no gop/vbios ROM that I can use,but If I don't use it my gpu won't work as you can see reading the thread above. Please help me. Thanks. Regards. -- Mario. --00000000000028d84c05eff97985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello FreeBSD Virtualization team,

I'm trying to boot my intel gpu model UHD 630 adding a GOP drive= r or a VBIOS rom directly between the bhyve parameters like this :

-s 7:0,passthru,0/2/0,rom=3DUHD-Graphics-630-vbios.ro= m

because I've read that it can be done,according = with your documentation :


Anyway,I'm not able to find the prope= r rom file. I went on the nvidia forum and I've been helped by an nvidi= a developer that explained to me how the generic situation for this user ca= se is. He is not a bhyve developer,so the information that he gave to me is= n't enough for me to understand what I should do. You can read our disc= ussion here :


We haven= 't reached a conclusion yet,so I would like to have some clarifications= from you. He says that there is no gop/vbios ROM that I can use,but If I d= on't use it my gpu won't work as you can see reading the thread abo= ve. Please help me. Thanks. Regards.

--
Mar= io.
--00000000000028d84c05eff97985-- From nobody Sat Dec 17 11:49:39 2022 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NZ45L2Z5fz1CTXB; Sat, 17 Dec 2022 11:49:42 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NZ45L1Cwqz4XyF; Sat, 17 Dec 2022 11:49:42 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671277782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wwjNDbZBw7RbgV6FQ41r9mGS7cPWczte2qxvuHKoHKo=; b=VtJMq1b9FBZSCjsq8xBCDwcDkw43o9O8nDIt5jUhGdNMlI6Tb1PBmHKS+oKqAQU7h2SmaY mZ44Myby1tdI1PWB5g5sbqGCL21oVL65RwwIMJw1vXKzACrqvNm4aDUlVibhr3cBdiQyMk Ovtc+V40YEc1xtKpXzcCtP+E2V+u1Gq9e9A1H1NxUO0OWBG9nHKIvUk6bU0y7qDrAPpZ5B rrk6yFdn2NHgBXX10vJOraVWR5GUBrdb/G38t9MER2gMZX6dGeb4QS7w4IfuB0m5hBaTK4 tJjgU+cqpKNOgSNBP/Ha5VCIbkjwOBivJyxmOOiHdkxMva0nwTY07GZPtz7rRg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671277782; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wwjNDbZBw7RbgV6FQ41r9mGS7cPWczte2qxvuHKoHKo=; b=MboqsJnYuiM/GYq4f+JcMAEg+zUJdNKeS2E9bFKGBeqRLrXokkGQ3jy5WK2Ym7D1F9M64f gN53Hmzwmh8mH9VZuVLYdUw5+RhdqqvHM6WO0XcPtaG0mb+SD6t/LSA35k6z/HdNRpfESG ZGlVFIyEAdIAtFjkIFpbFLwHWbQofHbf7YaYX26daOdaQmuVnRokekvu81ccR+XdFgwrb6 w1Clhu6oxHX1sVsK5HUl+F8DjZOkqinR1nH8VXJApYOSDVVfkdqoBxyPfC7PVqFVqXU37X GGgoXvlMd0egwn2qkY58exRtONrhgXSITSmuRgWHgNixr358G0QOB0/giXVYmA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671277782; a=rsa-sha256; cv=none; b=AdAOxUqSxUR0jEFJwJxY2AizbwK4pB2PoVejHJ3g1bs73f3DO21rjI5aL6J4YPGpubeLF1 B+7rXU99u+oO2XwwJgeXHPN9U2FeUHftxlutVJNindeH5fGeaHYknkSFjVwgv0RKlL0HQs EAgbnFAmvwQ/dT+fCeNQt/AQ0psAPxVPv19cHDtem9DMBAe1Pk7rPDBVWFGAcXm8AlxjVs iVqCf2SENB15/STsD6pgZrLZLfMHSlYN/djTsTSIzawFr4priaQCRK4knt8a3CEdT5WwH+ k/3aTPaH3DZIOKbjoiw17cf9AI0Q6JCec1Nt258LzW1amVvKkAWkarC4RKvYEQ== Received: from [IPV6:2001:470:1f1c:a0::2] (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0::2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: grahamperrin) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NZ45K2rpCz12Wg; Sat, 17 Dec 2022 11:49:41 +0000 (UTC) (envelope-from grahamperrin@freebsd.org) Message-ID: <5f1a29ab-de9f-4441-4fcc-e8ec8e780b28@freebsd.org> Date: Sat, 17 Dec 2022 11:49:39 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: How to use a gop or vbios rom for my Intel gpu card model Intel UHD 630 Content-Language: en-GB To: Mario Marietto , FreeBSD virtualization , hackers@freebsd.org, =?UTF-8?Q?Corvin_K=c3=b6hne?= , Peter Grehan References: From: Graham Perrin Organization: FreeBSD In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------xrZ0lAxSFdkBl5t548sqty6w" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------xrZ0lAxSFdkBl5t548sqty6w Content-Type: multipart/mixed; boundary="------------ELb6YDRnonsyJZEL5PAm10d0"; protected-headers="v1" From: Graham Perrin To: Mario Marietto , FreeBSD virtualization , hackers@freebsd.org, =?UTF-8?Q?Corvin_K=c3=b6hne?= , Peter Grehan Message-ID: <5f1a29ab-de9f-4441-4fcc-e8ec8e780b28@freebsd.org> Subject: Re: How to use a gop or vbios rom for my Intel gpu card model Intel UHD 630 References: In-Reply-To: --------------ELb6YDRnonsyJZEL5PAm10d0 Content-Type: multipart/alternative; boundary="------------sysMWaSEZBAQ8l9r6GE8Qqud" --------------sysMWaSEZBAQ8l9r6GE8Qqud Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VG8gYXZvaWQgbXVsdGlwbGljYXRpb24sIHBsZWFzZSBkcm9wIG1lIGZyb20gdGhlIGxpc3Qg b2YgcmVjaXBpZW50cy4gDQpUaGFuayB5b3UuDQo= --------------sysMWaSEZBAQ8l9r6GE8Qqud Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To avoid multiplication, please drop me from the list of recipients. Thank you.
--------------sysMWaSEZBAQ8l9r6GE8Qqud-- --------------ELb6YDRnonsyJZEL5PAm10d0-- --------------xrZ0lAxSFdkBl5t548sqty6w Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEWT/lssMHB+28ly8Kt2dIb0oY1AsFAmOdrNMFAwAAAAAACgkQt2dIb0oY1Atq zA/9Gj1d9DDANBD19g6YcybjlGC8ZjhGJbt19Cvt212DbmV/5WX+wmSwBgMhRX+HfRGdVgrxMAzB GpAa/wrYitfyTvS4AWftZD0vTiKUfklQ5B/sQxmt8CNId0/Ug2G0k8ciUwqjR1bDgW1Qz9fB4kLT vueKs2+braTVAt6UVLihlNbdrocQyXDYEgyoeqnRMe3uun1i4Na4S9qHxjUsvrCmZGd2jP/EOlgv TT8o14MhhzbxLg4I5yXKKMA9z3OdbpZEdglSQQ9jx26kSTZCoexoKFbTZmnLijzWai518mvGqIA/ Me0y2rlFJAOqHwv4v1+GpBZIYfprzgDaNL9oEjSmiM6GZcImgeaiQVS06SK1y37RGZLh/d77I5Sz XugeQc+t2aXsrRBne5Mpi94AQsr1q60OTA4C50PftbqOVuUKa8ZcLNugu7qTPjn8fqWW7EMmh8ZO uaI7mpG+ovps606Unp5Lb+EanZ7if2/P5KcYO/Jcnlr2NM5AokDdXaBEyFQLKZFcxdL8NUtY2rIZ UXglWmBb/i+BTiBKlaD9eBBvt13wWeBb43B+ue0z8vSl+P+xyfIevaKoMg7yQTmx91urzUoCU8Zi LTEeIg2d3rVee52271LvFGnREV1bLaY4tW0rHoNGb2/Ui0t5ypLlB4GXzp52P/FVOn4guSYStvy8 i80= =jNV7 -----END PGP SIGNATURE----- --------------xrZ0lAxSFdkBl5t548sqty6w-- From nobody Sun Dec 18 19:13:47 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NZsvT5hCCzsxCD for ; Sun, 18 Dec 2022 19:13:57 +0000 (UTC) (envelope-from jo@bruelltuete.com) Received: from email.jo-t.de (seppel.jo-t.de [45.132.244.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NZsvS3zVfz3JX7 for ; Sun, 18 Dec 2022 19:13:56 +0000 (UTC) (envelope-from jo@bruelltuete.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bruelltuete.com header.s=bruelltuete18a header.b=Qyt6ouoc; spf=pass (mx1.freebsd.org: domain of jo@bruelltuete.com designates 45.132.244.126 as permitted sender) smtp.mailfrom=jo@bruelltuete.com; dmarc=pass (policy=none) header.from=bruelltuete.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bruelltuete.com; s=bruelltuete18a; t=1671390829; bh=WHsx/iOyQuStbJQ37ksnA3B27MbThTK679cOQQEGVqI=; h=Message-ID:Date:MIME-Version:To:From:Subject:From; b=Qyt6ouocVuHCM4SC8PF1fMfJFbkr3+o0T5FZCViw8ZV2xINmoFXoC6W0WdmuHt/rT z2KzbZzSj//BBfP/tn/29pTddv1jNPXkcKm4ASPbaGyMYYbmtT8xLhIjj2hybqh3u2 vtJ24Cvw5CyTGHC+yEQ6EDrTDXEFSMAEX7lMFRbwZ8+zRKkI0ovDKVXy60yzzi2A29 Bvta92jrzeMRyLLoJe1Z1b+jSRViLTQmHn74qPvQTWv3iXveapHj13BU2q2QlGaglG /9FqrjiqSrjflDL+nvO/H95iDMJynKFDCm7I6RNlEETuZeT4NnBvEeKcMDtvoZWVcl sNH/JWXrooOtQ== Message-ID: <4af04584-b1f5-e546-01bd-5bf16fb9a085@bruelltuete.com> Date: Sun, 18 Dec 2022 19:13:47 +0000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Language: en-GB To: freebsd-hackers@FreeBSD.org From: Johannes Totz Subject: EFI wake time Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[bruelltuete.com,none]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[bruelltuete.com:s=bruelltuete18a]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:197540, ipnet:45.132.244.0/22, country:DE]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bruelltuete.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NZsvS3zVfz3JX7 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi folks, anyone here with EFI experience? And/or ACPI knowledge? I've got a patch to add EFI's wake time API: https://reviews.freebsd.org/D36714 Problem is that it does not wake up the machine... Any idea what else needs to happen for wake-up? thanks, Johannes From nobody Fri Dec 23 01:24:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NdTx10ckgz1HHM0 for ; Fri, 23 Dec 2022 01:24:21 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NdTwz6kd2z4Cvh for ; Fri, 23 Dec 2022 01:24:19 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=JebNv0tY; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="t kBr5Z9"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.27 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BDCF45C00E8 for ; Thu, 22 Dec 2022 20:24:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 22 Dec 2022 20:24:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1671758658; x=1671845058; bh=xhiH17n5hhVI+CH2ruGtoIWNjMGKZ+zmLuh LrB+fKYI=; b=JebNv0tY78+3rhmXJPSfw7Qz06tpQTxee34lmGlNUClJrPtVyEM XgPS+ts205Zr/tiQPXc8hp6BYtqDD+050YcuZDLb/p7zLQw7/axJLDUkNxSDurqZ YMcD/1Ui5vZ++iN3tFEzXAtgtq7Mrfxgn3ahsVfXmdd62EDa7k4d4GrpYHSBeuyG CF5iGbDcksRAhHxkVpA2hHagKVAbCUR8xDkxjyen1fW2iBEosow2ZMf5/zhpcI7b lFMbKhsfQRJuLNVkA4398G6i471zCiSwsXnl4LA28TPRtCD5kw0G3+8Melrp21KF QpeqfsrLJDN2FsTghVCevmJ1J5XG4Y4L25g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1671758658; x= 1671845058; bh=xhiH17n5hhVI+CH2ruGtoIWNjMGKZ+zmLuhLrB+fKYI=; b=t kBr5Z9q+/ENeUDSjdeT84owq3u/cXLZUO4+cu+pYHkLnipfLLoH+0PQXx9y9/fdZ tEw8Dvd04shp3oIX7vh7O0flwjw39secQW9P+HCBN9TWmCO+QbLdtvVIW8NCjtOV +AnyjiBUXv2/nMMnXyr0rOp4VFC4GvLf6fD+kdhA/TQ9mOeOfllGTwUp4zioYFgF OHlNcsfNzyJAgXzpP9VM1PvOL6S33GfrYMWvp1yiMrHL0/G7XWXiXsOnBUgnVmrz iBf8dHycqVim6hJuZgzOBb8NlfSeCjFCW5fLrL9BFEAYeLVMKCdomoBzPZj582lc RJCarGjalVIrt7iCZuQCw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrhedugdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertddttd dvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrghtthgv rhhnpeeuteethfethfegveffjeehieefffehvdfhleeltdffgefhudefueeuvdfhheeghf enucffohhmrghinhepnhhtphdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 22 Dec 2022 20:24:18 -0500 (EST) Date: Fri, 23 Dec 2022 01:24:07 +0000 From: void To: freebsd-hackers@freebsd.org Subject: wpa_supplicant in base and in ports Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-5.06 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.97)[-0.972]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.27:from] X-Rspamd-Queue-Id: 4NdTwz6kd2z4Cvh X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N Hi hackers@ I know there's been a lot of work in -current (and maybe some of this has been MFC'd, not sure) regarding wlan stuff over the last year; this is why I'm asking about this here. As I'm having a few issues [1] with connecting reliably with wifi on stable/13-n253168-46c09d766d26 amd64, do I stand a better chance of solving them with either upgrading the os to -current or installing any of security/wpa_supplicant security/wpa_supplicant-devel security/wpa_supplicant29 instead of using the wpa_supplicant in base? [1] it's using ath0 for wlan0. It's set up as a wireless client with SYNCDHCP. /var/log/messages has this over and over: Dec 21 18:25:41 REDACTED ntpd[18024]: error resolving pool 2.uk.pool.ntp.org: Name does not resolve (8) Dec 21 18:26:10 REDACTED kernel: ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping Dec 21 18:26:48 REDACTED ntpd[18024]: error resolving pool 2.uk.pool.ntp.org: Name does not resolve (8) Dec 21 18:27:52 REDACTED syslogd: last message repeated 1 times Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: Successfully initialized wpa_supplicant Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: ioctl[SIOCS80211, op=20, val=0, arg_len=7]: Invalid argument Dec 21 18:28:57 REDACTED syslogd: last message repeated 1 times Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 until I restart wlan0 and wpa_supplicant 15 or so times, it eventually synchs: wlan0: flags=8843 metric 0 mtu 1500 ether xx;xx:xx:xx:xx:xx inet 192.168.1.71 netmask 0xffffff00 broadcast 192.168.1.255 groups: wlan ssid REDACTED_5G channel 108 (5540 MHz 11a ht/40+) bssid yy:yy:yy:yy:yy:yy regdomain ETSI country GB indoor ecm authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 23 bmiss 7 mcastrate 6 mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 4 shortgi -uapsd wme burst roaming MANUAL Once the connection is established, it's stable. But why won't it connect post-reboot? and would upgrading the os to current or installing the above-mentioned ports help? tia, -- From nobody Fri Dec 23 14:48:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NdqnL6xXzz1Lkvf for ; Fri, 23 Dec 2022 14:48:54 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NdqnK72y8z3psD for ; Fri, 23 Dec 2022 14:48:53 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id 8Sc8pFPxec9C48jLxpDk5r; Fri, 23 Dec 2022 14:48:53 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id 8jLvpFJGiyAOe8jLwpfKG1; Fri, 23 Dec 2022 14:48:53 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=63a5bfd5 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=sHyYjHe8cH0A:10 a=vxP3BzG0AAAA:8 a=85N1-lAfAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=08b6VZKX2Obth5-BGjEA:9 a=CjuIK1q_8ugA:10 a=4tHceQipB5Rc01mo_vQZ:22 a=cyfSibbquD4hpIoiQNSb:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 7FC0A6D3 for ; Fri, 23 Dec 2022 06:48:51 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 6CA981EA; Fri, 23 Dec 2022 06:48:51 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports In-reply-to: References: Comments: In-reply-to void message dated "Fri, 23 Dec 2022 01:24:07 +0000." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Dec 2022 06:48:51 -0800 Message-Id: <20221223144851.6CA981EA@slippy.cwsent.com> X-CMAE-Envelope: MS4xfLyMEiQoqc0mVxk019M24Ueq+B04ZxTDQPcKvUL1qves0RLOruZ0W89/WpDl2EBhbpmC2Z5rA0kk21co1i7CQ2Z3+mfzYjqY45tRaGyU6XY07avtO0Ta 2AIY37z+JF+x6rwPEizfSbQJb6SnOHa7mWNNKOaQGOgod6kBQJNTEH7UKMycJ95t+NIfzGFXQ7GXkI0SBab4SNxP2YNyNHkpiiE= X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_ONE(0.00)[1]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NdqnK72y8z3psD X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N In message , void writes: > Hi hackers@ > > I know there's been a lot of work in -current (and maybe some of this > has been MFC'd, not sure) regarding wlan stuff over the last year; this > is why I'm asking about this here. > > As I'm having a few issues [1] with connecting reliably with wifi on > stable/13-n253168-46c09d766d26 amd64, do I stand a better chance of > solving them with either upgrading the os to -current or installing any > of > > security/wpa_supplicant > security/wpa_supplicant-devel > security/wpa_supplicant29 > > instead of using the wpa_supplicant in base? > > [1] it's using ath0 for wlan0. It's set up as a wireless client > with SYNCDHCP. /var/log/messages has this over and over: > > Dec 21 18:25:41 REDACTED ntpd[18024]: error resolving pool > 2.uk.pool.ntp.org: Name does not resolve (8) > Dec 21 18:26:10 REDACTED kernel: ath0: ath_edma_recv_tasklet: > sc_inreset_cnt > 0; skipping > Dec 21 18:26:48 REDACTED ntpd[18024]: error resolving pool > 2.uk.pool.ntp.org: Name does not resolve (8) > Dec 21 18:27:52 REDACTED syslogd: last message repeated 1 times > Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: Successfully initialized > wpa_supplicant > Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: ioctl[SIOCS80211, op=20, > val=0, arg_len=7]: Invalid argument > Dec 21 18:28:57 REDACTED syslogd: last message repeated 1 times > Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: ioctl[SIOCS80211, > op=103, val=0, arg_len=128]: Operation now in progress > Dec 21 18:28:57 REDACTED wpa_supplicant[43489]: wlan0: > CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 > > until I restart wlan0 and wpa_supplicant 15 or so times, it eventually > synchs: > > wlan0: flags=8843 metric 0 mtu > 1500 > ether xx;xx:xx:xx:xx:xx > inet 192.168.1.71 netmask 0xffffff00 broadcast 192.168.1.255 > groups: wlan > ssid REDACTED_5G channel 108 (5540 MHz 11a ht/40+) bssid yy:yy:yy:yy:yy:yy > regdomain ETSI country GB indoor ecm authmode WPA2/802.11i privacy ON > deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 23 bmiss 7 > mcastrate 6 mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 4 > shortgi -uapsd wme burst roaming MANUAL > > Once the connection is established, it's stable. But why won't it > connect post-reboot? and would upgrading the os to current or installing > the above-mentioned ports help? What hardware device is your wlan0? That would be "parent interface". -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Fri Dec 23 18:35:45 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ndwq95Dskz1HM7t for ; Fri, 23 Dec 2022 18:35:49 +0000 (UTC) (envelope-from void@f-m.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ndwq85kPLz3DRq for ; Fri, 23 Dec 2022 18:35:48 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=FvVhwGU4; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=ID+942wb; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 66.111.4.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F27435C0114 for ; Fri, 23 Dec 2022 13:35:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 23 Dec 2022 13:35:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1671820547; x=1671906947; bh=kHDLLlcIRL vkhl1To6DkBsuBnNw9PaLj45tMafgGrYY=; b=FvVhwGU4Hr+AjZ6VvtCu1C8NQz 5udzw+wzyr0K0dy4Qhb9+2/caHNSk4iQyvvgD76h3M3uPai2P6J+Yp1aaIKrX23w lsjp4p04X6FWGngdveYnnGprqFMgzPNCyUhavGTZ+hZPuVmeGtw0GDkb2y3C/Xix uSAvvzy74vMpgZl9YQFdRBw4el8unIsVY0V0ozJwHymPfN6UIflh2p0oBpVm1HwK WMkN+np1282URWD0GnWnwh0AqCgD0Lrcy6cvoEBWo+FCItS2nDto0WoYYcPi54L8 BV+HMmX8d2D7P1GZZ4l+EBWoVbLBQ7bJrl86R+w4sk6+9qyU0hdbMc9w7/tg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1671820547; x=1671906947; bh=kHDLLlcIRLvkhl1To6DkBsuBnNw9 PaLj45tMafgGrYY=; b=ID+942wb+q08J8TOxoy27hqAfhFanEqEdxoGfyLCInuo ve4sjrr4HRemP2rIe7VKpT+mDMlAPzqkyfra+6rgQogS2wk2OpZyWQZekxs6ulbn Dabhhsl8XSLXAhA9eQqFgORkwN1crzCQyCl/oSgUEendIrw61h5mp5ZgmzUwMrDh W7IWQd8Bpz41ZbcQu85IWZfa836FwBaBJxEVwko/tF+lUN3jh4yF+VVsfpwumwk1 4wuzmZrRWMEKJx5hlUrGCANV3YrZg9hYrMmfdfCjH7WMgt/tnzhMhkqTKLniV+KD D95feKY9YNewPbkMF9Rp0ehF8nJyhNPt0jQP8K1EfA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrhedvgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnhepkeeluddvlefhieelfefggffhffektdehleelgfdugfdvgeekjeejuddthe ehgfeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep vhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Fri, 23 Dec 2022 13:35:47 -0500 (EST) Date: Fri, 23 Dec 2022 18:35:45 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <20221223144851.6CA981EA@slippy.cwsent.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221223144851.6CA981EA@slippy.cwsent.com> X-Spamd-Result: default: False [-4.43 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; NEURAL_HAM_SHORT(-0.23)[-0.233]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4Ndwq85kPLz3DRq X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 23, 2022 at 06:48:51AM -0800, Cy Schubert wrote: > >What hardware device is your wlan0? That would be "parent interface". I *think* the answer is ath0. In case it isn't, I've provided the following info dmesg ----- ath0: mem 0xef200000-0xef27ffff irq 17 at device 0.0 on pci3 ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] LDPC transmit/receive enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 /etc/rc.conf ------------ wlans_ath0="wlan0" ifconfig_wlan0="DHCP" create_args_wlan0="country GB regdomain ETSI" /etc/wpa_supplicant.conf ------------------------ network={ ssid="REDACTED_5G" psk="REDACTED_PASSWD" } thanks, -- From nobody Sat Dec 24 00:00:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nf41N2p50z1Lrjg; Sat, 24 Dec 2022 00:00:08 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nf41N227yz4LS5; Sat, 24 Dec 2022 00:00:08 +0000 (UTC) (envelope-from salvadore@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671840008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=; b=ydB/v2B4dYlGyBYwnjCYqNA4gIq3M+kW/pq3JidvPV8PRHQHWh1hs9EvqRyrHBdO+wcVuh qnjtR9cQ3tSwrnOxBRMa/DixScRM83XNPgFsQ2LefKDKRVve1TRkcIdyoS93Y5ydT9MatS 0wwbB6UjNI4zGQ7L27S4QhsEMj05H5bAoCF8vt6saQ//+7KZI3k9uNoXIpIe/eVFywk432 v9aP6oZqmnqeCjIdAbNwZD8iW/9UwlbIVwZnt0BbF4elORGT1J0+eZMFRq2SsojvdfQr1m PLnI/dqP7m6EvKOQ3xdhZIfNNmBFN6M6pcY1rzVjq7fDQ32My9e6bs14TGjYSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1671840008; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc; bh=NHCrH3emcgUifmhNrGK5KqcfJlPpV/HJ5UClcPRnW20=; b=p/cZS3Dz5vUnuOgpoLsP1f66dg2Sv5e6oAnyn6+k762Qzb0RudyHDdSxE6yStS51sd4vDl oCUYjXjaNpoWN49od+c+Tp+v53izku5hdY3VdprG9sILj3hEyBuj83IeReXR/3PmgtMi20 0yfMKYGwLwpUryblMKLa7DQa1PiKJ0Vk7NQmMCakeob6VhGSuSDL8XpPmXiKnBNSSAak9H nyMPFDJxLecsxxazNdaqQfY0tRBthC63L7clUFVTz8DNb2BYU4wqoBc8QdYWwkyDwaztic j886+pOW8il4l7sPfYSzHAmp5Sjnkf48aLNojIEJYKNAOsfnw4IK2xayFD74Eg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1671840008; a=rsa-sha256; cv=none; b=bVphBOJHbTINPp2HRSAeCwx48EC94tS9QNeZoYA+YsA0wMIvHS5PuB8uGF+RlukiL9CaT7 3IYOfP6rcrmbPBMUaxb8mjAfEsyyZtW7DFeniNprLv32qmDapeO7z9W+E4oM9ILqErqTH2 FMl3dPYSqXC48699vt1wP+WSfHdvBRJwFP47aCNx/3tAf6Whj13b0QOhd7pyAhO2VHq3Jg dZVq92/IDgw/YMgjbLf69llO0uZpr52m1kQS3OSlMbfWuhbHx3xLUfLUG1bT4fIK3yJXUo zdm8wVCZQgW4HmEsTtkWEZGt8C8oZPmnVrfwfWZVMQp8K3QnZr6iwqmR1HvN1w== Received: by freefall.freebsd.org (Postfix, from userid 1472) id 09877377A; Sat, 24 Dec 2022 00:00:07 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2022Q4 quarterly status reports Cc: freebsd-current@FreeBSD.org,freebsd-hackers@FreeBSD.org,devsummit@FreeBSD.org Message-Id: <20221224000008.09877377A@freefall.freebsd.org> Date: Sat, 24 Dec 2022 00:00:07 +0000 (UTC) From: Lorenzo Salvadore X-ThisMailContainsUnwantedMimeParts: N List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is December, 31st 2022 for work done since the last round of Quarterly Reports: October 2022 - December 2022. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the AsciiDoctor template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The new AsciiDoctor template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.adoc We look forward to seeing your 2022Q4 reports! Thanks, Lorenzo Salvadore (on behalf of quarterly@) From nobody Sat Dec 24 04:48:34 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NfBQF3PYxz1HdpN for ; Sat, 24 Dec 2022 04:48:37 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NfBQD5nlfz47dh for ; Sat, 24 Dec 2022 04:48:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com; dmarc=none Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id 8fHOpHmxOc9C48wSapG9IE; Sat, 24 Dec 2022 04:48:36 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id 8wSYpWRajcyvu8wSZp8mKM; Sat, 24 Dec 2022 04:48:36 +0000 X-Authority-Analysis: v=2.4 cv=VbHkgXl9 c=1 sm=1 tr=0 ts=63a684a4 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=sHyYjHe8cH0A:10 a=vxP3BzG0AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=ng2YZ-K4mf26duQrGJoA:9 a=CjuIK1q_8ugA:10 a=4tHceQipB5Rc01mo_vQZ:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A4CD81153 for ; Fri, 23 Dec 2022 20:48:34 -0800 (PST) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 91BA3178; Fri, 23 Dec 2022 20:48:34 -0800 (PST) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports In-reply-to: References: <20221223144851.6CA981EA@slippy.cwsent.com> Comments: In-reply-to void message dated "Fri, 23 Dec 2022 18:35:45 +0000." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Dec 2022 20:48:34 -0800 Message-Id: <20221224044834.91BA3178@slippy.cwsent.com> X-CMAE-Envelope: MS4xfN/IpEDMLZYOY0ka0P2a4pjfRBdXtmCVSB0Dh9Gbw9m3l8f/6vyRwtPGA6L5RGQyRZtpG5YTbvbSGBSmvjJLav/9/w0lv2ykxDuhbkP9L/So/y6zA8Hc UhbwzsWaebZuc1dG9jx36A+mBLrPmoa0cCH7AxqcAlGBt9gWDEEiCp/y0YDDa3bY7ljSrO//Dvk+RhpWgtFfDXx7/JRSLLbakvU= X-Spamd-Result: default: False [-1.77 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.97)[-0.967]; MV_CASE(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCPT_COUNT_ONE(0.00)[1]; REPLYTO_EQ_FROM(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NfBQD5nlfz47dh X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N In message , void writes: > On Fri, Dec 23, 2022 at 06:48:51AM -0800, Cy Schubert wrote: > > > >What hardware device is your wlan0? That would be "parent interface". > > I *think* the answer is ath0. In case it isn't, I've provided the > following info > > dmesg > ----- > > ath0: mem 0xef200000-0xef27ffff irq 17 at device > 0.0 on pci3 > > ar9300_flash_map: unimplemented for now > Restoring Cal data from DRAM > Restoring Cal data from EEPROM > Restoring Cal data from Flash > Restoring Cal data from Flash > Restoring Cal data from OTP > ar9300_hw_attach: ar9300_eeprom_attach returned 0 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] LDPC transmit/receive enabled > ath0: [HT] 2 RX streams; 2 TX streams > ath0: AR9460 mac 640.2 RF5110 phy 0.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 > > /etc/rc.conf > ------------ > > wlans_ath0="wlan0" > ifconfig_wlan0="DHCP" The WPA keyword is missing here. It should read ifconfig_wlan0="WPA DHCP". > create_args_wlan0="country GB regdomain ETSI" > > /etc/wpa_supplicant.conf > ------------------------ > > network={ > ssid="REDACTED_5G" > psk="REDACTED_PASSWD" > } > > thanks, > -- > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Sat Dec 24 12:56:13 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NfPDz5X82z1Lnl5 for ; Sat, 24 Dec 2022 12:56:19 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NfPDy3fDSz4KX9 for ; Sat, 24 Dec 2022 12:56:18 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b="KG/eUCcf"; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=xN5+qdHc; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 9A6EB3200313 for ; Sat, 24 Dec 2022 07:56:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sat, 24 Dec 2022 07:56:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1671886576; x=1671972976; bh=TJzFZSWPgr Hlwi7f5RNUlKXDVx6NxbN1s9XRxlG+Zmg=; b=KG/eUCcfsdncB4xLTkxjoFo6y7 RD/GPNANlFG0eVHtpkFvLia0xYk/lNAo/uGLjX2dcaI9nds9gZ9KtM80Z3l7poQ5 ws4ahThsM5LAeMIbXIW0qnrYgMNfFAtYh8WZUgDsTz5WEsMmdm79wXzjRgd9A3f+ PnUDzkRE+BmYLO2pUQj5MgExWHynxaAI6UBup6C5kb8b1BWpJjsALt5iu/ugtduV Gtv/hEYH1OD+berv+3dVoRgAE8YgfoHA5Jboth6y5jUJqSBwrQa6rpjRNZbr/vHj 0W+JzOSfDplT6ftH0SwrKCXgzSYjK4ThaORucBkd5L/eqnI0IylNxiwwD/OQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1671886576; x=1671972976; bh=TJzFZSWPgrHlwi7f5RNUlKXDVx6N xbN1s9XRxlG+Zmg=; b=xN5+qdHcpCLrmS1K/hhZ7N4Jugn55y8t+jskO+o0hmuS 5EfJkRBWld/zsVRh5P6iAYSVrbOwr3bQR8bSjVdsUV/RqsFnikXIaWdmEP0GzsvX 6ojC1EqJ8GvrMP4rfnFeqZAPMkiiAOgYjyA4rixiIyk4ZdtlFxNuYcP8JQHen0Xo GlSG7NIBoHILEcn2HGWhW0jDiXbYea5jFusnZLKasTwzeJl89cSd/ErXS79KOtq9 /K/q2ZJbQlW4q/NheKnXysqgi2fFnVS36wi+j2n4cAeuoAOGXoxI4+JGmCL8olWG q4g8bNeODqoe+xV53ZKvgei5V5ykJxyuOXTSgOKTUw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheeggdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutdehhe fgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 24 Dec 2022 07:56:15 -0500 (EST) Date: Sat, 24 Dec 2022 12:56:13 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <20221223144851.6CA981EA@slippy.cwsent.com> <20221224044834.91BA3178@slippy.cwsent.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221224044834.91BA3178@slippy.cwsent.com> X-Spamd-Result: default: False [-4.84 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.74)[-0.744]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from] X-Rspamd-Queue-Id: 4NfPDy3fDSz4KX9 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 23, 2022 at 08:48:34PM -0800, Cy Schubert wrote: >The WPA keyword is missing here. It should read ifconfig_wlan0="WPA DHCP". I had omitted that in an attempt to solve the problem. But I'll try it again and report back. The end result I'm after is to have wlan0 on the internal rfc1918 LAN and the wired interface (em0) on real dual-stack IPs, *without* routing between them. The reason there's DHCP in the wlan0 line is because it's the only way I've managed to get the wireless working (as in associated) so far. -- From nobody Sat Dec 24 14:40:30 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NfRYJ08Dfz1mXqq for ; Sat, 24 Dec 2022 14:40:36 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NfRYH3K07z4Z64 for ; Sat, 24 Dec 2022 14:40:35 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=rQZSuUYN; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=GAYCpe04; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 40F923200911 for ; Sat, 24 Dec 2022 09:40:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 24 Dec 2022 09:40:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1671892832; x=1671979232; bh=0ky4w/Q5CO lkcJou6sHbM/f9fls0XpOxKGjA1OeOMrk=; b=rQZSuUYNPXsB6K7PQNgjFteRin f2MHRWeoe189MWHXnSeyw0xnHKgI/dTlUEf6k/6qTFSAyXX4lzEQzmT/qv7Z1eSX gb74sFWpi1GDvcXIQW26g0AxTrNKz2nvEI0QCQ2Xka6RypSYX2XHi8VJFRrKgqHK V9AbBSlZ8BtTZEzLpT8bTXbb7k/WZj9Oukjqs+4GTuJZzmsxLRQ7zkJl9j5wUlSj wt+fZfYTY01qV7T6SJSKRUkTjBhW6QhuuwE6/h8qonatwH1TPTebMv/Ih6OtW8Dk LrupCXyF9FhIdtZOnomdvV3SArpGOG22TZAN4XkGkajednJUKs3qKZzaHW4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1671892832; x=1671979232; bh=0ky4w/Q5COlkcJou6sHbM/f9fls0 XpOxKGjA1OeOMrk=; b=GAYCpe04gK3l5cY4pVN1SLrLqAPIr4D9BYMqwcT4vl28 Gg7gZuYL8eiJ46koC/oc1znhDjscZXUsQYwQLngMgrxssI9cY8B0ayY7xI+cg61T ppzOVXsYLcGnkidXKdkWHZrquvGVV+TkzJ9ham5Q6irwr2PstSRxDMleM11/m7ek 2acyHZBMOxIosUNika1L89ZJ1vcTU9ilOcU4eOuGsmwOGapfAsZtOiNGFNlciobJ fu22EgJHJTg6oa4DFSWEgy155+dlkojW8xJzTiwfMDvPPHXAOte32xJr7xF9F9nf 4UI3/1tG3iUiwGDtpXMClHguc8sY35vga4ijNjIH6Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheeggdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeekleduvdelhfeileefgffghfffkedtheellefgudfgvdegkeejjedutdehhe fgueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 24 Dec 2022 09:40:32 -0500 (EST) Date: Sat, 24 Dec 2022 14:40:30 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <20221223144851.6CA981EA@slippy.cwsent.com> <20221224044834.91BA3178@slippy.cwsent.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221224044834.91BA3178@slippy.cwsent.com> X-Spamd-Result: default: False [-5.09 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from] X-Rspamd-Queue-Id: 4NfRYH3K07z4Z64 X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N On Fri, Dec 23, 2022 at 08:48:34PM -0800, Cy Schubert wrote: >The WPA keyword is missing here. It should read ifconfig_wlan0="WPA DHCP". With the WPA keyword in place I only had to restart wlan0 a few times (instead of many) after reboot. What I'm not understanding is why it takes multiple times. If this isn't done, the wlan0 never associates. -- From nobody Sun Dec 25 01:58:35 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nfkc25LYKz1HYGx for ; Sun, 25 Dec 2022 01:58:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nfkc23J95z3lwh for ; Sun, 25 Dec 2022 01:58:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id 8sHkpJZp3c9C49GHxpI2nY; Sun, 25 Dec 2022 01:58:57 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id 9GHvp0VKsHFsO9GHwpYana; Sun, 25 Dec 2022 01:58:57 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=63a7ae61 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=IkcTkHD0fZMA:10 a=sHyYjHe8cH0A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=I7eXwJjMzQDmm0BlEaEA:9 a=QEXdDO2ut3YA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from [127.0.0.1] (unknown [209.52.88.154]) by spqr.komquats.com (Postfix) with ESMTPSA id 88DFB6BB; Sat, 24 Dec 2022 17:58:55 -0800 (PST) Date: Sat, 24 Dec 2022 17:58:35 -0800 From: Cy Schubert To: freebsd-hackers@freebsd.org, void Subject: Re: wpa_supplicant in base and in ports In-Reply-To: References: <20221223144851.6CA981EA@slippy.cwsent.com> <20221224044834.91BA3178@slippy.cwsent.com> Message-ID: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfHlPcc2B1EYjxVn0Hrj+m/U/CXNHdGeo7ZpxAkbAQ8lS82dfnaAYFlxGTD43acoz2Qc6w0f6II2WVRlqo2nSJYdI2lMY6utOVc4cW+A9Yw+dxxYdxE3u T2qm26e4VUl6rQMEG3QTA0xpIQ20E95j+5M+Bb2DXdn9wM0z5ZpzwDQMC/gbkisk9EnwLfWGa4/XiK9RDxVOeyVUu1QcbgK9cFTmtTm3tRzMF9I3zuJ7i6FE X-Rspamd-Queue-Id: 4Nfkc23J95z3lwh X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On December 24, 2022 6:40:30 AM PST, void wrote: >On Fri, Dec 23, 2022 at 08:48:34PM -0800, Cy Schubert wrote: > >> The WPA keyword is missing here=2E It should read ifconfig_wlan0=3D"WPA= DHCP"=2E > >With the WPA keyword in place I only had to restart wlan0 a few times >(instead of many) after reboot=2E > >What I'm not understanding is why it takes multiple times=2E If this isn'= t >done, the wlan0 never associates=2E Can you post dmesg and egrep 'wpa|dhclient' /var/log/messages, please=2E --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD=2Eorg NTP: Web: https://nwtime=2Eorg e^(i*pi)+1=3D0 Pardon the typos=2E Small keyboard in use=2E From nobody Mon Dec 26 12:12:05 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ngc982TfWz1J7Wj for ; Mon, 26 Dec 2022 12:12:12 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ngc972nfWz3qcD for ; Mon, 26 Dec 2022 12:12:11 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm2 header.b=rnk2uc9M; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=RtxVrziC; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 08ED632002B6 for ; Mon, 26 Dec 2022 07:12:08 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 26 Dec 2022 07:12:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1672056728; x=1672143128; bh=L6w86Ws76d k3BJQwk2c0c44gprz/QxvXND1oqXUEVEk=; b=rnk2uc9Msx1doF5FkGaq1ri/Ma JaQ77xLw2eI5mqs59BLkQb6RXLmrp4xsMwSI5bfI2R6QREiR68fwQEq/ia7pgM+M ZAVM7LqbObqn42+VkPBRjwGzOwjk7SNfzqrMrCbt67s0zncKG/HGbEul5n8EccvH 2yHdg8SLufMIY9TXKcZ4iScYizedf1lTbbNzc5NDNO3BeByoV5ulU22yXVpl67jh fvULLcBeX4pBvjhSRhd/LIDGikZ38LFHHQxmCDoXkr8FzRdvo8imX+hJHJRuXCX/ WQqZoFTALTFEYPXBRyvrLFMbXm/4MaDZVCsWRN7zfKniMH85t9McamRPpwtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672056728; x=1672143128; bh=L6w86Ws76dk3BJQwk2c0c44gprz/ QxvXND1oqXUEVEk=; b=RtxVrziCTBwJNh2yjH75v0RtIQe6fQOLGoLFg/kud7nc nW+RIKcWj2VPi+iKx9lS2LQHxS8TpX90Ca8ikaz8g0m+h/sw5Bs8H5TglEUQJQQZ Q5i3f+9C7Mq1+uVFoDmB1HEbGYSRwMGqMpGMUsHWhnFLj55G7kWlHVpLAQX48Q9s d12tVGJg9GgYxl4rs9f6Uj+RZ+4VJernZZaekWWxfDIn63XowNrP+VnsxFGgCtMM NMm7o+bTHQXtnAhJpezmrxZGB/g8TFu4AB5MaGxUxAxb2F8ornrqXoC28d/38hx/ fTU2QuZUDiaoid0UAP86RKEypWoa7oQN4f3d3XsLKw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheekgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjsehmtderre dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpefhlefghfefiefhheeiveehudelgefhiedvhffhveelieehjeefffdugfeghe evheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehv ohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 26 Dec 2022 07:12:07 -0500 (EST) Date: Mon, 26 Dec 2022 12:12:05 +0000 From: void To: freebsd-hackers@freebsd.org Subject: Re: wpa_supplicant in base and in ports Message-ID: Mail-Followup-To: freebsd-hackers@freebsd.org References: <20221223144851.6CA981EA@slippy.cwsent.com> <20221224044834.91BA3178@slippy.cwsent.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7vGGW4vaft9z+5F/" Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.09 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm2,messagingengine.com:s=fm2]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; TO_DN_NONE(0.00)[]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from] X-Rspamd-Queue-Id: 4Ngc972nfWz3qcD X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N --7vGGW4vaft9z+5F/ Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Sat, Dec 24, 2022 at 05:58:35PM -0800, Cy Schubert wrote: >Can you post dmesg and egrep 'wpa|dhclient' /var/log/messages, please. I rebooted to generate another dmesg & relevant wpa,dhclient messages. These are attached. In wpa-dhclient.txt there's a load of these lines: Dec 26 09:42:13 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:14 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress until I run 'ifconfig wlan0 down && ifconfig wlan0 up' where you'll see it connects. -- --7vGGW4vaft9z+5F/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg1.txt" --<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-STABLE #0 stable/13-n253168-46c09d766d26: Tue Nov 29 09:59:34 GMT 2022 root@desktop:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c) VT(efifb): resolution 1024x768 CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (3498.09-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 Features=0xbfebfbff Features2=0x7fdafbbf AMD Features=0x2c100800 AMD Features2=0x21 Structured Extended Features=0x27ab XSAVE Features=0x1 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33245048832 (31704 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. ioapic0 irqs 0-23 Launching APs: 1 3 6 4 2 5 7 vmx_modinit: VMX operation disabled by BIOS module_register_init: MOD_LOAD (vmm, 0xffffffff8543d130, 0) error 6 random: entropy device external interface kbd1 at kbdmux0 [ath_dfs] loaded [ath_rate] loaded [ar9300] loaded [ar5212] loaded [ar5416] loaded [ar5211] loaded [ar5210] loaded [ath] loaded nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 470.141.03 Thu Jun 30 18:34:20 UTC 2022 efirtc0: efirtc0: registered as a time-of-day clock, resolution 1.000000s smbios0: at iomem 0xf04c0-0xf04de smbios0: Version: 2.7, BCD Revision: 2.7 aesni0: acpi0: acpi0: Power Button (fixed) cpu0: on acpi0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 atrtc0: port 0x70-0x77 irq 8 on acpi0 atrtc0: Warning: Couldn't map I/O. atrtc0: registered as a time-of-day clock, resolution 1.000000s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xee000000-0xeeffffff,0xd0000000-0xdfffffff,0xe0000000-0xe1ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io vgapci0: Boot video device hdac0: mem 0xef080000-0xef083fff irq 17 at device 0.1 on pci1 xhci0: mem 0xef320000-0xef32ffff irq 21 at device 20.0 on pci0 xhci0: 32 bytes context size, 64-bit DMA xhci0: Port routing mask set to 0xffffffff usbus0 on xhci0 usbus0: 5.0Gbps Super Speed USB v3.0 pci0: at device 22.0 (no driver attached) em0: port 0xf040-0xf05f mem 0xef300000-0xef31ffff,0xef339000-0xef339fff irq 20 at device 25.0 on pci0 em0: EEPROM V0.13-4 em0: Using 1024 TX descriptors and 1024 RX descriptors em0: Using an MSI interrupt em0: Ethernet address: bc:ee:7b:5d:39:7a em0: netmap queues/slots: TX 1/1024, RX 1/1024 ehci0: mem 0xef338000-0xef3383ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 usbus1: 480Mbps High Speed USB v2.0 hdac1: mem 0xef330000-0xef333fff irq 22 at device 27.0 on pci0 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.1 on pci0 pci3: on pcib3 ath0: mem 0xef200000-0xef27ffff irq 17 at device 0.0 on pci3 ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal data from Flash Restoring Cal data from OTP ar9300_hw_attach: ar9300_eeprom_attach returned 0 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] LDPC transmit/receive enabled ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9460 mac 640.2 RF5110 phy 0.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000 pcib4: irq 17 at device 28.5 on pci0 pci4: on pcib4 ahci0: port 0xd050-0xd057,0xd040-0xd043,0xd030-0xd037,0xd020-0xd023,0xd000-0xd01f mem 0xef100000-0xef1001ff irq 17 at device 0.0 on pci4 ahci0: AHCI v1.20 with 2 6Gbps ports, Port Multiplier supported ahci0: quirks=0xc00000 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ehci1: mem 0xef337000-0xef3373ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 usbus2: 480Mbps High Speed USB v2.0 isab0: at device 31.0 on pci0 isa0: on isab0 ahci1: port 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xef336000-0xef3367ff irq 19 at device 31.2 on pci0 ahci1: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich5: at channel 3 on ahci1 ahcich6: at channel 4 on ahci1 ahcich7: at channel 5 on ahci1 ahciem0: on ahci1 acpi_button0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14. est0: on cpu0 Timecounter "TSC-low" frequency 1748987739 Hz quality 1000 Timecounters tick every 1.000 msec ZFS filesystem version: 5 ZFS storage pool version: features support (5000) hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 4 on hdaa0 pcm1: at nid 5 on hdaa0 pcm2: at nid 7 on hdaa0 hdacc1: at cad 0 on hdac1 hdaa1: at nid 1 on hdacc1 pcm3: at nid 20,22,21,23 and 24,26 on hdaa1 pcm4: at nid 27 and 25 on hdaa1 pcm5: at nid 17 on hdaa1 pcm6: at nid 30 on hdaa1 Trying to mount root from zfs:zroot/ROOT/default []... ugen0.1: at usbus0 uhub0 on usbus0 uhub0: on usbus0 ugen2.1: at usbus2 ugen1.1: at usbus1 uhub1 on usbus2 uhub1: on usbus2 uhub2 on usbus1 uhub2: on usbus1 ses0 at ahciem0 bus 0 scbus5 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-4 ATA SATA 3.x device ada0: Serial Number D260079A1C9B00113496 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 228936MB (468862128 512 byte sectors) ses0: pass1 in 'Slot 03', SATA Slot: scbus2 target 0 ada1 at ahcich5 bus 0 scbus2 target 0 lun 0 ada1: ACS-4 ATA SATA 3.x device ada1: Serial Number D260079A1C9B00113483 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 228936MB (468862128 512 byte sectors) ses0: pass2 in 'Slot 04', SATA Slot: scbus3 target 0 ada2 at ahcich6 bus 0 scbus3 target 0 lun 0 ada2: ACS-2 ATA SATA 3.x device ada2: Serial Number Z840ARNM ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 7630885MB (15628053168 512 byte sectors) ada2: quirks=0x8 ses0: pass3,cd0 in 'Slot 05', SATA Slot: scbus4 target 0 cd0 at ahcich7 bus 0 scbus4 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number K93DC781808 cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed GEOM_ELI: Device ada0p3.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: accelerated software GEOM_ELI: Device ada1p3.eli created. GEOM_ELI: Encryption: AES-XTS 256 GEOM_ELI: Crypto: accelerated software uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 21 ports with 21 removable, self powered Root mount waiting for: usbus0 usbus1 usbus2 ugen0.2: at usbus0 ukbd0 on uhub0 ukbd0: on usbus0 kbd2 at ukbd0 ugen1.2: at usbus1 uhub3 on uhub2 uhub3: on usbus1 ugen2.2: at usbus2 uhub4 on uhub1 uhub4: on usbus2 uhub3: 6 ports with 6 removable, self powered ugen0.3: at usbus0 uhub5 on uhub0 uhub5: on usbus0 uhub5: MTT enabled uhub4: 8 ports with 8 removable, self powered uhub5: 4 ports with 4 removable, self powered ugen0.4: at usbus0 Root mount waiting for: usbus0 ugen0.5: at usbus0 uhub6 on uhub0 uhub6: on usbus0 uhub6: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.6: at usbus0 ukbd1 on uhub6 ukbd1: on usbus0 kbd3 at ukbd1 ukbd2 on uhub6 ukbd2: on usbus0 kbd4 at ukbd2 ugen0.7: at usbus0 umass0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:6:0: Attached to scbus6 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SCSI device da0: Serial Number 058F63626476 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 da1 at umass-sim0 bus 0 scbus6 target 0 lun 1 da1: Removable Direct Access SCSI device da1: Serial Number 058F63626476 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da1: quirks=0x2 da2 at umass-sim0 bus 0 scbus6 target 0 lun 2 da2: Removable Direct Access SCSI device da2: Serial Number 058F63626476 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da2: quirks=0x2 da3 at umass-sim0 bus 0 scbus6 target 0 lun 3 da3: Removable Direct Access SCSI device da3: Serial Number 058F63626476 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present da3: quirks=0x2 ugen0.8: at usbus0 uhub7 on uhub0 uhub7: on usbus0 uhub7: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.9: at usbus0 uhub8 on uhub0 uhub8: on usbus0 Root mount waiting for: usbus0 uhub8: 4 ports with 4 removable, self powered GEOM_ELI: Device ada0p2.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: accelerated software GEOM_ELI: Device ada1p2.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: accelerated software ichsmb0: port 0xf000-0xf01f mem 0xef335000-0xef3350ff irq 18 at device 31.3 on pci0 smbus0: on ichsmb0 acpi_wmi0: on acpi0 acpi_wmi0: cannot find EC device acpi_wmi0: Embedded MOF found ACPI: \134AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361) acpi_wmi1: on acpi0 acpi_wmi1: cannot find EC device wlan0: Ethernet address: 24:0a:64:55:0a:35 lo0: link state changed to UP em0: link state changed to UP debugnet_any_ifnet_update: Bad dn_init result from em0 (ifp 0xfffff80001ceb000), ignoring. ums0 on uhub0 ums0: on usbus0 ums0: 16 buttons and [XYZT] coordinates ID=2 uhid0 on uhub0 uhid0: on usbus0 Security policy loaded: MAC/ntpd (mac_ntpd) ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping wlan0: link state changed to UP --7vGGW4vaft9z+5F/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wpa-dhclient.txt" Dec 26 09:41:58 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:41:58 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:41:59 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:41:59 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:00 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:00 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:01 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:01 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:02 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:02 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:03 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:03 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:04 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:04 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:05 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:05 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:06 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:06 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:07 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:07 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:08 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:08 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:09 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:09 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:10 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:10 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:12 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:12 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:13 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:13 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:14 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:14 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:15 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:15 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:16 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:16 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:17 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:17 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:18 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:18 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:19 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:19 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:20 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:20 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:21 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:21 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:22 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:22 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:23 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:23 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:24 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:24 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:25 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:25 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:26 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:26 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:28 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:28 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:29 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:29 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:30 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:30 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:31 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:31 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:32 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:32 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:33 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:33 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:34 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:34 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:35 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:35 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:36 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:36 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:37 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:37 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:38 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:38 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:39 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:39 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:41 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:41 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:42 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:42 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:43 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:43 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:44 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:44 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:45 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:45 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:46 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:46 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:47 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:47 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:48 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:48 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:49 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:49 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:50 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:50 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:51 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:51 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:52 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:52 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:53 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:53 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:54 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:54 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:55 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:55 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:56 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:56 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:58 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:58 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:42:59 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:42:59 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:00 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:00 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:01 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:01 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:02 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:02 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:03 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:03 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:04 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:04 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:05 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:05 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:06 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:06 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:07 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:07 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:08 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:08 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:09 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:09 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:10 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:10 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:11 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:11 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:13 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:13 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:14 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:14 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:15 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:15 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:16 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:16 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:17 desktop wpa_supplicant[92560]: ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Operation now in progress Dec 26 09:43:17 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1 Dec 26 09:43:24 desktop wpa_supplicant[92560]: wlan0: Trying to associate with d0:17:c2:de:8a:fc (SSID='REDACTED_5G' freq=5540 MHz) Dec 26 09:43:24 desktop wpa_supplicant[92560]: wlan0: Associated with d0:17:c2:de:8a:fc Dec 26 09:43:24 desktop wpa_supplicant[92560]: wlan0: WPA: Key negotiation completed with d0:17:c2:de:8a:fc [PTK=CCMP GTK=CCMP] Dec 26 09:43:24 desktop wpa_supplicant[92560]: wlan0: CTRL-EVENT-CONNECTED - Connection to d0:17:c2:de:8a:fc completed [id=0 id_str=] Dec 26 09:43:25 desktop dhclient[62347]: New IP Address (wlan0): 192.168.1.71 Dec 26 09:43:25 desktop dhclient[63452]: New Subnet Mask (wlan0): 255.255.255.0 Dec 26 09:43:25 desktop dhclient[64608]: New Broadcast Address (wlan0): 192.168.1.255 Dec 26 09:43:25 desktop dhclient[66525]: New Routers (wlan0): 192.168.1.1 Dec 26 09:59:25 desktop wpa_supplicant[92560]: wlan0: WPA: Group rekeying completed with d0:17:c2:de:8a:fc [GTK=CCMP] --7vGGW4vaft9z+5F/-- From nobody Mon Dec 26 17:18:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ngkz14gqHz2G3X6 for ; Mon, 26 Dec 2022 17:18:53 +0000 (UTC) (envelope-from nhuff@acm.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ngkz067RSz3Htn for ; Mon, 26 Dec 2022 17:18:52 +0000 (UTC) (envelope-from nhuff@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="g plJN77"; spf=softfail (mx1.freebsd.org: 66.111.4.27 is neither permitted nor denied by domain of nhuff@acm.org) smtp.mailfrom=nhuff@acm.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=acm.org (policy=none) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BE9AC5C00C6; Mon, 26 Dec 2022 12:18:52 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 26 Dec 2022 12:18:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1672075132; x= 1672161532; bh=qVXJc+fyWnvk2nA9LT0oLoN1NFCuqkZHeT675O0AdVQ=; b=g plJN772IqD/Rev2p24AkgyoELZE/wYP/V8yF3ayhtbzMUYoMNvrdoHKekZG8WvTo X3TAFi/0L5S68T8OWU9EUiMVhrx4Vgm5+nPBeTFHXq4exA6S9SY230w/FrT/MAqM UcfYgduhDAXLnjQBaGTzVwblI/Vdxg1yhLQ2zWoo762aZfk1+TRdm5bN8hgqJ+Z2 XbAW2UKWeafgmREMUV1QK26g57HsWhK/kV1jbjZ7t+ZwFTZKedupI5GCRwRKXswv 2pDPv6lq9zu4a9NzfZ6umtmpt3q8ETmd6tx2iX+lWmZ9nOUvL9wdJRAva4qeBmWc sQYndqnaqf6g9rM5/xqHA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheekgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgesthdtredttddttd enucfhrhhomheppfgrthhhrghnucfjuhhffhcuoehnhhhufhhfsegrtghmrdhorhhgqeen ucggtffrrghtthgvrhhnpefgvdffgefgvedugfeifeduveefudeuveefheejveffffejle ekjeffkedvteevgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehnhhhufhhfsegrtghmrdhorhhg X-ME-Proxy: Feedback-ID: ida914761:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 26 Dec 2022 12:18:52 -0500 (EST) From: Nathan Huff To: freebsd-hackers@freebsd.org Subject: daemon(8) exit behavior Date: Mon, 26 Dec 2022 10:18:51 -0700 Message-ID: <86tu1i6q2s.fsf@enyo.nrhuff.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-4.30 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; DMARC_POLICY_SOFTFAIL(0.10)[acm.org : No valid SPF, DKIM not aligned (relaxed),none]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.111.4.27:from]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4Ngkz067RSz3Htn X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N The current behavior for the daemon command when it receives the HUP signal and it is supervising a process is to send a HUP signal to the supervised process and then exit immediately. According to the source comments this is the intended behavior. The issue I have run into with this behavior is that when the daemon process is when writing the supervised processes stdout/stderr to syslog or an output file you can lose any log messages that the supervised process outputs during its shutdown process. I created a small modification to the daemon process that allows setting a shutdown delay that will send HUP to the supervised process then continues to read the process output for up to delay seconds and then sends the supervised process the KILL signal. This allows a window for the supervised process to gracefully shutdown and we can still log any messages created during that time period. A couple questions for the list. 1. Is there any interest in upstreaming this? 2. What should happen if the supervised process doesn't exit after the KILL signal is sent? Something has probably gone sideways somewhere if we end up here, but I have definitely seen cases where something is stuck with signals blocked. Currently my modification waits for the process to actually exit possibly indefinitely. I chose that because I don't think we should clean up PID files if the process is in fact still running, but I can see wanting the daemon process to exit even if the supervised process is still running as that is the current behavior and still the behavior if a shutdown delay is not specified in my modified version. -- Nathan Huff From nobody Mon Dec 26 17:34:51 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NglKh1Hp7z1HBY3 for ; Mon, 26 Dec 2022 17:35:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NglKg6bHkz3L6l for ; Mon, 26 Dec 2022 17:35:03 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vs1-f49.google.com with SMTP id 3so10695921vsq.7 for ; Mon, 26 Dec 2022 09:35:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=p6D18gtAkIv4BoyBsWNZKqOQJQdeZBU8SGArtq3Q6KA=; b=iQeRKARgLahm0HEk9Pnmag4KZ75LPKq2v8tYv0N5H3XQ9BHLufS+9D3tVPPaDwJPoq dltAaqFAUdSKfCfFqdhRSZf5u21GQjZdcgAhmGl9fSg/Q5Mo5nFbYatbniy9uh3j+ooj 4XhrXzC3L6hL6icVIeFVGeaoX7en1XaQ6nvAiGHgdkXGH9V0mg1pW6B+H/WH2NLn1p66 vh+s4GCMudOcAeiiWZxjJLLPiDMwOw1SLS1dDnKFR36uy4kRvBr4cGlkQ3YuXHr3kyDV yX1OSOmTHP1v13FMuGL7jTwTyLUb8FTkuYwrpYwXJ73Ft9hCajC6UbZtDlGwi3GcQGok O6mw== X-Gm-Message-State: AFqh2ko7vcoZ+GGBAytlPzUTra9bGtuq6+X8OlaurRG84LA0WVBwg9+l kLx+gcfs0PQKl/UAf4vSzLgbcPIDIAmT9ZgKA67Pypr2 X-Google-Smtp-Source: AMrXdXt5+RdU66ZB5AcslreV+r/BWXvSG3qd3aL53wn6O3V/fy4joURd/nzxMVePtU0oeode4ML6yNrr7DQev7l6yUo= X-Received: by 2002:a05:6102:3a63:b0:3b5:26e4:f191 with SMTP id bf3-20020a0561023a6300b003b526e4f191mr2256278vsb.53.1672076102687; Mon, 26 Dec 2022 09:35:02 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <86tu1i6q2s.fsf@enyo.nrhuff.com> In-Reply-To: <86tu1i6q2s.fsf@enyo.nrhuff.com> From: Alan Somers Date: Mon, 26 Dec 2022 10:34:51 -0700 Message-ID: Subject: Re: daemon(8) exit behavior To: Nathan Huff Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4NglKg6bHkz3L6l X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Dec 26, 2022 at 10:19 AM Nathan Huff wrote: > > > The current behavior for the daemon command when it receives the HUP > signal and it is supervising a process is to send a HUP signal to the > supervised process and then exit immediately. According to the source > comments this is the intended behavior. The issue I have run into with > this behavior is that when the daemon process is when writing the supervised > processes stdout/stderr to syslog or an output file you can lose any > log messages that the supervised process outputs during its shutdown > process. Do you mean SIGTERM instead of SIGHUP? > > I created a small modification to the daemon process that allows setting > a shutdown delay that will send HUP to the supervised process then > continues to read the process output for up to delay seconds and then > sends the supervised process the KILL signal. This allows a window for > the supervised process to gracefully shutdown and we can still log any > messages created during that time period. Instead of delaying for a fixed number of seconds, what if daemon were just to waitpid for the child after signaling it? That would prevent a command like "service foo restart" from starting a new instance of the daemon. But if the actual server process is still running, then that behavior is probably desirable. > > A couple questions for the list. > > 1. Is there any interest in upstreaming this? > > 2. What should happen if the supervised process doesn't exit after the > KILL signal is sent? Something has probably gone sideways somewhere if > we end up here, but I have definitely seen cases where something is > stuck with signals blocked. Currently my modification waits for the > process to actually exit possibly indefinitely. I chose that because I > don't think we should clean up PID files if the process is in fact still > running, but I can see wanting the daemon process to exit even if the > supervised process is still running as that is the current behavior and > still the behavior if a shutdown delay is not specified in my modified > version. Waiting indefinitely is probably the best thing that we can do if a SIGKILLed process doesn't exit. > > -- > Nathan Huff > From nobody Mon Dec 26 18:28:20 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NgmWM3Hxyz1HKBc for ; Mon, 26 Dec 2022 18:28:31 +0000 (UTC) (envelope-from mail@souji-thenria.net) Received: from alisa.souji-thenria.net (alisa.souji-thenria.net [188.68.37.165]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NgmWL6QhHz3hTd for ; Mon, 26 Dec 2022 18:28:30 +0000 (UTC) (envelope-from mail@souji-thenria.net) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=souji-thenria.net; s=20220813rsa; t=1672079302; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mgX8KQ2STzm6l55WZ+yq4QLBUTh7LrY0VQHUCD+k82s=; b=cPHRer7Xnn8Fj2aD50/2XTrA8fNrL2Wakm5vMWRXhaGBtZzf4jzfm3NIH/LV62EIwxf1LX P4nvAyWugelnc7Rfj9iFz1ZXwbIL9Bw25Q5DlGUhiYyP4uZNZKYOLn3MMmy/rrxB61fguR ejS4j924DL/xQduvQzP0EFG0Lto7lE8tu1H/IN4TPvx+FVlEM8SujoN0yHJ7cnQiuktyxV zyDUUy1GMTKKdfnNTJPlHg/sIBzD54UC1kJTkkQ0g3hZauORat1q6z6DJHp0w+qvzATaHz BCzWsSFEkrWUuMbQGwm1f5iBXtJ5Dp0GamLaLrn1h5wBq+A9rnNUxNPfUhI3Mg== Received: from [192.168.178.41] (nat-178-19-228-9.net.encoline.de [178.19.228.9]) by alisa.souji-thenria.net (OpenSMTPD) with ESMTPSA id 9c72f492 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 26 Dec 2022 19:28:21 +0100 (CET) Message-ID: <23fba5e2-0f7d-b609-9ec0-009d6f6bd085@souji-thenria.net> Date: Mon, 26 Dec 2022 19:28:20 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: daemon(8) exit behavior Content-Language: en-US To: Nathan Huff , freebsd-hackers@freebsd.org References: <86tu1i6q2s.fsf@enyo.nrhuff.com> From: Souji Thenria In-Reply-To: <86tu1i6q2s.fsf@enyo.nrhuff.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NgmWL6QhHz3hTd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:197540, ipnet:188.68.32.0/20, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 12/26/22 18:18, Nathan Huff wrote: > > 1. Is there any interest in upstreaming this? > Because I run in to this problem as well in the past, I would be most interested in this. > 2. What should happen if the supervised process doesn't exit after the > KILL signal is sent? Something has probably gone sideways somewhere if > we end up here, but I have definitely seen cases where something is > stuck with signals blocked. Currently my modification waits for the > process to actually exit possibly indefinitely. I chose that because I > don't think we should clean up PID files if the process is in fact still > running, but I can see wanting the daemon process to exit even if the > supervised process is still running as that is the current behavior and > still the behavior if a shutdown delay is not specified in my modified > version. > I think using the timeout limit which is used by FreeBSD when shutting down the system, makes the most sens and would have some consistency throughout the system, at leas in my opinion. Moreover, I think you should clean up the pidfile, if the daemon process created it. IIRC that's also the current behavior. -- Souji Thenria From nobody Mon Dec 26 21:13:29 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NgrB755bnz1J0Ds for ; Mon, 26 Dec 2022 21:13:51 +0000 (UTC) (envelope-from nhuff@acm.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NgrB66MpRz46HR for ; Mon, 26 Dec 2022 21:13:50 +0000 (UTC) (envelope-from nhuff@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="Y 0OZo9c"; spf=softfail (mx1.freebsd.org: 66.111.4.25 is neither permitted nor denied by domain of nhuff@acm.org) smtp.mailfrom=nhuff@acm.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=acm.org (policy=none) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6FADB5C0059 for ; Mon, 26 Dec 2022 16:13:50 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Mon, 26 Dec 2022 16:13:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1672089230; x= 1672175630; bh=DHDT/VrWNre1BFhNPcmue1QLZm0Wrmzi9pLxw4KbzUY=; b=Y 0OZo9cdPp/GqEKc61loqMrhTiSQ2KntPJqV+ikVr8VK7b4WOwXGVrNrcQ2uYBX9j QdBFbGZGGc6N4afl+Ue8w/hd7vR0u2LM56BsxglAz5swHrPOidznL9X6eWjACHyB oqsARtnpam+cTAwlm8Vc7/SqoL2iLm6E2Jq9y7JcLNUfFyo+IsvyPTfoItvTwAMV g4i7o8Ie5J65jaWk1DAMizpGwFWGg3PVb0x8GRtlDfkVQNj7dbimKvQC+TlTvCog 4vRNh1EfKZGSPTAPFHNjcTheNJhDuJKOB93OyPDVGyWwZ/hP3/fD5WkzgKabubwe zm7yPQOF2coXAT6h48Obw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheekgddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfpfgrthhhrghnucfjuhhffhdfuceonhhhuhhffhesrggtmhdr ohhrgheqnecuggftrfgrthhtvghrnhepleduteffvdfgudeiledugeduhfelffevvdekle duiedvgfeujeekgefhuedtueefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepnhhhuhhffhesrggtmhdrohhrgh X-ME-Proxy: Feedback-ID: ida914761:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17E182D4007D; Mon, 26 Dec 2022 16:13:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1185-g841157300a-fm-20221208.002-g84115730 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 x-forwarded-message-id: <86r0wm6o7o.fsf@enyo.nrhuff.com> Message-Id: <679d90a3-2b6b-4b9d-ab75-44558d93f916@app.fastmail.com> Date: Mon, 26 Dec 2022 14:13:29 -0700 From: "Nathan Huff" To: freebsd-hackers@freebsd.org Subject: Fwd: Re: daemon(8) exit behavior Content-Type: multipart/alternative; boundary=8cf3b13f4f3447a0bf3fd6291bddccec X-Spamd-Result: default: False [-3.89 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[acm.org : No valid SPF, DKIM not aligned (relaxed),none]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; XM_UA_NO_VERSION(0.01)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4NgrB66MpRz46HR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --8cf3b13f4f3447a0bf3fd6291bddccec Content-Type: text/plain Alan Somers writes: > > Do you mean SIGTERM instead of SIGHUP? > Yes I meant SIGTERM not SIGHUP. > > Instead of delaying for a fixed number of seconds, what if daemon were > just to waitpid for the child after signaling it? That would prevent > a command like "service foo restart" from starting a new instance of > the daemon. But if the actual server process is still running, then > that behavior is probably desirable. > That is basically what my modification does. The delay really just sends SIGKILL to the supervised process after the delay and waits for it to die. The delay just gives the supervised process time to gracefully shutdown before trying to more aggressively kill it. > > Waiting indefinitely is probably the best thing that we can do if a > SIGKILLed process doesn't exit. > That is my opinion, but it isn't the current behavior so I figured others might have a different opinion. >> >> -- >> Nathan Huff >> --8cf3b13f4f3447a0bf3fd6291bddccec Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Alan Somers <= ;asomers@freebsd.org> writ= es:

>
> Do you mean SIGTERM instead of SIGHUP?
>

Yes I meant SIGTERM not SIGHUP.<= br>

>
> Instead of delaying= for a fixed number of seconds, what if daemon were
> j= ust to waitpid for the child after signaling it?  That would preven= t
> a command like "service foo restart" from starting = a new instance of
> the daemon.  But if the actual= server process is still running, then
> that behavior = is probably desirable.
>

T= hat is basically what my modification does.  The delay really just<= br>
sends SIGKILL to the supervised process after the delay an= d waits for it
to die. The delay just gives the supervised= process time to gracefully
shutdown before trying to more= aggressively kill it.

>
&= gt; Waiting indefinitely is probably the best thing that we can do if a<= br>
> SIGKILLed process doesn't exit.
>

That is my opinion, but it isn't the current = behavior so I figured
others might have a different opinio= n.

>>
>> --
>> Nathan Huff
>>

<= /div>

--8cf3b13f4f3447a0bf3fd6291bddccec-- From nobody Mon Dec 26 22:20:56 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ngsgb6lbGz1J8VQ for ; Mon, 26 Dec 2022 22:20:59 +0000 (UTC) (envelope-from nhuff@acm.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ngsgb0q8pz4JMg for ; Mon, 26 Dec 2022 22:20:59 +0000 (UTC) (envelope-from nhuff@acm.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=i73NnDMr; spf=softfail (mx1.freebsd.org: 66.111.4.25 is neither permitted nor denied by domain of nhuff@acm.org) smtp.mailfrom=nhuff@acm.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=acm.org (policy=none) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3518E5C0172; Mon, 26 Dec 2022 17:20:58 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 26 Dec 2022 17:20:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1672093258; x=1672179658; bh=ZvReuqgfyh2LOjFvE2s7UCKU55dm c5IJQ8Kaq/35Wqw=; b=i73NnDMrrd89M3P//0rEICLOWJWmVK1uNVUbZ+9G640L uvx5QicVgKWQLK0Jze6M7sTfW1n+obYkCDnZFC4o4aqzRbNg0KNZlTko4LZG0n8G PjQH4Le6reokPrrE2Jn8Zf3uwBakGK6b6fQURVBqtnhyeh+VNCw5Eeg8kDZp/8of 92Ai1Let1Qe2fEfZ9t4Cq5PpTcm/YdBxkCPLW3g3z33aRA029PqJ26hE0A6LMoC8 GNoB4QqPln6YBNcyjvnaeYVi4h1W2ZOAcpCqhSg58jgV/gtP6FCdEtgWlr0671xM 0sioGJkFDzu0+G8LmEJFfv5xnbeoUPWl9aUCMvTU/A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrheekgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffujghffffkgggtsehttdertd dttddtnecuhfhrohhmpefprghthhgrnhcujfhufhhfuceonhhhuhhffhesrggtmhdrohhr gheqnecuggftrfgrthhtvghrnhepffdviefftdeghefhheetkedtgfdujeekjeejjefhve fftdevveeuudeivdfgvdffnecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhhhuhhffhesrg gtmhdrohhrgh X-ME-Proxy: Feedback-ID: ida914761:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 26 Dec 2022 17:20:57 -0500 (EST) From: Nathan Huff To: freebsd-hackers@freebsd.org Subject: Re: daemon(8) exit behavior In-Reply-To: <23fba5e2-0f7d-b609-9ec0-009d6f6bd085@souji-thenria.net> References: <86tu1i6q2s.fsf@enyo.nrhuff.com> <23fba5e2-0f7d-b609-9ec0-009d6f6bd085@souji-thenria.net> Date: Mon, 26 Dec 2022 15:20:56 -0700 Message-ID: <86o7rp7qnr.fsf@enyo.nrhuff.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Result: default: False [-4.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[messagingengine.com:s=fm2]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[acm.org : No valid SPF, DKIM not aligned (relaxed),none]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; DKIM_TRACE(0.00)[messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; R_SPF_SOFTFAIL(0.00)[~all]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4Ngsgb0q8pz4JMg X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N Souji Thenria writes: > On 12/26/22 18:18, Nathan Huff wrote: >> >> 1. Is there any interest in upstreaming this? >> > > Because I run in to this problem as well in the past, I would be most > interested in this. > I have submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268580 with the patch. > > I think using the timeout limit which is used by FreeBSD when shutting > down the system, makes the most sens and would have some consistency > throughout the system, at leas in my opinion. I don't want to tie daemon too closely to the init system since I use it in other contexts at times so that is why I have the delay configurable. > Moreover, I think you should clean up the pidfile, if the daemon process > created it. IIRC that's also the current behavior. > The pidfiles do get cleaned up in my version. They just don't get cleaned up until the supervised process actually exits. With the current behavior the pidfiles can get removed even if the supervised process has not exited. -- Nathan Huff From nobody Wed Dec 28 01:12:11 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NhYR3250gz2cBmf for ; Wed, 28 Dec 2022 01:12:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NhYR217qnz3J9B for ; Wed, 28 Dec 2022 01:12:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oABf2xkQ; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.32 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672189947; bh=JCTG/GnKmQbW1q0hgPc6LXpUcdYA1voftd39Kgf3k5M=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=oABf2xkQJA6UX3+lOiWwctFRvbkaQPEgY9n6vyewFOcohNI5AfO62aDDYnQhseW9ja0ATuCXlYW8GEEJU6w7DHYjiFet3Wdt3+UB3zp55W4Q5rwau0++iQJznfbrhHUFGaaiRnX1lU7ertvgj/NWtzI3uNr9A4l+74Gr8La+B59+1Lfd6LoWHbjibRk2sD9clgPau5w+Q/FMF62awx95Moq+2pxeQ9u5TeORLEtOQy2HGkN0cyMFj5H/O87D7QXVLFHSrO1a2IQYcJP/1nPqYs2EeJRxni8KUhdnsKy91O91Q1TGKZrPsX2re/59FvekwuNLbNWlYKGJxEO4hZLQPQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672189947; bh=sgQMaYAOnGBcpMztlhvvN5BTd2Y0CG7i1cLWxObHiuh=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=gv0D3Q9+vi687LfJpfOy5h6pQiytTY69c4YAXU65YXt90oFe14uC9faBSCp2bHxlSPkIn3vwU9qSfaCE1Ng2gglnzb5Rqg20Gjpmy1XGvVPxy1Er23IUzHNQfo/7g9ODb7nrxJ//0KraPjqTHqOajKHTLxFZ/X/YklPwgkFOvGMI9RRystDgk/fi2pGrkTzk4tR7tog73FEvVoVJDG24vO/6KspuWWS4CBiySFpTqLMiUDjl+ckPOQXSOYxfdzFizTb7ZlLDwZGYs4rky1n6wi2ZXUtzaPZfJ/l0OZ8zGB9i3oajVcZZ+/g2mLsNXXam0spKNEF6Dl1xY4krpjsXbQ== X-YMail-OSG: niHXbq8VM1k1e4h8yWUEmRmYhFpkcvBR1lxXSSfaA_hYmif9k98UMO9l2nUEeOS XAPTPpu1f_My9uT_801CZddO4.id3yjP6lbmBxC1BpBV50A_gqkqSy.zqmDVgAbgJqgs117iWCYx zboC0aySgBJ56sNFfmNtqAzKUE4uXmc7DALqjvsdMjLql4NBx8N8LRc2jhEqlOZs6sF6JKHUy2fG 9o28WWiYXHZNGy4nj747JseIFVjxQ5axlDuGCUdmy9KT34ENymX9nm3R6syLFpxi9oAPVtZf1Trk u2muQU4uBpYqOjVeGeU20cF.RpMKntuhnGmUEKbYxfzTXjWh9AoEK2YVDY5bggirZ3Mj8fKpp9mx NtaLsEfZcsVOz0LwpZOgCFXvJ8kcARTp4trtiMG3Mi7ZbqUHCwH8aKA5hX7lQI8Uf.6qSlJw0N9y Dx0aIVzfpcJzZV6WFEKfkUnWa464zZj5nWguQiL3UPjLYrU4chtGwTODqrt9quRXKUakujmWNw.3 Lw3kRG4zaqFxJ6MzTvfSFu9J7gnTFBoO41_QQuW613jm.w7cghF4QshIUB73JFjtQwXB6qEaUaWC 5BIXIdzQrbjN9oumOwC2DoZe4c8T_GTxpvRei7cB55HJSDQJSfnUTuj7E7tY2V400StKVubTO6Hl uSZsvaf5FCVsJW1STXH64hkfOaR9TCW.n67Mec9sgmO_N9yw_c6DD.Gf5N_UdODhd4pioGTBhl9Z pNhPXMBgn7f6YktgkeCWdTF9AaTUBGbaZOb669903QG6HHVG43Dz42dQVNYwCYph3qFv2ONbargw wkwjqQlOJ5a0lEdnk8aHCuArMnnNkZboz6c879p0adg_tacns1szDStzOpoY4DbW5156rIR9hlW4 b.By1QH7qrnSI236qF0dYp.bTap7w1KIprIPXaa8HuPg_a2ZqG9f1nBB5L__P4Pyhcfq0VCjoYU6 zVu.3HvNHtHMduCG2p60lSLgpwdmRbXKVzHKZBLRkEPREqm5Ab5AHCxd3Gu96lCu6O6fqeqw1VsK ry8LgKHpCCbcvzl8XZQh2Mw.ATZ24vJF1iMsIKYSEcL5KFze.N3cNi1mpKqW8bkfx6vfYtG9tECg PAvbF.fmPq3K93Bub2FDxgOBZZLNx4rX9hJZH7G2uOej6OhxwbPz.XZAtmkXyuw05EVQ1JBGOBQk zxgR03X_0wydQpBQzeHqj4ifmXEJUncbsqXa8Q9s6hAAFiSdh_SmzoCLeoXG5JMEU1cl0oYmTHnw hZhw70RcXXK_bzDl0A1G21xQ7r.OVrWa4XzkyHP3XLyHWZedtMEY4h7BzsJp.PHtetw3CYKNI3sL dpx74BJzQyG1rJ.Ks8BgifI7f.AVJn6XbAd5QF5cGcIxw.nuEppF.2YSvM_uqrUjAADFy3scciI2 UQ6TEjwyREYorX7k0gG9WAIjNIPdxsMGHBCu_jQhxdQNUsrf2PEuwhaYqP3aKfQpxcai3x5YrvkV wE0iADgIxnLHF.R6KifqVeo7B.dbRsubqqZGyJlBIsoyDV3zGqy0ZSGhamTJC7UyU3gGVUoLa0SS fAjkD_Tdx4IYoIZ7Fpi3BA.jPfxhshQUhApVn87xDrY2OCpQS2EtoMbTVRqB5mFlHj4tqESekGU2 9GQ4tVBan526Kv.B3.3VE4Fv4vehM0AOTWK5.vmOAMaaB0V_ZNSCsyJxpLexatuFeqwhg1N143aK YsNKJ12c1b7qjXk4Y0EJhWh8NCZ5pgDWO3Ks52SDwdH18lTz_p4loUraD9bvjFFj.I_Uaa2kwXEp 9v9yFOpYcOYeqI46xeoGCRPzXffqtw33MvXYCBej7734oINvwcfu6Yf35CiYGX26GsvwzvO5cmsB Ji58nY4zZDhYT6OJLve5sOJIITXy59fAGnE0bfM4Ef..QuxzkCTVJi98cn4fjgHUXTYKOx5l7qPe 4aQXm9wrK9tTpCMnmdUedfl.lvd0p0IqEpaDMb1PabtIT5hztmx1rP6yzRWnrbAGeauTKFNL8Q3R rwJyriVn7EvaWB_cAgL9bEDf_Cct1iAqv5GyFP4jPk7VQDu4jZx7H3oh2K5gsWvdjBZwJbPRIgZJ 4tjdUMfUh2Qf3eqTN_vBvHcfZoXDVnwKgNTWGL8vPGA_Xn47vAIsmbex0QUZVbqwxW1.DsoHAqUj 9F0MY6G08NTcR1bpcLk.QFBCHHMXsRWDYiyhRjLndMEJ5AF0NxrvmqK3_XuWVuIK.GjsdF9lpg9m xk..B8KDkgKW6AVG_.CTlW29L1T0CN9TqKXDARLQ6AboGgrUXJU1UN9kd1ADKSBg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Dec 2022 01:12:27 +0000 Received: by hermes--production-bf1-5458f64d4-kkg2s (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ccb3a8e72036075dedd02b38ceca06e1; Wed, 28 Dec 2022 01:12:23 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: How do I find whatever combination of things end up defining pcib_get_bus(. . .)? Message-Id: <5D802E64-9B2D-4ECB-9889-18C17ED4F788@yahoo.com> Date: Tue, 27 Dec 2022 17:12:11 -0800 To: FreeBSD Hackers X-Mailer: Apple Mail (2.3731.300.101.1.3) References: <5D802E64-9B2D-4ECB-9889-18C17ED4F788.ref@yahoo.com> X-Spamd-Result: default: False [-2.48 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.984]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.32:from]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.32:from] X-Rspamd-Queue-Id: 4NhYR217qnz3J9B X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N # grep -r "\" /usr/13S-src/ | more /usr/13S-src/sys/mips/nlm/xlp_pci.c: busno =3D pcib_get_bus(dev); /usr/13S-src/sys/powerpc/ofw/ofw_pcibus.c: busno =3D = pcib_get_bus(dev); /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); /usr/13S-src/sys/dev/cardbus/cardbus.c: pcib_get_bus(cbdev), = pcib_get_bus(cbdev), 1, 0); /usr/13S-src/sys/dev/cardbus/cardbus.c: bus =3D pcib_get_bus(cbdev); /usr/13S-src/sys/dev/hyperv/pcib/vmbus_pcib.c: busno =3D = pcib_get_bus(dev); /usr/13S-src/sys/dev/pccbb/pccbb.c: b =3D = pcib_get_bus(child); /usr/13S-src/sys/dev/pccbb/pccbb_pci.c: sc->pribus =3D = pcib_get_bus(parent); /usr/13S-src/sys/x86/pci/qpi.c: *result =3D pcib_get_bus(dev); /usr/13S-src/sys/x86/pci/pci_bus.c: bus =3D pcib_get_bus(dev); /usr/13S-src/sys/x86/iommu/intel_drv.c: *busno =3D = pcib_get_bus(bus); Everything found is a use, not a definition. (I also tried: # grep -r "\" /usr/obj/BUILDs/13S-CA72-nodbg-clang/ .) Historically I've managed to eventually track down definitions are are less direct, such as ones that are formed via macros that put together names. But, so far, I've not managed to for pcib_get_bus . So, hopefully, someone can point me to what I've missed. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Dec 28 01:41:21 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NhZ4P0Wznz2cGQD for ; Wed, 28 Dec 2022 01:41:25 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NhZ4N5Xt1z3Mck for ; Wed, 28 Dec 2022 01:41:24 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; none Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 283435C00A0; Tue, 27 Dec 2022 20:41:24 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Dec 2022 20:41:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1672191684; x= 1672278084; bh=shUuKMz/X0eP7VzDEHt2apAibkoR3Uvgx5RKyHsspWo=; b=E la13Q5SXtWsHsIviTY3/Gqdda1IJ+E/XmXiq65aMeZV+00AVvqHRWxcYFYI2hmzg dL3QYEHTg9jelbUOuu7BvHXEC1NuiDYeBc802LN18PW3WPPz6VzNGu/I6fb56OVf PKIzhyMjxUVIKpjdu5YoLYWwgYN38fdCjD0Xi5jSnHl350bN5Yiamaoebr1WbCqp 7yyM9Y4ihGzx+eEEcfvuG3vEHs0RAWiycsrvmxEqYeueJWfY/o+65YAO23wxEaJQ ePqNjm+rmXncw/NTEdfQtgKn2c7xebvR6SKG9+yYRKp3wzZntaDJrKvvf8JbjQQb b6711SzDI9cY1QE+eBDgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1672191684; x=1672278084; bh=s hUuKMz/X0eP7VzDEHt2apAibkoR3Uvgx5RKyHsspWo=; b=OnjFRm2oehtpj/ID1 J1mZigMEQFQQ/tdCzF3O1AatIEWn/6Ftqs6rcRs6y29nIPpeR5Z2eh5TNjYuOkdx qYvZOzoLbKtvSJ/5s6oX9aTwXXONHXF17AqB3ohYT41d6AXP/XcMS4k6Ypz1oJEh B3+pqkzgvg3/qfuMdbBWjtW3kopLYQS1fhiejuYSBAAeXy4wAqQWf2pBvID//z9g n9fVLWzciUcvoM5oNOgnsmDw/3AACgHYH92e2QJ6o3exOi/snGghzPRRMsuo8563 IQ6RXHTp+INbX85U1x3Tbm5zZnn8GHGxQWPmPGTQ570QinuSCX4kcz6+Czki4D5y lSUjw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedriedugdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpegjuhhrihcu oeihuhhrihesrggvthgvrhhnrdhorhhgqeenucggtffrrghtthgvrhhnpeevvdegledtve ekudfhjeeggeffteehueejlefhkeegffetheevveejfefhgffftdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihesrggvthgvrhhnrd horhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 27 Dec 2022 20:41:23 -0500 (EST) Message-ID: <0988689f-4434-f9f3-42c3-9f9622d31022@aetern.org> Date: Wed, 28 Dec 2022 02:41:21 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: How do I find whatever combination of things end up defining pcib_get_bus(. . .)? To: Mark Millard , FreeBSD Hackers References: <5D802E64-9B2D-4ECB-9889-18C17ED4F788.ref@yahoo.com> <5D802E64-9B2D-4ECB-9889-18C17ED4F788@yahoo.com> Content-Language: en-US From: Yuri In-Reply-To: <5D802E64-9B2D-4ECB-9889-18C17ED4F788@yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4NhZ4N5Xt1z3Mck X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > # grep -r "\" /usr/13S-src/ | more > /usr/13S-src/sys/mips/nlm/xlp_pci.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/powerpc/ofw/ofw_pcibus.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/dev/pci/pci.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/dev/pci/pci.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/dev/pci/pci.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/dev/cardbus/cardbus.c: pcib_get_bus(cbdev), pcib_get_bus(cbdev), 1, 0); > /usr/13S-src/sys/dev/cardbus/cardbus.c: bus = pcib_get_bus(cbdev); > /usr/13S-src/sys/dev/hyperv/pcib/vmbus_pcib.c: busno = pcib_get_bus(dev); > /usr/13S-src/sys/dev/pccbb/pccbb.c: b = pcib_get_bus(child); > /usr/13S-src/sys/dev/pccbb/pccbb_pci.c: sc->pribus = pcib_get_bus(parent); > /usr/13S-src/sys/x86/pci/qpi.c: *result = pcib_get_bus(dev); > /usr/13S-src/sys/x86/pci/pci_bus.c: bus = pcib_get_bus(dev); > /usr/13S-src/sys/x86/iommu/intel_drv.c: *busno = pcib_get_bus(bus); > > Everything found is a use, not a definition. (I also tried: > # grep -r "\" /usr/obj/BUILDs/13S-CA72-nodbg-clang/ .) > > Historically I've managed to eventually track down definitions > are are less direct, such as ones that are formed via macros > that put together names. But, so far, I've not managed to for > pcib_get_bus . > > So, hopefully, someone can point me to what I've missed. See __BUS_ACCESSOR() macro in sys/bus.h (I had to have a bit of fun with `cc -E` to get at it). From nobody Wed Dec 28 03:40:26 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nhck40Mc7z2khy8 for ; Wed, 28 Dec 2022 03:40:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nhck34n13z3l0c for ; Wed, 28 Dec 2022 03:40:43 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672198841; bh=fkJM0iZ/3f3GUQOGj/5OeSGgDrcBJ3PVIH9tE6WIkr4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=XVbukm8FzH9uD/LDE+xlcHE1R2t5oIpYbZufJb0Ed4+6eFMYgSk5PdprmWl84Zq8w+Rl4nForIJNNsY8a+nZawi7lCkRD8MRQ3Fc/BehyOprtbdS3RRJdWJNdwDE2pKeMDgLSpea2opCMkwwC7hcSGjWnWJlz+UJb4G9bdD5AZl1NiO7M34enk1Tpp6wlLI8824CdhtHMlfM8DEjI2THwoNAqVZbD449t3X8uBxDb1nW0siipFIb+w2mbMEqux2Bt/XRnALEbXDfq2gF3rkzxhztEg2rd6NOu4YBrH3BgSzqY9QoFq2F2OvQH3uaET+ms7Tv1n0Pvi+mv/1Sk5LQtA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1672198841; bh=dRozLEZ66MZYr4QsOPph8bSvzv4ysLFNBPXnCKvcq0z=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=YM8522nymqNhpv9HNetP6RCj90Daq0pQKMZc+u+iaLPQe8qtt6AfsAJCI1q28ZbDvFG7/FZHDKdxjxOaEubivirHwdvGCZEMyxn8JN9YS3XQKBv1scPeITqNJ8IcrMReIpCvMbmjVv2xZegM1zgydm6HbrfJe+vtJbguQydISvEEXJOMVJ7TPLc3NBOSY59Xp0/znIEmHWOAcyyR4YtSMR2Qfs09AXonFrUS0GSoJaYdieTq5V3HxkKHI70nV/sOiHdk8W7mT+vxs3Zq9H1JZ24lUv2Hnw1Hup3AjeliyBOGkoxrStCrLMVsXLahVjtYaH85flIsXmkqIknPpPig/Q== X-YMail-OSG: ReFR1e8VM1lt4z7LJgQzj_GAqGgJA5kFJ5lV2ZeVfRq30AW6NnoIRaY56k5t1ON Uhmr_3sVQX9_t1RGRSCcLpTYP2t7VQ1O3b_ntk9QRz6XiZKwGskSgwt41QsOD2hcaozWSKVS5qZq J8CH0vQ5_oI4Sbs_iyohGmYXdKggOkHUo1._Nx7lu1Lgo1G97CSF0msh.IwP0xeJWHdAGEKLqW63 cbn8GDNE5qrrKLulrK_QpIlim.0yMi0eMepTrr7AIDUshy7OOmEwfOvDydt7VmxNWdqgsJhIAWDk Cv3JaiSZI82rb.ml7fYMhPT5VaylJMdXLUY3W8_tKaZK4xiKbrwtZIAQi6KZCwPxMbiJwoKgpl9e K67Ov.deeylj.KwGiWv16QYBo6Ny2XH_vYrLdB3aR8fADEn1NIXa9RjRZStl2SJzllUupZVbNXlf qFghqa4dGEIsVf72QNLSXZ_9VzsCjfcuEGTvyDozlceCIOh.ch11pDH5vitenOGZNzj3OXMSHccq aDNNjJwkrpXbsRPSbLjat3B82A3XmkakrGQrFMsBPt7yLBNfhv9pe6.YUc6R8i7B.Vhz7CHvdCzG Sj.nO0Ihee9d8CQtBg8C69Fgk.yPpv.6sqS.qrfEwjgkf6hhj6NOgaWy5sCY_6iJEDy2mu0n63ph rQ6qt1Z4kOlk7.4TeCwb.3druAWlDOH_jILHighUxavxBD0EjoBdrJOHnApiXD7f7fdBC5xXVira 7iaEBca0c298tETbIlmACpZ8MYQz08XWUhU9_1sUeuOcEHyjW7LL7M2n0ZXlcargG_mOrPE1YLWQ J19B3aoHrdTWoyDXQPqxE3Ipnue8RkIxkyogSloVue1uDonoGJ_8SwMMJF7Mn8nybL8HWRsX_VO_ UJOB42t_JDCbuz0RHVtZtVO0vxfr3N.el26dJSOtDiH_kW7NnMAq3XLaUNttTk24TtGbeID4dpGh xXyNzkWvluf08bGfSzXmPTe1URS3D7vQ_5obL.ubkea0A_to2Eq.7RX8wm8.nJBIJWvmiAYWbOA. 8FLF1QTi.QZJ6GBXT3P.OmtE2IktUATPnshFzFAgs2nM4W6jFMraFZ3A_ChiZSyjy.H0odSRZqKm X26C0TKlCdUcMy.HU5thTgaMP86l9G1oLC3fI6.DAqskrHaR7Gb1_qZXS0ghA8nrxm61A9yw_.E4 jxxkc4cBPI9nIUx_64H1C4SSvKTdv8WzAcHtYjAkm9oBFd7roRtxkszd.ssgRpiwVob4eVBzU8Wi PncoNH0rQPy6KIkqapnh5WZ4LfxyIthxoolO3Yl.Kk24Mciz2J0bZvvmwhsjHxYl8auxUbwCIxCi jaUxzpVamTZlS2dHLiZLgzLMaiKrrVbkZt4VN.wkLGwhzsYlmDBNDZpecKa1RP3zZ_5cOX5haLNW 38oRq8XRL.oBxOrwaw4LmKkFRNp9_z3rDZIYsGPO8GJiHhk7rf8CkAi0HwZ0_ypECmMGy.e2IC5Q qkuaErDg1.GUbXBiF352fZvczMFSP51Dgw34AhNvEo2XHXoNiswzqHk4ptDdJwjqcRjDlV22cr5D 5tknUbsSWmneBBdaoIk.0ega46eCfdQVIZ0FfTMo7MzZYTLaUhE4QtWiRZk1BaJWoFsDVmT.0rpq E4XdA3JhzrNfyiJOat5FjmsVo8nPFdYfCC1QhEOA.20m9AMy8Il9lIammkBcq6N.YPGwuI69Ch.a ssQdUtsGWjMdKl6_QrYq_1KIYArRMqyuS4MV_RLGOI8q5rKNV5Omy0y1NOyUVcIgLQiVMYPkZJoS DRW4oyvdOJrPKcZrQtERb5NFpdu4CqI9tOKmUbBMynsAgaqli4g6XL10QBFh0VYasAB7U8g9bvBL W5tWZyjynthiiMkUBpjI9Wpz37Ux6Np_eRq.2qfv8VAJgrb9jVLra5p8LAnBh9YXJFGNrzfg2F5B HNRJubHoxHHc1EnGAKDa0yjLC5pEs7L0s_GM52CycYerL3r0iP7gCtkrEnEvs_8FxQuCOK.JWhA6 UcHbM2I3fidxAcr0JlgnbGIRNkKKrejr1biFdPGk74JyxS4QDruFUid.ud6NwR5RIngdA.lqL6xy 9HwWsV1Eix7wS7qaF0wUkhu6QCnO.sGrHGTCkOlBVLlhviF5r.yg7yd8X88CWAGosyksyUUHSR_R tsw1FFcaOkBUp.ueKN_YmfhtphWC9gxWeWkqi68zq4Zxn9OC2wK_XraxrRVngWyrao5DRYvQe9Ff IW54FEL0GLp9vJ08KKzhJJz9OqNi4pySxXJ.9TcIevGAbwOqm5rFJYZq_XjKO5jPoHvziXgN5bgx nCio- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Wed, 28 Dec 2022 03:40:41 +0000 Received: by hermes--production-ne1-7b69748c4d-tc4mm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e6a6331a28df4c962a5683a48593aed8; Wed, 28 Dec 2022 03:40:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: How do I find whatever combination of things end up defining pcib_get_bus(. . .)? From: Mark Millard In-Reply-To: <0988689f-4434-f9f3-42c3-9f9622d31022@aetern.org> Date: Tue, 27 Dec 2022 19:40:26 -0800 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <7DE1B7B5-9A74-43DC-B3B3-89D91834501B@yahoo.com> References: <5D802E64-9B2D-4ECB-9889-18C17ED4F788.ref@yahoo.com> <5D802E64-9B2D-4ECB-9889-18C17ED4F788@yahoo.com> <0988689f-4434-f9f3-42c3-9f9622d31022@aetern.org> To: Yuri X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4Nhck34n13z3l0c X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Dec 27, 2022, at 17:41, Yuri wrote: > Mark Millard wrote: >> # grep -r "\" /usr/13S-src/ | more >> /usr/13S-src/sys/mips/nlm/xlp_pci.c: busno =3D pcib_get_bus(dev); >> /usr/13S-src/sys/powerpc/ofw/ofw_pcibus.c: busno =3D = pcib_get_bus(dev); >> /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); >> /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); >> /usr/13S-src/sys/dev/pci/pci.c: busno =3D pcib_get_bus(dev); >> /usr/13S-src/sys/dev/cardbus/cardbus.c: pcib_get_bus(cbdev), = pcib_get_bus(cbdev), 1, 0); >> /usr/13S-src/sys/dev/cardbus/cardbus.c: bus =3D pcib_get_bus(cbdev); >> /usr/13S-src/sys/dev/hyperv/pcib/vmbus_pcib.c: busno =3D = pcib_get_bus(dev); >> /usr/13S-src/sys/dev/pccbb/pccbb.c: b =3D = pcib_get_bus(child); >> /usr/13S-src/sys/dev/pccbb/pccbb_pci.c: sc->pribus =3D = pcib_get_bus(parent); >> /usr/13S-src/sys/x86/pci/qpi.c: *result =3D = pcib_get_bus(dev); >> /usr/13S-src/sys/x86/pci/pci_bus.c: bus =3D pcib_get_bus(dev); >> /usr/13S-src/sys/x86/iommu/intel_drv.c: *busno =3D = pcib_get_bus(bus); >>=20 >> Everything found is a use, not a definition. (I also tried: >> # grep -r "\" /usr/obj/BUILDs/13S-CA72-nodbg-clang/ .) >>=20 >> Historically I've managed to eventually track down definitions >> are are less direct, such as ones that are formed via macros >> that put together names. But, so far, I've not managed to for >> pcib_get_bus . >>=20 >> So, hopefully, someone can point me to what I've missed. >=20 > See __BUS_ACCESSOR() macro in sys/bus.h (I had to have a bit of fun = with > `cc -E` to get at it). Thanks. Looks like could have explored with just PCIB_ and found: /usr/13S-src/sys/dev/pci/pcivar.h:#define PCIB_ACCESSOR(var, ivar, = type) \ /usr/13S-src/sys/dev/pci/pcivar.h:PCIB_ACCESSOR(domain, DOMAIN, = uint32_t) /usr/13S-src/sys/dev/pci/pcivar.h:PCIB_ACCESSOR(bus, BUS, = uint32_t) /usr/13S-src/sys/dev/pci/pcivar.h:#undef PCIB_ACCESSOR and the #define line would have shown: #define PCIB_ACCESSOR(var, ivar, type) = \ __BUS_ACCESSOR(pcib, var, PCIB, ivar, type) But in everything I did I was explicit about "get" as part of the text I explored with. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Jan 1 17:52:20 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NlRR93l5Cz2lN8L for ; Sun, 1 Jan 2023 17:52:37 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.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 (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NlRR833m8z3Q9M for ; Sun, 1 Jan 2023 17:52:36 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of george+freebsd@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george+freebsd@m5p.com; dmarc=none Received: from [IPV6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPSA id 301HqKQI033889 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 1 Jan 2023 12:52:26 -0500 (EST) (envelope-from george+freebsd@m5p.com) Message-ID: Date: Sun, 1 Jan 2023 12:52:20 -0500 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Content-Language: en-US To: FreeBSD Hackers From: George Mitchell Subject: What is "zio->i"? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mattapan.m5p.com X-Spamd-Result: default: False [-2.30 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TO_DN_ALL(0.00)[]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[freebsd] X-Rspamd-Queue-Id: 4NlRR833m8z3Q9M X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N FreeBSD 13.1-RELEASE-p5, using SCHED_4BSD. What is "top" telling me when a process is in "zio->i" state? Every so often, either firefox or thunderbird seemingly sits there contemplating its own navel in that state for up to a minute or two. It recovers of its own accord, of course, but I wish I knew what it meant. Just a few months ago, I moved my /usr partition from UFS to ZFS, saving myself some fsck aggravation (rarely necessary, but very slow when needed). "top" also reports some pretty big ARC numbers -- specifically, bigger than free memory, but not big enough to consume any swap space: Mem: 1232M Active, 1577M Inact, 27M Laundry, 2675M Wired, 175M Buf, 317M Free ARC: 1823M Total, 283M MFU, 1515M MRU, 16K Anon, 5117K Header, 13M Other 1712M Compressed, 2135M Uncompressed, 1.25:1 Ratio Swap: 8192M Total, 8192M Free -- George From nobody Mon Jan 2 11:00:44 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NltGl62LWz2p6J8 for ; Mon, 2 Jan 2023 11:01:51 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NltGk37qNz41RN for ; Mon, 2 Jan 2023 11:01:50 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=leidinger.net header.s=outgoing-alex header.b=PfrdfxJo; spf=pass (mx1.freebsd.org: domain of Alexander@leidinger.net designates 89.238.82.207 as permitted sender) smtp.mailfrom=Alexander@leidinger.net; dmarc=pass (policy=quarantine) header.from=leidinger.net Received: from outgoing.leidinger.net (p5b165611.dip0.t-ipconnect.de [91.22.86.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "outgoing.leidinger.net", Issuer "R3" (verified OK)) by mailgate.Leidinger.net (Postfix) with ESMTPSA id C6EB33338C for ; Mon, 2 Jan 2023 12:01:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1672657290; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=ydjhhgQ9UdlVsyi3T+e0vB29JOIFP6hyWGVBSsJQMbg=; b=PfrdfxJoMTQB6jLN6ZlKNCUBgmInVxr5UVRns0knppxINcm0VLuCFQxtOUqDnqR+P25c30 Pe70Chgw7lmNLYsZoYSIffz9ALmjq1Zg4YyB85C/ytvwx5sbJ85713RXF77HWnkECWPb/U oopi752HHvjjG7Yqg0NstBV5XHOxURubz7GS7hNq7wBHp4Wf8XFRwM56IRSq0GFH2BO+Et ePBND0UOegZSGDeQqf7crL/m5TO/WuJaRiHCjui0stATLWY02KxW8+weHmmsYW6tA0X9YA Bo/mU3uQ7nlzeAIutfNn2xnB62Jo5MF8iG9inF7ioQbfy3ssSrNrbVDa3HYrDg== Received: from webmail.leidinger.net (localhost [127.0.0.1]) by outgoing.leidinger.net (Postfix) with ESMTP id 8B62F4A97 for ; Mon, 2 Jan 2023 12:00:45 +0100 (CET) Received: from www (uid 80) (envelope-from Alexander@leidinger.net) id 811e4 by webmail.leidinger.net (DragonFly Mail Agent v0.13+ on webmail.leidinger.net); Mon, 02 Jan 2023 12:00:45 +0100 Date: Mon, 02 Jan 2023 12:00:44 +0100 Message-ID: <20230102120044.Horde.iouHjGhaxepeEKAbm7pBGb4@webmail.leidinger.net> From: Alexander Leidinger To: George Mitchell Cc: FreeBSD Hackers Subject: Re: What is "zio->i"? In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_qyArmExEM8xHaKs6o2nsGnr"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-Spamd-Result: default: False [-5.09 / 15.00]; SIGNED_PGP(-2.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[leidinger.net,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[leidinger.net:s=outgoing-alex]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[leidinger.net:+]; TAGGED_RCPT(0.00)[freebsd]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4NltGk37qNz41RN X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_qyArmExEM8xHaKs6o2nsGnr Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting George Mitchell (from Sun, 1 Jan 2023=20= =20 12:52:20=20-0500): > FreeBSD 13.1-RELEASE-p5, using SCHED_4BSD. > > What is "top" telling me when a process is in "zio->i" state? Every > so often, either firefox or thunderbird seemingly sits there > contemplating its own navel in that state for up to a minute or two. > It recovers of its own accord, of course, but I wish I knew what it > meant. Just a few months ago, I moved my /usr partition from UFS to > ZFS, saving myself some fsck aggravation (rarely necessary, but very > slow when needed). "top" also reports some pretty big ARC numbers > -- specifically, bigger than free memory, but not big enough to > consume any swap space: > > Mem: 1232M Active, 1577M Inact, 27M Laundry, 2675M Wired, 175M Buf, 317M = Free > ARC: 1823M Total, 283M MFU, 1515M MRU, 16K Anon, 5117K Header, 13M Other > 1712M Compressed, 2135M Uncompressed, 1.25:1 Ratio > Swap: 8192M Total, 8192M Free An incomplete list of wait channels is here:=20=20 https://wiki.freebsd.org/WaitChannels In=20your case it means most probably that it waits for some ZFS IO to fini= sh. Happy new year, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_qyArmExEM8xHaKs6o2nsGnr Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmOyuVwACgkQEg2wmwP4 2IbY4xAAiiy7WI/vdwl505QpJbjVac3Od62Mh7Rc+3XwT6a/dt150fdGqhloA3P8 5LaODEnHaJtTBreKOGNuFSk/3ZctzZNg5cTHhDiMwEzNvP+LNug3bLhEJLqAJ/h1 QFizHZvbuSqGoWiedZmgqiS0wa/kv7P5RyojEnWYD0pppWb7BKOLhBBcE7IOQ/pm anhGLiebW8VZGlXJGW8LxJIfqaEd+c7Ih3UPtTpmq6/Me6nXFlD+C6ovWTZZvd67 yyfw8IRhw/M2LHIxxxTlQAcvQVLZt0rLN51Q/8g9LSRrwWa9l7WGVNFXdgZ7GLJB iY3ss8XM5OCiXWIZhrrbygtl5PN325XZgPDcL2JIlpMTErfMYokvpLHHeC+R9m0b qbpzsKVG5ba/tMiPfLIkf+GZZT2e0413OfMfKjTNqsSHoTq+cxX5ySfGglKRBP2a iaDm6U80gBGLJilcVa2HUxqTsYAuE0ls06En14zbXoQ88kpLS7grQ3Y+q+I9vGgJ trTB5xhYbho/lSPnyegUFtuBEXlC2uKseRttPsoIQUMLSiNUcoisAUBDUxXKeLi4 uPoL7nWlt7SUIkLy1e4b++r0QK3s/XcQNfzbBLXi4eRZ6/Brdz7mKUySijkfpytf MZqxZV7gAj4PfzKyMTdfcT4t0pjKY+j+OEWKKqPdyod6+orVSvo= =xWbP -----END PGP SIGNATURE----- --=_qyArmExEM8xHaKs6o2nsGnr-- From nobody Sat Jan 7 16:41:59 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nq5fL6YNDz2r27R for ; Sat, 7 Jan 2023 16:44:58 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nq5fK67Xqz3GvX for ; Sat, 7 Jan 2023 16:44:57 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of freebsd-listen@fabiankeil.de has no SPF policy when checking 80.67.18.28) smtp.mailfrom=freebsd-listen@fabiankeil.de; dmarc=none Received: from [91.20.76.172] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pECK2-0001TP-70 for freebsd-hackers@freebsd.org; Sat, 07 Jan 2023 17:45:30 +0100 Date: Sat, 7 Jan 2023 17:41:59 +0100 From: Fabian Keil To: freebsd-hackers@freebsd.org Subject: ZFS-related panic(s) with zfs-2.1.7-FreeBSD_g21bd76613? Message-ID: <20230107174159.1b7e61e9@fabiankeil.de> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/b=hAGdo3Z+CY0ACQI+n1yOn"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Df-Sender: Nzc1MDY3 X-Spamd-Result: default: False [-1.15 / 15.00]; SIGNED_PGP(-2.00)[]; RBL_SENDERSCORE(2.00)[80.67.18.28:from]; AUTH_NA(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.996]; NEURAL_HAM_MEDIUM(-0.85)[-0.854]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[80.67.18.28:from]; DMARC_NA(0.00)[fabiankeil.de]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RCVD_IN_DNSWL_NONE(0.00)[80.67.18.28:from]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:34011, ipnet:80.67.16.0/20, country:DE]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Nq5fK67Xqz3GvX X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --Sig_/b=hAGdo3Z+CY0ACQI+n1yOn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yesterday I rebased ElectroBSD [0] on stable/13 77c0992af4e3b while it was previously based on stable/13 d3b97a1ea0123. I didn't notice any issues in a test VM and therefore decided to update my laptop as well. So far I've experienced three panics/reboots/freezes that I suspect might be caused by the upgrade from zfs-2.1.6-FreeBSD_g6a6bd4939 to zfs-2.1.7-FreeBSD_g21bd76613. They all occurred while I was syncing ZFS datasets with zogftw [0]. Unfortunately I only have one backtrace so I can't say for sure that the other times where ZFS related as well: Unread portion of the kernel message buffer: panic: VERIFY3(0 =3D=3D zap_remove(mos, dsobj, spa_feature_table[f].fi_guid= , tx)) failed (0 =3D=3D 2) cpuid =3D 3 time =3D 1673033419 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00dc686= 8a0 vpanic() at vpanic+0x151/frame 0xfffffe00dc6868f0 spl_panic() at spl_panic+0x3a/frame 0xfffffe00dc686950 dsl_dataset_deactivate_feature_impl() at dsl_dataset_deactivate_feature_imp= l+0xe6/frame 0xfffffe00dc6869a0 dsl_dataset_clone_swap_sync_impl() at dsl_dataset_clone_swap_sync_impl+0x13= 5/frame 0xfffffe00dc686ad0 dmu_recv_end_sync() at dmu_recv_end_sync+0x2a2/frame 0xfffffe00dc686b30 dsl_sync_task_sync() at dsl_sync_task_sync+0xb4/frame 0xfffffe00dc686b60 dsl_pool_sync() at dsl_pool_sync+0x42b/frame 0xfffffe00dc686be0 spa_sync() at spa_sync+0xb00/frame 0xfffffe00dc686e10 txg_sync_thread() at txg_sync_thread+0x281/frame 0xfffffe00dc686ef0 fork_exit() at fork_exit+0x7e/frame 0xfffffe00dc686f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00dc686f30 --- trap 0x3, rip =3D 0xffffffff80659b3f, rsp =3D 0, rbp =3D 0xffffffff818f= 4fa0 --- mi_startup() at mi_startup+0xdf/frame 0xffffffff818f4fa0 swapper() at swapper+0x69/frame 0xffffffff818f4ff0 btext() at btext+0x22 Uptime: 6m35s Dumping 1098 out of 8050 MB:..2%..11%..21%..31%..41%..51%..62%..72%..81%..9= 1% __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcpu, (kgdb) where #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff806cda18 in dumpsys (di=3D0x0) at /usr/src/sys/x86/include/du= mp.h:87 #3 doadump (textdump=3D1) at /usr/src/sys/kern/kern_shutdown.c:423 #4 kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:497 #5 0xffffffff806cde9e in vpanic (fmt=3D, ap=3Dap@entry=3D0x= fffffe00dc686930) at /usr/src/sys/kern/kern_shutdown.c:930 #6 0xffffffff81278e3a in spl_panic (file=3D, func=3D, line=3D, fmt=3D) at /usr/src/sys/contri= b/openzfs/module/os/freebsd/spl/spl_misc.c:107 #7 0xffffffff813001e6 in dsl_dataset_deactivate_feature_impl (ds=3Dds@entr= y=3D0xfffff80019a60000, f=3Df@entry=3DSPA_FEATURE_USEROBJ_ACCOUNTING, tx=3D= tx@entry=3D0xfffff80191ace200) at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:1116 #8 0xffffffff81304cb5 in dsl_dataset_clone_swap_sync_impl (clone=3D0xfffff= 8018fc79000, origin_head=3D, tx=3D, tx@entry=3D0x= fffff80191ace200) at /usr/src/sys/contrib/openzfs/module/zfs/dsl_dataset.c:= 4083 #9 0xffffffff812eaff2 in dmu_recv_end_sync (arg=3D0xfffffe00d91366b8, tx= =3D0xfffff80191ace200) at /usr/src/sys/contrib/openzfs/module/zfs/dmu_recv.= c:3233 #10 0xffffffff8132c254 in dsl_sync_task_sync (dst=3D0xfffffe00d91364a8, tx= =3Dtx@entry=3D0xfffff80191ace200) at /usr/src/sys/contrib/openzfs/module/zf= s/dsl_synctask.c:248 #11 0xffffffff8131ea6b in dsl_pool_sync (dp=3Ddp@entry=3D0xfffff801eabad800= , txg=3Dtxg@entry=3D3576757) at /usr/src/sys/contrib/openzfs/module/zfs/dsl= _pool.c:847 #12 0xffffffff81353930 in spa_sync_iterate_to_convergence (spa=3D0xfffffe00= da149000, tx=3D0xfffff80191e73400) at /usr/src/sys/contrib/openzfs/module/z= fs/spa.c:9069 #13 spa_sync (spa=3Dspa@entry=3D0xfffffe00da149000, txg=3Dtxg@entry=3D35767= 57) at /usr/src/sys/contrib/openzfs/module/zfs/spa.c:9287 #14 0xffffffff81368281 in txg_sync_thread (arg=3Darg@entry=3D0xfffff801eaba= d800) at /usr/src/sys/contrib/openzfs/module/zfs/txg.c:591 #15 0xffffffff80689fde in fork_exit (callout=3D0xffffffff81368000 , arg=3D0xfffff801eabad800, frame=3D0xfffffe00dc686f40) at /usr/src= /sys/kern/kern_fork.c:1093 #16 #17 mi_startup () at /usr/src/sys/kern/init_main.c:322 #18 0xffffffff80a1e439 in swapper () at /usr/src/sys/vm/vm_swapout.c:755 #19 0xffffffff802f8722 in btext () at /usr/src/sys/amd64/amd64/locore.S:80 Has anyone else seen this? I've seen it with three different ZFS pools and I think the pools are fine. The laptop only supports USB2 so scrubbing the pools takes days which is why I didn't do it yet. I have no reliable way to reproduce the issue yet. Running zogftw sync again after rebooting worked in all three cases. Fabian [0] [1] --Sig_/b=hAGdo3Z+CY0ACQI+n1yOn Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTKUNd6H/m3+ByGULIFiohV/3dUnQUCY7mg2AAKCRAFiohV/3dU nVeTAJwOJxTyRr8I094jXfB8FFndQhrgEgCgpRGdtjsZHCdb/PEFq5roM9bd6DU= =7ROx -----END PGP SIGNATURE----- --Sig_/b=hAGdo3Z+CY0ACQI+n1yOn-- From nobody Sun Jan 8 21:03:17 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NqqL25Y18z2r7xd for ; Sun, 8 Jan 2023 21:03:22 +0000 (UTC) (envelope-from paulf2718@gmail.com) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NqqL05RLJz3LCv for ; Sun, 8 Jan 2023 21:03:20 +0000 (UTC) (envelope-from paulf2718@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=EgQMtDYo; spf=pass (mx1.freebsd.org: domain of paulf2718@gmail.com designates 2a00:1450:4864:20::329 as permitted sender) smtp.mailfrom=paulf2718@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-x329.google.com with SMTP id o15so4915427wmr.4 for ; Sun, 08 Jan 2023 13:03:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=fThTILuwT4Sd7upUsAVfPl79KSWtLFX+DFeF6LWNpkc=; b=EgQMtDYoBjhYtqxop3dmdH+IxP73D8T6G4HR/hMEqCtZ10Z4p4GgS5uJDcmvCIyclW yh4U6KiVGPhdjsJv4WtA+8GZJBSDBIMp4bpnGmQN3exlmdWAUiO2VcKJBk5giQc1K3++ oohczZX1PmHrlEY4hxUHU4Eptw63NA05zUyPYvuPsm/T101zUxyZ7GlncV3qCWQlAB6f h/IC21CKtlIVkAD7r4Y5dUypI58btrlMmH14kSjbamWL1L3ThxmsGHzU6YVzG4FP0qhI aaEBKnPzhrtprjoY7YMC7cSFMSkcxDD52Ipydvtz6ZLYTTcq0VR+/HUVQcoAsGH/eKsV KkKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:from:content-language:to :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=fThTILuwT4Sd7upUsAVfPl79KSWtLFX+DFeF6LWNpkc=; b=TK8Rnw0oUeXwIDbMzZBINVEOiaWSBOORgvJ4/jJr39Aa5Rr6Jhc/B/vz68MKmRWi4k T6SpMmi+tjvulqtaKPRAN+kyIEmFbbj88GqUgGrcqeoyRQnILzxhYOO0ywsNKfvFj57s vTPKlhUBJ2o8HM7srfHM9FWMxfIU+qZVKs0QNdLngtPggeW9KznuU34PFmpJxgXXScY0 tFGhMJMBqOjtZnmr6ONO+6ubTNjrGIgaLjFO/Oh82MBprkSQgihRlCRgSzU7MyPEcov+ jivMnUw8UlGncFf5d+LkZPlgM0PFcsIGg0kQo51f21+yOhC1MZMD14OWUfT9ObL4BeZt EPOQ== X-Gm-Message-State: AFqh2krw+HdVIsH9rSr5LMTY7NlXtyJFG14rPRR0mGmPf2LtlHiLOBxj YhTBfAlH4KQFUXn5NDY4hWI0Wjxes8TNtw== X-Google-Smtp-Source: AMrXdXtPQVHzrvHqagaMmJcmf3espiyJ7oxEhjyRWeNK00ciDwAnZcPsWHpkh6/xg+7oQCdax0kkJQ== X-Received: by 2002:a05:600c:4496:b0:3d3:47b7:569e with SMTP id e22-20020a05600c449600b003d347b7569emr43881690wmo.2.1673211798119; Sun, 08 Jan 2023 13:03:18 -0800 (PST) Received: from [192.168.1.28] (lfbn-gre-1-309-115.w90-112.abo.wanadoo.fr. [90.112.30.115]) by smtp.gmail.com with ESMTPSA id m7-20020a05600c3b0700b003cfd4cf0761sm15260745wms.1.2023.01.08.13.03.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Jan 2023 13:03:17 -0800 (PST) Message-ID: Date: Sun, 8 Jan 2023 22:03:17 +0100 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: freebsd-hackers@freebsd.org Content-Language: en-US From: Paul Floyd Subject: Gdb auto-load python scripts Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::329:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org] X-Rspamd-Queue-Id: 4NqqL05RLJz3LCv X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi Does anyone have experience with gdb auto-load of python scripts? Valgrind just added a new feature that uses python to make interactive debugging nicer, but it doesn't work on FreeBSD. It uses an elf .debug_gdb_scripts section to tell what to load +#define DEFINE_GDB_PY_SCRIPT(script_name) \ + asm("\ +.pushsection \".debug_gdb_scripts\", \"MS\",@progbits,1\n\ +.byte 1 /* Python */\n\ +.asciz \"" script_name "\"\n\ +.popsection \n\ +"); + +DEFINE_GDB_PY_SCRIPT(VG_LIBDIR "/valgrind-monitor.py") But with this I get gdb errors: To stderr: +warning: File "/usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To stdout: +To enable execution of this file add + add-auto-load-safe-path /usr/home/paulf/tools/valgrind/libexec/valgrind/valgrind-monitor.py +line to your configuration file "/home/paulf/.gdbinit". +To completely disable this security protection add + set auto-load safe-path / +line to your configuration file "/home/paulf/.gdbinit". +For more information about this security protection see the +"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: + info "(gdb)Auto-loading safe path" I've tried adding set auto-load safe-path / to my ~/.gdbinit Any suggestions? My iniitisl impression is that ths is a gdb problem. A+ Paul From nobody Mon Jan 9 05:56:26 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nr39F2lvGz2r4bv for ; Mon, 9 Jan 2023 05:56:33 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from APC01-TYZ-obe.outbound.protection.outlook.com (mail-tyzapc01on2103.outbound.protection.outlook.com [40.107.117.103]) (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 4Nr39C4j2Hz4F03; Mon, 9 Jan 2023 05:56:31 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b=LvUq3yja; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 40.107.117.103 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FaJr4r3tGhxLDcnt6ybQVpggM/RgJAY4o4wXKGMTdZxhoPWshOoH1NnOt9VB1kGg+FbsylhzguuLETzehuY2ND98bohv9ZZrM3QITf9vqUmEnc9IfvKVqAUyCmKkAq2aiAr1K+mhBzZuwfp9zEj3SYmEeIdXwFUpiPZ/hQAFalrPA4HHXEBWSmTCwyYUjtoz/mWj/F/2tfH+yrGLU07cR8qIoEQH5HYGEKOzYcxAk5/jhq6dH+IRE55VQFec9r7DKbBjFu+/bq2kqh15b6NPUuKgEQORULBi0GXj0cUskEjbbRxpxjafc4hEw5sz7RX+G4YBob7EflZmCW7+7WPnBg== 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=Oc4vd2aNbGBe8YZdgj+59wgGEm009EyjPREasFhxDm8=; b=FSwQANjmTkaHcXcU3HYxutRlDE6R3RKDqLW9/7I2nl9hJoXovrpyRR0KsZ/E5WhErR5m5AD+a5MoFXiQ7HdmuMuiDI3qr2whpE5tyHXOlyfIv3Cr+Ec7l4R6M0OYqi/4ynMZWtn3nuS5QwEYpOyYhuiNuwYbcnxSzZYFXbWS+VhXRiNC58fNmqMaxZlDF//GWz003T0rlyX8z3GKJt+ESqkFwvpV7F34acxTZo81iSfHojVWdv+fvt9JVR731JQvq6LgL62xDgcKnYU3W5mnF5xkNNz9qBTkZxrvfNaOUzepKk6SyGy+/Oam9S46NRy5sMA3ai89UDYYqaFH2dtSTA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oc4vd2aNbGBe8YZdgj+59wgGEm009EyjPREasFhxDm8=; b=LvUq3yjaeA2ko0CUONrBDcgpRZ3RxFoLYqYfopR8GD2Zl/lBtlX1teEElUlBEP/PhvBTxmxF5IR8mYjhIOJ49ZSknyBESgbU4J678Il8NOBgvSbLCSPyLXGK3tPnjIGx5RzqQeGCMKUAgMlz42N/2TlCgc/95YH53znBdiaDm1o= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by TYZP153MB0738.APCP153.PROD.OUTLOOK.COM (2603:1096:400:260::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6002.9; Mon, 9 Jan 2023 05:56:26 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::9cbf:40b9:40ce:290]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::9cbf:40b9:40ce:290%5]) with mapi id 15.20.6023.003; Mon, 9 Jan 2023 05:56:26 +0000 From: Souradeep Chakrabarti To: Li-Wen Hsu , "freebsd-hackers@FreeBSD.org" , Andrew Turner , Andrew Turner CC: Wei Hu Subject: review of D37763 Thread-Topic: review of D37763 Thread-Index: Adkj7wXohGWS2OgpTYu/amh0jASVEg== Date: Mon, 9 Jan 2023 05:56:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=3626a6c9-8f5f-4bb7-82d1-ee922ea246b7;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2023-01-09T05:53:37Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|TYZP153MB0738:EE_ x-ms-office365-filtering-correlation-id: 6d13a4dc-ecdc-4c6e-0833-08daf2063eef x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: AefYM2m5J0Kjb/2lFgQjgIFCur+KmyU6+x9XlAcS/q5uaqsbCcYft4gZzrdoHE3vc28+JcuFjAe5D5IbDBLwj3DsaT8q53nKj6Oz4bKzwiPuDpo8tjBt+e3r7DLcFyxDUyZWyV3pDWzDmKC1H6GEeixh3hXohswzU8SW7UwD/MOpKkNiQ/jnXzJ0Mxo9XOjwcXlZBB2WjyNdSUpT6mWBRvIRUEBXn5ilX9URL2Ef2EErtpK4uKAqrUvv1awqG/59kH7947aerg935bmr1JTTFq5xdD65e+N0DsNW/bR45KW8H3qfK3pi2oBKwR/hNE+Fr7z1PV2k1Vd+VQU3jojeo6qwvZ2chaanAjxzPOiuNXWrt3Ivw/sKPlxn3wrwayZlqus/KIhM+exnW3hdfKTamd5WePt+cEVG0XgjqF0WN3ayXjvwc0tIO9t1/a6t8Hu7g/qqF8i3WripzWCEhJ6DMIUoNBKofXdLAmwzoGrO1mYEslIW6kD5PmsipAS91Ccq48a08gpQswI22uJikbFYFJVxLasnRXGD4VeKaUdvtxkgHRxKWrkZTBJlkn8SBolOznzQFrz5cIQasQUtvCZIBZ9W1u/fjTlcB5MNlQP7NOIXRInfLHxyQvG0cKpLIRbDEpSssN7MA/MHtx1ONecDuykkcdraTi+k1hYHHM6v/gKeIZqswF7KrwkuIncHWQKt9UbgPKNtcBQzQ56eHmZd8Gf9Ad73BOvxYN6FmQhgy0txoMPWrVBcsI1d3FR9SLOMQOZVdX99FFQAK4re77BKTA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(366004)(346002)(376002)(396003)(39860400002)(136003)(451199015)(8990500004)(5660300002)(52536014)(186003)(38070700005)(107886003)(41300700001)(6506007)(122000001)(26005)(8936002)(7116003)(9686003)(66946007)(64756008)(8676002)(33656002)(478600001)(82960400001)(4326008)(76116006)(66446008)(66476007)(558084003)(66556008)(38100700002)(10290500003)(71200400001)(316002)(2906002)(55016003)(7696005)(966005)(82950400001)(110136005)(86362001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lHEgB0zm5HixbEmvA3cTXEHIyCe59HFgAfg3wdAhCf4/5gOuViZkc44zEztW?= =?us-ascii?Q?HJQb0hhME799GwKqkluVKIDVCcKkdUGTQNz2a0yJKEqKLh0q1ahTCtCTS4tS?= =?us-ascii?Q?QS/X+SNnzAnNa8JwvFBrGoCPZ15kMcjDSxzXml7Iw9rq86iORN3ryJLmvcmA?= =?us-ascii?Q?UJZlRrtemPwY4W+qTxYFkS85iO9gblz9JhF8QJtUwmVMoJw1unaYdHjHHF2c?= =?us-ascii?Q?eJgdBQPjIamIcrSsNEy3An3Jm8KiMaOIGTipXH/PA7eP2wDeYcNnDS+tL+ep?= =?us-ascii?Q?jaGkaMSq03b5j93galTeqS2PpztwQXY96H5EdKNQjbzag7iS3tMvj7OydU1C?= =?us-ascii?Q?7PF8hjOcZ+0ZhqGGpvXrRvmclGdPhK4NHSpnIoVkqJv3HTEbbIBOVK+Xj9GC?= =?us-ascii?Q?QyjgudKmW3u+ZeToA5Pteed7nWA2Vz9BCZYD2vHG28uobVOGfnQm+DyyRbqr?= =?us-ascii?Q?xmNLacD7tqvDNe5WbYO9SiJ/hawyyMg2SDn0xeEhUKrtUSKPeJTME8+Vftux?= =?us-ascii?Q?DrjYdqCM92HRTCsjHpK90RdrOr8RB+6IM3e1/z5+aZXA8I+44XYbxODL6U74?= =?us-ascii?Q?BcVT+vV1L6eePaPiis32H46hHj0Y559iqk4z5bBVWZXOqgW+Ymu4/p1hGGD9?= =?us-ascii?Q?Flbw//HhVo0oTSq+wPUAvMtDcgmq2J5nSo12QbLn9YGZSvBANFKbdEOkhefW?= =?us-ascii?Q?UDIHy2VOqouQ8cKhnAfZ8GWmyhWpYlV16ejsDwbFTZxCnQBsZP3nnP7wa1wt?= =?us-ascii?Q?Azm9v3+2CMAu5ZtNKoxr2lXHh//6GzlqQcBmvfwzvNqHyeFoKBLiw2ThrF0L?= =?us-ascii?Q?7GqkHGot3WgvLn2WhwWia8tQHPWp55ETielJKoY/ob//VUr7b72Fwm81ZwI6?= =?us-ascii?Q?C6qy7c4iIo0yVrSWXLm9T96mxGhqUf5ocNlAxLInt6SJ2o0J6JT/jCExDvfw?= =?us-ascii?Q?xlEOkMlJexthTq00SuieG1PRxlJ1Zv3S0M0Qon08dJuw47GCYc0i7s2dzOh/?= =?us-ascii?Q?osHK5JQGzffypQTQVDSE8ipwe9GtCq7/i1Fn+7P5/+TLu90Kr3Jvwq/TxruY?= =?us-ascii?Q?ejY8Z3IGypE6mWS4Rg+TDDqSY8lQv7iL69hZtcb4Xtw4UpZ/P1ffQHwAHh/G?= =?us-ascii?Q?j5hEw9xjEnX+7rG8J0fCoVV0YvGKyh5bGjSRfZBHUSqixPkhC6ZWjEL6DXvY?= =?us-ascii?Q?6plxpcKhX5WDkVdXrdMwwBkJrDFkpuVl0IiDYeveUuVc+w/QDt2LgkjTqKsS?= =?us-ascii?Q?s64Xr2GK4IaSqcJCDiZ8CXdPhJv4jnOloJSy6XBa00/kqSwBCPMK9DswQzzB?= =?us-ascii?Q?eBT9MI9XJ83HpbwTTo2pDLcBPG8IHuTUzcsOWb10dxR6M4kXDy2/HxMd+Z4X?= =?us-ascii?Q?DOcZSgp/jPvDO57HsusCPjftitYXQm8hxqXe3v9SvdcoZe2J9OWawgX6ZcPV?= =?us-ascii?Q?FbvEWoQvFD7hkNHsAVLkEeOK/XXWMprgJ0rXAjISTZ39fjoM4UUFK062+NFq?= =?us-ascii?Q?Ye/5pVFGxcRCztf0Udllu/NOFgFf3GU5FLg9?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6d13a4dc-ecdc-4c6e-0833-08daf2063eef X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2023 05:56:26.5924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w3rM/6uiOpFr89aDBGYNLF4Xyz8FhW8S+YZINe4EcNkfGNTaNdapKOpa25SwhRJhvh+mcxoP2MjxemLszdgs+OMBViVu6E8pNwoxVEON+qw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYZP153MB0738 X-Spamd-Result: default: False [-9.99 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.993]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.117.103:from]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.117.103:from] X-Rspamd-Queue-Id: 4Nr39C4j2Hz4F03 X-Spamd-Bar: --------- X-ThisMailContainsUnwantedMimeParts: N Hi, I had submitted the patch for the review https://reviews.freebsd.org/D37763= . Can you please review the change. This is to enable SPI-MSI mapping in gic = acpi. Thanks & Regards, Souradeep From nobody Mon Jan 9 07:13:50 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nr4tY0HP5z2p1Zd; Mon, 9 Jan 2023 07:13:57 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Received: from HK2P15301CU002-vft-obe.outbound.protection.outlook.com (mail-eastasiaazon11020026.outbound.protection.outlook.com [52.101.128.26]) (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 4Nr4tW4GsXz4Kxy; Mon, 9 Jan 2023 07:13:55 +0000 (UTC) (envelope-from schakrabarti@microsoft.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=microsoft.com header.s=selector2 header.b="ZiPPN0/e"; spf=pass (mx1.freebsd.org: domain of schakrabarti@microsoft.com designates 52.101.128.26 as permitted sender) smtp.mailfrom=schakrabarti@microsoft.com; dmarc=pass (policy=reject) header.from=microsoft.com; arc=pass ("microsoft.com:s=arcselector9901:i=1") ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gKNlbeF/ugwOxwr8+U8jNxpeNAfRc7JqzDxakl4/80Np4U9hUySDLZ1/hd9wC+YofpDe5+eQKijgBoRwr21AeyZXOooH36IXY2IV8vq+G4el+f+5e7oZ9o1tW6S7Y2lJUy9H7QT8QboJtNYfE/G1lUBJouoYEx3Cly5jjFB5cw1jSnMqGCAJe8PyVzB0iB5tOj3iGVNStrUfY9bACAMZ5gYxG0th0bEFTdZF9WL1CYeAz42WZlTZ9HVlIOuWGzI+qb/xcxpB/KVyeFF2HxH2h5KTZOBd3apw1IpMe80+4ksDv108k9O+kU/T0ekcU5CrDBRJAVMAL2ZBTa6n34Qa+Q== 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=6ZWm7ElTEGxO6vzKr4R85Nr0OMsGd6apeiuJGZtjtI4=; b=cYr0txk9O4pRDFXbEMjNAugP09/2HgLxGqeVxlrPixNFOD4fxJOhHEttJjRG/Mm5leFOCYeOYTvqKLwoON3n+kL5GL/rcSzE+XtDYahYPc8QG6BG9N/BXOJ/Wmxmm3wN7qFWMEd3J9F7mOD8QoNH9i+7+nsBN4aPucSkALdXgL60F2FF00UpME+veDljQSRl+TkgLT8LDq7vLFFICsU18GIlyLJ0SaVapUi9nunxvH/FuNNdm2UtmAVBFCXqc8LY/6t2fEjwldHc0xGidKFhFmcsnRxNCdoBNYdv7o6qu/T0LsowymCzioMmvSHcuAK8pdXZ1usE3RrTREqQVjmprQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ZWm7ElTEGxO6vzKr4R85Nr0OMsGd6apeiuJGZtjtI4=; b=ZiPPN0/ek+g+VlBZdsMzDhKLFpzan5+ioKmAan7xMvOfBDXghyCAaadNg6wJRS1xK8yAkA0vJyFv/U9rRcpf6bYB03t3kWJDbDrFyzUhsgzrI2Y+VMiakw//fP0a1/o7sZlsiO2kL9toAzMVR74/tkclIZSlaKtowR1jdtknOKI= Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM (2603:1096:301:75::14) by PSAP153MB0422.APCP153.PROD.OUTLOOK.COM (2603:1096:301:38::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6023.3; Mon, 9 Jan 2023 07:13:50 +0000 Received: from PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::9cbf:40b9:40ce:290]) by PSAP153MB0536.APCP153.PROD.OUTLOOK.COM ([fe80::9cbf:40b9:40ce:290%5]) with mapi id 15.20.6023.003; Mon, 9 Jan 2023 07:13:50 +0000 From: Souradeep Chakrabarti To: "freebsd-arm@FreeBSD.org" , Li-Wen Hsu , Warner Losh , "freebsd-hackers@FreeBSD.org" CC: Wei Hu Subject: RE: MSI CPU affinity for ARM64 Thread-Topic: MSI CPU affinity for ARM64 Thread-Index: Adkio8F3khe3N5kdTvWiOLlk332lhABVhZLg Date: Mon, 9 Jan 2023 07:13:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=db4a32ba-f893-40d3-8ebf-516da4c3f48c;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2023-01-07T14:23:14Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PSAP153MB0536:EE_|PSAP153MB0422:EE_ x-ms-office365-filtering-correlation-id: 61d64e9d-209b-45f2-3264-08daf2110ed1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UrXKFAxpmS0fC4BKJVaEXnJ6k8q54/Qp/yj68PxKKtmQExaiLwHHgbslvwYc9XkLfWT9NuESJPjd3/dhjuOFZMwsZUNZoCzhtXmRj+SrAzpMwslxULXHsLsXb6Dx6g61hNIsKSnd+SZxr5krX7TMVwiITi1XzPmF2V5eBD98bYq88gitkWvdAtWqPqzGzpZ39tIPTaOZNH+9e6eLNJGopuSLZWm8IEnEuUJKPQBIHgmw51LliegWtTCQvsKlcpsMHrg7NTZ9rPLQRQJrUZr6WKvenBaK8iGomZjQYbZEKNDhkrt+nS1wuBlrnasfcjGETvB83gBiV+fnaCLgTpZbzaIDaHAC9I3EVRjmRxdAazgV6OBaHOPTErpQ4uTHS0T8dca094XhaFTinhKzaUAotYrVDerlZntJCvA9W1TSK233GKybIw6Ittw2fnzSzFIAoFgonbmMSvtFyCEjtYp2ugEo7s8eOb0UktDEYt5Mfuu6Y15qXV3576LSdDEypvNAZ2TRfhR+iwcQTaJ0EJUC5Tz3HyzN7zu/MRLgdDsgNQ+2QtOSLI0LFVn09ZL8ADtC6BTfhANIWXTlGTU1lkscjY/uog54y+xf3qTim0RabZ9SRL8R5H84QeNfERFUje7diyHTQaobnkJUdAIRfTCALdIhVSR1d9VqZVr9rpG0BetTu/wenw4RqKzlMnjndC0QBD2B0c7vRTbczQy9jCWMhZp+fJLDI+DWMbKf4ElBsHMM+DV9c+tKvpXxPfwbT/WL x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PSAP153MB0536.APCP153.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(451199015)(86362001)(110136005)(41300700001)(10290500003)(83380400001)(66446008)(76116006)(66946007)(66476007)(8676002)(4326008)(64756008)(66556008)(82950400001)(82960400001)(38100700002)(122000001)(33656002)(38070700005)(26005)(7696005)(6506007)(53546011)(107886003)(186003)(71200400001)(478600001)(2906002)(8936002)(316002)(52536014)(5660300002)(55016003)(8990500004)(9686003)(4744005);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?We1+kX8aN2xXKbjil0Tsf7lAyFDbv9xQUq7xPo5QNF7e6E12xZTp6gMUDodB?= =?us-ascii?Q?pmA8Gr0lrsNGo821mIMfqw6/ZtAfNQBP6h2nwWcfGnsRnJmxCqhSUmV72bPH?= =?us-ascii?Q?ojpqx2AQzp20mtKHs6cshUI0iUoYUbVkAvqz/03nBHiUx2LppxtlOSzOoMsV?= =?us-ascii?Q?aSTectAw1pSRYL33cYx9JtlMied6MJec6S+WRT/lEYf6csBtzpNNz7+TRQIK?= =?us-ascii?Q?gE/3f/RELwlnwxtRtGCtixyS+bUt7S1C69lcFjvBKEf1DXVacyeDiC+IkQXL?= =?us-ascii?Q?/gnk89YOPI8tVv7Fi3D0JItfe5+IPcK+WQknCUe9nu8rO1Wf8uJ7tDvJtVDA?= =?us-ascii?Q?mY4a8eLgyEQEvAIX54Z78r9wbNYIF81w7UbDic3SkvCcg6QVQxtI4HcQvAdU?= =?us-ascii?Q?SfBDJZcgCaf3Fjv6pFFTrLQIJ866z4ZHh6qU7R77PB+w/j8I/xm1QXFNaUSk?= =?us-ascii?Q?sSrmLyKsLU8fVA4b00l8RYAUbE9yZk4y9MaZKliFbMWPfD1YgFzcAZ7X1Fsi?= =?us-ascii?Q?6VDzxa8Y+keoAiPbXDear39oEGBAzG7SVuzrtIZ/7I2HCyKGbf1B8/FPkM//?= =?us-ascii?Q?jccgy93lNe8nnlKhzuEsWmc4MCsbpv4KfuqARic9Akenhip/3qLml46ncw7Z?= =?us-ascii?Q?b2dtoXFKJoQ+IEVIK7F1GE6BvlhrYpnZH8jjcQWW3AEOo4D3ZVIEZJ6VZQaL?= =?us-ascii?Q?ygX4P1GxTuxq/a0eGyWdOh3Vyv1xhB/qkKq0TUA8Wybjnm9i7rSV1usXhLjl?= =?us-ascii?Q?smBTU9kQuzkLkNkVMrzG1/OYGTCbo7QScjBX127P63yxSW6XJPb7mtxusk3G?= =?us-ascii?Q?LHbFMGJt0HVxxPg1U/SsIEo6zbSSZjQks8aWa0ytX7niAFUnqrLa1asdCr51?= =?us-ascii?Q?RD8/qc1TSbhUpuKrKx/gcuyMo4bGwW2XZVUq23y6LBs8590VxsueoAa84ItW?= =?us-ascii?Q?GQf3mJTgcKHJHVm1M2IdcLv7XqSqY4SuqWw3f3WQ1/J/uNIHPVKwQP1XLKQQ?= =?us-ascii?Q?AwOOODKN40FHOoxM3CwqvzZs9OMhZu9RqQNoH5i4ARiE+izTMOGQDRQfrQYz?= =?us-ascii?Q?gpUGfmxojGLtXT4URYtBEnrCRcrr2wAKQ8WFQhnRO5HCLy6hnmGodBX8AXrz?= =?us-ascii?Q?FdWWOHd74Zciqom4Fx6rYWDpv96IIR1+VM3986B67aBRl5MR/jHu6cl4yrET?= =?us-ascii?Q?Vpxow5jZv+I89PP1iHcbxGkL+Fkq2lKerlqHEvCEBMdA6kyxbejdokeV2EbK?= =?us-ascii?Q?4g7231cGaeiu8+UtJjAckYEHNnx+LEYrSu8jbgr2iViapZAPwJQHUkDCX3H5?= =?us-ascii?Q?Z8A8x4yno0QELwM5dnJwRmnwmBmRZJNZGL58v69kGkz1pzEYFP8ReugQiPJA?= =?us-ascii?Q?fYVQxTlC/0l4k3wWyHb2Tw+Sk4D34PG8q1qsWvap1dxZCZ9E1Q3Rp5cl181r?= =?us-ascii?Q?zn1t9D7FlVHyA1T+EohqIHYeTKIx89QK8pSpPwwgUDdzWnua/Awf6JhMlnj/?= =?us-ascii?Q?JvMCIUxVNcjUlMNIB9mBkznt6CBivb6YmkFR?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PSAP153MB0536.APCP153.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 61d64e9d-209b-45f2-3264-08daf2110ed1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2023 07:13:50.3146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2Pc+nIMOBkITKBXL3q+ylIYT0cI0D0TJ4OYXW6XrLG68B9VPF0QrTtpyZIc+UKmya6LQlU7hXZy2tpEtE9LlGzWwVlMctRJCkb2ZAYdbwFY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PSAP153MB0422 X-Spamd-Result: default: False [-10.00 / 15.00]; WHITELIST_SPF_DKIM(-3.00)[microsoft.com:d:+,microsoft.com:s:+]; DWL_DNSWL_MED(-2.00)[microsoft.com:dkim]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[microsoft.com,reject]; R_SPF_ALLOW(-0.20)[+ip4:52.100.0.0/14]; R_DKIM_ALLOW(-0.20)[microsoft.com:s=selector2]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org,freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:8075, ipnet:52.96.0.0/12, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[microsoft.com:+]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[52.101.128.26:from]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4Nr4tW4GsXz4Kxy X-Spamd-Bar: --------- X-ThisMailContainsUnwantedMimeParts: N > -----Original Message----- > From: Souradeep Chakrabarti > Sent: Saturday, January 7, 2023 8:24 PM > To: freebsd-arm@FreeBSD.org; Li-Wen Hsu > Cc: Wei Hu > Subject: MSI CPU affinity for ARM64 >=20 > Hi, > I am trying to understand how we can find the target CPU for MSI in ARM6= 4. > When looking at gic_v3 code I can see following: > gic_v3_bind_intr( ) does mapping to next incremental CPU but gic_v3_dist_= init( ) > does setup boot cpu as the target CPU for MSI interrupts. >=20 > If I need to find the CPU bound with a particular MSI interrupt, how we c= an do that? >=20 > Also is there a way get the the CPU id from the CPU affinity in ARM? >=20 > Thanks & Regards, > Souradeep [Souradeep]=20 Adding FreeBSD Hackers on the mail thread. From nobody Tue Jan 10 06:18:43 2023 X-Original-To: hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nrgcf2Cfvz2qnwY for ; Tue, 10 Jan 2023 06:18:58 +0000 (UTC) (envelope-from sahilpatidar60@gmail.com) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nrgcd1sSzz44nF for ; Tue, 10 Jan 2023 06:18:57 +0000 (UTC) (envelope-from sahilpatidar60@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=CJ3KZwV5; spf=pass (mx1.freebsd.org: domain of sahilpatidar60@gmail.com designates 2a00:1450:4864:20::236 as permitted sender) smtp.mailfrom=sahilpatidar60@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-x236.google.com with SMTP id y18so7833409ljk.11 for ; Mon, 09 Jan 2023 22:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=iogvr4VI9kaloM/9uLPF/ODY7uZ3aW+pI6Y0bcPh7IM=; b=CJ3KZwV5o9+EqXWnLVqr3+YEEui2YbOdga0GOuJUw4etU0tf1FtZSY4+wU3xM61EJI v2vtYjFfQ2HhXxeuTFBCCDvCIhQ12oN0fXVUUQuYDPhGTIrUQRGezZwuSWg+t9NrueIH YfCJ0yGl64Y9pzNmIMDuRNSfnasc8XhY1mG0FzrTjUh125RJDYhfmKhSxsTnhost45Ce o0CB3srKbLqQVIRUI7IXTYTdS4SPrNV8XokaGPQ8k/VbxsbWg1Z+DDlcLy4rh1dqrDc0 ClSAMMZ11QvhmrrgfMbO8WdltHHGVMRrgASBfsF0nq0nWTCgxIg+ZHe0l7ErHj0Y0XuR eUdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=iogvr4VI9kaloM/9uLPF/ODY7uZ3aW+pI6Y0bcPh7IM=; b=WJdBkWx+3dQ9HGOjwo+6gAhIOktBqsDMntSCLATxZ8+l+und9eV8woySy35BPGEZOb d05j+r6P5O0V/RiqVlD6Dxwl60Aju1Md4Nnq42ImKzwfpMmfwVfy5S0pTRH4OGZtM7VD bXD3m0P7VGFOFZBt2LHKSiJgFBOx/jDL83TqRcywwLZpRWDYUxHDpYrrI4KOBiNA4inl DdNDd4tLSL6wcLUbZGT+rRhf0Xx2PzN3gxLQGayXqsMSNMowlK14e1vjHBt4sqPdchaL 5hWRNRfZTsC1n0ZFQEBFVOwBra25b+4iOCTgOCE8KV70vigNvOeZxx/DBBA2aHlyO8mf dpyw== X-Gm-Message-State: AFqh2koSB4IQUyBby17vmiXrxn1MAvyEfCbkhwkN8SsH4Cuiw1bRr4nb PG8k7XWt0nbgGAlnqIULRj9r4BWux3I6ZSVKiHLQKEluTFs= X-Google-Smtp-Source: AMrXdXveh+tVXv/IEZ09J04JoFu8VgdlYFluXc2R+DL9rncpWtmYM9wcLNh/wxHNTmzGd94OeMCod/yU2ZEyVlLlscA= X-Received: by 2002:a2e:bd01:0:b0:27f:c69a:11b7 with SMTP id n1-20020a2ebd01000000b0027fc69a11b7mr3979686ljq.111.1673331535276; Mon, 09 Jan 2023 22:18:55 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: sahil patidar Date: Tue, 10 Jan 2023 11:48:43 +0530 Message-ID: Subject: kernel control flow integrity (kcfi) To: hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-2.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.03)[0.032]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::236:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Nrgcd1sSzz44nF X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N hello Hackers, I want to work on the Freebsd idealist project KCFI (kernel control flow integrity), I am new in this community and want to be involved in the Freebsd community and become a contributor. so I want to know if this project is already done or if someone is working on it. if no one working on this project so how can I start work on this project? I am interested in compiler or kernel dev. thanks From nobody Tue Jan 10 18:45:24 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns0BB6Y9dz2sQV6 for ; Tue, 10 Jan 2023 18:45:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns0B951xbz4DRp for ; Tue, 10 Jan 2023 18:45:37 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-ua1-f51.google.com with SMTP id z13so2014687uav.3 for ; Tue, 10 Jan 2023 10:45:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wJcE7a3O1D/9Yz9caBtDZEyRxHrl4/2YxRCVTKD/mv8=; b=3NIgJBS2rrRhPNtQEwVHBwG57CX+Zku+czqQilw42T2RPtOu8OwkQ7BplWcQeuo8La BTChrowBM0x+00X5FHSR54EpYm7fjKjoxZ6RHY5PWbgzNRWEeXz08jmOE0oM71S02Gib 5vJI1QOAJCcqIVDw8FlBL9zyA1TxIVk9xYV9Dszzq/HeUxLrSYFZ/+UlNNzKeZQWNLGj bMQPkB7Wsbw9j7O5upWk8PBsUWC9NYhqwtz0SpinZkuXqAqG+XepC5bFRGIabyslYrTP 5cl1FwOhF8DgDqLot3/HUAOIWvMecvYHbGM/pI8bc6qkbzpHWl6qApgWcZx7oujE43ml /+rA== X-Gm-Message-State: AFqh2kqEM2Wr8Meiy4zXXepYKCqLRxazQLJGkpoD1cqRBf/YTLvQcris BaLCCRP/fysRCAEBTHpG7zmv/CqyMOM+Fc+aFo0iS/VS X-Google-Smtp-Source: AMrXdXtC1XN11Q6mXTnHqHirnr4a9omZY9cFHJYX39EVB2KhUyBpmJNjyWSjh0TFjojzaoptNDUM1Ws3Frm4FZs3E8U= X-Received: by 2002:ab0:58c2:0:b0:419:d3f0:d6a6 with SMTP id r2-20020ab058c2000000b00419d3f0d6a6mr7456111uac.111.1673376336064; Tue, 10 Jan 2023 10:45:36 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Tue, 10 Jan 2023 11:45:24 -0700 Message-ID: Subject: libcasper and async-signal-safety To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-1.25 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.75)[0.746]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.51:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.51:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[asomers]; RCVD_COUNT_TWO(0.00)[2]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; TO_DOM_EQ_FROM_DOM(0.00)[] X-Rspamd-Queue-Id: 4Ns0B951xbz4DRp X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Normally when a multithreaded process forks, the child is restricted to only calling async-signal-safe functions until it exec()s.. Otherwise, bad stuff could happen like deadlocks on mutexes that will never be released. The cap_init(3) function, used to create Casper services, forks (and then its child forks again and again and again). But there's nothing in the libcasper_service(3) man page about async-signal-safety. I assume that this is just an oversight. After all, all of the existing programs in the base system that use casper are single-threaded. But it's a limitation that ought to be documented in the cap_init(3) man page, right? Or am I missing something? -Alan From nobody Tue Jan 10 18:55:15 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns0Pb0VyKz2sRXd for ; Tue, 10 Jan 2023 18:55:31 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns0PZ5x8hz4FTZ; Tue, 10 Jan 2023 18:55:30 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-f180.google.com with SMTP id n5so12992851ljc.9; Tue, 10 Jan 2023 10:55:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QU3yXC5bdehYb6KG09CCJYq480EfnpPuTepGqyiXkuk=; b=AdnTdSusPYUilltlkLdIGyEKhtdXz8hYlACSyWKlYyJRpKXXKq4V3iVp+66x4803Co h/2617bsoRGF7zTETqA4aEsUNxVh4PtIeQZ8BOaVotwGANeL2mJyC4yyFw7sMhV06D8k XofQSlFDY7FeBxkuc8an92VoT8quVcY35T0LDJGdpG4w8bX/LkOJG3t1CwymIWCXILpM BESOWlkvtIp8JLj2o0NHZXQpjmKaxshvsyOr1hYX0jdHJoASJkmG4EGueeiwa+q1KZd5 aIaboi3UiXW41WuzYdnAprEQr75sy0WFoXXgMB5CQivWwe3319ilVOa2CJOd5IUpcpoA b/KA== X-Gm-Message-State: AFqh2kr8onIylIfflrRgLrMpHcd4aNgxR2WI8hkL2wJNjSzQp+hrEskp 04dkkx87hvIGfTX7ihCFALZxQHiAHW5XP4+u2p90p27k X-Google-Smtp-Source: AMrXdXt6oXN0ddo/WUL+mBmOPsrQD2wWElfsr2KwZy1A3S13Yxj/2g/PxbZUIpjNVISzAfmTGt9AWk5SV0DE8XrzpaU= X-Received: by 2002:a2e:b88b:0:b0:288:2375:e931 with SMTP id r11-20020a2eb88b000000b002882375e931mr35145ljp.381.1673376928044; Tue, 10 Jan 2023 10:55:28 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 10 Jan 2023 13:55:15 -0500 Message-ID: Subject: Re: libcasper and async-signal-safety To: Alan Somers Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Ns0PZ5x8hz4FTZ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 10 Jan 2023 at 13:45, Alan Somers wrote: > > I assume that this is just an oversight. After all, all of the > existing programs in the base system that use casper are > single-threaded. But it's a limitation that ought to be documented in > the cap_init(3) man page, right? Or am I missing something? I don't think you're missing anything, and this just needs to be explicitly documented. The forking behaviour of Casper services is perhaps an internal implementation detail, but the limitations it imposes on the consumer should be clear. From nobody Tue Jan 10 23:21:42 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6K02cdgz2qllb for ; Tue, 10 Jan 2023 23:21:56 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns6Jz2j9vz3Mjf for ; Tue, 10 Jan 2023 23:21:55 +0000 (UTC) (envelope-from jake@technologyfriends.net) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=KQORGj2+; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2a00:1450:4864:20::12d) smtp.mailfrom=jake@technologyfriends.net; dmarc=none Received: by mail-lf1-x12d.google.com with SMTP id bu8so20853775lfb.4 for ; Tue, 10 Jan 2023 15:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3sV8xiiz83LsS/iCbZGpNkWtsmy1egmXatndWJ6Ep4Y=; b=KQORGj2++s4XuHyiOIWq8rzJyHWC/IGWKZG63dJVgT9ODdnyc+emv6EGFivKcZZUFU 0gbTZHiTKRk8ByB8VdWeb3Ex8Q/BxmXd0N2shIsECEf8z//B+WoGWCYiDUEAFDkZp1KY rEjZT4loZe6a6sDzgA+lJTOycIj4/SFcscLM1m0MT+1vhN3G6M8Cro7+fBcEmHh8MhA0 eFB+Ro1mWmEgKp59P2tGiUiSnxhd5yc7rBUz/3AvzFGzo2qkifoZZMwXGRQZA+Gik3PX u2GNLXkA9q3S7yE2uzzenU4plDaLU9j/suhPdMKPXqIEWR3xs5GhBeYIeOr/BX1/LMrQ PKcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3sV8xiiz83LsS/iCbZGpNkWtsmy1egmXatndWJ6Ep4Y=; b=WjzIJ7xSGiRX/QlekqQUDAuiePwRjJnbfLe3Uy5BzE4rGS3lFjE+mfrpkApjneQam7 6/tHzqG9ocIQe+LgApQX1ml++w8e65wArdqqLKIOwkZYvqJ6VJmyufkF29LWUDYP218d Ccyl0OFS6PkDK0jIolBiBTLMX2jFcUsTsVrN1hOkPnpKDsDuGHk9iWTmM+FLeYn9s1dW ht12gvpSAezgbUgMZQY5rw7FdWbjjtyGXsrD0QGnKwdJBe+kcY+01KbebY1rwmIauM2C YKlWDTsRzPfqqgBA2zuuscCnPckCU03H4NKrVKvoVOXvFVwTbY6riHhKgOJhxThgrRdz dOgg== X-Gm-Message-State: AFqh2kpUgb2MR7t/Lz2yL4IkV2QOGmBw+r/u0YSLix63Hb5XRJIC/OEA TbBdP7X5TsF26mA2Mi7nfDbik921gy3V47KWeI1dibSd0/OgoNF/v1o= X-Google-Smtp-Source: AMrXdXvwXDA9Ib+xrslMzvi7WVnhehTdUFc+A/luo1uDZwF21kwrJtTNO2iyFgbrl55f7UjAIW46vDZUyMUFxpayq4Q= X-Received: by 2002:a05:6512:3a86:b0:4cc:7ecb:32af with SMTP id q6-20020a0565123a8600b004cc7ecb32afmr928906lfu.393.1673392913048; Tue, 10 Jan 2023 15:21:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Jake Freeland Date: Tue, 10 Jan 2023 17:21:42 -0600 Message-ID: Subject: Syscalls: eventfd and timerfd To: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000027024205f1f126b2" X-Spamd-Result: default: False [-2.09 / 15.00]; AUTH_NA_OR_FAIL(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; ARC_NA(0.00)[]; DMARC_NA(0.00)[technologyfriends.net]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jake]; DKIM_TRACE(0.00)[technologyfriends.net:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Ns6Jz2j9vz3Mjf X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --00000000000027024205f1f126b2 Content-Type: text/plain; charset="UTF-8" Hi there, I am currently working on moving the linux_compat implementation of timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall similar to what was done for eventfd. This is my first time implementing a syscall, so I have been following the eventfd implementation as a reference. I noticed that the eventfd syscall entries are absent from sys/kern/syscalls.master and I am not sure why. Was eventfd never formally added as a syscall entry or am I missing something? I was planning on adding timerfd entries to syscalls.master, but now I am unsure how to proceed. I apologize for my ignorance. This process is new to me. Thank you, Jake Freeland --00000000000027024205f1f126b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

I am currently working on= moving the linux_compat implementation of
timerfd (in sys/compat= /linux/linux_event.c) into its own FreeBSD syscall
similar to wha= t was done for eventfd. This is my first time implementing
a sysc= all, so I have been following the eventfd implementation as a
ref= erence. I noticed that the eventfd syscall entries are absent from
sys/kern/syscalls.master and I am not sure why. Was eventfd never
formally added as a syscall entry or am I missing something? I was
planning on adding timerfd entries to syscalls.master, but now I a= m
unsure how to proceed.

I apologize for= my ignorance. This process is new to me.

Thank yo= u,
Jake Freeland
--00000000000027024205f1f126b2-- From nobody Tue Jan 10 23:29:35 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6V40zT3z2qn1l for ; Tue, 10 Jan 2023 23:29:48 +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 4Ns6V32FJYz3NTs for ; Tue, 10 Jan 2023 23:29:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 30ANTak8099609 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 11 Jan 2023 01:29:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 30ANTak8099609 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 30ANTZnI099606; Wed, 11 Jan 2023 01:29:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Jan 2023 01:29:35 +0200 From: Konstantin Belousov To: Jake Freeland Cc: freebsd-hackers@freebsd.org Subject: Re: Syscalls: eventfd and timerfd Message-ID: References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Ns6V32FJYz3NTs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, Jan 10, 2023 at 05:21:42PM -0600, Jake Freeland wrote: > Hi there, > > I am currently working on moving the linux_compat implementation of > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall > similar to what was done for eventfd. This is my first time implementing > a syscall, so I have been following the eventfd implementation as a > reference. I noticed that the eventfd syscall entries are absent from > sys/kern/syscalls.master and I am not sure why. Was eventfd never > formally added as a syscall entry or am I missing something? I was > planning on adding timerfd entries to syscalls.master, but now I am > unsure how to proceed. There is no eventfd(2) in FreeBSD. There is __specialfd(2) syscall #577, which dispatches based on type. The libc wrapper provides eventfd(3) API. From nobody Tue Jan 10 23:30:52 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6WL5LdGz2qn2Q for ; Tue, 10 Jan 2023 23:30:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns6WL3SjFz3PWr for ; Tue, 10 Jan 2023 23:30:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oi1-x234.google.com with SMTP id o66so11457956oia.6 for ; Tue, 10 Jan 2023 15:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aBPRip8WGRPQ2/qNQYdBguGWqs9EwvYYvO5MtwasnLs=; b=DlCBsgmZT+iwskspSgWs/DHsQrg5w8BzsS1j6y6cE/Gg8GKmYaBju/h+8L1UoAzOst xTqAr49vCcK7fkLLue79ykwopnGYgtvLRyocjl8yOIvMHhDBFpVtPP0W9HccEqh6oQOe M3NOEhOH6XVo9BfEiWIwQtLvws7C66UVgfj5RtnfMbAaTwodn3LzN6TPx9xVrXbm5/DJ hI3tgYIYBYYF0aFKgfd1JOZiopV84g6TrRyXFtJAVSITHSZvZW35cdG24G3E9R1FMtVC pja24dcTHUZim9nPwoL/TQVVj8imyGL3rFuj9zJVqJunv9nInWMfwZL3GH9wYE0z60XX N/rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aBPRip8WGRPQ2/qNQYdBguGWqs9EwvYYvO5MtwasnLs=; b=ASzvOvTGsHLO9t1VLpvVF0YjKjAHpzvYTqoi2nUKGam3GmD+WZehTTJlE3LhY+llFB 4FSnwnemVjhGkQnN6P0vwM/u+mWMlranDD75kezeuI8DGSFxyJ0dCOCwziRlAggGRH6m nvdHCoFpFsV5HWnstoojhceO0wzkjlUcb0480FJSaXQTyxVkRAHn6ZFK3Ne9EIakHxcV yzjmlYMtPS4jZZ6kHLGjBUwqD81ZJDu/hndFGuGMmhlrtTd10HhyZ6qms3qW6xELUKOd QDMkJW7EcsoOnDncvZR8ejIkO0Vu4Llko2h3t9X+X6aA04vC66eZu8d/BYbVh6Au/vyG iqwg== X-Gm-Message-State: AFqh2krVRKrKs4hF8jA/E/uNzMIJyyJqDVABUNwLMu7MsE9HRDaLHICW uRjrLeqtWyUoqfxhF63zwtyDYU7QDtSk03vlYuY= X-Google-Smtp-Source: AMrXdXvriTfxKjhCHBHCL4POxxGAm8uvQpbzI6xEr+pkQJ9okCghN2FEI/iyCSns4CE7lWH1Uu01Ifok4tj92pQQzvc= X-Received: by 2002:a05:6808:aaf:b0:35e:4337:35a8 with SMTP id r15-20020a0568080aaf00b0035e433735a8mr2927066oij.81.1673393453633; Tue, 10 Jan 2023 15:30:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:77d5:0:b0:491:8368:9bdd with HTTP; Tue, 10 Jan 2023 15:30:52 -0800 (PST) In-Reply-To: References: From: Mateusz Guzik Date: Wed, 11 Jan 2023 00:30:52 +0100 Message-ID: Subject: Re: Syscalls: eventfd and timerfd To: Jake Freeland Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Ns6WL3SjFz3PWr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N It is added with a non-standard entry point. If you git log -p sys/kern/sys_eventfd.c you will see: commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9 Author: Konstantin Belousov Date: Wed Dec 23 16:14:04 2020 +0200 Expose eventfd in the native API/ABI using a new __specialfd syscall then if you git grep __specialfd: lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD, &args, sizeof(args))); lib/libc/include/libc_private.h:int __sys___specialfd(int, const void *, __size_t); sys/compat/freebsd32/freebsd32_syscall.h:#define FREEBSD32_SYS___specialfd 577 sys/compat/freebsd32/freebsd32_syscalls.c: "__specialfd", /* 577 = __specialfd */ sys/compat/freebsd32/freebsd32_sysent.c: { .sy_narg = AS(__specialfd_args), .sy_call = (sy_call_t *)sys___specialfd, .sy_auevent = AUE_SPECIALFD, .sy_flags = SYF_CAPENABLED, .sy_thrcnt = SY_THR_STATIC }, /* 577 = __specialfd */ sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ sys/compat/freebsd32/freebsd32_systrace_args.c: struct __specialfd_args *p = params; sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ sys/kern/init_sysent.c: { .sy_narg = AS(__specialfd_args), .sy_call = (sy_call_t *)sys___specialfd, .sy_auevent = AUE_SPECIALFD, .sy_flags = SYF_CAPENABLED, .sy_thrcnt = SY_THR_STATIC }, /* 577 = __specialfd */ sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct __specialfd_args *args) sys/kern/syscalls.c: "__specialfd", /* 577 = __specialfd */ sys/kern/syscalls.master: int __specialfd( sys/kern/systrace_args.c: /* __specialfd */ sys/kern/systrace_args.c: struct __specialfd_args *p = params; sys/kern/systrace_args.c: /* __specialfd */ sys/kern/systrace_args.c: /* __specialfd */ sys/sys/syscall.h:#define SYS___specialfd 577 sys/sys/syscall.mk: __specialfd.o \ sys/sys/sysproto.h:struct __specialfd_args { sys/sys/sysproto.h:int sys___specialfd(struct thread *, struct __specialfd_args *); sys/sys/sysproto.h:#define SYS_AUE___specialfd AUE_SPECIALFD On 1/11/23, Jake Freeland wrote: > Hi there, > > I am currently working on moving the linux_compat implementation of > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall > similar to what was done for eventfd. This is my first time implementing > a syscall, so I have been following the eventfd implementation as a > reference. I noticed that the eventfd syscall entries are absent from > sys/kern/syscalls.master and I am not sure why. Was eventfd never > formally added as a syscall entry or am I missing something? I was > planning on adding timerfd entries to syscalls.master, but now I am > unsure how to proceed. > > I apologize for my ignorance. This process is new to me. > > Thank you, > Jake Freeland > -- Mateusz Guzik From nobody Tue Jan 10 23:39:53 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6jm4mQLz2qp86 for ; Tue, 10 Jan 2023 23:39:56 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns6jm2tGNz3QyK for ; Tue, 10 Jan 2023 23:39:56 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x636.google.com with SMTP id hw16so20887940ejc.10 for ; Tue, 10 Jan 2023 15:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iemIRVgn08nwebl8lm54yjwsDfrP4+FrfEtMa69nMUM=; b=LAmK5NH5V3fJPJNxtqail+gdq77gPVw4AZ22kdGCaOc8jij7oQTPMc+4cjhrwJhOfk FJb9CPJxgdSQMVo/+102ZNHYf7GihImpCCqG+fVaSkREihbUli3vvM55PJcf3R51pGlw /lFD3mRBsEq9EGpCRJtu/DG+WoOhKFhvr1ddaAZsEBKnxaH1qlbfnF0gtl95nk4fhS5o bSNph0U8sb/z53JE2r7MKhmFtyfGP0h8jD8ifg2wgkSMVSVJ2nh8m+W7JdmjystXsbyf tbtYCp7f3o8zMbzRAuEn9EdmCiYM3bN4CUExQFTbj264x9hqpzGCb1Z9iHY7TX+IsFaR WFVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iemIRVgn08nwebl8lm54yjwsDfrP4+FrfEtMa69nMUM=; b=cAhzt36RXZAms2ZHBathR5YT1OLLI2ePNtedGfq/T/ZSVgU72XgpJ2kJJHsrAhzCfY +YDzQVjVCS4QPWZoQFll1KpAWRIn/lgI1nozk0zsgA+yS5PH/o5DX8c8UVqY0ets3TxS cB5G7lmE+IHcclGc8K7HU4uFJ668kte3Q2NHufNeyV4cdS5sHeM0+doPt4Ss52KPeUN6 xZyqcSAqaMfKS+sPcpW5a/I3fn6LXrkfYd+xL6eoReVQWOR8UwszC6dbT72u2Sqxb2B+ 5uDcxT9wzmuF0g0EQRDgFmGiYFUMXkYbCMxBLByvd8Qllajrm3jmaOSA3E+ovqXv36Ec 2gKw== X-Gm-Message-State: AFqh2krun3i03KwFfOan8QswziD6FpxgJquqjjh27lMEQAPKiyXrHsuT d2TVogHgMprQ30WgLQlpuNRSdgg3JFZbT7E7NEc= X-Google-Smtp-Source: AMrXdXsiEp6LzyAyPcnVZKQop0ITYjIetTqeyIyC4lwZB0wuAg354TLfYxyXs3UjZH88l+JLWIR4O72dpD3h0xEwi70= X-Received: by 2002:a17:906:e2c4:b0:829:e4f0:bf2b with SMTP id gr4-20020a170906e2c400b00829e4f0bf2bmr4708019ejb.389.1673393993908; Tue, 10 Jan 2023 15:39:53 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a17:906:f88c:b0:7c1:ed:5065 with HTTP; Tue, 10 Jan 2023 15:39:53 -0800 (PST) In-Reply-To: References: From: Rob Wing Date: Tue, 10 Jan 2023 14:39:53 -0900 Message-ID: Subject: Re: Syscalls: eventfd and timerfd To: Mateusz Guzik Cc: Jake Freeland , "freebsd-hackers@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000093858505f1f16606" X-Rspamd-Queue-Id: 4Ns6jm2tGNz3QyK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000093858505f1f16606 Content-Type: text/plain; charset="UTF-8" You might also be interested in checking out Brooks Davis' talk on adding syscalls: https://www.bsdcan.org/events/bsdcan_2022/sessions/session/73/slides/35/so-you-want-to-add-a-syscall.pdf https://youtu.be/_5LF_0GIpi8 On Tuesday, January 10, 2023, Mateusz Guzik wrote: > It is added with a non-standard entry point. > > If you git log -p sys/kern/sys_eventfd.c you will see: > > commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9 > Author: Konstantin Belousov > Date: Wed Dec 23 16:14:04 2020 +0200 > > Expose eventfd in the native API/ABI using a new __specialfd syscall > > then if you git grep __specialfd: > lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD, > &args, sizeof(args))); > lib/libc/include/libc_private.h:int __sys___specialfd(int, > const void *, __size_t); > sys/compat/freebsd32/freebsd32_syscall.h:#define > FREEBSD32_SYS___specialfd 577 > sys/compat/freebsd32/freebsd32_syscalls.c: "__specialfd", > /* 577 = __specialfd */ > sys/compat/freebsd32/freebsd32_sysent.c: { .sy_narg = > AS(__specialfd_args), .sy_call = (sy_call_t *)sys___specialfd, > .sy_auevent = AUE_SPECIALFD, .sy_flags = SYF_CAPENABLED, .sy_thrcnt = > SY_THR_STATIC }, /* 577 = __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: struct > __specialfd_args *p = params; > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/kern/init_sysent.c: { .sy_narg = AS(__specialfd_args), .sy_call = > (sy_call_t *)sys___specialfd, .sy_auevent = AUE_SPECIALFD, .sy_flags = > SYF_CAPENABLED, .sy_thrcnt = SY_THR_STATIC }, /* 577 = __specialfd > */ > sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct > __specialfd_args *args) > sys/kern/syscalls.c: "__specialfd", /* 577 = > __specialfd */ > sys/kern/syscalls.master: int __specialfd( > sys/kern/systrace_args.c: /* __specialfd */ > sys/kern/systrace_args.c: struct __specialfd_args *p = > params; > sys/kern/systrace_args.c: /* __specialfd */ > sys/kern/systrace_args.c: /* __specialfd */ > sys/sys/syscall.h:#define SYS___specialfd 577 > sys/sys/syscall.mk: __specialfd.o \ > sys/sys/sysproto.h:struct __specialfd_args { > sys/sys/sysproto.h:int sys___specialfd(struct thread *, struct > __specialfd_args *); > sys/sys/sysproto.h:#define SYS_AUE___specialfd AUE_SPECIALFD > > On 1/11/23, Jake Freeland wrote: > > Hi there, > > > > I am currently working on moving the linux_compat implementation of > > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall > > similar to what was done for eventfd. This is my first time implementing > > a syscall, so I have been following the eventfd implementation as a > > reference. I noticed that the eventfd syscall entries are absent from > > sys/kern/syscalls.master and I am not sure why. Was eventfd never > > formally added as a syscall entry or am I missing something? I was > > planning on adding timerfd entries to syscalls.master, but now I am > > unsure how to proceed. > > > > I apologize for my ignorance. This process is new to me. > > > > Thank you, > > Jake Freeland > > > > > -- > Mateusz Guzik > > --00000000000093858505f1f16606 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You might also be interested in checking out Brooks Davis' talk on addi= ng syscalls:




On Tuesday, January 10, 2023, Mateusz Guzik <mjguzik@gmail.com> wrote:
It is added with a non-standard entry point.

If you git log -p sys/kern/sys_eventfd.c you will see:

commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:=C2=A0 =C2=A0Wed Dec 23 16:14:04 2020 +0200

=C2=A0 =C2=A0 Expose eventfd in the native API/ABI using a new __specialfd = syscall

then if you git grep __specialfd:
lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD, &args, sizeof(args)));
lib/libc/include/libc_private.h:int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__sys___specialfd(int,
const void *, __size_t);
sys/compat/freebsd32/freebsd32_syscall.h:#define
FREEBSD32_SYS___specialfd=C2=A0 =C2=A0 =C2=A0 =C2=A0577
sys/compat/freebsd32/freebsd32_syscalls.c:=C2=A0 =C2=A0 =C2=A0 "_= _specialfd",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_sysent.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 { = .sy_narg =3D
AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd,
.sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D SYF_CAPENABLED, .sy_thrcnt =3D=
SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0struct
__specialfd_args *p =3D params;
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/kern/init_sysent.c: { .sy_narg =3D AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd, .sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D<= br> SYF_CAPENABLED, .sy_thrcnt =3D SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __s= pecialfd
*/
sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct
__specialfd_args *args)
sys/kern/syscalls.c:=C2=A0 =C2=A0 "__specialfd",=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/kern/syscalls.master:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0int __specialfd(
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0struct __specialfd_args *p =3D params;
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/sys/syscall.h:#define=C2=A0 =C2=A0 =C2=A0 =C2=A0SYS___specialfd 577
sys/sys/syscall.mk:=C2= =A0 =C2=A0 =C2=A0__specialfd.o \
sys/sys/sysproto.h:struct __specialfd_args {
sys/sys/sysproto.h:int=C2=A0 sys___specialfd(struct thread *, struct
__specialfd_args *);
sys/sys/sysproto.h:#define=C2=A0 =C2=A0 =C2=A0 SYS_AUE___specialfd=C2=A0 = =C2=A0 =C2=A0AUE_SPECIALFD

On 1/11/23, Jake Freeland <jake@technologyfriends.net> wrote:
> Hi there,
>
> I am currently working on moving the linux_compat implementation of > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD = syscall
> similar to what was done for eventfd. This is my first time implementi= ng
> a syscall, so I have been following the eventfd implementation as a > reference. I noticed that the eventfd syscall entries are absent from<= br> > sys/kern/syscalls.master and I am not sure why. Was eventfd never
> formally added as a syscall entry or am I missing something? I was
> planning on adding timerfd entries to syscalls.master, but now I am > unsure how to proceed.
>
> I apologize for my ignorance. This process is new to me.
>
> Thank you,
> Jake Freeland
>


--
Mateusz Guzik <mjguzik gm= ail.com>

--00000000000093858505f1f16606-- From nobody Tue Jan 10 23:40:14 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6kM2qJKz2qp6G for ; Tue, 10 Jan 2023 23:40:27 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns6kM2LvQz3h8b for ; Tue, 10 Jan 2023 23:40:27 +0000 (UTC) (envelope-from jake@technologyfriends.net) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12d.google.com with SMTP id j17so20932268lfr.3 for ; Tue, 10 Jan 2023 15:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+CwdXId/S5Y3a8ovCRx6YZCYBSgRc46mit26y6fvjSM=; b=GuYvBKixcYcyxY+19hXhX5kW4WBvfBIX54wItTetRTRRYSznnWI6Q4Vny9e/8tbQnZ qAP0D4BPfG69PhX8/W9HfhSNPhMA2YRezbkSb3w5kuhi8Z4IoKZSV8KhBjOAmweFL60+ QX/gTU4dUSb0CmvPpEgCf/toEedZ14WToKMA3v7ojkM+c6GCAgEKM+o8Bd3A9VXH7m3E 3Uk+TfxBMpI7FsL0Wb8BWiWMUjq3+KasyXt5n7GSLwlzwJ00I3uU+6Qk1E9qRlQ/8niw b7jrKItyh2KB72gfCBGak+EqsmAcXq3yb9dDY1hYzcGIaF/nlOcASPzZ9J0GUGEVgvNa EO5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+CwdXId/S5Y3a8ovCRx6YZCYBSgRc46mit26y6fvjSM=; b=DeAKCuefac+s2jzHtD0ofEDc5CbvWZ7NYVRdIgG+RGYWX9KGajKnW6coeFsY6KxA5s yUObftvV0p+V0EbKg6PoNRK5l8Qj3EMDVdfq1zmpOr9HizKuuVOo1ADR2ntkvw83nM5q 55qa/YfG/3093vpmb+sM0rlQnk7ER99VnUIOJpLFiTYXAehoE/avde+7fQH51Emt9qWl 0pPK+GxhPoySUFewU8OzSgSyQvpGqwpA75HTVUM8ANUjQEeMOkG9sJSsQZW/lmwdb97Z TRLjwOxUDF8klZc08ilbw2H/KFxEn2ySNQuSDp0UM7DG0PgsbP4jCm1hoebZPJFEo/2p rbUg== X-Gm-Message-State: AFqh2kopQX+aApR5rT4eRT2+hvps4zXhb5Zu/apeYkU/hAaNaTGZ/QZ0 DoKxPQq1MNoy8fUcA1wDoWMxlg5UlCILN5feg4RPbOnub6MDW5QO X-Google-Smtp-Source: AMrXdXuVP4r1gWrdfqUQUWSSXDHjCkLMG/eUP9OcZ/+y5ry/9UrfLb6qFyudyYDaRjhPyjFM3rXohtWcg/5utCpqeM8= X-Received: by 2002:ac2:48bb:0:b0:4b1:753b:e677 with SMTP id u27-20020ac248bb000000b004b1753be677mr2762998lfg.407.1673394025646; Tue, 10 Jan 2023 15:40:25 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Tue, 10 Jan 2023 17:40:14 -0600 Message-ID: Subject: Re: Syscalls: eventfd and timerfd To: Mateusz Guzik Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000077e4cf05f1f16840" X-Rspamd-Queue-Id: 4Ns6kM2LvQz3h8b X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000077e4cf05f1f16840 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 10, 2023 at 5:30 PM Mateusz Guzik wrote: > It is added with a non-standard entry point. > > If you git log -p sys/kern/sys_eventfd.c you will see: > Thanks. This pointed me in the right direction. That commit contains almost everything I need to continue. Jake Freeland > > commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9 > Author: Konstantin Belousov > Date: Wed Dec 23 16:14:04 2020 +0200 > > Expose eventfd in the native API/ABI using a new __specialfd syscall > > then if you git grep __specialfd: > lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD, > &args, sizeof(args))); > lib/libc/include/libc_private.h:int __sys___specialfd(int, > const void *, __size_t); > sys/compat/freebsd32/freebsd32_syscall.h:#define > FREEBSD32_SYS___specialfd 577 > sys/compat/freebsd32/freebsd32_syscalls.c: "__specialfd", > /* 577 = __specialfd */ > sys/compat/freebsd32/freebsd32_sysent.c: { .sy_narg = > AS(__specialfd_args), .sy_call = (sy_call_t *)sys___specialfd, > .sy_auevent = AUE_SPECIALFD, .sy_flags = SYF_CAPENABLED, .sy_thrcnt = > SY_THR_STATIC }, /* 577 = __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: struct > __specialfd_args *p = params; > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ > sys/kern/init_sysent.c: { .sy_narg = AS(__specialfd_args), .sy_call = > (sy_call_t *)sys___specialfd, .sy_auevent = AUE_SPECIALFD, .sy_flags = > SYF_CAPENABLED, .sy_thrcnt = SY_THR_STATIC }, /* 577 = __specialfd > */ > sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct > __specialfd_args *args) > sys/kern/syscalls.c: "__specialfd", /* 577 = > __specialfd */ > sys/kern/syscalls.master: int __specialfd( > sys/kern/systrace_args.c: /* __specialfd */ > sys/kern/systrace_args.c: struct __specialfd_args *p = > params; > sys/kern/systrace_args.c: /* __specialfd */ > sys/kern/systrace_args.c: /* __specialfd */ > sys/sys/syscall.h:#define SYS___specialfd 577 > sys/sys/syscall.mk: __specialfd.o \ > sys/sys/sysproto.h:struct __specialfd_args { > sys/sys/sysproto.h:int sys___specialfd(struct thread *, struct > __specialfd_args *); > sys/sys/sysproto.h:#define SYS_AUE___specialfd AUE_SPECIALFD > > On 1/11/23, Jake Freeland wrote: > > Hi there, > > > > I am currently working on moving the linux_compat implementation of > > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall > > similar to what was done for eventfd. This is my first time implementing > > a syscall, so I have been following the eventfd implementation as a > > reference. I noticed that the eventfd syscall entries are absent from > > sys/kern/syscalls.master and I am not sure why. Was eventfd never > > formally added as a syscall entry or am I missing something? I was > > planning on adding timerfd entries to syscalls.master, but now I am > > unsure how to proceed. > > > > I apologize for my ignorance. This process is new to me. > > > > Thank you, > > Jake Freeland > > > > > -- > Mateusz Guzik > --00000000000077e4cf05f1f16840 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2023 at 5:30 PM Mateusz G= uzik <mjguzik@gmail.com> wro= te:
It is added with a non-standard entry point.

If you git log -p sys/kern/sys_eventfd.c you will see:

Thanks. This pointed me in the right=C2=A0direction. That c= ommit contains
almost everything I need to continue.
Jake Freeland
=C2=A0

commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:=C2=A0 =C2=A0Wed Dec 23 16:14:04 2020 +0200

=C2=A0 =C2=A0 Expose eventfd in the native API/ABI using a new __specialfd = syscall

then if you git grep __specialfd:
lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD,
&args, sizeof(args)));
lib/libc/include/libc_private.h:int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__sys___specialfd(int,
const void *, __size_t);
sys/compat/freebsd32/freebsd32_syscall.h:#define
FREEBSD32_SYS___specialfd=C2=A0 =C2=A0 =C2=A0 =C2=A0577
sys/compat/freebsd32/freebsd32_syscalls.c:=C2=A0 =C2=A0 =C2=A0 "__spec= ialfd",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_sysent.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 { .sy_n= arg =3D
AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd,
.sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D SYF_CAPENABLED, .sy_thrcnt =3D=
SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0struct
__specialfd_args *p =3D params;
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/kern/init_sysent.c: { .sy_narg =3D AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd, .sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D<= br> SYF_CAPENABLED, .sy_thrcnt =3D SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __s= pecialfd
*/
sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct
__specialfd_args *args)
sys/kern/syscalls.c:=C2=A0 =C2=A0 "__specialfd",=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/kern/syscalls.master:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0int __specialfd(
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0struct __specialfd_args *p =3D params;
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/sys/syscall.h:#define=C2=A0 =C2=A0 =C2=A0 =C2=A0SYS___specialfd 577
sys/sys/= syscall.mk:=C2=A0 =C2=A0 =C2=A0__specialfd.o \
sys/sys/sysproto.h:struct __specialfd_args {
sys/sys/sysproto.h:int=C2=A0 sys___specialfd(struct thread *, struct
__specialfd_args *);
sys/sys/sysproto.h:#define=C2=A0 =C2=A0 =C2=A0 SYS_AUE___specialfd=C2=A0 = =C2=A0 =C2=A0AUE_SPECIALFD

On 1/11/23, Jake Freeland <jake@technologyfriends.net> wrote:
> Hi there,
>
> I am currently working on moving the linux_compat implementation of > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD sysca= ll
> similar to what was done for eventfd. This is my first time implementi= ng
> a syscall, so I have been following the eventfd implementation as a > reference. I noticed that the eventfd syscall entries are absent from<= br> > sys/kern/syscalls.master and I am not sure why. Was eventfd never
> formally added as a syscall entry or am I missing something? I was
> planning on adding timerfd entries to syscalls.master, but now I am > unsure how to proceed.
>
> I apologize for my ignorance. This process is new to me.
>
> Thank you,
> Jake Freeland
>


--
Mateusz Guzik <mjguzik gmail.com>
--00000000000077e4cf05f1f16840-- From nobody Tue Jan 10 23:42:12 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Ns6mg36BXz2qpDG for ; Tue, 10 Jan 2023 23:42:27 +0000 (UTC) (envelope-from jake@technologyfriends.net) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ns6mf3pG7z3jJq for ; Tue, 10 Jan 2023 23:42:26 +0000 (UTC) (envelope-from jake@technologyfriends.net) Authentication-Results: mx1.freebsd.org; dkim=none ("invalid DKIM record") header.d=technologyfriends.net header.s=google header.b=QbtjnMNp; spf=none (mx1.freebsd.org: domain of jake@technologyfriends.net has no SPF policy when checking 2a00:1450:4864:20::22c) smtp.mailfrom=jake@technologyfriends.net; dmarc=none Received: by mail-lj1-x22c.google.com with SMTP id n5so13765677ljc.9 for ; Tue, 10 Jan 2023 15:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=technologyfriends.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LNAXbODrT1PLBhDZU5zn6S+aHHeTO/xW4SeTjopbOic=; b=QbtjnMNpugYdkb6DqqZuZNEhe1G3W6jcBz8DHOtPkpsLHMUAlXego46fI/yzr58y/s s7AIMk8rvcqvGwjggFLq8JoGNcqLOHGvYqWmYQC8+5V0ZShsUKRxnEoXUOMeMRHX9RT8 SZklQ3QxM5/d4zNPV7ZpfmF8mgvgNE9evSKu87x0LKA5reUWaqJz0GGl04jzgxY2rKP1 N54kR0+0KZORwe8It1CPqd6PmgY7UNjehRFsZwYidGMprtFAAmWRaK/CagcH4sjfW33I eRJ4Q5NRmWy3X2VGPAyOGyqW4aYWdzgSzQQlfmm3cDF9tR2jBypCip/Wl9lPl7dhuXsv mbkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LNAXbODrT1PLBhDZU5zn6S+aHHeTO/xW4SeTjopbOic=; b=pSeykTwR5I1o7MyYjq2s4fNqIsiAGFf0G0KD8AuLM/ItCM3k/QXVEHOzfDBAUhskXI VGiOiY0mOKAJpOumWY93CBKJK3vWzSXnwUzSY3GBFggRLdn88rNocl3NuTN5+SD1IUZX +FtS2szUnaQGJjdbIC3cW75U5idHyTn1Ev882k0FkUdYqWslRxze7G6WdXlffZ39MXHO lxEKqPauOiCnjc+oEpzp+R2iY42xzCsh3LT1/ITG8vxp4oG7vjGNlTotGbWWHi6hVBO3 ULIRDMPPPOub5YJ+UynJied/2lXe1qHQ/4QiCTAFfd78GNEJ5Uzo5jaa7frVH8EdBWa9 VX8g== X-Gm-Message-State: AFqh2krPenInZdHk5twiP61bw/tEFcpF8kFC6Pqp1xybJd7NH96X1s7M /1nyHOc6uhfKwLkILyWb6g9r9DfWeIFX8eWMNgKlHw== X-Google-Smtp-Source: AMrXdXvD0yXl6dp1UlJTtycc0xaKYpbo2/nY1RY09N4ZyXbJ3qNrx1L6GsMjWzUoi/+3EiHl9DLxym7yG5nfXmIfpY4= X-Received: by 2002:a2e:8e3b:0:b0:280:4f2:700a with SMTP id r27-20020a2e8e3b000000b0028004f2700amr2080504ljk.364.1673394143602; Tue, 10 Jan 2023 15:42:23 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Jake Freeland Date: Tue, 10 Jan 2023 17:42:12 -0600 Message-ID: Subject: Re: Syscalls: eventfd and timerfd To: Rob Wing Cc: Mateusz Guzik , "freebsd-hackers@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000007fc69505f1f16f79" X-Spamd-Result: default: False [-2.10 / 15.00]; AUTH_NA_OR_FAIL(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TAGGED_RCPT(0.00)[]; DMARC_NA(0.00)[technologyfriends.net]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_PERMFAIL(0.00)[technologyfriends.net:s=google]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::22c:from]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[technologyfriends.net:~]; TO_DN_SOME(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_LAST(0.00)[]; FREEFALL_USER(0.00)[jake]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Ns6mf3pG7z3jJq X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0000000000007fc69505f1f16f79 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 10, 2023 at 5:39 PM Rob Wing wrote: > You might also be interested in checking out Brooks Davis' talk on adding > syscalls: > > > https://www.bsdcan.org/events/bsdcan_2022/sessions/session/73/slides/35/so-you-want-to-add-a-syscall.pdf > > https://youtu.be/_5LF_0GIpi8 > I must've missed this when trying to find documentation on this topic. Thanks for recommending this. I'll give it a watch. Jake Freeland > > > On Tuesday, January 10, 2023, Mateusz Guzik wrote: > >> It is added with a non-standard entry point. >> >> If you git log -p sys/kern/sys_eventfd.c you will see: >> >> commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9 >> Author: Konstantin Belousov >> Date: Wed Dec 23 16:14:04 2020 +0200 >> >> Expose eventfd in the native API/ABI using a new __specialfd syscall >> >> then if you git grep __specialfd: >> lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD, >> &args, sizeof(args))); >> lib/libc/include/libc_private.h:int __sys___specialfd(int, >> const void *, __size_t); >> sys/compat/freebsd32/freebsd32_syscall.h:#define >> FREEBSD32_SYS___specialfd 577 >> sys/compat/freebsd32/freebsd32_syscalls.c: "__specialfd", >> /* 577 = __specialfd */ >> sys/compat/freebsd32/freebsd32_sysent.c: { .sy_narg = >> AS(__specialfd_args), .sy_call = (sy_call_t *)sys___specialfd, >> .sy_auevent = AUE_SPECIALFD, .sy_flags = SYF_CAPENABLED, .sy_thrcnt = >> SY_THR_STATIC }, /* 577 = __specialfd */ >> sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ >> sys/compat/freebsd32/freebsd32_systrace_args.c: struct >> __specialfd_args *p = params; >> sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ >> sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */ >> sys/kern/init_sysent.c: { .sy_narg = AS(__specialfd_args), .sy_call = >> (sy_call_t *)sys___specialfd, .sy_auevent = AUE_SPECIALFD, .sy_flags = >> SYF_CAPENABLED, .sy_thrcnt = SY_THR_STATIC }, /* 577 = __specialfd >> */ >> sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct >> __specialfd_args *args) >> sys/kern/syscalls.c: "__specialfd", /* 577 = >> __specialfd */ >> sys/kern/syscalls.master: int __specialfd( >> sys/kern/systrace_args.c: /* __specialfd */ >> sys/kern/systrace_args.c: struct __specialfd_args *p = >> params; >> sys/kern/systrace_args.c: /* __specialfd */ >> sys/kern/systrace_args.c: /* __specialfd */ >> sys/sys/syscall.h:#define SYS___specialfd 577 >> sys/sys/syscall.mk: __specialfd.o \ >> sys/sys/sysproto.h:struct __specialfd_args { >> sys/sys/sysproto.h:int sys___specialfd(struct thread *, struct >> __specialfd_args *); >> sys/sys/sysproto.h:#define SYS_AUE___specialfd AUE_SPECIALFD >> >> On 1/11/23, Jake Freeland wrote: >> > Hi there, >> > >> > I am currently working on moving the linux_compat implementation of >> > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD syscall >> > similar to what was done for eventfd. This is my first time implementing >> > a syscall, so I have been following the eventfd implementation as a >> > reference. I noticed that the eventfd syscall entries are absent from >> > sys/kern/syscalls.master and I am not sure why. Was eventfd never >> > formally added as a syscall entry or am I missing something? I was >> > planning on adding timerfd entries to syscalls.master, but now I am >> > unsure how to proceed. >> > >> > I apologize for my ignorance. This process is new to me. >> > >> > Thank you, >> > Jake Freeland >> > >> >> >> -- >> Mateusz Guzik >> >> --0000000000007fc69505f1f16f79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2023 at 5:39 PM Rob Wing <= rob.fx907@gmail.com> wrote:
You might also be= interested in checking out Brooks Davis' talk on adding syscalls:
=


I must&= #39;ve missed this when trying to find documentation on this topic.
Thanks for recommending this. I'll give it a watch.

Jake Freeland
=C2=A0



On Tuesday, January 10, 2023, Mateusz Guzik <mjguzik@gmail.com> wrote= :
It is added with a n= on-standard entry point.

If you git log -p sys/kern/sys_eventfd.c you will see:

commit 7a202823aa54ba18c485bdbcf355269bcfee1ab9
Author: Konstantin Belousov <kib@FreeBSD.org>
Date:=C2=A0 =C2=A0Wed Dec 23 16:14:04 2020 +0200

=C2=A0 =C2=A0 Expose eventfd in the native API/ABI using a new __specialfd = syscall

then if you git grep __specialfd:
lib/libc/gen/eventfd.c: return (__sys___specialfd(SPECIALFD_EVENTFD,
&args, sizeof(args)));
lib/libc/include/libc_private.h:int=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__sys___specialfd(int,
const void *, __size_t);
sys/compat/freebsd32/freebsd32_syscall.h:#define
FREEBSD32_SYS___specialfd=C2=A0 =C2=A0 =C2=A0 =C2=A0577
sys/compat/freebsd32/freebsd32_syscalls.c:=C2=A0 =C2=A0 =C2=A0 "__spec= ialfd",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_sysent.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 { .sy_n= arg =3D
AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd,
.sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D SYF_CAPENABLED, .sy_thrcnt =3D=
SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0struct
__specialfd_args *p =3D params;
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/compat/freebsd32/freebsd32_systrace_args.c: /* __specialfd */
sys/kern/init_sysent.c: { .sy_narg =3D AS(__specialfd_args), .sy_call =3D (sy_call_t *)sys___specialfd, .sy_auevent =3D AUE_SPECIALFD, .sy_flags =3D<= br> SYF_CAPENABLED, .sy_thrcnt =3D SY_THR_STATIC },=C2=A0 =C2=A0 /* 577 =3D __s= pecialfd
*/
sys/kern/sys_generic.c:sys___specialfd(struct thread *td, struct
__specialfd_args *args)
sys/kern/syscalls.c:=C2=A0 =C2=A0 "__specialfd",=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* 577 =3D __specialfd */
sys/kern/syscalls.master:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0int __specialfd(
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0struct __specialfd_args *p =3D params;
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/kern/systrace_args.c:=C2=A0 =C2=A0 =C2=A0 =C2=A0/* __specialfd */
sys/sys/syscall.h:#define=C2=A0 =C2=A0 =C2=A0 =C2=A0SYS___specialfd 577
sys/sys/syscall.mk:=C2= =A0 =C2=A0 =C2=A0__specialfd.o \
sys/sys/sysproto.h:struct __specialfd_args {
sys/sys/sysproto.h:int=C2=A0 sys___specialfd(struct thread *, struct
__specialfd_args *);
sys/sys/sysproto.h:#define=C2=A0 =C2=A0 =C2=A0 SYS_AUE___specialfd=C2=A0 = =C2=A0 =C2=A0AUE_SPECIALFD

On 1/11/23, Jake Freeland <jake@technologyfriends.net> wrote:
> Hi there,
>
> I am currently working on moving the linux_compat implementation of > timerfd (in sys/compat/linux/linux_event.c) into its own FreeBSD sysca= ll
> similar to what was done for eventfd. This is my first time implementi= ng
> a syscall, so I have been following the eventfd implementation as a > reference. I noticed that the eventfd syscall entries are absent from<= br> > sys/kern/syscalls.master and I am not sure why. Was eventfd never
> formally added as a syscall entry or am I missing something? I was
> planning on adding timerfd entries to syscalls.master, but now I am > unsure how to proceed.
>
> I apologize for my ignorance. This process is new to me.
>
> Thank you,
> Jake Freeland
>


--
Mateusz Guzik <mjguzik gm= ail.com>

--0000000000007fc69505f1f16f79-- From nobody Wed Jan 11 09:08:06 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NsMKX3kVDz2qntP for ; Wed, 11 Jan 2023 09:08:16 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4NsMKW1jXYz4Nm1 for ; Wed, 11 Jan 2023 09:08:15 +0000 (UTC) (envelope-from wojtek@puchar.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=puchar.net header.s=default header.b=FMdw7zPq; spf=pass (mx1.freebsd.org: domain of wojtek@puchar.net designates 194.1.144.90 as permitted sender) smtp.mailfrom=wojtek@puchar.net; dmarc=none Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.16.1) with ESMTPS id 30B986N2032832 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Jan 2023 10:08:07 +0100 (CET) (envelope-from wojtek@puchar.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=puchar.net; s=default; t=1673428087; bh=Uxhp0L4VfOt8am4S7eNRSEBdzmppBKuLqw2ibNBjJRg=; h=Date:From:To:Subject; b=FMdw7zPqs085poq4jKxK1IsLCvcPDDupt6ONfcShiqGk1cyXi5noNs8IiZGaom6Bx OKYtiCgTwh8r06fKu4HSeKhb+I1R0WTsPJk9IHrMNcV3+Et/kCBtLLrke1LGLpJf59 W+WEYcJ3vuORKInG0xaOd5YO6SsTw+qTjHYpl4Uk= Received: from wojtek.intra (localhost [127.0.0.1]) by wojtek.intra (8.16.1/8.16.1) with ESMTP id 30B986sP049447 for ; Wed, 11 Jan 2023 10:08:06 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by wojtek.intra (8.16.1/8.16.1/Submit) with ESMTP id 30B986JU049444 for ; Wed, 11 Jan 2023 10:08:06 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: wojtek.intra: wojtek owned process doing -bs Date: Wed, 11 Jan 2023 10:08:06 +0100 (CET) From: Wojciech Puchar To: "freebsd-hackers@freebsd.org" Subject: geli and gpt labels Message-ID: <6017eed6-aca4-ff4b-cb2d-ad21a2aff25@puchar.net> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[puchar.net:s=default]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; DKIM_TRACE(0.00)[puchar.net:+]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[puchar.net]; ARC_NA(0.00)[]; ASN(0.00)[asn:43476, ipnet:194.1.144.0/24, country:PL]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; HAS_XAW(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4NsMKW1jXYz4Nm1 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N i labeled by gpt partitioned SSD including root and i use geli on partitions /dev/gpt/root is marked bootable after kernel starts it asks password but for ada3p3 not /dev/gpt/root if i just press enter 3 times to enter bad password it asks for /dev/gpt/root and system boots. How can i make it ask for gpt labeled name first?