From owner-freebsd-hackers@freebsd.org Sun Apr 23 19:09:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24C6DD4BE5D for ; Sun, 23 Apr 2017 19:09:49 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 B7A9A14C0 for ; Sun, 23 Apr 2017 19:09:48 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:418:3fd::1f] (haymarket.m5p.com [IPv6:2001:418:3fd::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v3NJ9fWi058687 for ; Sun, 23 Apr 2017 15:09:46 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: freebsd-hackers@FreeBSD.org From: George Mitchell Subject: V-e-e-e-r-r-y slow subversion access? Message-ID: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> Date: Sun, 23 Apr 2017 15:09:35 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ep57I6EqFhi5ku8DaHDrROjcWevOaCLJ1" X-Spam-Status: No, score=0.3 required=10.0 tests=ALL_TRUSTED,GAPPY_SUBJECT, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.1 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sun, 23 Apr 2017 15:09:46 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 19:09:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ep57I6EqFhi5ku8DaHDrROjcWevOaCLJ1 Content-Type: multipart/mixed; boundary="7818bBrsxHvp2IUDOcQ7RVXqG6KGw5CeV"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@FreeBSD.org Message-ID: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> Subject: V-e-e-e-r-r-y slow subversion access? --7818bBrsxHvp2IUDOcQ7RVXqG6KGw5CeV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is it just me, or are the FreeBSD subversion mirrors running at a glacial pace for the last couple of days? -- George --7818bBrsxHvp2IUDOcQ7RVXqG6KGw5CeV-- --Ep57I6EqFhi5ku8DaHDrROjcWevOaCLJ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlj8+/UACgkQwRES3m+p 4fkP8w//VoZETMXZcK487Van80jFvcksdkqyfgpr66g/6j+/l8sas4IKjzfcA5tj g9FpdidN7kc5PCQ643cy2N5brvWspkqDvYmbMcH3R7G3y7QS/YC7dX3SKBoD/Jv+ ONW6YcTyfDVTeVMS8EeeNdHnXMsdth9sqtq0UvzmFYWmBiIMut68A+vmONPQteRF m8KJBMyei+iAuzfLo7TG6f67qyx+rck12jjFciVt3BLjyjoR3Q80rMJNib40+sFT NJTujWKazIKoozwosqV4EBUnr5hxzrPP7hkzAiNzW24NpJp23yrphPQ5WofUZWTr dlyi6WR9swU3oFfn6tSNTLOK3Fiz0e9+D8AvvvA85rfXtklh3RFpNQRjvhJM5YEk 63dce5xaaBaRhtdgpClDB8lyJmgHFlHudklxck1ulbfq1FOmd60vdXgX4G8jmJj7 FN8bk3DVqEhSImnvun8Ep+lblSbDuQnpDrxfsdvrKTh34uXV3PquZVAnGJBtC2Ip 7QCoXky9ax4mz7c8CjcK9T9LWybSie1okM/xqCoGZuUMT9l2m7PHWj1d2eYsRxA5 YQ3BQfDBu5h/JxmTutHNYFY/TBxGYGPH6ZjQwpOiBJRW6sBsz3aai66zH4RTQwAV RZmB4t15uQ+UxkC68Em9piS7OuS9jYIc+v0tl7O+BJUGmCX9PsQ= =syks -----END PGP SIGNATURE----- --Ep57I6EqFhi5ku8DaHDrROjcWevOaCLJ1-- From owner-freebsd-hackers@freebsd.org Sun Apr 23 20:02:21 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86FEBD483E6 for ; Sun, 23 Apr 2017 20:02:21 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BE98F86 for ; Sun, 23 Apr 2017 20:02:21 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [192.168.1.10] (unknown [192.168.1.10]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id C48A3D201 for ; Sun, 23 Apr 2017 20:02:14 +0000 (UTC) Subject: Re: V-e-e-e-r-r-y slow subversion access? To: freebsd-hackers@freebsd.org References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> From: Allan Jude Message-ID: Date: Sun, 23 Apr 2017 16:02:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 20:02:21 -0000 On 2017-04-23 15:09, George Mitchell wrote: > Is it just me, or are the FreeBSD subversion mirrors running at a > glacial pace for the last couple of days? -- George > Which mirror are you ending up at? Check the host svn.freebsd.org and then reverse lookup the IP address I end up at svnmir.nyi.freebsd.org, but you might be using the west coast, European, or Asia mirror. -- Allan Jude From owner-freebsd-hackers@freebsd.org Sun Apr 23 21:58:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58811D4DEAE for ; Sun, 23 Apr 2017 21:58:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (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 02EEF9C3 for ; Sun, 23 Apr 2017 21:58:21 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id v3NLwJ0V007532; Sun, 23 Apr 2017 21:58:19 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id v3NLwIoT007531; Sun, 23 Apr 2017 14:58:18 -0700 (PDT) (envelope-from david) Date: Sun, 23 Apr 2017 14:58:18 -0700 From: David Wolfskill To: George Mitchell Cc: freebsd-hackers@FreeBSD.org Subject: Re: V-e-e-e-r-r-y slow subversion access? Message-ID: <20170423215818.GC1439@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , George Mitchell , freebsd-hackers@FreeBSD.org References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline In-Reply-To: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> User-Agent: Mutt/1.8.2 (2017-04-18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 21:58:22 -0000 --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2017 at 03:09:35PM -0400, George Mitchell wrote: > Is it just me, or are the FreeBSD subversion mirrors running at a > glacial pace for the last couple of days? -- George I'm not seeing an issue; then again, my access is strictly to update my local (src, ports, and doc) mirrors (in that sequence). Eliding the end timestamps for src & ports (so we see effective elapsed time) for the last several days: g1-252(11.0-S)[8] grep '^svnsync ' svnsync.log | egrep -wv 'src|ports'| tai= l -40=20 svnsync started at Fri Apr 14 08:30:00 UTC 2017 svnsync for doc ended at Fri Apr 14 08:30:08 UTC 2017 exit status 0 svnsync started at Fri Apr 14 10:30:00 UTC 2017 svnsync for doc ended at Fri Apr 14 10:30:02 UTC 2017 exit status 0 svnsync started at Sat Apr 15 08:30:00 UTC 2017 svnsync for doc ended at Sat Apr 15 08:30:10 UTC 2017 exit status 0 svnsync started at Sat Apr 15 10:30:00 UTC 2017 svnsync for doc ended at Sat Apr 15 10:30:02 UTC 2017 exit status 0 svnsync started at Sun Apr 16 08:30:00 UTC 2017 svnsync for doc ended at Sun Apr 16 08:30:08 UTC 2017 exit status 0 svnsync started at Sun Apr 16 10:30:00 UTC 2017 svnsync for doc ended at Sun Apr 16 10:30:02 UTC 2017 exit status 0 svnsync started at Mon Apr 17 08:30:00 UTC 2017 svnsync for doc ended at Mon Apr 17 08:30:31 UTC 2017 exit status 0 svnsync started at Mon Apr 17 10:30:00 UTC 2017 svnsync for doc ended at Mon Apr 17 10:30:02 UTC 2017 exit status 0 svnsync started at Tue Apr 18 08:30:00 UTC 2017 svnsync for doc ended at Tue Apr 18 08:30:07 UTC 2017 exit status 0 svnsync started at Tue Apr 18 10:30:00 UTC 2017 svnsync for doc ended at Tue Apr 18 10:30:02 UTC 2017 exit status 0 svnsync started at Wed Apr 19 08:30:00 UTC 2017 svnsync for doc ended at Wed Apr 19 08:30:07 UTC 2017 exit status 0 svnsync started at Wed Apr 19 10:30:00 UTC 2017 svnsync for doc ended at Wed Apr 19 10:30:02 UTC 2017 exit status 0 svnsync started at Thu Apr 20 08:30:00 UTC 2017 svnsync for doc ended at Thu Apr 20 08:30:24 UTC 2017 exit status 0 svnsync started at Thu Apr 20 10:30:00 UTC 2017 svnsync for doc ended at Thu Apr 20 10:30:02 UTC 2017 exit status 0 svnsync started at Fri Apr 21 08:30:00 UTC 2017 svnsync for doc ended at Fri Apr 21 08:30:14 UTC 2017 exit status 0 svnsync started at Fri Apr 21 10:30:00 UTC 2017 svnsync for doc ended at Fri Apr 21 10:30:03 UTC 2017 exit status 0 svnsync started at Sat Apr 22 08:30:00 UTC 2017 svnsync for doc ended at Sat Apr 22 08:30:07 UTC 2017 exit status 0 svnsync started at Sat Apr 22 10:30:00 UTC 2017 svnsync for doc ended at Sat Apr 22 10:30:02 UTC 2017 exit status 0 svnsync started at Sun Apr 23 08:30:00 UTC 2017 svnsync for doc ended at Sun Apr 23 08:30:08 UTC 2017 exit status 0 svnsync started at Sun Apr 23 10:30:00 UTC 2017 svnsync for doc ended at Sun Apr 23 10:30:03 UTC 2017 exit status 0 (There are 2 mirror-updates per day: one starting at 08:30Z; another at 10:30Z [1]. This is largely an artifact of me having retained the pattern from when I was updating CVS mirrors, and is set up so that for the bulk of the day -- certainly all the time I'm awake -- my mirrors are "stable".) In any case, the first update is from about 7 - 30 seconds; the second, =66rom about 2 - 3 seconds. [1] That's a lie. The first actually starts at 01:30 US/Pacific; the second, at 03:30 US/Pacific. This is done via subterfuge that is off-topic. :-) Peace, david --=20 David H. Wolfskill david@catwhisker.org Who would have thought that a "hotelier" would be so ... unwelcoming? Sad. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJY/SN6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQ0I3Q0VGOTE3QTgwMUY0MzA2NEQ3N0Ix NTM5Q0M0MEEwNDlFRTE3AAoJEBU5zECgSe4XFgYIALsm/H5YzYm9FrSoo9Ydzl1Q Go2uhx5KiX2jitUwMrXxmkx9trxecZY8tglW9oPftibwfdqW9w9C5moUGGJRhnT8 voSgqW/bkYdwjYt1uQ6r5DvYwH5FbmWtYRhhZJ+huAVkXOzhIvOx2DxhK/PiUSlp IbeyVA4Su57ysuPrCbZzY/2QsjaPXC7q1qTl5Xpjt2mg+FjZOfNbRJsgjMvws7i0 KI7EfUZsOtXnOcj7hXWcAdEBwor/OP0IVtGWNpUtyN9wnCCe3YnQuMfCy1BpuJ8I dxIsDDeFQ/ZIbPSjqhu0X56XXuRrLSw7xs/4qTBadholwnTiNVOckQYGPhF2PkM= =cIUO -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- From owner-freebsd-hackers@freebsd.org Sun Apr 23 23:08:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C899D4D3CF for ; Sun, 23 Apr 2017 23:08:37 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 290681D17 for ; Sun, 23 Apr 2017 23:08:36 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:418:3fd::1f] (haymarket.m5p.com [IPv6:2001:418:3fd::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v3NN8T41059811 for ; Sun, 23 Apr 2017 19:08:34 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: V-e-e-e-r-r-y slow subversion access? To: freebsd-hackers@freebsd.org References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> From: George Mitchell Message-ID: <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> Date: Sun, 23 Apr 2017 19:08:23 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BxfaMoLhFbWRKkeOaxXqxpkMVU1Q1gshR" X-Spam-Status: No, score=0.3 required=10.0 tests=ALL_TRUSTED,GAPPY_SUBJECT, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.1 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Sun, 23 Apr 2017 19:08:35 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 23:08:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BxfaMoLhFbWRKkeOaxXqxpkMVU1Q1gshR Content-Type: multipart/mixed; boundary="bRTeHLdAjuR19sHK9rt0df9qVTo5e6cvn"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> Subject: Re: V-e-e-e-r-r-y slow subversion access? References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> In-Reply-To: --bRTeHLdAjuR19sHK9rt0df9qVTo5e6cvn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/23/17 16:02, Allan Jude wrote: > On 2017-04-23 15:09, George Mitchell wrote: >> Is it just me, or are the FreeBSD subversion mirrors running at a >> glacial pace for the last couple of days? -- George >> >=20 > Which mirror are you ending up at? >=20 > Check the host svn.freebsd.org and then reverse lookup the IP address >=20 > I end up at svnmir.nyi.freebsd.org, but you might be using the west > coast, European, or Asia mirror. >=20 That's where I'm ending up. I am trying to svn update my /usr/ports. svn status shows that the whole repository is locked, but no changes are taking place. netstat shows that I have an established TCP6 connection. Is IPv6 newly available here? Can I coerce an IPv4 connection somehow? -- George --bRTeHLdAjuR19sHK9rt0df9qVTo5e6cvn-- --BxfaMoLhFbWRKkeOaxXqxpkMVU1Q1gshR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlj9M+0ACgkQwRES3m+p 4fnfRBAAlx0RbH1EmY6F66noAstRIIR8VuP/9tW/DrEh1KjgXLXmdxw34iX5z+YW m8DmeqkjBG6ysOG50N6qhvB0V4JzaLr2KCLfhCfNAF5T/Y0H9296VvBSLoQONR4x Z3cCPYo+KqSb9JN/Mi/5kyJcl9FQopleagzhLSxJo/5CkUxAtfXi2RQfOF6Sytm2 N3iawuLi/z0WGjE1HC98mOmYx4PnCBl2B0NL6S7XDLmog77rwyAK4twpNk1bah5/ sAz/EAmxX+C750fGa4patwJiPQ06OmCTnvcc/gM8+CKGOC/nVejU7iBzjDLF2cIk FVg8IaGwdDrgrIHE8u6VpHah5sP4jy7jbYh2NOzdkKpuM8cBkmIyGkpFo9ReA1Iw DbVHT5JrEFHsgD9fGfTPKRB0OZydmIUBsDKE4H2v6SXqmEEy8nVqDqoA9GiA8Hid h0XuGaVy9S2eKscaPbY+799zWr/vHZ8wJnHgoK6mu7/KxXdutoii0ouIV9zfJe7T K1o8Sv2pAIOp4FQMIMtC/KITDIy2Yrcdsu6A5mfk6wRPT5fs+JHeKCBkEdRLEh27 88u+3BqYJdxCRBh7aZPd9qCt4IhrBcTHxDaK2bM4zAoOX7YSvtOrG/bKLfqR6U8e IF+gyKKR+2SUL3O5AnRfUhSCsWCZOjTufLBwez5guGoPdA3fnW8= =H9HM -----END PGP SIGNATURE----- --BxfaMoLhFbWRKkeOaxXqxpkMVU1Q1gshR-- From owner-freebsd-hackers@freebsd.org Mon Apr 24 16:43:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45CCAD4ED41 for ; Mon, 24 Apr 2017 16:43:17 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [IPv6:2001:418:3fd::f7]) (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 CA4921FE6 for ; Mon, 24 Apr 2017 16:43:16 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:418:3fd::1f] (haymarket.m5p.com [IPv6:2001:418:3fd::1f]) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTP id v3OGh9VH065429 for ; Mon, 24 Apr 2017 12:43:14 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: V-e-e-e-r-r-y slow subversion access? To: freebsd-hackers@freebsd.org References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> From: George Mitchell Message-ID: <682b92ea-d5a2-2b38-178b-7229ea9a1a80@m5p.com> Date: Mon, 24 Apr 2017 12:43:01 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2pnx5ogvhL48WFjBv3Ki8lkpV5r11hB2l" X-Spam-Status: No, score=0.3 required=10.0 tests=ALL_TRUSTED,GAPPY_SUBJECT, RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.1 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Mon, 24 Apr 2017 12:43:14 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 16:43:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2pnx5ogvhL48WFjBv3Ki8lkpV5r11hB2l Content-Type: multipart/mixed; boundary="V8uTouNV80mHLw58nplnn1UoQhxs4dN55"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: <682b92ea-d5a2-2b38-178b-7229ea9a1a80@m5p.com> Subject: Re: V-e-e-e-r-r-y slow subversion access? References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> In-Reply-To: <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> --V8uTouNV80mHLw58nplnn1UoQhxs4dN55 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/23/17 19:08, George Mitchell wrote: > [... a bunch of stuff ...] My slow subversion access is limited to one machine on my network. It works with no problems on any other machine. That doesn't make a lot of sense to me, but at least the problem is not at the FreeBSD end. -- George --V8uTouNV80mHLw58nplnn1UoQhxs4dN55-- --2pnx5ogvhL48WFjBv3Ki8lkpV5r11hB2l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAlj+KxwACgkQwRES3m+p 4flTaQ//XABY32MH0m24A/2EOCoAA7iBjJ9bi8rf+4e29v4CgqPbGDSpac5+9i6u yi4Sk0uIdgUtOb2o6CBY0ZkZw6DRcDj2mQZWgSrWl4mvmYaZEsek76b8qMYohb36 u+FosGpHWcv8Kj8wCKyobtriij8izPipEFvouppRpFp2+hdi8oy779XPVkS7/YND WReQUb0qfu3Vdo2f3eR0oYzThVItTcvbNF0d/knu8YIiQFcpB65+5muFIzmQRuR5 ZPqnXWsaoUOtzJeZW2w61xT6QiOjrnB/peFNtJFXg/qS3HIiJgarSjcL+6wuMi1Y 1UJEhDPL26QnHhK5I3reWLUQe67G87BEIv43j7m3H/xsTArH9fgp5b+nKnmibo0P q141zk+cjD/3NlhEcGt3KhhOK0PeyIt6ns1LqzwSZccxG6V+WeV5uJtH8Vb1JEzs qmJqV0fU/u1/h3b7OprXnjk0rBat3Gl6dmR3EALyaK1pn1zIUV7rbMAXqQbFlNxT AcFFaSwM0okkzR8JCnloZ0c32Sctm6vXf1AInwQ7vH/XlplfRuoFJl74OiyQmaGF xO7X+QphM6NDiZ2ISfNc0k0xPimH6ObTupOxc7BP/lxSlBt8RZcBJajTnh7ddLBg KHtb9PcvnPsRWu4hhFsj7/ufDCFsITt9ZlPA2ll/AKKI9eTwCes= =b2vx -----END PGP SIGNATURE----- --2pnx5ogvhL48WFjBv3Ki8lkpV5r11hB2l-- From owner-freebsd-hackers@freebsd.org Mon Apr 24 20:58:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4636AD4E2D5 for ; Mon, 24 Apr 2017 20:58:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D52251DDF for ; Mon, 24 Apr 2017 20:58:03 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x231.google.com with SMTP id m123so79225538wma.0 for ; Mon, 24 Apr 2017 13:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=h6tIQTGsoE64JwJPZrbAL7tpL78euASox0Tsm5rcF+E=; b=cLoVpigwqBhIDbIR/dA7wg9EyJ1yfMiJSK2d7i+ynElbcrkVHF9+paVgarpKeVtsg/ jTwdEPv4LjlFS3BiJD5F0sZaE/fhdRCtctmIvfcz+RPsTBD9m0tu2/+2G/lNkoLWg0Fd IOcsNMXjnNPKJ29PcQ6NmjEx6yPRAm2xg6NSrgLUmEFJakxwwlPKidyKcIGJvKW/I0+F Gcs2/KHfOCTYO2UuKBV5lKJl2roFaQi0OJ9LvgsUm6HcskKbOPF3k+xyDNxxWaaL6JSN aJGNGOTCo1Z2qmk5kh73YXQWeeVPOfBmywaTr+zui5B6ESQkvSWIkqe9crTuTQJmskrN JCpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=h6tIQTGsoE64JwJPZrbAL7tpL78euASox0Tsm5rcF+E=; b=Sr3wYlkt884lEXWzbChZj6R7qolyL9kSY5DcmWjFQb2xFQ6N/pZBf/jfijedUuAJkp a7g3W/3pI8+64RlF5b5p54c2VY/oxx6LtKoNj6wAdDcBEatwRmI6JV+zZehgWdza3+2q +pBFYHOibESNlJeXT23TsS19lXXGEGvSH3i1boet15YMAYGCR3mdsLcReYe+TK7PNjG8 1ByikHFlKL3JEAaIOQmvnNsYKJuzfxuQF2g1f2q5FcpFTwNRkyXSxz4Fc6KOrEt3YKIE cz0cIChQaKZHlQda5nm8MlOVtiDBpsvHKZ8s2vS/gGS68YId2zguZTlSlAUTy0JX8wQ6 QfMA== X-Gm-Message-State: AN3rC/7aO6MGCPCPkgaXLZSKWSsuuqDTk/12nFioF2PMpq9mNZFWbkS7 mO+H7FzjVeokdCuk6/7v7w== X-Received: by 10.28.147.198 with SMTP id v189mr10512721wmd.52.1493067481526; Mon, 24 Apr 2017 13:58:01 -0700 (PDT) Received: from [10.10.1.58] ([185.97.61.26]) by smtp.gmail.com with ESMTPSA id k90sm454567wmi.26.2017.04.24.13.58.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 13:58:00 -0700 (PDT) Subject: Re: V-e-e-e-r-r-y slow subversion access? To: freebsd-hackers@freebsd.org References: <01cbb00c-9f3f-27e7-7f89-68735670a742@m5p.com> <4e7f0d5b-b5e9-71ec-d962-5209a26cd8c3@m5p.com> <682b92ea-d5a2-2b38-178b-7229ea9a1a80@m5p.com> From: Steven Hartland Message-ID: Date: Mon, 24 Apr 2017 21:58:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <682b92ea-d5a2-2b38-178b-7229ea9a1a80@m5p.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 20:58:04 -0000 Incorrect duplex setting? On 24/04/2017 17:43, George Mitchell wrote: > On 04/23/17 19:08, George Mitchell wrote: >> [... a bunch of stuff ...] > My slow subversion access is limited to one machine on my network. > It works with no problems on any other machine. That doesn't make > a lot of sense to me, but at least the problem is not at the FreeBSD > end. -- George > > From owner-freebsd-hackers@freebsd.org Mon Apr 24 23:38:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76CF9D4E4E5; Mon, 24 Apr 2017 23:38:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 4B462B80; Mon, 24 Apr 2017 23:38:14 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 40EE91228; Mon, 24 Apr 2017 23:38:07 +0000 (UTC) Subject: Re: Proposal for a design for signed kernel/modules/etc To: Shawn Webb References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org From: Eric McCorkle Message-ID: <3279bd55-61ca-f46b-b01e-e1167279f43b@metricspace.net> Date: Mon, 24 Apr 2017 19:38:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NXKU5otAgl5if5joOeIffhsUh4JQlahdG" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:38:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NXKU5otAgl5if5joOeIffhsUh4JQlahdG Content-Type: multipart/mixed; boundary="HSPCsW02Won5INu917a2G509jcNFx47sm"; protected-headers="v1" From: Eric McCorkle To: Shawn Webb Cc: "freebsd-hackers@freebsd.org" , freebsd-security@freebsd.org Message-ID: <3279bd55-61ca-f46b-b01e-e1167279f43b@metricspace.net> Subject: Re: Proposal for a design for signed kernel/modules/etc References: <6f6b47ed-84e0-e4c0-9df5-350620cff45b@metricspace.net> <20170327183735.uokjhjaafkawc2id@mutt-hbsd> <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> In-Reply-To: <0943546b-2dcd-597b-e000-38926e55bc1d@metricspace.net> --HSPCsW02Won5INu917a2G509jcNFx47sm Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/27/2017 15:53, Eric McCorkle wrote: > On 03/27/2017 14:37, Shawn Webb wrote: >> Hey Eric, >> >> Thank you for writing this! ELF binary signing has been on my >> ever-growing list of things to research and develop. If you'd like hel= p, >> please let me know. >=20 > I'll probably spin up a branch on my github in the near future. I've gotten an implementation of the signelf utility working well enough to sign some binaries. You can check it out yourself here: https://github.com/emc2/freebsd/tree/elf_signing I also fixed two bugs in libelf in the process :D However, that means you'll need to build and install libelf from the repo. The utility fails when signing files that already have a signature, and verification is unimplemented at this point. But at least you can get a signed binary. --HSPCsW02Won5INu917a2G509jcNFx47sm-- --NXKU5otAgl5if5joOeIffhsUh4JQlahdG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzhiNNveVG6nWjcH1w0wQIFco2cFAlj+jFoACgkQ1w0wQIFc o2fZ/hAAujpdbrKIpRnv2zGamZqIIwfa1GUfuS7qmTMfkr3JCoI9xC4od3qsR6L0 +4rOSTJJt9ERcLttq23P7RaTlyN7Dl7eN/tFig7Xul2d14XsroQAonpXANudmlPi FipagEX+u1pTpBHBTARi9YEAJiesJRXzb1e4NZml/7PHeOb95gyYXCE9YxapdCqo wo5XB3cHbU4MKrwg65D2czDF2OOWbM+qe9T7VLnoRL6UtZtBTuZaidlAdXspnzof g3rd+pNObPXpXuXNVDqfnjsMc0gfwd3kA7lsIaXx6Jo+GLbjxjIrWT3Y5JBRf36z De1id855UO48rOLmX8QXTy2vdsMy9u9S4RPweF25SOfwiNHxODl9jTes4jd57FyJ O4/hRJgwwQvEmHGd2J9E9aBcAYcdlvePNloTxQzrp7YWmdMGAZrtsvCSRRRmRgA7 +UBhYwayeK7x93Xw/xfGjcnko6xWRrg1we+8OX3GWD2IuE4/rPiIT91bb9CW/y59 xu89vu33EYKgDfMZA/aZRYshwggMEL4XtLbFeH/hmng8o4aqWkyp8BHO2PW8e/+f MlXu497N0If3NBRq85WMMYg3qJIrbR6nmuE+DTwcH5Od4FMzkejUU1T6menXoXXW 1mCplgv5d/72voCZ7zcBfhVE2tQQS/9Z+7ed8ZUNWNHOklL5blo= =U2gt -----END PGP SIGNATURE----- --NXKU5otAgl5if5joOeIffhsUh4JQlahdG-- From owner-freebsd-hackers@freebsd.org Mon Apr 24 23:58:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34A87D4EE41 for ; Mon, 24 Apr 2017 23:58:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 D3281B90 for ; Mon, 24 Apr 2017 23:58:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10503 invoked from network); 24 Apr 2017 23:31:52 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Apr 2017 23:31:52 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 24 Apr 2017 19:31:52 -0400 (EDT) Received: (qmail 11984 invoked from network); 24 Apr 2017 23:31:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Apr 2017 23:31:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 66F8FEC88B5; Mon, 24 Apr 2017 16:31:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: The arm64 fork-then-swap-out-then-swap-in failures: a program source for exploring them From: Mark Millard In-Reply-To: <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> Date: Mon, 24 Apr 2017 16:31:50 -0700 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <7BE9D35E-2F53-49B6-ADE0-60570D01892D@dsl-only.net> References: <4DEA2D76-9F27-426D-A8D2-F07B16575FB9@dsl-only.net> <163B37B0-55D6-498E-8F52-9A95C036CDFA@dsl-only.net> <08E7A5B0-8707-4479-9D7A-272C427FF643@dsl-only.net> <20170409122715.GF1788@kib.kiev.ua> <9D152170-5F19-47A2-A06A-66F83CA88A09@dsl-only.net> <9DCAF95B-39A5-4346-88FC-6AFDEE8CF9BB@dsl-only.net> <8FFE95AA-DB40-4D1E-A103-4BA9FCC6EDEE@dsl-only.net> <89D6D677-3BE2-45E2-A902-CC6A0305F3F9@dsl-only.net> <585B43F7-D4C8-431A-BFFE-68B48C3214AE@dsl-only.net> <7D72C3EF-8F77-4701-93C9-1488072215FC@dsl-only.net> To: Jia-Shiun Li , freebsd-arm X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 23:58:34 -0000 On 2017-Apr-19, at 10:28 AM, Mark Millard wrote: > On 2017-Apr-18, at 11:16 AM, Jia-Shiun Li wrote: > >> just noticed that rpi3 wiki page still has outdated issue info regarding >> this (the jemalloc error). Anyone to help update it? >> >> https://wiki.freebsd.org/arm64/rpi3 > > stable/11 is still in process for the fork handling fixes. > > One of the 2 fixes to fork behavior has just been MFC'd: > -r313772 from head is now -r317147 in stable/11 . So > interrupts will no longer trash the sp_el0 register. > > There is still -r316679 from head to go so that > Copy-On-Write would work for fork. (The defect > may be more general than just being for fork.) stable/11 -r317354 completes the fixes: Author: kib Date: Mon Apr 24 07:52:44 2017 New Revision: 317354 URL: https://svnweb.freebsd.org/changeset/base/317354 Log: MFC r316679: Do not lose dirty bits for removing PROT_WRITE on arm64. Modified: stable/11/sys/arm64/arm64/pmap.c Directory Properties: stable/11/ (props changed) . . . See: https://lists.freebsd.org/pipermail/svn-src-stable-11/2017-April/003041.html So now the old rpi3 wiki page material is only for masking some of the problems in older contexts for 12 or for older contexts for 11. [I've not been running 11, just 12.] === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 01:42:27 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9C2DD4E3A5 for ; Tue, 25 Apr 2017 01:42:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 AFB591EFF for ; Tue, 25 Apr 2017 01:42:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9513 invoked from network); 25 Apr 2017 01:43:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 01:43:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Mon, 24 Apr 2017 21:42:25 -0400 (EDT) Received: (qmail 8880 invoked from network); 25 Apr 2017 01:42:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 01:42:25 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C73A6EC88B5; Mon, 24 Apr 2017 18:42:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: Evidence of a source of irq 1023's (with last irq 27) Message-Id: Date: Mon, 24 Apr 2017 18:42:24 -0700 Cc: Tom Vijlbrief To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 01:42:28 -0000 Note: The same kernel used below but installed on a rpi3 (aarch64) does not report such spurious interrupts. The issue is somehow specific to the Pine64+'s or at least not general to all aarch64's. (I've access to a Pine64+ 2GB but Tom V. to a Pine64+ 1GB if I understand right. I do not know about other folks.) The initial pine64+ 2GB context had a powered hub with an SSD and had Ethernet plugged in. But unplugging everything but the serial console and applying power gets the same sort of thing, other than instead of 107 shown for the first "last irq" a 64 was shown instead. I made the following change in order to gather more evidence for the spurious interrupts that I and others have seen on Pine64+'s: FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.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/arm/arm/gic.c (revision 317015) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,15 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +//#define EXPECTED_SPURIOUS_IRQ 1023 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +// } #endif return (FILTER_HANDLED); } @@ -720,6 +726,18 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { +//#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +#endif +// } + return (FILTER_HANDLED); } The second block of code is in the "next_irq:" part of the code and has a "nextirq:" prefix text to make its messages unique. The console result from a boot attempt with this was as follows but first I will note one line from it showing the irq 27 binding: ehci0: mem 0x1c1a000-0x1c1a0ff = irq 27 on simplebus0 That 27 is involved in what is shown below. >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Probing 3 block devices.....* done ZFS found no pools UFS found 1 partition Consoles: EFI console =20 Command line arguments: loader.efi Image base: 0xb8dc4000 EFI version: 2.05 EFI Firmware: Das U-boot (rev 0.00) FreeBSD/arm64 EFI loader, Revision 1.1 EFI boot environment Loading /boot/defaults/loader.conf /boot/kernel/kernel text=3D0x7ba128 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] /boot/entropy size=3D0x1000 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... =20 Using DTB provided by EFI at 0x49000000. KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT r317015M arm64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) VT: init without driver. Starting CPU 1 (1) Starting CPU 2 (2) Starting CPU 3 (3) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 clk_fixed2: on aw_ccu0 aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 aw_gate0: mem 0x1c20060-0x1c20073 on = aw_ccu0 aw_modclk0: mem 0x1c20088-0x1c2008b on aw_ccu0 aw_modclk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 aw_modclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 simplebus0: on ofwbus0 aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 regfix0: on simplebus0 psci0: on ofwbus0 aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 iichb0: mem 0x1f03400-0x1f037ff irq 24 on simplebus0 iicbus0: on iichb0 awusbphy0: mem = 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 0 on ofwbus0 gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 gpio0: mem 0x1c20800-0x1c20bff irq = 8,9,10 on simplebus0 gpiobus0: on gpio0 aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on = simplebus0 axp81x_pmu0: at addr 0x746 irq = 30 on iicbus0 gpiobus1: on axp81x_pmu0 generic_timer0: irq 1,2,3,4 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a10_mmc0: mem = 0x1c0f000-0x1c0ffff irq 5 on simplebus0 mmc0: on a10_mmc0 gpioc0: on gpio0 uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on = simplebus0 uart0: console (115384,n,8,1) awg0: mem = 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 miibus0: on awg0 rgephy0: PHY 0 on = miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow rgephy1: PHY 1 on = miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow awg0: Ethernet address: 02:ba:58:11:06:4e aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on = simplebus0 gpioc1: on axp81x_pmu0 iic0: on iicbus0 aw_thermal0: mem = 0x1c25000-0x1c253ff irq 25 on simplebus0 ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on = simplebus0 usbus0 on ohci0 ehci0: mem 0x1c1a000-0x1c1a0ff = irq 27 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on = simplebus0 usbus2 on ohci1 ehci1: mem 0x1c1b000-0x1c1b0ff = irq 29 on simplebus0 usbus3: EHCI version 1.0 usbus3 on ehci1 cryptosoft0: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 on = CPU0 0,1,2,3: last irqs: 107,0,0,0 Timecounters tick every 1.000 msec gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 0,1,2,3: last irqs: 27,0,0,0 . . . The messages just seem to be continuously generated. I ended up = unplugging the Pine64+ 2GB power. But they were all 27's expect for that first one being a 107 (or 64). So this starts before any of the other cores are started. I'll see if I can come up with a test showing later behavior. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 04:06:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F390D4FB56 for ; Tue, 25 Apr 2017 04:06:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-26.reflexion.net [208.70.210.26]) (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 5468F1F95 for ; Tue, 25 Apr 2017 04:06:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11165 invoked from network); 25 Apr 2017 04:06:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 04:06:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 00:06:12 -0400 (EDT) Received: (qmail 12350 invoked from network); 25 Apr 2017 04:06:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 04:06:12 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B3E98EC8552; Mon, 24 Apr 2017 21:06:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: Evidence of a source of irq 1023's (with last irq 27) From: Mark Millard In-Reply-To: Date: Mon, 24 Apr 2017 21:06:11 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 04:06:14 -0000 [I add more acquired information from generated messages this time, spanning a full boot and some later activity.] On 2017-Apr-24, at 6:42 PM, Mark Millard wrote: > Note: The same kernel used below but installed > on a rpi3 (aarch64) does not report such spurious > interrupts. The issue is somehow specific > to the Pine64+'s or at least not general > to all aarch64's. (I've access to a Pine64+ > 2GB but Tom V. to a Pine64+ 1GB if I understand > right. I do not know about other folks.) >=20 >=20 > The initial pine64+ 2GB context had a powered hub with > an SSD and had Ethernet plugged in. But unplugging > everything but the serial console and applying power > gets the same sort of thing, other than instead of > 107 shown for the first "last irq" a 64 was shown > instead. >=20 >=20 > I made the following change in order to gather > more evidence for the spurious interrupts that > I and others have seen on Pine64+'s: >=20 > FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c > Index: /usr/src/sys/arm/arm/gic.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/arm/arm/gic.c (revision 317015) > +++ /usr/src/sys/arm/arm/gic.c (working copy) > @@ -672,9 +672,15 @@ >=20 > if (irq >=3D sc->nirqs) { > #ifdef GIC_DEBUG_SPURIOUS > +//#define EXPECTED_SPURIOUS_IRQ 1023 > +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > device_printf(sc->gic_dev, > - "Spurious interrupt detected: last irq: %d on = CPU%d\n", > - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); > + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" > + "0,1,2,3: last irqs: %d,%d,%d,%d\n", > + irq, sc->nirqs, > + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), > + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); > +// } > #endif > return (FILTER_HANDLED); > } > @@ -720,6 +726,18 @@ > if (irq < sc->nirqs) > goto dispatch_irq; >=20 > +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { > +//#undef EXPECTED_SPURIOUS_IRQ > +#ifdef GIC_DEBUG_SPURIOUS > + device_printf(sc->gic_dev, > + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" > + "0,1,2,3: last irqs: %d,%d,%d,%d\n", > + irq, sc->nirqs, > + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), > + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); > +#endif > +// } > + > return (FILTER_HANDLED); > } >=20 > The second block of code is in the "next_irq:" > part of the code and has a "nextirq:" prefix > text to make its messages unique. >=20 > The console result from a boot attempt with this > was as follows but first I will note one line from > it showing the irq 27 binding: >=20 > ehci0: mem = 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 >=20 > That 27 is involved in what is shown below. >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Probing 3 block devices.....* done > ZFS found no pools > UFS found 1 partition > Consoles: EFI console =20 > Command line arguments: loader.efi > Image base: 0xb8dc4000 > EFI version: 2.05 > EFI Firmware: Das U-boot (rev 0.00) >=20 > FreeBSD/arm64 EFI loader, Revision 1.1 > EFI boot environment > Loading /boot/defaults/loader.conf > /boot/kernel/kernel text=3D0x7ba128 data=3D0x9e6f8+0x39c3fe = syms=3D[0x8+0x103b60+0x8+0xf8a79] > /boot/entropy size=3D0x1000 >=20 > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... =20 > Using DTB provided by EFI at 0x49000000. > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 > The Regents of the University of California. All rights = reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 12.0-CURRENT r317015M arm64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on = LLVM 4.0.0) > VT: init without driver. > Starting CPU 1 (1) > Starting CPU 2 (2) > Starting CPU 3 (3) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: unblocking device. > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > aw_ccu0: on ofwbus0 > clk_fixed0: on aw_ccu0 > clk_fixed1: on aw_ccu0 > aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 > aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 > clk_fixed2: on aw_ccu0 > aw_pll2: mem 0x1c2002c-0x1c2002f on aw_ccu0 > aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 > aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 > aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 > aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 > aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 > aw_gate0: mem 0x1c20060-0x1c20073 on = aw_ccu0 > aw_modclk0: mem 0x1c20088-0x1c2008b on = aw_ccu0 > aw_modclk1: mem 0x1c2008c-0x1c2008f on = aw_ccu0 > aw_modclk2: mem 0x1c20090-0x1c20093 on = aw_ccu0 > aw_pll3: mem 0x1c20044-0x1c20047 on aw_ccu0 > aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 > aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 > simplebus0: on ofwbus0 > aw_reset0: mem 0x1c202c0-0x1c202cb on = simplebus0 > aw_reset1: mem 0x1c202d0-0x1c202d3 on = simplebus0 > aw_reset2: mem 0x1c202d8-0x1c202db on = simplebus0 > regfix0: on simplebus0 > psci0: on ofwbus0 > aw_sid0: mem 0x1c14000-0x1c143ff on = simplebus0 > iichb0: mem 0x1f03400-0x1f037ff irq 24 on simplebus0 > iicbus0: on iichb0 > awusbphy0: mem = 0x1c19400-0x1c19423,0x1c1a800-0x1c1a803,0x1c1b800-0x1c1b803 on = simplebus0 > gic0: mem = 0x1c81000-0x1c81fff,0x1c82000-0x1c83fff,0x1c84000-0x1c85fff,0x1c86000-0x1c= 87fff irq 0 on ofwbus0 > gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 224 > gpio0: mem 0x1c20800-0x1c20bff irq = 8,9,10 on simplebus0 > gpiobus0: on gpio0 > aw_nmi0: mem 0x1f00c0c-0x1f00c43 irq 23 on = simplebus0 > axp81x_pmu0: at addr 0x746 irq = 30 on iicbus0 > gpiobus1: on axp81x_pmu0 > generic_timer0: irq 1,2,3,4 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality = 1000 > Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 > rtc0: mem 0x1f00000-0x1f00053 irq 16,17 on simplebus0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > cpufreq_dt0: on cpu0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > a10_mmc0: mem = 0x1c0f000-0x1c0ffff irq 5 on simplebus0 > mmc0: on a10_mmc0 > gpioc0: on gpio0 > uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 11 on = simplebus0 > uart0: console (115384,n,8,1) > awg0: mem = 0x1c30000-0x1c300ff,0x1c00030-0x1c00033 irq 21 on simplebus0 > miibus0: on awg0 > rgephy0: PHY 0 on = miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > rgephy1: PHY 1 on = miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, = 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, = 1000baseT-FDX-flow-master, auto, auto-flow > awg0: Ethernet address: 02:ba:58:11:06:4e > aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 22 on = simplebus0 > gpioc1: on axp81x_pmu0 > iic0: on iicbus0 > aw_thermal0: mem = 0x1c25000-0x1c253ff irq 25 on simplebus0 > ohci0: mem 0x1c1a400-0x1c1a4ff irq 26 on = simplebus0 > usbus0 on ohci0 > ehci0: mem = 0x1c1a000-0x1c1a0ff irq 27 on simplebus0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ohci1: mem 0x1c1b400-0x1c1b4ff irq 28 on = simplebus0 > usbus2 on ohci1 > ehci1: mem = 0x1c1b000-0x1c1b0ff irq 29 on simplebus0 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > cryptosoft0: > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 = on CPU0 > 0,1,2,3: last irqs: 107,0,0,0 > Timecounters tick every 1.000 msec > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 27 = on CPU0 > 0,1,2,3: last irqs: 27,0,0,0 > . . . >=20 > The messages just seem to be continuously generated. I ended up = unplugging > the Pine64+ 2GB power. >=20 > But they were all 27's expect for that first one being a 107 (or 64). >=20 > So this starts before any of the other cores are started. >=20 >=20 > I'll see if I can come up with a test showing later behavior. I updated my change to avoid reporting the: nextirq: . . . last irq: 27 on CPU 0 messages. This allows the boot to progress in reasonable time and exposes more notices with other content. FreeBSDx64# svnlite diff /usr/src/sys/arm/arm/gic.c Index: /usr/src/sys/arm/arm/gic.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/arm/arm/gic.c (revision 317015) +++ /usr/src/sys/arm/arm/gic.c (working copy) @@ -672,9 +672,15 @@ =20 if (irq >=3D sc->nirqs) { #ifdef GIC_DEBUG_SPURIOUS +#define EXPECTED_SPURIOUS_IRQ 1023 +// if (irq !=3D EXPECTED_SPURIOUS_IRQ) { device_printf(sc->gic_dev, - "Spurious interrupt detected: last irq: %d on = CPU%d\n", - sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid)); + "Spurious interrupt %d detected of %d: last irq: %d = on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +// } #endif return (FILTER_HANDLED); } @@ -720,6 +726,22 @@ if (irq < sc->nirqs) goto dispatch_irq; =20 + if ( irq !=3D EXPECTED_SPURIOUS_IRQ + || ( 0 =3D=3D PCPU_GET(cpuid) + && 27 !=3D sc->last_irq[0] + ) + ) { +#undef EXPECTED_SPURIOUS_IRQ +#ifdef GIC_DEBUG_SPURIOUS + device_printf(sc->gic_dev, + "nextirq: Spurious interrupt %d detected of %d: last = irq: %d on CPU%d\n" + "0,1,2,3: last irqs: %d,%d,%d,%d\n", + irq, sc->nirqs, + sc->last_irq[PCPU_GET(cpuid)], PCPU_GET(cpuid), + = sc->last_irq[0],sc->last_irq[1],sc->last_irq[2],sc->last_irq[3]); +#endif + } + return (FILTER_HANDLED); In this section I mix in comments at points of the sequence and I do not show every message but blocks of them. This example has the Ethernet plugged in and the powered USB HUB and its SSD in place. The SSD has the root file system that is booted. Initially for test test context: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 107 on = CPU0 0,1,2,3: last irqs: 107,0,0,0 Timecounters tick every 1.000 msec usbus0: gic0: nextirq: Spurious interrupt 1023 detected of 224: last = irq: 92 on CPU0 0,1,2,3: last irqs: 92,0,0,0 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on = usbus0 ugen1.1: at usbus1 uhub1: on = usbus1 ugen2.1: at usbus2 uhub2: on = usbus2 ugen3.1: at usbus3 uhub3: on = usbus3 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 . . . Then later "last irq: 106"s start being involved: . . . gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 . . . Once multiple cores are running the "nextirq:" messages stop and transition to all being from the first message block in the updated code. At which point "last irq: 27 on CPU 0" can be and is reported again. First I show up to the first non"nextirq:" message. . . . . . gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,0,0,0 da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SPC-4 SCSI device da0: Serial Number da0: 40.000MB/s transfers da0: 228936MB (468862128 512 byte sectors) da0: quirks=3D0x2 Release APs gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU0 0,1,2,3: last irqs: 106,27,27,27 CPU 0: ARM Cortex-A53 r0p4 affinity: 0 Instruction Set Attributes 0 =3D Instruction Set Attributes 1 =3D <0> Processor Features 0 =3D Processor Features 1 =3D <0> Memory Model Features 0 =3D <4k Granule,64k = Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA> Memory Model Features 1 =3D <> Debug Features 0 =3D <2 CTX Breakpoints,4 Watchpoints,6 = Breakpoints,PMUv3,Debug v8> Debug Features 1 =3D <0> Auxiliary Features 0 =3D <0> Auxiliary Features 1 =3D <0> CPU 1: ARM Cortex-A53 r0p4 affinity: 1 CPU 2: ARM Cortex-A53 r0p4 affinity: 2 CPU 3: ARM Cortex-A53 r0p4 affinity: 3 Trying to mount root from ufs:/dev/ufs/PINE642Grootfs [rw,noatime]... Setting hostuuid: a4f7fbeb-f668-11de-b280-ebb65474e619. Setting hostid: 0xcd8e9e25. Starting file system checks: /dev/ufs/PINE642Grootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/PINE642Grootfs: clean, 40252336 free (325480 frags, 4990857 = blocks, 0.7% fragmentation) Mounting local filesystems:gic0: nextirq: Spurious interrupt 1023 = detected of 224: last irq: 92 on CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/gcc6 /usr/local/lib/perl5/5.24/mach/CORE = /usr/local/llvm40/lib Setting hostname: pine64. Setting up harvesting: = [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATT= ACH,CACHED Feeding entropy: . awg0: link state changed to DOWN Starting dhclient. awg0: no link ......awg0: link state changed to UP got link Starting Network: lo0 awg0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 inet 127.0.0.1 netmask 0xff000000=20 groups: lo=20 nd6 options=3D21 awg0: flags=3D8843 metric 0 mtu = 1500 options=3D8000b ether 02:ba:58:11:06:4e inet 192.168.1.103 netmask 0xffffff00 broadcast 192.168.1.255=20 media: Ethernet autoselect (1000baseT ) status: active nd6 options=3D29 Starting devd. add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Creating and/or trimming log files. Starting syslogd. Starting rpcbind. No core dumps found. NFS access cache time=3D60 Clearing /tmp (X related). NFSv4 is disabled Starting mountd. Starting nfsd. Updating motd:. Mounting late filesystems:. Starting ntpd. Starting powerd. And from here on no more "nextirq:" messages occur during the boot activity. . . gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 Performing sanity check on sshd configuration. gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 gic0: 0,1,2,3: last irqs: 27,27,27,106 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 Starting sshd. gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,27 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on = CPU3 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU1 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU2 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU2 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,114,27,106 . . . Eventually there is evidence of 114 (see above) and of 32 or such in the list of last irqs across the cores, for example: Starting background file system checks in 60 seconds. gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 32 on = CPU1 Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,32,27,27 0,1,2,3: last irqs: 27,32,27,27 . . . 114 and 32 are not as common. Eventually when sitting idle it quits generating messages. Then if I run openssl speed, possibly in parallel, it is not generating messages while busy, other than possibly some at the start. But something like find / -name test print does generate messages. For example: gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: nextirq: Spurious interrupt 1023 detected of 224: last irq: 92 on = CPU0 0,1,2,3: last irqs: 92,27,27,27 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU2 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 gic0: gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on = CPU0 Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 27 on CPU0 0,1,2,3: last irqs: 27,27,27,106 gic0: Spurious interrupt 1023 detected of 224: last irq: 106 on CPU3 0,1,2,3: last irqs: 27,27,27,106 . . . Only initially did it get 92's, but note that they are "nextirq:" messages again! The rest being 27's and 106's and being from the first message code instead of from the "nextirq:" message. Trying find looking at the mmcsd0 gets nearly all 92's with "nextirq:" messages, suggesting that it is tied to the microSD card I/O, much like 27 seems to be for USB. For now I stop with that. I've not figured out how to get any better/non-redundant information. I vaguely remember that I've once seen something that had a table with something about what irq's numbers were for what in some possibly analogous context. But I do not remember where I ran into such a document. (And may be it was not for the Pine64+ context.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 05:03:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00A8BD4F633 for ; Tue, 25 Apr 2017 05:03:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (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 A8DE910C6 for ; Tue, 25 Apr 2017 05:03:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17451 invoked from network); 25 Apr 2017 05:03:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 05:03:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 01:03:15 -0400 (EDT) Received: (qmail 8912 invoked from network); 25 Apr 2017 05:03:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 05:03:14 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 428DFEC88E9; Mon, 24 Apr 2017 22:03:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Mon, 24 Apr 2017 22:03:13 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> References: To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 05:03:17 -0000 I found some basic reference material for the "last irq" numbers for the A64 that is in the Pine64+ 2GB (and 1GB). . . IRQ 27: PPI 11 interrupt, vector 0x006C (I've no clue about this one beyond it being a "Private Peripheral Interrupt" example, somehow specific to each core separately.) The rest of the IRQs are "Shared Peripheral Interrupt"s. . . IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 There were some: IRQ 114: EMAC interrupt, vector 0x01C8 IRQ 32: UART 0 interrupt, vector 0x0080 And the first "last irq:" for each boot was one of: IRQ 107: USB-OHCIO interrupt, vector 0x0A1C IRQ 64: External Non-Mask Interrupt, vector 0x0100 Neither 107 or 64 occurred again after the first message for a boot. 64 showed up when no USB device was plugged in; 107 showed when one was left plugged in (plugged in before powering on the Pine64+ 2GB). 1023 for the current irq number is special and not specific to the A64. So far I can not tell if the kernel mishandles the A64 in some way that leads to 1023's vs. if this is just what an A64 does for some odd reason, even with fully-correct software. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 07:25:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A8E4D4F2F3 for ; Tue, 25 Apr 2017 07:25:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (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 DCA74167F for ; Tue, 25 Apr 2017 07:25:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12184 invoked from network); 25 Apr 2017 07:25:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 07:25:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 03:25:29 -0400 (EDT) Received: (qmail 17239 invoked from network); 25 Apr 2017 07:25:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 07:25:29 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0692DEC856A; Tue, 25 Apr 2017 00:25:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> Date: Tue, 25 Apr 2017 00:25:28 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 07:25:32 -0000 On 2017-Apr-24, at 10:03 PM, Mark Millard wrote: > I found some basic reference material for the > "last irq" numbers for the A64 that is in the > Pine64+ 2GB (and 1GB). . . > > IRQ 27: PPI 11 interrupt, vector 0x006C > (I've no clue about this one beyond it being a > "Private Peripheral Interrupt" example, somehow > specific to each core separately.) Looks to be a timer, not that I can tell much about it: timer { compatible = "arm,armv8-timer"; interrupts = , , , ; }; But looking around I've seen references to needing IRQ_TYPE_NONE if the register is read-only, avoiding writes to read-only registers, --with such timers as examples (not necessarily A64 specific material though). > The rest of the IRQs are "Shared Peripheral > Interrupt"s. . . > > IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 > > IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 > > > There were some: > > IRQ 114: EMAC interrupt, vector 0x01C8 > IRQ 32: UART 0 interrupt, vector 0x0080 > > And the first "last irq:" for each boot was > one of: > > IRQ 107: USB-OHCIO interrupt, vector 0x0A1C > IRQ 64: External Non-Mask Interrupt, vector 0x0100 > > Neither 107 or 64 occurred again after the first > message for a boot. 64 showed up when no USB device > was plugged in; 107 showed when one was left plugged > in (plugged in before powering on the Pine64+ 2GB). > > 1023 for the current irq number is special > and not specific to the A64. > > > So far I can not tell if the kernel mishandles the > A64 in some way that leads to 1023's vs. if this > is just what an A64 does for some odd reason, even > with fully-correct software. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 09:55:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 145A7D4F4C6 for ; Tue, 25 Apr 2017 09:55:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-25.reflexion.net [208.70.210.25]) (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 C92431FB for ; Tue, 25 Apr 2017 09:55:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15678 invoked from network); 25 Apr 2017 09:58:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 09:58:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 05:55:42 -0400 (EDT) Received: (qmail 5287 invoked from network); 25 Apr 2017 09:55:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 09:55:41 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2D235EC8552; Tue, 25 Apr 2017 02:55:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] Date: Tue, 25 Apr 2017 02:55:40 -0700 References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org In-Reply-To: Message-Id: <62AF263E-8028-44AB-8AFA-B5F08C96673D@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 09:55:44 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard = wrote: >=20 >> I found some basic reference material for the=20 >> "last irq" numbers for the A64 that is in the >> Pine64+ 2GB (and 1GB). . . >>=20 >> IRQ 27: PPI 11 interrupt, vector 0x006C >> (I've no clue about this one beyond it being a >> "Private Peripheral Interrupt" example, somehow >> specific to each core separately.) >=20 > Looks to be a timer, not that I can tell > much about it: >=20 > timer { > compatible =3D "arm,armv8-timer"; > interrupts =3D (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>; > }; >=20 > But looking around I've seen references to needing IRQ_TYPE_NONE > if the register is read-only, avoiding writes to read-only > registers, --with such timers as examples (not necessarily > A64 specific material though). Looking around more the read-only status seems to be an implementation defined area for PPI's. But I have other notes later below on what appears to me to be a mismatch between _HIGH vs. _LOW use and what arm_gic_architecture_specification_v2.0.pdf says. >> The rest of the IRQs are "Shared Peripheral >> Interrupt"s. . . >>=20 >> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >>=20 >> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >>=20 >>=20 >> There were some: >>=20 >> IRQ 114: EMAC interrupt, vector 0x01C8 >> IRQ 32: UART 0 interrupt, vector 0x0080 >>=20 >> And the first "last irq:" for each boot was >> one of: >>=20 >> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >>=20 >> Neither 107 or 64 occurred again after the first >> message for a boot. 64 showed up when no USB device >> was plugged in; 107 showed when one was left plugged >> in (plugged in before powering on the Pine64+ 2GB). >>=20 >> 1023 for the current irq number is special >> and not specific to the A64. >>=20 >>=20 >> So far I can not tell if the kernel mishandles the >> A64 in some way that leads to 1023's vs. if this >> is just what an A64 does for some odd reason, even >> with fully-correct software. Looking around I see in sys/arm/arm/gic_common.h : #define GICD_ICFGR(n) (0x0C00 + (((n) >> 4) * 4)) /* v1 = ICDICFR */ #define GICD_I_PER_ICFGRn 16 /* First bit is a polarity bit (0 - low, 1 - high) */ #define GICD_ICFGR_POL_LOW (0 << 0) #define GICD_ICFGR_POL_HIGH (1 << 0) #define GICD_ICFGR_POL_MASK 0x1 /* Second bit is a trigger bit (0 - level, 1 - edge) */ #define GICD_ICFGR_TRIG_LVL (0 << 1) #define GICD_ICFGR_TRIG_EDGE (1 << 1) #define GICD_ICFGR_TRIG_MASK 0x2 But Pine64+ is based on (from what I read): arm_gic_architecture_specification_v2.0.pdf and that does not match for the "polarity" part of GICD_ICFGR code in the above. Quoting (for both bits, focused on PPI to some extent but some material applies to SPIs as well). . . For each supported PPI, it is IMPLEMENTATION DEFINED whether software can program the corresponding Int_config field. [2F+1:2F] Int_config, field F For Int_config[1], the most significant bit, bit [2F+1], the encoding = is: =E2=80=A2 0 Corresponding interrupt is level-sensitive. =E2=80=A2 1 Corresponding interrupt is edge-triggered. Int_config[0], the least significant bit, bit [2F], is reserved, but see Table 4-19 for the encoding of this bit on some early implementations of this GIC architecture. [so reserved instead of polarity in general] For SGIs: Int_config[1] Not programmable, RAO/WI. [So 1's fit with SGIs for Int_config[1].] For PPIs and SPIs: Int_config[1] For SPIs, this bit is programmable.a For PPIs it is = IMPLEMENTATION DEFINED whether this bit is programmable. A read of this bit always returns the = correct value to indicate whether the corresponding interrupt is level-sensitive or = edge-triggered. [But SGIs and PPIs are not the same for Int_config[1].] As for what reserved bits are intended to be, quoting more places. . . Bit positions described as Reserved are UNK/SBZP. UNK/SBZP UNKNOWN on reads, Should-Be-Zero-or-Preserved on writes. In any implementation, the bit must read as 0, or all 0s for a bit = field, and writes to the field must be ignored. Software must not rely on the = field reading as 0, or all 0s for a bit field, and must use an SBZP policy to write to the field. [The Int_config[1] wording overrides the read part of the above.] So it would appear that use of IRQ_TYPE_LEVEL_HIGH is a violation of the intent for PPI's by it translating to include use of GICD_ICFGR_POL_HIGH which uses 1 instead of 0 for the reserved bit. [As for those "early" implementations. . .] On a GIC where the handling mode of peripheral interrupts is = configurable, the encoding of Int_config[0] for PPIs and SPIs, is: =E2=80=A2 0 Corresponding interrupt is handled using the N-N = model. =E2=80=A2 1 Corresponding interrupt is handled using the 1-N = model. [which I do not think applies to the A64, instead the N-N model applies to PPIs and the 1-N model to SPIs with no control to do otherwise. But it is very different from a high vs. low polarity when it does apply.] Quoting another place. . . In a multiprocessor implementation, if bit[1] of the Int_config field for any PPI is programmable then GICD_ICFGR1 is banked for each connected processor. This register holds the Int_config fields for the PPIs, interrupts 16-31. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 21:58:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 461CFD50DD7 for ; Tue, 25 Apr 2017 21:58:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 E842E12B2 for ; Tue, 25 Apr 2017 21:58:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10309 invoked from network); 25 Apr 2017 21:51:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Apr 2017 21:51:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Tue, 25 Apr 2017 17:51:36 -0400 (EDT) Received: (qmail 5846 invoked from network); 25 Apr 2017 21:51:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Apr 2017 21:51:36 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E1AAFEC8714; Tue, 25 Apr 2017 14:51:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Tue, 25 Apr 2017 14:51:35 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: 7bit Message-Id: References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:58:18 -0000 On 2017-Apr-25, at 12:25 AM, Mark Millard wrote: > On 2017-Apr-24, at 10:03 PM, Mark Millard wrote: > >> I found some basic reference material for the >> "last irq" numbers for the A64 that is in the >> Pine64+ 2GB (and 1GB). . . >> >> IRQ 27: PPI 11 interrupt, vector 0x006C >> (I've no clue about this one beyond it being a >> "Private Peripheral Interrupt" example, somehow >> specific to each core separately.) > > Looks to be a timer, not that I can tell > much about it: > > timer { > compatible = "arm,armv8-timer"; > interrupts = (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>, > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; > }; > > But looking around I've seen references to needing IRQ_TYPE_NONE > if the register is read-only, avoiding writes to read-only > registers, --with such timers as examples (not necessarily > A64 specific material though). > >> The rest of the IRQs are "Shared Peripheral >> Interrupt"s. . . >> >> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >> >> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >> >> >> There were some: >> >> IRQ 114: EMAC interrupt, vector 0x01C8 >> IRQ 32: UART 0 interrupt, vector 0x0080 >> >> And the first "last irq:" for each boot was >> one of: >> >> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >> >> Neither 107 or 64 occurred again after the first >> message for a boot. 64 showed up when no USB device >> was plugged in; 107 showed when one was left plugged >> in (plugged in before powering on the Pine64+ 2GB). >> >> 1023 for the current irq number is special >> and not specific to the A64. >> >> >> So far I can not tell if the kernel mishandles the >> A64 in some way that leads to 1023's vs. if this >> is just what an A64 does for some odd reason, even >> with fully-correct software. When arm_gic_intr(.) jumps to "next_irq:" and finds that there is no next interrupt that is indicated by gic_c_read_4 of GICC_IAR returning 1023 according to arm_gic_architecture_specification_v2.0.pdf . So all the "nextirq:" messages that are in what I reported are as-expected. It is the messages that do not say "nextirq:" that are in question, the ones were the first gic_c_read_4 for GICC_IAR returns 1023 up front for some reason. === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Tue Apr 25 23:02:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 101A0D50738 for ; Tue, 25 Apr 2017 23:02:50 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E57511D82; Tue, 25 Apr 2017 23:02:49 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E95FF5A9F15; Tue, 25 Apr 2017 23:02:47 +0000 (UTC) Date: Tue, 25 Apr 2017 23:02:47 +0000 From: Brooks Davis To: freebsd-hackers@freebsd.org Cc: asomers@freebsd.org, ngie@freebsd.org Subject: racy tests Message-ID: <20170425230247.GA8201@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 23:02:50 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been running the FreeBSD test suite for mips64 under qemu. As a result, I'm seeing some tests fail due to assumptions about timing producing test races. For example one of the pwait tests does this: timeout_many_body() { sleep 1 & =20 p1=3D$! sleep 5 & p5=3D$! sleep 10 &=20 p10=3D$! atf_check \ -o empty \ -e empty \ -s exit:124 \ timeout --preserve-status 7.5 pwait -t 6 $p1 $p5 $p10 } Under emulation, particularly if the host disks are busy, it's easily possible for the first sleep to exit before pwait actually runs. In practice, we could probably get away with cranking up the times a fair bit, but that would make the test slow and the race would still exist. Any thoughts about the right solution? Something not time based would be ideal, but then it seems like we'd need a parallel process to kill some of the waited for victims we quickly end up with something more complicated than pwait that also needs testing... -- Brooks --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJY/9WXAAoJEKzQXbSebgfACPQIAInKbBBIC3kzkZc9Wi6A8kza UQYBlbR0CB4t3if3I+j97XBoNO+lQk9IfazSHCMmEeGJggj1UMSJh+H7p/NsyPoY ektl18buLHti9i8j+YadSRoNgNzWXZCLr+0gp6l2irAoRwHvssFCm+EB6ANWGuWX UnFX2ZolXrvFc4y3YKd1+P35/gIXUGxWRXWK9893+PyFU2XHUig/mIiui1klifIU kRQQVnxmOW0tyCVw7vmfRz9/0B0DpHcyZQwPpMVhZS/A88FQdk0X3RXyZM2XjWjM g3MsmFFoKaZsefKIqF10fPSf5N/pejFMLnL8Jm/aD3/bjh3fU5Re/5XXwHiAbhY= =LyF5 -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-hackers@freebsd.org Wed Apr 26 04:30:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 617BDD511A0 for ; Wed, 26 Apr 2017 04:30:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 252CB6C4 for ; Wed, 26 Apr 2017 04:30:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18887 invoked from network); 26 Apr 2017 04:33:32 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 04:33:32 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 00:30:22 -0400 (EDT) Received: (qmail 23247 invoked from network); 26 Apr 2017 04:30:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 04:30:21 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1ACD8EC7B46; Tue, 25 Apr 2017 21:30:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r317015 (and before) vs. Pine64+ 2GB (an aarch64) and spurious interrupts: [the A64 IRQ numbers involved other than 1023] From: Mark Millard In-Reply-To: Date: Tue, 25 Apr 2017 21:30:20 -0700 Cc: Tom Vijlbrief Content-Transfer-Encoding: quoted-printable Message-Id: <23D019EB-DF40-45FD-A981-50CED7EC3ABA@dsl-only.net> References: <49C0BC5D-8A31-4E77-AFC6-6F027CA3AB1E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:30:24 -0000 On 2017-Apr-25, at 2:51 PM, Mark Millard wrote: > On 2017-Apr-25, at 12:25 AM, Mark Millard = wrote: >=20 >> On 2017-Apr-24, at 10:03 PM, Mark Millard = wrote: >>=20 >>> I found some basic reference material for the=20 >>> "last irq" numbers for the A64 that is in the >>> Pine64+ 2GB (and 1GB). . . >>>=20 >>> IRQ 27: PPI 11 interrupt, vector 0x006C >>> (I've no clue about this one beyond it being a >>> "Private Peripheral Interrupt" example, somehow >>> specific to each core separately.) >>=20 >> Looks to be a timer, not that I can tell >> much about it: >>=20 >> timer { >> compatible =3D "arm,armv8-timer"; >> interrupts =3D > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>, >> > (GIC_CPU_MASK_SIMPLE(4) | = IRQ_TYPE_LEVEL_HIGH)>; >> }; >>=20 >> But looking around I've seen references to needing IRQ_TYPE_NONE >> if the register is read-only, avoiding writes to read-only >> registers, --with such timers as examples (not necessarily >> A64 specific material though). _HIGH is an incorrect description for A64's gic. Allwinner_A64_User_Manual_V1.0.pdf explicitly says, quoting: 3.12. GIC For details about GIC, please refer to the GIC PL400 technical reference manual and ARM GIC Architecture Specification V2.0. DDI0471B_gic400_r0p1_trm.pdf is explicit about the actual type of signal, quoting: 2.3.2 PPIs A PPI is an interrupt that is specific to a single processor. All PPI signals are active-LOW level-sensitive. arm_gic_architecture_specification_v2.0.pdf is not as specific. DDI0471B_gic400_r0p1_trm.pdf does describe what irq 27 (so PPI 11) is specifically. It also mentions that GICD) ICFGRn's even bits (Int_config[0]'s) are implemented but are always read-only, provided only for legacy software. But when I looked around more it looked like there was explicit code structure that ignored various details and forced other settings so that the _HIGH status was actually not used. >>> The rest of the IRQs are "Shared Peripheral >>> Interrupt"s. . . >>>=20 >>> IRQ 92: SD/MMC Host Controller 0 interrupt, vector 0x0170 >>>=20 >>> IRQ 106: USB-EHCI0 interrupt, vector 0x01A8 >>>=20 >>>=20 >>> There were some: >>>=20 >>> IRQ 114: EMAC interrupt, vector 0x01C8 >>> IRQ 32: UART 0 interrupt, vector 0x0080 >>>=20 >>> And the first "last irq:" for each boot was >>> one of: >>>=20 >>> IRQ 107: USB-OHCIO interrupt, vector 0x0A1C >>> IRQ 64: External Non-Mask Interrupt, vector 0x0100 >>>=20 >>> Neither 107 or 64 occurred again after the first >>> message for a boot. 64 showed up when no USB device >>> was plugged in; 107 showed when one was left plugged >>> in (plugged in before powering on the Pine64+ 2GB). >>>=20 >>> 1023 for the current irq number is special >>> and not specific to the A64. >>>=20 >>>=20 >>> So far I can not tell if the kernel mishandles the >>> A64 in some way that leads to 1023's vs. if this >>> is just what an A64 does for some odd reason, even >>> with fully-correct software. >=20 > When arm_gic_intr(.) jumps to "next_irq:" and finds that > there is no next interrupt that is indicated by > gic_c_read_4 of GICC_IAR returning 1023 according to > arm_gic_architecture_specification_v2.0.pdf . >=20 > So all the "nextirq:" messages that are in what I > reported are as-expected. >=20 > It is the messages that do not say "nextirq:" that are > in question, the ones were the first gic_c_read_4 for > GICC_IAR returns 1023 up front for some reason. All my testing has only found the A64's gic architecture's 1023 irq as the irq for everything the code classifies as spurious, everything that is "too large to be one of the used irq's". I find no evidence of any such generation other than automatic 1023's from the gic. arm_gic_intr handles the 1023's appropriately from what I read. No 1023 should be a problem. I've not found anything saying that the 1023's should not be generated by the gic, it appears optional for various ones being generated that are seen in the first read of GICC_IAR. Other gics might not. (I've not checked the gic status in an rpi3 but an rpi3 with the same kernel does not generate these 1023's seen on Pine64+ 2GB and 1GB boxes --and possibly other A64 boxes.) It appears that something like: # svnlite diff /usr/src/sys/arm/arm/gic.h = = Index: = /usr/src/sys/arm/arm/gic.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/arm/arm/gic.h (revision 317015) +++ /usr/src/sys/arm/arm/gic.h (working copy) @@ -39,7 +39,7 @@ #ifndef _ARM_GIC_H_ #define _ARM_GIC_H_ =20 -#define GIC_DEBUG_SPURIOUS +//#define GIC_DEBUG_SPURIOUS =20 #define GIC_FIRST_SGI 0 /* Irqs 0-15 are = SGIs/IPIs. */ #define GIC_LAST_SGI 15 would be more appropriate for at least the Pine64+ 2GB and 1GB so that the debug messages do not mess up use of the console (and cause extra activity and its consequences). This might help other A64's too. The GIC_DEBUG_SPURIOUS goes back to gic.c in head -r291424 from 2015-Nov 28 (UTC). While it moved to gic.h it seem to have stayed enabled since it was added. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed Apr 26 04:59:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2BBF6D51813 for ; Wed, 26 Apr 2017 04:59:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 D41023CF for ; Wed, 26 Apr 2017 04:59:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9771 invoked from network); 26 Apr 2017 04:59:38 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Apr 2017 04:59:38 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Wed, 26 Apr 2017 00:59:38 -0400 (EDT) Received: (qmail 4057 invoked from network); 26 Apr 2017 04:59:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Apr 2017 04:59:38 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 85028EC7B46; Tue, 25 Apr 2017 21:59:37 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Should sys/arm/arm/gic.h 's GIC_DEBUG_SPURIOUS be disabled? It would help Pine64+ 2GB and 1GB console use --and possibly other A64's Message-Id: <446204CA-0347-49FE-9EDC-24F4F273A0A3@dsl-only.net> Date: Tue, 25 Apr 2017 21:59:36 -0700 Cc: Tom Vijlbrief To: mmel@FreeBSD.org, freebsd-arm , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 04:59:40 -0000 This note is prompted by problems using the console on Pine64+ 2GB 's when it is busy. (And 1GB 's as reported by Tom V.) There are extensive messages about spurious interrupts. The following notes are written from the view of the A64's documented gic-400. All my testing has only found the A64's gic architecture's 1023 irq as the irq for everything the code classifies as spurious, everything that is "too large to be one of the used irq's" turns out to be the 1023 value. I find no evidence of any such generation of large irq's other than automatic 1023's generated by the gic itself. arm_gic_intr handles the 1023's appropriately from what I read. No 1023 should be a problem. I've not found anything saying that the 1023's should not be generated by the gic, it appears optional for various ones being generated that are seen in the first read of GICC_IAR for a core. Other gics might not. (I've not checked the gic status in an rpi3 but an rpi3 with the same kernel does not generate the spurious interrupt messages.) The "next_irq:" code should get a 1023 when no more interrupts are available for the core for an ARM64 and its gic --and it does. It appears that something like: # svnlite diff /usr/src/sys/arm/arm/gic.h = = Index: = /usr/src/sys/arm/arm/gic.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/arm/arm/gic.h (revision 317015) +++ /usr/src/sys/arm/arm/gic.h (working copy) @@ -39,7 +39,7 @@ #ifndef _ARM_GIC_H_ #define _ARM_GIC_H_ =20 -#define GIC_DEBUG_SPURIOUS +//#define GIC_DEBUG_SPURIOUS =20 #define GIC_FIRST_SGI 0 /* Irqs 0-15 are = SGIs/IPIs. */ #define GIC_LAST_SGI 15 would be more appropriate for at least the Pine64+ 2GB and 1GB so that the debug messages do not mess up use of the console (and cause the extra activity and its consequences). This might help other A64's too. The same sort of thing goes for stable/11's sys/arm/arm/gic.c that still has the older code structure but with GIC_DEBUG_SPURIOUS defined and used to cause the messages. The GIC_DEBUG_SPURIOUS goes back to gic.c in head -r291424 from 2015-Nov 28 (UTC) via mmel. While GIC_DEBUG_SPURIOUS moved to gic.h it seem to have stayed enabled since it was added. Note: In my testing I temporarily made variations of the messages that reported more. I found nothing I could point to as suggesting an error. It all seemed fine because of the 1023 status and the code's handling that that. [Some --but far form all-- this activity is visible in a different sequence of list submittals. The above is the overall conclusion of my investigation. The other messages clearly show my learning-as-I-go status for this.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Wed Apr 26 02:22:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CDC4D4FCB3; Wed, 26 Apr 2017 02:22:55 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EF8EA49; Wed, 26 Apr 2017 02:22:55 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id f76so81246756qke.2; Tue, 25 Apr 2017 19:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+cf7DkfaPGHK/kZGSh4y+qCLx/Juvh2LAkdfUwudXfA=; b=dsnPJYgd1wdKa/olZOJEvon/YuzMXAce1KHuUx8+iF6HfYWvw7dtGgtphv7ZUQyGug VUSqXs0Igll3clIQrEQ3SUuwC+xEOjhx2EaRmWVj6yEyx9rJR+KqOhtYQkx2RhukxRZN GhNb4yCYeu/ltVIkI19H1Cb5+mXkgyd/hUP5g9gizWg0GgrLZlLFddxRCW0wNdONr9D/ DgEvgcSBrcABAxv4XQGMy+WMWBnNk53f4slkIBn6pJvU7qdb4A9m2ae/P7J7YQV1YnCB Tfs5gBBa6smz/PkDaNELHc1iBUQWJmdOccydJBN4J9ZdQHEi8VkKtum0dycsRswoUnKL SAnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+cf7DkfaPGHK/kZGSh4y+qCLx/Juvh2LAkdfUwudXfA=; b=NI6YIwjPKSLzEocOdU0vDwJUU0ZfL1PmIl9nEBeXHhESQ4N6tfS0ToxB1PBJiRbFfB veZzDbZUxAiIXtKBeYu45/KdN15aAJ0+NqVfrPkRI10ra8Tzrvg4pH58vCBg+UTd/IEl wRSF6rTi9FGS/BK53q2KQ3Bjm8WYXGYSOs6p9zUmjk/Ql5QZsW6KG9Vq7iADbiMLObor BjYp8zDR6BRqZUOOxx7Rs63o6TvMr4mM6cupCaHa/4MvojgGC9eE2St0daf8Ajnz5WTg EXWauDTNf/G9pifa+QubZK0hi1DNWJGDywDOWkIqNtVJm891Nlv9E9etdMRT94jvKGPv aHSg== X-Gm-Message-State: AN3rC/5wlSbANhOrcZp4yfoFptEFM6F6enGRdChQRyx7Buu2Klnm6HrC RjvEsY9mVEz1WUVev1PExewx0mexXmll X-Received: by 10.55.127.199 with SMTP id a190mr21761429qkd.123.1493173374248; Tue, 25 Apr 2017 19:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.93.83 with HTTP; Tue, 25 Apr 2017 19:22:53 -0700 (PDT) In-Reply-To: <20170425230247.GA8201@spindle.one-eyed-alien.net> References: <20170425230247.GA8201@spindle.one-eyed-alien.net> From: Ngie Cooper Date: Tue, 25 Apr 2017 19:22:53 -0700 Message-ID: Subject: Re: racy tests To: Brooks Davis Cc: "freebsd-hackers@freebsd.org" , Alan Somers , "bdrewery@freebsd.org" , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 26 Apr 2017 11:04:23 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:22:55 -0000 On Tue, Apr 25, 2017 at 4:02 PM, Brooks Davis wrote: > I've been running the FreeBSD test suite for mips64 under qemu. As a > result, I'm seeing some tests fail due to assumptions about timing producing > test races. For example one of the pwait tests does this: > > timeout_many_body() > { > sleep 1 & > p1=$! > > sleep 5 & > p5=$! > > sleep 10 & > p10=$! > > atf_check \ > -o empty \ > -e empty \ > -s exit:124 \ > timeout --preserve-status 7.5 pwait -t 6 $p1 $p5 $p10 > } > > Under emulation, particularly if the host disks are busy, it's easily > possible for the first sleep to exit before pwait actually runs. > In practice, we could probably get away with cranking up the times a > fair bit, but that would make the test slow and the race would still > exist. > > Any thoughts about the right solution? Something not time based would > be ideal, but then it seems like we'd need a parallel process to kill > some of the waited for victims we quickly end up with something more > complicated than pwait that also needs testing... (Adding bdrewery@, testing@) I need to think about this a bit. The issue might be that we're using the wrong timer for sleep(1)/need to account for being interrupted. Needless to say, emulation really screws up timing assumptions because virtual clocks don't function like hardware clocks. Thanks, -Ngie From owner-freebsd-hackers@freebsd.org Wed Apr 26 15:40:22 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 609E3D511FE for ; Wed, 26 Apr 2017 15:40:22 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD58B19 for ; Wed, 26 Apr 2017 15:40:22 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:becd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id AFE401870 for ; Wed, 26 Apr 2017 15:40:14 +0000 (UTC) To: "freebsd-hackers@freebsd.org" From: Eric McCorkle Subject: Generating sources during buildworld Message-ID: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> Date: Wed, 26 Apr 2017 11:40:10 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7qp1q1g5xT8XjOTT92nMWQcaELFLw0GxR" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:40:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7qp1q1g5xT8XjOTT92nMWQcaELFLw0GxR Content-Type: multipart/mixed; boundary="aOaKO2Qb9Q5VwEXEbPk5epcLHPwmfQnmC"; protected-headers="v1" From: Eric McCorkle To: "freebsd-hackers@freebsd.org" Message-ID: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> Subject: Generating sources during buildworld --aOaKO2Qb9Q5VwEXEbPk5epcLHPwmfQnmC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm looking for some help with the build system, specifically how to generate sources for a library that will then be used to build the librar= y. Basically, I want to have a tool which collects public key certificates, then converts them into .c files which are used to build both loader and the kernel. Knowing how LLVM works, it seems that this is possible; however, I've been unable to find documentation on how to write a makefile that accomplishes this. Can someone point me to documentation or examples on how to do this? --aOaKO2Qb9Q5VwEXEbPk5epcLHPwmfQnmC-- --7qp1q1g5xT8XjOTT92nMWQcaELFLw0GxR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWQC/WgAKCRBWwohAqoAE jSUMAQCgRCgfpNn66/jtWiW+y06f9TEIQnWje20sa5qqFobo/QD9Ge3zvIfZkTYm 5sRJANE3Xvkl/5bf7qsxG0pFV2+Q+gg= =03kA -----END PGP SIGNATURE----- --7qp1q1g5xT8XjOTT92nMWQcaELFLw0GxR-- From owner-freebsd-hackers@freebsd.org Wed Apr 26 15:51:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2A38D515DC for ; Wed, 26 Apr 2017 15:51:55 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C224E646 for ; Wed, 26 Apr 2017 15:51:55 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 847A55A9F15; Wed, 26 Apr 2017 15:51:53 +0000 (UTC) Date: Wed, 26 Apr 2017 15:51:53 +0000 From: Brooks Davis To: Eric McCorkle Cc: "freebsd-hackers@freebsd.org" Subject: Re: Generating sources during buildworld Message-ID: <20170426155153.GA24831@spindle.one-eyed-alien.net> References: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:51:56 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 26, 2017 at 11:40:10AM -0400, Eric McCorkle wrote: > I'm looking for some help with the build system, specifically how to > generate sources for a library that will then be used to build the librar= y. >=20 > Basically, I want to have a tool which collects public key certificates, > then converts them into .c files which are used to build both loader and > the kernel. >=20 > Knowing how LLVM works, it seems that this is possible; however, I've > been unable to find documentation on how to write a makefile that > accomplishes this. Can someone point me to documentation or examples on > how to do this? It the tool is a script then take a look at usr.bin/getaddrinfo/Makefile (make sure it's from the tip of head, the initial version had rather poor style.) If the tool is a compiled program, then things get more complicated. An example of this is usr.bin/fortune/strfile/ and usr.bin/fortune/datfiles/. For a new program, you'd need to make your tool a bootstrap tool in Makefile.inc1. -- Brooks --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZAMIYAAoJEKzQXbSebgfAnjAIAI2cjIB3RbDVvBkFJB7/o+Th OQ8RyX1wk3vRMbCouQppbByGqGbAZ1NEBPsh732rAjji81VhbhrQSECSxpwj2W82 SgK4u6LhasIQeM0zSl/2ItQku9zcWZJJ+Jt/p9JznHMgQznR/Bz/QQWXYRCCJcxU PrdyL8Zrsq7rr079ZdU9qpfQAeK17oawmcODCFgLnCtkt+K2bAvlXxsbrf369BZ1 f14G4TI7LFfkQU6HCEihAi9IMEsgc9FDPx0zhZeViFc/5PwXrWbQ4yhaMQnpju42 Mq+KK6U6XYbLqo6eg1uln/7prjIhvI2OEp+aZI2GJmu8AsxLScX9lEZ5IBI9Hy0= =KFgx -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-hackers@freebsd.org Wed Apr 26 17:01:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6C3BD51884 for ; Wed, 26 Apr 2017 17:01:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B5A39BC for ; Wed, 26 Apr 2017 17:01:45 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: ea88ebfc-2aa1-11e7-8c46-c35e37f62db1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id ea88ebfc-2aa1-11e7-8c46-c35e37f62db1; Wed, 26 Apr 2017 17:00:57 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v3QH1bZQ001541; Wed, 26 Apr 2017 11:01:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1493226097.1195.1.camel@freebsd.org> Subject: Re: Generating sources during buildworld From: Ian Lepore To: Eric McCorkle , "freebsd-hackers@freebsd.org" Date: Wed, 26 Apr 2017 11:01:37 -0600 In-Reply-To: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> References: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:01:45 -0000 On Wed, 2017-04-26 at 11:40 -0400, Eric McCorkle wrote: > I'm looking for some help with the build system, specifically how to > generate sources for a library that will then be used to build the > library. > > Basically, I want to have a tool which collects public key > certificates, > then converts them into .c files which are used to build both loader > and > the kernel. > > Knowing how LLVM works, it seems that this is possible; however, I've > been unable to find documentation on how to write a makefile that > accomplishes this.  Can someone point me to documentation or examples > on > how to do this? > > There's a program named bin2c in contrib/binutils, but nothing seems to use it. There is also firmware(9) and the code in sys/conf/kmod.mk to convert firmware blobs to loadable modules -- not exactly the problem you're solving, but maybe close enough to cobble some ideas from.  Search for occurrances of FIRMWS in kmod.mk. -- Ian From owner-freebsd-hackers@freebsd.org Wed Apr 26 22:28:07 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70D32D51709 for ; Wed, 26 Apr 2017 22:28:07 +0000 (UTC) (envelope-from Zhuojia.Shen@rochester.edu) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0106.outbound.protection.outlook.com [104.47.36.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1C0F35 for ; Wed, 26 Apr 2017 22:28:06 +0000 (UTC) (envelope-from Zhuojia.Shen@rochester.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rochester.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tgYEwpyOyapp+m07N7knkWOHOx9eS+h95hlQTVwjeT4=; b=HOStNbQ0giSTix54rGbiNHLxpU9g9Fi5vTXORbOkyvLCWYyqStf7cxgeyXAdmVZNb/TI0fnhJl/Qm9HbY3kOt2YfcD/BZYGHc7JPnYtlfvoXATG/2/B/oSxo6Mnw7V15Jnirv1TDAgdI4FsDmxl5pm/C0WzD5p792fdeshQslpM= Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=cs.rochester.edu; Received: from j13.cs.rochester.edu (128.151.67.93) by DM5PR07MB3532.namprd07.prod.outlook.com (10.164.153.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Wed, 26 Apr 2017 22:28:04 +0000 From: Zhuojia Shen Subject: Allocate huge chunk of pageable memory in FreeBSD kernel space To: freebsd-hackers@freebsd.org Message-ID: <2c616149-274d-b758-1500-ffd580fd51fd@cs.rochester.edu> Date: Wed, 26 Apr 2017 18:28:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [128.151.67.93] X-ClientProxiedBy: BN3PR03CA0076.namprd03.prod.outlook.com (10.167.1.164) To DM5PR07MB3532.namprd07.prod.outlook.com (10.164.153.142) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b36caf95-6256-4fd7-5ece-08d48cf381f6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:DM5PR07MB3532; X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3532; 3:D1FTFZqP7SCqEn9UXhKyndt9o5uLRgFW0l5OwI3pOVVcuUzruFfjZ+X7aziik5zh5H9CXCoY6uN71jBE3k0bMavyi+F8xtEetdlZIsBOaRFzR+BDlaFVa4qoqQL8yT/8Av0EbgBMlraar5An8Jb4W5dfr4FADcb8X6zZefaDw45bjd3LNn3SjkaA/KhL6Ygzp7Vh62MrtN3X/NhXmWasSEp3+iknZfbf/TJuoPqpuKUHDa1ni6ngE0RFACTpM4yc5Q3xh1fotslqBxwUdEY8I1rblCQo01oAGf2RiiZDWpA21fu5euivKs3egiZZM+0vXMklDQkDaTbokqGcpqwUiA==; 25:HOib7ySMy0f+HQRh82Z6nsQ3Om05dAlJg+el/P7ONcCBHIBHgr0mdNaIICgEsjMjKQ2/TmjYaMUFyTOVn/ZwkB3SLSbb2zCV0TOFVKKQNW7oXP5qG13vJIO9pXEBQnlCsmY5TrNHL9yc+buYXstRslTBdCrsiGwf6bgAMSNnLhdG8jt9Y6wgQzycV/ZI6TQaWxc3eaZHYG+vIJxc+0TfMScJnHOJh82cY69ZpEx981f+tAnsxpIdyYaKr7IgTcC3FN+x9JtS4BBCrw2zRZTny2wzSjZSQKaroKbaFCuelmDYi73tKOwzHYwER/xWnzWUbdX59slukN4a3Av16W7Ra63jC79DdYF2gTYn7YMtOU4aeO5elSEipqLN/rauUjRGp5TFlIbvUDFBhzx5rGWqx0m+AM4Gdmulgi70nsiaDQK40deFe6lHUtkXCA6WdMPQpmYLnPIwpjWB7g+0GYBxTA== X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3532; 31:Wl2HI5isO6/lrj3HMOgP+iee5ypqoQrzEyhekwjif56bNhMCsYsb1LcePlHBPEL9BrozigZ6rw+KPWwjKoMPpaW6CZL1UI4P6F7bsYwflptHHY45Ks/qyH2EjetLCfJmewbPgmojOBDSLqkWyTDAzW13uazm/mBQRTEMFztwXKedRzyWDP1zDKqTIbxP2v33NcF8kfB3Z1cAagYSUa8Om80KRlFEGZ5IBHbjDurKTo1JDMtekbYgHWhZACCmHaFjbZLfSupfKT/FcariulteaszIUBj78Y/F5WljipC1mNQ=; 20:+RCGjCjDIBfJfQn4myDRk3skF32Vh5Rj08xnrvdzHmxunt0/09m04+Zaj3elmVVNaDWUCxZuUEyrt3Y0QT6GcQhfsw8b4TT4reCkfW5eNACb70SaNZIb3k0L6gMMAsJKGGinhyR5vrGvJoSvZeR4qnJ89synXUDS+Fjdrt05vxsH3IQ1bI0cIGaOoGUQlORrn+HoMqUslhnalNbK9WsRzXpq1TlbfpElM1LjxUdpqPQjz3I/A/d9PmaVAfYKWCIsKWSXlaqM8Szdkq9OcDfzLmh/U0ZcH8nBGV/oT52rUOyJvYFppVxWDTg5jrq15wNddg0vzCFa9ypldtdPcjIiDWGLwV57OUIurB4bSJmc8UPgxwnxmJMiI/S7tQBfpRBXQMXvsdtLeDK6yd9h42dakv7cRBZo3QgG+dEV5My6YxqqDTYpjE85Dx4O5x3xMCDkewHDt1oZg8sQcJedF7yPrDkMtbLSr5b0fQw8SYdDT2BbLD43oHtGTFCfYKBIiHaE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148); SRVR:DM5PR07MB3532; BCL:0; PCL:0; RULEID:; SRVR:DM5PR07MB3532; X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3532; 4:Eqc0DLB+HkOe4VezIGjoMNWReNWMb0iisB6F7NKolPWmFNj8VCh50FCCrF+DwJoDJU6g1YxIX9OqAKfo0SAvhQ37IvwnPniNGMFu5z8pQyyFAED1kKsPKdJaseZS0qqno8otSIuNomV8dbVVXEdSmeDOGbAOkhSND18vhocHYZ/dq2vjMJgpcZNrxslXvFiFUEdY+03oX0lbmHoYueBEtAmk/ly0sGe2dTiEuJg9Q/2aUZ8n8PzZzJ0TEhU29SI3QQLScjOCEIwxZ76zWm5sMLMWecc5rtGbPcHdjfZGoadFFNZZKv2yqpKMnlErkO+HMfPSf+MqvHkdkuvL8wUa7XFVtF+FgyH6Pe60+jBJ2DfJny38C/g6E1OvDxNeSW6DH98h2bg0u2dnYLb4oXVTSYlNNX7HvWEGc5zE+U+rkSEbDG00QpX3ok009aDMsadKGDml5diuy4f5shn4hhVP0rfCjtaUrEyGapIPv6Sq4b+ReDVJZ37fW/mI9bVFjeHGT5Ni1cmoGiuW5KarVkMhZPzJxTOMJWGvS8KnR0FtgT0o5Vd52kKqVwLpGtnZqqoqSnvsOtbd1LyyOfsUjzGBhwx8muHcwaSC2k4yvBNtmdN2HQfnYRjsQgdoXosBHRtj71XyOr+GPUurVvzih8qn+GT0RNmdb7LVnQu5gFeWtURL3+8RCCljxIPmRvwo2F0ssPlQKBV1puh6YhA7RmoTwcPAybFpT1Z3v+Wikz86GbzIsNacqzpfj0GJag1KYzku2UsLSo2i/iGaoMxVld6JRVqX0UaPKbbkJRnEeOaWOebIUD3FMYrxtxJpFiedg4QksyzqjAPspbSt84QfqC4oj4gjku4GC4DLPxPSbJbbO6I= X-Forefront-PRVS: 0289B6431E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(39850400002)(39840400002)(39410400002)(39400400002)(39450400003)(2361001)(7736002)(2351001)(2906002)(31696002)(230700001)(47776003)(305945005)(65956001)(33646002)(50986999)(88552002)(66066001)(6116002)(42186005)(54356999)(31686004)(25786009)(75432002)(3846002)(189998001)(4001350100001)(50466002)(83506001)(6916009)(5660300001)(65826007)(81166006)(23676002)(110136004)(38730400002)(6486002)(53936002)(14583001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR07MB3532; H:j13.cs.rochester.edu; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA3TUIzNTMyOzIzOnBIdDVNalJLemNsVXZYYVplL3lPRU1oeTU3?= =?utf-8?B?NThkcjZDdzN6Y3c4QnJpcTI1ZSt5OEFiaGY1eW81WXVQaUQrVjZyM1JlaGN3?= =?utf-8?B?T3Y4K3RObFpzN20raEUzR0tmdE00MDVHRU9TUUlra0hqTjJsT2YraUprTlB3?= =?utf-8?B?c2lnbUlJbHZRUXh0MFJpSmFOODdEa3NmWDdDTzIrWlg2eFhnTk5OaW91d3d1?= =?utf-8?B?ZXFNQU9RWFI0M2JwUG1mNUVoNS9ZaUF1elZrc25EQk10akpsWmFwdTM4TWo4?= =?utf-8?B?dVZKYnFIWjZJSis3N21oN2pBUWo5akQzbUVIbkFGN0NVSGtLSFAxc3c2MDlD?= =?utf-8?B?ZlV1WXhyZUF5R3JnWWFwSzdUTmNrbm5CU2pUMnRRYW5ZOXVvYmhRU1FxU2c3?= =?utf-8?B?ckNGU0JrRFVqWDhOT1ZHOWwrQ1VqVFNiMTVkOTJkS0ZGd3ZUMFB3eC82RS9M?= =?utf-8?B?Y1p2bVMyRGNkWDdIa3JhUTdHeWtCS2RiNkVlL1p3U3ArRTJQM2RWS1B6Y2NL?= =?utf-8?B?NWtiajhDNDk3NUw1dXNNQ0hlbERhQmVLdk5VTDZPREJrUUFIdE13R3FkandV?= =?utf-8?B?RDJrRkF2ZWRZSDJpT0FwVitaVVBhbVFCL2tkVm9MOWtxZmJIVExqSFkxRkFW?= =?utf-8?B?R2ZLcFgwUEp6Q0VKVndGa3VWSVd3Y1ozMzUzRzFjMWljc2hmR3ArczlDcVV3?= =?utf-8?B?aklGVjRlamhUWjlpcWFxaUl1TlF5czAvK0FaY292WkdXaFZqQWJidUp0T1N6?= =?utf-8?B?aEVxRTUxVExsT1VUZk05Tkw2MmMzZkErUHNwK1k3ZjRyL004RjRCTVdGS0Rk?= =?utf-8?B?RFQ1NzlrekpMTldwL05PUmI0SSs1WGNaa3k5K0lwLzh3SHlSRDJZbGZENXlT?= =?utf-8?B?d2QwWDNPZDdqblhBVDNQWjBFQUVjUFZTb0p1TnBmRWh3TDR6ZkNObG44YnYv?= =?utf-8?B?bEZxVUhQNnYrRWhteEpWY0tLWlR1Z2srdG9kSy96NXZhRE5LZ2NXaFU5bTVF?= =?utf-8?B?clh1ankyQktDWkZSa0dZWGtUK3BvTGJnUFBYclFNbml6c0FBV3lpNlFSTUFF?= =?utf-8?B?emwrRFNJWVpqQzdiTFJTcWxGbE5BNFdZcExRa0tPTGpEanlHenRJMDlqSUhn?= =?utf-8?B?NkF2MnhIV0tGR1pGbmUwT2JWSTVUOGpOckxyMFlRV0h4RDZSVTNJSWhwNk5l?= =?utf-8?B?QlRHQ3A1Y0kvM2huRmJJWG1NcGFHRmd2ZnZNZ3UwNW9xcXF3VW1jTStTRjQ4?= =?utf-8?B?SlRDOEJ1RjRsUXNPNlBxQjFaMGF1ZVByajc4UUpVZ3pBQi9PZnBiVTNSSSsr?= =?utf-8?B?TWU0SFZBTER5UllqTExBNVl4cTJQR1hJU3kzK1FiLzhIZ2tQMjZyZ1kvYnJt?= =?utf-8?B?eUJVVW5reWdaam1ockV3aGl2eE9na2lKQ0NCOEJDMGJsQ2tldU9aenpTZkwz?= =?utf-8?Q?YfzTqs=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3532; 6:Z0Ms1xJeE2hht5ySOa7tw57BcB0nnyODiZYjUWZF0ITUuh70r5+9C5+sUaxMTkrGlR4bGnQjqk4zucTtzb7MUT57yQ++hGtq0lTUnTJXdBo9H/0nwfyqzp53ULUGYXDUAYNx4S6W+ituuOozcfxIJqX7xJHIizBF+GxfHiULKBIRkpmOn463f63IpWPVzqhA8m4fI98jjQvgs4jRKw+FTskeb91YHmIGqFN2s7tjDAC+73Y3mS5KJl9KnIOO9CZsBS39+nOFpoXQZwNxSfEJCHtKt2OwoOsSiF7paJALYzc+BvLIJOl70svsKyyYc4f8q6SW+ZlbmG2wxObXDgti/86Vb25ynbFWn5OHEajJhBeZtzf2PvhjGd01cCDSvAfywk9y3yvM4JVbXbkrB+/lO5py/rSnqQffEcDBUAqioShDGUev2mlGa2WEk2Zt6MskG66YXHkyX6dkRu8fEQijHdleGBBinMC/xBysuPX4NHXGELuLDYCztQP0813Ydhjf5gGV6PxYUiB9izNkj6zGJg==; 5:fxQgtXTYwReIRqkclGHbEesWBSTmDPqk1TPoV7LIq5H4eXna/kDqjo0qQuPHY2PlA/CVti7kH2HC43Ll465NWYhjgmhH8S9t4AXGKGNNFgh7fj1BK0bAeVGhYTiQjg0DBdo5zukxXV8ZUaVp/MbJCw==; 24:tySukEXS7ddM8qAWfNJZdnQiCrs6pfY1aV7WyP+WZhiM6yF4N6YNeDBPxnFgL6EyGdwsmCbULOB5to33pRmcXAiAkniGi0iAOXkYuEbnmK0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3532; 7:FcsEb95sUvYEEnZr5s9TwU9JWA4+NQYM7IIBoahhMtyUDwSAf6DRNxgmGIMCLAbutsAUYzz1EeYLoPci7sB5rbxpSAbgLgGO+npJgIbo3SIq5vJMtpv6boH1yOyKZKCbV/QfwkUx9N9/ZM0yL8QFMAGVcC+uTOqZgbNGgeHjQyz1KJgAdp31oJ8Ff1QaV6qCU4G9b3B/kVkLwtk12hCa9D8B52EHatov3gYlgLMm5/tZqUjzoGTCpOuFv+RruzTZ5YLhgjdevKqvU9JKpWx8xJQDPtI8W1pZ36wgOo8Iy0UneaSdwo0XHDwWUF5K3EJcZW5s9c7iFqME3ivJ3a830g== X-OriginatorOrg: cs.rochester.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2017 22:28:04.9809 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR07MB3532 X-Mailman-Approved-At: Wed, 26 Apr 2017 22:40:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 22:28:07 -0000 Hi, I'm working on a project that uses FreeBSD 11.0 on amd64 to do some security research. Now what I want to achieve is to allocate an 8TB portion of memory within the kernel virtual address space using demand paging. I noticed that there is an unused portion of kernel space from 0xffff804020101000 to 0xfffff80000000000 where the 8TB structure will fit. I also noticed that there is a function kmap_alloc_wait() which can be used to allocate pageable memory. Do you suggest that I use this function and, if so, how would I use it? Thank you, Zhuojia -- Zhuojia Shen Graduate Student Department of Computer Science University of Rochester From owner-freebsd-hackers@freebsd.org Thu Apr 27 12:36:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C833D51637 for ; Thu, 27 Apr 2017 12:36:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 594F219CC for ; Thu, 27 Apr 2017 12:36:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 38E9D32BFE; Thu, 27 Apr 2017 14:36:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh2T_NbwucNh; Thu, 27 Apr 2017 14:36:53 +0200 (CEST) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 8B1C332BFD for ; Thu, 27 Apr 2017 14:36:53 +0200 (CEST) To: "freebsd-hackers@freebsd.org" From: Willem Jan Withagen Subject: Disabling program core dumps Message-ID: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> Date: Thu, 27 Apr 2017 14:36:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:36:58 -0000 Hi, Running (googletest) tests some are expected to die: EXPECT_DEATH(). This normally dumps a core, but since it is expected that core is rather useless. Thusfar I've found the best way to limit a program to dump core (from within the program) is to set its RLIMIT_CORE to 0. So I can do this before the test, and then set the old size back once the test is finished. Or is there another way, like setting a flag in process state (which I have not been able to find) --WjW From owner-freebsd-hackers@freebsd.org Thu Apr 27 12:47:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B735ED51C21; Thu, 27 Apr 2017 12:47:09 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id A762489; Thu, 27 Apr 2017 12:47:09 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:7598:6ebc:285c:5f89]) by elvis.mu.org (Postfix) with ESMTPSA id 08E4B346DE24; Thu, 27 Apr 2017 05:47:09 -0700 (PDT) Subject: Re: racy tests To: Ngie Cooper , Brooks Davis References: <20170425230247.GA8201@spindle.one-eyed-alien.net> Cc: "freebsd-testing@freebsd.org" , "freebsd-hackers@freebsd.org" , Alan Somers , "bdrewery@freebsd.org" From: Alfred Perlstein Organization: FreeBSD Message-ID: <878d2f79-df2d-0c6c-bd21-c0e663160f45@freebsd.org> Date: Thu, 27 Apr 2017 05:47:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:47:09 -0000 Can't something similar to this be done? .(05:40:37)(bright@elvis.mu.org) ~ % mkfifo derp .(05:43:46)(bright@elvis.mu.org) ~ % cat derp & [1] 59244 .(05:43:53)(bright@elvis.mu.org) ~ % ( pwait $! && echo "$?" > ex_status )& [2] 59263 .(05:44:28)(bright@elvis.mu.org) ~ % echo "hi" >> derp && echo "exit status: $(cat ex_status)" hi [2] + done ( pwait $! && echo "$?" > ex_status; ) [1] + done cat derp exit status: 0 Make a fifo, lodge a cat(1) process waiting for data, pwait in the background and stuff pwait's status into a file, then unstick the cat(1) by writing to the fifo, and then read the exit status from pwait from the file? \m/ -Alfred On 4/25/17 7:22 PM, Ngie Cooper wrote: > On Tue, Apr 25, 2017 at 4:02 PM, Brooks Davis wrote: >> I've been running the FreeBSD test suite for mips64 under qemu. As a >> result, I'm seeing some tests fail due to assumptions about timing producing >> test races. For example one of the pwait tests does this: >> >> timeout_many_body() >> { >> sleep 1 & >> p1=$! >> >> sleep 5 & >> p5=$! >> >> sleep 10 & >> p10=$! >> >> atf_check \ >> -o empty \ >> -e empty \ >> -s exit:124 \ >> timeout --preserve-status 7.5 pwait -t 6 $p1 $p5 $p10 >> } >> >> Under emulation, particularly if the host disks are busy, it's easily >> possible for the first sleep to exit before pwait actually runs. >> In practice, we could probably get away with cranking up the times a >> fair bit, but that would make the test slow and the race would still >> exist. >> >> Any thoughts about the right solution? Something not time based would >> be ideal, but then it seems like we'd need a parallel process to kill >> some of the waited for victims we quickly end up with something more >> complicated than pwait that also needs testing... > (Adding bdrewery@, testing@) > I need to think about this a bit. The issue might be that we're using > the wrong timer for sleep(1)/need to account for being interrupted. > > Needless to say, emulation really screws up timing assumptions because > virtual clocks don't function like hardware clocks. > > Thanks, > -Ngie > _______________________________________________ > 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 Thu Apr 27 12:48:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12C86D51D99 for ; Thu, 27 Apr 2017 12:48:47 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFD721F2 for ; Thu, 27 Apr 2017 12:48:46 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ua0-x22d.google.com with SMTP id f10so18580057uaa.2 for ; Thu, 27 Apr 2017 05:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t+G3RiRMY2/MVKhBAz18iQiE2HTnyKy3bqi9wBZkpv4=; b=FxD50jMw70tfw9TkJ7tzguTNkido9KpawCjrDSRdXkdtOomlh60HO+X4jAhA8ZE/Ai Dc6tH/9hXvRScWUWra01ShduVXZQlzHVwPyVgneBoluNUOVa94HL6PB44tH+oxhBE7ZL 271DwwKw7lf/EKMTgqeA2EBhS/thsmDp3okTOPmXHH97HzCkrbXXN7ifuN6Alz4HWx4H u3jm9ENudYHDZl3PvDzVSYu/v3ry42k+/+lWQa0NJaiMAnyXTStYAcC9SejkSXOfd0xX dfl3VBVtXyeXofVDwDrMm37emiDSyT6J99l9fLjVBW05G0+y+jGy9dwSkoJ/BToOZaRb zd4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t+G3RiRMY2/MVKhBAz18iQiE2HTnyKy3bqi9wBZkpv4=; b=WATQflE/9xcfbILBbPvqFc0fzn7+4hdsTTBwaoumzLVcPNtJMXfyn6nqGafz13k2eQ 4jTCKpMSKyvgSDC5LML9ydc3FctxVRU+cUVuBiotqT8dfpN5M52k0eAy8UytKBKtU2Cg YscQm6Jeb1QFkSUtjMfSzt5W1jhzxNZdatGONwYqwYRaQSgNNux4CzdbueC676wJWk9/ P9qW8X5alJxDFoRE+zZw9xHDiO1fNvX1YYeX7gdWw8mB2I2QNVZS+1DsAnRmq+NkDWcw UbESir/54EUNoMnosfPyP/eRVynW6ea0nVcC9Uh/unbN1eoyXR1+vZMi6WrXK+C/6hS3 oE6g== X-Gm-Message-State: AN3rC/4t1nENb+oeV11FS2/2Wz1Mucitbxslt0a5peVAeysL10YV08UE 2X/QSmukWjJTo1eH8+hoIcOrsbhnCQ== X-Received: by 10.176.82.136 with SMTP id v8mr2397387uav.123.1493297325842; Thu, 27 Apr 2017 05:48:45 -0700 (PDT) MIME-Version: 1.0 Sender: etnapierala@gmail.com Received: by 10.176.22.222 with HTTP; Thu, 27 Apr 2017 05:48:45 -0700 (PDT) In-Reply-To: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> References: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> From: Edward Napierala Date: Thu, 27 Apr 2017 13:48:45 +0100 X-Google-Sender-Auth: PtSLzMjmGRGwtovKe5Ct4iguVXw Message-ID: Subject: Re: Disabling program core dumps To: Willem Jan Withagen Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:48:47 -0000 There's the kern.coredump sysctl, which makes it possible to disable coredumping globally. 2017-04-27 13:36 GMT+01:00 Willem Jan Withagen : > Hi, > > Running (googletest) tests some are expected to die: EXPECT_DEATH(). > This normally dumps a core, but since it is expected that core is rather > useless. > > Thusfar I've found the best way to limit a program to dump core (from > within the program) is to set its RLIMIT_CORE to 0. > > So I can do this before the test, and then set the old size back once > the test is finished. > > Or is there another way, like setting a flag in process state (which I > have not been able to find) > > --WjW > _______________________________________________ > 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 Thu Apr 27 12:57:33 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5340DD530B5 for ; Thu, 27 Apr 2017 12:57:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 DF05AA80 for ; Thu, 27 Apr 2017 12:57:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v3RCvPGD098746 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 15:57:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v3RCvPGD098746 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v3RCvPPR098745; Thu, 27 Apr 2017 15:57:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Apr 2017 15:57:25 +0300 From: Konstantin Belousov To: Willem Jan Withagen Cc: "freebsd-hackers@freebsd.org" Subject: Re: Disabling program core dumps Message-ID: <20170427125725.GM1622@kib.kiev.ua> References: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:57:33 -0000 On Thu, Apr 27, 2017 at 02:36:52PM +0200, Willem Jan Withagen wrote: > Hi, > > Running (googletest) tests some are expected to die: EXPECT_DEATH(). > This normally dumps a core, but since it is expected that core is rather > useless. > > Thusfar I've found the best way to limit a program to dump core (from > within the program) is to set its RLIMIT_CORE to 0. > > So I can do this before the test, and then set the old size back once > the test is finished. > > Or is there another way, like setting a flag in process state (which I > have not been able to find) See procctl(2) PROC_TRACE_CTL command. Disabling tracing also disables coredumping. From owner-freebsd-hackers@freebsd.org Thu Apr 27 13:30:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92612D53873 for ; Thu, 27 Apr 2017 13:30:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5253C1D10; Thu, 27 Apr 2017 13:30:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 77782325DB; Thu, 27 Apr 2017 15:30:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cygub87H-79l; Thu, 27 Apr 2017 15:30:45 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id A24F6325DA; Thu, 27 Apr 2017 15:30:45 +0200 (CEST) Subject: Re: Disabling program core dumps To: Edward Napierala References: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> Cc: "freebsd-hackers@freebsd.org" From: Willem Jan Withagen Message-ID: Date: Thu, 27 Apr 2017 15:30:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:30:51 -0000 On 27-4-2017 14:48, Edward Napierala wrote: > There's the kern.coredump sysctl, which makes it possible to disable > coredumping globally. Yup, that one I knew. But that is global, where as I'd like to run: setcoreoff(); EXPECT_DEATH(test) setcoreon() And for that I need some micro controls from with in the program. Hence my fiddling with (get|set)_rlimits. --WjW > > 2017-04-27 13:36 GMT+01:00 Willem Jan Withagen >: > > Hi, > > Running (googletest) tests some are expected to die: EXPECT_DEATH(). > This normally dumps a core, but since it is expected that core is rather > useless. > > Thusfar I've found the best way to limit a program to dump core (from > within the program) is to set its RLIMIT_CORE to 0. > > So I can do this before the test, and then set the old size back once > the test is finished. > > Or is there another way, like setting a flag in process state (which I > have not been able to find) > > --WjW > _______________________________________________ > 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 Thu Apr 27 13:39:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AA07D53CF4 for ; Thu, 27 Apr 2017 13:39:14 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DB7B5153 for ; Thu, 27 Apr 2017 13:39:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 002E132B77; Thu, 27 Apr 2017 15:39:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrbqawAaT1Ob; Thu, 27 Apr 2017 15:39:11 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 5311E32B45; Thu, 27 Apr 2017 15:39:11 +0200 (CEST) Subject: Re: Disabling program core dumps To: Konstantin Belousov References: <32ac85ed-f0e5-2f80-299a-3bb1166cd5e6@digiware.nl> <20170427125725.GM1622@kib.kiev.ua> Cc: "freebsd-hackers@freebsd.org" From: Willem Jan Withagen Message-ID: <2e645e8d-125c-b2c8-1401-5a9da68ce5fb@digiware.nl> Date: Thu, 27 Apr 2017 15:39:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170427125725.GM1622@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:39:14 -0000 On 27-4-2017 14:57, Konstantin Belousov wrote: > On Thu, Apr 27, 2017 at 02:36:52PM +0200, Willem Jan Withagen wrote: >> Hi, >> >> Running (googletest) tests some are expected to die: EXPECT_DEATH(). >> This normally dumps a core, but since it is expected that core is rather >> useless. >> >> Thusfar I've found the best way to limit a program to dump core (from >> within the program) is to set its RLIMIT_CORE to 0. >> >> So I can do this before the test, and then set the old size back once >> the test is finished. >> >> Or is there another way, like setting a flag in process state (which I >> have not been able to find) > See procctl(2) PROC_TRACE_CTL command. Disabling tracing also disables > coredumping. Ah, that I did not find. Found procctl, but browsed thru it looking for coredump, but it is wrapped over 2 lines :) So setting PROC_TRACE_CTL_DISABLE_EXEC would work with googletests which fork to actually run the DEATH tests?? --WjW From owner-freebsd-hackers@freebsd.org Thu Apr 27 15:29:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E345D53480; Thu, 27 Apr 2017 15:29:30 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A57EC0E; Thu, 27 Apr 2017 15:29:30 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 39F9E6E; Thu, 27 Apr 2017 17:29:27 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 23C8128497; Thu, 27 Apr 2017 17:29:27 +0200 (CEST) Date: Thu, 27 Apr 2017 17:29:27 +0200 From: Jilles Tjoelker To: Alfred Perlstein Cc: Ngie Cooper , Brooks Davis , "freebsd-testing@freebsd.org" , "freebsd-hackers@freebsd.org" , Alan Somers , "bdrewery@freebsd.org" Subject: Re: racy tests Message-ID: <20170427152926.GA88843@stack.nl> References: <20170425230247.GA8201@spindle.one-eyed-alien.net> <878d2f79-df2d-0c6c-bd21-c0e663160f45@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878d2f79-df2d-0c6c-bd21-c0e663160f45@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:29:30 -0000 On Thu, Apr 27, 2017 at 05:47:11AM -0700, Alfred Perlstein wrote: > Can't something similar to this be done? > .(05:40:37)(bright@elvis.mu.org) > ~ % mkfifo derp > .(05:43:46)(bright@elvis.mu.org) > ~ % cat derp & > [1] 59244 > .(05:43:53)(bright@elvis.mu.org) > ~ % ( pwait $! && echo "$?" > ex_status )& > [2] 59263 > .(05:44:28)(bright@elvis.mu.org) > ~ % echo "hi" >> derp && echo "exit status: $(cat ex_status)" > hi > [2] + done ( pwait $! && echo "$?" > ex_status; ) > [1] + done cat derp > exit status: 0 > Make a fifo, lodge a cat(1) process waiting for data, pwait in the > background and stuff pwait's status into a file, then unstick the > cat(1) by writing to the fifo, and then read the exit status from > pwait from the file? Fifos are indeed a good idea. They are used various times in the /bin/sh tests, which should not wait for any sleeps in successful test runs (my main motivation for this is to be able to run the whole suite in a few seconds). In this case, however, the -t option being tested is inherently related to time. It would be possible to cheat by passing a very long timeout and cut it short by sending SIGALRM using kill (which depends on the concrete implementation). -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Thu Apr 27 15:36:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72C0CD53775; Thu, 27 Apr 2017 15:36:03 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 6265D10DE; Thu, 27 Apr 2017 15:36:03 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from [IPv6:2601:645:8003:a4d6:957:888b:2ca8:bdba] (unknown [IPv6:2601:645:8003:a4d6:957:888b:2ca8:bdba]) by elvis.mu.org (Postfix) with ESMTPSA id 8383F346DE24; Thu, 27 Apr 2017 08:35:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: racy tests From: Alfred Perlstein X-Mailer: iPhone Mail (14E304) In-Reply-To: <20170427152926.GA88843@stack.nl> Date: Thu, 27 Apr 2017 08:35:57 -0700 Cc: Ngie Cooper , Brooks Davis , "freebsd-testing@freebsd.org" , "freebsd-hackers@freebsd.org" , Alan Somers , "bdrewery@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9478F48E-4619-49F2-A9D8-34335C4A13AA@freebsd.org> References: <20170425230247.GA8201@spindle.one-eyed-alien.net> <878d2f79-df2d-0c6c-bd21-c0e663160f45@freebsd.org> <20170427152926.GA88843@stack.nl> To: Jilles Tjoelker X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:36:03 -0000 > On Apr 27, 2017, at 8:29 AM, Jilles Tjoelker wrote: >=20 >> On Thu, Apr 27, 2017 at 05:47:11AM -0700, Alfred Perlstein wrote: >> Can't something similar to this be done? >=20 >> .(05:40:37)(bright@elvis.mu.org) >> ~ % mkfifo derp >> .(05:43:46)(bright@elvis.mu.org) >> ~ % cat derp & >> [1] 59244 >> .(05:43:53)(bright@elvis.mu.org) >> ~ % ( pwait $! && echo "$?" > ex_status )& >> [2] 59263 >> .(05:44:28)(bright@elvis.mu.org) >> ~ % echo "hi" >> derp && echo "exit status: $(cat ex_status)" >> hi >> [2] + done ( pwait $! && echo "$?" > ex_status; ) >> [1] + done cat derp >> exit status: 0 >=20 >> Make a fifo, lodge a cat(1) process waiting for data, pwait in the >> background and stuff pwait's status into a file, then unstick the >> cat(1) by writing to the fifo, and then read the exit status from >> pwait from the file? >=20 > Fifos are indeed a good idea. They are used various times in the /bin/sh > tests, which should not wait for any sleeps in successful test runs (my > main motivation for this is to be able to run the whole suite in a few > seconds). >=20 > In this case, however, the -t option being tested is inherently related > to time. It would be possible to cheat by passing a very long timeout > and cut it short by sending SIGALRM using kill (which depends on the > concrete implementation). Makes sense. I was worried this was the case but I couldn't find any useful d= ocs on atf commands via google and man(3) on a 10.3 system. Thank you, your i= dea makes sense.=20 >=20 > --=20 > Jilles Tjoelker >=20 From owner-freebsd-hackers@freebsd.org Thu Apr 27 19:26:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EB25D53D28 for ; Thu, 27 Apr 2017 19:26:43 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mailout.stack.nl (mailout05.stack.nl [IPv6:2001:610:1108:5010::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E91B168F; Thu, 27 Apr 2017 19:26:43 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailout.stack.nl (Postfix) with ESMTP id 5EAD56E; Thu, 27 Apr 2017 21:26:33 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 4993428497; Thu, 27 Apr 2017 21:26:33 +0200 (CEST) Date: Thu, 27 Apr 2017 21:26:33 +0200 From: Jilles Tjoelker To: Brooks Davis Cc: Eric McCorkle , "freebsd-hackers@freebsd.org" Subject: Re: Generating sources during buildworld Message-ID: <20170427192633.GB88843@stack.nl> References: <3f63e99c-9241-380d-2e3a-12ef6a5a2758@metricspace.net> <20170426155153.GA24831@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170426155153.GA24831@spindle.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 19:26:43 -0000 On Wed, Apr 26, 2017 at 03:51:53PM +0000, Brooks Davis wrote: > On Wed, Apr 26, 2017 at 11:40:10AM -0400, Eric McCorkle wrote: > > I'm looking for some help with the build system, specifically how to > > generate sources for a library that will then be used to build the library. > > Basically, I want to have a tool which collects public key certificates, > > then converts them into .c files which are used to build both loader and > > the kernel. > > Knowing how LLVM works, it seems that this is possible; however, I've > > been unable to find documentation on how to write a makefile that > > accomplishes this. Can someone point me to documentation or examples on > > how to do this? > It the tool is a script then take a look at usr.bin/getaddrinfo/Makefile > (make sure it's from the tip of head, the initial version had rather > poor style.) > If the tool is a compiled program, then things get more complicated. An > example of this is usr.bin/fortune/strfile/ and > usr.bin/fortune/datfiles/. For a new program, you'd need to make your > tool a bootstrap tool in Makefile.inc1. There are actually two kinds of these tools: bootstrap tools and build tools. Bootstrap tools such as strfile are also installed as normal programs; often, they are not built as a bootstrap tool if the version in the host system is sufficiently recent. Build tools are specific to building a particular directory, and are not installed. These work by adding the directory to a list in Makefile.inc1 and adding a build-tools target to the directory's Makefile. Examples are bin/sh and usr.bin/awk. In either case, the tool must be buildable on fairly old systems and your life will be simpler if you can write your tool in shell or awk. -- Jilles Tjoelker From owner-freebsd-hackers@freebsd.org Thu Apr 27 20:29:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D4855D5168B for ; Thu, 27 Apr 2017 20:29:47 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.181]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "*.teksavvy.com", Issuer "DigiCert High Assurance CA-3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 919E21E3 for ; Thu, 27 Apr 2017 20:29:46 +0000 (UTC) (envelope-from 482254ac@razorfever.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CnGAC/UwJZ/0StpUVcGgEBAQECAQEBAQgBAQEBgjyBGSc9hHGKGHOPJgEBAQEBAQUBgQUdAS4BiS+MEYIPHIosQBgBAgEBAQEBAQFrBSOFPxUeWAImAjsxCAEBEIl8DZ4EkAyCJos2gQuFA4JPC4cUe4I6gl8BBJZShn0BAZR1AYkAEIZjkmOBRB84gQoaLDSEegEBAYJdJIlCAQEB X-IPAS-Result: A0CnGAC/UwJZ/0StpUVcGgEBAQECAQEBAQgBAQEBgjyBGSc9hHGKGHOPJgEBAQEBAQUBgQUdAS4BiS+MEYIPHIosQBgBAgEBAQEBAQFrBSOFPxUeWAImAjsxCAEBEIl8DZ4EkAyCJos2gQuFA4JPC4cUe4I6gl8BBJZShn0BAZR1AYkAEIZjkmOBRB84gQoaLDSEegEBAYJdJIlCAQEB X-IronPort-AV: E=Sophos;i="5.37,385,1488862800"; d="scan'208";a="309527543" Received: from 69-165-173-68.dsl.teksavvy.com (HELO mail.razorfever.net) ([69.165.173.68]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2017 16:28:36 -0400 Received: from [127.0.0.1] (mail.razorfever.net [192.168.0.4]) by mail.razorfever.net (8.15.2/8.14.9) with ESMTP id v3RKSZMs058010 for ; Thu, 27 Apr 2017 16:28:35 -0400 (EDT) (envelope-from 482254ac@razorfever.net) X-Authentication-Warning: mail.razorfever.net: Host mail.razorfever.net [192.168.0.4] claimed to be [127.0.0.1] To: freebsd-hackers@freebsd.org From: "Derek (freebsd lists)" <482254ac@razorfever.net> Subject: Hosted CI with FreeBSD targets Message-ID: <913d17aa-9fd1-4797-dd85-23259fc92a18@razorfever.net> Date: Thu, 27 Apr 2017 16:28:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED, FROM_STARTS_WITH_NUMS,RP_MATCHES_RCVD autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.razorfever.net X-Mailman-Approved-At: Thu, 27 Apr 2017 20:58:04 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 20:29:47 -0000 Hiya! Just wondering if anyone has experience with hosted CI services that support FreeBSD targets for building + tests. Looking to add native FreeBSD support to a project's CI, hoping to draw on the community's experience. Would also prefer to run a service, rather than self-host. Thanks! Derek From owner-freebsd-hackers@freebsd.org Thu Apr 27 21:02:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 538DDD53412 for ; Thu, 27 Apr 2017 21:02:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1627219E7 for ; Thu, 27 Apr 2017 21:02:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id k11so22210780ywb.1 for ; Thu, 27 Apr 2017 14:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ezFxPvhlzZxVoJwSlTpVRuAmC5CrJnKx+0VahqZYxwc=; b=UOgOU9nt7jh46Y3ogxrBOFIT2FmSR5Afwi8Ni7bTAOYEMEDYmhlD7yuJ/rekHyRfRH /cbu9wvVbU+AhWYHmxS7NgsnZnFYFmR618TVlMXjoCJxR7WK0yZRWlhfnmfMAgofkxVx 2m6Kv45HPOYYJRXEjdJlkyZ6mpcHWShBAxVfO1nJ9xz210UEmlx6MD01J8uVxBaSkUIV sPQVtL4FxYGQNhhReR+kWOcxq7IzdD4N6XaSPH3R9PZaQJRjpYyU5EtgghT5xcPi/psY duVwl595Dxi68ilDEYis/NkDYS1URZYQ0BsGMSz17Kvqc9yOkwH6hr46REAPA7mvOrPJ qSAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ezFxPvhlzZxVoJwSlTpVRuAmC5CrJnKx+0VahqZYxwc=; b=c30YUpje7IcBqmXwLLvEuT9b3sRq1N5anqeNSKdG2pUWbCLXbX7YseSp42KlkgMYLA 3f7VYPL4Iz3N2pNT7Ydie5434V0JlIoMD0lTcd07lhn/rOGef0LLp9E6ZKWbZzCkLRA/ b02KLVrQMUWfI3aP3hMo/HR61FtUEDiIMB/u7BOEXWPMw8+QcGT369i1s7KHmM6dzr5i GT/oEe2APDx/+E8bMYnnBXtuDm+4rPDuukz4eq29oo1wdsiZYjH6iOJGn4Pvnnmbpthf GEXThbPvpFrVp2XkFigg/wmE7krBbQeGeqheKGMoeWqIBfrjDUg3soNO8ggeBxSJ65ur ptsg== X-Gm-Message-State: AN3rC/7vT5LwWzNj4vTaqBCOsdUok7KgYXZPsv2/D8ziD5Id44HfaOsn 2TylYJSPLDd+torkRomvYchFQQA74Q== X-Received: by 10.129.156.204 with SMTP id t195mr6887888ywg.257.1493326924062; Thu, 27 Apr 2017 14:02:04 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Thu, 27 Apr 2017 14:02:03 -0700 (PDT) In-Reply-To: <913d17aa-9fd1-4797-dd85-23259fc92a18@razorfever.net> References: <913d17aa-9fd1-4797-dd85-23259fc92a18@razorfever.net> From: Alan Somers Date: Thu, 27 Apr 2017 15:02:03 -0600 X-Google-Sender-Auth: 2RF15-zwYwMjQ03tjD_Rus2nPtQ Message-ID: Subject: Re: Hosted CI with FreeBSD targets To: "Derek (freebsd lists)" <482254ac@razorfever.net> Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 21:02:06 -0000 On Thu, Apr 27, 2017 at 2:28 PM, Derek (freebsd lists) <482254ac@razorfever.net> wrote: > Hiya! > > Just wondering if anyone has experience with hosted CI services that support > FreeBSD targets for building + tests. > > Looking to add native FreeBSD support to a project's CI, hoping to draw on > the community's experience. > > Would also prefer to run a service, rather than self-host. > > Thanks! > Derek Sadly, I haven't found any, and not for lack of effort. I think the easiest way to do it is to rent a VPS and setup your own Buildbot or Jenkins server. Please let us know if you find anything better. -Alan From owner-freebsd-hackers@freebsd.org Thu Apr 27 23:14:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B33AED53837; Thu, 27 Apr 2017 23:14:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE9F6D4; Thu, 27 Apr 2017 23:14:17 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3RNEBps011407 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 16:14:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3RNEBRS011406; Thu, 27 Apr 2017 16:14:11 -0700 (PDT) (envelope-from sgk) Date: Thu, 27 Apr 2017 16:14:11 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170427231411.GA11346@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170409220809.GA25076@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 23:14:17 -0000 On Sun, Apr 09, 2017 at 03:08:09PM -0700, Steve Kargl wrote: > Both IEEE-754 2008 and ISO/IEC TS 18661-4 define the half-cycle > trignometric functions cospi, sinpi, and tanpi. The attached > patch implements cospi[fl], sinpi[fl], and tanpi[fl]. Limited > testing on the cospi and sinpi reveal a max ULP less than 0.89; > while tanpi is more problematic with a max ULP less than 2.01 > in the interval [0,0.5]. The algorithms used in these functions > are documented in {ks}_cospi.c, {ks}_sinpi.c, and s_tanpi.c. > > Note 1. ISO/IEC TS 18661-4 says these funstions are guarded by > a predefine macro. I have no idea or interest in what clang and > gcc do with regards to this macro. I've put the functions behind > __BSD_VISIBLE. > > Note 2. I no longer have access to a system with ld128 and > adequate support to compile and test the ld128 implementations > of these functions. Given the almost complete lack of input from > others on improvements to libm, I doubt that anyone cares. If > someone does care, the ld128 files contain a number of FIXME comments, > and in particular, while the polynomial coefficients are given > I did not update the polynomial algorithms to properly use the > coefficients. > > The code is attached the bug reportr. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218514 > I have attached a new diff to the bugzilla report. The diff is 3090 lines and won't be broadcast the mailing list. This diff includes fixes for a few inconsequential bugs and implements modified Estrin's method for sum a few ploynomials. If you want the previous Horner's method then add -DHORNER to your CFLAGS. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Thu Apr 27 23:22:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 979A2D53D05 for ; Thu, 27 Apr 2017 23:22:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 48980D43 for ; Thu, 27 Apr 2017 23:22:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24491 invoked from network); 27 Apr 2017 23:25:48 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 27 Apr 2017 23:25:48 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 27 Apr 2017 19:22:36 -0400 (EDT) Received: (qmail 20935 invoked from network); 27 Apr 2017 23:22:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Apr 2017 23:22:35 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2B1BAEC904C; Thu, 27 Apr 2017 16:22:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 Message-Id: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> Date: Thu, 27 Apr 2017 16:22:34 -0700 To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 23:22:38 -0000 Unfortunately for this FYI the attempt to produce a dump failed and so all the information that I have is what I first captured from the console output: a backtrace. The context was head -r317015 on a Pine64+ 2GB. At the time I was experimenting with trying to build a vm.raw from my own build of FreeBSD. The (root) file system is on a USB SSD off of a powered USB hub. panic: ARM64TODO: reclaim_pv_chunk cpuid = 1 time = 1493332968 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff000000605cc0 lr = 0xffff0000000869cc sp = 0xffff000083ba4f00 fp = 0xffff000083ba5110 db_trace_self_wrapper() at vpanic+0x164 pc = 0xffff0000000869cc lr = 0xffff00000031d464 sp = 0xffff000083ba5120 fp = 0xffff000083ba5190 vpanic() at panic+0x4c pc = 0xffff00000031d464 lr = 0xffff00000031d2fc sp = 0xffff000083ba51a0 fp = 0xffff000083ba5220 panic() at reclaim_pv_chunk+0x10 pc = 0xffff00000031d2fc lr = 0xffff00000061a234 sp = 0xffff000083ba5230 fp = 0xffff000083ba5230 reclaim_pv_chunk() at get_pv_entry+0x240 pc = 0xffff00000061a234 lr = 0xffff000000616184 sp = 0xffff000083ba5240 fp = 0xffff000083ba5260 get_pv_entry() at pmap_enter+0x694 pc = 0xffff000000616184 lr = 0xffff0000006156a0 sp = 0xffff000083ba5270 fp = 0xffff000083ba5300 pmap_enter() at vm_fault_hold+0x28c pc = 0xffff0000006156a0 lr = 0xffff0000005b9740 sp = 0xffff000083ba5310 fp = 0xffff000083ba5460 vm_fault_hold() at vm_fault+0x70 pc = 0xffff0000005b9740 lr = 0xffff0000005b9464 sp = 0xffff000083ba5470 fp = 0xffff000083ba54a0 vm_fault() at data_abort+0xe0 pc = 0xffff0000005b9464 lr = 0xffff00000061ad94 sp = 0xffff000083ba54b0 fp = 0xffff000083ba5560 data_abort() at handle_el1h_sync+0x70 pc = 0xffff00000061ad94 lr = 0xffff000000607870 sp = 0xffff000083ba5570 fp = 0xffff000083ba5680 handle_el1h_sync() at kern_select+0x9fc pc = 0xffff000000607870 lr = 0xffff00000037db3c sp = 0xffff000083ba5690 fp = 0xffff000083ba58f0 kern_select() at sys_select+0x5c pc = 0xffff00000037db3c lr = 0xffff00000037dc58 sp = 0xffff000083ba5900 fp = 0xffff000083ba5930 sys_select() at do_el0_sync+0xa48 pc = 0xffff00000037dc58 lr = 0xffff00000061b91c sp = 0xffff000083ba5940 fp = 0xffff000083ba5a70 do_el0_sync() at handle_el0_sync+0x6c pc = 0xffff00000061b91c lr = 0xffff0000006079e8 sp = 0xffff000083ba5a80 fp = 0xffff000083ba5b90 handle_el0_sync() at 0x4948c pc = 0xffff0000006079e8 lr = 0x000000000004948c sp = 0xffff000083ba5ba0 fp = 0x0000ffffffffd960 === Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Apr 28 01:01:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF430D4DF87; Fri, 28 Apr 2017 01:01:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A01B274; Fri, 28 Apr 2017 01:01:23 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3S11M2W012863 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 18:01:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3S11MRW012862; Thu, 27 Apr 2017 18:01:22 -0700 (PDT) (envelope-from sgk) Date: Thu, 27 Apr 2017 18:01:22 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170428010122.GA12814@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170427231411.GA11346@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 01:01:23 -0000 On Thu, Apr 27, 2017 at 04:14:11PM -0700, Steve Kargl wrote: > > I have attached a new diff to the bugzilla report. The > diff is 3090 lines and won't be broadcast the mailing list. > > This diff includes fixes for a few inconsequential bugs > and implements modified Estrin's method for sum a few > ploynomials. If you want the previous Horner's method > then add -DHORNER to your CFLAGS. > For those curious about testing, here are some numbers for the Estrin's method. These were obtained on an AMD FX(tm)-8350 @ 4018.34-MHz. The times are in microseconds and the number in parentheses are estimated cycles. | cospi | sinpi | tanpi ------------+--------------+--------------+-------------- float | 0.0089 (37) | 0.0130 (54) | 0.0194 (80) double | 0.0134 (55) | 0.0160 (66) | 0.0249 (102) long double | 0.0557 (228) | 0.0698 (287) | 0.0956 (393) ------------+--------------+--------------+-------------- The timing tests are done on the interval [0,0.25] as this is the interval where the polynomial approximations apply. Limited accuracy testing gives | cospif | cospi | cospil -----------------+------------+------------+------------- MAX ULP | 0.88242114 | 0.89339466 | 0.88799449 Total tested | 16777214 | 16777214 | 16777214 0.8 < ULP <= 0.9 | 1613 | 1682 | 1601 0.7 < ULP <= 0.8 | 33925 | 33817 | 33843 0.6 < ULP <= 0.7 | 171799 | 172775 | 171899 -----------------+------------+------------+------------- | sinpif | sinpi | sinpil -----------------+------------+------------+------------- MAX ULP | 0.80103672 | 0.79851085 | 0.77049407 Total tested | 16777214 | 16777214 | 16777214 0.8 < ULP <= 0.9 | 1 | 0 | 0 0.7 < ULP <= 0.8 | 727 | 1075 | 546 0.6 < ULP <= 0.7 | 19268 | 22722 | 19019 -----------------+------------+------------+------------- x in [0,0.25] | tanpif | tanpi | tanpil -----------------+------------+------------+------------- MAX ULP | 1.37954760 | 1.37300168 | 1.38800823 Total tested | 16777214 | 16777214 | 16777214 1.0 < ULP | 39109 | 38712 | 38798 0.9 < ULP <= 1.0 | 130373 | 131086 | 130803 0.8 < ULP <= 0.9 | 342624 | 341350 | 341155 0.7 < ULP <= 0.8 | 687244 | 687122 | 686814 0.6 < ULP <= 0.7 | 1078964 | 1079881 | 1078555 -----------------+------------+------------+------------- In the interval [0.25,0.5] tanpi[fl] is computed by cospi / sinpi. The numbers look like x in [0.25,0.5] | tanpif | tanpi | tanpil -----------------+------------+------------+------------- MAX ULP | 1.93529165 | 2.04485533 | 1.95823689 Total tested | 16777215 | 16777215 | 16777215 1.0 < ULP | 699310 | 701244 | 698946 0.9 < ULP <= 1.0 | 442978 | 443344 | 443599 0.8 < ULP <= 0.9 | 642991 | 642561 | 642601 0.7 < ULP <= 0.8 | 889357 | 890307 | 889233 0.6 < ULP <= 0.7 | 1176473 | 1177407 | 1177121 -----------------+------------+------------+------------- -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri Apr 28 02:31:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3E346D548EC for ; Fri, 28 Apr 2017 02:31:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 009411197 for ; Fri, 28 Apr 2017 02:31:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9390 invoked from network); 28 Apr 2017 02:31:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 Apr 2017 02:31:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 27 Apr 2017 22:31:46 -0400 (EDT) Received: (qmail 29250 invoked from network); 28 Apr 2017 02:31:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Apr 2017 02:31:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 490FCEC85DE; Thu, 27 Apr 2017 19:31:45 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [another example] Date: Thu, 27 Apr 2017 19:31:44 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> Message-Id: <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 02:31:48 -0000 [Another example panic. Again no dump. But I have what a top -PCwaopid froze at this time.] On 2017-Apr-27, at 4:22 PM, Mark Millard wrote: > Unfortunately for this FYI the attempt to produce a dump > failed and so all the information that I have is what I > first captured from the console output: a backtrace. >=20 > The context was head -r317015 on a Pine64+ 2GB. At the > time I was experimenting with trying to build a vm.raw > from my own build of FreeBSD. The (root) file system > is on a USB SSD off of a powered USB hub. >=20 > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 1 > time =3D 1493332968 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >=20 > data_abort() at handle_el1h_sync+0x70 > pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 > sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >=20 > handle_el1h_sync() at kern_select+0x9fc > pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c > sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >=20 > kern_select() at sys_select+0x5c > pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 > sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >=20 > sys_select() at do_el0_sync+0xa48 > pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c > sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >=20 > do_el0_sync() at handle_el0_sync+0x6c > pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >=20 > handle_el0_sync() at 0x4948c > pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c > sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 This time I got to record from top: (swap is on a swap partition) (pid 49888's SIZE vs. RES and SWAP might be interesting) (as might the Active figure) last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 32 processes: 2 running, 30 sleeping CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% idle CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% idle CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% idle CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% idle Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free Swap: 6144M Total, 34M Used, 6110M Free, 348K Out PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) And here is the backtrace: timeout stopping cpus panic: ARM64TODO: reclaim_pv_chunk cpuid =3D 0 time =3D 1493345992 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 db_trace_self_wrapper() at vpanic+0x164 pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 vpanic() at panic+0x4c pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 panic() at reclaim_pv_chunk+0x10 pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 reclaim_pv_chunk() at get_pv_entry+0x240 pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 get_pv_entry() at pmap_enter+0x694 pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 pmap_enter() at vm_fault_hold+0x28c pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 vm_fault_hold() at vm_fault+0x70 pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 vm_fault() at data_abort+0xe0 pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 data_abort() at handle_el0_sync+0x6c pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 handle_el0_sync() at 0x400a3de4 pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 KDB: enter: panic [ thread pid 48988 tid 100230 ] Stopped at kdb_enter+0x44: undefined d4200000 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Apr 28 04:18:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 542DDD53230; Fri, 28 Apr 2017 04:18:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 36C457B5; Fri, 28 Apr 2017 04:18:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3S4In0M013553 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 21:18:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3S4Intr013552; Thu, 27 Apr 2017 21:18:49 -0700 (PDT) (envelope-from sgk) Date: Thu, 27 Apr 2017 21:18:49 -0700 From: Steve Kargl To: freebsd-numerics@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170428041849.GA13544@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170427231411.GA11346@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 04:18:51 -0000 On Thu, Apr 27, 2017 at 04:14:11PM -0700, Steve Kargl wrote: > > > > The code is attached the bug reportr. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218514 > > > > I have attached a new diff to the bugzilla report. The > diff is 3090 lines and won't be broadcast the mailing list. > > This diff includes fixes for a few inconsequential bugs > and implements modified Estrin's method for sum a few > ploynomials. If you want the previous Horner's method > then add -DHORNER to your CFLAGS. > Grrrr. Find a sloppy theshold can be fun. Index: src/s_cospif.c =================================================================== --- src/s_cospif.c (revision 1916) +++ src/s_cospif.c (working copy) @@ -61,7 +61,7 @@ SET_FLOAT_WORD(ax, ix); if (ix < 0x3f800000) { /* |x| < 1 */ - if (ix < 0x39000000) { /* |x| < 0x1p-13 */ + if (ix < 0x38800000) { /* |x| < 0x1p-14 */ if (huge + ax > 0) /* Raise inexact iff != 0. */ return (1); } -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri Apr 28 05:26:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A75DBD54374 for ; Fri, 28 Apr 2017 05:26:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 6737B7A2 for ; Fri, 28 Apr 2017 05:26:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7428 invoked from network); 28 Apr 2017 05:29:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Apr 2017 05:29:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 01:26:22 -0400 (EDT) Received: (qmail 18704 invoked from network); 28 Apr 2017 05:26:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Apr 2017 05:26:22 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6D413EC904C; Thu, 27 Apr 2017 22:26:21 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: FYI: example "panic: ARM64TODO: reclaim_pv_chunk" on a Pine64+ 2GB with head -r317015 [mdconfig -d not effectively releasing memory?] Date: Thu, 27 Apr 2017 22:26:20 -0700 References: <4BC7E6BC-4BF9-4F5E-9851-E022AC9A3082@dsl-only.net> <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> To: freebsd-arm , freebsd-hackers@freebsd.org, FreeBSD Current In-Reply-To: <51050A07-B951-45C0-82CE-73BB342F012E@dsl-only.net> Message-Id: <302D1255-4D34-4C1B-8F3A-9180A6AF8768@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 05:26:24 -0000 [As the text does not really follow from the earlier text I'd sent directly I'm top posting a hypothesis about where so much active memory came from to be so low in available memory to get an reclaim_pv_chunk attempt.] My hypothesis is that the "mdconfig -d"s from vm_copy_base (from /usr/src/release/tools/vmimage.subr ) did not actually release the memory resources involved (from vnode backed mdconfig use): vm_copy_base() { # Creates a new UFS root filesystem and copies the contents of = the # current root filesystem into it. This produces a "clean" disk # image without any remnants of files which were created = temporarily # during image-creation and have since been deleted (e.g., = downloaded # package archives). mkdir -p ${DESTDIR}/old mdold=3D$(mdconfig -f ${VMBASE}) mount /dev/${mdold} ${DESTDIR}/old truncate -s ${VMSIZE} ${VMBASE}.tmp mkdir -p ${DESTDIR}/new mdnew=3D$(mdconfig -f ${VMBASE}.tmp) newfs -L rootfs /dev/${mdnew} mount /dev/${mdnew} ${DESTDIR}/new tar -cf- -C ${DESTDIR}/old . | tar -xUf- -C ${DESTDIR}/new umount_loop /dev/${mdold} rmdir ${DESTDIR}/old mdconfig -d -u ${mdold} umount_loop /dev/${mdnew} rmdir ${DESTDIR}/new tunefs -n enable /dev/${mdnew} mdconfig -d -u ${mdnew} mv ${VMBASE}.tmp ${VMBASE} } Without such prior mdconfig activity the "cp -p" and following "xz -T 0" do not get the large Meme:Active figure in top, "xz -T 0" getting more like 781M Mem:Active with a xz:SIZE of 791M and xz:RES < 800M (varying). Zero xz:SWAP. xz also gets all the cores going, so well over 300% in top always (4 cores) instead of < 100%. In this context both the cp and the xz finish just fine. In other words: no low memory problem without first having the vnode backed mdconfig use. =46rom the prior top report for the failure, partially repeated here: . . . Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free Swap: 6144M Total, 34M Used, 6110M Free, 348K Out PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT- . . . The combination 1618M Mem:Active but 34M Swap:Used and 651M xz:SIZE but 27M xz:RES and 0K xz:SWAP just seems very odd, like it should not happen. The 17M Mem:Inact is odd for the context as well. (Mem:Wired, Mem:Buf, and Mem:Free look normal.) An alternate hypothesis would be the memory "leak" is from mkimg not having it memory-use cleaned up. This happens after vm_copy_base but before the cp/xz sequence and is what produces vm.raw. For reference of what worked just fine after the post-panic reboot, using the already existing vm.raw (sparse) file as a starting place: # cp -p vm.raw = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw # xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw # ls -lTt *raw* -rw-r--r-- 1 root wheel 34360566272 Apr 27 18:40:24 2017 vm.raw -rw-r--r-- 1 root wheel 34359746560 Apr 27 18:37:29 2017 = vm.raw.nested_bsd -rw-r--r-- 1 root wheel 27917287424 Apr 27 18:34:45 2017 raw.img # du -sm *raw* 1762 raw.img 1583 vm.raw 1583 vm.raw.nested_bsd (Before the .xz replaces the .raw:) # ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/ total 33820032 -rw-r--r-- 1 root wheel 34360566272 Apr 27 18:40:24 2017 = FreeBSD-12.0-CURRENT-arm64-aarch64.raw # du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/* 32777 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw (After xz:) # ls -lT /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/ total 258208 -rw-r--r-- 1 root wheel 264275808 Apr 27 18:40:24 2017 = FreeBSD-12.0-CURRENT-arm64-aarch64.raw.xz # du -sm /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/* 253 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw.xz (Mem:Active returned to 10M when xz finished.) Prior reports from capturing text: On 2017-Apr-27, at 7:31 PM, Mark Millard wrote: > [Another example panic. Again no dump. But I have what > a top -PCwaopid froze at this time.] >=20 > On 2017-Apr-27, at 4:22 PM, Mark Millard = wrote: >=20 >> Unfortunately for this FYI the attempt to produce a dump >> failed and so all the information that I have is what I >> first captured from the console output: a backtrace. >>=20 >> The context was head -r317015 on a Pine64+ 2GB. At the >> time I was experimenting with trying to build a vm.raw >> from my own build of FreeBSD. The (root) file system >> is on a USB SSD off of a powered USB hub. >>=20 >> panic: ARM64TODO: reclaim_pv_chunk >> cpuid =3D 1 >> time =3D 1493332968 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self_wrapper+0x28 >> pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc >> sp =3D 0xffff000083ba4f00 fp =3D 0xffff000083ba5110 >>=20 >> db_trace_self_wrapper() at vpanic+0x164 >> pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 >> sp =3D 0xffff000083ba5120 fp =3D 0xffff000083ba5190 >>=20 >> vpanic() at panic+0x4c >> pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc >> sp =3D 0xffff000083ba51a0 fp =3D 0xffff000083ba5220 >>=20 >> panic() at reclaim_pv_chunk+0x10 >> pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 >> sp =3D 0xffff000083ba5230 fp =3D 0xffff000083ba5230 >>=20 >> reclaim_pv_chunk() at get_pv_entry+0x240 >> pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 >> sp =3D 0xffff000083ba5240 fp =3D 0xffff000083ba5260 >>=20 >> get_pv_entry() at pmap_enter+0x694 >> pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 >> sp =3D 0xffff000083ba5270 fp =3D 0xffff000083ba5300 >>=20 >> pmap_enter() at vm_fault_hold+0x28c >> pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 >> sp =3D 0xffff000083ba5310 fp =3D 0xffff000083ba5460 >>=20 >> vm_fault_hold() at vm_fault+0x70 >> pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 >> sp =3D 0xffff000083ba5470 fp =3D 0xffff000083ba54a0 >>=20 >> vm_fault() at data_abort+0xe0 >> pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 >> sp =3D 0xffff000083ba54b0 fp =3D 0xffff000083ba5560 >>=20 >> data_abort() at handle_el1h_sync+0x70 >> pc =3D 0xffff00000061ad94 lr =3D 0xffff000000607870 >> sp =3D 0xffff000083ba5570 fp =3D 0xffff000083ba5680 >>=20 >> handle_el1h_sync() at kern_select+0x9fc >> pc =3D 0xffff000000607870 lr =3D 0xffff00000037db3c >> sp =3D 0xffff000083ba5690 fp =3D 0xffff000083ba58f0 >>=20 >> kern_select() at sys_select+0x5c >> pc =3D 0xffff00000037db3c lr =3D 0xffff00000037dc58 >> sp =3D 0xffff000083ba5900 fp =3D 0xffff000083ba5930 >>=20 >> sys_select() at do_el0_sync+0xa48 >> pc =3D 0xffff00000037dc58 lr =3D 0xffff00000061b91c >> sp =3D 0xffff000083ba5940 fp =3D 0xffff000083ba5a70 >>=20 >> do_el0_sync() at handle_el0_sync+0x6c >> pc =3D 0xffff00000061b91c lr =3D 0xffff0000006079e8 >> sp =3D 0xffff000083ba5a80 fp =3D 0xffff000083ba5b90 >>=20 >> handle_el0_sync() at 0x4948c >> pc =3D 0xffff0000006079e8 lr =3D 0x000000000004948c >> sp =3D 0xffff000083ba5ba0 fp =3D 0x0000ffffffffd960 >=20 >=20 > This time I got to record from top: > (swap is on a swap partition) > (pid 49888's SIZE vs. RES and SWAP might be interesting) > (as might the Active figure) >=20 > last pid: 48988; load averages: 0.64, 0.44, 0.38 = = up 0+04:21:01 19:19:50 > 32 processes: 2 running, 30 sleeping > CPU 0: 13.2% user, 0.0% nice, 23.2% system, 0.3% interrupt, 63.3% = idle > CPU 1: 4.6% user, 0.0% nice, 23.9% system, 0.0% interrupt, 71.5% = idle > CPU 2: 2.1% user, 0.0% nice, 23.2% system, 0.0% interrupt, 74.8% = idle > CPU 3: 3.3% user, 0.0% nice, 23.8% system, 0.0% interrupt, 72.8% = idle > Mem: 1618M Active, 17M Inact, 315M Wired, 204M Buf, 15M Free > Swap: 6144M Total, 34M Used, 6110M Free, 348K Out >=20 > PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND > 48988 root 4 31 0 651M 27048K 0K RUN 0 0:03 = 87.60% xz -T 0 = /usr/obj/DESTDIRs/vmimage-aarch64/vmimages/FreeBSD-12.0-CURRENT-arm64-aarc= h64.raw > 11983 root 1 22 0 5068K 0K 0K wait 3 0:00 = 0.00% make vm-image vm-install DESTDIR=3D/usr/obj/DESTDIRs/vmimage-aarch64= () > 11981 root 1 42 0 7320K 0K 1516K wait 1 0:00 = 0.00% sh = /root/sys_build_scripts.aarch64-host/make_noscript_aarch64_nodebug_clang_b= ootstrap-aarch64-host.sh vm-image vm-install=20 > 11980 root 1 20 0 6656K 1548K 0K select 0 0:02 = 0.00% [script] > 11977 root 1 30 0 7320K 0K 1516K wait 3 0:00 = 0.00% /bin/sh = /root/sys_build_scripts.aarch64-host/make_aarch64_nodebug_clang_bootstrap-= aarch64-host.sh vm-image vm-install DEST > 2694 root 1 20 0 8804K 2072K 0K CPU2 2 0:07 = 0.17% top -PCwaopid > 827 root 1 20 0 7320K 0K 360K wait 0 0:00 = 0.00% su () > 826 markmi 1 22 0 10372K 0K 1532K wait 3 0:00 = 0.00% su () > 820 markmi 1 24 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 819 markmi 1 20 0 18416K 1152K 0K select 1 0:21 = 0.00% sshd: markmi@pts/1 (sshd) > 816 root 1 20 0 18416K 3276K 0K select 0 0:00 = 0.00% sshd: markmi [priv] (sshd) > 765 root 1 20 0 7320K 0K 224K wait 2 0:00 = 0.00% su () > 764 markmi 1 23 0 10372K 0K 1532K wait 0 0:00 = 0.00% su () > 758 markmi 1 31 0 7320K 0K 1516K wait 1 0:00 = 0.00% -sh () > 757 markmi 1 20 0 18416K 228K 904K select 3 0:01 = 0.01% sshd: markmi@pts/0 (sshd) > 754 root 1 25 0 18416K 3276K 0K select 1 0:00 = 0.00% sshd: markmi [priv] (sshd) > 746 root 1 27 0 7320K 1532K 0K ttyin 0 0:00 = 0.00% -sh (sh) > 745 root 1 20 0 10372K 0K 1532K wait 1 0:00 = 0.00% login [pam] () > 700 root 1 20 0 6948K 0K 168K nanslp 1 0:00 = 0.00% /usr/sbin/cron -s () > 696 smmsp 1 20 0 10460K 0K 184K pause 0 0:00 = 0.00% sendmail: Queue runner@00:30:00 for /var/spool/clientmqueue = () > 693 root 1 20 0 10460K 1392K 0K select 1 0:00 = 0.03% sendmail: accepting connections (sendmail) > 690 root 1 20 0 15800K 968K 0K select 2 0:00 = 0.00% /usr/sbin/sshd > 661 root 1 20 0 6656K 344K 0K select 2 0:01 = 0.00% /usr/sbin/powerd > 658 root 2 20 0 12788K 12672K 0K select 0 0:02 = 0.01% /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid -f = /var/db/ntpd.drift > 620 root 32 52 0 6384K 1100K 0K rpcsvc 1 0:00 = 0.00% nfsd: server (nfsd) > 619 root 1 52 0 6384K 704K 0K select 1 0:00 = 0.00% nfsd: master (nfsd) > 617 root 1 20 0 6684K 688K 0K select 1 0:00 = 0.00% /usr/sbin/mountd -r > 478 root 1 20 0 6676K 596K 0K select 3 0:00 = 0.00% /usr/sbin/rpcbind > 469 root 1 20 0 6680K 572K 0K select 2 0:00 = 0.00% /usr/sbin/syslogd -s > 396 root 1 20 0 9580K 32K 0K select 0 0:00 = 0.00% /sbin/devd > 308 _dhcp 1 20 0 6800K 532K 0K select 2 0:00 = 0.00% dhclient: awg0 (dhclient) > 307 root 1 52 0 6800K 424K 0K select 2 0:00 = 0.00% dhclient: awg0 [priv] (dhclient) >=20 > And here is the backtrace: >=20 > timeout stopping cpus > panic: ARM64TODO: reclaim_pv_chunk > cpuid =3D 0 > time =3D 1493345992 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc =3D 0xffff000000605cc0 lr =3D 0xffff0000000869cc > sp =3D 0xffff000083d301d0 fp =3D 0xffff000083d303e0 >=20 > db_trace_self_wrapper() at vpanic+0x164 > pc =3D 0xffff0000000869cc lr =3D 0xffff00000031d464 > sp =3D 0xffff000083d303f0 fp =3D 0xffff000083d30460 >=20 > vpanic() at panic+0x4c > pc =3D 0xffff00000031d464 lr =3D 0xffff00000031d2fc > sp =3D 0xffff000083d30470 fp =3D 0xffff000083d304f0 >=20 > panic() at reclaim_pv_chunk+0x10 > pc =3D 0xffff00000031d2fc lr =3D 0xffff00000061a234 > sp =3D 0xffff000083d30500 fp =3D 0xffff000083d30500 >=20 > reclaim_pv_chunk() at get_pv_entry+0x240 > pc =3D 0xffff00000061a234 lr =3D 0xffff000000616184 > sp =3D 0xffff000083d30510 fp =3D 0xffff000083d30530 >=20 > get_pv_entry() at pmap_enter+0x694 > pc =3D 0xffff000000616184 lr =3D 0xffff0000006156a0 > sp =3D 0xffff000083d30540 fp =3D 0xffff000083d305d0 >=20 > pmap_enter() at vm_fault_hold+0x28c > pc =3D 0xffff0000006156a0 lr =3D 0xffff0000005b9740 > sp =3D 0xffff000083d305e0 fp =3D 0xffff000083d30730 >=20 > vm_fault_hold() at vm_fault+0x70 > pc =3D 0xffff0000005b9740 lr =3D 0xffff0000005b9464 > sp =3D 0xffff000083d30740 fp =3D 0xffff000083d30770 >=20 > vm_fault() at data_abort+0xe0 > pc =3D 0xffff0000005b9464 lr =3D 0xffff00000061ad94 > sp =3D 0xffff000083d30780 fp =3D 0xffff000083d30830 >=20 > data_abort() at handle_el0_sync+0x6c > pc =3D 0xffff00000061ad94 lr =3D 0xffff0000006079e8 > sp =3D 0xffff000083d30840 fp =3D 0xffff000083d30950 >=20 > handle_el0_sync() at 0x400a3de4 > pc =3D 0xffff0000006079e8 lr =3D 0x00000000400a3de4 > sp =3D 0xffff000083d30960 fp =3D 0x0000ffffbfdfcd30 >=20 > KDB: enter: panic > [ thread pid 48988 tid 100230 ] > Stopped at kdb_enter+0x44: undefined d4200000 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Fri Apr 28 08:55:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76190D5279F; Fri, 28 Apr 2017 08:55:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 15EAFEA0; Fri, 28 Apr 2017 08:55:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id ED08AD4A8E5; Fri, 28 Apr 2017 18:33:57 +1000 (AEST) Date: Fri, 28 Apr 2017 18:33:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170428041849.GA13544@troutmask.apl.washington.edu> Message-ID: <20170428180046.P1386@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428041849.GA13544@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=uopPRt1wpuTJ01loTfUA:9 a=44QarpAT_w9gG2nY:21 a=cCMfiCuOYRyRPczO:21 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 X-Mailman-Approved-At: Fri, 28 Apr 2017 11:20:17 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:55:18 -0000 On Thu, 27 Apr 2017, Steve Kargl wrote: > On Thu, Apr 27, 2017 at 04:14:11PM -0700, Steve Kargl wrote: >>> >>> The code is attached the bug reportr. >>> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218514 >> >> I have attached a new diff to the bugzilla report. The >> diff is 3090 lines and won't be broadcast the mailing list. > ... > Grrrr. Find a sloppy theshold can be fun. > > Index: src/s_cospif.c > =================================================================== > --- src/s_cospif.c (revision 1916) > +++ src/s_cospif.c (working copy) > @@ -61,7 +61,7 @@ > SET_FLOAT_WORD(ax, ix); > > if (ix < 0x3f800000) { /* |x| < 1 */ > - if (ix < 0x39000000) { /* |x| < 0x1p-13 */ > + if (ix < 0x38800000) { /* |x| < 0x1p-14 */ > if (huge + ax > 0) /* Raise inexact iff != 0. */ > return (1); > } This looks too different from s_cosf.c: XX if(ix <= 0x3f490fda) { /* |x| ~<= pi/4 */ XX if(ix<0x39800000) /* |x| < 2**-12 */ XX if(((int)x)==0) return 1.0; /* 1 with inexact if x != 0 */ XX return __kernel_cosdf(x); XX } The (int)x == 0 method is perhaps not best (especially not the excessive parentheses used in it), but it was verified to be faster than other methods. This might be a matter of tricking the compiler into not optimizing the unusual case. (__predict ugliness doesn't work any better.) Non-formatting style bugs include: - arguably worse spelling of powers of 2 in comments - less information in the comment about inexact. I try to change all similar comments to be consistent whenever I change their code. s_cos.c still has a variant with less detail "/* generate inexact". s_sinl.c is still broken by your not copying the fdlibm code: XX /* If x = +-0 or x is a subnormal number, then sin(x) = x */ XX if (z.bits.exp == 0) XX return (x); This is missing not only the comment about setting inexact, but also the code. This is also poorly optimized. XX /* Optimize the case where x is already within range. */ XX if (z.e < M_PI_4) { XX hi = __kernel_sinl(z.e, 0, 0); XX RETURNI(s ? -hi : hi); XX } This is is considerably more broken. It underflows for small x. Evaluation of polynomials always depends on not doing it for tiny x, since evaluation of higher terms always underflows for tiny x even when x is not denormal (except when the poly is linear, the T1*x term doesn't underflow if either T1 is 0 or T1 is larger than about 1 and x is not denormal). Filtering out tiny x is just an optimization, but prevents this underflow. It sometimes also gives free tests for 0 and denormals (I don't see how to fold this test into the others), and free optimizations for tiny x. It does do this for sin(x), provided we don't support non-standard rounding modes. The correct value is just x with inexact if x != 0. s_cosl.c has the same bug. I sent you preliminary patches in 2008 when the long double trig functions were committed, but left fixing these bugs as an exercise. Actually, I thought I fixed this in cosl() and only left sinl() as an exercise. XX diff -u2 s_cosl.c~ s_cosl.c XX --- s_cosl.c~ Thu May 30 18:17:21 2013 XX +++ s_cosl.c Tue Sep 6 03:43:57 2016 XX @@ -55,21 +55,17 @@ XX long double y[2]; XX long double hi, lo; XX + int ex; XX XX z.e = x; XX - z.bits.sign = 0; XX - XX - /* If x = +-0 or x is a subnormal number, then cos(x) = 1 */ XX - if (z.bits.exp == 0) XX - return (1.0); XX - XX - /* If x = NaN or Inf, then cos(x) = NaN. */ XX - if (z.bits.exp == 32767) XX - return ((x - x) / (x - x)); XX + ex = z.bits.exp; Mostly style and minor efficiency fixes. XX XX ENTERI(); XX XX - /* Optimize the case where x is already within range. */ XX - if (z.e < M_PI_4) XX - RETURNI(__kernel_cosl(z.e, 0)); XX + if (ex < 0x3ffe || (ex == 0x3ffe && z.bits.manh < 0xc90fdaa2)) XX + RETURNI(__kernel_cosl(x, 0)); Efficiency fix for the comparison. But no fix for underflow, etc. XX + XX + /* If x = NaN or Inf, then cos(x) = NaN. */ XX + if (ex == 32767) XX + RETURNI(x - x); XX XX e0 = __ieee754_rem_pio2l(x, y); ISTR breaking s_sinf.c and/or s_cosf.c with the invalid optimization of just evaluating the polynomial, to avoid the branch for the micro-optimization. But it is not juste for an optimization. Bruce From owner-freebsd-hackers@freebsd.org Fri Apr 28 09:39:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75D16D53FF8; Fri, 28 Apr 2017 09:39:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0CEC0ECC; Fri, 28 Apr 2017 09:39:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 5551B1048F3C; Fri, 28 Apr 2017 19:13:17 +1000 (AEST) Date: Fri, 28 Apr 2017 19:13:16 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170428010122.GA12814@troutmask.apl.washington.edu> Message-ID: <20170428183733.V1497@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=HgMA7pdRT-D6GSaveAAA:9 a=bWHRhd8LnqQueheO:21 a=6RyRNACK7q-QfLbh:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 28 Apr 2017 11:20:37 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 09:39:45 -0000 On Thu, 27 Apr 2017, Steve Kargl wrote: > On Thu, Apr 27, 2017 at 04:14:11PM -0700, Steve Kargl wrote: >> >> I have attached a new diff to the bugzilla report. The >> diff is 3090 lines and won't be broadcast the mailing list. >> >> This diff includes fixes for a few inconsequential bugs >> and implements modified Estrin's method for sum a few >> ploynomials. If you want the previous Horner's method >> then add -DHORNER to your CFLAGS. > > For those curious about testing, here are some numbers > for the Estrin's method. These were obtained on an AMD > FX(tm)-8350 @ 4018.34-MHz. The times are in microseconds > and the number in parentheses are estimated cycles. > > | cospi | sinpi | tanpi > ------------+--------------+--------------+-------------- > float | 0.0089 (37) | 0.0130 (54) | 0.0194 (80) > double | 0.0134 (55) | 0.0160 (66) | 0.0249 (102) > long double | 0.0557 (228) | 0.0698 (287) | 0.0956 (393) > ------------+--------------+--------------+-------------- > > The timing tests are done on the interval [0,0.25] as > this is the interval where the polynomial approximations > apply. Limited accuracy testing gives These still seem slow. I did a quick test of naive evaluations of these functions as standard_function(Pi * x) and get times a bit faster on Haswell, except 2-4 times faster for the long double case, with the handicaps of using gcc-3.3.3 and i386. Of course, the naive evaluation is inaccurate, especially near multiples of Pi/2. > x in [0,0.25] | tanpif | tanpi | tanpil > -----------------+------------+------------+------------- > MAX ULP | 1.37954760 | 1.37300168 | 1.38800823 Just use the naive evaluation to get similar errors in this range. It is probably faster too. For tiny x, both reduce to the approximation Pi*x, with an error like this expected unless the evaluation is done in extra precision. > In the interval [0.25,0.5] tanpi[fl] is computed by > cospi / sinpi. The numbers look like > > x in [0.25,0.5] | tanpif | tanpi | tanpil > -----------------+------------+------------+------------- > MAX ULP | 1.93529165 | 2.04485533 | 1.95823689 The errors build up only linearly in the number of operations, which is good. Note that on i386 with its extended precision, in float precision the naive method is accurate to nearly 0.5 ulps provided you use extended precision for Pi, the multiplication, and also the function, so sinpif() is only worth having if it can do this almost as fast as sinf() (about 15 cycles throughput and less than 100 latency (50?) on modern x86). The extra precision is used automatically by sinf() (by using a double hack. Double is not very different from float+extended on i386). I think accuracy is enough up to extend float precision up to a useful multiple of Pi (suppose double precision and not full extended, so only 53 bits for Pi, so 29 extra; lose 24 to cancelations and 5 are left, so the accuracy is enough up to about 2**5*Pi). Bruce From owner-freebsd-hackers@freebsd.org Fri Apr 28 16:56:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4CE3D549E2; Fri, 28 Apr 2017 16:56:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 859451613; Fri, 28 Apr 2017 16:56:59 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3SGuwdl017872 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 09:56:58 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3SGuwdV017871; Fri, 28 Apr 2017 09:56:58 -0700 (PDT) (envelope-from sgk) Date: Fri, 28 Apr 2017 09:56:58 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170428165658.GA17560@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170428183733.V1497@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 16:56:59 -0000 On Fri, Apr 28, 2017 at 07:13:16PM +1000, Bruce Evans wrote: > On Thu, 27 Apr 2017, Steve Kargl wrote: > > > On Thu, Apr 27, 2017 at 04:14:11PM -0700, Steve Kargl wrote: > >> > >> I have attached a new diff to the bugzilla report. The > >> diff is 3090 lines and won't be broadcast the mailing list. > >> > >> This diff includes fixes for a few inconsequential bugs > >> and implements modified Estrin's method for sum a few > >> ploynomials. If you want the previous Horner's method > >> then add -DHORNER to your CFLAGS. > > > > For those curious about testing, here are some numbers > > for the Estrin's method. These were obtained on an AMD > > FX(tm)-8350 @ 4018.34-MHz. The times are in microseconds > > and the number in parentheses are estimated cycles. > > > > | cospi | sinpi | tanpi > > ------------+--------------+--------------+-------------- > > float | 0.0089 (37) | 0.0130 (54) | 0.0194 (80) > > double | 0.0134 (55) | 0.0160 (66) | 0.0249 (102) > > long double | 0.0557 (228) | 0.0698 (287) | 0.0956 (393) > > ------------+--------------+--------------+-------------- > > > > The timing tests are done on the interval [0,0.25] as > > this is the interval where the polynomial approximations > > apply. Limited accuracy testing gives > > These still seem slow. I did a quick test of naive evaluations of > these functions as standard_function(Pi * x) and get times a bit faster > on Haswell, except 2-4 times faster for the long double case, with the > handicaps of using gcc-3.3.3 and i386. Of course, the naive evaluation > is inaccurate, especially near multiples of Pi/2. The slowness comes from handling extra precision arithmetic. For sinpi(x) = x * p(x) where p(x) = s0 + x2 * S(x2) is the polynomial approximation and x2 = x * x. One needs to take care in the ordering on the evaluation where x and x2 are split into high and low parts. See the source code posted in response to your other email. > > x in [0,0.25] | tanpif | tanpi | tanpil > > -----------------+------------+------------+------------- > > MAX ULP | 1.37954760 | 1.37300168 | 1.38800823 > > Just use the naive evaluation to get similar errors in this > range. It is probably faster too. I haven't checked tanpif, but naive evaluation is faster for sinpif(x). But getting the worry answer fast seems to be counter to what one may expect from a math library. Consider the two naive implementations: float bde1(float x) { return (sinf((float)M_PI * x)); } float bde2(float x) { return (sinf((float)(M_PI * x))); } float bde3(float x) { return ((float)sin(M_PI * x)); } x in [0,0.25] | sinpif | bde1(x) | bde2(x) | bde3(x) -----------------+-------------+-------------+--------------+------------ Time usec (cyc) | 0.0130 (54) | 0.0084 (35) | 0.0093 (38) | 0.0109 (45) MAX ULP | 0.80103672 | 1.94017851 | 1.46830785 | 0.5 1.0 < ULP | 0 | 736496 | 47607 | 0 0.9 < ULP <= 1.0 | 0 | 563122 | 101162 | 0 0.8 < ULP <= 0.9 | 1 | 751605 | 386128 | 0 0.7 < ULP <= 0.8 | 727 | 942349 | 753647 | 0 0.6 < ULP <= 0.7 | 19268 | 1169719 | 1123518 | 0 x in [3990,3992] | sinpif | bde1(x) | bde2(x) | bde3(x) -----------------+-------------+-------------+-------------+------------ Time usec (cyc) | 0.0161 (66) | 0.0137 (56) | 0.0144 (59) | 0.0211 (87) MAX ULP | 0.65193975 | 10458803. | 6471461. | 0.5 1.0 < ULP | 0 | 16773117 | 16762878 | 0 0.9 < ULP <= 1.0 | 0 | 0 | 0 | 0 0.8 < ULP <= 0.9 | 0 | 0 | 0 | 0 0.7 < ULP <= 0.8 | 0 | 0 | 0 | 0 0.6 < ULP <= 0.7 | 19268 | 2047 | 2047 | 0 So bde3(x) is best, but if you're going to use sin(M_PI*x) for float sinpif, then use sinpi((double)x) which is faster than bde3 and just as accurate. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri Apr 28 18:40:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A38CED53A4E; Fri, 28 Apr 2017 18:40:26 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 523BBBBF; Fri, 28 Apr 2017 18:40:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 82D483C5E0A; Sat, 29 Apr 2017 04:40:18 +1000 (AEST) Date: Sat, 29 Apr 2017 04:40:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: Bruce Evans , freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170428165658.GA17560@troutmask.apl.washington.edu> Message-ID: <20170429035131.E3406@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=baPn34At2Hashz5YGC0A:9 a=-D1BXJ0ZKV1LJ0pY:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 28 Apr 2017 18:58:15 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 18:40:26 -0000 On Fri, 28 Apr 2017, Steve Kargl wrote: > On Fri, Apr 28, 2017 at 07:13:16PM +1000, Bruce Evans wrote: >> On Thu, 27 Apr 2017, Steve Kargl wrote: >>> For those curious about testing, here are some numbers >>> for the Estrin's method. These were obtained on an AMD >>> FX(tm)-8350 @ 4018.34-MHz. The times are in microseconds >>> and the number in parentheses are estimated cycles. >>> >>> | cospi | sinpi | tanpi >>> ------------+--------------+--------------+-------------- >>> float | 0.0089 (37) | 0.0130 (54) | 0.0194 (80) >>> double | 0.0134 (55) | 0.0160 (66) | 0.0249 (102) >>> long double | 0.0557 (228) | 0.0698 (287) | 0.0956 (393) >>> ------------+--------------+--------------+-------------- >>> >>> The timing tests are done on the interval [0,0.25] as >>> this is the interval where the polynomial approximations >>> apply. Limited accuracy testing gives >> >> These still seem slow. I did a quick test of naive evaluations of >> these functions as standard_function(Pi * x) and get times a bit faster >> on Haswell, except 2-4 times faster for the long double case, with the >> handicaps of using gcc-3.3.3 and i386. Of course, the naive evaluation >> is inaccurate, especially near multiples of Pi/2. > > The slowness comes from handling extra precision arithmetic. For > sinpi(x) = x * p(x) where p(x) = s0 + x2 * S(x2) is the polynomial > approximation and x2 = x * x. One needs to take care in the ordering > on the evaluation where x and x2 are split into high and low parts. > See the source code posted in response to your other email. See logl() for how to do this almost as well as possible using the 2sum primitives. Don't forget to test on i386 with i387, where you will need lots of slow STRICT_ASSIGN()s or careful use of float_t and double_t as in my uncomitted logf() and logl()i or more relevantly clog() (cplex.c) to avoid problems with extra precision (2sum requires this). Calculating the polynomial as x * p(x) seems wrong. That is too inaccurate even for sin(x), and probably slower too. __kernel_sin(x) uses x + x2*S(x2), with complications except in the first quadrant needed to improve accuracy. The arrangement of the second term is dubious too, even for sin(x). It unimproves acuracy but is apparently used because it is faster. I would try S(x2) * x4 + x2 * (x * S3) + x, where x2 * (x * S3) + x must all be evaluated in extra precision. >>> x in [0,0.25] | tanpif | tanpi | tanpil >>> -----------------+------------+------------+------------- >>> MAX ULP | 1.37954760 | 1.37300168 | 1.38800823 >> >> Just use the naive evaluation to get similar errors in this >> range. It is probably faster too. > > I haven't checked tanpif, but naive evaluation is faster > for sinpif(x). But getting the worry answer fast seems > to be counter to what one may expect from a math library. > Consider the two naive implementations: But the above is inaccurate too. > float > bde1(float x) > { > return (sinf((float)M_PI * x)); > } sinpif() with range reduction in float precision and multiplication by M_PI and __kernel_sin() to finish off would be much faster and more accurate than doing everything in float precision. On i386/i387, it could be arranged that naive users get M_PI and __kernel_sin() almost automatically. This is essentially what is already done for sinf(). Similarly for sinpi() on arches with extra precision for double. > float > bde2(float x) > { > return (sinf((float)(M_PI * x))); > } > > float > bde3(float x) > { > return ((float)sin(M_PI * x)); > } > > x in [0,0.25] | sinpif | bde1(x) | bde2(x) | bde3(x) > -----------------+-------------+-------------+--------------+------------ > Time usec (cyc) | 0.0130 (54) | 0.0084 (35) | 0.0093 (38) | 0.0109 (45) > MAX ULP | 0.80103672 | 1.94017851 | 1.46830785 | 0.5 > 1.0 < ULP | 0 | 736496 | 47607 | 0 > 0.9 < ULP <= 1.0 | 0 | 563122 | 101162 | 0 > 0.8 < ULP <= 0.9 | 1 | 751605 | 386128 | 0 > 0.7 < ULP <= 0.8 | 727 | 942349 | 753647 | 0 > 0.6 < ULP <= 0.7 | 19268 | 1169719 | 1123518 | 0 > > x in [3990,3992] | sinpif | bde1(x) | bde2(x) | bde3(x) > -----------------+-------------+-------------+-------------+------------ > Time usec (cyc) | 0.0161 (66) | 0.0137 (56) | 0.0144 (59) | 0.0211 (87) > MAX ULP | 0.65193975 | 10458803. | 6471461. | 0.5 > 1.0 < ULP | 0 | 16773117 | 16762878 | 0 > 0.9 < ULP <= 1.0 | 0 | 0 | 0 | 0 > 0.8 < ULP <= 0.9 | 0 | 0 | 0 | 0 > 0.7 < ULP <= 0.8 | 0 | 0 | 0 | 0 > 0.6 < ULP <= 0.7 | 19268 | 2047 | 2047 | 0 > > So bde3(x) is best, but if you're going to use sin(M_PI*x) for > float sinpif, then use sinpi((double)x) which is faster than bde3 > and just as accurate. That is a naive version, with explicit pesssimation and destruction of extra precision by casting to float. A fast version would do return (__kernel_sindf(M_PI * x)) after reducing the range of x (switch to +- and cosf for other quadrants). Perhaps optimize the range reduction for small quadrant numbers for sinf(). It is easier to subtract 1 from x than to subtract Pi/2 to adjust the quadrant, so this optimization might not be so useful. Bruce From owner-freebsd-hackers@freebsd.org Fri Apr 28 20:15:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B16CD549B6; Fri, 28 Apr 2017 20:15:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 170831269; Fri, 28 Apr 2017 20:15:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3SKFMnx033229 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 13:15:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3SKFMZ8033228; Fri, 28 Apr 2017 13:15:22 -0700 (PDT) (envelope-from sgk) Date: Fri, 28 Apr 2017 13:15:22 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170428201522.GA32785@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170429035131.E3406@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 20:15:24 -0000 On Sat, Apr 29, 2017 at 04:40:14AM +1000, Bruce Evans wrote: > On Fri, 28 Apr 2017, Steve Kargl wrote: > > > On Fri, Apr 28, 2017 at 07:13:16PM +1000, Bruce Evans wrote: > >> On Thu, 27 Apr 2017, Steve Kargl wrote: > >>> For those curious about testing, here are some numbers > >>> for the Estrin's method. These were obtained on an AMD > >>> FX(tm)-8350 @ 4018.34-MHz. The times are in microseconds > >>> and the number in parentheses are estimated cycles. > >>> > >>> | cospi | sinpi | tanpi > >>> ------------+--------------+--------------+-------------- > >>> float | 0.0089 (37) | 0.0130 (54) | 0.0194 (80) > >>> double | 0.0134 (55) | 0.0160 (66) | 0.0249 (102) > >>> long double | 0.0557 (228) | 0.0698 (287) | 0.0956 (393) > >>> ------------+--------------+--------------+-------------- > >>> > >>> The timing tests are done on the interval [0,0.25] as > >>> this is the interval where the polynomial approximations > >>> apply. Limited accuracy testing gives > >> > >> These still seem slow. I did a quick test of naive evaluations of > >> these functions as standard_function(Pi * x) and get times a bit faster > >> on Haswell, except 2-4 times faster for the long double case, with the > >> handicaps of using gcc-3.3.3 and i386. Of course, the naive evaluation > >> is inaccurate, especially near multiples of Pi/2. > > > > The slowness comes from handling extra precision arithmetic. For > > sinpi(x) = x * p(x) where p(x) = s0 + x2 * S(x2) is the polynomial > > approximation and x2 = x * x. One needs to take care in the ordering > > on the evaluation where x and x2 are split into high and low parts. > > See the source code posted in response to your other email. > > See logl() for how to do this almost as well as possible using the 2sum > primitives. Don't forget to test on i386 with i387, where you will need > lots of slow STRICT_ASSIGN()s or careful use of float_t and double_t > as in my uncomitted logf() and logl()i or more relevantly clog() (cplex.c) > to avoid problems with extra precision (2sum requires this). > > Calculating the polynomial as x * p(x) seems wrong. It starts life as the Remes approximation for p(x) = sin(pi*x) / x. Yes, I also looked into using p(x) = sin(pi*x) / (pi*x). At some point, one must do sinpi(x) = sin(pi*x) = x * p(x). One could do, as is done with sin(x), f(x) = (sin(pi*x) - pi*x)/(pi*x)**3 then sinpi(x) = pi*x + (pi*x)**3 * f(x), but this then adds the complication that pi*x must be computed in extra precision. For float, with the algorithm I have developed, one can simply do everything in double and then cast the result to float. In fact, my __kernel_sinpif was initially written in double with a max ULP less than 0.55. I then looked at what portions of the polynomial could be computed in float without reducing the 0.55. This then reveals what needs to be handle specially. But, what is one to do with double and long double functions? > That is too inaccurate even for sin(x), and probably slower too. I'm not sure why you're claiming that it is too inaccurate. Let's look at sinpi(x) and sin(x) on (roughly) the same interval to remove the different precisions involved in sinpif(x) and sinf(x). This is my sinpi(x) troutmask:kargl[221] ./testd -S -m 0.00 -M 0.25 -n 24 MAX ULP: 0.79851085 Total tested: 16777214 0.7 < ULP <= 0.8: 1075 0.6 < ULP <= 0.7: 22722 This is libm sin(x) troutmask:kargl[224] ./testd -S -m 0.00 -M 0.7853981634 -n 24 MAX ULP: 0.72922199 Total tested: 16777214 0.7 < ULP <= 0.8: 36 0.6 < ULP <= 0.7: 12193 The numbers above really aren't too different, and someone that actually understands numerical analysis might be able to take my code and (marginally) improve the numbers. > > float > > bde1(float x) > > { > > return (sinf((float)M_PI * x)); > > } > > sinpif() with range reduction in float precision and multiplication > by M_PI and __kernel_sin() to finish off would be much faster and > more accurate than doing everything in float precision. On i386/i387, Multiplication by M_PI and __kernel_sin() are double precision intermediates. That works for float. What are you going to do for double and long double? One of the benefits of writing sinpif(x) in float precision is that the exacts same algorithm is used in sinpi(x) and sinpil(x). One of these can be exhaustively tested. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Fri Apr 28 22:09:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14850D547CD; Fri, 28 Apr 2017 22:09:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id B7D39913; Fri, 28 Apr 2017 22:09:45 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 437AA104C43F; Sat, 29 Apr 2017 08:09:42 +1000 (AEST) Date: Sat, 29 Apr 2017 08:09:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: Bruce Evans , freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170428201522.GA32785@troutmask.apl.washington.edu> Message-ID: <20170429070036.A4005@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=VbSHBBh9 c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=2JjXyQGd_aUmJn-FHg8A:9 a=SzcEAFoTqt-hgAuy:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Fri, 28 Apr 2017 22:19:14 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 22:09:46 -0000 On Fri, 28 Apr 2017, Steve Kargl wrote: > On Sat, Apr 29, 2017 at 04:40:14AM +1000, Bruce Evans wrote: >> On Fri, 28 Apr 2017, Steve Kargl wrote: >>> ... >>> The slowness comes from handling extra precision arithmetic. For >>> sinpi(x) = x * p(x) where p(x) = s0 + x2 * S(x2) is the polynomial >>> approximation and x2 = x * x. One needs to take care in the ordering >>> on the evaluation where x and x2 are split into high and low parts. >>> See the source code posted in response to your other email. >> ... >> Calculating the polynomial as x * p(x) seems wrong. > > It starts life as the Remes approximation for p(x) = sin(pi*x) / x. > Yes, I also looked into using p(x) = sin(pi*x) / (pi*x). At some > point, one must do sinpi(x) = sin(pi*x) = x * p(x). I forgot that the linear term needs to be multiplied by Pi. Actually, the problem is only in the notation and the above description. s0 looks like a constant, but it is actually Pi*x in extra precision, and no extra precision is needed or done for x2. __kernel_cospi() seems to be buggy. It splits x2, but doesn't use extra precision for calculating x2. Is extra precision really needed for the x2 term? It is like the x3 term for sin*(), with the critical difference that the coeffient is much larger (-1/2 instead of -1/6 before multiplication by pi). This requires extra accuracy for cos() too, but not for the calculating the term. I optimized this by changing a slow fdlibm method to essentially 2sum. The x2/2 term is inaccurate but no significant further inaccuracies occur for adding terms. You have Pi*Pi*x2/2 which is more inaccurate. I guess the extra half an ulp accuracy here is too much. You avoid this half an ulp using extra precision, and seem to use lots of extra precision instead of the final 2sum step. Probably much slower. Here is my modified method: x2 = x*x; /* hopefully really don't need extra prec */ (hi, lo) = split(x2); resid = S(x2); hi = C2_hi * hi; lo = C2_lo * hi + C1_hi * lo + C1_lo * lo; lo = lo + resid; #ifdef hopefully_not_needed Re-split hi+lo if lo is too large. #endif return 3sum(1, hi, lo) 3sum is in math_private.h and is supposed to be used instead of magic- looking open code. Here it would reduce to the same expressions as in __kernel_sin(). 1+hi = hi_1 + lo_1; /* by hi-lo decomp. */ return (lo + lo_1 + hi_1); /* safely add the lo's and "carry" */ > One could do, as is done with sin(x), > > f(x) = (sin(pi*x) - pi*x)/(pi*x)**3 > > then sinpi(x) = pi*x + (pi*x)**3 * f(x), but this then adds > the complication that pi*x must be computed in extra precision. Isn't that what is done now? Of course pi*x must be evaluated in extra precision, but hopefully no more is needed. The x3 term would be much harder to do all in extra precision than the x2 term for cospi(). >> That is too inaccurate even for sin(x), and probably slower too. > > I'm not sure why you're claiming that it is too inaccurate. Writing sin(x) as x * (1 + C2*x*x + ...) without extra precision. This gives at best an error of half an ulp for the part in parentheses and another half an ulp for the multiplication. The final step must be an addition of a large term with a term at least 2 times smaller so that the error can be controlled (this depends on 1 of the terms being exact). > ... >>> float >>> bde1(float x) >>> { >>> return (sinf((float)M_PI * x)); >>> } >> >> sinpif() with range reduction in float precision and multiplication >> by M_PI and __kernel_sin() to finish off would be much faster and >> more accurate than doing everything in float precision. On i386/i387, > > Multiplication by M_PI and __kernel_sin() are double precision > intermediates. That works for float. That's what I mean by naive code having a chance of working. It takes foot-shooting to reduce M_PI to float. Unfortunately, the API + ABI does reduce (M_PI * x) to float in sinf(M_PI * x) if sinf() is extern. But if sinf() is in hardware, the compiler might not destroy the extra precision before or after using the hardware. > What are you going to > do for double and long double? One of the benefits of writing > sinpif(x) in float precision is that the exacts same algorithm is > used in sinpi(x) and sinpil(x). One of these can be exhaustively > tested. That is about the only benefit of the float functions, so I resist optimizing them using doubles. It would be better to use extra precision automatically, but not force it. Bruce From owner-freebsd-hackers@freebsd.org Fri Apr 28 23:36:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CA5DD55E45; Fri, 28 Apr 2017 23:36:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 146D41D75; Fri, 28 Apr 2017 23:36:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3SNZqXN034900 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 16:35:52 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3SNZqtZ034899; Fri, 28 Apr 2017 16:35:52 -0700 (PDT) (envelope-from sgk) Date: Fri, 28 Apr 2017 16:35:52 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-numerics@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170428233552.GA34580@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170429070036.A4005@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 23:36:00 -0000 On Sat, Apr 29, 2017 at 08:09:39AM +1000, Bruce Evans wrote: > On Fri, 28 Apr 2017, Steve Kargl wrote: > > > On Sat, Apr 29, 2017 at 04:40:14AM +1000, Bruce Evans wrote: > >> On Fri, 28 Apr 2017, Steve Kargl wrote: > >>> ... > >>> The slowness comes from handling extra precision arithmetic. For > >>> sinpi(x) = x * p(x) where p(x) = s0 + x2 * S(x2) is the polynomial > >>> approximation and x2 = x * x. One needs to take care in the ordering > >>> on the evaluation where x and x2 are split into high and low parts. > >>> See the source code posted in response to your other email. > >> ... > >> Calculating the polynomial as x * p(x) seems wrong. > > > > It starts life as the Remes approximation for p(x) = sin(pi*x) / x. > > Yes, I also looked into using p(x) = sin(pi*x) / (pi*x). At some > > point, one must do sinpi(x) = sin(pi*x) = x * p(x). > > I forgot that the linear term needs to be multiplied by Pi. > > Actually, the problem is only in the notation and the above description. > s0 looks like a constant, but it is actually Pi*x in extra precision, > and no extra precision is needed or done for x2. I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. static const float s0hi = 3.14062500e+00f, /* 0x40490000 */ s0lo = 9.67653585e-04f, /* 0x3a7daa22 */ s1 = -5.16771269e+00f, /* 0xc0a55de7 */ s2 = 2.55016255e+00f, /* 0x402335dd */ s3 = -5.99202096e-01f, /* 0xbf19654f */ s4 = 8.10018554e-02f; /* 0x3da5e44d */ static inline float __kernel_sinpif(float x) { double s; float p, x2; x2 = x * x; p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; s = x * (x2 * (double)p + s0hi + s0lo); return ((float)s); } x2 and p are computed in float but is accumulates the final result in double. Using a higher precision works for float, but double and long double becomes problematic. > __kernel_cospi() seems to be buggy. It splits x2, but doesn't use > extra precision for calculating x2. Is extra precision really needed > for the x2 term? Yes. The last part of __kernel_cospif() is a fused-multiple and add. For small |x2|, we can do a normal summation. That's this block of code GET_FLOAT_WORD(ix, x2); if (ix < 0x3c800000) /* |x2| < 0x1p-6 */ return (c0 + c * x2); If |x2| > 0x1p-6, then c0 + c * x2 is computed with a FMA, but its a little trickier. This splits c in clo and chi, and adds in a correction for c1 GET_FLOAT_WORD(ix, c); SET_FLOAT_WORD(chi, (ix >> 14) << 14); clo = c - chi + c1lo; In the final expression, c = clo * x2lo + chi * x2lo + clo * x2hi + (chi * x2hi + c0); chi * c2hi is exact, and the parenthesis are required to achieve max ULP < ~0.88. The grouping of the other terms does not seem to matter. > It is like the x3 term for sin*(), with the critical > difference that the coeffient is much larger (-1/2 instead of -1/6 > before multiplication by pi). This requires extra accuracy for cos() > too, but not for the calculating the term. I optimized this by changing > a slow fdlibm method to essentially 2sum. The x2/2 term is inaccurate > but no significant further inaccuracies occur for adding terms. You > have Pi*Pi*x2/2 which is more inaccurate. I guess the extra half an > ulp accuracy here is too much. You avoid this half an ulp using extra > precision, and seem to use lots of extra precision instead of the final > 2sum step. Probably much slower. > > Here is my modified method: > > x2 = x*x; /* hopefully really don't need extra prec */ > (hi, lo) = split(x2); > resid = S(x2); > hi = C2_hi * hi; > lo = C2_lo * hi + C1_hi * lo + C1_lo * lo; > lo = lo + resid; > #ifdef hopefully_not_needed > Re-split hi+lo if lo is too large. > #endif > return 3sum(1, hi, lo) > > 3sum is in math_private.h and is supposed to be used instead of magic- > looking open code. I completely missed 3sum in math_private.h. I did try using your 2sum and 2sumF macros, but did not recall seeing any difference from my hand-rolled code. I probably didn't spend enough time looking into if I was using 2sum[F] properly. I'll see if I can adapt my code to use these macros. > Here it would reduce to the same expressions as in > __kernel_sin(). > > 1+hi = hi_1 + lo_1; /* by hi-lo decomp. */ > return (lo + lo_1 + hi_1); /* safely add the lo's and "carry" */ > > > One could do, as is done with sin(x), > > > > f(x) = (sin(pi*x) - pi*x)/(pi*x)**3 > > > > then sinpi(x) = pi*x + (pi*x)**3 * f(x), but this then adds > > the complication that pi*x must be computed in extra precision. > > Isn't that what is done now? Of course pi*x must be evaluated in > extra precision, but hopefully no more is needed. The x3 term > would be much harder to do all in extra precision than the x2 > term for cospi(). Well, yes, I supposed that's one way to look at it. In the approximation of sinpif(x) = x * (s0 + x2 * S(x2)), the s0 term is nearly pi. The s1 coefficient, as determined by Remes, is s1 = -5.16771269, which happens to be close to -pi**3/6 = -5.16771278 (i.e, next term in McClauren series of sin(pi*x) = pi*x - (pi**3/6)*x**3 + .... So, the Remes coefficients have absorbed the factors of pi. > >> That is too inaccurate even for sin(x), and probably slower too. > > > > I'm not sure why you're claiming that it is too inaccurate. > > Writing sin(x) as x * (1 + C2*x*x + ...) without extra precision. > This gives at best an error of half an ulp for the part in parentheses > and another half an ulp for the multiplication. The final step > must be an addition of a large term with a term at least 2 times > smaller so that the error can be controlled (this depends on 1 > of the terms being exact). Ah, okay, I understand what you're getting at. I played a number of games with grouping intermediate results and trying to accumulate high and low parts. You're seeing the best that I can do. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat Apr 29 00:59:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B511FD52424; Sat, 29 Apr 2017 00:59:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F5581ABD; Sat, 29 Apr 2017 00:59:26 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3T0xPk4037996 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Apr 2017 17:59:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3T0xOBe037995; Fri, 28 Apr 2017 17:59:24 -0700 (PDT) (envelope-from sgk) Date: Fri, 28 Apr 2017 17:59:24 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170429005924.GA37947@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170428233552.GA34580@troutmask.apl.washington.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 00:59:26 -0000 On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: > > I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. > > static const float > s0hi = 3.14062500e+00f, /* 0x40490000 */ > s0lo = 9.67653585e-04f, /* 0x3a7daa22 */ > s1 = -5.16771269e+00f, /* 0xc0a55de7 */ > s2 = 2.55016255e+00f, /* 0x402335dd */ > s3 = -5.99202096e-01f, /* 0xbf19654f */ > s4 = 8.10018554e-02f; /* 0x3da5e44d */ > > static inline float > __kernel_sinpif(float x) > { > double s; > float p, x2; > x2 = x * x; > p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; > s = x * (x2 * (double)p + s0hi + s0lo); > return ((float)s); > } > Well, starting with above and playing the splitting game with x, x2, and p. I've manage to reduce the max ULP in the region testd. Testing against MPFR with sin(pi*x) computed in 5*24-bit precision gives MAX ULP: 0.73345101 Total tested: 33554427 0.7 < ULP <= 0.8: 90 0.6 < ULP <= 0.7: 23948 Exhaustive testing with my older sinpi(x) as the reference gives ./testf -S -m 0x1p-14 -M 0.25 -d -e MAX ULP: 0.73345101 Total tested: 100663296 0.7 < ULP <= 0.8: 45 0.6 < ULP <= 0.7: 11977 The code is slightly slower than my current best kernel. sinpif time is 0.0147 usec per call (60 cycles). static inline float __kernel_sinpif(float x) { float p, phi, x2, x2hi, x2lo, xhi, xlo; uint32_t ix; x2 = x * x; p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; GET_FLOAT_WORD(ix, p); SET_FLOAT_WORD(phi, (ix >> 14) << 14); GET_FLOAT_WORD(ix, x2); SET_FLOAT_WORD(x2hi, (ix >> 14) << 14); x2lo = s0lo + x2 * (p - phi) + (x2 - x2hi) * phi; x2hi *= phi; GET_FLOAT_WORD(ix, x); SET_FLOAT_WORD(xhi, (ix >> 14) << 14); xlo = x - xhi; xlo = xlo * (x2lo + x2hi) + (xlo * s0hi + xhi * x2lo); return (xlo + xhi * x2hi + xhi * s0hi); } -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat Apr 29 07:54:36 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4555BD55D2D; Sat, 29 Apr 2017 07:54:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8DBA21; Sat, 29 Apr 2017 07:54:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id C542AD69213; Sat, 29 Apr 2017 17:54:25 +1000 (AEST) Date: Sat, 29 Apr 2017 17:54:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170429005924.GA37947@troutmask.apl.washington.edu> Message-ID: <20170429151457.F809@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=nNk0bZpkwH5g55qFUBQA:9 a=tF56D53I6aLQB65K:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 29 Apr 2017 11:09:39 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 07:54:36 -0000 On Fri, 28 Apr 2017, Steve Kargl wrote: > On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: >> >> I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. Comments on this below. This is all rather over-engineered. Optimizing these functions is unimportant comparing with finishing cosl() and sinl() and optimizing all of the standard trig functions better, but we need correctness. But I now see many simplifications and improvements: (1) There is no need for new kernels. The standard kernels already handle extra precision using approximations like: sin(x+y) ~= sin(x) + (1-x*x/2)*y. Simply reduce x and write Pi*x = hi+lo. Then sin(Pi*x) = __kernel_sin(hi, lo, 1). I now see how to do the extra-precision calculations without any multiplications. For Pi*x, suppose that x is near 1/4. Choose a nice constant value x0 as far below 1/4 as works and reduce x further using this: x = x0 + (x - x0) // plain '=' means exact y0 ~= Pi*x0 = hi0 + lo0 // in extra prec at compile time y ~= Pi*(x-x0) // small, so doesn't need extra prec Pi*x ~= hi0 + lo0 + y = hi1 + lo1 // use 2sum sin(Pi*x) ~= __kernel_sin(hi1, lo1, 1). but it is better to use a special polynomial approximation about y0 on y. We have reduced x to the significantly smaller y, so the polynominal can have fewer terms and not need any extra precision except for the additive term. In infinite precision, sin(y+y0) = S0 + S1*y + ... Write S0 = hi2+lo2 and choose x0 so that lo2 can be replaced by 0 without significant loss of accuracy (see some exp2's for this method). At worst, lo2 is nonzero and we have to do just 1 extra-precision operation. Otherwise, we have a normal polyomial evaluation. Unlike for sin() near 0, there are even terms and and not nice fractional coefficients, but since y is small there aren't so many terms. It is important to avoid needing extra precision for many of the coefficients. Higher ones don't need it since y is small, and S0 might not need it. The Intel ia64 math library uses the reduction x = y+y0 at several interval endpoints below Pi/4 for ordinary sin(). Previously, I couldn't get this method to work as well as using the single large interval [-Pi/4, Pi/4], since the even terms take a while to calculate and I didn't understand the hi+lo decomposition methods so well. Reminder on why cos(x) needs extra precison but sin(x) doesn't when we use the brute force expansion up to Pi/4: we use cos(x) = 1 - x*x/2 + ... and the only problem is to subtract these terms accurately enough. There is a problem since Pi/4 is slightly larger than sqrt(1/2), so x*x/2 can be slightly larger than 1/4. If it were larger than 1/2, then the subtraction would lose a full bit to cancelation, so extra inaccuracy could be more than 1 ulp, but we want it to be less 0.5 ulps so that the combined inaccuracy is less than 1 ulp. Similarly, when x*x/2 is larger than 1/4 but below 1/2, the extra inaccuracy can be larger than 0.5 ulps though smaller than 1 ulp. Above 0.5 is still to high, so we need some extra precision. This problem doesn't affect sin(x) since the ratio of the terms is -x*x/6 so the extra inaccuracy is 3 times smaller so below 1/3 ulps. For cos(y+y0) ~= C0 + C1*y + C2*y*y, y must be small enough for the extra inaccuracy from the first addition to be a little smaller tha 0.5 ulps. This is not as easy as I was thinking, since the lineat term is relatively large. But there is no problem for cos(y+1/2): cos(y+1/2) ~= 0.88 - 0.48*y, and the ratio of terms with y = Pi/4-1/2 is ~0.16. However, sin(y+1/2) ~= 0.48 + 0.88*y, so the maximum ratio of terms is ~0.53 -- too much. >> static const float >> s0hi = 3.14062500e+00f, /* 0x40490000 */ >> s0lo = 9.67653585e-04f, /* 0x3a7daa22 */ >> s1 = -5.16771269e+00f, /* 0xc0a55de7 */ >> s2 = 2.55016255e+00f, /* 0x402335dd */ >> s3 = -5.99202096e-01f, /* 0xbf19654f */ >> s4 = 8.10018554e-02f; /* 0x3da5e44d */ >> >> static inline float >> __kernel_sinpif(float x) >> { >> double s; >> float p, x2; >> x2 = x * x; >> p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; >> s = x * (x2 * (double)p + s0hi + s0lo); >> return ((float)s); >> } I don't like the style being completely different. Why lower-case constants? ... > Well, starting with above and playing the splitting game > with x, x2, and p. I've manage to reduce the max ULP in > the region testd. Testing against MPFR with sin(pi*x) > computed in 5*24-bit precision gives It already cheats by using (double)p, but is limited by using float to caclulate p. p should have an inaccuracy of not much more than 1 ulp, and we don't care if this is a little over 1. Then when we do the final caclulations in either extra precision or using the double hack, we don't get any more inaccuracy. Extra precision is not very useful for x2 * p -- it only increases the error by another half an ulp. So errors for that part are 0.5 ulps for x2, ~1 ulp for p and 0.5 for a float multiplication -- 2.0 althogther -- and the the double multiplication reduces this to 1.5. This gets scaled down as usual by the term ratio x*x/6 ~= 0.2. 0.2 of 1.5 = 0.3 is below the magic 0.5, but so is 0.2 of 2.0 = 0.4. But I would prefer below the magic 0.25. > MAX ULP: 0.73345101 > Total tested: 33554427 > 0.7 < ULP <= 0.8: 90 > 0.6 < ULP <= 0.7: 23948 You can even reverse this to calculate the maximum of the term ratio fairly accuractely. The rounding error is 0.233. We had an error of about 1.5 before the final addition. The ratio 0.233/1.5 = 0.16 gives the reduction ratio for the final addition. It approximates the term ratio. (I'm surprised that it is lower than the term ratio instead of higher. In fact, I don't believe the 0.733. According to the term ratio, the worst case must be at least 0.800.) > Exhaustive testing with my older sinpi(x) as the reference > gives > > ./testf -S -m 0x1p-14 -M 0.25 -d -e > MAX ULP: 0.73345101 > Total tested: 100663296 > 0.7 < ULP <= 0.8: 45 > 0.6 < ULP <= 0.7: 11977 Perhaps it really is 0.733. I estimated an error of 1 ulp for p, but its term ratio is much lower than for the first 2 terms -- 20 times lower from the factorial in the denominator -- so 0.55 ulps would be a better estimate. This gives the estimate term_ratio * 1.05 = 0.21 extra ulps which matches 0.233 almost perfectly. Now it seems too perfect to be true -- I usually forget to add up all the half- ulps in calculations like this. > The code is slightly slower than my current best kernel. > sinpif time is 0.0147 usec per call (60 cycles). It still seems slow :-). Full sin(x) takes 43 cycles on amd64 (freefall xeon) for x where its extra precision is used (iy != 0), and calculating only Pi*x in extra precision shouldn't add much to that, and the simpler range reduction should subtract a lot (sin(x) takes 23 cycles below 2Pi where its range reduction is simple). > static inline float > __kernel_sinpif(float x) > { > float p, phi, x2, x2hi, x2lo, xhi, xlo; > uint32_t ix; > > x2 = x * x; > p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; > > GET_FLOAT_WORD(ix, p); > SET_FLOAT_WORD(phi, (ix >> 14) << 14); > > GET_FLOAT_WORD(ix, x2); > SET_FLOAT_WORD(x2hi, (ix >> 14) << 14); I expect that these GET/SET's are the slowest part. They are quite fast in float prec, but in double prec on old i386 CPUs compilers generate bad code which can have penalties of 20 cycles per GET/SET. Why the strange reduction? The double shift is just a manual optimization or pssimization (usually the latter) for clearing low bits. Here it is used to clear 14 low bits instead of the usual 12. This is normally written using just a mask of 0xffff0000, unless you want a different number of bits in the hi terms for technical reasons. Double precision can benefit more from asymmetric splitting of terms since 53 is not divisible by 2; 1 hi term must have less than 26.5 bits and the other term can hold an extra bit. Here is an example of fairly refined splitting and use of 2sum withit: X float X log10f(float x) X { X struct Float r; X float_t hi, lo; X float fhi; hi+lo decompositions need float_t in general, for both correctness and efficiency. X int32_t hx; X X DOPRINT_START(&x); X k_logf(x, &r); X if (!r.lo_set) X RETURNP(r.hi); X if (sizeof(float_t) > sizeof(float)) X RETURNP((invln10_lo + (float_t)invln10_hi) * (r.lo + r.hi)); X _2sumF(r.hi, r.lo); X fhi = r.hi; X GET_FLOAT_WORD(hx, fhi); X SET_FLOAT_WORD(fhi, hx & 0xfffff000); It is hard to do the splitting better than this. This method subtly masks bugs if float_t is not used. On i386/i387 it forces much the same slow loads and stores that are needed to discard any extra precision when float_t is not used. X hi = fhi; X lo = r.lo + (r.hi - hi); The code tries to optimize things with careful assignments between float_t and float. This has further subtleties from float_t being used. When there is extra precision, float_t should be different from float, and compilers should not be broken enough to elide conversions between float and float_t. The above 2 lines are basic splitting, and the subtleties are what is needed for this to work. struct Float is just hi and lo in a struct, each with type float, but a further subtlety is that you want the compiler to keep all variables in registers, with floats in extended precision in the registers; then it must be arranged that hi+lo decompositions in registers have no extra precision... X RETURN2P(invln10_hi * hi, X (invln10_lo + invln10_hi) * lo + invln10_lo * hi); X } ... but when the hi+lo values are used in expressions like this, we want the extra precision back. Here the hi*hi term is exact (that is the point of the decomposition), and extra precision gives some free extra accuracy for the rest of the calculation. > > x2lo = s0lo + x2 * (p - phi) + (x2 - x2hi) * phi; > x2hi *= phi; > > GET_FLOAT_WORD(ix, x); > SET_FLOAT_WORD(xhi, (ix >> 14) << 14); > xlo = x - xhi; > xlo = xlo * (x2lo + x2hi) + (xlo * s0hi + xhi * x2lo); > > return (xlo + xhi * x2hi + xhi * s0hi); > } Yet another splitting is going to be slow. This one is necessary. Are the first 2 really necessary? The above analysis might show that they really aren't -- didn't we get an error of 0.733 ulps (which seems too low) using both methods? Otherwise, this code is very similar to my log10f(). k_logf() does most of the work. It evaluates logf(x) in extra precision. log10f(x) is just C*logf(x) in extra precision. k_logf() arranges to return the extra precision. For sinpi*(), you need to scale the arg instead of the result. This is actually easier, since the arg is not in extra precision and the extra precision is very easy to handle in the kernel (and even already handled in standard kernels). The above logf() runs acceptably fast using a kernel not especially optimized for it. Signficantly slower than my logf(). Only slightly faster than fdlibm+cygnus log10f(), but it is much more accurate. Bruce From owner-freebsd-hackers@freebsd.org Sat Apr 29 10:49:25 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCCB4D5597F; Sat, 29 Apr 2017 10:49:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id 720191A07; Sat, 29 Apr 2017 10:49:24 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id B764110390F; Sat, 29 Apr 2017 20:19:27 +1000 (AEST) Date: Sat, 29 Apr 2017 20:19:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans cc: Steve Kargl , freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170429151457.F809@besplex.bde.org> Message-ID: <20170429194239.P3294@besplex.bde.org> References: <20170409220809.GA25076@troutmask.apl.washington.edu> <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=OsaYX3Fg_SImqZmlGUkA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 29 Apr 2017 11:09:57 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 10:49:26 -0000 On Sat, 29 Apr 2017, Bruce Evans wrote: > On Fri, 28 Apr 2017, Steve Kargl wrote: > >> On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: >>> >>> I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. > > Comments on this below. > > This is all rather over-engineered. Optimizing these functions is > unimportant comparing with finishing cosl() and sinl() and optimizing > all of the standard trig functions better, but we need correctness. > But I now see many simplifications and improvements: > > (1) There is no need for new kernels. The standard kernels already handle > extra precision using approximations like: > > sin(x+y) ~= sin(x) + (1-x*x/2)*y. > > Simply reduce x and write Pi*x = hi+lo. Then > > sin(Pi*x) = __kernel_sin(hi, lo, 1). > > I now see how to do the extra-precision calculations without any > multiplications. But that is over-engineered too. Using the standard kernels is easy and works well: XX #include XX #include XX XX #include "math_private.h" XX XX static const double XX pi_hi = 3.1415926218032837e+00, /* 0x400921fb 0x50000000 */ XX pi_lo = 3.1786509547050787e-08; /* 0x3e6110b4 0x611a5f14 */ XX XX /* Only for |x| <= ~0.25 (missing range reduction. */ XX XX double XX cospi(double x) XX { XX double_t hi, lo; XX XX hi = (float)x; XX lo = x - hi; XX lo = (pi_lo + pi_hi) * lo + pi_lo * hi; XX hi = pi_hi * hi; XX _2sumF(hi, lo); XX return __kernel_cos(hi, lo); XX } XX XX double XX sinpi(double x) XX { XX double_t hi, lo; XX XX hi = (float)x; XX lo = x - hi; XX lo = (pi_lo + pi_hi) * lo + pi_lo * hi; XX hi = pi_hi * hi; XX _2sumF(hi, lo); XX return __kernel_sin(hi, lo, 1); XX } XX XX double XX tanpi(double x) XX { XX double_t hi, lo; XX XX hi = (float)x; XX lo = x - hi; XX lo = (pi_lo + pi_hi) * lo + pi_lo * hi; XX hi = pi_hi * hi; XX _2sumF(hi, lo); XX return __kernel_tan(hi, lo, 1); XX } I only did a sloppy accuracy test for sinpi(). It was 0.03 ulps less accurate than sin() on the range [0, 0.25] for it and [0, Pi/4] for sin(). Efficiency is very good in some cases, but anomalous in others: all times in cycles, on i386, on the range [0, 0.25] athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 cos: 61-62 44 43 cospi: 69-71 (8-9 extra) 78 (anomalous...) 42 (faster to do more!) sin: 59-60 51 37 sinpi: 67-68 (8 extra) 80 42 tan: 136-172 93-195 67-94 tanpi: 144-187 (8-15 extra) 145-176 61-189 That was a throughput test. Latency is not so good. My latency test doesn't use serializing instructions, but uses random args and the partial serialization of making each result depend on the previous one. athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 cos: 84-85 69 79 cospi: 103-104 (19-21 extra) 117 94 sin: 75-76 89 77 sinpi: 105-106 (30 extra) 116 90 tan: 168-170 167-168 147 tanpi: 191-194 (23-24 extra) 191 154 This also indicates that the longest times for tan in the throughput test are what happens when the function doesn't run in parallel with itself. The high-degree polynomial and other complications in tan() are too complicated for much cross-function parallelism. Anywyay, it looks like the cost of using the kernel is at most 8-9 in the parallel case and at most 30 in the serial case. The extra- precision code has about 10 dependent instructions, so it s is doing OK to take 30. Bruce From owner-freebsd-hackers@freebsd.org Sat Apr 29 18:10:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E065D55BE9; Sat, 29 Apr 2017 18:10:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 76320D7A; Sat, 29 Apr 2017 18:10:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3TIAN63041484 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Apr 2017 11:10:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3TIAMGF041483; Sat, 29 Apr 2017 11:10:22 -0700 (PDT) (envelope-from sgk) Date: Sat, 29 Apr 2017 11:10:22 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170429181022.GA41420@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170429151457.F809@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 18:10:24 -0000 On Sat, Apr 29, 2017 at 05:54:21PM +1000, Bruce Evans wrote: > On Fri, 28 Apr 2017, Steve Kargl wrote: > > > On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: > >> > >> I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. > > Comments on this below. Way too much information to digest in one reading. I'll answer the things that are easy ... > >> x2 = x * x; > >> p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; > >> s = x * (x2 * (double)p + s0hi + s0lo); > >> return ((float)s); > >> } > > I don't like the style being completely different. Why lower-case constants? > ... Having teethed on musty FORTRAN code, I have an adversion to uppercase. I also do not like camel case, which seems to plague modern languages. > > Well, starting with above and playing the splitting game > > with x, x2, and p. I've manage to reduce the max ULP in > > the region testd. Testing against MPFR with sin(pi*x) > > computed in 5*24-bit precision gives > > It already cheats by using (double)p, but is limited by using float to > caclulate p. Yes, the above is cheating to the extent that the above code started out as completely written in double. This gives max ULP < 0.51. I then started reducing the double to float with the intent of finding when max ULP exceeds some chosen threshold. The above gave something like max ULP < 0.55. I then moved the (double) cast to different terms/factors, observed how the max ULP changed. This then gives information about what requires extra precision. > > static inline float > > __kernel_sinpif(float x) > > { > > float p, phi, x2, x2hi, x2lo, xhi, xlo; > > uint32_t ix; > > > > x2 = x * x; > > p = x2 * (x2 * (x2 * s4 + s3) + s2) + s1; > > > > GET_FLOAT_WORD(ix, p); > > SET_FLOAT_WORD(phi, (ix >> 14) << 14); > > > > GET_FLOAT_WORD(ix, x2); > > SET_FLOAT_WORD(x2hi, (ix >> 14) << 14); > > I expect that these GET/SET's are the slowest part. They are quite fast > in float prec, but in double prec on old i386 CPUs compilers generate bad > code which can have penalties of 20 cycles per GET/SET. > > Why the strange reduction? The double shift is just a manual optimization > or pssimization (usually the latter) for clearing low bits. Here it is > used to clear 14 low bits instead of the usual 12. This is normally > written using just a mask of 0xffff0000, unless you want a different > number of bits in the hi terms for technical reasons. Double precision > can benefit more from asymmetric splitting of terms since 53 is not > divisible by 2; 1 hi term must have less than 26.5 bits and the other term > can hold an extra bit. Because I didn't think about using a mask. :-) It's easy to change 14 to 13 or 11 or ..., while I would need to write out zeros and one to come up with 0xffff8000, etc. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat Apr 29 18:42:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8BCDD567C2; Sat, 29 Apr 2017 18:42:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A043F1D4B; Sat, 29 Apr 2017 18:42:11 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3TIg9KM041637 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Apr 2017 11:42:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3TIg95N041636; Sat, 29 Apr 2017 11:42:09 -0700 (PDT) (envelope-from sgk) Date: Sat, 29 Apr 2017 11:42:09 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170429184209.GB41420@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429194239.P3294@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170429194239.P3294@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 18:42:11 -0000 On Sat, Apr 29, 2017 at 08:19:23PM +1000, Bruce Evans wrote: > On Sat, 29 Apr 2017, Bruce Evans wrote: > > > On Fri, 28 Apr 2017, Steve Kargl wrote: > > > >> On Fri, Apr 28, 2017 at 04:35:52PM -0700, Steve Kargl wrote: > >>> > >>> I was just backtracking with __kernel_sinpi. This gets a max ULP < 0.61. > > > > Comments on this below. > > > > This is all rather over-engineered. Optimizing these functions is > > unimportant comparing with finishing cosl() and sinl() and optimizing > > all of the standard trig functions better, but we need correctness. > > But I now see many simplifications and improvements: > > > > (1) There is no need for new kernels. The standard kernels already handle > > extra precision using approximations like: > > > > sin(x+y) ~= sin(x) + (1-x*x/2)*y. > > > > Simply reduce x and write Pi*x = hi+lo. Then > > > > sin(Pi*x) = __kernel_sin(hi, lo, 1). > > > > I now see how to do the extra-precision calculations without any > > multiplications. > > But that is over-engineered too. > > Using the standard kernels is easy and works well: As your code only works on the interval [0,0.25], I took the liberty to use it as a __kernel_sinpi and __kernel_cospi. > XX double > XX cospi(double x) > XX { > XX double_t hi, lo; If sizeof(double_t) indicates what I think it means, This is slow on my Core2 duo (aka ia32 system). > XX hi = (float)x; > XX lo = x - hi; This is the splitting I use in my double version versions with hi and lo as simply double. > XX lo = (pi_lo + pi_hi) * lo + pi_lo * hi; > XX hi = pi_hi * hi; > XX _2sumF(hi, lo); > XX return __kernel_cos(hi, lo); > XX } > XX > > I only did a sloppy accuracy test for sinpi(). It was 0.03 ulps less > accurate than sin() on the range [0, 0.25] for it and [0, Pi/4] for > sin(). > > Efficiency is very good in some cases, but anomalous in others: all > times in cycles, on i386, on the range [0, 0.25] > > athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 > cos: 61-62 44 43 > cospi: 69-71 (8-9 extra) 78 (anomalous...) 42 (faster to do more!) > sin: 59-60 51 37 > sinpi: 67-68 (8 extra) 80 42 > tan: 136-172 93-195 67-94 > tanpi: 144-187 (8-15 extra) 145-176 61-189 > > That was a throughput test. Latency is not so good. My latency test > doesn't use serializing instructions, but uses random args and the > partial serialization of making each result depend on the previous > one. > > athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 > cos: 84-85 69 79 > cospi: 103-104 (19-21 extra) 117 94 > sin: 75-76 89 77 > sinpi: 105-106 (30 extra) 116 90 > tan: 168-170 167-168 147 > tanpi: 191-194 (23-24 extra) 191 154 I is unclear how you're making your measurements. My timings with my kernels compared to kernels based on your code: | Bruce | Steve ------+--------------+-------------- sinpi | 0.0742 (148) | 0.0633 (126) cospi | 0.0720 (144) | 0.0513 (102) First number is microseconds per call and the (xxx) is the time*cpu_freq. As far as over-engineering, for sinpi I find sinpi Bruce kernel Steve kernel MAX ULP: 0.73021263 0.73955815 Total tested: 33554431 33554431 0.7 < ULP <= 0.8: 154 280 0.6 < ULP <= 0.7: 27650 29197 cospi is much more interesting and as you state above more difficult to get right. I have reworked my kernel, yet, but I find cospi Bruce kernel Steve kernel MAX ULP: 0.78223389 0.89921787 Total tested: 33554431 33554431 0.8 < ULP <= 0.9: 0 3262 0.7 < ULP <= 0.8: 9663 68305 0.6 < ULP <= 0.7: 132948 346214 Perhaps, using double_t would reduce my max ULP at the expense of speed. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat Apr 29 19:09:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19F17D56FC5; Sat, 29 Apr 2017 19:09:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id A0FADD8A; Sat, 29 Apr 2017 19:09:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id A7D7342B17F; Sun, 30 Apr 2017 05:09:27 +1000 (AEST) Date: Sun, 30 Apr 2017 05:09:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170429181022.GA41420@troutmask.apl.washington.edu> Message-ID: <20170430042756.A862@besplex.bde.org> References: <20170427231411.GA11346@troutmask.apl.washington.edu> <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429181022.GA41420@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=4e2EsQlSr8nDh46oqDgA:9 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 29 Apr 2017 19:15:16 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 19:09:39 -0000 On Sat, 29 Apr 2017, Steve Kargl wrote: > On Sat, Apr 29, 2017 at 05:54:21PM +1000, Bruce Evans wrote: >> On Fri, 28 Apr 2017, Steve Kargl wrote: > ... >>> GET_FLOAT_WORD(ix, p); >>> SET_FLOAT_WORD(phi, (ix >> 14) << 14); >>> >>> GET_FLOAT_WORD(ix, x2); >>> SET_FLOAT_WORD(x2hi, (ix >> 14) << 14); >> >> I expect that these GET/SET's are the slowest part. They are quite fast >> in float prec, but in double prec on old i386 CPUs compilers generate bad >> code which can have penalties of 20 cycles per GET/SET. >> >> Why the strange reduction? The double shift is just a manual optimization >> or pssimization (usually the latter) for clearing low bits. Here it is >> used to clear 14 low bits instead of the usual 12. This is normally >> written using just a mask of 0xffff0000, unless you want a different >> number of bits in the hi terms for technical reasons. Double precision >> can benefit more from asymmetric splitting of terms since 53 is not >> divisible by 2; 1 hi term must have less than 26.5 bits and the other term >> can hold an extra bit. > > Because I didn't think about using a mask. :-) > > It's easy to change 14 to 13 or 11 or ..., while I would > need to write out zeros and one to come up with 0xffff8000, > etc. Here are some examples of more delicate splittings from the uncommitted clog*(). They are usually faster than GET/SET, but slower than converting to lower precision as is often possible for double precision and ld128 only. clog*() can't use the casting method since it needs to split in the middle, and doesn't use GET/SET since it is slow. It uses methods that only work on args that are not too large or too small, and uses a GET earlier to classify the arg size. XX double prec: XX double_t ax, ax2h, ax2l, t; XX XX t = (double)(ax * (0x1p27 + 1)); XX axh = (double)(ax - t) + t; XX axl = ax - axh; Splitting in the middle is required to calculate ax*ax exactly. Since the middle bit is 26.5, splitting in the middle is impossible, but there are tricks to make spitting at bit 26 or 27 work just as well. Multipling by 0x1p27 shifts to a place where the lower bits are canceled by the subtraction. Adding 1 is a trick to create a extra (virtual) bit needed for the exact multiplication. At least ax needs to have the extra-precision type double_t so that casting to double works. Otherwise, this code would need STRICT_ASSIGN() to work around compiler bugfreatures. We assign back to double_t for efficiency. XX float prec: XX float_t ax, axh, axl, t; XX XX t = (float)(ax * (0x1p12F + 1)); XX axh = (float)(ax - t) + t; XX axl = ax - axh; This is simpler because there is a middle. I think adding 1 is not needed. XX long double double prec: XX #if LDBL_MANT_DIG == 64 XX #define MULT_REDUX 0x1p32 /* exponent MANT_DIG / 2 rounded up */ XX #elif LDBL_MANT_DIG == 113 XX #define MULT_REDUX 0x1p57 XX #else XX #error "Unsupported long double format" XX #endif XX XX long double ax, axh, axl, t; XX XX /* Calculate ax*ax and ay*ay exactly using Dekker's algorithm. */ XX t = (long double)(ax * (MULT_REDUX + 1)); XX axh = (long double)(ax - t) + t; XX axl = ax - axh; This is more unsimpler because the middle depends on a parameter and it is fractional in some cases. If adding 1 is not needed for the non- fractional case, then it should be added in MULT_REDUX in the fractional case only. Several functions including expl and e_rem_pio* use this REDUX method with the parameter hard-coded in a different way, usually with a slower STRICT_ASSIGN() and a special conversion to an integer or integer divided by a power of 2. The above is supposed to be more careful with extra precision so that STRICT_ASSIGN() is not needed. The calculation of axh may have problems with double rounding, but I think this doesn't matter here -- whatever axh is, the rest ends up in axl and we just need to ensure that both have 27 lower bits zero. Bruce From owner-freebsd-hackers@freebsd.org Sat Apr 29 19:38:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3AD6D54D63; Sat, 29 Apr 2017 19:38:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9C012AE; Sat, 29 Apr 2017 19:38:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v3TJcTRx041989 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 29 Apr 2017 12:38:29 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v3TJcTNF041988; Sat, 29 Apr 2017 12:38:29 -0700 (PDT) (envelope-from sgk) Date: Sat, 29 Apr 2017 12:38:29 -0700 From: Steve Kargl To: Bruce Evans Cc: freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions Message-ID: <20170429193829.GA41964@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429181022.GA41420@troutmask.apl.washington.edu> <20170430042756.A862@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170430042756.A862@besplex.bde.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 19:38:30 -0000 On Sun, Apr 30, 2017 at 05:09:26AM +1000, Bruce Evans wrote: > On Sat, 29 Apr 2017, Steve Kargl wrote: > > > On Sat, Apr 29, 2017 at 05:54:21PM +1000, Bruce Evans wrote: > >> On Fri, 28 Apr 2017, Steve Kargl wrote: > > ... > >>> GET_FLOAT_WORD(ix, p); > >>> SET_FLOAT_WORD(phi, (ix >> 14) << 14); > >>> > >>> GET_FLOAT_WORD(ix, x2); > >>> SET_FLOAT_WORD(x2hi, (ix >> 14) << 14); > >> > >> I expect that these GET/SET's are the slowest part. They are quite fast > >> in float prec, but in double prec on old i386 CPUs compilers generate bad > >> code which can have penalties of 20 cycles per GET/SET. > >> > >> Why the strange reduction? The double shift is just a manual optimization > >> or pssimization (usually the latter) for clearing low bits. Here it is > >> used to clear 14 low bits instead of the usual 12. This is normally > >> written using just a mask of 0xffff0000, unless you want a different > >> number of bits in the hi terms for technical reasons. Double precision > >> can benefit more from asymmetric splitting of terms since 53 is not > >> divisible by 2; 1 hi term must have less than 26.5 bits and the other term > >> can hold an extra bit. > > > > Because I didn't think about using a mask. :-) > > > > It's easy to change 14 to 13 or 11 or ..., while I would > > need to write out zeros and one to come up with 0xffff8000, > > etc. > > Here are some examples of more delicate splittings from the uncommitted > clog*(). They are usually faster than GET/SET, but slower than converting > to lower precision as is often possible for double precision and ld128 > only. clog*() can't use the casting method since it needs to split in the > middle, and doesn't use GET/SET since it is slow. It uses methods that > only work on args that are not too large or too small, and uses a GET > earlier to classify the arg size. I didn't know about these other splitting methods. Thanks for pointing them out to me. I updated by k_sinpif.c to use the standard masking with 0xffff0000. It has no effect on the timing on Core2 dou. It did however effect the max ULP. With exhaustive testing in [0x1p-14,0.25] I now have MAX ULP: 0.68287528 Total tested: 100663296 0.6 < ULP <= 0.7: 5607 the older version with the shifts by 14 bits gives MAX ULP: 0.73345101 Total tested: 100663296 0.7 < ULP <= 0.8: 45 0.6 < ULP <= 0.7: 11977 The value of 14 is a holdover from an earlier version. Getting back to the use of float_t and double_t. If one wants the performance penalty, these then work well. Changing types to float_t in k_cospif.c, I find a slowdown of for cospif, but I also find MAX ULP: 0.64679509 Total tested: 1048576000 0.6 < ULP <= 0.7: 31598 with exhaustive testing in [0,0.25]. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow From owner-freebsd-hackers@freebsd.org Sat Apr 29 20:13:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8B38D55A65; Sat, 29 Apr 2017 20:13:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 952EC16C1; Sat, 29 Apr 2017 20:13:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 2DB851041D4A; Sun, 30 Apr 2017 06:12:46 +1000 (AEST) Date: Sun, 30 Apr 2017 06:12:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: Bruce Evans , freebsd-hackers@freebsd.org, freebsd-numerics@freebsd.org Subject: Re: Implementation of half-cycle trignometric functions In-Reply-To: <20170429184209.GB41420@troutmask.apl.washington.edu> Message-ID: <20170430051230.X1000@besplex.bde.org> References: <20170428010122.GA12814@troutmask.apl.washington.edu> <20170428183733.V1497@besplex.bde.org> <20170428165658.GA17560@troutmask.apl.washington.edu> <20170429035131.E3406@besplex.bde.org> <20170428201522.GA32785@troutmask.apl.washington.edu> <20170429070036.A4005@besplex.bde.org> <20170428233552.GA34580@troutmask.apl.washington.edu> <20170429005924.GA37947@troutmask.apl.washington.edu> <20170429151457.F809@besplex.bde.org> <20170429194239.P3294@besplex.bde.org> <20170429184209.GB41420@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=AYLBJzfG c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=ZDInmu-daXXT0OxnvG4A:9 a=dM07vABZqfTYfvwQ:21 a=CjuIK1q_8ugA:10 X-Mailman-Approved-At: Sat, 29 Apr 2017 21:34:02 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 20:13:01 -0000 On Sat, 29 Apr 2017, Steve Kargl wrote: > On Sat, Apr 29, 2017 at 08:19:23PM +1000, Bruce Evans wrote: >. ... >> Using the standard kernels is easy and works well: > > As your code only works on the interval [0,0.25], I took > the liberty to use it as a __kernel_sinpi and __kernel_cospi. You already wrote the reduction part, and lgamma already has it to. I just checked lgamma. Its reduction part is short (especially after your improvements to it). Then it is sloppy and doesn't caclulate Pi*x in extra precision. I think this is justified since lgamma generally has errors much larger than 1 ulp. it does some micro-optimizations involving minus signs. There is some danger that with the kernels inline, the compiler will generate large inline code for multiple copies whose difference is just the placement of a single instruction to do the negation. If this is an optimization, then it is small. > >> XX double >> XX cospi(double x) >> XX { >> XX double_t hi, lo; > > If sizeof(double_t) indicates what I think it means, > This is slow on my Core2 duo (aka ia32 system). I doubt that it is what you think it is, since you neglect testing on i386 :-). It makes no difference on amd64, but is needed on i386 to optimized and give correct code. However, double_t is broken with clang on i386 with certain CFLAGS that give SSE. Then clang produces code that is incompatible with FLT_EVAL_METHOD and double_t. This makes clangs use of SSE a pessimization. It dodn't seem to break correctness (the result is the same as using long double instead of double_t). >> XX hi = (float)x; >> XX lo = x - hi; > > This is the splitting I use in my double version versions > with hi and lo as simply double. It will work without double_t for the splitting. double_t (or lots of slow STRICT_ASSIGN()s is needed for 2sum. 2sum is like the above except it casts to double instead of float, and compilers intentionally break casts. >> ... >> Efficiency is very good in some cases, but anomalous in others: all >> times in cycles, on i386, on the range [0, 0.25] >> >> athlon-xp, gcc-3.3 Haswell, gcc-3.3 Haswell, gcc-4.2.1 >> cos: 61-62 44 43 >> cospi: 69-71 (8-9 extra) 78 (anomalous...) 42 (faster to do more!) >> ... > > I is unclear how you're making your measurements. My timings > with my kernels compared to kernels based on your code: Basically by timing a for loop, but with many refinements to make sure that I am timing the function and not the loop, or at least to make sure that the loop timing doesn't change. For example, on amd64 and i386, the stack is aligned at 4K plus a smaller adjustable parameter since otherwise the timing for long doubles is too variable. Also, rebuilding all the object files used with identical CFLAGS (usually -O -march=better-than-native). This probably makes my tests run 20-50 cycles per iteration faster (the simplest non-inline function takes 8 or 9 cycles and that takes running it in parallel with itself). > | Bruce | Steve > ------+--------------+-------------- > sinpi | 0.0742 (148) | 0.0633 (126) > cospi | 0.0720 (144) | 0.0513 (102) > > First number is microseconds per call and the (xxx) is the time*cpu_freq. The difference might be loop overhead or loss of parallelism. IIRC, you use something to serialize after every function. I have 4 variations and rarely use the serialization ones. Or thie difference might be more that the kernels are not inlined. I forgot to inline them too. I always rebuild the kernels for every test, so they get compiled with non-default CFLAGS, but they don't get inlined without #include statements. > As far as over-engineering, for sinpi I find > > sinpi Bruce kernel Steve kernel > MAX ULP: 0.73021263 0.73955815 > Total tested: 33554431 33554431 > 0.7 < ULP <= 0.8: 154 280 > 0.6 < ULP <= 0.7: 27650 29197 See, the kernels are already tuned almost as much as possible for accuracy/efficiency tradeoffs. > cospi is much more interesting and as you state above more > difficult to get right. I have reworked my kernel, yet, > but I find > > cospi Bruce kernel Steve kernel > MAX ULP: 0.78223389 0.89921787 > Total tested: 33554431 33554431 > 0.8 < ULP <= 0.9: 0 3262 > 0.7 < ULP <= 0.8: 9663 68305 > 0.6 < ULP <= 0.7: 132948 346214 > > Perhaps, using double_t would reduce my max ULP at the expense > of speed. On i386, it should reduce the error at the expense of slowness. On amd64, it makes no difference, but using long double should reduct the error at the expense of speed. Usually the reduction in the maximum error is only about 0.1 ulps unless the algorithm uses extra precision intentionally. This is available on i386, but is not large enough to compensate for the slowness. My example of log10*() unintentionally gave an example of using extra precision intentionally for efficiency. Here it is for log10(): XX double XX log10(double x) XX { XX struct Double r; XX double_t hi, lo; XX XX DOPRINT_START(&x); XX k_log(x, &r); XX if (!r.lo_set) XX RETURNP(r.hi); XX if (0 && sizeof(double_t) > sizeof(double)) XX RETURNP((invln10_lo + (double_t)invln10_hi) * (r.lo + r.hi)); This avoids the emulated extra-precision calculations of possible. This is under 'if (0)' since it is too hard to determine if extra precision is available. The sizeof() calculation doesn't tell you if it is. On i386, double_t is long double, but extra precision is not available under FreeBSD unless the program used fpsetprec(FP_PE) to change the default of double precision. This is not under 'if (0)' for float precision. Then it is assume that the program doesn't use fpsetprec(FP_PS) to change the default to float precision. XX _2sumF(r.hi, r.lo); XX hi = (float)r.hi; XX lo = r.lo + (r.hi - hi); XX RETURN2P(invln10_hi * hi, XX (invln10_lo + invln10_hi) * lo + invln10_lo * hi); XX } i386/i387, when used as designed, can execute this function much faster than SSE by not executing the lines beginning with _2sumF(). These lines take 20-40 cycles (latency) on modern SSE. Throughput is better. This would probably be a good optimization for amd64 too (using long double instead of double_t for the extra precision). The Intel ia64 math library uses this method of switching to extended precision often. ia64 has a better FP design. I don't know its details, but it seems to combine the best features of i387 and SSE. The FP registers should have extra precision as on i387, but the instructions should make it efficient to not use the extra precision for languages and programmers that don't want it. Bruce