From owner-freebsd-hackers@freebsd.org Sun Oct 8 03:42:31 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 EEE85E24B8E; Sun, 8 Oct 2017 03:42:31 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 18A4A6AF1B; Sun, 8 Oct 2017 03:42:30 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-a2dff70000001b86-e4-59d99d71dbca Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E9.3F.07046.17D99D95; Sat, 7 Oct 2017 23:37:21 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v983bKiX009792; Sat, 7 Oct 2017 23:37:21 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v983bHj4030520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Oct 2017 23:37:19 -0400 Date: Sat, 7 Oct 2017 22:37:17 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: Second Call for 2017Q3 quarterly status reports Message-ID: <20171008033717.GL96685@kduck.kaduk.org> References: <20170928142925.GG96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3U8TY7m7wOx7RL1F" Content-Disposition: inline In-Reply-To: <20170928142925.GG96685@kduck.kaduk.org> User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrVs492akwe17ehZz3nxgsti++R+j A5PHjE/zWQIYo7hsUlJzMstSi/TtErgyXs+8z1ZwTbRi4bb7bA2MJ4W6GDk5JARMJLYcOMfe xcjFISSwmEniwPX7LBDOBkaJaU+PsUE4V5gkmhduZQRpYRFQkTj7czaYzQZkN3RfZgaxRQTk JfY1vWcHsZmB7F9bm8BsYQELiSM7vrOC2LxA61Yu38gEYgsB2R+OP2GBiAtKnJwJYTMLlElM XHYaaD4HkC0tsfwfB0iYU8BU4v38R2AjRQWUJebtW8U2gVFgFpLuWUi6ZyF0Q4S1JG78e8mE IawtsWzha2YI21Zi3br3LAsY2VcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIE hT67i8oOxu4e70OMAhyMSjy8DzRuRgqxJpYVV+YeYpTkYFIS5RWdBRTiS8pPqcxILM6ILyrN SS0+xKgCtOvRhtUXGKVY8vLzUpVEeJnTgOp4UxIrq1KL8mHKpDlYlMR5twXtihQSSE8sSc1O TS1ILYLJynBwKEnw1s8BahQsSk1PrUjLzClBSDNxcB5ilODgARpeNxtkeHFBYm5xZjpE/hSj opQ471OQhABIIqM0D64XlLIksvfXvGIUB3pLmFcAZAUPMN3Bdb8CGswENJix+AbI4JJEhJRU AyOf+63w+pnOX0p5ihyTXpy8tOnuivSDO27LeCn/m+qXcitsgnTUHYN1+nWnXy5bzzrdTSTd M6i2NLX4tsm59AkerKUfrmx5Y7qpQ6E2yNlf38vy6TZ23Y2xTwWmb3tyev7uueY1p0sONGyc eS7YqWbLHa9wNfVY37+cvVGL+I/1200V2sORF6/EUpyRaKjFXFScCACNwlkONAMAAA== 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, 08 Oct 2017 03:42:32 -0000 --3U8TY7m7wOx7RL1F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Just a reminder: with the extended submission deadline for 2017Q3 entries, two weeks remain in the submission period. -Ben On Thu, Sep 28, 2017 at 09:29:25AM -0500, Benjamin Kaduk wrote: > Dear FreeBSD Community, >=20 > The deadline for the next FreeBSD Quarterly Status update is October 21, > 2017, for work done in July through September. >=20 > Status report submissions do not need to be very long. They may be about > anything happening in the FreeBSD project and community, and provide a gr= eat > way to inform FreeBSD users and developers about work that is underway and > completed. Submission of reports is not restricted to committers; anyone > doing anything interesting and FreeBSD related can -- and should -- write= one! >=20 > The preferred and easiest submission method is to use the XML generator [= 1] > with the results emailed to the status report team at monthly@FreeBSD.org= . > (Do be sure, though, to save the form output and not the form itself! In > particular, the Google Chrome "save as" function does not save the genera= ted > output for some reason.) There is also an XML template [2] that can be > filled out manually and attached if preferred. For the expected content > and style, please study our guidelines on how to write a good status > report [3]. You can also review previous issues [4][5] for ideas on the > style and format. >=20 > We look forward to seeing your 2017Q3 reports! >=20 > Thanks, >=20 > Ben (on behalf of monthly@) >=20 > [1] https://www.FreeBSD.org/cgi/monthly.cgi > [2] https://www.FreeBSD.org/news/status/report-sample.xml > [3] https://www.FreeBSD.org/news/status/howto.html > [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html > [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html >=20 >=20 --3U8TY7m7wOx7RL1F Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnZnWcACgkQKNmm82Tr dRK0bAwdH0aieF+hTINOeQpErQ7NKOK8HfFWntG2q20blTn3L1FK5d2qmCveOhdF kb3COT2J7Zo7NCfq1NME8zYiuhO2PmKENuaT2tfHaFEJcGWJ44nHfu2VVNzXAvaN HkF7RQlDdNTsuShO8bbULtNcH9aCfZHRknYHFOo2Z+6GpjMiL2p83K7n3GRHDgtC 5sqnRuzZF9tEAd8E3uNulscr2iN+6qluZUCTeA1Agd4q3xPjzOGqE01CK98jdVtf n33cd/3X2V+q7xf2SPTPRKcCoP2YhYYeSbxBgwbm3ao4gM7TDTXshtdnruIYwsNr wu3ocAP50frpUKZIcHNzGzIALFP6FUtM/lkxtRTEISXcv41UGvzwluy9wOCpLPNQ 8l0WWdJg/3/VK2E+9VGsJH94dqnRxvKoPpPUpzfxGApu5Cd3rAHV9Qe2t7kbETgF sqzyBn1649CMUaJ9JCdSYa61KQhBxARJq/I4hFUfS0pZGds280e/8FNAtW+y1mxE 2recASLoTKZncw== =s8ce -----END PGP SIGNATURE----- --3U8TY7m7wOx7RL1F-- From owner-freebsd-hackers@freebsd.org Sun Oct 8 07:52:57 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 6C3BFE2C052 for ; Sun, 8 Oct 2017 07:52:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC9C383948 for ; Sun, 8 Oct 2017 07:52:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1e16D6-000Fv2-6a; Sun, 08 Oct 2017 10:41:16 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: slow pxeboot on newer dell/optiplex From: Daniel Braniss In-Reply-To: <6284eb62-91cf-c4c9-78ff-347ec5318696@sentex.net> Date: Sun, 8 Oct 2017 10:41:16 +0300 Cc: Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <824EADB9-DF03-41A7-B6DA-F58AAAAA04B8@cs.huji.ac.il> References: <1536BD70-C292-4435-9DD4-0BA81A0B242B@cs.huji.ac.il> <494d3688-655a-92a2-2254-59b1494a82a0@sentex.net> <268D525C-F99B-434B-BB66-27DE95AC872F@cs.huji.ac.il> <6284eb62-91cf-c4c9-78ff-347ec5318696@sentex.net> To: Mike Tancsa 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: Sun, 08 Oct 2017 07:52:57 -0000 an upgrade to the bios fixed this! danny > On 31 Aug 2017, at 17:14, Mike Tancsa wrote: >=20 > On 8/31/2017 10:01 AM, Daniel Braniss wrote: >>=20 >> the thing is, after it boots, all is ok, so it=E2=80=99s something in = the pxe >> that pxeboot is in >> conflict with =E2=80=A6 > Yes, same here. Once the kernel is loaded, network throughput is = normal >=20 > ---Mike >=20 >=20 > --=20 > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-hackers@freebsd.org Sun Oct 8 11:34: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 46BA6E323DD for ; Sun, 8 Oct 2017 11:34:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 A588A6F815 for ; Sun, 8 Oct 2017 11:34:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11419 invoked from network); 8 Oct 2017 11:34:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 11:34:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 07:34:30 -0400 (EDT) Received: (qmail 17934 invoked from network); 8 Oct 2017 11:34:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 11:34:30 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BB325EC9220; Sun, 8 Oct 2017 04:34:29 -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 -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Message-Id: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> Date: Sun, 8 Oct 2017 04:34:29 -0700 To: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers 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: Sun, 08 Oct 2017 11:34:38 -0000 =46rom a dwarfdump's _Unwind_RaiseException information from a clang/clang++ 5 based compile: 91 DW_CFA_offset_extended r97 -496 (62 * -8) 94 DW_CFA_offset_extended r98 -480 (60 * -8) 97 DW_CFA_offset_extended r99 -464 (58 * -8) 100 DW_CFA_offset_extended r100 -448 (56 * -8) 103 DW_CFA_offset_extended r101 -432 (54 * -8) 106 DW_CFA_offset_extended r102 -416 (52 * -8) 109 DW_CFA_offset_extended r103 -400 (50 * -8) 112 DW_CFA_offset_extended r104 -384 (48 * -8) 115 DW_CFA_offset_extended r105 -368 (46 * -8) 118 DW_CFA_offset_extended r106 -352 (44 * -8) 121 DW_CFA_offset_extended r107 -336 (42 * -8) 124 DW_CFA_offset_extended r108 -320 (40 * -8) By contrast devel/powerpc64-gcc does not produce any of those. Is this lack of support of some part of an ABI? Is clang going outside the range of the intended ABI? Does FreeBSD's libgcc_s design and implementation handle these additional logical registers? (I've no clue what the logical registers r97-r108 are supposed to match up with in powerpc64 terms.) Supporting notes: r46-r63 are for floating point registers (that have been around for a long time: older powerpc family members). r70 is for having/using the value from "mfcr". r2(?)-r6 are scratch for C++ exception handling. (I originally identified r3-r6. r2 might have a somewhat distinct status?) r14-r31 are for the normal r14 through r31 registers. r65 is standard and heavily used on all(?) routines, not just some libgcc_s ones. (So r65 is not listed below.) In libgcc_s.so.1.full (via powerpc64-gcc): uw_update_context_1: r70 _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_RaiseException_Phase2: (nothing special matched) _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 __deregister_frame_info_bases: r70 _Unwind_Find_FDE: r70 In libgcc_s.so.1.full (via clang): uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_RaiseException_Phase2: r70 _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] __deregister_frame_info_bases: (nothing special matched) _Unwind_Find_FDE: (nothing special matched) clang is missing all the r[2-6] references but the code generated does have the registers in use. Thrown C++ exceptions crash because of the lack of the r2-r6's, dying on a r3 attempt. I have no clue yet what r9[7-9],r10[0-8] are for. _Unwind_Backtrace suggests that none of them are alternate names for scratch registers r[2-6]. I have no clue why _Unwind_RaiseException_Phase2 has a r70 for clang but not for powerpc64-gcc. Or the other way around for __deregister_frame_info_bases and _Unwind_Find_FDE. Which file's implementations are used from what I can tell : uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) An implication is that GPL Version 2 source code is involved even when clang is the system compiler. Is that what FreeBSD intends for the powerpc families? /* Exception handling and frame unwind runtime interface routines. -*- C = -*- Copyright (C) 2001, 2003 Free Software Foundation, Inc. This file is part of GCC. GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combined executable.) . . . Does libgcc_s.so.1 with its type of use form a "combined executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Oct 8 13:34: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 B4C05E35BDE for ; Sun, 8 Oct 2017 13:34:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 387C96977D for ; Sun, 8 Oct 2017 13:34:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21611 invoked from network); 8 Oct 2017 13:34:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 13:34:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 09:34:47 -0400 (EDT) Received: (qmail 19223 invoked from network); 8 Oct 2017 13:34:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 13:34:46 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9E437EC8B8D; Sun, 8 Oct 2017 06:34: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: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 06:34:44 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers In-Reply-To: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> Message-Id: <1098914B-6BA2-419D-B8FB-01AB71C3DC29@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: Sun, 08 Oct 2017 13:34:49 -0000 [Looks like r97-r108 are for vr20-vr31 (AltiVec Registers).] On 2017-Oct-8, at 4:34 AM, Mark Millard wrote: > =46rom a dwarfdump's _Unwind_RaiseException information > from a clang/clang++ 5 based compile: >=20 > 91 DW_CFA_offset_extended r97 -496 (62 * -8) > 94 DW_CFA_offset_extended r98 -480 (60 * -8) > 97 DW_CFA_offset_extended r99 -464 (58 * -8) > 100 DW_CFA_offset_extended r100 -448 (56 * -8) > 103 DW_CFA_offset_extended r101 -432 (54 * -8) > 106 DW_CFA_offset_extended r102 -416 (52 * -8) > 109 DW_CFA_offset_extended r103 -400 (50 * -8) > 112 DW_CFA_offset_extended r104 -384 (48 * -8) > 115 DW_CFA_offset_extended r105 -368 (46 * -8) > 118 DW_CFA_offset_extended r106 -352 (44 * -8) > 121 DW_CFA_offset_extended r107 -336 (42 * -8) > 124 DW_CFA_offset_extended r108 -320 (40 * -8) >=20 > By contrast devel/powerpc64-gcc does not produce any > of those. Is this lack of support of some part of an > ABI? Is clang going outside the range of the intended > ABI? ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates that r97-r108 are for vr20-vr31 (AltiVec Registers). [Is AltiVec optional --possibly missing?] So the questions translate into questions about AltiVec support/handling for C++ exceptions. [Note: R70 is supposed to be specific to CR2.] > Does FreeBSD's libgcc_s design and implementation handle > these additional logical registers? . . . So the libgcc_s question traces back to: does it handle AltiVec Registers vr20-vr31 if they are referenced (clang)? Is it well behaved if r97-r108 are not referenced (powerpc64-gcc)? > Supporting notes: >=20 > r46-r63 are for floating point registers (that > have been around for a long time: older > powerpc family members). r46-r63 are for f14-f31. > r70 is for having/using the value from "mfcr". Apparently r70 is supposed to be specific to CR2. > r2(?)-r6 are scratch for C++ exception handling. > (I originally identified r3-r6. r2 might have a > somewhat distinct status?) In normal functions r2-r6 do not get DW_CFA_offset_extended_sf or DW_CFA_offset entries. They are special to some internal exception handling routines. (See later.) > r14-r31 are for the normal r14 through r31 > registers. r97-r108 are for AltiVec Registers vr20-vr31. > r65 is standard and heavily used on all(?) > routines, not just some libgcc_s ones. (So > r65 is not listed below.) r65 for lr. > In libgcc_s.so.1.full (via powerpc64-gcc): >=20 > uw_update_context_1: r70 > _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_RaiseException_Phase2: (nothing special matched) > _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 > _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 > __deregister_frame_info_bases: r70 > _Unwind_Find_FDE: r70 So no AltiVec Registers listed. > In libgcc_s.so.1.full (via clang): >=20 > uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) > _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_RaiseException_Phase2: r70 > _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] > __deregister_frame_info_bases: (nothing special matched) > _Unwind_Find_FDE: (nothing special matched) So no internal, special-for-excpetion-routines scratch register usage listed (r2-r6). > clang is missing all the r[2-6] references but > the code generated does have the registers in > use. Thrown C++ exceptions crash because of > the lack of the r2-r6's, dying on a r3 attempt. >=20 . . . >=20 > I have no clue why _Unwind_RaiseException_Phase2 > has a r70 for clang but not for powerpc64-gcc. > Or the other way around for __deregister_frame_info_bases > and _Unwind_Find_FDE. >=20 > Which file's implementations are used from > what I can tell : >=20 > uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c > _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc > _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc > _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc > _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc > _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc > _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc > __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c > _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) >=20 > An implication is that GPL Version 2 source code > is involved even when clang is the system compiler. > Is that what FreeBSD intends for the powerpc > families? >=20 > /* Exception handling and frame unwind runtime interface routines. -*- = C -*- > Copyright (C) 2001, 2003 Free Software Foundation, Inc. >=20 > This file is part of GCC. >=20 > GCC is free software; you can redistribute it and/or modify it > under the terms of the GNU General Public License as published by > the Free Software Foundation; either version 2, or (at your option) > any later version. >=20 > In addition to the permissions in the GNU General Public License, = the > Free Software Foundation gives you unlimited permission to link the > compiled version of this file into combinations with other programs, > and to distribute those combinations without any restriction coming > from the use of this file. (The General Public License restrictions > do apply in other respects; for example, they cover modification of > the file, and distribution when not linked into a combined > executable.) >=20 > . . . >=20 > Does libgcc_s.so.1 with its type of use form a "combined executable"? >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Oct 8 21:24:12 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 2C7FDE40768 for ; Sun, 8 Oct 2017 21:24:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 3377E6F4B6 for ; Sun, 8 Oct 2017 21:24:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29870 invoked from network); 8 Oct 2017 21:24:09 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 21:24:09 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 17:24:09 -0400 (EDT) Received: (qmail 6810 invoked from network); 8 Oct 2017 21:24:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 21:24:08 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1AD7DEC952A; Sun, 8 Oct 2017 14:24:08 -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: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 14:24:07 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers , Justin Hibbits , Nathan Whitehorn In-Reply-To: <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> Message-Id: 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: Sun, 08 Oct 2017 21:24:12 -0000 Quick top note: clang 5 does generate code sequences with AltiVec stvx and lvx instructions where r97-r108 are listed but powerpc64-gcc is not doing so in those same sorts of places. This appears to be a ABI variation across toolchains to me, unless such is fully optional in the ABI somehow. On 2017-Oct-8, at 6:34 AM, Mark Millard wrote: > [Looks like r97-r108 are for vr20-vr31 (AltiVec > Registers).] >=20 > On 2017-Oct-8, at 4:34 AM, Mark Millard = wrote: >=20 >> =46rom a dwarfdump's _Unwind_RaiseException information >> from a clang/clang++ 5 based compile: >>=20 >> 91 DW_CFA_offset_extended r97 -496 (62 * -8) >> 94 DW_CFA_offset_extended r98 -480 (60 * -8) >> 97 DW_CFA_offset_extended r99 -464 (58 * -8) >> 100 DW_CFA_offset_extended r100 -448 (56 * -8) >> 103 DW_CFA_offset_extended r101 -432 (54 * -8) >> 106 DW_CFA_offset_extended r102 -416 (52 * -8) >> 109 DW_CFA_offset_extended r103 -400 (50 * -8) >> 112 DW_CFA_offset_extended r104 -384 (48 * -8) >> 115 DW_CFA_offset_extended r105 -368 (46 * -8) >> 118 DW_CFA_offset_extended r106 -352 (44 * -8) >> 121 DW_CFA_offset_extended r107 -336 (42 * -8) >> 124 DW_CFA_offset_extended r108 -320 (40 * -8) >>=20 >> By contrast devel/powerpc64-gcc does not produce any >> of those. Is this lack of support of some part of an >> ABI? Is clang going outside the range of the intended >> ABI? >=20 > ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates > that r97-r108 are for vr20-vr31 (AltiVec Registers). > [Is AltiVec optional --possibly missing?] >=20 > So the questions translate into questions about > AltiVec support/handling for C++ exceptions. >=20 > [Note: R70 is supposed to be specific to CR2.] >=20 >> Does FreeBSD's libgcc_s design and implementation handle >> these additional logical registers? > . . . >=20 > So the libgcc_s question traces back to: does it > handle AltiVec Registers vr20-vr31 if they are > referenced (clang)? Is it well behaved if r97-r108 > are not referenced (powerpc64-gcc)? >=20 >> Supporting notes: >>=20 >> r46-r63 are for floating point registers (that >> have been around for a long time: older >> powerpc family members). >=20 > r46-r63 are for f14-f31. >=20 >> r70 is for having/using the value from "mfcr". >=20 > Apparently r70 is supposed to be specific to CR2. >=20 >> r2(?)-r6 are scratch for C++ exception handling. >> (I originally identified r3-r6. r2 might have a >> somewhat distinct status?) >=20 > In normal functions r2-r6 do not get > DW_CFA_offset_extended_sf or > DW_CFA_offset entries. They are special > to some internal exception handling > routines. (See later.) >=20 >> r14-r31 are for the normal r14 through r31 >> registers. >=20 > r97-r108 are for AltiVec Registers vr20-vr31. >=20 >> r65 is standard and heavily used on all(?) >> routines, not just some libgcc_s ones. (So >> r65 is not listed below.) >=20 > r65 for lr. >=20 >> In libgcc_s.so.1.full (via powerpc64-gcc): >>=20 >> uw_update_context_1: r70 >> _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_RaiseException_Phase2: (nothing special matched) >> _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >> _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 >> __deregister_frame_info_bases: r70 >> _Unwind_Find_FDE: r70 >=20 > So no AltiVec Registers listed. >=20 >> In libgcc_s.so.1.full (via clang): >>=20 >> uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) >> _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_RaiseException_Phase2: r70 >> _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >> __deregister_frame_info_bases: (nothing special matched) >> _Unwind_Find_FDE: (nothing special matched) >=20 > So no internal, special-for-excpetion-routines > scratch register usage listed (r2-r6). >=20 >> clang is missing all the r[2-6] references but >> the code generated does have the registers in >> use. Thrown C++ exceptions crash because of >> the lack of the r2-r6's, dying on a r3 attempt. >>=20 > . . . >>=20 >> I have no clue why _Unwind_RaiseException_Phase2 >> has a r70 for clang but not for powerpc64-gcc. >> Or the other way around for __deregister_frame_info_bases >> and _Unwind_Find_FDE. >>=20 >> Which file's implementations are used from >> what I can tell : >>=20 >> uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c >> _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc >> _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc >> _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc >> _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc >> __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c >> _Unwind_Find_FDE: /usr/src/contrib/gcc/unwind-dw2-fde*.c = (unsure) >>=20 >> An implication is that GPL Version 2 source code >> is involved even when clang is the system compiler. >> Is that what FreeBSD intends for the powerpc >> families? >>=20 >> /* Exception handling and frame unwind runtime interface routines. = -*- C -*- >> Copyright (C) 2001, 2003 Free Software Foundation, Inc. >>=20 >> This file is part of GCC. >>=20 >> GCC is free software; you can redistribute it and/or modify it >> under the terms of the GNU General Public License as published by >> the Free Software Foundation; either version 2, or (at your option) >> any later version. >>=20 >> In addition to the permissions in the GNU General Public License, = the >> Free Software Foundation gives you unlimited permission to link the >> compiled version of this file into combinations with other programs, >> and to distribute those combinations without any restriction coming >> from the use of this file. (The General Public License restrictions >> do apply in other respects; for example, they cover modification of >> the file, and distribution when not linked into a combined >> executable.) >>=20 >> . . . >>=20 >> Does libgcc_s.so.1 with its type of use form a "combined executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Sun Oct 8 23:06:20 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 25CDAE422A0 for ; Sun, 8 Oct 2017 23:06:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (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 96B7C64337 for ; Sun, 8 Oct 2017 23:06:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23750 invoked from network); 8 Oct 2017 23:06:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 23:06:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 19:06:17 -0400 (EDT) Received: (qmail 5584 invoked from network); 8 Oct 2017 23:06:17 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 23:06:17 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 84A37EC7D4D; Sun, 8 Oct 2017 16:06:16 -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: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .) Date: Sun, 8 Oct 2017 16:06:15 -0700 References: <6FEAEDA2-6036-4FC0-B794-15BC264BD31D@dsl-only.net> <1098914B-6BA2-419D-B8FB-01AB71C3DC29@dsl-only.net> To: Roman Divacky , FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-hackers , Justin Hibbits , Nathan Whitehorn , Warner Losh In-Reply-To: Message-Id: 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: Sun, 08 Oct 2017 23:06:20 -0000 Another ABI variation/violation. I top post them because it is largely separate from the AltiVec Registers issue and is probably more important. Summary: Lack of r2-r6 save/restore (and so its matching DW_CFA_ material) so lack of places for the like of _Unwind_SetGR to work with. More detail: Beyond the AltiVec Registers issue it turns out that for: _Unwind_RaiseException _Unwind_ForcedUnwind _Unwind_Resume _Unwind_Resume_or_Rethrow the code generation from clang 5 for them does not save/restore the ABI's "scratch registers" involved in the exception handling: r2-r6. But they are in the code from powerpc64-gcc. In FreeBSD's libgcc_s.so.1 and libcxxrt.so.1 terms: This means that _Unwind_SetGR and _Unwind_GetGR have no place to set or access the value of the r2-r6 GR in question. It currently crashes as the first attempt, which happens to be for setting r3 (as a scratch value). This in turn prevents __gxx_personality_v0 from working. That in turn prevents throwing exceptions from working. Without the code generation, it makes sense to not have the DW_CFA_'s as well. The code generation (or lack of it) is a bigger deal. It appears that in this area clang 5 simply does not currently match the ABI that powerpc64-gcc is generating code for and that FreeBSD's libgcc_s.so.1 and libcxxrt.so.1 are designed for. That is why throwing a C++ exception gets the failure at: Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc70) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc70) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D terms): In libgcc_s.so.1.full (via clang): uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_RaiseException_Phase2: r70 _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] __deregister_frame_info_bases: (nothing special matched) _Unwind_Find_FDE: (nothing special matched) By contrast for powerpc64-gcc: In libgcc_s.so.1.full (via powerpc64-gcc): uw_update_context_1: r70 _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_RaiseException_Phase2: (nothing special matched) _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 __deregister_frame_info_bases: r70 _Unwind_Find_FDE: r70 On 2017-Oct-8, at 2:24 PM, Mark Millard wrote: > Quick top note: clang 5 does generate code sequences > with AltiVec stvx and lvx instructions where r97-r108 > are listed but powerpc64-gcc is not doing so in those > same sorts of places. This appears to be a ABI > variation across toolchains to me, unless such is > fully optional in the ABI somehow. >=20 > On 2017-Oct-8, at 6:34 AM, Mark Millard = wrote: >=20 >> [Looks like r97-r108 are for vr20-vr31 (AltiVec >> Registers).] >>=20 >> On 2017-Oct-8, at 4:34 AM, Mark Millard = wrote: >>=20 >>> =46rom a dwarfdump's _Unwind_RaiseException information >>> from a clang/clang++ 5 based compile: >>>=20 >>> 91 DW_CFA_offset_extended r97 -496 (62 * -8) >>> 94 DW_CFA_offset_extended r98 -480 (60 * -8) >>> 97 DW_CFA_offset_extended r99 -464 (58 * -8) >>> 100 DW_CFA_offset_extended r100 -448 (56 * -8) >>> 103 DW_CFA_offset_extended r101 -432 (54 * -8) >>> 106 DW_CFA_offset_extended r102 -416 (52 * -8) >>> 109 DW_CFA_offset_extended r103 -400 (50 * -8) >>> 112 DW_CFA_offset_extended r104 -384 (48 * -8) >>> 115 DW_CFA_offset_extended r105 -368 (46 * -8) >>> 118 DW_CFA_offset_extended r106 -352 (44 * -8) >>> 121 DW_CFA_offset_extended r107 -336 (42 * -8) >>> 124 DW_CFA_offset_extended r108 -320 (40 * -8) >>>=20 >>> By contrast devel/powerpc64-gcc does not produce any >>> of those. Is this lack of support of some part of an >>> ABI? Is clang going outside the range of the intended >>> ABI? >>=20 >> ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates >> that r97-r108 are for vr20-vr31 (AltiVec Registers). >> [Is AltiVec optional --possibly missing?] >>=20 >> So the questions translate into questions about >> AltiVec support/handling for C++ exceptions. >>=20 >> [Note: R70 is supposed to be specific to CR2.] >>=20 >>> Does FreeBSD's libgcc_s design and implementation handle >>> these additional logical registers? >> . . . >>=20 >> So the libgcc_s question traces back to: does it >> handle AltiVec Registers vr20-vr31 if they are >> referenced (clang)? Is it well behaved if r97-r108 >> are not referenced (powerpc64-gcc)? >>=20 >>> Supporting notes: >>>=20 >>> r46-r63 are for floating point registers (that >>> have been around for a long time: older >>> powerpc family members). >>=20 >> r46-r63 are for f14-f31. >>=20 >>> r70 is for having/using the value from "mfcr". >>=20 >> Apparently r70 is supposed to be specific to CR2. >>=20 >>> r2(?)-r6 are scratch for C++ exception handling. >>> (I originally identified r3-r6. r2 might have a >>> somewhat distinct status?) >>=20 >> In normal functions r2-r6 do not get >> DW_CFA_offset_extended_sf or >> DW_CFA_offset entries. They are special >> to some internal exception handling >> routines. (See later.) >>=20 >>> r14-r31 are for the normal r14 through r31 >>> registers. >>=20 >> r97-r108 are for AltiVec Registers vr20-vr31. >>=20 >>> r65 is standard and heavily used on all(?) >>> routines, not just some libgcc_s ones. (So >>> r65 is not listed below.) >>=20 >> r65 for lr. >>=20 >>> In libgcc_s.so.1.full (via powerpc64-gcc): >>>=20 >>> uw_update_context_1: r70 >>> _Unwind_RaiseException: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_RaiseException_Phase2: (nothing special matched) >>> _Unwind_ForcedUnwind: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Resume: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Resume_or_Rethrow: r[2-6],r4[6-9],r5[0-9],r6[0-3],r70 >>> _Unwind_Backtrace: r4[6-9],r5[0-9],r6[0-3],r70 >>> __deregister_frame_info_bases: r70 >>> _Unwind_Find_FDE: r70 >>=20 >> So no AltiVec Registers listed. >>=20 >>> In libgcc_s.so.1.full (via clang): >>>=20 >>> uw_update_context_1: r70 (uw_update_context_1 was actually = later in the file) >>> _Unwind_RaiseException: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_RaiseException_Phase2: r70 >>> _Unwind_ForcedUnwind: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Resume: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Resume_or_Rethrow: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> _Unwind_Backtrace: = r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8] >>> __deregister_frame_info_bases: (nothing special matched) >>> _Unwind_Find_FDE: (nothing special matched) >>=20 >> So no internal, special-for-excpetion-routines >> scratch register usage listed (r2-r6). >>=20 >>> clang is missing all the r[2-6] references but >>> the code generated does have the registers in >>> use. Thrown C++ exceptions crash because of >>> the lack of the r2-r6's, dying on a r3 attempt. >>>=20 >> . . . >>>=20 >>> I have no clue why _Unwind_RaiseException_Phase2 >>> has a r70 for clang but not for powerpc64-gcc. >>> Or the other way around for __deregister_frame_info_bases >>> and _Unwind_Find_FDE. >>>=20 >>> Which file's implementations are used from >>> what I can tell : >>>=20 >>> uw_update_context_1: /usr/src/contrib/gcc/unwind-dw2.c >>> _Unwind_RaiseException: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_ForcedUnwind: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Resume: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Resume_or_Rethrow: /usr/src/contrib/gcc/unwind.inc >>> _Unwind_Backtrace: /usr/src/contrib/gcc/unwind.inc >>> __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c >>> _Unwind_Find_FDE: = /usr/src/contrib/gcc/unwind-dw2-fde*.c (unsure) >>>=20 >>> An implication is that GPL Version 2 source code >>> is involved even when clang is the system compiler. >>> Is that what FreeBSD intends for the powerpc >>> families? >>>=20 >>> /* Exception handling and frame unwind runtime interface routines. = -*- C -*- >>> Copyright (C) 2001, 2003 Free Software Foundation, Inc. >>>=20 >>> This file is part of GCC. >>>=20 >>> GCC is free software; you can redistribute it and/or modify it >>> under the terms of the GNU General Public License as published by >>> the Free Software Foundation; either version 2, or (at your option) >>> any later version. >>>=20 >>> In addition to the permissions in the GNU General Public License, = the >>> Free Software Foundation gives you unlimited permission to link the >>> compiled version of this file into combinations with other programs, >>> and to distribute those combinations without any restriction coming >>> from the use of this file. (The General Public License restrictions >>> do apply in other respects; for example, they cover modification of >>> the file, and distribution when not linked into a combined >>> executable.) >>>=20 >>> . . . >>>=20 >>> Does libgcc_s.so.1 with its type of use form a "combined = executable"? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-hackers@freebsd.org Mon Oct 9 00:35: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 C797FE440BF for ; Mon, 9 Oct 2017 00:35:21 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 46A6577E2B for ; Mon, 9 Oct 2017 00:35:21 +0000 (UTC) (envelope-from artemb@gmail.com) Received: by mail-pf0-x22c.google.com with SMTP id n14so10247895pfh.8 for ; Sun, 08 Oct 2017 17:35:21 -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=mjfhSa9hz4uriiOReunW3z9EK52SmwCwKVHKvVgFN9g=; b=uSwFKgA3J/RrNN+IKRCwxknG/oYaQGQVKBjm/IFISSexZxsozKRw0n6e6lQmrgAsRn /mdZyhmb8Et5hFsjLGG0ZS6titrgdkNtcJMv4xX/914Fn4ee8UggHuEYDeXUfGv7go6F pDnWJ1Gp9VqTU7btd3SqHibfUAVFEpwlZot4Y2herM8cD5WL4P1q+0SJB5JXUf9vmUBt nTnlHDkTXmBfGYDUMNGzK/5LKbBHucKg7msEnF8cWe/iQH1GIe7uHAL+7wwLWb12nkqm nYotabVxvjV4H6KtHPnvTtpOd40FZoEnnR5lwUcyKgOYp8bUCHg7Cnit8+PH3Iy2d80L u3mA== 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=mjfhSa9hz4uriiOReunW3z9EK52SmwCwKVHKvVgFN9g=; b=M/5vLXX1EOl2pFDj15KsExy4j25ggYiA4MEy4NMnOb0XBYn3mMz+Dr3j4dc0p8Lf1I UNp5zk5Mc9yWL3Jm7Y9MDfrka5T3OlJVUjKcCjcckC9zahMVmTsGHgQVvD/lIpBZ0sbC q+BM5zziWKb/n5yEmjSjT9JZ4+Lt4kdpRyBaJYos00LxQDOYDp7zRr9YNoZfI7A2cC6L BVvmC05lp97oBY72NsKI6rnI39ozPmxTKVsnNROU7KFF5+dd6PRBE9REPwvjH1uwljW6 dv6GyqO530Nyk+iqtjzvqYWwjlR1+AooaatFUUl0DEasdr/sWmne7x9Z/LZkYD7ThgHN bP6w== X-Gm-Message-State: AMCzsaXHx7ZvUmbmwgg4lsg1aQnXQdzHiucRfN4q9ZiwRYVEcY5mDiuw B8W8lWLDCbl/R9ovgLhJPHM284uTilp9oV2bdWtnuw== X-Google-Smtp-Source: AOwi7QDZhaePkmRJMc9nrlvFLbsJ7Xhu8/j9x5dYIG6TduuohPYXqGU4MMIzx9+JZIuyz+UAYdYZdMt5zRG11acvBcE= X-Received: by 10.84.194.3 with SMTP id g3mr7879062pld.246.1507509320525; Sun, 08 Oct 2017 17:35:20 -0700 (PDT) MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.100.192.14 with HTTP; Sun, 8 Oct 2017 17:35:19 -0700 (PDT) In-Reply-To: References: <65001830-5520-cd20-fd71-130d28c7aadf@bsd.com.br> From: Artem Belevich Date: Sun, 8 Oct 2017 17:35:19 -0700 X-Google-Sender-Auth: 7sR6Xq0XRU5CuzYBSSOgJshlAwo Message-ID: Subject: Fwd: CUDA and FreeBSD To: =?UTF-8?B?T3RhY8OtbGlv?= Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, 09 Oct 2017 00:35:22 -0000 Your question is rather vague. Could you elaborate on what exactly you have in mind? Last time I checked, linux CUDA programs did run under linuxulator. It's been a while, though. Getting native CUDA binaries to compiler/run on FreeBSD is somewhat more complicated. CUDA SDK does not support freebsd, so you can't use nvcc to compile any CUDA binaries on FreeBSD. Recent Clang (~5.0 or newer) is capable of compiling CUDA programs, so getting it to compile CUDA source to an object file on FreeBSD should not be particularly hard. However, you would not be able to link anything that relies on standard CUDA features (e.g. using foo<<<..>>>() syntax to launch a kernel or using many cudaXXXX() calls) as they depend on libcudart and NVidia does not provide it for FreeBSD. You would need to write your own replacement for the CUDA runtime which would use raw driver API under the hood. It's somewhat complicated by the fact that the API provided by libcudart for compiler use is largely undocumented. You also can't use cuBLAS, cuFFT, cuDNN, etc, because NVidia does not provide those for FreeBSD, either. :-( That rules FreeBSD out for things like GPU support in Tensorflow. --Artem On Wed, Oct 4, 2017 at 5:41 AM, Otac=C3=ADlio wr= ote: > What are the issues that prevent programs using CUDA from running on > FreeBSD? > > []'s > > -Otacilio > > _______________________________________________ > 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 Mon Oct 9 14:50: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 78662E3247D for ; Mon, 9 Oct 2017 14:50:45 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 2022E6FDF9 for ; Mon, 9 Oct 2017 14:50:45 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x230.google.com with SMTP id z50so38531576qtj.4 for ; Mon, 09 Oct 2017 07:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=/TYPKQQCJ7heJrrkXriKeiIU4pPgjKixl8TxOyy+bbg=; b=TcTrznyJW6q2hg9va37I1LrLWysoAvW6X1nWTG4kOY6jQnWE2X4/hnpBboBHDRbhM2 xe0rLZykBHNqbfxdoWGGqFQ+TyzROjKLrdg4tL6AFoC0QHKToNj+uwWBcGIj5TTAy89u 18KC3zUm7gooFVNqxfu0xwZRBC0j3BQlPFITk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/TYPKQQCJ7heJrrkXriKeiIU4pPgjKixl8TxOyy+bbg=; b=O8c6hyYJYPsq6UWRt+tmC44MZoqVJ9znUQ89hn6MF1ZSo++wyJ8tgY5IMGgXVdmLUH j221G554uDeKSN3lvoZkW2jyxnRvWheA1gDtLrk96rwUugdoXuwRBXF1bJP4bBEC0lL5 GuymzJv6bzk+Q7WuGw2IWw0GEudiSFQYOOcEIET83N4vjrA2AkFhMnBbobKroowTwVvn QyRbubd5g8MYGNOe5fh2+MnJKHBQx2R7ShIogvJNlejmvmUrODGgoj395ZdQY4UquUjl WWiFyn38c3QtqaipV9nzWvffPvdyF3+qGLHqIrrPDYAZlBVunQvXerYB0+j47mRaaEcN Mvbg== X-Gm-Message-State: AMCzsaU+OAkMZVW0COI7twrHmpX7FmG/2zLTY7LEuA439tahkF5MM3Rz O4xuA31RbmWHWBixC4E/uuZnfWXVhXo= X-Google-Smtp-Source: AOwi7QDTo4a5h5f8NLTxKnnRymTp96PLbfGJIvV3DE6CND5JMJ0mf85uVzYHNFpe7Z4vZn5qnB+qrA== X-Received: by 10.237.60.50 with SMTP id t47mr15643518qte.49.1507560643708; Mon, 09 Oct 2017 07:50:43 -0700 (PDT) Received: from ?IPv6:2804:54:19ef:cc00:c0c5:44f7:3ce:1e03? ([2804:54:19ef:cc00:c0c5:44f7:3ce:1e03]) by smtp.gmail.com with ESMTPSA id q2sm1733485qtf.78.2017.10.09.07.50.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 07:50:42 -0700 (PDT) Subject: Re: Fwd: CUDA and FreeBSD To: Artem Belevich Cc: FreeBSD Hackers References: <65001830-5520-cd20-fd71-130d28c7aadf@bsd.com.br> From: Otacilio Message-ID: <27144872-11f5-26ba-4967-dd5350ba54a6@bsd.com.br> Date: Mon, 9 Oct 2017 11:50:38 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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, 09 Oct 2017 14:50:45 -0000 Em 08/10/2017 21:35, Artem Belevich escreveu: > Your question is rather vague. Could you elaborate on what exactly you > have in mind? > > Last time I checked, linux CUDA programs did run under linuxulator. > It's been a while, though. > > Getting native CUDA binaries to compiler/run on FreeBSD is somewhat > more complicated. > CUDA SDK does not support freebsd, so you can't use nvcc to compile > any CUDA binaries on FreeBSD. > Recent Clang (~5.0 or newer) is capable of compiling CUDA programs, so > getting it to compile CUDA source to an object file on FreeBSD should > not be particularly hard. However, you would not be able to link > anything that relies on standard CUDA features (e.g. using > foo<<<..>>>() syntax to launch a kernel or using many cudaXXXX() > calls) as they depend on libcudart and NVidia does not provide it for > FreeBSD. You would need to write your own replacement for the CUDA > runtime which would use raw driver API under the hood. It's somewhat > complicated by the fact that the API provided by libcudart for > compiler use is largely undocumented. > > You also can't use cuBLAS, cuFFT, cuDNN, etc, because NVidia does not > provide those for FreeBSD, either. :-( That rules FreeBSD out for > things like GPU support in Tensorflow. > > --Artem > > On Wed, Oct 4, 2017 at 5:41 AM, Otacílio > wrote: > > What are the issues that prevent programs using CUDA from running > on FreeBSD? > > []'s > > -Otacilio > Thank you so much for your answer. It was just this overview I was looking for. []'s -Otacilio From owner-freebsd-hackers@freebsd.org Tue Oct 10 04:23:41 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 6950FE481C1 for ; Tue, 10 Oct 2017 04:23:41 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vulpes.vvelox.net (vulpes.vvelox.net [96.95.67.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5019E6A86F for ; Tue, 10 Oct 2017 04:23:41 +0000 (UTC) (envelope-from v.velox@vvelox.net) Received: from vvelox.net (localhost [127.0.0.1]) (Authenticated sender: kitsune) by vulpes.vvelox.net (Postfix) with ESMTPA id 470E9224A64F for ; Mon, 9 Oct 2017 23:16:16 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 09 Oct 2017 23:16:16 -0500 From: "Zane C. B-H." To: freebsd-hackers@freebsd.org Subject: using pctcpu Message-ID: X-Sender: v.velox@vvelox.net User-Agent: Roundcube Webmail/1.3-beta 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, 10 Oct 2017 04:23:41 -0000 Using https://metacpan.org/pod/BSD::Process that to get pctcpu, but I can't get it to line up nicely with ps. The closest I can get is dividing pctcpu by 20, but that still tends to run high. For example dividing by 20 will give me 1635.8 while ps will show 1595.3. I know the 1635.8 is definitely off as this machine only has 16 cores. From owner-freebsd-hackers@freebsd.org Wed Oct 11 07:12:02 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 CA144E48A28 for ; Wed, 11 Oct 2017 07:12:02 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.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 80F1981686; Wed, 11 Oct 2017 07:12:02 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1e2AoW-0005Cr-8f; Wed, 11 Oct 2017 08:48:20 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e2AoW-0004LY-1p; Wed, 11 Oct 2017 08:48:20 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 280582A1677; Wed, 11 Oct 2017 08:48:16 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9yCQWP30E97y; Wed, 11 Oct 2017 08:48:16 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id E74D72A1678; Wed, 11 Oct 2017 08:48:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qunlG6H5OPMi; Wed, 11 Oct 2017 08:48:15 +0200 (CEST) Received: from linux-diu0.suse (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id C2B7D2A1677; Wed, 11 Oct 2017 08:48:15 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: kib@freebsd.org Subject: [PATCH] Simplify th_bintime update in tc_windup() Date: Wed, 11 Oct 2017 08:48:16 +0200 Message-Id: <20171011064816.20809-1-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 2.12.3 X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23935/Wed Oct 11 06:02:35 2017) 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, 11 Oct 2017 07:12:02 -0000 The th_bintime, th_microtime and th_nanotime members of the timehand all cache the last system time (uptime + boottime). Only the format differs. Do not re-calculate the bintime and simply use the value used to calculate the microtime and nanotime. Group all the updates under the relevant comment. Is the "XXX shouldn't do this here. Should force non-`get' versions." part of the comment still valid? --- sys/kern/kern_tc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 088fcb41cfa..e7cfc51aff7 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -1413,10 +1413,9 @@ tc_windup(struct bintime *new_boottimebin) if (bt.sec != t) th->th_boottime.sec += bt.sec - t; } - th->th_bintime = th->th_offset; - bintime_add(&th->th_bintime, &th->th_boottime); /* Update the UTC timestamps used by the get*() functions. */ /* XXX shouldn't do this here. Should force non-`get' versions. */ + th->th_bintime = bt; bintime2timeval(&bt, &th->th_microtime); bintime2timespec(&bt, &th->th_nanotime); -- 2.12.3 From owner-freebsd-hackers@freebsd.org Wed Oct 11 09:31: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 D6B0FE2643B for ; Wed, 11 Oct 2017 09:31:21 +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 559301398 for ; Wed, 11 Oct 2017 09:31:21 +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 v9B9V1k5001956 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Oct 2017 12:31:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9B9V1k5001956 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9B9V10N001955; Wed, 11 Oct 2017 12:31:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Oct 2017 12:31:01 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Simplify th_bintime update in tc_windup() Message-ID: <20171011093101.GX95911@kib.kiev.ua> References: <20171011064816.20809-1-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171011064816.20809-1-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.9.1 (2017-09-22) 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: Wed, 11 Oct 2017 09:31:21 -0000 On Wed, Oct 11, 2017 at 08:48:16AM +0200, Sebastian Huber wrote: > The th_bintime, th_microtime and th_nanotime members of the timehand all > cache the last system time (uptime + boottime). Only the format > differs. Do not re-calculate the bintime and simply use the value used > to calculate the microtime and nanotime. > > Group all the updates under the relevant comment. th->th_bintime is recalculated after possible adjustments made by the ntp loop to the th_boottime. But your patch makes me consider the two lines after the XXX comment. Shouldn't we use the updated th_bintime instead of the pre-adjustment bt value ? > > Is the > > "XXX shouldn't do this here. Should force non-`get' versions." > > part of the comment still valid? > --- > sys/kern/kern_tc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 088fcb41cfa..e7cfc51aff7 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -1413,10 +1413,9 @@ tc_windup(struct bintime *new_boottimebin) > if (bt.sec != t) > th->th_boottime.sec += bt.sec - t; > } > - th->th_bintime = th->th_offset; > - bintime_add(&th->th_bintime, &th->th_boottime); > /* Update the UTC timestamps used by the get*() functions. */ > /* XXX shouldn't do this here. Should force non-`get' versions. */ > + th->th_bintime = bt; > bintime2timeval(&bt, &th->th_microtime); > bintime2timespec(&bt, &th->th_nanotime); > > -- > 2.12.3 From owner-freebsd-hackers@freebsd.org Wed Oct 11 09:41: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 288ACE26808 for ; Wed, 11 Oct 2017 09:41:32 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from smtp.krpservers.com (smtp.krpservers.com [62.13.128.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.krpservers.com", Issuer "RapidSSL SHA256 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C58AB1A0A for ; Wed, 11 Oct 2017 09:41:31 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from [10.12.30.106] (host31-48-228-38.range31-48.btcentralplus.com [31.48.228.38]) (authenticated bits=0) by smtp.krpservers.com (8.15.2/8.15.2) with ESMTPSA id v9B9Dqg2075943 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Oct 2017 10:13:53 +0100 (BST) (envelope-from kpielorz_lst@tdx.co.uk) Date: Wed, 11 Oct 2017 10:13:35 +0100 From: Karl Pielorz To: freebsd-hackers@freebsd.org Subject: fprintf - threadsafe? - i.e. with process linked against '-pthread'? Message-ID: <03DA6274A199550235DC7351@[10.12.30.106]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 11 Oct 2017 09:41:32 -0000 Hi, I have a number of 10.3-R amd64 boxes which runs a heavily threaded process. This is linked against '-pthread' - and compiles / runs fine. Using 'fprintf' to log data to a file - it sometimes doesn't complete writing the line - e.g. literally in code: fprintf( fd, "The quick brown %s jumped over the slow lazy animal\n", animal ); Will sometimes result in: " The quick brown fox ju" Being written to the file. Presumably (and from what I can see) fprintf is 'thread safe'? - And it also appears multiple threads could write to a single file using it (i.e. it provides for atomic writes so lines won't intermingle - the lines written don't seem to intermingle). The process doesn't crash - but I can't understand why / how frpintf could either stop, or get stopped 'mid way' through? e.g. If a signal occurred would it complete the write to file? This only happens very, very occasionally (one fprintf out of many millions, with hundreds of threads running). Just a bit stumped as to what to try looking at to fix / debug the problem - if anyone has any suggestions, or further reading I can look at. -Karl From owner-freebsd-hackers@freebsd.org Wed Oct 11 09:49:10 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 B799CE269F1 for ; Wed, 11 Oct 2017 09:49:10 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.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 731EE1CC9 for ; Wed, 11 Oct 2017 09:49:10 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1e2DdT-0001qA-34; Wed, 11 Oct 2017 11:49:07 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e2DdS-0001bc-Ry; Wed, 11 Oct 2017 11:49:06 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id E09DF2A1677; Wed, 11 Oct 2017 11:49:02 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id b39luOFYEMKq; Wed, 11 Oct 2017 11:48:59 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A51F12A1678; Wed, 11 Oct 2017 11:48:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hUs5YazYYUi8; Wed, 11 Oct 2017 11:48:59 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 6E0462A1677; Wed, 11 Oct 2017 11:48:59 +0200 (CEST) Subject: Re: [PATCH] Simplify th_bintime update in tc_windup() To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org References: <20171011064816.20809-1-sebastian.huber@embedded-brains.de> <20171011093101.GX95911@kib.kiev.ua> From: Sebastian Huber Message-ID: <94f238ec-4cac-7c27-87ac-bc84d13d2eda@embedded-brains.de> Date: Wed, 11 Oct 2017 11:49:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171011093101.GX95911@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23935/Wed Oct 11 06:02:35 2017) 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, 11 Oct 2017 09:49:10 -0000 On 11/10/17 11:31, Konstantin Belousov wrote: > On Wed, Oct 11, 2017 at 08:48:16AM +0200, Sebastian Huber wrote: >> The th_bintime, th_microtime and th_nanotime members of the timehand a= ll >> cache the last system time (uptime + boottime). Only the format >> differs. Do not re-calculate the bintime and simply use the value use= d >> to calculate the microtime and nanotime. >> >> Group all the updates under the relevant comment. > th->th_bintime is recalculated after possible adjustments made by > the ntp loop to the th_boottime. The loop is: =C2=A0=C2=A0=C2=A0 bt =3D th->th_offset; =C2=A0=C2=A0=C2=A0 bintime_add(&bt, &th->th_boottime); <--- here the bt is our new system time =C2=A0=C2=A0=C2=A0 i =3D bt.sec - tho->th_microtime.tv_sec; =C2=A0=C2=A0=C2=A0 if (i > LARGE_STEP) =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 i =3D 2; =C2=A0=C2=A0=C2=A0 for (; i > 0; i--) { =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 t =3D bt.sec; =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ntp_update_second(&th->th_adjustme= nt, &bt.sec); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 if (bt.sec !=3D t) <-- here the bt.sec changed =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 th->th_boottime= .sec +=3D bt.sec - t; <-- here we update the boottime seconds, so now bt =3D=3D uptime + bootti= me =C2=A0=C2=A0=C2=A0 } So, I think the patch is correct. > > But your patch makes me consider the two lines after the XXX comment. > Shouldn't we use the updated th_bintime instead of the pre-adjustment > bt value ? > All values should reflect the same time. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Wed Oct 11 11:03: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 2163CE2880C for ; Wed, 11 Oct 2017 11:03:44 +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 ABF0063B66 for ; Wed, 11 Oct 2017 11:03:43 +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 v9BB3OmL022133 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Oct 2017 14:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9BB3OmL022133 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9BB3Or3022132; Wed, 11 Oct 2017 14:03:24 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Oct 2017 14:03:24 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org Subject: Re: [PATCH] Simplify th_bintime update in tc_windup() Message-ID: <20171011110324.GY95911@kib.kiev.ua> References: <20171011064816.20809-1-sebastian.huber@embedded-brains.de> <20171011093101.GX95911@kib.kiev.ua> <94f238ec-4cac-7c27-87ac-bc84d13d2eda@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <94f238ec-4cac-7c27-87ac-bc84d13d2eda@embedded-brains.de> User-Agent: Mutt/1.9.1 (2017-09-22) 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: Wed, 11 Oct 2017 11:03:44 -0000 On Wed, Oct 11, 2017 at 11:49:01AM +0200, Sebastian Huber wrote: > On 11/10/17 11:31, Konstantin Belousov wrote: > > > On Wed, Oct 11, 2017 at 08:48:16AM +0200, Sebastian Huber wrote: > >> The th_bintime, th_microtime and th_nanotime members of the timehand all > >> cache the last system time (uptime + boottime). Only the format > >> differs. Do not re-calculate the bintime and simply use the value used > >> to calculate the microtime and nanotime. > >> > >> Group all the updates under the relevant comment. > > th->th_bintime is recalculated after possible adjustments made by > > the ntp loop to the th_boottime. > > The loop is: > > ššš bt = th->th_offset; > ššš bintime_add(&bt, &th->th_boottime); > > <--- here the bt is our new system time > > ššš i = bt.sec - tho->th_microtime.tv_sec; > ššš if (i > LARGE_STEP) > ššš ššš i = 2; > ššš for (; i > 0; i--) { > ššš ššš t = bt.sec; > ššš ššš ntp_update_second(&th->th_adjustment, &bt.sec); > ššš ššš if (bt.sec != t) Can you fix your mail client ? The mail body is filled with the \x9a symbols which makes the text unreadable and requiring decyphering. > > <-- here the bt.sec changed > > ššš ššš ššš th->th_boottime.sec += bt.sec - t; > > <-- here we update the boottime seconds, so now bt == uptime + boottime > ššš } > > So, I think the patch is correct. Thank you for the explanation. I committed this as r324528. > > > > > But your patch makes me consider the two lines after the XXX comment. > > Shouldn't we use the updated th_bintime instead of the pre-adjustment > > bt value ? > > > > All values should reflect the same time. s/should// due to synchronity of the updates to bt and th_bootime, as you noted above. From owner-freebsd-hackers@freebsd.org Wed Oct 11 14:48: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 D4AEDE2E2B5 for ; Wed, 11 Oct 2017 14:48:18 +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 6C7FE6AC46 for ; Wed, 11 Oct 2017 14:48:18 +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 v9BEm9Qm073367 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 11 Oct 2017 17:48:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9BEm9Qm073367 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9BEm9cN073366; Wed, 11 Oct 2017 17:48:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 11 Oct 2017 17:48:09 +0300 From: Konstantin Belousov To: Karl Pielorz Cc: freebsd-hackers@freebsd.org Subject: Re: fprintf - threadsafe? - i.e. with process linked against '-pthread'? Message-ID: <20171011144809.GA95911@kib.kiev.ua> References: <03DA6274A199550235DC7351@[10.12.30.106]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03DA6274A199550235DC7351@[10.12.30.106]> User-Agent: Mutt/1.9.1 (2017-09-22) 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: Wed, 11 Oct 2017 14:48:18 -0000 On Wed, Oct 11, 2017 at 10:13:35AM +0100, Karl Pielorz wrote: > > Hi, > > I have a number of 10.3-R amd64 boxes which runs a heavily threaded > process. This is linked against '-pthread' - and compiles / runs fine. > > Using 'fprintf' to log data to a file - it sometimes doesn't complete > writing the line - e.g. literally in code: > > fprintf( fd, "The quick brown %s jumped over the slow lazy animal\n", > animal ); > > Will sometimes result in: > > " > The quick brown fox ju" > > Being written to the file. > > > Presumably (and from what I can see) fprintf is 'thread safe'? - And it > also appears multiple threads could write to a single file using it (i.e. > it provides for atomic writes so lines won't intermingle - the lines > written don't seem to intermingle). > > The process doesn't crash - but I can't understand why / how frpintf could > either stop, or get stopped 'mid way' through? > > e.g. If a signal occurred would it complete the write to file? > > This only happens very, very occasionally (one fprintf out of many > millions, with hundreds of threads running). > > Just a bit stumped as to what to try looking at to fix / debug the problem > - if anyone has any suggestions, or further reading I can look at. Does the program use cancellation ? If yes, it might be an issue solved by the r321074. Otherwise, you need to debug the program. I usually use ktrace for start, but if the event is rare and program intensively issues syscalls, you would need to develop some ad-hoc tecnhique. From owner-freebsd-hackers@freebsd.org Wed Oct 11 18:54:12 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 DD9ADE33B3F for ; Wed, 11 Oct 2017 18:54:12 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 9DED372A7C for ; Wed, 11 Oct 2017 18:54:12 +0000 (UTC) (envelope-from otacilio.neto@bsd.com.br) Received: by mail-qt0-x232.google.com with SMTP id n61so8214726qte.10 for ; Wed, 11 Oct 2017 11:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0fLqCF/3yocmpRLN47y4G6x/v2wMum8RltHRXoYyghc=; b=P48cw7QcyP+Nd4le9E7PlRsGk2gH/65H2X9FZ1p9GbjPnPUVg76PrtcO6WXu7UyWnL a7H3J+MkvMwwNuN/RVgx5Kit0YeckDbGP0sE560adEaEcMblo7H4cbwJ5ZaIHD1oQeet BT9y3gtkalaxZl21dGO1UhJkF3VgAtzY/AGfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0fLqCF/3yocmpRLN47y4G6x/v2wMum8RltHRXoYyghc=; b=a88u4Y8CjA8jw+Ug+YD2XhQTey/E0Zqqrp06W8r0HOcyKG87pEmFhz+ZNXJuKiBvO6 U7kGdVCmrHORODbG47O9cSQLk+wUkNDgY7k1397U19KvcPqEisoscSqqEHc7Swpg7H7g 5pb66H9il0gwX1MKJW2CBN1T06Cenlx3cA15yIY/N7bzGPaQWS1UL0unpYx9TlWVrMil ZFAQ0ICpjmi0QXo1SKe5WGg/WZm2CSdc14hl5X9PqWyJufUPl1hUZtFLfSkUDE2v7hbq V2TaSliV3VTVPkwIRJ6sRQfY+I/qn6bUTAm+VqfbuX9ZDB+rndwc+T3Gvv1ASDVM115t Z25w== X-Gm-Message-State: AMCzsaUTCUhgWqhaBzxRNCSIhE5TFMkogSM1PPu/RWEysyJjizgbU8g/ 51hyB4iF9yl/gNt2077VE34E/2rT+8E= X-Google-Smtp-Source: ABhQp+T/wdMsYZeyckaffp6VhFqe+xSzmLyntQeIAJHE5p+qPRA8atp4g09lSp0W5rMyM8jiPLHw4g== X-Received: by 10.233.244.74 with SMTP id z10mr916038qkl.31.1507748051290; Wed, 11 Oct 2017 11:54:11 -0700 (PDT) Received: from [192.168.43.219] (179-240-150-42.3g.claro.net.br. [179.240.150.42]) by smtp.googlemail.com with ESMTPSA id l1sm3561320qtf.5.2017.10.11.11.54.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 11:54:10 -0700 (PDT) Subject: Re: fprintf - threadsafe? - i.e. with process linked against '-pthread'? To: freebsd-hackers@freebsd.org References: <03DA6274A199550235DC7351@[10.12.30.106]> <20171011144809.GA95911@kib.kiev.ua> From: =?UTF-8?B?T3RhY8OtbGlv?= Message-ID: Date: Wed, 11 Oct 2017 15:54:01 -0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171011144809.GA95911@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: pt-BR 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, 11 Oct 2017 18:54:13 -0000 Em 11/10/2017 11:48, Konstantin Belousov escreveu: > On Wed, Oct 11, 2017 at 10:13:35AM +0100, Karl Pielorz wrote: >> Hi, >> >> I have a number of 10.3-R amd64 boxes which runs a heavily threaded >> process. This is linked against '-pthread' - and compiles / runs fine. >> >> Using 'fprintf' to log data to a file - it sometimes doesn't complete >> writing the line - e.g. literally in code: >> >> fprintf( fd, "The quick brown %s jumped over the slow lazy animal\n", >> animal ); >> >> Will sometimes result in: >> >> " >> The quick brown fox ju" >> >> Being written to the file. >> >> >> Presumably (and from what I can see) fprintf is 'thread safe'? - And it >> also appears multiple threads could write to a single file using it (i.e. >> it provides for atomic writes so lines won't intermingle - the lines >> written don't seem to intermingle). >> >> The process doesn't crash - but I can't understand why / how frpintf could >> either stop, or get stopped 'mid way' through? >> >> e.g. If a signal occurred would it complete the write to file? >> >> This only happens very, very occasionally (one fprintf out of many >> millions, with hundreds of threads running). >> >> Just a bit stumped as to what to try looking at to fix / debug the problem >> - if anyone has any suggestions, or further reading I can look at. > Does the program use cancellation ? If yes, it might be an issue solved > by the r321074. > > Otherwise, you need to debug the program. I usually use ktrace for start, > but if the event is rare and program intensively issues syscalls, you would > need to develop some ad-hoc tecnhique. > _______________________________________________ > 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" This program is able to reproduce the wrong behavior that you report as it also contains a solution to it. I tested on a FreeBSD 11.1 running on the virtualbox with three processors. To compile with bug cc -Wall -O2 -o main main.c -lpthread -DBUGED ./main 10 out To compile without bug cc -Wall -O2 -o main main.c -lpthread ./main 10 out If your problem is something like this, apparently the solution is for all threads to use the same variable FILE * #include #include #include #include #include #include #ifndef MAX_THREADS #define MAX_THREADS    1000 #endif void *thread_main(void *file){     unsigned int i;     #ifdef BUGED     FILE *arquivo  = fopen((char*)file, "a");     #else     FILE *arquivo = (FILE*) file;     #endif     for(i=0; i<3000; i++){         fprintf(arquivo, "The quick brown %d jumped over the slow lazy animal %d\n", getpid(), i);         pthread_yield();     }     pthread_exit(NULL);     return NULL; } int main(int argc, char **argv){     unsigned int j;     unsigned int threads;     static pthread_t mythread[MAX_THREADS];     FILE *arquivo;     if(argc != 3){         fprintf(stderr,"Use %s \n", argv[0]);         exit(EXIT_FAILURE);     }     threads = (unsigned int)strtol(argv[1], (char **)NULL, 10);     if(threads>MAX_THREADS){         fprintf(stderr, "Max thread suppor %dt\n", MAX_THREADS);         exit(EXIT_FAILURE);     }     if((arquivo = fopen(argv[2],"w+"))==NULL){         fprintf(stderr, "fopen error\n");         exit(EXIT_FAILURE);     }     for(j=0; j < threads; j++){         #ifdef BUGED         if (pthread_create( &mythread[j], NULL, thread_main, argv[2])){         #else         if (pthread_create( &mythread[j], NULL, thread_main, arquivo)){         #endif             fprintf(stderr,"thread create error.\n");             exit(EXIT_FAILURE);         }     }     //Vamos esperar pela conclusão de cada um dos threads     for(j=0; j 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 7CA57E378D0 for ; Wed, 11 Oct 2017 21:34:56 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D50C7D464 for ; Wed, 11 Oct 2017 21:34:56 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABC21B104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abc2:1b10:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 82FD617209B for ; Wed, 11 Oct 2017 23:34:53 +0200 (CEST) Date: Wed, 11 Oct 2017 23:34:52 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: fprintf - threadsafe? - i.e. with process linked against '-pthread'? Message-ID: <20171011213452.GB32399@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <03DA6274A199550235DC7351@[10.12.30.106]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03DA6274A199550235DC7351@[10.12.30.106]> User-Agent: Mutt/1.9.0 (2017-09-02) 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, 11 Oct 2017 21:34:56 -0000 On Wed, Oct 11, 2017 at 10:13:35AM +0100, Karl Pielorz wrote: > Presumably (and from what I can see) fprintf is 'thread safe'? - And it also > appears multiple threads could write to a single file using it (i.e. it > provides for atomic writes so lines won't intermingle - the lines written > don't seem to intermingle). stdio does not provide atomic IO. If you have two file handles or even just two separate FILE instances sharing the same file handle and two threads or processes are writing to them concurrently, buffering will result in seemingly random interwoven output. Even using non-buffered IO can trigger the same behavior as there is internal blocking going on. Try a printf that created i.e. 16K output or so in one way, it should increase the chance of seeing this a lot. Joerg From owner-freebsd-hackers@freebsd.org Wed Oct 11 21:54: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 5108CE38449 for ; Wed, 11 Oct 2017 21:54:24 +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 D7D6D7E65A for ; Wed, 11 Oct 2017 21:54:23 +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 v9BLsIY4070384 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 12 Oct 2017 00:54:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v9BLsIY4070384 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v9BLsHdZ070383 for freebsd-hackers@freebsd.org; Thu, 12 Oct 2017 00:54:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Oct 2017 00:54:17 +0300 From: Konstantin Belousov To: freebsd-hackers@freebsd.org Subject: Re: fprintf - threadsafe? - i.e. with process linked against '-pthread'? Message-ID: <20171011215417.GH95911@kib.kiev.ua> References: <03DA6274A199550235DC7351@[10.12.30.106]> <20171011213452.GB32399@britannica.bec.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171011213452.GB32399@britannica.bec.de> User-Agent: Mutt/1.9.1 (2017-09-22) 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: Wed, 11 Oct 2017 21:54:24 -0000 On Wed, Oct 11, 2017 at 11:34:52PM +0200, Joerg Sonnenberger wrote: > On Wed, Oct 11, 2017 at 10:13:35AM +0100, Karl Pielorz wrote: > > Presumably (and from what I can see) fprintf is 'thread safe'? - And it also > > appears multiple threads could write to a single file using it (i.e. it > > provides for atomic writes so lines won't intermingle - the lines written > > don't seem to intermingle). > > stdio does not provide atomic IO. If you have two file handles or even > just two separate FILE instances sharing the same file handle and two > threads or processes are writing to them concurrently, buffering will > result in seemingly random interwoven output. Even using non-buffered IO > can trigger the same behavior as there is internal blocking going on. > Try a printf that created i.e. 16K output or so in one way, it should > increase the chance of seeing this a lot. Indeed stdio does not provide atomic IO, but it is thread-safe. That is, each isolated stdio operation, except the ones with explicit _unlocked suffix, are required to take an exclusive ownership on the FILE for the duration of the operation. See the description of flockfile(). From owner-freebsd-hackers@freebsd.org Wed Oct 11 23:03:19 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 D6107E39BE8 for ; Wed, 11 Oct 2017 23:03:19 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6ADE80F1C for ; Wed, 11 Oct 2017 23:03:19 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABC21B104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abc2:1b10:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 80865A80D1 for ; Thu, 12 Oct 2017 01:03:17 +0200 (CEST) Date: Thu, 12 Oct 2017 01:03:16 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: fprintf - threadsafe? - i.e. with process linked against '-pthread'? Message-ID: <20171011230316.GA21395@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <03DA6274A199550235DC7351@[10.12.30.106]> <20171011213452.GB32399@britannica.bec.de> <20171011215417.GH95911@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171011215417.GH95911@kib.kiev.ua> User-Agent: Mutt/1.9.0 (2017-09-02) 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, 11 Oct 2017 23:03:20 -0000 On Thu, Oct 12, 2017 at 12:54:17AM +0300, Konstantin Belousov wrote: > On Wed, Oct 11, 2017 at 11:34:52PM +0200, Joerg Sonnenberger wrote: > > On Wed, Oct 11, 2017 at 10:13:35AM +0100, Karl Pielorz wrote: > > > Presumably (and from what I can see) fprintf is 'thread safe'? - And it also > > > appears multiple threads could write to a single file using it (i.e. it > > > provides for atomic writes so lines won't intermingle - the lines written > > > don't seem to intermingle). > > > > stdio does not provide atomic IO. If you have two file handles or even > > just two separate FILE instances sharing the same file handle and two > > threads or processes are writing to them concurrently, buffering will > > result in seemingly random interwoven output. Even using non-buffered IO > > can trigger the same behavior as there is internal blocking going on. > > Try a printf that created i.e. 16K output or so in one way, it should > > increase the chance of seeing this a lot. > > Indeed stdio does not provide atomic IO, but it is thread-safe. That is, > each isolated stdio operation, except the ones with explicit _unlocked > suffix, are required to take an exclusive ownership on the FILE for the > duration of the operation. See the description of flockfile(). That why I said "two separate FILE instances" :) The locking happens in the FILE, not on the file descriptor. Joerg From owner-freebsd-hackers@freebsd.org Thu Oct 12 15:21: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 3E5EAE2CAA9 for ; Thu, 12 Oct 2017 15:21:22 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 E6E83808B0 for ; Thu, 12 Oct 2017 15:21:21 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x233.google.com with SMTP id w45so3282990uac.3 for ; Thu, 12 Oct 2017 08:21:21 -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; bh=GJztWcDTv+H9glxXMfebfrL0FanfcezQYdKZI4T8NVM=; b=CseRZxl3pwAZQ55GHJq2HBhJqRKNwXqyiHlQVdeydRldZbyWIz+aWhvq+hOxyf45Gx hVoJdZzvpBXHdwJr0lXsLAUALDyYwrl++kxVucnBO/lFfjVzySwhkoBSz2z2Wseh7CNu ErPonuU4CDUaRcNo8JT6G/k9nYbWHBWdOtdEAkfdWfYZ+gQ7ZA2GpnN2An4Mmo9Pzea/ sVnvnHKhSy4vIFfcpCZM/cLeZWL27TrVP6QhhL4rzDmVu0uVh4cH4XVogx6mUxPzWTxP 9QmuvEfQAc5HoXJ1LWJsgAwRia56WkrtnAVjD4ogQjTIo72IUKm/3hIKQE61NfbCTURK wAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GJztWcDTv+H9glxXMfebfrL0FanfcezQYdKZI4T8NVM=; b=je/WuQkwHyG9jyAgMoBH12ob/GpCM/PwfEH06qMuxjoIE/9U+G/nWJ7G6PwsC5STaY ur3SJHN5puLWPShSfZ5/qfSKIwBl04kLNDrKEUfYF53Hhj7dPuofugyDj7ubNQtkuT/f QBWtE9swa+7GobuPvCYiZXdVMq+1jO77FhCMuF/F46QVTOOGMkBSPUlL23zsaHr/19by O6gFtdGwnE7qgbZda8n6DYq9mlJQnevORHHxjjgNrqrr6M9QK5Wb7Ev+0C/p+BBIRog6 Ll7JpzpJV+dwmaUP/hK/O6ZNpNEigO8vikovPJ+oFwM97ps5Cup+GAgd+BpjBNCla1zU qNRA== X-Gm-Message-State: AMCzsaUVy+DtFPhbBvm8OZYZDyZwaOJD+bnxQPR7FWi2H4l3MDWnMqEy tWXtf+L6W+YHXQol1uIh7JnMenb6wCCuzgwSuEAXwfEX X-Google-Smtp-Source: AOwi7QC9WrQGEXe5/uTSYtPoCQF0cJ1BRo/oKGGXZGADgxtwOM15xiJL27GR0PG8S44jthH6EZv+KxxESRbwsOWFJz0= X-Received: by 10.159.36.168 with SMTP id 37mr543291uar.187.1507821680684; Thu, 12 Oct 2017 08:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.131.80 with HTTP; Thu, 12 Oct 2017 08:21:20 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Thu, 12 Oct 2017 23:21:20 +0800 Message-ID: Subject: Re: [RFC] geli - Allow attaching multiple providers To: 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, 12 Oct 2017 15:21:22 -0000 On 28 May 2017 at 13:38, Ben Woods wrote: > Hi everyone, > > I would like to propose a patch to geli to allow multiple providers to be > attached in a single command if they use the same passphrase/keyfiles. > > This is helpful when the providers being attached are not used for boot, > and therefore the existing code to first try the cached password when > tasting the providers during boot does not apply. > > Multiple providers with the same passphrase and keyfiles can be attached > at the same time during system start-up by adding the following to > /etc/rc.conf: > > geli_groups="storage backup" > geli_storage_flags="-k /etc/geli/storage.keys" > geli_storage_devices="ada0 ada1" > geli_backup_flags="-j /etc/geli/backup.passfile -k /etc/geli/backup.keys" > geli_backup_devices="ada2 ada3" > > The patch is up for review on phabricator here: > https://reviews.freebsd.org/D9396 > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > Hi everyone, I have created a new phabricator review for this work to allow multiple providers to be attached in a single geli command if they use the same passphrase/keyfiles. Unlike D9396, this implementation does not modify the kernel. This is achieved by creating a new child geom request for each provider being attached, and passing each request to the kernel one by one. The new patch can be found here: https://reviews.freebsd.org/D12644 I am hoping people can review and comment on this patch, and that I can get assistance committing this once it is approved (as I am only a ports committer). Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-hackers@freebsd.org Thu Oct 12 15:18: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 8707CE2C832; Thu, 12 Oct 2017 15:18:26 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 3E169803FD; Thu, 12 Oct 2017 15:18:26 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x236.google.com with SMTP id w45so3276194uac.3; Thu, 12 Oct 2017 08:18:26 -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; bh=f9wy+PoAqlzCnyuBy3Q43zrR2/G2YUWZQ2E36/PPhcA=; b=HmjTTJx0ddOIINww8apm5xZLMiwsQ5WOJLRATfeWPjCnZpq28EOa+9G1s5gQD6jKxs tiApA4d6MsggFKmTVXkcDoEE0ELeMps5l4zaBpDo5+ibRtVfW0d7ZxceKYY45PS0fTo8 VwDav+nmvk6dyxYdY1dYcQG4R5OOsJE6w+oxlNHPoE+qSx2LXewuJ10nuWHGm16pU+pO e9TY8pcKdr4AmA+NHUimxPnFFL/3tNIl1IFKWJkmF7zmjdZgkUZBiM2W9Cv9U/gy7AOo xz4jzTqOB19j64NBICQqXxs0oLzqkTeE5UsZu451vRGPZDlaUMtNDoERBbjzeEoDhxfO KUHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=f9wy+PoAqlzCnyuBy3Q43zrR2/G2YUWZQ2E36/PPhcA=; b=Zhin1Cpdty4KbtfhNZ/F7vrKIn/t3blE9NSQCyfnWSHYNOAgHBuOEv9W+ml2oe646Q r39Drv5HBkcvRT53kqU3EyrqJ1gsnssJu/8ttVuKqYZnigV5/FuYTtHGk/7yTpfgcQe3 MGi/8tTC6cdBIQvVMjSzY4/kTkVfoW5IU5oCRVxTRReowwbaZf/FYbKcr3ZfR0R0uEPF qkMg0mJeu6MOXYBjj4Ac+w377wc5P7BFrfslWWAmTJCIpBvlOd0dUFk4EMGKanvuQW3l pKT6Dqo4IL7w5wfSJJflnOJLaG/M4A2YPaWLWQR6WgdVpXeyoJ8MTM5ddUHHmCEtc6bq LZRw== X-Gm-Message-State: AMCzsaXViJ9q88FoEpgEn044c4J99XuXhfo6gdAXVr+VoJAGggzl1Prh DeJeOdqfzx58YAuaxOiasjpOCTBZWYzS/qJExF3jXGYW X-Google-Smtp-Source: AOwi7QBSS5/EvTuYblsjDig41ga4uSBe2leeTgkELYmu32Frp1L1pXn2Fnd5ZHPp79lZA3fcQIeuepQMqM8deuoOl8A= X-Received: by 10.176.16.18 with SMTP id f18mr567208uab.108.1507821501773; Thu, 12 Oct 2017 08:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.131.80 with HTTP; Thu, 12 Oct 2017 08:18:21 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Thu, 12 Oct 2017 23:18:21 +0800 Message-ID: Subject: Re: [RFC] geli - Allow attaching multiple providers To: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Thu, 12 Oct 2017 16:19:18 +0000 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, 12 Oct 2017 15:18:26 -0000 On 28 May 2017 at 13:38, Ben Woods wrote: > Hi everyone, > > I would like to propose a patch to geli to allow multiple providers to be > attached in a single command if they use the same passphrase/keyfiles. > > This is helpful when the providers being attached are not used for boot, > and therefore the existing code to first try the cached password when > tasting the providers during boot does not apply. > > Multiple providers with the same passphrase and keyfiles can be attached > at the same time during system start-up by adding the following to > /etc/rc.conf: > > geli_groups="storage backup" > geli_storage_flags="-k /etc/geli/storage.keys" > geli_storage_devices="ada0 ada1" > geli_backup_flags="-j /etc/geli/backup.passfile -k /etc/geli/backup.keys" > geli_backup_devices="ada2 ada3" > > The patch is up for review on phabricator here: > https://reviews.freebsd.org/D9396 > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > Hi everyone, I have created a new phabricator review for this work to allow multiple providers to be attached in a single geli command if they use the same passphrase/keyfiles. Unlike D9396, this implementation does not modify the kernel. This is achieved by creating a new child geom request for each provider being attached, and passing each request to the kernel one by one. The new patch can be found here: https://reviews.freebsd.org/D12644 I am hoping people can review and comment on this patch, and that I can get assistance committing this once it is approved (as I am only a ports committer). Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com From owner-freebsd-hackers@freebsd.org Sat Oct 14 01:50: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 874F0E34827; Sat, 14 Oct 2017 01:50:55 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ua0-x242.google.com (mail-ua0-x242.google.com [IPv6:2607:f8b0:400c:c08::242]) (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 477F781B71; Sat, 14 Oct 2017 01:50:55 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ua0-x242.google.com with SMTP id s41so6448755uab.10; Fri, 13 Oct 2017 18:50: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=3rlXma3ZwBMFSoOR5TTiOnZPidAOhB9tJ+FPyeAyXFQ=; b=fr0C/hNRNWEQW1RU6h7LD0R6uT3llP8Wy9Tpu0Oh9PdursOxT4uo1xeKtXNm/co1xx 7A0Mvu0NQBAFTNqIOW35nQNVsVj9G88fPddlT/gnXIECvBsjo2adKDGuR3oXaYVkHbjz 6sSAOLY/mCTcso8iM+4ONWgqtmUxWJSxy1HzKZjDC/DD6d7ergEYWtSfldPx8hrdULR+ DP0C4AyaXKl4KnBwMV9/wHijsg0U1vz9iluEi67kT2Pu64EJTonIp9lC06eAeARJ2ld1 H/eOdUA6syNdV0p7Y/J/l1xxXL4OO3JlxKfJBlZMtsGkBo73oSRB5PmD+x6sgt/D5wsx 7eZA== 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=3rlXma3ZwBMFSoOR5TTiOnZPidAOhB9tJ+FPyeAyXFQ=; b=edGtfLpK4991C2KLABOe+WwwUBAFaY+B2ZXtfuFlE0ubD9hF8h5K6Jy6t/sfEX2fph AJL4+uKnZOLeqpI6fNwweBgOKwfJCJma99EMPpvzqilXs1pSexysqU19qSSqU5KxD786 XIYhNZZjhSL/T/Hfmbt0wHqZ4hJYsz1Fa/TpoeDWGoi15JQwkgRZiNfSaXjwRcmJ2wK/ pZpYelVDrhqkrC7PGWfs4CVUDTGtx829DBQA62cmvdWK0nXCm5C2ao+Mw3bRtsvXHayR rVBbfYDshgYOF6T6yHRfw/F8x2Mry2fs/H1CwYuRd2OE2gb0jtkOM00Cl3aGP1YvmnkF k0Ag== X-Gm-Message-State: AMCzsaXUoc1D8YNL2my5Vv3h98e9jdLTNCFUW+VxxmNdWGE1d4nXI9Ox LJk0x4xuHk26VLe3OtsrcVGCYW6Lotnh7Wm+LEZgQA== X-Google-Smtp-Source: AOwi7QBi2etPYGXUWLktm2EaxQ5mJD4Hkqcg24ZeeF0xdLJtWzL3Jf2RgbW+lNRSOLYU9J3DGTJe4S6Vzf4SC4oxN4E= X-Received: by 10.176.75.195 with SMTP id b3mr2628042uag.51.1507945853438; Fri, 13 Oct 2017 18:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.50.129 with HTTP; Fri, 13 Oct 2017 18:50:13 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Fri, 13 Oct 2017 21:50:13 -0400 Message-ID: Subject: Re: Power9 Inexpensive Development Testbed To: freebsd-hardware@freebsd.org Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org, freebsd-performance@freebsd.org, info@freebsdfoundation.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 14 Oct 2017 04:10:38 +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, 14 Oct 2017 01:50:55 -0000 On Mon, Oct 9, 2017 at 5:59 PM, grarpamp wrote: > With Power8 aging and Power9 shipping... Consider picking up a > couple of these to support the development of getting FreeBSD going > on the bare iron without hypervisor. FreeBSD being a member already, > good support for this effort should be available from the OpenPOWER > Foundation / IBM. They seem to want to make Power9 and beyond happen > in a big way. Linux also has support for Power9. > > A barebones selfbuilt machine for the dev cluster would cost about > $3200-$3500, and/or donation could be solicited from OpenPOWER > Foundation. > > https://raptorcs.com/TALOSII/ > https://raptorcs.com/content/base/faq.html > https://github.com/open-power > https://github.com/openbmc > https://wikipedia.org/wiki/POWER9 > https://openpowerfoundation.org/ > > Just an FYI for those unfamiliar, including potential users. > > This thread could be updated to list other Power9 > hardware sources as they become known by > the FreeBSD community. Adding some more "official" links about this CPU and platform for anyone interested. Some of them may refer to Power8, which can be viewed as carrying over plus better to Power9. The Open Power Foundation / IBM full release, marketing, and public availability of Power9 seems to be set for 2018q1. So expect more vendors and so forth at that time. *** Note that this platform apparently does not have any closed source firmware / microcode or BIOS blobs. That means no Intel AMT / ME, no AMD PSP, etc. Programming documentation should be available. And seems to perform competetively on a number of fronts / tasking. *** https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.raptorengineering.com/TALOS/op_qemu_gl.php https://www.raptorengineering.com/content/base/canary.htm https://secure.raptorcs.com/blog/08212017001.php https://social.raptorengineering.io/main/public https://www.reddit.com/user/madscientist159 https://twitter.com/RaptorEng https://twitter.com/RaptorCompSys https://www.reddit.com/user/stwcx https://wikipedia.org/wiki/OpenPOWER_Foundation https://www.ibm.com/power/operating-systems/linux https://www.ibm.com/Search/?q=power9 https://twitter.com/ibmpowerlinux http://tyan.com/campaign/OpenPOWER/ http://www.fsf.org/resources/hw/endorsement/respects-your-freedom https://www.fsf.org/blogs/licensing/only-a-short-time-left-to-pre-order-the-talos-ii-pre-orders-end-september-15th You can search some third party sites for performance, news, and reviews. Search on "openpower" or "power9". https://twitter.com/search?q=power9 https://www.nextplatform.com/?s=power9 https://www.servethehome.com/?s=openpower https://www.anandtech.com/SearchResults?q=openpower http://www.storagereview.com/search/node/openpower https://hn.algolia.com/?query=power9&sort=byDate&prefix&page=0&dateRange=all&type=story Some articles that have appeared... https://www.nextplatform.com/2016/04/06/inside-future-google-rackspace-power9-system/ https://www.nextplatform.com/2017/09/19/power9-rollout-begins-summit-sierra/ https://blog.rackspace.com/the-latest-zaius-barreleye-g2-open-compute-openpower-server https://www.enterprisetech.com/2014/07/15/open-sourced-bios-helps-power8-compete-x86/ http://www.theplatform.net/2015/03/23/inside-the-rackspace-openpower-megaserver/ https://news.ycombinator.com/item?id=12351319 https://news.ycombinator.com/item?id=14956257 https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.8-More-POWER9 https://www.phoronix.com/scan.php?page=news_item&px=Power-Changes-Linux-4.12 https://www.phoronix.com/scan.php?page=news_item&px=Raptor-Talos-2-Teaser https://www.phoronix.com/scan.php?page=news_item&px=Talos-2-POWER9-Pre-Order https://www.phoronix.com/scan.php?page=news_item&px=Talos-2-FSF-RYF-Possible FreeBSD status... https://wiki.freebsd.org/POWER8 https://www.freebsdnews.com/2015/03/04/freebsd-power8-its-alive-2/ https://svnweb.freebsd.org/base?view=revision&revision=279189 https://www.freebsd.org/news/status/report-2015-01-2015-03.html#FreeBSD-on-POWER8 https://reviews.freebsd.org/search/query/oIdoWWKTe71p/ Sorry don't know which list is best, perhaps hardware@? Anyway, happy hacking :) From owner-freebsd-hackers@freebsd.org Sat Oct 14 03:49: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 6679AE3A35C; Sat, 14 Oct 2017 03:49:45 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 448E616B6; Sat, 14 Oct 2017 03:49:44 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 4791ABFC; Fri, 13 Oct 2017 22:49:38 -0500 (CDT) Date: Fri, 13 Oct 2017 22:49:37 -0500 From: Mark Linimon To: grarpamp Cc: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org, freebsd-performance@freebsd.org, info@freebsdfoundation.org, freebsd-questions@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Power9 Inexpensive Development Testbed Message-ID: <20171014034936.GA18066@lonesome.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sat, 14 Oct 2017 10:37:18 +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, 14 Oct 2017 03:49:45 -0000 A few of us FreeBSD/powerpc64 fans are watching the developments closely. mcl From owner-freebsd-hackers@freebsd.org Sat Oct 14 23:54: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 8D61AE3001B; Sat, 14 Oct 2017 23:54:38 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 28AD0C65; Sat, 14 Oct 2017 23:54:37 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-9e7ff70000002861-74-59e2a3b5116c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id C2.71.10337.5B3A2E95; Sat, 14 Oct 2017 19:54:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v9ENsPSY003012; Sat, 14 Oct 2017 19:54:27 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v9ENsMUj025588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Oct 2017 19:54:25 -0400 Date: Sat, 14 Oct 2017 18:54:22 -0500 From: Benjamin Kaduk To: freebsd-hackers@FreeBSD.org Cc: freebsd-current@FreeBSD.org Subject: FINAL CALL for 2017Q3 quarterly status reports Message-ID: <20171014235422.GJ96685@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Vxa5joy26gVGOrvU" Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6nortt8aNIg54JjBZz3nxgsti++R+j A5PHjE/zWQIYo7hsUlJzMstSi/TtErgy/m44zVKwR7hi869VjA2MHwS6GDk5JARMJPauOcLS xcjFISSwmEmiZXEfO4SzkVHi0KxfUJmrTBI/ljYwgbSwCKhKzHzwiQ3EZhNQk1i/4hoziC0i IC+xr+k9O4jNDGT/2toEZHNwCAuYS7xfbQcS5gXa9uLUWTYIW1Di5MwnLBDlZRKrWyewgJQz C0hLLP/HARIWFVCWmLdvFdsERr5ZSDpmIemYhdABEdaSuPHvJROGsK3EunXvWRYwsq1ilE3J rdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIClhOSd4djP/ueh1iFOBgVOLhzch6FCnE mlhWXJl7iFGSg0lJlPdc68NIIb6k/JTKjMTijPii0pzU4kOMKkC7Hm1YfYFRiiUvPy9VSYSX zRGolTclsbIqtSgfpkyag0VJnHdb0K5IIYH0xJLU7NTUgtQimKwMB4eSBG/XIqBGwaLU9NSK tMycEoQ0EwfnIUYJDh6g4W9AaniLCxJzizPTIfKnGBWlxHmngSQEQBIZpXlwvaBEI5G9v+YV ozjQW8K8G0GqeIBJCq77FdBgJqDB7yIegAwuSURISTUwzpSKVQ/7nNo8TXK9WlhayFy9aZ9m HJqQKlm9OnxOks/uDvXrd/65f1+cE37zlOnkzW3zJNXmqZ5jYztnqlez89GbzqDZEWttu210 b8/681WoeHux5rI9+29lvVi+cENOprxX235lV8Nu7gafH6ay7FnC1k0rkt+dfaA0b8fRuIBz zxQd+n8rKLEUZyQaajEXFScCAP9kQT8PAwAA 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, 14 Oct 2017 23:54:38 -0000 --Vxa5joy26gVGOrvU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear FreeBSD Community, This is the last call for submissions for the 2017Q3 FreeBSD Quarterly Status update. The deadline for submissions is October 21, 2017, for work done in July through September. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . (Do be sure, though, to save the form output and not the form itself! In particular, the Google Chrome "save as" function does not save the generated output for some reason.) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017Q3 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html [5] https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html --Vxa5joy26gVGOrvU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlnio6gACgkQKNmm82Tr dRJMZAwg2OSeTx3F07vu0AlAWiHwJHuXlLszDWogAzSlR9j+rUmJ7wOtx9wjzoT9 XXT72qpqcgH9RJv4hXzFzt6VwI1yd7yDuqeucFYnPQbo87kGfHQLMXXcQT+IXCDo rmQiTAOs7uNHsyq9dlFMu2sxZlx/WURHuFXkNFR+jcly+bpVg2vFNyUwKSX7Ghsj 9U45k+jgJk/tTjCgFSXzonKM0lLovy0AVN2+vNGoG+/dU8JZb0GgZ4h2OzpYh28V fRAXN8YKEeKLielgiy7z7vtrPH7O/2TcqyjHbBOWCXlExbCJm3UBn0XXdnsp+oxY +iYDDUC3kD2m2tre0jFJvF09DulF97ornX+nqCSROX01WKp0XgEUK9qJe2SEU7Gz JuzMiyxpA8IaVgWHQ5or3NAgM0c0QcSpgPNDlZlPZ1/UDseGQBBRkygYvFRahnrG vM5AxWHFlj6LyZ1bhZcRCFeIWLLjkf12Hp1jj2s1S5FYzZJywraTUaBbzMag+7YN kPHCvEkBcZf/tQ== =DsOO -----END PGP SIGNATURE----- --Vxa5joy26gVGOrvU--