From owner-freebsd-hackers@freebsd.org Mon Jun 8 04:44:50 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D346341F56 for ; Mon, 8 Jun 2020 04:44:50 +0000 (UTC) (envelope-from darius@dons.net.au) Received: from midget.dons.net.au (midget.dons.net.au [IPv6:2403:5800:5101:0:ea:1cff:fefa:f00]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "dons.net.au", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49gLJb5vTcz4S6W for ; Mon, 8 Jun 2020 04:44:46 +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.15.2/8.15.2) with ESMTPS id 0584iMO3019765 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 8 Jun 2020 14:14:37 +0930 (ACST) (envelope-from darius@dons.net.au) Received: (from mailnull@localhost) by midget.dons.net.au (8.15.2/8.15.2/Submit) id 0584hrOs019745 for ; Mon, 8 Jun 2020 14:13:53 +0930 (ACST) (envelope-from darius@dons.net.au) X-MIMEDefang-Relay-be813b1f1da6d6b27d681222cb70cc4f5b642383: 2403:5800:5101:0:c539:aaa0:7db3:e5ff Received: from [IPv6:2403:5800:5101:0:c539:aaa0:7db3:e5ff] ([IPv6:2403:5800:5101:0:c539:aaa0:7db3:e5ff] [2403:5800:5101:0:c539:aaa0:7db3:e5ff]) by midget.dons.net.au (envelope-sender ) (MIMEDefang) with ESMTP id 0584hmHx019740; Mon, 08 Jun 2020 14:13:53 +0930 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Cross compile FreeBSD on amd64 for arm64 failes via compile determination error From: "O'Connor, Daniel" In-Reply-To: Date: Mon, 8 Jun 2020 14:13:48 +0930 Cc: Ian Lepore , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <710FD6CA-F6F4-40F1-9C78-0DE90639ED13@dons.net.au> References: <20200605183002.GA2973@lion.0xfce3.net> <2e91deb9835aaaadd6dceec95395b81f5257f15b.camel@freebsd.org> To: Mark Murray X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Spam-Score: 0 () No, score=0.0 required=5.0 tests=HELO_NO_DOMAIN, T_SPF_PERMERROR autolearn=unavailable autolearn_force=no version=3.4.2 X-Scanned-By: MIMEDefang 2.83 on 10.0.2.1 X-Rspamd-Queue-Id: 49gLJb5vTcz4S6W X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.049]; R_DKIM_ALLOW(-0.20)[dons.net.au:s=default]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.010]; 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.10)[-1.102]; 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-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 04:44:50 -0000 > On 6 Jun 2020, at 19:26, Mark Murray wrote: > I never tried this with anything other than i386/i386 or amd64/amd64, > so the above is interesting. Could a viable cross-build* be "fixed" by > symlinks, and somehow and easily forcing a cross-build of the = bootstrap > tools? >=20 > My RPis wish to know :-) I've done 'make installworld DESTDIR=3D/tmp/armdest' on the fast machine = then copied it over with tar to the slow one and it seemed to work OK. Being able to installworld with src/obj NFS mounted would be nice = though. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum From owner-freebsd-hackers@freebsd.org Mon Jun 8 15:03:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5358533290F for ; Mon, 8 Jun 2020 15:03:27 +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 49gc2Q3BbLz3Tbg; Mon, 8 Jun 2020 15:03:26 +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 058F33V3046859; Mon, 8 Jun 2020 08:03: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 058F32pJ046858; Mon, 8 Jun 2020 08:03:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006081503.058F32pJ046858@gndrsh.dnsmgr.net> Subject: Re: Cross compile FreeBSD on amd64 for arm64 failes via compile determination error In-Reply-To: <710FD6CA-F6F4-40F1-9C78-0DE90639ED13@dons.net.au> To: "O'Connor, Daniel" Date: Mon, 8 Jun 2020 08:03:02 -0700 (PDT) CC: Mark Murray , Ian Lepore , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49gc2Q3BbLz3Tbg 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.82 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.66)[-0.656]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.78)[-0.779]; 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(-0.29)[-0.289]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 15:03:27 -0000 > > > On 6 Jun 2020, at 19:26, Mark Murray wrote: > > I never tried this with anything other than i386/i386 or amd64/amd64, > > so the above is interesting. Could a viable cross-build* be "fixed" by > > symlinks, and somehow and easily forcing a cross-build of the bootstrap > > tools? > > > > My RPis wish to know :-) > > I've done 'make installworld DESTDIR=/tmp/armdest' on the fast machine then copied it over with tar to the slow one and it seemed to work OK. > > Being able to installworld with src/obj NFS mounted would be nice though. Idea: It would be nice if we could do what you just did, then export /tmp/armdest via NFS, then on arm system mount host:/tmp/armdest /tmp/armdest and the src and obj trees. And then somehow run a make installworld TOOLSDIR=/tmp/armdest, this would solve your problem with what I believe to be a very mininmal change/enhancement to the make system. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jun 8 15:12:00 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 469F3332EB0 for ; Mon, 8 Jun 2020 15:12:00 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49gcDJ0W6Tz3Vkb for ; Mon, 8 Jun 2020 15:12:00 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 11749332EAE; Mon, 8 Jun 2020 15:12:00 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 113E1332EAD for ; Mon, 8 Jun 2020 15:12:00 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49gcDH1mFlz3Vs7 for ; Mon, 8 Jun 2020 15:11:59 +0000 (UTC) (envelope-from mpp302@gmail.com) Received: by mail-ej1-f46.google.com with SMTP id gl26so18713972ejb.11 for ; Mon, 08 Jun 2020 08:11:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=tMyy0ov90+pRW24BcWD+UCjKorVyqXk1scFTwUxuI84=; b=q9rADDpizQE81MCBH3L0beX4goCEyMk7JZP6Sq2pJOprME8QIoYJlj6MtnBIXW8L42 FGLLyrFcpIqOTHhP/PImCVv+/s+bwJjrzjjlVw19Il6LU8BXUwMJrOF7pjwQOfGIaFz3 hOmFY28g6lwxYYbF0TzI541dt+z+ufAfODygWeHIpac2XH7uN5YwTCa9qFAc+0zmB4wj 5Bga65HyhofYwAbXNfm6zBrJLRT6YakTbQ0hBNMDh6xrMeyKHKwMrKPTzZCwGe1vLsXD Q/u+NuXHhQTZBjHcwW1nN47UnuIixuvMQ6nSjW1WLkZCxf1HzzuW8AbsTMnCbs7c5C9b ++rQ== X-Gm-Message-State: AOAM532+qv+dE1LoUttc54BUWcoatqh5tRzLaQmZ/ad1M62FGbK4rIKM YwClS0CnUqkK7LBk+WUoVe8uVdzN X-Google-Smtp-Source: ABdhPJyswvmKUmnp2HvMJvN6LupX/t/gQXlxtFbNKlVWwvy7aiwt7XRsoe6gFx/p8aoebHGZ3o46TQ== X-Received: by 2002:a17:906:4a03:: with SMTP id w3mr20953207eju.154.1591629117254; Mon, 08 Jun 2020 08:11:57 -0700 (PDT) Received: from [192.168.0.202] (ip5f5af65f.dynamic.kabel-deutschland.de. [95.90.246.95]) by smtp.gmail.com with ESMTPSA id p6sm11203508ejb.71.2020.06.08.08.11.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 08:11:56 -0700 (PDT) To: "freebsd-hackers@freebsd.org" From: Mateusz Piotrowski <0mp@FreeBSD.org> Subject: How to test modification to a userland program (e.g., sed)? Message-ID: Date: Mon, 8 Jun 2020 17:11:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49gcDH1mFlz3Vs7 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.46 as permitted sender) smtp.mailfrom=mpp302@gmail.com X-Spamd-Result: default: False [0.11 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.218.46:from]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.49)[-0.485]; FORGED_SENDER(0.30)[0mp@FreeBSD.org,mpp302@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[95.90.246.95:received]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.13)[-0.133]; FROM_NEQ_ENVFROM(0.00)[0mp@FreeBSD.org,mpp302@gmail.com]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.27)[-0.270]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[209.85.218.46:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 15:12:00 -0000 Hello hackers@, What is your preferred way to test local modifications to userland programs such as sed(1)? It feels like the correct way would be to create a jail, enter that jail, get the modified version of the src tree inside the jail and then run "make install check" in an appropriate subdirectory within that src tree (e.g., usr.sbin/sed). There must be a simpler way, not involving a jail, right? I've tried to experiment with the something along the following sequence of commands as well but it feels hacky and makes some of the tests fail: export DESTDIR=/test SRCTREE=/src make -C $SRCTREE hierarchy make -C $SRCTREE/usr.bin/sed install export PATH="$DESTDIR/usr/bin:$PATH" make -C $SRCTREE/usr.bin/sed check Cheers, Mateusz From owner-freebsd-hackers@freebsd.org Mon Jun 8 15:22:18 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CCCD3333393 for ; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49gcSB58G0z3X1R for ; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B0974333412; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0617333411 for ; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49gcSB4Jdfz3WsN for ; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 8C69E19098; Mon, 8 Jun 2020 15:22:18 +0000 (UTC) Date: Mon, 8 Jun 2020 17:22:16 +0200 From: Daniel Ebdrup Jensen To: "freebsd-hackers@freebsd.org" Subject: Re: How to test modification to a userland program (e.g., sed)? Message-ID: <20200608152216.7ihcflq2ixlgjui2@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , "freebsd-hackers@freebsd.org" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vxpmxgvvuvkknec6" Content-Disposition: inline In-Reply-To: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 15:22:18 -0000 --vxpmxgvvuvkknec6 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 08, 2020 at 05:11:55PM +0200, Mateusz Piotrowski wrote: >Hello hackers@, > >What is your preferred way to test local modifications to userland >programs such as sed(1)? > >It feels like the correct way would be to create a jail, enter that >jail, get the modified version of the src tree inside the jail and then >run "make install check" in an appropriate subdirectory within that src >tree (e.g., usr.sbin/sed). > >There must be a simpler way, not involving a jail, right? > >I've tried to experiment with the something along the following sequence >of commands as well but it feels hacky and makes some of the tests fail: > > export DESTDIR=3D/test > SRCTREE=3D/src > make -C $SRCTREE hierarchy > make -C $SRCTREE/usr.bin/sed install > export PATH=3D"$DESTDIR/usr/bin:$PATH" > make -C $SRCTREE/usr.bin/sed check > >Cheers, >Mateusz >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hi Matreusz, I think using ephemeral jails with nullfs mounts for /usr/src and /usr/obj = for=20 this is a perfectly valid way to test, as it gives you a clean environment. The only improvement I can think of is to ensure that your source tree is u= sing=20 metamode [1], so that when you're rebuilding a single application, only the= =20 files you changed are rebuilt between each build. If you're using zfs snapshots and clones, creating the base filesystem for = the=20 ephemeral jail also becomes incredibly quick. Do let us know what you settle on, though - I'm sure there are people other= than=20 me, who would be interested to learn if you're doing anything that we might= =20 learn from. :) Yours, Daniel Ebdrup Jensen [1]: https://wiki.freebsd.org/MetaMode --vxpmxgvvuvkknec6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl7eV6hfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87rZ2Af/e3qW2QafcDeHqTBWveVO6SIwEIVBy1bwYRFvjOtQE4k49lkSa7YzRWkS TDAgpl1iGCZY9BVP0QONU6pqcn07QDMFwPE+Lx2kxQt/nKcfRf8TdyT+HwSjMPji 0pWCPx+WfWD86Pc+GNpspNs1s8PDduSULaV74tGaddvJzCLllsMbaq0xGTIpJxw/ aYdqFYltCqYFV76fEHwvlqwe6fP7cYtx5Qj88APRoJmD80i3Ym4OkSovD9MHx/W8 YKtglYRThaIB8aywWy8XGE9V/ig4t/kaKUMr7oFADJpMVuBDxioSQg5dbHutlrla kbUfkqZO030pvH0clWaiRwI58iZTqQ== =fSJG -----END PGP SIGNATURE----- --vxpmxgvvuvkknec6-- From owner-freebsd-hackers@freebsd.org Mon Jun 8 21:19:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 45FB833B8EF for ; Mon, 8 Jun 2020 21:19:49 +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 49gmNh6Pl2z4ZYB; Mon, 8 Jun 2020 21:19:48 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 052B316054; Mon, 8 Jun 2020 23:19:41 +0200 (CEST) Date: Mon, 08 Jun 2020 23:19:40 +0200 From: Steffen Nurpmeso To: Mateusz Piotrowski <0mp@FreeBSD.org> Cc: freebsd-hackers@freebsd.org Subject: Re: svn commit: r361940 - head/usr.bin/mkimg Message-ID: <20200608211940.qrR5l%steffen@sdaoden.eu> In-Reply-To: <202006082111.058LBYfj075205@repo.freebsd.org> References: <202006082111.058LBYfj075205@repo.freebsd.org> Mail-Followup-To: Mateusz Piotrowski <0mp@FreeBSD.org>, freebsd-hackers@freebsd.org User-Agent: s-nail v14.9.19-56-g9975bde7 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: 49gmNh6Pl2z4ZYB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 21:19:49 -0000 Hi. Mateusz Piotrowski wrote in <202006082111.058LBYfj075205@repo.freebsd.org>: |Author: 0mp (doc,ports committer) |Date: Mon Jun 8 21:11:34 2020 |New Revision: 361940 |URL: https://svnweb.freebsd.org/changeset/base/361940 | |Log: | Use Fl instead of Ar for long flags ... |-.Ar --formats | --schemes | --version |+.Fl -formats | Fl -schemes | Fl -version Ingo Schwarze of mandoc has in the meanwhile committed support for ".Fl Fl", which is the term that seems to be most widely used for long options, for example .Fl Fl formats It also works just fine for groff, the real roff macros that is. 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 owner-freebsd-hackers@freebsd.org Tue Jun 9 06:48:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C48ED34B41E for ; Tue, 9 Jun 2020 06:48:30 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 49h10s6mGJz3YFF for ; Tue, 9 Jun 2020 06:48:29 +0000 (UTC) (envelope-from yuripv@yuripv.dev) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 479395C00C6 for ; Tue, 9 Jun 2020 02:48:29 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Jun 2020 02:48:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.dev; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=I 5fRr0HuXlu4Z/xGhRdA1JYOxgwoLf37e6ndttRSp2Q=; b=CkdvklMHPLhdEqmgQ 5UpEf9MqVYT8N3eDZKOqwyIyTZ0auIt0jPT+6s/oR3s6SkxqmWaQiYEE2ATxvNIC W3Xt5qC7JoF0xQHIktwi48aRyGA1/JCG9ziLr8ryWrjxWhl+A/ivmsdq/fgk3ssZ gsN9x/F4jihJjQMAzJ63wvGV2bxnpxAMF+J9pmAt88Jz0xoE3+afkvf0J03cuhrx UXac0BjpZ4VEndxhdeYXWJYhxUh84TR5a+7knJxTy2x1V4Mh2YYJD/IEflE4yoYS NAuG6Tu/jP10cNwQuuPr4JAPAZ6qPMpzaefCLtCrri1dCqSNoFNeuhESTcGrlt/c MNZqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=fm3; bh=I5fRr0HuXlu4Z/xGhRdA1JYOxgwoLf37e6ndttRSp 2Q=; b=fUh4pdtg4XHBJdjtDLlCZXtR2RZitl5Bui9vxbfJjTJ+ozKGzc0uaLWWw 7OffnSnxHUuZBkTvdeqkI1JxfgJfM9vICwwQKRA3KkmS2bTSCE+qWyFKxPzxs/w2 zp0l9Lut4m1GQ7HhApGTP/tkJrBTQgQ9bJLKOt9skSxUxSNvjV1dfceikOn/c6jJ UmGGwSC2YcGJBj1edG3IgDdZxPKFe+fAcI2DEdykz9SM0/huUaSgH0hmlD6TxLx3 AfOIXRlp0MtwLIkFyS/I3naH1OLWQQZtZZVUj7RhiRViyAT2Gc0VopqjPEEtoWjy bQuPONamW7mrl8kA/fC+0XFt94/NQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehfedgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ejredttdefjeenucfhrhhomhepjghurhhiucfrrghnkhhovhcuoeihuhhrihhpvheshihu rhhiphhvrdguvghvqeenucggtffrrghtthgvrhhnpeeikeetfedtfedtkefhffeuleejfe ffgfffffeuhfehgfehjedvgeefheeivedugfenucffohhmrghinhepfhhrvggvsghsugdr ohhrghenucfkphepledurddvgedtrdduvdegrddufeeknecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhiphhvseihuhhrihhpvhdruggv vh X-ME-Proxy: Received: from [192.168.1.6] (unknown [91.240.124.138]) by mail.messagingengine.com (Postfix) with ESMTPA id BF2913280065 for ; Tue, 9 Jun 2020 02:48:28 -0400 (EDT) Subject: Re: svn commit: r361940 - head/usr.bin/mkimg To: freebsd-hackers@freebsd.org References: <202006082111.058LBYfj075205@repo.freebsd.org> <20200608211940.qrR5l%steffen@sdaoden.eu> From: Yuri Pankov Message-ID: Date: Tue, 9 Jun 2020 09:48:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200608211940.qrR5l%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49h10s6mGJz3YFF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yuripv.dev header.s=fm1 header.b=CkdvklMH; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=fUh4pdtg; dmarc=none; spf=pass (mx1.freebsd.org: domain of yuripv@yuripv.dev designates 66.111.4.27 as permitted sender) smtp.mailfrom=yuripv@yuripv.dev X-Spamd-Result: default: False [3.25 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(0.00)[yuripv.dev:s=fm1,messagingengine.com:s=fm3]; FROM_HAS_DN(0.00)[]; SEM_URIBL_FRESH15(3.00)[yuripv.dev:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:66.111.4.27]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; NEURAL_SPAM_MEDIUM(0.25)[0.246]; RCPT_COUNT_ONE(0.00)[1]; BAD_REP_POLICIES(0.10)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[yuripv.dev]; DKIM_TRACE(0.00)[yuripv.dev:+,messagingengine.com:+]; NEURAL_SPAM_LONG(0.54)[0.543]; NEURAL_HAM_SHORT(-0.44)[-0.444]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:66.111.4.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[66.111.4.27:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 06:48:30 -0000 Steffen Nurpmeso wrote: > Hi. > > Mateusz Piotrowski wrote in > <202006082111.058LBYfj075205@repo.freebsd.org>: > |Author: 0mp (doc,ports committer) > |Date: Mon Jun 8 21:11:34 2020 > |New Revision: 361940 > |URL: https://svnweb.freebsd.org/changeset/base/361940 > | > |Log: > | Use Fl instead of Ar for long flags > ... > |-.Ar --formats | --schemes | --version > |+.Fl -formats | Fl -schemes | Fl -version > > Ingo Schwarze of mandoc has in the meanwhile committed support for > ".Fl Fl", which is the term that seems to be most widely used for > long options, for example > > .Fl Fl formats > > It also works just fine for groff, the real roff macros that is. This requires quoting the actual commit message: While we do not recommend the idiom ".Fl Fl long" for long options because it is an abuse of semantic macros for device-specific presentational effects, this idiom is so widespread that it makes sense to convert it to the recommended ".Fl \-long" during the validation phase. For example, this improves HTML formatting in pages where authors have used the dubious .Fl Fl. So, FWIW, while the support for ".Fl Fl" was added, using it is not recommended. From owner-freebsd-hackers@freebsd.org Tue Jun 9 14:21:06 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B34332E9AD for ; Tue, 9 Jun 2020 14:21:06 +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 49hC356Dgrz3S7k for ; Tue, 9 Jun 2020 14:21:05 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id D65F816054; Tue, 9 Jun 2020 16:13:19 +0200 (CEST) Date: Tue, 09 Jun 2020 16:13:19 +0200 From: Steffen Nurpmeso To: Yuri Pankov Cc: freebsd-hackers@freebsd.org Subject: Re: svn commit: r361940 - head/usr.bin/mkimg Message-ID: <20200609141319.u7QUq%steffen@sdaoden.eu> In-Reply-To: References: <202006082111.058LBYfj075205@repo.freebsd.org> <20200608211940.qrR5l%steffen@sdaoden.eu> Mail-Followup-To: Yuri Pankov , freebsd-hackers@freebsd.org User-Agent: s-nail v14.9.19-56-g9975bde7 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: 49hC356Dgrz3S7k 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 [5.41 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+a:c]; NEURAL_SPAM_SHORT(0.15)[0.153]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; SEM_URIBL_FRESH15(3.00)[yuripv.dev:email]; BAD_REP_POLICIES(0.10)[]; NEURAL_SPAM_MEDIUM(0.62)[0.617]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MID_CONTAINS_FROM(1.00)[]; NEURAL_SPAM_LONG(0.64)[0.643]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; GREYLIST(0.00)[pass,body] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 14:21:06 -0000 Yuri Pankov wrote in : |Steffen Nurpmeso wrote: |> Mateusz Piotrowski wrote in |> <202006082111.058LBYfj075205@repo.freebsd.org>: |>|Author: 0mp (doc,ports committer) |>|Date: Mon Jun 8 21:11:34 2020 |>|New Revision: 361940 |>|URL: https://svnweb.freebsd.org/changeset/base/361940 |>| |>|Log: |>| Use Fl instead of Ar for long flags |> ... |>|-.Ar --formats | --schemes | --version |>|+.Fl -formats | Fl -schemes | Fl -version |> |> Ingo Schwarze of mandoc has in the meanwhile committed support for |> ".Fl Fl", which is the term that seems to be most widely used for |> long options, for example |> |> .Fl Fl formats |> |> It also works just fine for groff, the real roff macros that is. | |This requires quoting the actual commit message: | | While we do not recommend the idiom ".Fl Fl long" for long options | because it is an abuse of semantic macros for device-specific | presentational effects, this idiom is so widespread that it makes | sense to convert it to the recommended ".Fl \-long" during the | validation phase. For example, this improves HTML formatting | in pages where authors have used the dubious .Fl Fl. | |So, FWIW, while the support for ".Fl Fl" was added, using it is not |recommended. I do not follow, sorry. I for one think Fl Fl is absolutely valid, where is the problem? If you go that route that Ingo (it is Ingo) brings into the world here (which counteracts many, many real-life manuals), then just reach into the macros and check how many characters the argument to Fl has, after all Fl is meant to document getopt-style things. If it is one, it is a short option, if it has more, it is a long one. Short options have one dash, long have two, that is the convention. That is, mdoc(7) is BSDs own, the macros have always been there, until groff has been replaced with mandoc, at least, but instead of just adding an easy .if (.ie, actually) roff condition check on a .length there is, dict.cc says: topsy-turvy. So whining on lost semantics is misplaced anyhow. With Fl Fl you can programmatically check easily (what you have to do with mdoc anyway because it is not "^.Fl .Fl bla" or "^.It .Fl .Fl bla", no, it is "^.It Fl bla", heh), whereas with Fl \-bla you have to parse actual string content to get semantic, at least in my opinion. It is a long option, not a short option, that requires special treatment, and is not even standardized until now. Just my one cent, of course. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Tue Jun 9 18:14:55 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF7E2338A0A for ; Tue, 9 Jun 2020 18:14:55 +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 49hJDv0XG6z4JJw; Tue, 9 Jun 2020 18:14:54 +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 059IErFi052231; Tue, 9 Jun 2020 11:14:53 -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 059IErtW052230; Tue, 9 Jun 2020 11:14:53 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006091814.059IErtW052230@gndrsh.dnsmgr.net> Subject: Re: svn commit: r361940 - head/usr.bin/mkimg In-Reply-To: <20200608211940.qrR5l%steffen@sdaoden.eu> To: Steffen Nurpmeso Date: Tue, 9 Jun 2020 11:14:53 -0700 (PDT) CC: Mateusz Piotrowski <0mp@freebsd.org>, freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49hJDv0XG6z4JJw 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.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.589]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.58)[0.582]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.03)[0.029]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 18:14:55 -0000 > Hi. > > Mateusz Piotrowski wrote in > <202006082111.058LBYfj075205@repo.freebsd.org>: > |Author: 0mp (doc,ports committer) > |Date: Mon Jun 8 21:11:34 2020 > |New Revision: 361940 > |URL: https://svnweb.freebsd.org/changeset/base/361940 > | > |Log: > | Use Fl instead of Ar for long flags > ... > |-.Ar --formats | --schemes | --version > |+.Fl -formats | Fl -schemes | Fl -version > > Ingo Schwarze of mandoc has in the meanwhile committed support for > ".Fl Fl", which is the term that seems to be most widely used for > long options, for example > > .Fl Fl formats > > It also works just fine for groff, the real roff macros that is. While this produces the correct typographic output, I believe it to be counter to the intent of roff to be a lexographical expression of content. It would probably be wise if one wants to preserve the intent of roff to introduce a new macro that describes the doublt dash long options. > 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) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Tue Jun 9 18:28:27 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5D3B33388F2 for ; Tue, 9 Jun 2020 18:28:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49hJXV6KSbz4Kbf for ; Tue, 9 Jun 2020 18:28:26 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1591727305; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=PZmuwgABkVxnPm+9P378Onk1ybfqLgOPVyaXREeQL/4BZzOLiwKJbpY9MfEbOsBc2gykvwzGqrv10 TrWyjbmdPPuloU3KDNAIva2PV6F43WcicoAglQbuUPBvQzLwMCTS6buKFGUTNDRJP/Gy9eIFnIHImR RYUG9z+OvLblBCLuSSG3hDiUqTCa7a5GbABKOo9l8Rx34j5XVpAIf37Z2WA1+Gb8OaBJUtPgMgV2u3 EC/283Qt74fg45L0NF6a0GSfZQqgqJogKV+AizXKRsIpR74pq/LJzcklHbMgS0FhT0UIjoKnEpDgB8 BGtU82rVgH4pHsrB2JS7UWxBac/3Gnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=U0LLJqk/68Ub/l6WZNDSf7fikAC95LLr5WwbGr2h9ds=; b=snXs2efOmoR6exf0Ys/7bRwTrCetXq9/1wnruGodwvBit8z0HkYd9aibmqfUTaaU9Y5dDVA52RI8b mOXjgS0tWdCaGUHp36J/K5j2Reb7cOWOsXMlGeNKGy+gqlUzigovlmiMpL9gh0IHDyauDPjyuKckac AwimM6YTmo61rrvfmZW1LDgST8/FPZqFNnJyIOaCgJaPsBIhRloWYWyZsl84c77ICE08xA4sEGozBe m5uHFQUrpn6uWQlNx+fKI4KwrTxIYiwT2hCgBLvKabuXSof3Wfkt3Y8bxyMld877dHtzJ3xx8pVD2D cLZsHLMj6gcZ6g4KqvYoLJGTX+HK3KA== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=U0LLJqk/68Ub/l6WZNDSf7fikAC95LLr5WwbGr2h9ds=; b=LKxPpgNEIW5d6Na/f3C6bCo8QBmSoupGX7GPDk5XVRzkHdJNorBM2LHWgeMRz+Xq2NSfj4BKGyQiC 6eSR4/Vhyyfcw1VT1Jk0FZF9YTKgmNCQPbtUIFlfm4IqWpeGk9YVvBxhSrz9u34TMoUL64tFp1jcc/ iSqjiZ5b3LeyLiCqF+XZaFcQTxdOSJkMh4s1VaNKmYRMTbAGz8+seJlpa6vyfa1EKzWOATu9yLzoNB SbC8hFCooEJNFRAdkwIdSPqlCsCdOlYOgp4R8WqZkE69EafOCKk4+BAI8kX1TXLOfWuDOvPIxpguPZ OZEl1ylw2qBDDViTsWkIyJ0QUHvdHOw== X-MHO-RoutePath: aGlwcGll X-MHO-User: ffcf2bde-aa7e-11ea-a067-6d02e42e573a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id ffcf2bde-aa7e-11ea-a067-6d02e42e573a; Tue, 09 Jun 2020 18:28:24 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 059ISLwd095919; Tue, 9 Jun 2020 12:28:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1743df590639dc61b2b4216c81677851d2ee1312.camel@freebsd.org> Subject: Re: svn commit: r361940 - head/usr.bin/mkimg From: Ian Lepore To: Steffen Nurpmeso , Yuri Pankov Cc: freebsd-hackers@freebsd.org Date: Tue, 09 Jun 2020 12:28:21 -0600 In-Reply-To: <20200609141319.u7QUq%steffen@sdaoden.eu> References: <202006082111.058LBYfj075205@repo.freebsd.org> <20200608211940.qrR5l%steffen@sdaoden.eu> <20200609141319.u7QUq%steffen@sdaoden.eu> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49hJXV6KSbz4Kbf X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 18:28:27 -0000 On Tue, 2020-06-09 at 16:13 +0200, Steffen Nurpmeso wrote: > I for one think Fl Fl is absolutely valid, where is the problem? > If you go that route that Ingo (it is Ingo) brings into the world > here (which counteracts many, many real-life manuals), then just > reach into the macros and check how many characters the argument > to Fl has, after all Fl is meant to document getopt-style things. > If it is one, it is a short option, if it has more, it is a long > one. Short options have one dash, long have two, that is the > convention. It may be a convention, but it is not a standard that is universally followed, as "man clang" or "man gcc" will show you. -- Ian From owner-freebsd-hackers@freebsd.org Tue Jun 9 19:37:18 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B24F333A2DA for ; Tue, 9 Jun 2020 19:37:18 +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 49hL3x2VzRz4TFL; Tue, 9 Jun 2020 19:37:17 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id 9DA9D16054; Tue, 9 Jun 2020 21:37:14 +0200 (CEST) Date: Tue, 09 Jun 2020 21:37:14 +0200 From: Steffen Nurpmeso To: Ian Lepore Cc: Yuri Pankov , freebsd-hackers@freebsd.org, "Rodney W. Grimes" Subject: Re: svn commit: r361940 - head/usr.bin/mkimg Message-ID: <20200609193714.lkpZS%steffen@sdaoden.eu> In-Reply-To: <1743df590639dc61b2b4216c81677851d2ee1312.camel@freebsd.org> References: <202006082111.058LBYfj075205@repo.freebsd.org> <20200608211940.qrR5l%steffen@sdaoden.eu> <20200609141319.u7QUq%steffen@sdaoden.eu> <1743df590639dc61b2b4216c81677851d2ee1312.camel@freebsd.org> Mail-Followup-To: Ian Lepore , Yuri Pankov , freebsd-hackers@freebsd.org, "Rodney W. Grimes" User-Agent: s-nail v14.9.19-56-g9975bde7 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: 49hL3x2VzRz4TFL 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.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.959]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-0.91)[-0.911]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.51)[-0.509]; MID_CONTAINS_FROM(1.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 19:37:18 -0000 Ian Lepore wrote in <1743df590639dc61b2b4216c81677851d2ee1312.camel@freebsd.org>: |On Tue, 2020-06-09 at 16:13 +0200, Steffen Nurpmeso wrote: |> I for one think Fl Fl is absolutely valid, where is the problem? |> If you go that route that Ingo (it is Ingo) brings into the world |> here (which counteracts many, many real-life manuals), then just |> reach into the macros and check how many characters the argument |> to Fl has, after all Fl is meant to document getopt-style things. |> If it is one, it is a short option, if it has more, it is a long |> one. Short options have one dash, long have two, that is the |> convention. | |It may be a convention, but it is not a standard that is universally |followed, as "man clang" or "man gcc" will show you. | |-- Ian --End of <1743df590639dc61b2b4216c81677851d2ee1312.camel@freebsd.org> Rodney W. Grimes wrote in <202006091814.059IErtW052230@gndrsh.dnsmgr.net>: |> Mateusz Piotrowski wrote in |> <202006082111.058LBYfj075205@repo.freebsd.org>: |>|Author: 0mp (doc,ports committer) |>|Date: Mon Jun 8 21:11:34 2020 |>|New Revision: 361940 |>|URL: https://svnweb.freebsd.org/changeset/base/361940 |>| |>|Log: |>| Use Fl instead of Ar for long flags |> ... |>|-.Ar --formats | --schemes | --version |>|+.Fl -formats | Fl -schemes | Fl -version |> |> Ingo Schwarze of mandoc has in the meanwhile committed support for |> ".Fl Fl", which is the term that seems to be most widely used for |> long options, for example |> |> .Fl Fl formats |> |> It also works just fine for groff, the real roff macros that is. | |While this produces the correct typographic output, I believe |it to be counter to the intent of roff to be a lexographical |expression of content. It would probably be wise if one |wants to preserve the intent of roff to introduce a new macro |that describes the doublt dash long options. ... |Rod Grimes rgrimes@freeb\ |sd.org --End of <202006091814.059IErtW052230@gndrsh.dnsmgr.net> Good, despite being not able to deal with programs which use their own style of options (lynx(1) would have been another example), the .length example will not work out for my own thing either, to handle the display of all the one-letter options without arguments, for example (here the optional ones: .Op Fl DdEFinv~#). I still stand by my opinion that Fl Fl gives more context than Fl \-, and keeps all the dirty logic in the macro set where it belongs. And is an easy rule to remember, because the above changeset turns something "wrong" into something that is at least doubtful, it will render ugly dependent on the output device, too. roff maybe, mdoc however is really lifted, it results in terrible constructs like the _unbelievable_ .Oo : Ns Fl S\0 Ns Ar var Ns Oo Ns = Ns Ar value Ns Oc Ns : Ns Oc At least it is "better" / more explicit than the man macros. P.S.: interesting that clang is noted as an example for manual pages, as it does not truly offer them as far as i know. When i look around more and more applications do not ship tarballs with readily prepared manuals at all, so you need a fully blown local "doc" environment to generate them, python / sphinx or docbook or asciidoc are common. This becomes a problem for self-builders, on CRUX-Linux some packages start shipping without any manuals (info always has been unwanted there) in order to reduce the build time dependencies. clang is one of those. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-hackers@freebsd.org Wed Jun 10 05:26:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A55B8329346; Wed, 10 Jun 2020 05:26:03 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49hb7G3Kszz4hQt; Wed, 10 Jun 2020 05:26:02 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id j12so709740lfh.0; Tue, 09 Jun 2020 22:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=LSerhDbvas11IA2kErUrzbds/Q110lc2O/L4COVGu0E=; b=egIqsIPrtFaDBpfqLhkOyGG3OKCoNivKWGnrg8x9O94X+7BxqDDA7ODpcM/4Pptwze MrscV7QI8YGGRtSQR8ENg+uuS+xkQr2EEK84LMRctKwwy6L3l4ezvtnwqDiK0lcoyJPi PrMbheuA4TeHe310EP89f4RNrzssMs1cWFRTcJq1Lm/Yctmt3SJyh4Gg0U/wAcxg6Dme 3uHF2fgkeGuZCxT5zJkE1XByNWMnZxELUfxjN5B6l/qCrQK0QbHfgxDJEpEjoMPWT2O6 5R+OoV1CfzSXwGbB6ELt/KSe9N1HNSapKgvjC12A5SjOnJwbmtqORFGhHBLykGht79p2 /gfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:mime-version :content-transfer-encoding; bh=LSerhDbvas11IA2kErUrzbds/Q110lc2O/L4COVGu0E=; b=Wzb+nb87y1JJzG4lpWWLKxejHThx/dlMJlq70RXP6E/sangZmmZXKLgcjlZLselG+o IlJA9LetLlr7SwXnoC2OGntI6te9bjecRzY+Fp2noexnuhsP/nY5+BcF1n9YfQCDdA5/ g0pmKnSvBukTRRff1zHzsx4SbBE7XtqiH/kTzjhtermkHl4XROEJcfwc6GLj80tQgIzO LGgSuR0TrnLz6JmB31+OjVEqMFcZcl3he7E4xKMhbr/aLaqQ4JkHXMsCxyvMujMG9v8W 1iciy1hXrqYJRC40/TbOLM72xitbAHJje3/bLhiBuFKeNETB0Dj+oF8jHwLlTrg/vSbe mOTg== X-Gm-Message-State: AOAM531OK32Wfjy+jPzx+xMj5GVsj2zF9QqTwSf/E418JOQQY6E1VTmP oF8VGIGCLtl3zGjXELcvqVllL5i2d8Q= X-Google-Smtp-Source: ABdhPJyP8djsbPU2BJlAftwIwkRke3KYkXzP5/h2QKp9D4tNxLmKKbKyr6as1+WKZinToBXV9b8YGw== X-Received: by 2002:a05:6512:7b:: with SMTP id i27mr743138lfo.30.1591766758848; Tue, 09 Jun 2020 22:25:58 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id w20sm4715273ljo.68.2020.06.09.22.25.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 22:25:57 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Wed, 10 Jun 2020 08:25:52 +0300 To: freebsd-net@freebsd.org, freebsd-hackers@freebsd.org Cc: Rozhuk Ivan Subject: WiFi with AC on FreeBSD Message-ID: <20200610082552.0e08045c@rimwks> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49hb7G3Kszz4hQt X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=egIqsIPr; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rozhukim@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=rozhukim@gmail.com X-Spamd-Result: default: False [-3.61 / 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.19)[-1.190]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.887]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.03)[-1.033]; 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::12d:from]; MID_RHS_NOT_FQDN(0.50)[]; FREEMAIL_CC(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 05:26:03 -0000 Hi! For peoples who want to use linux WiFi drivers on FreeBSD with minimum support overhead :) This "how-to" (draft) describes how to use OpenWRT as driver with web GUI for WiFi adapters. No more pain with slow speed, no strange wpa_supplicant gui tools :) This upgrades WiFi speed from media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11a to 866Mbps on my notebook with intel 8265. Resourses required: - 256 Mb ram - 128 Mb on hard drive - IOMMU support - FreeBSD AMD64 1. Download EFI based build. WWW: https://openwrt.org/docs/guide-developer/uefi-bootable-image cd /root/ fetch https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-squashfs-combined-efi.img.gz gunzip openwrt-x86-64-generic-squashfs-combined-efi.img.gz 2. Install sysutils/bhyve-firmware from ports. CSM not required. Patch required to build port (last attached): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211074 3. Configure system: WWW: https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html https://wiki.freebsd.org/bhyve/pci_passthru echo 'net.link.tap.up_on_open=1' >> /etc/sysctl.conf /etc/rc.conf: kld_list="nmdm vmm" cloned_interfaces="tap0" ifconfig_tap0_name="wifi0" ifconfig_wifi0="DHCP up" ifconfig_wifi0_ipv6="inet6 accept_rtadv auto_linklocal -ifdisabled" /boot/loader.conf # bhyve PCI device passthru. # "1/0/0" - PCI dev ident, see: pciconf -lv pptdevs="1/0/0" # For AMD systems hw.vmm.amdvi.enable="1" 4. Start OpenWRT /usr/sbin/bhyvectl --destroy --vm=owrt /usr/sbin/bhyve \ -A \ -H \ -c 2 \ -m 256M \ -S \ -s 0:0,hostbridge \ -s 1:0,lpc -l com1,stdio \ -s 3:0,ahci-hd,openwrt-x86-64-generic-squashfs-combined-efi.img \ -s 5:0,e1000,tap0,mac=00:be:fa:76:45:01 \ -s 7,passthru,1/0/0 \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ owrt To disable output remove: "-l com1,stdio" "1/0/0" - PCI dev ident, same as in loader.conf. 5. Configure OpenWRT: uci set network.lan.ipaddr='172.16.0.49' uci set network.lan.netmask='255.255.255.0' uci set network.lan.gateway='172.16.0.254' uci add_list network.lan.dns='172.16.0.254' uci commit network /etc/init.d/network restart opkg update opkg install luci Now web GUI can be used to install wpad*, hostapd*, WiFi driver and other staff. If you want use OpenWRT as bridge - read this: https://openwrt.org/docs/guide-user/network/wifi/relay_configuration Better to start with simple rourer+nat mode. From owner-freebsd-hackers@freebsd.org Wed Jun 10 07:53:09 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F20A332C929 for ; Wed, 10 Jun 2020 07:53:09 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49hfP165hZz4qst for ; Wed, 10 Jun 2020 07:53:09 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id BBDC52544; Wed, 10 Jun 2020 07:53:09 +0000 (UTC) Date: Wed, 10 Jun 2020 09:53:07 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: WiFi with AC on FreeBSD Message-ID: <20200610075307.5r4ynpool6grwsj5@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <20200610082552.0e08045c@rimwks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2woqfowgl6a3klqa" Content-Disposition: inline In-Reply-To: <20200610082552.0e08045c@rimwks> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 07:53:10 -0000 --2woqfowgl6a3klqa Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 10, 2020 at 08:25:52AM +0300, Rozhuk Ivan wrote: >Hi! > >For peoples who want to use linux WiFi drivers on FreeBSD with minimum sup= port overhead :) > >This "how-to" (draft) describes how to use OpenWRT as driver with web GUI = for WiFi adapters. >No more pain with slow speed, no strange wpa_supplicant gui tools :) > >This upgrades WiFi speed from >media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11a >to 866Mbps on my notebook with intel 8265. [SNIP of all the interesting stuff] > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hello, This is a very interesting draft, and it would be even better if it could b= e=20 included on the FreeBSD wiki [1], where it can be worked on by more people. If you don't have an account, it's as simple as emailing wiki-admin@FreeBSD= =2Eorg=20 with your FirstnameLastname (this will become your username) - as soon as t= hey=20 see it, they'll send you back a temporary password that you can change once= you=20 log in. :) Have you thought about taking this one step further and making a very small= =20 Linux appliance (ie. just the linux kernel with wpa_supplicant and perhaps = a few=20 other utilities statically compiled)? I don't know Linux well enough to kno= w if=20 it's possible, but it might even be worth trying to set the values of the= =20 parameters you're changing via kernel environment variables, if that's doab= le? Yours respectfully, Daniel Ebdrup Jensen [1]: https://wiki.freebsd.org --2woqfowgl6a3klqa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl7gkWNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qGAwf/Rs7bK4uS0sZKzgnW00iVeoWi0CZw3wgu9o++bf2wTwWEbkMKn+b7v6Wd mCBBBdiu7gsuMG/qxDaBL7/JSkC+dc9kyFbepoxsPEEoKtHoyDMCa7fU9LqufW8b G7gIAD6nodVYKVCukXUSi91e3gXSZ2n2lFNfwbhmdWy3IDLz5TPtnzex+4eolXck N1iFAgd3zPBeAIPwSvEKG8lLVvJ7ITJ9Uq0AOFBNLmflZCyrUiPKUPuctF/S7GLS z/Mw2JGIRzC6aAiqBwrX0bpsZGd8lJ69opvSZC2+QZcs28cathS6aJFjYrOSWX5M W3NGNU9jKVEooZnz/4i77N0vWocr0Q== =H61r -----END PGP SIGNATURE----- --2woqfowgl6a3klqa-- From owner-freebsd-hackers@freebsd.org Thu Jun 11 01:57:05 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D0C3B34492A for ; Thu, 11 Jun 2020 01:57:05 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-25.consmr.mail.gq1.yahoo.com (sonic312-25.consmr.mail.gq1.yahoo.com [98.137.69.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49j6Rh5Qqdz3Zy7 for ; Thu, 11 Jun 2020 01:57:04 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: EcYWCd8VM1mhPmWkBvPeNWsfCnelVPAeJfxYido6r5Q_2soHJB4lG8t0wILngZk ye9pqxVUx9zwz09dyfJ3P9EYJGgc4ytH4BceyfHk4hwnAyyKxQWlM2yIg96z4D0F8a01rykHKiog KMLdIfZHurDZCWn_Pjsej.VOidxZfTQoy_1Bt6hk8rZ62bB2h41cus_xwAsVHv664fshMWlw0Qbq d8KtbdMdRbN3BolSLp6P1ZecRM212r7w_SEKqRbW3yoZ1HQnk8FHZsxJXjsDJYFmd4eA1ZhMTKpA ZnmZAepncte_uEMMLk2J.qtE.zOwiwTrlt2ZRBB_gNBy2pAw9YEYif2wq25ZfXJi9fSNKn0rLHfi s7H9Suy89bm8VmUSliw03WBBHipLMy0ozMXnV9qkG7wksCFvLSlWClwcqh.GHk6UCt9m5ODJ.VAV tntWg3cXR1zR6wiXtnz2ttSjUTZuM5lA2GYzfOTDeX2rN6F70YtXUhrSiRrEX4njbgO3uz0nxxKe BWSNcJbUD7r80K7oKtbVsOL8AcKAHiJ_f3_EhtXseajEk0OaTeM9jKoQXjglsI6d..LmdZKhZ7S4 4oVLU5QgRrL._176furakeDlbcIOKcPUSBJkf82HsuD5jLKLANz4qyBz8wS5e6S1qHGhP_46O.rG w3GnF1VWLXvvp3uNnDeRDddCxWib9KFJDatOALRf7whI2vu6yql8yBYQZwBE0hddqCRZyONQ8JDc x8BTvZWw.9FS.RF5hfm_EyucxbUS9YNEkPWUiz2iEtCyv5xtmhvT222pZsbB7JT1wv6h9S5zMY8x atG6MSvNDkzrWdZK7SX4PzJRvegFWoabyVG3KOdoH.z_1hSlz3dgFZI7v.fc4yePdIq.126N77Y2 VzmsaYm3azMxU3YppO1eiXCx5_0IpQ0WCmX42JGrA6XTUHQDz0Hf_0ATHakqWQ8ZJfE4IYVueD.L zmD__lR3va3Lbzy_dRQ61eHByN7PvntVjeXpcrcjMmdUVIYS4Fk7H_FPrJnpYFGnr3CuOMWdO9wL divaKmYUKDx36okSLvbsvGMb_JmJn08ueU6xtdcwAl6WqCKxA6Nlfh7QT.zmJFK14Ho2lTHcW70C sNXZhA5YFQjpLTz.Xzrj9HH278ZzTpmHpVhvgwAV7T3kMCpHgyScn9REMhJX89W0brsKcoBZuCGo pmhULcAv6pLS7NXyYtKl_Tnvke4LoJKehtBYe9Va.sLAnkn_bTtn7k33Utg_KJJuSkOy5T66d0uQ SPgTROrzIbUcCPaYBfmZc4VEp0B86uw2czQCX_Zdds0lmzLYdqE3MjhZJZRdgMOeyPZvTVQ2zRbH 40W83C7fag4tqceICToJATPPi5he3fidNPxh13roTdt70kCcZB4LnJKLCAs95BiK9SgTvtq4snzT 2zbv6Tl_osVCl6VH.VQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2020 01:57:01 +0000 Received: by smtp419.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 54c6ff5e13356fd16977b52c6a38d5c8; Thu, 11 Jun 2020 01:56:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <20200513105632.06db9e21@titan.knownspace> Date: Wed, 10 Jun 2020 18:56:57 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49j6Rh5Qqdz3Zy7 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.02 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.47)[-0.466]; FREEMAIL_TO(0.00)[gmail.com]; 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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.06)[-1.064]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.206:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 01:57:05 -0000 On 2020-May-13, at 08:56, Justin Hibbits wrote: > Hi Mark, Hello Justin. > On Wed, 13 May 2020 01:43:23 -0700 > Mark Millard wrote: >=20 >> [I'm adding a reference to an old arm64/aarch64 bug that had >> pages turning to zero, in case this 32-bit powerpc issue is >> somewhat analogous.] >>=20 >>> . . . > ... >> . . . >>=20 >> (Note: dsl-only.net closed down, so the E-mail >> address reference is no longer valid.) >>=20 >> Author: kib >> Date: Mon Apr 10 15:32:26 2017 >> New Revision: 316679 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/316679 >>=20 >>=20 >> Log: >> Do not lose dirty bits for removing PROT_WRITE on arm64. >>=20 >> Arm64 pmap interprets accessed writable ptes as modified, since >> ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable >> bit is removed, page must be marked as dirty for MI VM. >>=20 >> This change is most important for COW, where fork caused losing >> content of the dirty pages which were not yet scanned by pagedaemon. >>=20 >> Reviewed by: alc, andrew >> Reported and tested by: Mark Millard >> PR: 217138, 217239 >> Sponsored by: The FreeBSD Foundation >> MFC after: 2 weeks >>=20 >> Modified: >> head/sys/arm64/arm64/pmap.c >>=20 >> Modified: head/sys/arm64/arm64/pmap.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/sys/arm64/arm64/pmap.c Mon Apr 10 12:35:58 >> 2017 (r316678) +++ head/sys/arm64/arm64/pmap.c Mon Apr >> 10 15:32:26 2017 (r316679) @@ -2481,6 +2481,11 @@ >> pmap_protect(pmap_t pmap, vm_offset_t sv sva +=3D L3_SIZE) { >> l3 =3D pmap_load(l3p); >> if (pmap_l3_valid(l3)) { >> + if ((l3 & ATTR_SW_MANAGED) && >> + pmap_page_dirty(l3)) { >> + >> vm_page_dirty(PHYS_TO_VM_PAGE(l3 & >> + ~ATTR_MASK)); >> + } >> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >> PTE_SYNC(l3p); >> /* XXX: Use pmap_invalidate_range */ >>=20 >> . . . >>=20 >=20 > Thanks for this reference. I took a quick look at the 3 pmap > implementations we have (haven't check the new radix pmap yet), and it > looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is missing > vm_page_dirty() calls in its pmap_protect() implementation, analogous > to the change you posted right above. Given this, I think it's safe to > say that this missing piece is necessary. We'll work on a fix for > this; looking at moea64_protect(), there may be additional work needed > to support this as well, so it may take a few days. Ping? Any clue when the above might happen? I've been avoiding the old PowerMacs and leaving them at head -r360311 , pending an update that would avoid the kernel zeroing pages that it should not zero. But I've seen that you were busy with more modern contexts this last about a month. And, clearly, my own context has left pending (for much longer) other more involved activities (compared to just periodically updating to more recent FreeBSD vintages). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Jun 11 05:44:26 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CD11B34BD9A for ; Thu, 11 Jun 2020 05:44:26 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jCV23ZsJz45lt; Thu, 11 Jun 2020 05:44:26 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-wm1-x341.google.com with SMTP id d128so3791306wmc.1; Wed, 10 Jun 2020 22:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=iID5V756E6fneYB5rLTGVrPcLAxHafjKdp/psMdq8JQ=; b=gktB6ywrTFtHEupHNxM6MWDdH5VgcOKV+trRtQIPeyZnv6zLhDDCaehalx/kL689BF 2TT2swjwHJB+mBaacWgOF0KfZTLNJXI5PuHV4zfLBHEqwrYQEmtaq5zg4f97EdyszWMG yxaOAUvTIBh6HGoxmG1HBGGI4ki1nFEBlc80rBtUylbP6Sals95aUZ/4J9JLB93Brp/p 6yeFv28m7Awh948zVOdszSe30W4q8dkIjcpCrU5kXfQZ3aXznx3Y3cqXrGHvDW1OtIIP apr+AdB309DZxKH8blVw24+AVrLLwWuNvtQlRn5fEqMjzncNTM8yqg2t4qbQ7WebG2Rl RGyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iID5V756E6fneYB5rLTGVrPcLAxHafjKdp/psMdq8JQ=; b=AwZd5QPzrDuWVD5ADve+33wGUnk2NQuE96taZUTx5vdmcKHbZJBPS5fYpIvWGelH1o Nz10h4vBQMp5VHxlxgbLh74e2Zfsh0t0weuuFcm8VmsMuS3UiCdSAQ4EpVlzL8fKWpiV RlH6/qNeqImeKabBxavq/c+HtgQ44z5gIPgD926BykxXlAGnKu+yb/FhAMWS7COHjFl4 EUNupChHp5KKiR8w7EhG/NxlxUOiy9TvWMp3Plpe6Uopkhl/SOrHf/GdfnwacXXL/OJF oJ2M0lOychBao8SQ8anZAF+jkypLJ7EcDWFgy38cFTMAWov/R7a5dLNmMUyhMBF8YElO IrUw== X-Gm-Message-State: AOAM530emyg3NrPOU5UnDSWCPrpIGQcDKCjqi4/ERakZscfp6ksX5ucX NkrA1nXMvIqMvfppA1WBsTvKPE2qgXM= X-Google-Smtp-Source: ABdhPJyy7gtX7oELpAQE0h52Ce9ioABhO0oGplPvLEAWKUVPV4+4cAM/9tUIb+qhTOBGxsmi8NNwVg== X-Received: by 2002:a1c:6583:: with SMTP id z125mr6466726wmb.102.1591854264014; Wed, 10 Jun 2020 22:44:24 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id i3sm3105947wrm.83.2020.06.10.22.44.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 22:44:23 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Thu, 11 Jun 2020 08:44:21 +0300 To: Daniel Ebdrup Jensen Cc: freebsd-hackers@freebsd.org Subject: Re: WiFi with AC on FreeBSD Message-ID: <20200611084421.31322e1a@rimwks> In-Reply-To: <20200610075307.5r4ynpool6grwsj5@nerd-thinkpad.local> References: <20200610082552.0e08045c@rimwks> <20200610075307.5r4ynpool6grwsj5@nerd-thinkpad.local> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49jCV23ZsJz45lt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none 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-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 05:44:26 -0000 On Wed, 10 Jun 2020 09:53:07 +0200 Daniel Ebdrup Jensen wrote: > This is a very interesting draft, and it would be even better if it > could be included on the FreeBSD wiki [1], where it can be worked on > by more people. Ok, I will do this. > Have you thought about taking this one step further and making a very > small Linux appliance (ie. just the linux kernel with wpa_supplicant > and perhaps a few other utilities statically compiled)? I don't know > Linux well enough to know if it's possible, but it might even be > worth trying to set the values of the parameters you're changing via > kernel environment variables, if that's doable? I have no idea how to make and use "linux kernel + wpa_supplicant" :) OpenWRT can be rebuild (I suspect) with less ram and hdd requiremens, like 64-128 ram and 32-64 hdd. It is very strange for me that it can not boot if ram is less than 256mb. From owner-freebsd-hackers@freebsd.org Thu Jun 11 05:59:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D82CA34BFE1 for ; Thu, 11 Jun 2020 05:59:12 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jCq45Qf0z46rj for ; Thu, 11 Jun 2020 05:59:12 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id A58F7153ED; Thu, 11 Jun 2020 05:59:12 +0000 (UTC) Date: Thu, 11 Jun 2020 07:59:10 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: WiFi with AC on FreeBSD Message-ID: <20200611055910.ldk6nkqgoo4neg2d@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <20200610082552.0e08045c@rimwks> <20200610075307.5r4ynpool6grwsj5@nerd-thinkpad.local> <20200611084421.31322e1a@rimwks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y3e2m6kfenhcxpuf" Content-Disposition: inline In-Reply-To: <20200611084421.31322e1a@rimwks> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 05:59:12 -0000 --y3e2m6kfenhcxpuf Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 11, 2020 at 08:44:21AM +0300, Rozhuk Ivan wrote: >On Wed, 10 Jun 2020 09:53:07 +0200 >Daniel Ebdrup Jensen wrote: > >> This is a very interesting draft, and it would be even better if it >> could be included on the FreeBSD wiki [1], where it can be worked on >> by more people. > >Ok, I will do this. > > >> Have you thought about taking this one step further and making a very >> small Linux appliance (ie. just the linux kernel with wpa_supplicant >> and perhaps a few other utilities statically compiled)? I don't know >> Linux well enough to know if it's possible, but it might even be >> worth trying to set the values of the parameters you're changing via >> kernel environment variables, if that's doable? > >I have no idea how to make and use "linux kernel + wpa_supplicant" :) >OpenWRT can be rebuild (I suspect) with less ram and hdd requiremens, >like 64-128 ram and 32-64 hdd. It is very strange for me that it can >not boot if ram is less than 256mb. Yes, that is rather strange. I find [1] and [2] quite interesting, because those are some very low-memor= y=20 systems, and they only have the kernel plus a statically built wpa_supplica= nt,=20 as far as I know. I'll ask around a bit, I might know someone who can help. [1]: https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5250 [2]: https://dmesgd.nycbug.org/index.cgi?do=3Dview&id=3D5499 --y3e2m6kfenhcxpuf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl7hyC5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pHsgf/bVMkRTiW85uCxqnwGWvcvkGWEvxeE/R/xAkbbdXFV4yTxe0OdH55Kq6+ xDuy/30sz3GGhHBHw/kOMJA4R1KlLXQNsgnYIxYtI5fDCS95QhaRToqP+i83ouPE i9Y1Sz9N5gXsDnO2M+FxwokVuz3VdXJgz0gi3xEK2YeHmZnwIgM+Zl/kKCJNCGrg w5MckZLHL33pcjeadwW0LniMFY5xDaAStnPrsNM7U6+G7/+pgHnCUJRxl8Fcnas+ 0hL/DUqeVrh6SSF8Eu0gi2Rm6ZSi8uyD97uvvY2ZQaJ8WWmaqtAenJPMoYRDKu7O MRcMGT0IPBeD6LuAFzAxbvf2eBuQFg== =3z8i -----END PGP SIGNATURE----- --y3e2m6kfenhcxpuf-- From owner-freebsd-hackers@freebsd.org Thu Jun 11 08:30:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C1B6034F18A for ; Thu, 11 Jun 2020 08:30:29 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jH9c5nSXz4F6C for ; Thu, 11 Jun 2020 08:30:28 +0000 (UTC) (envelope-from shrikanth07@gmail.com) Received: by mail-wm1-x344.google.com with SMTP id u13so4160436wml.1 for ; Thu, 11 Jun 2020 01:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dQ+kYZJ5KorOOFBosBbFXoFQttZJl6rhwqJPWKd/fyU=; b=pDmTtZXbf99ggmsM9mq/9psAiAyL6kEzycTl7wuGYom0UxkeOkE8ayynMO8xvptzFX E6WmNsauCyzHZiGKHNGYOSytwogEQeKeleUoLr8riWr5zkPNXW4XPq9sZISoJKxSK1vk ZrB4xX2ppO2Ne+VWhISGEYylpGy1pBfvMPOELlkK+WEMOggMHXYEg/K3pVOWVjPmPSML bu2hivDcF97QfDHhfyomaBD/tvmZsGEX2YDlPZIt+lA8eo10SXsy7NwYAWj+Ov/Cbxz8 awVxfUTvSj24AONTRsnw7E4UFYLPh1cHZ/Ssx4nBSKvGHFaEqifxi31+bkSSJ2G7bPx7 Nr6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dQ+kYZJ5KorOOFBosBbFXoFQttZJl6rhwqJPWKd/fyU=; b=D6RhXT16A8qoz0S8VNDlhRVO5sxgHva/Rq3c/+ILIrlONC7l1im5WnYEiWvu0HYaGA dhZcDfck/KbwsiW5Pw6ZmJzBI86pSBuqG2z9H4SKqxMHnCqaqmpT6jyP/B1paXLQnsjj oshetYZ87Xfqd928MwT3s5uWSpYd/JKFm3x7wdXgLunwTTBIBberaDmCiY3V/6RYyrC/ jgZpTO5NpqDbflxBwbaoZllUcSOisml47G8sLC6voNNR+gsLtGU8qJTl92LWINW3TNhe X8acVJvFzMfY9UcCvKJPxHSnGXBOqVx1VGG1pJfAITC654lQT6/3YTNzIJGwtjXLOxr7 Qkog== X-Gm-Message-State: AOAM532ZDvutwhAxm9Y1yGMrWxhqMTAKPVImIp5h409LRzVs3CfcJcuc Wt+l5zR7RrdK6Rd7IPAU03Bx7gLegHG9yPL3mCOuYuZ4 X-Google-Smtp-Source: ABdhPJwybQ23H1r/FQmWSkhQmwRqyd3CZBufqtqEfMvQleOSuT3Uy49HBJuU5p7bh+/CpoT6qjndxg4cCjrx95f414M= X-Received: by 2002:a1c:b443:: with SMTP id d64mr6670230wmf.157.1591864226101; Thu, 11 Jun 2020 01:30:26 -0700 (PDT) MIME-Version: 1.0 From: Shrikanth Kamath Date: Thu, 11 Jun 2020 01:30:14 -0700 Message-ID: Subject: Xentimer/Lapic differences when used as a eventtimer source To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 49jH9c5nSXz4F6C X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pDmTtZXb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shrikanth07@gmail.com designates 2a00:1450:4864:20::344 as permitted sender) smtp.mailfrom=shrikanth07@gmail.com X-Spamd-Result: default: False [-2.68 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.028]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; 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)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997]; 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::344:from]; NEURAL_SPAM_SHORT(0.35)[0.346]; 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] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 08:30:29 -0000 Trying to understand the implementation differences for xentimer v/s lapic when used as eventtimer sources. I have 2 setups where there is FreeBSD 11.0 based Junos running in a virtual environment one on a xen based hypervisor and another kvm based. The xen version has xentimer as the eventtimer source v/s lapic for the kvm version. For an application that is doing nanosleep with same resolution of 100 ns and running on these two systems the rate of timer interrupts is order of magnitude different and hogs the cpu in case of lapic but for xentimer it is not as significant. Below I have listed some readings from dtrace probes I ran to understand, For xen setup using xentimer as eventtimer # sysctl kern.eventtimer kern.eventtimer.periodic: 0 kern.eventtimer.timer: XENTIMER kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: XENTIMER(950) LAPIC(100) i8254(100) RTC(0) kern.eventtimer.et.XENTIMER.quality: 950 kern.eventtimer.et.XENTIMER.frequency: 1000000000 kern.eventtimer.et.XENTIMER.flags: 6 For kvm setup using lapic as eventtimer # sysctl kern.eventtimer kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 kern.eventtimer.choice: LAPIC(600) RTC(0) kern.eventtimer.et.LAPIC.quality: 600 kern.eventtimer.et.LAPIC.frequency: 3000050812 kern.eventtimer.et.LAPIC.flags: 7 Running fbt::et_start:entry with conditional for execname to be the application and using an aggregation to count() calls, shows ~6K calls per second for xentimer v/s ~95K calls for lapic Trying to count number of timer interrupts on each with dtrace -n 'fbt:kernel-xen:xentimer_intr:entry /cpu != 0/ { @cnt[cpu] = count();} tick-1s { printa(@cnt); clear(@cnt);}' gives --> 6083 interrupts per second v/s dtrace -n 'fbt:kernel:lapic_handle_timer:entry /cpu != 0/ { @cnt[cpu] = count();} tick-1s { printa(@cnt); clear(@cnt);}' gives --> 99063 interrupts per second For xentimer #vmstat -i | grep :xen interrupt total rate cpu1:xen 3642296440 6084 v/s lapic # vmstat -i interrupt total rate cpu1:timer 61458150612 102715 Also does lapic source have additional overhead of VM entry/VM exit? -- Shrikanth R K From owner-freebsd-hackers@freebsd.org Thu Jun 11 15:14:19 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B0667334F64 for ; Thu, 11 Jun 2020 15:14:19 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jS7b4J5Nz3ZRK; Thu, 11 Jun 2020 15:14:19 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lj1-x242.google.com with SMTP id n23so7320032ljh.7; Thu, 11 Jun 2020 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=aJAwkqF92zAwUDl4bZ2C6LYdTvgCF5w1EyfbQ/T8aos=; b=hYQYxTQbfSYjppEb8U4OiMb8ZbTeKKUl8cGrLcRdWrq2K0y5mCLWzNIV9Iha5X1HgP wdRthzAKbfww10bz+eSw8uNSwSNZ2PxgaXy0CTFuWyTO0Ra0bsd8TaYm3TvwcNvaKiO/ N7DacIk7MTQ9b5bHbLjh/SSuJ3oVlH3EsUrtDmfUaKG1ANzPtoZ8tetr9pALHk8ga0e4 pPesR5q+nieYU1x3yhMTUp8OBp1MB8ELLzoKJB16FtxHmhmwcHj16nbR/fFk56drrCg7 aaBJGIDNjxlj2Tfru2giZFliQ0CNGiFPMZUKO2u4pCcAv2ZWecT/HahpR1escLtRsvP6 PndQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=aJAwkqF92zAwUDl4bZ2C6LYdTvgCF5w1EyfbQ/T8aos=; b=NJrlcMS+BP1OTiv5Pz2yTb0V7C76gLFqQHwkbFgFaLovIw+XYKFlc9ZpUhFGgFQKxt 49c/ofI8ZRkDhecI05HCnL/ydbfhvMlLt6IclfALeDX+Jm6O5Pdb/e/tOXQwGa9umeHQ zCB3Va76y4Ypmu1R0an3SOGaUqbtcykTu+ALo6oMSTKai5j2BykFcGqW/je2x3wKrOhQ s2d1j42reIhB5QmIZl1yt9454Q0g21kXI13gBMwIaEBHFoQ6/pDHFeLPFWqlpeYavjR1 kWb+FnnbZfFjXXn2T/pUcGoWc5q9EOlVjME22um+vK0R8ddwRC1yYruFF2v+ruVWgEQp qy5Q== X-Gm-Message-State: AOAM532Q1zMvEOdzleN6/mh0qaLinf8pMO3/o6cyRRkhK5enRCRRqXl/ qFg5k2U2wjh4Y1+dLPy7iTDv2/IYeic= X-Google-Smtp-Source: ABdhPJxbfMQTgbRQttdhWWgvFOLnoXIUgKdRFTTdJcpxLX2uzUFF4a6TxX+XE8PaQh0gF6jbYQcfIw== X-Received: by 2002:a2e:7303:: with SMTP id o3mr4906510ljc.100.1591888457526; Thu, 11 Jun 2020 08:14:17 -0700 (PDT) Received: from rimwks ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id l14sm782283lja.2.2020.06.11.08.14.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jun 2020 08:14:16 -0700 (PDT) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Thu, 11 Jun 2020 18:14:15 +0300 To: Daniel Ebdrup Jensen Cc: freebsd-hackers@freebsd.org Subject: Re: WiFi with AC on FreeBSD Message-ID: <20200611181415.18c7bf4d@rimwks> In-Reply-To: <20200611055910.ldk6nkqgoo4neg2d@nerd-thinkpad.local> References: <20200610082552.0e08045c@rimwks> <20200610075307.5r4ynpool6grwsj5@nerd-thinkpad.local> <20200611084421.31322e1a@rimwks> <20200611055910.ldk6nkqgoo4neg2d@nerd-thinkpad.local> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49jS7b4J5Nz3ZRK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none 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-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 15:14:19 -0000 On Thu, 11 Jun 2020 07:59:10 +0200 Daniel Ebdrup Jensen wrote: > >I have no idea how to make and use "linux kernel + wpa_supplicant" :) > >OpenWRT can be rebuild (I suspect) with less ram and hdd requiremens, > >like 64-128 ram and 32-64 hdd. It is very strange for me that it can > >not boot if ram is less than 256mb. > > Yes, that is rather strange. > > I find [1] and [2] quite interesting, because those are some very > low-memory systems, and they only have the kernel plus a statically > built wpa_supplicant, as far as I know. > > I'll ask around a bit, I might know someone who can help. > > [1]: https://dmesgd.nycbug.org/index.cgi?do=view&id=5250 > [2]: https://dmesgd.nycbug.org/index.cgi?do=view&id=5499 This is arm and mips, without most drivers, without EFI... OpenWRT minimum recomended: 64 ram + 8 flash for arm based devices. They also have builds for tl3020 with 32 ram + 4 flash, but this is hard to use :) I play with OpenWRT@EFI in VBox and minimum ram to boot - 137mb. From owner-freebsd-hackers@freebsd.org Thu Jun 11 21:36:47 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABFD3341C6E for ; Thu, 11 Jun 2020 21:36:47 +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 49jcct57cmz4QnK for ; Thu, 11 Jun 2020 21:36:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oMlrzEkVM1n0fQy94q7okPpe3jwvUEdPQCVGTq7two5lUxYwGoA00PDhSFfvZEV fL8tTKl9DnO7erx4D7Fk1gCOyvv_Wlar7eaZKlyH2.1fPy2P1f1RxnI_O1H2L_7q5H_MiUU4o1by fS31gZjNhXHLCtFStH9Yu2Zua59G7ZOQp9KILYuPKO2HfQSwrkjDxe0HxHhrWQXLkyAEpGOCrdPB tixhqaTKEZJTJYpRRVxzlNHj6hU.lx5GpPxCP4Oa.GRJi1oPYz.3ue_gxDTcoOACRZUkcj5h1E25 _yYhxJH02JqlneJC0kybfKXMRh9UllX36TUV7CZKrWluqLOTFjDRk8cDjhymRxbQJaid6I9abfPf hWVKGITG5XAj.91xH9jldjCL1vvlhfQQBiA7nCJOF59VJUImr6qle1Ly0f0Df8BIV5hcOg8hQ1bd dYsWynkfcP7n0bgMzflkQ823.oFjZ9X6WJhk.Do6h6E06NEF0uiQrTwPvQD0icPV6Byvdix14tOY mtuKVe6joAOd74Cu0eX6pjytREg5P94kRhZAOxrWclD7xM026vi3l05ZiW7F1rde.njtwd5MojU_ wBZC_eCI4jIMWwB_bbNjSFccu3Nki.XCLMhqO0kVyK0sQKjn.ZXSDDGQ.q1M1f34hbarWwA0na.P vK.S0ueW6.gnOQVGwOtwR184YGzhhFDD889cZ9PCnSWDdQMr83zS8tdKkrDPKZ4v1kxBNYjko6qH Misr0ln9ygcAPQEYGY0ynssLLaWq0hKMU3.ZzrPThigjvl2ZoT9qG1vo6ot_WitUm_j_whd1O3AE qsMXZyTN__NPXURKQeRTc1AuYZITSWHKbw0D8IzA1AH0Ku49oBP6icue5oBwwR5uZHSK22.n6Sg7 jDZ9udIgpEwjEwKqvMp84Kr9iMnKuFV0W5xp9_.2AnLlYsGj8J0sLA8QaPckzgpPw.L6r6ixTS8K r1WgMPWRdafAtd.65Sk3TEFhhcIjTnWtcgaPFDjykQ42Y.r8oxsFKV4fWdeUjfzYCEYvZdSAHiCw ICEvnScN9bvsplu_dIdhEbp2rAE5Da1uMQ1eWosMR9_caBjSWYcEq9iyR9EC4LWS6HRzShR_JJdk 5ZC_V05t70_9.JmxQ84i1WsLpKlNQ0KKp3Ioyyp2rmkcitmx8U8A72yasgWp1KaPCthHPqQCQKgu gc4cN1PxG1DGEQim.1x_YEbVT271OE17aoUZjqlah6ityZ_5r3s7BGWyBIf0RjNSdBekz2ylv4DT FD1fuoMYK747RPLTFgM4lUeunGOx_yYZ86MEFBSi5EGyJIwTwLXzNoKCJJ5mfnp2EM6JaQ5GzKa0 zsCYCLnj3rXizkTfIe8BYkvnUpAAW5js27jYX7MmCgKMfMazh4p8K4fWKkKuvat3sqQjlk8kGSFb wyi2uqxZeUebZ4YaDKpN57AKWO5TN Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2020 21:36:44 +0000 Received: by smtp416.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fdfd3dccc9714f1e32d72e6a803eab89; Thu, 11 Jun 2020 21:36:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <20200611155545.55526f7c@ralga.knownspace> Date: Thu, 11 Jun 2020 14:36:37 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jcct57cmz4QnK X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.14 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.63)[-0.635]; FREEMAIL_TO(0.00)[gmail.com]; 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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:36:47 -0000 On 2020-Jun-11, at 13:55, Justin Hibbits = wrote: > On Wed, 10 Jun 2020 18:56:57 -0700 > Mark Millard wrote: >=20 >> On 2020-May-13, at 08:56, Justin Hibbits = wrote: >>=20 >>> Hi Mark, =20 >>=20 >> Hello Justin. >=20 > Hi Mark, Hello again, Justin. >>=20 >>> On Wed, 13 May 2020 01:43:23 -0700 >>> Mark Millard wrote: >>>=20 >>>> [I'm adding a reference to an old arm64/aarch64 bug that had >>>> pages turning to zero, in case this 32-bit powerpc issue is >>>> somewhat analogous.] >>>>=20 >>>>> . . . =20 >>> ... =20 >>>> . . . >>>>=20 >>>> (Note: dsl-only.net closed down, so the E-mail >>>> address reference is no longer valid.) >>>>=20 >>>> Author: kib >>>> Date: Mon Apr 10 15:32:26 2017 >>>> New Revision: 316679 >>>> URL:=20 >>>> https://svnweb.freebsd.org/changeset/base/316679 >>>>=20 >>>>=20 >>>> Log: >>>> Do not lose dirty bits for removing PROT_WRITE on arm64. >>>>=20 >>>> Arm64 pmap interprets accessed writable ptes as modified, since >>>> ARMv8.0 does not track Dirty Bit Modifier in hardware. If writable >>>> bit is removed, page must be marked as dirty for MI VM. >>>>=20 >>>> This change is most important for COW, where fork caused losing >>>> content of the dirty pages which were not yet scanned by >>>> pagedaemon. >>>>=20 >>>> Reviewed by: alc, andrew >>>> Reported and tested by: Mark Millard >>> dsl-only.net> PR: 217138, 217239 >>>> Sponsored by: The FreeBSD Foundation >>>> MFC after: 2 weeks >>>>=20 >>>> Modified: >>>> head/sys/arm64/arm64/pmap.c >>>>=20 >>>> Modified: head/sys/arm64/arm64/pmap.c >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>> --- head/sys/arm64/arm64/pmap.c Mon Apr 10 12:35:58 >>>> 2017 (r316678) +++ head/sys/arm64/arm64/pmap.c Mon >>>> Apr 10 15:32:26 2017 (r316679) @@ -2481,6 +2481,11 @@ >>>> pmap_protect(pmap_t pmap, vm_offset_t sv sva +=3D L3_SIZE) { >>>> l3 =3D pmap_load(l3p); >>>> if (pmap_l3_valid(l3)) { >>>> + if ((l3 & ATTR_SW_MANAGED) && >>>> + pmap_page_dirty(l3)) { >>>> + >>>> vm_page_dirty(PHYS_TO_VM_PAGE(l3 & >>>> + ~ATTR_MASK)); >>>> + } >>>> pmap_set(l3p, ATTR_AP(ATTR_AP_RO)); >>>> PTE_SYNC(l3p); >>>> /* XXX: Use pmap_invalidate_range >>>> */ >>>>=20 >>>> . . . >>>>=20 >>>=20 >>> Thanks for this reference. I took a quick look at the 3 pmap >>> implementations we have (haven't check the new radix pmap yet), and >>> it looks like only mmu_oea.c (32-bit AIM pmap, for G3 and G4) is >>> missing vm_page_dirty() calls in its pmap_protect() implementation, >>> analogous to the change you posted right above. Given this, I think >>> it's safe to say that this missing piece is necessary. We'll work >>> on a fix for this; looking at moea64_protect(), there may be >>> additional work needed to support this as well, so it may take a >>> few days. =20 >>=20 >> Ping? Any clue when the above might happen? >>=20 >> I've been avoiding the old PowerMacs and leaving >> them at head -r360311 , pending an update that >> would avoid the kernel zeroing pages that it >> should not zero. But I've seen that you were busy >> with more modern contexts this last about a month. >>=20 >> And, clearly, my own context has left pending >> (for much longer) other more involved activities >> (compared to just periodically updating to >> more recent FreeBSD vintages). >>=20 >> . . . >>=20 >=20 > Sorry for the delay, I got sidetracked with a bunch of other > development. > I did install a newer FreeBSD on my dual G4 and couldn't > see the problem. How did you test? In my context it was far easier to see the problem with builds that did not use MALLOC_PRODUCTION. In other words: jemalloc having its asserts tested. The easiest way I found to get the asserts to fail was to do (multiple processes (-m) and totaling to more than enough to force paging/swapping): stress -m 2 --vm-bytes 1700M & (Possibly setting up some shells first to potentially later exit.) Normally stress itself would hit jemalloc asserts. Apparently the asserts did not stop the code and it ran until a failure occurred (via dtv=3D0x0). I never had to manually stop the stress processes. If no failures during, then exit shells that likely were swapped out or partially paged out during the stress run. They hit jemalloc asserts during their cleanup activity in my testing. > That said, the attached patch effectively copies > what's done in OEA6464 into OEA pmap. Can you test it? I'll try it once I get a chance, probably later today. I gather from what I see that moea64_protect did not need the changes that you originally thought might be required? I only see moea_protect changes in the patch. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Jun 11 21:42:20 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA7563423F6; Thu, 11 Jun 2020 21:42:20 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49jclJ45plz4RQl; Thu, 11 Jun 2020 21:42:20 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bdragon/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 823D91F74B; Thu, 11 Jun 2020 21:42:20 +0000 (UTC) (envelope-from bdragon@FreeBSD.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 0D19A27C0054; Thu, 11 Jun 2020 17:42:20 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute4.internal (MEProxy); Thu, 11 Jun 2020 17:42:20 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeitddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdluddtmdenucfjughrpefofgggkfgjfhffhffvufgtsehttdertder reejnecuhfhrohhmpedfuehrrghnughonhcuuegvrhhgrhgvnhdfuceosggurhgrghhonh eshfhrvggvuefuffdrohhrgheqnecuggftrfgrthhtvghrnhepteefveelueekieeltedv jeeuuedutdfgtddviefhgeekhfeuledtteelvdffffetnecuffhomhgrihhnpegushhlqd honhhlhidrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegsughrrghgohhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqd dutdegvdefheekieegqddukedutdekheduqdgsughrrghgohhnpeephfhrvggvuefuffdr ohhrghesihhmrghprdgttg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D5332C200A6; Thu, 11 Jun 2020 17:42:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <8bf74674-4ccf-4f97-bbc5-fa5131209b66@www.fastmail.com> In-Reply-To: <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> Date: Thu, 11 Jun 2020 16:41:59 -0500 From: "Brandon Bergren" To: "Mark Millard" , "Justin Hibbits" Cc: "Eric van Gyzen" , svn-src-head@freebsd.org, "FreeBSD Current" , "FreeBSD Hackers" , "FreeBSD PowerPC ML" Subject: =?UTF-8?Q?Re:_svn_commit:_r360233_-_in_head:_contrib/jemalloc_._._._:_Th?= =?UTF-8?Q?is_partially_breaks_a_2-socket_32-bit_powerpc_(old_PowerMac_G?= =?UTF-8?Q?4)_based_on_head_-r360311?= Content-Type: text/plain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 21:42:20 -0000 An update from my end: I now have the ability to test dual processor G4 as well, now that mine is up and running. On Thu, Jun 11, 2020, at 4:36 PM, Mark Millard wrote: > > How did you test? > > In my context it was far easier to see the problem > with builds that did not use MALLOC_PRODUCTION. In > other words: jemalloc having its asserts tested. > > The easiest way I found to get the asserts to fail > was to do (multiple processes (-m) and totaling to > more than enough to force paging/swapping): > > stress -m 2 --vm-bytes 1700M & > > (Possibly setting up some shells first > to potentially later exit.) > > Normally stress itself would hit jemalloc > asserts. Apparently the asserts did not > stop the code and it ran until a failure > occurred (via dtv=0x0). I never had to > manually stop the stress processes. > > If no failures during, then exit shells > that likely were swapped out or partially > paged out during the stress run. They > hit jemalloc asserts during their cleanup > activity in my testing. > > > > That said, the attached patch effectively copies > > what's done in OEA6464 into OEA pmap. Can you test it? > > I'll try it once I get a chance, probably later > today. > > I gather from what I see that moea64_protect did not > need the changes that you originally thought might > be required? I only see moea_protect changes in the > patch. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Brandon Bergren bdragon@FreeBSD.org From owner-freebsd-hackers@freebsd.org Thu Jun 11 22:04:19 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 390D33430EF for ; Thu, 11 Jun 2020 22:04:19 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49jdDf0t1Kz4TcR for ; Thu, 11 Jun 2020 22:04:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 3oKnKC4VM1lYGbS2O.u1wktRLDRU3MpiMqXIjh4dvuwHa6Xa31BcqeOaAnYEkna KgaMLTs5p9sqvgW.RjjxXYAYJV_6iypseBy49dFp5GhbRsJCpQNNmO6YvGDG41HQIOfEPglmyPik aV4UMifLCBUIWxL6u_K6BACbAvvUnI5FsjDAz.wZTX.UYeDMA65WgzCdP3KmvJvecdk_9BPZbL4J mGIz95E8oulC1mmypm9MPQOPMUyRpgJ3CQZepvvRYWc28Z_yc9XFZ70dUerzNBB0PEFmKt3th.1t AUIAfE9QRVhuyWUcFAg5OHE6ub.5SKbZEectpOWSMO4PxpfT6kUO6cwEtUADP3zoD24aq1elLkGm 7z9XAvXtjo0IPiCmScio_QcE46rCvDuY2zWVIdSJwy3GOYTcV63i6CvQ0uMZKLdEa.y4A5T7vxLg K0m_lWVTOuf4NTVp07JeWzKHcD9CIgYpDZMj1eO.6wusSnDxL0vG6tp1MVbRIBjAIWw2PRfluS0M YaMDNeLEPu8If2Mq92x422oajBAuVtitunhITSCS9cUsbtOTPTBTPgPwJ40xc1sSlX9TCRskvSls Ko6LYt15MmaKXGzsLpXleHQE9391B3kVamWO7pzKKW3K79M3fLuvZp6NWyYKViZ3br0WsroLmcHI lPIKMFw2co1lj5kTWm6UCL3eIOZTWaJCtxH7yWLBrFx0GwveGXUuMYZom7W6XGPZMAJl.vgpLEpa zdhgmRcRvIsJuLoi6yKRwc62vdsJgvJEJu2.NvybfLEXllq5iezyQNYAXJVew6Wud__D59KRIPUr z2fF3ntD_L6CdOlgn3yDFfSYgSUdWCd3gSDIifrlPLY72tojn5yKkleN0rCeoUcCvKL3fI6JErgA 7qAvxDqcuT9HtREMplYj1uRNxej2jSgGz2NRLe7C2v8aAHmzOlh7.e.afuna8QU9T3Z2hiicPK7x v3OA7SUBXV71ysDnoMLMsrLycD_WeezneyBGFCUtq33kTL4WKcAYIv2eHqqeQtLb1.2XNYRtzoQM jCWRSrLxc0m_OWrBOsnai9aTrl6x3pK6HJraAhw_0CWflO5EnDZxw64JsoO3A00aSBMFhy94i5M3 nCvT2U217s0mXtCnMIsr6OiX0gFvwcvPgeJN1_WtBmNtnCl7eCqJu9TbdKTjCLbRdW3DGeZDlU_3 G9u_Z8oYXa6YgMiChWbUGP1M.IrpCOUpICayDRBMnzOfYDY1nxdI.yJ9_ctCVhE9m6yVPxXHrRcN um9MK9xGsfG3ZT6sS3_Bdyu21nRRLoUTXiX5DBqczNXCzakA4Koo6h7OffWPbUBjSZulgijSVXqy VPZEVSM9_Ii3tcYldBKKGe3Z8DT_SY3YtQW40Xc95WejaRKf.cheiyChw7Amdyt1S6XXP7VfHF6a aAN46ixpzMEYRDMHsAO.LXwUGvYaY1h9QhYNyFSq6stWEDUv_UC6vuodWu7lC5XOwGQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2020 22:04:16 +0000 Received: by smtp425.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 172ccf42c5eb921977547f6477b474b1; Thu, 11 Jun 2020 22:04:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <8bf74674-4ccf-4f97-bbc5-fa5131209b66@www.fastmail.com> Date: Thu, 11 Jun 2020 15:04:11 -0700 Cc: Justin Hibbits , Eric van Gyzen , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1C6209E6-E980-407B-B635-B76C5F192E8C@yahoo.com> References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <8bf74674-4ccf-4f97-bbc5-fa5131209b66@www.fastmail.com> To: Brandon Bergren X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jdDf0t1Kz4TcR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 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]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.65)[-0.654]; 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/21, 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.004]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.148:from]; FREEMAIL_CC(0.00)[gmail.com,FreeBSD.org,freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 22:04:19 -0000 On 2020-Jun-11, at 14:41, Brandon Bergren = wrote: > An update from my end: I now have the ability to test dual processor = G4 as well, now that mine is up and running. Cool. FYI: Dual processors are not required for the problem to happen: the stress based testing showed the problem just as easily on the single-socket/single-core contexts that I tried. > On Thu, Jun 11, 2020, at 4:36 PM, Mark Millard wrote: >>=20 >> How did you test? >>=20 >> In my context it was far easier to see the problem >> with builds that did not use MALLOC_PRODUCTION. In >> other words: jemalloc having its asserts tested. >>=20 >> The easiest way I found to get the asserts to fail >> was to do (multiple processes (-m) and totaling to >> more than enough to force paging/swapping): >>=20 >> stress -m 2 --vm-bytes 1700M & >>=20 >> (Possibly setting up some shells first >> to potentially later exit.) >>=20 >> Normally stress itself would hit jemalloc >> asserts. Apparently the asserts did not >> stop the code and it ran until a failure >> occurred (via dtv=3D0x0). I never had to >> manually stop the stress processes. >>=20 >> If no failures during, then exit shells >> that likely were swapped out or partially >> paged out during the stress run. They >> hit jemalloc asserts during their cleanup >> activity in my testing. >>=20 >>=20 >>> That said, the attached patch effectively copies >>> what's done in OEA6464 into OEA pmap. Can you test it? >>=20 >> I'll try it once I get a chance, probably later >> today. >>=20 >> I gather from what I see that moea64_protect did not >> need the changes that you originally thought might >> be required? I only see moea_protect changes in the >> patch. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Jun 11 23:49:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 187D4345334 for ; Thu, 11 Jun 2020 23:49:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49jgZC3y06z4ZvG for ; Thu, 11 Jun 2020 23:49:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: He.9TQYVM1mhX3UkSY6ZD9dDWgF8Cb3EkBYcNWmoOYnkr2J0VxnM.NrbIt48x9_ SivTGNX3zV7_7jctFE3O9SBDJbjeEjKMUkQi76qUKYddzTXLfVsKezxBNssv53H_rFA5amXS7ZcU LeLY7Mrj9CH00.MdgeklKnRO8R0OfZvWyUGFYNzQt7rb.ZUlggoFSQ5LCFYoDbgu36l0pKNx5dvh cK3CYPJ_LdUesq3HNe.AVBt8TzeMoetTJ0Sxdu9qeYVO1qN2LApYrgcjZTjP4P0D5Kh9sKwGhW7w pQ2C7aGfkLPFBRP3qsihLU8kKmgqV4gHmj3nblp4RqPNcN9sSX2xbPKK6t3gMnKkflHr.8JrMpju kMOhLNIHumgjlx2zA3y7JSKK39UD44WbG8P_mTNN7jAG0jypjx77wvcZz3Wd22Md6lhV9zQuSSB3 U48dNnN7e0oKRmpPwpxiqaNG3kNDCJf29YSp9vZWfvtLRFip8LRi.zawSGyNnsoYxNLB3ZD536vb Pd7HwhY84OoEp2DFX5sbESp9JK7sswE0vhSvhHSar6jLs1cXSWkIWbe7R5AUlTJjsFMq3jXgATU9 3rpEFGZwjBEVtN7UaiFtg6M50LK.pxOxChhwpVIKn9SRCMDrn2EWbC6UMH6KWvM7FJI0AbTrJeSY UEMwWyfpYLiezxi7JR5I4EFZDBJyvgVG0Wq2UhdEQQJaW67r0nVNeQqmOX7XLTEKqOmIoxXDK3K. h4uJpJD6MYASclWLIwtFMUQlMRPfEVU5.CbpbekJFFXM.vakt1qpxzijCWFL4TYlcEWlK97Kg8qK KH28Sp1d1VCk56bxE4dM.FBtJneMbRDRfae2t9OcTwO3LkT05.VkV27DQVsXo68KxNs8YW09cazj uJKbrsJtq0iN1XAEoOsM2vf26ULRFRgQ4DSFD6s04SiT_n_FmkXTfI.uvsshkQhgFZz5_BYovfZy T4YWfEVIDUZ5NSoKefweuuFtqMdoauYbvziRtwzfpGRvgHfD34PJTtY9X2F6XMl3ijx9N_HnrfZY nlXZiDsJ2zj9TvX0l5H09yt_A_lLsRdb0SP3UwV7A_vebgJI8X3IaZ.S9y2q7kAS.VUNkcVaIyth FYRMVwkyr3pmIYHddSl9AuqVRWIM33VKSdJsS804vEiradp7PBEN5UMrCboOp5HbhFbo9YHst_5o ZbpTcjGQJkIG0s8m70ZkiZVsoFT.DUjmxg1W6k15ffA3.ZlApvTcxQ5hEKQiqwYpZKfp6jVCvpCj QdBWPWGQ0fVOLVFCnZOFeNa.wqe0YogvXmHyz.JHKZs_ZoQZ52S_4ppYFzuBbsS97IqLEuBG2PnX FWJ1xzVLZ6g9M58_lqH.S0hGL7Cok6sZ9UA7EOh43jDsqBmr7JV6PnY.wEsUjfWLj9Kjwhjxh9lX ySgJWtVMr_xzfRL.1h0VZi.hkN1io2cg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2020 23:49:37 +0000 Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7a484c8b324b68c03576f32441dbcc44; Thu, 11 Jun 2020 23:49:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <20200611164216.47f82775@ralga.knownspace> Date: Thu, 11 Jun 2020 16:49:33 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jgZC3y06z4ZvG X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.89)[-0.892]; FREEMAIL_TO(0.00)[gmail.com]; 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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 23:49:41 -0000 On 2020-Jun-11, at 14:42, Justin Hibbits = wrote: On Thu, 11 Jun 2020 14:36:37 -0700 Mark Millard wrote: > On 2020-Jun-11, at 13:55, Justin Hibbits > wrote: >=20 >> On Wed, 10 Jun 2020 18:56:57 -0700 >> Mark Millard wrote: . . . >=20 >=20 >> That said, the attached patch effectively copies >> what's done in OEA6464 into OEA pmap. Can you test it? =20 >=20 > I'll try it once I get a chance, probably later > today. > . . . No luck at the change being a fix, I'm afraid. I verified that the build ended up with 00926cb0 bl 008e8dc8 00926cb4 mr r27,r3 00926cb8 addi r3,r3,36 00926cbc hwsync 00926cc0 lwarx r25,0,r3 00926cc4 li r4,0 00926cc8 stwcx. r4,0,r3 00926ccc bne- 00926cc0 00926cd0 andi. r3,r25,128 00926cd4 beq 00926ce0 00926cd8 mr r3,r27 00926cdc bl 008e9874 in the installed kernel. So I doubt a mis-build would be involved. It is a head -r360311 based context still. World is without MALLOC_PRODUCTION so that jemalloc code executes its asserts, catching more and earlier than otherwise. First test . . . The only thing that the witness kernel reported was: Jun 11 15:58:16 FBSDG4S2 kernel: lock order reversal: Jun 11 15:58:16 FBSDG4S2 kernel: 1st 0x216fb00 Mountpoints (UMA zone) @ = /usr/src/sys/vm/uma_core.c:4387 Jun 11 15:58:16 FBSDG4S2 kernel: 2nd 0x1192d2c kernelpmap (kernelpmap) = @ /usr/src/sys/powerpc/aim/mmu_oea.c:1524 Jun 11 15:58:16 FBSDG4S2 kernel: stack backtrace: Jun 11 15:58:16 FBSDG4S2 kernel: #0 0x5ec164 at witness_debugger+0x94 Jun 11 15:58:16 FBSDG4S2 kernel: #1 0x5ebe3c at witness_checkorder+0xb50 Jun 11 15:58:16 FBSDG4S2 kernel: #2 0x536d5c at __mtx_lock_flags+0xcc Jun 11 15:58:16 FBSDG4S2 kernel: #3 0x92636c at moea_kextract+0x5c Jun 11 15:58:16 FBSDG4S2 kernel: #4 0x965d30 at pmap_kextract+0x98 Jun 11 15:58:16 FBSDG4S2 kernel: #5 0x8bfdbc at zone_release+0xf0 Jun 11 15:58:16 FBSDG4S2 kernel: #6 0x8c7854 at bucket_drain+0x2f0 Jun 11 15:58:16 FBSDG4S2 kernel: #7 0x8c728c at bucket_free+0x54 Jun 11 15:58:16 FBSDG4S2 kernel: #8 0x8c74fc at = bucket_cache_reclaim+0x1bc Jun 11 15:58:16 FBSDG4S2 kernel: #9 0x8c7004 at zone_reclaim+0x128 Jun 11 15:58:16 FBSDG4S2 kernel: #10 0x8c3a40 at uma_reclaim+0x170 Jun 11 15:58:16 FBSDG4S2 kernel: #11 0x8c3f70 at uma_reclaim_worker+0x68 Jun 11 15:58:16 FBSDG4S2 kernel: #12 0x50fbac at fork_exit+0xb0 Jun 11 15:58:16 FBSDG4S2 kernel: #13 0x9684ac at fork_trampoline+0xc The processes that were hit were listed as: Jun 11 15:59:11 FBSDG4S2 kernel: pid 971 (cron), jid 0, uid 0: exited on = signal 11 (core dumped) Jun 11 16:02:59 FBSDG4S2 kernel: pid 1111 (stress), jid 0, uid 0: exited = on signal 6 (core dumped) Jun 11 16:03:27 FBSDG4S2 kernel: pid 871 (mountd), jid 0, uid 0: exited = on signal 6 (core dumped) Jun 11 16:03:40 FBSDG4S2 kernel: pid 1065 (su), jid 0, uid 0: exited on = signal 6 Jun 11 16:04:13 FBSDG4S2 kernel: pid 1088 (su), jid 0, uid 0: exited on = signal 6 Jun 11 16:04:28 FBSDG4S2 kernel: pid 968 (sshd), jid 0, uid 0: exited on = signal 6 Jun 11 16:05:42 FBSDG4S2 kernel: pid 1028 (login), jid 0, uid 0: exited = on signal 6 Jun 11 16:05:46 FBSDG4S2 kernel: pid 873 (nfsd), jid 0, uid 0: exited on = signal 6 (core dumped) Rebooting and rerunning and showing the stress output and such (I did not capture copies during the first test, but the first test had similar messages at the same sort of points): Second test . . . # stress -m 2 --vm-bytes 1700M stress: info: [1166] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" ^C # exit : = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: Failed = assertion: "ret =3D=3D sz_index2size_compute(index)" Abort trap The other stuff was similar to to first test, not repeated here. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 00:30:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BC2C8346AD4 for ; Fri, 12 Jun 2020 00:30:29 +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 49jhTJ1F8Qz4dC2 for ; Fri, 12 Jun 2020 00:30:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YRjKgZ8VM1nz1gmprGN5LHFr7c2ibc7p8GI71NzCZGXTHdzsyZR0vQwHLwPa7AB bYghn03LipAom3UDNW_Q2cQuWn9XgM5DnTGlgCTXl2Wa3Z9HFd3DmIOY2_ysSmEQ.Oeh8ar4wjSt H2ECt..1MXRVRKV5aAQGLl_a.JINY9SQfnYzg5WLKFewIALgETnCy5290ACMFykqHsY8Ti0GxePq PcfnZEM7kMNRE.yR_K6TY6tiqEh2NHuCrLSguIly.fag_GtIkgVTOQ2eRHGUhSEbAtT9.6GSZ6i_ X00wrvE3HjBUUTPCT8BuBemZVigBjsSx33dX98JsihM_WtJLiNYwUgwaxBQknJ2Z_8iugFOrM2OH Irqz9jLGoV4xO_loLjzF4gaAmzcVNXHePPHLnIEdflC4EPSU7.S15xl8E0_q.J4urQjWiqswcxi_ UZ62T_qN2IURrmbceorIo8QZVBJOwehjwrgFKK4V7dXoWDkPySCWqvXxVXl5n3k_SSljrYAxYumf 9GYlPpS7OXSMhdQ2.wHhU4WrmMSfudpJpEv5xgzv.aS2eNVpKSacc21_AjFVz6YBSjLBLbq1swN7 P4sepPNBuDUJ28VuwHcsiWGZK27cl7KLQMdUv1ZHx88SscE1lffueNxy.WHwktmECdU3iqJEFif9 9X1226AOzW5ZJfBtwPm9dqqWtPE7r3qD4_k4Ux_R99OJiAoHjg8IRFsvIP3ic_pJGpmmX3SlgrMA 6rRANDypWVdvWy9h_RMqg20fdyRyQHBh8S5QHF0Q8ZIkRq4aaEn3k8auG4U7lf3_qEIXDLLYw5Zv PMoDFlv5x77KhYdcn7B7ptwLgGg.kXiKxE0CqotkRJS5GAJEFZZwROi0lAGUE9125jdCUMVQptkt mfM9iDyhBnN1tI3pRo3.O6kAA5jtPVQ0Z2M3DYU2qtVFbnloS8JNT1vCpRwbBVZ_C2RK7F8he6oU O.2y9n0Kgm_I5LSOhpG_kvURahhRNtNuPV.Ly0XTd4pZMjcgMVxbOmOAxjdUzMdPCIpOnM1kS8bA FD980GhZofJlwaWY.e7lI.WfOrOHckJovI8suv3y7FUCInGlUshHE8c5q.P72NLynSb0mfBEPjCE j4jZmFFatRjR.iBK.j5ccgpv10lj6fz66U.iKRDvIXS.KmErysrhKzCMT1qpq2p996qCpKcRLk4s 9jlwaUo_7_mspyx_2Hv01lcg1NIBS4fCgtPsNMi3OH7px84.i6QtDFLzQlQ0HAr_AGIiu4oqNXl8 ZBlRXjH0HLu2EnYM_KYkF_A6lIomSaIJpmoVG8Lge8Ub82MeNtvZQWVj860vD0a2JzYKEWZA6REQ Tr_vabjuSf.kKWZQAGGBJc8WLl1q0CjfIVr23Ffus4_7KsuEpDGW3NHvyRljmCp7ZK._23uKIrmr dWSew1eFYyurdVlR32tWiWaXDTAPeIIHBYzIDTB7X4uz8MDzwQHiUPByJ9Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Fri, 12 Jun 2020 00:30:26 +0000 Received: by smtp428.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1f421ce3a9c01e05f91777c49cc0466a; Fri, 12 Jun 2020 00:30:25 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Thu, 11 Jun 2020 17:30:24 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: References: <8479DD58-44F6-446A-9CA5-D01F0F7C1B38@yahoo.com> <17ACDA02-D7EF-4F26-874A-BB3E935CD072@yahoo.com> <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jhTJ1F8Qz4dC2 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.12 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.61)[-0.614]; FREEMAIL_TO(0.00)[gmail.com]; 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/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.206:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.64.206:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 00:30:29 -0000 On 2020-Jun-11, at 16:49, Mark Millard wrote: > On 2020-Jun-11, at 14:42, Justin Hibbits = wrote: >=20 > On Thu, 11 Jun 2020 14:36:37 -0700 > Mark Millard wrote: >=20 >> On 2020-Jun-11, at 13:55, Justin Hibbits >> wrote: >>=20 >>> On Wed, 10 Jun 2020 18:56:57 -0700 >>> Mark Millard wrote: > . . . >>=20 >>=20 >>> That said, the attached patch effectively copies >>> what's done in OEA6464 into OEA pmap. Can you test it? =20 >>=20 >> I'll try it once I get a chance, probably later >> today. >> . . . >=20 > No luck at the change being a fix, I'm afraid. >=20 > I verified that the build ended up with >=20 > 00926cb0 bl 008e8dc8 > 00926cb4 mr r27,r3 > 00926cb8 addi r3,r3,36 > 00926cbc hwsync > 00926cc0 lwarx r25,0,r3 > 00926cc4 li r4,0 > 00926cc8 stwcx. r4,0,r3 > 00926ccc bne- 00926cc0 > 00926cd0 andi. r3,r25,128 > 00926cd4 beq 00926ce0 > 00926cd8 mr r3,r27 > 00926cdc bl 008e9874 >=20 > in the installed kernel. So I doubt a > mis-build would be involved. It is a > head -r360311 based context still. World is > without MALLOC_PRODUCTION so that jemalloc > code executes its asserts, catching more > and earlier than otherwise. >=20 > First test . . . >=20 > The only thing that the witness kernel reported was: >=20 > Jun 11 15:58:16 FBSDG4S2 kernel: lock order reversal: > Jun 11 15:58:16 FBSDG4S2 kernel: 1st 0x216fb00 Mountpoints (UMA zone) = @ /usr/src/sys/vm/uma_core.c:4387 > Jun 11 15:58:16 FBSDG4S2 kernel: 2nd 0x1192d2c kernelpmap = (kernelpmap) @ /usr/src/sys/powerpc/aim/mmu_oea.c:1524 > Jun 11 15:58:16 FBSDG4S2 kernel: stack backtrace: > Jun 11 15:58:16 FBSDG4S2 kernel: #0 0x5ec164 at witness_debugger+0x94 > Jun 11 15:58:16 FBSDG4S2 kernel: #1 0x5ebe3c at = witness_checkorder+0xb50 > Jun 11 15:58:16 FBSDG4S2 kernel: #2 0x536d5c at __mtx_lock_flags+0xcc > Jun 11 15:58:16 FBSDG4S2 kernel: #3 0x92636c at moea_kextract+0x5c > Jun 11 15:58:16 FBSDG4S2 kernel: #4 0x965d30 at pmap_kextract+0x98 > Jun 11 15:58:16 FBSDG4S2 kernel: #5 0x8bfdbc at zone_release+0xf0 > Jun 11 15:58:16 FBSDG4S2 kernel: #6 0x8c7854 at bucket_drain+0x2f0 > Jun 11 15:58:16 FBSDG4S2 kernel: #7 0x8c728c at bucket_free+0x54 > Jun 11 15:58:16 FBSDG4S2 kernel: #8 0x8c74fc at = bucket_cache_reclaim+0x1bc > Jun 11 15:58:16 FBSDG4S2 kernel: #9 0x8c7004 at zone_reclaim+0x128 > Jun 11 15:58:16 FBSDG4S2 kernel: #10 0x8c3a40 at uma_reclaim+0x170 > Jun 11 15:58:16 FBSDG4S2 kernel: #11 0x8c3f70 at = uma_reclaim_worker+0x68 > Jun 11 15:58:16 FBSDG4S2 kernel: #12 0x50fbac at fork_exit+0xb0 > Jun 11 15:58:16 FBSDG4S2 kernel: #13 0x9684ac at fork_trampoline+0xc >=20 > The processes that were hit were listed as: >=20 > Jun 11 15:59:11 FBSDG4S2 kernel: pid 971 (cron), jid 0, uid 0: exited = on signal 11 (core dumped) > Jun 11 16:02:59 FBSDG4S2 kernel: pid 1111 (stress), jid 0, uid 0: = exited on signal 6 (core dumped) > Jun 11 16:03:27 FBSDG4S2 kernel: pid 871 (mountd), jid 0, uid 0: = exited on signal 6 (core dumped) > Jun 11 16:03:40 FBSDG4S2 kernel: pid 1065 (su), jid 0, uid 0: exited = on signal 6 > Jun 11 16:04:13 FBSDG4S2 kernel: pid 1088 (su), jid 0, uid 0: exited = on signal 6 > Jun 11 16:04:28 FBSDG4S2 kernel: pid 968 (sshd), jid 0, uid 0: exited = on signal 6 >=20 > Jun 11 16:05:42 FBSDG4S2 kernel: pid 1028 (login), jid 0, uid 0: = exited on signal 6 >=20 > Jun 11 16:05:46 FBSDG4S2 kernel: pid 873 (nfsd), jid 0, uid 0: exited = on signal 6 (core dumped) >=20 >=20 > Rebooting and rerunning and showing the stress output and such > (I did not capture copies during the first test, but the first > test had similar messages at the same sort of points): >=20 > Second test . . . >=20 > # stress -m 2 --vm-bytes 1700M > stress: info: [1166] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= Failed assertion: "slab =3D=3D extent_slab_get(extent)" > ^C >=20 > # exit > : = /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: Failed = assertion: "ret =3D=3D sz_index2size_compute(index)" > Abort trap >=20 > The other stuff was similar to to first test, not repeated here. The updated code looks odd to me for how "m" is handled (part of a egrep to ensure I show all the usage of m): moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, vm_page_t m; if (pm !=3D kernel_pmap && m !=3D NULL && (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && if ((m->oflags & VPO_UNMANAGED) =3D=3D = 0) vm_page_aflag_set(m, = PGA_EXECUTABLE); m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & = PTE_RPGN); refchg =3D = atomic_readandclear_32(&m->md.mdpg_attrs); vm_page_dirty(m); vm_page_aflag_set(m, = PGA_REFERENCED); Or more completely, with notes mixed in: void=20 moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, vm_prot_t prot) { . . . vm_page_t m; . . . for (pvo =3D RB_NFIND(pvo_tree, &pm->pmap_pvo, &key); pvo !=3D NULL && PVO_VADDR(pvo) < eva; pvo =3D tpvo) { . . . if (pt !=3D NULL) { . . . if (pm !=3D kernel_pmap && m !=3D NULL && NOTE: m seems to be uninitialized but tested for being NULL above. (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && Note: This looks to potentially be using a random, non-NULL value for m during evaluation of m->a.flags . . . . if ((pvo->pvo_vaddr & PVO_MANAGED) && (pvo->pvo_pte.prot & VM_PROT_WRITE)) { m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & = PTE_RPGN); Note: m finally is potentially initialized(/set). refchg =3D = atomic_readandclear_32(&m->md.mdpg_attrs); if (refchg & PTE_CHG) vm_page_dirty(m); if (refchg & PTE_REF) vm_page_aflag_set(m, = PGA_REFERENCED); . . . Note: So, if m is set above, then the next loop iteration(s) would use this then-old value instead of an initialized value. It looks to me like at least one assignment to m is missing. moea64_pvo_protect has pg that seems analogous to m and has: pg =3D PHYS_TO_VM_PAGE(pvo->pvo_pte.pa & LPTE_RPGN); . . . if (pm !=3D kernel_pmap && pg !=3D NULL && (pg->a.flags & PGA_EXECUTABLE) =3D=3D 0 && (pvo->pvo_pte.pa & (LPTE_I | LPTE_G | LPTE_NOEXEC)) =3D=3D = 0) { if ((pg->oflags & VPO_UNMANAGED) =3D=3D 0) vm_page_aflag_set(pg, PGA_EXECUTABLE); . . . if (pg !=3D NULL && (pvo->pvo_vaddr & PVO_MANAGED) && (oldprot & VM_PROT_WRITE)) { refchg |=3D atomic_readandclear_32(&pg->md.mdpg_attrs); if (refchg & LPTE_CHG) vm_page_dirty(pg); if (refchg & LPTE_REF) vm_page_aflag_set(pg, PGA_REFERENCED); This might suggest some about what is missing. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 03:29:33 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EED4832B5BE for ; Fri, 12 Jun 2020 03:29:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-10.consmr.mail.ne1.yahoo.com (sonic313-10.consmr.mail.ne1.yahoo.com [66.163.185.33]) (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 49jmRw37Fgz3Ykk for ; Fri, 12 Jun 2020 03:29:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: f8ur2nAVM1m_2H7cyU1MzUgF3KAIM1WV9RIwy495A7JUs_f2kG86V7QDw.UGX2u Zs2FYpQfMWE2vLt4BLOwdnusUnk1P3HGLPB1fD2Ujatby5P115DdBvJyZm79CAKKkOfzEGNRz3MF 15S8lAO7EvAoxUieBTPufwYXRInFQxS9Vnd3FiQKESMJDvQFbiF6qFF6QFMDdBNpKv8gz9kR8GY_ TDsNzcdDzUrS9ivQiOXqeTqYMCDKso._fKfjjystBqtTtIPRnDQZUQhfwbtpi5Q1nktybJW12z_k Uk4A1ntCuGpTbNxBtyrl.ewbvPq92LCyCjFpLolXc3kUU5Uo81957z0yzIZ1yr39RqHzpyqWaxHM bPEu9WrZ8QYtZ3LlO7tbfsd_.PAROwY0WfoNfDkKo24TKRz58cbim6XQUTXJNCd9OImNy2cnM9DU krqWisdtMs.3jA5_cWTJ_hDOAgkxJd4CYK2t1V1zR546k1b6cw5hkwynBDDzEb0M5FWkKEgYslMH SVgBYOFxTq5c6NWB1XaPkNu414gZo87EEuU_3.uLD98X4eUgVeuVWW0J1Axat1LnQwlDi.K0Dr0W mAecKZWRGpnbkXEGbrWH343XNkH4TSGBqPiv8m6jSaJtGcs.TNo_Lc5Dfl4xXwU7xk8sjIW7.iRd tmMtpEQY9P2rfznZuGl3YMmifMuw3Jom7vmKO8e8d9s1Ay0g.YCROAoJmMZjBJTs9MCN92OHc8PS 5zlhJrVfduYb3zJ2LTJemaHyXznsUnS.zH_6P8jzIvEJ3U5rukPWtU.AU5AfHyYiGbnpC4q7wnih J.ce.HqC0tWufUnhjGcGyfUgkB25g5pLnx0iOY4wNXC9XnwJnWixy1vD5BArhrDmnlevUB0BBSyv 1a83C.XbKMsBjOZkQEJX2mvWSRC_H4qwqKhzsjnYv2KF9CKLk4yvuciZxaaIagEC7hEaTtNGFlzz FxinOZ9nU2uHJe_PvpvIg._DzMtPTrIvBZ2yrNmFBAEPuKZu6xpfKnX0xiq86H4GOJYihdl7Ixqp 6jed_F1jwsH3231kw_u.RvmDxlYz2g1oN4wSgyhWuTFYN1tJ29fycE9VS1aj8onIbSlnmqljT_M. ieT3MUq52XmsnQldGItsXadv8utSiQ.lqzwMA1GryAHhB3FiMH8hypIvPtXMMMIDTrAcJBioP5y. q0WjPfK2xKYcCyXmx1Bpm_tjUFl2jQ42X8TXCfCzEpFcZNB4lb7kzrs0mBS1aLGQs_4Usr6O6wqz DoLpuLSxAa1WjWmkZiaVRczypLuWlQ2CsHRQGTwkhcsT01wVIiqmvXHxQ05x8WfZm5xFo9brLmO4 gRaFKuE41nPFHcBo72g.UjmtpqzTQT8Zu7I9hiN.WQ2hWnZQH49fZXW9VKtzTyFvLqERbL1W8yLT Qb9LZGZS_tcAg0LDUC1cb Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 Jun 2020 03:29:30 +0000 Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 7e9a213763a55615b6663cd901b748e3; Fri, 12 Jun 2020 03:29:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <20200611212532.59f677be@ralga.knownspace> Date: Thu, 11 Jun 2020 20:29:27 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> References: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> <20200611212532.59f677be@ralga.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jmRw37Fgz3Ykk X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.33 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.82)[-0.819]; FREEMAIL_TO(0.00)[gmail.com]; 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:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.013]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.185.33:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.185.33:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 03:29:34 -0000 On 2020-Jun-11, at 19:25, Justin Hibbits = wrote: > On Thu, 11 Jun 2020 17:30:24 -0700 > Mark Millard wrote: >=20 >> On 2020-Jun-11, at 16:49, Mark Millard wrote: >>=20 >>> On 2020-Jun-11, at 14:42, Justin Hibbits >>> wrote: >>>=20 >>> On Thu, 11 Jun 2020 14:36:37 -0700 >>> Mark Millard wrote: >>>=20 >>>> On 2020-Jun-11, at 13:55, Justin Hibbits >>>> wrote: >>>>=20 >>>>> On Wed, 10 Jun 2020 18:56:57 -0700 >>>>> Mark Millard wrote: =20 >>> . . . =20 >>>>=20 >>>>=20 >>>>> That said, the attached patch effectively copies >>>>> what's done in OEA6464 into OEA pmap. Can you test it? =20 >>>>=20 >>>> I'll try it once I get a chance, probably later >>>> today. >>>> . . . =20 >>>=20 >>> No luck at the change being a fix, I'm afraid. >>>=20 >>> I verified that the build ended up with >>>=20 >>> 00926cb0 bl 008e8dc8 >>> 00926cb4 mr r27,r3 >>> 00926cb8 addi r3,r3,36 >>> 00926cbc hwsync >>> 00926cc0 lwarx r25,0,r3 >>> 00926cc4 li r4,0 >>> 00926cc8 stwcx. r4,0,r3 >>> 00926ccc bne- 00926cc0 >>> 00926cd0 andi. r3,r25,128 >>> 00926cd4 beq 00926ce0 >>> 00926cd8 mr r3,r27 >>> 00926cdc bl 008e9874 >>>=20 >>> in the installed kernel. So I doubt a >>> mis-build would be involved. It is a >>> head -r360311 based context still. World is >>> without MALLOC_PRODUCTION so that jemalloc >>> code executes its asserts, catching more >>> and earlier than otherwise. >>>=20 >>> First test . . . >>>=20 >>> The only thing that the witness kernel reported was: >>>=20 >>> Jun 11 15:58:16 FBSDG4S2 kernel: lock order reversal: >>> Jun 11 15:58:16 FBSDG4S2 kernel: 1st 0x216fb00 Mountpoints (UMA >>> zone) @ /usr/src/sys/vm/uma_core.c:4387 Jun 11 15:58:16 FBSDG4S2 >>> kernel: 2nd 0x1192d2c kernelpmap (kernelpmap) @ >>> /usr/src/sys/powerpc/aim/mmu_oea.c:1524 Jun 11 15:58:16 FBSDG4S2 >>> kernel: stack backtrace: Jun 11 15:58:16 FBSDG4S2 kernel: #0 >>> 0x5ec164 at witness_debugger+0x94 Jun 11 15:58:16 FBSDG4S2 kernel: >>> #1 0x5ebe3c at witness_checkorder+0xb50 Jun 11 15:58:16 FBSDG4S2 >>> kernel: #2 0x536d5c at __mtx_lock_flags+0xcc Jun 11 15:58:16 >>> FBSDG4S2 kernel: #3 0x92636c at moea_kextract+0x5c Jun 11 15:58:16 >>> FBSDG4S2 kernel: #4 0x965d30 at pmap_kextract+0x98 Jun 11 15:58:16 >>> FBSDG4S2 kernel: #5 0x8bfdbc at zone_release+0xf0 Jun 11 15:58:16 >>> FBSDG4S2 kernel: #6 0x8c7854 at bucket_drain+0x2f0 Jun 11 15:58:16 >>> FBSDG4S2 kernel: #7 0x8c728c at bucket_free+0x54 Jun 11 15:58:16 >>> FBSDG4S2 kernel: #8 0x8c74fc at bucket_cache_reclaim+0x1bc Jun 11 >>> 15:58:16 FBSDG4S2 kernel: #9 0x8c7004 at zone_reclaim+0x128 Jun 11 >>> 15:58:16 FBSDG4S2 kernel: #10 0x8c3a40 at uma_reclaim+0x170 Jun 11 >>> 15:58:16 FBSDG4S2 kernel: #11 0x8c3f70 at uma_reclaim_worker+0x68 >>> Jun 11 15:58:16 FBSDG4S2 kernel: #12 0x50fbac at fork_exit+0xb0 Jun >>> 11 15:58:16 FBSDG4S2 kernel: #13 0x9684ac at fork_trampoline+0xc >>>=20 >>> The processes that were hit were listed as: >>>=20 >>> Jun 11 15:59:11 FBSDG4S2 kernel: pid 971 (cron), jid 0, uid 0: >>> exited on signal 11 (core dumped) Jun 11 16:02:59 FBSDG4S2 kernel: >>> pid 1111 (stress), jid 0, uid 0: exited on signal 6 (core dumped) >>> Jun 11 16:03:27 FBSDG4S2 kernel: pid 871 (mountd), jid 0, uid 0: >>> exited on signal 6 (core dumped) Jun 11 16:03:40 FBSDG4S2 kernel: >>> pid 1065 (su), jid 0, uid 0: exited on signal 6 Jun 11 16:04:13 >>> FBSDG4S2 kernel: pid 1088 (su), jid 0, uid 0: exited on signal 6 >>> Jun 11 16:04:28 FBSDG4S2 kernel: pid 968 (sshd), jid 0, uid 0: >>> exited on signal 6 >>>=20 >>> Jun 11 16:05:42 FBSDG4S2 kernel: pid 1028 (login), jid 0, uid 0: >>> exited on signal 6 >>>=20 >>> Jun 11 16:05:46 FBSDG4S2 kernel: pid 873 (nfsd), jid 0, uid 0: >>> exited on signal 6 (core dumped) >>>=20 >>>=20 >>> Rebooting and rerunning and showing the stress output and such >>> (I did not capture copies during the first test, but the first >>> test had similar messages at the same sort of points): >>>=20 >>> Second test . . . >>>=20 >>> # stress -m 2 --vm-bytes 1700M >>> stress: info: [1166] dispatching hogs: 0 cpu, 0 io, 2 vm, 0 hdd >>> : >>> = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= >>> Failed assertion: "slab =3D=3D extent_slab_get(extent)" : >>> = /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:258:= >>> Failed assertion: "slab =3D=3D extent_slab_get(extent)" ^C >>>=20 >>> # exit >>> : >>> /usr/src/contrib/jemalloc/include/jemalloc/internal/sz.h:200: >>> Failed assertion: "ret =3D=3D sz_index2size_compute(index)" Abort = trap >>>=20 >>> The other stuff was similar to to first test, not repeated here. =20 >>=20 >> The updated code looks odd to me for how "m" is >> handled (part of a egrep to ensure I show all the >> usage of m): >>=20 >> moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, >> vm_page_t m; >> if (pm !=3D kernel_pmap && m !=3D NULL && >> (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && >> if ((m->oflags & VPO_UNMANAGED) =3D=3D = 0) >> vm_page_aflag_set(m, >> PGA_EXECUTABLE); m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & PTE_RPGN); >> refchg =3D >> atomic_readandclear_32(&m->md.mdpg_attrs); vm_page_dirty(m); >> vm_page_aflag_set(m, >> PGA_REFERENCED); >>=20 >> Or more completely, with notes mixed in: >>=20 >> void=20 >> moea_protect(mmu_t mmu, pmap_t pm, vm_offset_t sva, vm_offset_t eva, >> vm_prot_t prot) >> { >> . . . >> vm_page_t m; >> . . . >> for (pvo =3D RB_NFIND(pvo_tree, &pm->pmap_pvo, &key); >> pvo !=3D NULL && PVO_VADDR(pvo) < eva; pvo =3D tpvo) { >> . . . >> if (pt !=3D NULL) { >> . . . >> if (pm !=3D kernel_pmap && m !=3D NULL && >>=20 >> NOTE: m seems to be uninitialized but tested for being NULL >> above. >>=20 >> (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && >>=20 >> Note: This looks to potentially be using a random, non-NULL >> value for m during evaluation of m->a.flags . >>=20 >> . . . >>=20 >> if ((pvo->pvo_vaddr & PVO_MANAGED) && >> (pvo->pvo_pte.prot & VM_PROT_WRITE)) { >> m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & >> PTE_RPGN); >>=20 >> Note: m finally is potentially initialized(/set). >>=20 >> refchg =3D >> atomic_readandclear_32(&m->md.mdpg_attrs); if (refchg & PTE_CHG) >> vm_page_dirty(m); >> if (refchg & PTE_REF) >> vm_page_aflag_set(m, >> PGA_REFERENCED); . . . >>=20 >> Note: So, if m is set above, then the next loop >> iteration(s) would use this then-old value >> instead of an initialized value. >>=20 >> It looks to me like at least one assignment >> to m is missing. >>=20 >> moea64_pvo_protect has pg that seems analogous to >> m and has: >>=20 >> pg =3D PHYS_TO_VM_PAGE(pvo->pvo_pte.pa & LPTE_RPGN); >> . . . >> if (pm !=3D kernel_pmap && pg !=3D NULL && >> (pg->a.flags & PGA_EXECUTABLE) =3D=3D 0 && >> (pvo->pvo_pte.pa & (LPTE_I | LPTE_G | LPTE_NOEXEC)) =3D=3D = 0) >> { if ((pg->oflags & VPO_UNMANAGED) =3D=3D 0) >> vm_page_aflag_set(pg, PGA_EXECUTABLE); >>=20 >> . . . >> if (pg !=3D NULL && (pvo->pvo_vaddr & PVO_MANAGED) && >> (oldprot & VM_PROT_WRITE)) { >> refchg |=3D = atomic_readandclear_32(&pg->md.mdpg_attrs); >> if (refchg & LPTE_CHG) >> vm_page_dirty(pg); >> if (refchg & LPTE_REF) >> vm_page_aflag_set(pg, PGA_REFERENCED); >>=20 >>=20 >> This might suggest some about what is missing. >=20 > Can you try moving the assignment to 'm' to right below the > moea_pte_change() call? Panics during boot. svnlite diff shown later. That change got me a panic just after the lines about ada0 and cd0 details. (Unknown what internal stage.) Hand translated from a picture of the screen: panic: vm_page_free_prep: mapping flags set in page 0xd032a078 . . . panic vm_page_free_prep vm_page_free_toq vm_page_free vm_object_collapse vm_object_deallocate vm_map_process_deferred vm_map_remove exec_new_vmspace exec_elf32_imgact kern_execve sys_execve trap powerpc_interrupt user SC trap by 0x100d7af8 . . . # svnlite diff /usr/src/sys/powerpc/aim/mmu_oea.c Index: /usr/src/sys/powerpc/aim/mmu_oea.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/powerpc/aim/mmu_oea.c (revision 360322) +++ /usr/src/sys/powerpc/aim/mmu_oea.c (working copy) @@ -1773,6 +1773,9 @@ { struct pvo_entry *pvo, *tpvo, key; struct pte *pt; + struct pte old_pte; + vm_page_t m; + int32_t refchg; =20 KASSERT(pm =3D=3D &curproc->p_vmspace->vm_pmap || pm =3D=3D = kernel_pmap, ("moea_protect: non current pmap")); @@ -1800,12 +1803,31 @@ pvo->pvo_pte.pte.pte_lo &=3D ~PTE_PP; pvo->pvo_pte.pte.pte_lo |=3D PTE_BR; =20 + old_pte =3D *pt; + /* * If the PVO is in the page table, update that pte as = well. */ if (pt !=3D NULL) { moea_pte_change(pt, &pvo->pvo_pte.pte, = pvo->pvo_vaddr); + m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & = PTE_RPGN); + if (pm !=3D kernel_pmap && m !=3D NULL && + (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && + (pvo->pvo_pte.pa & (PTE_I | PTE_G)) =3D=3D = 0) { + if ((m->oflags & VPO_UNMANAGED) =3D=3D = 0) + vm_page_aflag_set(m, = PGA_EXECUTABLE); + moea_syncicache(pvo->pvo_pte.pa & = PTE_RPGN, + PAGE_SIZE); + } mtx_unlock(&moea_table_mutex); + if ((pvo->pvo_vaddr & PVO_MANAGED) && + (pvo->pvo_pte.prot & VM_PROT_WRITE)) { + refchg =3D = atomic_readandclear_32(&m->md.mdpg_attrs); + if (refchg & PTE_CHG) + vm_page_dirty(m); + if (refchg & PTE_REF) + vm_page_aflag_set(m, = PGA_REFERENCED); + } } } rw_wunlock(&pvh_global_lock); =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 03:47:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CBC832C308 for ; Fri, 12 Jun 2020 03:47:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49jmrL0Q35z3b14 for ; Fri, 12 Jun 2020 03:47:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VMi9fyQVM1mE6ZiSNMccaR6.dVkr_bGJqiszfpVppTjGBCw4T7ZMPM80goz6P08 aBe_MWPh33ykPTsF4vzvbVtsGD_esUF2BTDWlQbu3fbUGoLW24hT9PTecARP68wsQHPFqA.atDAa C0VhWX3Ygh2DjaYa_b_lVyMnHw3nRHP3YWra81EKp6l6tz4MxW.vkN_uqdlVZPYMAHqAukViyMKT odzhD6lX32m9nK2zNgzDBZ0jjmvpMjKkbunW24fLlF5HYA5U3T0EfSu89I08wGMjruwE_xwUsL8Z LdRAS5627Y2_LI4ac6e4E2RDW8MEFRA24Cm6oVLE3UPOl36MkzgCmrYL2MYBBuyYK_FtqBQM9PGl zEVo7fJUxa2FCneRVCvn4oRE4R3_iatkFW5zDH2_z4BMmrd5y.Tea.WqdIby.8zkAtkBg.3jGor7 OGpzHo4rcRau1kacAA1KaC9J73UUym96m9FP3lCtKWcPyFPcvrOfkEoRZcJ.EP0GFPBuaREJEWCA bKDGn8BFg426VNayqWCkxBJ1faO3vARuxIZmgkvTJ3M_20d5DdSW__dIslwYb7et2OoIcghymzvZ GpoS3Yf_au9qrQNqYFrQOqGa9e59_3RIYT4sczohV4VNL3FiiV193u9xqoNMdVr5CtjiMBsrVk7v JsSGNgeaMzmMB5rbHMCxZOEukhyNLuGkXPzQ8XqrNXH_ca7ynJYOJpD7tXCXwWXeoJ7YG1eRKqYu 1BCSEOKE6w5BJyO3EhiGzQ0Cd9ji6vLOdywBXMJZgT3IQYKarV.0gb_wmbwH8f2bzD505lk5MWwJ hVz81QnBKU01P7CjwPLg8NCXmXkWuxly4XQso1ZuCdex0B1ztiVHrPs4__ddhBV.KV98qm1vEoA1 0yNLHgQegAS2ROstl9na1IQy8dOJ8hLCQYLbKVADF2vvc5yYURZKm3ECmSuLAr64BlwWM16Mx9Kt 5zfb29WLzTjRfHJlaq2qEQF3blgKe_gloF3v5uBTPaQwwi6k28wCIQ6a0yo8xjHvocgFVPHfk7_C hdN6HfLRwJUVBcS8rBhWQYwl_gtC0oTZz8tQBeVp.QO6rfLEbKzc9AT7Rd1UM12aQ110eHQPNv.3 _KwJaTfSWnRGm6wJSVdiBolXzBeR0QOVKc.Vdc_WOxfbxiPjQH.AnAsfEhkWbV2s_jHvg1uq_G2O RzIbePz.Vi6UAMWSjtMbtdNTuz_kBsucTTEXG6pDzKG1Frr8k157uX8cZd6XvANXgrbJ0H5Z45.3 J6zfS2MjXHPxNiP1347osKzhrLE7TsKaGzXn1ocHm4saJ3RqLNMudq_2rXpvnPxs_G49xvBdAgkV It8rkio8l6PyS88bHlIZ3_KGqYm2KLUKrr3FFGeKcFFAAyy84e2CokJck3xmhj5wJDRZf6csW0gr Yg_GbUJ0GBz19BRDMmU2nSuC6ajc5hJ716NWsVEhXOZON67b5755Kx_CnQcdvY7Lf Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 Jun 2020 03:47:12 +0000 Received: by smtp402.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e174646f2964b434d05b418bca707b84; Fri, 12 Jun 2020 03:47:08 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> Date: Thu, 11 Jun 2020 20:47:06 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> References: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> <20200611212532.59f677be@ralga.knownspace> <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jmrL0Q35z3b14 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.82)[-0.817]; FREEMAIL_TO(0.00)[gmail.com]; 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:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.186.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.186.146:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 03:47:15 -0000 [Just a better panic backtrace text copy.] On 2020-Jun-11, at 20:29, Mark Millard wrote: > On 2020-Jun-11, at 19:25, Justin Hibbits = wrote: >=20 >> On Thu, 11 Jun 2020 17:30:24 -0700 >> Mark Millard wrote: >>=20 >>> On 2020-Jun-11, at 16:49, Mark Millard wrote: >>>=20 >>>> On 2020-Jun-11, at 14:42, Justin Hibbits >>>> wrote: >>>> . . . >>=20 >> Can you try moving the assignment to 'm' to right below the >> moea_pte_change() call? >=20 > Panics during boot. svnlite diff shown later. >=20 > That change got me a panic just after the lines about ada0 > and cd0 details. (Unknown what internal stage.) Hand > translated from a picture of the screen: >=20 > panic: . . . I forgot that 32-bit powerpc dump does partially work for PowerMacs (or at least my context). After booting with a non-debug kernel I've kept around, looking at /var/crash/vmcore.3 shows: panic: vm_page_free_prep: mapping flags set in page 0xd032a078 cpuid =3D 1 time =3D 1591931757 KDB: stack backtrace: 0xd2dc4340: at kdb_backtrace+0x64 0xd2dc43a0: at vpanic+0x208 0xd2dc4410: at panic+0x64 0xd2dc4450: at vm_page_free_prep+0x348 0xd2dc4470: at vm_page_free_toq+0x3c 0xd2dc4490: at vm_page_free+0x20 0xd2dc44a0: at vm_object_collapse+0x4ac 0xd2dc4510: at vm_object_deallocate+0x430 0xd2dc4550: at vm_map_process_deferred+0xec 0xd2dc4570: at vm_map_remove+0x12c 0xd2dc4590: at exec_new_vmspace+0x20c 0xd2dc45f0: at exec_elf32_imgact+0xa70 0xd2dc46a0: at kern_execve+0x600 0xd2dc4910: at sys_execve+0x84 0xd2dc4970: at trap+0x748 0xd2dc4a10: at powerpc_interrupt+0x178 0xd2dc4a40: user SC trap by 0x100d71f8: srr1=3D0xf032 r1=3D0xffffd810 cr=3D0x82000280 xer=3D0 ctr=3D0x10173810 = frame=3D0xd2dc4a48 KDB: enter: panic /wrkdirs/usr/ports/devel/gdb/work-py37/gdb-9.1/gdb/inferior.c:283: = internal-error: struct inferior *find_inferior_pid(int): Assertion `pid = !=3D 0' failed. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 04:05:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 52B1132C88B for ; Fri, 12 Jun 2020 04:05:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-22.consmr.mail.ne1.yahoo.com (sonic316-22.consmr.mail.ne1.yahoo.com [66.163.187.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49jnF264Kqz3c7Y for ; Fri, 12 Jun 2020 04:05:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: RIz_r6oVM1mh2YDU5fSHnOV11dkFFlKXYKeUXZ62oOzYXahDytlmC.xSwAVg3wA QiEltkaATCG4emFY7AyqBVbOucyG_IXQmO8hg8oVJ6ZesW1LHmSK7yZKloOk7yog9Kx2fS3cSQEF gvl_UpGR8OIrJlgC80brpj9OwEFhVa3MthmWYk0Q0raEBMkZJt16f3zzYkZSJuXJk6hlxTguV6Qe SYYtYol7o70vrk07ZPvuXPxuEmV6hdQgWrIIE8gmB7aAKQHBeTDc3vzI0KhNSagy1T_BIu39gj6n lOsYAbyTOusvKWmQG3j9qgNBrL6mPYo4jwPB5bmLOP0CtIh0bWTqVbANwlwqJf0_ZA3tISULbtUn g7xaUjasIgkEvV6j8kjJJJabRWPav6D_73iOousAq11qdsDDcVJ_9KU_.QdtGo8rMdUGPn2GOw.p nyNjOj.RupxX9tLclA6BKcLlYXHIvH..5ZXgdDrRUG2Ue3Ds.XvYreNgFyq6I4JMIbgvBP6dh9hJ mr4IxLXhxcOMIgRFspMYt4UFazL0xwovRsUoQgfobi.IaCxFSraJtq0FY4B5RB5aqPLqyhgTIM.S 67B0LqhgiJ1T74mL2hAhY9nrhVJyoXPlGhnPeuE9Ud8aRt1X77Dtw8t18lRe.gVmhyjLrivvjsdn yzeoTQvG1ePbN_kDlNOMWFTGe0kQpVYy9MWGGRngV1rgTn0JtI2I4s7hDwV_vpgmlOU07ZXwClzg fmSpeK4iFoakrEaN6CYpwdDW_mTxmKcOXZODQ6gCXgGHNfgDSbiH7ce1z2lKu2Oby_L0cIH0Ar8t w0Bm3bFgMdjQb5yy9qWR5NKzGIb1PCwk_XHM4MtXHgN5OOPaBOS1GlDv3vRTcgVIVWhvcKFUogf5 NbdlwAlGgGMxuFf3dVZp6Dbhrj_VMuYmlgcyPFuyQ3IOIO2UJbUgb7iV_dT4a0h.XRWV0p4Q.fDD 1k_0R25mrHhFw_UCU4L01yMKGpHpMXwLhEHadDRD0v.XKP_7cGFT1r2LShvkw2GZRBimEBO6a5i7 BF_wzKdkcCiqBlUrSsCWenivEeJpdBlaeyfhvTPvx.xwg06Ab4lvFYoA2FSMUy4niG2.XhouaYgS oEo2hhlxAfMA5fgtO31ID2GPTyjngJ7M2tPp4IfAGXf66dnIx0iYbTQOvMZ4TWhyI6O_YQt6MNSd aOAo.OUaZB6hf0klxPfkPmXCB9vR88v8MvPgiOiBR6AcdsK4ykcXQH6ZgqJNx.R.DJ6kQfFJvb_C UgexVyKXYYxknujXPrkFPR8xn40fRVYopaSL3Gq4uzPtIuZLXE9OD.RxIe1clnkDBK28T6arPK1L jN_pxyeyRZg_x5a152g4NC2mX.JX596JBKSCbb43QeolEnu6fizP4B1yzhoWVk2Ee6bctONqfNlt wCNvzuCOu20hMj513MrTHmf6Lpnqr26D. Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 Jun 2020 04:05:09 +0000 Received: by smtp420.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9598ca0db01bbcc2708f2559938fbab6; Fri, 12 Jun 2020 04:05:06 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> Date: Thu, 11 Jun 2020 21:05:05 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: 7bit Message-Id: References: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> <20200611212532.59f677be@ralga.knownspace> <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jnF264Kqz3c7Y X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.33 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.82)[-0.824]; FREEMAIL_TO(0.00)[gmail.com]; 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:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.995]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.187.148:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.187.148:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 04:05:12 -0000 There is another oddity in the code structure, in that if pt was ever NULL the code would misuse the NULL before the test for non-NULL is made: pt = moea_pvo_to_pte(pvo, -1); . . . old_pte = *pt; /* * If the PVO is in the page table, update that pte as well. */ if (pt != NULL) { (I'm not claiming that this explains the panic.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 04:33:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5FB1732D889 for ; Fri, 12 Jun 2020 04:33:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-22.consmr.mail.ne1.yahoo.com (sonic306-22.consmr.mail.ne1.yahoo.com [66.163.189.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49jnsg4h1Mz3dc0 for ; Fri, 12 Jun 2020 04:33:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 333vDqQVM1mnfuANn.3JatGMHevXN6svbO_nGtDOnwK6QhB.2zk_ix0iMr_cEnX aUdUyc1BuvvzDniVL7NDHgW9kRX6zjpkXFQW6tjOrHQTNQPafAqB8SezrSF6o8us1ihCZrFxvvU2 Oz5em88XvXJX85bHi0fxMOS9rUtnHx5B6WpFCRAIRR8eoXcIWYng.LG7bzrOjYj6QX5t5zX62NVR yo82FAyR0_orLiLduf_EPBeMg_fK9I0Oj4vbghMO6NjTVLLZYjG9O7of5BS_Fid8NkrEwmjKuxdw NnUCDysBykoAj_g_ogNFik.YWbQ_WJNhAzeeqg0j7XmBWzf1ypE5mWCN3HwCs49k1gLL0Q68dtcp MvjID8mNuhODZCscVPXEqYEMMKDtyLlIIGoYpVQ8WDLF_LgOrDpRQG25VwCUrtVxX5lc3ln3p1i_ ikTRiMT6vXZ7wtfaZ4B.PwyA61s2L7etexhHiKOMahxd.811eP.KTcvxvkg8tbC6yRBzb22QBZTu JFtjeabVZyaQfqhNHLr6tBcYYFuQfvb6_ZMyRa_92k11iohwP3kAbY46O1GSn2NrtBBInjrO2td5 FuYyfgBKqfByLFDkuAycpWvHigjtoyKRupoEtN6Kc6fZCseLTWQMDOjwPVhLdLfyXiAAzOgsRoZF LoBFmM9tBrzJ7h6rVYLM0oqiqZ6.pcB33EdEqJz13N_C0xx6ptcI7cAGGWhjSTH_u7FBKpOfMi1C nbcDiiYiPu5bWfQxFeT3cSZqTQxU5f7sqvNO59XaXA6WDx9Esl_m1kVAT92SGNaBOrypDVrj7.qq VeMMTFHwCNSLXtU0D0u7qAR7F8NBg3iwrIhsAn0bcrlHfo7VCX7MNez4eHGeZT2JGGdAfrXeu_3X KspgMn12NeleG7xcVX49cg0BInsM2h7ARk5lgotUi6UZ5DVCWuuoTK_KUY_fa.bEjkxDA7PjLVvs TUY5sdE9gJNkithpGRQZphmaRFZNNJFBOm1RA0FQ6Xq8mCWjXbInmdFZp0.c.20afoamh0XvKt6s skk.x3rHMSg9hP0VgNHDJR8FjDFCDFyABmgj7.5707XY.riXBR71RYfiXpz0T1KaN.R7gyXCjsO4 K4Fnizin.mwbQ20Ntvoqr3LwnSU0i4DA.aOvcnG.G7DkuyjoaRs2RtYg3uJZmvcw5WwiEN7tAO5X 4z8N0fatFxhM4S1aa6QTOotAzuazoJLZTUGGY5Gq3j9hV1xTTetV6s0KZymkcmrRnTOkQXOwXFfl 9auh8uiL2kgDFE39qsqnW6PdY22fJW1p6xeaecJj.RkdZZ4c_AwXi9BicjHKu2j5Pa2AvE.rPTab kzjCmzQf7wp8nP.7igXYobTh13PMl636ulWhJAuYaPEAgqXXytf067jdC.9Nh2hn3ogfcFJVD_x7 DVldBNZbRzbV7q1_nLpx6hSOC7UmdxeZO6tAnRywOdNHecSRm0skUB_Sk5ZBJkPQJE2o- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 Jun 2020 04:33:25 +0000 Received: by smtp416.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2f34606d33939f3e61488b33bfac734b; Fri, 12 Jun 2020 04:33:22 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311 From: Mark Millard In-Reply-To: Date: Thu, 11 Jun 2020 21:33:20 -0700 Cc: "vangyzen@freebsd.org" , svn-src-head@freebsd.org, FreeBSD Current , FreeBSD Hackers , FreeBSD PowerPC ML , Brandon Bergren Content-Transfer-Encoding: quoted-printable Message-Id: References: <695E6836-F860-4557-B7DE-CC1EDB347F18@yahoo.com> <121B9B09-141B-4DC3-918B-1E7CFB99E779@yahoo.com> <8AAB0462-3FA8-490C-8D8D-7C15B1C9E2DE@yahoo.com> <18E62746-80DB-4195-977D-4FF32D0129EE@yahoo.com> <9562EEE4-62EF-4164-91C0-948CC0432984@yahoo.com> <9B68839B-AEC8-43EE-B3B6-B696A4A57DAE@yahoo.com> <359C9C7D-4106-42B5-AAB5-08EF995B8100@yahoo.com> <20200513105632.06db9e21@titan.knownspace> <20200611155545.55526f7c@ralga.knownspace> <5542B85D-1C3A-41D8-98CE-3C02E990C3EB@yahoo.com> <20200611164216.47f82775@ralga.knownspace> <20200611212532.59f677be@ralga.knownspace> <1EDCA498-0B67-4374-B7CA-1ECDA8EE32AD@yahoo.com> <3605089E-7B5D-4FBA-B0D1-14B789BDF09B@yahoo.com> To: Justin Hibbits X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49jnsg4h1Mz3dc0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.38 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCPT_COUNT_SEVEN(0.00)[7]; NEURAL_HAM_SHORT(-0.87)[-0.866]; FREEMAIL_TO(0.00)[gmail.com]; 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:36646, ipnet:66.163.184.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.016]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.189.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.189.84:from]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 04:33:29 -0000 [Yet another oddity.] On 2020-Jun-11, at 21:05, Mark Millard wrote: >=20 > There is another oddity in the code structure, in > that if pt was ever NULL the code would misuse the > NULL before the test for non-NULL is made: >=20 > pt =3D moea_pvo_to_pte(pvo, -1); > . . . > old_pte =3D *pt; >=20 > /* > * If the PVO is in the page table, update that pte as = well. > */ > if (pt !=3D NULL) { >=20 > (I'm not claiming that this explains the panic.) There is another NULL handling oddity that the 64-bit code does not have. I'll show 64 relevant bit code first: pg =3D PHYS_TO_VM_PAGE(pvo->pvo_pte.pa & LPTE_RPGN); =20 . . . =20 if (. . .&& pg !=3D NULL && (pg->a.flags & PGA_EXECUTABLE) =3D=3D 0 && . . .) { if ((pg->oflags & VPO_UNMANAGED) =3D=3D 0) vm_page_aflag_set(pg, PGA_EXECUTABLE); . . . } . . . if (pg !=3D NULL && . . .) { refchg |=3D atomic_readandclear_32(&pg->md.mdpg_attrs); if (refchg & LPTE_CHG) vm_page_dirty(pg); if (refchg & LPTE_REF) vm_page_aflag_set(pg, PGA_REFERENCED); } Note: the 2nd outer-if tests for pg !=3D NULL, just like the first outer-if above does. It avoids potential abuse-of-NULL activity. This is not true of the 32-bit code for "m": m =3D PHYS_TO_VM_PAGE(old_pte.pte_lo & = PTE_RPGN); if (. . . && m !=3D NULL && (m->a.flags & PGA_EXECUTABLE) =3D=3D 0 && . . .) { if ((m->oflags & VPO_UNMANAGED) =3D=3D = 0) vm_page_aflag_set(m, = PGA_EXECUTABLE); moea_syncicache(pvo->pvo_pte.pa & = PTE_RPGN, PAGE_SIZE); } . . . if ((pvo->pvo_vaddr & PVO_MANAGED) && (pvo->pvo_pte.prot & VM_PROT_WRITE)) { refchg =3D = atomic_readandclear_32(&m->md.mdpg_attrs); if (refchg & PTE_CHG) vm_page_dirty(m); if (refchg & PTE_REF) vm_page_aflag_set(m, = PGA_REFERENCED); } The &m->md.mdpg_attrs use apparently could be based on m being NULL because there is no test for m !=3D NULL in the 2nd outer-if. Similarly for the other uses of m in that code block. My guess that that the 2nd outer-if should test something like: . . . if (m !=3D NULL && (pvo->pvo_vaddr & PVO_MANAGED) && (pvo->pvo_pte.prot & VM_PROT_WRITE)) { . . . (Presumes that the pre-existing m !=3D NULL tests are necessary, something that I do not know.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri Jun 12 16:14:09 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5876F33EE06 for ; Fri, 12 Jun 2020 16:14:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49k5Q84j4fz3Scj; Fri, 12 Jun 2020 16:14:08 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x72d.google.com with SMTP id c14so9449581qka.11; Fri, 12 Jun 2020 09:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=wx3DKO4ns/JahCcWxXVnoLoBaOvfU005d42GoW4zeac=; b=oQwa0G0226osz+gzZRelZIVEgRL/Ag7RtcZFlqaHegNKCDfFbRosqxVduVPQX2FDwX M8J9+LCNS9tIEYCvXzBHhcLVlrim6WQcxrgJLQGTdy0UQokUAevz3Dtb8iKl/g1xqV4M uqbHsQUShfCk0UkVhghgimNTnYjyQxEwD0SntXlnloLjUvo50FTN3D1T9s4xwEMNEkyH ohgbUQ7U9W/5+NljNZEKAw64BXjNCvB20Mmpp8eZsmEZhW2bDtbtnqtT5docpkw2ID3X ocbNZigrRPuO4NGGU+EPjbYoRS0Bo4WcNeB+B0W5XoEEnmrqf+9Qp5RcKf1thy383zyp aQTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :mime-version:content-disposition; bh=wx3DKO4ns/JahCcWxXVnoLoBaOvfU005d42GoW4zeac=; b=j2q4shd6JlYA2y+OXlTP3qO4wfbysSJmwruXzYjs5aZp756cHjoikA7Gpsxv/1Vvxb tDqmK6Ixc0fsMmOymaolsmB4eRfIV4jWIx6zVJOsiTxZ9DVtxnx7yqvO18UpXg953aAj D4PPF6EtFNEaZyInx9guvy12zuopQW12dSHtxrxtonKcgCbg27aEIaQA8CYCfyxd6EcX mpqSK5V0Fo6u6yQVeCfC17RFxuiFqS9AxKjMsCMPiWRB+AmZCvrytW0e/PuoY9liUL84 XcqV3GJcxSO7DIs+4NllHsdOWCSd9fThGJcygb2maDa0+Qc2jMBppKb8i8dZyNNAEsEZ Dx9w== X-Gm-Message-State: AOAM533epRYCU4WytH5P6rGI2hxDV5stOw2S/CUS3WJsngagy9w7y5Fb flU7w9l0bxymhVITVY16paWsVEqnetc= X-Google-Smtp-Source: ABdhPJxlIgdrVrOjzBztuQ9qgy8G5hejaqkQTZUJkc1+L9QN/I5+6L3m/soFxwma3gi1k4rfjBn7Iw== X-Received: by 2002:a37:9d43:: with SMTP id g64mr3602969qke.387.1591978447275; Fri, 12 Jun 2020 09:14:07 -0700 (PDT) Received: from raichu (bras-base-toroon0560w-grc-21-184-147-207-195.dsl.bell.ca. [184.147.207.195]) by smtp.gmail.com with ESMTPSA id x11sm4735426qti.60.2020.06.12.09.14.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 09:14:06 -0700 (PDT) Sender: Mark Johnston Date: Fri, 12 Jun 2020 12:14:01 -0400 From: Mark Johnston To: freebsd-hackers@freebsd.org Subject: maintaining CRYPTO_TIMING Message-ID: <20200612161401.GA3992@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 49k5Q84j4fz3Scj X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=oQwa0G02; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::72d as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.29 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.96)[-0.960]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_SHORT(0.37)[0.369]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_NOT_FQDN(0.50)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::72d:from]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[184.147.207.195:received]; 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)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:14:09 -0000 Hi, I noticed that the opencrypto framework maintains counters for various operations. These counters are all global and are updated non-atomically, so they aren't SMP-friendly and won't be precise. I wrote a patch to convert them to counter(9), which fixes both issues, and I note that kern.crypto_stats was renamed to kern.crypto.stats in HEAD so presumably we can use this opportunity to break the sysctl ABI as well (the counters have to be widened from 32 bits to 64 bits). Nothing in the base system seems to actually fetch these counters outside of some code under tools/, which wasn't updated when the sysctl was renamed. There is also CRYPTO_TIMING, which attempts to measure the time elapsed during various stages of cryptop processing. This similarly assumes that processing is single-threaded and I guess is really only useful to OCF driver developers. It has been in the tree for a very long time, but has anyone actually used it? I would like to remove it since it complicates the above-mentioned patch and is of limited usefulness in SMP systems. DTrace or some per-cryptop scheme could be used instead if it is really worth having that functionality, but I don't want to write a patch to implement that unless someone really wants it. From owner-freebsd-hackers@freebsd.org Fri Jun 12 16:18:36 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9222233EDD1 for ; Fri, 12 Jun 2020 16:18:36 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-ot1-f65.google.com (mail-ot1-f65.google.com [209.85.210.65]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49k5WJ0CbZz3SyY; Fri, 12 Jun 2020 16:18:35 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-ot1-f65.google.com with SMTP id t6so7746955otk.9; Fri, 12 Jun 2020 09:18:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=kys3fXtEO/SUU2PiH6pklLQs8TGa5EgFeM/npSy+PFU=; b=bpoDIT12W3fzWMMLdXiEn/9n3gxk44Njo4sLDNCUXMLQN0M4kSuqOKe4sUGsSvqNa2 pAWE5pBA+WS7EYxZOK+TtBSs0eRJ1fE2cwGSELhL6WpCtVgOULLF3RknD79OMuQ6/vAd Spch7ErIqq+HX2h2SVjtw02P2EHn81g3vhDajWcjLXmF6o+SO4bHH283riKkLW9FoKu1 jEyHtHUBELn6e9pQBO856dLW57QzL3xShCFLehdOl+rmSbymlP7kWTrD4bNJVmpOEIjN V4JDpUT2wn1pBzVkRS1flYfxh0A8UqYlOzJxMcM/gfpSOmyIohptWRkCS2duCuxfTcLu hlOQ== X-Gm-Message-State: AOAM5320xCuPKbSPrSA3px0KfxJcE2eOEhRNGiBvu6iBcD8ZzP0Xefx9 NpcrxNwJrN4Kl1VxTG+f+Sxmhn7P X-Google-Smtp-Source: ABdhPJxQ2AZijDRjQNuPoTBsuDYwKuUbOwQNIvfKyraxZmIUzFq6VCuIrUK/zVqjolTalb4L/9U/Sw== X-Received: by 2002:a05:6830:1dba:: with SMTP id z26mr11713191oti.180.1591978714757; Fri, 12 Jun 2020 09:18:34 -0700 (PDT) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com. [209.85.167.172]) by smtp.gmail.com with ESMTPSA id n9sm1535558oom.45.2020.06.12.09.18.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 09:18:34 -0700 (PDT) Received: by mail-oi1-f172.google.com with SMTP id i74so9215668oib.0; Fri, 12 Jun 2020 09:18:34 -0700 (PDT) X-Received: by 2002:aca:accd:: with SMTP id v196mr2805320oie.135.1591978714456; Fri, 12 Jun 2020 09:18:34 -0700 (PDT) MIME-Version: 1.0 References: <20200612161401.GA3992@raichu> In-Reply-To: <20200612161401.GA3992@raichu> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Fri, 12 Jun 2020 09:18:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: maintaining CRYPTO_TIMING To: Mark Johnston Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49k5WJ0CbZz3SyY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none 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]; TAGGED_FROM(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:18:36 -0000 Fine by me to just kill it. On Fri, Jun 12, 2020 at 9:14 AM Mark Johnston wrote: > > Hi, > > I noticed that the opencrypto framework maintains counters for various > operations. These counters are all global and are updated > non-atomically, so they aren't SMP-friendly and won't be precise. I > wrote a patch to convert them to counter(9), which fixes both issues, > and I note that kern.crypto_stats was renamed to kern.crypto.stats in > HEAD so presumably we can use this opportunity to break the sysctl ABI > as well (the counters have to be widened from 32 bits to 64 bits). > Nothing in the base system seems to actually fetch these counters > outside of some code under tools/, which wasn't updated when the sysctl > was renamed. > > There is also CRYPTO_TIMING, which attempts to measure the time elapsed > during various stages of cryptop processing. This similarly assumes > that processing is single-threaded and I guess is really only useful to > OCF driver developers. It has been in the tree for a very long time, > but has anyone actually used it? I would like to remove it since it > complicates the above-mentioned patch and is of limited usefulness in > SMP systems. DTrace or some per-cryptop scheme could be used instead if > it is really worth having that functionality, but I don't want to write > a patch to implement that unless someone really wants it. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Fri Jun 12 16:32:32 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9F4F933EC7A for ; Fri, 12 Jun 2020 16:32:32 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49k5qN3264z3Tkf for ; Fri, 12 Jun 2020 16:32:32 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 6104D17A14; Fri, 12 Jun 2020 16:32:32 +0000 (UTC) Date: Fri, 12 Jun 2020 18:32:30 +0200 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: maintaining CRYPTO_TIMING Message-ID: <20200612163230.37ocjvfebolkqiws@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <20200612161401.GA3992@raichu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fsh3nvpqkl5age7d" Content-Disposition: inline In-Reply-To: <20200612161401.GA3992@raichu> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 16:32:32 -0000 --fsh3nvpqkl5age7d Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Fri, Jun 12, 2020 at 12:14:01PM -0400, Mark Johnston wrote: >Hi, > >I noticed that the opencrypto framework maintains counters for various >operations. These counters are all global and are updated >non-atomically, so they aren't SMP-friendly and won't be precise. I >wrote a patch to convert them to counter(9), which fixes both issues, >and I note that kern.crypto_stats was renamed to kern.crypto.stats in >HEAD so presumably we can use this opportunity to break the sysctl ABI >as well (the counters have to be widened from 32 bits to 64 bits). >Nothing in the base system seems to actually fetch these counters >outside of some code under tools/, which wasn't updated when the sysctl >was renamed. > >There is also CRYPTO_TIMING, which attempts to measure the time elapsed >during various stages of cryptop processing. This similarly assumes >that processing is single-threaded and I guess is really only useful to >OCF driver developers. It has been in the tree for a very long time, >but has anyone actually used it? I would like to remove it since it >complicates the above-mentioned patch and is of limited usefulness in >SMP systems. DTrace or some per-cryptop scheme could be used instead if >it is really worth having that functionality, but I don't want to write >a patch to implement that unless someone really wants it. >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I mean, I really like dtrace, but I won't _force_ you to write it. I'll just applaud loudly if you do. :) Yours, Daniel Ebdrup Jensen --fsh3nvpqkl5age7d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl7jrh5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qmLAf8CpNEs0iQ49QFsSfyws7Jb+z45W7ulXcDs5ely/ipJj4JJ6LiowdhgDcv PZ7XbiMhfjpojqznss3I8qSeoijoy39HQ7g0iscI1+Y/mLnYqnKpYoMOXxDINVdU 5qd5KgDNsht5Mvopm4DgeOWDYzXXRvOgVKJvw+NxOq6cjjkakOPppfRVQ75oRjmm vxQ6oiMUyACunPzVXmMdhTcHMF/onpqJWkk4Gy7hP7ZCkFaqG3mJJjyqy4WOGcDQ rgbYYVtv4z7Z3WQiFzNkdTV1czaKV0gNwHTUVMJ8JmB1txXZQ6QO6zpm88i5lLip c8CiLpQpL1J3unEbDJBJgOx5BKU/dw== =Nj/3 -----END PGP SIGNATURE----- --fsh3nvpqkl5age7d-- From owner-freebsd-hackers@freebsd.org Fri Jun 12 19:46:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 42AB0343C91 for ; Fri, 12 Jun 2020 19:46:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49kB79135Qz3yQt; Fri, 12 Jun 2020 19:46:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-274.local (unknown [IPv6:2601:648:8203:2990:956d:aaea:1d3d:2765]) (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 D132B29FFE; Fri, 12 Jun 2020 19:46:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: maintaining CRYPTO_TIMING To: Mark Johnston , freebsd-hackers@freebsd.org References: <20200612161401.GA3992@raichu> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <37f0c691-f067-20e5-2c21-7513fbdc0380@FreeBSD.org> Date: Fri, 12 Jun 2020 12:46:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200612161401.GA3992@raichu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 19:46:29 -0000 On 6/12/20 9:14 AM, Mark Johnston wrote: > Hi, > > I noticed that the opencrypto framework maintains counters for various > operations. These counters are all global and are updated > non-atomically, so they aren't SMP-friendly and won't be precise. I > wrote a patch to convert them to counter(9), which fixes both issues, > and I note that kern.crypto_stats was renamed to kern.crypto.stats in > HEAD so presumably we can use this opportunity to break the sysctl ABI > as well (the counters have to be widened from 32 bits to 64 bits). > Nothing in the base system seems to actually fetch these counters > outside of some code under tools/, which wasn't updated when the sysctl > was renamed. I think this is fine. I'd probably not oppose just removing the stats outright though. Not clear to me how useful they really are (I've never used them, always used dtrace or other stats that are more specific) > There is also CRYPTO_TIMING, which attempts to measure the time elapsed > during various stages of cryptop processing. This similarly assumes > that processing is single-threaded and I guess is really only useful to > OCF driver developers. It has been in the tree for a very long time, > but has anyone actually used it? I would like to remove it since it > complicates the above-mentioned patch and is of limited usefulness in > SMP systems. DTrace or some per-cryptop scheme could be used instead if > it is really worth having that functionality, but I don't want to write > a patch to implement that unless someone really wants it. This can go. I do use DTrace a fair bit when debugging driver issues, but I haven't used any of this stuff at all. For real profiling pmcstat is a better tool. -- John Baldwin From owner-freebsd-hackers@freebsd.org Fri Jun 12 19:56:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 684FA344179 for ; Fri, 12 Jun 2020 19:56:29 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49kBLg1KN0z402v; Fri, 12 Jun 2020 19:56:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x742.google.com with SMTP id b27so10163174qka.4; Fri, 12 Jun 2020 12:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=AWg7TfgZuYURqOXgaLPgoVWDu44ZmtlFQIYHHpj+NWk=; b=CI8+u2TUFPwKl7xyhZKiOEG9OPwZEwRcvVvljJXkoiiCubpP2d6P7QVeDPTW7/6xEe 07rtW4ej9C6Jzul8oK4GO73zT/zsWdFMEhHsAAsy7NHAqAFhAsV80jD5HuVfk1Gw2PpZ hG++L+4qu2COH9pegWSIYsyvWUeHOYSan+tusSyXt1AN2ypld/8DysXFwEn3a/RWzoGY vP9cWzSz8mUIZ7lEArMr1XRAJSk9npEigPffKhZ7gTbK6QdrVkaOKE6d5ABESqqnmFzB zjTLBBDlMThGpBoRGTKGaFu+NdgqJUnHbVNezkX/oat+cRbrIhZYtHGNLbk61UsSlk4W l1wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=AWg7TfgZuYURqOXgaLPgoVWDu44ZmtlFQIYHHpj+NWk=; b=kXICws3kM6exZIw98KBfxwJmrITjlLTNCht9Am97XRA7BIPEphRRH2HsOQnWH+SQ2t uwDz946Wh/lWMWvpF0FIG4DjwK6xkOH3cElMvk/qkdZ6WXb8vm2TusBGZbRWN3RNRgtI hcVlm77XP1+4ShSshQI9SAm6//Z0DOiXr/EVMTV4op/scqr+HI/5KQ2akQAChrL5K1Wp 08yreQso2tWsX4LG3JYfTF43L9M9iArqI2hkDNIaA0oJrQjb7/MsjoJnx5Uh04lkDmRx qOXfCZHHGTUduxtIavzax+Zl0DZgyxIxZRsG/rwheUCSqB6ftblN17b+7kuLLWShaR9K zvMg== X-Gm-Message-State: AOAM532BMcWdCM99J7QvSc1ue7ScnwpKom/4jupdP6DJKmNdYc3mTWgS zGvCGak5fB46kCvggYFxFIfI2heQhz0= X-Google-Smtp-Source: ABdhPJypHWkSGK9kL3bgrBIfYsh8qvFFwFnwhgQVzyJY4GEewwcrOiUMERrWKfCiVysLVGokFzVudw== X-Received: by 2002:a37:bce:: with SMTP id 197mr4889602qkl.370.1591991784990; Fri, 12 Jun 2020 12:56:24 -0700 (PDT) Received: from raichu (bras-base-toroon0560w-grc-21-184-147-207-195.dsl.bell.ca. [184.147.207.195]) by smtp.gmail.com with ESMTPSA id m53sm5727895qtb.64.2020.06.12.12.56.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 12:56:24 -0700 (PDT) Sender: Mark Johnston Date: Fri, 12 Jun 2020 15:56:19 -0400 From: Mark Johnston To: John Baldwin Cc: freebsd-hackers@freebsd.org Subject: Re: maintaining CRYPTO_TIMING Message-ID: <20200612195619.GA14376@raichu> References: <20200612161401.GA3992@raichu> <37f0c691-f067-20e5-2c21-7513fbdc0380@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37f0c691-f067-20e5-2c21-7513fbdc0380@FreeBSD.org> X-Rspamd-Queue-Id: 49kBLg1KN0z402v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 19:56:29 -0000 On Fri, Jun 12, 2020 at 12:46:27PM -0700, John Baldwin wrote: > On 6/12/20 9:14 AM, Mark Johnston wrote: > > Hi, > > > > I noticed that the opencrypto framework maintains counters for various > > operations. These counters are all global and are updated > > non-atomically, so they aren't SMP-friendly and won't be precise. I > > wrote a patch to convert them to counter(9), which fixes both issues, > > and I note that kern.crypto_stats was renamed to kern.crypto.stats in > > HEAD so presumably we can use this opportunity to break the sysctl ABI > > as well (the counters have to be widened from 32 bits to 64 bits). > > Nothing in the base system seems to actually fetch these counters > > outside of some code under tools/, which wasn't updated when the sysctl > > was renamed. > > I think this is fine. I'd probably not oppose just removing the stats > outright though. Not clear to me how useful they really are (I've never > used them, always used dtrace or other stats that are more specific) I think the current stats are not particularly useful, but I could imagine adding stats that might be. For instance, a counter for failed CRYPTO_OP_VERIFY_DIGEST operations, or for operations handled by software drivers vs. hardware drivers. I noticed while testing GELI with a WIP driver that I had forgotten to implement AES-XTS+HMAC, so the tests were causing GELI to fall back to a software implementation. Counters could perhaps make it easier to spot cases where a consumer is unexpectedly using an unaccelerated implementation. Or is there already an easy way to spot that? > > There is also CRYPTO_TIMING, which attempts to measure the time elapsed > > during various stages of cryptop processing. This similarly assumes > > that processing is single-threaded and I guess is really only useful to > > OCF driver developers. It has been in the tree for a very long time, > > but has anyone actually used it? I would like to remove it since it > > complicates the above-mentioned patch and is of limited usefulness in > > SMP systems. DTrace or some per-cryptop scheme could be used instead if > > it is really worth having that functionality, but I don't want to write > > a patch to implement that unless someone really wants it. > > This can go. I do use DTrace a fair bit when debugging driver issues, but > I haven't used any of this stuff at all. For real profiling pmcstat is a > better tool. Ok, thanks. From owner-freebsd-hackers@freebsd.org Fri Jun 12 20:12:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 109453443C0 for ; Fri, 12 Jun 2020 20:12:41 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49kBjN6j8Tz41Bf; Fri, 12 Jun 2020 20:12:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-274.local (unknown [IPv6:2601:648:8203:2990:956d:aaea:1d3d:2765]) (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 98212293F2; Fri, 12 Jun 2020 20:12:40 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: maintaining CRYPTO_TIMING To: Mark Johnston Cc: freebsd-hackers@freebsd.org References: <20200612161401.GA3992@raichu> <37f0c691-f067-20e5-2c21-7513fbdc0380@FreeBSD.org> <20200612195619.GA14376@raichu> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <5e5c9bc6-ffec-cb50-920c-777ecefb917a@FreeBSD.org> Date: Fri, 12 Jun 2020 13:12:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200612195619.GA14376@raichu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2020 20:12:41 -0000 On 6/12/20 12:56 PM, Mark Johnston wrote: > On Fri, Jun 12, 2020 at 12:46:27PM -0700, John Baldwin wrote: >> On 6/12/20 9:14 AM, Mark Johnston wrote: >>> Hi, >>> >>> I noticed that the opencrypto framework maintains counters for various >>> operations. These counters are all global and are updated >>> non-atomically, so they aren't SMP-friendly and won't be precise. I >>> wrote a patch to convert them to counter(9), which fixes both issues, >>> and I note that kern.crypto_stats was renamed to kern.crypto.stats in >>> HEAD so presumably we can use this opportunity to break the sysctl ABI >>> as well (the counters have to be widened from 32 bits to 64 bits). >>> Nothing in the base system seems to actually fetch these counters >>> outside of some code under tools/, which wasn't updated when the sysctl >>> was renamed. >> >> I think this is fine. I'd probably not oppose just removing the stats >> outright though. Not clear to me how useful they really are (I've never >> used them, always used dtrace or other stats that are more specific) > > I think the current stats are not particularly useful, but I could > imagine adding stats that might be. For instance, a counter for failed > CRYPTO_OP_VERIFY_DIGEST operations, or for operations handled by > software drivers vs. hardware drivers. I noticed while testing GELI > with a WIP driver that I had forgotten to implement AES-XTS+HMAC, so the > tests were causing GELI to fall back to a software implementation. > Counters could perhaps make it easier to spot cases where a consumer is > unexpectedly using an unaccelerated implementation. Or is there already > an easy way to spot that? I use a dtrace script for that sort of thing: https://github.com/bsdjhb/kdbg/blob/master/dtrace/crypto_drivers.d I have other dtrace scripts I haven't committed that are also useful (like printing out the 'csp' when creating sessions) For ccr I added counters for specific types of operations (ETA, GCM, CCM, cipher, and digest) that I also used when working on ccr(4). KTLS also has its own counters for ktls_ocf for TLS 1.2 vs 1.3. -- John Baldwin From owner-freebsd-hackers@freebsd.org Sat Jun 13 20:10:05 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF2F1341631 for ; Sat, 13 Jun 2020 20:10:05 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49kpbw4dJCz4R47 for ; Sat, 13 Jun 2020 20:10: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.15.2/8.15.2) with ESMTPSA id 05DK9nTI056573 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Jun 2020 16:09:57 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: FreeBSD Hackers From: George Mitchell Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= mQINBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABtChHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZStmcmVlYnNkQG01cC5jb20+iQJUBBMBCAA+FiEENdM4ZHktsJW5kKZX wRES3m+p4fkFAlhZcR0CGyMFCQlmAYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQwRES 3m+p4flqmw/9Emr/ydTG2n9o/IX1yVCNcHVFenVrcOY0L+DGQYZRO/XpLvsGYcuSIQId1w7h l4HZKI89ri2fF2ks6upMqBajLf8s7a8PnYrbw5bPaoOFyNTjv57GLZVsYw95kmMUpK6siuAA fXvHfKUpC/sThbwSv/1CLryVG74+5vdI8j7cQeDM436FThxlVfHKrILIiL34D4WThFB3hV/Y 2A+mQwXmdLcuQXXeAazqsFJL8sgEKSC7GMcExDkVpGc5Rh2hu97a4Sa7qWX9G/YdZOrcDacJ XxfvePn3m3WfRtXN/r0lUfiVXiqkFfbvqSaZQ0I4UvZXNGd/gH4jKHtX9RTH9G96UZeHNoMo tPw9U0fx8Ceh72nUL9qzqnmok/ryWm+6gt4Q1eRP7QAosOa1g/RgUdS1Z9IuCmbXMDp5kbNw L4ZoDMF5U3mmh8/IOKkhGopNLbNv0mwUgC59pnCptiOVx8DyckXWC4L2r6PKbWGrcGIzsUER 9smfL10gpp5H5agjwwPZI6/kzJ0R5nBzQWAlwqI73YAy6JI0HTD6lvxW7yWm2fGjEfmyaBOU 8OLUin7auoFSn+QmD5yNCUn5Ls77qHARkT1ZGocAnQkvZBGTwXpvyJixygXsm+vSUFDYBOSn cR54vdXOEMqrJk6SGau5YI9V7EhQVveE1BUp8ofWf2oo4RG5Ag0EWCcufAEQALuTOxmqMFE+ ieev/rcL3wVJrcuKS+pBbKCY9IIL0OwVf98HQJJcgdOsdDhruVd19nJNlwZ3Fc34wLw7y2GO 9WrpZiYKnI4n9urhLE5r1ydBInlI/1UKZWgM3/dPjJtcXMsC3vnqR9DmOxW4/SbqJDjP3XzO FleT4yip3AaNhPGwEPTZrubVp5hp/JojaZn690TLRwOFXg8NcjpOEs0Bq9M+OLpmsF0flrgs yDfS7y+SQ17R4Iq9T7RxZvZVAh510yGGIZIETYO/4Dh417VVm+gaksOVh2egetpUUvYYc0Ub KaP+5F/WGNrmRb1F6SKypvLlKkYAHCsUUSzsAGl9gbQhEEpuOMbUKp1979HoRMkW+8046kIo 8BZ6ph8izG/g4dZOaEqKGEhqdhYIB7UwMtFFuPtSs5Nl6JrZYni/nzFtTmtVCgcj9PNqrzqt fNFYhNznD6St6wxp3TOm9D3TQF0dzwBM1jZpb8WvmK3k6oy8hbpjiBzxn3kyRA9Vzy+PdbN/ G5a1k0rpZu/ivpBuLCDVGljUmgQigXg6xkk5UxBoHp7MPvG9prZ5jqdEa2r1KgnGjaq+VJsu Uqrw10dVgeG1NulDU1+sQl+/mwtflbkimhjDDjxsVgfrv7uvV/9be+gGm1KATuqdgCboSb1s QAo5ARfwFfChrnh+fTfPpPKHABEBAAGJAiQEGAEIAA8FAlgnLnwCGwwFCQlmAYAACgkQwRES 3m+p4fno9w/4m+swztkzxSWdutjgSv2mw+PdrKWVGFAUD2HoY1Qpi5LNLE6s9pP3qzwpQYwK viOufVJYWZ540ss6BImZBGJwyHouacqrpZjpRo5+ftj07rY1SNd8QjcHDggPfpgJ1D4Il3Xi vRg5/gzkXnRu8dXeVvMP1Ndk/F5wcoLZlQwFtPfu2xyRYIsveXMoyypAvAFSaAGXU0hRzuDJ fGI3LFvpI9UXU2C4MMzjfyZyD2NJEDKOACTo85QQzxgheTDQaDocXW00wknXFMwEItiXp8dO 2zEml/3Kj4efDfjqGpjNefjK0cnj02Byt7y6GozWXyIylrXu0SN9qWRzUVZH3+q+ijA4q3Gm 9uWzLdpjN4QWAiiaEvMhLPohp9DdLsy3kAWWrA3+pAfHSTZXrobMMbSeBkE9E4/WxdKl0nM7 TNslAWcxkTd/7Ly9cxwT8wFdHuQB1hgCmIQxDNXHL1N1ANTeUYum1w9nUg6e1M0UWu+nk3Cw qL7oL2KZe13mQnU/CFwlhbf+i//j3SXrQLlIVQv9Fn805bxIcVo9yqUZyoiV7EUpvOsxDCZh ej3mNYF5nRCf6trEJQVk0aLC26zJAYExykdUlRqc4I13XPhlt+aFSMMkoL/thYO6e9oNFK6Q aJEKXomzxxqpceJVmPH6zvqJbOboAdE/mOD0PoS1M6saIQ== Subject: Jumbled Dependencies Message-ID: Date: Sat, 13 Jun 2020 16:09:43 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kLz4V73yGvRkMLwArMM7yTgLETehaamSM" X-Spam-Status: No, score=0.2 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mattapan.m5p.com X-Rspamd-Queue-Id: 49kpbw4dJCz4R47 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 [-4.53 / 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.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.990]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.21)[-0.208]; DMARC_NA(0.00)[m5p.com]; NEURAL_HAM_MEDIUM(-0.93)[-0.934]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; TAGGED_FROM(0.00)[freebsd] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 20:10:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kLz4V73yGvRkMLwArMM7yTgLETehaamSM Content-Type: multipart/mixed; boundary="HnQ3a8TQDCtjtmqC2r1B1NNYBFv0QGSzk"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: Subject: Jumbled Dependencies --HnQ3a8TQDCtjtmqC2r1B1NNYBFv0QGSzk Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable I do package builds on one machine on my (small) network, using portmaster, and then distributes the built packages to my other machines. This week, I decided to make python38, rather than python37, my default version on Python 3. Specifically, portmaster -o lang/python38 python37 I think I missed a step here to upgrade all my py37-* packages to py38-* packages. However, I did recompile a whole list of packages (specific example: vim) so that on my build machine it lists python38-3.8.3 as a dependency. I build a new repo on the build machine and then did a "pkg upgrade" on the other machines. This did install the new version of vim on the client machines, but "pkg info -d vim" on a client still says it depends on python37-3.7.7. (And there are a pile of other packages that are spuriously listed as still depending on python37.) Any suggestions as to why "pkg upgrade" did not copy correct dependency information from the build machine to the clients? And how do I bandage up the foot I shot myself in? -- George --HnQ3a8TQDCtjtmqC2r1B1NNYBFv0QGSzk-- --kLz4V73yGvRkMLwArMM7yTgLETehaamSM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAl7lMo0ACgkQwRES3m+p 4flliRAAg3tUorDRUDxxhHQVp9Lk6gtqxvv9hxOGkvPLqVtHfu/9WmDF5WmUTb4C yUavlAS+3naQJqbdb8FG9KS4w8lhD759670RkX8x8Uba3WHaaF+5SA+KoIFrH6Ud Oqo1/OmbIYA6mAmbxFCwtkolkcx821juw0oVezv39JokwbnQgfaLvNm8P4xCIJks 835Z/r3/v9kSdhlSxKoUMIaWFaKrjZsNCyUI4ZeHWsNS3DIWIw/Ta6T0j2GOXntn uFbjfjPuQE6lNMdkJZftM1vxLsK2UFl+NRxB8yRVfjJvakYvlSc5yAg1EqmSRXEg Lt73wmuTRoXVesSQEnyFl+oEZSNcNnZRWr1PYidQXKUMf2wJUFvf4Wx3ywpWslBG XyMZUnmlVhbbLAcjJIy3Zx7D7fyIOeGIc+6jASxvp8vUFWB7ViWCsYNsM7zd8bPx vXyIAmq2ns6vwmIvxZcGYIUSCVEucjbOujqseYa8aH8Ik+IR7W50oswdkgch56Il UmIDFtQ6PxeoTOYejs9ff05xYJKRxFcM6uE9pMnVrdvWgkRDUTZ082nIbxMSbJtL XY2tfOWLBjw8zfmZHzJl6eAKw2Q7iDivRAhfeezi20EDpAJF5E6floN2xNaHTqbn 6PMeJXetx2JCWCDIYU1kTmYw7N5nMVpiQtrL1+RMmEqU6UVQiaI= =86Rq -----END PGP SIGNATURE----- --kLz4V73yGvRkMLwArMM7yTgLETehaamSM--